TN 4X

323-1121-101
SDH TRANSMISSION
Nortel TN-4X
Software Description
Release 2.4 Standard February 1997
SDH TRANSMISSION
Nortel TN-4X
Document Number: 323-1121-101 Document Issue: Release 2.4 Document Status: Standard Product Release Number: 2.4 Date: February 1997
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.
323-1121-101 Release 2.4 Standard
TN-4X Software Description
iii
Publication history
September 1995 Release 1.7 Standard May 1996 Release 2.1.1 Standard February 1996 Release 2.4 Standard
End of chapter file
Contents
About this document Technical support and information Chapter 1: Introduction
SDH network 1-1 Basic terminology and concepts 1-3 Objects and object classes 1-3 Manager agent model 1-4 Network Element software overview 1-5 Hardware/software relationship 1-5 Building blocks 1-6 Structure of the Network Element software 1-6 Application software of the management & communication unit (MCU) 1-6 Application Software of the Peripheral Units 1-7 Infrastructure 1-7
xi xii 1-1
Chapter 2: Application software of the Management and communication unit
2-1
Overview 2-1 Structure of the management application function 2-1 Functional areas 2-1 Naming conventions and diagrams 2-3 Chapter Structure 2-4 CMIS agent and event report management 2-5 Definition of terms 2-5 Tasks of the CMIS agent and the event report management 2-7 The functions of the CMIS agent and the event report management system 2-8 Fault management 2-12 Definition of Terms 2-12 Fault management tasks 2-13 Fault management functions 2-14 Network element management 2-16 Definition of terms 2-16 Network element management task 2-16 Functions of the network element management 2-18 Equipment management 2-22 Definition of terms 2-22 Equipment management tasks 2-22 Functions of the equipment management 2-24
vi Contents Transmission object management 2-29 Definition of terms 2-29 Tasks of the transmission object management 2-32 Functions of the transmission object management 2-34 Connection management 2-39 Definition of terms 2-39 Connection management tasks 2-41 Connection management functions 2-43 Protection management 2-48 Protection management tasks 2-51 Protection management functions 2-52 Timing generator management 2-55 Definition of terms 2-55 Timing generator management tasks 2-56 Functions of timing generator management 2-58 Data restoration services 2-61 Definition of terms 2-61 Data Restoration Service Tasks 2-61 Functions of the data restoration services 2-62 Common services 2-65 Definition of terms 2-65 Common services building blocks 2-65
Chapter 3: Application software of the peripheral units

Introduction 3-1 General hardware control 3-3 Functions and Processes of the PU software 3-3 PU data handling 3-4 Unitcontroller object class 3-12 PU Alarm Handling 3-15 PU protection 3-20 Specific hardware control 3-21 TIU-1 3-21 TIU-3 3-24 TIU-4 3-28 SIU-1/4 3-33 CMU-1 3-38 PPU-1 3-39 Hardware access 3-42 General structure and function 3-43 Driver functions 3-45 Hardware access of the synchronous interface units 3-47
3-1
Contents vii
Chapter 4: Infrastructure
Introduction 4-1 System services 4-2 Structure of the system services 4-3 Operating system 4-3 Operating system functions 4-8 Basic infrastructure 4-14 Functions of the basic infrastructure software 4-15 Message services 4-17 Data block handler 4-18 Local address services 4-19 Hardware drivers 4-20 General building blocks 4-21 Communication services 4-21 Interfaces 4-21 Functions 4-22 The OSI model brief overview 4-23 Structure of the network communication 4-24 Distribution of management data 4-33 Software download 4-36
4-1
Chapter 5: MCU/PU software configuration

Introduction 5-1 Configuration of the MCU software 5-3 Overview 5-3 Building blocks employed 5-4 Configuration of the PU software 5-8 Overview 5-8 Building blocks employed 5-9 Software configuration overview 5-13
5-1
Index Figures
Figure 1-1 Figure 1-2 Figure 1-3 Figure 1-4 Figure 2-1 Figure 2-2 Figure 2-3 Figure 2-4 Figure 2-5 Figure 2-6 Figure 2-7 Figure 2-8 Figure 2-9 Figure 2-10 Figure 2-11 Figure 2-12 Figure 2-13 Figure 2-14 323-1121-101 Release 2.4 Standard
6-1
Management of regional subnetworks 1-2 Manager agent model 1-4 The network element software concept 1-5 Structure of the network element software 1-6 Tasks of the management application function 2-1 Sample functional area 2-3 Context of the sample software 2-4 Communication between NE and management system 2-5 Tasks of the CMIS agent and the event report management 2-7 Context of the CMIS agent and the event report management 2-8 Communication with the network management system 2-9 Forwarding network management commands 2-10 Fault management task 2-13 Context of fault management tasks 2-14 Network element management task 2-17 Context of the tasks of the network element management system 2-17 Completing the system start-up 2-19 Tasks of the equipment management system 2-23 TN-4X Software Description
viii Contents Figure 2-15 Figure 2-16 Figure 2-17 Figure 2-18 Figure 2-19 Figure 2-20 Figure 2-21 Figure 2-22 Figure 2-23 Figure 2-24 Figure 2-25 Figure 2-26 Figure 2-27 Figure 2-28 Figure 2-29 Figure 2-30 Figure 2-31 Figure 2-32 Figure 3-1 Figure 3-2 Figure 3-3 Figure 3-4 Figure 3-5 Figure 3-6 Figure 3-7 Figure 3-8 Figure 3-9 Figure 3-10 Figure 3-11 Figure 3-12 Figure 3-13 Figure 3-14 Figure 3-15 Figure 3-16 Figure 3-17 Figure 3-18 Figure 3-19 Figure 3-20 Figure 3-21 Figure 3-22 Figure 3-23 Figure 3-24 Figure 3-25 Figure 3-26 Figure 3-27 Figure 3-28 Figure 4-1 Figure 4-2 Figure 4-3 Figure 4-4 Figure 4-5 Figure 4-6 Figure 4-7 Figure 4-8 Figure 4-9 TN-4X Software Description Context of the equipment management 2-24 Multiplex structure 2-31 Transmission object management tasks 2-32 Context of the transmission object management 2-34 Bidirectional point-to-point connection 2-39 Subbuses in the shelf 2-41 Tasks of the connection management 2-42 Context of the connection management tasks 2-43 Protection switching of a subnetwork connection 2-48 Object approach to protection switching 2-49 Protection management task 2-51 Context of the protection management tasks 2-52 Timing generator management tasks 2-56 Context of the MCU timing generator task 2-57 MCU data restoration services building block 2-61 Context of the data restoration services tasks 2-62 Building blocks of the common services 2-65 Context of the common services 2-66 Structure of the PU software 3-2 Hardware control of the PU software 3-3 PU object-resource relationship 3-6 PU object state diagram 3-10 State diagram of the peripheral units 3-13 Alarm supervision 3-16 Alarm masking state transition diagram 3-17 Multiplexing and demultiplexing the TIU-1 3-21 Supported objects of the TIU-1 3-21 TIU-1 alarm masking 3-24 Multiplex and demultiplex path of the TIU-3 with AU-4 3-25 Supported objects of the TIU-3 3-25 TIU-3 alarm masking 3-28 TIU-4 objects in SDH mode 3-29 TIU-4 objects in PDH mode 3-29 TIU-4 alarm masking in SDH mode 3-32 TIU-4 alarm masking in PDH mode 3-33 SIU-1 objects 3-34 SIU-4 objects 3-35 SIU 1/4 alarm masking 3-37 CMU-1 object classes 3-38 CMU-1 alarm masking 3-39 PPU-1(4) objects (sink) 3-40 PPU-1(4) objects (source) 3-40 PPU-1 alarm masking 3-42 Driver building blocks of the peripheral units 3-43 Driver functions 3-46 Driver building blocks of the synchronous interface units 3-47 Infrastructure software 4-1 Basic structure of the system services 4-3 Operating system 4-3 XOS structure and interface 4-6 Communication paths in the system services 4-7 Division of the memory 4-8 Structure of a message 4-12 Basic infrastructure 4-14 Message services 4-18 323-1121-101 Release 2.4 Standard
Contents ix Figure 4-10 Figure 4-11 Figure 4-12 Figure 4-13 Figure 4-14 Figure 4-15 Figure 4-16 Figure 4-17 Figure 4-18 Figure 4-19 Figure 4-20 Figure 4-21 Figure 4-22 Figure 5-1 Figure 5-2 Figure 5-3 Figure 5-4 Local address services 4-19 Hardware drivers 4-20 General infrastructure building blocks 4-21 The communication services in the NE software 4-22 Communication via the layer model of the OSI 4-23 The protocol stack of the MCF 4-25 Building blocks of the communication services 4-26 Functional view of the block convergence functions 4-29 Point-to-point network and bus structure 4-31 The network element in the management network 4-34 Routing in the MCU 4-35 Software download 4-36 Software download: interaction of building blocks 4-38 TN-4X software architecture 5-2 Structure of the MCU software (overview) 5-3 Structure of the PU software (overview) 5-8 Configuration of the TN-4X software 5-14
Tables
Table 2-1 Table 2-2 Table 2-3 Table 3-1 Table 3-2 Table 3-3 Table 3-4 Table 3-5 Table 3-6 Table 3-7 Table 3-8 Table 4-1 Table 4-2 Table 5-1 Table 5-2 Table 5-3 Table 5-4 Plug-in unit code as part of the task name 2-3 Automatic instantiation 2-35 Automatic deletion 2-37 Processes of the hardware control 3-4 Possible alarms 3-18 Description of the TIU-1 objects 3-22 Description of the TIU-3 objects 3-26 Description of the TIU-4 objects 3-30 Description of the SIU-1/4 objects 3-35 Description of the CMU-1 objects 3-38 Description of the PPU-1(4) objects 3-41 Functions of the layers in the OSI model 4-24 The OSI stack of the MCF (message communication function) 4-27 MCU software configuration part 1: application software 5-4 MCU software configuration part 2: infrastructure 5-5 PU software configuration Main controller (MC) 5-9 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 Nortels TN-4X network element for use within a synchronous digital hierachy (SDH) bre 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 881 Telephone 0181 361 4693 FAX: 0181 945 3456 International Telephone: +44 181 361 4693 FAX: +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 network
An SDH telecommunication network can be set up with the subsystems:
0
Network Management System (NMS) TN-MS EC-4X Network Elements (NE) TN-4X Local Craft Terminal CAT-4X
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-1 Management of regional subnetworks
1-1
to superordinate network management
to other TN-4X subnetworks
Regional subnetwork
Network management server
Q interface
Regional network management NE NE

Q interface
NE
NE NE
Local craft terminal (CAT-4X) NE
The TN-4X network elements are responsible for transmitting the payload signals in the network. The conguration of the network is exible. 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.
Introduction 1-3
Basic terminology and concepts

The 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 classes The 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 dened 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 dene the object behaviour and can be assigned to an object instance during instance creation.
1-4 Introduction
Manager agent model Both 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 specic objects to the respective agent and receive a message from the agent containing the required information in return.
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-2 Manager agent model
1-2
Management operations Manager process Communication Notication Agent process
Management operations Notications Objects
e.g. within the TN-MS EC
Network element software
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.
Introduction 1-5
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 overview

Hardware/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 specic interfaces or functions and are therefore called peripheral units (PU).
Figure 1-3 The network element software concept
1-3
Network Element
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).
Unit 1 Unit 2 Unit 3 Unit 4 Unit 5 Unit 6 Unit 7 Unit 8 ... Internal communication
1-6 Introduction
Building blocks The 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 conguration contains a complete description of the software structure using the building blocks. Structure of the Network Element software The network element software (Figure 1-4) is divided into the following functional levels:
0
Application software and infrastructure.
Each plug-in unit works with its own separate application software, while the infrastructure software is used by all plug-in units.
Figure 1-4 Structure of the network element software
1-4
Application software of the management and communication unit
Application software of peripheral unit 1
...
Application software of peripheral unit n
Infrastructure System services Communication services
Application software of the management & communication unit (MCU) The MCU application software includes:
0
The internal management of the network element Provision of the agent for the network management.
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 conguration management. While fault management evaluates the ability to use the network element and the transmission link, conguration management can be used to set the transmission functionality of the network element according to the conguration data in the read-only memory or the instructions from the network management system.
Introduction 1-7
Application Software of the Peripheral Units The application software of the individual peripheral units has two main tasks:
0
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
The control and monitoring procedures are identical for all peripheral units, as common building blocks are used. For hardware access specic building blocks (e.g. hardware drivers) are required on the different plug-in units. Infrastructure The 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:
0
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.
Communication services consist of all functions that the application requires in order to communicate with external units. This includes:
0
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.
The following functions are also implemented within the communication services.
0
End of chapter file
Software download, i.e. loading the NE software from an external computer The administration of the ECC bus.
2-1
Chapter 2: Application software of the Management and communication unit

Overview
Structure 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-1 Tasks of the management application function
2-1
MCU application software NE conguration and supervision
CMIS agent and event report management
Timing generator management
Transmission object management
Connection management
Protection management
Fault management
Equipment management Network element management
Data restoration services Backup routines
Common services General routines
Functional areas The management application function (MAF) is subdivided into three blocks:
0
Conguration and supervision Data restoration services Common services.
2-2 Application software of the Management and communication unit
Conguration and Supervision The task of the Conguration 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.
The Conguration and supervision main block is subdivided into the following blocks:
0
CMIS agent and event report management Fault management Network element management Equipment management Transmission object management Connection management Protection management Timing generator management.
Data restoration services and common services The 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
Naming conventions and diagrams The individual tasks are named in accordance with the relevant naming convention. All task names consist of four characters. The rst 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).
Table 2-1 Plug-in unit code as part of the task name Plug-in unit MCU SIU PU Plug-in unit code MC SI PU (for any peripheral unit)
2
2-1
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-2 Sample functional area
2-2
Functional area
Task 1
Task 2
Routine 1
Routine 2
Procedure 1
Procedure 2
The context of the software in the individual plug-in units is illustrated in the gures 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 gure as special MAF range.
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 ow direction. As a rule, the individual tasks of the MAF correspond to precisely one building block.
Figure 2-3 Context of the sample software
2-3
MCU
Other MAF areas Spec. MAF areas Other MAF areas
Task 1
Procedure 1
MAF tasks
MAF tasks
Task 2
PU
Task 1
Task 2
Communication via a procedural interface Communication in the respective direction
Chapter Structure The 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. Denition of terms Description of the tasks and routines relevant to the respective functional area List of tasks and routines
TN-4X Software Description 323-1121-101 Release 2.4 Standard
Context of the tasks and routines

