Terms of Reference (ToR) for Establishment of IP-based International Switching System (ISS) in Baku

Project Title: “Modernization of Sustainability and Efficiency of ICT infrastructure and ICT services in the Republic of Azerbaijan”

Duration of work: The total duration of works will be 5 months within the period of February 2014 - June 2014. Duty Station: 74, A. Huseynzade Street, Baku, Azerbaijan

Background: Government of Azerbaijan pays special attention to the development of information technologies. Azerbaijan's National ICT Strategy (2003-2012) has promoted a widening use of ICT tools to raise efficiency and transparency in the public sector, and recognizes innovation as one of the underlying principles for ICT application. Azerbaijan is also well-known regionally and internationally for its promotion of information society as a national development priority. Concerted national efforts invested by the Government of Azerbaijan have enabled the country to become one of the best performers among the CIS countries. The ICT sector grew twice in size on average span of every 3 years covering the period of 2004-2013. The Republic of Azerbaijan is a leader among CIS countries for the density of Internet users during the last three years. In 2012 this figure increased from 65 % to 70%. Likewise, the quality of internet services as well as external internet connectivity increased by 2.2 times in 2012 and prices reduced by approximately 35% compared to 2011. Azerbaijan has caught up and, in a few instances, surpassed the Upper Middle Income Countries average, already moving close to the high-income country values. It is imperative that Azerbaijan builds upon this momentum by making it more sustainable through development of a comprehensive ICT strategy, a broader access through country-wide ICT infrastructure, promotion of ICT integration in business, and greater use of ICTs for social and economic impact. Development and growth in the modern age is directly associated with the application of Information and Communication Technologies (ICT). At present, the level of application of ICT is among the main indicators of intellectual and scientific potential, transparency in the public administration, solution of social and economic problems. ICTs are playing an increasingly important role in the achievement of Millennium Development Goals as a powerful tool to fight poverty, empower women, increase the education level, and improve environmental management. In June 2013 Ministry of Communications & IT proposed initiative on establishment of the IP-based International Switching System (ISS) in Azerbaijan. The establishment of the first Data Center in Azerbaijan will be deploying an IP based ISS as a demarcation point for International incoming and outgoing voice traffic at first, and then for using this infrastructure to give telecommunication services to the residential and business customer segment. Today in Azerbaijan, whole international incoming (from abroad to Azerbaijan) and outgoing (from Azerbaijan to abroad) voice traffic is carried over a TDM based Alcatel

System 12 Exchange (S12) located in AzTelekom’s building. Since the outdated S12 is only capable of carrying the international incoming and outgoing voice traffic, no value added voice or multimedia services can be provided to the customers. Today in Azerbaijan, whole international incoming (from abroad to Azerbaijan) and outgoing (from Azerbaijan to abroad) voice traffic is carried over a TDM based Alcatel System 12 International Gateway Exchange (S12) located in AzTelekom’s building. In case of an outgoing traffic the call is originated by a national PSTN or mobile network, directed to the S12 through E1/STM connections and routed to the most profitable and/or high quality providing international transit operators. In case of an incoming traffic; the call is forwarded by the international operator to the S12, and routed to the related national operator according to the destination number’s prefix. Since the outdated S12 is only capable of carrying the international incoming and outgoing voice traffic, no value added voice or multimedia services can be provided to the customers. Driven by the introduction of Voice over IP (VoIP) as well as the Move-to-all-IP and the phase out of legacy TDM technology, the “Modernization of Sustainability and Efficiency of ICT infrastructure and ICT services in the Republic of Azerbaijan” project is looking for a solution based on the latest technology to develop and keep up to date the country’s telecommunication asset. As a result of this, Project would like to deploy an IP based International Switching System (ISS) in Baku. The ISS is planned to replace the whole S12 platform and to be located in a new, international standards based (TIA942) data center building. The Project will choose the contractor/vendor, which will be in charge of setting up and delivering the ISS project as turnkey basis, by evaluating an RFP process both in terms of technically and commercially. UNDP is a natural partner for this complex project for the following reasons. UNDP Azerbaijan has a well-deserved reputation as a long-time supporter of a number of ICT-for-Development (ICT4D) projects in Azerbaijan. It has assisted the government to prepare the first National ICT Strategy, establish AzDataCom network, and automate business processes in the Pension Fund, Ministry of Justice, Civil Service Commission and State Customs Committee. It should be noted that Establishment of International Switching System in Baku will be totally funded by the Ministry of Communications and Information Technologies of the Republic of Azerbaijan. Objective: Establishment of IP based International Switching System (ISS) in Azerbaijan as a demarcation point for International incoming and outgoing voice traffic at first, and then for using this infrastructure to provide telecommunication services to the residential and business customer segment.

Scope of the work: The winning contractor will be responsible for setting up all the network infrastructure shown in the figure below.

Figure – The ISS Infrastructure

General requirements: The works to be done in ISS project is: “Establishment of IP-based ISS

(International Switching System) in Baku”:

1. Session Border Controller (SBC as I-BGF&IBCF, MRFC)

2. Class 4 Softswitch (as TrF,MGCF,MRFC,MRFP)

3. Trunking Media Gateway (as MGW,SGW,MRFP)

4. Firewall (FW)

5. Core Routers

6. Core Switches

7. Data Center Switches

8. Data Center ToR Switches

9. NOC Monitoring Dashboard

10. Network Management System (NMS)

11. Number Portability Solution (NP)

12. Routing and Billing System

13. Fraud Management System as a Professional Service

Useful notes

It is preferred the listed items above with # 1,2,3 to be provided by the same

manufacturer/vendor.

It is preferred the listed items above with # 5,6,7,8 to be provided by the same

manufacturer/vendor.

All the possible products listed above must be geographically redundant (GeoR)

(Please see the whole Technical Specifications Document for the GeoR related

products). The future planning redundant site will be far away ~10 Km from the

primary site. Although, at day 1 the redundant site will not be ready, the listed

producs must be provided as GeoR (better they to work in active/hot standby mode

in primary site until the disaster site launched).

All the critical alarms of the ISS project products’ must be shown in the supplied NOC

Monitoring Dashboard to help the NOC staff to track the events.

An NMS must be supplied to monitor all possible products in the project.

To process the call detail records, a Billing and Mediation System must be supplied.

All the National/International Mobile, Fixed Licensed Operators will be called as LOP.

Mobile Operators, Fixed Operators and National Internet Telephony Service

Providers (ITSP) are defined as NATIONAL Operators (NAT). All the operators in the

IGW cloud are defined as INTERNATIONAL Operators (INT). TDM based NAT and INT

operators, and IP based NAT operators will be connected to the ISS over the Baku city

Network as depicted above. IP based INT operators will be connected to the ISS using

IGW’s internet connection.

Total voice traffic for present is 80.000.000 minute/month (mostly TDM to TDM). Its

combined of 60M/month from international to Azerbaijan (IN) and 20M/month from

Azerbaijan to international (OUT). Fractionation per operators: Mob 1 Azercell –

45M, Mob 2 Bakcell – 15M, Mob 3 Azerfon – 10M, Baku PSTN – 5M, Regions – 5M.

Final capacities must be considered as 100% more than the present capacities, and

offered products must be chosen to support the final capacities without any

hardware changes.

For the calculation of BHCA/CAPS/simultaneous calls, average call time = 90 sec,

answer to seizure ratio (ASR) = 50%.

Call types

INT IN/OUT (International In&Out) includes the traffic between

o NAT TDM and INT TDM (eg, traffic between Mobile Operator and a TDM

based operator in IGW)

o NAT TDM and INT IP (eg, traffic between Mobile Operator and an IP based

operator in IGW)

o NAT IP and INT TDM (eg, traffic between National ITSP and a TDM based

operator in IGW)

o NAT IP and INT IP (eg, traffic between National ITSP and an IP based operator

in IGW)

TR-NAT (National Transit) includes the traffic between

o NAT TDM and NAT TDM (eg, traffic between Mobile Operator and Fixed

Operator)

o NAT TDM and NAT IP (eg, traffic between Mobile Operator and National ITSP)

o NAT IP and NAT IP (eg, traffic between a National ITSP and another National

ITSP)

National Transit traffic will not be applicable at day 1, but it will be presented as a

new service to the NAT needs to offload some of their traffic.

TR-INT (International Transit) includes the traffic between

o INT TDM and INT TDM (eg, traffic between two TDM based operators in IGW )

o INT TDM and INT IP (eg, traffic between a TDM based operator in IGW and an

IP based operator in IGW)

o INT IP and INT IP (eg, traffic between two IP based operators in IGW)

Requırements for CLASS4

The high level Class 4 transit/interconnect architecture shows a number of IP

interconnection points (IPCPs), an IP interconnection network, or transit network and a

number of TDM interconnection points (TDM-CPs).

In case of IP interconnect, other licensed national/internatinal operators (LOPs) connect to

one or more IPCPs using a primary link. Both signalling and media travel through the same

IPCP:

Signalling is treated by the functions IBCF and TrF. The IBCF and the TrF are central function.

Media is treated by the function I-BGF, which is centrally located.

In case of TDM interconnect, LOPs connect to one or more TDM-CPs using a primary link.

Both signalling and media travel through the same TDM-CP where the signalling will be back-

hauled from the MGW to the centralized MGCF.

Signalling is treated by the functions MGCF and TrF. Both will be a central function.

Media is treated by the function MGW, which is centrally located.

The role of the IP class4 network is to provide enhanced routing capabilities e.g. decide

whether a call needs to be terminated in VoIP, PSTN, PLMN, an IP interconnected LOP or a

TDM interconnected LOP. This involves taking into account NP data and possibly apply a

barring policy according to the applicable service plan. Additionally media transcoding is

required to be performed as well. Therefore some call handling logic is required in the IP

class 4 network. Finally, charging data needs to be generated.

The envisaged high level architecture is shown in figure.

LOP -1IP

I-BGF

ENUM

LOP -2TDM

IBCF

TrF

MGCF

MGW

IPCP

TDM-CP

Figure – High Level Architecture

Functional Architecture

