TNMS_TED

TNMS Core/CDM 12.0

Technical Description (TED)Issue 1

May 2009

A50023-K1010-X910-01-7618Technical Description (TED)

2 A50023-K1010-X910-01-7618Technical Description (TED)

Technical Description (TED)

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2009. All rights reserved

f Important Notice on Product Safety Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may 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 / IEC 60950. All equipment connected has to comply with the applicable safety standards.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Span-nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.

Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-zungen und Sachschäden führen.

Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und wartet.

Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.


3


Table of ContentsThis document has 55 pages.

1 Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1 Intended audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Structure of this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Symbols used in the manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4 Available documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Network overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1 Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.1 Network elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.2 Data communication networks (DCN). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.3 Examples of networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.3.1 WDM networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.3.2 Data networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.3.3 SDH networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.3.4 PDH access networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2 Network protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 System overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1 System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Hardware components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3 Software components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3.1 Core Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.2 Core NetServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.3 Core Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.4 Core System Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4 Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.5 System scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.6 Operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.7 External interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.8 System availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Installation notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.1 Licensed software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.2 NE upgrade packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Older Core versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Functional overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.1 Core features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2 Basic operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2.1 Core Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2.2 Core NetServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2.3 Core System Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2.4 Core Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3 Log management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3.1 Log classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3.2 Log types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34



5.4 Scheduled service activation/deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Client functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.1 Configuration management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.1.1 Network topology management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.1.2 Path management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.1.3 Subscriber management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.2 Performance management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2.1 Performance Log Export Tool (PLET) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2.2 TNMS OTS-4000 Performance Add On Tool (TOPAT) . . . . . . . . . . . . . . . . 426.3 Fault management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.4 Security management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7 Optional software components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.1 ASON/Ethernet Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2 Northbound interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2.1 TMF CORBA Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2.2 SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.3 Southbound interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.3.1 TMF CORBA Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8 System Administration functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.2 Alarm settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.3 Cost factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.4 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.5 Date/time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.6 License manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.7 NE inscription settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.8.1 Account policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.8.2 User management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.8.3 Container access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508.9 Northbound interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518.10 DCN management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518.10.1 NetServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518.10.2 DCN channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

9 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53


5


List of FiguresFigure 1 general structure of a Core network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Figure 2 example of data connections via different DCNs . . . . . . . . . . . . . . . . . . 15Figure 3 a WDM network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Figure 4 a data network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figure 5 an SDH network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Figure 6 a PDH access network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Figure 7 system architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figure 8 overview of software components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 9 a Core medium system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figure 10 a Core large system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27



List of TablesTable 1 structure of the manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Table 2 symbols used in the manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Table 3 list of supported NEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Table 4 HW recommendations for Core Server, NetServer, Client . . . . . . . . . . 22Table 5 external Interfaces of Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Table 6 log types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Table 7 DCN channels and interfaces supported by Core . . . . . . . . . . . . . . . . . 52


7

Technical Description (TED) Preface

1 PrefaceTNMS Core/CDM, hereinafter referred to as Core, is a telecommunications network management system comprising four applications: Client, System Administration, Server and NetServer.

1.1 Intended audienceThis document is intended to provide a technical overview of the applications, features, system architecture and functions of Core to operators with responsibilities of installa-tion, administration, supervision, operation, configuration and/or maintenance of the network.

1.2 Structure of this documentThis document, interchangeably referred to as manual, is structured as follows:

1.3 Symbols used in the manualThe following symbols are used in the manual:

Chapter Title Subject

Chapter 1 Preface Provides an introduction to this document.

Chapter 2 Network overview Provides a network overview.

Chapter 3 System overview Provides a system description.

Chapter 4 Installation notes Brief information on installation.

Chapter 5 Functional overview Provides information on the main features and operations of Core.

Chapter 6 Client functions Provides information about the Client applica-tion and user interface.

Chapter 7 Optional software components

Provides information about the optional compo-nents of Core.

Chapter 8 System Administra-tion functions

Provides information about the System Admin-istration application and user interface.

Table 1 structure of the manual

Symbol Explanation

Notes provide additional useful information.

Warnings give you important information which must be followed in order to avoid possible equipment damage or data loss.

Table 2 symbols used in the manual


Technical Description (TED)Preface

1.4 Available documentationAll Core manuals are available in English on DVD and can be ordered from Nokia Siemens Networks technical sales.

• Technical Description (TED)The Technical Description provides an overview of the applications, features, system architecture and functions of Core.

• Installation Manual (IMN)The Installation Manual contains instructions on installing Core.

• Operator Guidelines (OGL)The Operator Guidelines contain a general description of the Core Client and Core System Administration user interfaces.

• Operator Source Licenses (OSL)The Operator Source Licenses contains the text for several software licenses as well as the terms and conditions of each license.

You may also consult the online help which is provided with Core. It provides compre-hensive instructions on the functions offered by the Client and System Administration 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 for Core and the individual instruction manuals are also provided as *.pdf files under the Help menu. These files can be viewed and printed using Adobe Reader.


9

Technical Description (TED) Network overview

2 Network overviewCore is an integrated telecommunications network management system solution designed for large, medium and small networks. It supports network elements with WDM, OTH, SDH, PDH, Ethernet and Data interfaces and can be used to manage networks at the access, edge, metro, core and backbone levels.

Figure 1 general structure of a Core network


Technical Description (TED)Network overview

The figure above shows the general structure of a transmission network managed by Core. The NEs provide various management interfaces. This means that they can be connected via the DCN to the management system in several ways.

Element management functions are executed via the ethernet managers (LCTs, TNMS-SX, EM-OS, NetViewer NME) provided by the 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 Core network plan.

2.1 Network architectureCore can be used universally in all kinds of transport networks. The seamless integration of WDM, SDH, PDH, Radio and Data equipment significantly broadens the range of possible application scenarios. This manual offers a few examples.

2.1.1 Network elementsCore supports line, star, ring and mesh networks. Those networks may contain the sup-ported network elements listed in Table 3. Further NE types or versions can be added with software upgrade packages. Please refer to the release notes for further current NE versions.


11


NE class Device Version Note

WDM/

DWDM

FSP150 1.1, 2.1

FSP500 3.3 FM only

FSP1500 2.0, 2.1, 3.0(M), 3.1, 3.2

3.0 M (unprotected /M and Protected /M/P)

FSP2000 5.7, 5.8, 6.1, 6.2, 6.3, 6.5

FSP3000 3.4

FSP3000R7 7.0, 7.1.5, 7.1.68.1, 8.3

Infinity WLS 2.0, 2.05

Infinity MTS 1.1 ANSI, 2.05 1.1 ANSI not compatible with SDH devices, can be operated only with SONET equipment. Only subtypes OTT8, OTT16 and OLR are supported

Infinity MTS 1c 1.0

OCU 1.2.5, 2.01, 2.1.5, 2.2, 2.6, 2.65

SURPASS hiT 7300 4.0.3, 4.1 4.1.1, 4.2

SURPASS hiT 7500 3.02,3.13.60, 3.13.80,3.20,3.21.10, 3.21.20

SURPASS hiT 7540 1.5, 2.65

SURPASS hiT 7550 2.05

Waveline EL2 2.0

Waveline MN 3.1

Juniper M120, T320 V9.4, R1.8 10G only

Table 3 list of supported NEs



SDH SL16 2.4.1, 2.5 2.6

SL64 3.25, 3.27, 3.3

SLR16 2.2

SMA 1/4 2.2(R), 2.3(R)

SMA 4/1 4.2, 4.3

SMA1K 3.2, 3.3

SMA1K-CP 3.2, 3.3

