TN-4X

323-1121-101

SDH TRANSMISSION

Nortel TN-4XSoftware Description

Release 2.4 Standard February 1997

323-1121-101 Release 2.4 Standard TN-4X Software Description

SDH TRANSMISSION

Nortel TN-4X

Software Description

Copyright Coypright statement Country of printing NT confidential NTE disclaimer Trademarks

Copyright

1996, 1997 Northern Telecom

The copyright of this document is the property of Northern Telecom. Without the written consent of Northern Telecom, given by contract or otherwise, this document must not be copied, reprinted or reproduced in any material form, either wholly or in part, and the contents of this document, or any methods or techniques available therefrom, must not be disclosed to any other person whatsoever.

Printed in England

NORTHERN TELECOM CONFIDENTIAL:

The information contained in this document is the property of Northern Telecom. Except as specifically authorized in writing by Northern Telecom, the holder of this document shall keep the information contained herein confidential and shall protect same in whole or in part from disclosure and dissemination to third parties and use same for evaluation, operation, and maintenance purposes only.

So far as Nortel Limited is aware the contents of this document are correct. However, such contents have been obtained from a variety of sources and Nortel Limited can give no warranty or undertaking and make no representation as to their accuracy. In particular, Nortel Limited hereby expressly excludes liability for any form of consequential, indirect or special loss, and for loss of data, loss of profits or loss of business opportunity, howsoever arising and whether sustained by the user of the information herein or any third party arising out of the contents of this document.

Document Number: 323-1121-101Document Issue: Release 2.4Document Status: StandardProduct Release Number: 2.4Date: February 1997

iii

Publication historySeptember 1995

Release 1.7 Standard

May 1996Release 2.1.1 Standard

February 1996Release 2.4 Standard

End of chapter file


v

ContentsAbout this document xi

Technical support and information xii

Chapter 1: Introduction 1-1SDH network 1-1Basic terminology and concepts 1-3

Objects and object classes 1-3Manager agent model 1-4

Network Element software overview 1-5Hardware/software relationship 1-5Building blocks 1-6Structure of the Network Element software 1-6Application software of the management & communication unit (MCU) 1-6Application Software of the Peripheral Units 1-7Infrastructure 1-7

Chapter 2: Application software of the Management and communication unit 2-1Overview 2-1

Structure of the management application function 2-1Functional areas 2-1Naming conventions and diagrams 2-3Chapter Structure 2-4

CMIS agent and event report management 2-5Definition of terms 2-5Tasks of the CMIS agent and the event report management 2-7The functions of the CMIS agent and the event report management system 2-8

Fault management 2-12Definition of Terms 2-12Fault management tasks 2-13Fault management functions 2-14

Network element management 2-16Definition of terms 2-16Network element management task 2-16Functions of the network element management 2-18

Equipment management 2-22Definition of terms 2-22Equipment management tasks 2-22Functions of the equipment management 2-24


vi

Contents

Transmission object management 2-29Definition of terms 2-29Tasks of the transmission object management 2-32Functions of the transmission object management 2-34

Connection management 2-39Definition of terms 2-39Connection management tasks 2-41Connection management functions 2-43

Protection management 2-48Protection management tasks 2-51Protection management functions 2-52

Timing generator management 2-55Definition of terms 2-55Timing generator management tasks 2-56Functions of timing generator management 2-58

Data restoration services 2-61Definition of terms 2-61Data Restoration Service Tasks 2-61Functions of the data restoration services 2-62

Common services 2-65Definition of terms 2-65Common services building blocks 2-65

Chapter 3: Application software of the peripheral units 3-1Introduction 3-1General hardware control 3-3

Functions and Processes of the PU software 3-3PU data handling 3-4‘Unitcontroller’ object class 3-12PU Alarm Handling 3-15PU protection 3-20

Specific hardware control 3-21TIU-1 3-21TIU-3 3-24TIU-4 3-28SIU-1/4 3-33CMU-1 3-38PPU-1 3-39

Hardware access 3-42General structure and function 3-43Driver functions 3-45Hardware access of the synchronous interface units 3-47

TN-4X Software Description 323-1121-101 Release 2.4 Standard

Contents

vii

Chapter 4: Infrastructure 4-1Introduction 4-1System services 4-2

Structure of the system services 4-3Operating system 4-3Operating system functions 4-8Basic infrastructure 4-14Functions of the basic infrastructure software 4-15Message services 4-17Data block handler 4-18Local address services 4-19Hardware drivers 4-20General building blocks 4-21

Communication services 4-21Interfaces 4-21Functions 4-22The OSI model – brief overview 4-23Structure of the network communication 4-24Distribution of management data 4-33Software download 4-36

Chapter 5: MCU/PU software configuration 5-1Introduction 5-1Configuration of the MCU software 5-3

Overview 5-3Building blocks employed 5-4

Configuration of the PU software 5-8Overview 5-8Building blocks employed 5-9

‘Software configuration’ overview 5-13

Index 6-1

FiguresFigure 1-1 Management of regional subnetworks 1-2Figure 1-2 Manager agent model 1-4Figure 1-3 The network element software concept 1-5Figure 1-4 Structure of the network element software 1-6Figure 2-1 Tasks of the management application function 2-1Figure 2-2 Sample functional area 2-3Figure 2-3 Context of the sample software 2-4Figure 2-4 Communication between NE and management system 2-5Figure 2-5 Tasks of the CMIS agent and the event report management 2-7Figure 2-6 Context of the CMIS agent and the event report management 2-8Figure 2-7 Communication with the network management system 2-9Figure 2-8 Forwarding network management commands 2-10Figure 2-9 Fault management task 2-13Figure 2-10 Context of fault management tasks 2-14Figure 2-11 Network element management task 2-17Figure 2-12 Context of the tasks of the network element management

system 2-17Figure 2-13 Completing the system start-up 2-19Figure 2-14 Tasks of the equipment management system 2-23


viii

Contents

Figure 2-15 Context of the equipment management 2-24Figure 2-16 Multiplex structure 2-31Figure 2-17 Transmission object management tasks 2-32Figure 2-18 Context of the transmission object management 2-34Figure 2-19 Bidirectional point-to-point connection 2-39Figure 2-20 Subbuses in the shelf 2-41Figure 2-21 Tasks of the connection management 2-42Figure 2-22 Context of the connection management tasks 2-43Figure 2-23 Protection switching of a subnetwork connection 2-48Figure 2-24 Object approach to protection switching 2-49Figure 2-25 Protection management task 2-51Figure 2-26 Context of the protection management tasks 2-52Figure 2-27 Timing generator management tasks 2-56Figure 2-28 Context of the MCU timing generator task 2-57Figure 2-29 MCU data restoration services building block 2-61Figure 2-30 Context of the data restoration services tasks 2-62Figure 2-31 Building blocks of the common services 2-65Figure 2-32 Context of the common services 2-66Figure 3-1 Structure of the PU software 3-2Figure 3-2 Hardware control of the PU software 3-3Figure 3-3 PU object-resource relationship 3-6Figure 3-4 PU object state diagram 3-10Figure 3-5 State diagram of the peripheral units 3-13Figure 3-6 Alarm supervision 3-16Figure 3-7 Alarm masking state transition diagram 3-17Figure 3-8 Multiplexing and demultiplexing the TIU-1 3-21Figure 3-9 Supported objects of the TIU-1 3-21Figure 3-10 TIU-1 alarm masking 3-24Figure 3-11 Multiplex and demultiplex path of the TIU-3 with AU-4 3-25Figure 3-12 Supported objects of the TIU-3 3-25Figure 3-13 TIU-3 alarm masking 3-28Figure 3-14 TIU-4 objects in SDH mode 3-29Figure 3-15 TIU-4 objects in PDH mode 3-29Figure 3-16 TIU-4 alarm masking in SDH mode 3-32Figure 3-17 TIU-4 alarm masking in PDH mode 3-33Figure 3-18 SIU-1 objects 3-34Figure 3-19 SIU-4 objects 3-35Figure 3-20 SIU 1/4 alarm masking 3-37Figure 3-21 CMU-1 object classes 3-38Figure 3-22 CMU-1 alarm masking 3-39Figure 3-23 PPU-1(4) objects (sink) 3-40Figure 3-24 PPU-1(4) objects (source) 3-40Figure 3-25 PPU-1 alarm masking 3-42Figure 3-26 Driver building blocks of the peripheral units 3-43Figure 3-27 Driver functions 3-46Figure 3-28 Driver building blocks of the synchronous interface units 3-47Figure 4-1 Infrastructure software 4-1Figure 4-2 Basic structure of the system services 4-3Figure 4-3 Operating system 4-3Figure 4-4 XOS structure and interface 4-6Figure 4-5 Communication paths in the system services 4-7Figure 4-6 Division of the memory 4-8Figure 4-7 Structure of a message 4-12Figure 4-8 Basic infrastructure 4-14Figure 4-9 Message services 4-18


Contents

ix

Figure 4-10 Local address services 4-19Figure 4-11 Hardware drivers 4-20Figure 4-12 General infrastructure building blocks 4-21Figure 4-13 The communication services in the NE software 4-22Figure 4-14 Communication via the layer model of the OSI 4-23Figure 4-15 The protocol stack of the MCF 4-25Figure 4-16 Building blocks of the communication services 4-26Figure 4-17 Functional view of the block ‘convergence functions’ 4-29Figure 4-18 Point-to-point network and bus structure 4-31Figure 4-19 The network element in the management network 4-34Figure 4-20 Routing in the MCU 4-35Figure 4-21 Software download 4-36Figure 4-22 Software download: interaction of building blocks 4-38Figure 5-1 TN-4X software architecture 5-2Figure 5-2 Structure of the MCU software (overview) 5-3Figure 5-3 Structure of the PU software (overview) 5-8Figure 5-4 Configuration of the TN-4X software 5-14

TablesTable 2-1 Plug-in unit code as part of the task name 2-3Table 2-2 Automatic instantiation 2-35Table 2-3 Automatic deletion 2-37Table 3-1 Processes of the hardware control 3-4Table 3-2 Possible alarms 3-18Table 3-3 Description of the TIU-1 objects 3-22Table 3-4 Description of the TIU-3 objects 3-26Table 3-5 Description of the TIU-4 objects 3-30Table 3-6 Description of the SIU-1/4 objects 3-35Table 3-7 Description of the CMU-1 objects 3-38Table 3-8 Description of the PPU-1(4) objects 3-41Table 4-1 Functions of the layers in the OSI model 4-24Table 4-2 The OSI stack of the MCF (message communication

function) 4-27Table 5-1 MCU software configuration – part 1: application software 5-4Table 5-2 MCU software configuration – part 2: infrastructure 5-5Table 5-3 PU software configuration – Main controller (MC) 5-9Table 5-4 Software configuration of communication controller (SUIs,

TIU 4) 5-12


xi


About this document

This document describes the concept and structure of the software associated with Nortel’s TN-4X network element for use within a synchronous digital hierachy (SDH) fibre optic transmission system.

Audience

This document serves as a concise introduction to the software architecture of the TN-4X and is recommended reading for anyone working with a TN-4X network element.


xii

Technical support and information

Nortel provides a comprehensive technical support service for its customers. The Nortel service Desk may be contacted between the hours of 8:30 am and 5 pm, Monday to Friday (UK local time), using the following FAX or telephone numbers:

United Kingdom

Freephone: 0800 626 881Telephone 0181 361 4693FAX: 0181 945 3456

International

Telephone: +44 181 361 4693FAX: +44 181 945 3456

Access to assistance from the Customer Service Desk 24-hour help line can be provided and is subject to a suitable Support Agreement being in place.

To discuss Technical Support services, please contact the Technical Support Hotline on 0181 945 3525.

Declaration of product safety and EMC compliance

This product/product family complies with the provisions of the Low Voltage Directive 73/23/EEC, and with the essential protection requirements of the EMC Directive 89/336/EEC as amended by 92/31/EEC, when it is properly installed and maintained and when it is used for the purposes for which it is intended.

1-1

1

Chapter 1: Introduction

SDH networkAn SDH telecommunication network can be set up with the subsystems:

• Network Management System (NMS) TN-MS EC-4X

• Network Elements (NE) TN-4X

• Local Craft Terminal CAT-4X0

The integration of network elements from the TN-4X system family in a telecommunication network is illustrated in Figure 1-1.


1-2

Introduction

Figure 1-1Management of regional subnetworks 1-1

The TN-4X network elements are responsible for transmitting the payload signals in the network. The configuration of the network is flexible. This is accomplished by controlling the transmission functionality of the network elements by means of network management system or local craft terminal (CAT-4X) instructions.

The network management system is responsible for controlling, co-ordinating and monitoring the entire network. Network management guarantees the proper and reliable distribution of information in the entire network, which also includes error detection and error handling throughout the network.

The local craft terminal (CAT-4X) facilitates the implementation of installation and maintenance measures on a network element. The operator may also control and monitor the operating functions of the network element to which the CAT-4X is connected.

NE

NENE

NE

NE

NE

to superordinate

Q

Local craft

Regional network management

Network

networkmanagement

Regional subnetwork

management

Q interface

interface

terminal (CAT-4X)

to other TN-4X subnetworks

server


Introduction

1-3

1

Basic terminology and conceptsThe concept of the TN-4X software is designed to facilitate the integration of network elements in communication networks that are administered by network management systems that conform to ISO standards.

As a result, the form of communication between the TN-4X network elements and the network management system corresponds to ISO standards. The software concept of the network elements is therefore based on the object-oriented approach of the ISO recommendations.

Special terminology has been created by the ISO model for system management in an OSI environment. This section presents concepts and terminology that are required in the area of standardised network management.

Objects and object classesThe ITU-T and ISO recommendations for network management systems in the synchronous digital hierarchy (ISO 10165-X, ITU-T G.784, ITU-T G.821, ITU-T M.3010) are based on an object-oriented representation of network elements in which the resources of the communication network, e.g. network elements, plug-in units, communication links and various management functions, are represented by objects (Managed Objects). Objects with the same characteristics are combined to form object classes.

The object classes are defined by:

• The attributes that specify the object class

• The object behaviour that determines how objects of one object class react to status changes and incoming instructions and messages

• The conditional packages that further define the object behaviour and can be assigned to an object instance during ‘instance creation’.


1-4

Introduction

Manager agent modelBoth the software of the network elements and the network management system monitor, administer and co-ordinate the resources or objects of a system. This is accomplished by means of application processes. These processes can assume one of the following roles:

• As an agent process they are responsible for a number of objects. An agent sends inquiries and instructions to its MOs and receives messages from them.

• As a manager process they are assigned several agents. Manager processes are responsible for the execution of one or several management activities. They send inquiries about specific objects to the respective agent and receive a message from the agent containing the required information in return.

0

The network element software always responds as an agent, i.e. it receives instructions and internally converts these to activities. The agent forwards incoming instructions to the respective software packages. It also transfers data from the ‘network element’ object to the network management system or a local craft terminal in order to facilitate the administration of the network and the network element from this system or terminal.

Figure 1-2 provides an overview of the manager agent model (In acc. with ISO/IEC DIS 10040).

Figure 1-2Manager agent model 1-2

Communication between the manager and the agent is accomplished via special protocols in the various layers of the ISO reference model for Open Systems Interconnection (OSI) (the ISO reference model is explained in Chapter 4, page 23 ‘The OSI model – brief overview’). Protocols establish rules for the exchange of information between two communication partners.

Management operations

Notification

CommunicationManager process

Management operations

Notifications

Objects

Network element software

Agent process

e.g. within the TN-MS EC


Introduction

1-5

1

The services of the Common Management Information Service (CMIS) are primarily used as the communication services on layer 7. They have been specially designed for an object-oriented management model.

Network Element software overviewHardware/software relationship

A TN-4X network element (NE) comprises several different plug-in units which, individually, are responsible for different tasks and combined represent the functionality of the network element. The different unit combinations produce different types of network elements. The plug-in units are always set up in the same way, regardless of the type of network element.

The functional performance of a plug-in unit should not depend on the state of other plug-in units, but should be independently operational in order to achieve the highest possible degree of reliability.

Each plug-in unit in a TN-4X network element therefore has separate, executable software which is only responsible for the functionality of the respective plug-in unit. A central Management and Communication Unit (MCU) is responsible for external outgoing communication and external control. All other units implement specific interfaces or functions and are therefore called peripheral units (PU).

Figure 1-3The network element software concept 1-3

The network element has an internal communication system that facilitates the exchange of data between the plug-in units to allow the individual units of a network element to form a unit with the required functionality. This communication system consists of the extensive bus system and special software function blocks located on every plug-in unit. As seen from the superordinate instances, the software represents an overall system which disposes of all functions facilitated by the plug-in units (Figure 1-3).

Internal communication

...U

nit 8

Uni

t 7U

nit 6

Uni

t 5U

nit 4

Uni

t 3U

nit 2

Uni

t 1

Network Element=


1-6

Introduction

Building blocksThe software of the TN-4X network elements consists of functional areas made up of individual software building blocks.

A building block is a self-administrable software unit which usually implements a closed function. Chapter 5 ‘MCU/PU software configuration’ contains a complete description of the software structure using the building blocks.

Structure of the Network Element softwareThe network element software (Figure 1-4) is divided into the following functional levels:

• Application software and

• infrastructure.0

Each plug-in unit works with its own separate application software, while the infrastructure software is used by all plug-in units.

Figure 1-4Structure of the network element software 1-4

Application software of the management & communication unit (MCU)The MCU application software includes:

• The internal management of the network element

• Provision of the agent for the network management. 0

The entire network element is internally administered by means of the application software. This management is divided into different functional areas, e.g. fault and configuration management. While fault management evaluates the ability to use the network element and the transmission link, configuration management can be used to set the transmission functionality of the network element according to the configuration data in the read-only memory or the instructions from the network management system.

Application software of peripheral

unit 1


unit n

Application software of the management and communication unit

Infrastructure

System services Communication services

. . .


Introduction

1-7

1

Application Software of the Peripheral UnitsThe application software of the individual peripheral units has two main tasks:

• Control and monitoring of the peripheral unit functions and communication with the MCU

• Access to the transmission-related hardware components (e.g. ASICs) of the plug-in units

0

The control and monitoring procedures are identical for all peripheral units, as common building blocks are used. For hardware access specific building blocks (e.g. hardware drivers) are required on the different plug-in units.

InfrastructureThe infrastructure software constitutes the lowest software level. All plug-in units use the same infrastructure software in order to ensure that the software system interworks at this level. The infrastructure software is divided into two functional areas: system services and communication services.

System services constitute the basis of the NE software. They essentially contain the operating system of the network element and the required hardware drivers. The tasks of the operating system include in particular:

• The administration of memories and processors

• The administration of application tasks

• The control of internal communication and

• The administration of various time services, i.e. the system time.0

Communication services consist of all functions that the application requires in order to communicate with external units. This includes:

• The Q interface for communication with the network management system (TN-MS) and the local craft terminal

• The QECC interface for communication with other network elements.0

The following functions are also implemented within the communication services.

• Software download, i.e. loading the NE software from an external computer

• The administration of the ECC bus. 0

End of chapter file


2-12

Chapter 2: Application software of the Management and communication unit

OverviewStructure of the management application function

The network elements are designed to be operated using network management systems. The MCU application software is therefore also referred to as ‘management application function’. It is structured as follows (Figure 2-1):

Figure 2-1Tasks of the management application function 2-1

Functional areasThe management application function (MAF) is subdivided into three blocks:

• Configuration and supervision

• Data restoration services

• Common services.0

MCU application software

Common services

General routines

Data restoration services

NE configuration and supervision

CMIS agentand

Network element management

Equipment management

Timinggenerator

Transmission Connection Protection Faultobject management management management

management managementevent reportmanagement

Backup routines


2-2 Application software of the Management and communication unit

Configuration and SupervisionThe task of the ‘Configuration and supervision’ main block is to

• Provide the operations system with information on the available hardware components and communication links

• Report the current operational condition of the hardware components and communication links to the network management system and change it using the network management system if required

• Process routing-related network management instructions.0

The ‘Configuration and supervision’ main block is subdivided into the following blocks:

• CMIS agent and event report management

• Fault management

• Network element management

• Equipment management

• Transmission object management

• Connection management

• Protection management

• Timing generator management.0

Data restoration services and common servicesThe data restoration services and common services blocks are jointly used by the above management areas.

The data restoration services permit the permanent network element data to be saved and retrieved. These functions enable the MAF to save the data on a daily basis and perform a recovery if required.

The common services are used for the communication between the MAF tasks. They provide conversion routines for internal and external data structures. The common services implement general tasks that are used by all MAF tasks.


Application software of the Management and communication unit 2-3

2

Naming conventions and diagramsThe individual tasks are named in accordance with the relevant naming convention. All task names consist of four characters. The first two letters identify the plug-in unit (Table 2-1) that runs the process, the last two letters uniquely identify the respective task (example: MCFA, MCU fault).

The individual tasks and interrupt service routines or procedures that belong to a functional area or driver package are represented in a drawing according to the sample package (Figure 2-2). As this representation is uniform for all functional areas and driver packages of the application software, it clearly indicates which tasks and routines form a functional area.

Figure 2-2Sample functional area 2-2

The context of the software in the individual plug-in units is illustrated in the figures for all of the functional areas and driver packages and corresponds to the sample context (Figure 2-3). The functional area pertaining to the respective chapter is referred to in the figure as special MAF range.

Table 2-1Plug-in unit code as part of the task name 2-1

Plug-in unit Plug-in unit code

MCU MC

SIU SI

PU PU (for any peripheral unit)

Task 1

Routine 1

Task 2

Routine 2

Procedure 1 Procedure 2

Functional area



The oval-shaped elements represent the individual tasks, interrupt service routines and procedures. The arrows indicate which tasks and routines communicate with each other. The arrowheads point in the respective data flow direction.

As a rule, the individual tasks of the MAF correspond to precisely one building block.

Figure 2-3Context of the sample software 2-3

Chapter StructureThe sections within this chapter pertaining to the functional areas of the management application function are structured as follows to ensure simple access to the information.

• Definition of terms

• Description of the tasks and routines relevant to the respective functional area

— List of tasks and routines

Task 1

Task 2

MAF tasks MAF tasks

Other MAF areas

MCU

Other MAF areasSpec. MAF areas

Procedure 1

Task 2Task 1

PU

Communication via a procedural interface

Communication in the respective direction



2

— Context of the tasks and routines0

• Functions

— Overview of the functions

— Description of the implementation of the functions.0

The individual sections are structured to provide all information required for a specific functional area within one section.

CMIS agent and event report management A network element is represented by a number of objects vis-á-vis the network management system. The network element and the corresponding objects are accessed via the Q interface, which is implemented by an OSI stack with the Common Management Information Service (CMIS) in layer 7. In general, a network element can be connected to several management systems. The CMIS agent functions as the communication partner of the network management system in a network element.

The network element transmits all notifications to the network management system via the event report management system. The event report management system is responsible for the controlled transmission of network element notifications to the network management system.

Definition of termsCommunication between the management system and the network element is carried out using messages as illustrated in Figure 2-4. Messages transmitted from the management system to the network element are requests, e.g. ‘Set attributes’. Messages transmitted from the network element to the management system are notifications, e.g. alarm notifications. A manager request is followed by an answer (including the respective data if required). Likewise, an NE notification is followed by an acknowledgment from the management system.

Figure 2-4Communication between NE and management system 2-4

Connection

Request

Response

NE notification

Acknowledgments

Network element Manager

TN-4X



The ITU-T and ISO recommendations for network management systems in the synchronous digital hierarchy are based on an object-oriented representation of the network elements (ISO 10165-X, ITU-T G.784, ITU-T G.821, ITU-T M.3010). Object classes are assigned to the hardware components, communication links and various management tasks.

The object classes are defined by:

• The attributes which specify the object class

• The object behaviour which determines how objects of one object class react to status changes and incoming network management commands and messages

• The conditional packages which further define the object behaviour and which are permanently assigned to an object class.

0

The network management system can set up (instantiate) new objects for a network element during operation. These objects are based upon the respective object class definitions. In certain cases, the network element is permitted to instantiate objects by itself.

The CMIS provides the following services for communication between the network management system and the network elements.

• ‘Create Managed Object’

• ‘Delete Managed Object’

• ‘Action’

• ‘Get Attribute Value’

• ‘Set Attribute Value’

• ‘Event Report’.0

Event reports are notifications sent by the network element to the management system, all other services are requests sent by the management system to the network element.

The ‘Create Managed Object’ and ‘Delete Managed Object’ commands can be used to create new object instances or delete any existing object instances in the network element. ‘Define’ actions can also be used to create instances.

Tasks that are assigned to the objects can be triggered by activating the respective network management function using an ‘Action’.

‘Set Attribute Value’ is used to change the values of the object attributes. ‘Get Attribute Value’ triggers the retrieval of attribute values. Object attributes are changed by overwriting the old attribute values with new attribute values.

The ‘Event Report’ service of the CMIS constitutes the only means for a network element to send notifications to the network management system without a request.



2

Communication via CMIS is always connection-oriented. The connection management function between the manager and the agent is handled by the management interface library (MIL), which is implemented to relieve the application of this task. Refer to the communication services section (see Chapter 4) for a description of MIL functionality in connection with the communication stack of the Q interface.

Tasks of the CMIS agent and the event report management Figure 2-5 illustrates the tasks of the CMIS agent and the event report management system. These tasks fulfil the following functions:

• The MCEF task (MCU event forwarding discriminator task) forwards all notifications to the respective managers

• The MCCN task (MCU confirmed notification task) monitors the acknowledgment of notifications by the network management system

• The MCCM task (MCU CMISE agent task) receives the network management commands and forwards the respective answers to the network management system.

0

Figure 2-5Tasks of the CMIS agent and the event report management 2-5

The MCU event forwarding discriminator task is addressed by all application software tasks that send notifications to the network management system (Figure 2-6). Any requests that the MCCM receives from the network management system are forwarded to the MAF tasks. The MCNE task (MCU network element task) allows the CMIS agent and the event report management to forward notifications after a system recovery.

MCCMMCEF MCCN

MCCM

CMIS agent/event report management



Figure 2-6Context of the CMIS agent and the event report management 2-6

The functions of the CMIS agent and the event report management system

The CMIS agent and the event report management fulfil the following functions:

• Converting the format of incoming and outgoing messages

• Forwarding the network management commands to the MAF tasks and forwarding the notifications from the network elements to the network management system

• Organising object instances in the Management Information Tree (MIT)

• Administering the Event Forwarding Discriminator (EFD)

• Notification processing

• Monitoring notification acknowledgments

• Handling communication failures.0

Format conversion of incoming and outgoing messagesThe message formats used by the network management system and for internal NE communication are specially designed for the specific requirements of the network management system or internal communication between the tasks of the network element. The CMIS agent converts incoming messages into the internal message format. Outgoing messages are converted into the external message format required for the network management system.

MCCM

MCEF

MAF tasksMCCN MCNE

CMIS agent/Event report management

Network element managementOther MAF areas

MCU



2

Messages from the network management system are transmitted to the CMIS agent via the management interface library (MIL). Messages intended for the network management system are sent from the CMIS agent to the interface that is responsible for message transmission (see Figure 2-7).

Figure 2-7Communication with the network management system 2-7

Forwarding network management commandsIncoming CMIS commands are forwarded to the CMIS agent first. The CMIS agent functions as the agent for the network management system and is thus responsible for processing the command. The incoming command contains both the object identifier and a precise specification of the management instruction.

Only commands that can be interpreted and forwarded within the network element are accepted by the CMIS agent. If a network management command concerning the modification of the configuration data is received while the configuration data of the network element is being dumped, the dump is aborted. The management system cannot access the data while it is being read from the backup medium.

Once a CMIS command has been accepted, the CMIS agent must localise the respective object instance and ensure the proper execution of the command. The management information tree (MIT) is provided to facilitate localisation. The MIT contains information on all object instances of the network element, including the address at which the object instance can be reached. The CMIS agent updates the management information tree each time an instance is deleted or created.

Network management system

CMIS agent

Management

Communication

MIL

Communication stack

Network element

Q interface

services

application function



The CMIS agent requests the MAF task responsible for the respective instance to execute the management system command (see Figure 2-8). The MAF task transmits an answer for each command to the CMIS agent, which forwards the answer to the network management system. Data is transmitted with the answer if required.

Figure 2-8Forwarding network management commands 2-8

Organising object instances in the MITThe MCCM is responsible for organising the management information tree. Each time a new instance is created by an MAF task, the MCCM inserts the instance in the MIT. Instances that are to be deleted must be removed from the MIT first.

EFD managementThe MCEF is responsible for the creation, administration and deletion of instances that belong to the event forwarding discriminator object class.

Instances of the event forwarding discriminator object class are created upon the command of the network management system. However, the instance cannot be created unless the address to which notifications from this EFD instance are to be sent is listed in the manager address list of the network element. Only one EFD instance can be created for each manager address. A maximum of two manager addresses can be stored in the network element.

The MCU event forwarding discriminator task administers the attributes for instances of the event forwarding discriminator object class. One of these attributes functions as a pointer to an attribute of the ‘phase2’ object, which contains the manager addresses. The ‘AdministrativeState’ attribute can be used to specify whether or not notifications from the network elements are to be sent to the manager.

Instances of the event forwarding discriminator object class cannot be deleted unless requested by the network management system.

Notification processingNotifications that must be sent to the network management system during operation are initiated by the MAF tasks and forwarded to the MCU event forwarding discriminator task.

The event forwarding discriminator task (MCEF) checks whether an instance of the event forwarding discriminator object class is present whose ‘AdministrativeState’ attribute has the value ‘enabled’. If this is the case and

responsible taskMCCM

Network management command Network management command

Answer + data (if required)Answer + data (if required)



2

the forwarding of notifications has been enabled by the MCU network element task (MCNE), the notification is forwarded to the MCU confirmed notification task (MCCN).

The MCCN receives the notification and the respective destination from the MCEF and forwards these to the MCCM. The MCCN verifies whether the notifications are acknowledged by the management system within a certain period of time. If an acknowledgment is not received, the notification is sent again. All incoming notifications for the MCCN are stored in a buffer. If the storage space in the network element buffer is insufficient, a communication failure will occur for the MCCN during communication with the network element.

The MCCN starts a timer for each notification that it forwards to the CMIS agent. The CMIS agent then forwards the notification to the network management.

The network element always transmits one notification at a time, i.e. the next notification cannot be sent until the previous notification has been acknowledged by the network management system.

Monitoring notification acknowledgmentsThe network element requires all notifications to be acknowledged by all managers. The MCCN is responsible for monitoring the notification acknowledgments. The CMIS agent forwards all incoming notification acknowledgments directly to the MCCN.

