IN911 RFS for Wireless E911 and i3 Network Services

Pre-bid Meeting

August 13, 2014

Joel McCamley, ENPJim Lockard, PMP, ENP

Contents of Attachment D – Technical RFSSECTION 1 GENERAL REQUIREMENTS SECTION 2 IN911 ESINET REQUIREMENTS SECTION 3 IN911 SPECIFIC REQUIREMENTS SECTION 4 I3 NETWORK SERVICES REQUIREMENTS SECTION 5 SERVICE AND SUPPORT REQUIREMENTS SECTION 6 SYSTEM REPORTING REQUIREMENTS SECTION 7 MONITORING AND MAINTENANCE REQUIREMENTS SECTION 8 TRANSITION AND TESTING REQUIREMENTS SECTION 9 ELECTRICAL, WIRING, AND CABLE REQUIREMENTS SECTION 10 PROJECT PLANNING REQUIREMENTS SECTION 11 APPENDIX

SECTION 1 GENERAL REQUIREMENTS• 1.1 RESPONSE INSTRUCTIONS 3• 1.2 PURPOSE OF THIS PROCUREMENT 3• 1.3 PROJECT OVERVIEW 4• 1.4 SCOPE OF SERVICES 6• 1.5 IN911 BACKGROUND 7• 1.6 STANDARDS 17• 1.7 OPEN STANDARDS 18• 1.8 COST AND PRICING 18

1.2 Purpose of this procurement• Indiana statute IC-36-8-16.7-27(b) requires that the IN911 Board seek

competitive bids from qualified vendors to provide integrated network services for the operation of the IN911 Network currently serving the PSAPs of Indiana. Indiana is currently served by an IP-based network known as IN911.

• The purpose of this procurement is to ensure that at a minimum, the current services provided by the existing IN911 Network are continued and improved upon as technology, standards, and societal demands evolve.

• The IN911 Board invites qualified vendors with documented expertise and experience to submit proposals to provide wireless E9-1-1 call delivery, i3 ESInet Network Services, reporting, monitoring, service and support for the operation of the IN911 Network.

This RFS does not include PSAP CPE, PSAP call taking equipment, furniture, computers or other operational systems required by PSAPs.

It is focused only on the services required for the operation of the IN911 Network and the services it provides to Indiana PSAPs.

Proposing a Solution or Solutions• The solution(s) and services sought through this RFS may be proposed as an

integrated, comprehensive solution, or as a stand-alone component representing a best in class service offering capable of being integrated with other components that will comprise the IN911 ecosystem.

• The Board may, at its discretion, integrate proposed solutions or components of proposed solutions in order to achieve an enterprise-wide, state-wide, best in class system that benefits all Indiana PSAPs and best serves the Board in fulfilling its duties under the law.

• The Board would prefer an integrated solution with a designated primary vendor contractually responsible for providing the services as specified in this RFS.

• The Board may, at its discretion, designate a contractual prime vendor and require contractual relationships, cooperative agreements, interconnection to and interaction with other system service providers or third parties as required or necessary for the operation of IN911.

1.4 Scope of ServicesThe services sought by this RFS include:

1. ESInet network design, management, and operation services2. NG, i3 core functions and capabilities3. Wireless E911 call routing and reporting services4. Text to and from 911 services5. Enterprise/State-wide data collection and reporting services on all IN911

facilitated transactions 6. System and component level monitoring, alarming, diagnostics and reporting

services7. Disaster recovery and system restoration services8. 24/7/365 Help desk, trouble ticketing and customer facing support services9. 24/7/365 Network operations center (NOC) monitoring services10. Installation, testing, maintenance and on-site support services11. Project management services for the planning, design, testing, installation and

operation of the system or systems

IN911 Current System Overview

Due to the critical nature of operational specifics regarding the capabilities and operation of IN911, additional details

and information related to the current IN911 design, configuration, capabilities, connections and operations will

be shared with Respondents deemed qualified after the initial receipt of proposals to this RFS.

PrivateIP network statewide ESInet

core router

DNS

BCF

wireless device

legacy PSAP (B)

public calleroriginating

service provider9-1-1 system service provider ESInet (prime) other 911 SSPs

