• No results found

Service Management

4.3 Additional Backup Hardware

6.1.3 Service Management

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

Services can be created either automatically or manually.

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

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

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

Supported Services

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

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

Status Management of Services and Paths

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

– Administrative – Provisioning.

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

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

Showing Services and Paths

The user interface offers various service and path views.

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

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

6.1.4

Subscriber Management

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

6.2

Performance Management

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

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

A measurement and an update interval is configured for each performance measure- ment log. The 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, it should always be set in accordance with the measurement interval. The data is evaluated in accordance with ITU-T recommen- dations concerning error performance (G.821 and G.826).

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

6.3

Fault Management

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

– Alarm log

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

– External alarm output

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

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

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

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

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

6.4

Security Management

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

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

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

7

SysAdmin Functions

7.1

TNMS Server

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

7.2

Alarm Settings

SysAdmin supports the following alarm handling features:

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

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

– Configurable probable causes for alarms

7.3

Cost Factors

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

7.4

Database

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

Backup

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

Restore

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

Data Replication

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

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

DB Import/Export

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

Log Configuration

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

7.5

Date / Time

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

7.6

External Interfaces

7.6.1

SNMP Proxy

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

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

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

7.6.2

OCA Proxy

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

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

7.6.3

SNIF Proxy

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

7.7

Licensing

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

7.8

NE Inscription Settings

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

7.9

Security

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

7.9.1

Account Policy

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

7.9.2

User Management

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

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

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

modify element manager applications.

Maintenance: the user can execute supervision functions and start element

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

delete services.

Configuration: the user can perform operation functions and configuration

management functions.

Administration: the user can perform configuration functions and all administration

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

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

7.10

DCN Management

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

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

– Incorporation/deletion of network elements

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

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

8

Abbreviations

BSHR Bidirectional Self Healing Ring DCC Data Communication Channel

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

EM Element Manager

EML Element Management Layer GMT Greenwich Mean Time

ID Indentification (Service Status) IMN Installation Manual

ISDN Integrated Services Digital Network ITU-T Telecommunication Standardization Sector

of International Telecommunications Union LAN Local Area Network

LCT Local Craft Terminal

MSLTP Multiplex Section Linear Trail Protection NCT Network Craft Terminal

OCA Open Corba Agent OGL Operator Guidelines

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

PDH Plesiochronous Digital Hierarchy

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

STM Synchronous Transport Module TED Technical Description

TMN Telecommunication Management Network TP Termination Point

UHC Ultra-High Capacity UNO Universal Objects VC Virtual Container

Related documents