RFP Nms 070708

RFP for TX NMS
1 Introduction:
BHARAT SANCHAR NIGAM LIMITED intends to deploy an
Network Management System (NMS) for its Long Distance Transmission
Network. The scope of the NMS to be acquired through this RFP will
include main functional areas of FCAPS ,viz fault management
;configuration management ; performance management; service and
circuit monitoring and service-level management.
Additionally, facilities are required that will enable BSNL to
• monitor services and circuits end to end.

• Improving reliability of Network using traffic restoration features of
OXCs/DXCs
• Efficient and optimum utilization of Long Distance Network
resBSNL’sces.
• Enabling web based access to BSNL’s leased line customers to see
status of SLA commitments of their circuits transparently and
facilitating them dynamic bandwidth management.
• TX NMS will require to be interfaced with other Application software
running in BSNL for the purpose of facilitating
booking/commissioning/billing of circuits.
BSNL has fBSNL’s organizational units for Long Distance

Transmission Network maintenance viz Northern , Southern , Eastern
and Western Telecom Region with headquarter at Delhi , Chennai ,
Kolkata and Mumbai respectively. These units are mainly responsible for
inter LDCC and inter SDCC systems.
Telecom circles also maintain some intra SSA and intra SDCC
SDH /Radio Systems.
1.1 BSNL’s Current Infrastructure for Long Distance

Transmission Network.
BSNL owns and operates a multi-technology, multi-vendor

Transmission network infrastructure consisting of DWDM
Terminal/OADM/OLA , SDH rings , PDH OFC , PDH/STM-1 Digital
Microwave Systems and Satellite based IDR , VSAT Systems. . Major
Transmission Stations are co located with Level I TAXs ( 21 Nos.) .
SDH and PDH Systems deployed in access Network will also come
under the purview of proposed TX-NMS.
[RFP for Transmission NMS] Page 1 of 183

1.2 Future Plan
BSNL is proposing to induct following type of systems in it’s Long

Distance Network
• 10 G DWDM Systems. One Terminal or OADM at each SDCC(Short
distance charging center) .
• STM-16 MADMs or ADMs to create SDH rings on DWDM Network.
• ASON or G MPLS enabled Optical Cross Connects at each
LDCCs(Long distance charging center) Headquarter.
These equipment ( Total 1,00,000 NEs at present) will also need to

be monitored by proposed TX-NMS. Thus proposed TX NMS need to be
suitably dimensioned and scalable to accommodate all such future
Network Elements deployment ( Approximately 3,00,000 NEs).
1.3. Limitations of present Transmission Network
At present the BSNL’s Transmission Network comprises of

DWDM/SDH/PDH equipment from multiple vendors installed in the
Regions & territorial Circles. SDH Systems have three different
capacities namely STM-1,4,16 with associated EMSs. DWDM Systems
are of 2.5 G and 10 G type. Many rings are without EMS and managed
only with LCTs . Higher capacities viz. STM-64 have also being
inducted. Many rings run on the fibers and some are mounted on
DWDM links, which create virtual fibers. DWDM links and SDH rings are
from different vendors and have their own EMSs. These EMSs of SDH
systems and DWDM systems are not managed by any single NMS.
While traffic is built up over these systems , corresponding
management is not built up end to end. This creates independent
islands of management , lacking overall network management. Hence
there is need for a state of art good transmission Network
management system is obvious on a suitable platform.
All EMSs of SDH , DWDMs , DXC , Synchronization Network ,
DCME will have to be integrated with TX NMS. Same is to be done for
Microwave systems, VSAT hubs: MCPC, Ku Band, HVNET (wherever
manageability is feasible).
Many of SDH rings are not being managed by EMSs . They are
provided with Local Craft Terminal (LCT ) and do not have
NCT(Network Craft Terminal) or EMS at all. To impart necessary
manageability , they will have to be integrated with their EMSs through
DCN.

1.4 Inadequacies in available EMS from different
vendors
BSNL has variety of systems of different make in it’s network. There

is no strict compliance by vendors regarding full implementation of
FCAPS. Some only provide part of it leading to the following situations.
• EMSs fully compliant with TMF814 standard

• EMSs partially compliant with TMF814 and upgradeable
• EMSs non complaint with TMF814 and upgradeable to TMF814
• Non TMF Compliant and not upgradeable
EMS is a critical piece component in total management system.
Only EMS is exposed to complete management information content of
all NEs in its domain. The EMS is the sole mediator of this information
and the controlling of the NEs to Network Management Level.
Therefore, the EMS intimately should match to particular element(s)
NEs in the Network attached to it in order to enable and manage the
functions of the NEs.
Systems deployed before 2007 have EMSs which do not comply

with TMF 814 standard. Systems currently being deployed are TMF 814
compliant.
At present there are LCTs/NCTs/EMS with very limited

management functions. Distinctions amongst them are to be clearly
understood, as some EMSs though termed as EMS do not support
complete functionality as defined in TM forum standards, (Ref: TMF 814
standards and descriptions given al).
The gaps need to be identified and corrective actions taken wherever
feasible .
EMSs have evolved over a period of time and therefore all EMS
are not equal in their capability. BSNLs multivendor network is also
evolved over a period of time with each vendor giving its LCT/NCT/EMS
with varying capability and features.
1.5 End-to-end perspective, manageability, honoring

SLAs is almost impossible.
End to end bandwidth is built up on multiple SDH Rings from

Multi-vendors. End-to-end fault Management/Configuration is
impossible. In some cases end-to-end bandwidth also travels on
combination of PDH and SDH links.
Due to multi-vendor rings and also multi vendor Terminal
Multiplexers (TMs) connected to such rings , through their ADMs , it is
not possible to commission a bandwidth for eg. E1, E3 or STM-1 from a
single location and process in a timely manner . End to end
management involves manual activities which is cumbersome, and

time consuming . Meeting SLAs commitment and resolving SLA related
dispute impossible due to lack of authentic management related
information.
1.6 Manual diversion of Bandwidth in case of route

failures:
E1s, E3s, STM-1 or STM-16 streams are diverted manually by co-

ordination with multiple en route locations. As such there is no control
on outages .
1.7 Provisioning Deficiency: -
There is no computerized inventory of the bandwidth slots

Commissioned available/faulty in the Network. A humble beginning has
been made through a stand-alone Network Planner Software developed
by STR. This can only be an interim arrangement to a function of
Transmission NMS.
Details and scope of items mentioned above will be covered in the

following sections.
2 : Business Objectives And Approach
BSNL believes the business of providing communications services

will continue its rapid rate of change in the future, and the business
objectives that have been identified will allow BSNL to manage the
change and remain a dominant telecom player in India.
BSNL intends following major business goals to be achieved by

the TX NMS.
• Provide the point of integration across multi-vendor, multi
technology network equipment and element management systems.
• Provide an end-to-end view of services and service performance
(quality), and an end-to-end view of the bearer circuits that carry
services.
• Provide facility of end to end provisioning of bandwidth centrally.
• Enable fast fault resolution and reduced restoration times through
accurate fault localization and notifications to the appropriate repair
centers.
• Enable proactive maintenance and customer support through
detecting early signs of impending equipment failures and service
faults.
• Provide accurate, near-real-time service- and network-status
information.

• Provide information for long distance network
resBSNL’sce(bandwidth) availability.
• Provide relevant details to BSNL billing centers to facilitate
accounting and revenue generation.
• Automatically protect long distance traffic depending on priority.
• Provide information to other NMSs of BSNL services which uses Long
distance network for their operation and expansion.
• Be an aid to the automation of existing and future operational and
business processes.
• Be the key enabler for a centralized operations center.
• Provide self-management facilities.
Additionally, the vendor of the software product chosen as the basis

of the NMS, and the software itself, should have certain attributes:
1. The chosen software product should have a substantial track record

in complex operational environments similar to BSNL’s.
2. The chosen vendor should have a substantial track record, or have a
partner who has such a record, in providing system integration
services in complex environments similar to BSNL’s.
3. The chosen vendor should be capable of providing high level local
support.
The following sub-sections explore in more detail some of the issues

underlying these goals.
2.1 Unified View Of Networks And Services
BSNL’s networks are currently managed through a set of “silo”

operations. This is primarily due to the fact that each different
technology type/supplier combination is managed by an element
management system (EMS) that is specific to that combination.
BSNL sees one of the major benefits of the new TX NMS being its
ability to provide an integration point across the multiple types of EMSs
that are currently deployed, which will provide an overall view of the
network rather than the “blinkered” views that are currently available to
individual operation centers.
2.2 End-To-End View Of Networks And Services
The new TX NMS is expected to provide the ability to see an end-

to-end view of customers’ services, and of the bearer facilities that
carry those services. Currently, such a view is not available. The major
benefits of the end-to-end views are that they will enable BSNL to:
• More accurately and quickly localize faults.

• More accurately prioritize repair and restoration work.
• Conduct proactive fault management, anticipating faults before

they occur.
• Meet SLA commitment.
• Improve productivity by making officers and staff more
responsible.
2.3 The TX NMS as a unifying Force
It is BSNL’s intention to centralize the currently decentralized

network management functions in a TX NMS in New Delhi. The TX
NMS is intended to be the focal point of the NOC.
BSNL foresees that establishing the TX NMS will create synergies
between network management staff through better, more effective
communications.
2.4 Service-Level Guarantees
BSNL’s customers, particularly the larger ones, are increasingly

asking for service-level guarantees. Currently BSNL is not in a position
to offer service-level guarantees with any level of confidence because
there is no method of measuring service availability end-to-end.
The introduction of the performance and SLA management
capabilities of the TX NMS will enable BSNL to extend service level
guarantees to selected customers with confidence, and to measure
accurately actual performance against guarantees.
2.5 : The Scope Of The PROPOSED TX NMS Project
This section defines the scope of the TX NMS project to be

acquired as a result of this RFP.
Amongst other things, this section provides counts of the
equipment to be managed by the NMS. Tenderer should note that the
numbers given here are estimates for planning purposes. The number
of network elements in service fluctuates continually, and BSNL cannot
guarantee that the counts given here will apply at NMS implementation
time. No of elements to be managed will continue to grow . TX NMS
should be scalable enough to take care of proposed expansion plan.
3.1 Functionality To Be Provided:
Proposed TX NMS has to follow TMN Hierarchy .The TMN

architecture is a reference model for a hierarchical telecommunications
management approach. Its purpose is to partition the functional areas
of management into layers.
TMN calls for each layer to interface with adjacent layers
through an appropriate interface to provide communications

between applications, and as such more standard computing
technologies can be used. The TMN M.3010 document allows for
the use of multiple protocols. This means that open standards
such as SNMP and CORBA are consistent with the TMN
framework.
TMN model is simple but elegant and has been effectively used to
represent the complex relationships within network-management
architectures graphically. Originally based on common management
information service element (CMISE), the object-oriented technology
available at the time of inception in 1988, the model now demonstrates
its flexibility with the recent adoption of technologies such as common
object request broker architecture (CORBA), as we drive toward a more
generic data-processing type of computing. This evolution of CORBA
progressed in much the same way as SNMP led its generation of
protocol adoption.
Ideally EMSs should, by strict adherence with the TMN model,
communicate with their NEs by using the common management
information protocol (CMIP). This, however, takes no recognition of the
fact that most devices deployed in the BSNL use other protocols such
as TL1, SNMP, and a variety of proprietary mechanisms. An efficient
EMS communicates with its NE using whatever protocol is native to the
NE. The effective EMS will also communicate with other higher-level
management systems using protocols that are the most cost-effective
to implement. Therefore, the TMN layering is achieved by using
whatever protocols are appropriate
The TMN FCAPS Model of OSS Tasks.
In addition to the TMN–layering structure, the ITU–T also splits

the general-management functionality offered by systems into the five
key areas of fault, configuration, accounting, performance, and security
(FCAPS). This categorization is a functional one and does not describe
the business-related role of a management system within the
telecommunications network. The idea of FCAPS stems directly from the
ITU–T recommendations and describes the five different types of
information handled by management systems. Portions of each of the
FCAPS functionality will be performed at different layers of the TMN
architecture. As an example, fault management at the EML is detailed
logging of each discrete alarm or event
eatures Supported by FCAPS Components
3.2 : Core Network Equipment Types And EMSs To Be

Supported
The following table describes the Transmission network

equipments to be supported by the NMS, an equipment count for each

type and the EMS that is used to manage the equipment. The table
covers all DWDM And in the core as well as access networks.
STM-1 SDH EQUIPMENT
Vendor PO / DATE ADM TML REG NEs TOTAL

ITI 63/ 17.12.97 47 48 11 106
ITI 71/16.01.98 86 216 42 344
ITI 017/ 28.08.98 101 278 38 417
ITI 92/ 13.1.99 210 800 60 1070
ITI 12/10.6.99 117 428 0 545
ITI 5/ 3.8.2000 328 402 12 742
ITI 65/ 29.3.2001 155 190 12 357
ITI 16/ 12.9.01 280 420 26 726
ITI 17/ 12.9.01 165 252 16 433
ITI 20/ 12.9.01 39 140 0 179
ITI 34/ 23.11.01 102 84 0 186
ITI 30/ 24.9.02 432 136 8 576
ITI 12/ 4.8.04 1414 0 12 1426
ITI 18/ 7.12.04 735 0 9 744
ITI 19/ 30.01.06 784 0 0 784
ITI 13/ 18.9.2006 190 0 190
ITI 21/ 18.10.2006 7500 0 7500
FIBCOM 67/ 19.12.97 47 47 10 104
FIBCOM 11/ 10.6.99 237 848 80 1165
FIBCOM 66/ 29.3.2001 306 376 24 706
FIBCOM 18/ 12.9.01 256 390 9 655
FIBCOM 19/ 12.9.01 78 278 0 356
FIBCOM 32/ 8.10.01 202 248 6 456
FIBCOM 07/ 9.9.03 184 62 16 262
HFCL 13/ 10.6.99 118 422 31 571
HFCL 31/ 25.9.01 148 226 0 374
CG 10/ 10.6.99 117 420 17 554
SCL 10/ 20.10.03 108 26 2 136
SCL 06/ 5.9.05 568 0 0 568
SCL 25/ 22.11.06 6625 0 6625
SINCLAIR 06/ 20.10.03 56 14 1 71
Siemens 08/ 9.9.03 214 50 0 264
Siemens 01/ 27.4.05 2275 0 0 2275
Siemens 02/ 11.7.05 2275 0 6 2281
Siemens 11/ 13.12.05 2336 0 0 2336
Siemens 14/ 18.9.2006 444 0 444
Siemens 22/ 27.10.2006 4250 0 4250
Orion 24/7.11.06 6625 6625
Ordyn 28/ 11.12.07 336
Ordyn 29/ 11.12.07 539
TOTAL 40154 6801 448 48278
STM-4 SDH EQUIPMENT

ITI 64/ 17.12.97 79 9 25 113
ITI 74/27.1.98 55 59 61 175

ITI 1998 63 68 71 202
ITI 07/26.5.99 263 228 336 827
ITI 057/14.10.99 138 122 86 346
ITI 6/ 3.8.2000 298 50 29 377
ITI 63/ 28.3.2001 165 30 18 213
ITI 48/ 24.12.01 298 54 0 352
ITI 50/ 24.12.01 180 32 0 212
ITI 54/ 27.12.01 89 9 35 133
ITI 55/ 27.12.01 100 17 7 124
ITI 62/ 26.3.01 56 0 0 56
ITI 13/ 5.8.04 454 0 26 480
ITI 17/ 6.2.04 131 0 9 140
ITI 04/ 28.7.05 683 0 41 724
ITI 35/ 17.1.03 424 0 18 442
ITI 03/ 14.7.03 205 4 19 228
ITI 16/ 29.9.06 683 0 41 724
ITI 01/ 10.04.07 585 35 620
ALCATEL 059/ 14.10.99 133 118 41 292
BEL 056/ 14.10.99 135 120 102 357
FIBCOM 058/ 14.10.99 271 242 93 606
FIBCOM 64/ 28.3.2001 277 46 34 357
FIBCOM 49/ 24.12.01 349 62 7 418
FIBCOM 52/ 27.12.01 177 73 43 293
FIBCOM 53/ 27.12.01 153 0 12 165
FIBCOM 61/ 26.3.01 113 0 0 113
FIBCOM 02/ 14.7.03 406 0 28 434
PUNCOM 05/ 28.7.05 336 0 20 356
PUNCOM 10/ 14.9.06 336 0 20 356
Tejas 03/ 18.7.05 346 0 21 367
Tejas 9/ 14.9.06 346 0 21 367
HFCL 05/ 6.8.03 193 0 0 193
HFCL 04/ 6.8.03 180 0 0 180
TOTAL 8700 1343 1299 11342
STM-16 SDH EQUIPMENT

ITI 18/ 31.8.98 115 0 457 572
ITI 9/ 26.5.99 120 0 300 420
ITI 9/ 8.9.2000 78 0 0 78
ITI 71/ 4.4.01 50 0 3 53
ITI 15/ 7.9.01 216 0 84 300
ITI 46/ 11.12.01 138 0 54 192
ITI 68/ 19.3.02 49 0 36 85
ITI 16/ 2.12.04 38 0 9 47
ITI 07/ 26.10.05 190 0 0 190
ITI 03/ 26.4.02 49 0 36 85
ITI 23/ 30.10.06 190 0 0 190
ITI 20/ 18.10.06 535 0 0 535
ITI 18/ 16.10.06 188 0 0 188
ITI 38/ 29.1.07 144 0 144
HFCL 053/ 27.9.99 148 0 282 430
HFCL 70/ 4.4.01 102 0 6 108
HFCL 14/ 9.7.02 247 0 126 373
SIEMENS 52/ 27.9.99 73 0 127 200

SIEMENS 47/ 11.12.01 138 0 54 192
SIEMENS 58/11.3.02 10 0 4 14
SIEMENS 19/ 19.1.05 377 0 169 546
SIEMENS 08.26.10.05 273 0 0 273
SIEMENS 15/ 18.9.06 390 0 0 390
SIEMENS 17/ 16.10.06 872 0 0 872
SIEMENS 9/ 8.12.05 117 0 0 117
HTL 054/ 27.9.99 76 0 124 200
HTL 59/ 11.3.02 9 0 6 15
HTL 67/ 19.3.02 164 0 74 238
HTL 16/ 28.9.2000 59 0 0 59
HTL 02/ 18.4.02 164 0 74 238
FIBCOM 69/ 4.4.01 51 0 3 54
SCL 13/ 9.7.02 111 0 85 196
ICOMM 26/ 3.3.05 162 0 72 234
BEL 19/ 16.10.06 186 0 0 186
TOTAL 5829 2185 8014
DWDM EQUIPMENT
YEAR 2000-01
Vendor PO / NO. & DATE TML OLA OADM Total / NE

SIEMENS 67/ 30.3.01 6 7 0 13
ALCATEL 68/ 30.3.01 14 27 0 41
TOTAL 20 34 0 54
YEAR 2002-03
ITI 51/ 24.12.01 64 149 0 213
ARM 9/ 5.7.02 54 123 0 177
ACD 10/ 5.7.02 30 65 0 95
HECL 11/ 5.7.02 26 56 0 82
HFCL 12/ 5.7.02 27 62 0 89
TOTAL 201 455 0 656
YEAR 2004-05
ITI 14/ 19.8.04 30 58 6 94
ITI 24/ 16.2.05 42 66 11 119
UTL 25/16.2.05 18 28 4 50
TOTAL 90 152 21 263
YEAR 2005-06
ITI 1/ 15.5.06 8 13 0 21
UTL 2/ 15.5.06 4 5 0 9
TOTAL 12 18 0 30
YEAR 2006-07
ITI 2.5 G 40/ 2.3.07 236 163 47 446
YEAR 2007-08

UTL 2.5 G 16/ 2.11.07 458 0 191 649
PUNCOM 2.5G 17/ 2.11.07 65 0 27 92
UTL 2.5 G 26/ 4.12.07 0 0 269 269
PUNCOM 2.5G 27/ 4.12.07 0 0 38 38
PRITHVI 2.5G 31/ 4.1.08 130 0 216 346
PUNCOM 10 G 32/ 4.1.08 56 0 93 149
TOTAL 709 0 834 1543
GRAND TOTAL 1268 822 902 2992
COMPARISON BETWEEN DIFFERENT VENDORS NETWORK

ELEMENT AND THEIR EMS
NE LCT
SL NO SYSTEM INTERFACE INTERFACE EMS EMS PROTOCOL
NE & & SOFTWARE OS
CONNECTOR CONNECTOR
10 BASE 2 NM WIN
1 FIBCOM Q (ETH) 2100em NT CSMA / CD
STM16 15 PIN D 50 OHMS
CONNECTOR THIN CXL
10 BASE 5
2 HFCL Q (ETH) MSH 51C UNIX CSMA / CD
STM16 15 PIN D LLC-1
CONNECTOR
10 BASE T 10 BASE T
3 TEJAS (ETH) (ETH) MOZILLA UNIX OSPF
STM16 RJ 45 RJ 45 INTERNET
EXPLORER
10 BASE T 10 BASE T
4 ZTE (ETH) (ETH) UNITRANS UNIX TCP/IP
DWDM RJ 45 RJ 45
TELLABS 10 BASE 2 NM WIN

5 / ITI Q (ETH) 2100em NT CSMA / CD
DWDM 15 PIN D 50 OHMS
CONNECTOR THIN CXL
PROTOCOLS :
Carrier Sense Multiple Access with Collision
CSMA/CD Detection
OSPF Open Shortest Path First
LLC Logical Link Control

Transmission control protocol/internetworking
TCP/IP protocol
Vendorwise a physical connectivity diagram of different NEs with EMS and

LCT is given in annexures------
North bound Interfaces:

EMS Northbound interface of EMS
Tejas CORBA
Siemens T4
Fibcom Q3/CMISE
HFCL
* These north bound interfaces are indicative for the EMS of some of the vendors
operating in the Network.
3.3 . Road map to be followed :
1.As a first step, all SDH systems should be brought to their respective
EMSs if they have not been brought so far, through a DCN using BSNL’s
MPLS cloud . Apart from SDH this also be should be done for DWDM,
SSUs , DCME etc for their EMS from respective vendors. For all types of
EMSs (old or new) suitable mediation devices should be provided to
extract required information from EMSs or from NEs directly to achieve
the complete scope of TX NMS.
2. Problems encountered in integrating existing EMSs or Gateway NEs of

SDH and DWDM should be got resolved with respective vendors by the
bidder , in focused manner , so that a good foundation for NMS is
created as existing SDH rings and DWDM systems will continue in BSNL
network for some more years.
3. All future equipment will have TMF compliant EMSs with full FCAPS
features. All future OXCs will also be TMF compliant.
4. Present Synchronization systems like SSUs are managed by LCTs

only in a limited way. Older versions of SSUs may need upgrdation to
make them manageable by EMSs of new SSUs. Those SSUs which are
not feasible to be upgraded can be managed to the limited extent
possible , by Tx –NMS using RS232 ports of SSUs using MLLN’s
transport network .
5. All proposed PRCs and SSUs should be brought to TX NMS through
their EMSs .
6. Networking of various EMSs with TX-NNMS can be done utilizing

BSNL MPLS backbone.
7. BSNL has already developed software for “ NETPLANNER “ for

provisioning of Bandwidth. BSNL’s proposed TX-NNMS should support “

NETPLANNER “ features or should have better software for resBSNL’sce
allocation. BSNL’s aim is end-to-end provisioning through TX-NNMS
with physical wiring restricted to two ends only.
8. TX-NNMS should provide access to BUSINESS DEVELOPMENT cells of

Telecom Circles to help them visualize network and resBSNL’sce
availability. BD cell should be able to get feasibility for any bandwidth
requisition instantly. This will speed up leased lines provisioning
significantly.
9. At present we have a system “ TVARIT “ for leased lines provisioning

and accounting. We may deliberate on integrating TVARIT with BSNL’s
proposed TX-NNMS.
10. BSNL’s aim in near future will be to provide Long Distance Services
with minimal outages. For this we plan to have to have mesh Network
employing Optical Cross Connects and Digital Cross Connects. These
two types of cross connects should be controlled through BSNL’s
proposed TX-NNMS. They may be pre programmed for Traffic protection
but there should be provision to intervene in time of exigencies for
better utilization/diversion of traffic.
11.BSNL’s various services like PSTN, CMTS, CDMA, MPLS VPN, MLLN,
and NIB etc. Depends on Transmission Network for operation and
expansion. Thus there should be dialogue among NMSs of these
services with TX-NNMS of Transmission Systems at Business
Management Layer. This will help a lot in Operation and Future
Planning.
12. TX- NNMS should be dimensioned keeping in view future expansion of

BSNL’s Transmission Network. In future a lot of STM-1 Systems will be
deployed for Last mile connectivity. We are also planning to deploy G
PON , E PON services in a big way . They too will have to be managed
through BSNL’s proposed TX-NNMS. Thus Hardware as well as software of
TX-NNMS should be scaleable and upgradeable.
13. We may deploy “ Remote Fiber Test & Monitoring system “ in

BSNL’s Network in near future. EMS for this should be able to integrate
with TX-RNMS.
14. BSNL’s proposed TX-NNMS will have varied features as above

besides monitoring and control of a large Nos. of NEs. Such TX-NNMS
with enormous data and prowess should have a mirror image as a
Disaster Recovery(DR) site. This DR site should be able to function as
main NMS NOC whenever required.
15. TX NMS should also be able to help settle disputes of SLA

agreement, correlating failure of leased lines with systems failures. This

will require exchange of information among TX-NMS and EMS of MLLN,
MPLS VPN and other satellite based networks.
3.4 Traffic Protection Types To Be Supported
The following list describes the protection types that are to be

supported by the TX NMS as defined in this RFP.
• MS-SPRing in the SDH core network .
• SNCP (UPSR) in the junction, LEASED-LINE SERVICE and access

SDH networks.
• BSNL will soon deploy Optical Cross Connects. Optical path

protection using ASON or G MPLS should be supported by TX
NMS.
TX NMS should enable protection of traffic according to predefined or
dynamically defined priority.
3.5 Interfaces To Be Provided To Other NMSs in BSNL
Transmission system backbone is used by many BSNL services. For

Planning purposes and for day to day operation NMSs of these services
need to interact with TX NMS. This section describes the other NMSs
with which the TX NMS will be required to have interfaces .
• MLLN
• TX-NMS need to be interfaced with MLLN NOC located in

Bangalore. Inter DXC MLLN trunk are carried over Transmission
Network.
• TVARIT :
BSNL uses a software package called TVARIT for commercial and

accounting activities of leased lines. TX NMS will have to facilitate
commissioning of leased ccts booked on TVARIT.
• National Internet Backbone
NIB NOC is located in Bangalore. Backbone links of NIB are also

carried over Transmission System Backbone.
Trouble Ticket System Interface
• BSNL intends to have common trouble ticket systems which will

be put to common use across all network management
organizations.at the time the TX NMS is first put into operation.
TX NMS will need to interface with it.
• Network Inventory Interface.
BSNL’s network and service inventories are kept in a number of

systems: there is no one, unified network inventory system. The
current network and service inventory systems are generally
implemented using MS-Access, MS-Excel, Oracle or proprietary
databases depending on the sub organization that owns the inventory.
In the first instance, the TX NMS will have to take network and service
inventory data from these systems.
In the longer term, BSNL has an intention to acquire a new network and
service inventory system, which will be put to common use across all
network management organizations.
4 SPECIAL CONDITIONS OF CONTRACT
4.1 ELIGIBLE BIDDERS
Eligible bidders are the Indian Companies who are registered /incorporated in
India. The following criterion shall be met by the company or the bidder who
intends to participate in this tender and only those bidders who qualify the
following conditions, need bid:
i) The company shall be registered/incorporated in India
ii) The company shall have a minimum annual turnover of INR 200 Crore each
year during last 2 years (financial year 2006-07, FY 2007-08). Out of this
turnover figure, INR 100 Crore shall be from Networking/OSS business.
iii) Bidder shall have the experience of implementing at least two OSS projects
(involving servers, networking equipment, software etc) during last three years
(after 1st April 2005)
iv) Bidder or its OEMs should have implemented at least two NMS for Transmission
of 10000 network elements for Telecom operators.

v) The bidder shall be ISO 9001 company/ SEI CMM level 4 certified companies.
vi) Verifiable documentary proof is to be submitted for the above.
4.2 CLARIFICATION OF THE BID DOCUMENTS
The bidders may seek clarifications regarding the Bid Documents, as mentioned in
NIT schedule.
4.3 DOCUMENTS ESTABLISHING BIDDER’S ELIGIBILITY & QUALIFICATION
4.3.1 Eligibility Documents

Eligible bidders are required to submit the following documents:
Current and valid ISO 9001/ SEI-CMM Level 4 certificate(s).

Attested copy of the Certificate of Incorporation.
Latest Audited results of last three financial years (2005-06, 2006-07, 2007-08).
Article or Memorandum of Association or partnership deed as the case may be.
A certificate from its bankers as evidence that he has financial capability to
perform the contract.
4.4 Organizational Chart and infrastructure details with the list of support
centers at major cities of India.
4.4.1 Bidder shall submit along with the bid, the complete list of partners
(including database vendor) formed for bidding in this tender including but
not limited to Hardware-Software Solution Providers/ Technology Providers/
Consortium Members, etc. The bidder shall furnish signed letters from all
the partners stating their participation in the said tender. The bidder shall
have back-to-back agreement with each of the partners(including data base
vendor) individually, to ensure that respective product support for
implementation, operations, maintenance, spares and upgrades is available
to BSNL for a minimum period of 7 years excluding the period of
implementation from the date of commissioning the product/service.
4.4.2 Each of the partners (including data base vendor) shall also certify direct
support of its respective products supplied to BSNL for a period specified above,
giving a clear road map. The copies of the actual Teaming Agreement between the
bidder and each of the partner companies shall have to be submitted along with
the bid. All such agreements shall be signed by the respective authorized
signatories of the concerned companies. Teaming agreement is required for all
different technology partners (including data base vendor). Format of teaming
agreement is as at Section XII.
Eligibility criteria and

PROVENNESS for different items
4.5.1 In order to enable the Purchaser to assess and ensure the proven ness of the
products, eligibility criteria for selection of the products in addition to the
fulfillment of all functional requirements as per the detailed specifications are as
below. Eligibility criteria shall cover the minimum requirements w.r.t. Number of
live sites and eligibility parameter as applicable. Site references shall be verifiable
and in case, needed, BSNL reserves the right to visit the reference site.
4.5.2 Eligibility criteria for different items.

No. of
L iv e Elig ib ilit y Do c um ent
Pr o d uc t Sit es Cr it er ia Pa r a m et er (p er s to be
(M inim sit e) sub m itt ed
um )
4.5.2. NM S T wo End Mo nito r ing 1 00 00 e nd po ints
1 Po ints
5
4.5.2. Activat io n
50 00 0 activa tio n/
2 Service / C lie nt
T wo pro visio ns per 8
Provisioning Pro visio ni C er tifica te
ho ur s
ng
4.5.2. Fault/ Inve nto r y
3 Configuration Subscr ibe tr ansactio ns of C lie nt
T wo
/Inventory r s base minimum 5 00 00 C er tifica te
Management
per ho ur
4.5.2. The quoted Installa tio n in
4 St o r a g e product C lie nt
T wo T EL C O /IT
A rr a y (model) C er tifica te
e nvir o nme nt
shall be
4.5.2. deployed
5 for last
three Installa tio n in
Ta p e C lie nt
T wo months T EL C O /IT
L ib r ar y C er tifica te
from the e nvir o nme nt
date of bid
submission
4.5.2. Installation in
6 H elp d esk/ TELCO environment
C lie nt
t ro ub le T wo with installed
subscriber base of Ce r tificate
t ic ket ing
10 mn each
4.5.3 All SSPs shall provide a certificate that proposed application is ported on the
quoted hardware and Operating System (OS) on the date of bid submission.
The SI and the hardware vendor shall also sign this certificate jointly.
4.5.4 Including the above references each software solution shall be running at
minimum five live sites at the time of submission of the bid. Detailed case
study of all the five references shall have to be submitted along with the bid,
failing which the bid shall be summarily rejected.
4.5.5 “Live site as indicated in the eligibility criteria mean that the product shall be
live and running in production environment at the site since last one year or
more from the date of submission of bid for this tender. In case of software,
two prior major releases before the latest release shall only be counted. If at
any site a product is discontinued after certain period or is running in parallel
(Parallel run in order to phase out the product) with the other product, then
that site will not be considered as a valid reference.
4.5.6 Bidder shall ensure that certificates and verifiable references (eligibility clause)
given by SSP and different hardware vendors are authentic. Bidder shall give a
undertaking on its letter head that they are satisfied about the correctness of
the certificate and verifiable references.
4.5.7 The contact details shall be given for contact person for references, as
specified below:
(a) Details of the contact person:

i. Complete postal address
ii. Contact numbers and FAX
iii. Email address
(b) Postal address of the Location/ s of the Data Center
4.5.8 The reference certificate can be from Telco or any other Enterprise environment
for NMS.
4.5.9 RDBMS selected for specific application shall be up and running with the
application in a production system (live-site ) for at least six months as on date
of submission of the Bid. Certificate taken from SSP, with detail of reference
site in this regard shall be submitted along with bid.
4.5.10 Various products including servers, networking equipments, storage etc should
be commercially launched as on date of bid submission. Any product shall be
considered as commercially launched if it is declared so on the website or it has
been supplied to a customer by the OEM (in that case proof of supply shall be
attached).
4.5.11 The eligibility of networking equipments shall be governed by the following:
For Products such as Routers (Transmission centers, Aggregation, Central,

Backbone) and Ethernet switches including Type I & Type II, there shall be at
least three live sites running where at least 50 of these mentioned
equipments (taken together) connected in a single network. Equipments
installed in live sites shall be of the same family as quoted in the bid.
4.5.12 For all products quoted by the bidder, documentary evidence in respect of the
compliance of the clauses mentioned in the tender document shall have to be
furnished in the form of product datasheet, product manual, user manual, etc.
4.5.13 Apart from all the certificates, bidder shall have to furnish a joint undertaking
with the each of the software solution provider stating that all the references
provided are valid and are running in live environment as per the requirement
of this tender document.
4.5.14 The client certificate shall be as per format available in this document at
Annexure IV-E-1. Site references shall be verifiable and in case, needed, BSNL
reserves the right to visit the reference site.
4.5.15 All the references shall have to be of only live site of telecom operator (service
provider). BSNL team is at liberty to visit these live sites at its own cost for
verification of the details submitted by the bidder for that particular site,
however bidder shall be required to organize and co-ordinate the visit at
referred site.
4.5.16 RDBMS selected for specific application shall be up and running with the
application in a production system (live-site) for at least six months as on date
of submission of the Bid. Certificate with detail of reference site in this regard
taken from SSP shall be submitted along with bid. BSNL shall also be free to
contact any of the reference sites.
4.5.17 If at any point of time it is found that the document(s) submitted by the bidder
are untrue, the bid shall be rejected and the bid security will be forfeited.
4.6 Benchmark Metrics

4.6.1 With respect to the Benchmarking results, Bidder shall have to furnish the
Benchmarking Certificates duly authenticated by the Hardware Vendors.
4.6.2 The SSP shall have performed and published benchmarking results for all
software solutions on at least one of the following platforms:
4.6.2.1 Sun’s Solaris
4.6.2.2 HP’s HP-UX
4.6.2.3 IBM’s AIX
4.6.3 The SI can quote the applications on a different platform than on which it is
benchmarked provided that the application is ported on the quoted platform at
the time of bid submission. Necessary certificates in this regard have to be
submitted by the bidder along with the bid. The sizing arrived by the SSP shall
be explained with respect to the benchmark submitted. The hardware quoted
will however be as per ISV sizing certificate only.
4.6.4 The benchmark results shall be made available as a part of the response to
this Tender.
4.6.5 The application wise Benchmarking requirement is indicated below:
SN Application Benchmarking
4.6.5.1 NMS 10000 end points
4.6.5.2 Provisioning 1000 Service requests/ day
4.6.5.3 Fault 50000 alarms per minutes
management
Benchmarking results shall contain information like platform, OS, DB,

subscriber type, etc, in addition to the parameters necessary to judge the
volumetric mentioned under these clauses
Note:
i. By transaction it is meant as transaction done at individual software interface.
A process can have many transactions.
ii. For EAI, in place of benchmarking that for EAI, it is
allowed to submit live site certificate for telecom operator having 15000
Business Transactions per minute volume of Business transaction. Also that the
details given shall be authenticated as per the benchmarking requirement and
contain sufficient information as given in the benchmarking reports.
TENDER EVALUATION
As per clauses of section II of tender document.
4.7.1 Cost of AMC and NMS operation, for the period mentioned in the price schedule shall
be calculated to the Net present value (NPV) at a discounted rate of 12% per annum,
for evaluating purpose as per the formula given below:
For Transmission NMS operation
NPV= O1/(1+r/100)+O2/(1+r/100)2+ O3/(1+r/100)3+ O4/(1+r/100)4+ O5/(1+r/100)5 +

O6/(1+r/100)6 + O7/(1+r/100)7

Here O1, O2, O3, O4, O5, O6, O7 mentioned in the above formula are the system
operation cost for first, second, third, fBSNL’sth, fifth, sixth and seventh year
operations and “r” is the discounting rate of 12% per annum
For AMC cost NPV calculations:
NPV= A1/(1+r/100)3+A2/(1+r/100)4+ A3/(1+r/100)5+ A4/(1+r/100)6 + A5/(1+r/100)7
Here A1, A2, A3, A4, A5 are the AMC amounts for 5 years subsequent to the two
years of warranty and “r” is the discounting rate of 12% per annum.
Note: For evaluation purpose discounting shall be done on annual basis at a