The MCCN starts a timer for each notification. The notification is sent again if the MCCN fails to receive an acknowledgment for this notification within the specified period of time. If an acknowledgment is not received after a notification was sent for the third time, the MCCN presumes that a failure is present in the communication with the network management system.

Handling communication failuresIf a failure is detected in the communication with the network management system, the MCCN repeatedly transmits failure notifications to the network management system via the CMIS agent. Any remaining or new notifications are not transmitted. The MCCN resumes normal operation once the receipt of the failure notification is acknowledged by the network management system. Notifications from the MCEF are then forwarded to the CMIS agent.



Fault managementA fault management is required to detect and handle alarm conditions both within the network element and on the transmission routes. Alarm conditions are triggered by plug-in unit failures, hardware component failures, transmission failures and signal power drops. Failure information is forwarded to the network management system via the event report management system.

Definition of TermsThere are three types of network element alarms:

• Transmission object alarms

• Equipment alarms

• Clock supply alarms.0

Transmission object alarms are triggered for transmission line failures that were reported by the peripheral units. They always refer to a termination point. A loss of frame (LOF) in a regenerator section trail termination point (RSTTP) is an example of a transmission alarm.

Equipment alarms indicate failures in the:

• Plug-in unit hardware

• Communication between the peripheral units and the management and communication unit

• Clock supply for the peripheral units.0

Timing generator alarms indicate central clock supply failures. This refers to timing source failures rather than to failures in the clock supply of individual peripheral units.

Alarms can be assigned one of several severity levels on the basis of an alarm severity assignment profile (ASAP). The profile comprises a list of possible alarms and their severity. The alarm severity assignment profiles are stored as object instances. The following alarm severity levels are defined:

• Critical fault

• Major fault

• Minor fault

• Warning

• Non alarmed. 0

A current problem list is maintained by the fault management. This current problem list contains all present alarms and the respective alarm severity levels.



2

All transmission objects and plug-in units are assigned an operational state. This operational state indicates whether or not the transmission object or plug-in unit is ready for operation.

Fault management tasks The fault management functions are centrally controlled by the MCFA (MCU fault task) on the MCU (Figure 2-9).

Figure 2-9Fault management task 2-9

The MCFA communicates with the following tasks to fulfil its functions (Figure 2-10):

• The MCCM (MCU CMISE agent, CMIS agent), which forwards fault-related network management commands to the MCFA task

• The MCEF (MCU event forwarding discriminator task), which receives messages from the MCFA

• The MCTP (MCU termination point task), which administers the termination points of a network element as transmission objects

• The MCEQ (MCU equipment task), which administers the hardware components of a network element

• The MCNE (MCU network element task), which activates the fault management after system recovery

• The MCTG (MCU timing generator task), which is responsible for clock supply management

• The PUADs (PU administration data tasks) on the peripheral units, which contain information on whether or not equipment alarms or alarms for transmission objects are to be reported in connection with the peripheral unit

• The PUFAs (PU fault tasks) on the peripheral units, which transmit reportable faults to the fault management system.

0

MCFA

Fault management



Figure 2-10Context of fault management tasks 2-10

Fault management functionsThe following functions are implemented by the fault management tasks:

• Administration of the alarm severity assignment profile

• Starting fault management

• Terminating fault management

• Alarm notification processing

• Unit replacement handling.0

Administration of the alarm severity assignment profileThe alarm severity assignment profile is administered by the MCFA in the form of an object attribute. The corresponding object instance is instantiated automatically after system start-up if requested by the network element task.

Most of the alarms are assigned the ‘minor’ severity level by default. This assignment can be set separately by network management command for each alarm. The settings of the alarm severity assignment profile are retained by

MCTP

MCFA

MCEF

MCCM

MCEQ

POADPUFA

MCNE

Other tasks

MCTG



VariousMAF areas

Timing generator management

Fault management

Transmission objectmanagement


MCU

PU



2

the network management system if the network element must be rebooted after a failure.

Starting fault managementFault management can be started separately for each transmission object and for each plug-in unit. The same applies to timing generator fault management. All transmission objects and plug-in units to be monitored are registered with the fault task by the termination point task and the equipment task. The timing generator fault management is initiated by the MCTG task.

If fault management is to be initiated for a specific plug-in unit or transmission object, the fault task notifies the administration data task of the respective plug-in unit. The database of the plug-in unit contains information as to whether or not alarm notifications for hardware failures or certain transmission objects on the plug-in unit are to be forwarded. The respective alarm notification is not forwarded to the fault task unless this was specified for this alarm.

Terminating fault managementThe procedures for terminating fault management for individual transmission objects and plug-in units or timing sources are similar to the procedures required for starting the fault management system. The transmission objects and plug-in units are logged off of the fault management by the termination point task and the equipment task. The timing source fault management is terminated by the MCTG task.

The termination of fault management for a plug-in unit or transmission object is communicated to the PU administration data task on the respective plug-in unit by the fault task. Any subsequent alarms triggered for this plug-in unit or transmission object are not forwarded.

Alarm notification processingThe fault task receives alarm notifications from the alarm tasks and application drivers on the management and communication unit (if failures occur on the external network clock input ports). If an application task detects problems in the communication with a specific peripheral unit, it notifies the responsible fault task.

The fault task determines the severity level of the reported alarm and enters it in the current problem list. The fault task then sends an alarm notification to the event forwarding discriminator task.

The operational state of a transmission object, plug-in unit or timing source may change depending on the severity of a fault. The fault task reports any changes in the operational state to the responsible task, i.e. the termination point task, the equipment task or the timing generator task.

Once a fault is cleared, a notification is sent to the fault task. The fault task deletes the respective entry in the current problem list and sends a notification to the network management system. If the operational state of a transmission



object, plug-in unit or timing source changes as a result of fault clearance, the fault task informs the responsible task accordingly.

Unit replacement handlingIf a plug-in unit is replaced by an identical unit or returns to operation after a warm start, the fault task receives a notification from the equipment task. The fault task deletes all current problem list entries related to this plug-in unit, and the event forwarding discriminator task sends a notification to the network management system.

The fault task informs the administration data task on the plug-in unit of the alarms that are to be reported so that it may resume its fault management functions for the plug-in unit.

Network element managementThe network element management is responsible for aspects relating to the entire network element and which must therefore be organised for all functional areas.

Definition of termsThe manager address list of the network element contains the addresses of network management computers that receive notifications from the network element.

The basic configuration with which the network elements are initialised depends on the configuration of the peripheral units. Thus, the initial configuration of a network element depends on the basic configurations of the individual plug-in units and is referred to in the following as ‘basic configuration’. Some of the objects that are contained in the basic configuration do not depend on the actual configuration, e.g. ‘sdhNE’ (represents the network element as a whole) or ‘backplane’ (represents the backplane of the network element).

The basic configuration of the network element can be changed by the management system. All changes to the configuration are saved by the network element as commanded by the network management system. An automatic backup is performed daily at a specified time. The configuration that was saved last is regarded as the backup configuration.

Network element management taskFigure 2-11 shows the network element management task. The MCNE (MCU network element task) controls system start-up after the initialisation of the individual tasks of the management application function. It is also used by the network management system as its partner for all configuration-related communication.



2

Figure 2-11Network element management task 2-11

The MCNE communicates with the following tasks and building blocks to fulfil its tasks (Figure 2-12):

• The MCCM (MCU CMISE agent, CMIS agent), which forwards network management commands to the MCNE task

• The MCEF (MCU event forwarding discriminator task), which receives notifications from the MCNE task

• The MCEQ (MCU equipment task), which administers the hardware components of a network element

• The MCCF building block (MCU configuration database building block), which is responsible for configuration data handling.

0

Figure 2-12Context of the tasks of the network element management system 2-12

MCNE


MCNE

MCCM

MCEF

MCEQ

MAF task

Other MAF areas


Configuration management

Network element management Equipment management


MCU

MCCF



Functions of the network element managementThe following functions are implemented by the task of the network element management system:

• Controlling and completing system recovery

• Creating and administering object instances

• Coordinating configuration-data backups

• Resetting the network element. 0

Completing system start-upAs soon as the application tasks on the management and communication unit have been initialised, the network element task assumes control of the system start-up. System start-up is completed when the network element is ready to communicate with a manager.

The system start-up procedure varies depending on whether or not a backup configuration is available for the network element. Figure 2-13 illustrates the system start-up procedure.



2

Figure 2-13Completing the system start-up 2-13

Taking over the

Backup configuration

Backup configuration exists

Completing the

Recovering the

Unit registration

No manager addresses

Network manage-

Basic configuration exists

Plug-in units ‘Active-Non-Managed’

Event report

Activating the

Backup configuration exists

(complete configuration)

Unit registration

Activating the units

Restart notification

Monitoring the

Event report

Network manage-

Activating the

Units active

Operational

Network manage-

Restart notification

Event report

Monitoring the

Event report

Network manage-

Manager addresses:

No manager addresses Manager addresses

A

B C

D

E

G

H

D

H

E

G

F

I

E

G

H

F

I

E

G

Action is performed automatically by the network element

Action is performed by management system command

system start-up

does not exist

backup configurationbasic configuration

released

released

to the management system

ment access released

notification acknowledgement

management released



to the management system

notification acknowledgement

management released

units + dump management released

units + dump

management released




The following description of Figure 2-13 explains the left branch (‘backup configuration does not exist’) and subsequently the right branch (‘backup configuration exists’) of the chart. The bold capital letters used in the description correspond to the respective phases of system start-up in the representation.

Left branch: The backup configuration does not exist.B: The MCU basic configuration is set up first.

D: The network element task informs the equipment task that all plug-in units can register during the equipment task from this point on.

The basic general configuration, which is the sum of all of the individual basic configurations of the plug-in units, exists after this step. The plug-in units are in the ‘Active-Non-Managed’ state and work with their current internal hardware settings with respect to transmission functionality. They can communicate with the MCU and modify their internal data although the respective changes will not yet have taken effect in the transmission hardware.

• No manager addresses in the address list:

E: If the manager address list of the network element does not contain any addresses, access to the network management system is released and a request by a management system is awaited.

G: Once the management system request has been received, event report management is released for this address only.

H: The plug-in units remain in ‘Active-Non-Managed’ state until the manager initiates a configuration-data backup.

• Manager addresses in the address list:

F: If the manager address list of the network element contains an address, a message concerning the restart is sent to the management system.

I: Notification acknowledgment is monitored.

E: Access to the network management system is released.

G: Event report management is released.

H: The plug-in units remain in ‘Active-Non-Managed’ state until the manager initiates a configuration data backup.

Right main branch: The backup configuration exists.C: The backup configuration is recovered.

The complete backup configuration subsequently exists.

D: The network element task informs the equipment task that all plug-in units can register during the equipment task from this point on.

H: The plug-in units remain in ‘Active-Non-Managed’ state until the manager initiates a configuration data backup.



2

The plug-in units are now in active state (operational).

• No manager addresses:

E: If the manager address list does not contain an address, access to the network management system is released.


• Manager addresses:

F: If the manager address list of the network element contains an address, a message concerning the restart is sent to the management system.

I: Notification acknowledgment is monitored.

E: Access to the network management system is released.


Creating and administering object instancesThe network element task is responsible for creating and administering the instances of object classes that represent the network element and the system time.

The network element task instantiates all of its assigned object classes during system start-up. Only one instance per object class is permitted.

The network element task administers the attributes for the instances of its object classes. It executes commands related to these objects and administers the internal behaviour of these objects.

Object instances that are assigned to the network element task cannot be deleted from within the network element or by network management command.

Co-ordinating configuration data backupsThe configuration data is saved by the network element as commanded by the network management system. The CMIS task forwards the command to the network element task, which is responsible for coordinating the data backup. In addition, an automatic backup is performed once per day at a specified time.

The network element task initiates data backup if a backup configuration is not available or if the existing backup configuration does not match the actual configuration. The database building block of the MCU configuration notifies the network element task upon detection of the first mismatch between the actual network element configuration and the backup configuration.

The configuration data to be saved must not be changed during the backup procedure as the backup will otherwise be aborted.

The network element task sends a notification to the network management system before the database building block saves the configuration data. The



network element task also informs the network management system upon completion of the backup procedure.

Resetting the network elementThe network management system issues a command to trigger a reset of the entire network element. The MCU network element task restarts the network element during this reset. The network element is initialised with its basic configuration regardless of whether or not a backup configuration is available.

Equipment managementInformation that refers exclusively to the network element as a whole is insufficient for the network management system. Detailed information on the equipped plug-in units and their operational states is required to determine which network configurations are possible and can be implemented with regard to current availability, and where necessary to carry out card protection (protection switching at plug-in unit level). This information is administered by the equipment management.

Definition of termsThe NE equipment that is to be administered comprises the backplane with the backplane EEPROM and the individual plug-in units in the slots.

Alarms can be assigned one of several severity levels on the basis of an alarm severity assignment profile (ASAP). The profile comprises a list of possible alarms and their severity.

Similar to the application software of the management and communication unit, the application software on the peripheral units is designed in accordance with an object-oriented approach. If a warm start is triggered on a peripheral unit, the object configuration that was present prior to the warm start is maintained. However, all objects are undefined, i.e. the management and communication unit cannot query object attributes or receive notifications. The MCU application software can define the objects on the peripheral units individually in order to facilitate the facilitate the query of attributes and the receipt of notifications.

Equipment management tasksFigure 2-14 shows the tasks of the equipment management system. These tasks fulfil the following functions:

• The MCEQ (MCU equipment task) is responsible for the administration of all network element equipment

• The MCPO (MCU port task) is responsible for the administration of the ports in the network element.



2

Figure 2-14Tasks of the equipment management system 2-14

The equipment management tasks communicate with the following tasks to fulfil their functions (Figure 2-15):

• The MCCM (MCU CMISE agent), which forwards equipment-related network management commands to the equipment management

• The MCEF (MCU event forwarding discriminator task), which receives notifications from the equipment management

• The MCFA (MCU fault task), which administers equipment alarms

• The MCCO (MCU connection task), which is responsible for routing within the network element

• The MCCC (MCU centralized connections task), which implements the switching matrixes in the network element and carries out bus assignment operations

• The MCPR (MCU protection task), which is responsible for protection switching

• The MCTP (MCU termination point task), which administers the termination points of a network element as transmission objects

• The MCTG (MCU timing generator task), which administers the clock supply of the network element

• The PUADs (PU administration data tasks) on the peripheral units, which contain information on whether or not equipment alarms or alarms for transmission objects are to be reported in connection with the peripheral unit

• The PUEQs (PU equipment tasks) on the peripheral units, which are responsible for monitoring the hardware components of the units.

0

MCEQ MCPO




Figure 2-15Context of the equipment management 2-15

Functions of the equipment management The following functions are implemented by the equipment management tasks:

• Creating, administering and deleting object instances

• Registering new plug-in units

• Unit-replacement handling

• Handling the warm start of plug-in units

• Fault handling

• Putting the PUs into operation (set to operational).

• Card protection0

MCFA

MCEQ

MCTG

MCEF

MCCM

MCCO

MCPR

MCTP

MCPOMCCC

Transmission object management

Connection management

Protection management



Timing generator

Fault management

MCU

PUEQPUAD

PU

management



2

Creating, administering and deleting object instancesOne management and communication unit and the shelf backplane must be present to facilitate network element operation. The equipment task therefore instantiates the relevant object instances during system start-up. Instantiation is initiated by the MCU network element task.

The equipment task does not normally instantiate other object instances unless new plug-in units are registered. Refer to page 2-26, ‘Registering new plug-in units’ for further information.

The equipment task notifies the PU fault task of all existing object instances so that fault management can be initiated for these instances.

The Q interface and the PC interface of a network element are directly connected to the management and communication unit. The equipment task notifies the MCU port task as soon as the object instance for the management and communication unit has been created. The MCU port task subsequently creates a port object instance for the Q interface and the PC interface.

The network management system receives a notification (there are exceptions; not only for MCU instances) from the equipment task and the port task respectively as soon as these created an object instance.

The equipment task and the port task administer the attributes of their object instances. They communicate the respective attributes to the network management system upon request or set the attributes in accordance with incoming commands from the network management system.

Equipment objects can only be deleted by the network management system. This does not apply to the object instances for the management and communication unit (including the respective port instances) and the backplane of the network element, as these cannot be deleted at all.

The equipment task does not execute network management commands that are used to delete a PU object instance unless the following conditions are fulfilled:

• A connection does not exist to the plug-in unit, or the addressed plug-in unit is not in the slot

• The plug-in unit does not provide a timing source for selection

• A bus has not been assigned.0

The equipment task notifies the port task upon deletion of a plug-in unit instance. The port task deletes all port instances that were assigned to the plug-in unit. In addition, the port task notifies the termination point task of all instances that were deleted.

The equipment task and the port task notify the network management system of all plug-in unit instances that were deleted.



Registering new plug-in unitsThe equipment task on the management and communication unit does not register new plug-in units unless registration has been enabled by the MCU network element task.

All newly inserted plug-in units register with the management and communication unit. A registration acknowledgment is sent to the plug-in unit if registration has been enabled by the MCU network element task. If an acknowledgment is not received by the plug-in unit, the registration procedure is terminated at this point.

Certain plug-in units can only be used in conjunction with other plug-in units. This applies to the pointer processing unit, for example. An instance for these plug-in units is not created by the equipment task until all required units have been inserted.

The equipment task creates an object instance for the plug-in unit if all of the above conditions are fulfilled.

The administration data task on the new plug-in unit receives several ‘Define’ notifications from the equipment task after the object instance has been created. Once the peripheral unit has been put into operation, all failures of the unit are reported to the equipment task. The equipment task can also query and change all hardware-related attributes of the unit.

The equipment task informs the following tasks when object instances are created:

• The fault task, which is requested to take over fault management for the plug-in unit

• The centralized connections task

• The port task

• The transmission object task

• The timing generator task if the new plug-in unit is a synchronous interface unit (SIU) and a central clock unit (CCU-X3) is inserted in the respective slot

• The MCU event forwarding discriminator task, which sends a notification to the network management system if an EFD exists for it.

0

Once the port task is informed that a new plug-in unit has been installed, it creates the required number of port instances depending on the plug-in unit type (e.g. 21 ports for a TIU-1 tributary interface unit). The port task sends a notification to the MCU termination point task and the network management system for each port instance that has been created.

Unit replacement handlingIf a plug-in unit is replaced, the new unit sends a notification to the management and communication unit after start-up. The equipment task



2

acknowledges the receipt of the notification and queries the hardware type of the peripheral unit. On the basis of this information the equipment task determines whether a unit of the same or a different type was inserted.

If the unit is of a different type, the equipment task notifies the fault task that an incorrect plug-in unit was inserted. The fault task commands the equipment task to disable the respective plug-in unit if one of the severity levels ‘critical’ or ‘major’ is assigned to the installation of an incorrect unit type in the alarm severity assignment profile (ASAP).

If a plug-in unit of the same type is equipped, the equipment task informs the fault task that the communication failure which occurred after the old plug-in unit was unplugged has been cleared. In addition, the following tasks are notified that a plug-in unit has been replaced:

• The MCU termination point task

• The MCU centralized connections task

• The MCU protection task

• The fault task

• The MCU timing generator task.0

Handling the warm start of plug-in unitsFrom the point of view of the equipment management, a warm start of a plug-in unit is handled in the same way as a unit replacement. The difference is, however, that the equipment task notifies the other system tasks that a warm start, not a plug-in unit replacement, has been performed.

Fault handlingThe fault management task informs the equipment task of all unit-related faults.

If a hardware failure occurs on a plug-in unit which was classified as a critical or major fault, the ‘OperationalState’ attribute is set to ‘disabled’. This value is maintained until the fault is cleared. The termination point task receives a notification from the equipment task upon recovery of the fault.

If the fault task notifies the equipment task that a communication failure occurred, the equipment task attempts to establish a connection to the monitoring task of the affected plug-in unit. Once the connection has been established, the subsequent steps vary according to whether the plug-in unit registers again after a warm start (see page 2-27, ‘Handling the warm start of plug-in units’). Otherwise, the equipment task assumes that the plug-in unit was replaced (see page 2-26, ‘Unit replacement handling’).

Set to operationalThe equipment task notifies the monitoring task of a plug-in unit if the state of the unit is set to operational. The application software of the peripheral unit subsequently converts the attributes of all objects defined on the unit for the respective hardware registers.



The MCU network element task informs the equipment task whether or not the plug-in units can be put into operation. Once commissioning of the units has been enabled by the network element task, the equipment task puts all registered units into operation. All newly registered plug-in units are commissioned immediately.

Card protection 1+n card protection is generally based on a protection group comprising n protected plug-in units and a protecting plug-in unit of the same type.

Depending on the configuration, the plug-in units of a protection group assume one of the following roles:

• Protecting plug-in units, capable of taking over the transmission functions for one of the protected plug-in units in the event of an error

• Protected plug-in units, the transmission functions of which are protected in the event of equipment faults.

0

By means of protection switching processes, each of these plug-in units switches to one of the following two states:

• Active: The plug-in unit provides transmission functionality

• Standby: The plug-in unit is not currently providing transmission functionality, only equipment faults are monitored.

0

The following card protection possibilities are realised:

• 1+1 card protection of the CMU-1, i.e. the protection group comprises a CMU-1 and a further CMU-1 as protecting plug-in unit

• 1+n card protection of the TIU-1, i.e. the protection group comprises n (maximum 7) TIU-1s and a further TIU-1 as protecting plug-in unit.

0

Card protection is based on the fact that in the event of particular equipment faults (e.g. power failure of communication failure), the equipment task switches the traffic over from one of the protected plug-in units to the protecting plug-in unit. Information concerning the plug-in unit errors is sent to the equipment task by the fault task (MCFA).

The equipment task causes the traffic to be switched over to the protecting plug-in unit when an active plug-in unit in the protection group reports an equipment alarm and the protecting plug-in unit is without equipment faults.

If one of the other fault-free plug-in units of the protection group has the status ‘standby’, i.e. is not carrying data traffic, and the protecting plug-in unit is currently active, the traffic of the protecting plug-in unit is first switched to the plug-in unit with the status ‘standby’, before the traffic of the failed plug-in unit can be switched to the protecting plug-in unit.

If the equipment fault on this plug-in unit has been cleared and a further protected plug-in unit of this protection group reports an equipment alarm, the



2

traffic being carried by the protecting plug-in unit is first switched back to the original plug-in unit, and then the traffic of the failed plug-in unit is routed to the protecting plug-in unit.

Card protection does not feature a facility for automatically switching traffic back to a protected plug-in unit once the fault there has been cleared. However, by pressing a button on the plug-in unit, it is possible to create a virtual equipment alarm (PIU Power Failure) which triggers protection or a switching back. This alarm is also reported to the management system (NMS or CAT-4X).

The management system perceives card protection as follows:

• A protecting plug-in unit is not visible at the management interface of the NE. The protection group is established by inserting a protecting plug-in unit and deleted by inserting another card in the same slot

• A protection measure is reported to the management system by an equipment alarm generated by the protecting plug-in unit. This alarm is generated when the traffic is switched to the protecting plug-in unit, and cleared when the traffic is reverted to the original plug-in unit. As long as the alarm is present, the plug-in unit concerned thus remains in standby mode.

• Alarms generated by a protecting plug-in unit are set to ‘cleared’ while protection is in operation, and updated after successful completion of the switchover to reflect the status of the protecting plug-in unit.

0

Transmission object managementThe termination points of the signal transmission links are registered in the network management system and the network element as transmission objects. The transmission object management is responsible for the implementation of network management instructions and the administration of object data with regard to the transmission objects.

Definition of termsThe following termination point types exist:

• Trail termination point

• Connection termination point.0

A network element creates both the section overhead and the various path overheads in the respective trail termination points. This provides the trail termination points with the transport functions required for data transmission.

In addition, routes must be defined in the network before the transport functions can be used. This is accomplished using the connection termination points. A connection is established within a network by assigning connection termination points to certain trail termination points.



The transmission object management is designed to process the following types of termination points in the form of object instances:

• SDH physical interface trail termination point

• Trail termination point and connection termination point of a regenerator section

• Trail termination point and connection termination point of a multiplex section

• AU-4 connection termination point

• VC-4 connection termination point

• VC-4 trail termination point

• TU-12 connection termination point


• PDH-2 connection termination point

• Plesiochronous physical trail termination point


• P-2 connection termination point





• TU-3 connection termination point.0

In addition, transmission object management is responsible for the following elements of the multiplex structure:

• AUG administrative unit group

• TUG-3 tributary unit group

• TUG-2 tributary unit group. 0

The individual transmission objects are related to the multiplex structure illustrated in Figure 2-16. The objects are either directly related to an element of the multiplex structure (e.g. V-12 trail termination point) or they must be assigned to one of the elements.

The multiplex section overhead (MSOH) and the regenerator section overhead (RSOH) are processed in the termination points of the multiplex sections and the regenerator sections. These termination points are therefore related to the STM-N signal in the multiplex structure. The physical termination points function as transfer points to the transmission lines. The plesiochronous 2 MBit/s signal is inserted in the C-12 and retrieved from the



2

C-12 at the P-12 connection termination point and the PDH-12 connection termination point respectively.

Figure 2-16Multiplex structure 2-16

The cross-connection object pointer can be assigned to a termination point. This pointer specifies the switched connection in which the termination point is involved.

The upstream connectivity pointer and the downstream connectivity pointer can also be assigned to a termination point. These pointers inform the termination point of the termination points to which it is connected.

An object instance may contain subordinate object instances of other object classes. This is referred to as a containment relationship. On the other hand, an object instance can only belong to one superordinate object instance. The containment relationship reflects reality. The object instance of an AU-4 administrative unit can be contained in an AUG administrative unit group. This illustrates the interconnection between an AU-4 and an AUG in accordance with the multiplex structure.

Transmission object alarms are triggered for transmission line failures that were reported by the hardware drivers. Transmission object alarms may be triggered in downstream and upstream direction.

C-121) VC-12

TU-2 TUG-2

AUG

AU-3

C-2

C-3

C-4 VC-4

VC-3

VC-2

TU-12

AU-4 STM-N

Container Virtual container Tributary unit Tributary unit group

Administrative

Synchronous

140 Mbit/s

Tributary

34 Mbit/s

6 Mbit/s

2 Mbit/s

45 Mbit/s

C-111) VC-11 TU-111.5 MBit/s

TUG-3

•4•3

•1

TU-3VC-3•3

•1

•7

(lower order)

Virtual container(higher order) unit

part of the ETSI option supported by the network element

part of the ETSI option not supported by the network element and unsupported SONET option

1) Comment: The container C1 is divided into theversions C11 (1.5 MBit/s) and C12 (2 MBit/s) in this representation.

•7

•3

transportAdministrative

unitgroup

•N

signal

module



Alarms that are triggered for a specific transmission object can be assigned one of several severity levels on the basis of an alarm severity assignment profile (ASAP). The profile comprises a list of possible alarms and their severity.

Similar to the application software of the management and communication unit, the application software on the peripheral units is designed in accordance with an object-oriented approach. All objects are undefined after a warm start, i.e. the management and communication unit cannot query object attributes or receive notifications. The application software can be used to define the objects on the peripheral units individually using a ‘define’ notification in order to facilitate the explicit query of attributes and the receipt of notifications.

Automatic laser shutdown (ALS) is a safety mechanism that deactivates the laser if a signal is not present on the receive side and it must therefore be assumed that the optical signal connection is interrupted. The laser is automatically reactivated as soon as a signal is detected on the input port.

The laser can be temporarily activated by the network management system to run tests or manually return to normal operation.

Tasks of the transmission object management The following tasks are responsible for transmission object management (Figure 2-17):

• The MCTP (MCU termination point task) for the administration of transmission objects that represent termination points

• The MCAU (MCU administrative unit task) for the administration of administrative unit groups (AUGs) and tributary unit groups (TUGs).

0

The system tasks shown in Figure 2-17 are only responsible for the management of transmission objects and do not have transmission functions. The termination point task and the administrative unit task are commonly referred to in the following as ‘transmission object tasks’ where no differentiation is required.

Figure 2-17Transmission object management tasks 2-17

MCTP MCAU

Transmission object management



2

The transmission object tasks communicate with the following tasks to carry out their administrative function (Figure 2-18):

• The MCCM (MCU CMISE agent task), which forwards network management commands regarding the management of the transmission objects to the transmission object task

• The MCEF (MCU event forwarding discriminator task), which receives notifications from the transmission object tasks

• The MCFA (MCU fault task), which administers transmission line alarms for the individual transmission objects

• The MCEQ (MCU equipment task), which administers the plug-in units of the network element

• The MCPO (MCU port task), which administers the ports of the network element

• The MCTG (MCU timing generator task), which coordinates the clock supply for the network element

• The PUADs (PU administration data tasks), which function as the communication partners of the transmission object tasks on the peripheral units.

0



Figure 2-18Context of the transmission object management 2-18

Functions of the transmission object management The following functions are implemented by the transmission object management tasks:

• Creating object instances

• Administering object instances

• Deleting object instances.0

Creating object instances The creation of transmission objects can be initiated by:

• The creation of certain object instances

• A network management command.0

If the equipment task, the port task or the termination point task create an object instance, other object instances may be automatically created by the termination point task. The equipment task and the port task therefore report all newly created object instances to the termination point task.Table 2-2

MCFA

MCAU

MCTG

MCEF

MCCMMCPO

MCTP

MCEQ


Timing generator

Fault management

MCU

PUAD

PU


Transmission object managementmanagement



2

shows which instances are created by the termination point task if a certain object instance is created by a certain system task.

Otherwise, instances are only created by the transmission object tasks if a network management command is present. If a network management command calls for the creation of a specific instance, the termination point task creates this instance.

The network management determines whether the termination point to be created should be permanently connected to another termination point or whether it can be used by the connection management to switch between connections. If the new termination point is to be permanently connected to another termination point, the termination point task sets the connectivity pointers for the new and the existing termination points accordingly.

If the administrative unit task receives a command from the network management system to define the structure of the VC-4 virtual container, it creates an object instance for an administrative unit group. The administrative unit task subsequently creates object instances for the following structural elements according to the multiplex structure supported by the network element (Figure 2-16):

• Three TUG-3 tributary unit groups

• Seven TUG-2 tributary unit groups for each TUG-3 or TU-3

Table 2-2Automatic instantiation 2-2

Created object instance Creating task Automatically created instance

TIU-1 tributary interface unit Equipment task VC-12 trail termination point (a total of 21 instances per TIU-1)

SIU synchronous interface unit

