Siemens TNMS (Technical Descriptions)

Information TNMS Core 6.0 TED A42022-L5938-B51-1-7618

TED

!

Information TNMS Core 6.0

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 property 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 Technical modifications possible. Technical specifications and features are binding only insofar as they are specifically and expressly agreed upon in a written contract.

2

A42022-L5938-B51-1-7618


TED

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

Contents 1 1.1 1.2 1.3

Introductory Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Available Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Symbols Used in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 2.1 2.1.1 2.1.2 2.1.2.1 2.1.2.2 2.1.2.3 2.2

Network Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Network Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Network Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Data Communication Networks (DCN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 PDH Access Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 SDH Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 WDM Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Network Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 3.1 3.2 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.4 3.5 3.5.1 3.5.2

System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core NetServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core SysAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interfaces to Higher-Ranking Management Systems . . . . . . . . . . . . . . . . . Data Import/Export Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DCN Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16 16 16 18 19 19 20 20 21 21 21 22

4 4.1 4.2 4.3

Installation Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Licensed Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Additional Backup Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24 24 24 26

5 5.1 5.2 5.2.1 5.2.2 5.2.3 5.3 5.3.1 5.3.2

Functional Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Features of TNMS Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core NetServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Log Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Log Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Log Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 27 28 28 28 29 30 30 30

6 6.1 6.1.1 6.1.2 6.1.2.1

Client Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Universal Objects (UNO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Augmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32 32 32 32 32

A42022-L5938-B51-1-7618

5 5 6 6

3

TED

4


6.1.3 6.1.4 6.2 6.3 6.4

Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Subscriber Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Performance Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 7.1 7.2 7.3 7.4 7.5 7.6 7.6.1 7.6.2 7.6.3 7.7 7.8 7.9 7.9.1 7.9.2 7.10

SysAdmin Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 TNMS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Alarm Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Cost Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Date / Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 External Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 SNMP Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 OCA Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 SNIF Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 NE Inscription Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Account Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 DCN Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8

Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

A42022-L5938-B51-1-7618


TED

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

Table 1.1

TNMS Core Manuals

•

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

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

A42022-L5938-B51-1-7618

5

TED


1.2

Symbols Used in This Manual The following symbols are used in this manual: Additional information

i

Warnings

! Table 1.2

1.3

Symbols

Feedback We aim to provide you with documentation which is easy to understand and userfriendly. 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 necessary, do not forget to enter your contact details. Thank you in advance for your support!

6

A42022-L5938-B51-1-7618


TED

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

(...)

_______________________________

(...)

_______________________________

Page

A42022-L5938-B51-1-7618

Remarks

7

TED


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. TNMS Core Integrated element manager (EM): LCTs, TNMS-SX, EM-OS

Management interface

Type of network element

QD2SISA

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

QB3

ELI-SXEM

DCN

TNMS-SX

Waveline (SNMP)

SXA, SXD

Waveline EL2

EMOS-SLI

SLxx, SMAxx, etc.

EM-OS

TNMPV2 SRT 1C

UNO (logical interface)

Fig. 2.1

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

General Structure of a TNMS Core Network

Element management functions are executed via the element managers (LCTs, TNMSSX, 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.

8

A42022-L5938-B51-1-7618


TED

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 WDM

Table 2.1

A42022-L5938-B51-1-7618

Device

Version

Note

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

List of Supported Network Elements

9

TED


NE class SDH

Device

Version

OSN WTTR

2.0

SMA1/4

2.2.3, 2.3, 2.3E

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

Note

Includes 45 M tributary

ISDH PDH

FMX2 (MXS19 and CMXS subrack)

2

CC64kr LTO-LT, LTO-NT

SISA-V

Table 2.1

10

ASA32

SUE

LTCOH-LT, LTCOH-NT

LTC(LT), LTC(NT)

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

List of Supported Network Elements (Cont.)

A42022-L5938-B51-1-7618


TED

NE class Other

Table 2.1

Device Waveline EL

Version

Note

2

ERX700/1400

Screen-level integration of EM

SSU-2000E


ULAF+


Microsens GBE


List of Supported Network Elements (Cont.)

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.

A42022-L5938-B51-1-7618

11

TED


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

TNMS Core

DCN

SMA

SMA

SMA

STM-4 STM-4 SMA

SMA SMA

CMX

CMX CMX

FMX

Fig. 2.2

12

FMX Managed network

PDH Access Network

A42022-L5938-B51-1-7618


2.1.2.2

TED

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.

TNMS Core

DCN

Managed network SL64

SL64

STM-64

SL64

SMA16 SXA SLD16

SLD16 STM-16

SLD16

SLD16 MSLTP

SMA1

SMA4 SMA4 SMA1K

SMA1K STM-4

SMA4

Fig. 2.3

SMA4

SDH Network

A42022-L5938-B51-1-7618

13

TED


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

TNMS Core

DCN

n x 10 Gbit/s

n x 10 Gbit/s

OSN

Infinity

Infinity

Infinity

OSN

Infinity

Managed network Infinity

OSN n x 10 Gbit/s

Fig. 2.4

14

Infinity

Infinity

Infinity

OSN n x 10 Gbit/s

WDM Network

A42022-L5938-B51-1-7618


TED

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.

A42022-L5938-B51-1-7618

15

TED


3 System Overview 3.1

General Information The telecommunication network management system TNMS Core is an integrated solution 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. TNMS Core Client (1) TNMS Core SysAdmin

TNMS Core Client (max. 20 PCs, 3rd-party software) TNMS Core SysAdmin TNMS Core Server (TNMS Core SysAdmin, 3rd-party software)

Large network

TNMS Core NetServer (1)

TNMS Core NetServer (max. 10 PCs)

Subnetwork B Subnetwork A

Fig. 3.1

Subnetwork C

System Architecture

The TNMS Core software comprises the Client, SysAdmin, Server and NetServer applications. Client and SysAdmin are installed on a client PC. To support distributed operation of the network, up to 20 Client installations can be managed simultaneously. Concurrent access to network resources is regulated by the server PC - only one operator 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 client and server PC is interrupted. If the installation of an OCA proxy or SNIF proxy is required, additional 3rd-party software must also be installed on the server PC.

16

A42022-L5938-B51-1-7618


TED

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.

A42022-L5938-B51-1-7618

17

TED


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). TNMS Core SysAdmin components External data Export/ evaluation tool import

TNMS Core Client components Element manager SNIF/C

Element manager

TNMS Core Client

TNMS Core SysAdmin

Network management user interface

System administration user interface

TNMS Core Server components SNIF

Umbrella system interface proxy

SNMP

Umbrella system interface proxy

TNMS Core Config database

Open CORBA Umbrella system interface proxy

TNMS Core Server database TNMS Core Log database

TNMS Core Server

TNMS Core NetServer components TNMS Core NetServer database

TNMS Core NetServer EML server NE controller NE controller

EML server NE controller NE controller

DCN connector DCN connection DCN connection Protocol stack NEs NEs Fig. 3.2

18

Protocol stack NEs NEs

Software Components

A42022-L5938-B51-1-7618


TED

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.

A42022-L5938-B51-1-7618

19

TED


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.

i 3.3.4

Detailed operating information is provided in the Operator Guidelines (OGL) and in the online help.

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, Configuration, Security, Window and Help menus, with additional windows also provided for system message log management, DCN management and TNMS Core Client monitoring. The interface itself is similar to the TNMS Core Client user interface (see Section 3.3.3) and is operated in similar fashion.

i

20

Detailed information on SysAdmin is provided in the Operator Guidelines (OGL) and in the online help.

A42022-L5938-B51-1-7618


TED

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 management 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 (objectlinking 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.

A42022-L5938-B51-1-7618

21

TED


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 QB3

Ethernet (OSI)

Protocol

Network Elements/ Element Managers

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

Table 3.1

22

Physical Interface

DCN Interfaces

A42022-L5938-B51-1-7618


TED

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

TNMS Core

Ethernet SISAGKE QD2 FMX

SMA

SMA

STM-1 ring

SMA

SMA

QB3-DCN (routed via DCC channels)

CMX QD2-DCN routed via 64-kbit/s payload channel

Fig. 3.3

A42022-L5938-B51-1-7618

FMX

Data Connections via Different DCNs

23

TED


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 installation program for installing the individual TNMS Core applications, 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 manufacturer in question.

i 4.2

Full commissioning and startup details can be found in the Installation Manual (IMN).

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

2x

- 17-inch color monitor

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

2x

- 1.44 MB floppy disk - CD-ROM drive Tab. 4.1

24

Hardware Requirements

A42022-L5938-B51-1-7618


TED

Hardware - Ethernet cards

Remarks 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 Tab. 4.1

A42022-L5938-B51-1-7618

Hardware Requirements

25

TED


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 hardware options: –

–

–

–

–

26

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.

A42022-L5938-B51-1-7618


TED

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 performance 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 contextsensitive 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.

A42022-L5938-B51-1-7618

27

TED


5.2 5.2.1

Basic Operation 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 information is then compared with information 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. Distribution of Date / Time TNMS Core provides a manual date and time synchronization function for all managed NEs and TNMS Core components. The TNMS Core Server distributes the current

28

A42022-L5938-B51-1-7618


TED

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.

A42022-L5938-B51-1-7618

29

TED


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 applications 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: Log Type

TNMS Core Client

Alarm log

X

System message log

X

Network event log

X

Security event log X

Notifications log

X

Table 5.1

Log Class Permanent log

X

Permanent log Permanent log

X

Performance log

Operator input log

TNMS Core SysAdmin

Permanent log Custom log

X

Non-persistent log

X

Non-persistent log

Log Types

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. The system message log contains a chronological list of relevant administrative events. Critical events are indicated at the user interface.

30

A42022-L5938-B51-1-7618


TED

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.

A42022-L5938-B51-1-7618

31

TED


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 restructuring. 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 modifying port connections, even if these are used by services. The services must be detached beforehand.

32

A42022-L5938-B51-1-7618


TED

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 endto-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 appropriate 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 protection 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 properties. 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 highlighted 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

A42022-L5938-B51-1-7618

33

TED


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 userdefined 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 measurement log. The measurement interval which determines how often data is collected can be set to either every 15 minutes or every 24 hours. The update interval which determines 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 recommendations 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 network. The size of this log can be configured as required for up to one million entries. The alarm log and alarm lists can also be filtered and sorted in accordance with specific criteria.

34

A42022-L5938-B51-1-7618


TED

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 corresponding 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 termination 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 application. 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).

A42022-L5938-B51-1-7618

35

TED


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 directory 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 Stopping the TNMS Server activates a restore option which the operator can use to restore a previously-created backup set from the dedicated backup directory. This operation can only be completed offline and is used to support system migration, for example. To prevent inconsistent configuration data, the option for NetServer deactiva-

36

A42022-L5938-B51-1-7618


TED

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 databases. 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 destination 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 7.6.1

External Interfaces 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 information base (MIB). It facilitates the integration of TNMS Core with umbrella fault management systems such as INMS so that any umbrella management system which supports the SNMP protocol and which recognizes the TNMS Core MIB can read object proper-

A42022-L5938-B51-1-7618

37

TED


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 management 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 password.

38

A42022-L5938-B51-1-7618


TED

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 incorrect 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 question. 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 acknowledge 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 Chapter 6).

A42022-L5938-B51-1-7618

39

TED

40


A42022-L5938-B51-1-7618


8

TED

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

WDM

Wavelength Division Multiplexing

A42022-L5938-B51-1-7618

41

Siemens TNMS (Technical Descriptions)

Recommend Documents