Emergency Services IP Networks (ESInet)NG PSAPs or legacy PSAPs

ESRP

This diagram represents the G-11 structure of the IN911 network,which is in transition from legacy (i2) to a full NG9-1-1 i3 architecture.

PSAP router(PR / BCF)

PSTNdevice

LNG

legacy TDMcircuit switched

networks

legacyALI platforms and third party location

providers

LPG

NG ALI

i3 PSAP (A)

BCF

MEVOdisaster recovery

SIPCO switches

LNG

NG ALI

ESRP

legacyCO switchesLNG / LPG LNG / LPGcore router

core router

ECRF/LVF

Current Network Configuration (G-11 network)• Redundant SS7 networking, including IS-41 messaging to support

wireless carrier extended functions• Provides operational bandwidth from 3 megs to 1 gig (site and

application specific)• Uses Router Ethernet over SONET with tertiary backup connections• ESRP – dual geo-diverse ESRP’s in tandem mode, active / active• Each originating service provider has connectivity to diverse LNG’s.• LNG’s are dual homed with active routing to all ESRP’s• ESRP supports all i3 functions and ATIS TCC/MSRP for text routing• ECRF supports geospatial GIS call routing for all media types• ALI-db / legacy ERDB for transitional call routing

i3 functional elements in operation in IN911

• LNG - all are SS7 (or PRI) to IP, fully redundant with no common fault domains• LIS in the G-11 platform, this functional element is aliased by the NG-ALi platform• BCF - this is in service in the G-11 network• SIF in the G-11 platform, this functional element is aliased by the NG-ALi platform• ECRF - this is in production in the G-11 network• LVF - in the G-11 network, this functional element is aliased by the NG-Ali platform• ESRP - this is in production in the G-11 network• NG-ALI - not part of the i3 specification, but used to alias other FE’s in a transitional

E911 to NG911 configuration• LPG - this is in service in the G-11 network

PSAP Information• For the purposes of this procurement, the following number of PSAPs are

within the scope of this project and anticipated services.• There are 91 County level Primary PSAP’s in the state as two of the

counties operate in a consolidated facility (Fountain/Warren). • Additionally, there are six (6) Indiana State Police (ISP) Posts connected to

and served by IN911 as secondary PSAPs (calls transferred from a primary PSAP).

• For the purposes of this procurement, any solutions or services that require provisioning to a PSAP, the number of PSAPs to be considered will be 97 as explained and derived above.

• Specific address information for each of the 97 Indiana PSAPs covered by this RFS will be made available to qualified respondents as appropriate and necessary for the refinement of costs and designs of proposed solution(s).

1.8 Cost and Pricing• Cost estimates and pricing for proposed solutions must be provided using the

supplied Cost Proposal template (Appendix B). • NO COST or PRICING information is to be provided in the response to this

Appendix D – IN911 RFS Technical Specifications.• Estimated costs and pricing are to be expressed in one of two ways, as one-time

costs or as monthly recurring costs. Any one time costs must be amortized into the monthly recurring service fee over the initial term of the contract (6 years).

• The Board will be paying for the services provided on a monthly service fee basis.

• The Board will not be buying equipment, leasing physical infrastructure or be responsible for constructing or operating any portion of the proposed solution.

• Any and all costs proposed by respondents must ultimately be expressed as a monthly fee for services.

SECTION 2 IN911 ESINET REQUIREMENTS• 2.1 ESINET SERVICES 20• 2.2 ESINET ARCHITECTURE REQUIREMENTS 20• 2.3 ESINET NETWORK DIAGRAM(S) 21• 2.4 ESINET FEATURES AND FUNCTIONS 22• 2.5 NETWORK FAILOVER 27• 2.6 NETWORK SECURITY 27

ESInet Services

• The Board seeks network and operations services from a provider or a combination of providers to implement an Emergency Services IP-network (ESInet) to deliver or support the delivery of voice, text, or other emergency communications related data to the PSAP’s throughout Indiana and in the adjoining states of OH, KY and MI, or as may be designated by the Board.

• Respondents interested in providing ESInet services must design and provide an IP based network solution with the ability to connect and interconnect to other regional, state and potentially national emergency services networks (i.e. FirstNet).

