Network Management System (NMS) Intelligent ITMN Project Tender... · Network Management System (NMS) Intelligent ITMN September 2007 ... TCP/IP and SNMP protocol is the preferred

Esfahan Regional Electric Company

(EREC)

Ghods Niroo Consulting Engineers

TELECOMMUNICATION

TENDER DOCUMENT

Network Management System (NMS)

Intelligent ITMN

September 2007

GHODSNIROOCONSULTINGENGINEERS

Esfahan Regional Electric Company (EREC)


Telecommunication Tender Document – Network Management System (NMS)

Page 2 of 30 GN-1386-EREC-004

Table of content

1. Introduction

2. Transport Protocols

3. Connection To The Network

4. Standards And Protocols

5. General Network Management Requirements

6. Factory Tests

7. Factory System And Individual Card Software Tests

8. Management Software Tests

9. Other Requirements

10. System Administration

11. System Security

12. Operational Support System (OSS) Solution

13. Element Manager OS Service Management

14. Other Required Features For NMS

15. Summary Of The Network Management Requirements

16. NMS Requirements Under This RFQ





1. INTRODUCTION This specification is intended to describe the requirements for Telecommunication Network Management System (NMS) based on the ITU-T recommendations and standard specifications. The proposed NMS shall be used to manage Esfehan Regional Electric Company (EREC) Telecommunication Transport Network (TN) which is part of the power utility national interconnected telecommunication network for power management and new advanced applications.

2. TRANSPORT PROTOCOLS

2.1. Protocol/Interface to ITU TMN

2.2. TCP/IP and SNMP protocol is the preferred transport service in the ITMS.

3. CONNECTION TO THE NETWORK

3.1. Connection from network element to the SDH equipment multiplexer systems shall be via Ethernet port or ITU-T standard ports. NMS supplier shall provide all necessary HW and SW materials for Data Communication Network (DCN) requirements under this RFQ. This shall include a technical description and proposal indicating the supplier’s approach for DCN and also a commercial proposal to supply all DCN requirements for EREC project.

4. STANDARDS AND PROTOCOLS

4.1. The offered Network Management System (NMS) shall be fully in compliance with ITU-T recommendation and technical specification for necessary Management Layers.

4.2. The NMS shall comply following ITU management recommendations:

• M.3000 - Overview of TMN Recommendations

• M.3010 - Principles for a Telecommunications management network

• M.3020 - TMN interface specification methodology





• M.3100 - Generic network information model

• M.3101 - Managed object conformance statements for the generic network information model

• M.3180 - Catalogue of TMN management information

• M.3200 - TMN Management Services: Overview

• M.3300 - TMN management capabilities presented at the F interface

• M.3320 - Management requirements framework for the TMN X-interface

• M.3400 - TMN management functions

• G.774 series – SDH management

5. GENERAL NETWORK MANAGEMENT REQUIREMENTS

Esfehan Regional Electric Company (EREC) is one of the power utility companies in Iran, responsible for power management telecommunication services and energy market within the power utility regional companies. EREC will build the Telecommunication Network for EREC Company which is responsible for power generation and transmission together with about seventeen Regional Electric Companies in Iran. In this regard, EREC Telecommunication Network is an integrated optical transmission and switching network functioning as EREC integrated telecommunication Transport Network (TN) and the network will be built on the Iranian national interconnected power generation and transmission network grid. EREC telecommunication network will be used for power management, and shall be capable to function in a multi-vendor environment and using multiple transmissions and switching technologies and delivering multiple services for regional and power utility management purpose, but at the same time for other advanced applications.

5.1. TMF EMS Requirements

5.1.1 It is mandatory, and the NMS supplier/developer of this tender shall provide all technical requirements, commercial terms and conditions, required technical information from Lower Layer (other vendors) NMS, also prices and estimated time to integrate other vendors NMS.





5.1.2 It is mandatory and the NMS supplier/developer shall provide full detail information about the proposed NMS CORBA Agent, capabilities and abilities toady, and the NMS roadmap if further development exists in the future.

