Power Grid Corporation of India Ltd.

U-NMS for ISTS & State Utility Communication Network

Volume II - Technical Specification for U-NMS

Section 2

UNMS Software Specifications

Table of Contents

2.1 Introduction ....................................................................................................................... 3

2.2 General Requirements ...................................................................................................... 3
2.3 Control Centre Architecture: ............................................................................................ 4
2.4 Software Requirements for U-NMS ................................................................................. 6
2.4.1 Service Fulfillment ............................................................................................................ 6
2.4.1.1 Network Resource Management………………………………………………… ......... 6
2.4.1.2 Design, Assign, Activation/Provisioning, Configuration and Re-Engineering.......... 9
2.4.2 Service Assurance ........................................................................................................... 12
2.4.2.1 Fault Management System…………………………………………………................. 12
2.4.2.2 Performance Management System ................................................................................ 18
2.5 Functional Requirements of U-NMS………………………………………… ............. 22
2.5.1 Unified U-NMS Console (Common Reporting & Dash boarding System) ................. 22
2.5.1.1 Generic ............................................................................................................................. 22
2.5.1.2 User Management ........................................................................................................... 22
2.5.1.3 Integrations ...................................................................................................................... 22
2.5.1.4 U-NMS Console on Mobile/Handheld….........................................................................22
2.5.1.5 Dashboards ...................................................................................................................... 23
2.5.1.6 Reporting ......................................................................................................................... 23
2.5.1.7 Fault Analysis and Statistics ......................................................................................... 24
2.5.2 Trouble Ticketing & Web Portal System ...................................................................... 25
2.5.2.1 Trouble Ticketing System .............................................................................................. 26
2.5.2.2 Web portal system: ......................................................................................................... 30
2.6 Generic Integration Requirements:............................................................................... 30
2.6.1 Integration Points: .......................................................................................................... 30
2.6.2 Future Readiness ............................................................................................................. 30
2.6.3 User Management ........................................................................................................... 31
2.6.3.1 User Authentication & Authorization ........................................................................... 31
2.6.3.2 User Administration ....................................................................................................... 32
2.6.3.3 User Audit ........................................................................................................................ 33
2.6.4 System Security, Access Control Management System & Audit ................................ 33
2.7 Web User Management .................................................................................................. 35

Section 2 Jan’20 Page 1 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

2.8 Pre- Assessment of NMS/EMS Upgrades: .................................................................... 35

2.9 SLA Management ........................................................................................................... 36
2.9.1 SLA Monitoring .............................................................................................................. 36
2.9.2 SLA Reporting................................................................................................................. 36
2.9.3 SLA Portal ....................................................................................................................... 36
2.10 IT Setup: .......................................................................................................................... 37
2.10.1 Reverse proxy: ................................................................................................................. 37
2.10.2 GSLB (Global Server Load Balancer):. ........................................................................ 37

Section 2 Aug’17 Page 2 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

Section 2
U-NMS Software Specifications

2.1 Introduction
This section describes software requirements for various functionalities of Unified Network Management
System (U-NMS).

U-NMS shall facilitate centralized supervision, operation & control of the Regional and State level
Communication system on round the clock basis with main & back-up configuration. It shall be possible
to operate, monitor, configure, addition/ deletion and control elements of Communication Network from
U-NMS. This system shall also assist in the operations and maintenance of the communication resources
including detection of circuit failure and system performance, the diagnosis of problems, the
implementation of system suggested remedial actions and the allocation or reallocation of
communications resources.

2.2 General Requirements

The supplied system of U-NMS shall be provided with main & back-up configuration in High
Availability (HA) mode consisting of UNMS server software & hardware (including storage devices,
VPS, Firewall, local console, printer etc.) for Regional configuration and extended client/workstation of
regional UNMS for State level U-NMS to manage their respective Regional/State Communication
Network.

2.2.1 U-NMS shall facilitate following services through the supplied system:
a) Network Resource Management (Network Discovery &
Inventory Management)
b) Design, Assign, Activation/Provisioning, Configuration and Re-Engineering System,
Network Planning & Capacity Optimization
c) Fault Management System with Analytics for trending & prediction
d) Performance Management system
e) Trouble Ticketing System (Incident Management System & Web Portal)
f) Reporting & Dash Boarding System

2.2.2 The sub-systems used to provide the above services shall be fully integrated among each other so
as to provide seamless operations.
2.2.3 The design shall be according to industry best practices and follow proper disaster recovery
procedures and emergency response procedures in case of a disaster.
2.2.4 Hardware Sizing & Software licenses to be provided considering for 200% expandability for both
NMSs and (NEs & VNE‟s) without affecting performance of the supplied system.
2.2.5 The U-NMS design concept, functional and informational architecture and physical architecture,
shall comply with ITU-T Recommendation M.3010.
2.2.6 The source codes /web-services based APIs of the proposed U-NMS shall be provided to allow
integration with upper-layer management systems via XML/SOAP/HTTPS etc.

Section 2 Aug’17 Page 3 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

2.2.7 Supplied U-NMS system shall support north bound CORBA/XML/ Q3/SNMP or any other
acceptable open standard interface for ensuring integration with other existing/upcoming U-NMS
of similar nature.
2.2.8 The system shall be integration with SCADA system of Control Centers such as Load Dispatch
Centers (LDCs) & Renewable Energy Management System (REMC) on standard protocol such as
ICCP/web services/OPC etc. for Remote Terminal Unit (RTU) availability and co-relating the
same with respective link/node availability.

2.3 Control Centre Architecture:

2.3.1 The proposed solution shall have High Availability (HA) in active-active configuration mode at
main & back-up Regional CC to maintain uninterrupted service in the event of any kind of
software or hardware failure.

2.3.1 The infrastructure offered for proposed solution shall be completely virtualized and it shall be
possible to scale it vertically and horizontally for future requirements. Supply, installation &
commissioning of Software for virtualization shall be in the scope of bidder. Details of hardware
requirement are elaborated in Section-3 of this Technical Specifications.
2.3.2 The Operation of Main and backup control centre will be coordinated in such a way that the
Application and Database in both the control centres are real time synchronized.

2.3.3 The replication of Database (Main and backup) shall be done automatically (ref. Figure 2-1) and
are in near real time. In case of failure of main control centre, the control function shall be fully
taken care by the backup centre automatically and manual take over as per Employer’s
requirement. The U-NMS should operate in an active-active mode at Application and Database,
so that if one application goes down, other application should come up automatically. The
Availability of the U-NMS should be more than 99.9% on yearly basis.

Main & Back-up CC Connectivity (Typical)

Section 2 Aug’17 Page 4 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

FIGURE-2-1

2.3.4 Restoration of main Control Centre shall be done after synchronism of database is
achieved and after proper validation which shall be done automatically. Similar
methodology shall be adopted for restoration of back up Control centre from a
failover situation.

2.3.5 The proposed system shall meet main-backup redundancy requirement for all the
Applications, Tools & Database envisaged under this Technical Specification.

2.3.6 The Control Center architecture shall be scalable and shall have high performance.
Critical network equipment such as Switches, Routers and firewalls shall be provided
on a redundant mode with device level redundancy.

2.3.7 The switches are to be used to interconnect the Database Servers, Application Servers
and CC Administration Server. External firewalls secure the Control Centres from the
external world. Internal firewalls separate the zones of Application / Database tier
from the web tier & administration Tier (ref Figure 2-2).

Figure- 2-2: CC Architecture (Typical)

Section 2 Aug’17 Page 5 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

2.3.12 Intrusion Detection & Prevention System shall scrutinize all the traffic entering into
the CC from the internet for all type of attacks through Centralized Management
Console.

Back-up Control Center:

1) A replication link shall terminate over the WAN router at CC. The replication link
shall be provided by Employer to meet the requirements.
2) Data from the Main CC shall be replicated to the back-up CC in asynchronous mode
on an ongoing basis.
3) During regular updates, only incremental data pertaining to the previous interval shall
be transferred. However, it shall also be possible to mirror the whole database during
slack hours any number of times during the day at prescribed hours.
4) It shall be possible to monitor the health of back-up CC from main CC and vice -
versa continuously or under operator command.
5) The Contractor at least once in each quarter of the year, at a time mutually agreed
shall conduct the back-up drill.

2.4 Software requirements for U-NMS

The U-NMS system shall have capability of integration with multiple wired/wireless
technologies like SDH, PDH, DWDM, CWDM, ASON, OTN, PTN, MPLS, VSAT, Radio
etc. from multiple vendors. However, during implementation of U-NMS, transmission system
technology, termination/cross-connect/Access system configured in the network shall be
considered for integration in the proposed U-NMS. U-NMS shall ensure seamless operation
& management of Communication network viz. fault Management, Design & Provisioning,
Inventory management, Performance monitoring etc. without dependency on underlying
NMS. The delay/latency added due to U-NMS in existing Communication system shall not
exceed 1ms. Proposed U-NMS Performance Parameters for various aspects are provided at
appendix. The system shall have capabilities to take manual inputs for the systems which are
not integrated and shall consume & correlate the same for system discovery and O&M.

2.4.1 Service Fulfillment

2.4.1.1 Network Resource Management (Network Discovery & Inventory

Management):

There shall be facility for discovering the entire existing network and service/circuit
inventory. System shall support Auto Discovery and on demand Manual discovery of
Network Inventory, Network Topology, Services/Circuits and Topology Links. It should be

Section 2 Aug’17 Page 6 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