discounting rate of 12% per annum.
4.7.2 A Minimum AMC cost of 3% of the total equipment (includes software) cost shall be
considered for the purpose of evaluation, if the rate of AMC quoted by the bidder is
less than 3%. However payment towards AMC shall be as per the corrected quoted
price.
4.7.3 Although the AMC amount quoted is taken for evaluation as referred above, the
amount payable towards AMC charges shall be determined based on the actual
purchases made by BSNL.
4.7.4 Though the prices of optional item/s have been separately asked for, the cost of
Optional item/s shall be included for evaluation of the tender, unless otherwise
specified. BSNL reserves the right to procure or not to procure the optional items.
4.7.5 In case any item is not quoted by a Bidder, the bid will be loaded by the highest price
quoted in its own bid. In case the price is not available in its own bid then the loaded
price shall be the highest price quoted by any of the bidders for that item. The loaded
item shall be supplied free of cost by the bidder.
4.7.6 For bid evaluation purpose, the total AMC cost shall be arrived at by accounting for the
cost of loaded items on pro-rata basis. However, the AMC cost shall not be paid for all
items supplied free of cost on account of the loading. The same principle shall be
applied for the cost towards services and all other items.
4.7.7 Only Original Bid shall be considered for all evaluation purposes.
4.8 AWARD OF CONTRACT (PLACEMENT OF ORDER)
4.8.1 The ultimate aim of BSNL is to procure and implement the OSS & BSS for
TX NMS with main site at Delhi and its disaster (DR) site at Bangalore. This will be
achieved by floating one tender. BSNL intends to limit the number of technically
and commercially responsive bidders to one from the list of such bidders arranged
in increasing order of their evaluated prices starting from the lowest for the
purpose of ordering in this tender. The bidder with the lowest evaluated price will
be considered for supply and implementation of the tendered items within the
delivery schedule specified in the tender document for the quantity mentioned in
the purchase order.
4.8.2 In the event L1 bidder not agreeing to supply the tendered items or not being
considered by BSNL for placement of order, the work shall be awarded to the next
lowest bidder and so on, at the rates quoted by the L1 bidder.
4.8.3 BSNL will have the right to increase or decrease up to 50 % of the quantity of goods
and services specified in the schedule of requirements without any change in the unit
price or other terms and conditions as at the time of award of contract.

ACCEPTANCE TESTING AND
VALIDATION
4.9.1 “Validation” is a process of testing the “equipment” (Hardware,

Software and applications) as per the specifications including requirements for
use in BSNL network. Validation is carried out in simulated field environment
and includes stability, reliability and environmental tests etc.
4.9.2 Validation and Acceptance test would be done for the entire solution
(Hardware, Network, Software, applications, configurations, customizations and
Data Migration). The bidder shall be responsible for preparation of detailed
validation criteria documents. At the end of completion of such a test, BSNL
would accept the system.
4.9.3 All the development and testing shall be done in the respective environments
(development, testing etc.). Only on acceptance of the system, the replication
would be done on the production environment.
4.9.4 Purchaser reserves the right to appoint any testing authority at its own cost
with relevant experiences in the Telecom domain for carrying out Acceptance
testing and validation of the system.
4.9.5 The successful bidder will provide the list of tests for testing the conformance
of the equipment to the technical specifications, and validation schedule w.r.t
SRS (System Requirement Specifications) related items one month before the
start of validation However for all items not directly related to finalization of
SRS bidder shall provide validation schedule within one month of placement of
APO. The test schedule and procedures for tests will be finalized by the
validation team. BSNL shall have the right to make modification and/or
additions to any test or techniques of measurement as considered necessary by
it.
4.9.6 The Selected Bidder shall finalize an Acceptance Test schedule at least 15 days
in advance of offer for acceptance testing in consultation with Purchasing
Authority. He shall also clearly indicate the specifications clause(s) verified by
each test. The Acceptance Test schedule shall be exhaustive based on the
specifications and will generally cover the following:
1 Hardware and network equipment testing before commissioning

4.9.6.2 Check on Data Cabling, electrical cabling and other wiring
4.9.6.3 On-site validation at the DC locations of Hardware, network equipment &
other stores
4.9.6.4 Setting up of the test environment
4.9.6.5 Functional test on individual equipment, network, software, Reporting etc as
per specifications
4.9.6.6 System and/or Integration test on solution as a whole
4.9.6.7 Capacity/ Load test
4.9.6.8 100% traffic trials on the network.
4.9.6.9 Data updating at DR site with incremental update as well as flush update.
4.9.6.10 Switch over from main site to DR site, Backup, High Availability and Fallback
on N+ 1 server.
4.9.6.11 Intrusion detection and security preparation test
4.9.6.12 Operation of help desk
4.9.6.13 User acceptance testing with parallel run
4.9.7 For the above activities, in addition to providing a dedicated Validation and
Acceptance team, BSNL shall provide Criteria for creation of dummy test data
or actual data if available.

4.9.8 The equipment and accessories will also be pre-tested by supplier,
before offering for Validation and shall submit the test results before offering
them for validation.
4.9.9 The bidder shall make available the software programs and testers
required for carrying out the acceptance tests as per the schedule. Any
additional test equipment deemed required during Validation shall be arranged
by the bidder at no cost to BSNL, so as to complete the Validation as per the
specified time schedule in this document.
4.9.10 BSNL will carry out all the tests detailed in the acceptance test
schedule at site/s and tests on incremental implementations (if any) at other
sites to confirm that the performance of the different modules, subsystems,
and entire installation satisfies the specified requirement of specifications
including service performance.
4.9.11 The equipment, accessories and different software will also be pre-
tested by supplier, before offering to A/T, in coordination with the Data Center
In charge as per the procedure and Performa provided by purchaser in due
cBSNL’sse during and after installation/ commissioning before “take over” and
if any equipment and part thereof is found defective, the same shall be
replaced at no cost to the purchaser.
4.9.12 Any deficiency found during validation in performance of the system as

per the requirement shall be rectified by the bidder immediately at all the
locations. Any components or modules failing during the acceptance tests or
requiring alterations necessary to meet Specification requirements shall be
replaced at no extra cost to the Purchaser at site by the Selected Bidder in
consultation with BSNL . These shall be shipped within two weeks of the initial
reports.
4.9.13 If any equipment or software or any part thereof, before it is taken

over under is found defective or fails to fulfill the requirements of the contract,
the inspector shall give the Supplier notice setting forth details of such defects
or failure and the supplier shall make the defective equipment or software
good, or alter the same to make it comply with the requirements of the
contract within 4 weeks. These replacements shall be made by the supplier free
of all charges at site. Should it fail to do so within this time, the purchaser
reserves the discretion to reject and replace at the cost of the supplier the
whole or any part of equipment as the case may be, which is defective or fails
to fulfill the technical requirements of the contract. The cost of any such
replacement made by the purchaser shall be deducted from the amount
payable to the supplier.
4.9.14 Test environment setup and software readiness: After the entire
development cycle is over, all the components have to be tested end to end;
System Integrated Testing (SIT) would be done. Here SI has to demonstrate
the system in a controlled production environment. This involves the following
tasks:
.1 setting up of testing environment.

4.9.14.2 Deployment of Applications from Development Environment to Controlled
Production Environment
4.9.14.3 Implementation of Interfaces with External Systems
4.9.15 System integration testing phase: Here the entire system will be
tested on an integrated basis as a single solution. It involves the following
tasks:

.1 Test Planning
4.9.15.2 Test Data Preparation – while SI can state the test data requirement, BSNL
shall provide criterion for creation of dummy test data or actual data
wherever possible.
4.9.15.3 Integration Test Environment Setup in accordance with Technical
Architecture Blueprint
4.9.15.4 Integration testing (verification of features, inter-operability, application
performance, conformance to Architecture Document, conformance to
operations procedures & documentation). Architecture Document shall be
prepared by SI and submitted to BSNL for approval.
4.9.15.5 Mock User Acceptance Test
4.9.15.6 Problem Resolution
BIDDER’S RESPONSIBILITY
4.9.15.7 Educate the Senior Management, Middle Management and the executive
regarding the awareness of the project.
4.9.15.8 Supply, Install hardware & software and implement system.
4.9.15.9 Train all the users for the smooth usage of the system.
4.9.15.10 Train the core team to handle the support maintenance and minor
development in the post Go Live scenario.
Expenses:
4.9.15.11 All the expenses of the bidder in terms of boarding/lodging/traveling will be

borne by the bidder.
Technical Audit of System
4.9.15.12 Purchaser reserves the right to carry out technical audit of system by the
Bidder through agency designated by BSNL during warranty period. Based
on its recommendation, bidder shall take necessary corrective measures to
comply the performance parameters stipulated in the tender document.
Cost of technical audit shall be borne by BSNL. Any deficiencies pointed out
after technical audit and agreed by BSNL, shall be rectified by the bidder
free of cost within 45 days of acceptance of the audit report.
4.10 TRAINING
4.10.1 The bidder shall provide training to the personnel nominated by BSNL The
training shall be thorough and effective and shall enable the trained personnel
to independently handle the installation, operation and maintenance of the
system.
4.10.2 The bidder shall separately specify in his bid the number of trainees, quantum
of proposed training, if they feel the proposed training schedule mentioned
elsewhere in this document will not be adequate to achieve proficiency level for
different modules, duration of the proposed training.
4.10.3 The travel expenses, boarding and lodging for the trainees shall be borne by
the purchaser. The details of training to be conducted shall be indicated by the
bidder.
4.10.4 The bidder shall provide all training material, documents and training aids. It
shall also allow BSNL’s training centers to create copies of the training material
for internal consumption (within BSNL).

4.10.5 The bidder shall provide user training prior to cut-over to operational use of the
system.
4.10.6 Man days of Training required:

For Trainee Man Approx no. Location
days of trainees
NMS NOC personnel 200 20 NMS
Centre
User at field level ( For all named 1500 Sub
users) * regional
HQ
*: May be provided by the SI’s
SME.
4.10.7 Bidder shall have to provide detailed training programme indicating training
content, tentative schedule, etc.
4.10.8 Training at Development Center of Software Solution Provider (SSP):

Bidder shall have to provide training to NMS Centre personnel and the
validation team on the major software as per details given below: Bidder shall
have to provide training to data center personnel and the validation team on
the major software as per details given below:
S. No. Software Number of Duration Location

persons
4.10.8. NMS 12 10 days Same as
1 above
4.10.8. Networking 12 5 days Same as
2 above
4.10.8. Provisioning 12 5 days Same as
3 above
4.10.8. Fault/Configuration/Inven 12 5 days Same as
4 tory Management above
Note (*): These trainings are required to be compulsorily delivered by

application vendor (SSP) or its partner who are authorized to impart training for
their application, for which necessary proof is to be given by application vendor.
In case training is to be delivered by the authorized partner then valid
authorization letter from application vendor is required to be submitted.
4.10.9 Bidder shall have to provide detailed training program indicating training content,
tentative schedule, etc.
4.10.10 Content of training and the training schedule shall be finalized by BSNL in
consultation with the bidder as per the inputs provided along with the bid.
4.11 SPARES
4.11.1 During the implementation, warranty and AMC period, BSNL will not
procure any spare from the Bidder.
4.11.2 The bidder shall provide the list of spares as per annexure to the Schedule of
requirement name as “Annexure –Spares’ that shall be kept at NMS sites and
or any other sites, at its own cost, for maintenance during implementation,
warranty and AMC period. The price of spares thus mentioned need not be
quoted.
4.11.3 BSNL intends to procure the spares at the end of the AMC period at the

quoted price in the detailed price schedule. Therefore the bidder shall give
detailed price break up for the hardware items quoted in the bid. In case the
detailed breakup of cost of various items is not there then the spares as
required shall be procured free of cost.
4.12 WARRANTY
The bidder shall provide comprehensive warranty of all the tendered items
supplied for the project. It shall be for 24 months from the date of
commissioning of system.
4.13 Payment Terms :
The payment terms and conditions for different items are elaborated in the various
clauses below:
(A) Hardware
The payment terms shall be as below:

i. 30% payment of hardware including networking equipments shall be made
on delivery after physical inspection (without any physical damage)
ii. 50% on successful validation.
iii. 20 % after 1 year of successful operation
(B) Software:
i. 30% payment for software shall be made on receipt of licensed copies of

the software.
ii. 50 % payment after successful validation.
iii. 20 % after 1 year of successful operation
4.14 AMC:
i. No advance payment for AMC shall be made.

ii. The entire AMC duration for a year will be divided in 4 quarterly
segments.
iii. After successful completion of the AMC period of 3 months, 100%
payment after making due adjustment towards SLA penalties will be made
based on the quarterly bills submitted.
iv. It has to be ensured by the bidder that it has back to back AMC
agreements with all associated SSPs/vendors. The copy of the agreements
shall be supplied at the time of signing the AMC contract.
4.15 LIQUIDATED DAMAGES:
4.15.1 Should the bidder fail to implement the project within the period prescribed
in the tender, the purchaser shall be entitled to recover damages as per
details given below:

4.15.2 Delay in supply: In case of delay in supply of equipment as per
schedule i.e. 90 days from date of PO, a penalty shall be imposed. The
penalty amount shall be calculated on payment due at the time of supply of
these equipments as per payment terms and conditions mentioned in this
tender. The penalties imposed shall be as below:
4.15.2.1 For a delay up to 10 weeks – 0.5% (per week)

4.15.2.2 Further delay of 10 weeks - 0.7 % (Per week)
4.15.2.3 Overall maximum penalty - 12% of the total due cost at this stage.
4.15.3 Delay in commissioning: In case of delay in commissioning as per schedule i.e. 6

months from the date of PO, a penalty shall be imposed. The penalty amount shall be
calculated on payment due on completion commissioning as per payment terms and
conditions mentioned in this tender. The penalties imposed shall be as below:
3.1 For a delay up to 10 weeks – 0.5% (per week)

4.15..3.2 Further delay of 10 weeks - 0.7 % (per week)
4.15..3.3 Overall maximum penalty - 12% of the total due cost at this
stage.
4.15.4 Quantum of liquidated damages assessed and levied by the purchaser

shall be final and not challengeable by the supplier.
4.16 OTHER TERMS AND CONDITIONS
4.16.1 Date fixed for opening of bids is, if subsequently, declared as holiday by the
BSNL, the revised schedule will be notified. However, in absence of such
notification, the bids will be opened on next working day, time and venue
remaining unaltered.
4.16.2 Purchaser reserves the right to disqualify such bidders who have a
record of not meeting contractual obligations against earlier contracts entered
into with the purchaser.
4.16.3 BSNL reserves the right to blacklist a bidder for a suitable period in case
he fails to honBSNL’s his bid without sufficient grounds.
4.16.4 BSNL reserves the right to offer counter offer price(s) against the
price(s) quoted by any bidder.
4.16.5 Any clarification issued by BSNL in response to query raised by

prospective bidders shall form an integral part of Bid Documents and it shall
amount to amendment of relevant clauses of the Bid Documents.
4.16 FUNCTIONAL COMPLIANCE
4.16.1 Clause wise Compliance statement has to be furnished for the tender
document stating “Complied” or “Non-complied” for all sections except
Section VI (Technical specifications)
4.16.2 For the technical specifications under Section VI, compliance has to be
given in the format prescribed below. Bidder shall have to indicate full
compliance in yes or no format. All compliances in uniform format shall have to
be given by the bidder after consolidation of OEM’s compliances. Bidder shall
claim compliance only when compliance is 100%, otherwise non compliance

shall be mentioned and an explanation may be given in remark column, on how
it proposes to fully comply the clause. The compliance statement shall be
provided in the following format:
Section Page No. Clause No. Compliance Remarks

Yes No

Annexure VI-E-1
Client Certificate
(On client’s letter head)
Client certificate shall cover at least following:
1. Application (Name) is live and running since…………

Or
Product Name (and model)
2. Eligibility criterion:
(Signature of Authorized Signatory)
Details of the person signing the certificate:
Name and complete postal address

Contact numbers and FAX
Email address
Postal address of the Location/ s of
the Data Center

5. SCHEDULE OF REQUIREMENTS
(Bidders have to give un-priced detailed Bill of Material for all the quoted Hardware
and Software items along with the techno-commercial bid and same priced Bill of
Material of all the quoted hardware and software items in financial bid).
Main and DR NMS NOC
5.1 Hardware For Major Applications
Type of Data Center High DETAILS (to

Server Applications/ Availability be provided
Server by bidder)
DC
Class/Edge
class/Mid AAA 1+1 Server
5.1. range/
1 blade
DC
Class/Edge Provisioning 1+1 Server
5.1.2 class
5 DC
. Class/Edge
1 class Inventory
1+1 Server
. Management
3
5 DC
. Class/Edge
1 class Fault
1+1 Server
. management
4
5 DC
. Class/Edge
1 class
Mediation 1+1 Server
.
5
5 DC
. Class/Edge
1 class
NMS 1+1 Server
.
6
5 DC
. Class/Edge
1 class
Help desk 1+1 Server
.
7
5 DC Backup Server 1+1 Server

. Class/Edge
1 class

1. Bidder should specify suitable Server type based on applications and dimensioned
as per BSNL requirement.
5.2 Other Hardware Items
DETAILS
(to be
provided by
Remarks bidder) Quantity
5.2.1 System administration 1 per 1 DC class
Consoles for DC servers server 1 set
Work Stations(Thin
client) with preloaded
5.2.2 Hardware
software for NOC
operators 50
Remote Operator Hardware
5.2.3 Terminal with preloaded
software 30
DC Gigabit LAN Switch Server load balancing
as per TEC GR No., feature shall be
GR/LSW-01/03 Sep available on all ports.
5.2.4
2007 (high range), with (port shall be
minimum 48 port GE/FE distributed on
ports minimum 2 cards) 2
5.2.5 Printers as per Hardware
specifications given in
the document 2
5.3 Storage Equipment for main and DR NOC site

Remarks DETAILS Quantity
5.3. Mid-tier (as per TEC GR)
1 Storage for main site
5.3.1.1 Usable Storage Capacity using 2 TB
146GB 15K rpm drives after
RAID 5
5.3.1.2 Storage Software 1 set
5.3.2 Multi pathing and Load

Balancing Software

5.3. HBA multi pathing and load 1 set
2.1 balancing Host based Software
5.3.3 SAN Switches Not required
4. SAN Switch with minumum 128 128 Ports* 2

1 Ports & necessary cables,
software & any other
component required
5.3.4 Backup Software 1 Set
5.3. Tape Library 1

5
5.3.5.1 Tape Drives Minimum 4
5.3.5.2 Drive Slots Minimum 90
5.3. Tapes/Cartridges Minimum 60

6
5.3. Software 1 Set
7
Note:
1) Bidder should suggest whether LAN or SAN based storage will be suitable for
TX NMS.
5.4 Physical Security

Remarks Details to be Minimum
provided by bidder Quantity
5.4 Access control
.1 System (Hardware) 1 set
5.4.1.1 Door Controller 10
5.4.1.2 Smart Card Reader 10
5.4.1.3 Door Locks 10
5.4.1.4 Smart cards 50
5.4.1.5 Biometric finger Print
Scanner 5
5.4.1.6 Electronic Rodent
Management System 8
5.4 Access control 1 set
.2 System (Software)
5.4 CCTV Based
.3 surveillance System
(Hardware) 1 set
5.4.3.1 CCTV Cameras 10
5.4.3.2 DMR 1
5.4 CCTV Based
.4 surveillance System
(Software) 1 set
5.5 Uninterruptible Power Supply (For main & DR Site)

DETAILS
UPS (As per TEC GR No. GR/UPS-
(to be
01/03. May 2006, with
provided by
amendments if any)
bidder) Minimum Quantity
To be
UPS 80 KVA or higher provided in
5.5.1
(1+1) 4
configuration.
Battery Bank for each UPS to
provide 1 hrs backup (As per TEC
5.5.2
GR No. GR/BAT-02/02. Mar 2006
with amendments, if any) 4 sets
5.5.3 Associated switchgear and cables
4 sets
5.6 Miscellaneous Items
MISCELLANEOUS
DETAILS Minimum Quantity
5.6.1 Large Screen Wall as per 2
specification
5.6.1.1 Rear Projection Modules 2
5.6.1.2 Display Controller Unit with 2
required software
5.6.1.3 Display Controller Extension Unit 2
configured with RGB Interface for
Display Controller-Two ports with
one interface cable(15 m), Video
Interface for Display Controller -
FBSNL’s Ports with one interface
cable( 15 m)
5.7 Network
Item Probable
DETAILS Quantity
5.7. level 1 router configured with 2 channelized
1 STM-1, 4 number of ISDN PRI, 2number of 2
10/100 mbps Ethernet interface, 16 E1 ports
5.7 Additional interface of channelized STM-1 for
.2 CSR level 1 router, 2 number of GE interface. 2
(Optional)
5.7. LAN switch configured with 12 numbers of
350
3 10/100 and 2 numbers of 1000 base T LAN ports
5.7. REMOTE ACCESS SERVER (RAS) with 4
4 channelized E1R2/PRI ports, 120 digital modem
2
ports and 2 Ethernet ports of 10/100
mbps(Optional)
5.7.5 Transmission POP ROUTER configured with the
2 nos. of 10/100 mbps Ethernet interface, 2nos. 100
of E1interfaces
5.7.6 Ethernet to E1 converter(Optional) 100
5.7.7 Internet ROUTER configured with 2 nos. of GE
interface, 2 nos. of 10/100 mbps Ethernet 2
interface, 2 nos. of E1 interfaces

Note: Entire quantity mentioned in the “Probable Quantity” column shall be taken for
evaluation purpose, however, supply and payment of these above items shall be as per
actual deployment. Optional items may or may not be procured depending on actual
requirement. All networking equipments shall be housed in standard OEM racks supplied
as part of installation material at all locations.
5.8 Security
Minimum
Items
Remarks DETAILS Quantity
5.8. NMS CENTER FIREWALL in
1 Redundant Failover configuration
configured with FBSNL’s nos. of
Gigabit Ethernet interfaces (on each
of the redundant Firewall units) &
Two nos. of 10/100 mbps Ethernet 4
Interfaces(on each of the redundant
Firewall units) as per TEC GR
no.GR/FWS-01/01 SEP 2006 (as per
latest TEC GR available as on date
of bid submission)
5.8. Network IDS configured with Eight
2 Gigabit Ethernet interface Probes as
per TEC GR no.GR/IDS-01/01 FEB 2 sets
2003 (as per latest TEC GR available
as on date of bid submission)
5.8. 1 set
Server Access Control System (ACS)
3
Note: Annexure is to be given for license basis and calculation for total year
wise no of licenses for all security component
5.9 Major Software (All license on perpetual basis)

Application Software
Licensing
Basis (Bidder Quantity of
Details to specify) Licenses required
5.9.
1 Provisioning 2 set
5.9.2 Inventory Management 2 set
5.9.3 Fault Management 2 set
5.9.4 SLA management 2 set
5.9.5 Mediation server for non TMN 2 set
compliant EMSs
5.9.6 NMS 2 set
5.9.7 Help desk system 2 set
5.9.8 Oracle RDBMS 2 set

5.9.9 RDBMS other than Oracle ( 2 set
5.10 Documentation
DOCUMENTATION
DETAILS Minimum Quantity
5.10. Hard Copy 1
1
5.10. Soft Copy 2

2
Note: Payment for services shall be calculated on the pro-rata basis of cost of
equipments actually supplied.
5.11 Annual Maintenance Contract (For all items)

(including DR Site)
Item Details Quantity

5.11.1 Equipment including
HW and SW (other than
RDBMS)
5.11.1.1 Year 1 Lump sum 1 set
5.11.2 ORACLE RDMBS
Maintenance
5.11.3 RDMBS Maintenance
(Other than Oracle)
5.11.4 For Any other item


Note: Payment for AMC shall be calculated on the pro-rata basis of cost of equipments
actually supplied.

6 : Functional and Technical Requirement of the tender
6.1 Scope of Tender

6.1.1 Scope of the contract is for Supply, Installation, customization,
commissioning, training, Operation and maintenance of NMS for transmission
network, as per the requirement specified in this tender on turn-key basis. It is
proposed to have main data center at Delhi with DR site at Bangalore .
6.1.2 The NMS solution will distribute the mediation for fault, provisioning ,
inventory to each of the POP locations namely : Delhi, Bangalore.
6.1.3 BSNL reserves the right to change the NMS Center Locations even after
the submission of the tender.
6.1.4 NMS proposed to be implemented through this contract shall be IPV6

compliant.
Functional
Requirement.
The following sections describe BSNL’s detailed requirements for

the TX NMS architecture and various other general requirements.
Where a requirement is expressed using the word shall, it should be
read as a mandatory requirement: that is, if a Tender does not fulfill
such a requirement, the Tender may be excluded from further
consideration.
6.2.1 TX NMS Architecture
One of BSNL ’s major objectives is to acquire an TX NMS that features a

scalable, robust, open architecture that will enable the system to be
expanded to cover other management areas following the initial
implementation.
6.2.1.1 Architecture Principles To Be Adopted :
6.2.1.1.1 The TX NMS shall not be built on the basis of a “hard-

wired” solution, but shall provide a framework upon which
management facilities can be built.
6.2.1.1.2 Integration of the TX NMS with network technologies

(network elements and EMSs) shall be via standards-based
interfaces if such interfaces are available. For example, if an
EMS offers both a proprietary interface and a CORBA-based
interface, then the CORBA interface shall be used.

6.2.1.1.3 If an EMS offers a particular function that would be of
use to the TX NMS then that EMS function should be used rather
than replicating the function in the TX NMS. For example, if a
function is available in an EMS that accepts alarms from a set of
network elements and passes them along in a formally defined
North-bound interface, then that EMS should be used as a
mediation device for the TX NMS rather than building an interface
directly between the TX NMS and network elements.
6.2.1.1.4 The architecture of the TX NMS should be n-tiered.

Tenderer should give a detailed description of their TX NMS’s
architecture in their responses.
6.2.1.1.5 The user interface to the TX NMS should be windows

based, the client is to run on Windows 2000 or Windows XP
operating system. Tenderer should describe in their responses
the range of options available for GUI presentation.
6.2.1.1.6 While a proprietary electronic bus structure is

acceptable for connection between TX NMS components, the TX
NMS architecture shall be such as to allow connection of external
functional blocks (for example, a trouble ticket system) via one
or more EAI-type, commercial middleware products. Tenderer
should describe in their responses what options are available for
connections to other OSSs.
6.2.1.2 Architecture Extensibility:
6.2.1.2.1 The TX NMS shall be capable of readily being

extended to cover fault, service level and performance
management, and service and circuit monitoring, for other
technologies and service types currently implemented by BSNL
but which are not included in the scope of this RFP, and those
that are likely to be implemented in the future. Tenderer should
describe in their responses the extensibility features of their TX
NMS architecture that will allow the scope of the TX NMS to be
extended further in the future.
6.2.1.2.2 Service provisioning is a specific requirement in this

RFP. TX NMS shall be capable of being extended to cover cross-
technology, end-to-end service provisioning for all of the
technologies within the scope of this RFP, plus the additional
technologies described in the two preceding requirements.
Tenderer should comment in their responses on the feasibility of
supporting future end-to-end, cross-technology provisioning functions

using their TX NMS.
6.3 System Security:
6.3.1 The TX NMS shall have a coherent security system to protect it

from malicious attacks and accidental damage from both internal
and external sBSNL’sces. Tenderer should describe in their
responses the security architecture of the TX NMS that will allow
this requirement to be fulfilled. Of particular interest to BSNL is
the method of authentication and access control implemented by
the TX NMS, and the means that can be used to secure the
system from “hackers”.
6.3.2 The TX NMS shall enable users to have a single login identifier
and an associated password, which must be changed regularly.
Tenderer should describe in their responses how log-in identifiers
and passwords are managed securely. In particular, Tenderer
should comment on how the single login identifier requirement
can be reconciled with providing operations staff with pass-
through access to EMSs, which have their own password
schemes.
6.3.3 All user actions that result in changes in the condition of the
system or the state of any alarms (that is, are not simply
browsing operations) shall be logged by the TX NMS. In this
context, the word “user” includes any automatic action initiator
component. Tenderer should describe in their responses the
command logging facilities that are implemented in their TX NMS.
6.3.4 The TX NMS should grant access to functions and data on the
basis of a user profile. User profiles should define what can be
accessed rather than what cannot be accessed. BSNL will require
many levels of user profiles to be defined, and Tenderer should
describe in their response any limitations with respect to the
number of user profiles available. Tenderer should describe in
their responses how this requirement would be implemented in
their TX NMS.
6.3.5 The TX NMS shall not allow “backdoor” access to EMSs or
network elements. That is, the ability to login to EMSs and
network elements should be restricted by users’ profiles.
6.4 Function And Component Distribution :

6.4.1 Discrete logical components of the TX NMS shall be capable
of being distributed across hardware platforms as an aid to
providing increased performance and resilience against failures.
For example, the correlation component should be able to run on
a different hardware system to the alarm-handling component,
and the service-monitoring component should be able to run on a
different hardware system to the other two components.
Tenderer should describe in their responses the types of
functional distribution that can be realized using their TX NMS.
6.4.2 The TX NMS hardware components should be capable of
distribution as required: that is, the physical locations of system
hardware components should have no affects on how users
access the system or how application components function.
Tenderer should describe in their responses the types of hardware distribution
that can be realized using their TX NMS.
6.5 TX NMS Self Management
6.5.1 The TX NMS shall be capable of managing itself by reporting

alarms that are raised by its own components. Of cBSNL’sse,
this puts some constraints on the design of the alarm-handling
component of the system, which clearly must be protected.
Tenderer should comment in their responses as to the
practicability and methods of providing such a self-management
function in their TX NMS.
6.5.2 The TX NMS shall be capable of managing the infrastructure
that supports it (such as the DCN) by reporting alarms that are
raised against such infrastructure components. Tenderer should
describe in their responses the types of facilities in the TX NMS
that are available to manage the supporting infrastructure of the
TX NMS.
6.6 System Performance And Scalability
6.6.1 The TX NMS shall be capable of receiving large volumes of

alarms during periods of major network incidents without losing
any alarms. Section -- Error: Reference source not found, on
page --, provides some guidance on current alarm volumes.
Tenderer should describe in their responses the alarm-handling-
volume capabilities of their tendered configurations.
6.6.2 It is anticipated that there could be up to 1000 registered
users of the TX NMS when the scope described in this RFP is
covered, with up to 50% of those users being logged in at any one
time.

It should be assumed for planning purposes there will be up to
300 concurrently active users.
6.6.3 The initial TX NMS design shall be such as to allow twice the current
alarm arrival rates to be handled efficiently and effectively, with the
ability to be scaled in the future to handle five times the current rate as
more service types, EMSs, network elements and network element
types come under management.
Tenderer should describe in their responses the facilities of
their TX NMS that will support the ability to scale significantly as
the network under management becomes larger and as functions
such as provisioning and bandwidth control are introduced in the
future.
6.6.4 The TX NMS shall be capable of reflecting large numbers of service state
change events in the service-monitoring component during periods of
major network incidents. For example, if an STM-16 trunk suffers a
fiber cut, there may be well in excess of 1,000 2Mbit/s service state
change events to be reflected in a very short time, and a break in a
DWDM fiber could cause many more times that number of service state
changes to occur. Tenderer should comment in their responses as to the
sort of service state-change throughput that can be expected from the
tendered system configuration.
6.6.5 The TX NMS shall be capable of scaling both outwards (by adding more
hardware systems to a clustered configuration) and upwards (by, for
example, adding more processors, memory or disks to an existing
configuration in a cluster). Tenderer should describe in their responses
what scaling options are available for their TX NMS.
6.7 : System Availability
6.7.1 The TX NMS shall be designed so as to be highly available.

BSNL ’s target is that the TX NMS will have availability exceeding
99.95%, excluding planned maintenance and software and hardware
upgrade times.
6.7.2 To support the availability target stated above, the TX NMS

shall be constructed using redundant components for key
elements wherever practical and economically justifiable (for
example, the main alarm handling engine may be protected by
a redundant fail-over processor). Tenderer should describe in
their responses the design features of their proposed
configurations that will support this requirement.

6.8 :TX NMS Data Communications Network
6.8.1 The data communications network (DCN) between the TX

NMS location and the attached EMSs and network elements shall be
implemented on TCP/IP. BSNL will provide requisite bandwidth.
6.8.2 Tenderer shall describe in their responses the design of the

data communications network they propose would be used between the
TX NMS, operations staff using the TX NMS and the EMSs and network
elements that will feed alarms to the TX NMS. The DCN from the EMSs
to the various network facilities is already in place and need not be
incorporated in the design. For the purposes of the DCN design, the
following assumptions should be made.
6.8.3 EMSs are distributed across operational areas of BSNL.
6.9 : TX NMS Database Management System
TX NMS data stores shall be accessible to authorized external systems (

NMSs of BSNL’s other services and BSNL customers) that have a need
to see alarm data and network performance data. The TX NMS shall
publish some sort of open API, or provide some other mechanism, that
would allow such access to be made available. Tenderer should describe
in their responses what mechanisms are available to enable other
applications to share the TX NMS’s data, what DBMS is used to store
data internally and what security measures are available to ensure that
only authorized systems have access to the internal data stores
6.10 : Customer, Service and Network Inventory
Inventory data in the context of TX NMS refers to customer, service,

logical and physical network inventory data required in order to
implement the service-assurance related functionality of the TX NMS.
6.10.1 It is mandatory that the proposed TX NMS include

functionality to model and access customer data, services data, and
network topology (both logical and physical), in order to facilitate
effective service assurance and network management.
6.10.2 The tenderer shall achieve the above-mentioned

functionality by implementing a local data store for customer, service
and network inventory within the TX NMS, containing customer data,

services data, network topology (logical and physical) data and the
relationships between customers, services and logical/physical network
topology. This local repository is not intended as a master database or
inventory solution for other external BSNL systems, but will serve as
the main repository for TX NMS related usage. The tenderer shall
describe approaches for how the proposed local data store can be
expanded in future to play a larger role in BSNL’s OSS portfolio.
6.10.3 The tenderer shall state and specify in detail in which of

the following ways the local customer, service and network inventory
data store shall be implemented:
• Using a COTS inventory management solution.
• Using a proprietary data store integral to one or more modules
within the TX NMS
Implemented as a native schema on a database management
system as a “virtual” data store, through integration with existing
external BSNL data source to access the required data from the external
BSNL data sorce on demand (synchronously or asynchronously)
• Other approach / combination of above.
Tenderer to specify in detail.
The tenderer shall state the type of data model or data modelling
approach to be used by the local TX NMS customer, service, network
inventory data store:
TeleManagement Forum Shared Information/Data Model (TMF SID)
Proprietary Data Model
Other industry standard data model. Tenderer to state.
Other. Tenderer to describe in detail.
6.10.4 Currently, BSNL’s network and service inventory is maintained in a

number of existing home-grown systems ( Like NETPLANNER , TVARIT ,
SBNM). These inventory systems are based on various mechanisms,
such as MS-Access, MS-Excel, Oracle, or proprietary databases. The TX
NMS shall be required to interface with and/or obtain data from these
systems. The tenderer shall specify the approach to be taken during
the implementation to populate the TX NMS data store by leveraging
these types of existing data
.
6.11 : Different Sources of Inventory Data
6.11.1 Manual data entry or data population of the TX NMS data

stores should be minimized or avoided completely where
feasible.
6.11.2 The tenderer should describe in their responses the

approach taken to uploading/integrating customer, service and
network inventory data from external systems, and how the TX

NMS’s view of the inventory would be uploaded, updated or kept
in synchronization with the originating systems’ view.
6.11.3 The tenderer shall propose as part of the technical solution

the approach for auto-discovery/auto population of logical and
physical network infrastructure into the TX NMS data store(s).
6.11.4 The tenderer shall propose as part of the technical solution

the approach for reconciliation and consistency-checking of the
logical and physical network inventory in the local TX NMS data
stores with the actual network infrastructure.
6.11.5 The TX NMS shall support circuit end-to-end route

discovery and display, including network, node, port, timeslot.
6.11.6 This TX NMS shall provide topology views and flexible

switching on each resBSNL’sce view, including whole network,
equipment, port timeslot, and so on.Integrated with cutting-
edge Geographical Information Systems, exact locations of
network equipment can be pinpointed. High-resolution maps
allow users multiple zooming to display geographical details
accurately
6.12 : Integration with other BSNL NMSs
The TX NMS will need to have interfaces with a variety of other BSNL
NMSs like NIB , CDR based billing , GSM Mobile , CDMA Mobile , MLLN
etc , both at first implementation and in the longer term.
To give maximum future flexibility, the TX NMS shall support a

number of standards-based possible interfacing mechanisms (for
example, CORBA, SOAP and so on). Tenderer should describe in their
responses what interfacing mechanisms are available.
6.13 : Trouble Ticket Interfaces
6.13.1 BSNL currently has manual trouble ticket systems.

Tenderer should describe in their responses the approach they would
take to implement Trouble Ticketing Operations.
6.13.2 BSNL has yet to decide what trouble ticket system will
become the longer-term standard, but intends to seek a solution based
on a commercial, off-the-shelf (COTS) product. The TX NMS shall
provide interfacing facilities that will enable it to be relatively simply
integrated with whichever trouble ticket system BSNL chooses.
Tenderer should describe in their responses what trouble ticket system
interfacing mechanisms are available.

6.14 : Data For Further Analysis :
BSNL has significant reporting obligations – both to its external

regulator, and for internal management purposes. Many of the reports
that are required are used as key performance indicators (KPI) and
serve many purposes – from determining whether BSNL is meeting its
license requirements, SLA requirement and determining performance
levels for staff members.
Much of the data that BSNL needs to collect for reporting purposes will
come from the performance management component of the TX NMS,
but there is a need to collect other statistical data that will not be
collected by performance management.
The methods to be used for the analysis of such data is to be submitted
by tenderer.
1. The TX NMS should enable BSNL to define the types of reporting

data that are to be collected, and the triggers that will cause such
data to be collected. The TX NMS should store any such reporting
data for later use. The types of data that will be required are yet to
be determined, but they may include the following:
• Average time taken to acknowledge alarms.
• Average time taken to handle alarms.
• Average time taken to clear alarms.
• Average time taken to clear trouble tickets.
• Alarm arrival rates, peak and average, per hour, day, week and
month, per EMS and per network element.
Tenderer should describe in their responses the capabilities that their

TX NMS provides for defining trigger points for deriving statistical
information of the types described above, and for collecting and storing
these types of statistical data.
6.15. Communications With Network Elements
6.15.1 The TX NMS shall handle unsolicited messages (events)

sent from network elements attached to all the EMSs described above.
6.15.2 The TX NMS network element communications

mechanisms shall be open enough that the system will be able to
communicate in the future with any EMS that BSNL chooses to use with
relatively little duplication of effort put into creating the initial EMS
interfaces. Tenderer should describe in their responses the features of
their TX NMS that will enable such future interfaces to be implemented
relatively simply and quickly.
6.15.3 There may be cases in the future in which BSNL decides

that acquiring an EMS for a set of network elements is not commercially
justifiable. In such cases, the TX NMS shall be able to connect directly
to network elements. Tenderer should describe in their responses
whether, and how, direct network element connections, including the
case of SNMP-managed elements, could be provided by the proposed
TX NMS.
6.15.4 Some EMSs and network elements need a “keep alive”

signal from any system that has a connection with them. If a “keep
alive” signal is not received during a set period then the connection will
be dropped. The TX NMS shall be capable of sending a “keep alive”
signal to EMSs and network elements that require such a signal, and
the signaling period should be able to be set per EMS or network
element type.
6.15.5 The TX NMS shall support the sending of commands to all

the EMSs described above that are capable of taking commands from an
external system. The following constitute the minimum command sets
initially to be supported by the TX NMS (though it is possible that some
EMSs may not support these sets , for them suitable mediation
mechanism is to be evolved by bidder).
(A)Resynchronization request.
(B)Get performance data request.
(C)The basic set of SNMP requests.
TX NMS should also support provisioning functions, so the
system should have the ability to broaden the command set.
Tenderer should describe in their responses the scope of the
commands that their TX NMS is capable of sending to EMSs and
network elements, particularly with regard to supporting
provisioning functionality.
6.16 : Network Element Modeling Using Standards
Internally the TX NMS shall model all network elements as per the
relevant ITU-T information-model, if any, for the network element class.
For example, SDH network elements should be modeled as per ITU-T
Recommendation G.774 for both the transport and the equipment
fragments. Tenderer should describe in their responses what ITU-T
modeling recommendations are supported by their TX NMS.
6.17 : Drill-Through Sessions To EMSs:
6.17.1 The TX NMS shall enable authorized operators to “drill-

through” from the TX NMS so as to start a session with lower-layer
element management systems for detailed fault analysis and restoration

work.
6.17.2 It shall be transparent to the operator that such a session

has been started via the TX NMS. For example, the screen layouts and
functions of the EMS to which the operator is connected shall be the
same as though a direct connection were being used.

6.18 Fault Management Functionality
This section describes the fault management functionality required in

the TX NMS.
6.18.1 Event Collection
There is a distinction made by many network element manufacturers

between events and alarms.
For the purposes of this document, an event is defined to be an
unsolicited message from a network element. 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.
SNMP traps are assumed to be the same as “alarms”, and no distinction
is made in these sections between SNMP traps and alarms.
Generally speaking, the TX NMS will log and suppress non-alarm
events, but there may be a need to handle such events in the future.
The word “alarm” as used in this section should be read as meaning
“alarm event”.
6.18.2 Alarm Reception
1. Alarms arriving at the TX NMS shall be transformed into a common

(preferably ISO) format prior to processing by the TX NMS.
2. The TX NMS should use the common alarm format in all internal TX
NMS data stores, and in operator 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.
(A)
The common alarm format supported by the TX NMS shall contain at
least the following information:
Event type.
(B)
Managed object identifier.
(C)
Date and time of alarm emission.
(D)
Perceived severity.
(E)
Probable cause.
(F)
Notification identifier or correlated notification identifier.
(G)
Additional text.
(H)
Specific problem.

6.18.3 Alarm Mapping
1. Alarms from equipment that supports an ITU-T information model

shall be mapped to the relevant equipment object or transport
object in the network element as per the ITU-T information model
applicable to the network element class.
2. Alarms that cannot be mapped to an equipment object or a

transport object shall be mapped to the parent network element
object.
3. Alarms that cannot be mapped to a network element object shall be

mapped to a pseudo entity called the “unknown NE" or similar.
4. Alarms from equipment that does not support an ITU-T information

model should be mapped to the network element object (that is,
such a network element should consist of just one managed object,
and that object should be the network element itself).
6.18.4 Low-Level Alarm Logging
1.Alarms that have been mapped to the relevant managed object shall
immediately be logged prior to any other processing being applied to
them.
2. The TX NMS shall periodically archive alarms from the

low-level log prior to purging them. The archiving cycle shall be
externally programmable. Archiving shall be able to be initiated by an
operator command or as a system-initiated event.
3. The TX NMS should provide analysis tools that will

enable the low-level alarm archive to be examined for patterns of
alarms. For example, the analysis tools should be able to report on
network elements that show an increasing rate of alarm generation.
4. Tenderer should describe in their responses any alarm

log analysis tools the TX NMS has that may be applicable.
6.18.5 Alarm Augmentation
1. The TX NMS shall provide the ability to insert extra information into
an alarm (for example, into the additional text field) based on the
contents of a raw alarm. For example, an indication as to whether
an alarm is service-affecting might be placed into the additional text
field of the common-format alarm to assist service monitoring to
determine the affects of an alarm on services). The rules defining
such augmentation of alarm information should be externally

