1 / 43

IN911 RFS for Wireless E911 and i3 Network Services Pre-bid Meeting August 13, 2014

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. 1.1 RESPONSE INSTRUCTIONS 3 1.2 PURPOSE OF THIS PROCUREMENT 3

simone-randall
Download Presentation

IN911 RFS for Wireless E911 and i3 Network Services Pre-bid Meeting August 13, 2014

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IN911 RFS for Wireless E911 and i3 Network Services Pre-bid MeetingAugust 13, 2014 Joel McCamley, ENP Jim Lockard, PMP, ENP

  2. Contents of Attachment D – Technical RFS

  3. 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

  4. 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.

  5. 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.

  6. 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.

  7. 1.4 Scope of Services The services sought by this RFS include: • 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 • System and component level monitoring, alarming, diagnostics and reporting services • Disaster recovery and system restoration services • 24/7/365 Help desk, trouble ticketing and customer facing support services • 24/7/365 Network operations center (NOC) monitoring services • Installation, testing, maintenance and on-site support services • Project management services for the planning, design, testing, installation and operation of the system or systems

  8. IN911 Current System Overview

  9. 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.

  10. 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

  11. 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-ALiplatform • BCF - this is in service in the G-11 network • SIF in the G-11 platform, this functional element is aliased by the NG-ALiplatform • 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

  12. 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).

  13. 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.

  14. 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

  15. 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 minimumdeliver the same functionality of the current IN911 system ESInet as detailed in Section 1 of the specification.

  16. 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.

  17. 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.

  18. 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.

  19. 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.

  20. 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

  21. 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.

  22. 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.

  23. 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.

  24. 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

  25. SECTION 4 i3 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

  26. 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.

  27. SECTION 5 SERVICE 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

  28. 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.

  29. SECTION 6 SYSTEM 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

  30. 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.

  31. SECTION 7 MONITORING 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

  32. 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).

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

  34. 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

  35. 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.

  36. 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.

  37. 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

  38. SECTION 10 PROJECT PLANNING REQUIREMENTS • 10.1 IMPLEMENTATION PROJECT PLAN 50 • 10.2 SERVICE MANAGEMENT PLAN 50

More Related