SMA16/4 4.2, 4.3

SN16000 7.5

SURPASS hiT 7020 3.1, 3.2

SURPASS hiT 7025 4.0, 4.1, 4.2

SURPASS hiT 7030 3.3.1MTC, 3.4, 4.0

SURPASS hiT 7035 4.0, 4.1, 4.15, 4.2, 4.3

4.0, 4.01: extension shelf of SURPASS hiT 7060/hiT 7060HC

SURPASS hiT 7050 1.1, 3.1, 3.12, 3.2, 3.2.1MTC

FP1 (all versions).CC (for v3.1 and v3.2)

SURPASS hiT 7060 3.1, 3.2HC, 3.3, 3.3HC, 3.4, 4.0, 4.1, 4.2

SURPASS hiT 7070 1.1, 2.0, 2.1, 3.0, 3.2, 3.3, 3.4

SURPASS hiT 7080 4.0, 4.1, 4.15

SXA 2.50, 3.20, 3.25

SXD 1.30, 2.15

WTTR 2.0

PDH ASA32 SUE

CC64kr

FMX II (MXS19 and CMXS subrack)

2, 3

LTCOH-LT, LTCOH-NT LTC(LT), LTC(NT)

LTO-LT, LTO-NT

ULAF+ 3.1, 3.2, 3.5

Other SSU-2000E 1.0


Table 3 list of supported NEs (Cont.)


13


SDH Radio

SPS 155 1.5/2.3 Supported as icon only.TCOM required

SRA 1 1.13.x/2.13, 1.14.x/2.14

Supported as icon only.TCOM required

series 3:3.3.x, 3.4.x, 3.5.x, 3.6.x

TCOM required

series 4:4.1.x

TCOM required

SRA 1S 1.11.x/2.11.x 1.14.x/2.14.x

TCOM required

SRT 1 1.5/2.3 Supported as icon only.TCOM required

SRT 1C 1.15.x/2.15.x 1.16.x/2.16.x 1.18.x

TCOM required

SRT 1S 1.2.2/2.1 Supported as icon only.TCOM required

SPS E 3.0.x, 3.1.x TCOM required

SRT 1F 4.0.x, 4.1.x TCOM required

SRA 4 4.2.x, 4.4.x, 4.5.x, 4.6.x

TCOM required

Dual Q-Adapter 4.5 FM only

SRA 4HC 1.1.x Supported as icon only.TCOM required





PDH Radio

SRA L 1.3.x/2.1, 1.4.x/2.2, 1.3.xF/2.1F; 1.4.xF/2.2F; 1.3.xS2.1S; 1.4.xS/2.2S

TCOM required

SRA L XD FO(Fully Outdoor)

2.5

SRA L XD 3.3, 3.4, 3.5, 3.6, 3.9.x, 3.10.x, 4.3

3.10.x supported as icon only

SRA L XD TwoE1 1.3

MicroHop 5.2 Supported as icon only

MinIDU 6.3 Supported as icon only

SkyWeb 2.4, 2.5, MS GFL, PS GFL

MS GFL and PS GFL supported as icon only




15


2.1.2 Data communication networks (DCN)Data communication networks play an important role in managed transmission net-works. DCN faults therefore have a considerable effect on the functionality of the network as a whole. The transmission rate of each DCN also influences overall network performance.

Settings for the various DCN interfaces to the network elements (e.g. addresses) are made in Core System Administration. For more information, see 8.10.

Each type of DCN is assigned to a specific type of network element, an important con-sideration during DCN planning (see below).

Figure 2 example of data connections via different DCNs



2.1.3 Examples of networks

2.1.3.1 WDM networksCore offers comprehensive support for new-generation WDM systems such as Wave-line/FSP for metropolitan networks, SURPASS hiT 7550 for long-haul applications and Infinity WL/WLS. These systems are used in ultra-high capacity (UHC) as well as in met-ropolitan networks. A simple example of a UHC network is shown below. The 10 Gbit/s connections represent interfaces to a lower transport layer (comprising SDH systems, for example).

Figure 3 a WDM network


17


2.1.3.2 Data networksThere are several types of data networks. One of these, the Storage Area Network (SAN), is shown in the figure below.

Storage Area Networks consist of storage devices (e.g. RAID arrays, storage applica-tions, and tape storage) connected on a separate network from the LAN. In other words, a dedicated storage network is inserted between the network servers and various storage subsystems. This network operates at gigabit speed via fiber optic cabling, enabling long-distance communication between nodes. Because SANs run on an entirely separate network from that of the corporate LAN, a lot of bandwidth is freed up on the LAN, thus minimizing the risk of bottlenecks.

Figure 4 a data network

All standard optical fiber connections such as ESCON, FICON and Fiber Channel are supported by Core.



2.1.3.3 SDH networksCore is capable to manage various SDH NEs offering services from 2 Mbit/s up to STM-64. Both line and ring structures including BSHR and MSP are supported, depending on the NE version. The combination of full element management functionality and exten-sive network layer capabilities provides comprehensive support for network operator tasks such as end-to-end service and path provisioning (see chapter 6). Additional oper-ations such as supervision, monitoring, maintenance and provisioning of the SDH network can be completed without the need for auxiliary TMN equipment.

Figure 5 an SDH network


19


2.1.3.4 PDH access networksCore supports n x 64-Kbit PDH access services using tributary cards of FMX/CMX NEs. End-to-end management for PDH equipment is implemented via Core at the network management layer (NML). Other tributary cards such as ISDN and 64-Kbit sub-bitrate cards are configured via the LCT application and implemented at the element manage-ment 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 Core.

Here is a typical application scenario with FMX/CMX in interaction with a SDH network:

Figure 6 a PDH access network



2.2 Network protectionProtection 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 net-works, 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 protectionPath protection is configured in 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 protectionTrail protection is performed on the network management layer. The possibilities include multiplex section protection (MSP), a bidirectional self-healing ring (BSHR) or optical protection.

Multiplex section protection (1+1) is used on lines to protect point-to-point connections between network elements with multiplex capability. The individual service is not pro-tected, rather the whole multiplex section between two adjacent nodes with multiplex functionality. MSP is provided on the network management layer (NML).

A two or four-fiber bidirectional self-healing ring (BSHR-2/4) is a special multiplex section protection mechanism used within rings. As is the case with MSP, it protects the whole multiplex section between two adjacent ring nodes, called a span. BSHR is also provided on the network layer.

1+1 optical protectionCore supports 1+1 optical protection against failures:

– on the optical channel layer independent of the optical channel client (with NEs SURPASS hiT 7540/7500 or Waveline/FSP)

– on the optical multiplex section layer (with NE Waveline/FSP).


21

Technical Description (TED) System overview

3 System overview

3.1 System architectureCore is a scalable multi-user system with a distributed, client/server architecture com-prising several industry-standard PCs running Microsoft Windows XP Professional or Windows 2003 Server as well as various software applications. External devices (print-ers, tape drive units, remote clients) may be connected but are not dealt with here.

Figure 7 system architecture

Core is comprised of the Client, System Administration, Server and NetServer applica-tions.

The Client and System Administration are installed on a client PC.

The Server software is installed on a server PC, which governs concurrent access to network resources to ensure that only one operator at a time is granted write access to an NE.

A second System Administration installation on the server PC (together with an addi-tional monitor) is recommended as this enables system administration to continue even if the data flow between the client and server PCs is interrupted. If the installation of TCOA is required, additional 3rd-party software must be installed on the server PC.


Technical Description (TED)System overview

The NetServer is installed on a NetServer PC. The number of NetServer PCs that can be managed simultaneously is scalable and depends on the number of NEs on the network.