0
Functions Overview of the functions Description of the implementation of the functions.
The individual sections are structured to provide all information required for a specic 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 notications 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 notications to the network management system. Denition of terms Communication 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 notications, e.g. alarm notications. A manager request is followed by an answer (including the respective data if required). Likewise, an NE notication is followed by an acknowledgment from the management system.
Figure 2-4 Communication between NE and management system
2-4
Request
TN-4X
Response
Connection
NE notification Acknowledgments
Network element
Manager
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 dened 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 dene the object behaviour and which are permanently assigned to an object class.
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 denitions. 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.
0
Create Managed Object Delete Managed Object Action Get Attribute Value Set Attribute Value Event Report.
Event reports are notications 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. Dene 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 notications to the network management system without a request.
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 full the following functions: The MCEF task (MCU event forwarding discriminator task) forwards all notications to the respective managers The MCCN task (MCU conrmed notication task) monitors the acknowledgment of notications 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.
Figure 2-5 Tasks of the CMIS agent and the event report management
2-5
CMIS agent/event report management
MCEF
MCCM MCCN
MCCM
The MCU event forwarding discriminator task is addressed by all application software tasks that send notications 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 notications after a system recovery.
2-8 Application software of the Management and communication unit Figure 2-6 Context of the CMIS agent and the event report management
2-6
MCU
Other MAF areas CMIS agent/ Event report management Network element management
MCCM
MAF tasks
MCCN
MCNE
MCEF
The functions of the CMIS agent and the event report management system The CMIS agent and the event report management full the following functions: Converting the format of incoming and outgoing messages Forwarding the network management commands to the MAF tasks and forwarding the notications from the network elements to the network management system Organising object instances in the Management Information Tree (MIT) Administering the Event Forwarding Discriminator (EFD) Notication processing Monitoring notication acknowledgments Handling communication failures.
Format conversion of incoming and outgoing messages The message formats used by the network management system and for internal NE communication are specially designed for the specic 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.
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-7 Communication with the network management system
2
2-7
Network element Management application function CMIS agent
Communication services
MIL
Communication stack
Q interface
Network management system
Forwarding network management commands Incoming CMIS commands are forwarded to the CMIS agent rst. 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 identier and a precise specication 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 modication of the conguration data is received while the conguration 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.
323-1121-101 Release 2.4 Standard TN-4X Software Description
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-8 Forwarding network management commands
Network management command Network management command
2-8
MCCM
Answer + data (if required)
responsible task
Answer + data (if required)
Organising object instances in the MIT The 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 rst. EFD management The 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 notications 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 notications 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. Notication processing Notications 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
the forwarding of notications has been enabled by the MCU network element task (MCNE), the notication is forwarded to the MCU conrmed notication task (MCCN). The MCCN receives the notication and the respective destination from the MCEF and forwards these to the MCCM. The MCCN veries whether the notications are acknowledged by the management system within a certain period of time. If an acknowledgment is not received, the notication is sent again. All incoming notications for the MCCN are stored in a buffer. If the storage space in the network element buffer is insufcient, a communication failure will occur for the MCCN during communication with the network element. The MCCN starts a timer for each notication that it forwards to the CMIS agent. The CMIS agent then forwards the notication to the network management. The network element always transmits one notication at a time, i.e. the next notication cannot be sent until the previous notication has been acknowledged by the network management system. Monitoring notication acknowledgments The network element requires all notications to be acknowledged by all managers. The MCCN is responsible for monitoring the notication acknowledgments. The CMIS agent forwards all incoming notication acknowledgments directly to the MCCN. The MCCN starts a timer for each notication. The notication is sent again if the MCCN fails to receive an acknowledgment for this notication within the specied period of time. If an acknowledgment is not received after a notication was sent for the third time, the MCCN presumes that a failure is present in the communication with the network management system. Handling communication failures If a failure is detected in the communication with the network management system, the MCCN repeatedly transmits failure notications to the network management system via the CMIS agent. Any remaining or new notications are not transmitted. The MCCN resumes normal operation once the receipt of the failure notication is acknowledged by the network management system. Notications from the MCEF are then forwarded to the CMIS agent.
Fault management
A 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. Denition of Terms There are three types of network element alarms:
0
Transmission object alarms Equipment alarms Clock supply alarms.
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:
0
Plug-in unit hardware Communication between the peripheral units and the management and communication unit Clock supply for the peripheral units.
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 prole (ASAP). The prole comprises a list of possible alarms and their severity. The alarm severity assignment proles are stored as object instances. The following alarm severity levels are dened:
0
Critical fault Major fault Minor fault Warning Non alarmed.
A current problem list is maintained by the fault management. This current problem list contains all present alarms and the respective alarm severity levels.
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-9 Fault management task
2-9
Fault management
MCFA
The MCFA communicates with the following tasks to full 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.
2-14 Application software of the Management and communication unit Figure 2-10 Context of fault management tasks
2-10
MCU
Transmission object management Timing generator management Equipment management
MCTG MCTP
MCEQ
CMIS agent/ Event report management
Fault management
Network element management
MCNE MCCM MCFA MCEF Other tasks

Various MAF areas
PU
PUFA
POAD
Fault management functions The following functions are implemented by the fault management tasks:
0
Administration of the alarm severity assignment prole Starting fault management Terminating fault management Alarm notication processing Unit replacement handling.
Administration of the alarm severity assignment prole The alarm severity assignment prole 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 prole are retained by
the network management system if the network element must be rebooted after a failure. Starting fault management Fault 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 specic plug-in unit or transmission object, the fault task noties 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 notications for hardware failures or certain transmission objects on the plug-in unit are to be forwarded. The respective alarm notication is not forwarded to the fault task unless this was specied for this alarm. Terminating fault management The 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 notication processing The fault task receives alarm notications 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 specic peripheral unit, it noties 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 notication 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 notication is sent to the fault task. The fault task deletes the respective entry in the current problem list and sends a notication 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 handling If a plug-in unit is replaced by an identical unit or returns to operation after a warm start, the fault task receives a notication 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 notication 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.

The network element management is responsible for aspects relating to the entire network element and which must therefore be organised for all functional areas. Denition of terms The manager address list of the network element contains the addresses of network management computers that receive notications from the network element. The basic conguration with which the network elements are initialised depends on the conguration of the peripheral units. Thus, the initial conguration of a network element depends on the basic congurations of the individual plug-in units and is referred to in the following as basic conguration. Some of the objects that are contained in the basic conguration do not depend on the actual conguration, e.g. sdhNE (represents the network element as a whole) or backplane (represents the backplane of the network element). The basic conguration of the network element can be changed by the management system. All changes to the conguration are saved by the network element as commanded by the network management system. An automatic backup is performed daily at a specied time. The conguration that was saved last is regarded as the backup conguration. Network element management task Figure 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 conguration-related communication.
Application software of the Management and communication unit 2-17 Figure 2-11 Network element management task
2-11
2
MCNE
The MCNE communicates with the following tasks and building blocks to full its tasks (Figure 2-12):
0
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 notications from the MCNE task The MCEQ (MCU equipment task), which administers the hardware components of a network element The MCCF building block (MCU conguration database building block), which is responsible for conguration data handling.
Figure 2-12 Context of the tasks of the network element management system
2-12
MCU
Other MAF areas Conguration management
MAF task
MCCF
Equipment management
MCEF
MCNE MCEQ
MCCM
Communication via a procedural interface
Functions of the network element management The following functions are implemented by the task of the network element management system:
0
Controlling and completing system recovery Creating and administering object instances Coordinating conguration-data backups Resetting the network element.
Completing system start-up As 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 conguration is available for the network element. Figure 2-13 illustrates the system start-up procedure.
Application software of the Management and communication unit 2-19 Figure 2-13 Completing the system start-up
2-13
A Backup conguration does not exist
Taking over the system start-up Backup conguration exists
Completing the basic conguration
Recovering the backup conguration
Unit registration released
Backup conguration exists (complete conguration)
Basic conguration exists Plug-in units Active-Non-Managed No manager addresses Manager addresses:
Unit registration released
Network management access released F
Restart notication to the management system
Activating the units
I Event report management released E
Monitoring the notication acknowledgement
Units active Operational No manager addresses E Manager addresses
Network management access released
Network management access released F
Restart notication to the management system
Activating the units + dump G
Event report management released
I G Event report management released E
Monitoring the notication acknowledgement
Network management access released
Activating the units + dump Event report management released
Action is performed automatically by the network element Action is performed by management system command
The following description of Figure 2-13 explains the left branch (backup conguration does not exist) and subsequently the right branch (backup conguration 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 conguration does not exist. B: The MCU basic conguration is set up rst. 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 conguration, which is the sum of all of the individual basic congurations 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 conguration-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: Notication 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 conguration data backup. Right main branch: The backup conguration exists. C: The backup conguration is recovered. The complete backup conguration 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 conguration data backup.
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. G: Event report management 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: Notication acknowledgment is monitored. E: Access to the network management system is released. G: Event report management is released. Creating and administering object instances The 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 conguration data backups The conguration 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 specied time. The network element task initiates data backup if a backup conguration is not available or if the existing backup conguration does not match the actual conguration. The database building block of the MCU conguration noties the network element task upon detection of the rst mismatch between the actual network element conguration and the backup conguration. The conguration 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 notication to the network management system before the database building block saves the conguration data. The
network element task also informs the network management system upon completion of the backup procedure. Resetting the network element The 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 conguration regardless of whether or not a backup conguration is available.
Information that refers exclusively to the network element as a whole is insufcient for the network management system. Detailed information on the equipped plug-in units and their operational states is required to determine which network congurations 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. Denition of terms The 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 prole (ASAP). The prole 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 conguration that was present prior to the warm start is maintained. However, all objects are undened, i.e. the management and communication unit cannot query object attributes or receive notications. The MCU application software can dene the objects on the peripheral units individually in order to facilitate the facilitate the query of attributes and the receipt of notications. Equipment management tasks Figure 2-14 shows the tasks of the equipment management system. These tasks full 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.
Application software of the Management and communication unit 2-23 Figure 2-14 Tasks of the equipment management system
2-14
2
MCPO
MCEQ
The equipment management tasks communicate with the following tasks to full 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 notications 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.
2-24 Application software of the Management and communication unit Figure 2-15 Context of the equipment management
2-15
MCU
Transmission object management CMIS agent/ Event report management
MCTP
MCCM MCEF
MCCO MCPO MCCC
MCTG
MCEQ
Fault management
MCPR
MCFA
PU
PUAD
PUEQ
Functions of the equipment management The following functions are implemented by the equipment management tasks:
0
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 protection
Creating, administering and deleting object instances One 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 noties 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 noties 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 notication (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 fullled:
0
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.
The equipment task noties 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 noties 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 units The 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 fullled. The administration data task on the new plug-in unit receives several Dene notications 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 notication to the network management system if an EFD exists for it.
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 notication to the MCU termination point task and the network management system for each port instance that has been created. Unit replacement handling If a plug-in unit is replaced, the new unit sends a notication to the management and communication unit after start-up. The equipment task
acknowledges the receipt of the notication 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 noties 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 prole (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 notied that a plug-in unit has been replaced:
0
The MCU termination point task The MCU centralized connections task The MCU protection task The fault task The MCU timing generator task.
Handling the warm start of plug-in units From the point of view of the equipment management, a warm start of a plugin unit is handled in the same way as a unit replacement. The difference is, however, that the equipment task noties the other system tasks that a warm start, not a plug-in unit replacement, has been performed. Fault handling The fault management task informs the equipment task of all unit-related faults. If a hardware failure occurs on a plug-in unit which was classied 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 notication from the equipment task upon recovery of the fault. If the fault task noties 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 operational The equipment task noties 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 dened 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 conguration, the plug-in units of a protection group assume one of the following roles:
0
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.
By means of protection switching processes, each of these plug-in units switches to one of the following two states:
0
Active: The plug-in unit provides transmission functionality Standby: The plug-in unit is not currently providing transmission functionality, only equipment faults are monitored.
The following card protection possibilities are realised:

0
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.
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 trafc 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 trafc 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 trafc, and the protecting plug-in unit is currently active, the trafc of the protecting plug-in unit is rst switched to the plug-in unit with the status standby, before the trafc of the failed plugin 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
trafc being carried by the protecting plug-in unit is rst switched back to the original plug-in unit, and then the trafc of the failed plug-in unit is routed to the protecting plug-in unit. Card protection does not feature a facility for automatically switching trafc 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 trafc is switched to the protecting plug-in unit, and cleared when the trafc 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 reect the status of the protecting plug-in unit.

The 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. Denition of terms The following termination point types exist:
0
Trail termination point Connection termination point.
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 dened 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:
0
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 VC-12 trail termination point PDH-2 connection termination point Plesiochronous physical trail termination point PDH-140 connection termination point P-2 connection termination point P-4 connection termination point P-34 connection termination point PDH-34 connection termination point VC-3 trail termination point TU-3 connection termination point.
In addition, transmission object management is responsible for the following elements of the multiplex structure:
0
AUG administrative unit group TUG-3 tributary unit group TUG-2 tributary unit group.
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
C-12 at the P-12 connection termination point and the PDH-12 connection termination point respectively.
Figure 2-16 Multiplex structure
2-16
140 Mbit/s
C-4
3
VC-4 TUG-3
AU-4
AUG
STM-N
VC-3
34 Mbit/s 45 Mbit/s
TU-3
3 7
C-3
1
VC-3
7
AU-3
6 Mbit/s
C-2
VC-2
TU-2
TUG-2
3 4
2 Mbit/s
C-121) C-111)
VC-12 VC-11
TU-12 TU-11
Administrative unit group Virtual container Administrative (higher order) unit
Synchronous transport module
1.5 MBit/s
Tributary Container Virtual container Tributary unit Tributary unit group signal (lower order)
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 the versions C11 (1.5 MBit/s) and C12 (2 MBit/s) in this representation.
The cross-connection object pointer can be assigned to a termination point. This pointer species 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 reects 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.
Alarms that are triggered for a specic transmission object can be assigned one of several severity levels on the basis of an alarm severity assignment prole (ASAP). The prole 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 undened after a warm start, i.e. the management and communication unit cannot query object attributes or receive notications. The application software can be used to dene the objects on the peripheral units individually using a dene notication in order to facilitate the explicit query of attributes and the receipt of notications. 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):
0
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).
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-17 Transmission object management tasks
2-17
MCTP
MCAU
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 notications 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.
2-34 Application software of the Management and communication unit Figure 2-18 Context of the transmission object management
2-18
MCU
Timing generator management Transmission object management Fault management
MCTG
MCFA
MCTP
MCPO MCAU MCEQ
MCCM
MCEF
PU
PUAD
Functions of the transmission object management The following functions are implemented by the transmission object management tasks:
0
Creating object instances Administering object instances Deleting object instances.
Creating object instances The creation of transmission objects can be initiated by:
0
The creation of certain object instances A network management command.
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
shows which instances are created by the termination point task if a certain object instance is created by a certain system task.
Table 2-2 Automatic instantiation Created object instance TIU-1 tributary interface unit SIU synchronous interface unit Port on a synchronous interface unit Port on a tributary interface unit SDH physical interface TTP Plesiochronous physical trail termination point VC trail termination point Creating task Equipment task Equipment task Port task Port task Termination point task Termination point task Termination point task Automatically created instance VC-12 trail termination point (a total of 21 instances per TIU-1) Trail termination point of a regenerator section SDH physical interface trail termination point PDH physical interface TTP Connection termination point of a regenerator section PDH connection termination point P trail termination point
2-2
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 specic 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 dene 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
Three TU-12 tributary units for each TUG-2, if present.
The network management system receives a notication 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 notication from the termination point task for all newly created object instances. The fault task receives a notication for the creation of instances for:
0
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.
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 dene notication 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 dene notication for this termination point. Administering object instances The 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. Conguration data is not available on a plug-in unit after replacement or warm start. The MCU termination point task sends a dene notication to the administration data task of the affected PU after it is notied 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 identier 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
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 instances The deletion of transmission objects can be initiated by:
0
Deleting certain object instances A network management command.
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 fullled. 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.
Table 2-3 Automatic deletion
Object instance to be deleted Tributary interface unit TIU-1, TIU-3, TIU-4 Synchronous interface unit SIU Deleting task Automatically deleted instances Deletion conditions
2-3
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 No VC-4 trail termination point must be deleted No termination point provides a timing source for selection No termination point belongs to a switched connection and a bus has not been assigned
Equipment task
Transmission objects assigned to this plug-in unit
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.
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 fullled:
0
The termination point does not provide a timing source for selection A bus resource has not been allocated to the termination point.
The network management system receives a notication 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 rst. 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 notication 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):
0
The fault management task The MCU timing generator task.
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 undene notication 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.
The 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. Denition of terms Before 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 ow 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-19 Bidirectional point-to-point connection
2-19
Connection
5/6 7/8 TP-A bidirectional TP-Z bidirectional
The pointers have the following function:

0
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
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 specication. 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):
0
The ADD bus The DROP bus The SYNC bus.
The following plug-in units access the main data bus:

0
Tributary interface units (TIUs) Synchronous interface units (SIUs) Pointer processing units (PPUs) Connection matrix units (CMUs).
Figure 2-20 shows which subbus is accessed by the plug-in units, depending on the slot. The document TN-4X Equipment Conguration 323-1121-210 species the slot in which the plug-in units are to be inserted.
Application software of the Management and communication unit 2-41 Figure 2-20 Subbuses in the shelf
2-20
Shelf
DROP bus SYNC bus ADD bus
CMU
SIU
TIU
PPU
ADD/DROP busa
Write access SYNC bus Read access

a
DROP/ADD busa depending on the slot
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 specied for each slot. Connection management tasks The connection management is implemented by three tasks (Figure 2-21): The MCCO (MCU connection task), which administers the connections dened 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.
2-42 Application software of the Management and communication unit Figure 2-21 Tasks of the connection management
2-21
MCCO
MCFB
MCCC
The administration of the connections within the network element requires the connection management tasks to be connected to (see Figure 2-22):
0
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 notications 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.
Application software of the Management and communication unit 2-43 Figure 2-22 Context of the connection management tasks
2-22
MCU
2
Connection management Network element management MCNE MCEF MCFB Fault management MCCM MCCO MCFA
Equipment management MCCC MCEQ
Protection switching management MCPR
PU
PUAD
Connection management functions The following functions are implemented by the connection management tasks:
0
Creating, administering and deleting object instances Setting up a connection Releasing a connection Protection switching in the event of a connection failure Responding to equipment management messages
Creating, administering and deleting object instances After 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.
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 points
0
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.
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 species 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.
The network management system receives a notication from the connection management for every object instance that is created. It also receives a notication 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 specied 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 rst checks if the network management command is valid. The command is valid if:
0
A connection transmission object is specied in the delete command. The connection to be deleted is not assigned to a protection.
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 connection The 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 Connection A connection is released in the same logical way as it is set up. The unequipped identication 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 Failure If 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 modication 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 conrming 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 Messages The connection management receives a message from the equipment management in the following cases:
0
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.
The equipment task can only delete a plug-in unit if no connection is dened via this plug-in unit. A connection is dened if an object instance exists for this connection. The equipment task is notied by the connection task whether or not a connection is dened 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 congured for the rst time or recongured. The MCU centralized connections task is responsible for the conguration, insofar as it must have the objects that it requires for its task on the peripheral unit dened
either for the rst time or again. Therefore, handling is required for the MCU centralized connections task if the following unit types are affected:
0
Synchronous interface units (SIUs) Tributary interface units (TIUs) Pointer processing units (PPUs) Connection matrix units (CMUs)
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 dened 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 dened 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 denition are not required.
The 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-23 Protection switching of a subnetwork connection
2-23
Main line
CTP 1 bidir.
TP 3 bidir.
Standby line
CTP 2 bidir. Protection switching Network element
not switched through switched through
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.
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-24 Object approach to protection switching
2-24
Protection switching 3
1 2
16
CTP 1 bidir. 10/11
8/9
TP 3 bidir.
6 7
CTP 2 bidir.
12
13
14
15
Connection
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
Pointer 8: Downstream connectivity pointer of connection termination point 1 Pointer 9: Upstream connectivity pointer of connection termination point 1 Pointer 10: Upstream connectivity pointer of connection termination point 3 Pointer 12: From termination of the connection Pointer 13: Cross-connection pointer of termination point 1 Pointer 14: To termination of the connection Pointer 15: Cross-connection pointer of termination point 2 Pointer 16: Protection switching instance (Protected by).
According to the denition 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 specied 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 crossconnection 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
The cross-connection pointer of connection termination point 1 (pointer 13) points to the protection switching instance.
The remaining pointers remain unaffected by the execution of a protection switching measure. Protection management tasks Protection management is implemented by the MCPR (MCU protection group task) (Figure 2-25).
Figure 2-25 Protection management task
2-25
MCPR
The protection management communicates with the following tasks in order to be able to full 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.
2-52 Application software of the Management and communication unit Figure 2-26 Context of the protection management tasks
2-26
MCU
MCEF MCEQ
Protection management Connection management
MCCM
Fault management
MCPR MCCC
MCFA
PU
PUAD PUPA
Protection management functions The following functions are implemented by the protection management tasks:
0
Creating, administering and deleting object instances Performing a switching measure Responding to the planned deletion of a plug-in unit instance
Creating, administering and deleting object instances The 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 specications: Protected termination point Protecting termination point High-priority resource.
First, the MCU protection task veries whether or not the command is valid. The command is valid if:
0
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 dened between the high-priority resource and the protected termination point The dened 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 modied.
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 dened for a protection switching procedure (see page 2-5, Denition 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 notication from the MCU protection task regarding the object instance that was set up as well as all modied 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 noties the PU fault task. The network management system receives a notication from the protection management both for the deleted object instance and for every modied 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 fullled. Switching is performed if:
0
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.
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 notication from the MCU protection task for every modied 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 notication 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.
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 notication from the MCU protection task for all modied pointers and for the performed switching measure. Responding to the planned deletion of a plug-in unit instance The equipment task noties 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.

The 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. Denition of terms A 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.
The selection of a timing source for the network element clock depends on the signicance of a timing source. The signicance of a timing source depends:
0
First on the clock quality and in the case of several sources of the same quality, on the priority of the timing source.
The clock quality can assume the following values: G.811 (highest quality, ITU-T G.811 requirements are fullled)
G.812 transit (ITU-T G.812 requirements for transit node clock are fullled) G.812 local (ITU-T G.812 requirements for local node clock are fullled) SETS (Synchronous Equipment Timing Source, ITU-T G.783 requirements are fullled, internal oscillator) Unknown (lowest quality).
The priority of a timing source can be specied 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 dened 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 tasks The MCU timing generator task (MCTG) on the management and communication unit is responsible for timing generator management (Figure 2-27).
Figure 2-27 Timing generator management tasks
2-27
MCTG
The MCU timing generator task communicates with the following to full 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
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.
Figure 2-28 Context of the MCU timing generator task
2-28
MCU
MCEF MCCM MCEQ
Timing generator management Transmission object management
Fault management
MCFA
MCTP
MCTG MCMC
PU
PUAD
Functions of timing generator management The MCU timing generator task provides the following functions:
0
Creating, administering and deleting an object instance Responding to changes in the termination points Selecting the timing sources. Clock protection (CCU protection).
Creating, administering and deleting an object instance The 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 noties 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 notication from the MCU timing generator task which conrms that it is no longer necessary to administer the clock supply failures. The network management system receives the notication that the clock supply object instance no longer exists. Responding to changes in the termination points The 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,
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.
0
Clock in the SDH receive signals External timing sources Oscillator on the central clock unit (CCU)
The external list contains the following timing sources:

0
Clock in the SDH receive signals
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 noties 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 species 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).
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 rst 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 modied 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):
0
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.
In the event that the selected clock does not full 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 notication from the MCU timing generator task for all changes in the selection of the timing source. CCU protection CCU or clock protection requires the conguration 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 congured. 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.
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 recongures the CCU protection. The system is briey without a clock source while the switchover from the master clock source to the standby clock source takes place. As a result the trafc is interrupted for a brief moment (approx. 100ms).
Data restoration services

The building block Data restoration services facilitates the saving and reading of conguration data as well as the administration of this data using a backup medium. The functions of the MCU conguration database building block are implemented by means of a procedural interface and are not activated via general task communication. Denition of terms A dump saves the conguration data on the backup medium. This is accomplished using application dump procedures. These procedures read the conguration data and store the data on the backup medium. A recovery reads the conguration data from the backup medium. This is accomplished using application recovery procedures. These procedures read the conguration 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 conguration database building block. Data Restoration Service Tasks Figure 2-29 shows the MCCF building block (MCU conguration database building block) of the data restoration services. The MCU conguration database building block is responsible for the protection and recovery of the conguration data of a network element. It is the communication partner for the tasks that call up a dump or recovery.
Figure 2-29 MCU data restoration services building block
2-29
MCCF
In order to full 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 conguration data. Other MAF tasks that also call up the functions of the building block.
Figure 2-30 Context of the data restoration services tasks

MCU
Other MAF areas Data restoration services
2-30
MCCF
MAF tasks Network element management
MCNE
Functions of the data restoration services The procedures of the data restoration services implement the following functions:
0
Dumping conguration data to the backup medium Recovering conguration data from the backup medium Detecting modications to the conguration data Administering premature and changeable data Administering the backup medium.
Dumping conguration data to the backup medium Conguration data is saved as follows: The function reserves an area for the conguration 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 conguration data is stored.
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 conguration can now be used for the next recovery. The dump fails if the backup medium cannot be addressed or if insufcient storage space is available. Modifying the conguration 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 conguration data. In this case the management system can, however, repeat the dump procedure on its own. Recovering the conguration data from the backup medium The saved conguration data is read in the following steps:
0
The backup medium is scanned for the valid conguration data. The system checks that the backup medium can be used and that the saved conguration data was not changed. Reading the conguration data from the backup medium.
A recovery fails if the backup medium cannot be addressed or the valid conguration data was not found, or if the conguration on the backup medium does not correspond to the most recent network element conguration (is determined by the MCNE task). No changes are made to the conguration data by the management system during a recovery (see Figure 2-13). Detecting modications to the conguration data The 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 conguration data, this task subsequently calls up a special procedure, which then informs the network element task. If further changes are made to the conguration data, the MCCF building block does not send unnecessary additional messages to the network element task. The network element task administers the information that species whether or not the conguration set in the network element, i.e. the current conguration 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 attributeCongurationState of the network element object phase2 provides information regarding the state of the conguration. If a discrepancy between the network element conguration and the backup medium conguration is detected, the network element task changes the value of the attribute from Congured to Uncongured, using the building block MCCF. Administering the backup medium The building block administers the backup medium; it allocates or releases the backup medium storage space for the conguration data. The areas on the backup medium are administered in an efcient manner, so that superuous data build-ups are avoided, thus reducing the waiting time at the beginning of the next dump.
Common services
Common services building blocks are used by the building blocks of the area Conguration 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. Denition of terms The 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 blocks Figure 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-31 Building blocks of the common services
2-31
Common services
MSVM
XXMH
MCCR
XXXX
XXPH
In order to full their functions, these building blocks are available to other MAF tasks that call up the functions of the corresponding building block (Figure 2-32):
2-66 Application software of the Management and communication unit Figure 2-32 Context of the common services
MCU
Other MAF areas
2-32
MAF tasks
Common services
MSVM
XXMH
MCCR
XXXX
XXPH
Building block MSVM The 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 XXMH This building block converts the messages from the internal data structure to the external data structure and vice versa. Building block MCCR This 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 XXXX The building block contains
0
Initialisation routines Wrapper functions for the extended operating system XOS, for central error handling and debug functions Conversion routines for various data structures.
Building block XXPH This building block contains global type denitions for process handling.
End of chapter file
3-1
Chapter 3: Application software of the peripheral units

Introduction
The 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 rst PU software area are common in all PUs; these parts are described on page 3-3, General hardware control. Specic hardware control page 3-21 subsequently explains the special features and the specic functions of the application software of the individual PUs. The hardware access function area with the hardware-specic 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 conguration.
3-2 Application software of the peripheral units Figure 3-1 Structure of the PU software
3-1
TIU-1 application software

Hardware control PU Protection
PPU-1 application software

Hardware control
PU Alarm Handling
...
(corresponding software congurations for TIU-3, TIU-4, SIU-1/4 and CMU-1) The corresponding displays are contained in detail in Chapter 5.
PU Protection
PU Alarm Handling
PU Data Handling
PU Data Handling
Hardware access TIU-1 ASIC driver TIU-1 HW driver
Hardware access PPU-1 ASIC driver PPU-1 HW driver
Gen. PU-ASIC driver
Gen. PU-ASIC driver
Infrastructure
Application software of the peripheral units 3-3
General hardware control