Equipment task Trail termination point of a regenerator section

Port on a synchronous interface unit

Port task SDH physical interface trail termination point

Port on a tributary interface unit

Port task PDH physicalinterface TTP

SDH physical interface TTP Termination point task

Connection termination point of a regenerator section

Plesiochronous physical trail termination point

Termination point task

PDH connection termination point

VC trail termination point Termination point task

P trail termination point



• Three TU-12 tributary units for each TUG-2, if present.0

The network management system receives a notification from the transmission object tasks for each newly created instance. This also applies to automatically created instances with the exception of VC-4 substructures.

The timing generator task receives an NE-internal notification from the termination point task for all newly created object instances. The fault task receives a notification for the creation of instances for:

• SDH and PDH physical interface trail termination points

• Trail termination points of regenerator sections or multiplex sections

• AU-4 and TU-12 connection termination points

• VC-4 and VC-12 trail termination points

• VC-3 trail termination points and TU-3 connection termination points.0

Each instance that represents a termination point is related to a peripheral unit. The data task on the affected plug-in unit therefore receives a define notification for each newly created termination point. This does not apply to the connection termination points of multiplex sections. The management of MS connection termination points on the plug-in units is not required, as these termination points are not physically represented in the network.

If the termination point task creates an instance for a TU-12 connection termination point, the administration data task on the corresponding PPU-1 receives a define notification for this termination point.

Administering object instancesThe administration of object instances comprises the administration of object attributes and the implementation of incoming network management commands.

The operational state of a transmission object may change if a unit failure occurs or a transmission line alarm is triggered. The operational state indicates whether or not the transmission object can be used to switch a connection or perform other operations. If a unit failure occurs or a transmission line alarm with a ‘major’ or ‘critical’ severity level is triggered, the termination point task changes the operational state of the affected object instances to ‘not operational’.

Configuration data is not available on a plug-in unit after replacement or warm start. The MCU termination point task sends a define notification to the administration data task of the affected PU after it is notified by the equipment task that a unit has been replaced or reset.

The laser can be reactivated using a network management command after it was automatically shut down. The start command contains the identifier of a termination point. The termination point task only accepts the command if the termination point is an SDH physical interface trail termination point on a



2

synchronous interface unit. After acceptance of the command, the MCU termination point task instructs the administration data task on the affected synchronous interface unit to activate the laser.

The transmission object tasks provide object attributes if these are queried by the network management system. If the attribute values are only available on the plug-in units, the transmission object tasks poll the plug-in units for these values.

The object attributes are also changed by the transmission object tasks if commanded by the network management system. If an attribute value is stored in one of the peripheral units, the termination point task commands the PU administration data task to set the value on the PU.

Deleting object instancesThe deletion of transmission objects can be initiated by:

• Deleting certain object instances

• A network management command.0

Similar to the automatic creation of object instances, the deletion of certain object instances will automatically delete transmission objects. However, the transmission object tasks cannot delete an object instance unless all deletion conditions are fulfilled. The objects whose deletion effects the deletion of other transmission objects are shown with the deleting task in Table 2-3. Table 2-3 also illustrates the instances that are subsequently deleted by the transmission object tasks and the respective deletion conditions.

All objects that are assigned to the respective plug-in units are automatically deleted unless they are assigned a bus resource or are contained in the list of available timing sources.

Table 2-3Automatic deletion 2-3

Object instance to be deleted

Deleting task

Automatically deleted instances

Deletion conditions

Tributary interface unitTIU-1, TIU-3, TIU-4

Equipment task Transmission objects assigned to this plug-in unit

No termination point belongs to a switched connection and a bus has not been assigned

Synchronous interface unitSIU

Equipment task Transmission objects assigned to this plug-in unit

No VC-4 trail termination point must be deletedNo termination point provides a timing source for selectionNo termination point belongs to a switched connection and a bus has not been assigned



Otherwise, the network management system issues a command to delete certain transmission objects. The transmission object tasks execute the network management command if the following conditions are fulfilled:

• The termination point does not provide a timing source for selection

• A bus resource has not been allocated to the termination point.0

The network management system receives a notification from the transmission object tasks for each instance that is deleted. This ensures that the network management system is also informed about the object instances that are deleted automatically.

If an instance that is in a superordinate containment relationship with one or several object instances is to be deleted, all of the subordinate object instances must be deleted by the transmission object tasks first. Both superordinate and subordinate object instances can only be deleted by the transmission object tasks if none of the object instances belongs to a switched connection or a protection.

The following tasks receive an NE-internal notification from the termination point task for all object instances that are deleted by the termination point, provided these instances were previously registered by the termination point (see page 2-34, ‘Creating object instances’):

• The fault management task

• The MCU timing generator task.0

Each instance that represents a termination point is related to a plug-in unit. The administration data task on the affected plug-in unit therefore receives an undefine notification for each termination point that is deleted. This does not apply to the deletion of termination points of multiplex sections, as these are not physically represented on the peripheral units.



2

Connection managementThe task of the connection management is to switch the signal paths within the network element in accordance with the commands of the network management system. The connection management initiates and monitors the set-up and release of connections.

Definition of termsBefore connections are established, the respective termination points (TP) are assigned vacant bus resources by the management system.’

The set-up of a cross connection (CC) is identical to the connection of termination points.’ If the connection management is to connect individual termination points, the network management system must specify exactly which termination points are to be connected.

The application software supports bidirectional point-to-point connections. This type of connection involves the connection of two termination points to one another. The signal flow between the termination points is bidirectional.

Figure 2-19 shows a bidirectional point-to-point connection between two termination points. The various pointers used by the connection management are described below on the basis of this diagram.

Figure 2-19Bidirectional point-to-point connection 2-19

1 23 4

5/6

7/8

TP-Abidirectional

TP-Zbidirectional

Connection



The pointers have the following function:

• Pointer 1: Cross-connection pointer of termination point A

• Pointer 2: Cross-connection pointer of termination point Z

• Pointer 3: From termination of the connection

• Pointer 4: To termination of the connection

• Pointer 5: Upstream connectivity pointer of termination point A

• Pointer 6: Downstream connectivity pointer of termination point A

• Pointer 7: Upstream connectivity pointer of termination point Z

• Pointer 8: Downstream connectivity pointer of termination point Z 0

Each cross-connection pointer is assigned one termination point. This means that these pointers inform the termination points of the switched connection in which they are involved.

The switched connection is informed of the termination point assignment by means of the to and from termination specification.

The pointers 5, 6, 7 and 8 are the upstream/downstream connectivity pointers. These pointers inform the termination points which connection is switched to which termination point.

Each shelf contains a data bus that is composed of the following subbuses (Figure 2-20):

• The ADD bus

• The DROP bus

• The SYNC bus.0

The following plug-in units access the main data bus:

• Tributary interface units (TIUs)

• Synchronous interface units (SIUs)

• Pointer processing units (PPUs)

• Connection matrix units (CMUs).0

Figure 2-20 shows which subbus is accessed by the plug-in units, depending on the slot. The document TN-4X Equipment Configuration 323-1121-210 specifies the slot in which the plug-in units are to be inserted.



2

Figure 2-20Subbuses in the shelf 2-20

Each of the three subbuses consists of 18 micro-buses. Sixteen of these micro-buses are used to transfer data. The micro-buses that are to be accessed in read/write mode by a plug-in unit on the respective slot are specified for each slot.

Connection management tasksThe connection management is implemented by three tasks (Figure 2-21):

• The MCCO (MCU connection task), which administers the connections defined by the network management

• The MCCC (MCU centralized connections task), which coordinates the physical implementation of a connection

• The MCFB (MCU fabric task), which administers the fabric object that is addressed by the network management system during the set-up and release of connections.’

0

ShelfDROP

ADD

bus

bus

SYNCbus

CMU SIU TIU PPU

Read access

Write access

ADD/DROP busa

DROP/ADD busa

SYNC bus

adepending on the slot



Figure 2-21Tasks of the connection management 2-21

The administration of the connections within the network element requires the connection management tasks to be connected to (see Figure 2-22):

• The MCCM (MCU CMISE agent task, CMIS agent), which forwards network management commands to the connection management

• The MCEF (MCU event forwarding discriminator task), which receives notifications from the connection management

• The MCNE (MCU network element task), which reports after management and communication unit start-up

• The MCEQ (MCU equipment task), which administers the hardware components of a network element, including their availability

• The MCPR (MCU protection task), which initiates connection switching in the event of protection switching’

• The MCFA (MCU fault task), which is informed of failures in the communication with the peripheral units by the connection management

• The PUADs (PU administration data tasks) on the peripheral units, which accept the settings for the switching matrixes.

0

MCCO MCFB

MCCC




2

Figure 2-22Context of the connection management tasks 2-22

Connection management functionsThe following functions are implemented by the connection management tasks:


• Setting up a connection

• Releasing a connection

• Protection switching in the event of a connection failure

• Responding to equipment management messages0

Creating, administering and deleting object instancesAfter MCU start-up, the network element task requests the fabric task to create an instance of the object class ‘Fabric’. Since the network management system directs commands for the set-up and release of connections to the object instance ‘Fabric’, connection switchings can be processed immediately after the management and communication unit has been started.

MCCM

MCFB

MCCO

MCEQ

MCCC

MCEF

MCNE

MCFA

MCPR

PUAD

PU

MCU



Connection management Network element management

Fault management

Protection switching management



If the network management issues the command to switch a connection between two termination points, the fabric task checks that the network management has previously released the connection set-up. The command is only accepted by the fabric task and forwarded to the connection task if connection set-up has been enabled.

The connection task now checks whether or not the connection can be switched. A connection can be switched if:

• A bidirectional point-to-point connection is required

• A connection is to be set up between

— two TU-12 connection termination points

— a TU-12 connection termination point and a VC-12 trail termination point

— two VC-12 trail termination points

— two TU-3 connection termination points

— a TU-3 connection termination point and a VC-3 trail termination point

— two VC-3 trail termination points

— two AU-4 connection termination points

— an AU-4 connection termination point and a VC-4 trail termination point

— two VC-4 trail termination points0

• and the bus assignments have already been made by the management system

• Termination points have not yet been switched

• Termination points are not involved in a protection switching procedure.0

Bus assignments are vacant bus resources provided for the object instances AU-4, VC-4, VC-3 and VC-12. The MCU centralized connections task is responsible for the assignment and release of bus resources.

If the connection can be switched, the connection task creates an object instance for this connection and sets the cross-connection pointers of the respective transmission objects. The network management command used to switch the connection also specifies whether this connection is initially to be treated only as an object instance, or if it is to be converted for the hardware. The network management system provides this information in the form of an object attribute. If conversion is required, the connection task sets the cross-connection pointers of the affected termination points. In addition, the MCU centralized connections task receives the message that the connection is to be set up. The ‘Unequipped’ generators are deactivated, i.e. the signal output then provides a payload signal.



2

The network management system receives a notification from the connection management for every object instance that is created. It also receives a notification if the connection task has changed the pointers of a transmission object.

The network management system can poll and change the attributes assigned to the connection management object instances at any time by means of a command. Whether a connection is to be treated as an object instance only or converted to the hardware is specified via the ‘AdministrativeState’ attribute. If the network management changes the administrative state, the connection task instructs the MCU centralized connections task to set up or release the connection.

The connection management can delete only those object instances that represent a connection when commanded to do so by the network management. This network management command is received by the fabric task. If the network management has previously enabled the release of the connection, the fabric task accepts the command and forwards it to the connection task.

The connection task first checks if the network management command is valid. The command is valid if:

• A connection transmission object is specified in the delete command.

• The connection to be deleted is not assigned to a protection.0

The connection can be deleted regardless of the value of the attribute ‘Administrative State’ (either ‘locked’ or ‘unlocked’) for the object instance ‘Connection’ (CrossConnectionPNS). Furthermore, the connection task resets the cross-connection pointers of the affected transmission objects. The connection task deletes the object instance of the connection and resets the cross-connection pointers of the respective transmission objects.

Similar to the creation of object instances, the network management system receives information on all deleted object instances and all changed pointers of the respective transmission objects.

Setting up a connectionThe set-up of a connection is coordinated by the MCU centralized connections task upon the request of the connection task. The switching matrix must be set in order to establish a connection. The MCU centralized connections task calculates the settings for the switching matrix and transmits it to the data administration tasks of the respective peripheral unit.

The PU administration data tasks send the MCU centralized connections task an acknowledgment of receipt of the settings. If an acknowledgment is not sent, the MCU centralized connections task assumes that a communication failure has occurred and reports this to the fault task.



If a VC trail termination point is part of a connection, alarm monitoring must be activated for this termination point. Furthermore, the installation of the alarm indication signal (AIS) must be deactivated for the physical trail termination point assigned to the VC trail termination point. The PU data administration task, which is responsible for the termination points, receives a corresponding message from the MCU centralized connections task.

Releasing a ConnectionA connection is released in the same logical way as it is set up. The ‘unequipped’ identification or the alarm indication signal must be reinstalled depending on the termination points that were involved in the connection. Alarm monitoring must be deactivated.

Protection Switching in the Event of a Connection FailureIf protection switching is to be set up in the event of a connection failure, the MCU protection task initiates the switching measures. The MCU centralized connections task then receives a message from the MCU protection task. The message informs the MCU centralized connections task which connection is to be released and which one is to be set up again. This results in the modification of the switching matrix setting on the connection matrix unit (CMU). The new settings are sent by the MCU centralized connections task to the PU administration data task of the affected connection matrix unit.

If the MCU centralized connections task does not receive an acknowledgment from the PU administration data task confirming the receipt of the settings, the MCU centralized connections task assumes that a communication failure has occurred. The MCU centralized connections task reports the failure to the fault management system.

Responding to Equipment Management MessagesThe connection management receives a message from the equipment management in the following cases:

• A plug-in unit instance is to be deleted

• A plug-in unit has been replaced or a new one inserted

• A plug-in unit has undergone a warm start.0

The equipment task can only delete a plug-in unit if no connection is defined via this plug-in unit. A connection is defined if an object instance exists for this connection. The equipment task is notified by the connection task whether or not a connection is defined via this plug-in unit.

If a peripheral unit has been exchanged or a new one inserted, or if a plug-in unit has undergone a warm start, the MCU centralized connections task receives a message regarding this event from the equipment task. For the MCU centralized connections task, this means that the respective peripheral unit must be configured for the first time or reconfigured. The MCU centralized connections task is responsible for the configuration, insofar as it must have the objects that it requires for its task on the peripheral unit defined



2

either for the first time or again. Therefore, handling is required for the MCU centralized connections task if the following unit types are affected:

• Synchronous interface units (SIUs)

• Tributary interface units (TIUs)

• Pointer processing units (PPUs)

• Connection matrix units (CMUs) 0

If a corresponding plug-in unit has been exchanged for a plug-in unit of the same construction type, or if a corresponding plug-in unit has undergone a warm start, the MCU centralized connections task then has the required objects defined by the PU data administration task. In addition, the MCU centralized connections task sends the settings for access to the micro-buses and for the switching matrix (only in the case of a CMU) to the PU administration data task again. Depending on the termination points involved in the connection via the plug-in unit, idle frame labels or alarm indication signals must no longer be installed. Alarm monitoring must be activated (see page 2-45, ‘Setting up a connection’).

If one of the above-named peripheral units has been newly inserted, the connection management must have the required objects defined by the PU administration data task. This also involves the transmission of settings from the MCU centralized connections task to the new peripheral unit for access to the micro-buses. As no connections were previously established via this new peripheral unit, actions going beyond definition are not required.



Protection managementThe reliability of a transmission system can be increased considerably by protection switching measures. The protection management in network elements is used to support 1+1 subnetwork connection protections (SNCP) and 1+1 path protections.

Card protection is administered by equipment management (see page 2-22, ‘Equipment management’), CCU protection by timing generator management (see page 2-55, ‘Timing generator management’).

A subnetwork connection is a path segment between two units, between which STM signals are exchanged. The protection switching of the subnetwork connection is based on both the duplication of the signals that are to be transmitted on main lines and standby lines as well as the selection of one of the receive signals (Figure 2-23).

Figure 2-23Protection switching of a subnetwork connection 2-23

Path protection switching corresponds to the protection switching of a subnetwork connection, with the exception that termination point 3 is a connection termination point (CTP) for path protection switching and a trail termination point (TTP) for subnetwork connection protection switching.

CTP 1bidir.

CTP 2bidir.

TP 3bidir.

Protection switching

Main line

Standby line

Network element

switched through

not switched through



2

The termination point is referred to in the following as a working termination point that terminates the main or standby line and whose receive signal is forwarded.

In the object-oriented approach of network management, object instances are used to represent protection switching connections. Figure 2-24 shows the assignment of the object classes to one another, including the pointers (in the event that termination point 1 is a working termination point).

Figure 2-24Object approach to protection switching 2-24

The pointers shown in Figure 2-24 have the following functions:

• Pointer 1: Protected resource

• Pointer 2: High-priority resource

• Pointer 3: Low-priority resource

• Pointer 4: Protecting resource

• Pointer 5: Cross-connection pointer of termination point 2

• Pointer 6: Upstream connectivity pointer of connection termination point 2

• Pointers 7 and 11: Downstream connectivity pointers of termination point 3

41

CTP 1bidir.

CTP 2bidir.

TP 3bidir.

5

8/9

10/11

12 13

14 15

Connection

Protection switching

2

3

6

716



• Pointer 8: Downstream connectivity pointer of connection termination point 1



• Pointer 12: From termination of the connection


• Pointer 14: To termination of the connection


• Pointer 16: Protection switching instance (Protected by).0

According to the definition of the connection instance, the designation of the pointers 12 and 14 as to and from terminations can also be swapped over.

Each cross-connection pointer is assigned one cross-connection termination point or trail termination point, i.e. these pointers specify the switched connection in which the termination point is involved. The cross-connection pointer of termination point 2 points to the connection instance, as long as termination point 1 is the working termination point.

The assignment of the termination points to the switched connection is specified for the connection by the ‘to’ and ‘from’ terminations.

Pointers 6 to 11 are the upstream/downstream connectivity pointers. These pointers inform the cross-connection termination points which connection is switched to which termination point.

Pointers 1, 2 and 4 of the protection switching instance specify which termination points are involved in protection switching for the respective instance. The pointer to the subordinate termination point is not set in the case of 1+1 SNCP protection switching and 1+1 path protection switching.

The execution of a protection switching measure has the following effects on the pointers:

• The to termination of the connection (pointer 12) points to cross-connection termination point 2

• The cross-connection pointer of connection termination point 2 (pointer 5) points to the connection

• The upstream connectivity pointer of termination point 3 (pointer 10) points to connection termination point 2

• The downstream connectivity pointer of connection termination point 1 (pointer 8) is deleted and the corresponding pointer of connection termination point 2 is set



2

• The cross-connection pointer of connection termination point 1 (pointer 13) points to the protection switching instance.

0

The remaining pointers remain unaffected by the execution of a protection switching measure.

Protection management tasksProtection management is implemented by the MCPR (MCU protection group task) (Figure 2-25).

Figure 2-25Protection management task 2-25

The protection management communicates with the following tasks in order to be able to fulfil its function (Figure 2-26):

• The MCCM (MCU CMISE agent task, CMIS agent), which forwards network management instructions regarding external protection switching to the protection management

• The MCEF (MCU event forwarding discriminator task), which receives messages from protection management

• The MCEQ (MCU equipment task), which administers the plug-in units

• The MCFA (MCU fault task), which receives information regarding communication failures with the peripheral units

• The MCCC (MCU centralized connections task), which coordinates the conversion of the measure to the hardware in the event of a protection switching

• The PUPAs (PU protection alarm tasks), which monitor both the protecting and the protected termination points

• The PUADs (PU administration data tasks), which receive the protection data for the respective peripheral unit.

0

MCPR

Protection management



Figure 2-26Context of the protection management tasks 2-26

Protection management functionsThe following functions are implemented by the protection management tasks:


• Performing a switching measure

• Responding to the planned deletion of a plug-in unit instance0

Creating, administering and deleting object instancesThe network management must have a protection instance created in order to implement a protection option. The MCU protection task receives a command from the network management system. The command contains at least the following specifications:

• Protected termination point

• Protecting termination point

• High-priority resource.

MCCM

MCPR MCFA

MCEF

MCEQ

MCCC



Protection

Fault management


PUAD

PU

MCU

PUPA

management



2

First, the MCU protection task verifies whether or not the command is valid. The command is valid if:

• Both the protected and the protecting termination points are TU-12 or TU-3 or TU-4 connection termination points

• The transmission capacities of the termination points involved in the protection switching are identical

• A connection is defined between the high-priority resource and the protected termination point

• The defined connection is physically switched

• The protecting termination point is not already part of a connection or of another protection switching

• The protected termination point is not the same as the protecting termination point

• The bus allocation for protection switching has already been performed by the management system

• An AU-4 protection switching is not connected with a VC-4 that can be modified.

0

If the command is valid, the MCU protection task creates an object instance for the protection switching. In addition, it sets all pointers that are to be defined for a protection switching procedure (see page 2-5, ‘Definition of terms’). The MCU centralized connections task is then prompted to switch a unidirectional connection from the high-priority resource to the protecting termination point.

The protected and protecting termination points must be monitored so that the MCU protection task can identify the necessary switching measures. As a result, the PU administration data task on the pointer processing units (PPU) receives the command to monitor the two termination points. The MCU protection task awaits an acknowledgment of the command from the PU administration data task. If the acknowledgment is not received, the MCU protection task transmits an error message to the PU fault task.

The network management system receives a notification from the MCU protection task regarding the object instance that was set up as well as all modified pointer values.

The network management can poll and change the attributes assigned to the protection management object instances at any time using a command.

Protection switching is always based on a connection that was physically switched before the protection switching instance is created. If the network management system orders the deletion of a protection switching instance, the MCU protection task ensures that the switching matrixes are reset according to the original situation. The MCU centralized connections task receives an instruction from the MCU protection task. Furthermore, the MCU



protection task resets all pointers to the value set before the protection switching instance was created.

The MCU protection task informs the PU administration data task on the PPU that the protected and protecting termination points must no longer be monitored. If the PU administration data task does not acknowledge receipt of the information, the MCU protection task assumes that a failure has occurred and notifies the PU fault task.

The network management system receives a notification from the protection management both for the deleted object instance and for every modified pointer value.

Performing protection switching Protection switching can be executed automatically or manually by means of a network management command.

A network management command is necessary for manual protection switching. If the MCU protection task receives the command, it checks if the conditions for switching the protection have been fulfilled. Switching is performed if:

• The state of the protected and the protecting termination points are failure-free

• Both are not failure-free or the state is unknown

• The switch ‘autoswitch’ is in the ‘OFF’ position.0

Only then does it accept the command, change all affected pointers and have the MCU centralized connections task set the switching matrixes and the ‘Unequipped’ generators to AU-4 accordingly.

The network management system receives a notification from the MCU protection task for every modified pointer and for the successfully executed switching measure.

The MCU protection task can also automatically perform switching measures in the event of failures. This requires that automatic switching is released by the network management system. The network management system can enable the release for each protection switching instance individually.

The alarming task always sends the MCU protection task a message if a communication failure for the protected termination point or for the termination point to be protected occurs or comes to an end. The operating system informs the MCU protection task of peripheral unit failures. The MCU protection task receives a notification from the equipment task when a peripheral unit becomes available again after a warm start or has been replaced by another unit of the same type. The MCU protection task is thus informed of whether or not the receive signals of the main and standby lines can be forwarded to the high-priority resource.



2

A switching measure is necessary if a failure occurs in conjunction with the working termination point. In this case, the MCU protection task checks if the receive signal of the other termination point is failure-free and an automatic switchover has been released. If this is the case, the MCU protection task initiates a switching measure.

Initiation of the switching measure consists of modifying the affected pointer values and instructing the MCU centralized connections task to adapt the switching matrix settings.

The network management receives a notification from the MCU protection task for all modified pointers and for the performed switching measure.

Responding to the planned deletion of a plug-in unit instanceThe equipment task notifies the MCU protection task of every peripheral unit instance that it intends to delete. In the event that one of the termination points of a protection switching is located on the affected peripheral unit, the MCU protection task informs the equipment task accordingly. In this case, the equipment task does not delete the peripheral unit instance.

Timing generator managementThe synchronous operation of the individual network elements forms the basis of an SDH transmission network. In order to achieve this, the network element has a number of timing sources at its disposal. The timing generator management has the task of ensuring the clock supply for the entire network element using the available timing sources.

Definition of termsA variety of timing sources are available for a network element, which are supported by the application software:

• Clock in the SDH receive signals that are represented by the MSTTP objects (multiplex section trail termination point objects), and are the SDH receive signals of SIU-N or TIU-4 plug-in units.

• External timing sources, represented by the two instances of the MCU object ‘portPhase’.

• Oscillator on the central clock unit (CCU) as a piggy-back board on the SIU-1 or SIU-4 in slot 3.

0

The selection of a timing source for the network element clock depends on the significance of a timing source. The significance of a timing source depends:

• First on the clock quality

• and in the case of several sources of the same quality, on the priority of the timing source.

0

The clock quality can assume the following values:

• G.811 (highest quality, ITU-T G.811 requirements are fulfilled)



• G.812 transit (ITU-T G.812 requirements for ‘transit node clock’ are fulfilled)

• G.812 local (ITU-T G.812 requirements for ‘local node clock’ are fulfilled)

• SETS (Synchronous Equipment Timing Source, ITU-T G.783 requirements are fulfilled, internal oscillator)

• Unknown (lowest quality). 0

The priority of a timing source can be specified by the network management system. The priority can assume an integer value between 1 and 16. The priority ‘1’ corresponds to the highest priority.

In order that the network element at the far end is informed of the clock quality with which an SDH signal was generated, each network element sets the ‘Timing Marker’ in the overhead of the transmit signal (refer to ITU-T G.708). The quality of the reference clock is coded in the timing marker byte. In addition to the clock qualities defined above, the timing marker byte can also contain information specifying that the network element at the far end should not use the receive signal as a timing source (e.g. in order to avoid clock loops).

Timing generator management tasksThe MCU timing generator task (MCTG) on the management and communication unit is responsible for timing generator management (Figure 2-27).

Figure 2-27Timing generator management tasks 2-27

The MCU timing generator task communicates with the following to fulfil its function (Figure 2-28):

• The MCCM (MCU CMISE agent task, CMIS agent), which forwards network management system instructions regarding clock supply to the MCU timing generator task.

• The MCEF (MCU event forwarding discriminator task), which receives messages from the timing generator task

MCTG

Timing generator management



2

• The MCEQ (MCU equipment task), which reports changes in the peripheral units that are relevant for clock supply

• The MCTP (MCU termination point task), which informs the timing generator task of all created or deleted termination points

• The MCFA (MCU fault task), which administers clock supply failures

• The MCMC (MCU MCI driver task), via which timing generator management has access to the external clock input and output ports of the MCU connection interface (MCI).

• The PUADs (PU administration data tasks) on the synchronous interface units (SIUs), with which timing generator management can have values on the interface units polled or set.

0

Figure 2-28Context of the MCU timing generator task 2-28

MCCM

MCTG

MCEF

PU


Transmission object

Timing generatormanagement

Fault management


MCFA

MCTP

MCEQ

management

MCU

MCMC

PUAD



Functions of timing generator managementThe MCU timing generator task provides the following functions:

• Creating, administering and deleting an object instance

• Responding to changes in the termination points

• Selecting the timing sources.

• Clock protection (CCU protection). 0

Creating, administering and deleting an object instanceThe MCU timing generator task receives a message as soon as the equipment task has created the object instance of a synchronous interface unit with central clock unit.

The MCU timing generator task then creates an object instance for clock supply. Data administration on the synchronous interface unit with the central clock unit commands the MCU timing generator task to create an object for the clock supply.

If the data building block does not acknowledge the receipt of the request, the MCU timing generator task reports a communication failure to the PU fault task. The MCU timing generator task always notifies the PU fault task that clock supply failures exist that must be administered.

The MCU timing generator task informs the network management that it has created the object instance for the clock supply.

The CMIS agent transmits network management commands regarding timing generator attributes directly to the MCU timing generator task. If the MCU timing generator task has the attribute in its data area, it reads or changes the value in accordance with the network management command. Otherwise, it has the responsible data building block change the value, or it scans it for the desired value. The MCU timing generator task always forwards scanned attribute values to the network management system via the CMIS task.

If the equipment task informs the MCU timing generator task that the instance of the optical interface unit with central clock unit will be deleted, the MCU timing generator task deletes the object instance for the clock supply.

The PU fault task then receives a notification from the MCU timing generator task which confirms that it is no longer necessary to administer the clock supply failures. The network management system receives the notification that the clock supply object instance no longer exists.

Responding to changes in the termination pointsThe clock that can be extracted from an SDH receive signal can also act as the timing source for the network element. If the MCU termination point task has created a new termination point instance, it reports this to the MCU timing generator task. If this instance is the termination point of a multiplex section,



2

a new receive signal that can act as the timing source exists for the MCU timing generator task.

The termination point of a multiplex section is always assigned to a plug-in unit. The data administration on this plug-in unit is commanded by the MCU timing generator task to create an object for the new timing source.

Selection of the timing source The main task of the MCU timing generator task is the selection of one of the timing sources for the network element clock supply and the selection of the timing source for the external network clock output port T4 on the MCU connection interface. Correspondingly, a list of timing sources for the internal clock of the network element exists, as well as a list for the external network clock output.

The internal list contains all possible timing sources as described above.

• Clock in the SDH receive signals

• External timing sources

• Oscillator on the central clock unit (CCU) 0

The external list contains the following timing sources:

• Clock in the SDH receive signals0

As soon as the MCU timing generator task has created the clock supply object, it selects the timing source with the highest quality from the list of available timing sources. The MCU timing generator task notifies all peripheral units with an SDH transmit signal of the value of the timing marker bytes that are to be installed. The selected timing source is then responsible for generating the clock for the network element. The external network clock output port T4 is temporarily deactivated.

The priority of the timing source is a decisive criterion for the selection of the timing source. This priority always has a preset value until the network management specifies another priority using a command.

The MCU timing generator task determines the new timing source used to generate the network element clock supply under the following conditions:

• The network management system changes the priority of the timing sources in the internal or external list. As a rule, the timing source with the best quality is automatically selected from the list, unless there is a timing source of the same quality with a higher priority.

• The selected timing source for generating the network element clock fails, or the quality changes (message from the fault driver or MCI driver).

• Replacement or warm start of a synchronous interface unit (message from equipment task).

0