possible to define and view a complete Topology of the network in the Network inventory
solution.
System shall integrate with NMS/NE to capture network inventory. Further, it shall have
facility to integrate with more than one of the following applicable sources and discover
/capture the inventory from a combination of sources to build the E2E Network inventory:
i. Integration with other Existing Inventory Management Systems, if exists.
ii. Importing from Excel files
iii. Support in the proposed system for Templates / Rules based inventory building

Inventory data in the context of U-NMS refers to service/circuit, logical and physical network
inventory data besides others required in order to implement the service-assurance related
functionality of the U-NMS. The data that has to be maintained shall include the following
but not limited to:

1) The U-NMS Application shall do Automatic Topology Discovery for complete

network. Appropriate Bridge/Agent/Adapter software for each Vendor technology
shall communicate either with the respective NMSs or with the NEs directly, without
adding any further delay.
2) The application would then filter, correlate, reconcile and stitch the data together to
give a complete picture of the E2E circuits comprising of multiple make nodes from
multiple vendors and topology of the network.
3) Auto Discovery System shall have GUI based User Interface to provide map based
GUI to view the discovered Information on geographical map such as Google earth
etc., tracks discovery processes and allows to add/modify/delete profiles, which
defines scope of discovery. GUI module shall be capable to present the different
features to the users based on their respective privilege.
4) Since any communication network will undergo frequent changes, there should be an
automatic way to discover the newly added links. Deletion of the existing links shall
also be possible by adopting a similar approach with user confirmation. The system
should support dynamic addition/deletion of new links.
5) The system shall provide for the categorization of the circuits (Healthy Circuits,
Hanging Circuits, etc.) and shall discover the circuits found hanging and the same
would be identified and reported to the user.
6) The system shall provide GUI support to provide a view of all incomplete discovery
run status with option to suspend/resume/cancel. It should also provide the history
logs of completed discoverer processes
7) Manual data entry or data population of the U-NMS data stores should be minimized
or avoided completely where ever feasible.
8) The system shall support circuit end-to-end route discovery and display in GUI view,
including network, node, card, port, timeslot with all internal patching etc. (MUX
/DEMUX, OUT level).
9) The system shall provide inventory management process automation capabilities and
offer full visibility of all communication assets across the Regional/State Utility
network.

Section 2 Aug’17 Page 7 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

10) The system shall discover the physical and logical attributes for all the equipment and
for all equipment types in the network.
11) Physical attributes shall include node name, node id, channels available, NSAP/IP
address, Serial number, Shelves, Slots, cable and ports etc.
12) Logical attributes to be discovered shall include cross connect details, bandwidth, A
end and Z end, CTP details, Protected/Unprotected circuits, Topology link, Protection
paths, Circuit names, System configurations, etc.
13) The system should allow discoveries of smaller subsets of the network.
14) The IP based (SUBNET) discovery of network elements should also be supported.
15) It should be able to create profiles and initiate the profile based discovery.
16) It should provide different reports based on the discovered data and export the data in
mutually agreed formats such as .exe /.pdf/.hxml/.doc/.ppt etc.
17) The system should support configuration of threshold for data poling to ensure CPU
utilization is not exceeded permissible limit per vendor or discovery schedule. The
same shall be depicted by a system-generated report for an instantaneous / average
utilization of resources (such as CPU, RAM etc.)
18) The system shall have facility for presentation/bulk display/search page as well as
export in agreed formats.

19) The system shall support GUI reports for examining the utilization of the resources
such as Port, Link etc. The system should be able to provide link and ring utilization
information.
20) The system shall support creation of Virtual Network Elements (VNE) and virtual
networks for representing the 3rd party network elements and network respectively. In
addition, it must also support addition of inventory to the VNE/Virtual network to
provide the end-end view of the circuits passing through 3rd party networks.
21) The system shall provide facilities for creating custom grouping of available network
elements in to different maps.
22) The system shall allow performing renaming of trails on bulk basis as well.
23) The system shall accept the source and destination ports of the ring to be discovered.
24) The system shall have the capability to trace the entire ring on best effort basis and
present the same to the user for confirmation. The system shall store the traced ring in
the database after user confirmation.
25) The system shall allow the user to modify the traced ring during the discovery
process.
26) The system can get the intermediate ports as input wherever there are more paths and
complete the discovery.
27) The system shall present the complete ring in tabular and graphical form in the user
interface during the discovery process.
28) The system shall present the consolidated link utilization report, ring utilization report
and drop traffic reports for each discovered ring
29) The system shall be able to provide a list of all Network elements with respect to all
the Network Management systems that are managed by the system.
30) Application shall facilitate Role based access and shall support 100 Users; 50
concurrent users.

Section 2 Aug’17 Page 8 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

31) The system shall have the capability to discover and model the Ethernet Layers.
32) The system shall have the capability to add additional parameters or attributes to the
discovered data through a GUI to enrich the discovered inventory.
33) The system shall have the capability to interface with 3rd party U-NMS and
automatically reconcile the re-discovered data.
34) The system shall have the capability to provide the discrepancy reports comparing the
discovered data with the previous discovered data or comparing the 3rd party U-NMS
system .
35) The system shall have the capability to make changes in the 3rd party system based
on discrepancy identified.
36) The discrepancy identification, reporting, correction/deletion shall be workflow based
and shall require user approval at various stages.
37) The system shall have the capability to expose the discovered data through standard
NBI e.g. TMF 814 etc. to external 3rd party systems
38) The system shall have the capability to expand along with the network. The system
shall be able to accommodate new vendor, network growth based on network
elements, new device types etc. in the proposed system.
39) The system shall be scalable vertically and horizontally based on growth in the
network
40) The system shall have the capability to integrate with Assurance and Fulfillment
Systems to provide enriched Inventory.
41) The system shall discover synchronization status of all communication equipment (as
applicable) and display in GUI view indicating the synchronization status of each
node. The system should discover the sources (at least primary & secondary) and
display. The system should also discover & report nodes, which are discordant or
running on internal clock.
42) Real time inventory and bandwidth utilization status & reports (vendor wise, node
wise, section wise, ring wise, region wise, technology wise and for complete network)
shall be provided as per the frequency to be decided or whenever required.
43) Discovery and Inventory (Passive):
i. The system should be capable of monitoring passive inventory (inventory in
stores, issued to contractor for deployment or in transit etc.). Passive inventory
needs to be manually discovered. As part of initial Inventory loading to the
system, the contractor shall be responsible to consider all the existing Network
Inventory for building database and configure the same and correlation of
services with respect to allocated Network Services and Network resources.
ii. The system should be capable of keeping audit trails of changes in inventory
system.
iii. The inventory system shall be capable of showing up to date (recently)
discovered data in GUI in sync with earlier discovered data.
iv. There should not be any dependency on data availability during stitching post
discovery.
v. System should have capability to reserve paths for expected services for which
preliminary approvals have been done.

Section 2 Aug’17 Page 9 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

2.4.1.2 Design, Assign, Activation/Provisioning, Configuration and Re- Engineering

1) The purpose of Provisioning System is to enable process activation of new services in
the communications networks from a central location. A User enters the necessary
information into system. Provisioning system delivers it further to the right network
elements, after which the services are activated. Provisioning system shall interact
with network elements or NMS for the provisioning. The time taken for E2E
configuration & provisioning from command to execution including data pulling from
multiple NMS and final execution by U-NMS shall be as per Annexure.
2) The provisioning system shall interface with the inventory management system and
update service and network inventory.
3) The system shall ensure that the requested service is provisioned on the required
network elements/NMS.
4) For an end-to-end bandwidth request, the provisioning of resources shall be done in a
manner so as to optimize the path and minimize fragmentation of bandwidth.
5) The provisioning system must be capable of provisioning a working path and
protection path. Switching to protection path in case of failure of main path shall be
automatic and switching time shall be as per annexure.
6) The bandwidth provisioning system shall automate the end-to-end provisioning for a
given source and destination for the entire Communication network hierarchy.
7) The bandwidth provisioning system shall have the capability to perform pre-
activation validation
8) A batch interface shall also be supported for service provisioning requests.
9) The proposed system needs to interface with NMS/network elements belonging to
different OEMs, supporting different interfaces in the future also.
10) The system should be capable of giving multiple options & set rules for selecting
specific path & 2nd best possible path for provisioning.
11) The system shall log service provisioning information such as: Date of Request, Time
of Request, Type of Request, Status of Request, Request Id, Requester Details etc.
12) The system shall assign processing priorities to provisioning requests based on origin
and / or destination.
13) System shall be able to operate in centralized or de-centralized mode, i.e. the
provisioning shall be performed from a central location under Centralized mode
requirement and if necessary the provisioning for a particular region / location can
also be performed by any user from that particular region / location.
14) The system shall support the time component along with any of the dates so that it
shall make possible the activation of a service at a particular time and date.
15) There shall be a front end to monitor the status of the requests and any errors in
processing.
16) All the activities happening through the system shall be tracked and a history shall be
maintained at least for 3 months online in system & 3 years in archive mode.
17) The offered system shall be configurable & customizable.

Section 2 Aug’17 Page 10 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

