Annexure A TecGRs

Tamil Nadu FibreNet Corporation Ltd
(TANFINET)
Selection of System Integrators for Survey, Supply,
Installation, Commissioning and Operation & Maintenance
of Optical Fibre Network (OFN) in Tamil Nadu under
BharatNet Phase- II
Annexure-A – Technical Specifications (TEC

GRs)
Tamil Nadu FibreNet Corporation Ltd

807, 5th floor, Chengalvaraya Naicker Maaligai
Anna Salai
Chennai – 600 002
Phone: 044-28888230
e-mail: tenders.tanfinet@tn.gov.in
Website: www.tanfinet.tn.gov.in
Tender Ref: NIT/TANFINET/001
Important Notice
Applicability of Tamil Nadu Transparency in Tenders Act, 1998 and Tamil Nadu Transparency
in Tender Rules, 2000
This tender is governed by the Tamil Nadu Transparency in Tenders Act, 1998 and the Tamil Nadu
Transparency in Tender Rules, 2000 as amended from time to time. In case of any conflict between the
terms and conditions in the tender document and the Tamil Nadu Transparency in Tenders Act, 1998
and The Tamil Nadu Transparency in Tender Rules, 2000, the Act and Rules shall prevail.
TANFINET Corporation 2 Bidder’s sign and Seal

Table of Contents
1. Annexure A - TECHNICAL SPECIFICATIONs ................................................................................ 5
1.1 Technical Specification -Package A ........................................................................................ 5
A-Functional Requirements ................................................................................................................. 5
1.1.1 Functional Requirements for the Network ........................................................................... 5
1.1.2 Functional Requirements for NOC ...................................................................................... 8
B- Common Guidelines Regarding Compliance of Equipment/System ............................................ 10
C- Network Operation Centre – Technical Specification ................................................................... 11
1.1.3 42u Modular Network Rack ............................................................................................... 11
1.1.4 NOC and Internet Router Specifications ........................................................................... 12
1.1.5 Core Switch ....................................................................................................................... 16
1.1.6 Next Gen Firewall at Data Center and DMZ (De-Militarized Zone) ................................ 17
1.1.7 Ports & Performance Requirement ................................................................................... 19
1.1.8 Hyper Converged Infrastructure ........................................................................................ 20
1.1.9 GIS Software License ....................................................................................................... 22
1.2 Helpdesk ............................................................................................................................... 22
1.2.1 BSS- Customized Billing Solution- .................................................................................... 24
1.2.2 Billing System .................................................................................................................... 27
1.2.3 Enterprise Management System ....................................................................................... 33
1.3 Project Management Software .............................................................................................. 39
1.4 Workstation ........................................................................................................................... 40
D- Block & Gram Panchayat – Technical Specification .................................................................... 41
1.5 GP Type II, GP Type I, and Block Router Specification ....................................................... 41
1.6 Technical Specifications for 2.0 kVA ONLINE UPS System ................................................. 43
1.7 Technical Specifications for 1.0 kVA ONLINE UPS System ................................................. 45
1.8 Other Items – Technical Specification .................................................................................. 46
a) Earthing specifications .............................................................................................................. 46
b) General Earthing: ...................................................................................................................... 47
c) UPS Earthing(dedicated): ......................................................................................................... 47
d) LED Tube Light ......................................................................................................................... 47
e) Lock & Key ................................................................................................................................ 47
f) Electrical Work: ......................................................................................................................... 47
2. Technical Specification - Package B, C & D .................................................................................. 48
I. Aerial and Underground Cable.................................................................................................. 48
II. Underground Cable Accessories .............................................................................................. 48
III. PATCH CORD: As per TEC GR no. TEC/GR/TX/OFJ-01/05/Nov-09, with latest amendments
if any. ................................................................................................................................................. 48
2.1 24F Rack Mountable FDMS: ................................................................................................. 49
2.2 48 F Rack Mountable FDMS: ................................................................................................ 49
2.3 Technical Specification for Radio Link .................................................................................. 49
2.4 Antenna Characteristics shall be as follows: ......................................................................... 52

2.5 Carrier Ethernet Switch ......................................................................................................... 53
2.6 8.0m (200Kg WL) Pre-stressed Concrete Poles (PSC) detailed Specifications ................... 54
3. DESIGN REQUIREMENTS ........................................................................................................... 57
3.1 DIMENSIONS AND REINFORCEMENTS ............................................................................ 57
3.2 MANUFACTURE ................................................................................................................... 57
3.3 TESTS ................................................................................................................................... 59
3.4 INSPECTION &TESTING: .................................................................................................... 60
3.5 BRIEF TECHNICAL SPECIFATION: .................................................................................... 60
3.6 Block Location - Modular Network Rack (42 U): ................................................................... 61
3.7 Gram Panchayat Type 1 - Modular Network Rack (27 U): ................................................... 61
3.8 Gram Panchayat Type 2- 9U RACK (Wall Mount) ................................................................ 62
3.9 Mesh type filters .................................................................................................................... 62

1. ANNEXURE A - TECHNICAL SPECIFICATIONS
1.1 Technical Specification -Package A

A-Functional Requirements
1.1.1 Functional Requirements for the Network
S.No. Parameter Requirement
1. General
a) The network should support successful implementation of
Broadband, e-Education (Virtual and Digital), WiFi, Cable TV
networks and other State-wide network initiatives.
b) The network should be built to provide the following:
i. Higher Network Uptime.
ii. Complete Centralised Visibility of Network.
iii. Better Utilization of WAN Links.
iv. Segregation of Traffic and QOS in line with Industry
standards.
v. Better Network Management(Provisioning, Activation,
Fault, Performance etc)
c) The network should have the capability and facility for Seamless
integration with all other component required to build a digital
backhaul for the state.
d) Network Should act as backbone for all the State services (Layer
2 or layer 3) which may come in future
e) Network must support next generation architecture to support
future application like Voice, Video, data etc.
f) Devices must support the dynamic redundancy protocol for better
convergence.
g) Network Convergence methods like Fast Reroute and Bidirectional
failure detection must be deployed to achieve faster convergence.
h) Network must support segregation of traffic using Virtual Routing
and Forwarding (VRF).
i) QoS enables a network to provide improved service to selected
network traffic. The Network must support MPLS QoS features.
j) These nodes should have the capabilities to program the queues
in to logical queues to offer multiple services to the end customers.
k) The mapping of QoS should be done on basis of COS, IP prec,
TOS,IP address ,VLAN etc.
l) All nodes in network must support Hierarchical Quality of Service
for granular QoS.
m) All nodes must support priority queuing (more than one) for
assigning more priority to Voice and Video traffic over non critical
data traffic.

n) All nodes should act as Service Edge nodes and services can be
inserted from that node only.
o) Service edge should be the last node connecting to CPE.
p) “Any Service Any Where” with “Enter Anywhere Exit Anywhere”
from services and POI (Point of interconnect perspective).
q) Service edge Nodes should support layer2 VPN, layer3 VPN,IPTV
and multicast VPN and Cable TV transmission.
r) Network should have multicast capabilities and should support at
all layers
s) Network should have the capability to be used as Backhaul for
SWAN and other state networks.
t) All service edge nodes must support features to start IPTV and
Multicast VPN.
u) High QoS, Uptime, Security,L3 ,L2 and Multicast Services from
edge where the nodes are connected should be ensured as it will
be connecting to MSOs, SP and Telcos.
v) 4G and 5G backhaul should be supported at all nodes.
w) Packet clock and Sync E should be supported for connecting
Telco.
x) MPLS NNI (Option-1, 2 and 3) with telecos and other Service
providers for traffic exchange at all nodes should be supported.
y) Any to any, one to many, Many to many kind of service should be
supported from all nodes
z) Interop between OEM for non-vendor locking should be supported
at all nodes.
aa) Integration capabilities with IP/ATM/Frame relay/ TDM’s transport
technologies etc.
2. Key Features
a) All nodes in network must support protocol for management
information sharing so that devices can discover and reach to each
other.
b) Any changes in topology should be automatically learnt by all the
devices in network.
c) No manual intervention should be required in case of any physical
link failure.
d) Scalable dynamic protocol should be supported for transferring of
customer network information across all service edge devices.
3. QoS a) Low latency Queuing should be deployed to ensure CIR
Architecture guarantee to all Critical Traffic.
b) Minimum 4 Class-of-Service Model should be supported:
o Mission Critical : Class 1
o Business Critical : Class 2
o Business Critical Data : Class 3
o Best effort : Class 4

c) Matching of traffic should be based on ACL, IPP, DSCP &
MPLS EXP
d) Marking of traffic Should be based on MPLS EXP
e) Should also support weighted random early detection in the
network to avoid congestion
4. Traffic
a) Standard based protocols to automatically map packets onto the
Engineering
Capabilities appropriate traffic flows should be supported.
b) Should Support transport of traffic flows across a network using
MPLS forwarding.
c) Should support the determination of routes for traffic flows across
a network based on the resources the traffic flow requires and the
resources available in the network.
d) Should Employ "constraint-based routing," in which the path for a
traffic flow is the shortest path that meets the resource
requirements (constraints) of the traffic flow.
e) Should support QoS on Traffic engineering paths or LSPs.
f) Should support Recovery of link or node failures that change the
topology of the backbone by adapting to a new set of constraints.
Traffic engineering should be used for the following
g) Providing bandwidth guarantee for critical real-time applications in

the control plane
h) Optimized utilization of redundant
i) Handling of unanticipated load in the network
j) Fast reroute to provide fast convergence for critical real-time
application traffic.
5. MPLS VPN a) All Service edge nodes in network should support :
i. Layer 2 MPLS VPN
ii. Layer 3 MPLS VPN
6. Layer 2 MPLS
a) MPLS Transport Should be used for Providing Point to Point and
VPN
Point to Multipoint VPN services.
b) All these Services are in accordance of metro Ethernet Forum and
can be broadly categorized as below:
i. Ethernet wire Services
ii. Ethernet relay Services
iii. Ethernet Multipoint Services
7. Layer 3 MPLS a) Layer 3 MPLS VPN can be broadly classified in to :

VPN i. Hub and Spoke VPN
ii. MESH VPN
iii. Extranet VPN
iv. Multicast VPN.

1.1.2 Functional Requirements for NOC

SL No. Parameter Requirement
1. General
a) NOC to be established at Chennai in a space provided by in the
State Data Center.
b) NOC act as centralized management on full-network resource and
service inventory to improve utilization of in-service resources.
c) Provide key correlation analysis for network fault processing to
improve network fault processing efficiency
d) Provide the function of automatic service design and resource
distribution.
e) Provide performance & trend development analysis of network
equipment and impact range of network fault and supply end-to-
end service quality management & control, which control network
& service quality continuously and enhance customer satisfaction
f) Provide FOA (Field Operation Assistance) for field engineers.
g) SI needs to survey the site; design the layout of the site including
all the standard furnishings etc. to make the NOC operations. The
complete BOQ of the work to be done at NOC needs to be
submitted along with the design and approval to be taken from the
Authority before start of the work.
2. Key Functions
a) Centralized Operation
b) Network performance engagement
c) Planning and Engineering
d) Service management
e) Service provisioning
f) NOC Operation
g) Spare Management
3. Field
a) Connectivity
Operations
b) IT and Security
c) Provisioning on Field.
4. Core
a) Capable of connecting to 2 International Internet Gateways
Infrastructure
b) Capable of connecting to 2 National Internet Exchange Gateways
c) Setup IPV6 Network
d) ISP Peering & Up Stream Routers
e) Caching Servers
f) Core Switches for traffic aggregation
g) NMS (Network management system) for equipment’s to be
monitored. .
h) Network inventory & GIS management system

SL No. Parameter Requirement
5. ISP peering & Peering & Upstream Routers & Switches to be used the cross
Upstream connects need to be extended from Meet me room till Network
infrastructure Rack
6. NOC Routers 2 NOC routers operating in High Availability mode
7. Core Switches Min 2 Core Switches which will be connected on mesh mode to have
high availability.
8. Servers
i) All the Servers (CRM, NMS, Web Server), & FW devices will be
connected to these switches
j) All the servers will be kept behind Firewalls

B- Common Guidelines Regarding Compliance of Equipment/System

a) The specifications mentioned for various IT / Non-IT components are indicative requirements
and should be treated for benchmarking purpose only. Bidders are required to undertake their
own requirement analysis and may propose higher specifications that are better suited to the
requirements.
b) Any manufacturer and product name mentioned in the Tender should not be treated as a
recommendation of the manufacturer / product.
c) None of the IT / Non-IT equipment proposed by the Bidder should be End of Life product It is
essential that the technical proposal is accompanied by the OEM certificate in the format given
in this Tender, where-in the OEM will certify that the product is not end of life product and shall
support for at least 7 years from the date of Bid submission
d) All IT components should support IPv4 and IPv6
e) Technical Bid should be accompanied by OEM’s product brochure / datasheet. Bidders should
provide complete make, model, part numbers and sub-part numbers for all equipment/software
quoted, in the Technical Bid.
f) Bidders should ensure complete warranty and support for all equipment from OEMs. All the
back-to-back service agreements with respective OEMs should be submitted along with the
Technical Bid.
g) All equipment, parts should be original and new.
h) The user interface of the system should be a user-friendly Graphical User Interface (GUI).
i) Critical core components of the system should not have any requirements to have proprietary
platforms and should conform to open standards.
j) For custom made modules, industry standards and norms should be adhered to for coding
during application development to make debugging and maintenance easier. Object oriented
programming methodology must be followed to facilitate sharing, componentizing and multiple-
use of standard code. Before hosting the application, it shall be subjected to application security
audit (by any of the CERTIN empanelled vendors) to ensure that the application is free from
any vulnerability and approved by the Authority.
k) All the Clients Machines / Servers shall support static assigned IP addresses or shall obtain IP
addresses from a DNS/DHCP server.
l) The Successful Bidder should also propose the specifications of any additional servers / other
hardware, if required for the system.
m) All IP MPLS routers shall be from same OEM
n) The Servers provided should meet industry standard performance parameters (such as CPU
Utilisation of 60 percent or less, disk utilisation of 75 percent or less). In case any non-standard
computing environment is proposed, detail clarification needs to be provided in form of
supporting documents, to confirm (a) how the sizing has been arrived at and (b) how SLAs
would be met.
o) SI is required to ensure that there is no choking point / bottleneck anywhere in the system (end-
to-end) and enforce performance and adherence to SLAs. SLA reports must be submitted
quarterly/as specified in the Bid without fail.

p) All the hardware and software supplied should be from an Original Equipment Manufacturers
(OEMs). Authority reserves the right to ask replacement of any hardware / software if it is not
from a reputed brand and does not conform to all the requirements specified in the tender
documents.
q) All licenses should be in the name of the Authority.
C- Network Operation Centre – Technical Specification

1.1.3 42u Modular Network Rack
S.No. Minimum Requirement
42 U Network Rack of Dimension (800W X 1000D)
1 Modular cabinet Networking Rack-42U 800W -1000D -Block Fine Tex.
2 Modular cabinet Honey comb Flat Plain Door -42U -800W-Block Fine Tex-Assembly front
and Back door.
3 Modular cabinet Side Panel -42 U -1000D -Cam Lock -1/3 V
4 Fan’s- AC -90 Cfm -with four Fans - Assembly
6 Mounting Hardware packet -1000 Set
7 Metal Cable Channel -100 mm Width- 1600 mm Height – Black Fine Tex – Assembly.
8 Castor – 3 Inch Height – with Brake Assembly
9 Castor – 3 Inch Height – with Out Brake Assembly
10 Power Distribution Unit 2 nos - 06/16 Amp universal socket-6 socket- single pole / screw
Mountable / 32 Amp MCB / Alternating Current – Indicator – Black Fine Tex. – Assembly.
11 Power Distribution Unit should be of intelligent and should get monitored using SNMP
through network, should support SNMP V.2 and V.3
12 Rack should be having electronic, programmable, contactless card door lock.
Rack Access Control Requirement
13 The rack access control system should provide an extensive range of alarm and system
messages that should be customized.
Temperature
Unauthorized access
Status of Lock (open / closed)
Green period
Blocking period
14 The system should be able to provide wide range of options
Time stamp profiles
Days
Organizations
Temperature
Level of authentication – single, dual, triple
15 The system should be compatible for centralized architecture and de-centralized
architecture.