definable. Tenderer should describe in their responses any facilities
that are in their TX NMS to enable this requirement to be met.
2. The TX NMS shall be capable of assigning (mapping) values in a
common-format alarm based on the occurrence of text values in
incoming (raw) alarms. For example, if an equipment type reports
non-ISO probable causes, the TX NMS should be capable of
transforming the non-standard values into standard values. Mapping
should be done using rules that are externally configurable.
Tenderer should describe in their responses any facilities that are in
their TX NMS to enable this requirement to be met.
3. The TX NMS should be capable of mapping object identifiers in

incoming alarms in non-standard ways. For example, equipment
objects may be identified using a rack/shelf/ slot/port type of
addressing scheme. However, some network element types report
alarms using a value of zero for the first slot in a shelf, while others
use a value of one. The TX NMS should provide a rules-based
facility for changing the object identifier to a common base, and the
rules used for doing this should be externally configurable. Tenderer
should describe in their responses any facilities that are in their TX
NMS to enable this requirement to be met.
6.18.6 Current Problem List

1. The TX NMS should maintain a current problem list for each
managed object, and the current problem list should be updated on
the basis of alarms arriving from the network (for example, if a new
alarm arrives from a managed object that is already alarmed, the
new alarm should be added to the object’s current problem list; if a
clear alarm arrives, the corresponding raise should be cleared from
the current problem list).
2. The current problem lists should be used as the basis on which

resynchronization is done. That is, when a resynchronization
operation is requested, incoming resynchronization alarms should
only be passed to higher levels for handling if they do not appear in
the current problem list.
6.18.7 Alarm Suppression
1. 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 TX NMS shall provide
facilities that will enable it to identify build alarms and suppress them.

2. The TX NMS should enable operators 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. Tenderer should describe in their responses any
facilities that are in their TX NMS to enable this requirement to be met.
3. The TX NMS 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. Tenderer should describe in their responses any
facilities that are in their TX NMS to enable this requirement to be met.
6.18.8 Alarm Filtering
1. The TX NMS shall have the ability to apply filters to alarm

streams to remove alarms that are of no interest. Filtering shall take
place after alarms have been logged so no incoming alarms are lost.
2. Filtering should take place at the lowest possible level in the TX NMS
(that is, closest to the point at which alarms arrive from the
network).
3. The TX NMS filtering functions shall be programmable by network

operations staff, and shall allow alarms to be passed or removed
from the alarm stream based on a combination of one or more of the
alarm attributes, on the duration between the arrival times of alarms
or on other criteria that will facilitate removing no- or low-value
alarms. Tenderer should describe in their responses the facilities that
are provided in their TX NMS that will enable filtering functions to be
programmed by operations staff.
(A)
In addition to the types of filtering specifically described in this
document, the following general types of filters should be
available in the TX NMS:
Blocking (remove alarms based on sets of criteria).
(B)
Thresholds (pass or block alarms of a type once a certain number
have been received).
(C)
Toggle (Suppress repeated raise/clear sets, passing only the
initial raise and the final clear).
6.18.9 Clear-Alarm Correlation

The TX NMS 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). Tenderer should describe in
their responses the facilities available in their TX NMS that will enable
this requirement to be met.
6.18.10 Connection Monitoring
The TX NMS shall monitor its connections with EMSs and network
elements, and raise an alarm if a connection fails. Such an alarm
should be automatically cleared when the failed connection is restored.
Tenderer should describe in their responses the facilities available in
their TX NMS that will enable this requirement to be met.
6.18.11 Resynchronization
1. When a connection to an EMS or network element is restored after

having been lost, the TX NMS shall initiate a resynchronization
operation with the EMS to refresh the alarm states held by the TX
NMS.
2. The TX NMS shall enable operator-initiated resynchronization of

alarms with selected managed objects, network elements or EMSs.
Tenderer should describe in their responses the resynchronization
facilities available in their TX NMS.
6.18.12 Alarm Handling
For the purposes of this section alarm handling is defined as being the
set of facilities that will allow network operators to deal effectively and
efficiently with the alarm messages that appear on their displays.
During handling, alarms will transition through a number of states, from
the point at which they are received by the system but have not yet
been seen by anyone, through to the time when the underlying fault is
cleared and the alarm is terminated.
The TX NMS shall support at least the following alarm states (or
their equivalents by other names):
1. Raised (an alarm has been raised but not yet acknowledged).
2. Acknowledged (an operations staff has acknowledged that they have

seen an alarm).

3. Handled (handling of an alarm has been started).
4. Cleared (the condition that caused an alarm to be raised has been

cleared).
5. Terminated (there are no further outstanding issues with an alarm

(for example, traffic that failed because of an alarm condition has
now been restored) and the alarm can be archived).
6. Archived (an alarm has been archived and is eligible to be purged

from local storage).
6.18.13 Alarm Distribution
1. The TX NMS shall support multiple alarm-display domains.

Tenderer should describe in their responses any restrictions that
exist on the number of alarm-display domains that may be
currently active in their TX NMS.
2. 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 (for example, a transmission management
group may only want to see equipment alarms from the trunk
network, a customer service group may only want to see circuit
state change alarms, and so on). Tenderer should describe in
their responses the distribution facilities available in their TX NMS
that will enable this requirement to be met.
6.18.14 Alarm Display
1. Each alarm-display domain shall be implemented as

a graphical user interface (GUI) that is intuitive to use and will
require minimal operator training time. Tenderer should describe
in their responses the GUI facilities available in their TX NMS and
identify the pre-requisite required for the users to use the system
efficiently.
2. The alarms displayed in all display domains shall be

color coded on the basis of perceived severity.
3. Operators should be able to define their own

individual set of data that is to be reported against alarms (for
example, some operators may want to see the additional text of
alarms, while others may not).
4. As a minimum, the following types of alarm-display domain types

shall be provided:
I. 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.
II. Alarm-scrolling domain, in which the details of a selected subset of all
alarms are displayed in tabular form, with the list being able to be re-
sequenced as required.
III. 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.
IV. 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.
V. 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.
VI. The TX NMS should enable operators to hide single alarms or groups of
alarms from view in a display domain, and reshow any hidden alarms
with a mouse-button click or menu function.
6.18.15 Operator Notes
1. The TX NMS shall enable operators to append one or more notes to a

selected alarm or group of alarms. If a group of alarms is selected,
the note shall be appended to each of the selected alarms.
2. Operator notes should be able to be long enough to contain

substantial amounts of information that may be passed between
groups during fault resolution. Tenderer should describe in their
responses the operator notes facilities available in their TX NMS.
6.18.16 Trouble Ticketing Operations
TX NMS operators shall have the ability to raise trouble tickets from
their alarm handling screens, and to make certain management
operations against trouble tickets. Tenderer should describe in their

responses the facilities available in their TX NMS to support the trouble
ticketing operations described below.
6.18.17 Raising A Trouble Ticket

1. The TX NMS shall allow an operator to raise a trouble ticket by
selecting an alarm or a group of alarms and invoking the trouble
ticket interface by either a mouse click or a menu selection.
2. A trouble ticket raised via the trouble ticket interface shall be

automatically populated by the TX NMS with the details of the first
alarm selected when the trouble ticket was raised.
3. After a new trouble ticket has been raised, the TX NMS shall be able
to receive from the trouble ticket system a trouble ticket reference
number and append it to the alarms associated with the trouble
ticket.
6.18.18 Associating Alarms with Existing Trouble Tickets
1. The TX NMS should allow an operator to select an alarm or a group

of alarms and, using either a mouse click or a menu selection,
associate those alarms with a currently open trouble ticket.
2. The reference number of the trouble ticket to which alarms are

associated should be added to the relevant alarm record(s).
6.18.19 Disassociating Alarms from Trouble Tickets
1. The TX NMS should allow an operator to select an alarm or a

group of alarms and, using either a mouse click or a menu
selection, disassociate those alarms from a currently open
trouble ticket, with the provision that at least one alarm should
remain associated with the trouble ticket.
2. The reference number of the trouble ticket from which the
alarms are disassociated should be removed from the relevant
alarm record(s).
6.18.20 Clearance of Trouble Tickets
1. The TX NMS shall be able to accept a trouble ticket clearance

advice from BSNL’s trouble ticket system and automatically
terminate all outstanding alarms associated with the cleared
trouble ticket.

2. Alarms that are terminated automatically as a result of a trouble
ticket clearance shall have an appropriate note added to
them (for example, something like “Terminated by the TX
NMS due to the closure of trouble ticket nnnnn at nn:nn:nn
yyyy-mm-dd”).
6.18.21 Recognizing Duplicate Trouble Ticket Requests
The TX NMS should be able to recognize an attempt to raise a trouble

ticket against a facility that is already associated with an open trouble
ticket and give the operator the choice as to whether or not to proceed
with raising the new trouble ticket. Tenderer should describe in their
responses what facilities are provided in their TX NMS to support this
requirement.
6.18.22 Alarm State Transitions
The TX NMS shall enable an operator to select one or multiple alarms

and apply a state-change operation to each alarm in the selected group
(for example, if 10 alarms are selected and the operator invokes an
acknowledgment operation, then the states of all selected alarms should
be set to acknowledged).
6.18.23 Automatic Action Initiator
1. The TX NMS shall be capable of automatically initiating an

action on the occurrence of certain events or combinations of
events. For example, a critical alarm from a particular type of
network element may trigger (in addition to the display of the
critical alarm in the relevant domain windows) the following types
of actions:
2. Issuing diagnostic commands to the relevant EMS or

network element to capture more information about the fault.
3. Requesting the relevant EMS or network element to

perform a corrective action to resolve the fault.
4. Sending a message (by e-mail or SMS) to notify a service

technician about the fault.
5. The conditions in which automatic actions are initiated, and

the actions that an initiation will cause, shall be externally
programmable by network operations staff. Tenderer should

describe in their responses the facilities available in their TX NMS
that will enable the requirement for automatic invocation facilities
to be met.
6. Alarms that have their state affected by an automatic

action shall have a note added to them that indicates this is the
case. For example, something like “Cleared by automatic function
BSNLBSNL at hh:mm:ss on yyyy-mm-dd” could be used.
6.18.24 Alarm Correlation
Alarm correlation will generally be interested only in equipment alarms

(as opposed to traffic alarms) and will be used for two primary
purposes:
To determine the root-cause underlying sets of alarms and report the
root-cause as a single alarm.
To assist in reducing the number of alarms seen by operators to the
minimum necessary to effectively manages the network.
The TX NMS shall provide a comprehensive alarm correlation

facility. Tenderer should describe in their responses the alarm
correlation facilities available in their TX NMS, and comment on their
suitability for programming in the future by BSNL staff.
6.18.25 Root-Cause Analysis
1. The TX NMS shall

provide facilities that enable it to determine the root cause
underlying sets of alarms that exhibit certain patterns. For
example, the TX NMS should be able to deduce that a fiber cut is
the likely root-cause if it sees a certain pattern of alarms arriving
from an adjacent pair of SDH network elements. By implication,
the TX NMS will need to have an understanding of the physical
and logical topology of the network to allow this function to be
implemented.
2. When a root-cause is
determined, the TX NMS shall raise a root-cause alarm, associate
the contributory alarms (that is, those alarms that root-cause
analysis used to determine the root-cause) with the root-cause
alarm and remove the contributory alarms from the operator’s
view.
3. The TX NMS shall

enable an operator to see the contributory alarms associated with

a root-cause alarm by initiating a mouse action or menu selection
against the selected root-cause alarm.
4. When a root-cause
alarm is raised, the TX NMS shall indicate in the alarm the rule
that it used to determine that the root-cause existed. For
example, the additional text in the root-cause alarm may be set to
contain a note such as “Raised by root-cause rule BSNL at
hh:mm:ss on yyyy-mm-dd”.
5. An operator shall have

the ability to “dismiss” a root-cause alarm (for example, if the
operator does not agree that the pattern of alarms indicates the
root-cause inferred by the TX NMS).
6. If a root-cause alarm is
dismissed, the TX NMS shall terminate it and restore the
contributory alarms to the view of the operator. TX NMS should
subsequently modify root cause analysis criteria.
7. The TX NMS should

apply all actions that are applied to a root-cause alarm to the
associated contributory alarms. For example, if a root-cause alarm
is acknowledged, the contributory alarms should automatically be
acknowledged.
6.18.26 Fleeting Alarm Suppression

1. 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 TX NMS shall provide facilities that will
enable it to identify fleeting alarms and suppress them before
they are passed to alarm handling. Tenderer should describe in
their responses what facilities are provided in their TX NMS to
support this requirement.
2. The TX NMS 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.
6.18.27 Extraneous Alarm Suppression
1. Some network element types emit certain alarms that can safely
be ignored by the TX NMS. These alarms are called “extraneous
alarms”. The TX NMS shall provide externally programmable,

rule-based facilities that will enable it to identify extraneous
alarms and suppress them before they are passed to alarm
handling. Tenderer should describe in their responses what
facilities are provided in their TX NMS to support this
requirement.
2. The TX NMS should maintain a “master alarm” for each managed

object reporting extraneous alarms. The master alarm should
contain a count of extraneous alarms received from the reporting
object, and the count should be incremented each time a new
extraneous alarm is reported by that object and the alarm is
suppressed.
6.18.28 High-Level Alarm Logging
As noted earlier, the TX NMS shall be able to log all alarms at the
reception level. Those lower-level logs are kept for relatively brief
periods - mainly for the purposes of doing detailed analyses of network
behavior (for example, to investigate why a particular network element
has suddenly started reporting lots of fleeting alarms).
Similarly, there is a requirement to log alarms at the alarm-handling
level. This is referred to here as high-level logging. The alarms saved
by high-level logging are mainly used for statistical analysis of alarm
handling behavior, but they may also be used for SLA dispute
resolution and may be kept for many years.
• The TX NMS shall provide facilities that enable alarms to be

logged at the level at which they are managed by operators (that
is, when they have passed all filtering components of the system).
• The TX NMS shall periodically archive alarms that have a state of

terminated. The archiving cycle should be externally
programmable. Archiving should be able to be initiated by an
operator command or as a system-initiated event.
• The TX NMS should change the state of alarms that have been
archived to “archived”, and alarms with a state of “archived”
should be purged periodically from the alarm handling data store.
6.19 : Service And Circuit Monitoring
One of BSNL’s primary objectives for the TX NMS is to be able to

relate failures in the network directly to their impact on customers’

services. For the purposes of this section, this facility is known as
service monitoring.
The term service monitoring should be read as including circuit
monitoring, in which bearer circuits that are not of themselves
“services”, but which do carry services, are monitored. To be of
interest to the TX NMS, a bearer need not be carrying services that are
monitored by the TX NMS. For example, the TX NMS as defined in this
RFP will not be managing voice circuits. However, bearers that carry
voice services will be monitored by the TX NMS.
Service monitoring will generally be interested only in traffic alarms,
and will maintain a state view of services and bearers based on the
alarms it sees arriving from the network. For example, a service-
affecting alarm that is received from a managed object will affect the
state of the services that are carried by the object.
Tenderer should provide in their response a detailed description of the
service and circuit monitoring facilities available in their TX NMS.
1. The TX NMS shall

provide facilities that enable the states of services and bearer
circuits to be monitored.
2. The TX NMS shall

enable individual services and circuits to be mapped to the
network facilities that carry those services and circuits.
3. The TX NMS 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.
6.19.1 Mapping Services To Customers
The TX NMS shall enable services to be associated with the

customers who “own” them. This association should also identify any
service level guarantee that is applicable to a service. For example,
when service monitoring is showing the details of a service, the details
should include information that identifies the customer that “owns” the
service and describes the SLA applicable, if any.
.2 Modeling Of Service Protections

In determining the affects of network failures on a particular service or
circuit, the TX NMS shall take into account the protection facilities that
are available to that service or circuit. For example, if there is a fiber
cut on a MS SPRING -protected SDH ring that carries a particular
2Mbit/s service, the service state will change from “operational” to
“switched over” (because the service is now being carried on an
unprotected ring). If there is a second fiber cut on the same ring, then
the state of the service will change from “switched over” to “disabled”.
• Initially, the TX NMS shall support at least the following SDH

protection schemes:
1. 2-fiber MS-SPRing
2. Other protection schemes, available with G MPLS or ASON

enabled OXC for λ switching and other network technologies,
will need to be supported in the future for the purposes of
service protection & monitoring. Tenderer should describe in
their responses the types of protection schemes that are
modeled by their service monitoring facilities, and how the
service monitoring facilities can be expanded in the future to
support other protection schemes.
3. Priority wise protection plan should also be available as some

of BSNL customers will need high availability up to 99.999%
for their leased ccts.
6.19.3 Service And Circuit State Changes
1. The TX NMS shall raise state-change alarms or events to signal

changes in the operational state of services and circuits. For
example, when a service changes state from operational to
disabled, a corresponding state-change alarm should be raised.
Similarly, when a service changes state from disabled to
operational, a corresponding state-change clear alarm should be
raised (to automatically clear the original disabled state-change
alarm).
2. The TX NMS should use state-change alarms as the mechanism for

reporting service availability (for example, the rule may be that a
service is available so long as its state is operational or degraded. A
service is unavailable so long as its state is disabled). These state-
change alarms should be reported to service-level management,
which will use them in SLA performance measurement.
6.19.4 Display Of Affected Services

The TX NMS shall be able to selectively display details of bearer facilities
that are currently affected by faults. The display should initially have
focus on the highest-speed bearers that are affected (such as a VC-4),
and it should be possible to progressively “drill down” through the
higher-order bearers to the lower order services that are affected (for
example, the VC-12s carried on a failed VC-4). Tenderer should
describe the display facilities in their TX NMS that will enable this
requirement to be fulfilled.
6.20 Performance Management
This section describes the requirements for the TX NMS with regard to
performance management.
Performance management has four primary aims in the context of
this RFP:
1 To collect service-performance information for service level

management purposes.
2 To collect service- and network-performance data for management

and marketing purposes.
3 To collect network-performance data that can be used by

engineering groups for planning and maintenance purposes.
To detect pending network problems that are signaled by network

elements in the form of error reports.
• The TX NMS shall provide facilities that will enable the

performance of individual services and circuits to be monitored.
Tenderer should provide in their responses a detailed explanation
of how their performance management facilities relate equipment
performance information to individual services and bearer circuits,
as well as to equipment objects.
6.20.1 Performance Data Collection
1. The TX NMS 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).
2. The TX NMS 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 staff.
3. By default, 24-h BSNL’s performance data shall be collected from all

collection-enabled network elements every day, but operators shall
have the ability to select 15-minute performance data collection for
nominated network elements, with a correspondingly shorter
collection period.
4. Some EMSs do not support real-time collection of performance data:

collection is run as a batch task on the EMS system. For these
EMSs, the TX NMS shall provide a facility that runs on the EMS
system, collects performance data and places it into a well-known
location on the EMS host. The TX NMS should pick up such
performance data using a mechanism such as ftp.
5. The TX NMS should raise a critical alarm if a performance data

collection operation fails.
6.20.2 Storage Of Performance Data
1. Raw performance data

(as collected from network elements) shall be stored for a
programmable time from the date of collection. Typically, raw
performance data will need to be retained for a period of three to
six months from the date of collection.
2. Raw performance data

should be aggregated daily, weekly and monthly, and daily,
weekly and monthly aggregated data should be kept for a user-
specified time.
3. In the future, the TX NMS may be required to pass performance

data periodically to external data mining/warehousing
applications. Tenderer should describe the facilities that are
available to export performance data to other applications.
6.20.3 Performance Alarms

enable performance thresholds to be set on a per-managed-object
or per-managed-object-type basis, with hourly, daily and weekly
settings available.
2. The TX NMS should raise a performance alarm if a nominated

performance threshold for a managed object is exceeded. For
example, one threshold may be severely errored seconds (SES)

on SDH regenerator section trail termination points (rsTTP). If
the SES rate on an rsTTP were observed to exceed the hourly,
daily or weekly threshold, then a performance alarm would be
raised.
6.20.4 Performance Reporting

1. The TX NMS shall
provide a reporting capability that will enable BSNL 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. Bidder should describe in
their responses the range of reporting types that their solution
provides, and the network technologies that it supports.
2. The TX NMS 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.

enable inexperienced users to access pre-defined performance
reports, with more experienced users able to define new reports
based on existing pre-defined reports.
4. The TX NMS should enable suitably trained BSNL staff to define

new reports and save the report definitions for other users to
access.
The following are some of the report types that should be included in the TX NMS’s
range of capabilities:
(A) Best and worst performers reporting.

(B) Trend reporting.
(C)Comparison reporting between groups (for example,
all FIBCOM network elements of a type against all HFCL
network elements of the same type).
(D)Current experience against history (for example,
performance of a group of network elements for the past
week against performance a year ago).

6.21 Provisioning :
• TX NMS should enable BSNL to provision bandwidth , end to end

across multiple transmission network elements of various make.
• TX NMS should be able to entertain Provisioning requests from
different BSNL services( through their NMS) and BSNL’s leased
line subscribers.
6.22 Inventory Management
6.22.1 Inventory management shall provide inventory management process

automation capabilities offer full visibility into all transmission assets across the
country.
6.22.2 It shall allow quick and accurate identification of assignable devices and
equipment,.
6.22.3 The solution shall store both ports (connection terminations) and NE
names.
6.22.4 The inventory model for ports and switch names shall simple,
6.22.5 Each Network object shall have a one-to-one relationship with a port pool,
so there is one port pool for each NE.
6.22.6 A switch object has two attributes: its name and its location.
7 Implementation Plan
7. 1 BSNL envisages setting up a transmission NOC infrastructure, which is
centralized but has decentralized roles and privileges based access to
BSNL officials.
7.2 Purchase order for this project is proposed in two stages as below:
Stage 1:
Hardware and software supplied shall be procured around 50% of the total
requirement. It is planned to order racks and associated items in totality to
facilitate installation in the initial stage itself to avoid disturbance at a later
stage. Exact requirement will be worked out with the Successful bidder by
BSNL at the time of PO.
Stage 2:
Remaining hardware and software shall be ordered as and when need arises.
7.3 Time Frame:

7.3.1 Supply of Hardware, software and other items: within 3 months from the date
of PO
7.3.2 Commissioning of the system: within 6 months from the date of PO.
7.4 In case the above time frames are not met by the SI, Liquidated Damages
as per tender shall be levied.
8 Scope of work
8.1 Successful bidder shall have to submit draft layout showing actual partition,
location of the server room, workstation hall, active backup space, printer room,
dispatch room, storage of tapes, UPS room, Network Operation Center, Security
Monitoring room, UPS room and any other area required for NMS operation.
8.2Since, site preparation with respect to partition of space, lighting, flooring, ceiling,
Air conditioning, etc are under BSNL’s scope of work, SI shall have to indicate
special requirement in terms of raised flooring, special lighting points, power
ducting requirement within the building, network cabling duct. BSNL will consider
these requirements at the time of renovation and redesigning of the building.
8.3 The calculation for total heat dissipation should be specified to calculate the AC
tonnage along with the bid.
8.4 The total electrical power requirement shall be specified in the bid by the bidder.
A detailed calculation sheet shall be provided in the techno commercial bid taking
into account all components of NMS i.e. Servers, network, etc. However location
of Main Distribution Point shall be decided during SRS.
8.5All electrical wiring and earthing for the NMS Centre equipment within the NOC shall
be the responsibility of the SI. BSNL will provide requisite power pick up point from
its power panel located in the power room from where the SI shall carry the
connection up to the Data Center and distribute it further as per requirement.
8.5.1 The gigabit enabled structured cabling as per TEC GR No. SLC-01/02 Sep 2005
for Ethernet Switch establishing Local Area Network within the Data centre to
connect all kind of hardware resBSNL’sces shall be done in accordance with
design finalized by SI and approved by BSNL.
8.5.2 All Gigabit connectivity between different NMS NOC equipment shall be on
optical / electrical interface.
8.5.3 All LAN cabling shall meet the TEC GR no. GR/SLC-01/02 Sep
2005 structured cabling.
8.5.4 Provision of CCTV based Surveillance System & Access Control
System at the Data Center. A separate enclosure shall be
provided for monitoring screens.
8.6 Computer Hardware
8.6.1 Hardware requirement is categorized in two broad levels for all categories
of applications.
8.6.2 First category of servers is of Connection or Presentation Servers for

Applications which are multi instance and scale horizontally. For such category of
applications, Rack mounted Blade Servers/ Rack mounted Stand Alone Servers
shall have to be used. These type of servers shall be utilized as:

...1 NMS mediation servers
...2 Fault management
...3 AAA Servers
...4 Logical Security Elements
...5 Network Device Management Servers
...6 Performance , provisioning etc.
8.6.3 Second category is of Datacenter class Servers for the purpose of Database
where persistent data is stored and Application Servers where business
logic resides within which data is manipulated in response to a client’s
request. Here database and application can scale diagonally i.e. scales
vertically to an extent and horizontally beyond that. These services can run
on multiple mid range servers or on a few high end servers having multiple
instances of application running. Following applications shall run on these
servers:
..3.1. Provisioning, inventory management

..3.2. EAI
..3.3. EMS, NMS
..3.4. Help desk
..3.5. Backup
..3.6. High availability
8.6.4 Test, simulation, training and development server can be in DC

class or presentation servers depending upon SI’s overall
solution architecture and if the sizing by the SSP requires so.
These servers should not be mixed with production
environment.
8.6.5 System Architecture shall be modular in design allowing future expansions.
8.6.6 There shall be no single point of failure in the Hardware design.

8.6.7 SI shall provide operational and monitoring tools for each and
every hardware system.
8.6.8 Hardware System shall provide status information of the various
processes to an industry standard eMS (Third party)
8.6.9 The hardware requirement is enumerated in the tender
document elsewhere.
8.6.10 Every effort has been taken to specify correct interface for
connectivity of Hardware and Software. All equipments and software purchased
through this tender shall have to be deployed by the SI. Hence, any issues related
with the connectivity, interface, adapter, APIs, etc. have to be looked into in totality
and any missing item shall have to be clearly mentioned. Any hardware/ software
required in excess of the indicated figures in the Bill of Material shall be accordingly
quoted in the financial bid. Details in this regard are also to be furnished in the
technical bid. In case the bidder does not quote any additional hardware/ software and
the same is be found to be inadequate while meeting the performance parameters,
additional hardware/ software shall have to be supplied by the bidder free of cost.
8.6.11 Data Center Class Server Specifications
1. The servers shall have a capacity of minimum 64 1.6 GHz cores of dual core
processors. The servers shall be capable of having at least 4 high-end

partitions having all resBSNL’sces to support multiple hardware and software
level partitions with independent OS images associated with independent CPU,
memory & I/O resBSNL’sces for running different applications modules. It shall
be possible to configure partition in a cluster with same and different type of
servers and also with another partition within the same server for achieving a
high availability environment.
2. All CPUs shall be 64 Bit high performance processor of highest level of

frequency available from the vendor and it shall be possible to install different
versions of CPUs in a single server.
3. The total of chip cache (L1+L2+L3) per dual Core processor module shall
be at least 18 MB. On-chip CPU Cache shall be ECC protected.
4. The RAM used in the servers be DDR-2 and shall have support for chip-
kill/spare capability. ACPU and memory paths should be ECC protected. The
RAM shall support Chip-spare technology and Dynamic Memory Resilience
(DMR-Dynamic Memory de-allocation on failure).
5. The server shall have minimum 48 PCI X (64 bit) hot pluggable slots. At
least 10 slots shall remain free after implementation for future upgradeability.
All I/O slots shall dynamically adapt 32 or 64 bit cards at a minimum frequency
of 66 MHz giving an aggregate I/O bandwidth of minimum 8.5 GB/s. However,
the I/O bandwidth of the system shall be minimum 512 MB per processor
configured. All I/O paths shall be parity protected.
6. Each partition shall be provided with a minimum of 4 No. of 146 GB SCSI

/SAS hot swappable disks of latest technology (mirrored across two controllers)
and in two separate disk shelves for Operating System (OS). No two disk
shelves should be shared between partitions
7. Each partition shall be equipped with minimum 4 Nos. of 4 Gbps Fibre

Channel ports in each Partition (configurable as both F port and G port). The
ISV may define their requirement for FC ports over and above the minimum 4
ports if required. All the partitions shall be equipped with 2 No. Of dual
channel Ultra 2 SCSI controllers in each partition for accessing internal OS Disk.
Each partition shall be equipped with DVD-RW for OS Boot.
8. All the servers shall be equipped with a 20/40 DAT drive.
9. All the partitions shall be equipped with minimum fBSNL’s numbers of 1000
Mbps Ethernet- ports. The ISV may define their requirement of Ethernet ports
over and above the minimum 4 ports if required.
10. The bidder can use Combo PCI IO controllers. Not more than Two partition
can use one PCI-IO Drawer/ PCI-IO Chassis. This ensures maintenance of
necessary IO performance required by the application.
11. The servers shall have at least one Serial port. At least 2 servers shall have
rackmounted TFT based management console server with separate LAN
interface for managing various partition.
12. The servers shall be equipped with N+1 OLR Fan, Power supply with option
of alternate supply inputs.
13. In the offered Servers 52 cores will be configured for applications which is
80% of the capacity. Balance 20% of the cores will be configured as 20%
headroom for future scalability. This will eliminate downtime for any future

expansion. The bidder shall also quote necessary hardware such as disks, IO
controllers, disk shelves, IO chassis etc for 2 additional partitions for future
expansion.
14. Servers shall be configured minimum with 4 GB memory per processor core
and shall be scalable to minimum 8 GB memory per processor core in the same
server.
8.6.12 Operating System and other associated software
1. The Operating System shall be 64 bit UNIX with SMP support, unlimited user
license and XPG 3/4 Compliant. The UNIX Runtime version shall be licensed
for un-limited users. The OS shall have C2 level security and provide host
based intrusion detection and buffer overflow protection. The OS shall be
supplied with standard utilities for system administration and provide
software tools for hardware monitoring & diagnostics.
2. The software shall support Dynamic Memory Resilience (DMR) to
dynamically de- allocate bad memory pages before a serious memory
failure occurs.
3. The software shall support Dynamic Processor Resilience to facilitate a
faulty processor to be taken off-line without having to reboot the system.
4. The software shall provide Dynamic management of the JBSNL’snaled File
System with on-line backup, on-line disk de-fragmentation and online file
system resizing. It shall allow on-line file system management for the
JBSNL’snaled File System.
5. The software shall provide the capability to create Work Load Management
and Process ResBSNL’sce based management. The software should include
a capacity planning tool along with a comprehensive virtualization
management tool
6. It shall be possible for dynamic upgrade of patches.
7. The software shall support I/O load balancing and multiple pathing for
storage subsystem and networking.
8. The software shall provide support for TCP/IP (IPv4 and IPv6 support), NFS
etc.
9. The software shall support up to 16 node clusters. The Clustering shall be
capable of Cascading fail-over.
10. The supplier shall also ensure the supply of following software along with
the hardware. Validation with B&CCS vendor is required before bid
submission.
11. GUI Based Management application shall be provided to manage all the
resBSNL’sces in the virtualised partitions.
12. tool shall be provided to capture server utilization data and virtualization
scenarios to perform ongoing capacity planning.
13. A tool shall be provided to enable automated, dynamic allocation of server
resBSNL’sces among the applications according to predefined policies.
8.6.13 Edge Class Server Specifications
Edge servers will be Stand alone rack-mount servers or Blade Servers.
8.6.13.1 Each server will have following configuration