18) The provisioning system shall support rollback in case the activation fails.
19) The provisioning system shall support roll back to revert back to the earlier status
which shall also make necessary changes in underlying network as well. User should
be able to define specific roll back points. There should be facility to configure the
number of attempts and the frequency of attempts before rolling back the activation
process.
20) The system shall be able to support establishment of user groups, and permissions to
restrict certain users to specific provisioning activities.
21) The system shall send provisioning transactions to the NMS/EMS/NE in the real time
22) The system shall support field validations during provisioning input.
23) The system shall support automatic bandwidth grooming feature across multiple
Networks.
24) The system shall facilitate feasibility study for providing a circuit of a particular
capacity between two end points and also block the network resources for a
configurable time period & export API’s for external applications too.
25) The system should support path computation and Circuit Layout Record (CLR)
generation for path activation, with or without constraints like Ring diversity or Route
diversity or the combination of ring or route and any existing circuit.
26) System should be in a position to carry out the Auto deactivation and activation in a
manually planned as well as in a phase wise manner.
27) The system shall facilitate identifying Hanging Circuits in the Network. Such circuits
shall be identified and reported to the user. On confirmation from the user, the
hanging circuit shall be deactivated.
28) The system shall be able to flow-through provisioning and activate network devices &
services in a multi-vendor EMS/NMS/Device landscape to support “flow through
service activation”.
29) On successful provisioning, the system shall update the inventory database so that the
resources are not considered again for further provisioning.
30) The system shall support concurrent provisioning to various NMS/EMS.
31) The system shall propose various path options for different services between two
locations or NEs – shortest, least cost, minimum delay and optimized path based on
the following:
i. Cost
ii. Rings count & Hop Count
iii. Bandwidth Available

32) The system shall provide capability to a user to be able to reject the best path
computed/proposed by tool and to select/view from alternative options.
33) The system shall provide GUI to view the designed end-to-end circuit/service before
activation in network.
34) The system shall support all type of planned network changes.

Section 2 Aug’17 Page 11 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

35) The system shall provide the list of circuits/links/services, which are pending for
provisioning.
36) The system shall support upgrading/downgrading the existing circuit.
37) The system shall support creation/deletion/modification of NE level constraints
during activation.
38) The system shall highlight dropping and/or capacity constraints if path computation
failed.
39) The system shall consider the card capacity rules during provisioning.
40) The system shall support creation/deletion/modification of card capacity rules.
41) The system shall support topology based path computation.
42) The system shall support bulk provisioning of more than one circuit.
43) The system shall provide capability to do ring/link optimization by checking free
ports in same node/card and suggest possible optimization & take action accordingly.
44) The system shall support creation of business & global rule with admin approval.
45) The system shall provide Network planning & capacity optimization tool to study the
following
i. Present network scenario for network understanding
ii. Traffic forecasting for based on past trends.
iii. Network planning for fulfilling present services requirements.
iv. Exercising different options for network study
v. Simulation with real time network snapshots for planning and optimization
function in Testing and Development environment.
vi. For Planning and Optimization activities, the proposed changes have to be
implemented in Test & Development environment before deploying in
production.
vii. Tool shall be deployed at main CC

2.4.2 Service Assurance

2.4.2.1 Fault Management System (along with RCA, Service Impact Analysis & Network
Impact Analysis)
1) Fault Management System shall be implemented for the complete Service fulfillment
module of the Communication System under scope.
2) For the purposes of this document, an event is defined to be an unsolicited message
from a network element and an alarm is defined as a type of event that indicates that
there is some kind of fault on the network element that emitted the event.

Section 2 Aug’17 Page 12 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

3) The System Fault Management solution shall provide network engineers a global
view of their networks, and enable them to activate management functions and
operations from single or multiple workstations.
4) The FMS window shall display end to end circuit diagram in a graphical fashion
highlighting the affected section.
5) Any fault in FMS window should be graphically represented into other modules such
as Discovery, etc. i.e. if there is any fiber cut in the network, affected section should
turn RED into the graphical topology/circuit view.
6) There should be no constraint on no. of users that can be created on FMS window.
7) User privileges and rights should be decided as per requirements of Employer. All
activities carried out by any user should be captured in the log.
8) The System shall provide facilities that enable the states of services and bearer
circuits to be monitored.
9) The System shall enable individual services and circuits to be mapped to the network
facilities that carry those services and circuits.
10) The System shall provide a function that enables faults that occur in the network to be
related to the services and circuits that are carried by faulted facilities.
11) The System should provide a high-performance engine to meet the requirement of the
integrated alarm system, which can guarantee the normal running of the integrated
System especially when the event storm occurs in the network.
12) Alarms arriving at the System shall be transformed into a common format prior to
processing by the System. The System should use the common alarm format in all
internal System data stores, and in engineer displays, so that external applications that
need to process alarms will only have to deal with a single format, and operations
staff will see only one representation for all alarms from all network element types.
13) The common alarm format supported by the System shall contain at least the
following information:-
i. Event type.
ii. Managed object identifier.
iii. Date and time of alarm emission.
iv. Perceived severity.
v. Probable cause.
vi. Notification identifier or correlated notification identifier.
vii. Specific problem.
viii. Label / Native EMS Name of the Managed Object

14) The System shall provide a comprehensive alarm correlation facility which shall be
used for following primary purposes:-
a. To determine the root-cause underlying sets of alarms and report the root-
cause as a single alarm.

Section 2 Aug’17 Page 13 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

b. To assist in reducing the number of alarms seen by engineers to the minimum

necessary to effectively manages the network.
c. The correlation function shall correlate large number of alarms to identify the
underlying problems affecting the network equipment.
d. The function shall be used to automate network management tasks. In
particular, it shall be used to perform high-level automated actions for Alarm
filtering, Alarm aggregation, Alarm enrichment, Root cause analysis and
Service impact analysis.
15) A complete, practical and high-efficient fault association analysis system should be
established to meet the network event correlation requirement. Perform automatic
association analysis to intra-network or cross-network faults through establishing an
association model; assist the network maintenance personnel to correctly analyze and
locate the reason for fault events in the shortest period; and establish the association
between NE faults and service faults. Thus, the degree of influence on the service can
be known in the shortest time and the influence state of service faults can be rapidly
located through the association analysis engine.
16) If network events occur, the system should be able to implement the association
between these events and the asset/inventory management system in real-time.
17) The system shall obtain the related equipment asset/inventory information and related
operation personnel information, add the inventory information into the alarm
information and display the contact information in the FMS window. Thus, the
monitoring personnel can timely notify the related personnel of these faults and the
operation personnel can perform troubleshooting rapidly.
18) Working together with the related external network association model database, the
system should be able to analyze and locate the cross-network alarm for intra-
network and cross network faults.
19) Sending a message (by e-mail or SMS or PUSH notification on mobile App) to notify
maintenance personnel about the fault.
20) During network build activities, such as constructing a new trunk route or
provisioning a new circuit, alarms may be raised that are irrelevant to the proper
functioning of the network. These alarms may be referred to as “build alarms”. The
System shall provide facilities that will enable it to identify build alarms and suppress
them.
21) The System should enable engineers to request suppression of alarms from a
particular managed object, or a group of managed objects or an entire managed
network element. Alarms from those objects that are marked as “suppress” should be
logged but not passed on for handling.
22) The System shall be able to recognize duplicate alarms by comparing incoming
alarms to those already in the current problem list for the reporting object, based on
one or more alarm attributes (for example, object name and notification identifier),
and automatically suppress such alarms.
23) The function shall allow resynchronization of the System alarm status to the current
status of the managed equipment.

Section 2 Aug’17 Page 14 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

24) The system shall generate alarm for any synchronization issue. It should also report
for services affected due to synchronization in network.
25) It shall implement a remedy that eliminates any alarm status discrepancy that may
have occurred during operation between the alarm status as presented in System and
the real equipment status
26) Alarm resynchronization may be necessary in situations such as:
i. Equipment failure preventing alarm reporting (for example, disconnection, power
failure, hardware defects). ii. Mediation device failure preventing alarm reporting. iii.
Data communication link failure. iv. Equipment registered for the first time, but
starting with one or more initial alarms. v. Human errors in operation of equipment
or System
27) There is a requirement to log alarms at the alarm-handling level. The alarms saved
shall be used for statistical analysis of alarm handling behavior, but they may also be
used for SLA dispute resolution and may be kept for 7 years.
28) The function shall handle ISO-formatted alarms (notification events defined in the
ITU X.733 & X.736 Standards): Communications Alarm, Quality of Service Alarm,
Processing Error Alarm, Equipment Alarms and Environment Alarm.
29) The function shall handle both notification type events (notification events defined in
the ITU X.733 & X.736 Standards) and configuration type events (configuration
events defined in the ITU X.730, X731 & X.732 Standards) raised by equipment or
applications.
30) It shall provide real-time monitoring and notification to allow engineers to handle
alarms as they arrive.
31) It shall support collection, filtering, recording (logging of the actions performed on
the alarms), storage, and correlation and management functions.
32) The stored alarm records shall be made available to, and managed by, other System
applications in real-time.
33) The “terminated” alarms shall be exported to a database for further user-defined
processing.
34) The System shall be able to automatically clear an outstanding alarm when a
corresponding clear-alarm is received (corresponding means that the managed object
name and the notification identifier are the same in both the alarm raise and the alarm
clear, and that the clear was emitted temporally after the raise).
35) The U-NMS shall monitor its connections with EMS/NMSs and Network Elements,
and raise an alarm if a connection fails. Such an alarm should be automatically
cleared when the failed connection is restored.
36) When a connection to an EMS/NMS or network element is restored after having been
lost, the system shall initiate a resynchronization operation with the EMS/NMS to
refresh the alarm states held by the system. The alarm reported during
resynchronization shall be reported by exception.
37) The system shall support configuration of threshold for data polling (alarms) to make
sure CPU utilization is not exceeded the permissible limit, because data polling keeps
on consuming CPU as the alarm count increases.