5.2. Standards Compatibility

R.1 The offered TMF EMS (Element Management System) shall be compliant to the technologies (i.e. DWDM/SDH,..) Configuration Management solution as specified in TMF 814A version 2.5 document.

R.2 Equipment manufacture and NMS developer shall complete the following table indicating the standard technologies on which the proposed TMF EMS is built and supported today.





S.No Standard/Technology Version Supported Description

1. TMF

2. XML

3. JAXP

4. JDBC

5. HTTP

6. JFC

7. JSP

8. CORBA

9. SNMP

10. TL1





5.3. NMS Requirements

Equipment Manufacturer and NMS developer must provide, as a minimum, the following mandatory capabilities. Failure to provide these capabilities will result in the tender being disqualified and removed from further consideration:

R.1 SDH manufacturer Network Management System shall comply as a minimum, Element Layer (EL), Element Management Layer (EML), Network Management Layer (NML).

R.2 An Integrated Element Management System (EMS) for all the equipment and licensed software products including SDH STM 64/16/4/1 multiplexer platform, and any ancillary equipment tendered. Required equipment and software platforms and management framework must be stated and listed. The application must support multi-user and multi-server environments (more than one server and one client).

R.3 A centralized ASCII-based alarm log and scheduled performance monitoring log file that must be generated and accessible in real time and available at the EMS/ITMS interface. The EMS/ITMS link must be reliable and capable of transmitting heartbeat messages in the same alarm log.

R.4 All equipment tendered must be capable of remote download and upload of the licensed software products and configuration from and to the central EMS.

R.5 Must be capable of managing all equipment via a standard-based management protocol (preferably SNMP).

R.6 Must be capable of simultaneous sessions (i.e. modem link and EMS/ITMS) to all equipment.

R.7 Must be able to perform reset, diagnostic testing and self-diagnostic process for all equipment remotely and from EMS.

R.8 Must have redundant gateway network elements where complete system provisioning and monitoring can be performed.

R.9 Software upgrades must not interrupt system operation.





6. FACTORY TESTS

6.1. Demonstration of SDH STM-16/4/1 Multiplexer and Multiservice Access Multiplexer functionality using integrated management software. Manufacture shall arrange and build the entire EREC network in the facility and factory. The following functions shall be tested on the EREC network for every node in the network.

R.1 Configuration Management

1. Local Provisioning

2. Remote Provisioning

3. Automatic provisioning of replacement units

4. Configuration query and update

5. Inventory update

6. Local software maintenance

7. remote software maintenance

R.2 Fault Management

1. Network status supervision

2. Alarm Notification

3. Alarm Correlation

4. Alarm threshold definition

5. Fault History Report

6. Local and Remote Diagnostics

R.3 Performance Management (minimum parameters specified)

The proposed system shall be allowed evaluation of the quality of the transmission of the links give indication in advance of potential degradation of the services.





6.2. The Company shall demonstrate, as part of these tests that the transmission error parameters on the SDH Line, section and path as recorded by the network management software matches (or at least tracks with) that which is recorded on externally attached transmission test equipment.

7. FACTORY SYSTEM AND INDIVIDUAL CARD SOFTWARE TESTS

7.1. The Company shall demonstrate that the system software can be upgraded without interruption of service. The test equipment simulating payload shall not register any errors while the software upgrade is in progress, or while the switching from working to protection processor occurs.

7.2. The Company shall demonstrate that the equipment maintains its settings and configuration database after a power recycling.

7.3. The Company shall verify the presence of a regular “heartbeat” or “keepalive” status message at the EMS interface.

8. MANAGEMENT SOFTWARE TESTS

8.1. The Company shall demonstrate the availability of event and alert logs for monitoring purposes both dynamically and historically.

8.2. The Company shall demonstrate the capability of downloading both new software and configurations remotely to the device from a central site.

8.3. The Company shall demonstrate the ability to conduct simultaneous management sessions via multiple direct connections or modem connections.

8.4. The Company shall demonstrate the ability to perform remote reset, diagnostic testing (including self-diagnostics) for all modules remotely from the EMS.