8.6.13.2 32-bit Xeon 2x Quad Core CPUs of 2 GHz or higher clock
speed
8.6.13.3 64-bit RISC/EPIC 2x Dual Core CPUs of 1.6 GHz or higher
clock speed

8.6.13.4 Minimum 4 GB ECC RAM per CPU
8.6.13.5 Minimum 2 x 72 GB SCSI/SAS HDD mirrored with Raid
controller with appropriate cache. Mirroring through Software
RAID is also permitted.
8.6.13.6 Redundant power supplies
8.6.13.7 DVD Drive
8.6.13.8 Dual 10/100/1000 Ethernet Ports
8.6.13.9 One remote management port per server
8.6.13.10 Minimum one spare server per 5 stand alone server
8.6.13.11 42U Rack.
8.6.13.12 Windows/Linux/Unix OS will be configured as per the
application requirements
10
8.6.13.1 Tape Library Specifications
6. Offered Tape Library shall support Native data capacity of 72TB (uncompressed)
expandable to 144TB (compressed).
7. Tape Library shall provide web based remote monitoring capability.
8. The Tape Library unit shall be configured with FC LTO Gen4 Tape Drives.
9. Tape Library shall be configured with Two FC LTO4 drive scalable to fBSNL’s FC
LTO4 drives.
10.Tape Drive Architecture in the Library shall conform to Ultra3 SCSI standards.
11.Offered LTO4 drive in the Library shall conform to the Continuous and Data rate
matching technique for higher reliability.
12.Offered LTO4 drive in the library shall offer optional WORM support and embedded
AES 256 bit encryption.
13.Offered LTO4 drive shall have native speed of 120MB/sec and a compressed speed
of 240 MB/sec for 2:1 compression.
14.Tape Library shall provide native Fiber connectivity to SAN Environment.
15.For optimal Performance. Tape Library shall provide native 4Gbps FC interface
connectivity to SAN switches.
16.Tape Library shall be offered with minimum of 96 slots and barcode reader.
17.Tape library shall support removable magazine and at-least 15 mail slots.
18.Tape Library shall have GUI Front panel.
19.Tape Library shall have option for redundant power supply.
8.6.14 Backup Software Specifications

8.6.14.1 The proposed Backup Software should be available on various OS platforms such as
Windows and UNIX platforms and be capable of supporting SAN based backup / restore
from various platforms including UNIX , HP-UX, Linux, NetWare and Windows.
8.6.14.2 Proposed backup solution shall be offered with Cluster license of server.

8.6.14.3 Proposed backup solution shall have same GUI across heterogeneous platform to
ensure easy administration.
8.6.14.4 The proposed Backup Solution supports the capability to write up to 32 data streams to
a single tape device or multiple tape devices in parallel from multiple clients to leverage the
throughput of the Drives using Multiplexing technology.
8.6.14.5 The proposed backup solution should allow creating tape clone facility after the backup
process.
8.6.14.6 Backup solution shall be configured in such a fashion that no extra license for Client and
media servers is required while moving from LAN to SAN based backup.
8.6.14.7 The proposed backup solution shall be offered with unlimited client and Media
(Both Cluster and standalone) or at least 100 Client and Media license (Both Cluster and
standalone) for SAN based backup and LAN based backup.
8.6.14.8 The proposed Backup Solution Software has inbuilt Java / Web based GUI for
centralized management of backup domain.
8.6.14.9 The proposed solution also supports advanced Disk staging.

8.6.14.10
8.6.14.11 Backup Software is able to rebuild the Backup Database/Catalog from tapes in the
event of catalog loss/corruption.
8.6.14.12 The proposed Backup Software shall offer OPEN File Support for windows.
8.6.14.13 The proposed Backup Solution has certified “Hot-Online” backup solution for
different type of Databases such as Oracle, MS SQL, Sybase etc
8.6.14.14 Backup software shall also support Microsoft Share point Portal server & shall
have integration with Microsoft Data Protection Manager.
8.6.14.15 The solution shall provide with the unlimited or at-least 100 licenses for Bare Metal
restore for windows servers.
8.6.14.16 The Proposed backup solution shall provide granularity of single file restore.
8.6.14.17 The Proposed backup solution shall be designed in such a fashion so that every
client/server in a SAN can share the robotic.
8.6.14.18 Application vendors and hardware vendors shall provide written support stating
that their applications shall be supported on the given platform for the next 5 years
with effect from the date of project completion, and that upgrades shall be made
available on this platform for this period.
8.6.14
8.6.15 N+1 server instance of an application shall not be running on the

same box where its main server instance is running.
8.6.16 Different blades, for the same application shall be placed in

minimum two different shelves.
8.6.17 Standalone servers may also be deployed for edge application.
8.6.18 All the chassis supplied for housing the networking equipment,
Servers etc shall be housed in standard OEM racks.

8.6.19 All the hardware items (including network equipments) which are
supplied by the SI shall be brand new. SI shall not supply any Refurbished or second
hand item.
8.6.20
8.6.21 Bidders are required to provide the price breakup of the Data
Center Class Servers in a separate annexure to the price schedule at least in terms of
following sub-items:
a. Server Box
b. Core
c. RAM
d. Power Supply units
e. Other Modules
8.6.22 BSNL, if required, shall procure additional capacity based on this price
breakup of sub-items. In case bidder do not indicate the breakup for any
sub-item, the same shall have to be provided free of cost and in case if
such sub-item is short quoted then the loading principle as defined
elsewhere in the Tender document will be applied.
8.6.23 In case of Edge Applications, each application is to be configured

in N+1 environment for high availability where N should not be more than 5.
8.6.24 The vendor has to supply N+1 severs for all application running
on same OS taken together running on Edge servers i.e. to say for ex. If 23 servers
are required for all the applications on same OS then 5 servers shall be provided as
fail over taking in to consideration the OS required for different application.
8.7 Software
8.7.1 The detailed requirement from various software applications is
available under various sub parts of Section VI of this tender
document.
8.7.2 Software applications shall be near linear scalable with multi-

layered and multi-tiers, distributed, component-based architecture for reusability and
scalability with full support to clustered, failover and load balancing architecture.
Scalability to the required throughputs shall be done through configuration only.
8.7.3 Provision shall exist for on-line and batch methods of feeding all
types of data in each application. Generally batch mode of feeding data shall be file
based unless otherwise specified. Provisioning system shall be capable of provision in
all Transmission network elements
8.7.4 The system integrator shall furnish the documentary proof of

having tie-up with original software vendors with agreement for extending unequivocal
support and customization as per the tender requirement.
8.7.5 The System integrator shall ensure the software support

available for critical faults 24 hours a day, 7 day a week & 365 days a year for all
software.
8.7.6 SI shall ensure that patches, updates and upgrades are regularly
loaded on to the system as and when available. Patches, updates and upgrades shall
have to be provided free of cost till the completion of the AMC period. For all practical
purposes, a “Patch” will be defined as minor modifications to the Licensed Product

made by the Product Vendor during the performance of error correction services and
an “Update” shall mean a release of the Licensed Product which contains mainly error
corrections and may contain some minor functionality enhancements. “Upgrade” of
the software product shall mean a new release of the Licensed Product that involves
the addition and / or enhanced functionality and might involve migration from the
lower version to the higher version. Any replacement of hardware, if required for
support of patches, updates and upgrades shall be carried out free of cost.
8.7.7 All operational and Maintenance activities shall be done through

GUI/tested back end upload tools.
8.7.8 All the software system shall have easy integration capability by
supporting industry standard open transport technologies and middleware product.
8.7.9 The software systems shall offer the capability to import and
export information to/from external files or system.
8.7.10 Software Systems should have capability to apply software or

parameter changes without stopping the system.
8.7.11 Software System shall support clear demarcation for the core
layer and the customization layer. All business process reengineering shall be done
through customization layer. All future versions shall have backward compatibility to
ensure safe upgrades.
8.7.12 All the software customization required to meet the business

needs of BSNL, for the system supplied shall be done by the vendor till the contract
period.
8.7.13 It shall be possible to configure various parameters as per

business needs on a template to be provided and supported by all software solutions
for majority of the requirements.
8.7.14 The Software Systems shall be able to scale both vertically and
horizontally in order to utilize in-box capability of Servers (hardware) and if required
by deploying additional Servers.
8.7.15 SI shall provide operational and monitoring tools for each and
every software & hardware system.
8.7.16 Mechanism to ensure overall application data integrity shall be

enumerated in the form of document and seamlessly implemented
across all the system.
8.7.17 It shall be possible to simultaneously add, update, delete, etc the

relevant information in multiple applications maintaining separate
databases and tables.
8.7.18 2-6 months live database shall be required for various

applications with the provision of near on-line and archiving the
database for the period beyond that. There will be centralized database
servers and application servers with provision of client connectivity up
to SSA and SDCA level.
8.7.19 If any functionality specified in the software specifications

requires any specific hardware not covered under Schedule of Requirement, same
shall have to be included by the bidder under the head “Any other item” in the
Schedule of requirement along with the details of such requirement.

8.7.20 If SI from its experience feels that certain software functionality
is not covered by the software specifications but is necessarily required for providing
an end to end solution, then such functionality shall have to be included under the
head “Any Other Item” in Schedule of Requirement along with details of such
requirement.
8.7.21 For all the applications bidder shall have arrangement with the
original software solution provider (SSP) for maintenance and upgrade to meet the
obligations under this tender.
8.7.22 Software version of the equipment being supplied shall be latest

& must be indicated.
8.7.23 All the modules and sub modules of all the software shall be
described in brief.
8.7.24 SI shall have to implement the latest Software Updates, normal

Upgrades and /or Patches from time to time at no extra cost to the Purchaser along
with associated hardware and memory upgrade necessary for maintaining the
software, at each site for the entire period of Warranty and also during the AMC
period. It shall be the responsibility of SI to get necessary acceptance testing of the
system done by BSNL for affected functionality of all systems after every
implementation of Software Updates, Upgrades and Patches.
8.7.25 Software domain creation shall be as per SSP's recommendation.
8.7.26 Bidder shall clearly specify (Application wise) the list of bundled
software such as RDBMS etc., for which otherwise separate licenses
would have been required. It shall be the responsibility of the bidder
to indemnify BSNL against litigation arising out with the original
software solution provider. In support of this requirement a certificate
taken from SSP who offers their application bundled with other
application (RDBMS etc) shall have to submit for each such
application along with the bid.
8.8 Software Licenses

8.8.1 All software licenses shall be in the name of BSNL.
8.8.2 Bidder has to calculate the total licensing requirement of

different software including RDBMS, OS etc as per the present volumetric
given in the tender document and the same shall be specified along with
basis for the licensing.
8.8.3 License is chargeable by vendors in different ways, some based

on number of servers on which the application is hosted, some on number of
CPUs on the server on which the application has been hosted, some on
number of users, some on combination of number of adapter so on. Details
of such charging methodology shall have to be furnished by the bidder in the
software costs. The details shall include the unit price of various component
based on which the comprehensive license cost has been calculated, and it
shall form the part of price bid. The licensing basis, which the bidder has
indicated in the price schedule, will only be considered for payment purpose
on pro-rata basis.
8.8.4 Bidder shall provide the License charging methodology for

integrating into eMS with North bound interfaces of type, CORBA (TMF 814),
OSI, SNMP, ACSII.

8.8.5 Bidder shall provide support for update to the NMS interface on
account of any update to the NBI interface of eMS during the period of
support.
8.8.6 For any version change in the software license of the Network
element, SI shall have to deliver operational training to BSNL designated
staff for making changes in the adapter.
8.8.7 Certified and licensed copies in the name of BSNL of the

application software, RDBMS and any other software required for each Billing
Centre & remote terminal as applicable with back up copy shall be supplied.
8.8.8 Bidder shall quote the software licenses to meet the specified
requirements of Billing Centers as per the basis defined in the schedule of
requirement.
8.8.9 Delivery of all the software licenses shall take place at main NMS
site i.e. Delhi only. Accordingly, software is not repeated in the Schedule of
Requirement items at the DR Data Center. However, two copies of the Media
for all the software (including OS and RDBMS) shall be separately delivered
at all the Data Centers.
8.9 FREEWARE
Bidder is permitted to use the following freeware in case the same are pre-
integrated in the application software. Bidder shall submit certificate in this
regard from OEM about continued support and to certify that the freeware will
meet all the requirements as laid out in the tender document. Bidder will also
take care of bugs, security loopholes, patches, etc.
Apache Web-Server and Tomcat Application Server

8.9.2 Sleepycat Database for LDAP.
8.9.3 Latest version of Bind
8.9.4 Latest Version of Sendmail, qmail.
8.10 Network
8.10.1 TCP/IP based intranet shall have to be built up for
collection of events from various EMS in BSNL network and for other
operational requirements. This will cover major BSNL buildings and
offices including SSA headquarters, SDCA etc.
8.10.2 There shall be AAA Server installed at NMS centers with prescribed rights to
the individual remote terminals and users. Log of the changes made from the
remote work stations shall be maintained at the NMS center.
8.10.3 Intranet so established shall have IP addresses from private addressing pool.
BSNL shall supply the IP address at the time of implementation.
8.10.4 Network Specification is for guidance purpose. SI shall propose an optimum

network design based on actual data collected during POC phase. Overall
network design shall in general follow the proposed topology. SI shall try to
use BSNL’s MPLS cloud as far as possible. Number of leased line should be as
minimum as possible.. However equipments shall strictly adhere to the
requirement mentioned in the specifications.
8.10.5 Total Quantity specified against different network components in

the schedule of requirement shall be considered for evaluation to arrive at the
lowest bidder. However, procurement of these items shall be as per the exact
requirement. However, if the bidder feels that any additional new item not
mentioned in the networking Schedule of Requirement is required then he can
add the same and quote along with the probable quantity in any other item
heading of price schedule & SoR.
8.10.6 Network routers and all other equipments directly connected to

the BSNL network shall have Interface approval from TEC. Certificates in this
regard shall have to be submitted along with the Acceptance of APO. However
no Type Approval Certificate is required for imported items.
8.11 Database
8.11.1 For various application envisaged in this tender document, SI is at liberty

to use any RDBMS with necessary components with minimum features as
enumerated below:
Work in failover mode over geographical locations.

Work in a distributed mode across multiple servers.
Work in a cluster mode
For multiple standby (backup) systems
8.11.1.5 Feature for graceful switchover and switchback between the primary and
the standby databases (without any direct intervention from the database
administrators)
For Management through Enterprise Management System.
All the APIs for integration with 3rd Party Applications shall be provided.
It shall allow the users to use the standby database for read-only access while the
synchronization between the primary and standby systems happen simultaneously.
Access to all RDBMS stored procedures shall be available through JDBC, ODBC, C and
Active X
Detailed documentation shall be provided for Database Management specific to the
project and the applications deployed.
GUI based tool shall be provided to manage, test and tune the database.
All the applications implemented shall have provision for optimizing the number of
static connections to the database using connection pooling. All the applications
implemented shall also optimize the duration of connection to the database by using
techniques like session time out.
The database shall be able to support partitioning of tables to support linear data
scalability and parallel utility processing.
11.2 RDBMS Procurement Strategy
8.11.2.1 SI shall calculate and quote for total number of Data Base
Licenses (Processor license) required for various application.
8.11.2.2 Bidder will have to sign a teaming agreement with RDBMS vendors
and get a support certificate in the prescribed format for various
RDBMS quoted in the tender and submit the same along with the
technical bid.

8.11.2.3 BSNL is having a rate contract with M/s Oracle. In case ORACLE is
quoted as RDBMS and, BSNL shall procure Oracle license through the
bidder of this tender at the lesser of the of BSNL’s rate contract price
and the quoted price by the bidder.
8.11.2.4 The price quoted by the SI shall be used for price evaluation of this
tender.
8.11.2.5 Payment for AMC charges shall be done as per the actual licenses
deployed. This payment shall be calculated from the per licenses AMC
price quoted by the bidder.
8.12 Integration
8.12.1BSNL acknowledges the availability of over lapping functionality in different
standard application modules. SI shall take utmost care in efficient
integration of all the functionality needed to fulfill the business
requirements of BSNL.
8.12.2 The integration hub (EAI) shall comprise next generation open reference
architecture, business processes, a common business data model, etc.
8.12.3 The integration matrix in respect of various modules is tabulated

below, which is expected to be the minimum integration requirement
assessed by BSNL. SI shall however add additional integration points if they
feel it inadequate to meet the operational requirement as per present and
future need of BSNL. Changes in the nature of interface may be allowed if
valid reasoning for the same is provided.
8.12.4 SI shall design the system based on the interface requirement as

enumerated above. In case any other interface is required, SI shall have to
clearly mention and provide the same to meet complete integration
requirement of various modules.
8.12.5 If during the implementation or operation or maintenance stage

it is found that there is additional requirement of interfaces to meet
operational need of the system, the same shall have to be deployed free of
cost.
8.12.6 Integration with various eMS and network elements: BSNL

is presently having a range of transmission network elements and eMS.
Proposed system should be integrated with all such elements that are existing
under installation and as well as planned. Indicative list of existing systems is
at annexure to this section.
8.13 Security
8.13.1 To achieve the security goals for its Transmission NOC System, BSNL aims to
deploy a multi-layered detailed security system covering the data center’s
physical and logical systems needs.
8.13.2 There shall be a system to regulate, detect and monitor the

entry and exit of personnel and to monitor the movement of authorized
personnel inside the Data centre. This shall be possible through the provision
of Closed circuit TV and Physical Access Control System (Smart Card
Technology).
8.13.3 Logical Security Solution of Data Centre shall protect its

individual components from outsider and insider attacks. For this purpose a
strong Security and Auditing system shall be provided, wherein detailed log of
all transactions shall be maintained. It shall be built on using external
components such as firewall, intrusion detection system, antivirus
management system etc.
8.13.4 Refer Specification for this purpose elsewhere in the document,

for details.
8.14 Test & Development Server

8.14.1 There shall be provision in the hardware for separate Development System
for each software application so that production system should not get
affected in case of application of patches, versions change etc.
8.14.2 The development server shall make provision for all different system software
platform used along with all required compliers and libraries. It shall have all
application software and utilities along with the provision to customize and
test the applications. It shall also have provision for version control and
version management.
8.14.3 There shall be provision in the hardware for training servers for each of the
software application used for
8.15 Power Supply Requirement

8.15.1 The power supply required for running the NMS Center and its components
will be provided by BSNL. The total power requirement for Air-conditioning
and different hardware equipments, quoted in this bid, to be installed at
the NMS NOC shall be clearly indicated by the bidders for each DC
separately in the bid. The bidder shall give the power requirement in KVA
and BTU requirement for each hardware component in a separate annexure
no. VI-I -3.
8.15.2 All the servers and other critical equipments shall have load
sharing, hot swappable and redundant power supplies.
8.15.3 The UPS system shall be in N+N configuration. There shall be

dual & completely independent electrical cabling from the N+N UPS system.
Power to the electrical load (Output of UPS) shall be fed through two set of
separate bus bars and entire cabling shall be based on dual power
methodology For the purpose of redundancy in power system, the N+N UPS
system shall work in load sharing or hot stand-by mode.
8.15.4 The capacity of N+N UPS shall be calculated as 125% of rated

load of all components of this project. Bidder shall distribute the whole load
(including 25% extra) in N (N=>2) equal capacity UPS, in N+N configuration.
UPS shall be SNMP v2/v3 compliant and shall be managed from central EMS.
For UPS details refer specification elsewhere in the tender document.
8.16 Support centers

8.16.1 In addition to system integrator’s support facility, all the
Hardware vendors shall have maintenance support Center facility
located near the city where the billing Center is situated on 24
Hours x 365 days basis.
8.16 NMS Center Operation (TBD)
8.16.1 SI shall have to undertake Operation of the entire NMS Center

activities during the complete Implementation phase till the commissioning
free of cost and during the warranty period on payment basis. The Service
requirement and its associated SLA during the Operation phase are mentioned
elsewhere in the tender document. The bidder shall provide quote on annual
basis for Data Center Operation for contract period.
8.16.2 SI shall have to prepare a detailed NMS NOC Operating

procedure document. This document shall lay down the activities, procedures
and processes required to manage individual data centers. This shall contain
all the activities to be followed to efficiently manage the Data center right
from the scratch to the point of delivery to the customers.
8.16.3 Well documented system & data base administration and security
policy shall be prepared for smooth functioning of Data center.
8.17 Operational manpower:
8.17.1 Each Data Center will operate on 24x7 basis. Core team of each data center
will consist of highly trained BSNL staff and personnel of System Integrator.
BSNL proposes to deploy adequate operational staff at each data center, and
personnel of varying skills shall be provided by the SI on need basis.
However, bidder shall have to propose an optimum staffing plan so as to
meet the BSNL’s requirements along with the bid.
8.17.2 In general the core areas of NMS Center functioning as understood may
broadly be divided into following heads:
8.17.2.1 System Administration & Database Administration (OS,DB,User

management etc)
8.17.2.2 Application management (Maintain various applications)
8.17.2.3 Hardware and Network equipment maintenance
8.17.2.4 Back-Up /Disaster Management
8.17.2 Minimum qualification of Operational manpower to be provided by SI, shall be

BE/B Tech/ MCA with at least 2 years of experience in the IT field.
8.17.3 Detailed role and responsibility of operational staff shall have to be indicated
by the bidder along with the bid, however BSNL reserves the right to get the
plans of bidder modified depending upon exact requirement.
8.18 Scalability
8.18.1 The system shall be near linear scalable as per the increase in network
elements and users without effecting performance in online and batch
process mode. It shall also support parallel servers for load balancing.
8.18.2 The system shall scale both in terms of number of network

elements and the number of users. There shall be no limitations on these two

accounts.
8.19 Reports
8.19.1 Every product specification has requirement of different types of

standard, user friendly reports, available either out of box or through a script
written by SSP/SI. In addition to this there shall be many more reports, which
shall be finalized during SRS and implementation Phase and SI shall have to
deliver the same.
8.19.2 User wise report of activity performed by a user shall be made

available.
8.19.3 An outline of reporting requirement is mentioned elsewhere in

the document.
8.20 Documentation
Bidder shall supply 1 sets of hard copy and 2 sets of soft copy (CD) of documents on
operation, maintenance and planning aspects of the entire system and its modules.
8.21 Any other Item if required

8.21.1 The requirement of equipment (Hardware as well as software)
mentioned in this bid document and in SOR gives only the minimum set of
equipment to be supplied as a mandatory requirement. It shall be the Bidder’s
responsibility to ensure that any additional item, hardware or software
required for achieving the tender requirements and defined & implied
performance level for the specified customer base and its growth, and for
integration with other software & hardware, is also supplied and is quoted in
the Bid Document as additional items under any other items of SOR.
8.21.2 In case during the execution of the project or thereafter during

Warranty/AMC it is found that any additional item (Hardware as well as
software) is required while the same is not quoted by the bidder, the same
shall be supplied by the bidder at no extra cost to the BSNL.
8.22 Points to be considered before quoting the prices for line

items:
8.22.1 Any item (Hardware and/ or software) found short or not quoted
but required for successful implementation in terms of specifications and
performance requirement has to be supplied free of cost at the earliest, so
that committed implementation schedule shall not get affected. In case the
implementation schedule is affected, Liquidity charges will be applied.
8.22.2 In case this situation of any hardware/software found short or

not quoted but required to meet the tender conditions, arises during warranty
and AMC period, the supplies, installation and commissioning of the relevant
hardware and software shall have to be made free of cost and completed
within 10 weeks from the date of detection of such shortfall/ inadequacy.
8.22.3 The bidder shall include any other hardware/software item

required for installing/commissioning the system, which are not appearing in
the Section V, Schedule of Requirement (BOM) and its details should be given
in the separate Annexure.

8.22.4 In case it is found that any item, not accounted for in the bid, is
needed for successful implementation of the project and achievement of the
desired performance of the various parameters, the same shall have to be
supplied by the bidder free of cost.
8.22.5 If at any stage it is discovered that the software licenses have

been under provisioned the additional licenses have to be supplied free of
cost.
8.22.6 Bidders should note that in the specification documents or

elsewhere, ability or capability means that such functionality shall have to be
delivered during implementation. Some of the service requirements may
involve extra implementation efforts in terms of service cost or hardware cost
for which there is no special mention in the Schedule of requirement; in such
cases clarifications in this regard shall have to be sought by the bidder during
the clarification stage of the tender to avoid any ambiguity.
8.22.7 Though every effort has been made to refer latest available TEC
GR for various items, but it will be the bidder’s responsibility to quote all
items which are meeting specifications as per latest available TEC GRs and its
amendments as on date of bid submission, in addition to whatever mentioned
in the tender document.
8.23 Roles and Responsibility of System Integrator

8.23.1 SI’s roles and responsibilities are given in various clauses below.
8.23.2 Provide a complete turnkey implementation and assume responsibility for all
integration and implementation issues in order to deliver an operable system.
8.23.3 Structured Data Cabling and power cabling at TX NMS NOC.
8.23.4 Establishment of TX NMS NOC to host the hardware and software required for
all applications enumerated in this tender.
8.23.5 Supply of all the software solutions as listed in the tender document along
with any other software required to run various sub-system of the data center
as per the design and architecture of the end to end solution.
8.23.6 All functionalities for various applications as stated in the individual

specifications need to be delivered through software implementation in this
project.
8.23.7 Rollout of the TCP/IP Intranet for event Collection from various EMS, Service
Provisioning in Transmission network element, Remote Access to Data Centre,
Access by users etc.
8.23.8 Configuration, Customization & Dry run of all the software applications as per
the business processes frozen during SRS. Start of operation under
implementation phase.
8.23.9 Establishment of Disaster recovery infrastructure at DR site.
8.23.10 Data Centre Operation in association with BSNL officials posted at DC during
and after the commissioning of Data Center as per detail given in this tender
elsewhere.
8.23.11 Training to BSNL staff

8.23.12 Provide Support Service for the entire system of the DC.
8.23.13 The bidder shall have to furnish detailed Statement of Work comprising
following essentials along with the bid document:
8.22.1 Project Scope

8.22.2 Phase wise :
i) Responsibility matrix
ii) Breakup of work
iii) Deliverables
iv) Program Management Team
v) Detailed Time lines
8.23.14 To ensure the completion of the entire implementation within the scheduled
time frame (phase wise) as mentioned in the tender fulfilling the entire tender
terms and conditions.
8.23.15 To ensure the system performance as per specification.
8.23.16 Design the System ensuring redundancy at all critical points to achieve set
system level performance.
8.23.17 Provide suitable flexibility in the system to cater to the evolving needs during
the operation phase.
8.23.18 Different functionality defined in various products specifications may be met

through some other software module and not through the module whose
specifications are under consideration. SI shall clearly mention the compliance
of all functional needs with a statement of work delineating which functions is
met by which module.
8.23.19 SI shall ensure deployment of a strong operations team with relevant domain
expertise during the execution and operation of the DC Infrastructure.
8.23.20 SI shall offer proven solution Architecture for all hardware and software
component of the project and provide strong local support.
8.23.21 In case a specific feature in one application (say billing) requires similar
feature in other application, SI shall ensure flow through.
8.23.22 The successful SI shall provide an overall Project Plan showing a timetable
for the proposed phases. A list of project phases will be provided, to include
at least the following:
8.23.22.1 Functional Specification and Business Models Mapping
8.23.22.2 Environment set-up
8.23.22.3 Product Installation, Configuration
8.23.22.4 Implementation GUI and Reference Tables
8.23.22.5 Training
8.23.22.6 Validation and Acceptance Tests (preparation & execution)
8.23.22.7 Production/Rollover
8.23.2 The bidders can seek clarifications, if there is any doubt about the Project
Scope, Out of Scope, interpretation, etc.
8.23.3 SI shall submit the list of SSPs to be engaged in delivery of the products
along with the bid.

8.24 BSNL’s Responsibility
8.24.1 Raised flooring, False Ceiling and other building modifications if required.
8.24.2 Provision of three phase feeder power line
8.24.3 DG set installation
8.24.4 Air-conditioning of the Data Center
8.24.5 Requisite furniture for the Data Center
8.24.6 Bandwidth for network connectivity and MPLS ports
8.24.7 Availability of North Bound Interfaces on the eMS systems.

8.25 Dimensioning Details
8.25.1 System dimensioning for hardware and software will have to be done based on
below mentioned parameters:
8.25.2 The bidder may collect data appropriate for dimensioning the hardware
from the existing processor dwell time/occupancy/ performance and storage
requirements of the running systems and guarantee that the hardware sizing
would not pose any limitation in realizing the performance sought.
8.25.3 The following assumptions are to be made while estimating the hardware
requirements, however the BSNL may change these assumptions and shall
intimate before final bid submission date.
S. No. Parameter Value

8.25.3.1 Alarm Rate 300 Peak Alarms / Second
100 Average Alarms/ Second
8.25.3.2 Nos of clients 1000
8.25.3.3 Concurrent Clients 500
8.25.3.4 Number of eMS to be Integrated 1000?
8.25.3.5 Number of NEs for to be integrated 1,00,000
8.25.3.6 Number of NEs for to be integrated 5,00,000
in future.
8.25.3.7 Number of Network Interfaces for 10,00,000?
Inventory.
8.25.3.8 Number of circuits to be provisioned 1000
/ Day
8.25.3.9 No of SLAS to be monitored. 50000
8.25.3.1 Polling interval 10/5 (minutes)
0
8.25.3.1
Alarm Suppression 40%
1
Assumptions for help desk:
8.25.3.1 No. of held desk users (response time 500

2 <5 sec)
8.25.3.1 Number of Tickets per day
3 10000
8.25.3.1 Retention of history data in system 1
4 (years)

8.25.3. Maximum processor loading 70%
1
8.26 System Performance Parameters Per NMS NOC
System availability
8.26.1 UPS 100%
8.26.2 EAI 99 %
8.26.3 Service Provisioning 99 %
8.26.4 EMS (Enterprise Management System) 99%
8.26.5 Network Equipment 99.99 %
8.26.6 PCs 95 %
8.26.7 Printer 95%
8.26.8 Hardware * 98%
8.26.9 Storage SAN Solution 99 %
8.26.1 Tape library 97 %
0
8.26.1 Web Infrastructure 99%
1
8.26.1 Security 99.99%
2
8.26.1 Other items 95 %
3
8.26.1 Network Elements within Data Center 99.99%
4 premises (Routers, modems, RAS, LAN
switch, etc.)
1 Systems/ sub-systems for which the availability is 99% shall not be down
for more than 12 hours in a month.
4 No single fault shall take longer than 4 hours to repair for non-critical
fault and 1 hour for critical faults. The clause pertains to all equipments
operational at Data Centers and Locations where Aggregation & Central
Routers are installed.
5 The desired system availability over a defined period shall be ensured.

Scheduled backup and other recovery functions must be clearly identified by
the vendor with business impact explanations enclosure.
8.27 Architectural aspects

8.27.1 In case a specific feature in one application requires similar feature in
other application, SI shall ensure flow through features.
8.27.2 As far as possible database architecture shall maintain single truth table
to avoid inconsistency between the databases. Snapshots of table and
database may be utilized to deliver performance level as mentioned in this
document.

8.27.3 Each application shall be configured to run on one or more partition
servers. Each application shall be deployed in N+1 cluster.
8.27.4 Bidder shall describe in detail how different components of the solution
offered shall be integrated.
8.27.5 System consoles shall be provided on the basis of 1 each for every DC
server and one for every 10 other servers at the each site.
8.27.6
8.27.7 Bidder shall have back to back agreement with each of the equipment/
solution providers individually, so that the respective product support for
operation/maintenance and upgrades is available to BSNL for seven years
(two year warranty and five years under AMC) excluding the implementation
period.
8.27.8 The functional requirements enumerated in the tender document are

based on the present business process. These might undergo some change by
the time of placement of PO and during the execution of the project. Such
Changes shall be implemented without any additional financial implications
during the implementation period.
8.27.9 Business application shall be modular and component based. This shall
allow BSNL to adapt to new technology and business logic for the present
requirements and evolving needs during the cBSNL’sse of operations.
8.27.10 All application chosen for implementation shall have open, standard and
published APIs such as C/C++, JAVA, EJB, XML, CORBA, Stored Procedure
and Software Development Kits (SDKs) for interfacing and integrating with
the various software components of the Data Centre.
8.27.11 Software system shall have EAI connectors/adapters to integrate with

chosen middleware where ever required. Software system shall provide
access to object models, database schemas, etc used in the different solutions
for easy customization and integration.
8.28 System Reliability

System design shall have:
8.28.1 Distributed architecture with No Single Point of Failure. It shall utilize the
hardware and software to its optimal capacity by using techniques like load-
balancing.
8.28.2 Capability to up-grade without any performance impact or downtime of the

production environment.
8.28.3 Horizontal and vertical scalability of applications.
8.28.4 Point-in-time recovery of databases due to hardware or software failure(s).
8.28.5 Unattended automatic shutdown and restart of core processes in case of

failure. Auto restart of application shall be possible after application failure or
power-up. Auto start feature shall be configurable.
8.28.6 Maintain data integrity in case of a failure of a single component or

application.

8.28.7 Automatic rerouting and reconnection of client applications in case of failure
of the server.
8.28.8 Ability to generate error messages for every error condition that can occur
within the system.
8.28.9 Support operations on a large national network infrastructure that includes

multiple locations and a variety of networks.
8.28.2 Applications shall be capable of running on a single server or on multiple

servers. It shall be possible to add additional servers/databases with the
growth in number of subscribers without any loss of performance and
functionality.
8.28.3 Software Applications shall be multi-threaded and multi-processing
8.28.4 Bidder shall provide sufficient servers to meet the estimated load and
performance. Requisite load balancing mechanism shall be available to allow
balancing of load for avoiding congestion and bottlenecks at the front-end and
data-base levels.
8.28.5 Requisite provisions for maintaining the state and consistency of data in
databases. Automated Data Consistency Checks and Cleansing shall be
performed on a regular basis, across the system to prevent corruption and
inconsistencies.
8.28.6 Notification to the operations team on critical errors that impact the normal
operation of the system. Notifications shall be given through alerts and
messages on consoles and also through email and SMS etc.
8.29 Consortium Members/ Partners/ Technology

Providers
8.29.1 Bidder shall submit along with the bid, the complete list partners formed for
bidding in this tender including but not limited to Hardware-Software Solution
Providers/ Technology Providers/ Consortium Members, etc. The bidder shall
furnish signed letters from all the partners stating their participation in the
said tender. The bidder shall have back-to-back agreement with each of the
partners individually, to ensure that respective product support for
implementation, operations, maintenance, spares and upgrades is available
to BSNL for a minimum period of 7 years excluding the period of
implementation from the date of commissioning the product/service. Each of
the partners shall also certify direct support of its respective products
supplied to BSNL for a period specified above, giving a clear road map. The
copies of the actual Teaming Agreement between the bidder and each of the
partner companies shall have to be submitted along with the tender bid. All
such agreements shall be signed by the respective authorized signatories of
the concerned companies. MOU is asked wrt formation of consortium while
Teaming agreement is required wrt different technology partners.
8.29.2 All consortium members/ solution providers/ partners of the SI shall have
to sign a MOU which gives detailed roles & responsibilities for project
deliverables for each partner. MoU has to be individually between bidder and
the OEM.
8.30 Project Phases and Work flow- Implementation Plan
The following is the high level manner in which the implementation for the

entire project shall be carried out:
8.30.1 Project Initiation

SI shall identify and deploy key people for Planning, monitoring,
supervision & execution of the project. SI shall provide detailed Roles &
Responsibilities of these people to BSNL.
8.30.2 Program Management Office - Setup

A strong Program Management structure will be a key deliverable from
the SI. In order to ensure that the Program Management Activity happens in a
planned manner SI needs to formulate plans and frameworks for the project
w.r.to to Resources organization structure, communication channels, Change
Management, Development Approach etc. These plans & frameworks would
cover:
8.30.2.1 Resource Mobilization
8.30.2.2 Prepare Program Work Plan
8.30.2.3 Prepare Program Organization Chart
8.30.2.4 Prepare Quality Plan
8.30.2.5 Prepare Program Policies & Standards
8.30.2.6 Prepare Management Reporting
8.30.2.7 Prepare Communications Plan
8.30.2.8 Prepare Systems Development Approach
8.30.2.9 Prepare Release Management & Deployment Plan
8.30.2.10 Prepare ResBSNL’sce Plan
8.30.2.11 Prepare Change Management Plan
8.30.2.12 Prepare Issue Management Plan
8.30.2.13 Prepare Problem Reporting & Defect Management
8.30.2.14 Prepare Configuration Management Plan
8.30.2.15 Prepare Infrastructure Management Plan
8.30.2.16 Prepare Invoicing & Collection Management
8.30.2.17 Prepare Risk Management Plan
8.30.2.18 Prepare Project Deliverables Inventory
8.30.3 Analysis & Requirements Study Phase
8.30.3.1 While BSNL plans a phased roll out the Service Requirement Specification
(SRS) shall be prepared to cater for the complete scope of the deployment.
SI shall gather/capture the detailed requirement from BSNL by way of
interacting with BSNL SMEs. SI shall study the entire business process,
network infrastructure, existing Hardware and software, migration
requirement and other details required for project implementation. SI shall
further translate the business process into exact requirement. Based on this
exercise and the product features, which it intends to offer, SI shall prepare a
gap register highlighting the major and minor gaps.
8.30.3.2 As an outcome of the above exercise, all these inputs will be