Functions and Processes of the PU software The functionality of a peripheral unit depends on its specic hardware and on the implemented software features. In addition to the specic 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):
0
PU data handling PU alarm handling PU protection.
Figure 3-2 Hardware control of the PU software
3-2
PU application software
Hardware control PU Protection
PU Alarm Handling
PU Data Handling
Hardware access
These building blocks jointly implement the following fundamental tasks of the peripheral units: Conguration 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 Notication 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 notication 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
3-4 Application software of the peripheral units
PU control unit to ensure a dened state of the PU and data consistency at all times.
0
context
These functions are described on page 3-5, The PU object model in the 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.
Table 3-1 Processes of the hardware control Process PUAD PUEQ PUFA PUPA Function PU administration PU equipment supervision and maintenance PU fault and alarm Handling Supervision of termination points and generation of protection alarms Building Block PU Data Handling PU Data Handling PU Alarm Handling (Note) PU Protection
3-1
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 handling Main 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 notication when the recovery procedure has been concluded Offers the hardware and software for the management functions of the hardware controller module PU object
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.
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.
The PU object model An 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 rst 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, Specic hardware control. PU object classes The 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 specic
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-3 PU object-resource relationship
Object model
Object class:1 Instance: 1 Object class:2 Instance: 1 Object class:n Instance: 1 Object class:1 Instance: n
3-3
Resource:1 Instance: 1
Resource:1 Instance: n
SW resources
HW resources
Resource:1 Instance: 1
Resource:n Instance: 1
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 specied PU object classes are dened 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 dened 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 dened 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.
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 attributes Object 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: Conguration data attributes Conguration attributes contain the conguration information which inuences the functions of the object resource and species 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 state All 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 denes the main characteristics of an object. This applies to administration carried out by the management system, consistency between the content of object conguration attributes and the actual conguration 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:
0
Administrative state Consolidation state Operational state.
Administrative state The administrative state denes the management characteristics of a PU object class instance. The administrative state can have three values: (1) Undened 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 notications are sent from this instance to the management system. (2) Dened An object class instance which is in this state can be managed and the object attributes are accessible. All value changes made to conguration data are stored but do not inuence the conguration 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 notications sent to the management system are still disabled. (3) Active An object class instance which is in this state can be managed. The attributes of the object instance are accessible. All value changes of conguration attributes are saved and are consolidated with the conguration of the corresponding object resource. The content of the application data and alarm attributes is valid. Spontaneous notications can be sent to the management system. The administrative state can be specied by an managing unit (unit controller module) or can be changed automatically if PU error exceptions should occur. Consolidation state The consolidation state reects the consistency between the contents of the conguration attributes of an object instance and its corresponding resource conguration. This state may take two values: (1) Severed There is no consistency between the conguration attributes and the conguration of the corresponding object resource. (2) Consolidated There is consistency between the conguration attributes and the conguration 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.
Operational state The operational state reects the ability of an object instance to perform its function and provide services. This state may take two values: (1) Operational The corresponding resource of an object instance is available and provides its services in accordance with the current conguration. The validity of the contents of the application data and alarm attributes depends on the administrative state. (2) Unavailable The 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 diagram The 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 elds and the administrative states are marked with double lines.
3-10 Application software of the peripheral units Figure 3-4 PU object state diagram
Operational Consolidated 1 5 6 3 4, 5 Severed 2
3-4
Undened
Dened
Undened
6 4 3
Active
Transition events: 1: 2: 3: Power on Recoverable error exception Setting an object class to dened (only possible if PU state is set to operational, recovery) Setting an object class to undened PU state changes to recovery PU state changes to operational PU state changes to error
Undened 4: Severed Unavailable 5: 6: 7:
Transition events State 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 rst 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 dened in Figure 3-4. Instance-specic transition events An instance-specic transition event only affects one object instance. Setting an object class to Dened (3) A particular object class is dened by the management system with a special dene message that sets its administrative state to dened. A dene message is only evaluated by the peripheral unit if the PU state is Recovery or Operational. The resulting object state can be either [dened severed
operational] or [active consolidated operational] depending on the current consolidation state. Setting an object class to Undened (4) The administrative state of an object class instance can be set to undened by the management system with a special undene message. The resulting object state can be either [undened severed operational] or [undened consolidated operational] depending on the current consolidation state. Transition events that affect all object instances Changes 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 [undened 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 conguration attributes of all object instances are initialised with predened default values. However, the current conguration of the corresponding object resources (hardware resources only) is retained. Following these actions, all object instances are in the [undened severed operational] object state. PU state changes to Recovery (5) The conguration attributes of all object instances are initialised with default values if a PU state is changed to recovery; however, the current conguration of the corresponding object resources (hardware resources only) is retained. Following these actions, the administrative state is set to undened for all object instances. The resulting object state of all object instances is [undened severed operational]. PU state changes to Operational (6) The contents of the conguration data attributes of all object instances are consolidated with the conguration of their corresponding object resources if a PU state is changed to operational. All object instances with a dened administrative state are set to active. The resulting object states of all object instances are [active consolidated operational] or [undened consolidated operational].
PU state changes to Error (7) The PU hardware is set to the Power on default conguration (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 [undened consolidated unavailable]. Unitcontroller object class The 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 conguration 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 denition command. The setting of conguration 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 management The 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 conguration 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 states The PU states are associated with the general behaviour of all PU object class instances. Recovery The PU state recovery allows the conguration of the peripheral unit without inuencing the current behaviour of the object. All communication classes that are required for the conguration are enabled. Operational This is the normal operation mode of a peripheral unit. All communication classes are enabled. Disabled In this PU state the PU is deactivated as far as possible. The object state
for all instances is undened. No communication is possible except for communication class Maintenance Data; no object instances can be dened. Error The 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.
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 diagram Figure 3-5 displays the PU states and state transitions that are available:
Figure 3-5 State diagram of the peripheral units
Recoverable error exceptions
3 2
3-5
Power on reset
Hard error exceptions

8
Error Recovery 5 7 7 Disabled 7

Transition events: 1: Power on reset/ 2: Recoverable error exceptions (previous PU state = | Disabled) 3: 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 8: Error (hard error exception)
4,5 4,5 6 Operational 6
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
communication class is a specic, 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 dened 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 conguration 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 maximally isolated from the system in the error PU state. Handling of Processing errors The 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:
0
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).
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 notication after the unit controller module has been reset (warm start). PU Alarm Handling Main functions The 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 specied rule Signalling of the remaining alarms after ltering and masking at the MCU Execution of attribute change messages which are directly (i.e. without ltering 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 monitoring Alarm monitoring consists of the alarm ltering 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 ltering mechanism was introduced to reduce the rate of alarm state changes in case of intermittent failure behaviour. A special lter constant which denes the sensitivity of the lter exists for each alarm type. The alarm masking mechanism suppresses all alarm state change notications 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 dened in a masking tree. The masking tree for each PU is described on page 3-21, Specic 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-6 Alarm supervision
3-6
Masking state
Administrative state Alarm monitoring
Alarm Masking
Alarm state change notications
notied Alarm state Filtered alarm state
Current alarm state (from ASIC driver1)
Alarm Filtering
Filter counter
1) see page 3-45, section Alarm detection
The following criteria are used for alarm monitoring: Administrative state (undened, dened, 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 conguration attribute. This attribute enables the generation of alarm state change notications to be activated and deactivated for all alarm attributes of the object instance.
Masking state (ON, OFF) This indicates whether the current, ltered 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.
The output value of the alarm monitoring function is the alarm state that is saved in an alarm attribute. An alarm state change notication is generated as soon as the alarm state changes. Alarm ltering The alarm ltering function calculates the ltered alarm state according to the following procedure: The ltered alarm state is immediately set to present if the current alarm state changes from cleared to present. The ltered alarm state is only reset to cleared if the current alarm state remained cleared for at least N (N = lter constant) successive calculation periods. A new lter period is started if the alarm state changed to present within this period of time. Alarm masking The 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-7 Alarm masking state transition diagram
State transition events: 1: Administrative state changes to active Administrative state changes to undened or dened Filtered alarm state changes to present and masking state is OFF Masking state changes to OFF and ltered alarm state changes to present Filtered alarm state changes to cleared Masking state changes to ON
Administrative state = | Active
Cleared
1 2 2
2: 3: 4: 5: 5,6 6:
Cleared
3,4
Present
Administrative state = active The transitions 3, 4, 5, 6 are only performed if the alarm monitoring mechanism is activated.
3-7
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 notications to the MCU are initiated during each state transition from cleared to present and vice versa. Alarm state change notications 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 notied as present are now notied as cleared. The masking of subordinate alarm states is performed regardless of the alarm monitoring attribute of the superordinate object class. Alarms in dened or active object instances suppress subordinate alarms, even if the Alarm Monitoring conguration data attribute is set to OFF. The lter 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, Specic hardware control. Examples of possible alarms in the masking trees are displayed in Table 3-2.
Table 3-2 Possible alarms Alarm AIS BufferOverow FEBE FERF LossOfClock LOF LOM LOP LOS MAIS Meaning Alarm indication signal Buffer overow with corresponding object Far end block error Far end receive failure Loss of clock Loss of frame Loss of multiframe Loss of pointer Loss of signal Multiplex alarm indication signal
continued
3-2
Application software of the peripheral units 3-19 Table 3-2 Possible alarms (continued) Alarm PAIS SD SL Meaning Path alarm indication signal Signal degrade Signal label mismatch
end
3-2
Fault handling One of the main functions of the peripheral unit software is the handling of errors. A distinction is made between three classes of errors:
0
Transmission error Equipment error Processing error.
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 error Transmission 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 inuence 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 notied of all changes in the alarm state, depending on the object conguration. Equipment error Equipment 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
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 ash 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:
0
Clock failure Missing connection interface.
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 notied of all changes in the alarm state, depending on the object conguration. 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 fullled: (1) (2) (3) (4) The alarm is classied as a protection switching alarm and changes to present state Alarm monitoring is activated for the object instance Protection switching monitoring is activated for the object instance Protection alarm notications are permissible on the PU.
Specic hardware control

This section describes the specic functions and object classes of the peripheral units as well as any existing special object features and special processes. TIU-1 Functional description The 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-8 Multiplexing and demultiplexing the TIU-1
Backplane STM-1 AUG AU-4 VC-4
3-8
21 signals Plesiochronous 2 Mbit/s
C-12
VC-12
TU-12
TUG-2
TUG-3
Object classes The available objects of the TIU-1 are described in Figure 3-9 and listed in Table 3-3.
Figure 3-9 Supported objects of the TIU-1
Protection InputBus
3-9
AU4CTP
TU12CTP
VC12TTP
P12CTP
PDH2CTP Source
PPITTP Source 21 PPITTP 21 TimingSource 21 Sink
Sink
16 InputBus Protection OutputBus 2 16 OutputBus
Sink
Sink
63
21
21
Sink
21
AU4CTP Source
TU12CTP Source
VC12TTP Source
P12CTP Source
PDH2CTP
21
21
21
21
Transmission direction Connection 1 Max. number of object instances
UnitEquipment
UnitController
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
Sink
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-3 Description of the TIU-1 objects Object AU4CTPSink Resource AU-4 connection termination point in transmit direction (MSA, HPOM), multiplex section adaptation, higher-order path overhead monitoring AU-4 connection termination point in receive direction (MSA, HUG), multiplex section adaptation TU-12 connection termination point in transmit direction (HPA, LCS), higher-order section adaptation, monitoring of the VC-12 for parity or bit errors TU-12 connection termination point in receive direction (HPA, LUG), higher-order section adaptation, monitoring without payload signal VC-12 trail termination point in transmit direction (LPT), lower-order path termination VC-12 trail termination point in receive direction (LPT), lower-order path termination P-12 connection termination point in transmit direction (LPA), lower-order path adaptation P-12 connection termination point in receive direction (LPA), lower-order path adaptation PDH-2 connection termination point of the plesiochronous monitoring function in receive direction PDH-2 connection termination point of the plesiochronous monitoring function in transmit direction PDH trail termination point in receive direction, plesiochronous input port PDH trail termination point in transmit direction, plesiochronous output port Timing source quality monitoring, timing marker monitoring and clock recovery Bus signal from the backplane which has the capacity of an STM-1
continued
3-3
AU4CTPSource TU12CTPSink
TU12CTPSource
VC12TTPSink VC12TTPSource P12CTPSink P12CTPSource PDH2CTPSink PDH2CTPSource PPITTPSink PPITTPSource TimingSource InputBus
Application software of the peripheral units 3-23 Table 3-3 Description of the TIU-1 objects (continued) Object ProtectionInputBus OutputBus ProtectionOutputBus UnitEquipment UnitController Resource Protection bus signal from the backplane which has the capacity of an STM-1 Bus signal to the backplane which has the capacity of an STM-1 Protection bus signal to the backplane which has the capacity of an STM-1 Transmission hardware which is provided on the peripheral unit Unit controller module
end
3-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 dened 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 lter and alarm masking The general behaviour of the alarm ltering 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.
3-24 Application software of the peripheral units Figure 3-10 TIU-1 alarm masking
Transmit direction
Possible alarms Possible alarms
3-10
Receive direction
LossOfClock
UnitEquipment
LossOfClock
UnitEquipment
LOF
InputBus
LOP
AU4CTP Sink
LOP
TU12CTP Sink
SL
VC12TTP Sink
LOS
PPITTP Sink
Buffer overow
P12CTP Sink
Buffer overow
P12CTP Source
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 processes A 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-3 Functional description The 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.
Application software of the peripheral units 3-25 Figure 3-11 Multiplex and demultiplex path of the TIU-3 with AU-4
3-11
Backplane
STM-1
AUG
AU-4
VC-4
6 signals Plesiochronous 34 Mbit/s
C-3
VC-3
TU-3
TUG-3
3
Object classes The available TIU-3 objects are illustrated in Figure 3-12 and listed in Table 3-4.
Figure 3-12 Supported objects of the TIU-3
3-12
Protection InputBus 2
AU4CTP Sink
TU3CTP
VC3TTP
P3CTP
PDH34CTP Source
PPITTP Source 6 PPITTP Sink 6
Sink
Sink
16 InputBus
Sink 6
Protection OutputBus 2 16 OutputBus
AU4CTP TU3CTP Source Source
VC3TTP Source
P3CTP Source
PDH34CTP
UnitEquipment
UnitController
Transmission direction Connection 1 Max. number of object instances
Sink 6
3-26 Application software of the peripheral units Table 3-4 Description of the TIU-3 objects Object AU4CTPSink AU4CTPSource TU3CTPSink Resource AU-4 connection termination point in transmit direction (MSA, HPOM), multiplex section adaptation AU-4 connection termination point in receive direction (MSA, HUG), multiplex section adaptation TU-3 connection termination point in transmit direction (HPA, LPOM), higher-order section adaptation, low-order path monitoring TU-3 connection termination point in receive direction (HPA, LUG), higher-order section adaptation, path monitoring without payload signal VC-3 trail termination point in transmit direction (LPT), lower-order path termination VC-3 trail termination point in receive direction (LPT), lower-order path termination P-3 connection termination point in transmit direction (LPA), lower-order path adaptation P-3 connection termination point in receive direction (LPA), lower-order path adaptation PDH-34 connection termination point of the plesiochronous monitoring function in receive direction PDH-34 connection termination point of the plesiochronous monitoring function in transmit direction PDH trail termination point in receive direction, plesiochronous input port PDH trail termination point in transmit direction, plesiochronous output port Bus signal from the backplane which has the capacity of an STM-1 Protection bus signal from the backplane which has the capacity of an STM-1 Bus signal to the backplane which has the capacity of an STM-1 Protection bus signal to the backplane which has the capacity of an STM-1 Transmission hardware available on the peripheral unit
continued
3-4
TU3CTPSource
VC3TTPSink VC3TTPSource P3CTPSink P3CTPSource PDH34CTPSink PDH34CTPSource PPITTPSink PPITTPSource InputBus ProtectionInputBus OutputBus ProtectionOutputBus UnitEquipment
Application software of the peripheral units 3-27 Table 3-4 Description of the TIU-3 objects (continued) Object UnitController Resource Unit controller module
end
3-4
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 lter and alarm masking The general behaviour of the alarm ltering 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.
3-28 Application software of the peripheral units Figure 3-13 TIU-3 alarm masking
Transmit direction Receive direction
3-13
Possible alarms
Possible alarms
LossOfClock
UnitEquipment
LossOfClock
UnitEquipment
BusLOF
InputBus
LOP
AU4CTP Sink
LOP
TU3CTP Sink
LOS
PPITTP Sink
SL
VC3TTP Sink
LOF
PDH34CTP Sink
Buffer overow
P3CTP Sink
Buffer Overow
P3CTP Source
Special processes A 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-4 Functional description The 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 classes The available TIU-4 objects are illustrated in Figure 3-14 (SDH) or Figure 3-15 (PDH) and are listed in Table 3-5.
Application software of the peripheral units 3-29 Figure 3-14 TIU-4 objects in SDH mode
Protection OutputBus ElectricalSPITTP RSTTP MSTTP AU4CTP [VC4TTP]
3-14
Sink
Sink
Sink
Sink
Sink
2 4 QutputBus
TimingSource
4 ElectricalSPITTP Source RSTTP Source MSTTP AU4CTP Source [VC4TTP]
Protection InputBus
Source
Source
4 InputBus
UnitEquipment
UnitController Transmission direction Connection
Max. number of object instances
Figure 3-15 TIU-4 objects in PDH mode

Protection InputBus AU4CTP VC4TTP P4CTP PDH140CT Source PPITTP Source
3-15
Sink
Sink
4 Protection OutputBus InputBus
Sink 4
AU4CTP Source 2
VC4TTP Source
P4CTP Source
PDH140CT
PPITTP
Sink
4 OutputBus
UnitEquipment
UnitController Transmission direction Connection
Max. number of object instances
Sink 4
3-30 Application software of the peripheral units Table 3-5 Description of the TIU-4 objects Object Electrical SPITTPSink Electrical SPITTPSource RSTTPSink RSTTPSource MSTTPSink MSTTPSource AU4CTPSink Resource SDH physical interface trail termination point in receive direction, SDH input port SDH physical interface trail termination point, SDH output port Trail termination point of the regenerator section in receive direction (RST) Trail termination point of the regenerator section in transmit direction (RST) Trail termination point of the multiplex section in receive direction (MST) Trail termination point of the multiplex section in transmit direction (MST) AU-4 connection termination point in receive direction (MSA, HPOM), multiplex section adaptation, higher-order path overhead monitoring AU-4 connection termination point in transmit direction (MSA, HUG), multiplex section adaptation path overhead monitoring without payload signal VC-4 trail termination point in receive direction (LPT), higher-order path termination VC-4 trail termination point in transmit direction (HPT), higher-order path termination P-4 connection termination point in transmit direction (HPA), higher-order section adaptation P-4 connection termination point in receive direction (HPA), higher-order section adaptation PDH-140 connection termination point of the plesiochronous monitoring function in receive direction PDH-140 connection termination point of the plesiochronous monitoring function in transmit direction PDH-2 trail termination point in receive direction, plesiochronous input port PDH-2 trail termination point in transmit direction, plesiochronous output port
continued
3-5
AU4CTPSource
VC4TTPSink VC4TTPSource P4CTPSink P4CTPSource PDH140CTPSink PDH140CTPSource PPITTPSink PPITTPSource
Application software of the peripheral units 3-31 Table 3-5 Description of the TIU-4 objects (continued) Object TimingSource InputBus ProtectionInputBus OutputBus ProtectionOutputBus UnitEquipment Communication Controller UnitController Resource Timing source quality monitoring, timing marker monitoring and clock recovery Bus signal from the backplane which has the capacity of an STM-1 Protection bus signal from the backplane which has the capacity of an STM-1 Bus signal to the backplane which has the capacity of an STM-1 Protection bus signal to the backplane which has the capacity of an STM-1 Transmission hardware available on the peripheral unit Communication controller Unit controller module
end
3-5
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 dened. 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 dened: STM-1 number 1: subbus 0,1,2,3 STM-1 number 2: subbus 4,5,6,7 STM-1 number 3: subbus 8,9,10,11 STM-1 number 4: subbus 12,13,14,15
0
OutputBus as for the InputBus object
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 dened 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.
TimingSource All four instances can be dened but only one is enabled.
Alarm ltering and alarm masking The general behaviour of the alarm ltering 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-16 TIU-4 alarm masking in SDH mode
Receive direction Transmit direction
3-16
Possible alarms
Possible alarms
LossOfClock
UnitEquipment
LossOfClock
UnitEquipment
LOS
Electrical SPITTP Sink
BusLOF
InputBus
LOF
RSTTP Sink
AIS
MSTTP Sink
LOP
AU4CTP Sink
LOM
VC4TTP Sink
Application software of the peripheral units 3-33 Figure 3-17 TIU-4 alarm masking in PDH mode
Transmit direction Receive direction
3-17
Possible alarms
Possible alarms
LossOfClock
UnitEquipment
LossOfClock
UnitEquipment
BusLOF
InputBus
LOS
PPITTP Sink
LOP
AU4CTP Sink
LOF
PDH140CTP Sink
SL
VC4TTP Sink
Buffer overow
P4CTP Sink
SIU-1/4 Functional description The 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.
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 classes The 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.
3-34 Application software of the peripheral units Figure 3-18 SIU-1 objects
ProtectionOutputBus OpticalSPITTP Sink RSTTP Sink MSTTP Sink AU4CTP Sink [VC4TTP] Sink 2 16 OutputBus
3-18
1 TimingSource
1 OpticalSPITTP Source RSTTP Source MSTTP Source AU4CTP Source [VC4TTP] Source
ProtectionInputBus
16 InputBus
ClockSource
Communication Controller
UnitEquipment
UnitController
Transmission direction Connection Max. number of object instances
Application software of the peripheral units 3-35 Figure 3-19 SIU-4 objects
ProtectionOutputBus OpticalSPITTP Sink RSTTP Sink MSTTP Sink AU4CTP [VC4TTP] 2
3-19
Sink
1
TimingSource
Sink 4
16 OutputBus
3
2
1 OpticalSPITTP Source RSTTP Source MSTTP Source AU4CTP Source [VC4TTP] Source
ProtectionInputBus
16 InputBus
ClockSource
Communication Controller
UnitEquipment
UnitController
Transmission direction
Connection Max. number of object instances
Table 3-6 Description of the SIU-1/4 objects Object Optical SPITTPSink Optical SPITTPSource RSTTPSink RSTTPSource MSTTPSink Resource SDH physical interface trail termination point in receive direction, optical signal input port SDH physical interface trail termination point in transmit direction, optical signal output port Trail termination point of the regenerator section in receive direction (RST) Trail termination point of the regenerator section in transmit direction (RST) Trail termination point of the multiplex section in receive direction (MST)
continued
3-6
3-36 Application software of the peripheral units Table 3-6 Description of the SIU-1/4 objects (continued) Object MSTTPSource AU4CTPSink Resource Trail termination point of the multiplex section in transmit direction (MST) AU-4 connection termination point in receive direction (MSA, HPOM), multiplex section adaptation, higher-order path overhead monitoring AU-4 connection termination point in transmit direction (MSA, HUG), multiplex section adaptation, path monitoring without a payload signal VC-4 trail termination point in receive direction (HPT), higher-order path termination VC-4 trail termination point in transmit direction (HPT), higher-order path termination Timing source quality monitoring, timing marker monitoring and clock recovery Central clock source Bus signal from the backplane which has the capacity of an STM-1 Protection bus signal from the backplane which has the capacity of an STM-1 Bus signal to the backplane which has the capacity of an STM-1 Protection bus signal to the backplane which has the capacity of an STM-1 Transmission hardware available on the peripheral unit Communication controller Unit controller module
end
3-6
AU4CTPSource
VC4TTPSink VC4TTPSource TimingSource ClockSource InputBus ProtectionInputBus OutputBus ProtectionOutputBus UnitEquipment Communication Controller UnitController
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 dened. 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 lter and alarm masking The general behaviour of the alarm ltering 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-20 SIU 1/4 alarm masking
Possible alarms
3-20
Receive direction
UnitEquipment
Possible alarms
Transmit direction
UnitEquipment
LossOfClock
LossOfClock
LOS
Optical SPITTP Sink
BusLOF
InputBus
LOF
RSTTP Sink
AIS
MSTTP Sink
LOP
AU4CTP Sink
LOM
VC4TTP Sink*
* Object class is optional
CMU-1 Functional description The 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 Classes The available CMU object classes are illustrated in Figure 3-21 and listed in Table 3-7.
Figure 3-21 CMU-1 object classes
InputBus SwitchMatrix 16 ProtectionInputBus 16 2 UnitEquipment UnitController 16 ProtectionOutputBus OutputBus
3-21
Table 3-7 Description of the CMU-1 objects Object InputBus ProtectionInputBus OutputBus ProtectionOutputBus SwitchMatrix UnitEquipment UnitController Resource Bus signal from the backplane which has the capacity of an STM-1 Protection bus signal from the backplane which has the capacity of an STM-1 Bus signal to the backplane which has the capacity of an STM-1 Protection bus signal to the backplane which has the capacity of an STM-1 Functionality of the switching matrix with complete connectivity for an STM-1 Transmission hardware available on the peripheral unit Unit controller module
3-7
Alarm lter and alarm masking The behaviour of the alarm lter 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-22 CMU-1 alarm masking
Possible alarms
3-22
LossOfClock Bus LOF InputBus
UnitEquipment Bus LOF ProtectionInputBus
PPU-1 Functional description The 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 classes The available PPU-1 object classes are illustrated in Figure 3-23 (Sink) and Figure 3-24 (Source) and are listed in Table 3-8.
3-40 Application software of the peripheral units Figure 3-23 PPU-1(4) objects (sink)
3-23
TU3CTP Sink ProtectionInputbus AU4CTP Sink 2 4 InputBus VC4TTP TU12CTP Sink Sink 252 12 4 4 UnitEquipment UnitController Transmission direction Connection 1 1 1 Max. number of object instances
Figure 3-24 PPU-1(4) objects (source)
3-24
TU3CTP Source 12 AU4CTP 2 4 OutputBus Source VC4TTP Source TU12CTP Source 252 4 4
ProtectionOutputbus
Application software of the peripheral units 3-41 Table 3-8 Description of the PPU-1(4) objects Object AU4CTPSink Resource AU-4 connection termination point (MSA, HPOM), multiplex section adaptation, higher-order path overhead monitoring AU-4 connection termination point (MSA, HUG), multiplex section adaptation, path monitoring without a payload signal VC-4 trail termination point (HPT), higher-order path termination VC-4 trail termination point (HPT), higher-order path termination TU-3 connection termination point (HPA, LPOM or LCS), higher-order section adaptation, lower-order path monitoring TU-3 connection termination point direction (HPA, LUG), higher-order section adaptation, path monitoring without a user signal TU-12 connection termination point (HPA, LCS), higherorder section adaptation, monitoring of the VC-12 for parity or bit errors TU-12 connection termination point (HPA, LUG), higherorder section adaptation, path monitoring without a user signal Bus signal from the backplane which has the capacity of an STM-1 Protection bus signal from the backplane which has the capacity of an STM-1 Bus signal to the backplane which has the capacity of an STM-1 Protection bus signal to the backplane which has the capacity of an STM-1 Transmission hardware available on the peripheral unit Unit controller module
3-8
AU4CTPSource
VC4TTPSink VC4TTPSource TU3CTPSink
TU3CTPSource
TU12CTPSink
TU12CTPSource
InputBus ProtectionInputBus OutputBus ProtectionOutputBus UnitEquipment UnitController
Alarm lter and alarm masking The general behaviour of the alarm ltering 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-25 PPU-1 alarm masking
Possible alarms
3-25
LossOfClock
UnitEquipment
BusLOF
InputBus
ProtectionInputBus
BusLOF
LOP
AU4CTP Sink
LOM
VC4TTP Sink
LOP
TU12CTP Sink
TU3CTP Sink
LOP
Hardware access
The hardware access function area facilitates access to the unit-specic hardware building blocks used by the PUs for transmission. These building blocks are usually implemented as ASICs (application specic integrated circuits). This hardware access is necessary for the following functions:
0
Initialisation of the hardware with default values during a warm start Setting the hardware in accordance with external conguration 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.
Alarm ltering and alarm masking is executed in the PU alarm handling function block of the hardware control.
General structure and function This 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. Structure The 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-specic ASIC driver which performs the specic driver functions for the respective PU on a logical level. Each PU contains a unit-specic hardware driver for immediate access to the hardware register. This hardware driver carries out the unit-specic ASIC driver requests.
Figure 3-26 Driver building blocks of the peripheral units
3-26
General PU-ASIC driver
Unit-specic ASIC driver
Unit-specific hardware driver
ASIC
The general PU ASIC driver contains:

0 0
The process frame which regularly calls up the unit-specic ASIC driver Basic functions for the object classes that are not located on the special ASIC driver Globally used functions.
The unit-specic ASIC driver comprises

0
The object database Exported functions for access to the object database Internal functions for alarm detection Internal functions for recording application data Unit-specic functions.
The unit-specic hardware driver contains

0
The memory structure of the ASIC register Complex hardware access functions.
Object database Communication 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-specic 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:
0
Management data: object classes and object states Conguration data Alarm data Application data
The driver uses the object state to determine if the conguration data is valid and if it is to be transferred to the ASICs. The stored conguration data in the object database becomes valid if an object reaches the dened state, i.e. after the set-up call in the transmission hardware. When an object is dened, alarm monitoring for this object is started accordingly.
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 conicts with other processes that also access this data. Driver functions ASIC set-up The driver initiates a separate set-up routine for each object class. This routine is dened in the object database in accordance with the conguration data. This action is performed if the object class changes to operational state or the object class is in operational state and the conguration data changes. Application data The recording of application data is an independent process that handles measurement data. The process calls up a function within a dened 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 detection Alarm detection is an independent process. The process polls the hardware register for alarm states within a dened 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 unltered state (cleared or present) since the last recording. The alarm state change ag indicates whether the alarm has changed from cleared to present or vice versa since the last time interval. This enables briey occurring alarms to be easily reported to the PU alarm handling building block. The driver sets the application ag during the initialisation phase of the object database or when an object changes to the undened state.
The object data base informs the PU alarm handling mechanism of changed alarm. This building block is responsible for the alarm ltering and alarm handling mechanisms. The principle of ltering 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.
3-46 Application software of the peripheral units Figure 3-27 Driver functions
General PU-ASIC driver Alarm polling
3-27
Recording of application data
Alarm detection
Routine for updating the alarm data
Unit-specic ASIC driver and hardware driver Alarm register ASIC #1 Routine for polling alarm states
ASIC #n
Routine for calculating the current value
ASIC driver object database Administrative data Conguration data Application data Alarm data
Set-up functions
Hardware control for the application PU alarm handling
Alarm polling Call-up procedure Data access Function Process
Fault detection Each unit-specic 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.
Hardware access of the synchronous interface units Due 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-28 Driver building blocks of the synchronous interface units
3
3-28
Hardware access of SIUs
CCUX3HW
CCUCtrl
TIU-4 TIU-3 SIPU ASIC driver
SITI
SILA
SIHW
APDCtrl
Gen. PU ASIC driver
ADC
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:
0
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.
The SIHW building block contains:

0
The memory structure of the ASIC register Complex hardware access functions.
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).

0
End of chapter file
4-1
Chapter 4: Infrastructure
Introduction
The 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 classication of individual building blocks can be found in Chapter 5 MCU/PU software conguration. The infrastructure software is divided into system services and communication services according to the main functions (see Figure 4-1).
Figure 4-1 Infrastructure software
4-1
Application software of the management and communication unit
Application software of peripheral unit 1
...
Application software of peripheral unit n
Infrastructure System services Communication services
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
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).
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 efciently, particularly with regard to the computer capacity and the conguration 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
Structure of the system services The 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:
0
Basic infrastructure Message services Data block handler Local address services Hardware driver Other building blocks.
These areas are described in the following chapters.