3.2 Hardware componentsThe table below provides an overview of recommended hardware requirements for Core installations. However, other configurations are possible, depending on the network size. Planning for hardware, software and licenses should be undertaken on a project-specific basis.

g hyper-threading is not supported for NetServer and is recommended to be switched off for Client and Server.

Server NetServer Client

CPU: Xeon, 3.0 GHz.Multiprocessor operation supported

CPU: P4, 3.4 GHz. CPU: P4, 3.2 GHz.

RAM: 2 x 2GB * RAM: 1 GB RAM: 1 GB

Hard disk: 2 x 36 GB Hard disk: 80 GB Hard disk: 160 GB

Floppy disk: 1.44 MB Floppy disk: 1.44 MB Floppy disk: 1.44 MB

CD-ROM drive CD-ROM drive CD-ROM drive

Ethernet card Ethernet card, 2x Ethernet card

RAID controller - -

DAT streamer for backup - -

Color monitor 17” Color monitor 17” Color monitor 21”

Operating system:Windows 2003 Server (rec-ommended) orWindows XP Professional

Operating system:Windows XP Professional orWindows 2003 Server

Operating system:Windows XP Professional (recommended) or Windows 2003 Server

* Enhanced hardware

Table 4 HW recommendations for Core Server, NetServer, Client


23


3.3 Software componentsCore’s software architecture is depicted below:

Figure 8 overview of software components



3.3.1 Core ServerCore Server is the central component of Core and controls the following FCAPS 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 Core registry) stores general data, the Server database stores network management data and the log database stores log and list data. More informa-tion on Core databases is provided in Section 3.4.

As well as coordinating DCN management functions such as the administration of NE addresses, DCN channels and NetServers, the Core Server also support interfaces to higher-ranking network management systems (see 3.7), to Core NetServers and to Core Clients.

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

The main parts of the NetServer are the NetServer frame component, the EML packages and the Core EmlDB.

NetServer frame componentThe NetServer frame is essentially a proxy for the Server. It facilitates the management of EML packages as well as remote communication between Core Server components and Core NetServer components.

EML packagesA EML package is an installation package, which contain all relevant components (e.g. the NE controller) needed to run a family of NEs within Core.

The combination of EML packages required for a given Core system depends on the NE types that Core system configuration is required to support.

NE controllersThe main task of an NE controller is to convert NE-specific management interfaces to a simple internal Core element management interface. This way, the Server’s network layer management receives only the necessary information from the element manage-ment layer.

A corresponding NE controller must be registered in the system for every NE type to be managed by Core. Each NE controller class can support different NE types, but each NE can only be controlled by one type of NE controller.

Core NetServer databaseThe NetServer also includes a Core NetServer database (Core EmlDB) where relevant NE data is temporarily stored.


25


3.3.3 Core ClientThe Core Client is responsible for the following functional layers:

Network Management User InterfaceThe Core Client user interface provides the operator with several network views which contain graphical and textual information about current alarms, states and resources. Depending on the operator’s user class, the Client user interface also includes various wizards and dialogs which simplify system operation.

The main GUI contains the network map window, several list and log windows (alarm list, alarm log, network event log, system message log, etc.) and specific dialog windows associated to the functionality of the client.

Element Manager/Network Manager Application InterfacesA corresponding element manager can be started for each NE with a simple double-click (e.g. on the NE symbol within the network plan). The Core Client starts the correspond-ing process and provides the interface of the associated NE controller to the element manager.

Element manager applications provide full access to all NE data and also enable the configuration and control of NE behavior. This way, and depending on the actual NE type, performance values and alarms can be requested, and the backup and restore of configuration and other data initiated.

Network Management Data ExportData export is provided in the Core Client to export data for external evaluation. This enables the operator to export the content of each list and log to a file. This information is written to tab separated format (.tsf) files. Several tools and standard applications (e.g. MS Access or MS Excel) can read these files.

See chapter 6 for detailed functional information on Core Client.

g detailed Client operation information is provided in the Operator Guidelines (OGL) and in the online help.

3.3.4 Core System AdministrationCore System Administration provides administration functions for all Core components in the component tree, as well as various monitoring (e.g. client monitoring, DCN mon-itoring) and log (e.g. notification log, system message log) windows which can be opened in the main window.

Core Import/Export InterfaceCore System Administration supports an interface which allows the import (unsched-uled) and export (scheduled and unscheduled) of data using XML.

Detailed functional information on System Administration is provided in Chapter 8.

g detailed operating information on System Administration is provided in the Operator Guidelines (OGL) and in the online help.



3.4 DatabasesCore uses the following databases:– Core Registry (Core RegDB)– Core Network Management Layer (Core NmlDB)– Core Logs and Lists (Core LogDB)– Core Element Management Layer (Core EmlDB).

The Core RegDB stores general Core configuration data such as:– security policies– user group definitions– user account data– properties of Core components– properties of DCN objects– background bitmaps to be used for network maps.

The Core RegDB is managed by the Core Server and opens as soon as the Server loads. Core RegDB can be backed up, restored, replicated and migrated.

The Core NmlDB permanently stores the following objects:– subscribers– services– paths– port connections– NE links– NE containers– PM log definitions– NEs– ports– termination points– cross connections– protection groups– PMPs used in PM logs– alarms.

The Core NmlDB is managed by the Core Server and is opened when the Server is started. Core NmlDB can be backed up, restored, replicated and migrated.

The Core LogDB stores the following tables:– current alarm list– alarm log– network event log– security event log– system message log– PM logs– user-defined object types– user-defined probable causes.

The Core LogDB is managed by the Core Server and opened when the Server starts. Core LogDB can be backed up, restored, replicated and migrated. See 5.3. for more information on log management.


27


The Core EmlDB is used as a file cache by some NECs that cannot store the complete NE data. Core EmlDB cannot be backed up or migrated.

3.5 System scalabilityCore’s system architecture supports scalable configurations, which means that different groups of components can be installed on either one or several machines. Components of the same group must always run on the same machine.

Medium systemServer and NetServer components run on one PC; Client components run on separate PCs:

Figure 9 a Core medium system

Large systemThere is one Server associated to a number of NetServers running on separate PCs. Core Clients also run on separate PCs.

Figure 10 a Core large system



3.6 Operating systemWindows XP Professional (either 32- or 64-bit versions, depending on network size) is recommended for Core Client, System Administration and NetServer.

The Server should run Windows XP Professional (up to 10 clients) or Windows 2003 Server for larger systems.

3.7 External interfacesCore supports the following external interfaces:

Name Used by Attributes Description

Qx NE controller External Q interfaces.Proprietary NE interfaces such as QD2, QST, QST2, Q3, etc.

SNMP Umbrella systems

Open SNMP

TCOI EMS Systems (including other vendors’ applications)

TMF CORBA

TMF CORBA interface.This interface is compliant with the TMF CORBA specification. The interface provides access to the NEs, subnetworks and subnetwork connections managed by a Core Server

OLE-DB Tools for external data evaluation

Open OLE-DB DCOM

OLE-DB interface.This interface is a standard Microsoft database interface for accessing tabular data. Active read-only access is enabled for lists and logs

TSF Customers Open TSF TSF list export interface.Interface for exporting the contents of lists and logs a .tsf file

XML Customers Open XML XML list import/export interface.Interface for importing/exporting the contents of lists and logs an .xml file

Table 5 external Interfaces of Core


29


3.8 System availabilityCore’s advanced security concept provides the following options:– mirror disks– warm standby Core Server– standby Core NetServer– database backup and restore (see 8.4).