After the replacement or warm start of a synchronous interface unit with central clock unit, the MCU timing generator task instructs the PU data administration building block on the SIU unit to create a new object for the clock supply.

The MCU timing generator task then selects the highest quality timing source from those available. It first scans all peripheral units for the clock quality of all possible timing sources. In addition, it informs the PU administration data task on a peripheral unit of the modified value of the timing marker byte, if necessary.

The MCU timing generator task always switches the external clock output port T4 on or off, according to the internal list and quality (INTERNAL) or the external list and quality (EXTERNAL).

There are three switch positions for the external clock output port (ExternalOutputClockControl):

• OFF: The external clock output port is switched off.

• INTERNAL: The internal timing source with the highest priority switched to the external clock output port.

• EXTERNAL: The timing source with the highest priority is taken from the external list and switched to the clock output port.

0

In the event that the selected clock does not fulfil the quality demands of ITU-T recommendation G.811, the MCU timing generator task switches the external clock output port off.

The network management system receives a notification from the MCU timing generator task for all changes in the selection of the timing source.

CCU protection CCU or clock protection requires the configuration of two clock sources. Of these two sources one always operates as master clock source, delivering the system clock, and the other operates as standby clock source, and automatically takes over the clock supply if the master clock source fails. Both clock sources together form a clock source protection group.

As the CCU-X3 clock sources are part of the Synchronous Interface Units (SIU), CCU protection requires a second SIU to be configured. The clock protection group is established by inserting a second SIU with CCU-X3 and removed by deleting this second SIU (or by inserting an SIU without CCU-X3 in its slot).

CCU protection is based on the fact that the timing generator task switches from the master clock source to the standby clock source as soon as fault management reports an equipment alarm in the SIU containing the master clock source. The clock source is not switched over if there is an equipment error in the standby clock source.



2

Clock source errors are reported to the connected management systems by means of an equipment alarm generated in the corresponding SIU. If an SIU with CCU-X3 is inserted instead of an SIU with faulty clock source, the clock source error is regarded as being cleared, and the MCU reconfigures the CCU protection.

The system is briefly without a clock source while the switchover from the master clock source to the standby clock source takes place. As a result the traffic is interrupted for a brief moment (approx. 100ms).

Data restoration servicesThe building block ‘Data restoration services’ facilitates the saving and reading of configuration data as well as the administration of this data using a backup medium.

The functions of the MCU configuration database building block are implemented by means of a procedural interface and are not activated via general task communication.

Definition of termsA ‘dump’ saves the configuration data on the backup medium. This is accomplished using application dump procedures. These procedures read the configuration data and store the data on the backup medium.

A ‘recovery’ reads the configuration data from the backup medium. This is accomplished using application recovery procedures. These procedures read the configuration data from the backup medium and save the data in the network element.

The backup medium is a Flash-EPROM in the network element. It is administered by the MCU configuration database building block.

Data Restoration Service TasksFigure 2-29 shows the MCCF building block (MCU configuration database building block) of the data restoration services. The MCU configuration database building block is responsible for the protection and recovery of the configuration data of a network element. It is the communication partner for the tasks that call up a dump or recovery.

Figure 2-29MCU data restoration services building block 2-29


MCCF



In order to fulfil its function, the building block is available to the following tasks (Figure 2-30):

• The MCNE (MCU network element management task), which is the communication partner for the network management system with respect to configuration data.

• Other MAF tasks that also call up the functions of the building block.0

Figure 2-30Context of the data restoration services tasks 2-30

Functions of the data restoration servicesThe procedures of the data restoration services implement the following functions:

• Dumping configuration data to the backup medium

• Recovering configuration data from the backup medium

• Detecting modifications to the configuration data

• Administering ‘premature and changeable data

• Administering the backup medium.0

Dumping configuration data to the backup mediumConfiguration data is saved as follows:

• The function reserves an area for the configuration data on the backup medium. Each procedure in the list of application dump procedures is called up. Each procedure knows where and how the corresponding configuration data is stored.

MAF tasks

MCNE

Other MAF areas

MCU

MCCF






2

• The data is written to the backup medium in blocks; the contents on the backup medium are checked by a driver routine.

• Finally, the administration data is written to the backup medium. This data contains the information required to identify an error on the backup medium for example during a recovery.

The saved backup configuration can now be used for the next recovery.

The dump fails if the backup medium cannot be addressed or if insufficient storage space is available. Modifying the configuration data while writing also leads to a dump error. The dump is then cancelled. From the point of view of the MCNE task, no dump exists with the most recent configuration data. In this case the management system can, however, repeat the dump procedure on its own.

Recovering the configuration data from the backup mediumThe saved configuration data is read in the following steps:

• The backup medium is scanned for the valid configuration data.

• The system checks that the backup medium can be used and that the saved configuration data was not changed.

• Reading the configuration data from the backup medium.0

A recovery fails if the backup medium cannot be addressed or the valid configuration data was not found, or if the configuration on the backup medium does not correspond to the most recent network element configuration (is determined by the MCNE task).

No changes are made to the configuration data by the management system during a recovery (see Figure 2-13).

Detecting modifications to the configuration dataThe MCCF building block does not contain any tasks. Other tasks use the functions of the MCCF by calling up its procedures. There is consequently no task communication with the building block and other tasks.

There is, however, communication between the tasks that use the functions of the MCCF building block and the network element management task (MCNE). If, for example, a task makes a change in the configuration data, this task subsequently calls up a special procedure, which then informs the network element task. If further changes are made to the configuration data, the MCCF building block does not send unnecessary additional messages to the network element task.

The network element task administers the information that specifies whether or not the configuration set in the network element, i.e. the current configuration data, corresponds to the data on the backup medium.



Premature and changeable data‘Premature’ data is administration data that is read before a recovery.

‘Changeable’ data is written after a dump or recovery. The value of the attribute‘ConfigurationState’ of the network element object ‘phase2’ provides information regarding the state of the configuration. If a discrepancy between the network element configuration and the backup medium configuration is detected, the network element task changes the value of the attribute from ‘Configured’ to ‘Unconfigured’, using the building block MCCF.

Administering the backup mediumThe building block administers the backup medium; it allocates or releases the backup medium storage space for the configuration data. The areas on the backup medium are administered in an efficient manner, so that superfluous data build-ups are avoided, thus reducing the waiting time at the beginning of the next dump.



2

Common servicesCommon services building blocks are used by the building blocks of the area ‘Configuration and supervision’. These building blocks are responsible for monitoring the software and for providing and converting the various data structures.

The functions of the common services are implemented via a procedural interface and do not communicate with other tasks.

Definition of termsThe common services are used for the communication between the MAF tasks. They also provide conversion routines for internal and external data structures. The common services implement general tasks that are jointly used by all MAF tasks.

Common services building blocksFigure 2-31 shows the common services building blocks MSVM (MCU supervisory module), XXMH (message handling), XXPH (process handling), MCCR (MCU conversion routines) and XXXX (general building block).

Figure 2-31Building blocks of the common services 2-31

In order to fulfil their functions, these building blocks are available to other MAF tasks that call up the functions of the corresponding building block (Figure 2-32):

XXMH MCCR

XXXX

Common services

XXPH

MSVM



Figure 2-32Context of the common services 2-32

Building block MSVMThe MCU supervisory module provides services that are used to monitor the MCU application software using the processor system hardware watchdog. MSVM controls the triggering of watchdog activation.

Building block XXMHThis building block converts the messages from the internal data structure to the external data structure and vice versa.

Building block MCCRThis building block contains conversion routines for the conversion of the attribute format to the internal attribute format in accordance with ASN.1 (Abstract Syntax Notation) and vice versa. These routines are used by the MCCM task only.

Building block XXXXThe building block contains

• Initialisation routines

• Wrapper functions for the extended operating system XOS, for central error handling and debug functions

• Conversion routines for various data structures. 0

Building block XXPHThis building block contains global type definitions for process handling.

End of chapter file

MAF tasks

Other MAF areas

MCU

XXXX


XXMH XXPHMCCR

Common services

MSVM


3-1

3
Chapter 3: Application software of the peripheral units
IntroductionThe peripheral unit (PU) software consists of the infrastructure software part used by the PU (see Chapter 4 ‘Infrastructure’) and the application software for the respective PU.

The application software of the PU consists of the ‘hardware control’ and ‘hardware access’ areas. Large parts of the first PU software area are common in all PUs; these parts are described on page 3-3, ‘General hardware control’.

‘Specific hardware control’ page 3-21 subsequently explains the special features and the specific functions of the application software of the individual PUs.

The ‘hardware access’ function area with the hardware-specific drivers of the individual units is described on page 3-42, ‘Hardware access’.

Figure 3-1 displays an example of the structure of the PU software. The individual building blocks of the PU software are displayed in detail in Chapter 5 ‘MCU/PU software configuration’.


3-2 Application software of the peripheral units

Figure 3-1Structure of the PU software 3-1

TIU-1 application software

Hardware access

Gen. PU-ASIC driver

TIU-1 ASIC driver

TIU-1 HW driver

PPU-1 application software

Hardware access

Gen. PU-ASIC driver

PPU-1 ASIC driver

PPU-1 HW driver

...(corresponding software configurations for TIU-3,

TIU-4, SIU-1/4 andCMU-1)

The corresponding displays are contained in

detail in Chapter 5.

Infrastructure

PU Data Handling

Hardware control

PU Protection

PU Alarm Handling

PU Data Handling

Hardware control

PU Protection

PU Alarm Handling


Application software of the peripheral units 3-3

3

General hardware controlFunctions and Processes of the PU software

The functionality of a peripheral unit depends on its specific hardware and on the implemented software features. In addition to the specific software functions, there are a number of general PU software tasks which belong to the ‘hardware control’ function area. These function areas are divided into the following building blocks and are used by all peripheral units (see Figure 3-2):

• PU data handling

• PU alarm handling

• PU protection.0

Figure 3-2Hardware control of the PU software 3-2

These building blocks jointly implement the following fundamental tasks of the peripheral units:

• Configuration of the PU hardware and the software processes in accordance with the commands which the PU receives from the MCU

• Calculation and preparation of measurement data provided by the PU and required by the MCU

• Notification of supervisory alarms provided by the PU which can be requested by the MCU management and communication unit

• Monitoring the proper function of the PU hardware and the notification of errors detected in the MCU

• Self-control of the processor hardware and the processor software. This includes the handling of exceptions and the transmission of signals to the

PU application software

Hardware access

PU Data Handling

Hardware control

PU Protection

PU Alarm Handling



PU control unit to ensure a defined state of the PU and data consistency at all times.

0

These functions are described on page 3-5, ‘The PU object model’ in the context of the individual building blocks.

The following 3-1 lists the individual processes of the ‘hardware control’ area, their functions and the building blocks in which they are implemented. This facilitates the understanding of relationships of MCU and PU application software processes as described in FASC. AM.

Note: Important alarm handling functions are also located in the ‘PU ASIC driver’ building block. This building block contains its own process for alarm detection.

The communication between MCU and PU is accomplished via message exchange which is handled by the communication process of the ‘MCU PU Message Service’ building block.

PU data handlingMain functions The ‘PU data handling’ building block supports the ‘PU state management’ and ‘PU maintenance’ areas. This building block

• Guarantees the stable state of the peripheral unit after it was booted (this depends on the previous state). The PU state is activated in accordance with the received message (switching on the power switch, cold start or warm start).

• Provides the communication controller (CC) with the information from the received slot number

• Initiates the transfer of a message to the MCU after the peripheral unit was booted

• Sends a notification when the recovery procedure has been concluded

• Offers the hardware and software for the management functions of the ‘hardware controller module’ PU object

Table 3-1Processes of the hardware control 3-1

Process Function Building Block

PUAD PU administration PU Data Handling

PUEQ PU equipment supervision and maintenance

PU Data Handling

PUFA PU fault and alarm Handling PU Alarm Handling (Note)

PUPA Supervision of termination points and generation of protection alarms

PU Protection



3

• Triggers corresponding actions if a PU state transition is performed

• Provides access to an application that handles the various PU states. This application performs the various actions that are dependent on the state transition

• Periodically checks if the MCU can be reached

• Controls its own used storage area

• Handles LOC (loss of communication)

• Ensures that the watchdog supervisory functions which check software operation, e.g. for endless loops, are triggered regularly.

0

Furthermore this building block contains the following functions:

• Updating the ASIC driver object database

• Searching the ASIC driver database

• Checking if the object instance and its attributes are present

• Acknowledging messages after commands have been executed or after the ASIC driver object database has been updated. This depends on the state of the PU.

• Triggering the PU ASIC driver and the communication alarm handling to report data-base changes.

• Controlling the behaviour of the PU ASIC driver, alarm handling and the PU protection, according to PU state transitions.

0

The PU object modelAn important task of the PU software is to enable the MCU to use the various characteristics of the different peripheral units uniformly on a abstract, logical level.

The functions and data of the peripheral units are displayed as a number of instances of different object classes to provide a uniform view of the PU functions.

The object model first describes the concepts, the general object characteristics and object relationships.

The functions of the ‘UnitController’ object class representing the unit controller module (on any PU) are then described in page 3-12, ‘‘Unitcontroller’ object class’. Special functions and particular features of objects in the individual units are described in page 3-21, ‘Specific hardware control’.

PU object classesThe functions of a peripheral unit can be seen from a logical viewpoint as groups of different function parts which form the resources of a PU. A PU resource can be a part of a special hardware component that performs specific



transmission-related functions or a part of the software that provides certain services.

PU objects are logical representatives of particular PU resources. Each individual PU resource is represented in the PU object model by a corresponding PU instance (Figure 3-3).

Figure 3-3PU object-resource relationship 3-3

Each object instance is a member of an object class. A PU object class comprises all object instances with the same characteristics, i.e. instances of the same object class identify PU resources with the same functions.

The specified PU object classes are defined on the basis of the function blocks which are suggested in the ITU-T recommendations applicable to SDH for the hardware requirements of the respective PU, refer to the ‘Functions of the Network Elements’ chapter of the document TN-4X System Description 323-1121-100.

Functional parts are combined when object classes are defined in order to keep the overall number of the various object classes as low as possible. This leads to a uniform management view of different PUs; the behaviour and services are therefore not dependent on a particular type of unit. These are defined by the object class.

Differences between the peripheral unit types are represented by the particular number of different object classes and by special relationships between the object instances.

Object class:1Instance: 1

HW resources

Object class:2Instance: 1

Object class:nInstance: 1

Object class:1Instance: n

Resource:1Instance: 1

Resource:nInstance: 1

Resource:1Instance: 1

Resource:1Instance: n

Object model

SW resources



3

An object class displays the characteristics and data of its corresponding object resource using various attributes that can be addressed by a management system.

PU object attributesObject attributes represent the data of an object instance. Each instance of a particular object class contains this number of attributes.

Three different types are distinguished depending on the purpose of the attributes:

• Configuration data attributes

Configuration attributes contain the configuration information which influences the functions of the object resource and specifies particular management behaviour. These can be hardware-related functions or services implemented by the software in accordance with the relevant resource of the object instance.

• Application data attributes

Application attributes contain calculated data or measurement data, e.g. the laser temperature which can be retrieved by the management system.

• Alarm data attributes

Alarm attributes contain the alarm state resulting from the supervision functions. The attributes can indicate transmission errors (e.g. LOS) or equipment errors (e.g. ASIC parity errors).

0

PU object stateAll object instances of a peripheral unit have common characteristics that are independent of a particular object class. These characteristics and the behaviour of PU objects resulting from these characteristics are described by means of an object state model.

The object state model defines the main characteristics of an object. This applies to administration carried out by the management system, consistency between the content of object configuration attributes and the actual configuration of the corresponding object resource as well as the actual availability of the object resource.

The object state comprises the following sub-states in accordance with these three aspects:

• Administrative state

• Consolidation state

• Operational state.0



Administrative stateThe administrative state defines the management characteristics of a PU object class instance. The administrative state can have three values:

(1) Undefined This is the initial state. An object class instance which is in this state cannot be managed. The object attributes are not accessible and no spontaneous notifications are sent from this instance to the management system.

(2) DefinedAn object class instance which is in this state can be managed and the object attributes are accessible. All value changes made to configuration data are stored but do not influence the configuration of the corresponding object resource and therefore have no affect on the hardware. The content of the application attributes and alarm attributes is invalid. The spontaneous notifications sent to the management system are still disabled.

(3) ActiveAn object class instance which is in this state can be managed. The attributes of the object instance are accessible. All value changes of configuration attributes are saved and are consolidated with the configuration of the corresponding object resource. The content of the application data and alarm attributes is valid. Spontaneous notifications can be sent to the management system.

The administrative state can be specified by an managing unit (unit controller module) or can be changed automatically if PU error exceptions should occur.

Consolidation stateThe consolidation state reflects the consistency between the contents of the configuration attributes of an object instance and its corresponding resource configuration. This state may take two values:

(1) SeveredThere is no consistency between the configuration attributes and the configuration of the corresponding object resource.

(2) ConsolidatedThere is consistency between the configuration attributes and the configuration of the corresponding object resource.

The managing unit cannot directly request changes to the consolidation state. State changes are performed autonomously according to the actual requirements.



3

Operational stateThe operational state reflects the ability of an object instance to perform its function and provide services. This state may take two values:

(1) OperationalThe corresponding resource of an object instance is available and provides its services in accordance with the current configuration. The validity of the contents of the application data and alarm attributes depends on the administrative state.

(2) UnavailableThe corresponding resource of an object instance is not available and cannot provide any services. The validity of the contents of the application data and alarm attributes depends on the administrative state.

The managing unit cannot directly request changes to the operational state. State changes are performed autonomously according to the actual requirements.

Object state diagramThe combination of the three sub-states described above forms the object state. All possible combinations are displayed in Figure 3-4. The operational states are displayed as a grey grid, the consolidation states are displayed as white fields and the administrative states are marked with double lines.



Figure 3-4PU object state diagram 3-4

Transition eventsState transitions are triggered by ‘transition events’. Certain actions are executed by the respective object instance during a state transition. The following sections describe all transition events and the executed actions.

The transition events are divided into two classes. The first class only affects one particular object instance and second class affects all object instances of a peripheral unit. The latter is always a result of changes in the global PU state (see page 3-12, ‘PU state management’).

The notation [administration state – consolidation state – operational state] is used in the following sections to represent the object state. The digits in brackets refer to the state transitions defined in Figure 3-4.

Instance-specific transition eventsAn instance-specific transition event only affects one object instance.

Setting an object class to ‘Defined’ (3)A particular object class is defined by the management system with a special define message that sets its administrative state to ‘defined’. A define message is only evaluated by the peripheral unit if the PU state is Recovery or Operational. The resulting object state can be either [defined – severed –

Operational

DefinedUndefined

Severed

Undefined

Active

Consolidated

Severed

Unavailable

Undefined

1: Power on

2: Recoverable error exception

3: Setting an object class to ‘defined’(only possible if PU state is set to operational, recovery)

4: Setting an object class to ‘undefined’

5: PU state changes to ‘recovery’

6: PU state changes to ‘operational’

7: PU state changes to ‘error’

1 6

43

52

4, 53

7

65

Transition events:



3

operational] or [active – consolidated – operational] depending on the current consolidation state.

Setting an object class to ‘Undefined’ (4)The administrative state of an object class instance can be set to ‘undefined’ by the management system with a special undefine message. The resulting object state can be either [undefined – severed – operational] or [undefined – consolidated – operational] depending on the current consolidation state.

Transition events that affect all object instancesChanges to the PU state affect the object state of each object class instance of a PU. Possible reasons for PU state changes are described in detail in page 3-12, ‘PU state management’. PU state changes can generally be triggered by the management system or can occur if PU error conditions arise.

Power on (1)The PU software performs a cold start after the power switch has been actuated. The entire PU hardware and all of the software variables in volatile memory are initialised with default values during a cold start. Following these actions, all object instances are in the [undefined – consolidated – operational] object state.

Recoverable error exceptions (2)Processing errors in the PU software lead to recoverable error exceptions. The PU software performs a warm start in this case. During a warm start of the peripheral unit, the configuration attributes of all object instances are initialised with predefined default values. However, the current configuration of the corresponding object resources (hardware resources only) is retained. Following these actions, all object instances are in the [undefined – severed – operational] object state.

PU state changes to ‘Recovery’ (5)The configuration attributes of all object instances are initialised with default values if a PU state is changed to ‘recovery’; however, the current configuration of the corresponding object resources (hardware resources only) is retained. Following these actions, the administrative state is set to ‘undefined’ for all object instances. The resulting object state of all object instances is [undefined – severed – operational].

PU state changes to ‘Operational’ (6)The contents of the configuration data attributes of all object instances are consolidated with the configuration of their corresponding object resources if a PU state is changed to ‘operational’. All object instances with a ‘defined’ administrative state are set to ‘active’. The resulting object states of all object instances are [active – consolidated – operational] or [undefined – consolidated – operational].



PU state changes to ‘Error’ (7)The PU hardware is set to the ‘Power on’ default configuration (as is the case after the power switch is actuated) by a special reset signal if the PU state is changed to ‘error’. The unit controller module remains in the reset state. All interrupts are disabled. The peripheral unit is isolated from the system to the largest possible degree in the ‘error’ PU state. The resulting object states for all object instances are [undefined – consolidated – unavailable].

‘Unitcontroller’ object classThe ‘UnitController’ object class represents the functionality of the unit controller module of a PU. The unit controller module of a PU executes the PU software, controls the configuration of the hardware and monitors all of the PU functions.

This includes tasks such as PU state management, provision of the electronic type label and the indication of processing errors.

In contrast to all other object classes, exactly one object instance is always available and can be triggered without a preceding definition command. The setting of configuration attributes directly affects the corresponding object functions. All applications are continuously evaluated and are valid. This object class contains no alarm attributes, as only processing errors are reported.

PU state managementThe PU state is represented by a corresponding application attribute (PUStateActual) of the ‘UnitController’ object. This attribute always contains the current PU state. In addition, a further configuration attribute (PUStateRequested) enables the MCU to request a PU state.

Changes in the PU state affect the behaviour of all other object instances as described in the chapter ‘PU Object State’ (page 3-7, ‘PU object state’).

Communication with the MCU is also affected, i.e. the various communication classes of the peripheral unit can be enabled or disabled according to the current PU state.

PU statesThe PU states are associated with the general behaviour of all PU object class instances.

• RecoveryThe PU state ‘recovery’ allows the configuration of the peripheral unit without influencing the current behaviour of the object. All communication classes that are required for the configuration are enabled.

• OperationalThis is the normal operation mode of a peripheral unit. All communication classes are enabled.

• DisabledIn this PU state the PU is deactivated as far as possible. The object state



3

for all instances is ‘undefined’. No communication is possible except for communication class ‘Maintenance Data’; no object instances can be defined.

• ErrorThe peripheral unit is isolated to the highest possible degree in this state. The PU hardware is initialised with default values by means of a special reset signal. The unit controller module remains in reset state. All interrupts are disabled, preventing communication with the MCU. This status can only be cancelled by power on or hardware reset.

0

The effect on other object instances is described on page 3-7, ‘PU object state’ under the heading ‘Transition Events which Affect all Object Instances’.

PU state diagramFigure 3-5 displays the PU states and state transitions that are available:

Figure 3-5State diagram of the peripheral units 3-5

In addition to its effect on object states, the PU state determines the communication behaviour of a peripheral unit. This communication behaviour is described by means of communication classes. Each

Recoverable error exceptions

Error

Operational

Recovery

Power on reset Hard error exceptions

2 1 8

4,5

4,5

6

6

Transition events:

1: Power on reset/

2: Recoverable error exceptions (previous PU state =| Disabled)

4: Loss of Communication with the MCU disappears

5: Setting the PU state to “recovery”

6: Setting the PU state to “operational”

7: Set PU state to Disabled

Disabled7

8: Error (hard error exception)

7

5

7

3: Recoverable error exceptions (previous PU state = Disabled)

3



communication class is a specific, logical channel to the management system. These channels transmit particular types of messages. There is always one master within a communication class which is the initiator of a particular message transmission. A communication class can be either enabled or disabled.

The message is transmitted if a communication class whose peripheral unit is the master is enabled. The messages are output to the object instances if a communication class whose peripheral unit is only the recipient is enabled.

All pending send or receive messages are discarded if a communication class is disabled. In addition, message transmissions are no longer initiated and messages are no longer output to the object instances.

The transition events are described in more detail below. The digits in brackets refer to the state transitions defined in Figure 3-5.

Power on reset (1)The PU software performs a cold start sequence after power on. The entire PU hardware and all of the software variables in volatile memory are initialised with default values during a cold start. The PU maintenance and PU processing error communication classes are activated. A processing error message is transmitted.

Recoverable error exception (2, 3)The occurrence of processing errors in the PU software leads to recoverable error exceptions. The PU maintenance and PU processing error communication classes are activated.

‘Loss of communication’ with the MCU disappeared (4)This state change is performed if ‘Loss of communication’ with the MCU has disappeared. The PU maintenance and PU processing error communication classes are activated.

Setting the PU state to ‘Recovery’ (5)This state change is performed by the management system. The PU maintenance and PU processing error communication classes are enabled.

Setting the PU state to ‘Operational’ (6)This state change is performed with a ‘set action’ of the management system. All communication classes are activated.

Setting the PU state to ‘Disabled’ (7)This state change is performed with a ‘set action’ of the management system. All communication classes except for the class PU Maintenance are disabled.

PU State is changed to ‘Error’ (8)The PU hardware is set to the ‘power on’ default configuration by a special reset signal if the PU state is changed to ‘error’. The unit controller module



3

remains in the reset state. All interrupts are disabled. The peripheral unit is maximally isolated from the system in the ‘error’ PU state.

Handling of Processing errorsThe ‘UnitController’ object instance is responsible for the handling of processing errors.

Processing errors are runtime errors in the PU software. Processing errors are inherently recoverable error exceptions that affect the actual operation of the software in such a way that the normal function of the PU can be achieved again by special recovery actions performed by the network management system.

Typical examples are all ‘recoverable error exceptions’ that were caused by:

• Power on

• Watchdog

• Division by zero

• Hardware exception (e.g. access to invalid memory areas)

• Program parts calling the exception handler (e.g. attribute value is incorrect or required memory is not available).

0

Errors of this class are recovered by performing a warm start (see building block ‘FBoot’, page 4-14, ‘Basic infrastructure’). Processing errors are reported with a corresponding PU notification after the unit controller module has been reset (warm start).

PU Alarm HandlingMain functionsThe ‘PU alarm handling’ building block performs the following functions:

• Filtering of alarms which are signalled by the PU ASIC driver and evaluated regularly

• Execution of alarm masking in accordance with a specified rule

• Signalling of the remaining alarms after filtering and masking at the MCU

• Execution of attribute change messages which are directly (i.e. without filtering or masking) sent from the peripheral unit to the MCU

• Alarm supervision for the intended use of the protection switching

• Control of the red LED (note on equipment alarms)

• Control of the yellow LED (note on transmission alarms)

• Control of the green LED (note on manual protection switching)

• Handling of transmission and equipment errors.



Alarm monitoringAlarm monitoring consists of the alarm filtering and alarm masking mechanisms. Both mechanisms are executed for each alarm type. The alarm type is handled as an alarm attribute of an object instance.

The alarm filtering mechanism was introduced to reduce the rate of alarm state changes in case of intermittent failure behaviour. A special filter constant which defines the sensitivity of the filter exists for each alarm type.

The alarm masking mechanism suppresses all alarm state change notifications of subordinate alarm levels (alarm messages which occur as a logical consequence of a superordinate alarm) if a high-priority alarm occurs. This reduces the number of messages for an alarm state change. The alarm-level hierarchy is defined in a masking tree. The masking tree for each PU is described on page 3-21, ‘Specific hardware control’.

Figure 3-6 provides an overview of the alarm monitoring function with the input and output data for a single alarm attribute.

Figure 3-6Alarm supervision 3-6

The following criteria are used for alarm monitoring:

• Administrative state (undefined, defined, active)

The administrative state of the object instance to which the calculated alarm attribute belongs.

• Alarm monitoring (ON, OFF)

Each object instance which contains alarm attributes comprises an ‘alarm monitoring’ configuration attribute. This attribute enables the generation of alarm state change notifications to be activated and deactivated for all alarm attributes of the object instance.

AlarmMasking

AlarmFiltering

notified Alarm state

Alarm state changenotifications

Current alarm state(from ASIC driver1) Filter counter

Administrative state

Alarm monitoring

Masking state

Filtered alarm state

1) see page 3-45, section ‘Alarm detection’



3

• Masking state (ON, OFF)

This indicates whether the current, filtered alarm state of a superordinate alarm is present (ON) or not (OFF). Superordinate alarm states can be members of the same object instance and/or of a different object class instance.

• Current alarm state (‘cleared’ or ‘present’)

The current alarm state is requested at equidistant intervals of n*100 ms and provides information about the current error state of a particular monitored part.

0

The output value of the alarm monitoring function is the alarm state that is saved in an alarm attribute. An alarm state change notification is generated as soon as the alarm state changes.

Alarm filteringThe alarm filtering function calculates the filtered alarm state according to the following procedure:

The filtered alarm state is immediately set to ‘present’ if the current alarm state changes from ‘cleared’ to ‘present’. The filtered alarm state is only reset to ‘cleared’ if the current alarm state remained cleared for at least N (N = filter constant) successive calculation periods. A new filter period is started if the alarm state changed to ‘present’ within this period of time.

Alarm maskingThe functionality of the alarm masking mechanism for a single alarm can be displayed as an event-driven state machine with the alarm attribute as a state memory and with a state transition diagram (Figure 3-7).

Figure 3-7Alarm masking state transition diagram

3-7

Administrative state = active

Cleared Present

Cleared

State transition events:

The transitions 3, 4, 5, 6 are only performed if the alarm monitoring mechanism is activated.

1 2 2

5,6

3,4

1: Administrative state changes to “active”

3: Filtered alarm state changes to “present” and masking state is OFF

4: Masking state changes to OFF and filtered alarm state changes to “present”

5: Filtered alarm state changes to “cleared”

6: Masking state changes to ON

2: Administrative state changes to “undefined” or “defined”

Administrative state =| Active



If the administrative state value is not ‘active’, the content of an alarm attribute is ‘cleared’. The alarm monitoring mechanism is initiated in the ‘cleared’ state after the administrative state has changed to ‘active’.

Alarm state change notifications to the MCU are initiated during each state transition from ‘cleared’ to ‘present’ and vice versa.

Alarm state change notifications between ‘cleared’ and ‘present’ are only enabled if the alarm monitoring attribute of the corresponding object instance is set to ‘ON’. If the alarm monitoring attribute is set to ‘OFF’, alarms already notified as ‘present’ are now notified as ‘cleared’.