The functional architecture (based on ETSI TISPAN and 3GPP) a number of functional entities

devoted to transit and interconnection.

The main building block is a transit functional entity (TrF), including interaction with an ENUM database. The TrF is the only functional element for routing, accounting, barring and network management.

The IBCF/I-BGF caters for the interconnection of IP based signaling and IP based media.

The MGCF/MGW caters for the interconnection of TDM based signaling and TDM based media.

1. The solution proposed by the vendor shall comply to the above functional architecture.

Please explain how your physical solution fulfills this functional architecture.

Signalling traffic from an interconnected network enters the class 4 platform via the

incoming IBCF or MGCF. The incoming IBCF or MGCF sends the traffic to the TrF in order to

determine where the destination is located. This routing decision can depend on:

The presence of routing information in the Request-URI (resulting from a (NP) query performed by the preceding network), or

A database query (e.g. ENUM) in case no routing information was present.

The signalling traffic is then sent to the next network via the outgoing IBCF or MGCF.

2. Please explain how your solution supports this treatment of signalling traffic, especially

the support of the routing decisions by the TrF.

Media traffic from an IP interconnected network enters the class 4 platform via the incoming

I-BGF or MGW. The outgoing I-BGF or MGW sends the media traffic to the destination

network.

3. Please explain how your solution supports this treatment of media traffic, especially the

support of hairpinning.

Functional Building Blocks

The envisaged functional architecture for the IP transit and interconnect network consists of:

Interconnect Border Control Function (IBCF)

Interconnect Border Gateway Function (I-BGF)

Media Gateway Control Function (MGCF)

Media Gateway Function (MGW)

Signalling Gateway Function (SGF)

Transit Function (TrF)

In order to be able to perform transcoding or to provide tones/announcements the following

functional entities are needed:

Media Resource Function Controller (MRFC)

Media Resource Function Processor (MRFP)

In order to be able to perform charging the following functional entity is needed:

Charging functions (CCF)

Interconnect Border Control Function/Interconnect Border Gateway Function (IBCF/I-BGF)

The IBCF/I-BGF functions will be co-located in a Session Border Controller (SBC).

4. Please refer to “REQUIREMENTS OF SBC” part of this document.

Media Gateway Control Function/Media Gateway Function ( MGCF/MGW)

5. The MGCF and Trunk MGW shall be a split architecture in which one MGCF shall be able

to control several MGW and one MGW shall be able to be controlled by more than one

MGCF. Please describe your solution.

Media Gateway Control Function (MGCF)

6. The MGCF shall support conversion between SS7 ISUP (v2) signalling and SIP/SIP-I

signalling according to 3GPP TS 29.163 Release 9 or later. Specifically following aspects

need to be covered:

Support for, and conversion of, en-bloc and overlap signalling. Remark: The MGCF shall support both methods defined in TS 29.163.

It shall be configurable per trunk group which of both methods will be used.

Treatment of early media scenarios. Handling of early media is important concerning voice clipping etc. for announcements etc.

In case of a call from PSTN to IP the MGCF shall not use the CLI to populate the SIP Contact header.

Support for DTMF

Please describe the capabilities of your solution.

7. The MGCF shall support multiple SS7 point codes (PC), please indicate the supported

number of PCs.

8. The MGCF shall support Number Portability. This includes:

Performing INAP NP query

Mapping of SS7 ISUP NP information (e.g. routing prefix, NoA etc.) into SIP NP information (refer to RFC 4694).

9. The MGCF shall allow to adapt and adjust the SS7 ISUP signaling and/or SIP signalling:

It shall be possible to manipulate incoming signalling messages before further treatment

It shall be possible to manipulate outgoing signalling messages just before sending The manipulations includes:

Parameter manipulations e.g. add, remove, change content

Message manipulations e.g. add, remove, change content

These manipulations need to be configurable per trunk group or interconnect link.

Please describe the capabilities of your solution.

Media Gateway (MGW)

10. The MGW shall at least support the voice codecs G711 A-law, G.729, G.729a, G.729b,

GSM FR, AMR-NB, AMR-WB, including transcoding between them, and the pseudo-codec

called “clearmode” according to RFC4040.

Please provide a complete list of supported codecs

11. The MGW shall support different Fax over IP methods:

G.711 Fax pass through with fax tone detection, de-activation of echo cancelling, allocation of a fixed jitter buffer.

T.38 Fax relay

Please describe the capabilities.

12. The MGW shall support voice band data calls. Please provide a list of modem standards

supported and describe the solution.

13. The MGW shall support Echo cancelation, controlled by the MGCF. Echo cancelation shall be configurable per trunkgroup. Please describe the solution.

14. The MGW may need to generate tones e.g. congestion tone. Please provide a complete list of available tones.

15. The MGW shall support Type of Service (TOS) bits for IP traffic. 16. The MGW shall support a configurable adaptive jitter buffer. 17. The MGW shall support VLAN tagging according to IEEE 802.1Q.

Signalling Gateway Function (SGF)

18. A Signalling Gateway Function shall be co-located with the Media Gateway Function.

Does your proposed MGW include SGF functionality (e.g. SIGTRAN etc.)

19. Please list all supported adaptation layers (e.g. M2UA).

Transit Function (TrF)

20. The TrF shall provide all the enhanced routing capabilities listed below:

Calling Party Category (CPC) routing

Routing / Translation based on Called Party Number elements

Charge category routing

Least Cost Routing (LCR)

Time Of Day (TOD) routing

Percentage / random conditional routing

NCOS (Network Class Of Service) routing

Bearer Capability (BC) routing

NRR (Network Re-Routing)

21. The TrF shall be able route a call to an MRFC/MRFP in order to play tones or

announcements or to include media transcoding equipment in the media path, based on

(at least):

Remote failures (received SIP response codes or received ISUP release causes)

An internal telephone event (e.g. no match found)

A rerouting code (e.g. B<something>)

SDP information

Please describe the capabilities of your solution.

22. The TrF shall support database queries (i.e. ENUM). Whether to perform a query shall

depend on parameters like e.g. originating network, presence of routing information, SIP

NP parameters (refer to RFC 4694) etc.

Please explain the capabilities and configurability of the TrF.

System redundancy

23. Each component of the solution shall be fully redundant in an active/hot standby mode.

24. Both automatic failover (in case of failure of the active side) and manual failover (e.g. in

order to perform upgrades) shall be supported.

25. If any component can not be redundant in the system, the Supplier shall list the components and describe all consequences in case of failure of the component occurs.

26. The vendor shall describe how the integrity of system data (e.g. routing data in TrF) is assured as well as the recovery tools available.

27. The vendor shall describe how the integrity of system data (e.g. routing data in TrF) is assured as well as the recovery tools available.

Interfaces and Protocols

TDM interfaces

28. The MGW shall support the Universal T1/E1 Channelized Interface. 29. The MGW shall support the DS3 Channelized Interface. 30. The MGW shall support the Enhanced Quad OC-3/STM-1 31. The MGW shall support the Enhanced Quad OC-3/STM-1 with Facility Protection Scheme

(FPS) 32. The MGW shall support APS (automatic protection system) on the STM1 interfaces (1+1

architecture, bi-directional mode).

IP interfaces

33. All components of your solution shall support Gbit Ethernet interfaces. Please describe all available I/O boards (optical/electrical, SFP/GBIC) that support the termination of the IP traffic (media as well as signalling).

Media protocols

34. Media transport in IP uses RTP and/or SRTP and RTCP/RTCP XR protocols . Please describe the capabilities of your solution.

35. Transport of DTMF shall be done using RTP events according to RFC 4733.

Signalling protocols

The signalling protocol requirements for each of the functional elements of the solution can

be determined based on different interconnect scenarios.

In case of an IP interconnect scenario, the interconnected LOP can use either SIP or SIP-I on

the interconnect link to the IP-ICX platform (=the external interface). Internally in the IP-ICX

platform (=the internal interface(s)) the SIP or SIP-I protocol will be used as well as

ENUM/DNS protocol, between the TrF and the ENUM database.

LOP -1IP

I-BGF

ENUM

IBCF TrF

MRFC

SIP/RTP

H.248 SIP

ENUM

SIP

IPCP

MRFP

H.248RTP

Figure – Signaling Protocols for IP Interconnect

In case of a TDM interconnect scenario, the interconnected LOP use SS7 ISUP signalling on

the interconnect link to the IP-ICX platform (=the external interface). The SS7 ISUP protocol

can be transported in 2 ways:

The current connections with the SS7 Standalone STPs are re-used and the signalling gateway function in the SA-STP is used to transport ISUP over SCTP/IP to the IP-ICX platform (i.e. to the MGCF).

A signalling gateway function in the MGW is used to transport ISUP over SCTP/IP to the IP-ICX platform (i.e. to the MGCF).

Internally in the IP-ICX platform (=the internal interface(s)) the SIP-I protocol will be used in

order not to loose valuable SS7 ISUP signalling information. The MGCF communicates with

the MGW via the H.248 protocol. Between the TrF and the ENUM database the ENUM/DNS

protocol is used.

LOP -1TDM

ENUM

TrFMGCF

ISUP

SIP-I

ENUM

ISUP/SCTP

TDM-CP

H.248

circuits

MGCF

MGW

SGW

SIP-I

LOP -2TDM

MGW

SGW

H.248ISUP/SCTP

ISUP

circuitsRTP

Figure – Signaling Protocols for TDM Interconnect

SIP/SIP-I

36. The solution shall support the SIP protocol according to:

3GPP TS 29.163 (minimum Release 9)

3GPP TS 24.229 (minimum Release 9)

ETSI TISPAN TS 283 003. 37. SIP/SIP-I signalling might contain an XML body in addition to an SDP body. All network

elements shall correctly handle multipart bodies in SIP messages.

Please list all the types of bodies your solution supports.

ISUP

38. The solution shall support SS7 ETSI ISUP (v2) signaling according to ETS 300 356-1 (1995).

39. The solution shall support SS7 MTP signalling according to ITU-T Q.70x series (minimum

White book).

H.248