8.5. The Company shall demonstrate that all management provisioning and autonomous message reporting can be performed from a network element designated as a Gateway Network Element as well as a redundant Gateway Network Element.





9. OTHER REQUIREMENTS

9.1. Full Management Capability

R.1 The proposed NMS shall provide as a minimum management services from Network Element Level (NEL) to Network Management Level (NML), form a single physical platform (HW) system.

9.2. Entire Network View R.1 The Proposed NMS shall provide all level of networks view through

an easy and user friendly interface, in separate windows.

R.2 The network operators and technicians shall be able to select and display all network level components and resources including, Links, Circuits and Nodes, and focusing on routing and provisioning tasks.

9.3. Fault Detection and Analysis R.1 The NMS shall provide fast alarm detection, identification, analysis

and rectification mechanism in the network.

9.4. Automatic Network Provisioning R.1 The NMS shall be capable of provisioning the entire rout of channels

at all levels (Trail Provisioning) and mainly on E1 level through entire network. The operator shall be able to select the head-ends of E1 channels and NMS shall provision the entire path of the channel using cost routing algorithms.

R.2 The network provisioner shall be programmable to use time schedule for Activation, Detection and Provisioning time.

9.5. Performance Monitoring Records R.1 The NMS shall collect and record performance monitoring data of the

Network Elements and the Network for Business and Service quality study.

R.2 Graphical display thorough user friendly SW shall be deployed.

R.3 Performance report for performance analysis, in any statistical form (i.e. histogram) will be required.





9.6. Performance Monitoring Records

R.1 The NMS shall collect and record performance monitoring data of the Network Elements and the Network for Business and Service quality study.

R.2 Performance information in Graphical and user friendly display (i.e. customer service performance information)

9.7. Automatic Disaster Recovery

R.1 In addition to the normal traffic protection (i.e. MSP, SNCP, MS-SPRING,..), for high priority traffic, requiring high Quality of Service (QoS), the NMS shall provide additional protection and rout the high priority traffic over different rout.

9.8. Modular and Scalable NMS

R.1 The NMS shall support small sub-networks, regional networks and national or global networks using same HW platform and SW programs. Incremental growth of the network shall be supported by adding new workstations.

9.9. Mixed Network Topologies Support

R.1 The NMS shall support any combination of network topologies including Ring, Point-To-Point and Linear, Chain and Star...etc in different NE groups. The NMS shall be capable to create manageable Virtual network, sub-network and domain mall sub-networks, programs.

9.10. Trail & Capacity Management

R.1 The NMS shall create different manageable trails and capacities in the network at a real-time or scheduled time bases.

R.2 Trails to be created automatically, either by operator request or from an external Operation (O.S.)





9.11. Alarm correlation functionality

R.1 A real time alarm monitor shall display all the alarms from the network resources and entities. Operator shall be able to request a list of the elements alarms in the event of the network alarm.

9.12. Geographic map and GUI Interface

R.1 The network topology shall be displayed in a user-friendly manner over different geographical maps for each domain, level or zoom.

10. SYSTEM ADMINISTRATION

The following system administration capability as a minimum shall be provided:

10.1. Programmable operator access rights

10.2. Domain management by geographical, circuit and Network Element (NE) type

10.3. Features can be time-controlled, or scheduled

11. SYSTEM SECURITY

The following system security as a minimum is required:

11.1. Entry and validation of user name and password

11.2. Restriction on actions which an individual user can take

12. OPERATIONAL SUPPORT SYSTEM (OSS) SOLUTION

12.1. EREC will use fibre optic as a common infrastructure to provide multiple services for power management System. SDH manufacturer and NMS shall provide clear technical information for the proposed NMS system using OSS solutions, and demonstrating how the NMS is capable and can manage today, the network for multiple services applications including but not limited to:

• Synchronous Digital Hierarchy (SDH) Networks at all layers (TN, Access and CP), network and technologies,





• Internet Protocol (IP) Network and technologies,

• Dense Wavelength Division Multiplexing (DWDM),