The masking of subordinate alarm states is performed regardless of the alarm monitoring attribute of the superordinate object class. Alarms in defined or active object instances suppress subordinate alarms, even if the ‘Alarm Monitoring’ configuration data attribute is set to ‘OFF’.

The filter time constants are set for each alarm according to the following rule in the ‘PU alarm handling’ building block prior to compilation:

Filter time of the superordinate alarm < Filter time of the subordinate alarm

Pending superordinate alarms suppress subordinate alarms. The alarms of the object instances which have a higher priority are illustrated for each peripheral unit in a function tree in page 3-21, ‘Specific hardware control’. Examples of possible alarms in the masking trees are displayed in Table 3-2.

Table 3-2Possible alarms 3-2

Alarm Meaning

AIS Alarm indication signal

BufferOverflow Buffer overflow with corresponding object

FEBE Far end block error

FERF Far end receive failure

LossOfClock Loss of clock

LOF Loss of frame

LOM Loss of multiframe

LOP Loss of pointer

LOS Loss of signal

MAIS Multiplex alarm indication signal

—continued—



3
Fault handlingOne of the main functions of the peripheral unit software is the handling of errors. A distinction is made between three classes of errors:
• Transmission error

• Equipment error

• Processing error.0

PU alarm handling treats transmission and equipment errors. Processing errors are handled by PU data handling (see page 3-15, ‘Handling of Processing errors’).

Transmission errorTransmission errors are related to errors in the transmission signals that are processed by the peripheral unit. The monitoring of transmission signals and the alarming during error conditions is part of the normal operation functionality of each peripheral unit.

Transmission errors always occur outside of the PU which detects these errors and do not indicate a malfunction in the PU itself. These errors therefore do not affect the functionality of the PU and do not have any influence on the state of the PU. A transmission error can, nevertheless, indicate an equipment error in another PU connected in series in the transmission path. The network management system, which possesses knowledge about the network element topology, generally decides if this is the case.

Each transmission error is represented as a corresponding alarm attribute of an object instance. An alarm attribute contains the alarm state which can be either ‘cleared’ or ‘present’. The management system is notified of all changes in the alarm state, depending on the object configuration.

Equipment errorEquipment alarm states are related to hardware failures in the network element (NE). A PU can detect equipment errors, which can be localised on the PU, as well as equipment errors which are found outside the PU that detects these errors. Three types of equipment errors are distinguished:

• Hard errors

PAIS Path alarm indication signal

SD Signal degrade

SL Signal label mismatch

—end—

Table 3-2Possible alarms (continued) 3-2

Alarm Meaning



Hard errors are static errors of the detecting PU which make the continuation of work impossible. Typical examples include:

— CRC (cyclic redundancy check) errors in program memory (ROM or flash EPROM)

— Static RAM failure.

The PU is transferred to error state and the PU is isolated from the system to the highest possible degree if errors of this type occur. Errors of this type are indirectly reported to the MCU as a result of a loss of communication.

• Restricting errors

Restricting errors are errors of the detecting PU which partly restrict the functionality but which do not affect the management capability of the PU. A typical example is an ASIC parity error.

• Environment errors

Environment errors are errors which are localised outside of the PU that detects these errors. Typical examples include:

• Clock failure

• Missing connection interface.0

The last two types of equipment errors are represented as alarm attributes in dedicated object instances. An alarm attribute contains the alarm state which is either ‘cleared’ or ‘present’. The management system is notified of all changes in the alarm state, depending on the object configuration.

PU protection The ‘PU protection’ building block is responsible for the generation of protection switching alarm messages. A protection switching alarm is signalled if the following four conditions have been fulfilled:

(1) The alarm is classified as a protection switching alarm and changes to ‘present’ state

(2) Alarm monitoring is activated for the object instance

(3) Protection switching monitoring is activated for the object instance

(4) Protection alarm notifications are permissible on the PU.



3

Specific hardware control This section describes the specific functions and object classes of the peripheral units as well as any existing special object features and special processes.

TIU-1Functional descriptionThe TIU-1 tributary interface unit multiplexes and demultiplexes twenty-one plesiochronous 2 Mbit/s signals into one synchronous STM-1 signal of the SDH and vice versa.

Figure 3-8Multiplexing and demultiplexing the TIU-1 3-8

Object classesThe available objects of the TIU-1 are described in Figure 3-9 and listed in Table 3-3.

Figure 3-9Supported objects of the TIU-1 3-9

Note: The direction (‘transmit direction’ and ‘receive direction’) is based on an external point of view. It assumes that a peripheral unit receives signals at the input port and transmits signals at the output port. Signals

AUG AU-4 VC-4

TU-12 TUG-2 TUG-3

STM-1

VC-12C-1221 signalsPlesiochronous2 Mbit/s

Backplane

1

2

2

AU4CTP VC12TTP P12CTP PDH2CTP

InputBus

16 21

Sou

rce

21

Sou

rce

21

Sin

k

21

Sin

k

PPITTPTU12CTP

63

Sin

k

1

Sin

k

UnitEquipment

1

UnitController

1

21

16 21

Sin

k

21

Sin

k

21

Sou

rce

21

Sou

rce


OutputBus

PPITTP

21

Sou

rce

TU12CTP

1

Sou

rce

TimingSource

ProtectionOutputBus

ProtectionInputBus

Transmission direction

Connection

Max. number of object instances



are forwarded within the peripheral unit and assigned a path overhead, or the path overhead is retrieved from the signal. The network backplane is the backplane transceiver logic.

Table 3-3Description of the TIU-1 objects 3-3

Object Resource

AU4CTPSink AU-4 connection termination point in transmit direction (MSA, HPOM), multiplex section adaptation, higher-order path overhead monitoring

AU4CTPSource AU-4 connection termination point in receive direction (MSA, HUG), multiplex section adaptation

TU12CTPSink TU-12 connection termination point in transmit direction (HPA, LCS), higher-order section adaptation, monitoring of the VC-12 for parity or bit errors

TU12CTPSource TU-12 connection termination point in receive direction (HPA, LUG), higher-order section adaptation, monitoring without payload signal

VC12TTPSink VC-12 trail termination point in transmit direction (LPT), lower-order path termination

VC12TTPSource VC-12 trail termination point in receive direction (LPT), lower-order path termination

P12CTPSink P-12 connection termination point in transmit direction (LPA), lower-order path adaptation

P12CTPSource P-12 connection termination point in receive direction (LPA), lower-order path adaptation

PDH2CTPSink PDH-2 connection termination point of the plesiochronous monitoring function in receive direction

PDH2CTPSource PDH-2 connection termination point of the plesiochronous monitoring function in transmit direction

PPITTPSink PDH trail termination point in receive direction, plesiochronous input port

PPITTPSource PDH trail termination point in transmit direction, plesiochronous output port

TimingSource Timing source quality monitoring, timing marker monitoring and clock recovery

InputBus Bus signal from the backplane which has the capacity of an STM-1

—continued—



3

The function blocks MSA, HPOM, HUG, HPA, LCS, LUG, LPT and LPA mentioned in the table correspond to the G.783 ITU-T recommendations that apply to SDH and are described in detail in the ‘Functions of the Network Elements’ chapter of the document TN-4X System Description 323-1121-100.

Special features of objects• Bus objects

The STMBus mode is valid for all bus objects. The TIU-1 peripheral unit occupies a third of an STM-1 signal. Three TIU-1 signals can therefore be assigned to one complete STM-1 signal with the CMU-1.

• TU12CTP

A maximum of 21 object instances can be created in receive direction. 63 object instances are available in transmit direction.

• TimingSource

All 21 instances can be defined at the same time but only one instance is enabled. No port is selected for the external clock output port (the external clock output port is only selected for SIU-1/4 and TIU-4).

0

Alarm filter and alarm maskingThe general behaviour of the alarm filtering mechanism is described on page 3-16, ‘Alarm monitoring’. Pending superordinate alarms suppress subordinate alarms. The priority of the object instances and their respective alarms is displayed in Figure 3-10.

ProtectionInputBus Protection bus signal from the backplane which has the capacity of an STM-1

OutputBus Bus signal to the backplane which has the capacity of an STM-1

ProtectionOutputBus Protection bus signal to the backplane which has the capacity of an STM-1

UnitEquipment Transmission hardware which is provided on the peripheral unit

UnitController Unit controller module

—end—

Table 3-3Description of the TIU-1 objects (continued) 3-3

Object Resource



Figure 3-10TIU-1 alarm masking 3-10

The diagram contains examples of possible alarm messages. An LOP alarm (loss of pointer) for the TU12CTP-Sink object suppresses, for example, the SL alarm (Signal Label Mismatch) of the VC12TTPSink object (transmit direction, left-hand path).

Special processesA special process is used to monitor the switch under the 7-segment LED display (additional key for the test output port of the TCI-1 connection interface). The monitored port can be selected with the key. The two 7-segment displays show the port number that is currently selected and monitored.

TIU-3Functional descriptionThe TIU-3 tributary interface unit multiplexes and demultiplexes 6 plesiochronous 34 Mbit/s signals into two synchronous STM-1 signals of the SDH and vice versa. Each STM-1 frame can contain three plesiochronous tributaries with 34 Mbit/s.

The peripheral unit implements the multiplex or demultiplex path of the SDH structure as illustrated in Figure 3-11.

Transmit direction Receive direction

UnitEquipment

InputBus

AU4CTP Sink

TU12CTP Sink

VC12TTP Sink

P12CTP Sink

UnitEquipment

PPITTP Sink

P12CTP Source

LossOfClock

LOF

LOP

LOP

SL

Buffer overflow

LossOfClock

LOS

Buffer overflow

Possible alarms

Possible alarms



3

Figure 3-11Multiplex and demultiplex path of the TIU-3 with AU-4 3-11

Object classesThe available TIU-3 objects are illustrated in Figure 3-12 and listed in Table 3-4.

Figure 3-12Supported objects of the TIU-3 3-12

AUG AU-4 VC-4

VC-3 TU-3 TUG-3

STM-1

C-36 signalsPlesiochronous34 Mbit/s

Backplane

6

Sou

rce


6

Sou

rce

6

Sou

rce

6

Sin

k

6

Sin

k

PPITTPTU3CTP

6

Sin

k

2

Sin

k

UnitEquipment

1

UnitController

1

6

Sin

k

6

Sin

k

6

Sou

rce

AU4CTP VC3TTP P3CTP PDH34CTP PPITTP

6

Sou

rce

TU3CTP

2

Sou

rce

2

InputBus

16

ProtectionInputBus

2

16

OutputBus

ProtectionOutputBus

1


Connection





Object Resource

AU4CTPSink AU-4 connection termination point in transmit direction (MSA, HPOM), multiplex section adaptation

AU4CTPSource AU-4 connection termination point in receive direction (MSA, HUG), multiplex section adaptation

TU3CTPSink TU-3 connection termination point in transmit direction (HPA, LPOM), higher-order section adaptation, low-order path monitoring

TU3CTPSource TU-3 connection termination point in receive direction (HPA, LUG), higher-order section adaptation, path monitoring without payload signal

VC3TTPSink VC-3 trail termination point in transmit direction (LPT), lower-order path termination

VC3TTPSource VC-3 trail termination point in receive direction (LPT), lower-order path termination

P3CTPSink P-3 connection termination point in transmit direction (LPA), lower-order path adaptation

P3CTPSource P-3 connection termination point in receive direction (LPA), lower-order path adaptation



PPITTPSink PDH trail termination point in receive direction, plesiochronous input port

PPITTPSource PDH trail termination point in transmit direction, plesiochronous output port





UnitEquipment Transmission hardware available on the peripheral unit

—continued—



3
Special features of objects• InputBus
The STMBus mode is valid for all bus objects.

The selection of the available subbuses for the two STM-1 signals is restricted with regard to the software:

— STM-1 number 1: Subbus 0,1,2,3 or subbus 8,9,10,11

— STM-1 number 2: Subbus 4,5,6,7 or subbus 12,13,14,15.

This is only an internal restriction, as the user does not use the subbus but rather assigns the bus capacities.

• OutputBus

as for the InputBus class

• VC3TTP

The structured attribute of the VC3TTPSink instance is always deactivated, as the hardware only supports 34 Mbit/s mode.

0

Alarm filter and alarm maskingThe general behaviour of the alarm filtering mechanism is described on page 3-16, ‘Alarm monitoring’. Pending superordinate alarms suppress subordinate alarms. The priority of the object instances and their respective alarms is displayed in Figure 3-13.


—end—


Object Resource



Figure 3-13TIU-3 alarm masking 3-13

Special processesA special process is used to monitor the switch under the 7-segment LED display (additional key for the test output port of the TCI-3 connection interface). The monitored port can be selected with the key. The 7-segment display shows the port number that is currently selected and monitored.

TIU-4Functional descriptionThe TIU-4 tributary interface unit implements the electrical STM-1 or 140 Mbit/s interface of the network element. It receives four electrical SDH/PDH signals and retrieves four electrical STM-1 signals from the backplane in order to transfer the four SDH/PDH signals.

Each port of a TIU-4 can be operated in STM-1 mode (SDH) or in 140 Mbit/s mode (PDH).

Object classesThe available TIU-4 objects are illustrated in Figure 3-14 (SDH) or Figure 3-15 (PDH) and are listed in Table 3-5.

Transmit direction Receive direction

UnitEquipment

InputBus

AU4CTP Sink

TU3CTP Sink

VC3TTP Sink

P3CTP Sink

UnitEquipment

PPITTP Sink

PDH34CTP Sink

P3CTP Source

LossOfClock

BusLOF

LOP

LOP

SL

Buffer overflow

LossOfClock

LOS

LOF

BufferOverflow

Possible alarms

Possible alarms



3

Figure 3-14TIU-4 objects in SDH mode 3-14

Figure 3-15TIU-4 objects in PDH mode 3-15

2

2

ElectricalSPITTP MSTTPRSTTP AU4CTP [VC4TTP]

4

4

4

Sin

k

ElectricalSPITTP RSTTP AU4CTP [VC4TTP]

4

Sin

k

4

Sou

rce

4

Sou

rce

4

Sin

k

4

Sin

k

4

Sin

k

4S

ourc

e4

Sou

rce

4

Sou

rce

UnitEquipment

1

UnitController

1

4

TimingSourceQutputBus

ProtectionOutputBus

InputBus

Protection InputBus

1


Connection


MSTTP

2

2

AU4CTP VC4TTP P4CTP PDH140CT

4 4

Sou

rce

4

Sou

rce

4

Sin

k

4

Sin

k

4

Sin

k

PPITTP

4 4

Sin

k

4

Sin

k

4

Sou

rce

4

Sou

rce

4

Sou

rce

AU4CTP VC4TTP P4CTP PDH140CT PPITTP

UnitEquipment

1

UnitController

1

Protection InputBus

ProtectionOutputBus

OutputBus

InputBus

1


Connection





Object Resource

ElectricalSPITTPSink

SDH physical interface trail termination point in receive direction, SDH input port

Electrical SPITTPSource

SDH physical interface trail termination point, SDH output port

RSTTPSink Trail termination point of the regenerator section in receive direction (RST)

RSTTPSource Trail termination point of the regenerator section in transmit direction (RST)

MSTTPSink Trail termination point of the multiplex section in receive direction (MST)

MSTTPSource Trail termination point of the multiplex section in transmit direction (MST)

AU4CTPSink AU-4 connection termination point in receive direction (MSA, HPOM), multiplex section adaptation, higher-order path overhead monitoring

AU4CTPSource AU-4 connection termination point in transmit direction (MSA, HUG), multiplex section adaptation path overhead monitoring without payload signal

VC4TTPSink VC-4 trail termination point in receive direction (LPT), higher-order path termination

VC4TTPSource VC-4 trail termination point in transmit direction (HPT), higher-order path termination

P4CTPSink P-4 connection termination point in transmit direction (HPA), higher-order section adaptation

P4CTPSource P-4 connection termination point in receive direction (HPA), higher-order section adaptation



PPITTPSink PDH-2 trail termination point in receive direction, plesiochronous input port

PPITTPSource PDH-2 trail termination point in transmit direction, plesiochronous output port

—continued—



3

Special features of objects• VC4TTP – AU4CTP

Monitoring by means of the AU4CTP (HPOM) or alternatively the insertion/removal of the J1 byte (PathTrace) and of the C2 byte (SignalLabels) is useful. The object automatically takes over the monitoring process if VC4TTP is defined.

The J1 byte is used to monitor the path connection. The C2 byte provides information about the composition of the VCn payload.

• ProtectionOutputBus

Protection bus 1 protects subbuses 0 to 7 and protection bus 2 protects subbuses 8 to 15.

• InputBus

One bus per STM-1 can be defined:

— STM-1 number 1: subbus 0,1,2,3










Communication Controller

Communication controller


—end—


Object Resource



• OutputBus

as for the InputBus object0

• 140 Mbit/s mode or 155 Mbit/s mode

If a port is operating in 140 Mbit/s mode on the TIU-4, no objects of 155 Mbit/s mode are defined for this port and vice versa.

P4CTP, PDHCTP and PPITTP are the objects which are only used for 140 Mbit/s mode.

The TimingSource, MSTTP, RSTTP and ElectricalSPITTP objects are only used for the 155 Mbit/s mode.

0

• TimingSource

All four instances can be defined but only one is enabled.0

Alarm filtering and alarm maskingThe general behaviour of the alarm filtering mechanism is described in page 3-16, ‘Alarm monitoring’. Pending superordinate alarms suppress subordinate alarms. The priority of the object instances and their respective alarms is illustrated in Figure 3-16 (SDH mode) and Figure 3-17.

Figure 3-16TIU-4 alarm masking in SDH mode 3-16

Receive direction Transmit direction

UnitEquipment

Electrical SPITTP Sink

RSTTP Sink

MSTTP Sink

AU4CTP Sink

VC4TTP Sink

UnitEquipment

InputBus

LossOfClock

LOF

AIS

LOP

LOM

LossOfClock

BusLOF

Possible alarms

Possible alarms

LOS



3

Figure 3-17TIU-4 alarm masking in PDH mode 3-17

SIU-1/4Functional descriptionThe SIU-1 and SIU-4 synchronous interface units are peripheral units which implement an optical interface of the network element respectively. They convert an optical signal to an electrical signal and vice versa. The following variants can be differentiated with regard to the transmission rates:

• SIU-1, which receives an optical STM-1 signal and transmits it as an electrical STM-1 signal to the backplane and also retrieves an electrical STM-1 signal from the backplane and transmits it as an optical STM-1 signal

• SIU-4, which receives an optical STM-4 signal and transmits it as four electrical STM-1 signals to the backplane and also retrieves four electrical STM-1 signals from the backplane and transmits them as optical STM-4 signals.

0

The behaviour of the two interface units, SIU-1 and SIU-4, is identical. They are therefore described together as the SIU-1/4 unit.

Object classesThe available SIU-1 object classes are illustrated in Figure 3-18, and the object classes of an SUI -4 are displayed in Figure 3-19. The object classes are listed in Table 3-6.

Receive direction

UnitEquipment

PPITTP Sink

PDH140CTP Sink

LossOfClock

BusLOF

LOP

SL

Buffer overflow

LossOfClock

LOS

LOF

Possible alarms

Possible alarms

Transmit direction

UnitEquipment

InputBus

AU4CTP Sink

VC4TTP Sink

P4CTP Sink



Figure 3-18SIU-1 objects 3-18

OpticalSPITTP

1

Sin

k

1

Sin

k

1

Sin

k

1

Sin

k

MSTTPRSTTP AU4CTP

1

Sin

k

[VC4TTP]

OutputBus

1

Sou

rce

1

Sou

rce

1

Sou

rce

1

Sou

rce

1S

ourc

e

OpticalSPITTP MSTTPRSTTP AU4CTP [VC4TTP]

InputBus

TimingSource

1

ClockSource

1

UnitEquipment

1


1

UnitController

1

ProtectionOutputBus

2

16

2

16

ProtectionInputBus

1


ConnectionMax. number of object instances



3

Figure 3-19SIU-4 objects 3-19

Table 3-6Description of the SIU-1/4 objects 3-6

Object Resource

Optical SPITTPSink

SDH physical interface trail termination point in receive direction, optical signal input port

Optical SPITTPSource

SDH physical interface trail termination point in transmit direction, optical signal output port

RSTTPSink Trail termination point of the regenerator section in receive direction (RST)

RSTTPSource Trail termination point of the regenerator section in transmit direction (RST)

MSTTPSink Trail termination point of the multiplex section in receive direction (MST)

—continued—

OpticalSPITTP

1

Sin

k

1

Sin

k

1

Sin

k

MSTTPRSTTP AU4CTP [VC4TTP]

OutputBus

1

Sou

rce

1

Sou

rce

1S

ourc

e

4

Sin

k

OpticalSPITTP MSTTPRSTTP AU4CTP [VC4TTP]

InputBus

4

Sin

k

4

Sou

rce

4

Sou

rce

ClockSource

1

UnitEquipment

1


1

UnitController

1

TimingSource

1

ProtectionOutputBus

ProtectionInputBus

2

16

2

16

1


Connection




MSTTPSource Trail termination point of the multiplex section in transmit direction (MST)

AU4CTPSink AU-4 connection termination point in receive direction (MSA, HPOM), multiplex section adaptation, higher-order path overhead monitoring

AU4CTPSource AU-4 connection termination point in transmit direction (MSA, HUG), multiplex section adaptation, path monitoring without a payload signal

VC4TTPSink VC-4 trail termination point in receive direction (HPT), higher-order path termination

VC4TTPSource VC-4 trail termination point in transmit direction (HPT), higher-order path termination


ClockSource Central clock source







Communication controller


—end—

Table 3-6Description of the SIU-1/4 objects (continued) 3-6

Object Resource



3

Object features• VC4TTP – AU4CTP

Monitoring by means of the AU4CTP (HPOM) or alternatively the insertion/removal of the J1 byte (PathTrace) and of the C2 byte (SignalLabels) is useful. The object automatically takes over the monitoring process if VC4TTP is defined.

The J1 byte is used to monitor the path connection. The C2 byte provides information about the composition of the VCn payload.

• ClockSource

The instance for the clock generator is available if the SIU-1 or SIU-4 is equipped with the CCU-X3 piggy-back board.

0

Alarm filter and alarm maskingThe general behaviour of the alarm filtering mechanism is described on page 3-16, ‘Alarm monitoring’. Pending superordinate alarms suppress subordinate alarms. The priority of the object instances and their respective alarms is illustrated in Figure 3-20.

Figure 3-20SIU 1/4 alarm masking 3-20

Receive direction

UnitEquipment

Optical SPITTP Sink

RSTTP Sink

MSTTP Sink

AU4CTP Sink

*VC4TTP Sink * Object class is optional

LossOfClock

Transmit direction

UnitEquipment

InputBus

LossOfClock

LOF

AIS

BusLOF

Possible alarms

Possible alarms

LOS

LOP

LOM



CMU-1Functional descriptionThe special aspects of the application software of the CMU-1 connection matrix unit are described in this section.

The connection matrix unit is used to switch the connections in the network element. The connection matrix unit can generate up to 16 STM-1 output signals from 16 STM-1 input signals.

Object ClassesThe available CMU object classes are illustrated in Figure 3-21 and listed in Table 3-7.

Figure 3-21CMU-1 object classes 3-21

Table 3-7Description of the CMU-1 objects 3-7

Object Resource





SwitchMatrix Functionality of the switching matrix with complete connectivity for an STM-1



OutputBus

ProtectionOutputBus

SwitchMatrix

InputBus

ProtectionInputBus

UnitEquipment UnitController

1616

2

1

2

16

1



3

Alarm filter and alarm maskingThe behaviour of the alarm filter is described in the general section. Pending superordinate alarms suppress subordinate alarms. The alarms of the object instances that have a higher priority are illustrated in Figure 3-22.

Figure 3-22CMU-1 alarm masking 3-22

PPU-1Functional descriptionThe special aspects of the application software of the PPU-1 pointer processing unit are described in this section.

The pointer processing unit generates the pointers for AU-4, TU-3 and TU-12. A PPU processes four STM-1 signals of the same value. It reads the data from the ADD bus and transmits it to the SYNC bus. The main data bus, which consists of the ADD bus, the DROP bus and the SYNC bus, is dealt with in detail in the TN-4X system description 323-1121-100.

Object classesThe available PPU-1 object classes are illustrated in Figure 3-23 (Sink) and Figure 3-24 (Source) and are listed in Table 3-8.

UnitEquipment

InputBus ProtectionInputBus

Bus LOF

LossOfClock

Bus LOF

Possible alarms



Figure 3-23PPU-1(4) objects (sink) 3-23

Figure 3-24PPU-1(4) objects (source) 3-24

VC4TTP

TU3CTP

AU4CTP

4

Sin

k

252

Sin

k

4

Sin

k

12

Sin

k

TU12CTP

UnitEquipment

1

UnitController

1

4

InputBus

ProtectionInputbus

2

1


Connection


VC4TTP

TU3CTP

AU4CTP

4 4

Sou

rce

252

Sou

rce

4

Sou

rce

12S

ourc

e

TU12CTP

OutputBus

ProtectionOutputbus

2



3

Table 3-8Description of the PPU-1(4) objects 3-8

Object Resource

AU4CTPSink AU-4 connection termination point (MSA, HPOM), multiplex section adaptation, higher-order path overhead monitoring

AU4CTPSource AU-4 connection termination point (MSA, HUG), multiplex section adaptation, path monitoring without a payload signal

VC4TTPSink VC-4 trail termination point (HPT), higher-order path termination

VC4TTPSource VC-4 trail termination point (HPT), higher-order path termination

TU3CTPSink TU-3 connection termination point (HPA, LPOM or LCS), higher-order section adaptation, lower-order path monitoring

TU3CTPSource TU-3 connection termination point direction (HPA, LUG), higher-order section adaptation, path monitoring without a user signal

TU12CTPSink TU-12 connection termination point (HPA, LCS), higher-order section adaptation, monitoring of the VC-12 for parity or bit errors

TU12CTPSource TU-12 connection termination point (HPA, LUG), higher-order section adaptation, path monitoring without a user signal









Alarm filter and alarm maskingThe general behaviour of the alarm filtering mechanism is described on page 3-16, ‘Alarm monitoring’. Pending superordinate alarms suppress subordinate alarms. The priority of the object instances and their respective alarms is illustrated in Figure 3-25.

Figure 3-25PPU-1 alarm masking 3-25

Hardware accessThe ‘hardware access’ function area facilitates access to the unit-specific hardware building blocks used by the PUs for transmission. These building blocks are usually implemented as ASICs (application specific integrated circuits). This hardware access is necessary for the following functions:

• Initialisation of the hardware with default values during a warm start

• Setting the hardware in accordance with external configuration commands

• Recording measurement data, e.g. the laser temperature

• Alarm detection by regularly polling the alarm register

• Control of the hardware for the CCU-X3 clock generator and the avalanche photodiode (APD) of the SIUs.

0

Alarm filtering and alarm masking is executed in the ‘PU alarm handling’ function block of the hardware control.

UnitEquipmentLossOfClock

InputBus

AU4CTP Sink

VC4TTP Sink

TU12CTP Sink TU3CTP Sink

BusLOF

LOP

LOM

LOP LOP

Possible alarms

ProtectionInputBus BusLOF



3

General structure and functionThis section describes the structural and functional aspects of the ‘hardware access’ function area which are identical in all PUs. The description in this section (page 3-43, ‘General structure and function’) refers to all peripheral units. However, some deviations apply to the synchronous interface units and are described on page 3-47, ‘Hardware access of the synchronous interface units’.

StructureThe ‘hardware access’ function area is implemented by ‘drivers’ (see Figure 3-26):

• The general PU-ASIC driver is used on each PU and contains the basic functions common to all peripheral units.

• Each PU additionally contains a unit-specific ASIC driver which performs the specific driver functions for the respective PU on a logical level.

• Each PU contains a unit-specific hardware driver for immediate access to the hardware register. This hardware driver carries out the unit-specific ASIC driver requests.

0

Figure 3-26Driver building blocks of the peripheral units 3-26

The general PU ASIC driver contains:

• The process frame which regularly calls up the unit-specific ASIC driver

• Basic functions for the object classes that are not located on the special ASIC driver

• Globally used functions.00

General PU-ASIC driver

Unit-specific hardware driver

Unit-specific ASIC driver

ASIC



The unit-specific ASIC driver comprises

• The object database

• Exported functions for access to the object database

• Internal functions for alarm detection

• Internal functions for recording application data

• Unit-specific functions.0

The unit-specific hardware driver contains

• The memory structure of the ASIC register

• Complex hardware access functions.0

Object databaseCommunication between the ASIC drivers and the PU applications is achieved by means of the object database. The object database is structured in the same way on all peripheral units. The object database of a peripheral unit contains the relevant object instances.

The object classes represent the actual functionality of the plug-in units and correspond to the function blocks as described in the G.783 ITU-T recommendations valid for the SDH.

The unit-specific ASIC driver indicates the object data in the object database by means of a pointer. If there are several instances of the object, these instances are also stored in the object database. The return value of the access routine is the NULL pointer if the instance of an object class is not in the object database.

No objects are created or deleted. All available instances are assigned their default values after the initialisation routines have been initiated.

An object class contains the following information:

• Management data: object classes and object states

• Configuration data

• Alarm data

• Application data0

The driver uses the object state to determine if the configuration data is valid and if it is to be transferred to the ASICs.

The stored configuration data in the object database becomes valid if an object reaches the ‘defined’ state, i.e. after the set-up call in the transmission hardware. When an object is defined, alarm monitoring for this object is started accordingly.



3

Special routines are initiated for access to the object database. These routines indicate the appropriate data structure by means of a pointer. Access is controlled by means of enable and disable functions to prevent conflicts with other processes that also access this data.

Driver functionsASIC set-upThe driver initiates a separate set-up routine for each object class. This routine is defined in the object database in accordance with the configuration data. This action is performed if the object class changes to ‘operational’ state or the object class is in ‘operational’ state and the configuration data changes.

Application dataThe recording of application data is an independent process that handles measurement data. The process calls up a function within a defined time interval (1 second is the standard interval) which calculates the current value of the measurement data and enters it in the object database. The application can then retrieve this value asynchronously.

Alarm detectionAlarm detection is an independent process. The process polls the hardware register for alarm states within a defined time interval (the time intervals for the recording of the application data and alarms are set prior to the compilation of the data and alarms) by means of an access procedure. It subsequently initiates a separate procedure for each alarm which processes the alarm data structure.