Section 2 Aug’17 Page 15 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

38) The System shall enable engineer-initiated resynchronization of alarms with selected
managed objects, network elements or EMS/NMSs.
39) The System shall support at least the following alarm states (or their equivalents by
other names): -
a. Raised (an alarm has been raised but not yet acknowledged)
b. Acknowledged (an operations staff has acknowledged that they have seen an
alarm).
c. Handled (handling of an alarm has been started).
d. Cleared (the condition that caused an alarm to be raised has been cleared).
e. Archived (an alarm has been archived and is eligible to be purged from local
storage).
40) The System shall support multiple alarm-display domains. It shall be possible to
apply filters to each alarm-display domain so a given domain shows only a selected
subset of the total list of outstanding alarms.
41) The System shall support a state-change operation to bulk of alarms (for example, if
10 alarms are selected and the engineer invokes an acknowledgment operation, then
the states of all selected alarms should be set to acknowledged).
42) Some network element types emit certain alarms that are outstanding only for a short
period of time (typically less than five seconds, but the period can be longer or
shorter) before a corresponding clear alarm arrives. These alarms are called “fleeting
alarms”. The System shall provide facilities that will enable it to identify fleeting
alarms and suppress them before they are passed to alarm handling.
43) The System should maintain a “master alarm” for each managed object reporting
fleeting alarms. The master alarm should contain a count of fleeting alarms received
from the reporting object, and the count should be incremented each time a new
fleeting alarm is reported by that object
44) Each alarm-display domain shall be implemented as a Graphical User Interface
(GUI) that is intuitive to use and will require minimal engineer training time.
45) The alarms displayed in all display domains shall be color coded (customized as per
employer requirement) on the basis of perceived severity.
46) Engineers should be able to define their own individual set of data that is to be
reported against alarms (for example, some engineers may want to see the additional
text of alarms, while others may not).
47) Map display, with a top-level summary of the current network status in a selected
geographic area. The colors of the icons shown on such a display should reflect the
current worst alarm status of the underlying elements. Initiating an action against an
icon should cause a “zoom-in” to show progressively more detailed views of the
individual lower-order entities that comprise the icon.
48) Root-cause domain, in which a selected set of current root-cause alarms is displayed
in tabular form. Selecting an alarm and invoking an action against it should show the
alarms that contributed to the raising of the root-cause alarm.

Section 2 Aug’17 Page 16 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

49) Service-state domain, in which the states of a selected subset of services are
displayed. Invoking an action against an alarmed service should show the alarms that
contributed to the service being alarmed.
50) Circuit-state domain, in which the current state of selected (generally high-speed)
bearers is displayed. Invoking an action against an alarmed circuit should show the
alarms that contributed to the circuit being alarmed and the services that are affected.
51) The System shall enable engineers to append one or more notes to a selected alarm or
group of alarms.
52) Engineer notes should be able to be long enough to contain substantial amounts
(minimum 500 words) of information that may be passed between groups during
fault resolution.
53) Customized dashboard should be available indicating No. of ring failures, Node
isolations, etc. to present the status of services based on fault and performance data
available in U-NMS.
54) The system shall be able to classify the services as fully affected or degraded based
on the shape of the circuits
55) At a given point of time, the system shall be able to list all affected or degraded
services in a separate UI with their corresponding root cause alarm
56) The system shall be able to show all the lower order trails that are affected when the
corresponding higher order trail has failed
57) The system shall be able to list the services for every topological link or network
element that will be affected or degraded when this element goes down
58) The system shall be able to update the results of SIA while receiving the faults from
the network
59) The System Notify Function shall support manual or automatic forwarding of
notifications via SMS, email. It shall support forwarding of selected alarms to
individuals based on configured notification settings.
60) The system shall take in to consideration all standard protection mechanisms while
computing the RCA.
61) The system shall be able to modify the RCA results on receiving every/new alarm
from the network.
62) The system shall have the capability to handle a minimum of 1 million alarms per
Day with an average alarm rate of 60 alarms per second and peak at 200 alarms per
second for 1 minute.
63) The system shall be able to compute the RCA and related SLA within 3 minutes from
receiving the alarms for at least 95% of alarms received.
64) The System shall have the capability to simulate an alarm in the database and identify
the related services, which are affected based on the alarm raised.
65) The system shall have capability to correlate and display the relationships across
Root

Section 2 Aug’17 Page 17 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

Cause and Impacts as a hierarchy across the network / service objects as shown (but
not limited to) below:
i. Correlation within SDH Layers - The system shall have the capability to correlate
the impacts of failure of one of more of the following SDH layers to other SDH
layers riding over them
a) STM-n Links to VC4
b) VC4 Server Trails to VC12 / VC3 Trails riding over them
ii. Correlation from SDH to EoSDH layers - The system shall have the capability to
correlate the impacts of failure of SDH Layer to the EoSDH VCG Server Trails
encapsulating them
iii. Correlation within EoSDH Layer - The system shall have the capability to
correlate the impacts of failure of GFP/VCG Layer to the Ethernet Services riding
over them
iv. Network to Passive Objects Correlation – The system shall have the capability to
correlate the impacts of failures of the Passive Infrastructure Objects to the
Network Objects using such infrastructure
a) Cable to Link failures
b) Site / Location to Network Element Failures
c) Auxiliary system alarm

66) Integration with Trouble Ticketing (TT)

i. The system shall support automatic/manual creation of Trouble Ticket for
Problems / Root Cause Failures identified.
ii. The system shall have the support to publish the SIA & NIA list of a Problems
into its respective Network Failure Ticket
iii. The system shall have support for manual Creation of Service Incident Tickets in
a user-friendly manner with minimum inputs from user
iv. The system shall have facilities for automatic association of the Service tickets to
its associated Network Ticket
v. The system shall support automatic/manual resolution of Network Trouble Ticket
on clearance of Network Problem
vi. The system have facilities for user-approved auto-ticketing, i.e. Interrupt Auto
Ticketing process and put ticket creation on hold till user confirmation
vii. There should be mechanism to define workflow for different tickets types & user
assignments.
67) Consolidated Fault management system should enable operators to Identify hot spots
and frequently occurring events with guided search based on best practices. The
search should be based on key words and should fetch data from real time as well as
historical events for empowering operators with relevant and quicker Root Cause
Analysis.
68) The system shall have report generation facility for RCA and alarms elementwise,
link/service wise/ port wise etc.

Section 2 Aug’17 Page 18 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

2.4.2.2 Performance Management System (PMS)

1) Performance Management Tool shall be agnostic to technologies and vendors.
2) The System shall collect performance data from all network elements that support
performance data production, but collection shall be able to be turned on or off per
network element or per managed object (if supported by an EMS/network element
combination).
3) The System should allow performance data collection schedules to be defined per
network element or per network element type or per EMS, with the schedules able to
be programmed by operations personnel.
4) By default, 24-h Customer’s performance data shall be collected from all collection
enabled network elements every day, but operations personnel shall have the ability to
select 15 minutes performance data collection for nominated network elements, with a
correspondingly shorter collection period.
5) Some EMS/NMSs do not support real-time collection of performance data: collection
is run as a batch task on the EMS system. The System should pick up such
performance data using some mechanism such as ftp or alternatively may collect
performance data directly from NEs.
6) The System should poll the PM data to be collected from the EMS/NMS for the PM
Points (Layer Rate/Location/Granularity/Parameter) including all the KPIs supported
by the EMS/NMS for all the enabled ports (PTP-Physical Termination points)/CTP
Circuit Termination Points) at regular scheduled intervals.
7) The System should raise a critical alarm if a performance data collection operation
fails.
8) The system should allow configuration of threshold for direct poling via NE to make
sure CPU utilization is not exceeded.
9) The System should enable performance thresholds to be set on a per managed-object
or per-managed-object-type basis, with hourly, daily and weekly settings available.
10) The System should raise a performance alarm if a nominated performance threshold
for a managed object is exceeded and the Tool shall have capability to forward a
Threshold Crossing Alert (TCA) to the appropriate system.
11) The System should be able to collect service-performance information for service
level management purposes.
12) The System should be able to collect network-performance data that can be used by
engineering groups for planning and maintenance purposes.
13) The System should be able to detect pending network problems that is signaled by
network elements in the form of error reports.
14) The System shall provide facilities that will enable the performance of individual
services and circuits to be monitored.
15) Customized reports based on service, link/circuit, region, technology, vendor etc.
should be possible.

Section 2 Aug’17 Page 19 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