40. The protocol used between the MGCF and the MGW shall be H.248. Please provide

detailed information about the supported H.248 packages. Text encoding as well as

ASN.1 encoding of H.248 signalling shall be supported in all applicable network elements.

Traffic management

41. The solution shall provide a traffic management capability allowing The Customer to limit

the bandwidth, number of simultaneous sessions, codec used, based on a contract

between The Customer and the LOP. This shall be available for incoming traffic as well as

for outgoing traffic.

42. The solution shall provide a traffic management capability allowing The Customer to

protect the network against traffic bursts (session establishment burst), bandwidth

saturation.

43. The solution shall support priority calls. A priority call may be a call to an emergency

centre (priority based on destination) or may be a call from a priority user (e.g police).

Transcoding

In some transit voice call scenarios transcoding might be necessary:

VoIP-to-VoIP: in case the originating network and the terminating network do not use the same codec the transit network i.e. the MRFC/MRFP may require to do transcoding.

VoIP-to-TDM: in case the originating network does not use G.711 A-law codec, the MGW requires to do transcoding.

TDM-to-VoIP: in case the terminating network does not use G.711 A-law codec, the MGW requires to do transcoding.

TDM-to-TDM: no transcoding needed.

44. The solution shall allow The Customer to configure the decision for transcoding based on

parameters like e.g. incoming network/trunkgroup/SIP trunk, outgoing

network/trunkgroup/SIP trunk, codec.

Please describe your solution.

Charging and accounting

45. The solution shall be able to generate Call Detail Records (CDRs).

The CDR shall contains at least the following key fields:

Calling party

Called party (as received)

Destination party (as sent out, e.g. after ENUM query)

Incoming route

Outgoing route

Seizure time (date and hour)

Answer time (if applicable – date and hour)

Media type (for audio, video and events)

Release time (date and hour)

Releasing party

Release reason (a SIP error code and/or ISUP release cause)

Please describe your solution. Please indicate which functional element in your architecture

will be responsible to create the ADRs.

46. For long duration calls partial CDRs shall be generated every 8 hours in order to detect

and prevent timely fraud. The interval shall be configurable.

47. The solution shall be able to offload (push/pull) the CDRs to the The Customer’s charging

and billing chain.

Please describe the capabilities of your solution.

Scaling and capacity

48. The vendor shall provide information about the maximum capacity (in terms of call

attempt per second, simultaneous SIP sessions, interface capacity) of the solution.

Dependencies of the capacity on different HW/SW configurations of the functional

elements (IBCF, MGCF, etc. ) shall be detailed.

49. The vendor shall indicate if any other service parameters affect the capacity and

performance and the degree to which the capacity and performance is affected by each

of these parameters.

50. The vendor shall describe how the offered solution scales (in terms of equipment extensions).

51. Provisioning, service management, monitoring, operation and maintenance (including backup) of the system shall not degrade the performance of the platform. The load of the system under normal conditions shall not impact the performance of the provisioning and the operation of the system.

52. Scaling the capacity of the system (e.g. by adding network elements) shall not impact the interfacing of the system to the operation support systems (for provisioning, monitoring, operation and fault management). This means for instance that all actions can be performed via the same unique physical and logical interface independent of the capacity of the system.

53. If capacity and performance limits are reached and exceeded, there shall be a graceful degradation of the services. Describe the effect. How is the reporting and alarming of overload done.

Security

54. Each user shall have a dedicated login on each of the components, with a dedicated user profile. At least the following profiles shall be available:

System administrator

User administrator

Operator

Viewer

55. All the commands/actions performed on the solution shall be logged with the associated id of the one performing those commands/actions.

56. The solution shall provide a Single Sign On solution to logon on the platform components. It shall support LDAP and active directory.

57. The solution shall provide centralized remote user access management for remote vendor access (e.g. in case of vendor interventions). All the commands/actions performed by the vendor shall be logged with the associated id of the one performing those commands/actions. Please describe your remote user management solution.

Requırements for sessıon border controller

Architecture

58. The offered session border controller solution shall support decoupling of signaling and media processing, each with dedicated multi-core processors.

59. The offered session border controller solution shall provide separate interfaces for

signaling and media.

60. The offered session border controller solution shall have common SBC software on all

hardware.

61. The offered session border controller solution shall support virtualized SBCs running on

same physical hardware.

62. Each virtuliazed SBC on the same physical hardware shall include separate user access,

CDRs, reporting and analytics, routes and policy configuration.

63. The offered session border controller solution shall support in service patchability.

Call Control

64. The offered session border controller solution shall support B2BUA - Back to Back user

agent.

65. The offered session border controller solution shall support Outbound Proxy mode.

66. The offered session border controller solution shall support Mirror Proxy mode

(Outbound proxy with toplogy hiding).

67. The offered session border controller solution shall support H.323 Gatekeeper.

68. The offered session border controller solution shall interwork between IMS and non-IMS

call flows.

69. The offered session border controller solution shall have integrated I-BCF/ BGF functions

within.

Security

70. The offered session border controller solution shall support dynamic pin hole

management - open close media pin holes only for sessions established.

71. The offered session border controller solution shall support topology hiding via L3/4

NAT/PAT.

72. The offered session border controller solution shall support DoS/DDoS protection.

73. The offered session border controller solution shall support Registration Throttling (i.e.

outbound registration rate limiting): Protect core network multimedia infrastructure

entities from receiving large amount of keep alive registrations by throttling keep alive

registrations received from SIP devices and locally respond by sending 200 OK.

74. The offered session border controller solution shall support rogue RTP detection and

prevention.

75. The offered session border controller solution shall support Call admission control – in

the meaning of total incoming calls, total outgoing calls, total calls.

76. The offered session border controller solution shall support destination IP rate limiting.

77. The offered session border controller solution shall support destination bandwidth

limiting.

78. The offered session border controller solution shall support congestion control

mechanisms to prevent overload conditions - CPU, memory, processes, request queues

with configurable response code.

79. The offered session border controller solution shall support access control lists - IP

based, DID based, subnet based.

80. The offered session border controller solution shall protect against theft of service

through strict protocol and payload inspection and policing.

81. The offered session border controller solution shall support 802.1q VLAN traffic mapping

for boht layer 2 and layer 3 VPN aggregation and bridging to separate customer and

supplier traffic securely.

82. The offered session border controller solution shall support IPSec - transport mode and

tunnel mode with pre-shared key as well as X.509 certificates.

83. The offered session border controller solution shall support TLS - Transport Layer

Security.

84. The offered session border controller solution shall support RADIUS based session

authentication & authorization.

85. The offered session border controller solution shall be hardened against various security

vulnerabilities.

86. The offered session border controller solution shall have hardened VoIP stack (SIP and

H.323) designed to protect against malformed messages and protocol abnormalities.

Additionally SIP stack protects against DoS and SIP vulnerabilities such as Codenomicon,

PROTOS, SIP Torture test (RFC 4475).

87. The offered session border controller solution shall support user privacy management -

RFC 3325 and Draft-01 support.

88. The offered session border controller solution shall support SRTP – Secure RTP.

89. The offered session border controller solution shall support CDR Checksum to validate

the content of CDRs and avoid any billing fraud.

90. The offered session border controller solution shall support SIP BYE message rate limiting

in the event of large number of sessions being terminated simultaneously.

Interworking

91. The offered session border controller solution shall interwork between H323/SIP.

92. The offered session border controller solution shall interwork between H.323 slow start -

fast start.

93. The offered session border controller solution shall support SIP over UDP/ TCP/ TLS/

SCTP.

94. The offered session border controller solution shall support with and without SDP.

95. The offered session border controller solution shall interwork between SIP to SIP-I/ SIP-T.

96. The offered session border controller solution shall interwork between IPv4 to IPv6.

97. The offered session border controller solution shall support ANI and DNIS manipulation.

98. The offered session border controller solution shall support High scale DTMF Translation

- SIP INFO to SIP NOTIFY, RFC 2833 to inbound G.711, inbound (RFC 2833 or G.711) to out

of bound (SIP INFO/ SIP NOTIFY).

99. The offered session border controller solution shall support Multi-vendor interop - IP

PBX's, softswitches, IP Phones, IADs, SBC, GWs.

100. The offered session border controller solution shall support overlapping IP addresses

– both for signaling and media.

101. The offered session border controller solution shall provide dynamic SIP Header &

message manipulation function- add/ modify/ delete/ pass through.

102. The offered session border controller solution shall support Diversion Header

manipulation : Manipulating the contents of the SIP Diversion header allows for

translation between E.164 numbers and “internet ID” (user@host) address types using

call route-level manipulations that map one identifier to another. All combinations of

translation are supported (i.e., number-to-ID, number-to-number, ID-to-ID, and ID-to-

number).

103. The offered session border controller solution shall support ISDN Cause code to SIP

response code mapping.

104. The offered session border controller solution shall support SIP response code

mapping.

105. The offered session border controller solution shall support media transcoding and

transrating.

106. The offered session border controller solution shall support T.38 to G.711 fall-back.

Service Visibility and SLA Assurance

107. The offered session border controller solution shall provide detailed CDRs and SDRs.

108. The offered session border controller solution shall provide Radius CDRs.

109. The offered session border controller solution shall store CDRs locally and externally.

110. The offered session border controller solution shall support QoS media policing,

marking, metrics collection.

111. The offered session border controller solution shall support the collection of all the

quality metrics at media and signaling layer - Jitter, Packet Loss, R-Factor, Post dial delay,

call completion rate.

112. The offered session border controller solution shall provide real time CDR alarming

and reporting for troubleshooting and performance monitoring.

113. The offered session border controller solution shall provide detailed analysis on

business, service, and network performance - cost of network, revenue of network,

profitability/ loss analysis.

114. The offered session border controller solution shall provide teal time quality CDR

alarming, notifications (email), logging and rerouting/blocking/restore routing, colour

coding/flagging based on severity classifications for:

a. Average call duration

b. Average post dial delay

c. Answer seizure ratio (ASR)

d. Average high packet loss

e. Low voice quality (R-Factor)

f. High packet loss