• The proposed solution must at a minimum deliver the same functionality of the current IN911 system ESInet as detailed in Section 1 of the specification.

PrivateIP network statewide ESInet

core router

DNS

BCF

wireless device

legacy PSAP (B)

public calleroriginating

service provider9-1-1 system service provider ESInet (prime) other 911 SSPs

Emergency Services IP Networks (ESInet)NG PSAPs or legacy PSAPs

ESRP

This diagram represents the G-11 structure of the IN911 network,which is in transition from legacy (i2) to a full NG9-1-1 i3 architecture.

PSAP router(PR / BCF)

PSTNdevice

LNG

legacy TDMcircuit switched

networks

legacyALI platforms and third party location

providers

LPG

NG ALI

i3 PSAP (A)

BCF

MEVOdisaster recovery

SIPCO switches

LNG

NG ALI

ESRP

legacyCO switchesLNG / LPG LNG / LPGcore router

core router

ECRF/LVF

ESInet design requirements include but are not limited to:• The ESInet shall be designed to operate on a 24x7x365 basis and be configured to

minimize or eliminate any single point of failure where possible. • The ESInet shall be designed with a minimum level of bandwidth to support

delivery of calls and associated data from originating service providers or other integrated ESInets to the PSAPs.

• Availability, diversity, redundancy and resiliency shall be the guiding ESInet design principals

• The ESInet design shall support the ability to automatically reroute traffic to alternate routes or systems in order to avoid network outages and system failures.

• The ESInet shall be designed to support the automatic adjustment of traffic priorities in order to meet established QoS levels as defined in NENA 08-003

• The ESInet design shall support the ability to handle legacy 9-1-1 calls and ensure the capability of handling future call types.

2.3 ESInet Network Diagram(s) • Respondents shall provide Network Diagrams to support their

narrative that accurately displays how their proposed ESInet will be configured and deployed.

• The Network Diagrams shall display information about the core ESInet design, the configuration, the interconnections and the access network links so that the diagram can be used as a basis for evaluation and understanding.

2.4 ESInet Features and Functions • Respondents shall provide a narrative of their proposed ESInet with

enough detail to ensure proper evaluation, using appropriate diagrams and language that explains how the proposed ESInet solution is NG9-1-1 capable, supports current and evolving standards, and how it will accommodate the integration of other networks operated by other providers that comprise the IN911 ecosystem.

2.5 Network Failover• The proposed solution must contain a network failover function that

is capable of recognizing faults and automatically taking measures to avoid the fault.

2.6 Network Security• Respondents shall propose a solution that meets a minimum level of security as

defined by the national standards.• The Board requires that proposed solutions comply with the Federal Bureau of

Investigation (FBI) Criminal Justice Information Services (CJIS) Security policies.

SECTION 3 IN911 SPECIFIC REQUIREMENTS

• 3.1 SYSTEM SERVICE PROVIDER COORDINATION REQUIREMENTS 30• 3.2 INTERSTATE INTERCONNECTION REQUIREMENTS 30• 3.3 TEXT TO 9-1-1 REQUIREMENTS 30• 3.4 TEXT FROM 911 REQUIREMENTS 33

3.1 System Service Provider Coordination• Successful Respondents will be required to coordinate with other

service providers as necessary to operate a seamless solution in support of the operation of IN911.

• Respondents will need to enter into Interconnection agreements which legally allow the connectivity and interconnection with other networks as well as other service providers throughout Indiana.

• This includes but is not limited to LECs, CLECs, ILEC and all Wireless Carriers providing service in Indiana.

3.2 Interstate Interconnection Requirements

• Respondents must be capable of interconnecting with other SSPs in states other than Indiana.

• States currently interconnected to IN911 include:OhioMichiganKentucky

• The Board anticipates that future interconnections will be required with SSPs in Illinois.

• Respondents shall provide the Board with example agreements, relationships, licenses or other documents demonstrating Respondents legal ability to enter into such agreements in other states.

3.3 Text to 911 Requirements• The Board is looking for Respondents to provide a hosted solution for the processing of

text-to-9-1-1 messages on Respondents proposed ESInet.• The system shall support the delivery of 911 text calls to all participating PSAPs located