S.No. Minimum Requirement
16 The software must be reliable and convenient for different users with different access profiles
for their respective data racks.
17 All actions should logged as – log events ll which could also be exported (pdf, html, mht, rich
text, excel, icsv)
18 The software graphically displays the status of all swing handle stations in real time.
19 The swing handle lock should have multicolor status LED indicator and field for display of
rack name and number.
20 Four Eye principle – Triple authorization via transponder card and secret pin / numeric key
pad numbers at rack level
21 The Mechatronic lock should have memory to store 1000 user cards + 1000 pins + 1 Super
User
22 The system should work as standalone during network failure
23 The system should provide High Security, Control mechanism, Monitoring and Audit reports.
24 The swing handle should have a feature to turn to unlock automatically during emergency /
fire accidents
25 The Mechatronic locks should eliminate the use of traditional mechanical key locks for racks
26 The systems should be Retrofitted on server racks of different OEM rack manufacturers
27 It should have proper mechanism to override in case of network failure / power failure /
emergency without breaking the swing handle.
28 The system / software should facilitate planned access and super user function.
29 The System / software should have task scheduler for pre-programming the activities in DC
30 The system / software should allow specific user to be assigned to a specific rack.
31 The Software should integrate with authentication system like Active Directory, Radius, etc.,
32 The geographically distributed devices across different locations should be control, monitor
and audit from remote location.
1.1.4 NOC and Internet Router Specifications

S.No. Minimum Requirements Description
Chassis with Scalability
1 The Router should be 19” rack mountable, chassis based with modular architecture; the router
should be able to accommodate interfaces scalability as specified in Table in the sequel, either
by having additional slots or by having modules with higher number of interfaces to
accommodate future expansion.
Redundancy
2 The Router should have redundant CPUs, Switching Fabric, Power Supplies, and Fans / Fan
Tray’s, for high availability; all redundant subsystems must be hot swappable, including interface
modules.
High Availability of Line cards and the Control plane

3 In case of a line card failure on the router; the multicast routing, multicast distribution and
multicast replication architecture of the router shall have minimum impact and minimal packet
loss of multicast video, audio, and data traffic that are currently in progress on rest of the line
cards in the system.

High Availability – Protocols
4 The Router shall have Non-Stop forwarding, Nonstop routing with graceful restart and fast re-
convergence of routing protocols for (BGP, OSPF, IS-IS) and any other protocols enabled for
the Digital Infrastructure of Tamil Nadu.
Architecture
5 In case the primary route processor fails on the router, there should be ZERO packet loss on
the whole router for both unicast and multicast traffic.
Performance
6 All the Interfaces provided in the router should have wire-rate throughput (@64 Bytes) per slot
and the total router capacity (without degradation of throughput, if one of the CPU or switching
fabric fails).
Interfaces Capability
7 The Router should support optics for 100G, 10G, 1G interfaces; should provide maximum
distance of at least 70 KMs for 100G and 10G, 2 to 10 KMs for 1G without any additional
regenerators. Routers should support coherent DWDM with flexible grid support / OTN.
Clocking
8 The Router Line cards should have L2 and L3 service capabilities on all interfaces and should
have hardware timing protocol support such as 1588v2 (with boundary clock as well as ordinary
clock (master and slave) and sync E.
Operating system
9 The operating system architecture of the Router should be microkernel-based; the router shall
run all critical functions such as routing protocols, forwarding plane and management functions
in separate memory protected modules with storage of multiple images and configurations.
Failure of one module shall not impact operations of rest of the operating system. The Router
shall provide In-Service-Software upgrade from one version to another without any traffic
disruption and rebooting of the device.
10 It should have capabilities to Boot with multiple options such as booting from TFTP server,
Network node, as well as Flash Memory
Routing and Multicast Protocols
11 The Router should have IPv4 and IPv6 Routing, in the following: Border Gateway Protocol,
Intermediate System-to- Intermediate System [IS-IS], and Open Shortest Path First [OSPF]),
Hot Standby Router Protocol (HSRP)/ Virtual Router Redundancy Protocol (VRRP), BGP Prefix
Independent Convergence, GRE (Generic Routing Encapsulation) Tunnelling, Multicast routing
protocols IGMPv1, v2, v3, PIM-SM (RFC 2362) and PIM-SSM, MSDP, IGMP v2 snooping,
DHCPv6 and OSPFv3 for IPv6.
MPLS Protocols and VPN
12 The Router should support MPLS Provider / Provider Edge functionality such as MPLS VPN,
MPLS mVPN (Multicast VPN), NGMVPN, Carrier Supporting Carrier (CSC), DiffServ Tunnel
Modes, MPLS TE (Fast re-route), DiffServ- Aware TE, Inter-AS VPN, Resource Reservation
Protocol (RSVP), VPLS, VPWS, Ethernet over MPLS, Segment Routing, BFD, BGP-PIC, BGP–
LU, 6PE and 6VPE.

OAM
Router should support MPLS OAM, Ethernet OAM protocols - CFM (IEEE 802.1ag),
13
Link OAM (IEEE 802.3ah) and ITU Y.1731,
BRAS and CGNAT
Router should be able to support distributed BRAS functionality with min 64K
subscribers as and when required. Besides, the Router should have hardware based
14 CGNAT capabilities with a minimum of 10 Million sessions, 15 Gbps of Throughput and
scalable by 100% in future. This is to be provided in the Router with a hardware module
or as an additional device.
QoS Features
Traffic Classification using parameters such as source physical interfaces,
source/destination IP subnet, protocol types (IP/TCP/UDP), source/destination ports, IP
Precedence, 802.1p, MPLS EXP, DSCP, hierarchical shaping, scheduling, and policing
15
for the control of upstream and downstream traffic as well as 4 levels of scheduling for
HQOS in hardware and should have 64K hardware Queues.
Security
The Router should support Access Control List to filter traffic based on Source &
Destination IP Subnet, Source & Destination Port, Protocol Type (IP, UDP, TCP, ICMP
16 etc.) and Port Range etc.; per-user Authentication, Authorization and Accounting
through RADIUS or TACACS, URPF, DHCP snooping, control plane policing, MD-5
route authentication for RIP, OSPF and BGP.
Flow
17 The router should support Netflow-v9/J-Flow/ equivalent feature.
Management and Software Defined Network
The Router should support multi-level access with SNMPv3 authentication, SSHv2,
18 Multiple privilege level authentications for console and telnet access through Local
database or through an external AAA Server.
The Router should support an Architecture for Network Management using NETCONF
19
and YANG models.
The Router should have standards based PCE and PCEP protocols as per RFC 5440
20
to provide SDN capabilities to the network
21 The Router should support Zero touch provisioning
The Router should support Configuration Roll Back feature to recover the mis-
22
configured router to last good configuration.
Debug, Alarms, and Diagnostics
The Router should support the following:
1. Monitoring of Traffic flows for Network planning and Security.
2. System and Event logging functions.
23 3. Forwarding of these logs onto a separate Server for log management.
4. Embedded RMON support for the four groups - history, statistics, alarms and
events.
5. Debugging features to display and analyse various types of packets
Operational Logging and Performance Monitoring
The Router should support:
1. Event and System logging.
2. Event and system history logging.
24
3. Generate system alarms on events.
4. Facility to put selective logging of events on to a separate hardware with log
analysis

The Router should support streaming of data to a performance management system to

25 enable network administrators to measure trends in link and node utilization, and
troubleshoot issues such as network congestion in real time using Telemetry Interface.
Certification
26 The product offered or the family should be CE2.0 compliant.
Environmental
27 Operating temperature: 5 to 40 degrees with Humidity – 10% to 90% Non-Condensing.
1.1.4.1 Router Specifications Wire Speed

Specifications
FD 800 Gbps
NOC Router
HD 1.6 Tbps
1.1.4.2 Router Ports Specifications

Total
1GE 1GO 10GO 100GO Total Capacity
Ports
NOC Router
(6,0) (8,0) (12,0) (4,2) 32 734 Gbps
1.1.4.3 Routes and Addresses

Multi- Pseudo MPLS-
IPv4 IPv6 MAC RSVP- TE
NOC Router Cast Wire VPN
256k 256k 256k 32K 16K 500 16K
Internet Router 1 Mil 1 Mil 256k 32K 16K 500 16K

1.1.5 Core Switch

Make
Model
S.No. Minimum Requirements Description
Architecture
1 Modular Switch with at least 5 Slots
2 All interface modules, power supplies should be hot swappable for high availability
3 Shall support modular power supply and more power supply is added as a when required
The Switch should have control-plane and data-plane separation with control-plane redundancy in
4
hardware
5 All interfaces on the switch shall provide wire-rate throughput
6 The switch shall support following type of interfaces – 100GE, 40GE, 10GE, 1 Gig interfaces.
7 Chassis should be 19” rack mountable type
8 The operating system of the switch shall have a microkernel-based architecture.

The switch should be able to accommodate interfaces scalability to the interfaces mentioned from day-
9
1 either by using additional slots or by using module with higher number of interfaces.
10 Shall support Online Insertion and Removal (OIR) that is non-disruptive in nature.
The switch should have distributed architecture with Interface cards having own ASIC, memory for
11
enhancing the performance of the Data-Plane with local L2 and L3 capabilities in each card.
Should be supplied with necessary power cards, data cables, connectors, CD’s, manuals, bracket
12
accessories, wire managers and other appropriate accessories.
High Availability
13 Shall support On-line insertion and removal for cards including Power supplies and fans.
Shall support Non-Stop forwarding, Non-Stop Routing, Non-Stop Bridging for fast re-convergence of
14
routing protocols (BGP, OSPF).
15 Shall support multiple storage of multiple images and configurations.
Shall support link aggregation using LACP as per IEEE 802.3ad. The router shall support IEEE 802.3ad
16
link aggregation of minimum of 16 links within a single bundle.
17 Should support Boot options such as booting from TFTP server, Network node and Flash Memory.
L2 and L3 Protocols Features
Should support Industry Standard Port/Link Aggregation for All Ports as well as Cross Module Link
18
aggregation.
19 Should support MC-LAG or equivalent for a single (virtual) L2/L3 interface.
20 The switch should support IEEE 802.1w RSTP and IEEE 802.1s MSTP.
21 Should have RIP v1/v2, OSPF v1/v2 from Day 1.
22 Should support BGPv4, IS-IS.
23 Should support IPv6 packet switching and routing using OSPFv3, RIPng in hardware.
24 Should have VRRP Protocol.

Multicast Features
25 Should support H/W based IPv4 and IPv6 Multicasting.
26 Should Support IGMP v1, v2, v3, IGMP Snooping.
27 Should support Protocol Independent Multicast - Sparse Mode and PIM - SSM, MSDP.
Security Features
28 Should support Access Control Lists.
29 Should support various type of ACLs like port based and VLAN based.
Should support integrated security features such as DHCP relay with option-82, Dynamic ARP
30
Inspection.
31 Should Support MAC Address Filtering based on source and destination address.
32 Should have support for RADIUS and TACACS+
33 The switch should support Port-security.
QOS Features
34 Should support Ingress/Egress Queuing.
35 Should be able to filter, mark and limit traffic flows.

Should support policy based traffic classification based on Type of Service (ToS), IP Precedence
36
mapping, Layer 2/3/4 defined traffic flows, MAC address, VLANs.
37 Should Support hardware based QOS.
Management Features
Switch should be manageable through NMS on per port/switch basis with common interface for all
38 manageable devices on the network. Should Support SNMP, RMON/RMON-II, SSH, telnet, web
management through network management software.
39 Should support port-mirroring feature for monitoring network traffic.
40 The switch should support role-based access control to limit access to switch operations.
41 The switch should support configuration verification and rollback.
1.1.6 Next Gen Firewall at Data Center and DMZ (De-Militarized Zone)
S.No Minimum Requirement Description
Architecture
1 The appliance based security platform shall have firewall and IPS functionality simultaneously.
2 The platform should be based on real time, secure, embedded operating system.
3 Capability to detect hardware failure during power up and before going online.
4 Should provide Stateful failover.
5 HA configuration that uses dedicated HA-control interfaces apart from the mentioned traffic interfaces.
6 Should provide active/active and active/standby failover.
Hardware and Performance Specifications
7 Should support up to 20 Million Concurrent sessions and at least 500,000 sessions per second.
8 Should provide 80 Gbps Firewall Throughput and IPS throughput 20 Gbps.
9 Memory – at least 16GB or higher and 100GB storage.

S.No Minimum Requirement Description
10 Internal Redundant Power supply.
11 4 x 100 Gig Ports and 8 x 10G Ports
Features Specifications
IKEv1 and v2, IPsec VPN standards, 56-bit DES, 168-bit 3DES, OSPF routing, x.509, Up to 256-bit AES
12
data encryption.
Network and application level attacks ranging from malformed packet attacks to DoS attacks, Support
13
RSA and Diffie-Hellman, MD-5, SHA-1, SHA-128, SHA-256.
14 There are more than 3000 signatures for identifying anomalies, attacks, spyware, and applications.
15 Should support traffic normalization.
16 Should support Zero-day protection.
17 Stateful and stateless and Zone-based device.
18 Traffic anomaly protection.
Forwards DHCP requests from internal devices to an administrator-specified DHCP server, enabling
19
centralized distribution, tracking, and maintenance of IP addresses.
20 Rich dynamic NAT and PAT services.
21 Bidirectional NAT and Transparency.
22 Static NAT and PAT services.
23 Stateful and stateless and Zone-based firewall.
24 Denial of service (DDoS) protection.
25 Traffic anomaly protection.
26 Support for IPv4, RIPv2, OSPF, BGP, VLAN, DHCP. Support for IPv6 RIPng, OSPFv3.
Management Specifications
27 Web based management to support for remote monitoring.
28 Accessible through variety of methods including: Telnet, Console Port, SSH.
29 Dedicated Out-of-Management interface.
30 Support SNMPv1, v2, v3 & Support for syslog.
Should have the ability to create customizable administrative roles/profiles (monitoring only, read-only
31
access to configuration).
32 EAL-4 certified /NDcPP

1.1.7 Ports & Performance Requirement

Total Number of 64
Ports
Performance 1.54 Tbps Full Duplex
3.08 Tbps Half Duplex
Wire speed throughput – means all ports should be capable of handling data at the
rated speed all the time
Interfaces 1G Type Number Cumulative Handling
From day-1 of Ports Capacity
Fibre-SX 12 12 Gbps
Copper 12 12 Gbps
10 G Fibre-SR 18 180 Gbps
Future 10 G Fibre 10 100 Gbps

100 G Fibre 12 1200 Gbps
Cumulative 1.54 Tbps
(Minimum) Back-
Plane Capacity
Required
Routes and IPv4 512k
Addresses IPv6 512k
Multicast 64k
MAC 1 Mill
VLAN 4000
LAG 16 ports per group
QOS 8 Hardware queues per port

1.1.8 Hyper Converged Infrastructure