g. Post Dial Delay

115. The offered session border controller solution shall support business CDR alarming,

notifications (email), logging and rerouting/percentage based rerouting/blocking based

on thresholds for dollar amounts, minutes, calls by trunk group, destination, origination,

supplier, customer.

116. The offered session border controller solution shall support monitoring of system

resources and multi-threshold alarming based on - disk usage, memory consumption,

processes, SIP statistics, port usage.

117. The offered session border controller solution shall support real time troubleshooting

by running etherial (wireshark) directly on SBCs to capture packet traces and build ladder

diagrams.

118. The offered session border controller solution shall provide consolidated view of

multiple CDRs for the same session that spans multiple SBC for terminating a session.

Routing

119. The offered session border controller solution shall support routes based on:

a. Digit Based routing based on Called Party (DNIS) or Calling Party (ANI) digits - NPA,

NPA NXX, NPA NXXX based

b. Outgoing Trunk Group (OTG) / Destination Trunk Group (DTG)

c. Domain based routing

d. Originating Line Information (OLI)

e. Local Routing Number (LRN)

f. Call Identification Code (CIC)

g. IP address of incoming /outgoing trunks

h. Incoming and outgoing cost factors (Margin / best / profit based routing) - LCR, and

profitability based

i. Capacity-Based Routing

j. Percentage-based routing

k. Time of Day based Routing

l. Day of Week Routing

m. Priority-Based Routing

120. The offered session border controller solution shall support lose route proxy - routing

based on maddr parameter.

121. The offered session border controller solution shall support To Header based routing.

122. The offered session border controller solution shall support customer specific

rate/routing plans based on traffic type.

123. The offered session border controller solution shall support overflow routing – call

blocking (total or %), by time, by day, by termination, by origination.

124. The offered session border controller solution shall support termination blocking - An

ability to block routes for all carriers or a single carrier to all routes or for specific routes.

125. The offered session border controller solution shall support advanced dynamic

routing by through dynamic adjustment of route priorities based on network

performance - adjustment of route priorities based on quality of network, cost and

profitability targets, quality of routes, and route availability.

126. The offered session border controller solution shall support routing based on

response code, route availability, and utilization.

127. The offered session border controller solution shall support ENUM based route query

to external route server - SIP, H.323, TLS.

128. The offered session border controller solution shall support Route query from

external SIP redirect server - SIP INVITE/ SIP 3xx.The offered session border controller

solution shall support

129. The offered session border controller solution shall have least cost routing engine.

130. The offered session border controller solution shall have rate management tool.

Rating capabilities:

a. By destination

b. Connection charge

c. Variable rates per call

d. Minimum billing per call (0, 10, 30 seconds etc. or based on rate)

e. Selectable billing increments

f. Time of day and day of week

g. Support for key currencies ($US, Euro, British pound)

h. Support for mass rate additions/deletions

i. CDR rerating capabilities

j. Rate data validation capabilities – warnings and error flagging.

Multimedia Capability

131. The offered session border controller solution shall support Voice, Video, Data, T.38

Fax.

132. The offered session border controller solution shall support SIP Support for Instant

Messaging and Presence.

133. The offered session border controller solution shall support QoS reporting for all

multimedia sessions.

134. The offered session border controller solution shall support proactive transcoding -

determine need for transcoding via static configuration of preferred and prohibited

codec profiles of source and destination networks.

135. The offered session border controller solution shall support dynamic transcoding -

determine need for transcoding based on session negotiation between source and

destination network.

136. The offered session border controller solution shall support codec filtering & re-

ordering - reordering of codecs in SDP based on configured preferred and prohibited

codecs, and codec priorities of destination network. This assists in reducing the need for

transcoding by managing the codecs offered in SDP.

137. The offered session border controller solution shall support centralized transcoding

solution - Use of centralized transcoder resource by multiple SBCs in the network.

138. The offered session border controller solution shall support the following Voice

Codecs:

a. AMR-NB

b. EVRC0

c. EVRC-A

d. EVRC-B

e. G.711 a-law and mu-law

f. G.722

g. G.722.2 (AMR-WB)

h. G.723.1

i. G.726

j. G.728

k. G.729a/b

l. G.729e

m. GSM FR

n. iLBC

139. The offered session border controller solution shall support Video codecs (H.261,

H.263, H.264).

140. The offered session border controller solution shall support SIP over UDP.

141. The offered session border controller solution shall support SIP over TCP.

142. The offered session border controller solution shall support SIP over SCTP.

143. The offered session border controller solution shall support SIP over TLS.

144. The offered session border controller solution shall support SIP-I.

145. The offered session border controller solution shall support SIP-T.

146. The offered session border controller solution shall support SIP SIMPLE.

147. The offered session border controller solution shall support Standards compliant

H.323 (v2, 3, and 4).

148. The offered session border controller solution shall support DSCP.

149. The offered session border controller solution shall support 802.1p/q VLANS.

150. The offered session border controller solution shall support ENUM.

151. The offered session border controller solution shall support DNS SRV.

152. The offered session border controller solution shall support RADIUS.

153. The offered session border controller solution shall support DIAMETER (Rx interface

with PCRF).

154. The offered session border controller solution shall support DIAMETER H.248

interface.

155. The offered session border controller solution shall support TLS.

156. The offered session border controller solution shall support RTP/ RTCP.

157. The offered session border controller solution shall support SNMP.

158. The offered session border controller solution shall support dual stack IPv4 & IPv6.

159. The offered session border controller solution shall support Message Session Relay

Protocol (MSRP).

Regulatory

160. The offered session border controller solution shall support E911 - Emergency Call

Routing.

161. The offered session border controller solution shall support Operator provisioned Call

Admission Control (CAC) to limit maximum media bandwidth usage for non-emergency

and emergency calls.

162. The offered session border controller solution shall support Lawful Interception.

High Availability and Resiliency

163. The offered session border controller solution shall support carrier class 1+1 HA/

standby redundancy with five 9's availability and stateful call migration.

164. The offered session border controller solution shall support geographic redundancy.

165. The offered session border controller solution shall support geographic resiliency.

166. The offered session border controller solution shall support health check of network

devices using SIP OPTIONS

167. The offered session border controller solution shall support congestion control

mechanism to monitor system resources and take proactive measures to assure

continuity of operations.

168. The offered session border controller solution shall support inservice field upgrades

without loss of service.

169. The offered session border controller solution shall have hot swappable components.

170. The offered session border controller solution shall support support for simplex EMS

system (with large capacity hard drives) as well as redundant EMS system with external

SAN array for large CDR storage.

Management

171. The offered session border controller solution shall support secure access to

management interface via HTTPS.

172. The offered session border controller solution shall support centralized EMS for full

FCAPS management of multiple SBCs.

173. The offered session border controller solution shall support 100% GUI as well as CLI

based interface for configuration.

174. The offered session border controller solution shall support XML/SOAP interface for

OSS/ BSS integration and flow through provisioning of SBC.

175. The offered session border controller solution shall support ability to incorporate into

an external Network Management System for alarm management - SNMP alarms The

offered session border controller solution shall support.

176. The offered session border controller solution shall support report management:

i. Downloaded to local file and saved in HTML, .csv. Text and XML formats

ii. Email reports

iii. Ability to save customized report formats

iv. Customized - Flexible sorting by date ranges, suppliers, destinations

v. Hierarchical reporting – grouping of a string of numbers for consolidated reporting

such as country code, city code, IP address,

vi. Dial string based reporting on a dialed number of groups of dialed numbers

vii. Sorting on fields – ability to sort reporting data on column fields

viii. Threshold reporting – ability to report on data only over or below a threshold such as

ASR for quality purposes

ix. Time zone selection for reporting

x. Unrated CDR reporting

xi. Graphical representation of reporting data

xii. Configurable currency type for business reports

177. The offered session border controller solution shall support automatically back-up

and restore any/all of the tables, data and configurations.

178. The offered session border controller solution shall support automatically log to track

changes made for routes, rates and alarms.

179. The offered session border controller solution shall support ability to import/export

CDRs.

180. The offered session border controller solution shall support role based user access

and user rights management tools for administrator and users - managing privileges

based for read only access, read and write access, configuring routing, rating and

reporting management.

181. The offered session border controller solution shall support GUI based license

management of all managed SBCs.

182. The offered session border controller solution shall support automated software

upgrade and downgrade of SBC from EMS.

183. The offered session border controller solution shall support audit trail of all activities.

184. Please provide the following performance figures of the offered product:

a. Calls Per Second (CPS)

b. Media Bandwidth

c. Concurrent SIP sessions

d. Registration rate

e. Number of registered subscribers

f. Number of routes

g. Number of local signaling IPs supported per SBC

h. Number of local media IPs supported per SBC

i. Number of local signaling VLAN’s supported per SBC

j. Number of local media VLAN’s supported per SBC

k. Number of transcoding sessions from G.711 to G.729

185. Please describe the licence model of the offered product. Make clear statements

regarding hard and soft limits of your licence model. The offered session border

controller solution shall support.

Requirements for carrier interconnect monitorıng, routıng and billing system

Traffic Forecast

Number of monthly CDRs 2nd year 3rd year

In and Out total number of total CDRs

150 Million 200 Million

186. The systems shall be scalable at least up to 200 million CDRs.

Monitoring, Alerting, and Reporting System Capabilities

187. The offered monitoring solution shall support granular CDR querying on all available

CDR parameters and metrics from multiple nodes

188. Inside these filters, duration, CDR criterias such as call count, short call, long call,

called number lenght, calling number, called number, hour, disconnected by, call id,

codec, protocol should be configurable.

189. Both ingress and egress data should be filterable where available

190. Short call variable should be configurable.

191. Long call variable should be configurable.

192. Inside these filters, KPIs such as ASR, ACR, NER, PDD, R-Factor, Jitter, Latency, Packet

Loss should be included

193. Again both ingress and egress data should be filterable where available for KPI filters

too

194. A custom efficiency ratio should be defined for individual usage in addition to the KPI

filters

195. Reporting should be able to filter inactive carriers and destinations