throughout Indiana.• Functionally the Board’s desire is to have emergency text messages (text-to-9-1-1) from

all wireless carriers aggregated from Respondents’ proposed solution and forwarded to the appropriate PSAP.

• Respondents proposed solution(s) shall aggregate incoming Short Message Service (SMS) text messages from the public through one interface to all Text Control Centers (TCCs) provided by wireless carriers/vendors

• Respondents proposed solution shall distribute the text message to the appropriate Public Safety Answering Point (PSAP) in the format required by that PSAP (web browser, TTY, Direct IP interface).

• Respondents proposed solution(s), through a distribution method, shall allow messages to be transferred between adjoining PSAPs (primary and secondary) that use a web-based browser or NENA i3 CPE interfaces.

3.4 Text FROM 911 Requirements• Respondents shall propose an ability for an outbound sms text

capability commensurate with the current Text FROM 911 capability that exists in IN911 today.

• PSAPs shall have the ability to create an outbound text message to a mobile number once that number has contacted the PSAP or has been provided to the PSAP for emergency response purposes.

• The Boards expectation is that the Text FROM 911 system will be configured over a similar platform as the Text TO 911.

• The requirements for each system must be coordinated in a manner that minimizes the processes a PSAP must engage for Text TO and FROM 911.

• Ability to initiate outbound texts via a user interface for all texts • Allow PSAP control

SECTION 4i3 NETWORK SERVICES REQUIREMENTS

• 4.1 I3 FUNCTIONAL REQUIREMENTS 33• 4.2 BORDER CONTROL FUNCTION (BCF) 34• 4.3 EMERGENCY CALL ROUTING FUNCTION (ECRF) 34• 4.4 EMERGENCY SERVICES ROUTING PROXY (ESRP) 36• 4.5 LEGACY NETWORK GATEWAY (LNG) 37• 4.6 LEGACY PSAP GATEWAY (LPG) 37• 4.7 LEGACY SELECTIVE ROUTER GATEWAY (LSRG) 38• 4.8 LOCATION VALIDATION FUNCTION (LVF) 38• 4.9 ALI DATABASE SERVICES 39• 4.10 DISASTER RECOVERY / BUSINESS CONTINUITY 39

4.1 i3 Functional Requirements• The proposed system shall be designed to meet the current i3

capabilities of the IN911 system and be expandable and adaptable to accept new payloads (such as Text, Pictures and Video) that may be necessary during the term of the contract.

• IN911 is configured to the NENA i3 functional standard and includes many of the necessary components to enable NG9-1-1.

regional ESInet

911 SSP / state ESInetPublic Access

IP Networkglobal ES

internetwork

core router

LIS DNS

BCFCRBCF

BCF

SIP/H.323(VoIP)clients

wireless device

ESRP

legacy PSAP (C)

public calleroriginating

service provider 9-1-1 system service provider ESInet (prime) ESInet (additional)

Emergency Services IP Networks (ESInet)NG PSAPs or legacy PSAPs

ESRP(Forest Guide)

LoSTECRF/LVF

ECRF/LVF

i3 PSAP (B)

BCF

This diagram represents a basic andTDM transitional NG9-1-1 architecture.

BCF

PSTNdevice

LNG

legacy TDMcircuit switched

networks

legacyALI platforms and third party location

providers

The objective is to demonstrate how a hiearchical distribution of functional elements facilitate a public caller’s ability to be routed to the proper PSAP.

LPG

NG ALI

i3 PSAP (A)

LIS

LIS

BCF

MEVOdisaster recovery

SECTION 5SERVICE AND SUPPORT REQUIREMENTS

• 5.1 CUSTOMER SUPPORT SERVICES 39• 5.2 HELP DESK 40• 5.3 TROUBLE HANDLING AND TICKETING REQUIREMENTS 40• 5.4 TRAINING 41