S.No Minimum Requirements Description
Qualification
The proposed solution should be in the leaders quadrant by latest FY18/19 Gartner Report for Hyper
1
Converged Infrastructure.
Architecture
It is proposed to have two HCI clusters, one for management and one for applications. The
management cluster shall have 3 nodes and the applications cluster shall have 3 nodes respectively.
Each node in both the HCI clusters must be configured with Intel Skylake processor with at least 20
2
cores useable (without any HCI overhead). Besides, each node should have at least 192 GB useable
DDR4 memory (without any HCI overhead).
Each module in both cases shall be populated using 2 sockets per node.
The management HCI cluster must be configured with at least 64 TB of usable capacity (even after one
node failure scenario) in the HCI cluster, after providing for not more than 1:1.25 data efficiency due to
3
compression and de-duplication. Erasure coding should be deployed for cold data not exceeding 40%.
The solution should be provisioned with minimum 10% SSD.
The proposed solution should support all leading Virtualization Software; viz., VMware ESXi, Microsoft
4 Hyper-V, Open KVM, and XenServer. HCI solution must support industry-leading protocols NFS, iSCSI
& SMB.
The proposed solution should provide hyper-converged software that allows delivery of storage
5 services across any type of disks (SSD, SAS, and NLSAS), without dependence on a separate Storage
Area Network & associated component such as SAN Switches & HBAs.
The proposed HCI solution should be fully software defined and should not leverage any specialized
6 (proprietary) hardware to run virtualization layer with virtual storage appliance, or for providing data
services such as de-duplication and compression.
Software Defined Storage Requirements
The proposed HCI solution for both management and application cluster should use Erasure Coding
7
for cold data.
The proposed solution should independently scale storage and compute as and when needed without
8 any downtime. HCI should support storage expansion without any virtualization license implication for
“only storage” expansion.
The proposed HCI solution must have metadata distributed on all nodes in a cluster i.e. each node in
9 the cluster should carry information about data lying across every other node in the cluster (including
its own), while maintaining the capacity utilization /and distribution across all nodes uniform at all times.
The proposed HCI solution should be able to create multiple logical unit (LUN's) for storage, with the
10
ability to support different policy for de-duplication and compression, across LUNs.
The proposed HCI solution must support Hybrid and All flash nodes in same cluster without impacting
11
any functionality
Future Scalability Requirements
The proposed solution must have capability to support HCI nodes with different models (same OEM) /
12 different CPU and Memory / Disks configurations in the same cluster without any impact on storage
services/functionalities.
13 The proposed solution should be scalable to 64 nodes in the same cluster without any federation.
Other Features, Requirements
All the required Hypervisor Licenses and the associated Hypervisor Management should be included
14
in the solution. Besides, all the required software and associated licenses to protected east-west traffic
S.No Minimum Requirements Description

by leveraging VM-based attributes such as VM names, Security tags, OS type, port number etc. should
be included.
The proposed HCI solution must provide logging, analysis, and reporting facilities related to operations,
15
performance, storage, CPU utilization management on a per VM basis.
16 The proposed solution should support multi-site (One-to-Many and Many-to-One) replication of data.
Connectivity Requirements
Proposed solution should integrate with L2/L3 network device. Each HCI node must be configured with
17
at least 4 x 10G Ethernet ports.
The proposed HCI should support native (without any third party software) File Services over NFS,
18
CIFS, and SMB and file replication across clusters and data centres.
Management Requirements
The Platform must provide management through a web based console. The Platform while providing
19 health and monitoring of entire platform, must also provide storage, compute, and hypervisor metrics
on a per VM basis. Besides, the Platform should support LDAP Active Directory integration.
20 The Solution should support RESTful API for third party integration.
The solution should have “Call Home” capability for remote log collection and proactive support for
21
predictive failure of hardware component.
SECURITY
The proposed HCI solution should support data at rest encryption without using any specialized
23
hardware.
The solution should support out of the box security compliance for proposed HCI solution to ensure
24 highly secure HCI environment. Solution should have as many industry certifications as feasible. (e.g.
NIST, FIPS140-2, EAL2 CCC-Common Criteria Certified, DISA- approved STIG).

1.1.9 GIS Software License

Preference is for an open source software. All data formats shall be compatible with
data/coordinate system of Tamil Nadu Geographical Information System (TNGIS) formats.
Make Offered:
Model Offered:
S. No. Minimum Specification
1 The system shall have capability to perform attribute or spatial queries on data from selected sources.
Solution shall ensure that the GIS Map provides complete details of the city in various digital vector
2
layers and allows for zoom in/out, searching, and retrieving information capabilities
3 The system shall support clipping and/or downloading of raster and vector data by authorized users.
4 The system shall support server side Geo-processing
5 The application shall have standard and modern map navigation tools of pan and zoom
6 The application shall support client requests to print the spatial data.
The system shall be able to support industry-standard data types, industry-standard data formats,
7
unlimited file size or database size, unlimited number of files or tables, and unlimited number of users.
8 The system shall support geocoding and reverse geocoding
The system shall allow the users to perform advanced spatial analysis like geocoding, routing, buffering
9
and attribute based analysis.
10 The application shall have standard and modern map navigation tools of pan and zoom.
11 The system shall have the facility wherein the user can opt to view in 2D or 3D environment.
The system shall be compatible with Google Maps, Bing™ Maps, Micro Station, AutoCAD, MGE,
12
FRAMME, G/Technology, ODBC source.
13 The System shall support hierarchical legends, and watermarks
The application shall allow users to views the data with different symbology styles like differentiating
14 feature records based on attributes or types, dynamic label generation with conflict detection, and
translucency of all raster data and area colour fill.
15 The system shall allow the user to find Address
The system shall be able to consume real-time enterprise published spatial data. It shall be able to
16
consume the third-party published OGC web-services.
Application shall be OGC compliant for database and shall provision conversion to other database
17
formats.
18 GIS tool needs to be bought in the name of the Authority and will belong to Authority.
1.2 Helpdesk
Make Offered:
Model Offered:
S No. Parameter Minimum Specifications
Routing of the calls to available agent would be done by ACD.
ACD would employ a rule based routing strategy
Automatic
Call ACD should be able to identify available agents and transfer the call
1.
Distribution accordingly
(ACD)
Call routing to the agents based on the “longest idle basis”
ACD shall seamlessly integrate with EPABX system

Make Offered:
Model Offered:
S No. Parameter Minimum Specifications
When a call is transferred to the IP phone then the call details should also
be simultaneously transferred to CAD software in a pre-defined format.
Allow interaction between telephone and a computer to be integrated or
coordinated.
Call Shall act as a common interface for integration of all the software
Telephony applications deployed.
2.
Integration Shall support relevant screen pop-ups on the agents’ screen on the basis
(CTI) of call location detection
Shall pass events & information of agents’ status & changes in agent
status as well as incoming calls to the computer applications
Shall help caller in interaction with voice and DTMF (Dual tone multi-flexing
Interactive signalling) via keypad. Through the IVRS system, caller would easily be
Voice able to direct the concern to appropriate agent at the helpdesk
3. Recording
IVRS shall be able to queue the calls and provide position number in
System
queue and approximate time to reach agent
(IVRS)
Shall support English and Tamil languages

1.2.1 BSS- Customized Billing Solution-
a. B2B-Enterprise Model: ISPs/Operator offering the Enterprise services (VPN, MPLS, P2P etc.)
to the Enterprise Customers. Service based, No. of Links/ dark fibre and Circuits based billing
should be supported.
b. Wholesale Model: Wholesale operator leasing the network to various CSP/ISP/Cable
Operators/OSPs. Dark fibre, Leased Line, Bandwidth, QoS/CoS/SLA based billing should be
supported.
I. Digital Customer Relationship Management (CRM): Digital CRM for Communication Service
Providers (CSPs) with complete selling, marketing, monetization and self-care capabilities.
With customer at the heart of offering, it offers a completely new way to interact and engage
with CSPs – Customers and Partners, enabling them to monetize their services via every touch
point, channel and device.
a. Enterprise (B2B): Integrated partner management module to create combined
offers/packages, using their core products with partner offerings. Digital CRM
should support following:
1. Organization/Unit/Channel Partner/Hierarchy creation: System should enable B2B

organizations to accommodate a wide variety of distributors, resellers, retailers and stores
on a single platform, while automating sales administration and maintaining the operational
efficiency required to drive customer satisfaction and, ultimately, profits.
2. Self-serve Organization Management: System should provide B2B customers with a self-
service area to set up and manage their company. The B2B customer builds an
Organization Structure to group their users who will interact with the B2B merchant in terms
of permissions, rights and their hierarchy within the organization. It shall be flexible enough
to allow for a wide range of company set ups from small and simple up to large and complex.
The self-service area includes the following functions:
a. Business units
b. Order permissions
c. Users and user groups
d. Cost centres Budgets
e. Order approval workflow
f. Early login to allow organizations to set up visibility of catalogues for general
purpose or logged in users.
g. Registration form available for customers logging in for the first time.
3. B2B Users and Access Groups: System shall allow to create various B2B users based on
various needs along with access rights
4. Persona and eKYC details: System shall allow to create the persona details for the B2B
Users created for Unit/Channel Partner that would carry all important information like:
Name, Address, Biometric Impression, Unique Identity number like Aadhar card etc.
5. B2B Spend Control: System should be able to support below
i. Cost Centres and Budgets – shall be added to the organization to group and
manage expenditure, and therefore reduce the B2B customer organization’s
exposure to the B2B Operator
ii. Credit Limit –Shall enable to protect their interests the Operator's Account
Managers can define Credit Limits for or within their B2B Customer
Organizations. They can assign multiple credit limits with a variety of currency
and date-range options to their B2B accounts. After an order has been placed
the Account Manager will receive a credit limit alert if an order has exceeded
the assigned limit. Orders will be processed up the point the credit limit is
reached; after which they will be directed to a holding area from which they can
be released by the Account Manager.
iii. Configurable Authorization and Workflows – Shall support highly configurable
workflow rules and authorizations ensure complete control over budgets.
Administrators can easily assign levels of access (or permission) to a specific
person or role. They can create and modify rules that allow users to access

customized catalogues, place orders within a given budget and/or approve
orders. (See also Order Approval feature, below)
6. B2B Self-Service: System should support below
i. In the online self-service area B2B customers shall be able to manage their
quotes, track order history and use the order replenishment and scheduling
capabilities.
ii. For B2B customers who are company approvers, there shall be easy access
to managing order approvals.
7. B2B Customer Account Management: System should support below
i. Self-service control over customer information such as delivery addresses,
payment methods, and personal details from within the My Account area.
Customers can manage details such as:
ii. Updating personal details.
iii. Updating account password.
iv. Editing / removing delivery address.
v. Setting a default delivery address.
vi. Setting a default payment method.
vii. Viewing order history
viii. Manage Units/View Hierarchy (CP)
8. B2B Special Pricing: System should support below
i. It shall support the various commerce accelerator for B2B examples special
volume pricing with tool-tips appearing on products with volume pricing setup.
ii. Digital CRM shall support other forms of special pricing such as customer,
customer group specific pricing and product (or product group) specific pricing
which can be configured.
9. B2B Multidimensional Products: System should allow to define multidimensional products
using multiple attributes i.e. Colour, Model etc.
10. B2B Advanced Search: System should allow advanced search option that shall allow users
to search for products using default string search or by their product IDs. After the search
result is presented, user may select multiple products which will later on be available in the
order form for mass purchases.
11. B2B Purchase Order Form Generation: System should allow
i. Should support advanced search functionality together with multidimensional
products attributes that shall enable customers to create mass orders in an
easy and efficient way. For each of the products in the search lists that were
added to the order form, system should create a grid list that displays all
available dimensions of all products together with their stock availability.
ii. Should support creation of orders that contain multiple products (dimensional
and non-dimensional items)
iii. Should support future availability of a product
iv. Should be available in both Product Details and Checkout view
12. B2B Online Ordering & Order Replenishment: System should allow users to place orders
online and schedule orders that are automatically replenished. It should also support the
below
i. Order Replenishment - B2B customers can better manage routine ordering by
using the automated stock replenishment capability.
ii. Re-Order -The same selection of products can be ordered based on a previous
order.
13. B2B Order Management: System should allow that all order management functions are
easily accessible from B2B Portal, from where B2B customers should have ability to view
their:
i. Order history details
ii. Order status details like Quantity approved, Order approved, rejected
iii. To manage their replenishment schedules or set up a new replenishment
schedule
14. Partial order fulfillment: System should facilitate partial fulfillment of orders in case of
insufficient stock. B2B user should be able to check this partially accepted order status from
order History, and shall be able to have details available such as available quantity &
reserved end date for that order. Accept & Reject button should be available against the

order and B2B user should be able to either accept the order with partial quantity or reject
the whole order.
15. Hold Orders: In case of insufficient stock, a B2B user(distributor) should be able to put an
order (coming from down line) on hold. In turn, B2B user should be able to raise an order
to its parent unit.
16. B2B Order Approval: System should support order approval, that should enable the manual
validation and approval of orders placed by a B2B customer both on the customer and on
the operator side. The key components of this process should include following:
i. B2B Customers should have specific ordering permissions such as a monetary
threshold per order. e.g. the order is less than the threshold, the order is
automatically approved. If the order exceeds the permission, the order is
placed in a pending approval state. Eligible order approvers are notified and
must manually approve or reject the order.
ii. Order Thresholds can be defined on a per-order basis, or cover a time span of
weeks or months. An optional permission to exceed the assigned budget can
be given to specific B2B customers.
iii. To provide customer approval for an order a user must have the B2B Approver
role. In addition, he must also have rights which define the monetary limits to
which he can approve. The position of the B2B Approver in the hierarchy is
used by the Customer Approval Process when finding the least senior B2B
Approver permitted to approve an order.
iv. If the order exceeds the B2B unit’s credit limit on the merchant’s side it requires
additional approval by the assigned Account Manager in the Digital CRM
business tools.
v. To view, approve and reject pending orders, the B2B Approver should be able
to use the Order Approval Dashboard.
vi. Features like Hold order, Approve/Reject partial orders, Cancel Order should
be available.
17. Easy Returns: System should allow to request a complete or partial return using B2B
storefront. This should allow to bypass having to call a customer service agent to return an
order that was placed. It should also support requesting a partial return for an order or
request a complete return for an order.
18. B2B Assisted Service Module: System should enable customer service personnel to
provide real-time customer sales and service support, using the same storefront across the
Omni-channel framework, both physically shoulder-to-shoulder, in-store, and virtually
online.
19. Checkout Privileges Respected: System should enable not to override checkout restrictions
that apply to the customer. If an agent tries to check out with a user that is not allowed to
do so (for example, the customer is an administrator and not a B2B customer), the message,
“your account does not allow you to checkout” here is displayed.
20. My Company Pages: System should allow customer service personnel to access the B2B
Portal -My Company pages on behalf of the B2B Commerce Administrator. The customer
service personnel shall only be able to access My Company if they have the administrative
privilege.
21. Advanced Configurations: System should also allow to configure for more advanced
scenarios, such as setting promotions that only an agent can apply to a customer's cart, or
create a special product category that is only viewable by agents.
22. Partner Credit Balance: System should allow to associate Credit Balance with Channel
Partner(CP). CP should purchase credit balance through online payment. Credit Balance
should also be augmented via commission earned by CP. The Credit balance is used by
CP to perform operations like Recharge, Subscriptions, B2B Order fulfillment. CP should
be able to view the commissions earned in B2B portal
23. Quick Communication: System should allow operators to send Email notifications
automatically to confirm/cancel orders, tickets or in responses to interactions.
24. 2-way Ticketing: System should allow each unit to have 2-way ticket visibility mechanism.
Units can raise their tickets from B2B portal & can view from portal itself. Units can see
tickets raised to them by their downline in back office.
25. Integration with PBSS: Digital CRM (B2B) should be integrated with PBSS (Partner BSS
aka Partner Management). The Channel Partner billing, commissions and pay-outs should
be triggered in PBSS system

26. Mobile APP for Partner: System should support following for Partner APP
i. View & Update Personal Data: View and update personal details associated
with the partners
ii. View Commission: View commission details
iii. View credit limit assigned by MSO
1.2.2 Billing System

The Billing System should support Enterprise & Wholesale Billing with following functionalities:
a. Product Management/ Product Catalogue
1. Product Life Cycle Management (PLM): Product lifecycle should define the lifespan of
the individual product from concept to retirement. Each entity in PLM shall have a
different lifecycle of its own.
2. Product Offer / Product Package Management: The system must provide a bottom-to-
top approach for creating product packages. The component model shall allow
OPERATOR to re-use existing components for speedy launches. Further, the system
shall enable the operator to edit/update these entities as per the business requirement.
3. Capability to offer variety of plans: Ability to leverage Product Management features to
quickly and easily develop & implement new pricing plans. It shall offer wide range
pricing plans for Convergent services - Volume-based Data Plans, Volume-based Data
with over-usage policies, Time-based (Happy Hour) Plans, Value-based Data Plans
4. Service Hierarchy Definition: Ability to provide Service Specification module that allows
creating services and sub-services with a support to create n-level of hierarchy of
services.
5. Service Level Convergence: The system should provide the convergent platform by
supporting prepaid and post-paid convergence, multi-service, multi-technology
convergence. It should support multiple business models viz. wholesale & enterprise.
It should have the ability to rate and bill usage of multiple services.
6. Product Offer Types: System should allow creating variety of tariff plans
a. Basic Plan consisting of the product specification, base tariff details and the
free usage details in the plan
b. Add-on Plan an offer over and above the basic plan in the customer account
to give additional perks such as a rate cutter, bandwidth on demand, special
tariffs/offers etc
7. Discount Scope: System should provide with Discount Scope. The scope defines the
visibility/availability of discount. (How discount will apply)
a. Package level Scope - The discounts are bound to the plans, to which these
are to be applied
b. Global level Scope - The discounts if not bound to any plan, will be Global i.e.
applied to all.
8. Product Manager should offer the flexibility to customize the configuration screens for
various entities – Rate Card, Usage Parameter Group, etc. as per OPERATOR’s
requirement. This will allow OPERATOR to decide as to what features are to be made
visible on the screen at the time of configuring a specific entity. OPERATOR can restrict
the availability of certain features as per requirement.
b. Billing Functional Requirements:

1. Bill Cycle Management: System should support Bill Cycle Management. A CSR
assigns a bill cycle to the customer account at the time of account creation. A bill cycle
is the period for which the BE generates bills for the set of customers that belong to the
particular bill cycle.
2. Invoice Types: The Billing system should support below type of invoices:
a. Sales Invoice - Sales Invoices are generated for the below event/process:
i. When service instance is activated from registered state with billing
effect as 'immediate', a sales invoice for advance charges is generated.
ii. A manual invoice (of type sales invoice) can be generated for the
existing or non-existing/walk-in customers.
b. Regular Invoice - Regular invoices are cyclic invoices that are generated at the
end of billing cycles defined for the customer. Bill Generation Agent is used to
generate regular invoices for customers.
c. On-demand Invoice - The on-demand invoice is generated when the customer
requests for the invoice in the middle of billing cycle. The On-demand invoice
cannot be generated for the future date. This invoice consists of arrears
charges and usage till date.
3. Bill Rules Management: System should support Bill Rule Management. A Bill Rule
Configuration is a technical framework which enables the system to comply with
changing business requirements. Bill Rules can be used to define certain criteria based
on which the billing will be done.
4. Customized Bill Templates: System should support Bill template (JRXML/XSLT)
management. Bill template management will be used to define Invoice templates to
generate formatted bills. The file types can be text or PDF.
5. Tax Application: System should support the following:
a. Tax Application configuration allows you to apply tax globally or based on some
attributes. The tax amount can be configured as either of the following:
i. Inclusive – The tax amount is included in the charge amount
ii. Exclusive – The tax is applied exclusively on the charge amount
6. Split Bills Functionality: System should allow the service provider to configure aksplit
charge refers to customized allocation of charges across two billing accounts as per
the subscriber's requirement. The following charges can be split:
a. Non-Usage Charges – The rentals and other recurring charges can be split
across the billing accounts in absolute or percentage value of the total amount.
b. Usage Charges – The usage charges can be split using the following:
i. Time band split – The usage done in the specific time duration of the
day can be split, the rest borne by the owner.
ii. Absolute or Percentage – The usage charge can be split across the
billing accounts in absolute or percentage value of the total amount
7. Backdated Billing: System should support backdated billing. Backdated Billing is used
to bill accounts, services, product and discounts to a prior date. Backdated billing is
used to charge customers for previous dates.
8. Trial Bill Generation: System should support Trial Bill functionality. The Trial Bill Run
should allow OPERATOR to validate the accuracy of the bills before actually generating
bills for the customers.
9. Bill Delivery Modes: System should support sending paper copy or electronic copy of
bills to the customers. Required delivery mode for the bill can be selected when the
customer account is being created in the system.
10. Bill Download Formats: Should allow operator to download an invoice in different
formats like – PDF, CSV, XLS, TXT, POSTSCRIPT, HTML and FLATFILE. One can
download both trial bill and the actual bill.
11. Bill Disputes Handling: System should allow the service provider to manage the bill
disputes raised by the subscribers. It should allow marking the subscriber's bill or a
particular bill charge as 'Disputed' or 'Undisputed' with reasons. A dispute can be raised
on the following:
a. Bill – In this case, the dispute is raised on the total bill amount
b. Bill Charge – In this case, the dispute can be raised on a particular charge that
is erroneous.
12. Cancel Bill: System should support Cancel bill feature to allow service provider to
cancel the existing invoice and reproduce new invoice with correction.
13. Re-Generate Bill: System should support Re-Generate Bill functionality to allow service
provider to generate the cancelled invoice again after correction.
14. Generate aggregated statement: System should support generation of aggregated
statement. Billing Aggregator is an entity that has multiple billing accounts mapped
under it. It will serve as a grouping entity of all billing accounts mapped to the single
billing aggregator.
15. Types of Services:
a. L2 & L3 VPN
b. Fibre leasing
c. Internet Bandwidth
16. Customer Types:
a. CABLE MSO providers
b. Telco Service Provider / Internet Service Provider

c. Government Offices/Setup (Horizontal Connectivity)
d. Private B2B Customers (Banks etc)
17. Tariff shall include leasing partner’s agreement, but not limited to:
a. Unit (monthly, quarterly, yearly).
b. Fixed charges
c. Maintenance charges
d. Bandwidth offered (as per the Contract with the fibre Leasing Agency)
e. Length of Fibre
f. SLA based events
g. Quality of Service based
h. Class of Service based
c. Payments & Adjustments:

1. Payment Channels: System should provide with the following payment modes through
which billing accounts (subscribers) can make payments:
a. Online Payment Mode – Online payment mode refers to the payment
modes through which payment is realized promptly. It includes: Cash,
Credit Card, Debit Card, Online, and Demand Draft.
b. Offline Payment Mode – Offline payment mode refers to the payment
modes that require any third party involvement for realizing payments. It
includes: Direct Debit and Cheque
2. Payment Priority: System should provide the support for defining payment priority.
When a partial payment is made, the payment priority settings done by the operator
are used to determine which elements of the bill are to be treated as paid and which to
be treated as partially paid or unpaid.
3. Third Party Payment Gateways/Institutes: System should allow operator to configure
the third party institutes such as Banks (Cheque, Direct Debit) and Payment Gateways
(Online Payment).
4. Customized Payment Receipt Format: System should support configurable format of
the payment receipt to have desired look & feel and contents in the receipt. Payment
Receipt Templates should be configured for Original Payment Slips as well as
Duplicate Payment Slips.
5. Payment Agreements: The system should allow configuring Payment plans to offer
payment flexibility to the subscribers. Two types of payment plans can be configured:
a. Budget Payment Plan - This payment plan can be used to configure the
Auto Deduction payment method for the subscriber accounts
b. Instalment Payment Plan - Instalment Payment Plan can be associated
with a billing account so that the subscriber can make payment for pending
debits/invoices in instalments.
6. Payment Types: System should support following payment types;
a. Debit Payment – This payment type refers to the payment against a debit
document or an invoice. The system allows making payments in full,
itemized, or partial amounts for all debit documents or for only the selected
debit document(s) in a selected account.
b. Advance Payment – This feature allows you to make advance payments
for an account. Such payments are used to offset debits through auto-
adjustment.
7. Transfer Payment: System should support a feature where the unadjusted amount in
a subscriber’s billing account can be transferred to another subscriber’s billing account.
8. Defer Payment: System should support a feature that allows the operator to defer a
payment date to a prior or a previous date. A payment is deferred in cases where you
do not want a subscriber to incur late payment charge (LPC).
9. Write-off Bills: The system should allow fully or partially waiving off the outstanding
amounts for a scenario like bad debt recovery.

d. Dunning:
1. Dunning types: System should Support dunning both at the invoice-level and account-
level:
a. Invoice-level Dunning – In invoice-level dunning the receivables are chased on
an invoice by invoice basis.
b. Account-level Dunning – In account-level dunning all overdue amounts for an
account, across several invoices, are handled by a single dunning action.
2. Dunning Notification Management: System should allow configuring the following
Notifications related to Dunning:
a. Dunning Notification Action (Communication to Subscriber)
b. Dunning Unit Activity (Communication to Internal Staff)
c. Dunning Escalation (Communication to Action Administrator)
d. Collection Agency
3. Business Rule Management: System should allow Dunning to creating Business Rules.
These rules are created to achieve business cases which are subject to change as per
operator’s policy or government regulations.
4. Credit Class: System should allow defining the credit class for a subscriber. The credit
class defines a category of the subscriber and associated risk of revenue can be taken
with that subscriber. A credit class also defines which dunning scenario is to be applied
to the subscriber.
5. Dunning Actions: System should support Dunning Action Management. Dunning Action
Management contains a set of actions which forms part of dunning scenario and vary
in their applicability as per the configuration of scenario.
a. Soft Dunning Actions (Dunning Notices)
b. Hard Dunning Actions (Blacklisting)
6. Reverting Dunning Action: System should provide a feature to revert the dunning
actions performed on an account. It might be required in a scenario where a customer
is blacklisted and once the unpaid debts are cleared, subscriber must be white-listed.
e. Staff & Access Management:

1. Access Control List: System should provide with the support of access rights, based
on the user's role. It provides function for associating users with configurable roles that
define which areas of functionality and data within the system, the user is allowed to
access, and what transaction limits are imposed on the user.
2. Access Groups: System should provide with the support of access groups to define the
rights that a group of users should have, based on the functions that are required to
perform respective duties.
3. Staff Creation Modes: The system shall support the following modes for staff creation.
The administrator can create staff accounts through either of the following two modes:
a. Create Staff': By specifying all details such as login details, personal details,
contact details, and adjustment details
b. Create Quick Staff': To create staff instantly by entering only essential details
c. Staff accounts can be searched, viewed, edited or deleted any time
d. Staff Management Activities: System should provides following functionalities
to manage the staff account: Update Staff, Update Billing Area, Update Access
Group, Change Status, Change Username, Change Password etc
4. Audit Trail: System should provide the Audit Trail functionality. Audit Trail keeps track
of who did what, to what, and when they did it, as well as who tried to do something
but was unsuccessful.
5. Event Notifications for staff activities: System should allow to configure notifications for
the following events - Create Staff, Update Staff, Change Staff Password, Change Staff
Status, Change Staff Username, Forgot Staff Password
6. Alerts and Reminder Management: The system should allow sending alerts and
reminders to concerned user when any configured/required activity is performed. To
send alerts first the alerts need to be configured in System alerts and reminder
management.

f. Web Self Care Module
1. Web self-care module shall be able to provide a one-stop facility to the corporate
customers (enterprise wide access – corporate self-care) with secure access to their
information including but not limited to Bill viewing, Bill payment, complaint booking &
monitoring, purchasing products & services online, updating personal information,
general enquiry etc. using a standard Internet browser.
2. The main components of the Web Self Care Portal Framework which are available on
365x24 basis
3. Delivery Channels: Corporate Customers (enterprise wide access – corporate self-
care), customers / dealers, Field Users, Regional Users Citizens and other Agencies.
System shall support all types of customers / dealers including corporate customers.
4. Presentation Services: Application Services, Marketing Requirements
Notification Services, Searching and Personalization, Online help
5. Business Support Services: Custom Applications, Electronic Bill presentment and
payment, Processing Services and Reporting / Report Generation
6. Identity and Integration Services: Account and Service Management Features, Identity
Management, Authentication and Authorization, System Messaging, Trouble Ticketing
7. Infrastructure Services: System Maintenance, System Management Integration web
self-care module with the CRM, Billing, etc and other third party system (e.g. NMS,
GIS etc). The portal framework supports content delivery to a number of different
devices.
8. Web Portal: The web portal would provide information as well as links to delivery
services for the main actors in the system.
9. Payment Gateway Integration: The solution would support Payment Gateway and also
support the integration with the TANFINET and all System Users through the web portal.
10. SMS Gateway Integration: The solution would support SMS based services and also
support the integration with the TANFINET and all System Users through the web portal.
11. Email Integration: The solution would support email based services and also support
the integration with the TANFINET and all System Users
g. MIS Reports and Analytics System

1. TANFINET will have multiple applications in their IT environment, applications such as
Customer relationship management (CRM), Billing System, Order management and
provisioning application, etc.
2. The centralized enterprise reporting system shall have visibility and access capability
to take data from all the mentioned applications and will create reports and analytics to
be used for various reporting purposes by TANFINET.
3. System should have the capabilities to present reports in a dash-board like
environment for the top management so as to help them make intelligent decisions
based on factual data.
4. System should have capability to use Data Centre (DC) environment by using
production/archived data for report generation. The reporting requirement is primarily
two types:
a. Mandatory Reports (Standard): Needed by TANFINET Management, TRAI,
CCI, DOT and other government agencies.)
b. Customised Reports: Needed by TANFINET on Daily, Weekly, Quarterly and
Yearly Basis for various Activities:
i. CRM
ii. Billing
iii. Payments
iv. Service Activation and Assurance
v. Trouble Tickets
vi. Contact Centre Activities
vii. Batch Mode replication of Data
5. The System should take care of the enterprise wide reporting need for TANFINET and
should have the components for creating comprehensive reports.
6. SI must have capability to support additional Reporting and Analytics requirements
during implementation and contract period as per TANFINET business needs.
7. The specifications listed below layout requirements of a platform required for reporting
needs of TANFINET middle level & top management for this project.