Figure 4-2 Basic structure of the system services
4
4-2
System services
Operating system Basic infrastructure Message services Data block handler Local address services Other building blocks
Hardware drivers
Operating system This function area consists of the following building blocks (see Figure 4-3):
Figure 4-3 Operating system
Operating system XOS
4-3
SIGBus L2 PREPC pSOS
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 congurations 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 insufcient 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 pSOS pSOS 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
Message queues (communication primitives) Semaphores (synchronisation primitives) Time services Interrupt services.
Tasks of the XOS While 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 specic process. A local service has no information pertaining to other processes and is therefore unable to communicate with them. Local services are:
0
Timer management: A corresponding message is sent using the timer functions to the initiating process after a specied 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).
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-4 XOS structure and interface
KAI CAPI +PAPI
4-4
XOS
Application programmers interface (API)

Local services Global services
Memory management
Time management
IPC
Kernel adaptation layer (KAL)
CSG
Node management Shared memory transmission SIG bus transmission
Timer administration
pSOS
Infrastructure 4-7
Interfaces to the operating system Communication 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 difcult 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 paths The 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-5 Communication paths in the system services
Singleprocessor plug-in unit Multiprocessor plug-in unit
4-5
SIG bus
Shared memory
pSOS
pSOS
pSOS
4-8 Infrastructure
Operating system functions Memory management The 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 plugin 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 units 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, conguration 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 specied by the conguration data (though they can be modied). Each block pool consists of a number of blocks of the same size; the quantity of blocks as well as their size are also specied by the corresponding conguration data.
Figure 4-6 Division of the memory