used to develop High Level Specification documents for Configuration,
Customization, Interfaces and Application Architecture Document (AAD).
8.30.3.3 Subsequently, all these documents will be submitted to BSNL for review and
final approval.
8.30.3.4 Apart from the above exercise, SI shall also suggest the best practices
based on e-TOM (enhanced Telecom Operation Map) framework for the
practices which are not exactly followed by BSNL.
8.30.4 Infrastructure Setup

8.30.4.1 This will be a parallel stage to the analysis and requirement analysis phase.
This phase involves the infrastructure setup at the Data center with respect
to the hardware, Network, other equipments, applications and 3rd party
software’s.
8.30.4.2 This will be the phase during which the hardware, Network and other
equipments will be delivered by the SI at the DC. BSNL will carry out the
validation of these equipments and will be installed after validation clearance
from BSNL.
8.30.5 Development Phase
8.30.5.1 After setting the infrastructure, the actual development work will
start for the various Components. This will include the configuration,
customization and interface development activities. Key stages in this
phase will include:
8.30.5.2 Pre-Development Workshop
8.30.5.3 Development of Low Level Design documents (LLDD) - All Components
8.30.5.4 Development of Test Plans & Test Cases - All Components
8.30.5.5 Development Activities for the individual components
8.30.5.6 Configuration of the individual components
8.30.5.7 Development of Interfaces for the individual components
8.30.5.8 Application Testing for the individual components
8.30.5.9
8.30.5.10 After the completion of this exercise SI shall have to ensure that
captured requirements shall either exist in the code or in the built- in
code
8.30.5.11 With the software developed as per BSNL requirements & the
data centers having been established, the deployment phase of the
project shall commence.
8.30.5.12 After User Acceptance testing, the system will be ready for
handover to BSNL.
8.30.5.13 Handover process shall include, apart from other items:
8.30.5.14 Finalize & sign-off on Handover process
8.30.5.15 Ensure transfer of relevant stores
8.30.5.16 Initiate the post-live warranty support program
8.30.6 Project Completion

8.30.6.1 Handover of the system and start of the warranty support
program will result in the completion of the Project.
8.31 Confidentiality
8.31.1 Bidder & its associates and the purchaser shall treat all documents / data /
software or part of them, which one may provide to the other, as strictly
confidential and maintain secrecy for the same.
8.31.2 Bidder & its associates and BSNL shall not publish, disclose any
information about, make available or otherwise dispose of the document /
data / software or any part or parts thereof to any third party, directly or
indirectly without prior written consent of the other party to this agreement.
8.31.3 Bidder & its associates shall restrict access to the

documents/data/software only to those of their employees to whom it will be
felt necessary and relevant for this project and shall draw the provision of this
undertaking to the personal attention of those of its employees to whom
access to the document/data/software will be granted.

Annexure-VI-I-1
(Support Certificate)
(To be given by all partners/vendors/OEMs/database vendors)
(On the Bidder’s Letter Head)
To,
Tendering Authority
BSNL
Subject: Transmission NOC
Sir,
It is to certify that the following hardware/software, for which M/s ……………. is the
OEM, has been quoted in BSNL’s (M/s ……..name of the bidder………) bid.
S.N. All Hardware/ Network/ Software System Model/ Version

1
2
3
…
We undertake to provide the following:
1. Full Professional Service Support for turnkey implementation of the project

covering all the above hardware/network/ software components, their Design,
Planning, Supply, Installation, customization, commissioning, integration with
other components of the project, migration, training, Operation for two years
and five year maintenance of system and project completion within the time
schedules specified in the tender document.
2. Preparation of all the documentation pertaining to planning, design,

engineering, customization, integration, installation, operations and
maintenance.
3. Support for operation, maintenance and upgrades is available as per terms and
conditions of Operation during warranty (2 years) and AMC (5 years) on 24x7
basis from the date of commissioning.
4. Applications shall be supported on the given platform (including OS and quoted

Database) for the next 8 years with effect from the date of project completion,
and that patches, release, updates and upgrades shall be made available on
this platform (including OS and quoted Database) for this period
We also certify that the agreement in the above respect has already been
signed with the OEM.
__________________________________
Signature of Authorized signatory of Bidder
_______________________________________________
Signature of Authorized signatory of OEM/ Country Manager of OEM
Name
Designation

Annexure-VI-I-2
(Sizing Certificate)
(To be given by application vendor i.e. OEM/SSP)
ON THE OEM’S/SSP LETTER HEAD
To
Tendering authority
BSNL
Subject: Transmission NOC - Certificate from OEM about sizing of hardware with
OEM’s application software.
Sir,
1. This is to certify that the solution and following hardware sizing quoted in the bid of
M/s ………….(Name of the Bidder………..), for the applications (including all the
modules), for which BSNL’s company, M/s …………………..is the OEM, is sufficient to
meet all the requirements mentioned in the tender. The details of the Applications and
Hardware are as under:
A. Production Sizing Phase 1

(__________) TX NMS NOC (Specify the location of NOC)
S.N Application Application Hardware Platform Licenses
. Software Version Required(Core Details Required (for
Name Clock speed, including OS software OEM)
type/make, RAM with version
& soft/hard & Database
partition) with version
B. Test & Development, Simulation Sizing: This shall include Cores/RAM/HDD etc for
T&D server with class of Cores i.e. DC class or edge class.
(Furnish separate details for different Data Center locations)
2. This is to also to certify that this application has been benchmarked on class/family
of the quoted hardware as on date.
___________________________
-----------------------------------
Signature of Authorized signatory of OEM/ Signature of the Authorized

signatory of
Country Manager of OEM/SSP HW OEM/Country Manager of
OEM
Name Name
Designation Designation

Annexure VI-I-3
Power & BTU Table

(To be given separately for Main and DR TX NMS NOC)
TX NMS NOC name (Delhi/Bangalore)
Power & BTU
Hardware No. of Power Total BTU Total BTUs

Name Units required Power in required
per unit KVA per unit
DC Server 1
DC Server 2
……………..
Edge Server 1
Edge Server2
……………...
Networking
Equipments
Desk tops/
Workstations
Printers
Grand Total
UPS and Battery calculation is also to be furnished in this annexure.

1. Backup Location considerations
1.1. The OSS solution shall be based on Application to Application failover

capability and not Storage replication.
1.2. The two specific active OSS systems located in different sites shall be used as
backups systems for each other.
1.3.
1.4. In case of disaster of one of the site, the following tasks have to be
performed:
1.5. eMS shall be reconfigured to send events to the DR site.
1.6. The operators shall connect to the backup site.

Section VI-T
Help Desk Management
Introduction
Helpdesk Solution is a incident logging and tracking system. It shall provide

multi-purpose support tools that can be used across the BSNL organization to
manage processes such as technical helpdesks, customer services, asset tracking
and facilities management.
Functional Requirements
2.1. Bidder shall provide for helpdesk licenses to meet the requirement of a total user
base of 500 in phase-l of this tender and another 500 in Year-2
2.2. System shall provide distributed database capability, allowing multiple sites to
synchronize subsets of users' data. It shall be possible to define rules selectively
transfer business data between these servers. Integrity of the database shall be
ensured when deployed in distributed environment. The capability specified in the
clause shall be available, however Help Desk deployment shall be based on
centralized database.
2.3. System shall have LDAP support.
2.4. System shall have web interface for users, customers and other administrators
which shall support all the helpdesk functionalities including analysis and
reporting
2.5. System shall be ITIL compliant. Verifiable proof that the helpdesk is ITIL
compliant shall be submitted.
2.6. System shall manage the relationships between user problems and network and
services events.
2.7. System shall integrate with NMS. Integration with the NMS shall be bi-directional
so that both the systems are synchronized at all times
2.8. Single customer care view must manage business logic independent of
downstream application logic
2.9. It shall provide workflow and business process orchestration and automation
2.10. Help Desk Management System shall provide the interface to backend systems
for the customer care agents.
2.11. It shall provide single sign-on feature and shall store single sign on credentials.
2.12. It shall provide integrated authentication and authorization for agent roles and
applications by means of Enterprise Single Sign-On and the Active Directory®
directory service.
2.13. System shall have smart client technology for CSR Desktops however the same
system shall provide the web based self care functionality for the subscribers.
2.14. The system must support access to data through increasing diversity of channels
using a common business logic layer in a SOA Compliant architecture.
2.15. It should be possible to design Web-capable forms and distribute them on

corporate intranets, extranets, or the Internet. Users can fill out forms in a
browser with no download or client components needed.
2.16. Native support for Web services and customer-defined XML schemas should
makes it easy to integrate form data with many back-end systems using Web
[Transmission NOC] [Bidder’s Signature] [Section VI (T)] Page 93 of 183

services.
2.17. It should provide Real-Time Presence functionality, displaying virtually

everywhere a person’s name in the portal, tells you in real time whether a person
is online and available for a telephone or audio conference call, instant
messaging, or two-way video conversation.
2.18. Trouble ticketing system shall be able to extract all incidents, resolution progress
reports and all affected services via its interface with the inventory system.
2.19. Trouble ticket shall be tracked in the helpdesk system till the cause of the outage
has been detected, repaired and the service restored.
2.20. In case the outage is self healing, the event management system shall notify the
help desk system and clear the trouble ticket automatically.
2.21. Whenever a problem is reported by a customer a unique trouble ticket ID shall be

generated by the system. This shall be intimated to the customer, so that he can
track the status on the basis of this ID
2.22. It shall be possible for Customers to submit and check the status of reported
problems through web interface.
2.23. System shall automatically track, log and escalate user interactions and requests.
2.24. CSRs shall be able to view, change the status of the calls, reassign / transfer the
trouble tickets to other CSRs or technical specialist through the web interface.
2.25. It shall be able to generate various customized Service Level Reports e.g. Open
Call Reports, Closed Call Reports, Problem Area / Location specific Reports.
2.26. It shall have the capability for accepting queries through various sBSNL’sces
including telephone, email or web interface.
2.27. Shall provide case categorization capabilities for the CSR to quickly and
consistently categorize incoming requests and problems etc using category, type,
urgency level and item menus etc.
2.28. Duplicate case tracking. Support staff can associate multiple instances to a single
problem and tie the resolution of multiple cases to the resolution of one case.
2.29. System shall check for tickets status and escalation and notify the management
or next level of support staff based on predefined Service Level Agreement (SLA)
which shall include criteria like service application, severity and customer etc.
2.30. It shall be possible for the queries and escalations to be assigned to CSR groups
or CSRs
2.31. It shall have bulletin board to allow CSRs, Managers and Customers to post and
review messages about critical issues. It shall be possible to track the time spent
on specific case.
2.32. Trouble ticketing system shall be able to escalate and track problems to the
support agencies external to BSNL

2.33. Trouble ticketing system shall interface with SLA and Performance management
systems to account for the period of network or service unavailability.
2.34. Trouble ticketing system shall be able to extract all incidents, resolution progress
reports and all affected services via its interface with the inventory system.
2.35. Life cycle of the case or trouble ticket shall include phases like opening,
suspension, closing and archiving which shall be tracked by the system.
2.36. Assignment, routing and escalation of trouble ticket shall be both automated and
manual and shall be based on pre-defined rules. Rules shall include the case of
escalation when estimated time to repair is not met.
2.37. The trouble tickets shall be attached to a work-flow where ever there are multiple
steps required for resolution.
2.38. FAX HANDLING: The integration of messages received by fax into the CSR Work
queue shall be provided. Sending of fax messages directly from the agent
desktop shall be provided.
2.39. INBOUND & OUTBOUND CALL MANAGEMENT
REPORTING
3.1. System shall provide predefined reports for the proposed components.
3.2. System shall have the capability to access and query the database
3.3. It should make it easy to index and search any relational database or other
information store accessible by ADO.NET or a Web service; for example, data in a
CRM system.
3.4. System should be able to write custom protocol handlers or create searchable
HTML representations of information in a database.
3.5. Solution shall provide document management system required for the purpose.
WORKFLOW
4.1. System shall provide the ability for an administrator to customize its workflow via point-
and-click capabilities
4.2. Shall provide the ability for a CSR/administrator to customize his GUI using a
point-and-click interface to add and change windows, objects, and fields in
windows
4.3. System shall provide the ability to integrate the application with web portal,
eMS, NMS etc. using XML and lavaiC APIs etc
4.4. Workflow shall be able to perform notification via email, SMS, set fields, push
fields, SQL query, field's manipulations and calculation etc.
4.5. System shall provide the ability to develop workflow for data record create,
update, modify and delete operation. System shall provide the ability to develop
time driven workflow to perform data manipulations.
4.6. System shall have the capability to attach documents along with the trouble
ticket. System shall provide security at form, fields, workflow level

4.7. System shall provide approval engine so that any customized applications
developed could incorporate the hierarchy, role based, level based ad-hoc
approval structure. Shall include notification and escalation capability, if
approval is not performed.
4.8. It shall enable single sign on for all applications on the portal by integration with
directory services. It shall enable Trimmed-UI where the CSRs will only see what
access rights he/she has.
CHANGE/MAINTENANCE MANAGEMENT
5.1. System shall allow creation of change/maintenance tasks by the change/maintenance
supervisor for assignment to individual implementers. Change request shall be resolved
when all the change tasks are completed.
5.2. System shall allow advance planning of change/maintenance tasks. Individual

templates shall be available to facilitate planning. Implementers shall be
informed only when the tasks are actually scheduled after planning.
5.3. The scheduled tasks shall be automatically assigned to an individual

implementer or group based on the category. It shall be possible to enforce
dependencies between scheduled tasks where required
5.4. Enforce dependencies between change/maintenance requests where required.

System shall check for ticket status, escalate and notify the management or
next level of support staff based on predefined Service Level Agreement (SLA)
which will include criteria like service application, severity and customer etc.
5.5. System shall automatically notify the approver (Manager or Supervisor) when
there are pending change/maintenance request that requires their attention for
approval. System shall have the capability for the approver to designate another
person to act on his behalf during his absence.

Section VI-V
(Access Management)
1.0 Functional Requirements
1.1 These Access Management requirements will primarily be for Authentication,

Authorization, Access and single sign-on for web based applications for users
based on their roles to access application resBSNL’sces and content hosted on the
streaming solution and the Service Delivery Platform.
1.2 Access Management shall provide a centralized Authentication, authorization and

Access and Single Sign-On for users requesting for accessing various applications
as per their roles and policy.
1.3 Access management software shall be integrated with Identity management

Server for user Provisioning.
1.4 Access management solution shall take care of signing the user for all required
applications by providing a method requiring a single set of authentication
credentials (rather than one set for each application).
1.5 Access management shall have mechanism for Authentication and Authorization
of users based on their roles to access hardware and application resBSNL’sces in
the data center. The authentication shall be based on a PKI mechanism as well as
username & password in an encrypted manner.
1.6 The Access Management shall be provided for not only the users accessing the
applications from PCs but also from other devices such as PDAs, Mobile phones
etc.
1.7 The Access management shall have X.500 and LDAP compliant directory system
for storing user data and other attributes.
1.8 The solution shall adhere to standards for ease-of-integration with existing
systems and future IT investments. Native support for known industry standards,
such as aznAPI, JAAS, J2EE, LDAP, PKIX, x.509v3, Triple-DES encryption, SSL
and WAP is necessary.
1.9 The solution shall be highly scalable to adapt to growth in users, applications and
access methods.
1.10 The solution shall support multiple methods of authentication, including:
1.10.1 Secure ID token and PIN functionality

1.10.2 Certificates with certificate revocation list (CRL)
checking
1.10.3 Custom HTTP header
1.10.4 Wireless devices
1.10.5 Pluggable authentication for unique
authentication requirements, such as biometrics
1.10.6 Single sign-on (SSO) capabilities for both single
domain and cross domain
1.10.7 Federated identity capability. It should support
SAML protocol
[ Transmission NOC] [Bidder’s Signature] [Section VI (X)] Page 97 of 183

1.10.8 Automatic assignment of unique universal
identifiers to users, avoiding error-prone manual settings.
1.11 The solution shall support the following authorization features:

1.11.1 Encryption of all transmitted data
1.11.2 Authentication and authorization in pure Java 2, JAAS and J2EE environments
1.11.3 Unauthenticated users and role-based authorization
1.11.4 Control of access to dynamic Web content
1.11.5 Time-based, day-of-week-based, location-based and group-based authorization
1.11.6 Ability to create rule for access management without writing codes.
1.11.7 Granularity, enabling a single template to assign different permissions to
different users and groups
1.11.8 Automatic replication of policy changes to security enforcement points
1.11.9 Dynamic roles
1.12 The solution shall be able to secure any Web server running on any
platform.
1.13 The solution shall enable components to run on all major operating
systems, including Microsoft Windows NT, Microsoft Windows2000, IBM AIX, Sun
Solaris, HP-UX and Linux.
1.14 The solution shall provide comprehensive security for key Web products,
including portal, customer relationship management, enterprise resBSNL’sce
planning etc.
1.15 Integration and certification with security products (e.g., PKI, firewalls,
identity management and risk management) from the same and different
vendors, in order to easily construct an end-to-end security solution.
1.16 Integration with industry-leading Web application servers, such as

WebSphere Application Server and BEA WebLogic Server.
1.17 Support for the latest Web standards, such as Transport Layer Security
(TLS), SOAP transactions and Web Services Security.
1.18 The solution should provide a GUI interface for management.
2.0 AAA Server
2.1 The AAA server provides Authentication, Authorization and Accounting

services for network users dialing into the network from various nodes via the
Remote Access Servers.
2.2 The AAA server shall support standard RADIUS features. It shall be able to
interoperate with any RADIUS compliant clients.
2.3 It shall support an internal embedded database as well as support

common RDBMS through ODBC (Open Database Connectivity)
2.4 It shall have support for LDAP (Lightweight Directory Access Protocol).
2.5 The AAA server shall support extension points for integration with third
party products using custom scripts or programming language like C/C++.
2.6 The AAA server shall be capable of tracking user sessions and enforcing
session limits on a per-user or per-group basis.

2.7 The AAA server shall support interactive configuration. It shall also be
possible to automate configuration and integrate with the NMS/OSS system
deployed in the network.
2.8 The AAA server shall support allocation of IP addresses to users from a
shared pool.
2.9 The AAA server shall support high availability architecture. AAA servers
shall be deployed in N+1 redundant mode such that if the primary AAA server
fails, the client shall switch over to the secondary server. The primary server
shall automatically replicate its configuration to the secondary server to maintain
synchronization of data.
2.10 The AAA server shall be capable of creating and storing accounting records
in a single file or multiple files.
2.11 The AAA server shall maintain log files for all processes. It shall support
audit log of all configuration changes and logging of files to a syslog server.

Section VI-Y
Uninterrupted Power Supply
This specification describes a three-phase, on-line continuous operation, solid-state

uninterruptible power supply (UPS). The features of the UPS system shall be as below:
1.0 General
1.1. It shall be modular/standalone & online UPS, designed for 24x7 operation. Online
UPS means that the input AC power shall be subjected to process of inversion &
conversion to supply conditioned & pure sine wave AC supply to the load.
1.2. The UPS system shall be wired to supply conditioned and uninterrupted power
supply to all the application servers, network equipments, storage device,
workstations or any other device installed in the data center.
1.3. Proper ventilation/cooling arrangements to support continuous operation.
1.4. It shall be housed in a self supporting structure made of steel. It shall house all
the components of the UPS. Optionally batteries can be housed separately.
1.5. UPS shall be as TEC GR no. GR/UPS-01/03 May 2006 and amendments if any.
1.6. Battery backup available shall be for 1 hour for full load. Batteries supplied shall
be maintenance free VRLA Batteries and shall be as per TEC GR No. GR/Bat-
02/02 Mar 2006 with amendments if any.
1.7. It shall condition the power supply by regulating the power factor & harmonics in
the input mains power supply.
1.8. It shall be 3-phase input & 3-phase output power supply UPS system
1.9. It shall have high availability through intelligent precision-charging that
maximizes battery performance, life, and reliability.
2.0 Parameters
2.1 Input Power Supply:
2.1.1. Nominal voltage shall be 415 V AC ( +10% to -15%), 3 Phase & neutral
2.1.2. Minimum 0.98 lagging on 100% load.( Power factor correction equipment can be
put in to use, if required)
2.1.3. Input current harmonic distortion less than 2% max for linear loads & less than
5% max for non linear loads.
2.1.4. Input power harmonics shall be less than 5%.
2.1.5. Input Frequency: It shall operate satisfactorily at input supply frequency of 50Hz
+/- 6%
2.2 Output Power Supply:
2.2.1. Nominal output voltage shall be 380/ 400/ 415 V AC , 3 phase and
neutral (adjustable steplessly) with ± 1% accuracy.
2.2.2. Output waveform shall be true sine wave.
2.2.3. UPS Output shall be isolated from UPS input through an isolation
transformer.
2.2.4. Output Frequency: UPS shall provide 50 Hz +/- 0.5 Hz free running
(battery operation)output .
2.2.5. It shall support unbalanced load. Load unbalance of 50% shall not trip
the UPS i.e. if a load on one of the three phases is ‘x’ kVA then a load of x/2
shall not trip the UPS.
2.2.6. It shall be able to supply 150% overload for atleast 60 seconds and
shall supply 125% overload for atleast 10 minutes.. This enables the system to
handle inrush currents, sudden peak loads and output faults without transitioning
to bypass.
2.2.7. Acoustics noise generated from the operation of the UPS shall be less
than 65 dbA typically, measured at 1 meter from the UPS.
[Transmission NOC] [Bidder’s Signature] [Section VI (Y)] Page 100 of 183

2.2.8. The UPS shall operate with an efficiency of more than 90% at 75% of the rated
load.
2.2.9. There shall be a provision of static bypass (automatic) with voltage
rating of 380/400/415 V AC ,3 phase & neutral +/- 10% . Bypass arrangement
shall be through an external static bypass panel to enable delinking any UPS in
the network without disturbing the load.
3.0 Architecture
3.1 Entire UPS system shall be supplied in N+N (N ≥2) configuration based on actual
KVA requirements as calculated by the bidder.
3.2 If bidder feels that N+N configuration of UPS system shall not meet the 100%
availability criterion, they shall quote a higher redundancy configuration.
3.3 Total UPS shall be supplied in units of capacity as mentioned in SOR for Primary,
Intermediate and DR site.
4.0 Manageability
4.1 It shall provide for redundant serial ports for manageability by EMS of
the data center. UPS shall be SNMP compliant for SNMP trap etc.
4.2 It shall have provision for remote management of the UPS over the
network
4.3 It shall allow management of the UPS locally through a text-based
display that allows quick diagnosis via stored alarm conditions and events
4.4 The UPS shall indicate if the unit is on battery, if the battery is low or if
there is an overload condition.
4.5 The UPS shall monitor the health and status of the external batteries
and their expected runtime.
4.6 The UPS shall ensure early detection of potential problems by periodic
testing of UPS components
4.7 It shall prevent unauthorized access to the UPS through a suitably
designed rack system.
5.0 Protection Requirements
Output short circuit protection shall be there with fault isolation capability.
Input phase reversal protection.
Input voltage high/low protection.
Input surge/transient protection
Soft start or slow voltage transfer to generator.
5.6 Low Battery Voltage Protection to prevent total discharge or damage to the
battery, the UPS must stop supplying to connected load when the battery voltage
reaches a set minimum voltage level (programmable).
[Transmission NOC] [Bidder’s Signature] [Section VI (Y)] Page 101 of 183

[GSM Phase.VI/ Part IV-OSS & BSS] [Bidder’s Signature] [Section VI (AA] Page 102 of 183
sction VI-BB
Network Requirement
1.1 Backbone Router
1.1.1 The Backbone router provides the connectivity from the NIB-2 MPLS
network to the NMS NOC. The connectivity is through GE/FE /STM-1 or E3 WAN
links from the two nearest MPLS Edge Routers. The connectivity to the Firewall is
through Gigabit Ethernet ports.
1.1.2 The Backbone Router shall comply with all clauses of chapter 2 of
TEC GR No. GR/TCP-01/02 AUG 2003 for Internet Access Router. The bidder shall
provide a clause-by-clause compliance to the specifications.
1.1.3 The Backbone Router shall support the interface types given below.
The exact quantities required of each interface are given in the Schedule of
Requirements:
i. 10/100 mbps Ethernet interface.

ii. Gigabit Ethernet interface (optical)
iii. E1 with G.703 interface configurable for the following modes – clear channel
E1 and channelised E1.
iv. E3 interface.
v. STM-1 & STM-4 POS (Packet over SDH) interface (Optical).
1.1.4 The Backbone Router shall operate on 230V AC power supply
1.2 Ethernet Switch Type 1
1.2.1 The Ethernet Switch Type 1 provides connectivity to the servers,

Backbone routers, IDS, and other critical devices at the NMS NOC LAN. The
specifications of the Ethernet Switch Type 1 are given below.
1.2.2 The Ethernet Switch Type 1 shall comply with all clauses for LAN
Switch – High Range under chapter 2 of TEC GR No. G/LSW-01/02 OCT 2003. The
bidder shall provide a clause-by-clause compliance to the specifications.
1.2.3 The Ethernet Switch Type I shall comply with all security and QoS
specifications given under Managed Exchange Ethernet Switch category.
1.2.4 Each Ethernet Switch Type 1 shall be provided with the following
interfaces:
i. The necessary number of 10/100/1000 mbps Ethernet and Gigabit

Ethernet ports to connect all the servers and other devices in the Data center shall be
provided. Each server shall be connected in dual homed fashion to the two Ethernet
chassis. The 10/100/1000 mbps interface & Gig E interface shall be distributed over
minimum two modules of each type in each chassis.
ii. Minimum requirement of interfaces which are to be supplied, is given in
schedule of requirements. Any additional quantity of above mentioned interfaces to meet
RFP for Transmission NMS Page 103 of 183

the requirement of the tender shall be supplied at no additional cost.
iii. There shall be sufficient headroom in the chassis to allow further
expansion of upto 50% of the provisioned capacity by only adding interface modules
without requiring additional hardware (Chassis) and with no impact on performance.
1.2.5 The Ethernet Switch Type 1 shall operate on 230V AC power supply
1.3 Ethernet Switch Type 2
1.3.1 The Ethernet Switch Type 2 provides LAN connectivity to the RAS,
AAA, Web Application Servers, etc. The specifications of the Ethernet Switch Type 2
are given below.
1.3.2 The Ethernet Switch Type 2 switch shall comply with all clauses for
LAN Switch – Low Range under chapter 2 of TEC GR No. G/LSW-01/02 OCT 2003.
The bidder shall provide a clause-by-clause compliance to the specifications.
1.3.3 The Ethernet Switch shall support the following Security features:
i. Support for multiple password protected user access levels. It shall be possible to
define the access rights including list of permitted commands for each level.
ii. IEEE 802.1x port based Authentication to deny unauthorized connectivity and
802.1x Accounting for collecting connectivity information of users including
duration of connectivity.
iii. Prevent connection to the Ethernet switch by unauthorized stations by restricting
access to each port to a specified list of MAC addresses only. Up to 24 MAC
addresses shall be configurable on a per port basis.
iv. Prevent faulty workstations from flooding the network with unwanted traffic by
setting limits to broadcast, multicast and unicast traffic on a per port basis.
v. Support for SNMP version 3
1.3.4 Switch shall support the following Quality of Service features:
i) Traffic prioritization by providing multiple queues per port with configurable

bandwidth per queue.
ii) Ability to rate limit the bandwidth on each port to minimize congestion.
iii) Support for a minimum of 32 VLANs compliant with IEEE 802.1q.
iv) Support for IEEE 802.1s and 802.1w standards.
1.3.5 The Ethernet Switch Type 2 shall be provided with the

following interfaces:
i. 24 numbers of 10/100 mbps Ethernet ports.

ii. 2 numbers of Gigabit Ethernet ports (optical SX)
1.3.6 The Ethernet Switch Type 2 shall be provided in redundant
configuration. Wherever the connecting devices are provided with dual Ethernet
ports, they shall be dual homed to the two Ethernet switches Type 2.
1.3.7 The Ethernet Switch Type 2 shall operate on 230V AC power supply

1.4 Internet Router
1.4.1 The Internet router provides Internet connectivity from the NMS
NOC. It provides web access to certain applications for customers and other
external users. It terminates multiples E1/E3 or STM-1 WAN links from the
Internet. There shall be two Internet routers for each Data Center. It connects to
the Firewall in the Data center through 10/100 mbps Ethernet ports.
1.4.2 The Internet Router shall comply with all clauses of chapter 2 of TEC
GR No. GR/TCP-01/02 AUG 2003 for Internet Access Router. The bidder shall
provide a clause-by-clause compliance to the specifications.
1.4.3 The Internet Router shall comply with all security features specified
under the central Router category
1.4.4 The Internet Router shall support the interface types given below.
The exact quantities required of each interface are given in the Schedule of
Requirements:
i. 10/100 mbps Ethernet interface

ii. GE Ethernet interface Optical interface (SX)
iii. E1 with G.703 interface
iv. E3 interface.
v. STM-1 POS (Packet over SDH) interface (Optical).
1.4.5 The Internet Router shall operate on redundant 230V AC power
supply
1.5 Data Communication Network Management System (DCNMS)
1.5.1 The DCN shall be fully managed through a centralized Data

Communication Network Management System (DCNMS). The CDNMS will
interface the overall Enterprise Management System (EMS) of the the NOC at the
data Center. The DCNMS shall manage all the networking devices in the network
including routers, RAS and LAN switches. This shall comply with the following
specifications:
1.5.2 The DCNMS shall support the following Configuration Management

features:
i) The DMS shall maintain an active archive of configuration files for the managed
network devices.
ii) The DMS shall maintain information on multiple configuration files and
modifications made.
iii) It shall be able to export configuration files to 3rd party applications for modeling,
integrity checking, or generating reports
1.5.3 The DMS shall support the following Device Management features:
i) The DMS shall provide a GUI-based device management software application that
provides dynamic status, statistics, and comprehensive configuration information
for the managed devices.
ii) Graphically display a real-time physical view of managed network devices.
iii) Graphically displays connected network devices from a centralized network
management location, giving network managers a complete view of without
physically checking each device at remote sites.
iv) Graphical real-time monitoring and tracking of key information and data relating to

device performance, traffic, and usage, such as utilization percentage, frames
transmitted and received and errors
1.5.4 The DMS shall support the following Audit Management features
i) Provide a comprehensive audit of network changes reported chronologically

ii) Maintain records of modifications in the areas of hardware, software, and
configurations
1.5.5 The DMS shall support the following Inventory Management

features:
i) Inventory management of all network routers and switches

ii) Provide links to increasing levels of detail for each device, including device name,
chassis ID, free memory, software versions and serial numbers
iii) Capacity planning information
1.5.6 The DMS shall support the following Reliability Management features
i) User-defined views of critical device reachability.

ii) Drill down for reachability and response time history
iii) Links to detailed view of interface status
iv) Identifies offline devices and reports reloads and reason for reload
v) Display a graph of the Aggregation of protocol packets for routers.
1.5.7 The DMS shall support the following Log management features:
i) Provide links to remote syslog servers with customizable filtering of messages

ii) View syslog messages from devices.
iii) User-defined views of syslog messages for connected routers, switches and
firewalls, filtered by device, device type, message severity, and alert type.
iv) Default and custom reports by error type and severity.
v) Provides probable cause and recommended action.
1.5.8 The DMS shall support the following Packet Filtering Management
features:
a) Support for a policy template to simplifying the setup, management, and
optimization of IP packet filter lists.
b) Support for IP packet-filter list editor, policy template manager, list navigation
tools for troubleshooting, and automated Aggregation of filter list updates.
1.5.9 The DMS shall support the following Performance Monitoring features
i) The DMS shall allow the administrator to proactively troubleshoot network

response times.
ii) The DMS shall provide path and hop performance analysis by identifying devices
that are contributing to latency and network delays.
iii) Monitor and manage the effectiveness of quality of service (QoS) features based on
IP Precedence and troubleshooting network jitter related problems.

Section VI- Z
Hardware Requirement and specifications
Introduction
1.1 The specification of various servers as required in Schedule of requirement of this

document is given below. All Servers shall be housed in 42 U OEM Rack with
appropriate accessories for racking the servers with foldable TFT monitor. All
Enterprise and other servers shall support functioning with EMC make enterprise
class storage solutions working in BSNL data center.
1.2 All applications on DC Class & Edge class hardware shall have to be sized
accurately to meet the desired service level/ performance criteria at the full load.
In this regard SI shall furnish the sizing information and an undertaking duly
authenticated and signed by respective software vendor.
1.3 Bidders whose sizing does not meet the required service level / performance
criteria shall be required to provide additional hardware and software resBSNL’sces
at no additional cost to meet the desired performance levels.
1.4 Bidders are not allowed to quote hybrid type of CPUs/Cores in a single server box.
1.5 Bidders are not allowed to supply refurbished items.
1.6 BSNL would like to minimize the number of server models in the Datacenter. This
is for better management and serviceability.
1.7 File system, volume manger and cluster software will be supplied with servers to
meet the tender requirement.
1.8 BSNL acknowledges that there are two categories of applications which require
servers of different architecture:
1.8.1 Connection / Presentation Servers – Applications at this stage are multi instance
and scale horizontally - e.g., Application Servers, Web Servers etc
1.8.2 Datacenter Class Servers – Database servers where persistent data is stored and
manipulated in response to a client’s request. Database servers scale diagonally
i.e. scales vertically to an extent and horizontally beyond that.
High Availability Architecture for Data enter Servers
2.1 All applications shall fail over on to High availability Server in separate
partitions. In case of failure of any Application or Server, it shall be possible to
dynamically move CPU resBSNL’sces from other partitions to the High Availability
Partition without re-booting the system or partition.
2.2 Capacity of High Availability Server shall be calculated in a such a way that
in case of failure of any single application, it shall be possible to dynamically
allocate same amount of CPU resBSNL’sces (as in production) to the HA partition.
2.3 High availability cluster Partitions/Servers shall not be in the same footprint
running production applications.
2.4 Each partition of the High Availability Server shall have 2 nos. oft Gigabit
Ethernet adapters for public interconnect and 2 nos. of Gigabit Ethernet for cluster
interconnect
3. Data center class Server

3.1 It shall be at least dual core, 64 bit CPUs with minimum 64 cores and scalable up
to 128 cores in each server. Each core shall have clock speed of 1.6 Ghz or above,
having a minimum of 4 GB dedicated DDRII RAM per core. No of equipped cores
shall be as per ISV sizing.
3.2 Servers shall be populated with a maximum of only 80% of total cores capacity and
20% headroom shall be kept for future Scalability.
3.3 Servers offered shall be with the latest generation and highest clock speed
processors at the time of supply. (BSNL will accept faster than those quoted
against the tender however the quantity of the cores shall remain the same as that
of quoted cores. Before placement of order and before acceptance of Supply BSNL
reserves the right to verify availability of latest Model/Generation of Processor and
fastest clock speed available from the short listed vendor)
3.4 It shall have an operating system of any flavor of Unix Operating System.
3.5 It shall have dual power supply servers capable to run on either or both the power
supplies.
3.6 It shall be configurable with minimum 8 partitions. Each partition shall be capable
of dynamic increase and decrease in cores as per the requirement of the
application in future.
3.7 The partition shall be hardware/software based and it shall be possible to fully
isolate fault from each other. Each partition shall support at least 8 PCI-X/PCI-E
slots.
3.8 Each partition shall have two numbers of Gigabit Ethernet controllers for public
interconnect and two numbers of Gigabit Ethernet controller dedicated for cluster
interconnect.
3.9 The Server/Partition shall have at least two numbers of 4 Gbps Fiber Channel
adapter. Database partitions shall have minimum of 4 fibre channel adapter per
partition. If application requires higher I/O throughput the server shall be
configured with an appropriate numbers of Fiber Channel adapters.
3.10 There shall be management feature for configuration and management of all
partitions within the server.
3.11 Same type of interfaces being used for a dedicated purpose shall be distributed in
at least two cards for redundancy purpose. For example if 4 fiber channel adapters
are to be provisioned in a partition then two cards shall be supplied with 2 fiber
channel adapters per card.
3.12 Each data base partition shall have minimum of 4 fiber channel ports to connect to
the storage device. If application requires higher I/O throughput the server shall be
configured with an appropriate numbers of Fiber Channel adapters.
3.13 It shall also have fBSNL’s 10/100/1000 mbps Ethernet ports per partition.
3.14 The application provider shall certify that the server quoted is sufficient to meet the
tender requirements in terms of a sizing certificate with details like number of
cores, RAM, OS and database size required.
3.15 The bidder shall supply all requisite software like OS, clustering software. These
software shall be able to work with leading brand of Storage Area Network (SAN)
systems like HP, EMC, IBM etc.

3.16 Offered system / processors shall have a clear road map for next 5 years.
3.17 Minimum 4 Hot Swap/ 4 Spare Core shall be provided.
3.18 Each partition to have Dual Mirrored disk of at least 146 GB capacity. Mirrored disk
shall not be connected to the same controller.
3.19 Each server to have 6X or higher DVD drive
3.20 Operating System
3.20.1 UNIX 98 and later version complied for 64-Bit Architecture, with
unlimited Systems user license.
3.20.2 Independent and isolated OS images shall be runs in each partition.
3.20.3 OS shall permit activation of additional processors without requiring