196. Reporting should be able to allow choosing a group of different destinations and

prefixes at the same time

197. Reporting should be able to allow different users can have own views

198. Reporting should be able to group different paramenters at the same time

199. Paging should be defined for results

200. The offered monitoring solution shall support dynamic drilldown functionality on

multiple parameters

201. There should be a second layer of filtering inside the results

202. The results should also be grouped by after queried

203. The results should be allowed to be auto refresh without re-query

204. The results should be exported to MS Excel file or Adobe PDF file

205. The offered monitoring solution shall support reports can be saved and shared

amongst users

206. The offered monitoring solution shall support scheduled reports available in multiple

formats

207. The offered monitoring solution shall support real-time call statistics at node and

carrier level with graph and matrix views

208. The offered monitoring solution shall support user configurable dashboards based on

saved reports, call stats, system stats, and alarms

209. The offered monitoring solution shall support dashboard auto slider functionality to

fit into any display size

210. The offered monitoring solution shall support powerful multi-severity alarming and

notifications based on metrics and KPIs

211. KPIs such as ASR, NER, ACD, Jitter, Packet Loss, Packet Delay, R-Factor, PDD, short call

count, long call count, and CER should be supported for alarming

212. All above criterias should be configurable as equal, greater than, lower than

213. In case of need, all above criterias should be considered with AND boolean operator

214. A threshold for Minimum CDR Count should be considered to take the alarm action

or not

215. A threshold for Total Duration should be considered to take the alarm action or not

216. Both Minimum CDR Count and Total Duration should be considered with AND

boolean operator

217. For different severities, same alarm with different action trigger should be

configurable

218. Deviation in percentage should be supported for alarm KPIs

219. Actions triggers should be emailing, SMS, API calls, or running remote commands and

in case of need, all should be configured at the same time for a single alarm

220. The system should offer a embedded SIP based call generator

221. Test calls should be scheduled

222. Audio file which will be played on call connection should be uploadable

223. ANIs for test calls should be configurable

224. Same test call should be supported from different codecs in case of need

225. A DNIS list should be uploaded in order to run testing

226. For testing, number of calls should be defined

227. For testing, per call duration should be defined

228. While testing, calls should be flagged FAS calls or no FAS calls

229. The offered monitoring solution shall support role based access control and full audit

trail

Routing Server Capabilities

230. The routing logic should be supported with a centralized routing engine instead of

direct switching node integrations.

231. The centralized routing engine shall support built-in SIP load balancer as well as DNS

server with SRV/ FQDN for load balancing, high availability, and scalability

232. The centralized routing engine shall support horizontal scalability through real-time

addition of edge route server processors into the cluster

233. The centralized routing engine shall support geographic redundancy

234. The centralized routing engine shall support RFC 3261 SIP compliance

235. The centralized routing engine shall support SIGTRAN and SS7/C7 interfaces for

legacy networks

236. The centralized routing engine shall support AIN, CAP, and INAP

237. The centralized routing engine shall support full management and provisioning web

services APIs to be used with routing logic modules

238. The centralized routing engine shall support simple to use web GUI for provisioning

network elements

239. The centralized routing engine shall support role based access control and full audit

trail

240. The centralized routing engine shall support embedded trace route utility apart from

routing logic module

Centralized Routing Server Routing Capabilities

241. The centralized routing engine shall support origin based routing plans for class of

service flexibility

242. The centralized routing engine shall support priority/order and percentage based

routing

243. The centralized routing engine shall support time of day and day of week routing

244. The centralized routing engine shall support zone routing

245. The centralized routing engine shall support US domestic and jurisdictional routing by

LATA and state

246. The centralized routing engine shall support international and domestic best match

routing by ANI and/or DNIS

247. The centralized routing engine shall support up to 18 digits depth A/B number digit

analysis

248. The centralized routing engine shall support powerful digit matching and number

translation engine with wildcards

249. The centralized routing engine shall support number portability with local NPDB in

case of need

250. The centralized routing engine shall support number portability with external ENUM

dip to NPDB

251. The centralized routing engine shall support for TGRP (RFC 4904) or OTG/DTG

252. The centralized routing engine shall support for customer identification based on SIP

Trunk Group or DNIS tech prefix in SIP invite from authorized SIP devices

253. The centralized routing engine shall support for different egress routing types based

on combinations of SIP Trunk Group, DNIS Tech prefix, and IP Addresses of Provider

Gateways

254. The centralized routing engine shall support optional 3XX q-value support for

prioritizing R-URI’s in the contact header

255. The centralized routing engine shall support route loop prevention

Routing Logic and Generation Server Capabilities

256. Routing generation engine should provide own routing logic with a high performance

centralized route server

257. The routing logic engine shall support rule based automated route policy

management

258. The routing logic engine shall support class of service to group different quality

routing between customers and suppliers

259. Rules should include removing, moving to first place, moving the last place, or

moving to a custom place

260. The routing logic engine shall support preventing cherry picking

261. The routing logic engine shall support drag & drop route changes through a

WYSIWYG type of editor

262. Supplier rates for minimum & maximum for code matching, and also avarage rate

should be summaried in routing editor

263. Minute reports and QoS charts should be embedded in routing screen

264. The routing logic engine shall support version control to track routing changes

265. The routing logic engine shall support configurable supplier rate importing

266. The routing logic engine shall support LCR routing functionality

267. The routing logic engine shall support Dynamic LCR functionality

268. The routing logic engine shall support scheduled routing functionality

269. The routing logic engine shall support percentage routing functionality

270. The routing logic engine shall support fetching of automated updates

271. The routing logic engine shall support role based access control and full audit trail

Billing and Invoicing Server Capabilities

272. The billing server shall support multi currency

273. The billing server shall support flexible destination and prefix management in offer

and routing levels

274. The billing server shall support trunk groups from different nodes to run a shared

tariff

275. The billing server shall support integrated configurable supplier rate importing with

routing

276. The billing server shall support offer management to be used for egress trunks

277. The billing server shall support general ledger both for prepaid and postpaid

interconnect carries with all in and out data

278. The billing server shall support SoA (statement of account)

279. The billing server shall support exposure reporting

280. The billing server shall support gross profit reporting in prefix level

281. The billing server shall support realtime loss alerts

282. The billing server shall support CDR reconciliation

283. The billing server shall support integrated invoicing

284. The billing server shall support invoice designer

285. The billing server shall support rerating of CDRs

286. The billing server shall support netting

287. The billing server shall support blocage functionality both for ingress direction and

netting

288. The billing server shall support role based access control and full audit trail

Requırements for router&swıtch and fırewall

Core Router (Quantity 1)

The Core Router shall provide a resilient infrastructure capable of meeting the performance,

functional and capability criteria set out within this specification as well as being scalable to

meet expansion requirements. The Core Router will operate 24 hours a day, 365 days a

year. The proposed Core Router shall allow an maintenance to be performed without

interruption to the operation of the systems / applications transported across it.

The Core Router, Core Switches, Data Center Core Switches and Top of Rack Data Center

switches should come from the same vendor units. The bidder must provide the

equipments with all necessary licenses depend on the following technical specifications:

289. The offered Core Router shall provide minimum 10 Gbps forwarding capacity and can

be scalable up to 30 Gbps or more.

290. The offered Core Router must support GE, 10GE, E1, E3, STM-1, STM-4, STM-16

interfaces.

291. The offered Core Router shall have minimum 6 Gigabit Ethernet ports with 2 SFP

Modules (one LX and one SX) and 4 1000Base-T Ethernet ports.

292. The offered Core Router shall support AC or DC power supply units. Tender shall offer

AC Power Supplies.

293. The offered Core Router must have redundant and hot swappable power supply units

and fans.

294. The offered Core Router SFP/GBIC modules shall hot-swappable.

295. The offered Core Router shall support static and dynamic (RIPv2, OSPF, BGPv4) IPv4

routing.

296. The offered Core Router shall support static and dynamic (RIPng, OSPFv2, BGP) IPv6

routing.

297. The offered Core Router shall support full MPLS capabilities (MPLS Layer 3 VPN, MPLS

Layer 2 VPN, MPLS Traffic Engineering).

298. The offered Core Router shall support BGP route filtering and BGP Communities

functions.

299. The offered Core Router shall support VRRP or similar gateway redundancy

protocol.

300. The offered Core Router shall support Authentication Authorization Accounting using

local database or RADIUS.

301. The offered Core Router should be managed via console port, Telnet, SSHv2.

302. The offered Core Router shall support SNMP v2v3.

303. The offered Core Router shall support QoS. Priority Queuing, MQC, DiffServ

(Differentiated Services) queues, Low Latency Queuing (LLQ) and Weighted RED.

304. The offered Core Router shall support Layer 3 IP Based and Layer 4 UDP and TCP

based Access Control Lists.

305. The offered Core Router shall support minimum 1.000.000 active IPv4 routes and

minimum 250.000 IPv6 Routes.

306. The offered Core Router shall support minimum 1.000 VRF instances (L3VPNs).

307. The offered Core Router shall support minimum 15 Mpps forwarding capacity.

308. The offered Core Router shall support minimum 1.000 GRE Tunnels.

309. The offered Core Router shall support operating temperature 5°C to 40°C and

operating altitude up to 2000 mt.

310. The offered Core Router shall support operating humidity 10 to 85%.

311. The offered Core Switches shall be mountable in standard 19’’ data cabinets. Tender

shall provide all rack mount equipment.

312. The bidder shall offer equipment with minimum 3 years support packets.

Core Switch (Quantity 2)

The Core Switch shall provide a resilient infrastructure capable of meeting the performance,

functional and capability criteria set out within this specification as well as being scalable to

meet expansion requirements. The Core Switch will operate 24 hours a day, 365 days a year.

The proposed Core Switch shall allow an maintenance to be performed without interruption

to the operation of the systems / applications transported across it.

Core Switches will be installed with VSS ( Virtual Switching System ), VCS (Virtual Chassis

Stack ) or similar technology.

The Core Router, Core Switches, Data Center Core and ToR Switches shall come from the

same vendor units. The bidder must provide the equipments with all necessary licenses

