IN911 RFS for Wireless E911 and
i3 Network Services
Pre-bid Meeting
August 13, 2014
Joel McCamley, ENP
Jim Lockard, PMP, ENP
Contents of Attachment D – Technical RFS
SECTION 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
• 1.2
• 1.3
• 1.4
• 1.5
• 1.6
• 1.7
• 1.8
RESPONSE INSTRUCTIONS
PURPOSE OF THIS PROCUREMENT
PROJECT OVERVIEW
SCOPE OF SERVICES
IN911 BACKGROUND
STANDARDS
OPEN STANDARDS
COST AND PRICING
3
3
4
6
7
17
18
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 IPbased 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 Services
The services sought by this RFS include:
1.
2.
3.
4.
5.
ESInet network design, management, and operation services
NG, i3 core functions and capabilities
Wireless E911 call routing and reporting services
Text to and from 911 services
Enterprise/State-wide data collection and reporting services on all IN911
facilitated transactions
6. System and component level monitoring, alarming, diagnostics and reporting
services
7. Disaster recovery and system restoration services
8. 24/7/365 Help desk, trouble ticketing and customer facing support services
9. 24/7/365 Network operations center (NOC) monitoring services
10. Installation, testing, maintenance and on-site support services
11. 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.
public caller
originating
service provider
9-1-1 system service provider
SIP
CO switches
other 911 SSPs
NG ALI
DNS
Private
IP network
ESInet (prime)
LNG
ESRP
core router
BCF
LNG / LPG LNG / LPG
ECRF/LVF
legacy
CO switches
statewide ESInet
core router
LNG
NG ALI
core router
ESRP
PSAP router
(PR / BCF) BCF
LPG
wireless
device
legacy TDM
circuit switched
networks
MEVO
disaster recovery
PSTN
device
legacy
ALI platforms and
third party location
providers
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.
i3 PSAP (A)
legacy
PSAP (B)
Emergency Services IP Networks (ESInet)
NG PSAPs or legacy PSAPs
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 onetime 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
• 2.2
• 2.3
• 2.4
• 2.5
• 2.6
ESINET SERVICES
ESINET ARCHITECTURE REQUIREMENTS
ESINET NETWORK DIAGRAM(S)
ESINET FEATURES AND FUNCTIONS
NETWORK FAILOVER
NETWORK SECURITY
20
20
21
22
27
27
ESInet Services
• The Board seeks network and operations services from a provider or a
combination of providers to implement an Emergency Services IPnetwork (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.
public caller
originating
service provider
9-1-1 system service provider
SIP
CO switches
other 911 SSPs
NG ALI
DNS
Private
IP network
ESInet (prime)
LNG
ESRP
core router
BCF
LNG / LPG LNG / LPG
ECRF/LVF
legacy
CO switches
statewide ESInet
core router
LNG
NG ALI
core router
ESRP
PSAP router
(PR / BCF) BCF
LPG
wireless
device
legacy TDM
circuit switched
networks
MEVO
disaster recovery
PSTN
device
legacy
ALI platforms and
third party location
providers
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.
i3 PSAP (A)
legacy
PSAP (B)
Emergency Services IP Networks (ESInet)
NG PSAPs or legacy PSAPs
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
• 3.2
• 3.3
• 3.4
SYSTEM SERVICE PROVIDER COORDINATION REQUIREMENTS
INTERSTATE INTERCONNECTION REQUIREMENTS
TEXT TO 9-1-1 REQUIREMENTS
TEXT FROM 911 REQUIREMENTS
30
30
30
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:
Ohio
Michigan
Kentucky
• 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 (textto-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 4
•
•
•
•
•
•
•
•
•
•
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
i3 NETWORK SERVICES REQUIREMENTS
I3 FUNCTIONAL REQUIREMENTS
BORDER CONTROL FUNCTION (BCF)
EMERGENCY CALL ROUTING FUNCTION (ECRF)
EMERGENCY SERVICES ROUTING PROXY (ESRP)
LEGACY NETWORK GATEWAY (LNG)
LEGACY PSAP GATEWAY (LPG)
LEGACY SELECTIVE ROUTER GATEWAY (LSRG)
LOCATION VALIDATION FUNCTION (LVF)
ALI DATABASE SERVICES
DISASTER RECOVERY / BUSINESS CONTINUITY
33
34
34
36
37
37
38
38
39
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.
public caller
originating
service provider
9-1-1 system service provider
LIS (Forest Guide)
LIS
SIP/H.323
(VoIP)
clients
DNS
BCF
Public Access
IP Network
ESInet (prime)
ECRF/LVF
LoST
ESRP
global ES
internetwork
CR
BCF
BCF
BCF
core router
BCF
regional ESInet
BCF
NG ALI
LIS
legacy TDM
circuit switched
networks
LPG
ECRF/LVF
MEVO
disaster recovery
PSTN
device
i3 PSAP (B)
911 SSP / state ESInet
LNG
wireless
device
ESInet (additional)
legacy
ALI platforms and
third party location
providers
ESRP
i3 PSAP (A)
Emergency Services IP Networks (ESInet)
NG PSAPs or legacy PSAPs
This diagram represents a basic and
The objective is to demonstrate how a hiearchical
TDM transitional NG9-1-1 architecture. distribution of functional elements facilitate a public
caller’s ability to be routed to the proper PSAP.
legacy
PSAP (C)
SECTION 5
• 5.1
• 5.2
• 5.3
• 5.4
SERVICE AND SUPPORT REQUIREMENTS
CUSTOMER SUPPORT SERVICES
HELP DESK
TROUBLE HANDLING AND TICKETING REQUIREMENTS
TRAINING
39
40
40
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 6
• 6.1
• 6.2
• 6.3
• 6.4
• 6.5
SYSTEM REPORTING REQUIREMENTS
REPORTING AND DATA COLLECTION SYSTEM REQUIREMENTS
STATEWIDE STATISTICAL MONITORING
OPERATIONAL REPORTING
EVENT REPORTS
LOCAL LOGGING RECORDER INTERFACE
42
42
43
44
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 standalone proposals from vendors who can offer an enterprise wide, multivendor 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 7 MONITORING AND MAINTENANCE
REQUIREMENTS
• 7.1
• 7.2
• 7.3
• 7.4
• 7.5
• 7.6
• 7.7
MONITORING OF APPLICATIONS AND EQUIPMENT
NETWORK OPERATIONS CENTER
NOTIFICATION AND ESCALATION
PERFORMANCE MONITORING
ALARM CATEGORIES
SCHEDULED MAINTENANCE
MAINTENANCE SUPPORT LOGS
44
45
45
45
46
46
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
• 8.2 SYSTEM TEST PLAN
46
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
• 9.2
• 9.3
• 9.4
ELECTRICAL
ELECTRICAL INTERFERENCE
WIRING AND CABLING
GROUNDING
48
48
48
49
SECTION 10 PROJECT PLANNING REQUIREMENTS
• 10.1 IMPLEMENTATION PROJECT PLAN
• 10.2 SERVICE MANAGEMENT PLAN
50
50