Block pools Blocks
4-6
Allocate once pool
Buffer pools
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.
Infrastructure 4-9
The division of the memory in xed 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:
0
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.
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 congured during the initialisation of the network element. The application cannot inuence the conguration during operation. The kernel application interface (KAI, see page 4-7, Interfaces to the operating system) is used for this conguration. 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 management In 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:
0
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.
4-10 Infrastructure
Timer The 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 specied 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 specied. 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.
The XOS sends a message (see above) to the process after the specied time expires or is reached. The timer messages have priority over all other messages, i.e they are put in the rst 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 nish 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 reconguration). 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
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.
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 addresses The 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 sufcient for identication. The plug-in unit is also specied by the domain address; allowing the process to be explicitly addressed. The denition of domains as well as the specication 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 denition. Message transmission The 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 sufcient 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.
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-7 Structure of a message
Sender Receiver Message data Information
4-7
Contents of the information block in - Scalar messages: - Vector messages: Data Address of a data block
- General messages:
Address of the beginning of a data structure
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.
Infrastructure 4-13
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 sufcient. This simplies the procedure, particularly in the initialisation phase. In addition, a message can be sent simultaneously to several different processes (broadcasting).
Interrupt services The 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 fullled 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 trafc 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 infrastructure The 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-8 Basic infrastructure
4-8
Basic infrastructure FBoot
Exception handler BLIB
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
Infrastructure 4-15
Functions of the basic infrastructure software Initialisation The 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:
0
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.
The cold start is permanently congured in the boot PROM. The cold start process checks the various memories (PROM, RAM, Flash EPROM) and the unit-specic hardware elements, carries out the basic initialisation of the plug-in unit and then initiates the warm start. A warm start occurs:
0
After a successful cold start Upon the instruction of the exception handler.
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 rst 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 handler The 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 circuit
0
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
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).
Exceptions detector The 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:
0
Identication Localisation Classication Additional information.
Identication and localisation provide accurate information concerning the type and source of an exception. The identied 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
The exception handler also receives a classication of the message from the detector message:
0
Informing message for insignicant 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.
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 handler An exception is either ignored (informing or warning messages) or processed in one of the following actions according to its classication: 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 inuence on the network element despite the failure.
If an error classied as severe is not eliminated after a warm start, the exception handler assumes, contrary to the classication 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-9 Message services
4-9
Message Services
MCU-PU message PU message interface
MCU-PU message service PU The building block MCU-PU message service is responsible for interprocess 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.)
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 handler This 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.
Infrastructure 4-19
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 modied (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 services If 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-10 Local address services
4-10
Local address services AETable
Local environment Local address service
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.
4-20 Infrastructure
Hardware drivers System 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-11 Hardware drivers
Hardware drivers
4-11
Watchdog MCMC
EEPROM
Flash EPROM RTC
IIC driver V.24 driver
SW Clock LED driver
MC-CC driver1 TPU driver2
EEPROM
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
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 ash 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 mans button in railway trafc: 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.
Infrastructure 4-21
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).
General building blocks This area consists of three globally used building blocks of the infrastructure software (see Figure 4-12):
Figure 4-12 General infrastructure building blocks
General building blocks General include les Coding Standards EEPROM administration
4-12
The building block general include les provides global constants and denitions that are used, for example, to ensure that coding standards are maintained. The building block coding standards provides include les which ensure that coding standards are maintained. EEPROM management administers the data stored on the EEPROM of the backplane of the shelf.
Communication services
Interfaces 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 dened as QECC interface.
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)
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. Functions The 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-13 The communication services in the NE software
4-13
Communication Services MCF

MIL Stack SW Download
Communication drivers
Infrastructure 4-23
The OSI model brief overview The 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-14 Communication via the layer model of the OSI
4-14
Application
Application
7 6 5 4 3 2 1 Unit A
OSI stack
7 6 5 4 3 2 1 Unit B
Physical connection
The following table can only provide a brief overview of the tasks of the models 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 specied in a variety of other standards.
4-24 Infrastructure
Table 4-1 Functions of the layers in the OSI model Applicationrelated services 7 Application layer
4-1
Direct application support, connection setup to the communication partner (on application level), remote invocation of functions
Presentation layer Uniform representation of information, i.e. conversion of data structures (from the application standpoint) to transportable structures and vice versa Session layer Organisation and control of the dialogue between the communicating partners (e.g. conference calls) Reliable and efcient data transport between the communicating partners via guaranteed point-to-point connection Path selection and routing to the destination system, segmentation and lling, ow control Setup and release of individual reliable transmission channels, error control, detection and elimination, ow control Mechanical (functional) and electrical control of the bit transmission (hardware)
Transportrelated services
Transport layer
Network layer
Data link layer
Physical layer
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 communication Structure of the MCF The 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 specications for open system communication (OSI layer model, see Figure 4-13).
Infrastructure 4-25
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
Message Communication Function MIL
Application layer
Presentation layer
OSI protocol stack
Session layer
Transport layer
Network layer Data link layer Q Data link layer QECC1 Data link layer
ECC BUS
QECC1
CAT-4X
NMS
other NE1
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.
Layer implementation The function and implementation of the common upper layers correspond to ITU-T specications for the OSI model (see page 4-23, The OSI model brief overview). They are implemented using ported and - wherever necessary - modied products from Retix. Figure 4-16 shows the building block structure of the communication services.
4-26 Infrastructure Figure 4-16 Building blocks of the communication services