depends on the following technical specifications:

313. The offered Core Switches shall have minimum 40 ports 10 GBase-X. Tender should

provide solution for 80 ports 10 GBase-X totally.

314. The offered Core Switches shall support 10GBase-SR, 10GBase-LR, 10GBase-ER,

1000Base-T, 1000Base-LX, 1000Base-SX SFP Modules. These modules must be hot

swappable.

315. Each Core switch must have minimum 24 1000Base-T GBIC modules.

316. The offered Core Switches fans and power supply units must be redundant and hot

swappable.

317. The Offered Core Switches shall support AC and DC Power Supply Units. Tender shall

offer with AC Power Supplies.

318. The offered Core Switches shall provides minimum 800 Gbps switching and 250 Mpps

Throughput capacity.

319. The offered Core Switches must have minimum 32.000 MAC address table capacity.

320. The offered Core Switches must have IPv4 and IPv6 routing capacity.

321. The offered Core Switches shall support minimum 4.000 VLANs.

322. The offered Core Switches shall support minimum 10.000 IPv4 Routes.

323. The offered Core Switches shall support minimum 4.000 Multicast Routes.

324. The offered Core Switches shall support minimum 1.000 IPv6 Routes.

325. The offered Core Switches shall support minimum 9.000 byte MTU Jumbo Frames.

326. The offered Core Switches shall support minimum 8.000 ARP entries.

327. The offered Core Switches shall support IEEE 802.1Q Vlan Trunking Protocol.

328. The offered Core Switches shall support UDLD (Uni-Directional Link Detection) or

similar protocol.

329. The offered Core Switches shall support RIPv2, OSPFv2 and BGP IPv4 routing

protocols.

330. The offered Core Switches shall support RIPng, OSPFv3 and BGP IPv6 routing

protocols.

331. The offered Core Switches shall support Multicast PIM Sparse Mode and Source

Specific Multicast.

332. The offered Core Switches shall support VSS (Virtual Switching System), Virtual

Chassis Stacking (VCS) or equivalent redundancy system. Tender shall provide all

equipment and licenses.

333. The offered Core Switches shall support VRRP or equivalent gateway redundancy

protocol.

334. The offered Core Switches shall support IEEE 802.1d “ Spanning Tree “ , IEEE 802.1s

“Multiple Spanning Tree”, IEEE 802.1w “Rapid Reconvergence “ protocols.

335. The offered Core Switches shall support 802.3ad LACP (Link Aggregation Control

Protocol) and Link Aggregation groups ( LAGs ).

336. The offered Core Switches shall support port security and IEEE 802.1x user

authentication standard.

337. The offered Core Switches shall support Layer 2 Mac Address, Layer 3 IP address and

Layer 4 UDP and TCP based Access Control Lists.

338. The offered Core Switches shall support Private VLAN isolation functions.

339. The offered Core Switches shall support Neighbour Learning Functions (Automatically

discover connected switches).

340. The offered Core Switches shall support BPDU Guard, BPDU Filter and Root Guard or

equivalent functions.

341. The offered Core Switches shall support AAA ( Authentication Authorization

Accounting ) using local database, RADIUS and TACACS+

342. The offered core switches shall support SSHv1 and SSHv2 connections.

343. The offered Core Switches shall support DHCP Server, DHCP Relay Agent, DHCP

Snooping and DHCP Snooping Option 82 functions.

344. The offered Core Switches shall support FTP and TFTP file transfer protocols.

345. The offered Core Switches shall support SNMPv1,v2,v3 protocols.

346. The offered Core Switches shall support SPAN, RSPAN and RMON.

347. The offered Core Switches shall support NetFlow or sFlow protocols.

348. The offered Core Switches shall support minimum 8 queues per port.

349. The offered Core Switches shall support L2, L3 QoS (Quality of Service) and Rate

Limiting functions.

350. The offered Core Switches shall support Differentiated Services Code Point (DSCP), IP

Precedence marking. IEEE 802.1p CoS (Class of Service).

351. The offered Core Switches shall be managed via CLI Console Port, Telnet and SSH

access. HTTP GUI Web interface is preferable.

352. The offered Core Switches shall support NTP Client and NTP Server functions.

353. The offered Core Switches must have minimum one USB Port for operating system

and log files. The bidder shall provide minimum one USB Flash Disk.

354. The offered Core Switches must have minimum the following EMI and EMC

Standards:

EN5522 Class A

EN 55024

EN 300386

355. The offered Core Switches must have minimum the following safety certifications:

UL 60950-1

CAN/CSA-C22.2 No.60950-1

356. The offered Core Switches shall support operating temperature 0°C to 40°C and

operating altitude up to 3000 mt.

357. The offered Core Switches shall support operating humidity up to 90%.

358. The offered Core Switches shall be mountable in standard 19’’ data cabinets. Tender

shall provide all rack mount equipment.

359. The bidder shall offer minimum 3 years support packets.

Data Center Top of Rack (ToR) Switch (Quantity 15)

The Data Center ToR Switch shall provide a resilient infrastructure capable of meeting the

performance, functional and capability criteria set out within this specification as well as

being scalable to meet expansion requirements. The Data Center ToR Switch will operate 24

hours a day, 365 days a year. The proposed Data Center ToR Switch shall allow an

maintenance to be performed without interruption to the operation of the systems /

applications transported across it.

The Core Router, Core switches, Data Center Core and ToR Switches shall come from the

same vendor units. ToR Switches shall connect to the Core Data Center Switches via 10 Gb

Fiber Optic ports. The bidder must provide the equipments with all necessary licenses

depends on the following technical specifications:

360. The offered Data Center ToR Switch shall provide minimum 32 port 1/10 Gbps

connection.

361. The offered Data Center ToR Switch shall provide minimum 8 port 2/4/8 Gbps Fiber

Channel ports.

362. The offered Data Center ToR Switches should be 1 RU.

363. The offered each Data Center ToR Switch must have minimum 24 1000BaseT ports or

modules.

364. The offered each Data Center ToR Switch must have minimum 2 10 Gb SR modules.

365. The offered Data Center ToR Switch shall support minimum 160 gbps full duplex

fabric speed and minimum 560 Gbps forwarding or 595 Mpps performance.

366. The offered Data Center ToR Switches must have redundand and hot swappable

power supply units and fans.

367. The offered Data Center ToR Switches SFP/GBIC modules shall be hot-swappable.

368. The offered Data Center ToR Switches shall support 1/10 Gigabit Ethernet ports

SFP/SFP+ (Supported transceiver and cables include Twinax SFP-H10GB-CU1M, SFP-

H10GB-CU3M, SFP-H10GB-CU5M, SFP-H10GB-ACU7M, and SFP-H10GB-ACU10M, include

SFP+ SFP-10G-SR, SFP-10G-LR, and include SFP GLC-T, GLC-SX-MM, GLC-LH-SM, SFP-GE-T,

SFP-GE-S, SFP-GE-L).

369. The offered Data Center ToR Switches shall support Front-to-Back and Back-to-Front

Air Flow capability. Tender shall offer Front-to-Back Air Flow cooling.

370. The offered Data Center ToR Switches shall support AC and DC Power Supply Units.

Tender shall offer AC Power Supply units.

371. The offered Data Center Core Switches shall be mountable in standard 19’’ data

cabinets. Tender shall offer all rack mount equipment.

372. The offered Data Center Core Switches shall support operating temperature 0°C to

40°C and operating altitude up to 3000 mt.

373. The offered Data Center Core Swıtches shall support operatıng humidity 5% to 90%.

374. The offered Data Center Core Switches must have minimum the following safety

certifications:

UL 60950-1 Second Edition

CAN/CSA-C22.2 No.60950-1

375. The offered Core Switches must have minimum the following EMI and EMC

Emissions:

EN5522 Class A

AS/NZS CISPR22

376. The bidder shall ofer equipments witth minimum 3 years support packets.

Data Center Core Switch (Quantity 2)

The Data Center Core Switch shall provide a resilient infrastructure capable of meeting the

performance, functional and capability criteria set out within this specification as well as

being scalable to meet expansion requirements. The Data Center Core Switch will operate

24 hours a day, 365 days a year. The proposed Data Center Core Switch shall allow a

maintenance to be performed without interruption to the operation of the systems /

applications transported across it.

The Data Center Core Switch shall collect Top of Rack ( ToR ) switch connections. Each ToR

and Data Center Core Switch connection shall be minimum 10 Gbps.

The bidder shall offer solution with capability of minimum 16 ToR connections per Data

Center Core Switch.

The Core switches, Data Center Core and ToR Switches shall be the same vendor units. The

bidder must provide the equipments with all necessary licenses depends on the following

technical specifications:

377. The offered Data Center Core Switches shall provide minimum 48 port 1/10 Gbps

connection.

378. The offered Data Center Core Switches shall provide minimum 12 port 2/4/8 Gbps

Fiber Channel ports.

379. The offered each Data Center Core Switches must have minimum 16 10 Gb SR

modules.

380. The offered each Data Center Core Switches must have minimum 16 1000Base-T

ports or modules.

381. The offered each Data Center Core Switches must have minimum 8 2/4/8 Gbps Fiber

Channel modules.

382. The offered Data Center Core Switches shall support minimum 1.2 Tbps Layer 2

forwarding and minimum 160 Gbps Layer 3 performance.

383. The offered Data Center Core Switches shall support minimum 240 Mpps Layer 3

performance.

384. The offered Data Center Core Switches must have redundant and hot swappable

power supply units and fans. Tender shall ofer equipment with AC Power Supply’s.

385. The offered Data Center Core Switches SFP/GBIC modules shall be hot-swappable.

386. The offered Data Center Core Switches shall support VSS, VCS, VPC or similar

technology.

387. The offered Data Center Core Switches shall support Front-to-Back and Back-to-

Front Air Flow capability. Tender shall offer Front-to-Back Air Flow cooling.

388. The offered Data Center Core Switches will have USB port for USB Flash disk. Tender

shall provide USB Flash disk.

389. The offered Data Center Core Switches shall support minimum 32.000 MAC table