a. The users shall be able to login and access the reporting platform based on
their privileges.
b. MRAS must have web based interfaces
c. Able to pull and analyze data from multiple data sources in Data Center.
d. Ability to drill, slice, dice. The level of drill, etc. shall be finalized in the SRS
Phase.
e. Ability to create graphs, charts on parameters mentioned in Reports
f. Ability to download reports for TANFINET Management users depending on
access privileges
g. Must provide online Help and Tutorial feature to get the desired outputs
h. MRAS Management of Users, Folders, Servers, Objects, User Groups,
Server Groups, Authorization and Setting
i. Each user shall be able to get scheduled reports on his/her chosen e-mail ID.
e.g: Various report type
j. Ad Hoc Reports
k. Object and Folder level Security
l. Multiple Export format support including PDF, MS XL, MS Word, RTF and
HTML
m. Objective model programmable administrative control mechanism
n. Parameterized reporting and sorting
o. Cross Platform Deployment
8. The report design software shall have following features:
a. Multiple report types including Mailing Labels, Cross Tabs, Conditional and
other reports
b. Local printing and exporting capability
c. Formula expert, customs functions and display string formatting
d. Unlimited SQL commands
e. Capability error-check queries in the reporting software. Policies in this regard
shall be user configurable by the administrator.
I. Monitoring Tool: The monitoring tool shall monitor following parameters:
1. Hardware and Software Application modules of at NOC.
2. The management system shall alarm critical, major and minor events.
a. The Management System shall display alarms based on violation of traffic
thresholds of each of the interfaces, interconnection links with other nodes
and system performance indicators (KPI). It shall be possible to customize
these KPIs. Display alarms based on thresholds violation system
parameters such as: size of files systems, processor load, memory
utilization etc.
3. All kind of reporting about system’s capacity & licensing utilization. Reporting about
connected/concurrent users; Reporting about connected users & their status with time
duration.
4. Monitor performance and faults. Support for event notifications. Support of SNMP
protocol standard. Support full backup and restoration of the system configuration,
system database, reports, configuration profiles, views, maps, Concurrent number of
transactions/second etc.
5. Login and session details, browsing history and audit trails. The solution shall provide
at least the following statistics. Number of login attempts; Number of successful
sessions; Number of failed sessions.
II. Order Management: Order Management System shall manage and orchestrate different type
of order/request related to other systems namely CRM, Billing etc. The OM system shall enable
the complete business flow for order entry / replacement and fulfilment:
1. The system shall include an integrated order entry process for various types of products,
places of installation, geographic area and clients, temporary product. CRM should
ensure all necessary information about the Customer Order (for example, type of
product, address, payment information, special requirements, etc.) is available.
2. This functional area must be able to receive service requests from the Order Entry
system. This process behaves as an entry point for service requests into the application
and notifies the Order Management functional area of new or changed service requests.
Order Entry shall be able to receive different types of orders e.g. installation, fault,
maintenance etc.