a reboot.
3.20.4 JBSNL’snaling file system and a volume manager shall be provided

with each server as to meet the tender requirements.
3.20.5 OS shall support online version upgrades.

3.20.6 OS shall be provided with cluster software to meet tender
requirements.
3.20.7 OS shall be provided with Server Management software.
3.20.8 OS to support online server upgrade and serviceability.
3.20.9 OS shall have ability to apply the patches online. Support Virtual IP
Address to help applications remain available if network adapter connection is
lost.
3.20.10 Shall support IP fail over
3.20.11 OS shall permit activation of additional processors without requiring
a reboot.
3.20.12 JBSNL’snaling file system and a volume manager shall be provided
with each server
3.20.13 OS shall support secure shell
3.20.14 OS shall support IPV6
3.20.15 OS shall have ability to apply the patches online.
Edge Application Server
4.1 These shall be 64 bit CPU with clock speed of 1.4 GHz or above servers, with each
server having minimum 8 cores, 32 GB RAM.
4.2 The server shall have dual redundant 146GB internal disks in mirror mode
4.3 The server shall have n+1 power supply
4.4 The server shall be supplied with minimum 4 nos. of GbE Ethernet ports.
4.5 The server shall be configured with dual redundant 4 Gbps FC adapters.
4.6 CD ROM Drive
4.7 2 Console Ports Remote /local
4.8 Management Module with 1 FE (Field Engineer) port
4.9 42U OEM rack
Consoles for server
5.1 PC based Management Consoles for DC class servers and Edge servers are required
as per dimensioning details provided under Section VI-I.
5.2 Full Server Console features (as available in a direct

connected console terminal) including power on and off shall be made available.
5.3 The Management console will be connected to the servers using
dedicated Ethernet switched network.
Work stations/Desktop
Work Station specifications are given below:

Processor Dual core 2.8 GHz or better, 4 MB, 800 MHz FSB
Motherboard OEM mother board
Memory 1 GB DDR2 SDRAM @ 533 MHz dual channel or more
expandable to 4 GB
Cabinet Mini tower
Hard Disk Drive 160 GB SATA SMART III 7200 rpm
DVD ROM drive 8x or betterDVD ROM drive
Graphics Integrated (on board) Media Accelerator 900
Audio Integrated (on board) Audio controller with Internal speaker
Ethernet/network Integrated (on-board) 10/100/1000 controller with remote
ing booting facility, remote system installation, remote wake up.
Slots Integrated Graphics, Minimum 4 PCI slots with one PCI
Express Slot and one PCI Express Graphics Slot (x16)
Bays 4 Nos. (2 Nos. 5.25 inches for Optical media drive, 2 Nos. 3.5
inches for hard disk drives.
Ports 1 Parallel, 1 Serial, at least 6 USB (Version 2.0) ports with at
least 2 ports in front, VGA, Speaker, ports for Microphone and
Headphone, 2 PS/2 ports, 1 PS2 mouse port
Form Factor Micro/Mini Tower
Power Screen blanking, Hard disk and system idle mode in power
Management on, set up passwords, power supply SMPS Surge protected
Monitor 17”TFT LCD monitor with minimum 1280 x 1024 pixels
Keyboard PS/2 104 keys keyboard
Mouse PS/2, 2 Button Optical Scroll Mouse
Preloaded i. Pre installed Microsoft
software Windows Vista Business with Restore / Recovery CD ,OS
CD, documentation CD with each PC (in absence of OS
CD, OEM pack of OS to be supplied) and MS office
Professional 2007 or higher
ii. Norton, McAfee, Etrust or
equivalent Antivirus (Latest version) with 24 months
subscription
Recovery Tool Pre loaded software tool that has provision for scheduled
backup for restoring OS & data
Diagnostic Tool Pre installed OEM's Diagnostic tool for hardware diagnostics
Manageability OEM Tool that allows to centrally track, monitor & manage the
Tool h/w.
Security 1. Security loop
2. Removable media boot control
3. Serial, Parallel & USB Interface Control
4. Power-On Password
5. Setup Password
Additional An application for centralized monitoring of operators
Software activities

Section VI- AA
Storage Area Network
Introduction
1.1 The proposed Enterprise Storage system(s) shall be configured with storage
capacity to take care of storage requirements. The configured capacity on
enterprise storage system(s) shall be able to address the data storage
requirement, of production instances of various applications running in the data
center, on enterprise storage, their corresponding PIT Copy/BCV.
1.2 The overall availability of the entire SAN solution shall be 99%. Storage Area
Network (SAN) will comprise at least Mid-tier class Storage array, tape library, SAN
switch, various hardware and software to manage SAN etc. These are briefly
described in the subsequent clauses of this section.
Mid tier Storage Array
1.1 Vendors shall offer Mid-tier Storage arrays complying with the specifications for in
TEC GR/NO. GR/ESI-01/01.OCT.2005.
Tape Library
1.1. Offered Tape Library shall support Native data capacity of 72TB (uncompressed)
expandable to 144TB (compressed).
Tape Library shall provide web based remote monitoring capability.
The Tape Library unit shall be configured with FC LTO Gen4 Tape Drives.
Tape Library shall be configured with Two FC LTO4 drive scalable to fBSNL’s FC
LTO4 drives.
Tape Drive Architecture in the Library shall conform to Ultra3 SCSI standards.
Offered LTO4 drive in the Library shall conform to the Continuous and Data rate
matching technique for higher reliability.
Offered LTO4 drive in the library shall offer optional WORM support and embedded
AES 256 bit encryption.
Offered LTO4 drive shall have native speed of 120MB/sec and a compressed speed of
240 MB/sec for 2:1 compression.
Tape Library shall provide native Fiber connectivity to SAN Environment.
For optimal Performance. Tape Library shall provide native 4Gbps FC interface
connectivity to SAN switches.
Tape Library shall be offered with minimum of 96 slots and barcode reader.
Tape library shall support removable magazine and at-least 15 mail slots.
Tape Library shall have GUI Front panel.
Tape Library shall have option for redundant power supply.

8.12.7 Backup Software Specifications
6.2.1.2 The proposed Backup Software should be available on various OS platforms such as
Windows and UNIX platforms and be capable of supporting SAN based backup / restore from
various platforms including UNIX , HP-UX, Linux, NetWare and Windows.
6.2.1.3 Proposed backup solution shall be offered with Cluster license of server.
6.2.1.4 Proposed backup solution shall have same GUI across heterogeneous platform to
ensure easy administration.
6.2.1.5 The proposed Backup Solution supports the capability to write up to 32 data streams to
a single tape device or multiple tape devices in parallel from multiple clients to leverage the
throughput of the Drives using Multiplexing technology.
6.2.1.6 The proposed backup solution should allow creating tape clone facility after the backup
process.
6.2.1.7 Backup solution shall be configured in such a fashion that no extra license for Client
and media servers is required while moving from LAN to SAN based backup.
6.2.1.8 The proposed backup solution shall be offered with unlimited client and Media (Both
Cluster and standalone) or at least 100 Client and Media license (Both Cluster and standalone)
for SAN based backup and LAN based backup.
6.2.1.9 The proposed Backup Solution Software has inbuilt Java / Web based GUI for
centralized management of backup domain.
6.2.1.10 The proposed solution also supports advanced Disk staging.
6.2.1.11 Backup Software is able to rebuild the Backup Database/Catalog from tapes in the
event of catalog loss/corruption.
6.2.1.12 The proposed Backup Software shall offer OPEN File Support for windows.
6.2.1.13 The proposed Backup Solution has certified “Hot-Online” backup solution for different
type of Databases such as Oracle, MS SQL, Sybase etc
6.2.1.14 Backup software shall also support Microsoft Share point Portal server & shall have
integration with Microsoft Data Protection Manager.
6.2.1.15 The solution shall provide with the unlimited or at-least 100 licenses for Bare Metal
restore for windows servers.
6.2.1.16 The Proposed backup solution shall provide granularity of single file restore.
The Proposed backup solution shall be designed in such a fashion so that every client/server in a SAN
can share the robotic.
Fiber Channel SAN Switches
5.1 Vendors shall offer Fiber Channel SAN Switches complying with the specifications
for Fiber Channel Switches in TEC GR/NO. GR/ESI-01/01.OCT.2005.
5.2 In addition, the SAN Switches shall also have the following features:
i. Vendors shall provision SAN switches for connecting all the devices on the
SAN through Fiber Channel. At least two switches in redundant mode with
minimum 128 FC ports each shall be supplied at each location.
ii. Each FC port in the SAN switch shall support 4 GBPS throughput and

backward compatibility to 2 GBPS.
iii. The switch shall support the aggregation of ports on any module to provide
aggregated link.
iv. Switch shall support SNMP traps and management through/integration with
Element Management Software.
Software Features & Functionality
7.1 Centralized Management Software
7.1.1 Vendors shall offer Centralized Management Software complying with the
specifications for Storage ResBSNL’sce Management in TEC GR/NO. GR/ESI-
01/01.OCT.2005.
7.1.2 In addition, the software shall also have the following features:
i. It shall provide monitoring and performance reporting on multi-vendor hosts,

SAN switches and storage arrays
ii. It shall support open standards based management like CIM/SMI-S//SNMP
etc. and also support integration with popular Third Party Enterprise
Management Software (EMS) frameworks.
iii. It shall offer a Topology view providing an overview of the structure of the
Storage Area Network and be able to explore detailed resBSNL’sce properties
from topology objects and provide context-sensitive action menu to give
properties and more options.
iv. It shall be able to discover and visualize supported data backup servers, tape
libraries etc. and also be able to monitor multiple backup job status reports
on a single screen for supported backup applications.
7.2 Multiple Path Access Software for HBA Load Balancing & Auto Failover
7.2.1 The hosts connecting to the storage arrays with 2 or more HBAs shall be configured
with specific software for HBA load balancing, multi-pathing and auto failover.
7.2.2 This software shall allow multiple path I/O capabilities from the Host and also have
the ability to automatically detect and recover failed paths.
7.2.3 It shall provide dynamic load balancing and automatic path failover capabilities. It
shall support 24 or more paths from the hosts to the Storage system concurrently
per logical volume/device.
7.2.4 It shall have the ability to provide I/O prioritization for devices and automatic
channel failover from the host to the storage to ensure optimal application
performance.
Backup Solution
8.1 At least one Tape Library shall be proposed in the Primary Site, connected to the
SAN fabric, with quantity of drives and slots/cartridges as mentioned in this tender
document.
8.2 Backup Software along with licenses shall be provided for the purpose of backing
up data on to the disk library & tape library at Primary site.
8.3 Average daily archive logs – assuming additional 5% of production capacity –
would also need be backed up and retained for 3 months.
8.4 The Backup shall be staggered such that it can be completed in 5 backup windows
of 8 hours each in a week.
8.5 All backups shall be based on BCV / PIT Copy in enterprise SAN storage arrays.
8.6 Backup policy shall be decided at the SRS stage.
******

Section VI-DD
Large Screen Wall
1. The large screen display wall shall be located in the operation control room.
There shall be two screen walls per data center. Screen walls shall be used for the
display of important NMS and other data, graphics from the PCs, Workstation and
Video. It shall have the functionality to pre configure and save various display layouts
to be accessed at any given point of time with a simple mouse click.
2. The large screen display wall shall provide real time clear luminous view to
share information between users and decision makers.
3. The operators whose systems are on the same Ethernet shall be able to
work on the large screen sitting at their own position with his PC’s keyboard & mouse.
4. The large screen display wall shall be able to show the images of the PC
monitor, which is connected on the LAN and the windows shall be freely resizable and
re positioned on any part of the graphics wall.
5. The large screen display wall shall consist of multiple rear projection
modules in multiple rows and columns behaving as single or multiple logical screens.
It shall be possible to use any configurable number of visual display units for a display
input.
6. The large screen display wall shall be able to show the applications running
on Windows 2000, Windows XP, Windows NT 4, different UNIX flavors supporting X-
windows protocol and LINUX OS.
7. The large screen display wall shall be rugged and industrial nature and shall
be able to work in 24/7 environments.
8. The large screen display wall shall consist of the Visual display unit, control
ware and the wall management software as per following requirements:
VISUAL DISPLAY UNIT:
8.1.1 It shall have the scalability and upgradeability to be made up

of multiple rear projection modules stacked up in rows and columns to achieve a
display wall in linear or curved configuration
8.1.2 The minimum diagonal size of each visual display unit/rear

projection module shall be 50” with a native resolution of at least 1400 X 1050
pixels and shall offer in excess of 16 million colors.
8.1.3 Projection system shall have the ability to maintain consistent

image quality throughout the life of the projector.
8.1.4 The visual display unit/rear projection modules shall have in-
built dual lamp system and shall have dual lamps to ensure redundancy at the
lamp level.
8.1.5 The system shall be capable of automatic detection of lamp

failure and automatic lamp switching after lamp failure detection.
8.1.6 The lamp shall be hot swappable.
8.1.7 The brightness uniformity shall not be less than 95% & the
contrast ratio shall be minimum 1200:1

8.1.8 Each of the Rear projection modules shall have an optical
dimmer arrangement to adjust the brightness of individual projection module
automatically to have a completely uniform graphics wall without compromising the
contrast & colors.
8.1.9 The screen shall be high contrast and wide viewing angle. The
seam between adjacent screens achieved shall be less than 0.2mm using the
stitched screens. The screen surface shall not be reflective. The half gain angle of
the screen shall be ± 45° horizontal as well as vertical.
8.1.10 The input to projection module shall be Digital Visual

Interface-D (DVI-D) to have a flicker free image on the large screen display wall.
8.1.11 Each lamp shall be Ultra High Pressure lamp with minimum
luminance of 100 cd/sq m. or higher. The life of the lamp shall not be less than
6000 hours.
Display Controller
8.2.1. The Controller shall be in an industrial 19” rack mounted casing based on P IV 2.4
Ghz (or higher) processor.
8.2.2. The minimum random access memory of 1024 MB (standard) expandable upto 2
GB.
8.2.3. The unit shall be equipped with a 48X or better CD ROM.
8.2.4. The hard Disk supplied shall be of more than 60 GB, 7200 rpm.
8.2.5. The display controller shall have dual redundant hot swappable power supply.
8.2.6. It shall have two 10/100/1000 Mbps Ethernet ports for LAN connection.
8.2.7. It shall be supplied with a Keyboard and mouse with 20 m cable extension.
8.2.8. It shall operate on WINDOWS 2K/XP OS.
8.2.9. Dual redundant power supply in the display controller & each shall be hot
swappable.
8.2.10. It shall give multiple DVI graphics outputs to be connected to the multiple rear
projection modules and the no. of such graphics outputs shall be equal to the no.
of rear projection modules.
8.2.11. There shall be interfaces to connect to video (VHS / SVHA), RGB and DVI to this
controller to show the multiple RGB & Video sBSNL’sces in scalable and moveable
windows on the graphics wall.
8.3. Software
8.3.1 The software shall be able pre configure various display layouts and access
them at any time with a simple mouse click or based on the timer.
8.3.2 The software shall enable the users to see the desktop of the graphics display
wall remotely on the any WIN 2K PC connected with the Display Controller over the
Ethernet and change the size and position of the various windows being shown.
8.3.3 The software shall enable various operators to access the display wall from the

local keyboard and mouse of their WIN NT / 2K workstation connected with the
Display Controller on the Ethernet and should support open API.
8.3.4 The software shall copy the screen content of the workstation/PC connected to
the Ethernet, on the large screen display wall in scalable and moveable windows in
real time environment.
Pre Qualification Requirements:
8.4.1 The complete solution i.e. the projection modules, display controller and the
wall management software shall be from the same manufacturer to overcome any
compatibility issues.
8.4.2 The bidder shall have minimum 3 installations for the similar systems in the
control room environment.
8.4.3 Service support offices shall be present in major cities of India.
Line Item Description:
1 Rear Projection Module Sixteen

2 Display Controller Unit with required Softwares Two
3 Display Controller Extension Unit configured with Two
i. RGB Interface for Display Controller --- Two ports
with one interface cable(15 m)
ii. Video Interface for Display Controller --- FBSNL’s Ports
with one interface cable( 15 m)

Section VI-EE
Security System
1.0 Introduction
1.1 The growth of the Internet and the move to Web-based computing has brought
about new challenges to how Information technology is used by businesses.
Central to this deployment of IT is the data center management. With the increase
of security incidents against information technology the need to develop an
Information Security Management System to ensure the security of the data
centers has become imperative. An integrated approach in which security is
designed into the management process will help BSNL keep itself robust and ready
to handle all security and technology challenges to its Information Technology
deployments.
1.2 To achieve the security goals for its integrated Customer Care & Convergent Billing
System, BSNL aims to deploy a multi-layered detailed security system covering the
data center’s physical and logical systems needs.
2.0 Physical Security System
There shall be a system to regulate, detect and monitor the entry/exit of personnel
and to monitor the movement of authorized personnel inside the Data centre. This
shall be possible through the provision of Closed circuit TV and Physical Access
Control System (Biometrics Technology). BSNL will provide round the clock
physical manning of entry/exit points as per the requirement.
2.1 Physical Access Control System (PACS)
2.1.1 Components of PACS
2.1.1.1 Door Controller: It shall be an intelligent door open/close control mechanism on

stand alone basis and network mode (software selectable). It shall act upon
inputs from biometric scanner attached to it. It shall also be able to accept open
commands from a centralized location. All door controllers shall be networked to
pass attendance data to a connected database/Server.
2.1.1.2 Biometric Scanner: It shall be able to read the finger/thumb scan pass on the
result to the door controller or any other authorization unit for validation.
2.1.1.3 Electromagnetic Locks: It shall be a locking mechanism controlled by the door
controller .It shall be fail safe and shall allow doors to be opened freely in case
of failure.
2.1.1.4 Rodent Management System: This shall be a complete solution to prevent entry
and free movement of rodents inside the data center.
2.1.2 Specifications of PACS
SNO Specification
2.1.2.1 Biometric Scanner type - Optical Scanner Resolution - minimum 500 dpi or
above.
Sensors should be optimally designed with SEIR
(Surface Enhanced Irregular Reflection),
incorporating high resolution and endurance
(scratches, chemical corrosion, ESD, physical
impacts) and has been certified by International
Biometrics Group (IBG)
2.1.2.2 Support for Card reader Port Option and interface for card reader.

2.1.2.3 Support for attaching The Device should support two smart card readers
two smart card readers
2.1.2.4 Ability to store user Ability to store user fingerprint on Contactless

fingerprint credentials on mifare smart card in a secure way thus making it
smart card usable for unlimited users as the Fingerprint is now
stored on the contactless smart card.When the user
puts a smart card on the reader (For Access
Control/Attendance In Activity) the recorded
fingerprint template is read from the card. The
device then scans the actual user fingerprint. The
matching result between the two FP templates
authenticates the user. This also provides ability to
authenticate roaming employees. When the user
puts the smart card on the OUT reader (For Access
Control/Attendance OUT activity), the employee id
should be read from the card and based on this the
Door should open/Attendance marked.
2.1.2.5 LCD display 16x4 LCD Display
2.1.2.6 Should be able to show informations like current
date and time, verify passed or failed accesses
2.1.2.7 PC connectivity Should support advanced and fast TCP/IP LAN
networking and plugs directly into network
HUB/Switch. Should support connectivity options
like RS232, RS 485 etc.
2.1.2.8 ID Matching Methods Identification (1:N) : In this matching technique an
user comes to the device an can directly place his
finger onto the scanner for authentication, without
the need for punching in Employee ID or a
password before placing his finger onto the scanner
for finger print authentication. Hence in
identification process the algorithm shall match the
current finger print against all the finger print
present within the system. 1:N matching provides
convenience and freedom to the end user from
punching his employee Id or carrying any smart
card
2.1.2.9 Verification (1:1) : In this matching technique an
user comes to the device an first keys in his Emp-
ID or password or puts his smart card and then
places his finger on the scanner for fingerprint
authentication.Hence in verifiction process the
algorithm shall match the current Emp-ID with all
the Emp-ID and once the Emp-ID is found then it
shall scan the finger and try to match it with the
finger print stored in the data base against the
matched Emp-ID provided by the user.
2.1.2.10 1:N matching speed of min 100 and up to 300
finger print per sec
2.1.2.11 Mode of working Should be able to work in Standalone and
networked mode
2.1.2.12 In Stand alone mode the device act in an stand
alone mode and has no communication with the
PC /Server, it can add new users delete and modify
all by it self.

2.1.2.13 In Network Line mode the device is always online
with the PC / Server on real time basis . It shall be
remotely managed the device and add, delete
modify and Synchonise changes from the central PC
/Server with the device and visa versa.
2.1.2.14 Support for access The device should have the capability to send
control relays to electro magnetic locks for opening of
doors on positive finger print verification.
The device should be able to perform role based
access control according to day ,date, time and
person
2.1.2.15
2.1.2.16 Personalized You can leave messages for an individual via the
messaging system admin Interface specifying the date and timings
2.1.2.17 Buzzer Availability of buzzer sound to display for pass /
fail.
2.1.2.18 Central Management of multiple attendance terminals through central console
through LAN.
2.1.2.19 Authentication methods for user No FP,PW,,ARD,P / PW, P / CARD, PW /
can be set at any of the CARD, FP & PW,
following combinations FP & CARD, PW & CARD, FP & PW & CARD
where FP=Fingerprint, Card= Contact Less
Smart Card, PW= Password Authentication
2.1.2.20 Facility to register users from the central location using USB finger print
scanner and contact-less smart card writer. The registered users can be
pushed to specific attendance terminals.
2.1.2.21 Ability to push/export fingerprint template to selected attendance devices over
LAN through central console. This determines the terminals to which the user
has access.
2.1.2.22 Ability to set 1:N Fingerprint matching security level from level 1 to level 9.
Security level in FP matching determines the severity of matching between
stored FP template and lively acquired FP.
2.1.2.23 Ability to store user fingerprint on Contactless smart card in a secure way thus
making it usable for unlimited users as the Fingerprint is now stored on the
contactless smart card. Whe the user puts a smart card on the reader the
recorded fingerprint template is read from the card. The device then scans the
actual user fingerprint. The matching result between the two FP templates
authenticates the user. This also provides ability to authenticate roaming
employees.
2.1.2.24 Employee Masking: Ability to restrict employee access to any/all attendance
terminals.
2.1.2.25 Fingerprint auto snesor: Ability to sense fingerprint automatically without
pressing any button and fire the fingerprint sensor thus providing employee
convinience and faster authentication.
2.1.2.26 The logs generated on the device should be pushed to the central remote
manager software in real time. In case the central remote manager software is
not available the device should keep backup of logs. On availability of
Remotemanager the logs should be pushed to central server. The backup log
capacity of the deviec should be 20000 logs
2.1.2.27 Locks Supported- Strike type, Electromagnetic(EM) type
2.1.2.28 Supports auto door sensor to detect if the door is left open.
2.1.2.29 Visual LED indication to detect authentication Pass, Fail and device network
status.
2.1.3 Physical Access Control System based on biometric technology shall be sturdy,

maintenance free and easy to operate.
2.1.4 There shall be an arrangement to restrict entry to different areas of Data Center
through layered check points. S.I. shall elaborate the complete arrangement of
PACS vis-à-vis physical layout of Data Center.
2.1.5 It shall have secure management capability for console management & security
databases with sufficient check points
2.1.6 All mechanical system used shall have minimum wear and tear with very high
value of MTBF (more than 10 years)
2.1.7 PACS shall show default behavior in the event of a disaster eg. all physical
entry/exit points to be opened automatically .
2.1.8 Data base updation, auditing, alarms and reports like access and security breach
reports shall be possible in real time.
2.1.9 The same PACS shall be used to maintain attendance records. It shall be
possible to integrate the system with payroll application.
2.1.10 Supply of photo identity cum smart cards (approx. 500 nos.) ,during the
contract period , shall be made by the S.I.
2.1.11 The smart cards shall be programmed inside the Data Centre. The program for
cards shall be changeable as per the need and requirement of the Data Center.
Accordingly provision for hardware and software shall be made in Physical
Access Control System.
2.1.12 There shall be established controls to check for entry and exit of assets through
the security parameter. Exit of data in form of papers, USB pen drives, CD,
floppy etc. shall be prevented by using proper media destruction mechanism like
paper shredder etc.
2.1.13 The Data Centers shall have a mechanism in place to prevent the entry of
rodents from outside. The rodent prevention system shall also stop free
movement of rodents inside the data center with an elimination system which
kills the rodents.
2.1.14 Bidders shall provide Electronic Rodent Management System (ERMS) The ERMS
shall meet the following specifications:
a. The ERMS shall be a system of Master Console and Satellites/ Transducers.

b. The Master Consoles will be installed in the control room, and the satellites in the
problem areas.
c. Master Console: The Master console shall run on 230 V AC power connection. It
shall be connected to all satellite units which shall be minimum 10 in numbers to
feed them necessary signals.
d. Satellites Each shall cover an open area of min. 300 sq ft with average height of
the ceiling as 10 ft and shall cover a minimum area of 150 sq ft in case of false
ceiling roof. It shall be a 24 V exciter based system.
e. Peak frequency responses of each of the satellites shall be one or more of
frequency ranges as mentioned below:
i. 21.6 KHz +/- 3 KHz

ii. 31.6 KHz +/- 3 KHz
iii. 50.4 KHz +/- 3KHz
iv. 60 KHz +/- 3 KHz
f. It shall have uniform pressure output of 80dB to 110 dB with 3600 transmission
angle.
g. Linear propagation of mixed/ variable frequencies detectable at about 40 ft
distance from the sBSNL’sce (transducer/ satellite).
h. One system shall consist of one master console and at least 10 satellites.
i. The bidder shall supply the most suitable of frequency response systems (as
mentioned in clause (e) above) required at BSNL data centers.

2.2 Closed Circuit Television system
2.2.1 CCTV system shall ensure effective supervision of all important

areas and also to create a record for post event analysis. It shall
provide on line display of video images on a monitor system of
atleast 12 screen of 20’ size. Each screen shall be able to display the
name of the area under supervision.
2.2.2 The CCTV system shall be able to record minimum of two weeks of
data on 24 hour basis.
2.2.3 The cameras employed in the CCTV system shall be able to deliver
fine quality pictures for display and recording. The cameras shall
have minimum 16X optical zoom and minimum 8X electronic zoom
giving a minimum of 128X zoom function with auto focus and high
speed 360 degree pan/tilt function.
2.2.4 CCTV system shall have a Digital Multiplex Recorder (DMR)/System

based CCTV solution to control the recording operations centrally.
2.2.4.1 DMR shall have the capability to be networked and controlled/upgraded

from a remote workstation.
2.2.4.2 DMR shall have full access and control of cameras connected to it.
2.2.4.3 DMR shall be able to display user defined cameras in all multi screen modes
and as per selected sequence. It shall be able to play back in full screen, pic
in pic or quad multi screen display.
2.2.4.4 DMR shall be able to go back to a particular date and time. It shall have all
recording features like pause, FF, rewind etc.
2.2.4.5 DMR shall be able to hide user defined cameras through a super-user
password
3.0 Logical Security System
3.1 General
3.1.1 Logical Security Solution of Data Centre shall protect its individual
components from outsider and insider attacks. It shall be built on using external
components such as firewall, intrusion detection system, anti virus management
system, access control systems etc.
3.1.2 Security Solution should be based on “Defense in Depth (multiple
layer of security)” approach to implement effective protection strategy.
3.1.3 Comprehensive end to end security frame work shall ensure that
circumvention or failure of one component does not compromise the security of
rest of the system.
3.1.4 Any transaction involving an outside entity (e.g. internet access)
shall be passed through firewall systems and shall be secured using SSL frame
work.
3.1.5 Security Solution should have no single point of failure.
3.1.6 Security Solution should take care of Access Control of servers like
application servers and database servers.
3.1.7 Security Solution should be capable of providing comprehensive
reporting capability of Firewalls, Access Control System, Intrusion Detection
systems and anti virus/vulnerability management system.
3.1.8 All Security Devices should be capable of operating on Gigabit
networks without any security fallback and should be dimensioned to meet
performance parameters of mentioned elsewhere in the tender document.
3.1.9 All communications within the logical security system shall be

suitably encrypted to prevent any security breach.
3.1.10 The Security Solution should be centrally managed by a Security
Device Management System (SDMS) with provision for truly redundant highly
available management architectures.
3.1.11 The SDMS shall allow centralized management of components of the
security network like Firewalls, Intrusion Detection Systems, Access control
systems, Anti virus system etc.
3.1.12 The SDMS management shall be GUI base through a security policy
for configuration and up dation of network elements of the logical security system.
3.1.13 Security solution shall integrate seamlessly with Network
Management System controlling the Customer Care & Billing System of BSNL.
3.2 Firewall
3.2.1 It shall meet the TEC GR no. GR/FWS-01/01 SEP 2006 or the latest
available. The firewall shall be appliance based and shall facilitate multi-vendor,
multi-application environment and shall support third-party products.
3.2.2 The stateful inspection firewall must provide a means to define and
modify existing services and state engines.
3.2.3 Minimum number of rules/policies supported by the firewall shall be
70000.
3.2.4 Firewall shall support following performance parameters:
3.2.5 Minimum throughput of 5 Gbps. The performance shall be scalable to
2 times (10 Gbps).
3.2.6 Minimum 20,000 New connections per second scalable to 30,000
new connections
3.2.7 The firewall shall support minimum 1,000,000 concurrent sessions
3.2.8 The required performance of the firewall as described in clause 3.2.4
can be met by providing multiple firewalls. These multiple firewalls shall act as a
single unit providing all the functionality & specifications mentioned in this
document.
3.2.9 The firewall must have hardware assisted NAT.
3.2.10 Virtual firewall must support with minimum of 20 virtual firewall
instances.
3.2.11 The firewall shall be deployed as shown in the Data Center
Schematic diagram elsewhere. All critical Data Center equipment including servers
and LAN devices shall be connected to the “inside” or secure zone of the firewall.
All non-secure and general access servers shall be connected to the de-militarized
zone of the firewall. The “outside” interfaces of the firewall shall be connected to
the outside network containing the Backbone and Internet routers.
3.2.12 It shall support account management on the firewall module by
integrating with LDAP V3 compliant directories and other authentication systems.
3.2.13 It shall also support security for UDP communications occurring in
the network.
3.2.14 Firewall shall be supplied in 1+1 redundant configuration. Each
firewall units shall support active –active configuration and active-standby mode of
configuration for high availability & redundancy. There shall not be a single point
failure in the Firewall system.
3.2.15 Firewall Reporting: The Firewall reporting software should have
centralized reporting and log collection features to collect and report on Firewall
activity in various formats from a central server. The administrators should be able
to generate reports of various configurable parameters remotely
3.2.16 The Firewall shall be provided with interfaces as mentioned below:
a) 5 numbers of Gigabit Ethernet ports.
b) 2 numbers 10/100 mbps Ethernet ports
3.3 Network based IDS

3.3.1 Network based Intrusion Detection System shall meet TEC GR No.
GR/IDS-01/01 FEB.2003. It shall be appliance based NIDS capable of monitoring
multiple LAN network segments.
3.3.2 It shall act as a second level defense mechanism after the firewall in
the BSNL network.
3.3.3 IDS shall be deployed at strategic locations to provide maximum
security as indicated in Data Center Schematic diagram at Annexure VI-T(5).
Network traffic flowing into and out of the endpoint shall be monitored for network-
based attacks.
3.3.4 NIDS shall be provisioned to support at least 2 GBPS of traffic
monitoring on single IDS without any degradation in performance. The NIDS shall
detect unauthorized internal/external intrusion attempts into the data centers and
shall be able to apply appropriate policies on the firewall so as to prevent such
attacks in real time.
3.3.5 It shall be able to covertly monitor and report the activities of an
attacker in real time.
3.3.6 It shall enable stealth monitoring and containment plus live attack
analysis.
3.3.7 It shall monitor, detect and contain intrusions as they happen.
3.3.8 It shall be able to record sessions and play back for further analysis
3.3.9 The IDS probes shall be able to monitor and secure all ethernet LAN
segments to which it is connected.
3.3.10 The IDS shall be capable of detecting threats through stateful
pattern recognition and protocol analysis. It shall be able to monitor and detect
anomalies in protocols like TCP/IP, UDP, ICMP, FTP, SMTP, HTTP, DNS, NNTP,
Telnet etc.
3.3.11 It shall have signature based as well as protocol anomaly detection.
3.3.12 It shall be possible to customize & store signatures to enable the IDS
to detect and prevent new types of attacks. It shall also be possible to
automatically update the IDS probes with new signatures files through the Data
Center Security Management system(DMS), Secure links etc.
3.3.13 The IDS shall work through sniffer modules. Sniffer shall be able to
automatically respond to detected attacks through (1) termination of the offending
sessions, (2) sending alarms, SMS and emails to concerned personnel and the
security management console.
3.3.14 It should be able to handle concurrent sessions up to 1,000,000.
3.3.15 It should provide dual redundant power supply, device failure
detection, link loss detection, disk drive (removable), and passive mode failover.
3.3.16 It shall centrally manage multiple network sensors from single
management station
3.3.17 The NIDS shall be complete in all respects including database
signature files and shall be integrated and out of the box without any inter-
dependency on any other 3rd party software for its functioning
3.3.18 NIDS shall provide capability to filter out false positives once they
have been identified as such.
3.3.19 Each IDS probe shall be capable of handling minimum of one gbps
of throughput.
3.3.20 The IDS probe shall have required management interface to meet
the requirements of this document.
3.3.21 Shall log raw data locally for internal forensic analysis of attacks for
a period of at least 30 days.
3.3.22 It shall provide following, but not limited to, alerting mechanisms:
(i) E-mail alerts,
(ii) Real-time alerts,
(iii) SNMP notifications, etc.

3.4 Server Access Control System (SACS)
3.4.1 The SACS is a centralized system that controls access to the servers,
file systems and databases in the Billing data Center.
3.4.2 The SACS shall control access to all server system (all industry
standard OS) resBSNL’sces including applications, data files, devices,
processes/daemons, and audit files.
3.4.3 It shall intercept security-sensitive events in real-time, and evaluate

its validity before passing control to the OS.
3.4.4 It shall make no changes to the operating system kernel or binaries.

Software must allow for quick uninstall if necessary.
3.4.5 It shall be able to prevent hackers with root access from

circumventing or shutting down the security engine. Must use separate database
for storing all security information.
3.4.6 It shall allow controlling actions and access to resources of all users
including privileged accounts such as root / administrator.
3.4.7 It shall provide the ability to designate specific roles like

Administrators, Auditors, and Password Managers etc with appropriate rights. It
must also provide the ability to designate specific users as Subordinate or Group
Administrators, to manage users and file permissions for their Group
3.4.8 The SACS shall provide complete file protection by intercepting every
file access request and deciding if the user is authorized to access the file.
3.4.9 The SACS shall enable administrators to designate critical files that
when changed or modified, shall generate a suitable alarm and write an audit
record.
3.4.10 It shall support creation of rules for access permissions to various

file systems on per user and group profile basis.
3.4.11 Users shall be allowed to access the system resources as per the day
and time pre-described in the system.
3.4.12 It shall support management and policy distribution across multiple

platforms from a central management console. It must support the deployment of
the same policies across multiple servers ensuring consistency of security policies .
3.4.13 SACS shall support audit trail of all access activities. It shall track
user logins, logouts access to resources and track user names from initial
authentication to create secure and useful audit trails with full integrity. It shall
provide a monitoring mode to record activity of specific users.
3.4.14 It shall provide simple to use graphical interface to enable complete

management of all user, group, resource, audit and policy settings, either centrally
for an enterprise or de-centralized to departments or business units.
3.4.15 Host based IDS shall be able to log out a suspect or offending user
temporarily and disable the account with suitable alarm for the administrator.
3.5 User management

3.5.1 The functionality mentioned in this system can be offered through
Identity Management system/Access Management system as the case may be.
3.5.2 It shall provide simple to use graphical interface to enable complete

management of all user, group, resource, audit and policy settings, either centrally
for an enterprise or de-centralized to departments or business units.
3.5.3 It shall provide the facility to set accounts to expire on specific

dates, deactivate accounts on a configurable date or after a configurable amount of
inactive time, lock out accounts after multiple failed logins through a daemon,
restrict accounts logins during configurable times and days, deny access to
accounts based on company holidays.
3.5.4 The user's permissions must always be governed by the original

login ID. Taking over the root account should not grant the user any additional
privileges.
3.5.5 It shall enable the administrators to share subsets of root authority

among different administrators based on their functional roles.
3.5.6 It shall be possible to automate the creation of complex security

policies with point-and-click options including control over logins, password quality,
user and group access, system files, attack prevention, network and environments.
3.5.7 It shall enable fast addition, change, deletion and modifications to

users and groups across platforms, including synchronization with native operating
system settings.
3.5.8 It shall allow controlling actions and access to resources of all users
including privileged accounts such as root / administrator. Must track the "real
user" even in case of surrogates.
3.5.9 Some of the requirements stated above may be overlapping with

Identity Management System as defined in the Identity Management
Specifications.
5.0 Eligibility Criteria
5.0 Firewall: ICSA certifications

5.1 NIDS: ICSA certifications /CC EAL 3 certification.

Section VI-FF
Disaster Recovery
1.0 NMS NOC locations
Primary Site – Delhi