capacity.

390. The offered Data Center Core Switches shall support minimum 16.000 IPv4 Routes.

391. The offered Data Center Core Switches shall support at least 4.000 VLANs.

392. The offered Data Center Core Switches shall support minimum 16 way ECMP (Equal

Cost Multipath).

393. The offered Data Center Core Switches shall support Link Aggregation Control

Protocol (LACP): IEEE 802.3ad; Storm control (unicast, multicast, and broadcast);

functions.

394. The offered Data Center Core Switches shall support Spanning-Tree protocol STP

IEEE 802.1D; Rapid Spanning-Tree protocol RSTP IEEE 802.1W; Multiple Spanning-Tree

Protocol MSTP IEEE 802.1S.

395. The offered Data Center Core Switches shall support IEEE 802.1Q: VLAN tagging

protocol on trunk ports.

396. The offered Data Center Core Switches shall support minimum 9.000 byte Jumbo

Frames on all ports.

397. The offered Data Center Core Switches shall support BPDU Guard and Root Guard

functions.

398. The offered Data Center Core Switches shall support Storm control (unicast, multicast

and broadcast), port error dissable, and auto-recovery functions.

399. The offered Data Center Core Switches shall support Private Vlan function.

400. The offered Data Center Core Switches shall support Static Routing, RIPv2, OSPFv2

and BGPv4 IPv4 routing protocols.

401. The offered Data Center Core switches shall support VRRP (Virtual Router

Redundancy Protocol) or similar protocols.

402. The offered Data Center Core Switches shall support Internet Group Management

Protocol IGMPv2v3 and IGMP Snooping.

403. The Offered Data Center Core Switches shall support PIM Sparse Mode, Multicast

Source Discovery Protocol MSDP and Source Specific Multicast SSM.

404. The offered Data Center Core Switches shall support DHCP Relay, DHCP Snooping

with option 82 and Dynamic ARP Inspection.

405. The offered Data Center Core Switches shall support port based and vlan based

Access Control Lists.

406. The offered Data Center Core Switches shall support Layer 2 MAC based, Layer 3 IP

based and Layer 4 TCP or UDP based Access Control Lists.

407. The offered Data Center Core Switches shall support AAA ( Authentication

Authorization Accounting) with RADIUS and TACACS+.

408. The offered Data Center Switches shall support SNMP v1v2v3.

409. The offered Data Center Core Switches shall support Layer 2 IEEE 802.1p (CoS) and

minimum 8 hardware queues per port.

410. The offered data Center Core Switches shall support ACL-based QoS classification

(Layers 2, 3, and 4).

411. The offered data Center Core Switches shall support Strict Priority Queuing (LLQ).

412. The offered data Center Core Switches shall support RMON.

413. The offered Data Center Core Switches shall support 1000BASE-T SFP; 1000BASE-SX

SFP; 1000BASE-LX SFP; 8/4/2/1-Gbps Fibre Channel SFP. These modules must be hot

swappable.

414. The offered Data Center Core Switches shall support 10GBASE-SR, 10GBASE-LR,

10GBASE-ER modules. These modules must be hot swappable.

415. The offered Data Center Core Switches shall be managed via Console port,

Management port, Telnet, SSHv2.

416. The offered data Center Core Switches shall support NTP Network Time Protocol.

417. The offered Data Center Core Switches shall be mountable in standard 19’’ data

cabinets. Tender shall offer all rack mount equipment.

418. The offered Data Center Core Switches shall support operating temperature 0°C to

40°C and operating altitude up to 2000 mt.

419. The offered Data Center Core Swıtches shall support operatıng humidity 5% to 90%.

420. The offered Data Center Core Switches must have minimum the following safety

certifications:

UL 60950-1 Second Edıtıon

CAN/CSA-C22.2 No.60950-1

421. The offered Core Switches must have minimum the following EMI and EMC

Emissions:

EN5522 Class A

AS/NZS CISPR22

422. The bidder shall offer equipment with minimum 3 years support packets.

ToR Switch ToR Switch ToR Switch ToR Switch

Data Center Core Switch 1

Data Center Core Switch 2

10 G

b

10 Gb

10 Gb

10 Gb 10 Gb

10 Gb

10 Gb10 Gb

1 Gb

10 G

b 1 G

b2/

4/8

FC

10 G

b

1 G

b1

Gb

1 G

b

10

Gb

2/4

/8 F

C

Figure – Datacenter Switch Connections

Datacenter Firewall

The Bidder has to support firewall to protect the NMS, and other network elements and

should also provide secure access/ connectivity for the remote users. The firewall shall be

supplied with 1+1 redundancy to avoid single point of failure.

The firewall shall support the following features. Any deviation shall be treated as “Change

of Substance”.

423. The firewall should protect the NMS and BSS network and also provides secure

access/connectivity for the remote users.

424. The firewall system must be high available and Active/Active or Active/Standby

redundancy shall support.

425. The system shall provide Failover Port connectivity between Primary and Secondary

Firewall.

426. The firewall shall support at least 3Gbps IPS throughput capacity.

427. The firewall shall support at least 2 Million concurrent sessions.

428. The firewall shall support at least 125.000 connections per second performance.

429. The firewall shall support at least 2 Gbps 3DES/AES VPN throughput.

430. The firewall shall support at least 8-port 10/100/1000 and 2-port 10 GE (SFP+)

interface.

431. The firewall shall support dual power supplies for redundancy.

432. The firewall shall support SSL in addition to IPSEC based VPN. VPN user session can be

reach to 10.000 user.

433. The system shall provide flexible access-control capabilities for more applications,

services, and protocols, with the ability to define custom applications and services.

434. The system should support AAA services via RADIUS, with support for redundant

servers for increased AAA services resiliency

435. The firewall shall also support native IPv6 network environments and applications.

436. The firewall shall support SSHv2, telnet, HTTP/HTTPS, and ICMP-based management.

437. The system support dynamic, static, and policy-based NAT, and PAT services.

438. The system shall support SNMP MIB for VPN flow statistics including tunnel uptime,

bytes/packets transferred, etc.

439. The system shall support H.323 NAT Traversal.

440. The firewall shall support minimum 10Gbps stateful Inspection throughput capacity.

Requırements for network management system

The system should include a centralized Network Management System (NMS) for proper

operation and maintenance of all the systems covered by this purchase.

The NMS shall include all necessary hardware and software to be installed on a complete

turn-key basis including design, installation, testing and commissioning. The NMS shall have

the following characteristics:

Server System

441. Each of the Server Terminal shall be from internationally reputed Brand and

complete in all aspects to work as PC and shall be equipped with LCD Monitors (at least

17” wide), Hard Drive (at least 3 TB), RAM (at least 32 GB,) DVD Drive and Sufficient

numbers of USB-2 Ports (at least 4), Optical USB Mouse. The operating voltage should be

230 V AC ± 10%, 50 Hz. Servers should have a redundant power supply. Servers should

support RAID configuration.

442. The bidder shall supply O&M and service terminals at designated premise as per

following requirement:

a) O&M Control Console

b) Alarm Management Console

c) Device Configuration Console

d) Performance Console

e) CDR Management and Accounting

443. The bidder shall supply Monitoring terminals at designated Premise as per following

requirement:

a) O&M Control Console

b) Alarm Management Console

c) Device Configuration Console

d) Performance Console

e) CDR Management and Accounting

f) Reporting Module

Wide Screen Display Panel

444. The supply shall include a Wide Screen LCD Panel of the connected network and the

screen shall be mounted on wall. The screen shall

a) Show the real-time alarm status of the related nodes by easily distinguishable color

scheme.

b) The screen shall show different measurement and operational data in graphical

format provided by the NMS system.

c) The display screen should be rugged and industrial nature and should be able to work

24/7 in the required environmental condition specified.

d) The screen shall be of high graphics resolution.

Laser Printer

445. The supply shall include at least 3 (Three) numbers of Printer having following

specifications for each lot connected in the LAN of the NMS.

a) Resolution : 600 X 1200 pixels Minimum

b) Pages per minute : Minimum 32

c) Memory : 32 MB

d) Paper Tray : Three trays, one of 100-Sheets and two of 500-sheets

e) Network Interface Card : 10/100 base - TX

f) Paper size : A3/A4/ Legal/Letter

g) Spare cartridge : 3 (Three)

h) Software Driver : 1 (One) Set

i) Product Documentation : 1 (One) Set

Inverters

446. The supply shall include necessary inverters for all equipment of the NMS, if needed.

Software Requirements of NMS

Software Capability

447. The software(s) shall be modular in structure and shall be capable of merging new

files and programs with existing files at the site without any interruption of service in the

following cases. Deviation form such capability shall be considered as “Change of

Substance”.

a) Expansion or change of MGW capacity

b) Loading of new software patches or changes of program version

c) Changes and employment of new service features and facilities

d) Permanent or temporary withdrawal of any existing hardware

e) Changing of any hardware for maintenance or up-gradation purpose

Password Protection

448. The main features and data of the software shall be protected by multi-level

password control. Modification of the Network data and Subscriber configuration data

shall also be protected by passwords. The system password will not be erased or

corrupted during system reboot and/ or redundant server switchover or for any other

reasons.

Immunity against propagated faults

449. All modules of the Software shall be immune against propagation of faults from any

other software or hardware modules and shall be protected against any mutilation of

data. The faulty software module shall also not propagate its own fault to any other

software or any hardware modules.

450. Records of all executed commands shall be kept in log files and these files shall be

stored in system hard disk.

System and Alarm Messages

451. The software shall be capable of recognizing different system degradation, alarm and

fault conditions and generate appropriate spontaneous messages. The relevant output

messages must be in Azerbaijanese and English.

Functional Requirements of NMS

452. The NMS shall have the capability to support the following management functions for

all elements:

a) Fault Management b) Configuration Management c) Performance Management d) Security Management

453. All the management functionalities shall be implemented in the NMS as a set of

interactive application components using client-server architecture and can be vertically

and horizontally integrated.

454. The NMS should support the following:

a) Graphical Unit Interface (GUI)