Each alarm has an alarm data structure containing the following information:

• The current alarm state is the unfiltered state (‘cleared’ or ‘present’) since the last recording.

• The ‘alarm state change’ flag indicates whether the alarm has changed from ‘cleared’ to ‘present’ or vice versa since the last time interval. This enables briefly occurring alarms to be easily reported to the ‘PU alarm handling’ building block.

• The driver sets the ‘application flag’ during the initialisation phase of the object database or when an object changes to the ‘undefined’ state.

0

The object data base informs the PU alarm handling mechanism of changed alarm. This building block is responsible for the alarm filtering and alarm handling mechanisms. The principle of filtering and masking is described in page 3-16, ‘Alarm monitoring’.

Figure 3-27 illustrates the ASIC set-up, alarm detection and error recognition driver functions described above.



Figure 3-27Driver functions 3-27

Fault detectionEach unit-specific ASIC driver checks the plausibility of the function parameters and the values in the object database (e.g. consistency of the set-up data, observance of the data value range). All data is therefore checked before it is written to the ASIC register.

Alarm register

ASIC #1

ASIC #n

PU alarm handling

Hardware control

Unit-specific ASIC driver and hardware driver

Routine for updating the alarm data

Routine for polling alarm states

Alarm polling

Call-up procedure

Data access

Administrative data

Configuration data

Application data

Alarm data

ASIC driver object database

Function Process

for the application

Recording of

application data

Alarm detection

Alarm polling

General PU-ASIC driver

Set-up functions

Routine for calculating the current value



3

Hardware access of the synchronous interface unitsDue to their functional complexity, the SIUs contain, in addition to the driver building blocks provided on all peripheral units, separate ASIC drivers for laser control and for timer operations as well as for the control of the APD photodiode and the CCU-X3 clock generator on the PU.

The optical SIU-1/4 and the electrical SIU-1el are not differentiated at this point. The SIU with optical interface and additional components for laser operation is described below.

Figure 3-28Driver building blocks of the synchronous interface units 3-28

The driver building blocks of the ‘hardware access’ function area of the SIUs have the following function:

The general PU ASIC driver has the functions described on page 3-43, ‘General structure and function’.

The ‘SIU ASIC driver (SIPU)’ building block contains:

• The object database

• Exported functions for access to the object database

• Internal functions for alarm detection

• Internal functions for recording the application data

• Internal functions for recording the measurement data.0

TIU-3ASIC driver

TIU-4ASIC driver

Hardware access of SIUs

SILA SIHW

SIPU SITI

CCUX3HW CCUCtrl

Gen. PU ASIC driver ADC

APDCtrl



The ‘SIHW’ building block contains:

• The memory structure of the ASIC register

• Complex hardware access functions.0

The ‘SILA’ building block is used to control the laser (e.g. signal transmission and laser temperature).

The ‘SITI’ building block controls and monitors time-related operations.

The ‘hardware access’ area of the SIUs contains the following building blocks in addition to the drivers:

• The ‘CCUControl’ building block represents the CCU-X3 clock generator on the SIU-1/4 that is not dependent on the hardware. CCUX3HW is the relevant hardware driver for the clock generator.

• The ‘APD control’ building block represents the software control of the d.c. supply for the optical receiver photodiode in the SIU-4.

• The ‘ADC’ building block represents an analogue-digital converter (ADC).

0End of chapter file


4-1

4

Chapter 4: Infrastructure

IntroductionThe infrastructure software constitutes the lowest level of the software system. The software level is responsible for the operating system functions as well as for the communication between the plug-in units. All plug-in units, i.e. Management and Communication Unit (MCU) and peripheral units (PU), always use the same infrastructure software in order to ensure that the software system interworks at this level. Therefore, the infrastructure level can also be viewed as a distributed operating system for the entire network element.

The functions of the infrastructure are a result of the interworking among the individual building blocks. The description of functions take all building blocks into consideration in order to clearly indicate the correlations. Further details about the structure of the infrastructure software and the classification of individual building blocks can be found in Chapter 5 ‘MCU/PU software configuration’.

The infrastructure software is divided into system services and communication services according to the main functions (see Figure 4-1).

Figure 4-1Infrastructure software 4-1

The function of system services is to provide the network element software to all operating system functions as well as some other central administrative functions, such as the administration of system time. In addition, the system services take over internal communication as well as decentralised functions

Infrastructure

System services Communication services


unit 1


unit n

Application software of the management and communication unit

. . .


4-2 Infrastructure

that are used in all plug-in units in the same way, such as memory management.

Communication services comprise the Message Communication Function (MCF) and Software Download. The MCF manages both of the interfaces that the network element uses to communicate with external partners:

• The Q interface enables a computer to be connected which can be used as a local or regional network management computer. A local computer is also referred to as craft terminal.

• The QECC interface is used to couple the network element to its nearest neighbour via several overhead bytes from the STM transmission signal. The actual telecommunications management network (TMN) originates from this coupling. This connection is physically embedded in the optical transmission signal; logically, however, it is unrelated and viewed as a separate connection (QECC).

0

The MCF provides the application software with all of the functions required to communicate with the network management system, with the other network elements or with the local craft terminal. Internal communication, in other words, the exchange of data between the plug-in units and the processor within a network element, is not the responsibility of the communication services, but rather of the system services.

Software Download, i.e. all the functions for loading the NE software from an external PC, possibly via the network (‘Remote Software Download’ via QECC), is also realised within the communication services.

System services The application functions are implemented by a system of processes that communicate with each other and otherwise generally work completely on their own. These processes are managed within the system services; each process uses the resources of the executing processor. As far as the processes are concerned, it is irrelevant in which processor they run. They can generally belong to any processor of any plug-in unit, as long as they are not directly dependent on the special hardware of a plug-in unit. In general, a process naturally runs on the processor (on the plug-in unit) on which it can work most efficiently, particularly with regard to the computer capacity and the configuration of the system.

All processes have a message queue at their disposal which they use for their internal communication. It consists of a buffer in which the messages are stored in the order of arrival and then read and processed by the process one after the other (see page 4-10, ‘Process management’, page 4-11, ‘Process addresses’ and page 4-11, ‘Message transmission’). Every queue has an address with which it can be reached from the outside. This address is the only possible way to access a process. A queue is always linked to a process, i.e. messages can only be read out by the accompanying process. Therefore, from now on a process and its queue will often be viewed as one unit.


Infrastructure 4-3

4

Structure of the system servicesThe following Figure 4-2 indicates the basic structure of the system services. The main functions of the system services are detected by the operating system; in addition, there are other function areas as follows:

• Basic infrastructure

• Message services

• Data block handler

• Local address services

• Hardware driver

• Other building blocks.0

These areas are described in the following chapters.

Figure 4-2Basic structure of the system services 4-2

Operating systemThis function area consists of the following building blocks (see Figure 4-3):

Figure 4-3Operating system 4-3

System services

Hardware drivers

Message Local Other

services address services

Data

block

handler

Operating system building

blocks

Basicinfra-

structure

Operating system

XOS

SIGBusL2

pSOSPREPC


4-4 Infrastructure

The commercial operating system kernel pSOS is used as the basis and supplies the basic system calls. This pSOS can be found in all plug-in units, as the TN-4X network element software is distributed among several plug-in units and consequently among several processors.

On the other hand, the application software considers the entire system to be interrelated. The fact that the hardware is composed of different plug-in units is generally irrelevant for the purely functional level of the application software (it is involved both in changing configurations and in the initialisation). Therefore, there is another layer between the operating system level pSOS and the application services XOS (extended operating system) which hides the distribution of the system from the higher levels and takes over all communicative services within the processes.

The PREPC building block contains the pSOS runtime library; it supports some standard operations, including the manipulation of character strings.

The driver for the SIG bus layer 2 (SIGBusL2) supports communication between the plug-in units of a network element using the SIG bus (see page 4-7, ‘Communication paths’,). It contains the sub-layers LLC (Logical Link Control) and MAC (Media Access Control) from layer 2 of the OSI stack (see page 4-31, ‘The data link layer (Layer 2)’).

The XOS has three fundamental functions according to the system structure:

(1) Restricting pSOS system call selection:Some of the system calls normally offered by the pSOS are not required in the NE software. Therefore, they are no longer transferred to the XOS to allow the program structure to remain as clear as possible and guarantee certain system principles.

(2) Expanding the functionality of some system calls:Some system calls are insufficient in the form in which they are offered by the pSOS. The functionality of these calls is expanded in the XOS. This consequently relieves the load on the higher level program parts.

(3) Detachment of pSOS from superordinate layers:The replacement of the pSOS may become necessary at a later date (portability). In order to avoid a subsequent adaptation of the software, the XOS has a sort of buffer function: all system calls, regardless of their ability to reach the pSOS directly, run using the XOS and can be adapted to another operating system kernel if required.

Task of the pSOSpSOS is a product of Software Components Group, Inc. It consists of a real-time operating system kernel with multitasking capabilities. Its main task is to provide different basic services via system calls. These basic services are:

• Memory management

• Process management


Infrastructure 4-5

4

• Message queues (communication primitives)

• Semaphores (synchronisation primitives)

• Time services

• Interrupt services.0

Tasks of the XOSWhile the pSOS handles process control in each processor, the XOS has the task of managing and coordinating the different processors with their respective independent pSOS. It has several functional blocks at its disposal (see Figure 4-4) with the following tasks:

Global services are services which cover all processes of a network element and must consequently be managed globally. This entails the IPC (Inter-Process Communication), in other words, communication between processes; seen from the outside, it is in this case irrelevant whether two processes that communicate with each other run on the same processor or on different processors.

Local services are services which are called up by a process and individually managed for a specific process. A local service has no information pertaining to other processes and is therefore unable to communicate with them. Local services are:

• Timer management: A corresponding message is sent using the timer functions to the initiating process after a specified period of time;

• Memory management, which is responsible for the allocation of memory areas to the processes (see page 4-8, ‘Memory management’);

• The Critical Section Guard (CSG): This function is explained in page 4-14, ‘Critical section guard (CSG)’.

0

The Application Programmers Interface (API) supplies almost all system calls to the application. This transition between the system services and the rest of the software is explained in detail in page 4-7, ‘Interfaces to the operating system’.

The node management ensures communication between the processes on different processors. It decides, for instance, if transmission is performed using the SIG bus or one of the two memory areas jointly used by the processors (shared memory).

It uses the blocks SIG bus transmission and shared memory transmission which manage and control the SIG bus and the shared memory areas respectively (see page 4-7, ‘Communication paths’).

The XOS is intentionally designed in a way that not all pSOS functions are available to the higher levels. Due to this restriction, the functionality of the system services remains clear and largely independent of the pSOS. Services that are not required are not offered. However, the services offered by the


4-6 Infrastructure

XOS are often an expansion of the services offered by the pSOS in order that the functions from the higher-level program parts can be relocated in the XOS, thus relieving the higher-level program parts. This also provides a better overview of the software structure.

In addition, the initialisation phase and other special cases require functions whose structure is highly dependent on the pSOS. This also includes the generation and deletion of processes. These functions are summarised in the block Kernel Adaptation Layer (KAL) and are not related to the pSOS.

Thus, the pSOS can be directly accessed in such a way that the form of the system calls does not depend on the type of kernel being used. In addition, the affected functions of the XOS can be informed about such actions.

Access to the KAL (and consequently to the pSOS) must be accurately synchronised with the system structure so that the reliability of the entire system is not impaired and the clarity of the software structure is not reduced. The KAL is therefore only accessed when the required function can be reached exclusively via this path (this also applies for accesses via the pAPI, see page 4-7, ‘Interfaces to the operating system’).

Figure 4-4XOS structure and interface 4-4

SIG bus transmission

Shared memory transmission

Node management

Application programmers interface (API)

Kernel adaptation layer (KAL)

pSOS

Local services Global services

Memory management

CSG

Timer administration

IPCTime management

CAPI +PAPIKAI

XOS


Infrastructure 4-7

4

Interfaces to the operating systemCommunication between the application services and the operating system is accomplished via the application programmers interface (API). There are three different ways to access the system services:

Most system calls occur via the Common API (CAPI), because this path offers all XOS and pSOS functions required by the application processes.

Some processes require functions that are either difficult to reach or cannot be reached at all via the CAPI, e.g. the critical section guard (see page 4-14, ‘Critical section guard (CSG)’). These functions are triggered via the Privileged API (PAPI).

The Kernel Adaptation Interface (KAI) can also be used in exceptional cases. It accesses the pSOS (via the KAL) almost directly (see page 4-5, ‘Tasks of the XOS’). This type of access can be used, for example, to create or delete processes during the initialisation phase.

Communication pathsThe system services are also responsible for communication between the processes in different processors.

The processors can normally communicate with each other via two different paths:

Communication between plug-in units is accomplished via the SIG bus, while communication between two processors takes place using the shared memory mechanism. In the latter case, the sending process writes data in a memory area which is also used by another processor, allowing the information to move from one process to another.

The management of the SIG bus and the shared memory is the responsibility of node management and the transmission blocks in the XOS, whereas the driver used for this purpose is implemented in the transmission blocks ‘shared memory transmission’ and ‘SIG bus transmission’ (see Figure 4-5).

Figure 4-5Communication paths in the system services 4-5

Single-processor plug-in unit SIG bus Shared

memory

Multi-processor plug-in unit

pSOS pSOS pSOS


4-8 Infrastructure

Operating system functionsMemory managementThe memory of a network element is divided among the various plug-in units and there is no central memory. Each process can only access the memory which is controlled by its processor. This memory is always on the plug-in unit where the process is also present. A process can also only see the memory assigned to it.

To a certain extent, the structure of the memory is set up similarly on all plug-in units. The distribution capability of the memory is irrelevant for the application, because every process is allocated its own memory area, each of which is managed locally.

The part of a unit’s main memory (RAM) described as free memory is divided into a static area and a dynamic area according to its tasks.

The statically allocated memory area (allocate once pool) consists of blocks of variable length that can only be assigned once during the delay time (normally during the initialisation phase), after which they can no longer be released. This memory is used, among other things, for the storage of data that is required during the entire operation, for instance, configuration data.

The dynamic memory area is managed in the form of buffer pools. These are memory areas which allow the memory to be divided into two hierarchical levels:

• Each memory pool divides itself in one or more block pools; the number of block pools is specified by the configuration data (though they can be modified).

• Each block pool consists of a number of blocks of the same size; the quantity of blocks as well as their size are also specified by the corresponding configuration data.

0

Figure 4-6Division of the memory 4-6

The data on size and quantity of blocks and the quantity of block pools determines the size of a buffer pool; this data is summarised under the term size characteristics.

Allocate once pool Buffer pools

Block pools Blocks


Infrastructure 4-9

4

The division of the memory in fixed blocks leads to internal fragmentation, i.e. the allocated memory area is almost always slightly larger than the required memory area; the extra storage space cannot be used. In order to use the memory in the most effective manner, the values of the memory size characteristics are adapted to the expected memory requests.

The quantity and structuring of the buffer pools is the responsibility of the application and can be performed differently on the various plug-in units (more precisely: in the management area of the various processors).

A typical example is the division into two buffer pools:

• The transient buffer pool for short-life data (such as message queues) and

• the long-term buffer pool for long-life data, which is nevertheless occasionally deleted.

0

Other buffer pools can be set up if a plug-in unit uses software packets which require permanently allocated pools for special applications. These pools are assigned their own memory pool.

All buffer pools are configured during the initialisation of the network element. The application cannot influence the configuration during operation. The kernel application interface (KAI, see page 4-7, ‘Interfaces to the operating system’) is used for this configuration.

Most plug-in units have other memory building blocks at their disposal in addition to the RAM. However, with the exception of the ‘global RAM’, they are neither used nor managed by the operating system but rather addressed directly from the application.

The ‘global RAM’ is used for the shared memory.

System time managementIn order to guarantee the synchronisation of all processes on the various plug-in units, the system time is managed centrally in the XOS according to the following procedure:

• Each processor maintains its own system time.

• Whenever a process intends to poll the system time, it commissions the XOS which supplies the system time.

0


4-10 Infrastructure

TimerThe operating system also enables timer functions to be used. These functions are managed locally in the XOS and called up via the CAPI. Local management means that a timer always belongs to its calling process and only sends information to this same process upon expiry of the time. The transmitted signal is a message which is supplied to the timer via the system call.

There are four different types of timer functions:

• Expiration timers correspond to short-time alarm bells: The signal is transmitted when the specified period of time expires.

• Periodic timers are expiration timers that repeatedly activate themselves automatically and transmit their signals periodically; this procedure can preset a sort of clock pulse.

• Anchored timers correspond to the reminder alarm: a signal is transmitted at a certain time.

• Anchored periodic timers are a combination of the two previously mentioned types: a periodic timer is started by a call; however, the timer does not orient its phase on the starting time but rather a time that must be specified. For instance, if an anchored periodic timer starts at 10.00 AM with a period of 20 minutes and an anchor time 11.15 AM, it sends its signal at 10.15 AM, 10.35 AM, 10.55 AM, 11.15 AM, 11.35 AM, etc.

0

The XOS sends a message (see above) to the process after the specified time expires or is reached. The timer messages have priority over all other messages, i.e they are put in the first position of the queue and read by the process before all other messages. If a process contains several successive timer messages, the messages are arranged in chronological order.

Timers can be stopped by the calling process before the preset time expires. However, a timer cannot continue to operate after it has been stopped, as the timer is deleted immediately after stopping (a timer is a special data structure and not a process; it is created according to requirements and deleted again as soon as it is no longer needed). As a consequence, the timer message is also lost.

Periodic timers do not expire, they only finish their work if they are stopped by a calling process.

Process management All processes required for the operation of a network element are created during the initialisation phase of the software. Neither the generation nor the deletion of a process is necessary during operation (with the exception of reconfiguration). Thus, all necessary resources are also guaranteed.

A process will be blocked if it currently has no work. It waits until it receives data with which it can work via its queue. Once it has accomplished its task, it returns to the blocked state (message loop).


Infrastructure 4-11

4

Every process can be found on a processor in the pSOS. Therefore, process management occurs individually in every processor. The pSOS facilitates multitasking mode. Several processes are operated simultaneously; however, only one of them is always active. The process is controlled by means of priority classes; the process with the highest priority class is always active, unless it has been suspended. A process is suspended

• if it activates an XOS system call which currently cannot be carried out (for instance, because of missing data). In this case, the system is blocked until the system call is available or, if applicable, until a process with higher priority level is activated.

• if a process with higher priority is activated. This can occur if the current process is interrupted by an interrupt-routine, or if the current process itself activates a process with higher priority.

0

A process can be interrupted preemptively if another process with a higher priority or a previously blocked or suspended process can operate again as a result of its activities and also uses the processor. It is also possible to interrupt the currently active process via interrupt service routines (ISR) (see page 4-13, ‘Interrupt services’).

Process addressesThe address of a process – more precisely the address of its message queue – consists of two parts: the domain address and the local address. This is due to the fact that a network element can contain several identical plug-in units, for instance, when using various synchronous interface units (SIU) or in order to increase reliability (internal protection). These plug-in units also use identical processes, and therefore, the local process address is no longer sufficient for identification. The plug-in unit is also specified by the domain address; allowing the process to be explicitly addressed.

The definition of domains as well as the specification of domain addresses are performed by the application during the initialisation of a plug-in unit. A domain does not necessarily have to be identical with a plug-in unit, but can also contain subdomains of a plug-in unit. The decisive factor in this case is that the processes are clearly allocated by means of the domain definition.

Message transmissionThe XOS provides a data block of four times four bytes for the transmission of each message. This is the position a message can take in a message queue. The structure of a data block is identical for all messages (see Figure 4-7). It consists of transmission control data and information data:

The transmission control data contains information on the transmitter, the receiver as well as some information on the message (such as message type). The information data contains the information to be transmitted; it represents the user data container.


4-12 Infrastructure

There are three different types of messages, depending on how the user data container is used (see Figure 4-7):

• With regard to scalar messages, the container itself comprises the information to be transmitted. This space is sufficient for general state messages or for the timer messages, for instance.

• With regard to vector messages, the container comprises an address of the memory; this address contains the beginning of a vector data structure, where there is a data block. This data block contains, among other things, the address of another datablock, which in turn refers to another block, and so forth. These data blocks contain the addresses of each next block as well as the useful information that is to be transmitted.

• In general messages, the container also refers to an address in the memory. However, this entails a complex data structure. In other words, the data blocks no longer refer exclusively to another block, but rather to several data blocks; thus, entire data records (keeping their structure, for instance a tree structure) can be transmitted.

0

This type of message can only be exchanged between processes of the same processor (see below). If possible, this type of message is not used, as it leads to a dependence of the processes on individual processors, which should be avoided according to the system concept.

Figure 4-7Structure of a message 4-7

Transmission is carried out according to the following principle: The sender arranges a message according to one of the three mentioned patterns and sends it to the target queue. The receiver reads the message and is also responsible for making the storage space available again.

Receiver InformationSender

Contents of the information block in

- Scalar messages: Data

- Vector messages: Address of a data block

- General messages: Address of the beginning of a data structure

Message data


Infrastructure 4-13

4

The sender does not receive an acknowledgment. If a message does not reach its target, the XOS ensures that the necessary storage space is made available again.

If the message is directed to a process of another processor, all information must be sent to another processor (via SIG bus or via Shared Memory) where it is then forwarded. This also applies to the data block in the memory of vector messages, because the processors can only access their own memory (see page 4-8, ‘Memory management’). Therefore, it is also impossible to transmit general messages between two processors: the data structure cannot be changed to a portable code, because the system services are normally not informed about the structure itself.

The entire administration of the message exchange is the responsibility of the IPC (inter process communication) and node management. In this case, for instance, it is determined whether the SIG bus is required and, if applicable, how the data will be sent via the SIG bus. The information is placed in the memory with the assistance of the memory management.

A message can have various destinations:

• A message can be sent directly to a process by specifying the global process address, i.e. the domain and local address, as the destination.

• If a message should only be sent within the management area of a processor (local cast), the local address is sufficient. This simplifies the procedure, particularly in the initialisation phase.

• In addition, a message can be sent simultaneously to several different processes (broadcasting).

0

Interrupt servicesThe purpose of interrupt services is to notify processors of events which require a priority handling. This refers primarily to signals which arrive at the processor from other hardware units (particularly from input and output units).

An interrupt service can cause the interruption of a current process and the activation or preparation of another process as a reaction to the interrupt signal. Interrupt services are carried out by the Interrupt Service Routines (ISR).

The interrupt service routines are performed immediately and occupy the processor during execution. They are intended for certain applications in which an interrupt signal requires an immediate reaction or the necessary task only demands the processor for a short time. An ISR will always activate a normal process for longer tasks.

The interrupt service is suspended again once it has fulfilled its task. The previously active process is subsequently continued or a process of higher priority is activated.


4-14 Infrastructure

Critical section guard (CSG)A data area that can be read and written by several processes, is a critical area. The problem with these constructs is that several processes access them simultaneously without being aware of each other, thus leading to critical situations. This can be compared to a large street intersection, where accidents are inevitable if the traffic is not regulated.

These critical areas are only used in Shared Application Libraries (SAL) of the application in form of data application modules.

The system services offer a supervising function for these critical areas whose function is similar to that of a semaphore: A critical area can only be reached via an access point and left via an exit. As soon as a process runs through the access point, this point is blocked for the following processes. However, if the accessing process demands access to the critical area, e.g. as a result of a recurrence, it will be granted. Every other process will only receive access to the critical area after the accessing process leaves the area again through the exit.

Basic infrastructureThe functional area ‘basic infrastructure’ comprises building blocks required during the initialisation and recovery of a network element.

Initialisation and recovery are carried out in the same way for all processors, i.e. MCU, Main Controller (MC) and Communication Controller (CC) of the PU.

The basic infrastructure consists of three building blocks (see Figure 4-8):

Figure 4-8Basic infrastructure 4-8

• FBoot: boot process (warm start) for the initialisation of the processors (MCU, MC, CC)

• Exception handler: this building block handles hardware and software exceptions

• The basic infrastructure library (BLIB) is a library with basic functions for the basic infrastructure software

0

Basic infrastructure

FBoot

Exception handler

BLIB


Infrastructure 4-15

4

Functions of the basic infrastructure softwareInitialisationThe basic infrastructure software plays a fundamental role in the initialisation of the network element. The initialisation is responsible for putting the network element in a state in which the application software can begin its work. This includes not only hardware initialisation (e.g. interfaces, controller) but also SW initialisation (pSOS, XOS, tasks, software interfaces). The initialisation can be divided into cold start and warm start depending on the starting point.

A cold start is carried out:

• After the insertion of a plug-in unit

• After clearing a voltage failure (power-down)

• After power-on of a network element

• When the watchdog circuit is triggered during a warm start, e.g. owing to an endless loop

• Upon the instruction of the exception handler.0

The cold start is permanently configured in the boot PROM. The cold start process checks the various memories (PROM, RAM, Flash EPROM) and the unit-specific hardware elements, carries out the basic initialisation of the plug-in unit and then initiates the warm start.

A warm start occurs:

• After a successful cold start

• Upon the instruction of the exception handler.0

A warm start is carried out primarily by the FBoot process (the designation FBOOT is based on the fact that the software for the warm start (like the remaining software) is located on the Flash EPROM - in contrast to the software for a cold start, which is stored in the boot PROM). The FBoot process calls up the initialisation functions of other building blocks which carry out the initialisation of various system components.

The initialisation routines (in the FBoot building block) call up the initialisation routines of the hardware drivers which carry out hardware initialisation. (Thus, the building block ‘V.24 driver’ contains functions for the initialisation of the V.24 interface in addition to the driver functions).

This first warm start phase is carried out in single tasking mode, i.e. only the FBoot process runs. The pSOS and XOS tasks are initialised during this phase.

The second warm start phase runs in multitasking mode; the pSOS and XOS users are initialised in this phase. For this purpose, some functions are called up and made available for the initialisation of the respective building blocks.


4-16 Infrastructure

Exception handlerThe exception handler is activated by software or hardware functions. The responsibility of the exception handler is to react immediately to reported hardware and software exceptions.

The exception handler must avoid that the exceptions have an effect on the signal transmission. If this cannot be avoided, the handling of the error has to limit the exceptions as much as possible.

The exception handler reacts to:

• Static hardware exceptions

— incorrect or defective components on the plug-in unit

— short circuit, open circuit0

• Temporary hardware exceptions

— errors in the memory

— errors in the data or address buses

— errors on the interfaces

— hardware exceptions are also caused by program errors that are recognised by the hardware, e.g. when accessing an inadmissable memory area or division by zero

0

• Software exceptions

— parameter error (the functional block transmits invalid parameters, or the activated process does not respond as expected)

— missing resources (the memory cannot be made available, the message queues are overloaded)

— synchronisation error (different system time on the plug-in units, faulty process synchronisation).

0

Exceptions detectorThe exception handler requires information from the detectors that supervise the hardware and the software in order to properly react to an exception. A detector message consists of:

• Identification

• Localisation

• Classification

• Additional information.0

Identification and localisation provide accurate information concerning the type and source of an exception. The identified error can be more precisely described using the additional information. This optimises the operation of the exception handler according to the message.


Infrastructure 4-17

4

The exception handler also receives a classification of the message from the detector message:

• Informing message for insignificant errors which do not require a reaction

• Warning message for small errors which do not have to be eliminated

• Severe exceptions which can only be eliminated by a warm start

• Fatal exceptions which must be eliminated by a cold start.0

A distributed control system is implemented within the application software, i.e. all application processes report parameter errors to the exception handler.

Exceptions are also supplied by the watchdog circuit. The watchdog is a hardware component that awaits a signal from the software in regular intervals. If the signal is not sent (e.g. due to an endless loop in the program), the watchdog assumes that an operation error exists.

In addition, a ‘heartbeat’ function is implemented that expects regular functional acknowledgments from all of its registered processes. If the acknowledgment is not received, an operation error within this process has occurred.

Actions of the exception handlerAn exception is either ignored (informing or warning messages) or processed in one of the following actions according to its classification:

• Request for a warm start of the affected controller in the case of severe errors

• Request for a cold start of the affected controller in the case of fatal errors

• Blocking of the affected controller in the case of fatal errors which are based on static hardware errors. The controller is brought to a state in which it cannot have a negative influence on the network element despite the failure.

0

If an error classified as ‘severe’ is not eliminated after a warm start, the exception handler assumes, contrary to the classification in the detector message, that a fatal error exists and subsequently invokes a cold start.

Message services The functional area ‘Message Services’ consists of building blocks required for communication between the MCU and peripheral units (PU).

The message services comprise two building blocks (see Figure 4-9).


4-18 Infrastructure

Figure 4-9Message services 4-9

MCU-PU message service PU The building block ‘MCU-PU message service’ is responsible for inter-process communication between the MCU and the peripheral units. This communication is based on the exchange of messages. The MCU-PU message service has the following tasks:

• Sending messages to the respective far end, including detection and forwarding of transmission-related events (acknowledgements, timeouts, etc.)

• Receiving messages from the respective far end, including detection and forwarding of transmission-related events (invalid messages, etc.)

0

The MCU-PU message service is responsible exclusively for protocol handling, and thus has no knowledge of the applications using the message service or of the message contents.

PU Message Interface The building block ‘PU message interface’ is responsible for converting the message formats required for communication between the MCU and the PU from the PU-internal representation (in accordance with the valid PU message catalogue) to the external (XOS) format and vice versa.

Access to messages is provided via Message Access Routines (MARs), which carry out the syntax analysis and format conversion of messages. In addition, the PU message interface has a number of functions for seizing message buffers, determining message parameters and assigning object instance IDs to physical addresses.

Data block handlerThis functional area consists of only one building block which is responsible for the administration of data and memory blocks.

The data block handler accepts requests for the memory blocks from the application software and makes them available to the invoking building blocks. The data block handler uses the memory management services of the pSOS for this purpose.

Message Services

PU message interface

MCU-PU message


Infrastructure 4-19

4

The pSOS manages blocks of different lengths 2n in a statically allocated memory area. The blocks are only allocated once during the initialisation phase and can no longer be released or modified (see page 4-8, ‘Memory management’). If a building block requests the allocation of a block via the data block handler, the latter allows the pSOS memory management to allocate the most appropriate free block according to the required size.

Example: The application software requires a block with a length of 300 bytes. The data block handler requests a block with 512 bytes from the pSOS if such a block is available; otherwise, it requests a block of 1024 bytes, an so forth.

Local address servicesIf local addresses (e.g. stack addresses) are required, the local address services are called up by the MCU application software, by the communication services or by the infrastructure software. The Local Address Services (LAS) make these addresses centrally available; thus, the addresses do not have to be administered in the individual software packets.