• VPN networks,

• Extranet networks,

• Intranet networks.

Telecommunication Equipment and NMS supplier for this tender shall provide information if the offered NMS can support: PDH, xDSL, wireless (ie. SDH Radio) and other equipment systems/networks

13. ELEMENT MANAGER OS SERVICE MANAGEMENT

13.1. The NMS Element Management –OS shall perform following functions:

• Configuration management

• Fault management

• Performance management

• Security management

14. OTHER REQUIRED FEATURES FOR NMS

14.1. Modular and scalable management platform for small to larg networks

14.2. Graphical User Interface (GUI) flexibility to manage and display network and sub-networks through interaction.

14.3. Available memory to store data on the Network Element configuration and alarm conditions in case of Element failure

14.4. Remote Software downloads from the element manger to upgrade NE functionality.

14.5. Total NE configuration and functional availability Element Manager-OS.

14.6. A historic alarm log shall be available to store alarms and operator actions.





14.7. Change on the F/W of the NE, shall not affect the NMS functionality. However, the equipment manufacturer and NMS developer shall provide information if F/W change of NE may need any modification of the proposed NMS.

15. SUMMARY OF THE NETWORK MANAGEMENT REQUIREMENTS

15.1. Network Management Functions

R.1 Network Management Functions

1. The Network Management System shall feature the following powerful automated features:

a. Security Management Function

b. Customer Administration Function

c. Network Configuration Function

d. Routing Function with End-to End Provisioning and Management

e. Test and Loop-Back Functions

f. Trunk and Channel Rerouting Function

g. Fault Management and Trouble Ticket Function

h. Performance Management Function

i. Fault Simulation

j. Application Development Function

k. Reporting through Web

2. These application functions shall be implemented in the Network Management System as a set of interactive application components using client-server architecture.

15.2. Network Configuration Function

1. The Network Configuration Function shall provide facilities to define the topology and configuration of the network.





2. The network topology shall be determined by the placement of locations, nodes, trunks on a network map and by the placement of nodes within locations.

3. The network configuration shall be determined by equipping nodes with units and interface modules, and by binding of trunks to interfaces.

4. Network objects shall be processed through three stages during installation and dismantling. These three stages shall be:

a. Stage supporting objects that are planned into database without installed hardware

b. Stage supporting hardware installations and tests

c. Stage for objects in production use

5. Preplanning shall be possible for channels and network topology (see b). All the related Network Elements shall be updated with a single action in Network Management System.

6. Provisioning of embedded control channel needs to be supported by Network Management System.

7. The Network Configuration Function shall provide facilities to define the parameters for nodes, units and interfaces. Group operations to allow parameterization of several interfaces at a time shall be included. If Vendor’s base band modems are connected to the node, all of their settings can be managed.

8. The system shall contain an integrated unit software download manager facility with the following features:

a. Scanning of unit software versions from the network element

b. Download of new unit software

9. The system shall contain an integrated unit software download manager facility for NTUs and hub nodes with the following features:

a. Automatic scanning of unit software versions from the network based on defined search criteria





b. Intelligent selection of compatible latest unit software revisions from the hard disk

c. Programmable execution of remote download actions based on user defined start up time

10. The facilities to define and monitor network synchronization shall be included in the Network Configuration Function.

11. The system shall automatically maintain, monitor and distribute real time in each network element. This real time shall contain time and date information.

12. The user can proceed with the following diagnostics:

a. Memory tests

b. Control bus tests

c. Cross-connection matrix and bus tests

d. Operating voltage tests

e. LED tests

f. Data interface circuit states

g. Interface and line loop activation

13. It shall be possible to change the active cross-connection card or matrix by one operator command.

14. The system shall be able to record graphical user interface actions into macro files, such as channel provisioning. Macro files shall support control structures, i.e. for-loops, to fasten up programming of repetitive actions.

15. The system shall contain an integrated mechanism to allocate identification number intervals for network objects. Definition of IDs that are not in compliance with programmed network numbering plan shall be automatically restricted by the system.

