Siemens TNMS (Technical Descriptions)

TNMS Core 6.0

TED

!

Important Notice on Product Safety

Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts can also have elevated operating temperatures.

Non-observance of these conditions and the safety instructions can result in personal injury or in prop-erty damage.

Therefore only trained and qualified personnel may install and maintain the system.

The system complies with the standard EN 60950. All equipment connected has to comply with the applicable safety standards.

Copyright (C) Siemens AG 2001.

Issued by the Information and Communication Networks Group Hofmannstraße 51

D-81359 München

This document consists of a total of 41 pages. All pages are issue 1.

Contents

1 Introductory Notes. . . 5

1.1 Available Documentation . . . 5

1.2 Symbols Used in This Manual . . . 6

1.3 Feedback . . . 6

2 Network Overview . . . 8

2.1 Network Architecture. . . 9

2.1.1 Network Elements . . . 9

2.1.2 Data Communication Networks (DCN) . . . 11

2.1.2.1 PDH Access Networks . . . 12 2.1.2.2 SDH Networks . . . 13 2.1.2.3 WDM Networks . . . 14 2.2 Network Protection . . . 15 3 System Overview . . . 16 3.1 General Information . . . 16 3.2 System Architecture . . . 16 3.3 Software Components . . . 18 3.3.1 TNMS Core NetServer . . . 19 3.3.2 TNMS Core Server . . . 19 3.3.3 TNMS Core Client . . . 20 3.3.4 TNMS Core SysAdmin . . . 20 3.4 Databases. . . 21

3.5 Interfaces to Higher-Ranking Management Systems . . . 21

3.5.1 Data Import/Export Interfaces . . . 21

3.5.2 DCN Interfaces . . . 22

4 Installation Notes . . . 24

4.1 Licensed Software . . . 24

4.2 Hardware Requirements . . . 24

4.3 Additional Backup Hardware. . . 26

5 Functional Overview . . . 27 5.1 Features of TNMS Core . . . 27 5.2 Basic Operation . . . 28 5.2.1 TNMS Core NetServer . . . 28 5.2.2 TNMS Core Server . . . 28 5.2.3 TNMS Core Client . . . 29 5.3 Log Management . . . 30 5.3.1 Log Classes . . . 30 5.3.2 Log Types . . . 30 6 Client Functions . . . 32 6.1 Configuration Management. . . 32 6.1.1 Network Management . . . 32

6.1.2 Universal Objects (UNO) . . . 32

6.1.3 Service Management . . . 33 6.1.4 Subscriber Management . . . 34 6.2 Performance Management. . . 34 6.3 Fault Management . . . 34 6.4 Security Management . . . 35 7 SysAdmin Functions . . . 36 7.1 TNMS Server . . . 36 7.2 Alarm Settings . . . 36 7.3 Cost Factors. . . 36 7.4 Database . . . 36 7.5 Date / Time. . . 37 7.6 External Interfaces . . . 37 7.6.1 SNMP Proxy. . . 37 7.6.2 OCA Proxy . . . 38 7.6.3 SNIF Proxy. . . 38 7.7 Licensing . . . 38 7.8 NE Inscription Settings. . . 38 7.9 Security . . . 38 7.9.1 Account Policy . . . 39 7.9.2 User Management . . . 39 7.10 DCN Management . . . 39 8 Abbreviations . . . 41

1

Introductory Notes

1.1

Available Documentation

All TNMS Core manuals are available both in hardcopy form and on CD-ROM, and can be ordered either in German or in English.

• Technical Description (TED)

The Technical Description provides an overview of the applications, features, system architecture and functions of TNMS Core.

• Installation Manual (IMN)

The Installation Manual contains instructions on installing the TNMS Core software.

• Operator Guidelines (OGL)

The Operator Guidelines contain a general description of the TNMS Core Client and TNMS Core SysAdmin user interfaces, as well as the necessary background infor-mation.

You may also consult the online help which is delivered with the software. It provides comprehensive instructions on the functions offered by the Client and SysAdmin user interfaces. The ‘Contents’, ‘Index’ and ‘Search’ tabs enable the online help to be searched quickly and conveniently. Individual help topics can be printed, and context-sensitive help texts called up directly from the user interface.

The complete online help and the individual instruction manuals are also provided as *.pdf files under the Help menu. These files can be viewed and printed using Adobe Acrobat Reader.

Manual Type Order Number (English) Order Number (German) Technical Description (TED) A42022-L5938-B51-*-7618 A42022-L5938-B51-*-18 Installation Manual (IMN) A42022-L5938-B52-*-76D1 A42022-L5938-B52-*-D1 Operator Guidelines (OGL) A42022-L5938-B53-*-7619 A42022-L5938-B53-*-19 CD-ROM (contains

TED, IMN and OGL)

A42022-L5938-B10-*-76K5 A42022-L5938-B10-*-K5

1.2

Symbols Used in This Manual

The following symbols are used in this manual:

1.3

Feedback

We aim to provide you with documentation which is easy to understand and user-friendly. Your practical experience is very important to us in achieving this objective. We are particularly interested in your opinion on the following issues:

• Where is too much/not enough detail provided?

• Where do you find these instructions difficult to understand?

• Where would additional graphics be useful to improve understanding?

• What improvements could be made to the basic layout of the TNMS Core documentation?

Please enter your comments, suggestions and corrections in the questionnaire on the following page. If necessary, this questionnaire can also be photocopied or printed out from your documentation CD.

So that we can contact you and discuss your comments at greater length if neces-sary, do not forget to enter your contact details.

Thank you in advance for your support!

i

!

Questionnaire

Completed questionnaires can be returned: by fax: +49 89 722 57315

or by post:

SIEMENS AKTIENGESELLSCHAFT

Information and Communication Networks Group ICN ON CS C2 Hofmannstrasse 51 D-81359 München Company/Name: Address: Department: Telephone: Fax: Date: Signed:

I am using this documentation My duties include (...) As service documentation (...) Commissioning (...) As an installation/commissioning guide (...) Operation (...) As a general introduction (...) Maintenance (...) For reference purposes (...) Sales

(...) As training material (...) Training activities