The LAS consists of three building blocks (see Figure 4-10):

Figure 4-10Local address services 4-10

• The building block ‘local address service’ contains the access procedures for the addresses.

• The ‘AETable’ saves the local address data in table format.

• The building block ‘local environment’ comprises both access procedures and data for internal addresses, e.g. the slot addresses of individual plug-in units.

0

Local address

AETable

Local environment

Local address service

services


4-20 Infrastructure

Hardware driversSystem services hardware drivers ensure that the functions of the system service can be used. The functional block comprises the following drivers (see Figure 4-11):

Figure 4-11Hardware drivers 4-11

• EEPROM driver for the transfer of data to and from the EEPROM, for instance on the shelf backplane. There is one driver as process and one for procedural callups

• Flash EPROM driver for the transfer of data to and from the flash EPROM on the plug-in units

• IIC bus driver: the IIC bus interconnects various HW components of a plug-in unit. The IIC bus driver provides the mechanism for data exchange using the IIC protocol and access to the HW components using the bus.

• Driver of the real time clock

• SW clock driver: the timers use a clock pulse generated by the HW; the SW clock driver controls the hardware for the generation of clock pulses.

• Watchdog driver: in order to detect a plug-in unit failure, every network element has a so-called watchdog mechanism at its disposal. This mechanism can be compared to a dead man’s button in railway traffic: every plug-in unit must send a signal to the watchdog in regular intervals. The plug-in unit is no longer functioning properly if the signal is not sent.

• V.24 driver: this driver implements the V.24 protocol for communication with the V.24 interfaces on the plug-in units.

• MCMC: the MCI driver controls the three clock pulse interfaces (T3.1in, T3.2in, T4out) on the MCU connection interface, i.e. it is responsible for the activation, deactivation and monitoring of these interfaces.

• The TPU driver is used to control the programmable timer function (TPU) of the main controllers on the peripheral units.

• The LED driver controls the light emitting diodes (LED) on the plug-in units.

1) Used only on the Communication Controller (SIU, TIU-4). The TIU-4 has a Communication Controller (CC); however, it has no function on this plug-in unit.

2) Used only on the Main Controller (MC) of the peripheral units, not on the MCU

Hardware drivers

MCMC RTC V.24 driver LED driver

Watchdog EEPROM Flash EPROM IIC driver SW Clock

TPU driver2

MC-CC driver1

EEPROM


Infrastructure 4-21

4

• The MC-CC driver is used for exchanging data between the main controller (MC) and the communication controller (CC) of a plug-in unit via shared memory (see page 4-7).

0

General building blocksThis area consists of three globally used building blocks of the infrastructure software (see Figure 4-12):

Figure 4-12General infrastructure building blocks 4-12

• The building block ‘general include files’ provides global constants and definitions that are used, for example, to ensure that coding standards are maintained.

• The building block ‘coding standards’ provides include files which ensure that coding standards are maintained.

• ‘EEPROM management’ administers the data stored on the EEPROM of the backplane of the shelf.

0

Communication servicesInterfaces

A network element can communicate with and be controlled by various external partners. Each network element is therefore equipped with two different interfaces:

• The Q interface has a separate socket for the connection of a computer. This can be used as a local or as regional network management computer. A local computer is also referred to as craft terminal.

• A network element is coupled to each of its closest neighbours via several overhead bytes of the STM transmission signal. The actual Telecommunications Management Network (TMN) is based upon this coupling. This connection is physically embedded in the optical transmission signal; however, it is logically unrelated and considered a separate connection which is defined as QECC interface.

0

The Q and QECC interface are interconnected within each network element. Data which is received via the Q interface can be transferred to other network elements via the QECC interface and vice-versa (a corresponding addressing is required). This procedure also allows a network management system (NMS)

General

General include files

EEPROM administration

building blocks

CodingStandards


4-22 Infrastructure

that is directly connected to a network element via the Q interface, to communicate with other network elements in the transmission network.

The implementation of the corresponding protocols and the administration of both interfaces is performed by the communication services (Figure 4-13). The communication services provide the application software with all of the functions it requires to communicate with the network management system, with the other network elements or with the local craft terminal. Internal communication, in other words, the exchange of data between the plug-in units and the processor within a network element, is not performed by the communication services, but rather by the system services.

Note: In addition to the overhead bytes used for the transmission of management data and implementation of the QECC interface, the TN-4X network elements use various overhead bytes, for instance, for the localisation of errors and for the activation of protection switching. The concept of the QECC interface does not include this signalling; it includes only the transmission of management data within the TMN.

FunctionsThe functions of the communication services comprise Software Download and the Message Communication Function (MCF), which groups together the remaining functions of the communication services.

The MCF represents one protocol stack in accordance with the OSI (see Figure 4-13) that implements all transmission protocols.

Figure 4-13The communication services in the NE software 4-13

Communication Services

Communication drivers

SW DownloadStack

MIL

MCF


Infrastructure 4-23

4

The OSI model – brief overviewThe implementation of the communication services is primarily based on the standards of the seven-layer model for communication in open systems (OSI layer model), which was developed by the International Organisation of Standardisation (ISO).

The OSI layer model is a standard designed to facilitate the communication and the exchange of information among the different systems. In order to simplify the development of such communication interfaces, their functions are divided into seven layers arranged on top of each other. The features and interfaces of each of these layers have been standardised by the ITU-T, which allows the layers to be developed independently. Thus, a software packet that implements a layer can also be replaced by another packet without affecting the rest of the software.

Each of the two partners that wish to communicate with each other have this type of stack (OSI stack) at their disposal. The stacks are interconnected via the lowest of the seven layers (see Figure 4-14).

Figure 4-14Communication via the layer model of the OSI 4-14

The following table can only provide a brief overview of the tasks of the model’s individual layers. Refer to technical literature for a more complete description (the following sections provide a more detailed explanation of the tasks and structures of some layers). The fundamental standard for the OSI model is the standard ISO 7498; however, most details are specified in a variety of other standards.

7654321

Application

7654321

Application

OSI stack

Physical connection

Unit A Unit B


4-24 Infrastructure

Note: The physical layer (layer 1) is implemented exclusively by the hardware components and therefore does not belong to the communication services; for this reason it will not be discussed any further.

Structure of the network communicationStructure of the MCFThe network element carries out all external communication, i.e. with the Craft Access Terminal, with the network management system (TN-MS EC-4X) or with other network elements, via the OSI protocol stack which is implemented by the Message Communication Function (MCF), see Figure 4-15. Both the Q and QECC interfaces use layers 3 to 7 of the message communication function jointly, as they use the same transmission protocol. Only the data link layer (layer 2) is implemented separately for each interface because it must handle different requirements.

The message communication function corresponds to the ITU-T specifications for open system communication (OSI layer model, see Figure 4-13).

Table 4-1Functions of the layers in the OSI model 4-1

Application-related services

7 Application layer

Direct application support, connection setup to the communication partner (on application level), remote invocation of functions

6 Presentation layer

Uniform representation of information, i.e. conversion of data structures (from the application standpoint) to transportable structures and vice versa

5 Session layer Organisation and control of the dialogue between the communicating partners (e.g. conference calls)

Transport-related services

4 Transport layer

Reliable and efficient data transport between the communicating partners via guaranteed point-to-point connection

3 Network layer

Path selection and routing to the destination system,segmentation and filling,flow control

2 Data link layer

Setup and release of individual reliable transmission channels, error control, detection and elimination,flow control

1 Physical layer

Mechanical (functional) and electrical control of the bit transmission (hardware)


Infrastructure 4-25

4

The ECC bus which transfers the data of the QECC interface within the network element is also connected via the common protocol stack. Again, only the data link layer is implemented separately.

Figure 4-15 The protocol stack of the MCF 4-15

Layer implementationThe function and implementation of the common upper layers correspond to ITU-T specifications for the OSI model (see page 4-23, ‘The OSI model – brief overview’). They are implemented using ported and - wherever necessary - modified products from Retix . Figure 4-16 shows the building block structure of the communication services.

QQECC

1

MIL

Data link layerQECC

1Data link layer

QData link layer

ECC BUS

1 Network elements that are connected to more than one additional NE via the optical line (STM signal) (e.g. line repeater) have more than one QECC data link layer and one QECC interface accordingly.

Message Communication Function

ECC busNMS other NE1CAT-4X

Application layer

Presentation layer

Session layer

Transport layer

Network layer

OS

I pro

toco

l sta

ck


4-26 Infrastructure

Figure 4-16Building blocks of the communication services 4-16

MCF


MIL

Stack

MIL

CM

Pres

RtxComInc

CEC

LLC1

BAS

StackUtilities

StackProtectionTP4

StackEnv

RtxLowInc

ROSE

Upper

RtxRouterInc

ISISMgmt

System

ACSE

MCU802MACdriver

ECC bus driver QECCR driver1

1) Only used on communication controller (SIU, TIU-4)

MILPXOS

StackUpperITISISRtgIT

RouterUpper

ISISRfoITRtxUppInc

PHASEStackEnv

RouterLower StackInit

TPInterface TP4IT

General Retix Components

Stack Environment


Infrastructure 4-27

4

Table 4-2 provides an overview of the functional blocks used in the OSI stack and their implementation using the building blocks, as well as the respective standards.

Further Retix® components (see page 4-32, ‘Further retix components’) and the stack environment (see page 4-32, ‘Stack environment’) are needed for implementing the stack.

The management interface library (MIL)The CMISE of the application layer only allows a point-to-point connection between two objects (see below); for the application, however, communication should occur connectionless. As a result, the management interface library is located between the application and the CMISE, and the MIL assumes all aspects that control the connection (i.e. set-up and clear-down of the connection). Connectionless communication means that the

Table 4-2The OSI stack of the MCF (message communication function) 4-2

OSI layer Implementation Building blocks

Standard

Application layer(layer 7)

CMISE (Common Management Information Service Element)

CM ISO 9595, ISO 9596

ROSE (Remote Operation Service Element)

ROSE ISO 8822, ISO 8823

ACSE (Association Control Service Element)

ACSE ISO 8549,ISO 8650

Presentation layer(layer 6)

Presentation service Pres ISO9072.1, ISO 9072.2

ASN.1 (Abstract Syntax Notation One)

Upper ISO 8824, ISO 8825

Session layer(layer 5)

Session service BAS ISO 8326,ISO 8327

Transport layer(layer 4)

Transport service class 4 TP4, TPInterface,TP4IT

ISO 8073

Network layer(layer 3)

Connectionless network layer {ISISMgmt, ISISRfoIT, ISISRtgIT, RouterUpper, RouterLower}

ISO 8473 (CLNP)ISO 10589 (IS-IS)ISO 9542 (ES-IS)

Data link layer (layer 2)

for QECC interface:LAPD protocol (HDLC method)

ECC bus driver,QECCr

in acc. withG.784, Q.921

for Q interface:- LLC sub-layer (logical link control)- MAC sub-layer (media access control) with CSMA/CD method.

LLC1MCU802MAC

ISO 8802.2

ISO 8802.3


4-28 Infrastructure

communication partners are no longer in direct contact with each other (e.g. as in a telephone conversation), but rather send a message with a destination to the transmission service which then delivers this message to the specified address (e.g. as in the letter post).

This system relieves the application, as it no longer has to worry about the setting up of the connection. Another advantage is that call set-up and call management occur in a central position instead of in many different positions within the application.

The MIL is realised by two building blocks, ‘MIL’ and ‘MILPXOS’, with MILPXOS containing all the parts of MIL which access the Extended Operating System (XOS).

The application layer (Layer 7)The application layer of the protocol stack is implemented by three functional blocks:

• The Common Management Information Service Element (CMISE)

• The Remote Operation Service Element (ROSE) and

• The Association Control Service Element (ACSE).0

The three service elements CMISE, ROSE and ACSE are standard products for the communication between a manager system and an agent system. A brief description of the functions of these functional blocks is sufficient to understand their integration in the remaining software.

The CMISE provides the application with all of the services it requires for communication with the far end. It uses the services of the ACSE to establish a point-to-point connection with a remote object and maintain it for the duration of communication. Then this object at the far end is addressed and (remote-) controlled using ROSE; if necessary, data is also received from there.

The presentation layer (Layer 6)The main function of the presentation layer is to convert the complex application layer information to linear data structures that can be transmitted via the lowermost communication layers. This can be compared to an image sensor that converts the two-dimensional representation of a photo into a one-dimensional representation made up of data, that can be compiled again to form an image on the other side.

A number of terms must first be defined before the implementation of this structural converter can be explained:

The data structures of the application are referred to as ‘abstract syntax’ (AS), while the data structures of the lower transmission layers are referred to as ‘transfer syntax’. In order to be able to convert the abstract syntax to transfer syntax and back again, a type of dictionary is necessary that is


Infrastructure 4-29

4

available in the presentation layers of both communication partners. This dictionary is called ‘presentation context’.

According to ITU-T, a structural converter is capable of administering several different abstract syntaxes and transfer syntaxes and using the corresponding presentation context for one pair at a time. A defined context set (DCS) refers to the sum of all ‘dictionaries’ defined in the presentation layers of the affected communication partners. The appropriate presentation context is specified from this set for the communication between a manager and an object respectively. This procedure guarantees that the data to be transmitted is always decoded on the receive side in the same way as it was encoded on the transmit side.

Only one abstract syntax and one transfer syntax is used in each of the TN-4X network elements; the DCS therefore consists of only one presentation context.

Figure 4-17Functional view of the block ‘convergence functions’ 4-17

The structure converter, and thus the implementation of the presentation layer in the communication services, consists of four functional blocks as well as the two interfaces to the application layer and to the session layer. The individual blocks (see Figure 4-17) have the following functions:

(1) Abstract syntax: This block acts as a buffer for the application data; here, the data is temporarily saved in the format recognised by the application.

(2) Translator: The conversion between abstract and transfer syntax takes place here. Translation from the abstract syntax to the transfer syntax is the task of the formatter, the translation in the other direction is performed by the parser. Both access a previously specified presentation

Administration

Transfer syntax

Abstract syntax

Formatter Parser

Translator

DCS

Lower interface

Upper interface

Structure converter


4-30 Infrastructure

context from the DCS. The abstract syntax is represented with the aid of the abstract syntax notation 1 (ASN.1), a widely known standard (Since only one abstract syntax and one transfer syntax are used, only simple encoded data is used. This results in a reduction in the quantity of data to be transmitted in comparison to fully encoded data).

(3) Transfer syntax: This block is the buffer for the transport data and is similar to the block ‘abstract syntax’.

(4) Administration: The administration block executes all functions required to set up the connection to the presentation layer at the far end. The presentation context is also specified here after the translators on both sides have converted the data.

The intermediate layers (Layers 3, 4 and 5)The intermediate layers, i.e. the session layer, the transport layer and the network layer generate standard protocols for transmission within the network:

• The session layer is responsible for setting up and maintaining a connection requested by an application process. If the connection is no longer required, the session layer first ensures that all data arrives at the recipient, and then releases the connection (on this level). Then the request for a connection can be processed another application process.

• The transport layer is responsible for using the available transmission network as efficiently as possible and for protecting the data to be transmitted against failures that can occur in particular in the network layer below it. These tasks also include dividing the data stream on the transmit side into data packets that can be transmitted individually and, if necessary, in multiplex operation, and compiling these data packets again in the correct order at the other end to create a data stream.

The class 4 protocol is used in the TN-4X network elements in the transport layer. In addition to the above-named properties, the class 4 protocol also supports the identification and clearance of transmission errors. This is necessary because transmission via a LAN (Q interface) in the lower layers does not provide for a connection-oriented protocol and thus a fault-free connection can only be guaranteed using this transport protocol.

• Finally, the network layer is responsible for addressing the data to be transmitted and evaluating addresses for received data. Its task becomes clear in page 4-33, ‘Distribution of management data’, which explains the routing of the management data within a network element.

0

The network layer is realised by the following protocols:

• Dynamic IS-IS routing (routing between ‘Intermediate Systems’)

• ES-IS protocol for communication between ‘End Systems’ and ‘Intermediate Systems’


Infrastructure 4-31

4

• CLNP (Connectionless Network Protocol) protocol for connectionless network communication.

0

The data link layer (Layer 2)The data link layer is implemented differently for the two network element interfaces in accordance with their different functions:

Q interfaceThe Q interface establishes the connection to a network with multiple access, i.e. several communication partners can access the same channel at the same time (bus structure, see Figure 4-18). This property is required if, for example, several computers are to be connected simultaneously to the network element via the Q interface, e.g. a local craft terminal and a regional network management terminal. In order to enable this access, the data link layer of the Q interface consists of two sub-layers:

• The LLC sub-layer (logical link control) is responsible for data link control; it uses an LLC-Class1 protocol in accordance with ISO 8802.2.

• The MAC sub-layer (media access control) ensures that the data is properly transmitted via the line and reaches the correct communication partner. It also guarantees that only one communication partner writes on the transmission channel at any one time. It uses a protocol according to the CSMA/CD standard (ISO 8802.3), which corresponds to the Ethernet link access procedure.

QECC interfaceIn contrast to the Q interface, a point-to-point connection is always set up via the QECC interface, as the TMN is a point-to-point network: Two network elements are connected with one another (see Figure 4-18). Therefore, only data link control is required and not the access control of the MAC sub-layer. As a result, the data link layer is implemented in the QECC interface by means of a HDLC process that represents an automatically configuring, symmetric version of the standardised protocol specified in the ITU-T recommendation G.784.

Figure 4-18Point-to-point network and bus structure 4-18

In the HDLC procedure, one block of bytes is combined at a time, regardless of inner contexts. It then receives a destination and check bytes as well as a number of other bytes with additional administrative information and, in this

Point-to-point network Bus structure


4-32 Infrastructure

combination, forms what is called a frame. This frame is transmitted to the far end. The check bytes can be used to detect transmission errors. In the event of a faulty frame, the sender is informed of which frame(s) must be re-transmitted. This guarantees almost 100% transmission quality.

The ECC bus is designed in exactly the same way as the Q interface in terms of structure, i.e. it basically has the same bus structure.

Further retix components Besides the building blocks described above, the following Retix® components are required for setting up the OSI stack:

• The building block ‘System’ contains the functions for memory and pool administration for the lower layers of the Retix stack.

• The building block ‘RtxRouterInc’ contains all Include files for the software of the IS-IS routing protocol within the Retix stack.

• The building block ‘RtxUppInc’ contains all Include files for the software of the upper layers of the Retix stack.

• The building block ‘RtxLowInc’ contains all Include files for the software of the lower layers of the Retix stack.

• The building block ‘RtxComInc’ contains all the common Include files used commonly for the entire Retix software.

0

Stack environmentA number of additional building blocks is required in order to construct the OSI stack environment. The functions of these building blocks are briefly explained below:

• The building block ‘StackEnv’ (Stack Environment) contains the general (project independent) runtime environment for the OSI stack.

• The building block ‘PHASEStackEnv’ (PHASE Stack Environment) contains the TN-4X-specific runtime environment for the OSI stack.

• The building block ‘CEC’ (Construction Element Communication) is responsible for the inter-process communication between the stack processes.

• The building block ‘StackProtection’ is responsible for process coordination when accessing the resources (memory, processor, timer) of the processor system and ensures that these are accessed in the correct order in case of concurrency.

• The building block ‘StackUpperIT’ (Stack Upper Interface) implements the interface between CMISE and MIL.

• The building block ‘StackInit’ (Stack Initialisation) is responsible for the initialisation of the OSI Stack.

• The building block ‘StackUtilities’ provides frequently used utilities to the OSI stack.

0


Infrastructure 4-33

4

Communication driversCommunication drivers are used to implement the data link layer (layer 2) of the OSI stack (see page 4-31, ‘The data link layer (Layer 2)’). The ECC bus driver is used for the QECC interface, which implements both the LLC sub-layer (logical link control) and the MAC sub-layer (media access control).

The QECC (or QECCR) driver is used on the communication controller of the plug-in units with synchronous interfaces (SIU, TIU-4).

The MCU802MAC driver, which provides the MAC sub-layer of the Ethernet interface, is used for the Q interface.

Distribution of management dataAs mentioned at the beginning of this fascicle, all administration of external communication takes place on the MCU. While the Q interface is directly connected to the MCU via the MCU connection interface (MCI), the connection to the optical network is accomplished via the synchronous interface units (SIUs).


4-34 Infrastructure

Figure 4-19The network element in the management network 4-19

Protocol conversion on the synchronous interface unitsEvery synchronous interface unit (SIU) maintains both a main controller (MC) that controls the activities of the plug-in unit and a communication controller (CC) that is used exclusively to convert management data. These units also contain AISCs that process the optical signal and read the management data from the receive signal or insert the data in the transmit signal.

The communication controller also contains an OSI partial stacks (see Figure 4-13) that only implements layers 1 and 2 and are responsible for converting the external transmission protocol (Q interface) into the internal transmission protocol (ECC bus) and vice versa. All received data is forwarded to the MCU via the ECC bus.

NE

NENE

NE

X interface to

Q interface Regional network management

Network

superordinatenetwork management

Regional subnetwork

management server

ASICs

MC CCSIU

ASICs

MC CC

SIU

SIG bus

ECC bus

MCI Q interface

Local craft

STM signalSTM signal

Network

Link to other TN-4X subnetworks

MCU

element

terminal(CAT-4X)


Infrastructure 4-35

4

Routing in the MCUData routing is performed on the MCU. This involves establishing the address for which the data is intended: the data is subsequently forwarded to this address.

The MCU contains the complete OSI stack of the communication services, i.e. a protocol stack on all seven layers of the OSI model. Data that reaches the MCU via the ECC bus is initially evaluated up to layer 3, where the recipient of the data is then determined.

• If the data is intended for the MCU, it is evaluated in the upper layers of the OSI stack and subsequently sent to the application. Data that is to be forwarded to other plug-in units in the network element are sent via the SIG bus.

• If the data is intended for the local craft terminal, the protocol data of layers 3 to 1 is re-inserted and the data is sent directly to the MCU connection interface (MCI), i.e. the Q interface.

• If the data is intended for another network element, all protocol data in layers 3 to 1 is re-inserted and the data is sent to the synchronous interface unit that sets up the connection to the next network element via the ECC bus (see Figure 4-20).

0

Figure 4-20Routing in the MCU 4-20

Communication between the MCU (application) and the local craft terminal is accomplished via layers 7 to 1 of the stack on the MCU.

Management data from / to STM signal (via ASIC)

CC on SIU

ECC

bus

Craft terminal

MCU

Application

Q interface

321

321

654

7

Stack

Stack

2 21 1CC on SIU

Stack

2 21 1

MCI


4-36 Infrastructure

Internal transmission systemsManagement data is transmitted between the MCU and the synchronous interface units (SIUs) via the ECC bus only. On the other hand, data that is sent by the MCU to the plug-in units of the network element in order to control or retrieve information from these units is transmitted via internal system services communication using the SIG bus.

This also applies to management data relating to the SIUs: this data is first retrieved from the STM signal on the SIU (via the ASICs and the communication controller) and forwarded to the MCU via the ECC bus, where it is converted to a form that can be processed by the SIUs. It is subsequently returned to the main controller of the SIU via the SIG bus.

Software downloadThe functional area ‘Software Download’ (SWDL) allows updates of network element software to be downloaded from an external load workstation (The loading requires a special load workstation and is intended only for specially trained service personnel of the manufacturer), possibly via the network (‘Remote SWDL’ via the ECC). Software Download thus enables the MCU software and that of main controllers and communication controllers on the PUs to be upgraded.

The functional area ‘Software Download’ comprises six building blocks (see Figure 4-21), the functions of which are described in the context of the download procedure:

Figure 4-21Software download 4-21

Software Download requires a special workstation as a load server to be connected to the MCU of the network element (possibly via the QECC). All the commands of the load server concerning the download are first sent to the CE protocol handler via layer 4 of the OSI stack.

The CE protocol handler is responsible for communication between the network element and the load server, and processes the command/event protocol, i.e. all control commands, answers and events involved in Software Download. The CE protocol handler converts the incoming commands from the load server into the NE-internal message format and forwards them to the

MDTprotocol

Command handler

Loadhandler

CE protocol

Object handler

Gen. SWDL module

Software Download


Infrastructure 4-37

4

command handler. In the opposite direction the CE protocol handler formats answers and events from the command handler and routes them back to the load server.

The command handler executes the commands from the load server and controls the Software Download procedure within the network element. In particular this involves coordinating the actions of the load handler and of the object handler. The command handler also carries out the updating and state management of the software images and initiates the erasing of the memory bank prior to the loading of a new image.

The load handler controls the loading of a software image into the inactive flash EPROM memory bank of the processor system. The load handler requests the new software image from the load server (via the MDT protocol handler) and via the object handler controls the programming of the memory bank with the delivered units of data.

The MDT protocol handler constitutes the interface for the Mass Data Transfer (MDT), i.e. for loading software images from the load server. The protocol handler is responsible on the network element side for communication with the load server. It requests the image specified (via the user interface) from the load server, receives the incoming data and forwards it in a suitable format to the load handler.

The object handler constitutes the interface for all accesses to the internal infrastructure, memory areas and hardware components, and represents these areas - irrespective of their distribution within the network element - uniformly to the command handler and load handler as objects. The object handler provides uniform access to all SWDL objects and synchronises the operations concerning these objects.

Although all building blocks of Software Download are located on the MCU, the object handler itself is also present on the main and communication controllers of the PUs, where it represents the PU-local hardware components. The object handler on the MCU communicates with the PU-local object handlers so that it can also display the objects on the PUs. For this communication the MCU-PU message service is used (see page 4-17, ‘Message services’).

The General SWDL module provides commonly used utilities for Software Download.

Figure 4-22 illustrates the interaction of the individual building blocks of Software Download.


4-38 Infrastructure

Figure 4-22Software download: interaction of building blocks 4-22

End of chapter file

PU

MDT protocol handler

Commandhandler

Loadhandler

CE protocol handler

Objecthandler

7654321

Load PC

OSI stack

PUMCU

Objecthandler

Network element

(connected to the NE

SIG bus

HW driver

HW

HW driver

HW

HW driver

HW

HW driver

HW

. . .

The building blocks of the functional area "Software Download" are within the dashed lines.

directly or via QECC)

Flash EPROMs Flash EPROMs


5-1

5

Chapter 5: MCU/PU software configuration

IntroductionA TN-4X network element contains a management and communication unit (MCU) and several peripheral units (PU), each of which contains its own software. All of the plug-in units of this configuration combined form an independent system.

Figure 5-1 outlines both the layout of these plug-in units and the layer model used to represent the system architecture. Several software layers are located above the hardware which forms the lowest layer in this model.

The infrastructure software represents the lowest software layer. All plug-in units use the same infrastructure software in order to ensure that the software system interworks at this level. This software layer is responsible for the operations system functions as well as for communication between the plug-in units. The infrastructure level can therefore be considered a distributed operating system for the entire network element.

Every plug-in unit has its own, separate application software that is not dependent on the application software of other plug-in units.


5-2 MCU/PU software configuration

Figure 5-1TN-4X software architecture 5-1

Figure 5-4 at the end of this chapter provides a detailed overview of the system architecture, i.e. the assignment of building blocks. This figure should always be consulted if the exact position of a building block or the structure of a software subsystem is required.

MCU

Hardware

Infrastructuresoftware

Applicationsoftware

Software

SIU

Units

Laye

rs. . .

. . .

. . .

. . .


MCU/PU software configuration 5-3

5

Configuration of the MCU softwareOverview

The MCU software comprises the infrastructure software section used by the MCU, as well as the MCU application software. Figure 5-2 contains the components of the MCU software. The individual building blocks of these components are listed in the following tables and in a detailed figure in the general overview at the end of this Chapter (Figure 5-4).

Figure 5-2Structure of the MCU software (overview) 5-2

MCU application software

Common servicesGeneral routines


NE configuration and supervision

CMIS agentand



Timing

Transmission Connection Protection Faultobject

eventreportmanagement

Backup routines

management managementmanagement management managementgenerator

Infrastructure

Communication services System services

Communication drivers Hardware drivers

MIL

Stack

Operation Messageservices

Basic Local Generalbuildingblocks

infra-structure

system addressservices

Data block handling

Software download



Building blocks employed The building blocks used by the MCU software are listed in the following two tables. These tables briefly characterise the function of the building blocks and specify where the function of every MCU building block is described in this software description.

Table 5-1 below contains the building blocks used by the MCU application software.

Table 5-1MCU software configuration – part 1: application software 5-1

Building block Meaning / function (see chapter/page)

NE configuration and monitoring

MCAU Management of AUG and TUG (page 2-29)

MCCC Switching matrix process (page 2-39)

MCCM CMISE agent (page 2-5)

MCCN Confirmation monitoring for notifications (page 2-5)

MCCO Connection management (page 2-39)

MCEF Event forwarding discriminator (page 2-7, page 2-8)

MCEQ Equipment management (page 2-22)

MCFA Fault management (page 2-12)

MCFB Fabric task (page 2-39)

MCNE Network element management (page 2-16)

MCPO Port management (page 2-22)

MCPR Protection switching management (page 2-48)

MCTG Timing generator management (page 2-55)

MCTP Management of termination points (page 2-29)

Database services

MCCF Data restoration services (page 2-61)

General services

MCCR Conversion routines (page 2-65)

MSVM Watchdog triggering for MCU monitoring (page 2-65)

XXMH Message handling (page 2-65)

XXPH Process handling (page 2-65)

XXXX Common building block



5

Table 5-2 lists the infrastructure building blocks. Building blocks that implement the same function may be grouped together in the functional description.

Table 5-2MCU software configuration – part 2: infrastructure 5-2


INFRASTRUCTURE – SYSTEM SERVICES

Operations system (OS)

PREPC pSOS runtime library (page 4-3)

pSOS pSOS (page 4-3)

SIGBusL2 SIGBUS level-2 driver (LLC and MAC) (page 4-3)

XOS Extended operation system (page 4-3)

Message Services

MCU_MessageService Service for communication between MCU and PU (page 4-17)

PU_MessageInterface Interface for communication betw. MCU and PU (page 4-17)

Data block handler

DBH Data block handler (page 4-18)


BLIB Basic infrastructure library for basic functions (page 4-14)

FBoot FBoot process for warm start (page 4-14)

XH Exception handler (page 4-14)

Local address server

AeTable Table for the administration of local addresses (page 4-19)