16. The operator shall be able to assign information on each interface, such as connected base station / node -B location and exchange block. This information must be seen from fault management application.





17. The Network Configuration Function shall provide direct access to unit faults and interface error counters.

15.3. Fault Management and Trouble Ticket Function

1. The Fault Manager shall provide facilities to monitor faults in the network objects.

2. The fault state of a network object shall either be normal, alerting, or faulty.

3. The severity of the fault is indicated with a corresponding colour. It shall be possible to customize colours for each severity class.

4. In the normal state the object shall not contain any faults and it will be indicated in the graphical user interface with normal colour.

5. In the alerting state the object shall contain one or more unacknowledged faults. This is indicated with a blinking colour on a corresponding object. Once the fault is acknowledged, blinking shall stop and the colour shall turn to steady.

6. In the faulty state the object shall contain one or more faults.

7. Cleared faults shall be stored in a fault history database. Deletion of entries in fault history requires a special access right. Fault reports, either displayed or printed, can be customized by selecting included nodes, columns and a time period.

8. Each active fault or fault history entry shall contain at least the following attributes:

a. Fault source b. Customer / Base station / node -B or Collection and module c. Fault description and code d. Fault classification e. Possible cause and suggested actions to correct the problem f. Fault maintenance status and service status g. Fault activation and deactivation time





h. Fault count i. Fault rerouting status j. Fault acknowledgement time k. Acknowledged operator

9. It shall be possible to affect the behaviour of the Fault Manager by means of system level fault filtering, so that the adjustment affects the handling of transient faults, the clearing acceptance criteria of faults, the masking of faults and the altering properties of faults.

10. It shall be possible to use state filtering to ignore faults coming from network objects that are being installed and are not carrying production traffic.

11. Besides system level fault filtering, the system shall support computer specific views to customize the severity classes seen on the screen.

12. It shall be possible to define different beep types for alarm indications and the severity threshold that causes the system to beep. Beep frequency shall be definable.

13. Problems shall either be of a general nature, related to some customer or channel, or related to some network object.

14. The Network Management System shall contain a fault consistency check, which shall automatically compare the information in the database with the information in the hardware of the network.

15. It shall be possible to record problem description into a Trouble Ticket.

16. The Trouble Ticket shall provide facilities to record information on network service problems.

17. Additional information on the problem shall either be attached to the Trouble Ticket (network faults), or shall be accessed from the Trouble Ticket (channel performance statistics, G.821).





18. A customer/channel Trouble Ticket shall be attached to a customer or channel and shall usually be created as a response to a customer complaint.

19. A network Trouble Ticket shall be attached to a network object or trunk, and shall usually be created as a response to an alarm from the network object concerned.

20. A general Trouble Ticket shall be created when the problem cannot be attached to any customer, channel, or network object.

21. The Trouble Ticket shall define an initiating operator and a responsible operator.

22. These operators shall edit, close and delete the Trouble Ticket. Other operators shall only be able to view the Trouble Ticket.

15.4. Performance Management Function

1. The Performance Manager shall provide facilities to monitor the performance of all trunks and channels without exception and including subrates, the load in nodes and trunks, and the performance of the management channel.

2. The performance of a trunk or channel shall be presented as G.821 (PDH) and G.826 (SDH) counters

a. The G.821 performance limits for triggering the sampling shall be set individually for all interfaces, trunks and channels without exception. Group operations help in defining similar parameters for several objects at the same time.

b. 15 minute limits shall be based on parameters, such as Severely Errored Seconds, Errored Seconds, CRC Errors and Remote Alarm Indications

c. It shall be possible for the performance statistics to be reported in tabular as well as in a graphical form such as a histogram.





d. The load in a trunk shall be presented as the ratio of used capacity to available capacity.

e. The load in each trunk shall be sampled once a day and stored for a period of several months.

f. The load statistics in a trunk shall be reported in tabular form.

15.5. Security Management Function

1. Security Management shall provide facilities to control operators' access to the Network Management System.

2. The access control shall be based on the use of operator user names, passwords and access rights.