The current IN911 system utilizes the following procedures. Respondents may use this as a guide for their proposed system.Critical – Network outage• 1st Level Support – Within 15 minutes Continuous problem resolution/workaround effort• 2nd Level Support – within 2 Hours• 3rd Level Support – within 4 Hours or upon Customer request.Major – Service effecting• 1st Level Support – Within 15 minutes• 2nd Level Support – Within 4 Hours• 3rd Level Support – Within 24 Hours or upon Customer request.Minor – Non-service effecting• 1st Level Support – Within 30 minutes• 2nd Level Support – Within 1 business day• 3rd Level Support - Within 1 week or upon Customer request. Planned Maintenance/Informational – Software update, configuration.• 1st Level Support – Within 2 Hours• 2nd Level Support – Within 5 Business days• 3rd Level Support – Only upon Customer or Management request.

SECTION 6SYSTEM REPORTING REQUIREMENTS

• 6.1 REPORTING AND DATA COLLECTION SYSTEM REQUIREMENTS 42• 6.2 STATEWIDE STATISTICAL MONITORING 42• 6.3 OPERATIONAL REPORTING 43• 6.4 EVENT REPORTS 44• 6.5 LOCAL LOGGING RECORDER INTERFACE 44

6.1 Reporting and Data Collection System

• The Board requires enterprise wide reporting and data collection capabilities on all aspects of the IN911 ecosystem.

• This capability must be agnostic to provider, system or technology and must be able to collect reportable data on the operation of the IN911 system regardless of function, domain, service area or provider.

• Given that there may be multiple providers of components and systems that will comprise the IN911 ecosystem, the Board will entertain stand-alone proposals from vendors who can offer an enterprise wide, multi-vendor integratable solution to satisfy this requirement.

• Respondents may offer enterprise wide reporting as a component of their solution as well.

• The Board will not entertain proprietary, disparate or system specific reporting systems.

• Respondents must be prepared to provide or support the collection and integration of an enterprise wide reporting and data collection capability.

SECTION 7MONITORING AND MAINTENANCE REQUIREMENTS

• 7.1 MONITORING OF APPLICATIONS AND EQUIPMENT 44• 7.2 NETWORK OPERATIONS CENTER 45• 7.3 NOTIFICATION AND ESCALATION 45• 7.4 PERFORMANCE MONITORING 45• 7.5 ALARM CATEGORIES 46• 7.6 SCHEDULED MAINTENANCE 46• 7.7 MAINTENANCE SUPPORT LOGS 46

7.1 Monitoring of Applications and Equipment• Proposed solutions will require proactive monitoring of all system

components for operation, performance and fault conditions.• The proposed solution shall ensure that all alarms including

environmental status alarms are received and monitored in a Network Operations Center (NOC).

SECTION 8 TRANSITION AND TESTING REQUIREMENTS• 8.1 TRANSITION PLAN 46• 8.2 SYSTEM TEST PLAN 47

Respondents must provide a proposed transition plan for their systems or services in their response that address the following areas at a minimum:• Transition schedule including milestone dates for design, development,

testing and implementation phases necessary to achieve full operational readiness and cutover to full operation

• System testing approach• Site cutover approach• Contingency or roll back plans should implementation or integration failures

occur during the transition or cutover of the proposed systems or services• Identification of risks, dependencies or interdependencies that may impact

the transition to full operational status and cutover • Identification and definition of the ability to support a phased migration and

parallel operation with current IN911 operations

• The current master services agreement (MSA) for the operation of the current IN911 system anticipates and provides for a six (6) month transition period.

• It is strongly recommended that respondents plan for and operate within the allocated six (6) month contractual transition period to fully implement their proposed systems or services.

• Throughout this anticipated transition period, current IN911 wireless 9-1-1 call delivery, existing features, functions, capabilities and operations must not be limited or impacted in any fashion by the Respondents.

8.2 System Test Plan• System testing of any new implementations will be required prior to

the Board authorizing any cutover to full operational status and the commencement of payment for services.

• Respondents must anticipate and plan for all necessary system testing for each service, component, function, application or piece of equipment comprising the proposed solution.

SECTION 9 ELECTRICAL, WIRING, AND CABLE REQUIREMENTS• 9.1 ELECTRICAL 48• 9.2 ELECTRICAL INTERFERENCE 48• 9.3 WIRING AND CABLING 48• 9.4 GROUNDING 49

SECTION 10 PROJECT PLANNING REQUIREMENTS

• 10.1 IMPLEMENTATION PROJECT PLAN 50• 10.2 SERVICE MANAGEMENT PLAN 50