3. Multi-channel - The Order Entry process shall be prepared to receive order feeds from
a number of different channels, such as Customer Care applications, back-end offices,
POS, third party dealers, Internet, extranet, intranet, IVR- etc.
4. The Order Entry process shall be integrated with the CRM, billing etc.
5. Order priority - Ability for the service representative to assign and display a priority level,
indicating the level of care that needs to be given to the order
6. Billing accounts information - Ability to capture billing account and billing information
required to bill the product or service.
7. Order identification - The system shall generate a unique internal order ID. It shall also
be able to reference an internal order ID with several external order IDs.
8. Provide information with order status - Provide CSRs or other entities with information
regarding the order status.
9. Order tracking - Ability to track all information within an order at all task levels; Ability
to monitor orders by different types of information, which may be geographical
information, order type, resources allocated, etc.
10. View orders/requests rejected by downstream systems - Ability to view order status
based on rejections by downstream systems (e.g. Billing, CRM).
11. Managing multiple order amendment - Ability to recycle in batch multiple orders after
correction for a particular rejection; with this functionality, OM is able to correct all the
orders for which the same rejection occurred (e.g., product-related rejections).
12. Interface with provisioning platforms: Workflow engine shall have to interface with the
provisioning platforms following the order, thus installing the necessary features and
line classes, modifying them or taking them away. Also, it shall be possible to interface
both online and through batch processes
13. Re-routing of orders - Ability to re-route the order or create an alternative workflow
based on information of up- and downstream systems.
14. Escalation of orders - Mechanism based on a set of business rules to escalate orders
in terms of workgroups, priority etc.
15. Support of order life-cycle in differing transition states - Ability to flag the order to the
appropriate office for manual intervention (e.g., incomplete information).
16. The system should have the ability to define the type of fulfilment required for a
particular order. These types of fulfilment shall be determined according to business
rules which include all the functionality associated with service provisioning, inventory
management and work force management, necessary to complete the order.
17. The system should have the capability to break down an order into different parts and
fulfil the parts separately at different times. This can be linked to the provisioning timing
or to the customer’s demands.
18. The system should have the capability to automatically recognize that the entire work
has been done and that the order can be closed and moved to order history.
19. It should allow cancellation of customer order. Order cancellation request may come
from Portal/CRM. Penalty for cancellation will be as per pre-configured rules. CRM
should inform customer regarding cancellation penalty (if applicable).
20. Reports – The system should be able to generate various management and analysis
reports such as Total number of orders, Number of orders per input source, per entity
and per user etc.
1.2.3 Enterprise Management System

Various key components of Enterprise Management System (EMS) are:
a. SLA & Contract management System

b. Network Monitoring System
c. Server Monitoring System
d. Helpdesk System
Respective OEM/Vendor shall provide Element Manager to manage their supplied hardware
equipment. Umbrella NMS will integrate and consolidate Event, Performance, Configuration, reporting
and Network compliance across a multi-vendor setup.
Proposed EMS Solution shall be based on industry standard best practice framework such as ITIL etc.
S. No. Parameter Minimum Specifications

The EMS shall support capability for monitoring and configuration of
DWDM based Optical and IP/MPLS network through NOC
EMS shall support single management system for optical and IP/MPLS
network to provide ease of operation.
EMS shall be capable of providing the FCAPS functionality to the
network. EMS shall provide all necessary information to NMS on
standard interfaces.
EMS for Network Elements shall support northbound open interfaces
such as SNMP/JAVA/CORBA/XML or any other protocols for
integration with the NMS.
The EMS system shall support SNMPv1, v2 & v3.
EMS shall support client–server based architecture. Client being
GUI/web browser based access with secure interface to the server.
EMS should allow the user to zoom down to the port level of any given
card /equipment.
EMS should support administrative operations to be performed
repeatedly such as: NE configuration backup, software image
download, operator login/logout attempts, etc.
EMS must support below network element software management: -
a. Loading of new software images.
b. Management of multiple versions of software
c. Installation of software updates.
d. Software download status reporting.
1. General
e. Administrator authorization for the loading of software
f. Coordination for the software download to multiple end element
based on a single software source.
g. Version control for all network
h. Administrator authorization for the loading of software
The EMS GUI should allow authorised personnel to create and activate
end-to-end services.
The EMS should be able to provision, configure and manage network
for DWDM and IP/MPLS
EMS should allow service and equipment provisioning.
The Management System shall be able to auto-discover the Network
elements and the corresponding connections between them.
The EMS should support provision of creation, addition, deletion,
updation and viewing capability of the managed network
The system should support health monitoring of all modules and
indicate health of the system and connectivity.
The Management System shall support the provisioning of :-
a. All equipment parameters.
b. Threshold Crossing Alert(TCA) Alarm Severity
Alarms should be categorised into different categories e.g.
Emergency/Critical, Flash/Major, Immediate/Minor, Priority/Warning,
Deferred/Informative depending upon the severity of the alarm.


EMS should be able to display the Network Elements and the links in
different colours depending upon their status for healthy, degraded and
critical alarm conditions.
Dashboard should indicate the number of active alarms with filtering
options based on the period, duration, severity, event type and location.
The NMS system should support email or SMS feature for informing
user
All failure and restoration events should be time-stamped.
The GUI shall provide the ability to create, delete and modify topology
views of the network.
EMS should be based on open, secure, and scalable software for
optimizing network infrastructure and operations
EMS Should support editing that provides the ability to view, edit, and
delete all aspects of a device’s configuration.
EMS should support audit logs
EMS Should support rapid deployment of DWDM based Optical and
IP/MPLS network.
EMS Should support APIs for customization and integration.
The system should be able to create performance reports and Alarm
reports. These reports shall be HTML or pdf which can be dynamically
generated and sent over e-mail.
The system should allow creation of group profiles with multiple users
as member and should facilitate with similar access policy and
permission.
The EMS should support RADIUS/TACACS based access control
The SLA & Contract Management solution should enable the Authority
to capture all the System based SLAs defined in this Tender and then
calculate quarterly (or for any duration) penalty automatically.
Measuring service performance requires incorporation of a wide variety
of data sources of the project. The SLA solution should support the
collection data from various sources in order to calculate Uptime /
Performance / Security SLAs. Various features required in this
component to EMS are -
It must be a centralized monitoring solution for all IT assets (including
servers, network equipment etc.)
The solution must have integrated dashboard providing view of non
SLA &
performing components / issues with related to service on any active
2. Contract
components
Management
The solution must follow governance, compliance and content
validations to improve standardization of service level contracts
Application should be pre-configured so as to allow the users to
generate timely reports on the SLAs on various parameters.
The solution must support Service Level Agreements & Lifecycle
Management including Version Control, Status Control, Effectively and
audit Trail to ensure accountability for the project.
The solution must have the ability to define and calculate key
performance indicators from an End to End Business Service delivery
perspective related to the Project under discussion.


The solution should support requirements of the auditors requiring
technical audit of the whole system
The solution most have an integrated dashboard, view of Contract
Parties & current SLA delivery levels and view of Services & current
SLA performance
The solution should support SLA Alerts escalation and approval
process.
Solution should support effective root cause analysis, support
capabilities for investigating the root causes of failed service levels and
must make it possible to find the underlying events that cause the
service level contract to fail.
Support for Defining and Calculating service Credit and Penalty based
on clauses in SLAs.
Ability to generate reports on penalty and credit due, to check on non-
compliance of SLAs.
Monetary penalties to be levied for non-compliance of SLA, thus the
system must provide Service Level Performance Report over time,
contract, service and more.
The solution should provide historical and concurrent service level
reports for the project in order to ensure accountability of the service
provider’s performance
Automatic Report creation, execution and Scheduling, must support
variety of export formats including Microsoft Word, Adobe PDF etc.
The solution must support Templates for report generation, Report
Filtering and Consolidation and Context sensitive Drill-down on specific
3. Reporting report data to drive standardization and governance of the project
The solution must support security for drill-down capabilities in
dashboard reports ensuring visibility for only relevant personnel of the
project
Support real-time reports as well as historical analysis reports (like
Trend, TopN, Capacity planning reports etc.)
a. Resource utilization exceeding or below customer-defined limits
b. Resource utilization exceeding or below predefined threshold
limits
An indicative List of SLAs that need to be measured centrally by SLA
contract management system are given in the Tender Document. These
SLAs must be represented using appropriate customizable reports to
ensure overall service delivery.
Solution should provide Fault, Configuration & Performance
management of the entire datacentre infrastructure and should monitor
IP\SNMP enabled devices such as Routers, Switches, Cameras, Online
UPS, etc. Proposed Network Management shall integrate with SLA &
Contract Management system in order to supply KPI metrics like
Network availability, utilisation in order to measure central SLA’s and calculate
4. Management penalties. Following are key functionalities that are required, which will
System help measuring SLA’s as well as assist administrators to monitor
network faults & performance degradations in order to reduce
downtimes, increase availability and take proactive actions to remediate
& restore network services.
The proposed solution must automatically discover manageable
elements connected to the infrastructure and map the connectivity

between them. Solution should provide centralized monitoring console
displaying network topology map from central location to node level.
Proposed solution should provide customizable reporting interface to
create custom reports for collected data.
The system must use advanced root-cause analysis techniques and
policy-based condition correlation technology for comprehensive
analysis of infrastructure faults.
The system should be able to clearly identify configuration changes as
root cause of network problems and administrators should receive an
alert in case of any change made on routers spread across project.
Network Performance management system should provide predictive
performance monitoring and should be able to auto-calculate resource
utilisation baselines for the entire managed systems and networks and
allow user to set corresponding upper and lower threshold limits based
on baseline data instead of setting up manual thresholds for monitored
devices.
The system must support the ability to create reports that allow the
network administrators to search all IP traffic over a specified historical
period, for a variety of conditions for critical router interfaces.
The proposed system must be capable of providing the following
detailed analysis across network domain:
a. Top utilised links (inbound and outbound) based on utilisation of
link
b. Top protocols by volume based on utilisation of link
c. Top host by volume based on utilisation of link
The proposed tool should integrate with network performance
management system and support operating system monitoring for
various platforms supplied as part of the project.
The proposed tool must provide information about availability and
performance for target server nodes.
Server The proposed tool should be able to monitor various operating system
Performance parameters such as processors, memory, files, processes, file systems,
5.
Monitoring etc. where applicable.
System
The solution should provide a unified web based console, which
consolidates all aspects of role based access under a single console.
Proposed Network Management shall integrate with SLA & Contract
Management system in order to supply KPI metrics like availability,
utilization, and performance in order to measure central SLA’s and
calculate penalties.
The proposed helpdesk solution must provide flexibility of logging,
viewing, updating and closing incident manually via web interface for
issues related to project.
Helpdesk system should provide incident management, problem
Centralized management templates along with helpdesk SLA system for tracking
6.
Helpdesk SLA’s pertaining to incident resolution time for priority / non-priority
incidents.
The proposed helpdesk solution must have a built-in workflow engine to
define escalations or tasks to be carried out after issues or change order
are logged pertaining to the project.


Centralized Helpdesk System should have integration with
Network/Server Monitoring Systems so that the Helpdesk Operators
can associate alarms with Service Desk tickets to help operators that
for what particular alarms corresponding helpdesk tickets got logged.
Network admin should be able to manually create tickets through Fault
Management GUI.
System should also automatically create tickets based on alarm type
System should provide a link to directly launch a Service Desk view of
a particular ticket created by alarm from within the Network Operation
console.

1.3 Project Management Software

Make
Offered:
Model
Offered:
S. No. Minimum Specification
1. SI shall procure a licensed project management software in the name of the Authority.
2. The Project Management System should have the following modules:
1. Task management
2. Workflow management
3. Inventory management
4. Integration with project plan and critical path identification
5. Survey module
6. Implementation module
7. Mobile application for the field level users
8. Integration with GIS
9. Project dash boards
3. The platform should allow integration and data fetching from other similar PM tools
(automatically and manually) to facilitate a unified view of multiple projects in a single
PM tool.
4. Additional 10 licenses for Purchaser
5. Provide a framework for project management
6. Provide a clear view of the project in terms of: Resources, Cost, Time to complete, Risk,
Priority, Progress
7. Provide a single repository for maintaining project data, project documents, resource
pools and skills
8. Allow to define project steps like tasks and subtasks
9. Allow to create complex dependencies between tasks
10. Support resource management
11. Provide user and user role management
12. Support budget control, invoicing and payment control integrated with TPA, Purchaser
and Finance Dept. of Purchaser.
13. Support storage of data in the centralized data storage or as specified by TANFINET
14. Change management
15. Cataloguing of project requests
16. Assessment/approval of project requests (feasibility, risk, etc.)
17. Project prioritization, Customized KPI setting, Data fetching according to KPI and
Analysis of data w.r.t KPI
18. Tracking project documents (Survey reports, statements of work, project plans, etc.).
19. Capturing and reporting on project progress, issues and changes.
20. Providing high-level project status reports and dashboards and provision of customized
dashboards, reports/analysis and archiving facility for 6 months
21. Post-implementation project audits (checklists, etc.).
22. Providing project performance reports/scorecards.
23. The proposed tool should be a carrier grade tool which has proven capabilities in
Telecom /Internet rollouts

1.4 Workstation
Make Offered
Model Offered
Sl. Parameter Minimum Specifications
No.
1. Processor Latest generation 64bit X86 Quad core processor(3.33 Ghz) or
better
2. Chipset Latest series 64bit Chipset
3. Motherboard OEM Motherboard
4. RAM Minimum 8 GB DDR4 ECC Memory @ 2133 Mhz. Slots should
be free for future upgrade. Minimum 4 DIMM slots, supporting
up to 32GB ECC
5. Graphics card WHQL certified Graphics card with 2 GB video memory (non-
shared).
6. HDD 2 TB SATA-3 Hard drive @7200 rpm
7. Media Drive NO CD / DVD Drive
8. Network interface 1000BaseT, Gigabit Ethernet (10/100/1G auto sensing)
9. Audio Line/Mic IN, Line-out/Spr Out (3.5 mm)
10. Ports Minimum 6 USB ports (out of that 2 in front). These would be
disabled for data transfer.
11. Keyboard 104 keys minimum OEM keyboard
12. Mouse 2 button optical scroll mouse (USB)
13. Monitor 27” TFT LED monitor, Minimum 1920 x1080 resolution, 5 ms or
better response time, TCO 05 (or higher) certified
14. Certification Energy star 5.0/BEE star certified
15. Operating System 64 bit pre-loaded OS with recovery disc
16. Security BIOS controlled electro-mechanical internal chassis lock for the
system.
17. Antivirus feature Advanced antivirus, antispyware, desktop firewall, intrusion
prevention (comprising of a single, deployable agent) which can
be managed by a central server. (Support, updates, patches
and errata for the entire contract/ project period)
18. DLP/DRM Software There would be DRM Software/application installed on these
workstations that would prevent unauthorized copying of
sensitive data.
19. Operation System and Operating system proposed should be suitable for the solution
Support offered and pre-loaded.

D- Block & Gram Panchayat – Technical Specification

1.5 GP Type II, GP Type I, and Block Router Specification
S Minimum Requirements Description
No.
This is the common specification for GP Type II, GP Type I, and Block Router at Gram
Panchayats. The capacity and interfaces required are given in the sequel in Tables 1, 2, 3 and
4
Hardware
1 The Router should be Standalone / modular and 19" rack mountable
Interfaces
2 The Router should support Copper, Fibre Ethernet, 1G, 10G and 100G Interfaces consistent with
Tables 1, 2, 3 and 4 that are given in the sequel, for each type of router.
High Availability
3 The Router should support even multiple(s) of 100G and 10G (consistent with Tables 1, 2, 3 and
4 that are given in the sequel, for each type of router)
4 The Router should have flexibility to support both Metro-Ethernet and IP/MPLS features.
5 The Router should have SyncE (1588).
Protocols – IPv4, IPv6, MPLS
6 The Router should support the following:
OSPF, BGP, IS-IS, IP Multicast, PIM, IGMP/ IGMPv1/v2/v3, MLDv2, MPLS, L2VPN, L3VPN,
Segment Routing / seamless MPLS, BGP-LS /LU, VPLS/H- VPLS, RSVP/FRR, BFD for IPv4 and
IPv6.
Security features
7 The Router should have Protection against Broadcast, Multicast and Unicast Storms, DHCP
relay.
Ethernet Features
8 The Router should support the following features: 802.1Q, LFA, VLAN Stacking (Q-in-Q), Y.1731,
802.1ag, ERPS-G.8032 / FRR, LACP, etc.
9 The Router should have Carrier Ethernet features - E-LAN and E-Line capabilities.
Quality of Service Classifications
10 The Router should support the following: 802.1Q, Source and Destination IP address/subnet
mask, DSCP value, IP precedence classification, Protocol type (TCP, UDP, etc.), Default
markings per port (ingress), 802.1p/DSCP (ingress), Per port and per queue shaping, Eight
hardware queues per port for flow treatment of traffic, WRED or equivalent.
Performance Management
11 The Router should support Zero touch provisioning for ease of management with Y.1731
Performance Management, support Network Time Protocol (NTP) as per RFC 1305, NETCONF,
CLI, SNMP v1/v2/v3, and Role based privileges for the system access.
Physical specifications
12 Operating Temperature 0 to +65 degrees, Relative Humidity: 10% to 90% non-condensing.
Certification
13 The product offered or the family should be CE 2.0 compliant