DR site (One for all) - Bangalore
2.0 DR Requirements
2.1 Disaster will be considered as an event that makes the continuation of normal
functions impossible. BSNL can declare a situation as Disaster if it becomes difficult
to run normal operation from a Data Centre.
2.2 Stack of Data Centre resources in terms of Hardware and Software at DR site shall
remain similar to the Primary site. All applications in the site where disaster has
occurred will fail over to the hardware installed at DR site. DR setup shall cover
unplanned as well as planned outages at reduced performance level as defined.
2.3 Each DR site shall have 100% redundant storage capacity to take care of the
requirement of each data centre. In case of any natural or manmade DR instance,
all critical functionality related to all applications shall switch over to the designated
DR site. The degradation of performance for the applications failing over to the DR
site is permitted up to 50%. For Mediation no degradation in performance is
permissible.
2.4
2.5 Enough precautions shall have to be taken to remove all single point of failure. In
spite of all that SI shall also define different disaster like situation when impact on
business is considerable because complete disruption of one or more element of DC
resulting into disruption of different services, considering correction time, recovery
time, business impact etc. restoration action has to be planned and documented
during the Project execution phase.
2.6
2.7 The distribution capability of NMS Solution shall provide by itself, and without any
customization or development, a first solution for Site Disaster Recovery.
2.8 The total NMS hardware and entities configurations shall be duplicated in two
different sites, the primary and the secondary site.
2.9 All the entities ( eMS, Operators, Configurations ..) shall be configured in both
sites.
2.10 Events from eMS shall be configured ( wherever possible ) to be sent to both sites.
2.11 In case of disaster, the operators shall connect to the secondary site.
2.12 The SI shall demonstrate its DR preparedness in following disaster scenarios:
2.13 A system / hardware failure at the primary site resulting in the system’s/
hardware’s unavailability.
2.14 Core equipment/ components failing at the primary data centre resulting in the
several systems of the primary site being affected/ unavailable.
2.15 Non-availability of the primary site as a result of a disaster restricted to that part

of the city.
2.16 Non-availability of the primary site due to disaster situation in the city where the
primary data centre is located.
2.17 The disaster scenario shall specify the contingency arrangements for people and
shall consider situations such as:
2.17.1 Non-availability of Data Centre operations team.
2.17.2 Non-availability of the key decision makers at the Primary site beyond a
significant time during a disaster.
2.18 Servers earmarked to take the load in case of disaster shall be pre or post
configured as per well documented DR plan prepared by SI in all respect for
quickest possible switch over which is maximum 3 days.
2.19 Actions to initiate Switchover to DR site and Switchback from DR to production site
shall be initiated manually.
2.20 Data replication from online storage of primary site to online storage of disaster
recovery site shall be in asynchronous mode and for mission critical data (as
defined elsewhere) shall be in synchronous mode.
2.21 Collection servers of mediation system shall have 100% redundancy. No

degradation of performance is permitted in case of collection.
2.22 Periodic backups of the Database data as per backup policy and Non-Database data
(System data, Application data, Business data) etc. are taken on tapes and kept in
safe storage outside the Data Centre.
2.23 Switchover or Switchback shall be completed in maximum 72 hours except for

Collection server (Mediation), which shall start within 3 hours.
2.24 SI shall document different unplanned outage scenario application and database
wise with probable solution to overcome the problem.
3.0
3.1
3.2
3.3
3.4
3.5
4.0 General
4.1 Data Centers will be dual homed to MPLS network through E3/STM-1 links to two
different points of presence. Bidder shall provide all the equipments such as
Routers/ modems/etc needed at the Data center for MPLS connectivity. Additional
bandwidth can be provided if requested for. The dual links can be dedicated also.
In such situation provision for additional link has to be made for other applications
such as CDR collection and system access etc.

4.2 It shall be possible to test the Disaster Recovery Function live every three months
as per DR Plan at any time without loss of any data or service being offered to
customer as per the degradation in performance permitted in case of actual
disaster.
4.3 It shall be possible to monitor the health of disaster recovery system from main
system and vice-versa continuously or under operator command through EMS.
4.4 Bidder shall frame detailed DR policies in consultation with BSNL and the same
shall be further tuned based on experience gathered during the implementation
phase and warranty phase.
4.5 The vendor must provide a detailed proposal in the technical bid to achieve the DR
objectives keeping in consideration the best practices followed in the similar
environment.
4.6 Bidder shall demonstrate the capability of the DR solution as part of the Proof of
concept.
4.7 Acceptance testing shall include drill DR and actual work on a mock DR situation
for duration of at least two weeks.
4.8 The bidders shall develop complete disaster recovery solution as per above
requirements, provide extensive documentation or process and procedures, carry
out business impact analysis, train BSNL people to handle DR situations and define
the associated manual processes which shall facilitate the switch over the DR site
as part of their scope of work.
4.9 The SI shall consider the following key factors while designing DR solutions:
4.9.1 Suitable optimization of resources required.
4.9.2 Minimization of the duration of a serious disruption to business operations.
4.9.3 Effective co-ordination of recovery tasks.
4.9.4 Reduction of the complexity of the recovery strategy.

Section VI-HH
Service Requirement and Operational SLA
Introduction
1.1 After the system is live for the usage of BSNL users, SI need to take care of
the Operation and Maintenance of the installed systems and software. SI also
needs to adhere to Service level agreement as indicated in the tender document.
The O&M activities can be classified into the following activities:
1.1.1 Uptime of installed systems and software: As part of this activity SI will maintain
the uptime with guaranteed SLA for the whole systems and software installed. This
will be achieved through proactive monitoring of all processes, resBSNL’sces. In
case of any SLA violation, the O&M team will generate a trouble ticket which will be
used to track and resolve the issue in defined timeline. The resolution process shall
include clear escalation process and monthly report shall be produced to BSNL
indicating no of such issues, time of resolution and root cause of issues and their
remedial action plan.
1.1.2 Preventive maintenance of the installed systems and software: Preventive

maintenance shall have a process of approval and communication to field force in
advance. Once the activity is over, the O&M team of SI shall produce a report
indicating, approved time of maintenance activity and actual time spent to
complete the same
2. Service requirements
SI shall be responsible for overall operation, and maintenance of system at Data

Center, to meet the overall objective of system. This shall also include Operation &
Maintenance of DR and Intermediate site. Service Requirements from SI during the
Operation period is defined below:
1.1 Business Process Support
Since system touches the various internal functional areas of BSNL as an

enterprise, it is imperative that the various business processes will undergo
continuous changes. During SRS stage BSNL in consultation with SI will arrive at
the required business process flows of each module. This will be achieved as part
of implementation. However, the request of various business process changes
during entire O&M period need to be taken care of by SI.
1.2 User Interface Support
The installed system will be used by nationwide BSNL employees. Hence it is

imperative that the end users are able to access the required modules in a
continuous basis. As part of O&M, SI will have to provide support from Data center
for various queries and issues related to access of system. The major deliverables
are as under:
Support the desktop and LAN and their interaction with the application software
1.2.2 Coordinate desktop software versions to make sure they are compatible with the
system
1.2.3 Work with other support team members to assist with problem
resolution
1.2.4 Assist with planning and implementation efforts around major
release upgrades

1.2.5 Software distribution to the client desktop
1.3 Application Support
Application support broadly consists of the operation and development support.

Application operation support consists of day to day support of installed software.
Whereas application development support consists of minor developments and
customization without touching the core software, which needs to be taken care of
to introduce new features and facilities as per BSNL requirement.
Application operation support functionalities are:
i. Perform software configuration tasks

ii. Generate queries and basic reports
iii. Assist with security management
iv. Provide level II help desk support for the application
v. The maintenance of end-user training plans and materials
vi. System software (operating system, database and application) licensing,
installation, configuration and maintenance
vii. Monitoring availability and performance of the system (application, operating
system, database servers and network)
viii. Application of vendor patches
ix. Assisting with planning and support of efforts for major release upgrades
x. Database administration
xi. Print management
xii. Workflow management
xiii. Job scheduling
xiv. Performing operating system, database and application security administration
1.3.2 Application Development Support
i. Use vendor-provided or other third party tools to enhance the application

ii. Build extensions to the core software
iii. Integrate the solution with other packages
iv. Develop code to produce complex reports
v. Assist in solving problems that relate to the technical characteristics of the
application.
1.4 Infrastructure Support
i. Hardware acquisition, installation and maintenance

ii. Planning and testing disaster recovery
iii. Storage management (allocation, backups, restores, archiving)
iv. Network performance monitoring
v. All application servers & workstations shall stay connected over a reasonable
bandwidth.

Disaster preparedness and recovery by SI: In case of a disaster the DR site shall be taking
over the load of the primary site.
1.4.2 Data loss: In no circumstances there shall be a data loss.
1.4.3 Backup: Data backup shall be carried out by the SI as per the
backup policy of the BSNL.
1.4.4 Database Management: Database shall be maintained & tuned so
as to maintain only the required data.
1.4.5 Interface/Configuration: All system configuration & various

interfaces shall be maintained so that all application keep interacting with each
other as designed. SI shall be responsible for configuration of new schemes, plans,
circulars, rules etc.
1.5 Change requests
All change requests arising out of changes in business processes and Business
process Re-engineering etc, shall form part of the operation and Maintenance
scope.
1.6 Application wise Service Requirement
1.6.1 Some of the application-wise Service Requirements during the Operation period is
defined below:
1.6.2 Event collection: Timely collection of events from all the network elements as per
the scheduled time frame.
1.6.3 Distribution: events collected from the various NEs are to be processed
immediately and to be distributed to downstream applications for further
processing. In no case more than one hour old (from the point of collection) event
shall remain in the system pending for processing.
1.6.4 Rating: Formatted CDRs furnished by the Mediation system shall have to be
immediately rated and kept ready for billing. Under no circumstances CDRs
belonging to a particular day shall be kept unrated for the next calendar day (with
exceptions like CDRs generated just before the transition time and during planned
outages).
1.6.5 There shall be a mechanism to monitor the number of CDRs fed to the Mediation
server, number of Retail CDRs forwarded by Mediation server to the Billing
application, number of errored CDRs, number of rated CDRs and number of billed
CDRs. System architecture shall ensure accounting of each and every CDR
collected from switches.
1.6.6 Service/Tariff: New services or tariff changes shall be implemented in a time bound
& scheduled manner.
1.6.7 Order Management: All the service orders booked by CSRs shall be implemented in
a timely & planned fashion.
1.6.8 Provisioning: All orders booked by the OM module shall be provisioned in the
network elements, billing, CRM modules & other related modules etc.
1.6.9 Disaster preparedness and recovery: In case of a disaster the DR site shall be
taking over the load of the primary site and shall run on a reduced efficiency of

50%. Necessary services namely CDR collection, rating and customer services shall
be up and running within the prescribed time frames from the time of occurrence
of the disaster.
1.6.10 Data loss: In no circumstances there shall be a data loss except in case of a
disaster, where the permissible period of Data loss is 2 hours.
1.6.11 Backup: Data backup shall be carried out as per the backup policy of the BSNL.
1.6.12 Database Management: Database shall be maintained & tuned so as to maintain

only the required data.
1.6.13 Interface/Configuration: All system configuration & various interfaces shall be

maintained so that all application keep interacting with each other as designed.
1.6.14 Fault management/Maintenance system: The SI shall maintain a Fault Management

process for services provided to BSNL. Fault Management operations shall prioritize
the restoration of service by standard technical practice, including alternate and
redundant paths. The SI shall provide appropriate access mechanisms for the Fault
Management process to BSNL. Help desk for registering complaints shall be made
available on 24 x 7 basis. A fault docket shall be provided by the system as and
when a fault or service failure is reported and the status of the fault shall be made
available online by providing the docket number. The docket shall be cleared only
when the service is fully restored. The maintenance requirements shall be met as
per the maintenance requirements mentioned elsewhere in this document.
1.6.15 LAN: All application servers & workstations shall stay connected over a reasonable
bandwidth.
1.6.16 Web Services: Web self care is to be maintained so that web access to permitted
services and users is maintained at all times.
1.6.17 Service representatives shall be providing the Level 1 Support and shall escalate
Service issues as and when required. The Level 1 support staff shall have access to
the highest-level experts available from the SI and shall be adequately trained in
the system.
Operational Service Level

Agreement
2.1 The SI shall have to operate the data centers in a fashion so that all the services &
systems perform as per the performance parameters defined in this document. The
parameters defined in this table are meant for IT related activities and do not
involve any manual operations like extension of copper pair etc. The performance
related SLAs are mentioned below:
Sl. No Area SLA Level Level Level

1(L1) 2(L2) 3(L3)
2.1.1 Provisioning Maximum time taken to 80% in 1 90% in 2 100% in
commission requested Hour hours 4 hrs
bandwidth from the time of
logging of customer
acceptance form details to
the system till the time of
provisioning. To be
measured for provisioning
orders booked in every
fifteen minutes.

Note: “*” The levels of issues will be decided by BSNL and SI before
commencement of operation and maintenance period and shall be reviewed on a
quarterly basis.
3 Help desk Management
3.1 The O&M team will be positioned in the data center in a 24 X 7 support. Similar
team will be available at Disaster Recovery center. To make optimum usage of
resBSNL’sces, day to day activities will be defined and will be shared by the O&M
personnel at DC & DR. However to address to various operational requirements
as well as BSNL employee issues, A help desk system is required. Hence bidders
are requested to propose a help desk system for the O&M team, both at DC and
DR. BSNL would also like to extend the help desk terminals to other BSNL places.
3.2 The help desk shall also be integrated with the Web portal, so that O&M
personnel can log calls either through IVRS, Web portal or other media like, Fax,
email, Phone call and SMS.
3.3 Once the call is logged, as per predefined time frame calls will be resolved
or escalated. The help desk system shall have features for call escalation as per
problem area identified and shall provide monthly report on logged calls and its
resolution time etc.
3.4 A comprehensive IT help desk management system/software shall be

supplied and put in place by SI for management and monitoring the performance
of help desk and associated SLAs along with necessary licenses and integration
methodologies to various support systems.
3.5 Web Services: Web self care is to be maintained so that web access to
permitted services and users is maintained at all times.
3.6 Service representatives shall be providing the Level 1 Support and shall
escalate Service issues as and when required. The Level 1 support staff shall have
access to the highest-level experts available from the SI and shall be adequately
trained in the system.
3.7 For monitoring all the above mentioned SLA requirements, an operational
SLA tool shall be provided which may be the same as mentioned in AMC
requirements in this tender document.
3.8 In case the SLA requirements are not met as per the table above the
penalties shall be levied on the SI as per levels defined in the table. These
penalties will have a ceiling of 20% each of rates quoted for Data Center
Operation during contract period and data center operation during warranty
period. Penalty for various levels shall be as below:
Formula A :
(X- L1 in hrs) x Rs 2000, or

(Y- L2 in hrs) x Rs 3000, or
(Z- L3 in hrs) x Rs 5000
Here,
X is the time taken to meet the operational requirement beyond the time
mentioned against level 1,
Y is the time taken to meet the operational requirement beyond the time

mentioned against level 2 and
Z is the time taken to meet the operational requirement beyond the time
mentioned against level 3
L1, L2, L3 are the time values mentioned in hrs against various clauses in table
above.
Wherever time is mentioned in days the penalties shall be calculated as per the
formula B, below:
3.8.2 Formula B:
(X-L1 in days) x Rs 10,000, or

(Y- L2 in days) x Rs 15,000, or
(Z- L3 in days) x Rs 20,000
3.9 These penalties will be deducted from the payment due to the SI,
performance guarantee or any other payment due to be paid to the SI. Maximum
amount of penalty shall be restricted to 25% of the payment due for that
particular 3 months period.
********

Section VI-II
Annual Maintenance Contract (AMC)
This in the present form is from GSM tender , needs to be modified as per current
requirement
Agreement Performa
This agreement is made on the ________ day of ______(year) to be effective from

___________ between M/s. Bharat Sanchar Nigam Limited a company registered under
the Companies Act 1956 having license to provide all types of services of Telegraph and
having its registered and Corporate office at Bharat Sanchar Bhawan, H. C. Mathur Lane,
Janpath, New Delhi-110 001 (hereinafter called BSNL) of the ONE PART and
______________ a company registered under the Companies Act 1956 and having its
registered office at _____________________(hereinafter called SI which expression shall
unless repugnant to the context, include its successors in business, legal representatives
and administrators or permitted assigns) of the OTHER PART.
WHEREAS, BSNL has placed purchase order on the SI vide No. _________ dated
________ for supply, installation, commissioning & Annual Maintenance of System in
BSNL against Tender No. Dated at . WHEREAS the SI has made the
offer to duly comply with all the provisions of the Bid Document, including those
pertaining to Post Warranty Annual Maintenance Contract, after making himself fully
aware and understanding fully the implications of the terms and conditions and
specifications mentioned therein and which has been accepted by BSNL on the terms and
conditions mentioned hereafter and after ascertaining that the SI is fully capable of
complying with the aforesaid terms of the Bid Document.
Now the Agreement witnesses as follows:

(“Bidder” and “SI” have been used interchangeably, and are same entity)
1. General
1.1 In addition to complying with all the terms and conditions recorded in the Bid
Document, the SI hereby agrees and unequivocally undertakes to fully comply with
all the terms and conditions stipulated in this Agreement and without any deviation
or reservations of any kind.
1.2 Unless otherwise mentioned or appearing from the context, the Tender (Bid)
Document and any clarifications thereof and the purchase order shall form part and
parcel of this agreement, provided that in case of conflict or inconsistency on any
issue relating to this Agreement, the terms set out in the body of this agreement
shall prevail.
1.3 The SI shall prepare the schedule of preventive maintenance for each quarter
and shall submit the same to BSNL in advance. Schedule shall include in details,
system wide preventive maintenance activities. The preventive maintenance shall
not affect the normal functioning of the system.
1.4 The SI shall be solely responsible for the maintenance & repair of the
software/hardware equipments procured through this tender and parts thereof and
BSNL shall not be liable to interact with any of the partners/ collaborators or
subcontractors of the SI.
1.5 The SI shall install and maintain a Service Level Management (SLM) tool to help
automate the evaluation of IT Service delivery against the committed Service
Levels.
RFP for TX NMS Page 135 of 183

1.6 It has to be ensured by the bidder that it has back to back AMC agreements
with all associated SSPs/vendors. The copy of the agreements shall be supplied at
the time of signing the AMC contract.
Periodicity of AMC
2.1 The Agreement shall remain in force for seven years from the date of
completion of warranty period while at the same time the terms and conditions of
this agreement except for payment of charges to the SI shall also apply during
warranty period.
2.2 Extension of this Agreement shall be negotiable for the second term depending
on the performance of the SI during the period of the initial term of 7 years.
Maintenance Responsibilities of SI
3.1 The detailed responsibility of the SI from maintenance perspective are given
below in subsequent clauses, however, broadly the maintenance responsibility of
SI shall comprise:
3.1.1 Diagnose the fault/s in hardware, Data Center equipment, system

software and application software as and when they occur.
3.1.2 Rectify the faults detected.
3.1.3 Replace and if possible, repair faulty equipment or part thereof.
3.1.4 Provide application/systems software related fixes / patches and/or
work around to resolve the application/system related faults.
3.1.5 Carry out preventive maintenance of hardware and system software
every quarter.
3.2 The SI shall be responsible for maintaining the Data Center systems in such a
manner so as to provide an optimum level of performance & service.
3.3 Service availability shall be maintained by the SI in accordance with the Uptime
SLA terms for hardware/equipment and applications as mentioned in this
document.
3.4 The uptime of the hardware / network would be defined as availability of the
hardware to the application to perform its functions e.g. in case of clustered
hardware, the downtime of the production hardware would be used to calculate the
uptime.
3.5 The uptime of the applications would be defined as availability of the

applications in conduct of the ‘normal’ business.
3.6 Vendor shall provide an overall annual average uptime as given below on the
hardware configuration.
3.6.1 The Uptime would be measured as detailed below:
3.6.1.1 {[(Actual Uptime + Scheduled Downtime) / Scheduled Hours] x 100}

3.6.1.2 The above percentage will be averaged annually.
3.6.1.3 "Actual Uptime" means, of the Scheduled Hours, the aggregate number of
hours in any month during which each Machine / application, is actually
available for use.
3.6.1.4 Scheduled Downtime" means the aggregate number of hours in any month
during which each Machine / application, is down during Scheduled Hours,
due to preventive maintenance, scheduled outages, However for any
scheduled and planned outages, the SI will take prior approval from BSNL.

3.6.1.5 "Scheduled Hours" means the measurement period in a 24 x 7 manner i.e.
equivalent number of hours in one year excluding the downtime associated to
BSNL.
3.7 Any impairment of the Data Center infrastructure (due to reasons other than as
mentioned above) which results in creating backlogs in terms of data processing,
halting the rating & billing process, makes the billing application unavailable to
commercial offices, makes the CRM application unavailable to the CSRs etc., would
be solely attributable to the SI unless it is due to Force Majeure conditions. Such
impairment will attract the penalty clauses as per this document.
3.8 If a BSNL user selects to continue the operation on a Machine or a module of

the application, when a part of Machine or other modules of the application is
giving problem, the commencement of downtime shall be deferred until the user/s
releases the Machine / applications or items of Machine / modules of the
applications or operating software respectively required by the engineers of
Technical Support Center to do remedial maintenance.
3.9 Machine / application downtime shall end when the Machine or application is
rectified and the system resumes normal functioning.
3.10 Down time will not be considered under the following conditions:
3.10.1 Failure by BSNL to take any specified action previously agreed with
the SI.
3.10.2 Where BSNL has modified the software or hardware, without the
prior written consent of the Technical Support Center of the SI.
3.10.3 Repair time due to operational errors.
3.10.4 Repair time due to failure caused by confirmed environmental
conditions.
Technical Support Centre
4.1 The SI shall have Technical Support Centers co-located at the cities of location
of Data Center to provide technical support. The SI shall furnish the names,
locations, complete postal address, Telephone numbers and FAX numbers of all
Technical support Centers and the URL of the website for helpdesk purposes at the
time of signing this Agreement. Location of these support centers shall be such
that it shall not take more than one hour to reach the Data Centers.
4.2 Any change in Address, Phone number, FAX Number etc shall have to be
intimated in writing by the SI to the concerned In charge of the BSNL Data Center.
4.3 The SI shall ensure that all the Technical support centers are manned by fully
competent and responsible Engineers. It shall be:
(i) Capable of giving all types of necessary technical guidance/assistance over

phone to the respective Data Center In-charge or any other designated officers,
so authorized.
(ii) Capable of attending the faults at the BSNL sites whenever needed by deputing
competent technical expert.
(iii) SI Shall have a dedicated team of engineers at Data Center to attend the
software, hardware/equipment faults, which can be rectified on site.
4.4 The SI shall also ensure that Technical support Centers are manned and are
able to provide service to BSNL round the clock, all the seven days of the week
throughout the year. The level of service provided to BSNL shall not go down
during night time or due to any day being holiday, or for any other reason.

4.5 The Technical support Centers shall be responsible to repair/replace the faulty
cards/units/PCBs of any system which is part of the Data Center with good
cards/units/PCBs during the period of AMC.
4.6 One or more of the Technical Support Center(s) shall also work as repair
center(s) and the same shall be responsible for repairing/ replacing of the faulty
cards/units/PCBs and shall also maintain a requisite minimum stock of such
cards/equipment often going faulty, in order to keep the down time within limits as
envisaged in this agreement.
4.7 The Technical support Center shall regularly obtain feedback about the health
of the systems under its jurisdiction from the Data Center in-charge of BSNL on a
monthly basis and maintain a proper record of such feedback. These shall be made
available to the technical experts nominated by the SI for analysis and such
technical expert in turn shall give adequate and proper guidelines / technical
advice process change recommendations to the in-charge of BSNL Data Centers for
taking necessary preventive measure for reducing the frequency of such faults and
also for preventing such faults from re-occurring. This shall, however, not absolve
the SI from fulfilling his obligations under this agreement.
4.8 The SI shall provide Level I support from the TSC with the provision for
escalation of Service issues. The Level 1 support staff shall be thoroughly trained in
the system and shall have access to the highest-level experts available from the
SI.
4.9 The faulty modules/parts/cards shall be picked up by the SI from the Data
Center and returned after repairs or replacement as per SLAs indicated in this
document.
4.10 The SI shall ensure sufficient spares at the respective Technical support
Centers to meet the desired service levels. The SI would also ensure availability of
right number of manpower (resBSNL’sces) with appropriate skill sets.
Technical Support Procedure
5.1 The SI would need to have a Maintenance Desk facility which would be
responsible for all data center related maintenance activities. This desk shall
also handle manual complaints regarding maintenance of the equipments and
applications by BSNL and/or its own staff. The procedure for the Technical
support is defined below.
5.2 The maintenance desk shall be manned round the clock by SI staff capable of
handling both hardware/software related problems. In case of any fault,
abnormality in the system, partial or total failure of the system, the officer in-
charge/ designated official of the BSNL Data Center will immediately access
the maintenance desk facility, maintained by the SI, for registering the fault.
5.3 In case of failure of resolution of the fault in time, the maintenance desk staff
shall contact the SME/s of the hardware/software figuring in the complaint.
Staff of the SI stationed at the Data Center shall give information about the
nature of fault.
5.4 In both the scenarios, where fault is registered manually with maintenance
desk facility or discovered by SI staff, Phone call/E-mails/fax shall be sent to
concerned Data Center in-charge with details of the registered faults including
a reference/complaint number and a time/date stamp. This reference number
shall be issued from a web portal section meant to keep record of all such

faults.
5.5 The maintenance desk facility shall manage & regularly update a history/record
of all types of faults in the above mentioned web portal for
browsing/downloading/print out by the technical staff of BSNL & SI. It shall also
store & display typical operational problems, errors & their rectification process.
5.6 Accessing of the maintenance web portal shall be possible to authorized users
only.
5.7 The time of reporting of the fault shall only be taken into consideration for
calculating the actual duration of faults.
5.8 Similarly, after rectification of fault a ‘Fault Rectification Details’ with the time
of registering, time of restoration, total duration of fault, severity level and
other details of the fault shall be automatically displayed in the helpdesk
facility. This shall tally with the Fault Rectification Form signed by the Data
center in-charge. The SI shall keep a record of all the fault rectification forms
signed by the data center in-charge for verification. The Fault Rectification form
would have signatures of the SI’s engineer as well.
5.9 In case of any dispute arising regarding duration of fault etc, the Fault
registration details & fault rectification form, as maintained at the BSNL Data
Center and web portal shall be the guiding documents to resolve the dispute.
5.10 Technical instructions shall be given to the BSNL staff of the concerned Data
Center, over phone. If the fault is restored by following the instructions given
over phone, the Data Center In-charge will register the fault as closed in the
helpdesk facility after making suitable entries and after satisfying himself of the
proper restoration of the fault
5.11 The SI shall also ensure visits of the expert and competent technical staff of the
SI in case the fault is not rectified to the satisfaction of BSNL even after
following the telephonic instructions and advice. In such a case, the elapsed
time will count towards fault restoration time/ system downtime.
5.12 Once the fault has been rectified and the system & services were restored to
normalcy, the visiting engineer of the SI shall record in the Data Center
Maintenance Log Book, the details of the works done by him for restoration of
the faults and also record the details of further steps to be taken.
Upgrade/Updates/Patch/Release Management:
6.1 Vendor shall supply and apply Patches, Updates and upgrades, and
corresponding Documentation (the number of copies indicated in the Commercial
Terms) from time to time as available.
6.2 Maintenance Services shall include the provision of Third Party Software
upgrades, as made available by the Third Party Software manufacturer and as
supported by Vendor.
6.3 The SI shall follow a Patch Management/Release Management Procedure and

share the plan for the same with BSNL
6.4 All the Patches/upgrades/Releases prior to their application on the Production

Server need to be tested in the development/test Environment by the SI before
apply in production. All such tests need to be validated and signed off by BSNL
personnel before release for Production. SI shall apply such releases to Production

only after BSNL has approved and signed off all the tests for the
Patches/Releases/Upgrades.
6.5 The test Scenarios for testing of Patches/Upgrades/Releases shall be provided

by the SI however BSNL will have the authority to change the existing testing
Scenarios and add new scenarios for testing for their satisfaction.
6.6 The Patches/Releases/Upgrades failing in Production will be treated as faults

and will be prioritized based on Severity Levels defined in this document. Each
such failure shall be categorized as per the situation arising out of such
Patches/Releases/Upgrades failure. For example any Patches/Releases/Upgrades
failure resulting in ‘CRM application failure affecting the availability of CRM
application’ will be treated as severity level 1A with allowable quarterly downtime
of 15 hours & resolution time as 12 hours as mentioned elsewhere . The SI need to
resolve the faults within the time frame defined in tender as Faults and Severity
Levels and Resolution time, failing which the SI will need to pay the Penalties as
defined elsewhere.
6.7 SI to provide BSNL all the training required and the necessary documentation
for the Release/Patches/Upgrades.
6.8 Updates and Upgrades shall be warranted for, in accordance with the terms of
Licensed Products Warranty Section of the General Terms beginning on the date
the Update or Upgrade is delivered to BSNL. If BSNL receives Updates or
Upgrades via the vendor’s support website, the download date shall be used to
calculate the warranty period.
6.9 Vendor shall provide Maintenance Services for the all the Upgrades and
Updates
6.10 Beginning on the day Vendor implements a new Version on the system
supplied it shall support both the old Version and new Version concurrently for at
least 120 days.
7. MAINTENANCE OF HISTORY
SHEET AND LOG BOOKS:
7.1 The SI shall supply elaborate maintenance procedures and proforma of the history
sheet to every Data Center of BSNL, where its equipments are installed. The In-
charge of the Data Center shall fill up the computerized history sheet containing
the statistics about the health of the equipments installed at the concerned Data
Center and send a report to the Technical support Center of the SI on monthly
basis.
7.2 Based on the History sheet report, the SI shall analyze the health record of each
site and if something alarming or unusual is noticed, shall advise the Data Center
In-charge to take necessary actions for preventive maintenance of such
equipments.
7.3 Database driven computerized History sheet proforma integrated with SLM tool
shall become part of this agreement. The SI shall provide the hardcopy of the same
at the time of signing of the agreement.
Helpdesk Utility
8.1 SI shall maintain a helpdesk utility to provide the following services apart from
functionalities mentioned above:

8.2 The web based Help Desk system would be the focal point in providing Technical
support services to BSNL. System shall automatically track, log and escalate user
service requests.
8.3 All Faults registered, shall be tracked in the helpdesk system till the cause of the
fault has been detected, repaired and equipment/application restored.
8.4 Categorization of the faults shall be configurable. Once the resolution time of the
faults gets over, it shall raise alarms, notification and escalation. The reports for
the same shall be available from the Help Desk system.
8.5 Provide a solutions database - Support staff can create a solution database
containing information that other support users and end users can access for
potential solutions to their problems or questions. The Help Desk system shall be
configurable for different access for users/user groups as per their role. The entire
database shall be able to be searched and shall output records containing the
search criteria.
8.6 It shall allow submitting and checking the status of reported problems through web
interface based on complaint number, user name, equipment/application name,
fault category etc.
8.7 The Technical Support Center shall have quality complaint processes to facilitate
management of requests. The Technical Support Center shall respond to phone, fax
and on line requests for AMC Services in accordance with agreed terms of the
contract. The Technical Support Center shall be equipped with Service Desk with
sufficient manpower to record requests in the Help Desk system, which will track
the entire life cycle of the request, and will manage the opening, assignment,
acceptance, escalation, resolution and closing of the request.
8.8 The Service Center shall manage requests in a way that is transparent to BSNL,.
During a request life cycle, the Service Desk shall make available information
regarding its status and will notify the state upon completion.
8.9 The SI shall employ a judicious approach to prioritize requests depending upon the
severity of the complaint received. The SI shall support different priority targets
depending upon the agreed level of business impact on a particular support issue.
9. Degradation in Performance,
Faults, Resolution Time and Penalties
9.1 During the AMC period, the entire system shall support the performance
parameters and % availability as defined in tender document. In case there is
degradation in performance or % non-availability is higher than specified or delay
in restoration of faults beyond the prescribed limits will result in Penalties as per
the corresponding non- compliance to AMC clauses.
9.2 Penalties will be imposed based on three parameters:
9.2.1 Complete non-availability of a sub-system (Hardware/ Software)

9.2.2 Partial availability of a sub-system
9.2.3 Mal-functioning of the Data Center equipment or any other
equipments
9.3 In case a sub-system is completely non-available then the severity level shall
be defined as per the system non-availability calculated over a period of three
months. The penalties in such cases shall be imposed as indicated below:

S. No. Performance requirement Range of non- Penalty
availability
99% availability a. 97% to 99% in 0.05% of annual AMC
steps of 0.1% charges per 0.1%
degradation
b. Less than 97% 0.1% of Annual AMC
charges per 0.1 %
degradation
98% availability a. 96% to 98% in 0.025% of annual
steps of 0.1% AMC charges per
0.1% degradation
b. Less than 96% 0.05% of Annual AMC
charges per 0.1 %
degradation
97% availability a. 95% to 97% in 0.0125% of annual
steps of 0.1% AMC charges per
0.1% degradation
b. Less than 95% 0.025% of Annual
AMC charges per 0.1
% degradation
Less than 97% availability a. Less than 97% 0.00625% of annual
AMC charges per
0.1% degradation
In case the % non-availability is a fraction of the 0.1, then the normal
rounding procedure will be deployed, i.e. Value less than 0.05 will be waived
off and value more than 0.05 will be considered as 0.1.
9.4 In case a sub-system is partially available, then the severity level shall be
defined as per the number of subscriber affected by the partial non-availability.
9.4.1 Parameters, which are directly related to subscribers, considered for

ascertaining the severity level will be, Subscriber Billing, Billing functionality (tariff
plan, discount, ) ,Subscriber Bill Printing, CDR Rating, CDR Collection, CRM, Service
request, Service Provisioning, IVRS/CTI/ACD access
9.4.2 Parameters not directly related to subscriber, but affecting the

subscribers will be:
CSR access, Storage data, Tape library access, Degradation in performance levels
9.4.3 Based on these parameters, Penalty for partial non-availability shall

be imposed as per details given below:
circuits effected Acceptable Range of Time Penalty

Time period period if fault
of fault exceeds the
acceptable time
9.4.3.1 More than 25 6 hours More than 6 and less 0.05% of annual
thousands than 24 hours AMC charges per 6
hours delay
More than 24 hours 0.1% of Annual
AMC charges per 6
hours delay
Less than 25 12 hours More than 12 hours 0.025% of annual
thousands and more and less than 36 AMC charges per 6
than 10 thousands hours hours delay

AMC charges per 6
hours delay
Less than 10 24 hours More than 24 hours 0.0125% of annual
thousands and more and less than 72 AMC charges per 6
than 5 thousands hours hours delay
AMC charges per 6
hours delay
Less than 5 24 hours More than 24 hours 0.00625% of
thousands annual AMC
charges per 6
hours delay
9.5 Penalties for mal-functioning of TX NMS equipments or other equipments will

be associated as per the severity level of the faults as described in this agreement.
Severity level wise faults are described below(this fault list is not exhaustive and
shall be decided before start of AMC period by BSNL and SI):
Type of Problem Total accepted Penalty

down time in 3 code
month(in
hours)
9 Complete DC/application, edge Server/DC 12 A
. router/Backbone router/LAN switch down
5
.
1
9 One processor board down in a Server 12 B

.
5
.
2
9 Test & Development/Training server down 24 C

.
5
.
3
9 Workstations, PC, Printer not working 24 D

.
5
.
4
9 Aggregation/central router down 12 A

.
5
.
5
9 Other multiple routers down in the 18 B

. network connected to a single MPLS node
5
.
6

9 Single router down in the network 24 C
. connected to a single MPLS node
5
.
7
Enterprise Array Fault

9 Complete Enterprise Array down 6 A
.
5
.
8
9 Read or write Cache down 6 A

.
5
.
9
9 Complete FC card down 18 B

.
5
.
1
0
9 Backend Controller down 18 B

.
5
.
1
1
9 One CPU down in a Enterprise Array 24 C

.
5
.
1
2
Disk Problems in Enterprise Array

9 Disks in one full loop down 12 B
.
5
.
1
3
9 More than two disks down in RAID 1/0 36 C

. (stripping & mirroring)
5
.
1
4
Disk/Tape Library Problems

9 One Disk array down 12 B

9 Two tape drives down 18 B
.
5
.
1
6
9 One tape drive down 36 C

.
5
.
1
7
9 One robotic Arm down 24 C

.
5
.
1
8
9 Two disks in array down 36 D

.
5
.
1
9
9.6 Penalty codes given above are defined below. These penalties shall be imposed
for every occasion, Severity Level wise Penalty per hours of delay are given below:
Fault Severity Level Per Occasion Penalty per hours

of delay
A Rs. 5,000
B Rs. 3,000
C Rs. 2,000
D Rs. 1000
Delay will be counted in steps of one hours. More than half hours of
delay will be treated as one hours delay.
9.7 Over and above the faults defined above, there would be minor faults which do
not fully make the system un-operational e.g. the CD ROM drive becoming faulty,
Cluster hardware needing repair or replacement of part, Application needing proper
solution instead of a work around etc. Such faults shall also be rectified. In the
event of such faults are not repaired within 120 hours. The SI would be charged a
penalty as per Severity Level D if such faults are not resolved.
9.8 In case of any fault, not mentioned in the table above, affects the functionality
of the Data Center in any way shall be treated as per the severity level defined by
the BSNL along with the resolution time.
9.9 The time for restoration of fault will be counted from the time of reporting to
the help desk and obtaining the fault ticket number from them.
9.10 The penalty shall be deducted from the quarterly bills. The maximum value
of penalty for fault in Data Center shall not exceed 25% of AMC amount applicable