(...) _______________________________ (...) _______________________________

2

Network Overview

Fig. 2.1 shows the general structure of a transmission network managed by TNMS Core. The network elements (NE) provide various management interfaces. This means that they can be connected via the DCN to the management system in several ways.

Fig. 2.1 General Structure of a TNMS Core Network

Element management functions are executed via the element managers (LCTs, TNMS-SX, EM-OS) provided by the TNMS Core system.

For network elements managed via EM-OS, network management is restricted to fault management (alarm mapping). These network elements are displayed as universal objects in the TNMS Core network plan.

Management interface TNMS Core

DCN

Type of network element

Q_D2SISA QB3 TNMS-SX EM-OS EMOS-SLI ELI-SXEM FMX, CMX

SMA1/4, SL16, MTS, MODIF, SMA1K, SMA1K-CP, SLR16, Infinity WL, Infinity WLS, OSN, OCU, Infinity MTS , WTTR, SMA16, SMA4, SLD16, SL64

SXA, SXD

SLxx, SMAxx, etc. Integrated element manager (EM):

LCTs, TNMS-SX, EM-OS Waveline (SNMP) Waveline EL2 UNO TNMPV2 SRT 1C (logical interface)

e. g. NEs supported via TIF, e. g. ERX700/1400, SSU-2000e

2.1

Network Architecture

TNMS Core can be used universally in all kinds of transport networks. The seamless integration of WDM, SDH and PDH equipment significantly increases the number of application scenarios, not all of which are described here.

2.1.1

Network Elements

TNMS Core supports line, star and ring networks comprising the network elements listed in Table 2.1.

NE class Device Version Note

WDM Infinity WL 2.1, 2.2, 2.3, 2.35

Infinity WLS 1.0, 2.0-1, 2.0-2, 2.0-5

PM is not supported. Infinity MTS 1.1E, 1.1 ANSI,

2.0-1, 2.0-2

1.1.ANSI: Only the subtypes OTT8, OTT16 and OLR are supported. 2.0-1: Only the subtypes OTTU and OLRU are supported.

2.0-2: Only the subtypes OADMU, OTTU and OLRU are supported. OSN OCU 1.0E, 1.2.5,

2.0.1 (TEX), 2.1 (OCR)

SRC

OSN MODIF 1.0

SDH OSN WTTR 2.0

SMA1/4 2.2.3, 2.3, 2.3E Includes 45 M tributary

SMA 4 2.3E SMA1K 3.2, 3.3 SMA1K-CP 3.2, 3.3 SMA16 4.1, 4.2 SMA16/4 4.2 SL16 2.3, 2.4, 2.5 SL64 3.2, 3.25, 3.26, 3.27 SLR 2.2 SXA 3.2.30, 3.2.50, 3.3.10 SXD 3.1.20, 3.1.30 ISDH PDH FMX2 (MXS19 and CMXS subrack) 2 CC64kr LTO-LT, LTO-NT ASA32 SUE LTCOH-LT, LTCOH-NT LTC(LT), LTC(NT)

SISA-V SISA-KGwd SISAK

SISA-V/LMX CUA/CUD

SISA-V/LMX-V2 SUE