Router Specifications Wire Speed

GP Router Type II FD 10 Gbps
HD 20 Gbps
GP Router Type I FD 60 Gbps
HD 120 Gbps
Block Router FD 300 Gbps
HD 600 Gbps
GP Type II, GP Type I, and Block Router Ports Specifications

1GE 1GO 10GO 100GO Total Ports Total Capacity
GP Type II 8 2 0 0 10 10 Gbps
GP Type I (4,2) (2,4) (2,2) (0,0) 16 52 Gbps
Block Router (4,2) (4,4) (4,4) (2,0) 24 294 Gbps
(x,y) means now and later

GP Type II, GP Type I, and Block Routers: Routes and Addresses

Multi- Pseudo RSVP
IPv4 IPv6 MAC
Cast wire TE
GP Type II 10K 2K 10K 1K 512 512
GP Type I 20K 5k 15K 4K 2K 2K
Block
40K 10K 30K 6K 3K 5K
Router
1.6 Technical Specifications for 2.0 kVA ONLINE UPS System

S. Specifications Requirement
No.
1 Capacity 2.0 KVA / 1800 W
2 Technology IGBT (Rectifier & Inverter both); ECO Mode
3 Wave form & Freq Pure Sine wave & shall have frequency converter mode
converter
4 Display LCD
5 Input power factor 0.99
correction
6 Input configuration 1Ph,L-N+PE (160 to 300Vac on full load & shall support
upto 110Vac for 60% load). UPS Shall have inbuilt
OVCD protection. The input range from 110 to 300V
must be settable by end user
7 PF >=0.99
8 Frequency (Input) 40 to 70Hz frequency
9 Frequency (output) 50Hz/60Hz frequency
10 Output Voltage 200/208/220/230/240Vac shall be available with +/-1%
regulation in battery mode
11 V threshold 3% max full linear load, 5% max on Non-linear load
12 Output Power factor 0.9
13 Crest factor 3.0 or better

14 AC-AC Efficiency 89% for 2.0kva
15 Transfer time Main- 0
Battery
16 Transfer time 4ms
Inverter-Bypass
17 Output Connection Minimum 10A X 3 nos - Indian Socket
inbuilt to the UPS back. One of these O/p Socket shall
be Programmable with settable time so as to increase
the back-up time for critical load
18 Monitoring software Shall be provided for monitoring of UPS from remote

for UPS along with SNMP Card
19 Communication SNMP
21 Port USB, RS 232, RJ45

No.
22 Battery Type 12V SMF having JIS 8702 certification
23 Battery backup 2.0 kVA - 60 minutes (Min VAH 2340)
24 Charger Min. 15 amp inbuilt (for any future expansion of back-up

time). Charger shall be settable for 1/2/4/6/8/10/12/14 A
ratings as per the need of battery charging
25 Environmental Parameter
a. Operating 0-40 deg C with full load @ 0.9PF. Later de-rating
temperature range applicable upto 50 deg C
b. Other Indication required -> Over Temperature, Load on
Battery, Battery on Charge, Battery low, Mains on
Fan Speed control (as per load & room temp) shall be
possible
c. Humidity 0% to 95% non-condensing
d. Noise Level 52 dBA max
e. Mounting Tower type only (Rack Mount type not acceptable)
f. Auto Start, Cold Start Shall be available
& EPO
26 Protection IP20
27 LCD Display
a. Measurements (On Input & Output Voltage, Input & Output Frequency,
LCD) Bypass: Voltage & Frequency, Remaining time &
Battery Level Indicator, Load Level indicator, Fault
codes, Estimated or running autonomy time, UPS alarm
enable or disable, Overload, Short circuit, Low Battery.
b. Fault Indication (On Bus start fail, Bus over & under, Inverter soft start
LCD) failure, Inverter voltage high & low, Inverter output short,
Battery voltage high & low, charger output short, over
temperature, overload, charger failure, over input
current, over input current, battery not connected, over
charge, EPO enable, Programmable output enable.
c. Settable data Inverter voltage & frequency, Frequency converter, ECO
mode, ECO voltage range, Bypass setting, Bypass
voltage range, Autonomy limitation setting, Battery total
Ah setting, Charger current, Bypass frequency range,
Programmable outlet, Programmable outlet setting,
Charger boost & float voltage setting, EPO logic setting,
Isolation transformer O/P (if applicable in design of
OEM), Display setting for autonomy, Acceptable input
voltage range.
28 Manufacturer Manufacturer - > ISO 9001, TL 9000, ISO 14001 &
OHSAS 18001 (ISO & OHSAS for Indian Operation of
OEM only). Factory calibration lab of manufacturer shall
be NABL accredited in India
29 Product BIS certification required
30 Management Windows® 2000/ 2003 /XP/Vista/ 2008, Windows® 7 /

Supports /Software 8/10, Linux, Unix

1.7 Technical Specifications for 1.0 kVA ONLINE UPS System

No.
1 Capacity 1.0 KVA / 900 W
2 Technology IGBT (Rectifier & Inverter both); ECO Mode
3 Wave form & Freq Pure Sine wave & shall have frequency converter mode
converter
4 Display LCD
5 Input power factor 0.99
correction
6 Input configuration 1Ph,L-N+PE (160 to 300Vac on full load & shall support
upto 110Vac for 60% load). UPS Shall have inbuilt
OVCD protection. The input range from 110 to 300V
must be settable by end user
7 PF >=0.99
8 Frequency (Input) 40 to 70Hz frequency
9 Frequency (output) 50Hz/60Hz frequency
10 Output Voltage 200/208/220/230/240Vac shall be available with +/-1%
regulation in battery mode
11 V threshold 3% max full linear load, 5% max on Non-linear load
12 Output Power factor 0.9
13 Crest factor 3.0 or better
14 AC-AC Efficiency 89% for 1.0kva
15 Transfer time Main- 0
Battery
16 Transfer time 4ms
Inverter-Bypass
17 Output Connection Minimum 10A X 3 nos - Indian Socket
inbuilt to the UPS back. One of these O/p Socket shall
be Programmable with settable time so as to increase
the back-up time for critical load
18 Monitoring software Shall be provided for monitoring of UPS from remote
for UPS along with SNMP Card
19 Communication SNMP
21 Port USB, RS 232, RJ45
22 Battery Type 12V SMF having JIS 8702 certification
23 Battery backup 1.0 kVA - 60 minutes (Min VAH 2340)
24 Charger Min. 15 amp inbuilt (for any future expansion of back-up
time). Charger shall be settable for 1/2/4/6/8/10/12/14 A
ratings as per the need of battery charging
25 Environmental Parameter
a. Operating 0-40 deg C with full load @ 0.9PF. Later de-rating
temperature range applicable upto 50 deg C
b. Other Indication required -> Over Temperature, Load on
Battery, Battery on Charge, Battery low, Mains on

No.
Fan Speed control (as per load & room temp) shall be
possible
c. Humidity 0% to 95% non-condensing
d. Noise Level 52 dBA max
e. Mounting Tower type only (Rack Mount type not acceptable)
f. Auto Start, Cold Start Shall be available
& EPO
26 Protection IP20
27 LCD Display
a. Measurements (On Input & Output Voltage, Input & Output Frequency,
LCD) Bypass: Voltage & Frequency, Remaining time &
Battery Level Indicator, Load Level indicator, Fault
codes, Estimated or running autonomy time, UPS alarm
enable or disable, Overload, Short circuit, Low Battery.
b. Fault Indication (On Bus start fail, Bus over & under, Inverter soft start
LCD) failure, Inverter voltage high & low, Inverter output short,
Battery voltage high & low, charger output short, over
temperature, overload, charger failure, over input
current, over input current, battery not connected, over
charge, EPO enable, Programmable output enable.
c. Settable data Inverter voltage & frequency, Frequency converter, ECO
mode, ECO voltage range, Bypass setting, Bypass
voltage range, Autonomy limitation setting, Battery total
Ah setting, Charger current, Bypass frequency range,
Programmable outlet, Programmable outlet setting,
Charger boost & float voltage setting, EPO logic setting,
Isolation transformer O/P (if applicable in design of
OEM), Display setting for autonomy, Acceptable input
voltage range.
28 Manufacturer Manufacturer - > ISO 9001, TL 9000, ISO 14001 &
OHSAS 18001 (ISO & OHSAS for Indian Operation of
OEM only) . Factory calibration lab of manufacturer shall
be NABL accredited in India
29 Product BIS certification required
30 Management Windows® 2000/ 2003 /XP/Vista/ 2008, Windows® 7 /
Supports /Software 8/10, Linux, Unix
1.8 Other Items – Technical Specification

a) Earthing specifications
Each and every electrical component deployed in the PoP must be earthed properly as per the standard
practice that shall be in conformity with provision of rules 32, 61, 62, 67 & 68 of Indian Electricity Rules
1956 and as per standards in IS-3043. Earthing of equipment should be provided by connecting two
earth tapes/copper wire from the frame of the component ring and will be connected via several earth
electrodes and the cable arm must be earthen through the cable glands/end termination.
To avoid ground differential, earthing should be done for the complete power system that should
provide proper earthing facility to UPS systems, Power distribution units etc., and should ensure
whether all associated metallic objects within the premises that are likely to be energized by electric
currents should be effectively grounded.

The earth link or electrode system must be with sufficient low resistance range of 0 to 2.5 ohm.
This is to ensure the safety of the equipment from an electric shock to personnel & protect the equipment
from voltage gradients. And to prompt operation of respective protective devices in event of a ground
fault.
Recommended levels for equipment grounding conductors should have very low resistance level less
than 0.25 ohm.
For critical infrastructure, as per the standard practices, it is necessary to provide two separate earthing
pits for general earthing (Main) and UPS.
b) General Earthing:
Civil infrastructure should be constructed with a pit of size 600x600mm using brick chamber of
40mm thick cement slab covering. Earthing electrode 38mm dia, 2.4 mts long with 1R x 25x3mm cu
strip must be erected with back filling alternate layer of salt, charcoal and sand/ Bentonite. Should
deploy with all necessary and associated earthing accessories as per standards. Proper identification
marking should be made inside and outside of the pit.
2Rx6.0 Sqmm copper wire must be used to link earth pit and all terminations points.
c) UPS Earthing(dedicated):
Civil infrastructure should be constructed with a pit of size 600x600mm using brick chamber of
40mm thick cement slab covering. Earthing electrode of 38mm dia, 2.4 mts long with 1R x 25x3mm cu
strip and 300x300x3mm Cu plate placed at the bottom should be installed with back filling alternate
layer of salt, charcoal and sand/Bentonite its complete earthing accessories. Proper identification
marking should be made inside and outside of the pit.
2Rx6.0 Sq.mm copper wire should be used to link earth pit to UPS output Neutral terminal.
(Green)
d) LED Tube Light

20W LED tube light as per IS 16101 (2012), with necessary fitting and wiring connections.
e) Lock & Key

Two lock is required for each PoP. One door located at the training hall should be locked always. 3 keys
for each lock. Lock details: Maxed Globe Pressing Padlock 2 Inch Safety Lock.
f) Electrical Work:
Providing electrical wirings, Main DB, UPS DB, Cable, cable end termination, industrial plug socket,
cable tray, cable truff and support materials as per IS 732: 1989 (Indian standard code of practice for
electrical wiring installation)
There should be enough space between data and power cabling and there should not be any cross
wiring of the two.

2. TECHNICAL SPECIFICATION - PACKAGE B, C & D

I. Aerial and Underground Cable
1. Aerial OF Cable (ADSS Cable): 24 pair ADSS on power lines: As per TEC GR No.
TEC/GR/TX/OFC-022/02/MAR-17 with latest amendments if any. (Type 2A)
2. Aerial OF Cable (ADSS Cable): 48 pair ADSS on power lines: As per TEC GR No.
TEC/GR/TX/OFC-022/02/MAR-17 with latest amendments if any. (Type 2A)
3. Underground (OFC Cable): 96 pair ADSS on power lines: As per TEC GR No.
TEC/GR/TX/OFC-022/02/MAR-17 with latest amendments if any.
4. Underground (OFC Cable): 144 pair ADSS on power lines: As per TEC GR No.
TEC/GR/TX/OFC-022/02/MAR-17 with latest amendments if any.
II. Underground Cable Accessories

1. HDPE: As per TEC GR No. TEC/GR/TX/CDS-008/03/MAR-11 with latest amendments, if any.
2. DWC Pipe 75/61 mm: TEC/GR/DWC-34/01 Sep.2007 with latest amendments, if any.
3. GI Pipe: TEC GR No: IS554/1985 (Revised up to date) & IS 1239(Part- I), 1900 Sockets (revised
up to date) & IS 1239 (Part-II) 1992 revised up to date.
4. Supply of Route / joint indicator:
5. Supply of Manhole & Joint chambers & Loop chamber:
i. FDMS outdoor 96: GR No. TEC/GR/TX/FDM-003/01 MAR 2012 with latest amendments if any.
ii. FDMS outdoor 144: GR No. TEC/GR/TX/FDM-003/01 MAR 2012 with latest amendments if
any.
Below mentioned accessories for Aerial Cable (Wedge Type) –
(As per TEC GR No. TEC/GR/TX/OAF-001/03/MAR-17) with latest amendments if any.
1. Formed OFC Dead End & Termination Fittings @ 5 per Km (Wedge Type)
2. OFC Suspension Fittings @ 12 per Km (Wedge Type)
3. De-mountable pulley @ 1 per 10 Km
4. Adjustable Cable Storage Bracket @ 3 per Km (One loop bracket 1.5m stainless steel strap
& 2 nos buckles) Wedge Type - Type 3
III. PATCH CORD: As per TEC GR no. TEC/GR/TX/OFJ -01/05/Nov-09, with latest
amendments if any.
iii. OFC: 48 Pair OFC: As taken from BSNL Tender No.: Tender Enquiry No.: CA/Ent.-CNP/OFC/T-
553/2016 issued on 24-June-2016.
Note: Draft GR GENERIC REQUIREMENTS NO. TEC/GR/OFC-23/01/XXX-2011 (under finalization
in TEC, finalized GR and its latest amendment, thereof, will be considered).
TECHNICAL SPECIFICATIONS (DTR)/REQUIREMENTS FOR 24F and 48F METAL FREE OPTICAL
FIBRE CABLE WITH DOUBLE HDPE SHEATH (G.652D Fibre)”
GR No. TEC/GR/TX/ORM-01/04 SEP.09 Specification for Raw Material used in
Manufacturing of Cables.
GR No. GR/OFT-01/03. APR 2006 Tools for installation & Operating the OFC &
for assembly of the OF Splice Closures.
GR No. G/CBD-01/02. NOV 94 Drum specifications for Cable ends.
GR No. TEC/GR/TX/OJC-002/03/APR-2010 Specifications for Splice Closure for Optical
Fibre Cable.
Note: All the materials as above have to be TSEC/Type approved by BSNL QA/TEC against
mentioned TEC GR or as per the approval procedure of BBNL for which TEC GR not there.

2.1 24F Rack Mountable FDMS:

TEC GR Reference - GR/FDM-01/02 APR 2007.
S.No. Parameter Minimum Specification & requirement
1 24F S & P Module 19-inch Rack Mountable, 1U height, with 1 nos of 12F Splicing
Trays, each preloaded with 12 Nos. single fibre pigtails of 0.9mm
SCAPC/SCPC connectorized and 1.5 meters in length & 12 Nos. of
SCAPC/SCPC Adaptors. The pigtails shall be color coded for easy
identification
2 Type of Fibre Individual Fibre
3 Type of Adaptor, SCAPC / SCPC as per TEC GR TX/OFJ-01/05
(CACT Approved) NOV 2009
4 Connector SCAPC/SCPC as per TEC GR TX/OFJ-01/05
NOV 2009 (CACT Approved Source)
5 Type of pigtail SCAPC/SCPC pigtail 1.5m.
6 Splice tray Splice Tray for Individual Fibre
7 Splice Protection 24 F FDMS S&P Shelf: As per GR TEC/GR/TX/PTS-02/03. JAN-
Sleeves 2011- 24 nos. + 25% extra
2.2 48 F Rack Mountable FDMS:

TEC GR Reference - GR/FDM-01/02 APR 2007.
S.No. Parameter Minimum Specification & requirement
1 48F S & P Module 19-inch Rack Mountable, 2U height , with 1 nos of 12F
Splicing Trays, each preloaded with 12 Nos. single fibre
pigtails of 0.9mm SCAPC/SCPC connectorized and 1.5
meters in length & 12 Nos. of
SCAPC/SCPC Adaptors. The pigtails shall be color coded
for easy identification
2 Type of Fibre Individual Fibre
3 Type of Adaptor, (CACT SCAPC / SCPC as per TEC GR TX/OFJ-01/05
Approved) NOV 2009
4 Connector SCAPC/SCPC as per TEC GR TX/OFJ-01/05
NOV 2009 (CACT Approved Source)
5 Type of pigtail SCAPC/SCPC pigtail 1.5m.
6 Splice tray Splice Tray for Individual fibre
7 Splice Protection 24 F FDMS S&P Shelf: As per GR TEC/GR/TX/PTS-02/03.
Sleeves JAN-2011- 24 nos. + 25% extra
2.3 Technical Specification for Radio Link

a. Radio Modem:
Reference: TEC/GR/R/ISM-MOD-001/04.MAR2016
State/SIA intends to purchase Radio Equipment for point to point installation between location as
mentioned at Annexure –A, as per Generic Requirements as mentioned in TEC/GR/R/ISM-MOD-
001/04.MAR2016 for point to point deployment along with following additional requirement of State/SIA.
Requirement of radio infrastructure of State/SIA is for establishing point-to-point link between BSNL
tower and Gram Panchayat. The system should work in Point to Point mode of operation.
The system will employ modulation techniques like FHSS (Frequency Hopping Spread Spectrum,
DSSS (Direct Sequence Spread Spectrum), OFDM (Orthogonal Frequency Division Multiplexing) etc.
and will work in TDD (Time Division Duplex) or FDD (Frequency Division Duplex) with channel

bandwidths of 20MHZ and 40MHz in addition to 50MHZ (optional, if available). Bidders offering 50
MHz/40 MHz should have fall back option to operate in lower channel bandwidths in case of RF
interference, low signal or installation inaccuracies etc. At the same time, it should not interfere with
adjacent bands.
1. Systems based on IEEE Standard 802.11 ac are also allowed.
2. The system should support Point-to-Point architecture.
3. The frequency range of the system shall lie within 5825 - 5875 MHz. However, it should be
configurable in complete ISM Band (5 GHz) as per NFAP present provisions or any future
changes.
4. The modem shall support pure IP traffic (Type B). However installer will have to deploy
appropriate converter where ever support for backend connectivity from E1 port is required to
be extended. (To be added in Price schedule)
5. The system should support the minimum data rates as per the table below (with maximum two
spatial streams):
Modulation Physical data Data Rate Physical Data Rate Data Rate
and FEC Rate in Mbps (throughput) data Rate in (throughput) (throughput)
(20 MHz) in Mbps* Mbps in Mbps* in Mbps*
(20 MHz) (40 MHz) (40 MHz) (50 MHz)
BPSK-1/2 13 6.5 27 13.5 18
QPSK-1/2 26 13.0 54 27.0 37
QPSK-3/4 39 19.5 81 40.5 55
16QAM-1/2 52 26.0 108 54.0 73
16QAM-3/4 78 39.0 162 81.0 110
64QAM-2/3 104 52.0 216 108.0 146
64QAM-3/4 117 58.0 243 121.0 165
64QAM-5/6 130 65.0 270 135.0 183
*Minimum unidirectional throughput (in Mbps) for different channel widths.
Note:
1. For 802.11ac testing will be done at GI=800ns.
2. It is mandatory for the system to operate with at least 64 QAM modulation scheme and should
have adaptive coding & modulation which enables dynamically altering of modulation scheme
to maintain link quality and optimize the throughput in case of RF interference, low signal or
installation inaccuracies etc.
3. Bidders may also offer 256 QAM in which case it should have adaptive coding and modulation
which enables dynamically altering of modulation scheme to maintain link quality and optimize
the throughput in case of RF interference, low signal or installation inaccuracies etc.
4. Channelling Plan / Configurable Channel Bandwidth: The system should be configurable to
20/40/50(optional) MHz channel bandwidths. This flexibility shall allow BBNL to use different
channel bandwidths in different installations depending on throughput requirements.
5. The status of Alarms and Diagnostics should be displayed on the front panel of the equipment
(LED/LCD display) and should be extendable to EMS/State/BBNL NMS.
6. There should be a provision of extending at least Four External Alarms such as SPV health
indicating Alarms (4Nos.) to be extended to the EMS/NMS.
7. There shall be indication on front panel on LED/LCD display/GUI and EMS/State/SIA NMS for
the following alarms.
a. Power failure
b. Receive power below threshold
c. Radio sync loss
d. Dying Gasp (message to EMS/NMS)
e. The equipment shall have (1+1) hot standby configuration for point to point deployment
scenarios.

f.
Nominal power supply available at telephone exchange or tower site is -48 volts DC,
with a variation over the range -44V to -57V. The equipment should operate over this
range without any degradation in performance by using suitable convertor.
b. DC to DC Convertor
S. No. Specification parameter Parameter value
1 Operating temperature range -10°C to 60°C
2 Protections Short circuit, Overload, Over-voltage
Provision for 1000 Mbps PoE (Power over Ethernet) may also be supported wherever required.
For the equipment to be installed in snowbound areas, it should be IP-67 compliant. For other regions
it should be IP-65.
Synchronization: As per TEC GR. Frequency, Phase and Time/ it will ensure successful transmission
of packet of sync without fail---

c. Tower/Pole Specification (9 m pole and 15 m tower)

S. No. Specification parameter Parameter value
1. 50 kg (This includes antenna, solar
Minimum Load Capacity
panel and 3 access points etc.
2. Maximum survival wind speed upto 196 km/h
3. Lightning arrestor Yes
All steel parts - IS: 4759
4. Galvanisation
Bolts and nuts - IS- 1367 part VIII
2.4 Antenna Characteristics shall be as follows:

1. Electrical Parameters
Frequency 4900-5900 MHz
Gain (dBi) (Minimum) H=23.5 +/- 0.5
V=23.5 +/- 0.5
VSWR (Max) 1.5:1
E Plane BW (deg) 7 +/- 0.5
H plane BW (deg) 7 +/- 0.5
Polarization Dual (Linear H & V)
Port to port isolation ( dB) 25
Max power input (watts) 50
Impedence 50 Ohm
Front to back ratio (dB) > 26
Cross polarization (dB) > 28
2. Mechanical Parameters
Radome UV Stabilized ABS/UV Protected
Polycarbonate
Mounting hardware MS galvanized powder coated
Mounting style Tower, Pole and Wall
Mounting adjustment H Plane +/- 180degree
V Plane +/- 180degree
3. Environmental Parameters
Temperature Range (deg C) -10 to +65
(Snow bound areas - -40 to 65)
Max Wind Speed survivability (Km/hr) 196
Humidity 95% No condensation
Shock QM333, Category D
Vibration QM333, Category D
Water Protection IP65*
Environmental protection QM333, category D
RoHS/WEEE comply Complied
*For snow bound areas like Ladakh etc. equipment should be IP67 compliant.

2.5 Carrier Ethernet Switch

Carrier Ethernet Switch conforming to Metro Ethernet Forum (MEF) standards will enable setting up
various Quality of Service (QoS) parameters if the bandwidth is to be distributed among different
operators.
The switch should be minimum 8 ports out of which, four should be optical ports with 3 single mode
operation of reaching up to 10 Km at 1310 nm lasers and one multi-mode. Out of 8 ports, at least 50%
of the ports should be pluggable. Other specifications are standard Ethernet Switch specification. The
device should be temperature hardened and also the power consumption should be low.
S. No. Parameter Parameter value
1 Carrier Ethernet Standards MEF CE 2.0 and above
IEEE 802.1Q VLAN tagging
2 Ethernet Services IEEE 802.1ad Q-in-Q VLAN tagging
IEEE 802.3x Flow Control
3 Number of VLANs 256 active VLANs (VLAN ID range is 4096)
Port-based and 802.1Q Tag-based VLANs
4 VLAN
Management VLAN
Spanning Tree Protocols (STP)
802.1D STP
802.1s MSTP
5 L2 features
802.1w RSTP
Loopback Detection
Link Aggregation (IEEE 802.3ad compliant)
AC Input – 100 to 240 V AC, 50/60 Hz
6 Power Specifications
Power Consumption < 20 W
Storage temperature: -40 to 65° C
Operating temperature: -40° to 65° C
Storage Humidity – 5% to 90%
7 Environmental Specifications non-condensing
Operating Humidity – 10% to 90%
non-condensing
Temperature Hardened
8 HOL Blocking Head of line blocking prevention
Web User Interface
RMON: Remote Monitoring (RMON)
9 Management
Port Mirroring
Zero Touch Provisioning (ZTP)
Traceroute
Secure Socket Layer (SSL)
Secure Shell (SSH)
TFTP upgrade
SSL security for Web UI
10 Other Management DHCP client
SNMP v1,v2,v3
Cable diagnostics
PING
Telnet client (SSH secure support)
System Logs
IEEE 802.1X : 802.1X - RADIUS
Authentication. MD5 Encryption
AAA with RADIUS/TACACS+
Access Control: ACLs - Drop or rate limit
11 Security/Authentication based on:
Source and destination MAC-based
Source and destination IP address
Protocol
MAC security on EVCs

S. No. Parameter Parameter value
TOS/DSCP
Port Security
Broadcast/Multicast/Unicast storm control
ITU-T Synchronous Ethernet (SyncE)
12 Clocking
G.8264 (ESMC)
Class of Service: Port-based
802.1p VLAN priority based
IPv4/v6 IP precedence/TOS/DSCP based
TCP/UDP port-based
13 QoS Diffserv
Classification and remarking ACLs
Bandwidth control
Port/Flow based
Egress queue bandwidth control
Device Safety/Emission compliance UL
14
certificates VCCI Class A, FCC 47CFR15 Class A
2.6 8.0m (200Kg WL) Pre-stressed Concrete Poles (PSC) detailed Specifications
1. STANDARDS:
PSC poles shall comply with the recommendation of REC as per REC specification 15/1979 (with latest
amendment) except where the conflict specific requirement, with above REC specification, the pole
shall comply with the relevant provisions made in the following IS specification.
i. IS: 1678-1998, Specification for pre-stressed concrete poles for overhead power, traction
and telecommunication lines.
ii. IS: 2905-1989, Methods of test for concrete poles for overhead power and
telecommunication lines.
iii. IS: 7321-1974, Code of Practice for selection, handling and erection of concrete poles for
overhead power and telecommunication lines.
2. INSPECTION:
The Purchaser reserves the right to depute a representative for
i. Inspection of the Company’s work site to check up the capacity and financial capability
before accepting the offer (ISI Certification),
ii. Inspecting the manufacturing process at Company’s worksite. Necessary facilities for
such inspection shall be provided by the SI.
The materials will be inspected by Purchaser or his representative during the process of manufacturing
and prior to dispatch, if necessary. Failure to adhere to the specification will entail rejection of materials.
The supply will also be rejected if the materials ordered, do not conform to the standards and in the
opinion of the Inspecting Officer are found not suitable for the purpose for which they are intended.
The tests will be carried out by the Authorized representative of the Purchaser in the presence of the
Supplier and other authorized persons of SI.

All the tests and manufacturing process stipulated by the Indian Standard and REC Specifications are
applicable to this Tender.
3. APPLICABLE CODES AND SPECIFICATIONS:
All standards, Specifications, and Codes of practice referred to herein shall be the latest editions
including all applicable official Amendments and revisions. In case of discrepancy, between this
Specification and those referred to herein, this Specification shall govern.
A) MATERIALS
1. I.S.12269 - Specification for 53 Grade Ordinary Portland cement.
2. I.S.650 - Specification for standard sand for testing of Cement.
3. I.S.383 - Specification for coarse and fine aggregates from natural sources for concrete.
4. I.S.2386 - Methods of test for aggregate for concrete (Parts I to VIII)
5. I.S.516 - Method of test for strength of concrete.
6. I.S.1199 - Method of sampling and analysis of concrete.
7. I.S.3025 - Method of sampling and testing (Physical and Chemical) of water used.
8. I.S.6003 - High Tensile Pre-stressing cold drawn indented wire (HTS Wire).
B) EQUIPMENT
1. I.S.1791 - Specification for batch type concrete mixers.
2. I.S.2505 - Specification for concrete vibrators.
C) CODES OF PRACTICE FOR CONCRETE
1. I.S. 456- Code of practice for plain and reinforced concrete.
2. I.S.3558- Code of practice for use of immersion Vibrators for consolidating concrete.
3. I.S. 1343- Code of practice for pre stressed concrete.
4. I.S. 516- Sampling and testing for Concretes strength.
5. I.S. 1678- Prestressed Concrete Poles -specification.
6. I.S. 2905- Methods of test for Concrete Poles.
7. I.S. 7321- Code of Practice for selection, handling and erection of Concrete Poles.
Note: In the event that Government bodies or other local bodies have requirements more stringent than
those set forth in this Specification, such requirements shall be considered part of this specification and
shall supersede this Specification wherever applicable.
4. MATERIALS FOR CONCRETE

a. Cement
The cement used in the manufacture of prestressed concrete poles shall be ordinary or rapid
hardening Portland cement conforming to IS : 269-1976 (Specification for ordinary and low heat
Portland cement) or IS :8041 E-1978 (Specification for rapid hardening Portland cement), or high
strength ordinary Portland cement conforming to IS : 8112-1976 (Specification for high strength
ordinary Portland cement).

b. Aggregates
Aggregates used for the manufacture of prestressed concrete poles shall confirm to IS: 383-
1970 (Specification for coarse and fine aggregates from natural sources for concrete). The
nominal maximum size of aggregates shall in no case exceed 12mm.
c. Water
Water should be free from chlorides, sulphates, other salts and organic matter. Potable water
will be generally suitable.
d. Admixture
Admixtures should not contain Calcium Chloride or other chlorides and salts which are likely
to promote corrosion of prestressing steel.
e. Pre-stressing steel
a. The pre-stressing steel wires, including those used as untensioned wires, should conform
to IS: 1785(Part-I)-1983 (Specification for plain hard-drawn steel wire for prestressed
concrete, Part-I cold drawn stress relieved wire)
(or)
b. IS:6003-1983 (Specification for indented wire for prestressed concrete) or the latest
versions thereof. The type designs given in Annexure-I and II are for plain wires of 4 mm
diameter with a guaranteed ultimate strength of 175 kg/mm 2.
c. The concrete mix shall be designed to the requirements laid down for controlled concrete
(also called design mix concrete) in IS: 1343-1980 (Code of practice for prestressed
concrete) and IS: 456-1978 (Code of practice for plain and reinforced concrete), subject to
the following special conditions:
i. Maximum works cube strength at 28 days should be at 420kg/cm 2 for Design mix M-
420.
ii. The concrete strength at transfer should be at least half the 28 days design strength.
iii. The mix should contain at least 380 kg of cement per cubic meter of concrete.
iv. The mix should contain as low water content as is consistent with adequate
workability. If it becomes necessary to add water to increase the workability, the
cement content also should be raised in such a way that the original value of water
cement ratio is maintained.

5. DESIGN REQUIREMENTS
i. The working load on the poles should correspond to those that are likely to come on the
pole during their service life applied at 0.6m from top.
ii. The average permanent load shall be 40% of the working load.
iii. The F.O.S. against first crack load shall be 1.0.
iv. At average permanent load, permissible tensile stress in concrete shall be 30kg/cm2.
v. At the design value of first crack load, the modulus of rupture shall not exceed 55.2kg/cm2
for M-420 concrete.
vi. The ultimate moment capacity in the longitudinal direction should be at least one fourth of
that in the transverse direction.
vii. The maximum compressive stress in concrete at the time of transfer of prestress should
not exceed 0.8 times the cube strength.
viii. The concrete strength at transfer shall not be less than half the 28 days strength ensured
in the design.
6. DIMENSIONS AND REINFORCEMENTS