Mirror diskIf the Core Server PC is provided with a RAID system, all data is also stored on an addi-tional mirror disk monitored by a SCSI RAID controller. The controller ensures automatic data synchronization between the active hard disk and the mirror disk, so if the active hard disk develop a fault, a mirror disk takes over and the system is not affected. The faulty disk can be replaced by a new disk of the same type without shutting down the Server. The RAID controller then copies the data from the active hard disk to the newly installed hard disk.

Warm standby Core ServerThis option can be used if the Core Server is no longer available, e.g. due to a fire or complete hardware failure. The standby server is a second server machine with the same/similar hardware and software configuration as the active server. The operator registers the standby server at the active Core Server and activates database replication mechanisms. Should a failure occur, the operator simply switches manually to the standby server and starts the Core Server process as normal on the standby system.

The standby Core Server also supports the following features:

– configuration ID counters on the NML and NEC proxy layer.The configuration ID counters on the NEC proxy layer each record changes to a par-ticular object class, e.g. ports, cross connections, alarms, termination points, etc.. After switchover to the standby server, these changes are synchronized only with those NEs which have different counter values. This enables accelerated startup of the standby system.

– automatic synchronization of the NML with the NECs.If changes have been recorded to object classes, Core automatically initiates resyn-chronization of the NML with the NECs. The operator no longer needs to synchro-nize manually.

– access to additional standby server information.The operator can log onto the standby server via System Administration and obtain information about the status of the data replication process (see Data replication) as well as the name of the corresponding active server. This ensures greater transpar-ency during switchover to the standby server. The user can also manually validate or cancel database replication at any time.

In order to make the most of these features, a reliable link must be provided to the remote server. So that the database can be updated without interruption, this link should have a transfer rate of > 2 Mbps as well as low signal latency.

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


Technical Description (TED)Installation notes

4 Installation notesCore includes a number of applications and feature components. It also includes a master installation program for:

– installing Core components on the user’s hard disk– modifying an existing installation by adding or removing selected components or

subcomponents– completely removing Core from the hard disk.

g full commissioning/startup details are available in the Installation Manual (IMN).

4.1 Licensed softwareIn order to install Core, the corresponding licenses are required.

Depending on functionality, Core is divided into several software packages, which are provided on separate discs with individual licenses.

g various software products referred to in the manual have been licensed by Nokia Siemens Networks and are provided together with Core. Any questions concerning these products should therefore be directed to Nokia Siemens Networks rather than to the original manufacturer. Questions regarding software products such as virus scanners, which may run with Core, but which are not provided, sold or purchased by Nokia Siemens Networks, should be addressed directly to the manufacturer in question.

4.2 NE upgrade packagesCore supports subsequent integration of new NEs or new NE versions. The software components for managing a new NE or a new NE version are provided with a Core upgrade installation package. Using this package, a Core system can be upgraded with the EM components required for the new NE or NE version. It is not necessary, however, to install a new version of Core.

4.3 Older Core versionsCore supports the migration of databases when upgrading from versions 11.1, 11.3 or 11.4.


31

Technical Description (TED) Functional overview

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

5.1 Core featuresThe main features of Core are summarized below:

g to have full access to all the features you must belong to either the Windows “Power Users” or “Administrators” user groups, otherwise you will have trouble when per-forming certain actions.

– integrated management for NEs with WDM, OTH, SDH, PDH, Ethernet and data interfaces

– management of the network, NE and service layers– fault, configuration, performance and security management– E2E connection management for services with WDM, OTH, SDH, PDH, Ethernet

and data interfaces– support of SNCP and VC4, VC3 and VC12 concatenation– support of multi-layer switching, sub-equipped cards and auto-link detection (e.g. for

SURPASS hiT 70xx)– support of radio NEs (via NetViewer)– scheduled service activation and deactivation– logical domain and NE container concepts– TMF CORBA Interface to umbrella TMN– SNMP interface to umbrella TMN (alarm and status management)– import (unscheduled) and export (scheduled/unscheduled) for configuration data

and logs– external alarming (summary of network statistics) via e-mail/SMS– visual NW representation, intuitive operator guidance, detailed and context-sensi-

tive online help– scalable system architecture, high system availability– multi-user capability– remote control via public networks– dedicated configuration windows for automatic and manual routing– operating capacity overview for port connections– straightforward installation/upgrading of NEs– software updates without data loss/traffic interruption– subscriber management– enhanced security management– support of multiple management interfaces to the NEs– support of additional NE types or versions in upgrade packages– support of MPLS forwarding (only on hiT7080 4.15 with 1x10GE+10xGE/l2).

Core itself provides only, in an MPLS-specific path container, E2E visualization and supervision of P2P MPLS unidirectional trails.The provision of P2P MPLS, definition of forwarding rules, and fixed mapping of MPLS labels to card ports (including LAN ports and WAN-port VCGs) are set up at the EM


Technical Description (TED)Functional overview

– standby system– LCAS handling: the configuration is done directly in Core and reflected in the NE.

These functions are available via the Client and System Administration interfaces.

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

For more information, see chapters 6 and 8.

5.2 Basic operation

5.2.1 Core Server

Starting Core ServerCore Server can be either be started automatically or manually by the administrator. Once it has been started, Core Server is linked to all active Core NetServers.

Stopping Core ServerCore Server can be stopped by the administrator. When the Server is stopped, all con-nected client PCs are notified and any further login attempts rejected. Once all clients have been disconnected from the Core Server, the NetServers are also shut down and the Core databases closed. The Core Server can also be stopped independently of the NetServers, for example if maintenance work is required.

Concurrent accessConcurrent access to multiple Core Clients is managed by the Core Server as follows:– network configuration, creation of port connections and alterations to icons in the

network editor are only permitted for one 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, an NE is not available to

other operators.

Distribution of date/timeCore provides a manual date and time synchronization function for all managed Core components and for NEs which support this function. The Core Server distributes the current 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, except for NetServer or Client installations running on the Server.

For the NE types MTS, WLS, OCU, SURPASS hiT 75... and SURPASS hiT 70... the NE clock is set automatically in regular intervals to avoid that the NE time will get inaccurate.

5.2.2 Core NetServer

Activating/Deactivating Core NetServerA Core NetServer and each DCN object managed by the NetServer can have the acti-vation state “activated” or “deactivated”.


33


If a Core Server is started, connections will be established for all activated NetServers.

5.2.3 Core System Administration

Starting Core System AdministrationTo access the Core system, you must first log onto the System Administration software. Once you have logged on, you can start the Core Server using the icon provided in the toolbar. Once the Server is started, you can also access the Core Client software. More information on Core System Administration is provided in chapter 8.

5.2.4 Core Client

Starting a Core ClientOnce the 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 8.8.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 NEs, these are shown as unavailable on the user interface by a box contain-ing two 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 Core Server is not available, an error message is displayed.

Starting Element Manager applicationsThe element manager applications are started via 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 accessCore only administers write access to managed NEs which support this feature. Write access to a given NE or set of NEs can be requested, enforced or released. In this way the Core operator also has control over external LCT write access.

Terminating a Core Client sessionA 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 managementIn Core, specific operator activities as well as random actions and events are stored in log files on the Core Server.

The log contents can be printed out, saved to a file or evaluated via a standard OLEDB/ADO interface.

The Performance Log Export Tool (PLET) exports performance logs, alarm logs, network event logs and system message logs to different applications and systems (for details see Section 6.2.1).


Technical Description (TED)Functional overview

5.3.1 Log classesIn Core, each log is assigned one of the following classes:

– permanent– custom– non-persistent.

Permanent logs are fixed, global logs administered by the 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 Core Client and Core System Administration and exist only for the duration of a client session. The log content is deleted when the client session is terminated.

5.3.2 Log typesThe following log types are possible in 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 if the toggling filter with a proper time setting is switched on.