3. Each operator shall have a user name, a password and a set of application specific read/write access rights.

4. All successful and unsuccessful login and logout attempts shall be stored in a log accessible for an operator with the highest security management access rights.

5. The user access rights shall determine which Network Management System user interface components the operator can use. The system shall provide means for getting report of all operators and their access rights to each application.

6. Additional security shall be achieved by setting a password expiration time and by setting a login attempt limit.

7. The operator with the highest security access rights can restrict other operators to access the system.

8. The system shall control that a VPN operator cannot access the system without a pre-programmed hardware identification module.

9. Customer Administration Function

a. Customer Administration shall provide facilities to maintain the customer directory and produce connection time reports of the customer channels. This customer directory can be used for managing information of base station / node -B and exchange sites.





b. The connection time reports shall be based on the channel accounting data, which the Network Management System components produce during the channel lifetime.

c. The accounting data shall contain information on all activation, deactivation, testing and recovery actions on the channel.

15.6. Fault Simulation

1. A tool to simulate fault shall be supplied to facilitate "off-line" emulation for purposes of trunk and channel level rerouting design.

2. Simulated node and trunk level failures shall be supported. Rerouting results shall be monitored as the normal rerouting actions in the production network.

15.7. Application Development Function

1. It shall be possible for the user to design and implement his/her own management software applications with a set of Network Management System integrated software development tools.

2. The developed applications shall be able monitor and create customized reports based on the existing run time network data, e.g. detected network errors.

3. It shall be possible to enhance existing Network Management workflows to speed up Network Management processes like network configuration.

4. The developed applications shall support timer controlled and simultaneous task execution for applications like queries.

5. It shall be possible to design and customize the graphical user interface, e.g. dialogs and windows of the developed applications





15.8. Network Management System User Interface

1. The user interface shall be graphical and consist of a hierarchical set of tools. These tools shall be controlled by selecting objects with a mouse and inputting information with a keyboard.

2. It shall be possible to view the network in both tree-like and graphical format

3. All the NMS tools shall be opened from the main program such as a NMS Toolbox.

4. Each tool, in turn, shall consist of a set of windows and dialogues.

5. The system shall not have any limitations of number of simultaneously opened windows and dialogues.

6. The system shall support minimum of six simultaneous program sessions in one management workstation thus making it possible for the operator to run several identical applications at the same time.

7. The windows shall graphically represent various network elements and objects.

8. Network objects shall consist of:

a. Physical entities in the network, such as nodes

b. Logical entities in the database, such as locations (collection of nodes in a geographical location), trunk bundles (collection of trunks between nodes), and channels

9. In addition to the graphical user interface, the system shall support an integrated macro manager facility to execute command files and thus speed up the configuration process. No such applications that are run on different operating system or computer platform shall be deemed acceptable.





10. Configuration updates on network topology (NEs, trunks, channels) executed in one user interface computer shall be visible for all other operators and no data conflict shall occur.

11. The system shall provide a comprehensive and easy-to-use on-line help facility in each application.

12. The system main dialogues for trunks, nodes and channels shall contain filtration facility with wildcard option to ease searching and sorting of information in large networks.

15.9. Network Management System Architecture

1. Architecture and Platform

a. The interactive components (clients) shall make up the user interface of the Network Management System.

b. The non-interactive components (servers) shall perform background tasks and provide services to the interactive components.

c. The Vendor shall supply recommendations for the hardware platform on which the management system shall run.

d. The supplier shall ensure that the hardware and the software work together correctly and efficiently.

e. It is possible for the user to get network status reports through Web.

f. It shall be possible to replicate the network fault information to another database to be stored for further analysis.

2. Redundancy and Solidity Management

a. The computer hardware platform shall include full backup facilities for the protection of the database(s) and performance data.





b. Hot stand-by protection of the database server shall be carried through replication.

c. Failure in the network management system shall not affect the traffic in the network.

3. Expandability

a. With this design it shall be possible to build a flexible system that adapts easily to changes in the managed network and to changes in the organization.

b. The system shall support dedicated server computers for transferring messages between the management system and the network.