SISA-V LTC(LT, LTO(LT)

SISA GK V11 asynchron EM only

SISA GK G703 EM only

SISA GK E EM only

NE class Device Version Note

TNMS Core can manage large, medium and small transport networks. Network dimensioning with the TMN system is influenced by the following factors:

– Network criteria, e.g. size, topology, simple/complex network elements – Operational criteria, e.g. number of services, number of PMPs

– Fault criteria, e.g. alarm bursts

As these criteria can vary considerably from network to network, separate planning is for each customer.

2.1.2

Data Communication Networks (DCN)

Data communication networks play an important role in managed transmission networks. DCN faults therefore have a considerable effect on the functionality of the network as a whole. The transmission rate of each DCN also influences the general network performance.

Settings for the various DCN interfaces to the network elements (e.g. addresses) are made in TNMS Core SysAdmin. For more information, see Section 3.5.2.

Other Waveline EL 2

ERX700/1400 Screen-level integration of EM

SSU-2000E Screen-level integration of EM

ULAF+ Screen-level integration

of EM

Microsens GBE Screen-level integration of EM

NE class Device Version Note

2.1.2.1

PDH Access Networks

TNMS Core supports n x 64-Kbit PDH access services using tributary cards such as FMX/CMX. End-to-end management for PDH equipment is implemented via TNMS Core at the network layer (NWL). Other tributary cards such as ISDN and 64-Kbit sub-bitrate cards are configured via the LCT application and implemented at the element management layer (EML). Administration of these services is therefore performed directly via the element managers. For the purposes of fault management, however, all alarms are written to a global alarm log maintained in TNMS Core.

Fig. 2.2 shows a typical application scenario with FMX/CMX in interaction with a SDH network.

Fig. 2.2 PDH Access Network

STM-4

SMA SMA SMA

SMA SMA SMA DCN STM-4 Managed network TNMS Core CMX FMX CMX FMX SMA CMX

2.1.2.2

SDH Networks

TMNS Core uses a combination of various SDH devices to enable management of services ranging from 2 Mbit/s up to STM-64. Both line and ring structures including BSHR and MSLTP are supported, depending on the NE version. The combination of full element management functionality and extensive network layer capabilities provides comprehensive support for network operator tasks such as end-to-end service and path provisioning (see Chapter 6). Additional operations such as supervision, monitoring, maintenance and provisioning of the SDH network can be completed without the need for auxiliary TMN equipment.

Fig. 2.3 SDH Network SMA4 DCN STM-16 Managed network TNMS Core SLD16 SLD16 SLD16 SLD16 SMA1 SMA1K SMA1K SMA4 SMA4 SMA4 MSLTP SL64 SL64 SL64 SMA16 SXA STM-64 STM-4

2.1.2.3

WDM Networks

TNMS Core offers comprehensive support for new-generation WDM systems such as Waveline products for metropolitan networks, Infinity MTS for long-haul applications, Infinity WL/WLS and Optical Service Node OSN. These systems are used in ultra-high capacity (UHC) networks as well as in metropolitan networks. Fig. 2.4 shows a simple example of a UHC network. The 10 Gbit/s connections represent interfaces to a lower transport layer (comprising SDH systems, for example).

Fig. 2.4 WDM Network DCN Managed network TNMS Core Infinity OSN OSN OSN OSN Infinity Infinity Infinity Infinity Infinity Infinity Infinity n x 10 Gbit/s n x 10 Gbit/s n x 10 Gbit/s n x 10 Gbit/s

2.2

Network Protection

Protection mechanisms are used to ensure the continued availability of a service even if a connection or part of a connection fails. Services can be protected using either path protection (for the transmission path) or trail protection (for the physical network elements and lines). Various network structures are supported such as meshed networks, line structures, and rings.

A path comprises a sequence of port connections and cross connections. Both path ends may have either one or two endpoints. The path endpoints may lie on the same or on different network element layers. The route and endpoints can be modified by the operator.

A trail comprises a defined number of connections between termination points on the same network layer. Connections in adjacent transmission layers have a client/server relationship. The individual trails are known as client trails, and if located on adjacent transmission layers, they can be linked to create a server trail.

Path Protection

Path protection is configured in TNMS Core using a series of dedicated windows which create a standby path for every working path selected. The option for sub-network connection protection (SNCP) provides protection at every transmission level and can therefore be used to protect either an entire path or parts of a path across a network.

Trail Protection

Trail protection is performed on the network element layer via an element manager. The possibilities include multiplex section protection (MSP), a bi-directional self-healing

ring (BSHR) or optical protection.

Multiplex section protection is used on lines to protect point-to-point connections between network elements with multiplex capability. The individual service is not protected, rather the whole multiplex section between two adjacent nodes with multiplex functionality. A two or four-fiber bi-directional self-healing ring (BSHR-2/4) is a special multiplex section protection mechanism used within rings. It protects the whole multiplex section between two adjacent ring nodes, called a span. Optical protection protects specifically against failures on the optical layer.

3

System Overview

3.1

General Information

The telecommunication network management system TNMS Core is an integrated solu-tion designed for large, medium and small networks. It supports network elements with WDM, SDH, PDH and Ethernet interfaces and can be used to monitor and configure entire networks, both in core and backbone applications.

3.2

System Architecture

TNMS Core is a scalable multi-user system with a client/server architecture comprising several industry standard PCs with the Windows 2000 operating system and various software applications. External devices such as printers, tape units and remote clients are not dealt with here.

Fig. 3.1 System Architecture

The TNMS Core software comprises the Client, SysAdmin, Server and NetServer appli-cations. Client and SysAdmin are installed on a client PC. To support distributed oper-ation of the network, up to 20 Client installoper-ations can be managed simultaneously. Concurrent access to network resources is regulated by the server PC - only one oper-ator at a time is granted write access to a network element.

The Server software is installed on a server PC. A second SysAdmin installation on the server PC together with an additional monitor is also recommended as this enables administration of the TNMS Core system to continue even if the dataflow between the

TNMS Core Client (max. 20 PCs, 3rd-party software) TNMS Core SysAdmin TNMS Core Client (1) TNMS Core SysAdmin Subnetwork A Large network TNMS Core NetServer (1) TNMS Core NetServer (max. 10 PCs) TNMS Core Server (TNMS Core SysAdmin, 3rd-party software) Subnetwork C Subnetwork B

An additional client PC must also be installed with 3rd-party software if an OCA proxy is to be installed or if access to a UNIX PC is required.

The NetServer software is installed on a netserver PC. Depending on the number of network elements, up to 10 NetServer PCs can be managed simultaneously.

3.3

Software Components

The TNMS Core software architecture is scalable. This means that different software application groups can be installed on one or more PCs. However, software applications of the same group must be installed on the same PC (see diagram below).

Open CORBA

TNMS Core Client TNMS Core SysAdmin TNMS Core Client components

TNMS Core Server Network management user interface Element manager Element manager SNIF/C System administration user interface TNMS Core SysAdmin components

TNMS Core Server components Umbrella system interface proxy Umbrella system interface proxy SNIF SNMP

TNMS Core NetServer components TNMS Core NetServer TNMS Core Config database TNMS Core Server database TNMS Core Log database TNMS Core NetServer database Umbrella system interface proxy External data evaluation tool Export/ import EML server NE controller NE controller DCN connector DCN connection DCN connection EML server NE controller NE controller

Protocol stack Protocol stack NEs

3.3.1

TNMS Core NetServer

TNMS Core NetServer operates as a mediation device for the DCNs connected to it. It processes large volumes of data imported from the DCN and relays this information to the TNMS Core Server in compressed form. The NetServer supports all NE-specific functions, except for the element managers included with TNMS Core Client.

The NE Controllers

The NE controllers are provided with the NetServer application. A corresponding NE controller must be registered in the system for every NE type to be managed by TNMS Core. Each NE controller class can support different NE types, but each NE can only be controlled by one type of NE controller.

The main task of an NE controller is to convert NE-specific management interfaces to a simple internal TNMS Core element management interface. In this way, network layer management in the TNMS Core Server only receives the necessary information from the element management layer.

The DCN Connectors

The DCN connectors are separate software components included with the NetServer. An associated DCN connector must be provided for each DCN interfacing with TNMS Core.

The DCN connectors provide the interfaces for managing connections and transferring data between network elements and NE controllers. The main difference between the craft terminals (LCT and (NCT) and TNMS Core is that TNMS Core can operate all DCN connectors simultaneously.

The TNMS Core NetServer Database

The NetServer also includes the TNMS Core NetServer database where all relevant network element data is stored.

3.3.2

TNMS Core Server

TNMS Core Server is the central component of TNMS Core and controls the following

FCAPS (Fault, Configuration, Accounting, Performance, Security) functions for the

network management layer and element management layer: – Fault Management

– Configuration Management – Performance Management – Security Management

Data relating to these processes is written to various databases. The config database (also known as the TNMS Core registry) stores general data, the server database stores network management data and the log database stores log data. More information on TNMS Core databases is provided in Section 5.3.

As well as coordinating DCN management functions such as the administration of network element addresses, DCN channels and NetServers, TNMS Core Server also supports interfaces to higher-ranking network management systems, to TNMS Core NetServers and to TNMS Core Clients. Up to 20 Clients and 10 NetServers can be connected to the TNMS Core Server at the same time.

3.3.3

TNMS Core Client

TNMS Core Client provides an intuitive, user-friendly interface for network management. All TNMS Core Server management functions are accessed via the TNMS Core Client interface. Access is also provided to the element managers using a user interface identical to that of the LCTs. The element managers in turn access the NE via the NE controller provided with TNMS Core NetServer.

TNMS Core Client supports the connection of remote clients via modem or ISDN. For external data evaluation, TNMS Core Client therefore provides a data export function which enables the operator to save the content of each log to a separate file.

Other TNMS Core management functions are called up using the File, View, Fault, Configuration, Performance, Security, Windows and Help menus. Most functions are also directly accessible via object-oriented context menus.

3.3.4

TNMS Core SysAdmin

The SysAdmin application offers a dedicated user interface for performing system administration functions. Supported functions include user, database and account configuration, DCN management, system monitoring and system security.

These functions are accessed via the following items in the SysAdmin functional tree: – TNMS Server – Alarm Settings – Cost factors – Database – Date / Time – External Interfaces – Licensing – NE Inscription Settings – Security

Other administration functions can be called up using the File, View, Server, Configura-tion, Security, Window and Help menus, with additional windows also provided for system message log management, DCN management and TNMS Core Client moni-toring.

The interface itself is similar to the TNMS Core Client user interface (see Section 3.3.3) and is operated in similar fashion.

i

3.4

Databases

TNMS Core supports the following databases: – NetServer database

– Server database – Config database – Log database

The NetServer database is located in the TNMS Core NetServer. It stores all NE data relevant for TNMS Core management tasks. Since this data can be called up via the NEs at any time, the TNMS Core NetServer database does not include an automatic backup facility.

The Server database is located in the TNMS Core Server. It stores all network manage-ment data which cannot be assigned to NEs. This includes information on subscribers, services, paths and the resources which these require. Backup and restore functions are provided.

The Config database is located in the TNMS Core Server. It stores information concerning user management, licenses, general settings and DCN settings. Backup and restore functions are provided.

The Log database is located in the TNMS Core Server. It stores all logs, apart from the notification log. Backup and restore functions are provided.

The TNMS Core NetServer database and the TNMS Core Server database are created automatically the first time TNMS Core NetServer or TNMS Core Server are started. TNMS Core Server also creates a copy of the TNMS Core Server database and a log file so that the server database can be backed up and restored if necessary.

3.5

Interfaces to Higher-Ranking Management Systems

TNMS Core supports various external interfaces, with the external interfaces support package providing the OCA, SNMP and SNIF components.

The physical arrangement of the external interfaces is illustrated in Figure 3.2.

3.5.1

Data Import/Export Interfaces

TNMS Core supports a variety of convenient import/export options. As well as the import/export of network configuration data using XML, for example, performance logs defined for services or network elements can also be exported to different applications and systems using the Performance Log Export Tool (PLET). In addition to performance logs, alarm logs and network event logs can also be exported using external tools. Automatic access to logfile data is also available via the OLE-DB interface (object-linking and embedding database) for active data objects. This interface can also be used to export performance data for processing by external tools.

Finally, administration users can import and export external configuration data to and from the TNMS Core Server database using the import/export interfaces provided.

3.5.2

DCN Interfaces

Network elements are either connected directly to the TNMS Core NetServer or via an external element manager (see Fig. 2.1) and a DCN.

TNMS Core supports the following DCN technologies:

DCN Interface

Physical Interface Protocol Network Elements/ Element Managers

QB3 Ethernet (OSI) QD2 SDH e.g. SMA1/4 QST SDH e.g. SL16

Q3 WDM e.g. MTS, MODIF ELI-SXEM Ethernet (TCP/IP) ELI SXA, SXD

TNMPV2 Ethernet (TCP/IP) TNMP Radio NEs, e.g. SRT 1C QD2-SISA Ethernet (TCP/IP) SISA PDH (e.g. FMX, CMX) with

connection node type SISA-GKE only

EMOS-SLI RS232 SLI EMOS NEs, e.g. SLxx, SMAxx, etc.

Waveline (SNMP)

Ethernet (TCP/IP) SNMP Waveline EL2

UNO None None Universal objects

Each type of DCN is assigned to a specific type of network element, an important consideration during DCN planning (see Fig. 3.3 below).

Fig. 3.3 Data Connections via Different DCNs SMA SMA SMA SMA STM-1 ring QB3-DCN (routed via DCC channels) Ethernet TNMS Core FMX CMX FMX QD2 QD2-DCN routed via 64-kbit/s payload channel SISA-GKE

4

Installation Notes

The TNMS Core software includes a number of software applications and feature components. It is supplied on a CD-ROM which includes a convenient master installa-tion program for installing the individual TNMS Core applicainstalla-tions, or features such as QB3 Support, Waveline ELI, etc. Each application and feature can also be installed separately using the relevant package installation program.

The master installation program is also used for adding or removing components and subcomponents and for uninstalling or upgrading the TNMS Core software.

4.1

Licensed Software

Various software products referred to in this manual have been licensed by Siemens AG and are provided together with the TNMS Core software. Any questions concerning these products should therefore be directed to Siemens AG rather than to the manufac-turer in question.

4.2

Hardware Requirements

The table below provides an overview of the minimum hardware requirements for TNMS Core. However, as greater capacity may be required depending on the network size, planning for hardware, software and licences should be undertaken on a project-specific basis.

i

Hardware Remarks TNMS Core NetServer - Pentium III PC 800 MHz - Memory 1 GB - 18 GB SCSI HD - 1.44 MB floppy disk - CD-ROM drive - Ethernet card 2 x - 17-inch color monitor

TNMS Core Server - Pentium III PC 800 MHz - Memory 1 GB

- 36 GB SCSI HD 2 x - 1.44 MB floppy disk

- Ethernet cards 2 x, optional - 17-inch color monitor

- RAID controller Optional - DAT streamer for backup

TNMS Core Client - Pentium III PC 800 MHz - Memory 512 MB 2x - 9 GB SCSI HD - 1.44 MB floppy disk - CD-ROM drive - Ethernet card - 21-inch color monitor

- PC I/O card Optional

Operating System

Windows 2000 Professional/Server incl. Service Pack 2

Hardware Remarks

4.3

Additional Backup Hardware

TNMS Core meets stringent data security requirements by using a multi-stage concept. The TNMS Core configuration can be expanded as required using the following hard-ware options:

– Mirror disks: The TNMS Core Server is equipped with duplicate hard disks and a

SCSI RAID controller system. This prevents the failure of individual hard disks from interrupting operations.

– Warm standby TNMS Core Server: This option can be used if the TNMS Core

Server is no longer available, e.g. due to a fire or complete hardware failure. The warm standby server is a second server machine with exactly the same hardware and software configuration as the active server. The operator registers the warm standby server at the active TNMS Core Server and activates database replication mechanisms. Should a failure occur, the operator simply switches manually to the warm standby server and starts the TNMS Core Server process as normal on the warm standby computer.

– Cold standby TNMS Core NetServer: This option can be used if the TNMS Core

NetServer is no longer available, e.g. due to a fire or complete hardware failure. The cold standby NetServer is a second machine with exactly the same hardware and software configuration as the active NetServer. Activating a cold standby NetServer requires full DCN access at the standby site.

– Additional Archive Server: An additional server at the LAN runs as a file server for

the TNMS Core databases. Should the TNMS Core Server fail, the stored database backups can be used to restore the TNMS Core database.

– TNMS Core has an internal DAT system. This allows data to be backed up at regular intervals without interrupting operations.

5

Functional Overview

TNMS Core provides all the major network management functions defined in the ITU-T standard M.3010 “Principles for a Telecommunications Management Network”.

Fault, configuration and performance management are supported at the element management layer, with configuration management and fault management also provided at the network management layer. Additional configuration, fault and perfor-mance management features are available at the service management layer, and various security management features are also implemented.

5.1

Features of TNMS Core

The main features of TNMS Core are summarized below:

– Integrated management for network elements with WDM, SDH, PDH and Ethernet interfaces

– Management at the network layer, network element layer, and service management layer

– Fault, configuration, performance and security management

– End-to-end connection management at the following transmission levels SDH/SONET: STM-256, STM-64, STM-16, STM-4, STM-1, STM0, STS1 ( VC4, VC4-4, VC4-16, VC3, VC2, VC11, VC12)

PDH: 140, 45, 34, 8, 2; 1.5 Mbit/s, 64 kbit/s, n x 64 kbit/s WDM: OCh, OMS, ODU2

– Support by SNCP during manual routing – Support of VC4 concatenation

– Support of virtual private networks (VPN) – Support of domains

– Open CORBA interface to umbrella TMN

– SNMP interface to umbrella TMN (alarm management only) – IP interface to web/LCT

– Import/export interface for configuration data and logs – External alarming via e-mail/SMS

– Visual network representation, intuitive operator guidance, detailed and context-sensitive online help

– Scalable system architecture

– Multi-user capability (up to 20 clients can be connected to the server) – High system availability

– Remote control via public networks

– Dedicated configuration windows for automatic and manual routing – Grouping NEs to form NE containers

– Straightforward insertion/updating of network elements – Software upgrades without loss of data

– Subscriber management

– Support of different management interfaces to the NEs – Redundant standby system

These functions are available via the Client and SysAdmin interfaces. For more information, see Chapter 6 and Chapter 7.

5.2

Basic Operation

5.2.1

TNMS Core NetServer

Starting TNMS Core NetServer

TNMS Core NetServer can be started either automatically or manually. When the NetServer is started, all registered DCN connectors are activated. An associated NE controller is also detected and started for each accessible network element.

Once started, each NE controller requests from its network element the data required for detecting changes in alarms, port configurations, cross-connections, etc. This infor-mation is then compared with inforinfor-mation already stored for the network element on the NetServer.

During the synchronization process which follows, the NetServer compares its existing data with the data supplied by the NE. The NetServer data is overwritten if it does not correlate with the data supplied by the NE - data is not transferred to the network element. The operator can manually initiate the resynchronization of NE data and refresh current alarms. Other operator actions cannot be performed on the NE while the data request is in progress or during resynchronization.

Stopping TNMS Core NetServer

TNMS Core NetServer can be stopped by the administrator. This action shuts down all communication channels and isolates the DCN connectors from the DCN. The TNMS Core NetServer database is also closed.

Deactivating the TNMS Core NetServer

TNMS Core NetServer can also be deactivated by the administrator. This action suspends communication between the TNMS Core NetServer, NetServer components and the TNMS Core Server.

5.2.2

TNMS Core Server

Starting TNMS Core Server

TNMS Core Server can be either be started automatically or manually. Once it has been started, TNMS Core Server is linked to all active TNMS Core NetServers.

Concurrent Access

Concurrent access to different TNMS Core Clients is managed by the TNMS Core Server as follows:

– Network configuration, creation of port connections and alterations to icons in the network editor are only permitted for one TNMS Core Client at a time.

– Subscriber information can only be changed by one operator at a time.

– If selected for service management in the service mode, a network element is not available to other operators.

– Up to 20 Client installations can be operated simultaneously.

TNMS Core Server time in GMT to every available NE controller. The date and time are also distributed to all active NetServers and connected Client PCs, with the exception of NetServer or Client installations running on the TNMS Core Server machine.

Stopping TNMS Core Server

TNMS Core Server can be stopped by the administrator. When the server is stopped, all connected Client PCs are notified and any further login attempts rejected. Once all Clients have been isolated from the TNMS Core Server, the NetServers are shut down and the TNMS Core databases closed. The TNMS Core Server can also be stopped independently of the NetServers, for example if maintenance work is required.

5.2.3

TNMS Core Client

Starting a TNMS Core Client

Once the TNMS Core Client has been started, the operator can enter the login data. Functions authorized by the operator’s user class can now be accessed (see Section 7.9.2).

The Client contacts the Server and requests alarm information, port and connection data, and the data required for mapping the network. If complete data is not available for certain network elements, these are shown as unavailable on the user interface by a box containing three question marks.

The first time the Client is started, only the notifications log is opened. In subsequent sessions, log windows which were opened when previous sessions were shut down are also opened. The entries from previous sessions are then displayed.

If the TNMS Core Server is not available, an error message is displayed.

Starting Element Manager Applications

The element manager applications are started via TNMS Core Client. A data connection is established to the relevant NE which allows the user to execute required functions directly at the NE. The user interface is the same as for operations with the LCT.

Administrating NE Write Access

TNMS Core only administers write access to managed network elements which support this feature. Write access to a given network element or set of network elements can be requested, enforced or released. In this way the TNMS Core operator also has limited control over external LCT write access.

Terminating a TNMS Core Client Session

A TNMS Core Client session is terminated when the user logs off. All windows are closed and access is only provided to the login function.

5.3

Log Management

In TNMS Core, specific operator activities as well as random actions and events are stored in log files on the TNMS Core Server. The Performance Log Export Tool (PLET) exports performance logs defined for services or network elements to different applica-tions and systems. The log contents can also be printed out, saved to a file, or evaluated via a standard OLE-DB/ADO interface.

5.3.1

Log Classes

In TNMS Core, each log is assigned one of the following classes: – Permanent

– Custom – Non-persistent

Permanent logs are fixed, global logs administered by the TNMS Core system. The

operator can however specify certain attributes such as the type of event to be included, maximum log size, etc.

Custom logs are created and administered entirely by the operator. Operators can

create or delete custom logs according to their individual access rights. Attributes such as log capacity and scope can be defined as required, and logs of this type can also started or stopped at any time.

Non-persistent logs are maintained by the TNMS Core Client and TNMS Core

SysAdmin and only exist for the duration of a client session. The log content is deleted when the client session is terminated.

5.3.2

Log Types

The following log types are possible in TNMS Core:

The alarm log contains a chronological list of alarms which have occurred. Toggling alarms, i.e. identical alarms which are triggered repeatedly, are entered once only with a timestamp indicating when they were raised and when they were cleared.

Log Type TNMS Core Client

TNMS Core SysAdmin

Log Class

Alarm log X Permanent log

System message log X X Permanent log

Network event log X Permanent log

Security event log X Permanent log

Performance log X Custom log

Notifications log X X Non-persistent log Operator input log X Non-persistent log

The network event log documents configuration changes to the network management layer. It includes actions initiated or triggered directly by the network or individual network components.

The security event log documents relevant security events in TNMS Core. It provides information such as the event type, event severity and the object affected.

The performance log documents the performance records for the measurement points defined by the operator. As there may be several network elements each with a number of measurement points, special algorithms regulate data collection and ensure that each value is only requested once. These mechanisms prevent the unnecessarily high network loads which can occur when numerous data requests are sent simultaneously. The notifications log only documents events which are relevant for the current Client session, for example communication errors.

An individual operator input log can be created for each operator. Information relevant to the operator, such as executed actions, is collected from the permanent logs and presented in a report window. The operator input log is a snapshot, and is therefore not updated automatically.

6

Client Functions

6.1

Configuration Management

Configuration management is an umbrella term for the tasks involved in the organization and modification of the network plan, the creation and modification of services, and the administration of subscribers to these services.

6.1.1

Network Management

Network elements form the basis of the network topology. Each individual NE is both clearly identifiable and can also be combined with other NEs to form network structures known as NE containers. Further NE containers can then be created for each NE container configured.

Connections between the NEs or between ports of the same network element are referred to as external port connections. Connections between the various NE modules are referred to as internal port connections. An internal port connection cannot be deleted or created by the operator.

Network elements and port connections form the physical network depicted in the network plan. The internal port connections are only visible within the port connection property window.

TNMS Core contains a list of all port connections. The list can be filtered and also printed out or saved to a file for further processing.

6.1.2

Universal Objects (UNO)

Where network elements or other devices are not directly supported by TNMS Core or only offer restricted functionality, universal objects are used to provide the required management functions. Universal objects can be created, configured and deleted, and can be included in the network topology using port connections. For this purpose, modules and ports can be created and deleted for universal objects via a dedicated element manager application.

6.1.2.1

Network Augmentation

Network augmentation refers specifically to the dynamic aspects of network restruc-turing. This includes migration from one protection mechanism to another, the insertion and removal of traffic-carrying network elements, the re-routing of paths, the extension of managed networks and the merging of fragmented managed networks.

TNMS Core provides the following options for network augmentation:

– Re-routing paths: This can be implemented either directly where traffic interruption is permitted, or using SNCP mechanisms.

– Inserting and removing network elements: NEs can be inserted or removed by modi-fying port connections, even if these are used by services. The services must be detached beforehand.

6.1.3

Service Management

Service management includes the creation, maintenance and supervision of services. Once the relevant network elements have been selected, services (also known as end-to-end connections or paths) can be established quickly and conveniently in TNMS Core Client using dedicated configuration windows. These guide the user step-by-step through connection setup. Once they have been configured, services are then assigned to a subscriber.

Services can be created either automatically or manually.

With automatic routing, only the endpoints must be selected. Available connections are then searched for across all network elements between these endpoints. Automatic routing is not possible in mixed networks.

With manual routing, the operator must configure the service step-by-step via the appro-priate network elements from one endpoint to the other endpoint.

Services which are created automatically can be configured with additional protection the during automatic routing process. For manually-created services, additional protec-tion can be configured after the service has been created.

Supported Services

Unidirectional, bidirectional and broadcast services (consisting of several unidirectional services) can be created. The services which TNMS Core can administer are classified according to the source and destination port, the transmission direction and type of TP, the bitrate, and the type of user data which can be transmitted (WDM, SDH or PDH). Services are also classified according to whether both endpoints are located within the administered network (closed path), or whether one endpoint or both endpoints are located outside the network (half-open path or open path).

Physical verification of the routed paths can be implemented using the options for path loopback.

Status Management of Services and Paths

Services and paths are assigned three different operating states: – Operational

– Administrative – Provisioning.

The operational state indicates whether sufficient resources are currently available to enable access to the service or path. The administrative state indicates whether this service or path has been locked or unlocked by the administrator. The provisioning state indicates whether the service or path has been correctly configured.

The operational, administrative and provisioning states are shown in the service prop-erties. The provisioning state of a port connection is also indicated by the color of the ends of the port connection line which links the ports together.

Showing Services and Paths

The user interface offers various service and path views.

The ‘Service Tree View’ for example contains a complete overview of all services and paths assigned to particular subscribers. If a path is selected in this view, it can be high-lighted in the network plan. TNMS Core also provides a list of all services and paths together with relevant attributes. This list can be filtered according to the given

attributes, and also printed out or saved to a file for further processing. The details of a service can be displayed or modified both in the service tree view and in the list view.

6.1.4

Subscriber Management

Each new service is assigned to a subscriber. The subscriber’s name can be added to a subscriber list in TNMS Core Client, together with other relevant contact data. This list can then be printed out or saved to a file for further processing.

6.2

Performance Management

TNMS Core enables transmission quality in the network to be monitored at one or more network elements using a series of PMPs (performance measurement points). PMPs can also be defined for a specific path or service.

The performance data collected is stored on the TNMS Core Server machine in user-defined performance logs (see Section 5.3 for details). A new performance log can be created at any time, however in order to modify or delete an existing performance log, the log in question must be locked first.

A measurement and an update interval is configured for each performance measure-ment log. The measuremeasure-ment interval which determines how often data is collected can be set to either every 15 minutes or every 24 hours. The update interval which deter-mines when data is actually written to the performance data log is freely configurable. However, in order to minimize the DCN load, it should always be set in accordance with the measurement interval. The data is evaluated in accordance with ITU-T recommen-dations concerning error performance (G.821 and G.826).

Transmission quality can also be monitored using element managers. For network elements managed by EM-OS or TNMS-SX, performance management is possible both via TNMS Core or directly via the EM-OS or TNMS-SX element managers.

6.3

Fault Management

Fault management comprises all TNMS Core alarm handling functions. These include: – Alarm list

– Alarm log

– Display of alarm summary – Display of alarm state – Display of alarm severity – Audible alarm

– External alarm output

All alarms are administered in the TNMS Core Server and recorded in an alarm list and an alarm log. The alarm list is accessed via the TNMS Core Client. A global alarm list contains all alarms currently raised for all NEs in the network, with the exception of alarms which have been suppressed. An individual list of current alarms can also be generated for each NE. Once an alarm has been cleared it is deleted from the alarm list. The alarm log, by contrast, is a permanent record containing all network element layer alarms, both raised and cleared. It provides a complete alarm history for the supervised

The operator can localize the network element raising the alarm by referring to the alarm list. The NE is then highlighted in the network plan and the DCN tree structure. Specific symbols are used to illustrate the current access state and the highest alarm severity. These can be displayed for both the network as a whole as well as for individual network elements. This allows the user to quickly assess the importance of the alarm concerned. The alarms at the ports determine the color of the port connection line on the network plan.

The user can also refresh the alarm information either for an individual network element, for all NEs in an NE container or for all NEs in a DCN.

For further fault localization, the user can also call up the appropriate element manager. The element manager EM-OS, for example, provides an alarm list which can be displayed by TNMS Core. Additional functions must be performed via the element manager itself. This is simplified by screen-level integration of the EM-OS GUI.

Raised alarms can also be correlated either automatically or manually to the corre-sponding paths. With automatic correlation, alarms are only correlated to the endpoints of the affected path so that the operational state of the path can be determined quickly. Complete manual alarm correlation is also supported for complex paths so that all termi-nation points, ports and modules in the current path are also included.

6.4

Security Management

Security management functions are provided to restrict access to either the TNMS Core user interface or to individual network elements.

Access to the TNMS Core user interface is regulated by a user ID password which is initially configured under the security settings in the SysAdmin application (see Chapter 7). If required, this password can subsequently be changed directly in the Client appli-cation.

For NEs which do not have their own security mechanisms, access can be restricted via the NE write access options (see Section 5.2.3).

7

SysAdmin Functions

7.1

TNMS Server

The TNMS Server option in the SysAdmin menu tree provides an overview of the TNMS Core Server properties as well as a list of installed sub-components.

7.2

Alarm Settings

SysAdmin supports the following alarm handling features:

– Alarm messenger for alarm summary forwarding via email/SMS – Configurable alarm severity colors

– Configurable toggle filter to sort alarm events – Configurable alarm objects

– Configurable probable causes for alarms

7.3

Cost Factors

Cost factors can be used to optimize automatically-routed paths. If cost factors are assigned to port connections, these connections are considered less attractive by the automatic router which then searches for less expensive options.

7.4

Database

SysAdmin provides a comprehensive range of database functions. These functions are available to system administrators only, and include database analysis to ensure data consistency and integrity, backup and recovery utilities for data restoration in the case of system failure, and options for importing/exporting network configuration data. TNMS Core system data is distributed across a number of databases (see Chapter 3 for details).

Backup

TNMS Core provides a backup facility which enables the administrator to maintain several sets for the TNMS Core Server database, TNMS Core Config database and TNMS Core Log database for later restoration. The operator can either implement the backup manually, or can configure a scheduled backup to be saved to a particular direc-tory at a particular time. During the backup procedure, an analysis function checks the referential integrity and data consistency of each backup. A browse function is also provided so that the administrator can obtain an overview of existing backup sets. As part of a manual or scheduled operation, backup sets in the dedicated directory can be copied by the operator to a SCSI DAT streamer using the Windows 2000 backup utility. This can be completed once a day, preferably at a time of low system and user activity.

Restore

tion should also be selected. Once the restore operation has been completed, the TNMS Core Server and TNMS Core NetServer have to be restarted. Restarting the TNMS Core Server opens the restored databases and restores the backed-up configuration.

Data Replication

To minimize the loss of data after a system component breaks down, the TNMS Core system provides an internal database recovery mechanism for all TNMS Core data-bases. This mechanism automatically implements an internal backup at regular intervals using a previously-created backup copy of the database. The database itself is not affected and normal system functionality is still available while database recovery is in progress. Should a software failure occur, the system uses these database backups to restart the system.

TNMS Core also provides an incremental data replication function which continuously replicates the databases of the active server system to the standby system. Should the active server fail, the operator can then switch to the standby system. However, open transactions and queued jobs are lost.

DB Import/Export

With this component the operator can export and import network configuration data. NetServer, DCN channel, network element, NE container or port connection data can be selected as required, and then imported from a source file or exported to a destina-tion file accordingly. In this way, data can be read into the system automatically so that the operator does not need to re-enter configurations manually.

Log Configuration

Several different log types are maintained by the system. The space available on the hard disk for TNMS Core log data can be set using this option. Once this has been completed, the system message log can be configured to include a specific level of entries, for example, and the network event log configured to include particular types of network event. Display and configuration facilities are also provided for the operator input log and security event log in the main SysAdmin menu. For more information on log management and log types, see Chapter 5.

7.5

Date / Time

The system date and time configured for the TNMS Server can be viewed and adjusted as required. The server date and time can also be set to the date and time of the SysAdmin PC .

7.6

External Interfaces

7.6.1

SNMP Proxy

The SNMP proxy component provides an SNMP-based interface to the network layer of the TNMS Core system and enables access to the TNMS Core management informa-tion base (MIB). It facilitates the integrainforma-tion of TNMS Core with umbrella fault manage-ment systems such as INMS so that any umbrella managemanage-ment system which supports the SNMP protocol and which recognizes the TNMS Core MIB can read object

proper-ties and receive traps from the TNMS Core element management layer and network management layer.

The SNMP proxy is a read-only interface. Once it has been configured under SysAdmin, it can be activated or deactivated as required.

7.6.2

OCA Proxy

The OCA (Open Corba Agent) proxy is an optional module which implements the open CORBA interface, a standardized, multi-technology interface for the management of multi-vendor transport networks. The OCA proxy enables the TNMS Core Server to connect to third-party open CORBA managers and should be installed if TNMS Core is to be connected to a superior network management system. WDM and SDH network elements are supported, however support is not available for PDH or SISA-V network elements.

The OCA interface in implemented in line with TMF (TeleManagement Forum).

7.6.3

SNIF Proxy

The SNIF proxy provides access to SNIF (Service Network Interface), a read only, service-oriented interface. Two SNIF interfaces are provided, SNIF/S and SNIF/C. SNIF/S is a CORBA interface between TNMS Core Server and an umbrella manage-ment system. This interface makes the connections of the NE container (paths) managed in the TNMS Core system available to umbrella management systems. SNIF/C is an OLE2 automation interface between TNMS Core Client and an umbrella management GUI client.

7.7

Licensing

TNMS Core supports security mechanisms for accessing network elements, if these are also provided by the network elements. When a connection is created to an NE, login must be completed successfully. A password is required for each NE, and if additional network element licences are required, these can be configured under Licensing.

7.8

NE Inscription Settings

The network element inscription labels shown in the Network View in TNMS Client can be adjusted here. The ID name of the network element appears by default, however other information such as the NE name, NE type, location, or user-defined texts entered in the network element property pages can also be included as required.

7.9

Security

Special security features are provided by SysAdmin to regulate access to the TNMS Core interface. An authorized user must have an account with a valid user ID and pass-word.

7.9.1

Account Policy

Global account settings which apply for all user accounts are set under Account Policy. These include specific password restrictions and options for account lockout if an incor-rect password is entered.

7.9.2

User Management

Under User Management, existing user configurations can be changed and new users set up by the administrator. The level of user access is determined by the user class, user properties, and password restrictions set by the administrator for the user in ques-tion.

The user class is of particular significance as it determines the range of functions which a user is permitted to perform:

– Supervision: the user can execute supervision functions but cannot configure or

modify element manager applications.

– Maintenance: the user can execute supervision functions and start element

manager applications to access specific data on NEs. The user can also acknowl-edge alarms and configure performance logs to monitor system performance. – Operation: the user can perform maintenance functions and create, modify or

delete services.

– Configuration: the user can perform operation functions and configuration

management functions.

– Administration: the user can perform configuration functions and all administration

management functions. In other words, the user has unrestricted access.

If required, the administrator can also assign a user to one or more user groups. The access rights defined by the individual user classes are no longer taken into account in this case. The user group can be authorized to access one or more NE containers each of which may represent a network domain. However, each individual NE container can only be assigned one user or user group. The user’s access rights are limited to the NE container assigned and the NEs which this container comprises.

7.10

DCN Management

Various functions can be implemented via DCN Management, including: – Modification of TNMS Server properties

– Activation/deactivation of DCN channels – Inclusion of new NetServers

– Incorporation/deletion of network elements

– Modification of NetServer, network element and DCN channel properties – Display of all QD2 SISA +EMOS network elements

Network elements or other devices which are not directly supported by TNMS Core can be managed using universal objects (see Chapter6).

8

Abbreviations

BSHR Bidirectional Self Healing Ring DCC Data Communication Channel

DCN Data Communications Network (G.784) ELI External Link Interface

EM Element Manager

EML Element Management Layer GMT Greenwich Mean Time

ID Indentification (Service Status) IMN Installation Manual

ISDN Integrated Services Digital Network ITU-T Telecommunication Standardization Sector

of International Telecommunications Union LAN Local Area Network

LCT Local Craft Terminal

MSLTP Multiplex Section Linear Trail Protection NCT Network Craft Terminal

OCA Open Corba Agent OGL Operator Guidelines

OSI Open Systems Interconnection (G.784) OSN Optical Service Node

PDH Plesiochronous Digital Hierarchy

RAID Redundancy Array of Independent Disks SCSI Small Computer System Interface SDH Synchronous Digital Hierarchy SNCP Subnetwork Connection Protection SNMP Simple Network Management Protocol SONET Synchronous Optical Network

STM Synchronous Transport Module TED Technical Description

TMN Telecommunication Management Network TP Termination Point

UHC Ultra-High Capacity UNO Universal Objects VC Virtual Container