MCF
CM MIL Pres MIL MILPXOS BAS CEC Stack General Retix Components RtxUppInc RtxLowInc System RtxComInc RtxRouterInc TP4 ISISMgmt TPInterface ISISRtgIT RouterUpper TP4IT ISISRfoIT RouterLower LLC1 StackProtection StackUpperIT StackInit StackUtilities Upper PHASEStackEnv ROSE ACSE Stack Environment StackEnv
4-16
Communication drivers ECC bus driver MCU802MAC driver QECCR driver1
1) Only used on communication controller (SIU, TIU-4)
Infrastructure 4-27
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.
Table 4-2 The OSI stack of the MCF (message communication function) OSI layer Application layer (layer 7) Implementation CMISE (Common Management Information Service Element) ROSE (Remote Operation Service Element) Building blocks CM ROSE Standard ISO 9595, ISO 9596 ISO 8822, ISO 8823 ISO 8549, ISO 8650 ISO9072.1, ISO 9072.2 ISO 8824, ISO 8825 ISO 8326, ISO 8327 ISO 8073
4-2
ACSE (Association Control Service ACSE Element) Presentation layer (layer 6) Presentation service ASN.1 (Abstract Syntax Notation One) Pres Upper BAS TP4, TPInterface, TP4IT {ISISMgmt, ISISRfoIT, ISISRtgIT, RouterUpper, RouterLower} ECC bus driver, QECCr
Session layer Session service (layer 5) Transport layer (layer 4) Transport service class 4
Network layer Connectionless network layer (layer 3)
ISO 8473 (CLNP) ISO 10589 (IS-IS) ISO 9542 (ES-IS) in acc. withG.784, Q.921
Data link layer for QECC interface: LAPD protocol (HDLC method) (layer 2)
for Q interface: - LLC sub-layer (logical link control) LLC1 ISO 8802.2 - MAC sub-layer (media access MCU802MAC control) with CSMA/CD method. ISO 8802.3
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
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 specied 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:
0
The Common Management Information Service Element (CMISE) The Remote Operation Service Element (ROSE) and The Association Control Service Element (ACSE).
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 sufcient 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 rst be dened 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
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 dened context set (DCS) refers to the sum of all dictionaries dened in the presentation layers of the affected communication partners. The appropriate presentation context is specied 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-17 Functional view of the block convergence functions
Upper interface Structure converter
4-17
Abstract syntax
Translator Formatter Parser DCS Administration
Transfer syntax
Lower interface
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 specied presentation
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 specied 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 rst 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 efciently 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 identication 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.
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
CLNP (Connectionless Network Protocol) protocol for connectionless network communication.
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 interface The 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 interface In 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 conguring, symmetric version of the standardised protocol specied in the ITU-T recommendation G.784.
Figure 4-18 Point-to-point network and bus structure
4-18
Point-to-point network
Bus structure
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
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 retransmitted. 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:
0
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 les for the software of the IS-IS routing protocol within the Retix stack. The building block RtxUppInc contains all Include les for the software of the upper layers of the Retix stack. The building block RtxLowInc contains all Include les for the software of the lower layers of the Retix stack. The building block RtxComInc contains all the common Include les used commonly for the entire Retix software.
Stack environment A number of additional building blocks is required in order to construct the OSI stack environment. The functions of these building blocks are briey 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-specic 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.
Infrastructure 4-33
Communication drivers Communication 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 data As 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-19 The network element in the management network
X interface to superordinate network management
4-19
Link to other TN-4X subnetworks
Regional subnetwork
NE
NE
Network management server
NE
Q interface
NE
Regional network management
STM signal
STM signal
Q interface MCI
Network element
ASICs MC CC MC SIU ASICs CC
MCU SIG bus
SIU
Local craft terminal (CAT-4X)
ECC bus
Protocol conversion on the synchronous interface units Every 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.
Infrastructure 4-35
Routing in the MCU Data 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).
Figure 4-20 Routing in the MCU
4-20
Application
Craft terminal
CC on SIU 2 1 CC on SIU 2 1
Stack Management data from / to STM signal (via ASIC)
2 1
Stack
Communication between the MCU (application) and the local craft terminal is accomplished via layers 7 to 1 of the stack on the MCU.
EC
bu s
2 1
7 6 5 4 3 2 1
Stack
Q interface
MCU 3 2 1
MCI
4-36 Infrastructure
Internal transmission systems Management 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 rst 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 download The 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-21 Software download
4-21
Software Download CE protocol Object handler Gen. SWDL module MDT protocol Command handler Load handler
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 rst 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
Infrastructure 4-37
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 ash 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 specied (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-22 Software download: interaction of building blocks
4-22
Network element MCU
...
PU PU
CE protocol handler
Command handler
7 6 5 4 3 2 1
MDT protocol handler
Load handler
Object handler
Object handler
OSI stack Load PC (connected to the NE directly or via QECC)
HW driver HW driver
HW driver HW driver
HW
HW
HW
HW
Flash EPROMs
Flash EPROMs
SIG bus
The building blocks of the functional area "Software Download" are within the dashed lines.
End of chapter file
5-1
Chapter 5: MCU/PU software conguration

Introduction
A 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 conguration 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-1 TN-4X software architecture

Units MCU SIU
5-1
...
Software
Application software
... ... ...
Infrastructure software
Layers
Hardware
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 gure should always be consulted if the exact position of a building block or the structure of a software subsystem is required.
MCU/PU software configuration 5-3
Conguration of the MCU software

Overview 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 gure in the general overview at the end of this Chapter (Figure 5-4).
Figure 5-2 Structure of the MCU software (overview)
5-2
MCU application software NE conguration and supervision

CMIS agent and event report management Timing generator management Transmission object management Connection management Protection management Fault management
5
Equipment management Network element management

Backup routines
Common services
General routines
Infrastructure Communication services

MIL Stack Software download
System services
Operation system Message services Basic infrastructure Data block handling Local address services General building blocks
Hardware drivers
5-4 MCU/PU software configuration
Building blocks employed The building blocks used by the MCU software are listed in the following two tables. These tables briey 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-1 MCU software conguration part 1: application software Building block Meaning / function (see chapter/page)
5-1
NE conguration and monitoring MCAU MCCC MCCM MCCN MCCO MCEF MCEQ MCFA MCFB MCNE MCPO MCPR MCTG MCTP Database services MCCF General services MCCR MSVM XXMH XXPH XXXX Conversion routines (page 2-65) Watchdog triggering for MCU monitoring (page 2-65) Message handling (page 2-65) Process handling (page 2-65) Common building block Data restoration services (page 2-61) Management of AUG and TUG (page 2-29) Switching matrix process (page 2-39) CMISE agent (page 2-5) Conrmation monitoring for notications (page 2-5) Connection management (page 2-39) Event forwarding discriminator (page 2-7, page 2-8) Equipment management (page 2-22) Fault management (page 2-12) Fabric task (page 2-39) Network element management (page 2-16) Port management (page 2-22) Protection switching management (page 2-48) Timing generator management (page 2-55) Management of termination points (page 2-29)
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-2 MCU software conguration part 2: infrastructure Building block Meaning / function (see chapter/page)
5-2
INFRASTRUCTURE SYSTEM SERVICES Operations system (OS) PREPC pSOS SIGBusL2 XOS Message Services MCU_MessageService PU_MessageInterface Data block handler DBH Basic infrastructure BLIB FBoot XH Local address server AeTable LocalAddressServer LocalEnv Other building blocks EEPROMadmin NE_Global Includes CodeStdInc Hardware drivers EEPROM EEPROM driver for access to backplane EEPROM (page 4-20)
continued
pSOS runtime library (page 4-3) pSOS (page 4-3) SIGBUS level-2 driver (LLC and MAC) (page 4-3) Extended operation system (page 4-3)
Service for communication between MCU and PU (page 4-17) Interface for communication betw. MCU and PU (page 4-17)
Data block handler (page 4-18)
Basic infrastructure library for basic functions (page 4-14) FBoot process for warm start (page 4-14) Exception handler (page 4-14)
Table for the administration of local addresses (page 4-19) Access procedures for the provision of local addresses (page 4-19 Provision of internal addresses (page 4-19)
Data administration on the backplane EEPROM (page 4-21) General includes (coding standards) (page 4-21) Includes to ensure coding standards (page 4-21)
5-6 MCU/PU software configuration Table 5-2 MCU software conguration part 2: infrastructure (continued) Building block EEPROM_P Flash IIC LED RTC SWClock V24 Watchdog MCMC Meaning / function (see chapter/page) Driver f. acc. to backpl. EEPROM (procedural) (page 4-20) Flash EPROM driver (page 4-20) IIC bus driver (page 4-20) LED driver (page 4-20) Driver for real-time clock (page 4-20) Timer driver (page 4-20) V.24 interface driver (page 4-20) Watchdog driver (page 4-20) Driver for clock interface on the MCI (page 4-20)
5-2
INFRASTRUCTURE COMMUNICATION SERVICES MIL MIL MILPXOS OSI stack (Environment) StackEnv PHASEStackEnv StackInit CEC StackProtection StackUpperInterface StackUtilities OSI Stack (Retix Software) ACSE BAS CM LLC1 Pres ROSE RtxInc RtxComInc
continued
OSI stack, management interface library (page 4-25) MIL parts that require XOS (page 4-25)
Project independent runtime environment for OSI stack (Fascicle IS, Chap. 3.4.2.7) OSI stack, management (page 4-32) Initialisation of OSI stack (page 4-32) Communication between the processes of the stack (page 4-32) Coordination of the processes of the stack (page 4-32) Interface between MIL and CMISE (page 4-32) Commonly used utilities for the OSI stack (page 4-32)
OSI stack, access control service element (page 4-25) OSI stack, session layer (page 4-25) OSI stack, CMISE (page 4-25) OSI stack, logical link control (page 4-25) OSI stack, presentation layer (page 4-25) OSI stack, remote operation service element (page 4-25) Include les for the Retix stack (page 4-25)
MCU/PU software configuration 5-7 Table 5-2 MCU software conguration part 2: infrastructure (continued) Building block RtxLowInc RtxRouterInc System RouterUpper RouterLower TP4 Upper Software Download SWDL_LoadHandler SWDL_ObjectHandler SWDL_CommandHandler Load control for software download (page 4-36) Access to hardware drivers (page 4-36) Command control for software download (page 4-36) Retix components (page 4-25) Source code for IS-IS routing (page 4-25) Source code for event forwarding process (page 4-25) OSI stack, transport layer 4 (page 4-25) OSI stack, presentation layer (runtime env.) (page 4-25) Meaning / function (see chapter/page)
5-2
SWDL_CEProtocolHandler Protocol conversion for download commands (page 4-36) SWDL_MDTProtocolHandl Protocol conversion for download software er (page 4-36) SWDL_CommonInterface Communication drivers ECCBus MCU802MAC QECC driver and data link layer (page 4-33) Driver (MAC) for Ethernet interface (page 4-33)
end
Utilities for Software download (page 4-36)
Conguration of the PU software

Overview 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 specic 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 conguration of the peripheral units is therefore combined in the following gure 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 gure in the general overview at the end of this chapter (Figure 5-4).
Figure 5-3 Structure of the PU software (overview)
5-3
TIU-1 application software

PU Control
Protection Switching Alarm Handling Data Handling
PPU-1 application software

PU Control
...
(corresponding software congurations for TIU-3, TIU-4, SIU-1/4, SIU-el and CMU) The corresponding representations may be found in detail in Figure 5-4. The building blocks are listed in the following tables.
Protection Switching Alarm Handling Data Handling
Hardware access TIU-1 ASIC Driver TIU-1 HW Driver
Hardware access PPU-1 ASIC Driver PPU-1 HW Driver
General PU ASIC Driver
General PU ASIC Driver
Infrastructure Communication services

MIL Stack Software download
System services
Operation system Message services Basic infrastructure Data block handling Local address services General building blocks
Hardware drivers
Building blocks employed The building blocks used by the PU software are listed in the following two tables. These tables briey 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 conguration 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-3 PU software conguration Main controller (MC)
SIU-1/4 CMU-1 PPU-1 Building block Meaning / function (see chapter/page) TIU-1 TIU-3 TIU-4
5
5-3
Unit control PU_AlarmHandling PU_Protection PU_DataHandling Hardware access PUASICDriver TIU-1ASICDriver TIU-3ASICDriver TIU-4ASICDriver CMU-1ASICDriver PPU-1ASICDriver TIU-1_HW TIU-3_HW TIU-4_HW CMU-1_HW PPU-1_HW General PU-ASIC driver (page 3-43) TIU-1 ASIC driver (page 3-43) TIU-3 ASIC driver (page 3-43 TIU-4 ASIC driver (page 3-43 CMU-1 ASIC driver (page 3-43) PPU-1 ASIC driver (page 3-43) TUI-1 HW driver (page 3-43) TUI-3 HW driver (page 3-43) TUI-4 HW driver (page 3-43) CMU-1 HW driver (page 3-43) PPU-1 HW driver (page 3-43) continued
r r r r r r r r r r r r r r r r
PU alarm handling (page 3-15) PU protection switching (page 3-20) PU data administration (page 3-4)
r r r
r r r
r r r
r r r
r r r
r r r
5-10 MCU/PU software configuration Table 5-3 PU software conguration Main controller (MC) (continued)
SIU-1/4 CMU-1 PPU-1
r r r r r r r r r r r r
5-3
Building block
Meaning / function (see chapter/page) TIU-1 TIU-3 TIU-4

r
CCU_Ctrl CCUX3HW SIPU SITI SILA SIHW APD_Ctrl ADC General services XXMH XXPH XXXX INFRASTRUCTURE Operations system (OS) PREPC pSOS SIGBusL2 XOS
Message services MCU_MessageService PU_MessageInterface
CCU control (Fascicle AP, Chap. 4.2) CCU-X3 hardware driver (page 3-47) SIU ASIC driver (page 3-47) SIU hardware driver for timer services (page 3-47) SIU hardware driver for laser control (page 3-47) SIU hardware driver (page 3-47) Control of optical components (page 3-47) Analogue/digital converter (ADC) (page 3-47)
r r
r r r r r r r r r
Message handling (page 2-65) Process handling (page 2-65) Common building block (page 2-65)
r r r
r r r r r
r r r r r
r r r r r
r r r r r
pSOS runime library (page 4-3) pSOS (page 4-3) SIGBUS level-2 driver (LLC, MAC) (page 4-3) Extended operations system (page 4-3)
r r r r
Service for communication between MCU and PU (page 4-17) Interface for communication betw. MCU and PU (page 4-17)
r r
r r
r r
r r
r r
Basic infrastructure BLIB FBoot XH Local address services LocalEnv Provision of internal addresses (page 4-19) continued
r r r r r
r r r
r r r
r r r
r r r
r r r
MCU/PU software configuration 5-11 Table 5-3 PU software conguration Main controller (MC) (continued)
SIU-1/4 CMU-1 PPU-1
r r r r r r r r r r r r
5-3
Building block
Meaning / function (see chapter/page) TIU-1 TIU-3

r r r
Other building blocks EEPROMadmin NE_Global Includes

CodeStdInc
Data administration on the backplane EEPROM (page 4-21) General includes (coding standards) (page 4-21)
Includes to ensure coding standards (Fascicle IS, Chap. 2.8)
r r r
TIU-4
r r r
r r r
r r r
Hardware drivers EEPROM

EEPROM_P
EEPROM driver for access to backplane EEPROM (page 4-20)

Driver f. acc. to backpl. EEPROM (procedural) (page 4-20)
Flash IIC TPU LED RTC SWClock V24 Watchdog Software Download SWDL_ObjectHandler SWDL_CommonInterface
Flash EPROM driver (page 4-20) IIC bus driver (page 4-20) Activation of programmable timer function (TPU) on the MC LED driver (page 4-20) Driver for real-time clock (page 4-20) Timer driver (page 4-206) V.24 interface driver (page 4-20) Watchdog driver (page 4-20)
r r r r r r r r
r r r r r r r r
r r r r r r r r
r r r r r r r r
r r r r r r r r
Access to hardware drivers (page 4-36) Utilities for Software download (page 4-36) end
r r
r r
r r
r r
r r
r r
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 conguration 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-4 Software conguration of communication controller (SUIs, TIU-4)
Building block Meaning / function (see chapter/page) INFRASTRUCTURE SYSTEM SERVICES Operations system (OS) PREPC pSOS Basic infrastructure BLIB FBoot XH
Local address services LocalEnv Provision of internal addresses (Fascicle IS, Chap. 2.5)
5-4
pSOS runtime environment (page 4-3) pSOS (page 4-3)
Other building blocks

EEPROMadmin Data administration on the backplane EEPROM (Fascicle IS, Chap. 2.8)
Hardware drivers IIC LED SWClock V24 Watchdog ShMemMC_CC IIC bus driver (page 4-20 LED driver (page 4-20) Timer driver (page 4-20) V.24 interface driver (page 4-20) Watchdog driver (page 4-20) Dricer for communications between MC and CC via Shared memory (page 4-20)
INFRASTRUCTURE COMMUNICATION SERVICES OSI stack (Environment)

CCStackEnv CCCLMgr OSI stack (Retix components) Runtime environment for OSI stack on CC (page 4-32) CC Layer Manager: XOS access for stack data (page 4-32)
Software Download SWDL_ObjectHandler SWDL_CommonInterface Communication driver ECCBus QECCR Driver and data link layer for ECC bus (page 4-33) Driver for the QECC interface Access to hardware drivers (page 4-36) Utilities for Software download (page 4-36)
Software conguration overview

The TN-4X software conguration 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.
Application Software MCU

Application SW TIU-1 Application SW TIU-4 Application SW SIU-1/4 Application SW SIU-1el Application SW CMU-1 Application SW PPU-1
NE Con guration and Super vision MCPR MCFB

Data admin Data admin Data admin Prot. switchi ng Data admin Data admin Data admin Prot. switchi ng Prot. switchi ng Data admin Message Services Message Services Message Services Message Services Message Services Prot. switchi ng Prot. switchi ng Prot. switchi ng Alarm handling Mainte nance Mainte nance Mainte nance Mainte nance Mainte nance Mainte nance Alarm handling Alarm handling Alarm handling Alarm handling Alarm handling Alarm handling Mainte nance Prot. switchi ng Message Services
PU Control H/W Control PU Control
PU Control PU Control
PU Control PU Control
MCAU
MCCO

MCFA
Hardware Access Hardware Access Hardware Access Hardware Access CCUCtr CCUX3 Hardware Access CCUCtr CCUX3 Hardware Access Message Services Hardware Access TIU-1 ASIC Driver TIU-1 HW Driver TIU-3 HW Driver TIU-4 ASIC Driver TIU-4 HW Driver TIU-3 ASIC Driver
MCTG
MCTP
MCEF
MCPO
MCCC
MCCN
SITI SIHW
APDCtrl APDCtrl ADC ADC General PU-ASIC Driver
MCEQ Equipment Management SITI SIHW
Figure 5-4 Conguration of the TN-4X software
MCCM SIPU SIPU SILA SILA

General PU-ASIC Driver CMU-1 ASIC Driver
MCNE Network Element Management
CMU-1 HW Driver ADC
PPU-1 ASIC Driver
PPU-1 HW Driver
Data Restoration Ser vices

XXXX ADC ADC ADC General PU-ASIC Driver General PU-ASIC Driver General PU-ASIC Driver
Common Ser vices
MCCF
MSVM
XXMH
XXPH
MCCR
General PU-ASIC Driver
General PU-ASIC Driver
ADC
Infrastructure
Comm unication Services

Pres BAS TP4 Upper Stack-Prot CLNP PREPC PSOS Stack-Msg Stack-Env. SIGBus L2 StackInit Stack-UInt RtxInc Stack-Util
System Services
Data Block Administration Operations System XOS
Basic Instructions
Local Address Services
MIL
General Building Blocks
MIL
CM
FBoot Exception Handler

Data Block Handler
AETable LocalEnv
LLC1
General Include Files
Stack
ACSE
System
ROSE
BLIB
Local Address Server
EEPROM Administration
Communication Drivers QECCR Driver1
Hardware Drivers MCMC
ECC-Bus Driver
MCU802MAC
EEPROM Driver Watchdog Driver
Flash-EPROM Driver RTC Driver
IIC Driver V.24 Driver
SW Clock LED Driver TPU Driver2
Driver
1) Used only on the Communication Controller (SIU, TIU-4). The TIU-4 is equipped with a Communication Controller, the CC, however, has no function on the TIU-4. 2) Used only on the Main Controller (MC) of the Peripheral Units, not on the MCU
5-4
6-1
Index
A B
Abstract syntax 4-28 Backplane EEPROM 2-22 Abstract Syntax Notation One (ASN.1) 4-27, Backup configuration 2-16 4-30 Backup medium 2-61 ACSE 4-27, 4-28 Basic configuration 2-16 Action 2-6 Basic infrastructure 4-14 Address services 4-19 Bidirectional point-to-point connection 2-39 Administrative state 2-45 Block pool 4-8 AETable 4-19 Blocked process 4-10 Agent 1-6 Boot process 4-14 Agent process 1-4 Buffer pool 4-8 Alarm data 3-7, 3-44 Buffer pool configuration 4-9 Alarm detection 3-42, 3-45 Building block 1-6, 2-4, 4-1, 4-25, 5-2, 5-3, Alarm filtering 3-16 5-4, 5-8, 5-13 Alarm masking 3-16 Alarm monitoring 3-16 C Alarm notification 2-15 CAPI 4-7 Alarm severity assignment profile 2-12, 2-14, Card protection 2-24, 2-28, 2-29 2-22, 2-32 CCU protection 2-58, 2-60 Alarm state 3-7 CCU-X3 clock generator 3-48 Alarm types 2-12 Clock generator 2-61 Allocate once pool 4-8 Clock output 2-59 Anchored periodic timer 4-10 Clock protection 2-58, 2-60 Anchored timer 4-10 Clock quality 2-55 Application data 3-7, 3-44 Clock source Application interface 4-5 switchover 2-61 Application layer 4-24, 4-28 Clock supply 2-59 Application software 1-6, 5-1 CMIS agent 2-5, 2-7, 2-11 MCU 1-6 CMIS services 2-6 PU 1-7, 3-1 CMISE 4-27, 4-28 ASIC 3-42, 3-45, 3-46 CMU-1 specific software 3-38 ASIC driver 3-5, 3-43 Cold start 4-15 ASIC driver object database 3-5 Common API (CAPI) 4-7 ASN.1 4-27, 4-30 Common management information service Association Control Service Element 4-27, (CMIS) 1-5 4-28 Common Management Information Service Attributes 1-3 Element (CMISE) 4-27, 4-28 Automatic laser shutdown 2-32, 2-36 Common services 2-65
6-2 Index
Communication 4-24 between MCU and PUs 4-18 connectionless 4-27 failure 2-11 manager - agent 1-4 Communication controller (CC) 5-9 Communication driver 4-33 Communication paths (operating system) 4-7 Communication services 1-7, 4-1, 4-2, 4-21, 4-22, 4-25 Communication system network element 1-5 Conditional package 1-3 Configuration 2-16 Configuration and supervision 2-1, 2-2 Configuration data 2-17, 3-44 Configuration data backup 2-21 Connection 2-39 Connection management 2-39 Connection termination point 2-29 Connectivity pointer 2-31, 2-40, 2-49 Consolidation state 3-7 Containment relationship 2-31 Control 1-5 Control system 4-17 Conversion routines (ASN.1) 2-66 Craft terminal 1-1 Create 2-6 Critical section 4-14 Critical Section Guard (CSG) 4-5, 4-14 Cross-connection 2-39 Cross-connection pointer 2-31, 2-40, 2-49 CSG 4-5, 4-14
Dynamic memory area 4-8
E
ECC bus 4-25, 4-32, 4-35 EEPROM driver 4-20 Equipment 2-22 Equipment alarm 2-12 Equipment error 3-19 Equipment management 2-22 Error classification 4-17 Event forwarding discriminator 2-7, 2-10 Event report 2-6 Event report management 2-5, 2-7 Event report service 2-6 Exception handler 4-16 Exceptions 4-16 Expiration timer 4-10
F
Fault handling PU 3-19 Fault management 2-12, 2-15 FBoot process 4-15 Flash EPROM driver 4-20 Formatter 4-29 Fragmentation 4-9 Free memory 4-8 From termination 2-40, 2-50
G
General messages 4-12 Get 2-6 Global services 4-5
D
Data block handler 4-18 Data link layer 4-24 Data restoration services 2-61 Defined context set 4-29 Delete 2-6 Dictionary 4-28 Distributed control system 4-17 Domain 4-11 Domain address 4-11 Download 4-36 Driver infrastructure 4-20 peripheral units 3-43 SIU 3-47 Dump 2-61, 2-62
H
Hardware access 3-1, 3-42 Hardware component failure 2-12 Hardware control 3-3 Hardware driver 4-20 Hardware/software relationship 1-5 HDLC 4-31 Heartbeat 4-17 High-priority resource 2-49
I
IIC bus driver 4-20 Information data 4-11 Infrastructure software 1-7, 4-1, 5-1, 5-3
Index 6-3
Initialisation 3-42, 4-15 Instance 2-25 Instantiate 2-6 Interfaces 4-21 Inter-Process Communication (IPC) 4-13 Interrupt Service Routine (ISR) 4-13 Interrupt services 4-5, 4-13 IPC 4-13 IS-IS routing 4-30 ISR 4-13 ITU-T G.783 2-56 ITU-T G.811 2-55 ITU-T G.812 2-56
K
KAI 4-7 KAL 4-6 Kernel Adaptation Interface (KAI) 4-7 Kernel Adaptation Layer (KAL) 4-6
L
Laser control 3-47 LED driver 4-20 Line transmission alarm 2-31 LLC sub-layer 4-31 Local address 4-11 Local address services 4-19 Local cast 4-13 Local craft terminal 1-1, 1-2 Local management 4-10 Local services 4-5 Long-term buffer pool 4-9 Low-priority resource 2-49
MCCM 2-13, 2-17, 2-33, 2-42, 2-51, 2-56 MCCO 2-23, 2-41 MCEF 2-13, 2-17, 2-33, 2-42, 2-51, 2-56 MCEQ 2-17, 2-22, 2-33, 2-42, 2-57 MCF 4-22, 4-24 MCFA 2-13, 2-23, 2-33 MCFB 2-41 MCI driver 4-20 MCNE 2-42 MCPO 2-22 MCPR 2-23 MCTP 2-23, 2-32 MCU application software 1-6, 5-3, 5-4 MCU Connection Interface (MCI) 4-20 MCU event forwarding discriminator task 2-10 MCU software 5-3 MCU supervisory module 2-66 MCU timing generator 2-59 MCU-PU message service 4-18 Memory management 4-4, 4-5, 4-8, 4-13 Message Access Routines (MARS) 4-18 Message Communication Function (MCF) 4-22, 4-24 Message Interface (MCU-PU) 4-18 Message queue 4-2, 4-11 Message services 4-17 message services 4-18 MIL 4-27 Multiplex structure 2-30 Multitasking operation 4-11
N
Naming conventions 2-3 Network element 5-1 Network element management 2-16 Network element software 1-4 Network layer 4-24 Network management system 1-1, 1-2, 1-3, Unit 2-1, 2-6, 2-11, 2-16, 4-21 Node management 4-5, 4-13 Notifications 2-10
MAC sub-layer 4-31 Main controller (MC) 5-9 Main memory 4-8 Management and Communication (MCU) 1-5, 4-1, 5-1 Management application function 2-1 Management information tree 2-9 Management Interface Library (MIL) 4-27 Management task 2-6 Manager address list 2-16 Manager agent model 1-4 Manager process 1-4 MCAU 2-32 MC-CC driver 4-21
O
Object behaviour 1-3, 2-6 Object classes 1-3, 3-5 Object database 3-5, 3-44 Object instance 2-18, 2-21, 2-34, 2-36 Object model PU 3-5
6-4 Index
Object state 3-7 Objects 1-3 Operating system 4-1, 4-3, 5-1 Operating system functions 4-1 Operational state 2-15, 3-7, 3-9 OSI layer model 4-23, 4-24 OSI model 4-22 OSI protocol stack 4-22 OSI stack 4-23, 4-27 Overhead 2-29 Overview 5-13
Protocol stack (MCF) 4-25 pSOS (kernel) 4-4 PU 1-5 PU alarm handling 3-15 PU ASIC driver 3-5 PU maintenance 3-4 PU message services 4-18 PU protection 3-20 PU software 5-8 PU state management 3-12 PU states 3-12, 3-13
P
PAPI 4-7 Parameter error 4-16 Parser 4-29 Path protection switching 2-48 Periodic timer 4-10 Peripheral unit 2-22 Peripheral units (PU) 1-5, 3-1, 4-1, 5-1 Physical layer 4-24 Plug-in unit 4-1 Plug-in unit failure 2-12 Plug-in units card protection 2-28 protected 2-28 protecting 2-28 Portability 4-4 PPU-1 specific software 3-39 Premature and changeable data 2-62 PREPC 4-4 Presentation context 4-29 Presentation layer 4-24, 4-28 Priority 4-10 Priority level 4-11 Privileged API (PAPI) 4-7 Process address 4-11 Process interruption 4-11 Process management 4-4, 4-10 Processes 4-2, 4-10 Processor 4-2 Protected resource 2-49 Protecting plug-in unit 2-28 Protecting resource 2-49 Protection CCU (clock sources) 2-58, 2-60 Protection group 2-28 Protection management 2-48 Protection switching 2-46, 3-20 Protocol stack 4-22
Q
Q interface 4-2, 4-21, 4-31, 4-35 QECC interface 4-2, 4-21, 4-31 Queue (cf. Message queue) 4-2
R
Real time clock 4-20 Recording measurement data 3-42 Recovery 2-18, 2-61, 2-62, 3-11, 4-14 Reference clock 2-56 Releasing a connection 2-46 Reliability 1-5, 4-6 Remote Operation Service Element (ROSE) 4-27, 4-28 Reset 2-18, 2-22 Resources 3-5 Retix 4-27 ROSE 4-27, 4-28
S
Scalar messages 4-12 Session layer 4-24 Set 2-6 Setting up a connection 2-46 Seven-layer model 4-23 Shared memory 4-5, 4-7, 4-9 SIG bus 4-5, 4-7 SIGBusL2 4-4 SIU driver 3-47 SIU specific software 3-33, 3-47 Size characteristics 4-8 Software MCU 2-1, 5-3 peripheral units 3-1 Software concept 1-3 Software configuration 5-13 Software context 2-3
Index 6-5
Software Download (SWDL) 4-2, 4-36 Software layers 5-1 Software of the peripheral units 5-8 Stack 4-22 Stack environment 4-32 Standby clock source 2-60 State management 3-12 State transition 3-10 Statically allocated memory area 4-8 Subnetwork connection 2-48 Subsystems 1-1 Suspended process 4-11 Switching matrix 2-45 Synchronisation error 4-16 System architecture 5-1 System services 1-7, 4-1, 4-3 System time 4-9 System time management 4-9
V
V.24 driver 4-20 Vector messages 4-12 Virtual container 2-35
W
Warm start 2-22, 2-27, 4-15 Watchdog 4-17, 4-20 Watchdog driver 4-20
X
XOS 4-4, 4-5 XOS and system architecture 4-4 XOS structure and interfaces 4-6
T
Task 2-3 Telecommunications Management Network (TMN) 4-2, 4-21 Termination point 2-29 Time services 4-5 Timer 4-5, 4-10 Timer driver 4-20 Timing generator management 2-55 Timing marker 2-56 Timing source 2-55, 2-59 TIU-1 specific software 3-21 TIU-3 specific software 3-24 TIU-4 specific software 3-28 TN-MS EC-4X 1-1 To termination 2-40, 2-50 TPU driver 4-20 Trail termination point 2-29 Transfer syntax 4-28 Transient buffer pool 4-9 Transmission control data 4-11 Transmission failure 2-12 Transmission object 2-29 Transmission object alarm 2-12 Transmission object management 2-29 Transport layer 4-24
U
Unit replacement handling 2-16, 2-26 User data container 4-11
Contacts Legal statements Trademarks
International Broadband Networks (Dept. 18600) Nortel Limited Oakleigh Road South London, 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-4X
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-101 Document issue: Release 2.4 Document Status: Standard Date: February 1997 Printed in England

TN 4X

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

TN 4X

Загружено:

Авторское право:

Доступные форматы

323-1121-101

Copyright Coypright statement Country of printing NT confidential NTE disclaimer Trademarks

Copyright 1996, 1997 Northern Telecom

Printed in England NORTHERN TELECOM CONFIDENTIAL:

323-1121-101 Release 2.4 Standard

TN-4X Software Description

323-1121-101 Release 2.4 Standard

TN-4X Software Description

Chapter 2: Application software of the Management and communication unit

323-1121-101 Release 2.4 Standard

TN-4X Software Description

Chapter 3: Application software of the peripheral units

TN-4X Software Description

323-1121-101 Release 2.4 Standard

Chapter 5: MCU/PU software configuration

323-1121-101 Release 2.4 Standard

TN-4X Software Description

About this document

323-1121-101 Release 2.4 Standard

TN-4X Software Description

Technical support and information

TN-4X Software Description

323-1121-101 Release 2.4 Standard

323-1121-101 Release 2.4 Standard

TN-4X Software Description

1-2 Introduction Figure 1-1 Management of regional subnetworks

to superordinate network management

to other TN-4X subnetworks

Network management server

Regional network management NE NE

Local craft terminal (CAT-4X) NE

TN-4X Software Description

323-1121-101 Release 2.4 Standard

Basic terminology and concepts

323-1121-101 Release 2.4 Standard

TN-4X Software Description

Management operations Manager process Communication Notication Agent process

Management operations Notications Objects

e.g. within the TN-MS EC

Network element software

TN-4X Software Description

323-1121-101 Release 2.4 Standard

Network Element software overview

323-1121-101 Release 2.4 Standard

TN-4X Software Description

Application software and infrastructure.

Application software of the management and communication unit

Application software of peripheral unit 1

Application software of peripheral unit n

Infrastructure System services Communication services

TN-4X Software Description

323-1121-101 Release 2.4 Standard

323-1121-101 Release 2.4 Standard

TN-4X Software Description

Chapter 2: Application software of the Management and communication unit

MCU application software NE conguration and supervision

CMIS agent and event report management

Timing generator management

Transmission object management

Equipment management Network element management

Data restoration services Backup routines

Common services General routines

Conguration and supervision Data restoration services Common services.