16) If User selects any OEM, no. of erroring ports should be displayed. On selecting the
port, PM data should be displayed and if required may be compared with previous
day.
17) Comparing of PM data of ports/service/circuits etc. should be possible in the same
window.
18) Raw performance data (as collected from network elements) shall be stored online for
a programmable time as per Annexure from the date of collection.
19) In the future, the System may be required to pass performance data periodically to
external data mining/warehousing applications. Bidder should describe the facilities
that are available to export performance data to other applications.
20) System shall provide a reporting capability that will enable Employer to create
comprehensive performance reports from both a network and a service viewpoint,
both as an aid to seeing failure trends, but also as an aid to network capacity planning.
21) The System shall enable performance reports to be created in hard-copy form, or
viewed via a web-browser interface. A suitable browser “plug-in‟ shall be provided to
enable browser-based viewing of performance graphs.
22) The System should enable inexperienced users to access pre-defined performance
reports, with more experienced users able to derive new reports based on existing
predefined reports.
23) The System should enable suitably trained Operations personnel to define new reports
and save the report definitions for other users to access.
24) PMS should be integrated with various modules such as IMS, Discovery, FMS, RCA,
etc.
25) Performance management (PM) operations such as - enable PM, disable PM, set
TCA, retrieve PM enabled entity, get PM reports - historic/current needs to be
supported by the tool to perform PM operations on the network via EMS/NMS/NEs
interfaces of various vendors. PM tool own operations shall include PM report
generations - service/network, database management functions - archive/restore, user
management.
26) PM tool shall support GUI based reporting using Web Interface. The reporting
capability shall be less than 10 sec processing time for every 1000 rows of data
fetched for any type of report with 100 concurrent users accessing the PM tool. Web
Interface shall support all PM operations directed towards EMS/NMS/NEs and tool
own operations beside PM reporting. Reporting engine is key element of the PM tool
where user needs periodic/scheduled and on-demand reports.
27) The PM tool shall be highly scalable and reliable for its database performance, GUI
performance, PM operations to EMS/NMS/NEs and scheduled reporting. Multiple
operations shall be supported concurrently.
28) The tool shall support the Offline and Online mode of operations. The online means it
is connected to EMS/NMS/NE systems of various vendors. Offline means it is
working on its own database copy. This will allow performance management statistics
can be generated offline when needed and online version is used when database
synchronization is required between PM tool and EMS/NMS/NE systems.

Section 2 Aug’17 Page 20 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

29) Tool shall have built-in intelligence of service/ circuit end to end connection detail i.e.
Port, NE ID along with path detail. The details shall be available by integrating with
Inventory System
30) Tool shall provide the ability to enable / disable performance monitoring on a per
Port, Card, NE & services basis. It shall also provide the ability to enable/disable
monitoring on a bulk basis.
31) Tool shall have not any limitation on TPs (Terminating Points) for enabling of PM for
15min/24Hrs counters.
32) Tool shall provide a facility of real time data extraction from NMS/EMS/NEs/objects.
33) Tool shall report the events where immediate action is required, based on user defined
threshold, on a real time basis
34) Tool shall facilitate history PM report extraction, summarized by time –Hour, Day,
Week, Month, Quarter, Year and by Property- service, circuit, location, Node etc.
35) Tool shall have capability of exporting report in Excel in user defined tabular format
& same shall be displayed graphically.
36) Tool shall act as a Unified source of information for all performance related queries
by the users. It shall support comprehensive set of performance reports for
Multivendor equipment on one single platform at all layers viz. MS/RS/HO path/LO
path/Ethernet etc.
37) Tool shall have capability to retrieve and report performance-monitoring data both on
request and as per schedule.
38) Tool shall provide PM Report with Zero suppression, removing all the rows with
complete zeros (rows with no data) so as to effectively present only non-zero rows.
39) Tool shall provide option to integrate with Trouble Ticketing System and Power
Level/Current parameter of SFP shall be reported to Ticketing System, before and
after restoration of Cable Cut, Partial cut or any failures.
40) Tool shall provide consolidated report of span loss for each section as compared to
the designed parameters & reporting deviations, if any. It should also keep record of
all old span loss (section wise) data in online/archive form.
41) Tool shall provide Proactive Error Reporting/Trending for comparison of the vendor
provided threshold value and the actual FEC error values observed on the network.
42) Tool shall be capable of providing Report for all the ports in the network
generating/detecting errors as per defined PM parameters.
43) Tool shall provide analysis report of repeat cases (ports/services) on a user defined
interval
44) Tool shall be capable of providing report for trend analysis of performance on
individual service/ circuit/ port.
45) Tool shall have capability of service degradation correlation with the anomalies
detected/reported at higher network level carrying the service. Tool shall also have
capability of user defined correlation rules.

Section 2 Aug’17 Page 21 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