The system message log contains a chronological list of relevant administrative events. Critical events are indicated at the user interface.

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 Core. It provides infor-mation 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 NEs each with a number of measure-ment points, special algorithms regulate data collection and ensure that each value is

Log type Core Client Core System Administration

Log Class

Alarm log X Permanent

System message log X X Permanent

Network event log X Permanent

Security event log X Permanent

Performance log X Custom

Notifications log X X Non-persistent

Operator input log X Non-persistent

Table 6 log types


35


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 pre-sented in a report window. The operator input log is a snapshot, and is therefore not updated automatically.

5.4 Scheduled service activation/deactivationCore features scheduled service activation and deactivation. It can be used to activate and deactivate paths in a scheduled way. It allows to specify a (periodical) activa-tion/deactivation schedule for activated/not activated paths. Services can also be acti-vated/deactivated by activating/deactivating all belonging path of the service.


Technical Description (TED)Client functions

6 Client functions

6.1 Configuration managementConfiguration 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 topology managementNetwork topology management is concerned with the process of preparing and enabling Core for network management operation. This includes in particular the following:

– providing information necessary for communication between network components, e.g. NE addresses

– configuring the NE container topology structure– providing information about the physical network topology, i.e. the NEs and the port

connections between these NEs.

The following objects are managed by Core and represented on the network map by various graphical symbols such as icons, lines, etc.

Network elementThis object represents a physical NE. Core provides two types of NE object.

A “real” NE object represents those NEs that can be managed directly via an NE con-troller in the NetServer and that are therefore also managed entirely by Core. A UNO NE object is used to represent those NEs that are not managed entirely by Core because:

– alarms for the NE in question are not forwarded to Core directly but via another NE– alarms for the NE in question are not forwarded to Core directly but via an EMOS

management system using a serial interface– the NE is not managed at all. In this case the UNO only provides a symbolic repre-

sentation of the unmanaged NE.

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.

Invoking the LCT of an individual NE, the operator can execute functions on element management layer. In case of configuration management for example it is possible to use the “Script Configuration Function” of the LCT to configure several NEs in a com-fortable way (only for NEs which support this function, e.g. for hiT 7070).

Protection group and MS protectionA protection group is an object that represents MSP or BSHR functionality in the NEs. The MS protection object represents an interworking relation between dedicated protec-tion groups in different NEs (e.g. between two MSP protection groups that belong together).


37

Technical Description (TED) Client functions

NE containerThis object represents a container where NEs and UNOs are grouped together and illus-trated by icons. In addition to these NEs, every NE container can also contain one or more other NE subcontainers.

Port connectionThis object represents physical connections (e.g. fibers) that are possible between NEs/UNOs/multi-NE devices and also inside the multi-NE devices.

A prerequisite for port connections is that the ports at both ends either support the same transmission layer, or have a dedicated transmission layer at one end (e.g. STM-16) and a generic port belonging to the generic trail layer at the other:

– port connections can be configured between real NE ports, UNO ports or between a combination of both

– port connections can connect NEs and UNOs in different NE containers. In the case of NEs, connections are also possible between different NE types

– port connections can be created for a wide range of technologies such as pure optical networks, SDH, PDH, Ethernet, ESCON, FICON, Fiber Channel, etc.

– unidirectional and bidirectional port connections are possible– port connections can be configured between ports with MSP or BSHR functionality– it is also possible to connect two ports within the same NE, e.g. for test purposes.

Unlike internal port connections within Core and port connections within an Multi-NE devices, external port connections are always created explicitly by the Core operator.

Server pathThis object represents an explicitly/implicitly created server path that provides infrastruc-ture for lower order paths.

Remote inventoryIn order to determine the requirements when updating or upgrading network compo-nents, or extending the network, the operator must have sufficient information about the installed base. For this purpose, Core provides a remote inventory (RI) which stores inventory files. These files contain information about the hardware and software installed on each individual NE.

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

Core provides the following options for network augmentation:– re-routing paths, which can be done either directly, where traffic interruption is per-

mitted, or using SNCP mechanisms– inserting and removing NEs by modifying port connections when such connections

are not supporting services.



Auto-link detectionWith Auto-link Detection it is possible to detect physical connected ports (i.e. port con-nections) not yet known by Core. To enable this, each NE sends automatically a unique trace to other NEs. Core may request traces received and traces sent from/to the NEs and evaluate them by comparison to suggest automatically port connections on the operators decision. As a result Core knows all about existing port connections of all managed NEs that support auto link detection (e.g. hiT 7070/7050/7540).

Typically auto-link detection will occur in augmentation scenarios where a telecommu-nication provider extends or reorganizes its network and adds such NEs.

6.1.2 Path managementPath management includes the creation, maintenance and supervision of paths. Once the relevant NEs have been selected, paths (also known as end-to-end connections) can be established quickly and conveniently in Core Client using dedicated configura-tion windows. These guide the user step-by-step through connection setup. Once they have been configured, paths are then assigned to a subscriber.

As a large number of ports and termination points (TPs) are administered as part of path management, it can be quite difficult to maintain an adequate overview of all configured paths. For this reason, a special hierarchy tree which only displays the TPs of the current level is implemented. Ports which are shared by two different modules are also only dis-played once in the tree. In addition, special icons are implemented to enable clearer dis-tinction between the various operational states and port connection types. Core also enables either a complete list of TPs to be displayed, or just those TPs of a particular layer.

Paths can be created either automatically or manually. A combination of the automatic and manual routing mechanisms is also possible. This feature is known as hybrid routing.

With automatic routing, only the endpoints must be selected. The least expensive avail-able connections are then searched for across all NEs between these endpoints.

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

Hybrid routing combines the automation and easy handling of the automatic router with the flexibility of the manual router. With hybrid routing, you can simply switch as required between automatic and manual routing during the path creation process.

Paths can be configured with additional SNC protection during or after the routing process.

Core supports multiple cable conduits. This function enables maximum network traffic availability because the cables for the working path and the standby (protection) path are not located in the same cable conduits. This is particularly important in the case of automatic routing.


39


Supported path typesUnidirectional, bidirectional and broadcast path (consisting of several unidirectional paths) can be created. The paths which 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, OTH, SDH, PDH, Ethernet or data).

Optical server paths are also supported thus enabling enhanced handling for optical NEs and concatenated SDH path. This feature facilitates the creation of optical lines (e.g. hiT 7550) and the routing of paths (e.g. SDH) over optical NEs.

For Ethernet services scalability is supported by the use of the Generic Framing Proce-dure (GFP) functionality in the NEs. The bandwidth can be defined during path creation and is scalable in fix steps of 1Mbit/s.

Paths are also classified according to whether both endpoints are located within the administered network (closed path), or whether one endpoint or both endpoints is/are located outside the network (half-open path or open path).

Path bundle routingA path bundle is a collection of paths used to concentrate identical operations on multiple paths into one bulk operation. For fast creation of identical paths, the provision-ing of NEs often requires the configuration of path bundles, e.g. for several VC 12 paths or other using the same NEs (though bundles on layers with variable bandwidths (GFP) are not supported). Via path bundles the routing of multiple paths can be done more effectively and thus saves operation efforts.

The function allows the creation and modification of path bundles, thus allows the handling of one or more path(s) belonging to a path bundle. Paths bundles need not to be created in one step and no new connection type or object type is required. Thus it can save a lot of operation efforts. On the other hand, it is the operator’s responsibility to select all paths belonging to a bundle for an effort-saving bulk operation.

Trail-oriented server modelIn Core, a trail-oriented server model has been implemented to enable the exact defini-tion of paths and server paths for individual network layers. This model also incorporates ports and TPs which are located on more than one transport layer. Multiple networks, and networks which are partitioned into different subnetworks or include a variety of transport technologies can now be managed via a single user interface. Enhanced service creation, manual and automatic routing are also supported.