The cross-sectional dimensions and the details of prestressing wires should conform to the particulars
given in Clause -10 of this section.
7. MANUFACTURE
i. All prestressing wires and reinforcements shall be accurately fixed as shown in drawings and
maintained in position during manufacture. The untensioned reinforcement, as indicated in the
drawings, should be held in position.
ii. All wires shall be accurately stretched with uniform prestress in each wire. Each wire or a group
of wires shall be anchored positively during casing. Care should be taken to see that the
anchorages do not yield before the concrete attains the necessary strength.
iii. Cover
The cover of concrete measured from the outside of pre-stressing tendon shall be normally
20mm.
iv. Welding and Lapping of Steel
The high tensile steel wire shall be continuous over the entire length of the tendon. Welding
shall not be allowed in any case. However, jointing or coupling may be permitted provided the
strength of the joint or coupling is not less than the strength of each individual wire.
v. Compacting
Concrete shall be compacted by spinning, vibrating, shocking or other suitable mechanical
means. Hand compaction shall not be permitted.
vi. Detensioning
The prestressing wires shall be detensioned only after the concrete has attained the specified
strength at transfer. The cubes cast for the purpose of determining the strength at transfer
should be cured, as far as possible, under conditions similar to those under which the poles
are cured. The transfer stage shall be determined based on the daily tests carried out on

concrete cubes till the specified strength indicated above is reached. Thereafter the test on
concrete shall be carried out as detailed in IS: 1343-1980 (Code of practice for prestressed
concrete). The manufacturer shall supply, when required by the employer or his
representative, result of compressive test conducted in accordance with IS: 456-1978 (Code
of practice for plain and reinforced concrete) on concrete cubes made from the concrete used
for the poles. If the employer so desires, the manufacturer shall supply cubes for test purposes
and such cubes shall be tested in accordance with IS:456-1978 (Code of practice for plain and
reinforced concrete).
The detensioning shall be done by slowly releasing the wires, without imparting shock or
sudden load to the poles. The rate of detensioning may be controlled by any suitable means
either mechanical (screw type) or hydraulic. The poles shall not be detensioned or released
by cutting the pre-stressing wires using flames or bar croppers while the wires are still under
tension.
vii. Eye-hooks
Separate eye-hooks or holes shall be provided for handling the transport, one each at a
distance of 0.15 times the overall length, from either end of the pole. Eye-hooks, if provided,
should be properly anchored and should be on the face that has the shorter dimension of the
cross-section. Holes, if provided for lifting purposes, should be perpendicular to the broad face
of the pole.
viii. Curing
The concrete shall be covered with a layer of sacking, canvass, hessian or similar absorbent
material and kept constantly wet up to the time when the strength of concrete is at least equal
to the minimum strength of concrete at transfer of prestress. After detensioning, the poles shall
be cured for a further period of not less than 14 days by submerging in water tanks for a period
of 7 days followed by curing for a further 7 days with mechanical water spraying arrangements
which shall be invariably carried out under cover and shall ensure full humidity conditions.
During manufacturer, periodical tests on concrete cubes shall be carried out till the concrete
achieves the required strength at transfer. Thereafter, the test on concrete shall be carried out
at detailed in IS:1343. The manufacturer shall supply, when required by the purchaser, results
of compressive test conducted in accordance with IS:456 on concrete cubes made from the
concrete used for the poles. If the purchaser so desires, the manufacturer shall supply, cubes
for test purposes and such cubes shall be tested in accordance with IS:456.
ix. Finish
a. Poles shall be free from surface defects including hair cracks. The surface of the poles in
contact with the steel mould shall be smooth and regular in shape and shall, as far as
possible, be free from pores. Water retaining pockets or honey-combing formation shall
not be admissible.
b. The ends of the prestressing wires shall be out as close to the surface of the pole as
possible and in any case shall not project more than 3mm.
c. The ends of the prestressing wires shall be given two coats of suitable anti-corrosive paints
approved by the purchaser.
d. The edges of the poles shall not be sharp.
e. The poles supplied should have blended edges to avoid injuries while handling and those
poles with sharp ends shall be summarily rejected.
f. The poles shall also not have glossy finished surface for effective handling and
maintenance.
x. Stacking
Stacking should be done in such a manner that the broad side of the pole is vertical. Each tier
in the stack should be supported on timber sleepers located as 0.15 times the overall length,
measured from the end. The timber supported in the stack should be aligned in a vertical line.
Poles should be transported with their broad faces placed vertically and in such a manner that
shocks are avoided. Supports should be so arranged that they are located approximately at a
distance equal to 0.15 times the overall length from the ends. The erection of the pole should
be carried out in such a way that the erection loads are applied so as to cause moment with
respect to the major axis, i.e. the rope used for hoisting the pole should be parallel to the
broader face of the pole.
8. TESTS
i. Transverse Strength Test
a) Poles made from ordinary Portland cement shall be tested only on the completion of
28 days after the day of manufacture.
b) The poles may be tested in either horizontal or vertical position. If tested in horizontal
position, provisions shall be made to compensate for the overhanging weight of the
pole, for this purpose, the overhanging portion of the pole may be supported on a
movable trolley or similar device.
c) The pole shall be rigidly supported at the butt end for a distance equal to the bens
“agreed depth of planting.
d) Load shall be applied at a point 600 mm from the top of the pole and shall be steadily
and gradually increased to the design value of the transverse load at first crack. The
deflection at this load shall be measured.
A prestressed concrete pole shall be deemed not to have passed the test if visible
cracks appear at a stage prior to the application of the design transverse load for the
first crack.
The load shall then be reduced to zero and increased gradually to a load m equal to
the first crack load plus 10% of the minimum ultimate transverse load Poe: and held
up for 2 minutes. This procedure shall be repeated until the load reaches the value of
80 percent of the minimum ultimate transverse load and thereafter increased by 5
percent of the minimum ultimate transverse load until failure occurs. Each time the
load is applied, it shall be held for 2 minutes. The load applied to pre-stressed concrete
pole at the point of failure shall be measured to the nearest five Kilograms. The pole
shall be deemed not to have passed the test if the observed ultimate transverse load
is less than the design ultimate transverse load.
ii. Measurement of Cover

After completion of the transverse strength test, the sample pole shall be taken and checked
for cover. The cover of the pole shall be measured at 3 points, one within 1.8 meter from the
butt end of the pole, the second within 0.6 meters from the top and the third at an intermediate
point and the mean value compared with the specified value.
The mean value of the measured cover should not differ by more than (±) 1 mm from the
specified cover. The individual values should not differ by more than (±) 3 mm from the
specified value.
iii. Marking
A black ring is to be painted at 1.5 m for 8.0m PSC poles i.e. planting depth from the base/
bottom of the pole with indelible marker.
9. INSPECTION &TESTING:
The pole manufactured at your works shall be inspected/tested as per provision of IS:2905 and
IS:1678 by a representative deputed by the Purchaser.
Destruction test should be resorted to as per code of practice. The full lot in which the failure occurs
shall be rejected.
TESTING OF POLES
Testing of poles will be carried out at the rate of one in 500 poles cast. Destructive test as per IS
2905 shall be carried out in the presence of a representative of the Purchaser. All testing
arrangements and labour required for testing the poles shall be supplied by the Supplier/SI. None
of the tested pole will be accounted in the bills for payment to the SI. A lot of 500 poles will be treated
as passed and suitable for works, if the pole selected at random and tested, withstood the test. If
the selected pole fails in the test another pole shall be selected and tested. If that second pole also
fails during the test, 4 Nos. new poles will be selected and tested. If all the 4 poles pass the test,
then only, the lot will be treated as quality check passed. Otherwise the entire 500 poles will be
treated as damaged poles and rejected and there will not be any payment for the entire lot of 500
poles.
10. BRIEF TECHNICAL SPECIFATION:
8.00 m Pre-Stressed Concrete Pole (200 kg Working Load)
S.No. DESCRIPTION QUANTITY
1 LENGTH OF POLE 8.00 m
2 SIZE OF THE POLE – TOP 14.5 cm X 9.0 cm
3 SIZE OF THE POLE – BOTTOM 29.0 cm X 9.0 cm
4 THICKNESS OF THE POLE 9.0 cm
5 CONCRETE MIX M42
6 QUANTITY OF CONCRETE PER POLE 0.157 m3
7 SIZE OF HTS WIRE 4 mm
8 NUMBER OF HTS WIRE 14 nos.
9 TENSIONED WIRE 12 nos.
10 UN-TENSIONED WIRE 2 nos.
11 WEIGHT OF EACH POLE (approx.) 380 kg
12 CLEAR COVER TO WIRES 20 mm
13 FACTOR OF SAFETY 2.5
14 WORKING LOAD 200 kg
ULTIMATE TENSILE STRENGTH OF PRE-
15 175 kg/mm2
STRESSING WIRE
2.7 Block Location - Modular Network Rack (42 U):

S.No Minimum requirement description
1 Form factor 42 U Rack Modular Network Rack (Minimum 800 * 1000)
2 General Floor mount Rack – 42 U with heavy duty extruded Aluminum Frame
for rigidity. Top cover with FHU provision. Top & Bottom cover with
cable entry gland plates. Heavy Duty Top and Bottom frame of MS.
Two pairs of 19” mounting angles with ‘U’ marking. Depth support
channels - pairs
A Front and Back doors should be perforated
B All racks should have mounting hardware 2 Packs, Blanking Panel.
C All racks must be lockable on all sides with unique key for each rack
D Racks should have Rear Cable Management channels, Roof and
base cable access.
3 Wire managers Two vertical and four horizontals
4 Power Power Distribution Unit Vertically mounted 2 nos - 06/16 Amp
Industrial socket-6 socket with Complete hardware accessories.
5 Door The racks must have steel (Solid / grill / mesh) front / rear doors and
side panels. Racks should Not have glass doors/ Panels.
6 Door Both the front and rear doors should be designed with quick release
hinges allowing for quick and easy detachment without the use of
tools.
7 Fan Fan 90CFM 230V AC, 4” dia (2 No.s per Rack)
8 Fan Trays Fan Housing Unit 2 Fan position (Top Mounted) (1 no. per Rack)
9 Side panels Detachable side panels (set of 2 per racks)
2.8 Gram Panchayat Type 1 - Modular Network Rack (27 U):

S.No. Minimum requirement description
1 Form factor 27 U Rack Modular Network Rack (Minimum 800 * 1000)
2 General Floor mount Rack – 27 U with heavy duty extruded Aluminum Frame
for rigidity. Top cover with FHU provision. Top & Bottom cover with
cable entry gland plates. Heavy Duty Top and Bottom frame of MS.
Two pairs of 19” mounting angles with ‘U’ marking. Depth support
channels - pairs
A Front and Back doors should be perforated
B All racks should have mounting hardware 2 Packs, Blanking Panel.
C All racks must be lockable on all sides with unique key for each rack

S.No. Minimum requirement description
D Racks should have Cable Management channels, Roof and base
cable access.
3 Wire managers Two vertical and four horizontals
4 Power Power Distribution Unit Vertically mounted 2 nos - 06/16 Amp
Industrial socket-6 socket with Complete hardware accessories.
5 Door The racks must have steel (Solid / grill / mesh) front / rear doors and
side panels. Racks should Not have glass doors/ Panels.
6 Door Both the front and rear doors should be designed with quick release
hinges allowing for quick and easy detachment without the use of
tools.
7 Fan Fan 90CFM 230V AC, 4” dia (2 No.s per Rack)
8 Fan Trays Fan Housing Unit 2 Fan position (Top Mounted) (1 no. per Rack)
9 Side panels Detachable side panels (set of 2 per racks)
Base frame
150mm ISMC Base Frame for 27 U/42 U rack as required size.
2.9 Gram Panchayat Type 2- 9U RACK (Wall Mount)

General 9U 19" wall mount rack 600mmW/500mmD, Front glass door with lock & key
Requirements Bolted construction, Top and Bottom Cable entry provision, Maximum load
carrying capacity of 40Kg.
Accessories Fan -AC-90cfm, Cable manger 1u 19” Cantilever Shelf 1U 19” mtg, CKD
type completely knock down condition
PDU Power Distribution Unit 1nos-06/16 Amp universal socket-6 socket with
Complete hardware accessories.
2.10 Mesh type filters

Stainless steel perforated sheet with 4 mm hole diameter with fine holes punching type with necessary
framework to prevent dust and insects as per site window size (1200 mm*1300 mm). In each PoP two
mesh type filters to be installed at two to maintain the Ambient temperature and remaining two windows
must be closed.

Annexure A TecGRs

Uploaded by

Document Information

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

Annexure A TecGRs

Uploaded by

Copyright:

Available Formats

Tamil Nadu FibreNet Corporation Ltd

Annexure-A – Technical Specifications (TEC

Tamil Nadu FibreNet Corporation Ltd

TANFINET Corporation 2 Bidder’s sign and Seal

TANFINET Corporation 3 Bidder’s sign and Seal

TANFINET Corporation 4 Bidder’s sign and Seal

1. ANNEXURE A - TECHNICAL SPECIFICATIONS

1.1 Technical Specification -Package A

TANFINET Corporation 5 Bidder’s sign and Seal

TANFINET Corporation 6 Bidder’s sign and Seal

Traffic engineering should be used for the following

g) Providing bandwidth guarantee for critical real-time applications in

7. Layer 3 MPLS a) Layer 3 MPLS VPN can be broadly classified in to :

TANFINET Corporation 7 Bidder’s sign and Seal

1.1.2 Functional Requirements for NOC

TANFINET Corporation 8 Bidder’s sign and Seal

TANFINET Corporation 9 Bidder’s sign and Seal

B- Common Guidelines Regarding Compliance of Equipment/System

d) All IT components should support IPv4 and IPv6

g) All equipment, parts should be original and new.

m) All IP MPLS routers shall be from same OEM

TANFINET Corporation 10 Bidder’s sign and Seal

q) All licenses should be in the name of the Authority.

C- Network Operation Centre – Technical Specification

TANFINET Corporation 11 Bidder’s sign and Seal

1.1.4 NOC and Internet Router Specifications

High Availability of Line cards and the Control plane

TANFINET Corporation 12 Bidder’s sign and Seal

TANFINET Corporation 13 Bidder’s sign and Seal

TANFINET Corporation 14 Bidder’s sign and Seal

The Router should support streaming of data to a performance management system to

1.1.4.1 Router Specifications Wire Speed

1.1.4.2 Router Ports Specifications

1.1.4.3 Routes and Addresses

TANFINET Corporation 15 Bidder’s sign and Seal

1.1.5 Core Switch

7 Chassis should be 19” rack mountable type

8 The operating system of the switch shall have a microkernel-based architecture.

19 Should support MC-LAG or equivalent for a single (virtual) L2/L3 interface.

21 Should have RIP v1/v2, OSPF v1/v2 from Day 1.

22 Should support BGPv4, IS-IS.

24 Should have VRRP Protocol.

TANFINET Corporation 16 Bidder’s sign and Seal

25 Should support H/W based IPv4 and IPv6 Multicasting.

26 Should Support IGMP v1, v2, v3, IGMP Snooping.

28 Should support Access Control Lists.

32 Should have support for RADIUS and TACACS+

33 The switch should support Port-security.

34 Should support Ingress/Egress Queuing.

35 Should be able to filter, mark and limit traffic flows.

41 The switch should support configuration verification and rollback.

TANFINET Corporation 17 Bidder’s sign and Seal

TANFINET Corporation 18 Bidder’s sign and Seal

1.1.7 Ports & Performance Requirement

Future 10 G Fibre 10 100 Gbps

TANFINET Corporation 19 Bidder’s sign and Seal

1.1.8 Hyper Converged Infrastructure

S.No Minimum Requirements Description

TANFINET Corporation 21 Bidder’s sign and Seal

1.1.9 GIS Software License

TANFINET Corporation 22 Bidder’s sign and Seal

TANFINET Corporation 23 Bidder’s sign and Seal

1.2.1 BSS- Customized Billing Solution-