46) Tool shall provide Service/Circuit Level Fault Analysis Report to identify the root
cause of faults/errors occurring on a particular Circuit/Service id.
47) Tool shall be capable of providing end to end service performance monitoring reports
for individual circuit/service along with associated bandwidth, end points, node name
etc.
48) Tool shall provide compute the Service Availability based on the occurrence of the
UAS for the PTP/CTPs associated with the service monitored for PM. The service
monitored for PM shall be considered down (Not available) for the duration of UAS
observed in the PMS.
49) The performance monitoring system can be started/stopped ON Demand basis. There
should be an option to keep default performance monitoring ON or OFF.
50) Tool shall have ability to enable users to do audits by generating periodic reports on
user settable specific parameters such as group of NE`s, circuits, services, ports, sites,
operations regions and others.
51) Tool shall enable limitation to access performance reports, based on the user rights.
52) The system should be able to dump Performance data to an external system for
external analysis purpose. User should be able to specify the period of the data to be
dumped for a specific parameter for complete data as per industry best practices.

53) The system should be able to generate reports for all performances in terms of
availability of NE/link/channel/port/NMS/Server/Application/complete system
delivered on all parameters.

2.5 Common Functional Requirements of U-NMS

2.5.1 Unified U-NMS Console (Common Reporting & Dash boarding System)

2.5.1.1 Generic

1) Unified U-NMS Console shall be single presentation layer across fulfilment and
assurance stack. All applications such as Order & Inventory/Discovery Management,
Configuration Management, Fault Management, Performance Management, Trouble
Ticketing, SLA Management, Reporting and Dashboards etc. should be seamlessly
interconnected and available in single window, single URL with single user
authentication.

2) Other than Unified Console, users will not refer to any other application window for
any assurance and fulfillment, reports and dashboards or any other application.

3) Unified console should support single window for Alarm Management, Root Cause
analysis, Service Impact analysis, Auto and Manual Ticket creation, Ticket update,
ticket resolution, SLA calculation and escalation, Inventory/Discovery view and

Section 2 Aug’17 Page 22 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

update, Order Management, Performance Reports, report creation and execution,

dashboard creation, update, automatic refreshing etc.

4) The Unified console User Interface should be built on latest technology /version as on
date of bid opening and should be rich in graphics and flexible for quick aesthetic
changes.

2.5.1.2 User Management

1) Access of different U-NMS applications has to be governed by user privileges in

respective console/application and user shall only be able to access the applications he
is authorized to access, along with defined role in the application.

2) Administrator should be able to create, delete and modify users and their privileges.

2.5.1.3 Integrations
1) The Unified Console should be able to integrate on standard protocols/APIs with
multi party U-NMS/other CC and related systems for common presentation layer.
2) Console should have built in plug-ins for quick and easy integration with 3 rd party
databases, applications, dashboards (View import).

2.5.1.4 U-NMS Console on Mobile/Handheld

1) It is required that centralized U-NMS system should be fully compatible with different
types of mobile/handheld/tablet devices offering functionalities of Dashboard,
Reports, Tickets, and Alarms.

2) The mobile/handheld views should be fully customizable to meet specific end user
requirements as finalized during detailed engineering.

3) All the functionalities of U-NMS console should be seamlessly available on smart

mobile phone with Android, iOS and Windows platform, without any additional
software or hardware on server side.

4) The users interface for mobile devices has to be pre designed with proven deployment
references in the similar environment.

5) Sufficient control over user / device specific access (like MAC /IP range based access
etc.) of console on mobile application.

6) U-NMS applications should having a separate tabs in mobile view of U-NMS

Console, and all functionalities of each application should be available within mobile
view also.

7) U-NMS should support PUSH notification for the alerts as desired by Employer.

2.5.1.5 Dashboards

Section 2 Aug’17 Page 23 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

1) Dashboard shall be integrated with all applications and shall be extendable to systems
such as Trouble Ticketing, Service Provisioning, Service Activation, Inventory
System etc. as required.

2) Dashboards shall automatically update at least once every 5 minutes and customizable
as per needs.

3) Dashboards shall be drilled down to specific network and service component.

4) Allows modifying and creating new views in a few clicks with the View Designer and
make changes available dynamically across the production environment.

2.5.1.6 Reporting

Reporting system should be capable of producing following reports in mutually

agreed formats such as Excel/Word/XML/Pdf etc.:

1) Real time inventory and bandwidth utilization reports (Vendor wise, Node wise,
Section wise, Service wise, Ring wise, Region wise, Technology wise and for
complete network).

2) Network MTTR/Fault Reports: Yearly, Quarterly, Monthly, Weekly, Daily(Vendor

wise, Node wise, Section wise, Link wise, Service wise, Ring wise, Region wise,
Technology wise and for complete network).

3) MTTR violation Reports.

4) Circuit SLA Reports: Yearly, Quarterly, Monthly, Weekly, Daily.

5) Service & link/circuit wise SLA Violation Report: Yearly, Quarterly, Monthly,
Weekly, and Daily.
6) Service & link/circuit wise Performance Reports.

7) Percentage, Chart and Graph Options for all Reports.

8) Management Information System (MIS) Reports on Capacity Utilization, Service

Quality etc.

9) Adequate security of the extensions (as mentioned above) through internet shall be
ensured.

10) The reports should be extractable in CSV, Excel & PDF form or any other mutually
agreed format.

11) Reports shall be made available in the desired format on the website designed for
proposed U-NMS

Section 2 Aug’17 Page 24 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

2.5.1.7 Fault Analytics and Statistics

Fault Analytics and Statistics provide an existing set of KPIs based on collected and
archived alarm information.

The common U-NMS console should also offer statistical analysis of real-time and
historical data such as alarms, trouble tickets etc. for the purpose of trend, seasonality
and CC surveillance efficiency.

The system must offer set of inbuilt statistics such as:

1) Network Health Dashboards

i. Number of alarms
ii. Number of alarm occurrences
iii. Number of Known Managed Objects
iv. Cumulative Alarms In Fault Duration
v. Distribution of alarms per Optical Carrier (OC) and per domain
vi. Top 10 Failed or Problematic Equipment Classes
vii. Top 10 Failed or Problematic Equipment Parent Entities
viii. Distribution of Affected Objects (AOs) per severity, per alarm type
viii. Top 20 probable causes
ix. Performance Comparison make wise (Tejas/ECI/Fibcom etc.)
x. Comparative State wise availability
xi. Comparative AMC performance vendor wise

2) Network Management Health Dashboards

i. Average Event/Alarm Collection Duration
ii. Average Event/Alarm Acknowledgement Duration
iii. Average Event/Alarm Close Duration
iv. Number of escalated alarms.
v. Top 10 Equipment Classes, in terms of the average and cumulative In
Management Duration
vi. Alarm Characteristics Distribution
vii. Trending and deviation
viii. Vulnerable area identification

3) Fault Management effectiveness

i. Alarm reduction percentage (w.r.t previous three months record)
ii. Automatic TT creation percentage
iii. The percentage of raw network events filtered out
iv. Percentage of post filtered events reduced by the similarity function
v. Percentage of post filtered network events, reduced by the similarity function,
correlated by the Root Cause Analysis function

Section 2 Aug’17 Page 25 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

4) Service satisfaction ( for all types of services, eg. E1, Eth, 64Kbps, VLAN, VSAT, etc.)
i. Mean-Time-To-Resolve Service Impacting Problems
ii. Mean-Time-To-Resolve Non- Service Impacting Problems

5) Operations responsiveness
i. Mean-Time-To-Create a ticket
ii. Percentage of problems resolved by due date
iii. Mean Service Problem Resolution Time
iv. Mean-Time-To-Resolve Service problems
v. Mean-Time-To-Resolve Network Problems

6) CC staff effectiveness
i. CC Full Time Equivalent (FTE) Efficiency
ii. Percentage of problems by cause type
iii. Percentage of maintenance time used for repair
iv. Percentage of escalated alarms

2.5.2 Trouble Ticketing & Web Portal System:

The regional and state CCs shall operate, monitor & manage their respective
Communication Network.

2.5.2.1 Trouble Ticketing System

1) Effective CC operations shall be established based on the IT Infrastructure Library

(ITIL) v3 and Industry best practices.

2) The following are the processes that will be tracked part of the trouble ticketing
services in this section:
i. Incident Management (Service Monitoring and User Complaint)
ii. Complaint Management
iii. Problem Management
iv. Change Management
v. Knowledge Management
vi. Release Management

3) Alarm management Tool will continuously monitor the Network for Events. Filtered
critical event shall be reported as a ticket to CC who shall acknowledge the same for
resolution.

4) Configurable rules like routing and auto assigning will be supported by the Ticketing
system.

5) The System shall notify the network alarm to create a Network or Event Trouble
Ticket (TT) automatically. Network Alarms shall be correlated and prioritized with

Section 2 Aug’17 Page 26 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

severity levels to create or update a TT. TT shall be notified to the CC who shall
accept it to service. Automatic Event TT creation shall import the properties of the
alarm such as type, cause, network, network resource, source (managed object where
the Event/Alarm occurred).

6) The TT should provide the ability to define priority, severity and impact for the
tickets.

7) The Trouble Ticketing System shall be a web based ITIL (IT Infrastructure Library)
certified system with minimum five analyst to handle incident management and
change management.

8) The proposed trouble ticketing system must have a valid ITIL v3 certificate for above
functions.

9) The system shall create an Incident ticket due to the service/circuit outage or
degradation (Incident ticket shall be marked Service wise). SMS alert facility for
service link down shall be deployed.

10) The system shall update the incident ticket upon more alarms on the same service.
Service level RCA shall be applied prior to ticket creation to avoid flooding of tickets
and thereby differentiate & identify multiple incidents appropriately.

11) Ticketing system shall support standard and custom reports of tickets, based on SLA,
Ticket statistics and ticket execution for different ticketing queue.

12) TT escalation should be supported for SLA “about to be breached” and “SLA
breached” cases for all severity and all high and critical tickets.

13) Ticketing system shall show ticketing analytics that will result SLA and severity
based ticket resolution analytics report.

14) Format of Trouble Tickets (TT) shall be configurable in a flexible way. Several
formats of TT should be usable in parallel.

15) TT shall be generated in one of the following ways:

i. Automatically by Resource Trouble Management based on an alarm in the
network
ii. Automatically based on predefined schedules for planned maintenance activities
iii. Manually by Users of the CC and authorized personnel.

20) It shall be possible to configure filters that prevent the automatic creation of TT.

21) Every TT must have an owner. Ownership of a TT will not change during its lifetime
unless ownership will be manually assigned by authorized personal. TT owners shall
be role or function based.

22) Owners (roles, functions) must be linked to users (individuals).

Section 2 Aug’17 Page 27 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

23) The solution shall manage the automatic hand over of TT from one user to another
(e.g. in case of shift changes).

24) The solution shall provide freely configurable roles. The supplier shall specify the
default roles supported by the system.

25) The System shall support manual and automatic escalation within set levels and
notification of trouble tickets both internally and externally (e.g. to vendors and other
carriers) based on:

i. TT elapsed open time

ii. TT remaining open time
iii. Resolution status
iv. SLA thresholds
v. Others

26) The escalation process must be user configurable.

27) The system shall provide views to tickets already existing for the service associated
with the user and thereby avoid duplication of incident tickets.

28) The system shall allow modification of ticket on selected parameters.

29) Inputs for trouble ticket shall be

a) Type of Failure:
b) Traffic Impact: Traffic affecting, Non-Traffic affecting
c) Severity: S-1 till S4 (Minor, Major and Critical)
d) Suspected Problem:
e) Affected Traffic:
f) Brief Fault Description: User will describe the fault (Text Box)
g) Documents: User can attach required Files
h) Submit:
i) Vendor Ticket Number:
j) Date:
k) Time:
l) Trouble Ticket Submitted By:

30) CC will close the trouble ticket after resolution & provide “Reason for Outage” RFO
in case of service outages. Provision shall be there to rate individuals based on AMC
performance.

31) The system shall provide users acting on a TT (auto & manual) to annotate a message
for the same. User with authorized privileges shall only be able to act on a TT.

Section 2 Aug’17 Page 28 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

32) The system shall allow authorized users to resolve the TT. Operator shall provide the
resolution comments while resolving the TT. TT shall be either Cleared or Cancelled while
resolving the ticket. All resolved TTs shall be in CLEARED state. On receiving an
automatic network alarm clearance, the alarm shall be correlated to update the TT that was
created. On subsequent verification of the alarm the TT shall be updated as CLEARED.

33) The system shall allow authorized users to choose multiple TT to resolve the ticket
with the same resolution. (e.g. Tickets that are linked)

34) The system shall provide option to close or re-open the cleared ticket on user
confirmation.

35) The system shall record all tickets OPEN/CLEAR/CLOSED and other WORKLOG
activities such as acknowledgement etc. as TT history for Service Level/KPI computations
and past data analysis. TAT (Turnaround Time) shall be calculated from the time of TT
creation to its resolution.

36) Concurrent ticket creation shall also be supported for simultaneous troubleshooting.
Parent / Child ticket approach shall be allowed to support the same. Until all child tickets
are closed/cancelled, parent ticket shall not be allowed to closed

37) The system shall track the ticket status based on a unique TT id.
38) The system shall maintain the Known Error Database (KEDB) updated by authorized
operators for tickets resolved with new design/solution. KEDB allows operators to look up
the past resolution steps/solution design to resolve and fix the issue tickets.

39) KEDB shall have creation and latest update/lookup dates. The system shall update the
KEDB upon resolution of the problem with root cause and resolution steps taken.

40) The system shall create problem tickets if the incident ticket does not resolve the root
cause of the outage or degradation. Incident may have been resolved through an
intermediate or workaround solution but the problem ticket shall be maintained as a new
ticket and tracked for permanent resolution and avoid the reoccurring of the incident.

41) TT logs shall be periodically purged from the database. (TT shall be purged on a
yearly basis) from online system to Archive and to be kept for a longer duration at least for
3 years.

42) The system shall provide Web based tabular views for the active tickets and past TT
history (also includes Network / Service Alarm details part of TT information).

43) The system shall provide a web based interface for users to create/update/close the
tickets. The ticket should also be viewed/create/update from mobile App. PUSH
notification should also be issued to respective maintenance engineer for rectification.

44) The system shall allow user to configure TT views based on user define filter criteria.

45) The system shall provide filtering, sorting and search utility to locate specific TT in
the view pages.

Section 2 Aug’17 Page 29 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

46) The system shall provide views for the KEDB and Problem tickets maintained in the
system with filtering, sorting and key word search utility.
47) The system shall provide summary counter view across all events/incident/problem
tickets against severities. Requirement of summary counter view is to have KPI's to be
reflected on dashboard/ console reflecting the summary in terms of count of open Priority
1, Priority 2 tickets and so on and in progress Priority 1, Priority 2 tickets and so on.

48) The system shall provide ticket views/operations that shall correlate the tickets that are
linked.

49) The system shall provide users to export the TT data to XLS or PDF and any other
required format.

50) Message system broadcast - Email communication and Message Board on the Portal
part of trouble ticket updates shall be supported

51) The system Email System shall be linked with TT functions for auto or manual
notifications.

52) The system shall provide separate view or color coded indicators to track a ticket that
has violated the KPI for TAT on ticket resolution.

53) The email and SMS notifications triggered from the ticketing system should reach the
Users as per escalation matrix within less than 60 seconds.

54) Total time for Ticket creation after submission should be less than 10 seconds.

55) Average report generation time should be less than 30 seconds.

56) For qualified search criteria, search results should be fetched within stipulated time of
less than 20 seconds for each 100 results.

2.5.2.2 Web portal system:

POWERGRID intends to provide a web portal for its Users with proper security in
place to monitor status of their services and availability parameters. User should also
be able to raise ticket for issues in their services/circuits and can get update on their
tickets. SMS & Email alters shall also be provided to the User for update of ticket
status and on resolution of their tickets. Contractor shall supply, install, commission,
Integrate & test required solution including application Software, OS & hardware for
implementation of the same under the proposed solution. The system shall have at
least following capabilities:

1) It should be able to handle 200 concurrent users.

2) The user shall be allowed to login only after authentication of credentials provided
to him.

Section 2 Aug’17 Page 30 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

3) The solution shall be integrated with relevant UNMS modules, AAA/radius

server, Trouble ticketing System, Service Assurance solution etc. for publishing
routine availability & performance report of the communication system to be
finalized during detailed engineering.

4) The solution shall be housed in appropriate zone within the CC to ensure all
security aspects including data & application security as per DOT guideline.

5) All reports as desired by Employer should be available on Web portal.

6) Domain to be procured by the Employer and integrated with the U-NMS system,
however, the Web portal should be designed and maintained by the Contractor.

2.6 Generic Integration Requirements:

2.6.1 Integration Points: The Bidder must ensure that UNMS application supports
standard internationally acceptable formats, protocols & open standard interface for
ensuring the integration with other Employer’s systems such as GIS, ERP & SD-
WAN (if required by Employer) at a later date but before the expiry of UNMS
contract.

2.6.2 Future Readiness

1) UNMS will be able to integrate and assure a range of Network Function

Virtualization (NFV) solutions from a range of vendors
2) Alarm, Auto TT and provide performance data on virtualized network functions
as currently done for traditional physical network elements

3) Integrate with NFV solution to automatically manage the NFV platform to add /
remove capacity dynamically

4) Out of box integration with NFV Orchestrators

5) Out of box capability to correlate hardware and software alarms to root cause i.e.
SD card/SSD/ HDD failures.

6) Automate resolution of Virtual Network Functional issues using automated

workflows.

7) Out of the box support for NFV Service elasticity scale-in/scale-out.

2.6.3 User Management

The User Management System shall provide features primarily that consist of the
following services:
1) Authentication
2) Authorization
3) Administration

Section 2 Aug’17 Page 31 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

4) Audit
2.6.3.1 User Authentication & Authorization

i. The System shall provide an option for the newly logged in user to change his
password and the user shall be forced to change the password first time. It shall
also provide option to authenticated user to change password.

ii. Passwords shall be encrypted and stored in database and will not be stored in
clear text.

iii. Strong Password techniques shall be employed as powerful password login

mechanism.

iv. The System shall provide User account expiry date. It shall be set/modified to
the required number of days, once the number of days set for the user account
exceeds, the user will not be allowed to log in to system as the user status will
be changed as "userExpired". Configuration for the userExpiry shall be enabled
or disabled accordingly.

v. The System shall allow User login to be enabled /disabled.

vi. The System shall provide Password expiry date and can also be set/modified as
number of days after which the user status will be changed as
"PasswordExpired". By default the password expiry is enabled and set for 90
days. Thus when the user tries to log in, then the message "Password Expired"
will be displayed and user is allowed to configure a new password.

vii. The System shall provide a mechanism in which continuously failed login
attempts will be detected and controlled. Number of failed login attempts shall
be configurable and will default to 5. After 5 failed attempts, the User account
shall be locked. The process for unlocking shall be finalized during detailed
engineering. The failure attempts and unlocking of User account shall be
logged in the user audit records.

viii. The System Admin with sufficient privileges shall only restore the user access
further to failed attempts, and shall not automatically allow access.

ix. The System Authorization service shall control the access limits of the
respective logged in users. Authorization shall validate an authenticated user's
request and grant/deny him permission to perform a requested operation.

x. The System Authorization level shall be extensible towards a fine gained

security wherein the users shall perform the operations based on the data like
location or department.

xi. The existing Communication nodes & EMS/NMS shall be integrated with
AAA/RADIUS server being supplied under this contract.

xii. The System shall support integration with external user authentication systems
with AAA, LDAP, Active Directory or Radius.

Section 2 Aug’17 Page 32 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

xiii. The contractor may require to integrate with existing LDAP/AAA of Employer
within its network else may provide separate servers to install these (AAA &
LDAP) functionalities.

2.6.3.2 User Administration

i. The System shall provide a Super User who shall administrate the system User
Groups and its privileges. Super User shall be the system Security
Administrator (System Admin).

ii. The system shall have role based access.

iii. The System Admin shall create User Groups as per the profiles with pre-
defined privileges.

iv. The System Admin shall be able to administer user / password of users across
all groups and privileges across all user groups.
v. The System Admin shall have the rights to create users and administer
username/password of User Group / Users. Users created shall derive its
default privileges as per the User Group created by System Admin.

vi. The System shall support users belonging to multiple groups.

vii. The System shall be customizable towards multitenant architecture that allows
distributing the secured user administration to select group(s) to administer
users within their organization. The System shall support auto generation of
password.

viii. The System shall be customizable towards Two Factor Authentication with
OTP (One Time Password) support.

ix. The System shall send mail notification on key admin transactions like account
creation along with first time password

2.6.3.3 User Audit

i. The System shall provide facility to audit the authentication and authorization
related information and stored in.

ii. Auditing shall monitor the selected operations performed by the user.

iii. The User Audit trails shall be logged and viewed by authorized security admin,
it includes views of the current users logged in and past users logged in/out and
the operations performed.

iv. All authorized operations that are performed are audited and logged in the audit
tables.

v. Any erroneous and suspicious activities like login attempt failures shall be
logged and viewed part of audit.

Section 2 Aug’17 Page 33 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

vi. The system shall provide audit reports on the performed operations with it user
information and time stamps.

2.6.4 System Security, Access Control Management System & Audit (CERT-In or other
guideline as applicable)

1) The process of networks Audit and certification must (performed by Third

Party/Parties) include following activities:
i. Network Architecture Security Review
ii. Review/ update of security policies and processes
iii. Host security configuration
review
iv. Network forensics
v. Network Hardening
vi. Network penetration test
vii. Risk assessment
viii. Actions to fix found problems
ix. Any other required audit as per DoT guidelines, which has not been
specifically mentioned in this document

2) The proposed solution should provide secure administrator control, monitor and
record privileged sessions including VNC, RDP, SSH, Telnet, HTTP/HTTPS, AS400
and Mainframe.

3) The proposed solution should have the ability to support load balancing and
activeactive High Availability (HA) out-of the-box to cater for current requirements
and future expansion.

4) The proposed solution should be able to prevent leap frog attempts, session
continuous recording & ideal session time out.

5) The proposed solution should allow defining roles or groups for user management.
Roles should be customizable and pre-defined in system.

6) The proposed solution should be able to support text searching for GUI session logs
and records.

7) The proposed solution should provide the capability to manage application credential
together with access control, password management all within a hardened platform.
The product's appliance supports all features: Password Vault, Access Management,
Session Recording, Application to Application (allows dynamic password access from
applications), etc.

8) Solution should have successful reference able implementations.

9) The product's appliance is highly scalable, supporting (for example) 3000 concurrent
SSH sessions, 1500 concurrent RDP sessions, or 2000 concurrent connections of
mixed SSH and RDP regardless of which form factor (physical or virtual) is used. The
product adds scale by simply adding new appliance to a cluster.

Section 2 Aug’17 Page 34 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

10) The product should work with industry standard third-party software or hardware such
as Operating Systems, Databases, High Availability, Load Balancers, etc.

11) Solution should provide real time alert for command line and GUI on back listed GUI
actions or commands on target end points such as applications, server & command
line. It should detect when violations of the rules occur and can automate action as a
result including warning the user, logging off the session, as well as alerting when the
event occurs.

12) The audit shall be completed within end of every year during Implementation,
warranty & AMC period. The report shall contains at least following:
i. Audit Report – Executive Summary: The vendor should submit a report to
summarize the Scope, Approach, Findings and recommendations, in a manner
suitable for senior management. Selected Bidder will also detail the positive
findings (No Gap found) for various tests conducted.

ii. Audit Report – Core Findings along with Risk Analysis: The agency/ bidder
should submit a report bringing out the core findings of the audit/ testing
conducted for network devices, security devices, servers etc.

iii. Audit Report – Detailed Findings/Checklists: The detailed findings of the

audit would be brought out in this report which will cover in details all
aspects viz. identification of vulnerabilities/ threats in the systems (specific to
equipment/ resources – indicating name and IP address), identifications of
threat sources, identification of Risk, Identification of inherent weaknesses,
Servers/Resources affected with IP Addresses etc. Report should classify the
observations into Critical /Non Critical category and asses the category of
Risk
Implication as VERY HIGH/HIGH/ MEDIUM/ LOW RISK based on the
impact. The various checklist formats, designed and used for conducting the
audit activity as per the scope, should also be included in the report separately
for Servers (different for different OS), Network equipment, Switches,
security equipment etc. Snap shots/ Output of any script /documents etc. from
where the finding/ observations have been made shall be attached.

iv. Audit Report - In Depth Analysis of findings /Corrective Measures &

Recommendations along with Risk Analysis: The findings of the entire audit
Process should be critically analyzed and controls should be suggested as
corrective /preventive measures for strengthening / safeguarding the Telecom
assets of POWERGRID against existing and future threats in the short /long
term. Report should contain suggestions/ recommendations for improvement
in the systems wherever required. If recommendations for Risk Mitigation/
Removal could not be implemented as suggested, alternate solutions shall be
provided. Also, if the formal procedures are not in place for any activity,
evaluate the process & the associated risks and give recommendations for
improvement as per the best practices.

Section 2 Aug’17 Page 35 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

2.7 Web User Management

i. The System shall provide authentication of user credential over secured

encrypted transmission over HTTPS

ii. The contractor shall supply required SSL certificates etc. for entire period of
contract i.e. from implementation phase till end of AMC (1+6 years).

iii. The authentication verification shall happen on server side.

iv. The System shall support User Idle Time session time out for the web session if
it exceeds a user defined (configurable) limit.
v. The System shall provide logout that will close the session and close all cookies
on the browser.

vi. The contractor shall be responsible for secure access of web portal from internet
without any security threat and provide necessary infrastructure to ensure the
same. If required separate hardware may be provided for providing web access
from internet and restrict the data exchange from external world.

2.8 Pre- Assessment of NMS/EMS Upgrades:

The system should be designed and implemented in such a way that the testing &
development system for UNMS should have capability to assess & report the impact of
base NMS-EMS software upgrade on integration with UNMS for any of the underlying
Communication networks. The NMS-EMS upgrade shall be reviewed, tested & cleared
by UNMS contractor before it is actually implemented in the underlying NMS/EMS
system.

2.9 SLA Management

The design shall be according to industry best practices and follow proper disaster
recovery procedures and emergency response procedures in case of a disaster at the
primary site. The Contractor has to provide 99.9 % SLA on the operations of the
entire CC. Following SLA functionalities must be supported in SLA management
system.

2.9.1 SLA Monitoring

i. Solution should calculate SLAs values, compliance and service impact in near
real time

ii. Solution should offer collection framework for ease integration with Trouble
Ticket, Performance Management or other types of systems

iii. Solution should support update or exclusion of source raw data, collect these
updates, and recalculate automatically SLA Values and statuses

iv. Solution should offer User Interface to monitor SLA compliance and service
Impact in real time

Section 2 Aug’17 Page 36 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

v. Solution should provide a User Interface to enter exclusions on SLAs

vii. Solution should provide a "Exclusion" collection framework for integration

with external exclusion management system

viii. Solution should provide predefined "actions" to be triggered on threshold

crossing or compliance change

ix. Solution should propose an Action Executor Framework to create customized

action executor.
x. Solution should provide a way to inset/update and exclude raw data from User
Interface.

2.9.2 SLA Reporting

1) Solution should provide a library of predefined reports

2) Solution should provide user interface to allow creation of customized reports

on SLA Data

3) Solution should allow the Scheduling of report production

4) Solution should provide reports in different formats (pdf, csv...)

2.9.3 SLA Portal

i. Solution should provide portlets to integrate in any compliant portal to allow

SLA Display for end users.
ii. Solution should provide API to retrieve SLA Information

iii. Further details with respect to the specific functional requirements stated in the
subsequent section. Basic features of SLA management shall be supplied on per
service per circuit wise:
a. Circuit availability / Uptime
b. Circuit / Link / Service Latency
c. QoS related parameters like jitter , wander , Packet loss
d. IP based Traffic monitoring
e. Bandwidth/Network Usage etc.

2.10 IT Setup:
An IT infrastructure is envisaged at each UNMS server location to enable publishing
various applications such as Web portal System, Trouble ticketing etc. to be used by
while on site. Other applications like DNS, Email servers etc. are also to be placed
within this setup. Different zones shall be created for hosting different applications
within this setup.

Section 2 Aug’17 Page 37 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

This setup shall be designed such that redundancy & replication of all applications
shall be maintained with proper backup. The following components are to be included
in this setup.

2.10.1 Reverse proxy:

To publish portal and applications on internet using reverse proxy server is to be
supplied. The proposed reverse proxy server should have following minimum
functionalities:
1) Throughput - 5Gbps
2) Ports required – 2x10GE + 4x1GE
3) WAF (Web Application Firewall) capability
4) SSL Encryption with SSL acceleration hardware

2.10.2 SLB (Server Load Balancer): SLB is required for managing redundancy between
applications & database hosted at main CC & back-up CC. All the applications
offered under this project shall use this facility subject to the application & database
internal architecture failover design. The same shall be finalized during detailed
engineering. Contractor shall size the SLB such that it should be able to cater the
requirement of redundancy for all applications & Database supplied under this project.

Server Load balancers are not mandatory. Bidder can offer a Solution Architecture that
meets the end objectives without Load Balancers. However, if the bidder proposes a
Server load balancer it should meet following minimum specifications.
1) The port density shall be as per implementation design finalized during detailed
engineering & project execution considering expandability.
2) Following Server Load Balancing Topologies should be supported:
i. Virtual Matrix Architecture
ii.Client Network Address Translation (Proxy IP)
iii. Mapping Ports
iv. Direct Server Return
v. One Arm Topology Application
vi. Direct Access Mode
vii. Assigning Multiple IP Addresses
viii. Immediate and Delayed Binding ix. IP Address Ranges Using imask

The Server Load Balancer (SLB) should support the below metrics:-
Minimum Misses, Hash, Persistent Hash, Tunable Hash, Weighted Hash, Least
Connections, Least Connections per service, Round-Robin, Response Time and
Bandwidth

2.11 Virtualization

Section 2 Aug’17 Page 38 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

Virtualization is not mandatory. Bidder can offer a Solution Architecture that meets
the end objectives without virtualization.
However, if the bidder proposes virtualization it should meet following minimum
specifications.
a) Solution should include bare metal hypervisor with functionality of High Availability,
Fault Tolerance, hot Add (CPU, Memory, Storage & Network), dynamic power
management, storage and network IO control, VM level encryption. 
b) Solution should include the ability to add CPU and memory to virtual machines
dynamically on the fly when needed, without disruption or downtime of working VMs
for both windows and Linux based VMs.
c) Solution should be able to identify, showcase, recommend and reclaim resources like
powered-off VMs, idle VMs, orphaned objects etc. from the virtualized environment.
d) Solution should show dashboards and generate or schedule reports on capacity
utilization, performance management and standard compliances.
e) Solution should be able to run scenarios to determine whether future workloads or
expansions can be accommodated on the running virtualized environment.
f) Solution should have an operations console that provides an easy way to perform
monitoring and logging of the virtualized environment in order to quickly identify the
root cause and troubleshoot issues.
g) Solution should have the capability to provision and migrate the workloads to more
than one public cloud without any rearchitecting of the application

2.12 Back-up & Restore Software

i. Backup Software shall be capable of supporting backup /restore from various

platforms.

ii. Ability to backup data from one server platform and restore it from another server
platform to eliminate dependence on a particular OS machine and for disaster
recovery purposes, as per software application / database. Software shall have full
command line support on above mention operating systems.

iii. The backup software shall be able to encrypt the backed up data using 128-bit /
256-bit AES encryption on the backup client and shall not demand for additional
license, any such license if needed shall be quoted for the total number of backup
clients asked for.

iv. Shall support wizard-driven configuration and modifications for backups and
devices.

v. The backup software shall support industry standard Common Device Interface
for advanced device reporting and handling.

Section 2 Aug’17 Page 39 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

vi. Shall have cross platform Domain Architecture for User management and shall
also have role based User management and access control for multitenant
environments.

vii. Shall support de-duplicated backup and recovery

viii. Shall support backups for clustered servers and shall have the ability to backup
data from clustered servers from the virtual client, backing up data only once
and giving consistent backup in case of failover of nodes.

ix. The backup software shall support backup and restore of NDMP data to media
server attached Storage.

x. Shall integrate with third party VTL which has data de-duplication capabilities.

xi. The backup software shall support for online backup for all the OS / Data
Bases supplied with out of box agents. Backup licenses shall be provided based
on database being used in the system.

xii. Must support Hardware and storage array based snapshot backup for off host
zero downtime and zero load on the primary backup client.

xiii. The backup software shall support data movement directly from the backup
client to the disk target without passing through the backup server.

2.13 Operating System (OS)

Operating system shall support latest version for Applications and Databases.
Desktops shall support Microsoft Windows for client applications. Servers shall be
Windows/Linux/Unix operating system based. All Operating System shall be supplied
with required licenses valid throughout project implementation, Warranty & AMC
period. Operating system in production environment shall have Premium support.

2.14 Antivirus Software

The antivirus software shall be enterprise class along with latest version of software.
The software should be upgradable to latest virus definitions on periodic basis. The
license should be considered for the contract lifetime.

Section 2 Aug’17 Page 40 of 41

 Power Grid Corporation of India Ltd.
U-NMS for ISTS & State Utility Communication Network
Volume II - Technical Specification for U-NMS

--- End of Vol II Section 2 ---

Section 2 Aug’17 Page 41 of 41