Loopback functionsThe loopback functions are used for physical verification of the routed paths, usually for test purposes as they are service-affecting.

Two types of loop backs are supported in Core:

– port loopbackThe port loopback can be done in the interface cards of the NEs (for Ethernet and PDH) by setting a special switch. Internal (inwards) and external (outwards) loop backs with different modes are possible. Port loopback is supported by hiT 70.., SMA4 4.x and SMA16 4.x.

– matrix loopbackThe matrix loopback can be done in the switching matrix of the NEs: In this case a unidirectional cross-connection is created from the source to the sink sides of the



same TP to loop back the traffic (for all supported path transmission levels - as far as unidirectional CCs are supported by the NE type).

Status management for pathsPaths are assigned to three different state types:

– operational stateIt indicates whether sufficient resources are currently available to enable access to the service or path

– administrative stateIt indicates whether this service or path has been locked or unlocked by the admin-istrator. Locked means that the resource is not used by the autorouter mechanism

– Required Creation State (RCS)It expresses the desired state of the path, which is set by the user. Possible values are active, not active, not routed, unmanaged, under test or in deletion

– Actual Creation State (ACS)It represents the actual creation state according to the corresponding infrastructure in the network. Possible values active, not active, not routed, unmanaged, under test or in deletion.

The operational, administrative and creation states are shown in the ’Path Properties’ window and are also indicated by icons in the service tree.

Showing services and pathsThe user interface offers various service (container for paths) and path views.

The ‘Subscribers and Services’ tree view in the client 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. Core also provides a list of all 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 path can be displayed or modified both in the ’Path Properties’ window.

Paths not assigned to a subscriber or service are shown in the default path container, which is layer structured.

Path analyzerThe result of the path analyses is shown in the “Unmanaged Path” tree window. This window shows - similar to the default path container in the “Subscriber and Services” window - an overview of all paths existing in the network, but not yet being managed.

RCS is accordingly set to unmanaged. Highlighting is possible in the network plan and details of a path can be displayed in the “Path Properties” window

6.1.3 Subscriber managementEach new service must be assigned to a subscriber. The subscriber name can be added to a subscriber list in Core Client, together with other relevant contact data. This list can then be printed out or saved to a file for further processing.

Core provides a built-in subscriber account with the name "Default subscriber". If a service is not assigned to a specific subscriber during subscriber creation, it is automat-ically assigned to the default subscriber.


41


6.2 Performance managementTransmission quality can be monitored by PMP (performance measurement point) for any path. Furthermore any PMP of any NE may be monitored.