for that three month period.
10. AMC Charges and Payments
10.1 The charges for AMC will be as given in the purchase order. A copy of the
same shall be enclosed as Appendix (to be made part of the agreement at the time
of signing AMC).
10.2 BSNL shall not pay any charges in advance. Bills for AMC shall be paid by
BSNL at the end of every three months, after successful execution of the works
under this Agreement within 15 (fifteen) days of the receipt of the duly completed
Data Center-wise bills.
10.3 All payments shall be made by the Data Center In-charge based on the fault
report received from the Data Center, after deducting penalties if any.
11. Force Majeure
11.1 Neither BSNL nor the SI shall be liable to the other for any delay in or failure of
performance of their respective obligation under the agreement caused by
occurrences beyond the control of BSNL or the SI including but not limited to
fire (including failure or reductions), acts of God, acts to the public enemy,
war, insurrections, riots, strikes, lockouts, sabotage, any law, status or
ordinance, thereof of any other local authority, or any compliance therewith or
any other causes, contingencies of circumstances similar to the above. Either
party shall promptly but not later than twenty days thereafter notify the other
of the commencement, and cessation of such contingencies, and if such
contingencies continue beyond three months. Both parties agree upon the
equitable solution for termination of this agreement or otherwise decide the
cBSNL’sse of action to be adopted.
12. Disputes & Arbitration
12.1 Disputes and Arbitration shall be governed by Arbitration clauses and its sub-
clauses of Section III-D of the tender document.
12.2 Any party shall not use any information obtained from other party during the
course of dispute resolution process under this clause for any purpose other than to
resolve the dispute and such information shall not be used in any litigation.
12.3 Both parties shall use their best efforts in good faith and best intention to
resolve disputes by mutual negotiation and consultation and shall settle amicably any
dispute that may arise or relate to this agreement or a breach thereof. Pending resolution
of a dispute, the SI shall continue to fulfill its obligations under this agreement.
13. Termination of AMC
13.1 Notwithstanding anything contained in Dispute and Arbitration Clause above, it

is expressly agreed and understood that BSNL at its sole discretion will terminate the
agreement in case of following contingencies:
13.1.1 If BSNL finds the services of the SI during AMC period are not as per
the committed SLAs for two halves, it reserves the right to terminate the AMC
during its validity period, after giving three months notice to the SI.
13.1.2 If for any reason whatsoever, the SI is not able to perform their part
under this agreement for continuous period of ten days or more.

13.1.3 If BSNL is required to pay any damages and/or compensation and/or
any payment to the third party including its customers on account of any negligent
action or otherwise on part of the SI.
13.1.4 If the SI is unable to give proper account of tools, equipment's etc,

entrusted to them for their custody and fail to return when demanded for the
execution of work under this agreement.
13.2 In case, BSNL decides to terminate the contract because of the bad
performance of the SI, the AMC charges will be paid/ recovered on pro-rata basis.
Recovery amount will also include any penalties already levied in the respective six
months period.
13.3 After the expiry of annual maintenance contract, it shall be optional for BSNL to
further enter into AMC contract with the contractor. In such circumstances, BSNL may
purchase the spare parts /sub assemblies /printed circuit boards etc from the SI. For this
reason the bidder shall quote, in the bid the price of these parts /sub assemblies, etc to
be paid by BSNL at that time.
14. Set off
14.1 Any sum of money due and payable to the SI (including security deposit
refundable to him) under this contract may be appropriated by the BSNL and set
off the same against any claim of BSNL for payment of a sum of money arising out
of this contract or under any other contract made by the SI with BSNL.
IN WITNESS WHEREOF the parties hereto have caused this Agreement to be executed
through their respective authorized representatives on the day and year first above
written.
Signed and delivered for and on behalf of BHARAT SANCHAR NIGAM LIMITED.
By____________
Signed on behalf of M/s._____________________________________________

By Shri _______________ holder of General Power of Attorney dated__________
executed in accordance with the Resolution No. Nil dated _____________ passed by
Board of Directors.
In the presence of:

Witness:
1. _____________________
2. _____________________

Section –VII (JJ)
PART-I: BID FORM
Tender No. ............................. Date: .................
To
Tendering authority
BSNL
Dear Sir,
1. Having examined the conditions of contract and specifications including addenda

Nos......................the receipt of which is hereby duly acknowledged, we,
undersigned, offer to supply and deliver .............................................. in
conformity with the said drawings, conditions of contract and specifications for the
sum shown in the schedule of prices attached herewith and made part of this Bid.
2. We undertake, if BSNL’s Bid is accepted, to commence deliveries within ( )

months and to complete delivery of all the items specified in the contract within (
) months calculated from the date of issue of your purchase order (PO).
3. If BSNL’s Bid is accepted, we will obtain the performance guarantees of a
Scheduled Bank for a sum @ 5% of the contract value for the due performance of
the contract.
4. We agree to abide by this Bid for a period of ------- days from the date fixed for
Bid opening and it shall remain binding upon us and may be accepted at any time
before the expiration of that period.
5. Until a formal Purchase Order of Contract is prepared and executed, this Bid
together with your written acceptance thereof in your notification of award shall
constitute a binding contract between us.
6. Bid submitted by us is properly sealed and prepared so as to prevent any

subsequent alteration and replacement.
7. We understand that you are not bound to accept the lowest or any bid, you may
receive.
Dated this .............................. day of ........................ 200
Name and Signature ------------------------
In the capacity of ----------------------
Duly authorized to sign the bid for and on behalf of ..............................................
witness .........................................
Address ......................................
Signature
[GSM Phase.VI/ Part IV-OSS & BSS] [Bidder’s Signature] [Section VII (JJ)] Page 149 of 183
Section VII (KK)
Part-II: (Price Schedule)
A1-Price Schedule for Indigenous Equipment

(Phase 1)
E.D.Tarif Head
Percentage (%) of Customs duty
Customs tariff Head

Import content
Ex-factory Price (Basic Unit Price exclusive
Duties & Taxes CENVATable on unit price
Unit Price excluding Duties & Taxes

Other levies & charges, if any
Total
of all levies & charges)
if anyDiscount offered,
Total discou
Price nted
CENVAT able
Unit Inclusive price
Quantity
Price of all excludi

Excise Sales F.F.Pkg
SL No Item description (all levies & ng
Duty Tax &I
inclusi charges Duties
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)

+11)
1. Hardware For Major Applications
Subtotal (Table 1)
1.1 AAA Server-HW 1 set
1.2 AAA Server-SW 1 set
1.3 N+1 servers 1 set
Subtotal (Table 2)
2.0 Other Hardware items
2.1 DC Gigabit LAN 2
Switch as per TEC GR
No., GR/LSW-01/03
Sep 2007 (high
[GSM Phase.VI/ Part IV-OSS & BSS] [Bidder’s Signature] [Section VII (KK)] Page 150 of 183
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
range), with
minimum 48 port GE
ports
Subtotal (Table 3)
Subtotal (Table 4)
3.0 Physical Security
5.1 Access control
System (Hardware) 1 set
5.1.1 Door Controller 10
5.1.2 Smart Card Reader 10
5.1.3 Door Locks 10
5.1.4 Smart cards 50
5.1.5 Biometric finger Print
Scanner 5
5.1.6 *Electronic Rodent
150
Management System
5.2 Access control
System (Software) 8
5.3 Secure ID token 1 set
system (including HW
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
and SW)
5.4 CCTV Based
surveillance System
(Hardware) 1 set
5.4.1 CCTV Cameras 15
5.4.2 DMR 1
5.5 CCTV Based
surveillance System
(Software) 1 set
Subtotal (Table 5)
4.0 Uninterrupted Power Supply (Primary site)
6.1
UPS 140 KVA or 4
higher
6.2 Battery Bank for each
UPS to provide 1 hrs
backup (As per TEC
GR No. GR/BAT-
02/02. Mar 2006 with
amendments, if any) 4 sets
6.3 Associated 4 sets
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
switchgear and
cables
Subtotal (Table 6)
5.0 Miscellaneous items
5.1 Fire Proof Safe 2
5.2 Large Screen Wall as 2

per specification
5.2.1 Rear Projection 16
Modules
5.2.2 Display Controller 2
Unit with required
software
Extension Unit
configured with RGB
Interface for Display
Controller-Two ports
with one interface
cable(15 m), Video
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
Controller - FBSNL’s
Ports with one
interface cable( 15
m)
Subtotal (Table 7)
6.0 Network items
6.1 level 1 router
configured with 2
channelized STM-1, 4
number of ISDN PRI,
4
2number of 10/100
mbps Ethernet
interface, 16 E1
ports-optional
6.1.1 Additional
interface of
channelized STM-1, 2
number of GE 2
interface for CSR
level 1 router.
(Optional)
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
6.2 LAN switch
configured with 12
numbers of 10/100
250
and 2 numbers of
1000 base T LAN
ports
6.3 REMOTE ACCESS
SERVER (RAS) with
4 channelized
E1R2/PRI ports, 120
2
digital modem ports
and 2 Ethernet ports
of 10/100
mbps(Optional)
6.4 BACKBONE 2
ROUTER configured
with the 2 nos. of
10/100 mbps
Ethernet interface, 2
GE Ethernet
interface, 4 nos. of
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
clear channel E3
interfaces, 4 nos. of
STM-1 interfaces
6.4.1 Additional module
of 2 GE interface
2
for DC-DR router
(Optional)
6.5 ETHERNET SWITCH
Type I Chassis
configured with Two
or more independent
modules per switch, 2
with 80 no.
10/100/1000 MBPS
Ports, 40 Ports GE
optical
6.6 ETHERNET SWITCH
Type 2 configured 6
with 24 ports of
10/100 mbps & 2
GigE ports Ethernet
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
ports
6.7 Internet ROUTER
configured with 2
nos. of GE interface,
2 nos. of 10/100
mbps Ethernet 2
interface, 8 nos. of
E1 interfaces, 4 nos.
of E3 interfaces, 2
STM-1 POS
Subtotal (Table 8)
7.0 Security
7.1 NMS NOC 4
FIREWALL in
Redundant Failover
configuration
configured with
FBSNL’s nos. of
Gigabit Ethernet
interfaces (on each of
the redundant
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
Firewall units) & Two
nos. of 10/100 mbps
Ethernet
Interfaces(on each of
the redundant
Firewall units) as per
TEC GR no.GR/FWS-
01/01 SEP 2006 (as
per latest TEC GR
available as on date
of bid submission)
7.2 Network IDS
configured with Eight
Gigabit Ethernet
interface Probes as
per TEC GR
2 sets
no.GR/IDS-01/01
FEB 2003 (as per
latest TEC GR
available as on date
of bid submission)
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
7.3
Host Based IDS 1 set
7.4 Vulnerability 1 set
Assessment & Policy
Compliance System
7.5 Server Access 1 set
Control System
(ACS)
7.6 Security Device 1 set
Management System
7.7 Security Information 1 set
and event
management system
Subtotal (Table 9)
8.0 Major Software (All license on perpetual basis)
8.1 Performance
management 1 set
8.2
Fault management
1 set
8.3 SLA management 1 set
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
8.4
Mediation
1 set
8.5
Provision 1 set
8.6 Inventory
Management 1 set
8.7
NMS 1 set
8.8
Help desk system 1 set
8.9
ETL Tool 1 set
8.10
Oracle RDBMS 1 set
8.11 RDBMS other than
Oracle 1 set
8.12
CRM -Optional 1 set
8.13 IOBAS- (optional) 1 set
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
Subtotal (Table 10)

9.0 Any other item (s)
9.1 Engineered Items by
Bidder
bidder (Additional
to
lines may be added
specify
by the bidder for this
item)
\ Subtotal (Table 11)
10.0 Documentation
10.1 Hard Copy 5
10.2 Soft Copy 5
Subtotal (Table 12)

11.0 Services (For all items) (including DR and Intermediate site also)
11.1 All Software 1 set
implementations as
per tender
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
requirements
11.2 Installation &
commissioning of 1 set
Hardware Equipment
Subtotal (Table 13)
Subtotal (Table 14)
12.0 NMS NOC OPERATION (Including DR and Intermediate Site)
12.1 Data Center In
Operation charges man-
including DR and months
Intermediate site
during Warranty
12.1.1 Year 1 120
12.2 Data Center
Operation charges
In
including DR and
man-
Intermediate site
months
after Warranty
(optional)
12.2.1 Year 1 120
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
12.2.2 Year 2 120
12.2.3 Year 3 120
12.2.4 Year 4 120
12.2.5 Year 5 120
12.2.6 Year 6 120
12.2.7 Year 7 120
Subtotal (Table 15)
13.0 Annual Maintenance Contract (For all items) (including DR and Intermediate Site)
16.1 Equipment including
HW and SW (other
than RDBMS)
16.1. Year 1 1 set
1
16.1. Year 2 1 set
2
16.1. Year 3 1 set
3
16.1. Year 4 1 set
4
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
16.1. Year 5 1 set
5
16.1. Year 6 1 set
6
16.1. Year 7 1 set
7
16.2 ORACLE RDMBS
Maintenance
16.2. Year 1 1 set
1
16.2. Year 2 1 set
2
16.2. Year 3 1 set
3
16.2. Year 4 1 set
4
16.2. Year 5 1 set
5
16.2. Year 6 1 set
6
16.2. Year 7 1 set
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
16.3 RDMBS Maintenance

(Other than Oracle)
16.3. Year 1 1 set
1
16.3. Year 2 1 set
2
16.3. Year 3 1 set
3
16.3. Year 4 1 set
4
16.3. Year 5 1 set
5
16.3. Year 6 1 set
6
16.3. Year 7 1 set
7
Subtotal (Table 16)
ASYNCHRONOUS DR SITE
14.0 Other hardware items (At asynchronous DR site)
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
Subtotal (Table 19)
15.0 Miscellaneous Items

15.1 Large Screen Wall as
per specification
15.1.1 Rear Projection 8
Modules
Unit with required
software
Extension Unit
configured with RGB
Controller-Two ports
with one interface
cable(15 m), Video
Controller - FBSNL’s
E.D.Tarif Head
Customs tariff Head

Import content

Total
Total discou
Price nted
CENVAT able
Quantity
Duty Tax &I
ve) excludin &
g Duties Taxes
& Taxes CENVA
T-able
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Amt
(4+6+ (12- (3X14) (15-
Amt
Amt
% % % 8+10 13) 16)
+11)
Ports with one
interface cable( 15
m)
Subtotal (Table 23)
Note:
1. “We hereby declare that in quoting the above prices, we have taken into account the entire credit on inputs available
under the MODVAT SCHEME introduced w.e.f. 1st March 1986 and further extended on more items till date”.
2. If Annual maintenance Contract charges are required to be quoted as per SOR, basic charges should be shown in column-
4 & the service tax in column 11 & 13.
3. “We hereby certify that E.D/Customs Tariff Head shown in column 18/21 are correct & CENVAT Credit for the amount
shown in column 13 above are admissible as per CENVAT Credit Rules 2004”.
4. The bidder shall quote separately for hardware and software as per special conditions of the contract.
5. The bidder submitted the offer with concessional E.D/sales tax shall submit the proof of applicable concessional ED/Sales
Tax.
B- Price Schedule for Imported Equipment (for 100% Imported Items)
Customs Tariff head

Ex-factory Price (Basic Unit Price
SL.N
Discount offered, if any

Total
exclusive of all levies & charges)

o discoun
Total

ted
Price price
Inclusi excludi
ve of ng
Unit
Price all Duties
Unit Duties & Price
Per Unit levies & Taxes
price Packing Taxes excludin
Item Tota Custom Sales Price for & CENVAT
per & Inland CENVAT- g Duties
description l Qty Duty Tax site (all charge -able
Unit freight able on & Taxes
inclusive s
CIF unit price CENVAT
) excludi
able
ng
Duties
&
Taxes
1 2 3 4A 4B 5 6 7 8 9 10 11 12 13 14 15 16 17 18
(4B+6+ (12-13) (3X14) (15-16)
Amt.
Amt.
Amt.
% % % 8+10+1
1)
Note:
1. “We hereby declare that in quoting the above prices, we have taken into account the entire credit on inputs available
under the MODVAT SCHEME introduced w.e.f. 1st March 1986 and further extended on more items till date”.
2. If Annual maintenance Contract charges are required to be quoted as per SOR, basic charges should be shown in column-
4B & the service tax in column 11 & 13.
3. “We hereby certify that Customs Tariff Head shown in column 18 are correct & CENVAT Credit for the amount shown in
column 13 above are admissible as per CENVAT Credit Rules 2004”.
4. The bidder shall quote separately for hardware and software as per special conditions of the contract.
5. The bidder submitted the offer with concessional sales tax shall submit the proof of applicable concessional Sales Tax.
Section VIII (LL)
BID SECURITRY FORM
Tender No:
Whereas .................................. (hereinafter called “the Bidder”) has submitted its bid
dated............for the supply of ........................ vide Tender No……………………
dated............ KNOW ALL MEN by these presents that We.......................
Of .................... having BSNL’s registered office at .................(hereinafter called “the
Bank”) are bound unto Bharat Sanchar Nigam Limited (hereinafter called “the Purchaser”)
in the sum of Rs.................... for which payment will and truly to be made of the said
Purchaser, the Bank binds itself, its successors and assigns by these present.
THE CONDITIONS of the obligation are:
1. If the Bidder withdraws his bid during the period of bid validity specified by the
Bidder on the Bid form or
2. If the Bidder, having been notified of the acceptance of his bid by the Purchaser
during the period of bid validity
(a) fails or refuses to execute the Contract, if required; or
(b) fails or refuses to furnish the Performance Security, in accordance

with the instructions to Bidders.
We undertake to pay to the Purchaser up to the above amount upon receipt of its first
written demand, without the purchaser having to substantiate its demand, provided that
in its demand, the purchaser will note that the amount claimed by it is due to it owning to
the occurrence of one or both of the two conditions, specifying the occurred condition or
conditions.
This guarantee will remain in force as specified in clauses 12 and 28.2 of section II of the
Bid Document up to and including THIRTY (30) days after the Period of bid validity and
any demand in respect thereof should reach the Bank not later than the specified
date/dates.
Signature of the Bank Authority.
Name
Signed in Capacity of
Name & Signature of witness Full address of Branch
Address of witness Tel No. of Branch
Fax No. of Branch
***
[GSM Phase.VI/ Part IV-OSS & BSS] [Bidder’s Signature] [Section VIII (LL)] Page 170 of 183
Section IX (MM)
PERFORMANCE SECURITY GUARANTEE Bond
In consideration of the CMD, BSNL (hereinafter called ‘BSNL’) having agreed to exempt
___________________ (hereinafter called ‘the said contractor(s)’) from the demand
under the terms and conditions of an agreement/Advance Purchase Order No
________________ dated ____________ made between _____________________ and
__________________ for the supply of _______________________ (hereinafter called
“the said agreement ”), of security deposit for the due fulfillment by the said contractor
(s) of the terms and conditions contained in the said Agreement, on production of the
bank guarantee for _____________________________________we, (name of the bank)
_________________________ ( hereinafter refer to as “the bank”) at the request of
___________________________________ (contractor(s)) do hereby undertake to pay
to the BSNL an amount not exceeding ___________________ against any loss or
damage caused to or suffered or would be caused to or suffered by BSNL by reason of any
breach by the said Contractor(s) of any of the terms or conditions contained in the said
Agreement.
2. We (name of the bank) ____________________ do hereby undertake to pay the

amounts due and payable under this guarantee without any demure, merely on a demand
from the BSNL by reason of breach by the said contractor(s)’ of any of the terms or
conditions contained in the said Agreement or by reason of the contractors(s)’ failure to
perform the said Agreement. Any such demand made on the bank shall be conclusive as
regards the amount due and payable by the Bank under this guarantee where the decision
of BSNL in these counts shall be final and binding on the bank. However, BSNL’s liability
under this guarantee shall be restricted to an amount not exceeding
___________________________________.
3. We undertake to pay to the BSNL any money so demanded notwithstanding any

dispute or disputes raised by the contractor(s)/supplier(s) in any suit or proceeding
pending before any cBSNL’st or tribunal relating thereto BSNL’s liability under this
present being absolute and unequivocal. The payment so made by us under this bond
shall be valid discharge of BSNL’s liability for payment there under and the
contractor(s)/supplier(s) shall have no claim against us for making such payment.
4. We( name of the bank)_________________________ further agree that the

guarantee herein contained shall remain in full force and effect during the period that
would be taken for the performance of the said agreement and that it shall continue to be
enforceable till all the dues of the BSNL under or by virtue of the said Agreement have
been fully paid and its claims satisfied or discharged or till
________________________(office/Department) BSNL certifies that the terms and
conditions of the said Agreement have been fully or properly carried out by the said
contractor(s) and accordingly discharges this guarantee. Unless a demand or claim under
this guarantee is made on us in writing on or before the expiry of YEARS etc.
(as specified in APO/PO) from the date hereof, we shall be discharged from all liabilities
under this guarantee thereafter.
5. We (name of the bank)_________________________ further agree with the

BSNL that the BSNL shall have the fullest liberty without BSNL’s consent and without
affecting in any manner BSNL’s obligations hereunder to vary any of the terms and
conditions of the said Agreement or to extend time of performance by the said
contractor(s) from time to time or to postpone for any time or from time to time any of
the powers exercisable by the BSNL against the said Contractor(s) and to forbear or
enforce any of the terms and conditions relating to the said agreement and we shall not
be relieved from BSNL’s liability by reason of any such variation, or extension being
granted to the said Contractor(s) or for any forbearance, act or omission on the part of
[GSM Phase.VI/ Part IV-OSS & BSS] [Bidder’s Signature] [Section IX (MM)] Page 171 of 183
the BSNL or any indulgence by the BSNL to the said Contractor(s) or by any such matter
or thing whatsoever which under the law relating to sureties would, but for this provision,
have effect of so relieving us.
6. This guarantee will not be discharged due to the change in the constitution of the
Bank or the Contractor(s)/supplier(s).
7. We (name of the bank) ____________________ lastly undertake not to revoke

this guarantee during its currency except with the previous consent of the BSNL in writing.
Dated the ________________ day of _______
for __________________________________
(Indicate the name of bank)
[GSM Phase.VI/ Part IV-OSS & BSS] [Bidder’s Signature] [Section IX (MM)] Page 172 of 183
Section-X (NN)
LETTER OF AUTHORISATION FOR ATTENDING BID OPENING

(To reach before date of bid opening)
To
Tendering authority
BSNL
Subject: Authorization for attending bid opening on _________________________(date)

in the Tender of
____________________________________________________.
Following persons are hereby authorized to attend the bid opening for the tender
mentioned above on behalf of ______________________________________________
(Bidder) in order of preference given below.
Order of Preference Name Specimen Signatures
I.
II.
Alternate
Representative
Signatures of bidder
Or
Officer authorized to sign the bid
Documents on behalf of the bidder.
Note: 1. Maximum of two representatives will be permitted to attend bid opening. In

cases where it is restricted to one, first preference will be allowed. Alternate
representative will be permitted when regular representatives are not able to
attend.
2. Permission for entry to the hall where bids are opened, may be refused in case
authorization as prescribed above is not recovered.
***

Section-XII (OO)
Teaming Agreement
Consituents of teaming agreement:
1. SI is required to sign separate teaming agreement with each partner

which is to be signed jointly by the authorized signatories of the SI and the
technology partner/ apllication providers/SSP/database vendor etc. No specific
format for teaming agreement is proposed and it shall be SI’s responsibility to
word the teaming agreement.
2. Teaming agreement shall necessarily have Annexure -A and Annexure

-B (enclosed herewith in section-XII) as the integral part of the teaming
agrement, apart from other items, failing which the bid will be rejected.
3. Responsibilities of technology partner/ application

providers/SSPs/database vendor etc, which are to be incorporated in the teaming
agreement are provided under Annexure -B.
4. Clauses provided under Annexure -B are to be replaced by relevant

clauses in respect of Hardware, Networking, other Technology partner, database
vendors etc in their respective teaming agreements.

Annexure -A
System Integrator (SI) shall have following obligations:
1. Provide a complete turnkey implementation and assume responsibility for all

integration and implementation issues in order to deliver an operable system as
per the scope of work defined in tender no. _____________________
2. Structured Data Cabling and power cabling at Data Center.
3. To host the hardware in data centre and software required for all applications
enumerated in this tender.
4. Supply of software solution as listed in the tender document along with any other
software required to run various sub-system of the data center as per the design
and architecture of the end to end solution.
5. Functionalities for system as stated broadly in the tender, need to be delivered

through software implementations in this project.
6. Configuration, Customization & Dry run of system as per the business processes
frozen during SRS.
7. Establishment of Disaster recovery infrastructure at DR site.
8. Data Centre Operation in association with BSNL officials posted at DC during and
after the commissioning of Data Center as per detail given in this tender
elsewhere.
9. Training to BSNL staff
10. Provide Support Service for the entire system of the DC provided as part of this
project.
11. Furnish detailed Statement of Work comprising following essentials:

i. Project Scope
ii. Phase wise :
(a) Responsibility matrix
(b) Breakup of work
(c) Deliverables
(d) Program Management Team
(e) Detailed Time lines
12. To ensure the completion of the entire implementation within the scheduled time
frame (phase wise) as mentioned in the tender fulfilling the entire tender terms
and conditions.

13. To ensure the system performance as per specification.
14. Design the System ensuring redundancy at all critical points to achieve set
system level performance.
15. Provide suitable flexibility in the system to cater to the evolving needs during the
operation phase.
16. Deployment of a strong operations team with relevant domain expertise and
qualification as defined elsewhere, during the execution and operation.
17. Offer proven solution Architecture for all hardware and software component of the
project and provide strong local support.
18. Provide an overall Project Plan showing a timetable for the proposed phases. A
list of project phases will be provided, to include at least the following:
a) Functional Specification and Business Models Mapping

b) Environment set-up
c) Product Installation, Configuration
d) Implementation GUI and Reference Tables
e) Training
f) Validation and Acceptance Tests (preparation & execution)
g) Production/Rollover
19. Once the implementation starts following activities are to be taken care by the SI
along with the Software Solution Provider:
a) Interact with BSNL SMEs to finalize the requirements

b) Capture the business process in designed templates
c) Translate the business process into exact requirements
d) Provide a gap register keeping in view the requirements and
product features
e) Offsite configuration and testing
f) Ensure all captured requirements shall either exist in the code or
will be built in to the code
g) Detail list of all modules required to be implemented
h) Installation of the software at all the sites
i) Provide all services related to installation, configuration and
customization of the software
j) Rules configuration
k) Provide the audit and test plans including the production
acceptance testing criteria
l) Conduct testing of the software including the unit and system
testing in the SSP development environment
m) Provide all services related to re-configuration and customization
n) Provide training plan for BSNL staff inclusive of overview,
Reporting, System administration, etc
o) SSP’s Project Manager to report to BSNL and SIs Project Managers
p) Training of BSNL nominees as per details specified elsewhere.

Annexure -B
Application Provider(SSP)/Software Solution provider (SSP) shall at least have

following obligations included in teaming agreement between SI and SSP, apart from
other items:
1. SI shall ensure that SSP provides the following deliverables for the software
solution offered in the bid.
2. SSP shall have to give skill set requirements from its own perspective and from
SI’s perspective.
3. SSP shall clearly specify the parameters responsible for performance.
4. Sizing has to be done exactly as per the software solution provider’s

recommendation.
5. SSP has to give a Certificate of Satisfaction with respect to all the parameters
concerning sizing and performance.
6. SSP shall deliver product training for:
a) Installation
b) Product Configuration
c) API
d) First Level Support
e) Train the BSNL Training team
7. Availability of Subject Matter Expertise on site from SSP.
7.1 A minimum number of SME expertises shall be made available for entire
implementation duration. The same shall be covered contractually.
7.2 Identified SMEs to be attached with respective SIs for the period of
delivery or up to an identified milestone.
7.3 Designated SSP representative shall be available for all Project Steering
committee meetings.
8. Review of Statement of Work created by SI:
1.1 SSP representative shall have to go through the functionalities highlighted in the
Scope of work (SOW) and shall have to be a signatory along with the SI.
1.2 SSP shall have to authorize the customizations. SSP will have to provide a
guarantee that the Customizations being done would be supportable by subsequent
upgrades. In case of customizations that require touching the core, same would
have to be pointed out to BSNL.
1.3 SSP shall have to accept the Interface details, giving consent to overall design.
2. Training & Documentation on APIs available – SSP shall enable the SI to use the
API for plugging on customizations or interfaces to third party solution. In case APIs

need to be modified or new APIs need to be created to enable customization/ interface
the primary responsibility for this will be with the SSP. The new APIs created/modified
shall be supported by subsequent upgrades.
3. SSP shall give an undertaking that the SLA applicable to their solution will be
supportable. SSP shall give undertaking that current version of the software will be
supported for next 8 years excluding the contract implementation period.
4. The SSP shall clearly define its policy of releasing major and minor version each
year. The implementation shall be based on a product configuration with a clear product
roadmap for the contract period.
5. SSP Shall deliver the following to System Integrators for finally delivering to BSNL:
12.1 Licensed copy of all SSP applications that are within the scope of
implementation by SI.
12.2 Licensed copy of development and runtime versions of the report writer
products and other products bundled with the application.
12.3 List and specifications of all available APIs in each version.
12.4 Installation Scripts for all SSP applications that are within the scope of
implementation by SI
12.5 Product Specifications of all SSP applications that are within the scope of
implementation by SI.
12.6 User Manuals (hard & soft copy)
12.7 Functional Overview Manual
12.8 Operations Manuals
12.9 System Administration Manuals
12.10 Business process guide
12.11 Reporting reference guide
12.12 Screens reference guide
12.13 Training Brochure containing details of training programs to be offered

(hard & soft copy)
12.14 Training Kit for training of SI personnel
12.15 Hardware Specifications meeting the Sizing & SLA requirements
12.16 Benchmark Reports on Supported Platforms
12.17 Guaranteed response times for typical OLTP and batch transactions on
various configurations of the suggested hardware.

12.18 Product Road Map document
12.19 Warranty, Post Warranty, and Operational Support programs offered by

SSP – including commercial implications, SLA and availability of local support
facilities. This shall include problem resolution, application maintenance, change
requests, as well as policy for upgrades and updates.
12.20 Before Commencing Project SI shall have to give an undertaking of having

received & understood the material mentioned above.
12.21 Along with the bid document, the bidder shall have to submit a certificate
as given at Annexure-VI-I-1 with regard to professional service support from all
the OEM partners/SSP/ application provider, duly signed by the authorized
signatory of the bidder and the authorized signatory/ Country Manager of the
OEM.
12.22 The bidder shall furnish, along with the bid document, a Certificate from
the Application OEM with regard to hardware sizing of the application provided by
the OEM as per Annexure VI-I-2.

List of Acronyms
A
ACU Alarm Collection Unit
ADSL Asymmetric Digital Subscriber Line
ADM Add Drop Multiplexers
AM Alarm Management
B
BC Business Case
BD Breakdown
BER Bit Error Rate
C
CAMS Centralized Alarm Management System
CAPEX Capital Expenditure
CDMA Code Division Multiple Access
CDR Call Detail record
CM Configuration Management
CPE Customer Premise Equipment
CR Caution Report
CRM Customer Relation Management
CSV Centralized Supervisory System
CTR Cycle Time to Restore
CV Curriculum Vitae
D
DCC Data Communication Channel
DTS Digital Tandem Switch
DWDM Dense Wavelength Digital Multiplexer
EAI Enterprise Application Integration

EMS Element Management System
End-to- In the context of this RFP, from the A-end of a circuit or service in the
end managed network to the B-end in the managed network. Customer

premises equipment is specifically excluded from this definition.
ETL Export, Transform & Load
F
FAME Fault Alarm Monitoring and Escalation
FM Fault Management
FMU Fault Management Unit
G
GPS Global Positioning System
GUI Graphical User Interface
H
HDSL High Bit-rate Digital Subscriber Line
HP Hewlett-Packard
HPOV Hewlett Packard Open View
HRM Human ResBSNL’sce Management
I
INO International Network Operation
ISDN Integrated Services Digital Network
ITD Information Technology Department
K
KBPS Kilo Bit Per Second
KPI Key Performance Indicator
L
LAN Local Area Network
LSS Leased & Switched Services
LTU Line Terminating Unit
M
MBPS Mega Bit Per Second
MDF Main Distribution Frame
MLLN Managed Leased Line Network
MSC Mobile Switch Centre

MTBF Mean Time Before Failure
MTTR Mean Time To Restore
MVNO Mobile Virtual Network Operator
N
NE Network Element
NEO Network Engineering and Operation
NGN Next Generation Network
NIPS Network Inventory & Planning System
NMS Network Management System
O
OFM Optical Fiber Management
OEM Original Equipment Manufacturer
OLNO Other Local Network Operator
OLTE Optical Line Terminal Equipment
OPEX Operational Expenditure
OSS Operation Support System
P
PAM Priority Access Modules
PDH Plesiochronous Digital Hierarchy
PM Performance Management
PoC Proof of Concept
POI Point Of Interconnect
PoP Point of Presence
PRC Primary Reference Clock
PRS Primary Reference SBSNL’sce
R
RFTS Remote Fiber Testing System
RTCC Regional Transmission Control Center
RTU Remote Testing Unit
S
SAP Software Application & Procedures
SDH Synchronous Digital Hierarchy

SI System Integration
SLA Service Level Agreement
SLG Service Level Guarantee
SMS Short Messaging Service
SNMP Simple Network Management Protocol
SNMS Signaling Network Management System
SOP Service Order Provisioning
SPL Semi Permanent Link
SRS System Requirement Specifications
SSU Synchronization Supply Unit
STARS-Re System for Testing and Administration of Repair Services Reengineering
STP Signal Transfer Point
T
TCP/IP Telecommunication Communication Protocol/Internet Protocol
TNOC Transmission Network Operation Center
TOM Telecom Operations Map
TOMA Transmission Operation & Maintenance Center
TOSS Transmission OSS (system admin)
V
VAS Value Added Services
VAS-NOC Value Added Services Network Operation Center
VHF Very High Frequency
VoIP Voice over IP
VSAT Very Small Aperture Terminal
W
WAN Wide Area Network
WiLL Wireless Local Loop
WNO Wireless Network Operation
*****
END of DOCUMENT

RFP Nms 070708

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RFP Nms 070708

Uploaded by

Copyright:

Available Formats

RFP for TX NMS

Additionally, facilities are required that will enable BSNL to

• monitor services and circuits end to end.

BSNL has fBSNL’s organizational units for Long Distance

1.1 BSNL’s Current Infrastructure for Long Distance

BSNL owns and operates a multi-technology, multi-vendor

[RFP for Transmission NMS] Page 1 of 183

BSNL is proposing to induct following type of systems in it’s Long

These equipment ( Total 1,00,000 NEs at present) will also need to

1.3. Limitations of present Transmission Network

At present the BSNL’s Transmission Network comprises of

[RFP for Transmission NMS] Page 2 of 183

BSNL has variety of systems of different make in it’s network. There

• EMSs fully compliant with TMF814 standard

Systems deployed before 2007 have EMSs which do not comply

At present there are LCTs/NCTs/EMS with very limited

1.5 End-to-end perspective, manageability, honoring

End to end bandwidth is built up on multiple SDH Rings from

[RFP for Transmission NMS] Page 3 of 183

1.6 Manual diversion of Bandwidth in case of route

E1s, E3s, STM-1 or STM-16 streams are diverted manually by co-

1.7 Provisioning Deficiency: -

There is no computerized inventory of the bandwidth slots

Details and scope of items mentioned above will be covered in the

2 : Business Objectives And Approach

BSNL believes the business of providing communications services

BSNL intends following major business goals to be achieved by

[RFP for Transmission NMS] Page 4 of 183

Additionally, the vendor of the software product chosen as the basis

1. The chosen software product should have a substantial track record

The following sub-sections explore in more detail some of the issues

2.1 Unified View Of Networks And Services

BSNL’s networks are currently managed through a set of “silo”

2.2 End-To-End View Of Networks And Services

The new TX NMS is expected to provide the ability to see an end-

• More accurately and quickly localize faults.

[RFP for Transmission NMS] Page 5 of 183

2.3 The TX NMS as a unifying Force

It is BSNL’s intention to centralize the currently decentralized

2.4 Service-Level Guarantees

BSNL’s customers, particularly the larger ones, are increasingly

2.5 : The Scope Of The PROPOSED TX NMS Project

This section defines the scope of the TX NMS project to be

3.1 Functionality To Be Provided:

Proposed TX NMS has to follow TMN Hierarchy .The TMN

[RFP for Transmission NMS] Page 6 of 183

The TMN FCAPS Model of OSS Tasks.

In addition to the TMN–layering structure, the ITU–T also splits

3.2 : Core Network Equipment Types And EMSs To Be

The following table describes the Transmission network

[RFP for Transmission NMS] Page 7 of 183

STM-1 SDH EQUIPMENT

Vendor PO / DATE ADM TML REG NEs TOTAL

STM-4 SDH EQUIPMENT

Vendor PO / DATE ADM TML REG NEs TOTAL

[RFP for Transmission NMS] Page 8 of 183

STM-16 SDH EQUIPMENT

Vendor PO / DATE ADM TML REG NEs TOTAL

[RFP for Transmission NMS] Page 9 of 183

Vendor PO / NO. & DATE TML OLA OADM Total / NE

[RFP for Transmission NMS] Page 10 of 183

GRAND TOTAL 1268 822 902 2992