LocalAddressServer Access procedures for the provision of local addresses (page 4-19

LocalEnv Provision of internal addresses (page 4-19)

Other building blocks

EEPROMadmin Data administration on the backplane EEPROM (page 4-21)

NE_Global Includes General includes (coding standards) (page 4-21)

CodeStdInc Includes to ensure coding standards (page 4-21)

Hardware drivers

EEPROM EEPROM driver for access to backplane EEPROM (page 4-20)

—continued—



EEPROM_P Driver f. acc. to backpl. EEPROM (procedural) (page 4-20)

Flash Flash EPROM driver (page 4-20)

IIC IIC bus driver (page 4-20)

LED LED driver (page 4-20)

RTC Driver for real-time clock (page 4-20)

SWClock Timer driver (page 4-20)

V24 V.24 interface driver (page 4-20)

Watchdog Watchdog driver (page 4-20)

MCMC Driver for clock interface on the MCI (page 4-20)

INFRASTRUCTURE – COMMUNICATION SERVICES

MIL

MIL OSI stack, management interface library (page 4-25)

MILPXOS MIL parts that require XOS (page 4-25)

OSI stack (Environment)

StackEnv Project independent runtime environment for OSI stack (Fascicle IS, Chap. 3.4.2.7)

PHASEStackEnv OSI stack, management (page 4-32)

StackInit Initialisation of OSI stack (page 4-32)

CEC Communication between the processes of the stack (page 4-32)

StackProtection Coordination of the processes of the stack (page 4-32)

StackUpperInterface Interface between MIL and CMISE (page 4-32)

StackUtilities Commonly used utilities for the OSI stack (page 4-32)

OSI Stack (Retix Software)

ACSE OSI stack, access control service element (page 4-25)

BAS OSI stack, session layer (page 4-25)

CM OSI stack, CMISE (page 4-25)

LLC1 OSI stack, logical link control (page 4-25)

Pres OSI stack, presentation layer (page 4-25)

ROSE OSI stack, remote operation service element (page 4-25)

RtxInc Include files for the Retix stack (page 4-25)

RtxComInc

—continued—

Table 5-2MCU software configuration – part 2: infrastructure (continued) 5-2




5

RtxLowInc

RtxRouterInc

System Retix components (page 4-25)

RouterUpper Source code for IS-IS routing (page 4-25)

RouterLower Source code for event forwarding process (page 4-25)

TP4 OSI stack, transport layer 4 (page 4-25)

Upper OSI stack, presentation layer (runtime env.) (page 4-25)

Software Download

SWDL_LoadHandler Load control for software download (page 4-36)

SWDL_ObjectHandler Access to hardware drivers (page 4-36)

SWDL_CommandHandler Command control for software download (page 4-36)

SWDL_CEProtocolHandler Protocol conversion for download commands (page 4-36)

SWDL_MDTProtocolHandler

Protocol conversion for download software (page 4-36)

SWDL_CommonInterface Utilities for Software download (page 4-36)


ECCBus QECC driver and data link layer (page 4-33)

MCU802MAC Driver (MAC) for Ethernet interface (page 4-33)

—end—

Table 5-2MCU software configuration – part 2: infrastructure (continued) 5-2




Configuration of the PU softwareOverview

The software of the peripheral units (PU) comprises the part of the infrastructure software used by the PU, the (common) section of the PU application software used by all PUs and the specific sections of the application software for the respective plug-in unit.

A large proportion of the PU software is common to all PUs. The software configuration of the peripheral units is therefore combined in the following figure and in the tables.

Figure 5-3 shows an overview the structure of the PU software. The individual building blocks of these components are listed in the following tables and in a detailed figure in the general overview at the end of this chapter (Figure 5-4).

Figure 5-3Structure of the PU software (overview) 5-3

TIU-1 application software PPU-1 application software

...(corresponding software configurations for TIU-3, TIU-4, SIU-1/4, SIU-el and CMU)

The corresponding representations may befound in detail in Figure 5-4. The buildingblocks are listed in the followingtables.

Infrastructure

Communication services System services

Communication drivers Hardware drivers

MIL

Stack

Operation Messageservices

Basic Local Generalbuildingblocks

infra-structure

system addressservices

Data block handling

Software download

Hardware access

General PU ASIC Driver

TIU-1ASIC Driver

TIU-1HW Driver

DataHandling

PU Control

ProtectionSwitching

AlarmHandling

Hardware access

General PU ASIC Driver

PPU-1ASIC Driver

PPU-1HW Driver

DataHandling

PU Control

ProtectionSwitching

AlarmHandling



5

Building blocks employed The building blocks used by the PU software are listed in the following two tables. These tables briefly characterise the function of the building blocks and specify where the function of every building block is described in this software description.

All peripheral units whose synchronous interfaces transmit and receive network management information in the STM-N signal (all SIUs, TUI-4) (The TIU-4 is equipped with a Communication Controller; the CC, however, has no function on the TIU-4) have both a main controller (MC) and a separate communication controller (CC) that is used exclusively for the conversion of management data. These PUs therefore have a separate software configuration for the MC and CC respectively. All other PUs are equipped with only an MC.

Table 5-3 below contains the building blocks used by the PU application software.

Table 5-3PU software configuration – Main controller (MC) 5-3


TIU

-1

TIU

-3

TIU

-4

SIU

-1/4

CM

U-1

PP

U-1

Unit control

PU_AlarmHandling PU alarm handling (page 3-15) ❍ ❍ ❍ ❍ ❍ ❍

PU_Protection PU protection switching (page 3-20) ❍ ❍ ❍ ❍ ❍ ❍

PU_DataHandling PU data administration (page 3-4) ❍ ❍ ❍ ❍ ❍ ❍

Hardware access

PUASICDriver General PU-ASIC driver (page 3-43) ❍ ❍ ❍ ❍ ❍ ❍

TIU-1ASICDriver TIU-1 ASIC driver (page 3-43) ❍

TIU-3ASICDriver TIU-3 ASIC driver (page 3-43 ❍

TIU-4ASICDriver TIU-4 ASIC driver (page 3-43 ❍

CMU-1ASICDriver CMU-1 ASIC driver (page 3-43) ❍

PPU-1ASICDriver PPU-1 ASIC driver (page 3-43) ❍

TIU-1_HW TUI-1 HW driver (page 3-43) ❍



CMU-1_HW CMU-1 HW driver (page 3-43) ❍

PPU-1_HW PPU-1 HW driver (page 3-43) ❍

—continued—




TIU

-1

TIU

-3

TIU

-4

SIU

-1/4

CM

U-1

PP

U-1

CCU_Ctrl CCU control (Fascicle AP, Chap. 4.2) ❍

CCUX3HW CCU-X3 hardware driver (page 3-47) ❍

SIPU SIU ASIC driver (page 3-47) ❍

SITI SIU hardware driver for timer services (page 3-47) ❍

SILA SIU hardware driver for laser control (page 3-47) ❍

SIHW SIU hardware driver (page 3-47) ❍

APD_Ctrl Control of optical components (page 3-47) ❍

ADC Analogue/digital converter (ADC) (page 3-47) ❍ ❍ ❍ ❍ ❍ ❍

General services

XXMH Message handling (page 2-65) ❍

XXPH Process handling (page 2-65) ❍

XXXX Common building block (page 2-65) ❍

INFRASTRUCTURE

Operations system (OS) ❍ ❍ ❍ ❍ ❍ ❍

PREPC pSOS runime library (page 4-3) ❍ ❍ ❍ ❍ ❍ ❍

pSOS pSOS (page 4-3) ❍ ❍ ❍ ❍ ❍ ❍

SIGBusL2 SIGBUS level-2 driver (LLC, MAC) (page 4-3) ❍ ❍ ❍ ❍ ❍ ❍

XOS Extended operations system (page 4-3) ❍ ❍ ❍ ❍ ❍ ❍

Message services

MCU_MessageService Service for communication between MCU and PU (page 4-17) ❍ ❍ ❍ ❍ ❍ ❍

PU_MessageInterface Interface for communication betw. MCU and PU (page 4-17) ❍ ❍ ❍ ❍ ❍ ❍


BLIB Basic infrastructure library for basic functions (page 4-14) ❍ ❍ ❍ ❍ ❍ ❍

FBoot FBoot process for warm start (page 4-14) ❍ ❍ ❍ ❍ ❍ ❍

XH Exception handler (page 4-14) ❍ ❍ ❍ ❍ ❍ ❍

Local address services

LocalEnv Provision of internal addresses (page 4-19) ❍ ❍ ❍ ❍ ❍ ❍

—continued—

Table 5-3PU software configuration – Main controller (MC) (continued) 5-3



5


TIU

-1

TIU

-3

TIU

-4

SIU

-1/4

CM

U-1

PP

U-1


EEPROMadmin Data administration on the backplane EEPROM (page 4-21) ❍ ❍ ❍ ❍ ❍ ❍

NE_Global Includes General includes (coding standards) (page 4-21) ❍ ❍ ❍ ❍ ❍ ❍

CodeStdInc Includes to ensure coding standards (Fascicle IS, Chap. 2.8) ❍ ❍ ❍ ❍ ❍ ❍

Hardware drivers

EEPROM EEPROM driver for access to backplane EEPROM (page 4-20) ❍ ❍ ❍ ❍ ❍ ❍

EEPROM_P Driver f. acc. to backpl. EEPROM (procedural) (page 4-20)

Flash Flash EPROM driver (page 4-20) ❍ ❍ ❍ ❍ ❍ ❍

IIC IIC bus driver (page 4-20) ❍ ❍ ❍ ❍ ❍ ❍

TPU Activation of programmable timer function (TPU) on the MC ❍ ❍ ❍ ❍ ❍ ❍

LED LED driver (page 4-20) ❍ ❍ ❍ ❍ ❍ ❍

RTC Driver for real-time clock (page 4-20) ❍ ❍ ❍ ❍ ❍ ❍

SWClock Timer driver (page 4-206) ❍ ❍ ❍ ❍ ❍ ❍

V24 V.24 interface driver (page 4-20) ❍ ❍ ❍ ❍ ❍ ❍

Watchdog Watchdog driver (page 4-20) ❍ ❍ ❍ ❍ ❍ ❍

Software Download

SWDL_ObjectHandler Access to hardware drivers (page 4-36) ❍ ❍ ❍ ❍ ❍ ❍

SWDL_CommonInterface Utilities for Software download (page 4-36) ❍ ❍ ❍ ❍ ❍ ❍

—end—

Table 5-3PU software configuration – Main controller (MC) (continued) 5-3



Table 5-4 below lists the building blocks of the communication controller (CC) for the SIUs and the TUI-4 (The TIU-4 is equipped with a Communication Controller; the CC, however, has no function on the TIU-4). The software configuration of the CC includes a part of the system services and the parts of the infrastructure software required for communication via the QECC (see page 4-33, ‘Distribution of management data’).

Table 5-4Software configuration of communication controller (SUIs, TIU-4) 5-4


INFRASTRUCTURE – SYSTEM SERVICES

Operations system (OS)

PREPC pSOS runtime environment (page 4-3)

pSOS pSOS (page 4-3)


BLIB Basic infrastructure library for basic functions (page 4-14)

FBoot FBoot process for warm start (page 4-14)

XH Exception handler (page 4-14)

Local address services

LocalEnv Provision of internal addresses (Fascicle IS, Chap. 2.5)


EEPROMadmin Data administration on the backplane EEPROM (Fascicle IS, Chap. 2.8)

Hardware drivers

IIC IIC bus driver (page 4-20

LED LED driver (page 4-20)

SWClock Timer driver (page 4-20)

V24 V.24 interface driver (page 4-20)

Watchdog Watchdog driver (page 4-20)

ShMemMC_CC Dricer for communications between MC and CC via Shared memory (page 4-20)

INFRASTRUCTURE – COMMUNICATION SERVICES

OSI stack (Environment)

CCStackEnv Runtime environment for OSI stack on CC (page 4-32)

CCCLMgr CC Layer Manager: XOS access for stack data (page 4-32)

OSI stack (Retix components)

Software Download

SWDL_ObjectHandler Access to hardware drivers (page 4-36)

SWDL_CommonInterface Utilities for Software download (page 4-36)

Communication driver

ECCBus Driver and data link layer for ECC bus (page 4-33)

QECCR Driver for the QECC interface



5

‘Software configuration’ overviewThe TN-4X ‘software configuration’ overview (Figure 5-4) shows the structure of the network element software for the entire system, i.e. for MCUs and peripheral units (PU). Each functionally related area is graphically represented as a separate block. They comprise the building blocks (all of which are shown in white) contained in the respective units.

The structure of the individual software areas (abstracted and specialised for the respective area accordingly) is also included in the sections which precede this one.

The building block layering is also indicated in the application software area. Each software package in this area uses the packages directly below it.

The infrastructure building blocks are very closely connected. The infrastructure software should therefore be considered a single unit upon which the application software of the MCUs and PUs (as a whole) is based.



Figure 5-4Configuration of the TN-4X software 5-4

Infr

astr

uct

ure

Com

mun

icat

ion

Serv

ices

Sys

tem

Ser

vice

s

Co

mm

un

icat

ion

Dri

vers

Har

dw

are

Dri

vers

MIL

Sta

ck

Op

erat

ion

sD

ata

Blo

ckB

asic

Lo

cal A

dd

ress

Gen

eral

Appl

icat

ion

Softw

are

MCU

Com

mon

Ser

vice

sDa

ta R

esto

ratio

n Se

rvic

es

NE C

onfi

gura

tion

and

Supe

rvis

ion

MC

NE

Net

wor

k E

lem

ent M

anag

emen

t

MC

EQ

Equ

ipm

ent M

anag

emen

t

Appl

icat

ion

SW P

PU-1

Har

dw

are

Acc

ess

PP

U-1

HW

D

river

Har

dw

are

Acc

ess

Appl

icat

ion

SW T

IU-4

Har

dw

are

Acc

ess

TIU

-4H

W

Driv

er

Appl

icat

ion

SW S

IU-1

/4

Har

dw

are

Acc

ess

Appl

icat

ion

SW S

IU-1

el

Har

dw

are

Acc

ess

Appl

icat

ion

SW C

MU-

1

Har

dw

are

Acc

ess

CM

U-1

AS

IC

Driv

er

Appl

icat

ion

SW T

IU-1

Dat

aad

min

Mai

nte

nanc

e

Pro

t.sw

itchi

ng

Ala

rmha

ndlin

g

Mes

sage

Ser

vice

s

PU

Co

ntr

ol

Har

dw

are

Acc

ess

SIL

AS

IHW

SIP

US

ITI

CC

UX3

CC

UC

tr

Gen

eral

P

U-A

SIC

D

river

AD

C

Gen

eral

P

U-A

SIC

D

river

AD

C

PP

U-1

AS

IC

Driv

er

TIU

-4A

SIC

D

river

AP

DC

trl

CM

U-1

HW

D

river

MIL

CM

Pre

sR

txIn

cS

tack

-Util

LLC

1B

AS

Sta

ckIn

itS

tack

-UIn

t

TP

4S

tack

-Msg

Sta

ck-E

nv.

RO

SE

Upp

erS

tack

-Pro

tC

LNP

Sys

tem

AC

SE

MC

U80

2MA

CD

river

EC

C-B

us D

river

Ad

min

istr

atio

nS

ervi

ces

Bu

ildin

g B

lock

s

Wat

chdo

g D

river

RT

C D

river

V.24

Driv

erLE

D D

river

MC

MC

EE

PR

OM

D

river

Fla

sh-E

PR

OM

D

river

IIC D

river

SW

Clo

ck

Dat

a B

lock

H

andl

er

FB

oot

Exc

eptio

n H

andl

er

BLI

B

AE

Tabl

e

Loca

lEnv

Loca

l Add

ress

S

erve

r

Gen

eral

In

clud

e F

iles

EE

PR

OM

A

dmin

istra

tion

XO

S

SIG

Bus

L2 PS

OS

PR

EP

C

MC

FB

MC

PR

MC

FA

MC

CO

MC

TP

MC

CC

MC

AU

MC

TG

MC

PO

MC

CM

MC

EF

MC

CN

MC

CF

MS

VM

XX

MH

XX

PH

MC

CR

XX

XX

TP

U D

river

2

1) U

sed

only

on

the

Com

mun

icat

ion

Con

trol

ler

(SIU

, T

IU-4

). T

he T

IU-4

is e

quip

ped

with

a

Com

mun

icat

ion

Con

trol

ler,

the

CC

, how

ever

, has

no

func

tion

on th

e T

IU-4

.

2) U

sed

only

on

the

Mai

n C

ontr

olle

r (M

C)

of th

e P

erip

hera

l Uni

ts, n

ot o

n th

e M

CU

QE

CC

R

Driv

er1

Inst

ruct

ion

sS

yste

m

Dat

aad

min

Mai

nte

nanc

e

Pro

t.sw

itchi

ng

Ala

rmha

ndlin

g

Mes

sage

Ser

vice

s

PU

Co

ntr

ol

Dat

aad

min

Mai

nte

nanc

e

Pro

t.sw

itchi

ng

Ala

rmha

ndlin

g

Mes

sage

Ser

vice

s

PU

Co

ntr

ol

Dat

aad

min

Mai

nte

nanc

e

Pro

t.sw

itchi

ng

Ala

rmha

ndlin

g

Mes

sage

Ser

vice

s

H/W

Co

ntr

ol

Dat

aad

min

Mai

nte

nanc

e

Pro

t.sw

itchi

ng

Ala

rmha

ndlin

g

Mes

sage

Ser

vice

s

PU

Co

ntr

ol

Dat

aad

min

Mai

nte

nanc

e

Pro

t.sw

itchi

ng

Ala

rmha

ndlin

g

Mes

sage

Ser

vice

s

PU

Co

ntr

ol

Dat

aad

min

Mai

nte

nanc

e

Pro

t.sw

itchi

ng

Ala

rmha

ndlin

g

Mes

sage

Ser

vice

s

PU

Co

ntr

ol

Gen

eral

P

U-A

SIC

D

river

AD

C

SIL

AS

IHW

SIP

US

ITI

CC

UX3

CC

UC

tr

AP

DC

trlG

ener

al

PU

-AS

IC

Driv

erA

DC

Gen

eral

P

U-A

SIC

D

river

AD

C

TIU

-3H

W

Driv

er

TIU

-3A

SIC

D

river

Gen

eral

P

U-A

SIC

D

river

AD

C

TIU

-1H

W

Driv

er

TIU

-1A

SIC

D

river

Gen

eral

P

U-A

SIC

D

river

AD

C


6-1

Index 6

AAbstract syntax 4-28Abstract Syntax Notation One (ASN.1) 4-27,

4-30ACSE 4-27, 4-28Action 2-6Address services 4-19Administrative state 2-45AETable 4-19Agent 1-6Agent process 1-4Alarm data 3-7, 3-44Alarm detection 3-42, 3-45Alarm filtering 3-16Alarm masking 3-16Alarm monitoring 3-16Alarm notification 2-15Alarm severity assignment profile 2-12, 2-14,

2-22, 2-32Alarm state 3-7Alarm types 2-12Allocate once pool 4-8Anchored periodic timer 4-10Anchored timer 4-10Application data 3-7, 3-44Application interface 4-5Application layer 4-24, 4-28Application software 1-6, 5-1

MCU 1-6PU 1-7, 3-1

ASIC 3-42, 3-45, 3-46ASIC driver 3-5, 3-43ASIC driver object database 3-5ASN.1 4-27, 4-30Association Control Service Element 4-27,

4-28Attributes 1-3Automatic laser shutdown 2-32, 2-36

BBackplane EEPROM 2-22Backup configuration 2-16Backup medium 2-61Basic configuration 2-16Basic infrastructure 4-14Bidirectional point-to-point connection 2-39Block pool 4-8Blocked process 4-10Boot process 4-14Buffer pool 4-8Buffer pool configuration 4-9Building block 1-6, 2-4, 4-1, 4-25, 5-2, 5-3,

5-4, 5-8, 5-13

CCAPI 4-7Card protection 2-24, 2-28, 2-29CCU protection 2-58, 2-60CCU-X3 clock generator 3-48Clock generator 2-61Clock output 2-59Clock protection 2-58, 2-60Clock quality 2-55Clock source

switchover 2-61Clock supply 2-59CMIS agent 2-5, 2-7, 2-11CMIS services 2-6CMISE 4-27, 4-28CMU-1 specific software 3-38Cold start 4-15Common API (CAPI) 4-7Common management information service

(CMIS) 1-5Common Management Information Service

Element (CMISE) 4-27, 4-28Common services 2-65


6-2 Index

Communication 4-24between MCU and PUs 4-18connectionless 4-27failure 2-11manager - agent 1-4

Communication controller (CC) 5-9Communication driver 4-33Communication paths (operating system) 4-7Communication services 1-7, 4-1, 4-2, 4-21,

4-22, 4-25Communication system

network element 1-5Conditional package 1-3Configuration 2-16Configuration and supervision 2-1, 2-2Configuration data 2-17, 3-44Configuration data backup 2-21Connection 2-39Connection management 2-39Connection termination point 2-29Connectivity pointer 2-31, 2-40, 2-49Consolidation state 3-7Containment relationship 2-31Control 1-5Control system 4-17Conversion routines (ASN.1) 2-66Craft terminal 1-1Create 2-6Critical section 4-14Critical Section Guard (CSG) 4-5, 4-14Cross-connection 2-39Cross-connection pointer 2-31, 2-40, 2-49CSG 4-5, 4-14

DData block handler 4-18Data link layer 4-24Data restoration services 2-61Defined context set 4-29Delete 2-6Dictionary 4-28Distributed control system 4-17Domain 4-11Domain address 4-11Download 4-36Driver

infrastructure 4-20peripheral units 3-43SIU 3-47

Dump 2-61, 2-62

Dynamic memory area 4-8

EECC bus 4-25, 4-32, 4-35EEPROM driver 4-20Equipment 2-22Equipment alarm 2-12Equipment error 3-19Equipment management 2-22Error classification 4-17Event forwarding discriminator 2-7, 2-10Event report 2-6Event report management 2-5, 2-7Event report service 2-6Exception handler 4-16Exceptions 4-16Expiration timer 4-10

FFault handling

PU 3-19Fault management 2-12, 2-15FBoot process 4-15Flash EPROM driver 4-20Formatter 4-29Fragmentation 4-9Free memory 4-8From termination 2-40, 2-50

GGeneral messages 4-12Get 2-6Global services 4-5

HHardware access 3-1, 3-42Hardware component failure 2-12Hardware control 3-3Hardware driver 4-20Hardware/software relationship 1-5HDLC 4-31Heartbeat 4-17High-priority resource 2-49

IIIC bus driver 4-20Information data 4-11Infrastructure software 1-7, 4-1, 5-1, 5-3


Index 6-3

Initialisation 3-42, 4-15Instance 2-25Instantiate 2-6Interfaces 4-21Inter-Process Communication (IPC) 4-13Interrupt Service Routine (ISR) 4-13Interrupt services 4-5, 4-13IPC 4-13IS-IS routing 4-30ISR 4-13ITU-T G.783 2-56ITU-T G.811 2-55ITU-T G.812 2-56

KKAI 4-7KAL 4-6Kernel Adaptation Interface (KAI) 4-7Kernel Adaptation Layer (KAL) 4-6

LLaser control 3-47LED driver 4-20Line transmission alarm 2-31LLC sub-layer 4-31Local address 4-11Local address services 4-19Local cast 4-13Local craft terminal 1-1, 1-2Local management 4-10Local services 4-5Long-term buffer pool 4-9Low-priority resource 2-49

MMAC sub-layer 4-31Main controller (MC) 5-9Main memory 4-8Management and Communication Unit

(MCU) 1-5, 4-1, 5-1Management application function 2-1Management information tree 2-9Management Interface Library (MIL) 4-27Management task 2-6Manager address list 2-16Manager agent model 1-4Manager process 1-4MCAU 2-32MC-CC driver 4-21

MCCM 2-13, 2-17, 2-33, 2-42, 2-51, 2-56MCCO 2-23, 2-41MCEF 2-13, 2-17, 2-33, 2-42, 2-51, 2-56MCEQ 2-17, 2-22, 2-33, 2-42, 2-57MCF 4-22, 4-24MCFA 2-13, 2-23, 2-33MCFB 2-41MCI driver 4-20MCNE 2-42MCPO 2-22MCPR 2-23MCTP 2-23, 2-32MCU application software 1-6, 5-3, 5-4MCU Connection Interface (MCI) 4-20MCU event forwarding discriminator task

2-10MCU software 5-3MCU supervisory module 2-66MCU timing generator 2-59MCU-PU message service 4-18Memory management 4-4, 4-5, 4-8, 4-13Message Access Routines (MARS) 4-18Message Communication Function (MCF)

4-22, 4-24Message Interface (MCU-PU) 4-18Message queue 4-2, 4-11Message services 4-17message services 4-18MIL 4-27Multiplex structure 2-30Multitasking operation 4-11

NNaming conventions 2-3Network element 5-1Network element management 2-16Network element software 1-4Network layer 4-24Network management system 1-1, 1-2, 1-3,

2-1, 2-6, 2-11, 2-16, 4-21Node management 4-5, 4-13Notifications 2-10

OObject behaviour 1-3, 2-6Object classes 1-3, 3-5Object database 3-5, 3-44Object instance 2-18, 2-21, 2-34, 2-36Object model

PU 3-5


6-4 Index

Object state 3-7Objects 1-3Operating system 4-1, 4-3, 5-1Operating system functions 4-1Operational state 2-15, 3-7, 3-9OSI layer model 4-23, 4-24OSI model 4-22OSI protocol stack 4-22OSI stack 4-23, 4-27Overhead 2-29Overview 5-13

PPAPI 4-7Parameter error 4-16Parser 4-29Path protection switching 2-48Periodic timer 4-10Peripheral unit 2-22Peripheral units (PU) 1-5, 3-1, 4-1, 5-1Physical layer 4-24Plug-in unit 4-1Plug-in unit failure 2-12Plug-in units

card protection 2-28protected 2-28protecting 2-28

Portability 4-4PPU-1 specific software 3-39Premature and changeable data 2-62PREPC 4-4Presentation context 4-29Presentation layer 4-24, 4-28Priority 4-10Priority level 4-11Privileged API (PAPI) 4-7Process address 4-11Process interruption 4-11Process management 4-4, 4-10Processes 4-2, 4-10Processor 4-2Protected resource 2-49Protecting plug-in unit 2-28Protecting resource 2-49Protection

CCU (clock sources) 2-58, 2-60Protection group 2-28Protection management 2-48Protection switching 2-46, 3-20Protocol stack 4-22

Protocol stack (MCF) 4-25pSOS (kernel) 4-4PU 1-5PU alarm handling 3-15PU ASIC driver 3-5PU maintenance 3-4PU message services 4-18PU protection 3-20PU software 5-8PU state management 3-12PU states 3-12, 3-13

QQ interface 4-2, 4-21, 4-31, 4-35QECC interface 4-2, 4-21, 4-31Queue (cf. Message queue) 4-2

RReal time clock 4-20Recording measurement data 3-42Recovery 2-18, 2-61, 2-62, 3-11, 4-14Reference clock 2-56Releasing a connection 2-46Reliability 1-5, 4-6Remote Operation Service Element (ROSE)

4-27, 4-28Reset 2-18, 2-22Resources 3-5Retix® 4-27ROSE 4-27, 4-28

SScalar messages 4-12Session layer 4-24Set 2-6Setting up a connection 2-46Seven-layer model 4-23Shared memory 4-5, 4-7, 4-9SIG bus 4-5, 4-7SIGBusL2 4-4SIU driver 3-47SIU specific software 3-33, 3-47Size characteristics 4-8Software

MCU 2-1, 5-3peripheral units 3-1

Software concept 1-3Software configuration 5-13Software context 2-3


Index 6-5

Software Download (SWDL) 4-2, 4-36Software layers 5-1Software of the peripheral units 5-8Stack 4-22Stack environment 4-32Standby clock source 2-60State management 3-12State transition 3-10Statically allocated memory area 4-8Subnetwork connection 2-48Subsystems 1-1Suspended process 4-11Switching matrix 2-45Synchronisation error 4-16System architecture 5-1System services 1-7, 4-1, 4-3System time 4-9System time management 4-9

TTask 2-3Telecommunications Management Network

(TMN) 4-2, 4-21Termination point 2-29Time services 4-5Timer 4-5, 4-10Timer driver 4-20Timing generator management 2-55Timing marker 2-56Timing source 2-55, 2-59TIU-1 specific software 3-21TIU-3 specific software 3-24TIU-4 specific software 3-28TN-MS EC-4X 1-1To termination 2-40, 2-50TPU driver 4-20Trail termination point 2-29Transfer syntax 4-28Transient buffer pool 4-9Transmission control data 4-11Transmission failure 2-12Transmission object 2-29Transmission object alarm 2-12Transmission object management 2-29Transport layer 4-24

UUnit replacement handling 2-16, 2-26User data container 4-11

VV.24 driver 4-20Vector messages 4-12Virtual container 2-35

WWarm start 2-22, 2-27, 4-15Watchdog 4-17, 4-20Watchdog driver 4-20

XXOS 4-4, 4-5XOS and system architecture 4-4XOS structure and interfaces 4-6


Contacts Legal statements Trademarks

International Broadband Networks (Dept. 18600)Nortel LimitedOakleigh Road SouthLondon, N11 1HB

So far as Nortel Limited is aware the contents of this document are correct. However, such contents have been obtained from a variety of sources and Nortel Limited can give no warranty or undertaking and make no representation as to their accuracy. In particular, Nortel Limited hereby expressly excludes liability for any form of consequential, indirect or special loss, and for loss of data, loss of profits or loss of business opportunity, howsoever arising and whether sustained by the user of the information herein or any third party arising out of the contents of this document.

Family Product Manual Copyright Copyright statement NT confidetial DocNum DocIssue DocStatus Date Publishing statement

SDH TRANSMISSION

Nortel TN-4XSoftware Description

Copyright 1996, 1997 Northern Telecom

The copyright of this document is the property of Northern Telecom. Without the written consent of Northern Telecom, given by contract or otherwise, this document must not be copied, reprinted or reproduced in any material form, either wholly or in part, and the contents of this document, or any methods or techniques available therefrom, must not be disclosed to any other person whatsoever.

NORTHERN TELECOM CONFIDENTIAL: The information contained in this document is the property of Northern Telecom. Except as specifically authorized in writing by Northern Telecom, the holder of this document shall keep the information contained herein confidential and shall protect same in whole or in part from disclosure and dissemination to third parties and use same for evaluation, operation, and maintenance purposes only.

Document number: 323-1121-101Document issue: Release 2.4Document Status: StandardDate: February 1997Printed in England

Documents

TN-4X