The performance data collected is stored on the Core Server machine in user-defined performance logs (see 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.

As the number of supported NEs increases, so does the number of performance counters which are supported by Core. The performance parameters to be collected at the PMP can be selected individually. This minimizes the amount of data requested from a PMP when a performance log is created. Examples for performance parameters are Background Block Error and Errored Seconds (SDH), Minimum Power Level and Maximum Signal to Noise Ratio (Optical) or MultiBroadcastFrames Rx and Unicast-Througput Rx (Ethernet).

A measurement and an update interval is configured for each performance measure-ment 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 deter-mines when data is actually written to the performance data log is freely configurable. However, in order to minimize the DCN load, the update interval is always determined by the PMPs attributes. The data is evaluated in accordance with ITU-T recommenda-tions concerning error performance (G.821 and G.826).

Transmission quality can also be monitored using element managers. Via the element managers further settings can be done concerning performance management (e.g. adjusting the threshold values).

For NEs managed by EM-OS, performance management is possible via the EM-OS element manager. For NEs managed by TNMS-SX, performance management is possible both via Core or directly via the SX element manager.

Core also supports Tandem Connection Monitoring (TCM). TCM is an attribute that can be set for a regular performance log. A tandem connection consists of a start PMP and an end PMP. During TCM, data for both PMPs is compared and any differences are written in the log.

6.2.1 Performance Log Export Tool (PLET)The Performance Log Export Tool (PLET) can run on a Windows XP Professional platform either together with Core or separately. PLET is not an integral part of Core and has therefore to be installed separately. Using PLET, logs can be exported automatically so that the data they contain can be imported and used in different applications and systems.

PLET is installed on the Client machine. It is possible to install PLET on more than one Client machine (i.e. it is possible to use PLET in parallel).



6.2.2 TNMS OTS-4000 Performance Add On Tool (TOPAT)The TNMS OTS-4000 Performance Add On Tool (TOPAT) is an external application that enables the management of specific performance log information. The log informa-tion is collected from the NEs by the StrataLight OTS-4000 equipment.

TOPAT runs separately from Core and is installed on both Server and Clients.

TOPAT enables:

– creation of new performance logs– configuration of performance logs and PMP parameters– showing performance logs– saving performance logs– deleting performance logs

6.3 Fault managementFault management in Core comprises the following alarm handling functions:– alarm list– alarm log– display of alarm summary– display of alarm state– display of alarm severity– audible alarm– external alarm output– alarm messenger for alarm summary forwarding via email/SMS

All alarms are administered in the Core Server and recorded in an alarm list and an alarm log. The alarm list is accessed via the 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 NE-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.

If alarm notifications are received by the Core Server or Core Client, the following actions are performed.

For each alarm notification received by the Core Server: – the notification is forwarded to all connected Core Clients– the list of current alarms is updated– automatic correlation to services is performed– the notification is stored in the alarm log.

For each alarm notification received by the Core Client:– the alarm is updated– the alarm log is updated– the alarm supervision of NE icons and NE container icons is updated– the current alarm statistics for NEs and NE containers are updated– the operational state for services/paths is updated.


43


Core supports alarm suppression and modification of alarm suppression for certain objects. This can be implemented:– for all alarms relating to unused TPs for a selected NE– for secondary alarms of service endpoints– for secondary alarms of a service– for all alarms of a service– when creating/deleting cross-connections.

Transient alarms where the operator is not required to take any action are suppressed in Core. These alarms may occur as a result of structuring/unstructuring of ports, for example, or due to differing CC creation/deletion times for the NEs used by the path. As far as possible such alarms will already be suppressed in the NEs in order to decrease DCN load.The main benefits of improved alarm suppression are:

– transient alarms where operator action is not required are not stored in the alarm logs or displayed in the alarm list

– delays in the clearance of events for transient alarms are restricted due to the alarm toggle filter

– the DCN load is decreased.

The operator can find the NE where the alarm was raised by referring to the alarm list. The NE is then highlighted in the network plan and the DCN tree. 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 NEs. 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 NE, 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 dis-played by Core. Additional functions must be performed via the element manager itself. This is simplified by screen-level integration of the EM-OS GUI.

The alarm statistics window enables the operator to handle alarms conveniently. The alarm summary windows shows:– the number of current alarm per severity– alarms separated for unacknowledged and acknowledged state– summary counters per severity– summary counters per management state– summary counter of total alarms.

The window presents the alarm statistics in a matrix view and is updated automatically.

Raised alarms can also be correlated to the corresponding paths. The operator can choose the settings “Off”, “Normal” or Extended”. With normal correlation (default set-ting), alarms are only correlated to the endpoints of the affected path so that the opera-tional state of the path can be determined quickly. With extended correlation, alarms are correlated to all TPs/ports of the affected path. 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.

Core provides a summary of network statistics for selected NEs. These can be for-warded via email/SMS in order to provide the operator with an overview of the current



network state. The information provided by these statistics can include, for example, the number of enabled/disabled paths, PCs and faulty DCN objects. The operator can con-figure various settings for this function, including a notification interval and a severity threshold for the notified alarms. Alarms are forwarded using the standard SMTP protocol and implement a fixed message format which also meets the requirements for SMS (142 characters maximum, no attachments).

Alarm integration for the NE Juniper 10G PICThe Juniper 10G is integrated into Core as a Generic SNMP NE and therefore appears on the network map as a generic icon.

Alarms from the PIC are reported by the NE and logged to the alarm list, which Core configures and manages via a Telnet or terminal application. Such application thus acts as the NE’s EM.

For the NE, Fault Management consists only of alarm supervision at EM level.

6.4 Security managementSecurity management functions can be used to restrict access either to the Core user interface or to individual NEs.

Access to the Core user interface is controlled by a user ID and a password which are initially configured in the security settings provided by System Administration (see Chapter 8). If required, the password can subsequently be changed directly in the Client application.

For NEs that do not have security mechanisms, access can be restricted via the NE write access options (see 5.2.4).

The access rights defined for users based on their class can be further restricted to par-ticular NE containers (domains) for which the user is responsible. This way, useless vis-ibility of objects is also avoided, i.e. only those objects belonging to those NE or sub-NE containers for which the user has access permissions are displayed.

Find more information on container permissions and object visibility in section 8.8.3.

Antivirus and firewall softwareTo prevent computer viruses from damaging the Core system, and to prevent infiltration and sabotage of the system, professional antivirus may be installed on all Core machines.

Windows XP professional firewall must be disabled for this Core version. Third party fire-walls or separated firewall servers are recommended instead (refer to the IMN docu-mentation for further details on the procedure). Firewalls servers control and monitor access to the Core Server and NetServer. This solution is more expensive but is worth-while as it offers greatly improved security.


45

Technical Description (TED) Optional software components

7 Optional software components

7.1 ASON/Ethernet ManagerASON/EM is add-on to Core. Management functions for two different technologies are provided: ASON and VLAN configurations with multipoint-to-multipoint connections on network layer 2. While Core manages the physical structure of the transport network and its conventional network elements, it gets enhanced by ASON/EM, which is responsible for the logical end-to-end connections and services running atop them.

7.2 Northbound interfaces

7.2.1 TMF CORBA AgentTCOA (TMF CORBA Agent) is a module which implements the TMF CORBA Interface (TCOI), a standardized, multi-technology interface for the management of multi-vendor transport networks. TCOA enables the Core Server to connect to third-party TMF CORBA Managers (TCOM) and should be installed if Core is to be connected to an umbrella network management system. WDM and SDH network elements are sup-ported, however support is not available for PDH NEs or SISA-V DCN components.

7.2.2 SNMPThe SNMP proxy component provides an SNMP-based interface to the network layer of the Core system and enables access to the Core management information base (MIB). It facilitates the integration of Core with umbrella fault management systems which support the SNMP protocol and which recognizes the Core MIB can read object proper-ties and receive traps from the Core element management layer and network manage-ment layer.

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

7.3 Southbound interfaces

7.3.1 TMF CORBA ManagerTCOM is a southbound interface connecting network elements or other vendors’ EMSs (e.g. NetViewer) and NEs managed by them. The TMF814 is a TMF CORBA interface (TCOI) realized by TCOM.


Technical Description (TED)System Administration functions

8 System Administration functionsThe Core System Administration application is used to configure and administer the Server and NetServer components, since they have no user interface. An overview of Core Server data is available from the System Administration menu tree (Properties > Component Info > Core Server).For security reasons, System Administration is accessible only to users with administra-tion rights, and the system administration features are not available in Core Client. It is nevertheless possible to run System Administration and Client on the same PC.

8.1 ConceptsData security: the Server and System Administration software ensures that all user management data (accounts, passwords, groups etc.) are transferred and stored encrypted between both recipients and secure data will only be stored on the Core Server side.

Notifications: all running Clients including System Administration will be notified if errors, relevant to the Core, occur. It will be evaluated by the Core Server which infor-mation has to be sent to a Client.

Remote access: in order to enable remote control of Core via public telecom network it is necessary to configure the Windows XP Professional or 2003 Server Remote Access Services on Server and Client and to add appropriate entries in the Dial-Up Networking Service on the Client workstation.

DCN Management: a central address administration called "DCN Management" combines the administration of subnetwork addresses as well as the administration of DCN channels and NetServers in a similar manner.

Concurrent user access: concurrent access from different System Administration application instances to properties of a component of the System Administration's com-ponent tree is handled by a corresponding locking mechanism.

Domain: a domain is represented in Core as an NE container that comprises one or more NEs and/or (sub) NE containers. One domain represents a subnetwork.

User class: controls a basic set of access rights to network resources. Each user in the same class does not have extra individual access rights. See 8.8.2.

User groups: contains a number of users and keeps the limitation of access rights for operators to logical subnetworks, more clearly.

The System Administration functions are available via the main menu, the toolbar and the System Administration component tree window. For details refer to the OGL or Core’s Online Help.

8.2 Alarm settingsSystem Administration supports the following alarm handling features:– alarm messenger for alarm summary (network statistic) forwarding via email/SMS– color settings for alarm severity colors– general settings for alarm objects (Toggle Filter, Default Severity, Alarm Overview)– probable causes (user-defined settings)– user-defined object types (user-defined settings).


47

Technical Description (TED) System Administration functions

The alarm severity can be both displayed and configured for user-defined probable causes. In order to configure the alarm severity, the operator must define a severity profile. This is stored in the Core database.

8.3 Cost factorsThree cost factor levels can be configured in System Administration. If these are assigned to the port connections, the automatic router can select the least expensive route first.

8.4 DatabaseSystem Administration provides a comprehensive range of database functions. These functions are only available to system administrators, 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.

Core system data is distributed across a number of databases. See chapter 3 for details.

BackupCore provides a backup facility which enables the administrator to maintain several backup sets for the Core Server database, Core Config database and Core Log database for later restoration. Utilization of an own backup server is supported. 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 pro-cedure, an analysis function checks the referential integrity and data consistency of each backup set. 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 backup operation, you may copy backup sets in the dedicated directory to a safe locale using the Windows XP Professional backup utility. This can be completed once a day, preferably at a time of low system and user activity.

Creating backup sets, configuring scheduling of backup sets and analyzing a database is possible regardless of whether the server is started or stopped.

RestoreStopping the Core Server activates a restore option which the operator can use to restore a previously-created backup set from the dedicated backup directory. This oper-ation can only be completed offline and is used to support system migration, for example. To prevent inconsistent configuration data, the option for NetServer deactiva-tion should also be selected. Once the restore operation has been completed, the Core Server and Core NetServer have to be restarted. Restarting the Core Server opens the restored databases and restores the backed-up configuration.

Data replicationTo minimize the loss of data after a system component has broken down, the Core system provides an internal database recovery mechanism for all 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.

Core also provides an incremental data replication function which continuously repli-cates 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.

Data import/exportCore supports, through XML, an array of import/export options: service layer informa-tion, configuration data, alarm logs, network event logs, system message logs and per-formance logs can be exported. Scheduled and unscheduled export is possible, as is the very definition of the objects to be exported. Time, cycles and destination can be defined when using scheduled export. XML files can be viewed with Internet Explorer.

Automatic access to log file 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 data for processing by external tools (e.g. with the Performance Log Export Tool, a scheduled export of log data is possible).

Log configurationSeveral different log types are maintained by the system. The space available on the hard disk for Core log data can be set using this option. The system message log can then 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 facilities are also provided for the security event log and operator input log (here, configuration is also possible) in the main System Administration menu. For more information on log man-agement and log types see chapter 5.

8.5 Date/timeThe system date and time configured for the Core Server can be viewed and adjusted as required. The Server date and time can also be set to the date and time of the PC where System Administration is installed.


49


8.6 License managerLicenses are mandatory if you wish to install and operate Core. The following types of licenses exist:– basic license– upgrade license– NE license– feature license.

A list of the available licenses can be viewed and imported/exported as .xml file.

The number and type of licenses must be planned on a customer-specific basis. The license keys are delivered as XML files and can be imported conveniently in Core.

Core supports download of license key files to an NE via EM (e.g. for hiT 70xx).

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

8.8 SecuritySystem Administration provides special security features to regulate access to the Core interface. An authorized user must have an account with a valid user ID and password.

8.8.1 Account policyGlobal 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.

8.8.2 User managementUser Management allows an administrator to change existing users’ configurations and setting up new users. A user’s access level is determined by the user class, user prop-erties, 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 able to perform:

– supervision: the user can execute supervision functions and start EM applications with read-only access

– maintenance: the user can execute supervision functions and start EM element manager applications with read-only access. 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 manage-ment functions

– administration: the user can perform configuration functions and all administration management functions. In other words, the user has unrestricted access.



The user’s access rights are limited to specific domains. Each NE container comprises a number of NEs and represents a domain of a network. To every domain available, one user or one user-group can be assigned. User groups are logical combinations of single users without influence on the access rights defined by the user classes.

A user or 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. If required, the administrator can also assign a user to one or more user groups.

It is part of the administrator user privileges to manage new users creation by assigning proper access rights through a user class, and assigning the proper network domain to this user or to the group where the user belongs to.

A special default group superuser is also available. This group allows users to access the whole network.

8.8.3 Container access

User responsibility for an NE containerAccess rights to containers are configured in System Administration and assigned on a per-user basis. Users cannot access objects in NE containers to which they do not have access permissions.

Specific NE container access levels are defined as follows:– responsible:

the user is responsible for this NE container. An NE container of this type is visible to the user concerned

– child responsible:the user is responsible not for this NE container as a whole but only for a child NE container within. An NE container of this type is visible to the user concerned

– not responsible:the user is responsible neither for this NE container, nor for child NE containers within, nor for the parent container.An NE container of this type is not visible for the user concerned.

Container visibility can also be set to non-restricted, in which case all objects are visible regardless of their NE container visibility.

Object visibility related to an NE containerRestricted access rights to NE containers may result in restricted visibility of the follow-ing objects:– network objects, e.g. a path or a port connection– object lists, e.g. port connections, TP, service, or protection group lists– logs, e.g. network event, system message, performance or alarm log– alarms, i.e. the alarm log, current alarm list and service/port connection-related

alarm list

The security event log, operator input log and list of DCN objects are, however, visible at all times. An object is also generally visible if at least one part of the object lies in an NE container for which the user is responsible.


51


8.9 Northbound interfacesOptional northbound interfaces can be used to connect the Core system with an umbrella network management system. Core supports two types of northbound inter-faces: TCOA and SNMP. See 7.2. for details.

8.10 DCN managementDCN management comprises the definition and administration of NetServers, DCN channels and NEs. These DCN objects are displayed in a hierarchical tree and can be added, deleted and modified as required. They can also be moved to another parent element, e.g. NEs can be moved from one NetServer to another NetServer. The current connection state is also displayed for each DCN object.

Some NE types may group or address further NEs. Such types are known as node NEs. The following node NE types can perform this function:

– SISA network node (for PDH NEs)– multi-NE devices.

8.10.1 NetServerThis object

– handles the connection to one or more different NEs– is the direct source for all NE data to be uploaded by the Core Server– loads the NE data required by the Core Server to the NetServer memory and main-

tains data consistency while NetServer is connected to the NE– acts as an mediation device by standardizing the data transferred from the different

NE interfaces to the Core Server and vice versa.



8.10.2 DCN channelsDCN channels connect the NEs directly or via an external EM to their Core NetServer. The operator uses DCN channels to group NEs of the same DCN channel type. Core supports the following DCN channels and interfaces:

DCNchannel

Physicalinterface

Protocol NE/EMs

ELI Ethernet (TCP/IP)

ELI SXA, SXD

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

QB3M Ethernet (OSI)

QD2 SDH, e.g. SMA1/4, SMA4/1

QST, QST2

SDH, e.g. SL16

Q3 WDM, e.g. SURPASS hiT 7500, 7540, 7550

QD2-SISA Ethernet (TCP/IP)

SISA PDH (e.g. FMX, CMX) with connection node type SISA-GKE only

SNMP Ethernet (TCP/IP)

SNMP Generic SNMP (e.g. Juniper 10G PIC, ULAF+, FSP2000/3000/3000R7)

SNMPv2 SURPASS hiT7020/25/30/35/60/60HC

SNMPv3 SURPASS hiT7300 4.1.1, 4.2; 7080 4.0, 4.1, 4.15

UNO+ None None Universal objects

TCOM Ethernet (TCP/IP)

TCOI SXC

TCOM(TMF 814)

Ethernet (TCP/IP)

TCOI SN16000, NetViewer NME/Radio NEs

Table 7 DCN channels and interfaces supported by Core


53

Technical Description (TED) Abbreviations

9 AbbreviationsASON Automatically-Switched Optical Network

BCM Border-Crossing Mode

BSHR Bidirectional Self-Healing Ring

CC Cross Connection

CE Communauté Européenne

CDM Cross-domain Manager

CORBA Common Object Request Broker Architecture

DAT Digital Audio Tape

DB Database

DCN Data Communications Network

EM Element Manager

EML Element Management Layer

EM-OS Element Manager Operations System

EMS Element Management System

ESCON Enterprise System Connection

FCAPS ISO's TMN Fault, Configuration, Accounting (or Administration, in non-billing organiza-tions), Performance and Security

FICON Fiber Connection

GBE Gigabit Ethernet

GMT Greenwich Mean Time

GUI Graphical User Interface

IMN Installation Manual

ITU-T International Telecommunications Union - Telecommunications Standard Sector

LAN Local Area Network

LCAS Link Capacity Adjustment Scheme

LCT Local Craft Terminal

MDAC Microsoft Data Access Components

MIB Management Information Base

MS Microsoft

MSDE Microsoft SQL Server Desktop Engine

MSP Multiplex Section Protection


Technical Description (TED)Abbreviations

NE Network Element

NML Network Management Layer

NEC NE Controller

OGL Operator Guidelines

OLEDB/ADO Object Linking and Embedding Database/ActiveX Data Objects

OSI Open System Interconnection

OSL Operator Source Licenses

OTH Optical Transport Hierarchy

PC Personal Computer

PDH Plesiochronous Digital Hierarchy

PDF Portable Document Format

PLET Performance Log Export Tool

PM Performance Measurement

PMP Performance Measurement Point

RAID Redundant Array of Independent Disks

SAN Storage Area Network

SDF Semicolon-Delimited Format

SDH Synchronous Digital Hierarchy

SMS Short Message System

SNCP SubNetwork Connection Protection

SNMP Simple Network Management Protocol

TCM Tandem Connection Monitoring

TCOA TMF CORBA Agent

TCOI TMF CORBA Interface

TCOM TMF CORBA Manager

TED Technical Description

TIF Telemetry Interface

TMF Telecommunications Management Forum

TMN Telecommunications Management Network

TNMS Telecommunications Network Management System

TP Termination Point

TSF Tab-Separated Format


55

Technical Description (TED) Abbreviations

UHC Ultra-High Capacity

UNO Universal Network Object

VLAN Virtual LAN

WAN Wide Area Network

WDM Wavelength Division Multiplexing

XML eXtended Markup Language

TNMS_TED

Documents

Transcript of TNMS_TED