c. The minimum number of nodes that can be managed with the centralized or partitioned multi-computer management system shall be proposed by the supplier. Network Terminating Units are not counted as nodes.

d. The minimum number of operator’s client computers supported by the system shall be proposed by the supplier.

e. Adding new client computers shall not cause any interruptions to the network management activities.

f. Upgrading the network management system software shall be able to be proceeded remotely and with maximum one hour interruption to network management.

g. The local management access to the network nodes shall be preceded through an intelligent service computer with graphical user interface. No dummy terminals shall be deemed acceptable.

4. Virtual Private Networking and Network Partitioning

a. The network management system shall support virtual private networking rendering it possible for the operator to assign some portion of the management capabilities for an external organization.





b. Virtual private network shall consist of the following components:

Shared and dedicated nodes

Dedicated trunks

Virtual trunks

Shared and dedicated interfaces

c. The virtual private network operator shall not be able to see those parts of the network belonging to the real network operator or other VPN operators.

d. The system shall also offer a growth path to partitioned network concept allowing the operator to break the network into regional sub-networks. This partitioned network concept shall allow the operators to view their regions as separate networks with applications specific access rights.

e. Network partitioning shall support service partitioning, such as customer- and circuit component views.

15.10. Information Output

1. Printed outputs of the performance, capacity and configuration of channels and trunks as well as fault histories shall be possible.

2. It shall be possible to provide customers with tabular printouts of the performance of any number of channels in complete accordance with G.821 and G.826

3. Printouts shall be possible on a daily, weekly or monthly basis.

4. It shall additionally be possible to write all of the above to industry standard text files, for further processing by other applications, such as spreadsheets.





5. It shall be possible to distribute network information like availability figures, fault information, node contents and network statistics by WWW. The access to the information shall be with standard Internet browsers like Microsoft Explorer or Netscape.

16. NMS REQUIREMENTS UNDER THIS RFQ

16.1. CONCEPT

Equipment suppliers shall offer Network Management Requirements of the ERECNET to meet the following concept (FIG-1&2):

• The NMS redundant Server System will be installed in CAOC site

• A remote client will be installed in Najafabad site.

FIG-1: ERECNET NMS Areas





FIG-2: ERECNET NMS configuration layout

16.2. NMS FUNCTION REQUIRMENTS

The offered management system shall meet following function and

system requirements:

CAOC:

Function: Full Management Capability Including; Network Element Level (NEL), Sub-Network Management, Element Management Level (EML), Network Management Level (NML),

o 1+1 Server + 1 Client shall be located at CAOC as Main NMS





Najafabad:

Function: Management Capability Including; Network Element Level (NEL), Sub-Network Management, Element Management Level (EML)

o One Client (PC Operator) shall be located at Najafabad

TMN NETWORK ARCHITECTURE REQUIREMENTS

Access Network Element Management Services shall inculde:

• Fault Management • Configuration Management • Accounting (if applicable) • Performance Management • Security Management • Log Management

Local Management requirements

• Alarm Mgt • Configuration Mgt • Security Mgt, • Performance Mgt • Graphical Network views

Remote Management requirements

• Local & Remote management • Alarm Mgt • Configuration Mgt • Security Mgt • Performance Mgt • Graphical Network views





Central Management requirements

• Single/multiple • Server/workstation Based • Remote operators • Centralized/Distributed operators • Open interface to higher level • Remote management • Full centralised Mgt • Alarm Mgt • Configuration Mgt • Security Mgt • Performance Mgt • Events logging • Graphical NE views • Graphical Network views

Graphical View Requirements

• NE Level Graphical NE views • Subnetwork Level Graphical NE views • Security Mgt includes Graphical NE views • Site Level Graphical NE views • Network Level Graphical NE views





Following provides network management required functions for VLAN management capabilities.

FIG-3

FIG-4

Documents

Network Management System (NMS) Intelligent ITMN Project Tender... · Network Management System (NMS) Intelligent ITMN September 2007 ... TCP/IP and SNMP protocol is the preferred