b) Real-time alarm display and collection

c) Card/circuit level diagnosis

d) Interface line status monitoring, both subscriber lines and network interface.

e) Performance monitoring and traffic measurement.

f) Network/NE configuration management.

g) Routing table management

h) SNMP-based network management interface(s) to support third party network

management system.

i) Implementation of software patches and releases on the NGN nodes remotely.

Basic Features and Capabilities

455. The NMS shall provide:

a) Preferably a single Application Program Interface (API) for requested network

elements regardless of Brand and Model.

b) Automatic copy of configurations at device, cards, and ports level to the customer

information database system within the NMS.

c) Network Integrity check at the network, device, card, and port levels.

d) End to end path management.

e) Advance alarm management setting for priorities and types.

f) Multiple network managers support with different access authorities.

g) Network element status displayed by colors.

h) Graphical User and user-friendly interface with online help.

i) Identification of problems through event correlation. It should intelligently correlate

events into high level alarms, immediately pinpointing the root cause of network

problems.

j) Web-based user interface

Fault/Alarm Management

456. The NMS shall support (but not limited to) the following fault and alarm management

capabilities:

a) Detected errors/unusual network behavior should be isolated and controlled.

b) Results of errors/unusual network behavior should be displayed in graphical and

tabular form.

c) Alarm facilities should permit the easy identification and correction of faulty element.

d) Alarms should have a status of active, deferred, or cleared and should be in active

state when first received.

e) The severity of the alarm, full alarm message and time of delivery should be available

for display and are logged in the alarm database.

f) The administrator should be able to set various thresholds for alarm reporting,

including filtering by severity, number of occurrences within a given period and interval

between occurrences.

g) SNMP, Corba and/or XML/SOAP technologies should be used for the communication

of Management System with other management systems.

h) Fault deduplication in order to find root cause of the alarms and correlation rules

between switch alarms.

i) Recsynchronization process with 3rd party OSS systems, in order to process the alarms

on a connection failure.

k) User can add 'description' information on an alarm on Management system.

l) Management system should support resycnronization on a single alarm.

Configuration Management

457. The Configuration Management should initialize and close down manage objects,

collect information on demand about the current condition of the network, obtain

announcements of significant changes in the condition of the network, and change the

configuration of the Network and the Network Elements.

458. The NMS should support the following configuration management capabilities:

a) Complete configuration of all network devices, cards, and ports for connection

establishment and complete control of the network.

b) Graphical User Interface for configuring all system devices, cards, and ports.

c) Web-based Graphical User Interface for remote configuration management for all

system devices, cards, and ports.

d) The NMS should have an automatic backup configuration facility

Performance Management

459. The NMS should support, but should not be limited to the following performance

management capabilities:

a) Monitor network throughput and real-time Bit Error Rate must be supported.

b) Set thresholds for various variables, such as error rates or link utilization.

c) Continuous background diagnostics during system uptime are required for early

detection of fault conditions and timely activation of alarms.

d) Log and save all or defined events for present and future reference.

e) All man-machine interfaces shall be in a Graphical User Interface.

Security Management

460. The NMS should support (but not limited to) the following security management

capabilities:

a) Secure access between network elements and the network manager.

b) The system should incorporate security measures against unauthorized personnel to

access the office data/programs and entering of commands.

c) Several access levels according to the order of their influence on program

performance should be identified with the corresponding password.

Requırements monthly based fraud management servıce

1. SIM Box detection service should include a limitless number of countermeasures to

avoid that fraudsters detect the test calls. Following countermeasures are included

and will be customized and optimized in accordance with the specific situation in the

country:

A number rotation

B number rotation

Virtual number management up to 10 000 numbers

SIM Box Gun

Creation of realistic Answer To Seizure ratio (Pick up of at least 60 % on all Carrier routes, highly affected with SIM Boxes)

Human behavior calling

2. A dedicated Interconnect and Fraud consultant should be assigned to the ISS project.

Following services should be included in the full service model:

In depth customer dedicated analysis and daily follow up of your account

Trend analysis by your dedicated coordinator

Choice between English – French – Spanish or Portuguese speaking contact person

Answer to your questions within 24 hours (Weekdays)

3. To detect off-net SIM Boxes, two other mobile operators should be included in the

testing (optional). The provider should use a limited amount of test calls towards

each competitor. Tests will be distributed between on-net and off-net, based on the

results.

4. At the end of each monthly testing period, the provider should generate a detailed

report containing all relevant information. After having sent out the monthly report,

the dedicated Customer Service Engineer should guide through the report during a

conference call.

5. At the end of a 12 month testing period the provider should generate a detailed

overview report of all previous testing periods, the results of the past year and year

to date evolutions. This report should allow to review the results after one year

cooperation and the evolution on the bypass situation on the network.

6. The provider should provide a detailed monthly report with Interconnect Quality of

Service parameters and extended fraud issues. Following parameters should be

reported within the Interconnect QoS report:

False Answer

Early Answer

Late Disconnect

CLI Transparency

Call Setup Time (CST)

Network information

7. The provider should provide, maintain and manage all necessary equipment during

the entire contract. The equipment should be installed at a collocation facility with

Public IP and professional housing foreseen by the provider. The probe will be

shipped by the provider within 6 weeks after reception of the Purchase Order.

Monitoring: The offeror activities will be supervised by project staff guided by NDP

Programme Advisor and National Project Manager in order to ensure that they are on

schedule in meeting the objectives, deadlines and performance targets of the assignment.

Training: The Vendor will have to plan a training strategy and train the associates of the end

user on how to use the switching system. The beneficiary will provide the list of trainees to

the successful vendor.

Deliverables:

Deliverables Timining

Deliverable 1: Installation and testing of class 4 infrastructure for protecting the network, call routing controlling, call processing and transcoding: Session Border Controller (SBC as I-BGF&IBCF, MRFC) • Class 4 Softswitch (as TrF, MGCF, MRFC, MRFP) • Trunking Media Gateway (as MGW,SGW,MRFP) • Installation and Testing

February, 2014

Deliverable 2: Installation and testing of

security switching and data center facilities:

• Firewall (FW) • Core Routers • Core Switches • Data Center Switches • Data Center ToR Switches • Installation and Testing

March,2014

Deliverable 3: Installation and testing of

operational support system:

• NOC Monitoring Dashboard

April, 2014

• Network Management System (NMS) • Number Portability Solution (NP) • Installation and Testing

Deliverable 4: Installation and testing of

Routing and Billing System:

• Installation and Testing

May, 2014

Deliverable 5: Installation and testing of Fraud

Management System as a Professional Service:

• Installation and Testing

June, 2014

Deliverable 6: Providing trainings for 5 (five)

associates of the end user on how to use the

switching system

June, 2014

Deliverable 7: After-sales service (technical

support) / Warranty on parts and services

Three years starting from the succesfull

delivery and installation of ISS

Qualifications:

Experience in IP based ISS projects as well as data center construction and

installation of DC equipment in Azerbaijan and abroad (please list the projects for DC

construction and installation of DC equipment);

Ability to deliver the services described in this ToR on an ongoing and consistent

basis;

Consistent processes of interaction within the company;

Overall capabilities and compatibility with the Project’s requirements during the

whole cooperation period;

Competitive quality and performance guarantees;

Ability to comply with the requirements of Azerbaijan law, clients' recommendations

(interested in those customers which were provided with the services on data center

construction and installation of required equipment);

Availability of formal employment relations of the firm with its employees and

personnel stability;

Highly professional management;

A list of customers for which such services were rendered;

Competitive pricing;

Professional liability insurance;

Firm's flexibility during negotiations;

Taking responsibility for the opportunity of going through project proposals offered

by the company as well as resolutions of the construction expertise body.

Evaluation of performance:

Validation of extent of compliance to the RFP requirements and evaluation criteria

based on what has so far been found by the evaluation team;

Inquiry and reference checking with Government entities with jurisdiction on the

bidder, or any other entity that may have done business with the bidder;

Inquiry and reference checking with other previous clients on the quality of

performance on ongoing or previous contracts completed;

Testing and sampling of completed goods similar to the requirements of UNDP,

where available; and

Warranty: The Company shall warrant that the goods supplied under the Contract are new, un-used, of the most recent or current models and incorporate all the latest improvements in design and materials unless provided otherwise in the Contract. The Company shall further warrant that all goods supplied under this Contract shall have no defect arising from design, material or workmanship or from any act or omission of the Company that may develop under normal use of the supplied goods in the conditions prevailing in the country of final destination. The Company shall ensure that the selected equipment hardware and software shall not be at End of Life for the prevailing 4 years and End of support for the prevailing 8 years after FAC. Project shall promptly notify the Company in writing of any claims arising under this warranty. Upon receipt of such notice, the Company, with all reasonable speed replaces the defective goods or part thereof, without any costs to Project including the cost of inland delivery of the repaired replace goods or parts from the port of entry to final destination. If the Company, having been notified, fails to remedy the defect(s) within a reasonable period, Project may proceed to take such remedial actions as may be necessary, at the Company's risk and expense and without prejudice to any other rights which Project may have accrued or will accrue to Project against the Company under the Contract. The repair/replacement shall include the hardware, parts and components maintenance, all software upgrade, patch serving and technical support. The Company shall maintain an emergency On-call team of skilled technicians / engineers equipped with necessary tools round the clock for the emergency fault calls. The Contractor shall be responsible to maintain a ticketing system for each incidence recording the work done at each visit and get it verified by the Purchaser. All defects, replacement of parts, work done etc. shall be recorded. A proper Fault Escalation process will be defined with clear responsibilities and physical names, phone numbers, e-mails and title in the organization The Company shall provide full support during and after the warranty period including the technical support with reporting time, hardware and spare parts as well as components

replacement in case of failure and upgrade of new firmware and patches. Company should offer a solution and providing after sales technical support through maintenance

and service level agreements.

The repair/replacement shall include the hardware, parts and components maintenance, all software

upgrade, patch serving and technical support.

The manufacturer shall repair or replace without charge, manufactured products proven defective in

material or workmanship for the stated warranty period from the date of shipment