da.ks.govda.ks.gov/purch/contracts/default.aspx?getfile=evt... · web viewkansas ng9-1-1...

RFP #EVT0003196 Specifications

Kansas NG9-1-1 Infrastructure RequirementsBidder shall provide their Technical Proposal in the designated text boxes. Bidder shall provide their Cost Proposal using the pricing template.No pricing information shall be included in the Technical Proposal.Failure to follow proposal preparation instructions is grounds for disqualification.

EXECUTIVE SUMMARYBidder shall include an Executive Summary not to exceed two (2) pages in length.

Bidder’s executive summary goes here:


1. BIDDER’S CHOICEThe Kansas NG9-1-1 System is comprised of the NG9-1-1 System, or a combination of four (4) subsystems. The 9-1-1 Coordinating Council (“Council”) invites Bidder to act as a system integrator providing a response to the system integration all four (4) subsystems as a turn-key solution of services. However, Bidder is free to bid on any or all of the subsystems listed below. A Bidder may be awarded multiple subsystems.

Bidder shall indicate their preference for consideration of award in the table below as “First Choice,” “Second Choice,” Third Choice,” Fourth Choice,” as applicable.

NG9-1-1 System / Subsystem Bidder’s preference goes here:

Infrastructure System IntegrationIP Network

Core SubsystemRegional Subsystem

Data Center SubsystemNetwork Monitor and Management (NMM)Call Handling Subsystem


2. COMPLIANCE SUMMARYBidder shall state his compliance in the Compliance Summary Table below by placing an “x” in the appropriate column.

Requirements Compliance Summary

Sub-Title FullyCompliant

Partially Compliant

Non-Compliant

SECTION 6 IP Network6.1 Physical Network6.1.1 State-level Ring6.1.2 Regional Ring Detail6.2 General Technical Requirements6.2.1 Network Providers6..2.2 Telecommunications Service Priority Codes6.2.3 Time Division Multiplexing (TDM) to IP Conversion6.2.4 Open Standards6.2.5 Scalability6.2.6 Architectural Survivability6.2.7 Network upgrades and Maintenance6.2.8 Bandwidth6.2.9 Network-PSAP Interface6.2.10 IP Addressing6.2.11 IP Subnetting6.2.12 IPv6 Addressing6.2.12.1 Migration to IPv66.2.13 IP Routing6.2.13.1 Interior Gateway Routing6.2.13.2 Exterior Gateway Routing6.2.13.3 Multicast Routing6.2.13.4 Common Routing Requirements6.2.14 Quality of Service6.2.15 Network Address Translation (NAT)6.3 Auxiliary IP Networks6.4 New Network Equipment6.5 Virtual Local Area Networks (VLANS)6.5.1 VLAN Design6.5.2 VLAN Management6.5.3 Multicast Routing and Switching6.6 Data Encryption6.6.1 Network Risk6.6.2 Network Diagrams6.6.2.1 Diagrams as a Deliverable upon Completion of the Network.6.7 General Network Device Security


6.8 Device Naming and Labeling and Cable Labeling6.9 Network Performance6.9.1 Network Latency6.9.1.1 POP to POP6.9.1.2 POP to Endpoints6.9.2 Packet Loss6.9.3 Network Traffic Convergence6.9.4 Mean Time to Repair (MTTR)6.9.5 Mean Time Between Failure (MTBF)6.9.6 Network Availability6.9.7 Remedies6.10 Project Management6.11 Change ManagementSECTION 7 Data Centers7 State-Level Data Center7.1.1 Cabinets and Power Distribution7.1.2 Data and Power Cabling7.1.3 Physical Security and Access7.2 Servers and Software7.2.1 Server and Storage Hardware and Software7.2.2 Server Installation7.3.1 Domain Name Services7.3.2 SNMP7.3.3 Other Common Network Services7.4.1 Mean Time to Repair (MTTR)7.4.2 Mean Time Between Failures (MTBF)7.4.3 System Availability7.4.4 Remedies7.5 Statement on Standards For Attestation Engagements Number 167.6 Project Management7.7 Change ManagementSECTION 8 Network and Application Management and Monitoring8.1 Network and Application Management8.2.1 Network Monitoring8.2.2 Network Fault Management8.2.3 Network Performance Management8.2.4 Information Storage and Retrieval8.2.5 Incident Management System8.2.6 Change Management System8.2.7 Network Logging8.2.8 Security Monitoring and Management8.2.9 Physical Access Monitoring and Management8.2.10 Management Software8.2.11 Network Configuration Management8.2.12 Configuration Backup and Restoration


8.2.13 Reason for Outage (RFO) Report8.2.14 Preventative Maintenance8.2.15 Scheduled Maintenance8.2.16 Support Contracts8.2.17 Support Maintenance8.2.18 Access to Technical Staff8.2.19 Notification8.2.20 Escalation Procedures8.2.21 Change Management Procedures8.2.22 Statement on Standards for Attestation Engagements # 168.3 Vendor Consideration in Monitoring Plans8.4 Project Management8.5 Change ManagementSECTION 9 Call Handling9.1 Call Handling Architecture9.2 Vendor’ Visions of NG9-1-1 Call Handling9.3 NENA Industry Collaboration Events (ICE)SECTION 10 Call Handling Requirements10.1 Call Handling Locations10.2 Call-handling Data Center Requirements10.2.1 Call-Handling System Cabinets and Power Distribution10.2.2 Call-handling System Data and Power Cabling10.2.3 Physical Security and Access10.3 Call-handling System Servers and Software10.3.1 Call-handling Server and Storage Hardware and Software10.3.2 Call-handling Server Installation10.4 Call Handling Performance10.5 Call Handling Hardware10.6 Call Handling Protocols10.7 Ongoing Call Handling Monitoring and Maintenance10.8 Call Handling Connectivity Requirement10.9 Call Handling Protocols and Firewall Ports10.10 Call Handling Solution Survivability10.11 Call Handling System Inter-node Bandwidth10.12 Call Handling Upgrade and Update Process10.13 Call Handling Security Management10.14 Cost for Call Handling Upgrades10.15 Call Handling Connectivity10.15.1 Call Handling to CAD System Connectivity10.15.2 Administrative Lines to Call Handling System10.15.3 ALI Links to Call Handling System10.16 Call Handling System Security10.16.1 Malware and Anti-Virus10.16.2 Malware and Anti-Virus – Software Updates10.17 Call Handling System Single-Logon Authentication


10.18 Call Taker Human Machine Interface (HMI) Call Handling System10.18.1 Call Handling Call Controls and Display10.18.2 Call Handling Incident Information10.18.3 Call Handling System Additional Data/Call History10.19 ALI Interface to Call Handling System10.19.1 Call Handling System ALI Caching10.19.2 Call Handling System Manual ALI Request10.19.3 Call Handling System Supplemental ALI10.19.4 Call Handling System ANI/ALI/Caller ID (CID) Display10.19.5 Call Handling System ALI Rebids10.19.6 Call Handling System Pre-answer ALI10.19.7 Call Handling System Calls in Queue – View ALI Detail10.19.9 Call Handling System ALI Display – Post Call10.19.9 Call Handling System ALI Display – Callback10.19.10 Call Handling System ALI Parsing10.19.11 Call Handling System ALI Discrepancy Reporting10.19.12 Call Handling System Incomplete ANI Spills10.20 Call Handling ACD10.20.1 Call Handling Call Delivery10.20.2 ACD Hunt Types10.20.3 Call Handling Barge-in10.20.4 Call Handling Callback10.21 Call Handling Conference10.21.1 Basic Call Handling Conference Requirements10.21.2 Call Handling Conference Disconnect Control10.21.3 Call Handling Conference Mute Transmit Toward 911 Caller10.22 Call Handling Hold/Park10.22.1 Call Handling Hold/Park - Retrieval10.23 Call Handling Merge Media10.24 Call Handling Supervisory Monitor10.25 Call Handling Speed Dial10.25.1 Call Handling Access to Speed Dial Feature10.25.2 Call Handling Speed Dial List Quantity of Numbers10.25.3 Call Handling Speed Dial – Extra Digits10.25.4 Call Handling Speed Dial Library – Search10.25.5 Call Handling Speed Dial – PSAP and Personal List10.26 Call Handling Status Monitor10.26.1 Call Handling Status Monitor10.26.2 Call Handling Status Timer10.27 Call Handling Transfer10.27.1 Transferred Calls (Tandem)10.27.2 Transferred Calls (Network)10.27.3 Intelligent Transfer Button10.27.4 Transfer via 911 Tandem10.28 TDD/TTY Call Handling


10.28.1 TDD/TTY Federal Requirements10.28.2 Automatic TDD/TTY Call Detection10.28.3 TDD/TTY Direct Connection10.28.4 911 and Administrative TDD/TTY10.28.5 Baudot and ASCII TDD/TTY Protocols10.28.6 Preprogrammed TDD/TTY Messages10.28.7 TDD / TEXT Conferencing10.28.8 Message Display10.28.9 Message Length10.28.10 TDD / TTY or TEXT Transfer10.28.11 TDD/TTY – TEXT Archiving10.28.12 Hearing Carry Over / Voice Carry Over (HCO / VCO)10.29 Call Handling Wall Board Status Monitor10.30 Call Handling Instant Recall Recording10.30.1 Instant Recall Recorder (IRR)10.30.2 Administrative Calls10.30.3 Automatic / Manual Recording10.30.4 Call Recording Storage10.30.5 Storage Capacity10.30.6 Erasure of IRR Call Recordings10.30.7 Recording Radio Channel10.30.8 Recording Call Type / Text Information10.30.9 Recording Playback10.30.10 Recording Export10.30.11 Supervisor Access to Recordings10.31 Call Handling Multi-Media Display10.32 Call Handling Video10.33 Call Handling System Map Display10.33.1 Call Handling System support of Esri10.34 Call Handling System Support of GIS Data / Mapping Application10.34.1 Map Circle of Uncertainty10.34.2 Map Zoom10.34.3 Map Imagery10.34.4 GIS Reverse Geocoding10.34.5 Mapping of Abandoned Calls10.35 Call Handling Call Detail Records (CDRS)10.35.1 CDR Availability10.35.2 CDR Content10.36 Call Handling MIS10.36.1 Basic MIS Requirements10.36.2 MIS Access – PSAP10.36.3 Redacted Reports10.36.4 PSAP Group Performance Reports10.36.5 Trunk Performance M|IS Reports10.36.6 PSAP Performance Goals MIS Reports


10.36.7 MIS ad Hoc Reports10.36.8 Multi-media MIS Reports10.37 Call Handling Workstations10.37.1 Workstation – Wiring Runs per Position10.37.2 Genovation Keypad for Workstation10.38 Call Handling Handset/Headsets10.38.1 Dual Connections for Headset/Handset10.38.2 Headset/Handset Radio/Telephone Integration10.39 Call Handling Workstation Support Applications10.39.1 Workstation Audio Volume Control10.39.2 Workstation Display Color Options10.39.3 Call Alert While in Third-Party Application10.39.4 Workstation Previous Calls Data10.39.5 Modify Workstation Sounds10.39.6 Application Workstation Feature Shortcuts10.39.7 Workstation Screen Configuration10.39.8 Line / Trunk Status on Workstation10.39.9 Workstation-to-Workstation10.39.10 Interactive Workstation Messaging10.40 Project Management10.41 Change Management


3. SCOPE AND PURPOSEThe purpose of this Request For Proposal (RFP) is to obtain Bid and Proposals (B&Ps) for implementing a statewide IP Network and an i3-ready NG9-1-1 call handling system for Kansas. The RFP includes the System Integration of all four (4) NG9-1-1 infrastructure subsystems as a turn-key solution; or furnishing any combination of individual or collection of individual subsystems:

NG9-1-1 Infrastructure System Integration NG9-1-1 IP Network Subsystem NG9-1-1 Call Handling Data Center Subsystem NG9-1-1 Call Handling Subsystem NG9-1-1 Network Monitoring and Maintenance (NMM) Subsystem

Bidder may respond to all or any part of this RFP. While the Council prefers a comprehensive system integration response, they will select the response(s) most advantageous to the state. Bidder shall identify all subcontractors that are a part of their response.

Adherence to industry-accepted recommendations and best practices provides many advantages including protection from obsolescence, improved supportability, reduced costs, and improved interoperability. For these reasons, the Council requires standards compliance and best practices.

System IntegrationThe Kansas NG9-1-1 Infrastructure System has four (4) major subsystem components. System integration is the bringing together of those four subsystems as a turn-key solution that successfully meets or exceeds the specifications herein.

The System Integrator shall address both the Implementation phase and the Operation and Maintenance (O&M) phase of NG9-1-1. The System Integration Bidder shall fully define their system integration solution, fully explain their project plan, fully describe their resource plan, and fully disclose their system integration experience.

Bidder’s Proposal Response To This Requirement(s) goes here.

(select one) Fully Compliant, Partially Compliant, Non-Compliant

If you are bidding as system integrator, discuss and illustrate how your proposal meets or exceeds our requirements.

System Integration Solution. How do you intend to bring together the four (4) subsystems into a turn-key, supportable solution?

System Integration Project Plan. What are the salient differences between a typical subsystem


project plan, and your system integration program plan?

System Integration Resource Plan. What internal, external or mix of resources do you intend to use to successfully accomplish the requirements of a supportable NG9-1-1 infrastructure?

System Integration Experience. What relevant experience do you have integrating a comparable infrastructure platform such as our NG9-1-1 system?

Network SubsystemThe purpose of the network portion of this RFP is to communicate the Council’s plans to contract a scalable, standards-based, interoperable, carrier-agnostic, and managed-IP Network solution for transporting existing E911 calls and related data. The IP Network shall be capable of supporting NG9-1-1 applications and services currently available and new services as they are developed. Examples include but are not limited to text messaging (SMS), pictures and video (MMS), native VoIP call delivery, and telematics. The IP Network design shall meet National Emergency Number Association (NENA) and Internet Engineering Task Force (IETF) standards and adhere to industry best practices. This specification including Section 4 and Appendix A, lists applicable documents, standards, and guidelines.

Since this infrastructure will carry 911 voice traffic, ALI data services, and other applications to the PSAPs, the new IP-enabled Network shall be redundant and diverse in order to achieve the required reliability. Individual circuit, hardware, software, or firmware failures shall not disrupt normal IP communications. There shall be no single point of failure in an IP infrastructure that carries live 911 calls.

Vendor shall develop solution(s) in conformance to IETF Request for Comments (RFCs), NENA recommendations for IP Networks, and applicable Federal Communication Commission (FCC) Communications Security, Reliability, and Interoperability Council (CSRIC) recommendations for 911 networks. Appendix A contains a basic list of relevant RFCs, standards, and guidelines.

The IP Network shall comply with applicable IETF RFCs including but not limited to: IP, IP routing, Quality-of-Service (QoS), and Simple Network Management Protocol (SNMP). The proposed IP Network shall be capable of supporting Session Initiation Protocol (SIP) and provide high-quality transport of Real-time Transport Protocol (RTP) media streams such as G.711 voice. The proposed IP Network shall be Voice over IP (VoIP) ready.

The IP Network chassis-based devices shall be equipped with redundant, hot-swappable power supplies, processors, and interface cards such as would be found in the network core (often referred to


as “carrier grade”) shall be designed with a chassis service life of 15 years or more. Processors, memory, power supplies, and line cards shall be upgraded or replaced as required to satisfy all functional and performance requirements. The smaller access switches and routers that will be deployed in the PSAPs shall be upgrade or replaced as required to satisfy all functional and performance requirements.

Data CentersWhile there are many excellent network equipment manufacturers, each conforming to recognized standards, there can sometimes be a slight difference in the implementation of those standards. For this reason, more than one manufacturer shall be avoided, especially within and between data centers. Bidder shall specifically address the equipment and manufacturer proposed for their solution.

Call HandlingThe NG9-1-1 call handling solution of Vendor shall incorporate all current i3 NENA requirements. Additionally, the NG9-1-1 call handling solution shall provide a clear roadmap, complete with dates, for implementing known emerging NENA i3 requirements. Bidder shall explain how their NG9-1-1 call handling solution satisfies NENA i3 standards in a timely manner and from an historical perspective.

Network and Application Monitoring and Maintenance (NMM) SubsystemThe Council desires to select a single Vendor to have overarching monitoring and management responsibilities for the IP Network and NG9-1-1 Applications. This includes monitoring out to the device at the PSAP. Vendor shall maintain a problem management system for tracking and reporting trouble. Vendor shall furnish and maintain a change management system for tracking and reporting changes to the network and subsystems. Vendor shall be prepared to handle After Action Reviews (AARs) and issue Reason for Outage (RFO) reports when outages occur.

All IP Network, i3 Call Handling, and i3 Service Providers shall demonstrate a clear and thorough understanding of the intra-state interoperability requirements of a NG9-1-1 System. As the IP networks of neighboring states are connected to the Kansas IP Network, the Monitoring and Maintenance Plan furnished by Vendor shall address inter-state interconnectivity and interoperability with the same rigor as intra-state interconnectivity and interoperability.



Discuss and illustrate how your proposed solution meets each of these requirements for the subsystem(s) you are bidding.


4. APPLICABLE DOCUMENTS Kansas NG9-1-1 Change Management Policy (available at

http://admin.ks.gov/offices/procurement-and-contracts/additional-files-for-bid-solicitations) Kansas NG9-1-1 GIS Data Model (available at

http://admin.ks.gov/offices/procurement-and-contracts/additional-files-for-bid-solicitations) NENA ADM-000 - Master Glossary of 9-1-1 Terminology NENA 08-002 v1 - Functional & Interface Standards for NG9-1-1 (i3) NENA 08-751 NENA i3 Technical Requirements NENA 75-001 v1 - NENA Security for Next-Generation 9-1-1 Standard (NG-SEC) NENA Baseline Next Generation 911 Description, February 22, 2011 National Institute of Standards and Technology (NIST) 800-53 Revision 4 RFC 3261 – SIP: Session Initiation Protocol RFC 3376 – Version 3 of the Internet Group Management Protocol (IGMPv3) RFC 4604 - Standards for using Internet Group Management Protocol v3 and Multicast Listener

Discovery Protocols v2 for source specific multicast RFC 3973 – Defines Protocol Independent Multicast – Dense Mode (PIM-DM) RFC 5015 – Discusses Bidirectional PIM (BIDR-PIM) RFC 3569 – Source-Specific Multicast (SSM) RFC 4601 – Protocol Independent Multicast – Spare Mode (PIM-SM) RFC 2328 – Open Shortest Path First (OSPF) Version 2 RFC 4271 – Border Gateway Protocol 4 (BGP4) RFC 3411 – An Architecture for Describing SNMP Management Frameworks RFC 3412 – Message Processing and Dispatching for the SNMP RFC 3413 – SNMP Applications RFC 3414 – User-based Security Model (USM) for version 3 of the SNMPv3 RFC 3415 – View-based Access Control Model (VACM) for the SNMP RFC 3416 – Version 2 of the Protocol Operations for the SNMP RFC 3417 – Transport Mappings for the SNMP RFC 3418 – Management Information Base (MIB) for the SNMP

http://tools.ietf.org/html/rfc3418








http://admin.ks.gov/offices/procurement-and-contracts/additional-files-for-bid-solicitations

http://admin.ks.gov/offices/procurement-and-contracts/additional-files-for-bid-solicitations


5. NEXT GENERATION NG9-1-1 OVERVIEW

5.1. NG9-1-1 BASELINE

NENA Baseline NG9-1-1 is a description of a basic set of features & functions that constitute a NENA Standards based Next Generation 9-1-1 solution, on the path to end-state i3 architecture. The i3 architecture components are only one aspect of NG9-1-1. There are more components that make up a complete NG9-1-1 ‘system.’ As future needs are identified, overall NG9-1-1 standards will be updated.

Vendor’s baseline NG9-1-1 system shall include the functionality of a legacy E911 system including all network and PSAP system components, as well as capabilities beyond E911 functionality, such as the ability to support text, multimedia, and video. While these forms of communication may not be immediately available, the Vendor baseline NG9-1-1 shall have the system functionality to support multimedia, perform routing, provide for call media logging, and enable PSAP/caller interactive communications.

Vendor solution shall provide the components and capabilities required of a baseline NG9-1-1 system according to NENA standards including, but are not limited to:

1. ESInet (Emergency Service IP network)2. GIS data creation to support items 3 and 6 below, and associated management tools3. Publication of Authoritative NG9-1-1 Validation related Databases for use by OSPs

and Location DB providers to pre-validate civic addresses (in replacement of MSAG), supported by LVF and LIS functionality

4. Publication of Authoritative NG9-1-1 Routing Data for state and regional levels5. Support for legacy originating services via gateways; for example, access to

traditional ALI databases6. Geospatial controlled IP software Emergency Call Routing Function (ECRF) and

Emergency Services Routing Proxy (ESRP)7. The ability to control call routing based upon a Policy Routing Function (PRF) with

standardized methods to define/build and control Policy Rules8. Additional data acquisition after call delivery to facilitate call processing by a call

taker or other public safety entities9. Support for transfer of calls with accumulated call taker notes and added data, or an

access key to such data, to any authorized entity interconnected by ESInets 10. Ability to interconnect with other NG9-1-1 systems and to interwork with other E9-1-1

systems 11. Support for system monitoring/logging/discrepancy reporting necessary to support

troubleshooting and ongoing operation and maintenance.

The above minimally required components or capabilities of Vendor baseline NG9-1-1 system encompass architectural, security, data, confidentiality, interconnection with


other 9-1-1 systems, and operations aspects of NG9-1-1 service as defined by NENA Standards and related documentation.

The NENA document and additional information on baseline NG9-1-1 can be found at http://www.nena.org/?NG911_Baseline

Figure 1 depicts i3 services implemented to provide the ability to communicate with an individual “calling” from any device and provide the call taker with critical information about that caller, including location. In NG9-1-1, the location information comes with the 911 call.

Figure 1 Transitional IP network and i3 Services

5.2. I3 PSAP

The call handling system(s) shall include SIP-based call handling equipment at the answering points and NG9-1-1-capable answering positions. This equipment shall be capable of receiving and interpreting the data delivered with emergency calls routed to the PSAP by the i3 services. The call handling system shall also provide standard interfaces to the existing Computer Aided Dispatch (CAD) system and mapping applications.

http://www.nena.org/?NG911_Baseline


Currently, most equipment providers advise that they will include all new standards as they are developed; many of the basic standards are already in place. Bidder shall fully disclose their plan(s) to implement the Human Machine Interface & PSAP Display Requirements (NENA 54-750) jointly developed by NENA and the Association of Public-Safety Communications Officials, International (APCO).

5.3. ADDITIONAL I3 ELEMENTS

Figure 1 depicts the future i3-related services that will be delivered from state-level data centers across the IP Network. This figure shows a transitional network; the legacy gateway functionality will decline as the carriers and PSAPs transition to all-IP delivery. This is a functional diagram rather than a device diagram.

5.3.1. Border Control Function

The Vendor Border Control Function (BCF) shall consist of several functions:

highly resilient routers to accept connections

firewalls and other security devices for network protection

back-to-back user agent (B2BUA) for call control for SIP calls entering the system

continuous network and system monitoring.

Options include the possibility of implementing many or all of these functions into IP routers provisioned at Points of Interconnection (POIs) to other entities.

The Legacy Selective Router Gateway (LSRG) and Legacy Network Gateway (LNG) may be located either in a state-level Data Center or in a carrier’s Central Office (CO). From a physical perspective, the functionality may reside in the same chassis. If the LSRG and LNG are located in a carrier CO, the IP traffic from them will pass through the BCF just like any other external IP traffic. The Legacy PSAP Gateways (LPGs), for non-i3 compatible Call Handling subsystem, will reside at the PSAPs. These devices convert the SIP voice traffic back to Centralized Automatic Message Accounting (CAMA) trunks to interface with the Customer Premise Equipment (CPE). Like the LSRG and LNG, these will fade from service as PSAPs update their call handling system to i3-ready systems.

Although i3 services are not a part of this RFP, the subsystems that make up this RFP shall be capable of supporting i3 services as they are added to the infrastructure.



The proposed infrastructure shall be capable of supporting i3 services as such services become available and are added to the infrastructure. Describe and diagram how the proposed solution meets the requirements of Section 5.


6. NETWORK DESIGN REQUIREMENTS

6.1. PHYSICAL NETWORK

Vendor shall implement a hybrid network design consisting of a series of regional rings overlaid with and connected to a statewide ring. The regional rings will connect directly to the PSAPs. The statewide ring will connect the regional rings to three (3) geographically diverse Data Centers located at least 100 miles apart, but still within the state of Kansas. This design concept shall not preclude having an individual PSAP directly connected to the state ring if necessary due to technical constraints or financial limitations.

Fiber optics is the preferred method for connectivity due to available capacity (bandwidth) and increased reliability. Given the amount of fiber optic facilities and interconnections between the fiber optic networks in the state, the statewide IP Network design shall include as much fiber as possible, not only on the transport side, but on the access side as well.

Figure 2 depicts the conceptual network.

Figure 2 State / Regional Network Design

The network drawings show backbone connections as 1-10 Gigabits (Gb). This is merely an indication of the physical connectivity desired, not the purchased bandwidth on those links. The IP Network shall


have the ability to adjust bandwidth to changing needs easily, quickly, and with minimal operational impact. For example, the Council may contract initially for 100Mb connectivity, then increasing bandwidth as traffic increases.

Note that Figure 2 shows that individual PSAPs may connect directly to the state network in the event it is not feasible or possible for them to connect to a regional network. Figure 2 also illustrates three (3) possible backup scenarios:

wireless backup (PSAP-A) no redundant circuit or service (PSAP-B) primary connection via fiber or T1 backed up by a physically diverse T1 or HFC link.

To the maximum extent economically and technically feasible, fiber optic connectivity shall extend all the way to the PSAP. Although the backup network is shown as a wireless network, it may be any IP-capable media.

The scenario for PSAP-B (no redundant circuit) illustrates that the backup for some PSAPs may be through either a make-busy switch on the CAMA trunks, or the PRF in the i3 services (the i3 equivalent of the make-busy switch). Some PSAPs, rather than incur the cost of a redundant circuit, may choose to have their traffic rerouted to a neighboring PSAP. Vendor shall include redundant, diverse connectivity quotes for every PSAP.

The proposed IP Network shall be private, robust, scalable, secure, diverse, redundant, and sustainable. Vendor shall describe how their proposed solution meets each of these goals. Vendor shall propose a diverse, redundant network solution for all sites listed herein. Bidder shall price redundant connectivity as a price option for each PSAP site in their Cost Proposal pricing template, thus allowing the Council to determine if redundant links will be chosen. No pricing shall be provided in the Technical Proposal. Pricing shall only be included only in the Cost Proposal. A list of PSAPs appears in Appendix C.



The proposed IP network shall be private, robust, scalable, secure, diverse, redundant, and sustainable. Describe how the proposed solution meets each of these requirements. Propose a network solution for all sites listed herein.

6.1.1. State-Level Ring


The state-level ring shall be a fiber optic data network with a capacity of 1-10 Gb initially, expandable as required. It shall have three (3) Data Centers located strategically within the state, with a minimum distance of 100 miles between the centers. The Data Centers will house the i3 services, and also may house the hosted CPE solution. Figure 3 below shows a high-level view of the state ring. The “Backup Network” is not depicted as any specific type of network. It could be fiber, carrier-based Multiprotocol Label Switching (MPLS), satellite broadband, HFC, microwave, and/or 4G LTE. In fact, at any given Data Center there may be several types of connectivity providing backup network connections to regional rings and/or PSAPs.

Figure 3 State-level Detail



Discuss and illustrate how the proposed solution meets each of these requirements.

6.1.2. Regional Ring Detail

The Regional Rings will be small-scale versions of the Statewide Ring and shall meet all requirements of the Statewide Ring. Regional Rings shall have two (2) connections to the Statewide Ring. While a complete ring through all participating PSAPs in a given region is preferred, there may be a few PSAPs


where this is not feasible for either technical or financial reasons. Figure 4 depicts a typical Regional Ring, and shows how PSAPs that can’t be on a ring can still connect to the regional network. This concept is also illustrated in Figure 2, but with these outlying PSAPs connecting to one or more state-level Data Centers. Both options are shown to demonstrate the flexibility desired of the IP Network and to reinforce the idea that, within governance and security best practices, one of the primary underlying design principles is for the PSAPs to have the optimum connectivity value cost benefit. The links from the Regional Rings to the Statewide Ring shall be physically diverse and connect to different POPs.

Figure 4 Regional Ring Detail

The Regional Rings will generally be based on the six (6) state homeland security regions as depicted in the map shown in Figure 5. Due to a variety of technical and political factors, it is expected there will some variations in exact regional boundaries particularly along the regional borders. The Mid-America Regional Council (MARC) which is depicted in yellow would be a seventh region, but is not considered part of this RFP for regional purposes. Vendor shall furnish MARC with diverse, redundant connections to the Statewide Ring. Miami County, which is shown in the Northeast Region (light blue) in Figure 5 should be considered as part of MARC.


Figure 5 State Regions




6.2. GENERAL NETWORK REQUIREMENTS

Vendor shall propose an IP Network based on fiber optic services when and where available at a given location or between locations. The IP Network shall be Open Systems Interconnection (OSI) Layer 3; that is, the delivery of IP packets between nodes on the network. The IP Network shall deliver IP packets from any IP address to any other IP address among any and all connected sites. Any network solution’s hardware, software and firmware shall support both IP Version 4 (IPv4) and IP Version 6 (IPv6).

Fiber is the preferred Layer 1 media, and Ethernet the preferred Layer 2 technology when available. Vendor may consider other Layer 1 (copper, wireless…) and Layer 2 (High-level Data Link Control [HDLC], frame-relay, Asynchronous Transfer Mode [ATM], Multiprotocol Label Switching [MPLS]…) technologies, in any combination and arrangement, which shall deliver the most cost effective solution meeting the requirements of this RFP. Vendor shall provide, directly or through subcontractors, the


Layer 1 and Layer 2 facilities required to interconnect specified sites. The IP Network shall have redundant, physically diverse connections to each point of interconnection (POI), end office, central office, selective router, PSAP, and other such facilities that may be part of the IP Network.

Vendor shall propose an IP network that evenly distributes the PSAP data circuits across as many provider edge devices and physical cards and ports on those devices as practical to minimize the effects in the event of an edge device failure. Additionally, Vendor shall work with the Council to ensure PSAPs that back each other up are served by edge devices located in separate central offices or Data Centers.

Nothing in this RFP shall preclude the Council from acquiring certain redundant, diverse connectivity from the Kansas Criminal Justice Information System (KCJIS) and/or Office of Information Technology Services (OITS), nor from utilizing pre-existing connectivity at any given PSAP. In those instances, Vendor shall work cooperatively with KCJIS and/or OITS as with any other service provider.

Vendor shall disclose the Layer 1 and Layer 2 technologies and topologies that they intend to deploy by providing network diagram(s) and text that show and explain these implementation details. It is not necessary that Vendor furnish complete finished network diagrams showing all network sites. However, the diagrams furnished shall display sufficient and adequate information about the core network and each unique type of site connection so that the topology and design of Layers 1, 2 and 3 are clear. The diagrams and narrative shall provide sufficient information so technical reviewers can identify how the design meets the requirements and intent of this RFP. The narrative and drawings shall reference and depict all POIs and POPs. POP / POI information including estimated bandwidth is provided in Appendix D. Vendor shall furnish a brief description of the rationale for the network topology, the Layer 1 and Layer 2 design, and the advantages of the design. In any case, the Layer 3 IP service shall meet the service level requirements specified in Appendix E.

The IP network shall make use of applicable switching and/or routing protocols to enable fast failover in the event of a link or equipment failure.

If a Vendor is unable to avoid any potential single points of failure in this deployment, the failure point(s) shall be noted on the drawings with the reasons and the mitigation strategies included in the narrative.

Drawings shall be furnished in both Adobe PDF and Microsoft Visio formats. Both hard copies and soft copies shall be included in the response as specified in the proposal response instructions of this RFP.



Provide a detailed explanation and associated drawings explaining how the proposed solution meets or exceeds the above requirements.


6.2.1. Network Providers

Vendor that will provision circuits using the facilities of other providers shall identify each provider they are including in their proposal. Bidder shall provide a description of the facilities used and interconnection type(s) of each provider. Detailed information on this shall be a part of the as-built documentation to be provided at the completion of the project.




6.2.2. Network Services Telecommunications Service Priority Codes

Vendor shall work with the Council’s designee to obtain Telecommunications Service Priority (TSP) codes, and enter said codes in the Vendor’s circuit records. Vendor shall further ensure that all other carriers and service providers who transport or deliver circuits for the IP Network and related systems record the TSP codes in their circuit records. Upon completion of a network segment, Vendor shall provide documentary evidence that the codes have been properly recorded



Bidder shall provide a detailed explanation and associated drawings explaining how their proposed solution meets or exceeds the above requirements.

6.2.3. Time Division Multiplex (TDM) to IP Conversion

Vendor shall furnish, when and where appropriate, geographically diverse LSRGs and/or LNGs to accept trunks from the legacy selective routers and legacy networks. These gateways will also allow


for calls to be transferred out of the IP Network to PSAPs still on existing CPE and legacy network trunks.




6.2.4. Open Standards

The proposed network shall be based on open standards such as Institute of Electrical and Electronics Engineers (IEEE) 802.3 at Open Systems Interconnection (OSI) Layer 2, and IP and Transmission Control Protocol (TCP), as defined by IETF in applicable Requests for Comments (RFCs), at OSI Layer 3 and above. All proposed network hardware, software and firmware shall support both IPv4 and IPv6.

Any and all protocols that run on top of or that use IP for transmission shall be transported over the proposed network. No protocol or use of the IP Network may be blocked or prevented by the network provider, unless in compliance with authorized Council security policies.

Networks and devices shall, where applicable, support both Alliance for Telecommunications Industry Solutions’ (ATIS’) Request for Assistance Interface (RFAI) specifications and NENA’s i3 specifications for SIP call handling.

Bidder shall reveal any use of proprietary standards or protocols in their proposed solution, or state that they fully comply with this requirement. Any limitations, whether technological or philosophical, shall be revealed.





6.2.5. Scalability

The overall design shall scale to include redundant interconnections to additional sites and other (separate) public safety IP networks. The proposed network shall include a strategy for expected growth over the next five (5) to seven (7) years. The design shall plan for interconnections to as many as six (6) additional public safety IP networks. The design shall accommodate this goal without wholesale replacement, forklift upgrades or excessive non-recurring charges.

Bidder shall demonstrate, through diagrams, narrative, and pricing, how this goal can be realized with the proposed network design. This narrative shall explain changes or upgrades to proposed components of the network that would be required to accomplish this level of expansion. All pricing must be included only in the Pricing Proposal, and not the Bidder’s Technical Proposal.




6.2.6. Architectural Survivability

The core network and the redundantly connected sites shall be able to survive the total destruction, of any one core network site, such as a switching center, data center, POP, or POI site, by fire, flood, or other disaster.

The proposed network solution and supporting hardware shall be designed so that any one failure of any one circuit or piece of equipment shall not result in a total network failure, but only the loss of connectivity associated with that circuit or equipment. For sites with redundant connectivity, loss of one such connection shall not interrupt service to that site.

The proposed network shall incorporate service provider and/or facility diversity. The network core solution and redundantly connected sites shall include physically diverse routes and physically diverse building entrances. Any network elements that are not provisioned with physical diversity shall be revealed and explained in the Bidder’s Technical Proposal. Bidder shall specify in detail how network convergence activities are accomplished as a result of a network failure. Failures and convergence at the network and transport layers shall be specified.

With full redundancy implemented to all sites, the proposed network shall be designed to provide “five nines” (99.999 percent) availability to all sites as measured monthly. Availability is defined in Section


6.9.6. The service level agreements (SLAs) shall specify the performance requirements for the network as actually deployed at any time. Bidder shall specify how the technical solution meets availability requirements. Bidder shall define architecture availability in terms of percentage, for example, 99.999 percent.

Bidder shall support claims of reliability by including known or projected network reliability statistics or other scientific data that supports those assertions. Bidder shall also describe obstacles and risks to achieving high availability in their proposed solution. Bidder shall include a narrative describing the solution that details redundancy, resiliency, scalability, survivability, and convergence.




6.2.7. Network Upgrades and Maintenance

The proposed core network and redundantly connected sites shall not require downtime for planned maintenance. It is acceptable that individual components or elements have downtime for planned maintenance; however, Bidder shall provide an explanation of how the proposed solution shall remain operational when such planned maintenance is performed. Note that a fully redundant design together with appropriate Methods of Procedure (MOPs) for maintenance should meet this requirement.



Bidder shall provide a detailed explanation and associated drawings explaining how their proposed solution meets or exceeds the above requirements.

6.2.8. Bandwidth


The Council shall require the network provide, as a minimum, the bandwidth necessary to support the call volumes listed in Appendices C and D. Bidder shall explain their bandwidth methodology and calculations.

The proposed solution shall support a growth in bandwidth at each site to at least four (4) times the initial requirements by simple provisioning changes, adding facilities, or using faster facilities, but without replacing major components such as core or on-site routers. Bidder shall provide pricing in the Cost Proposal pricing template for all equipment upgrades required to the proposal to obtain the conceptual bandwidth.

The bandwidth requirements in Appendices C and D are for a fully functioning network with redundant connections in service. The failure of a redundant link may result in a loss of up to 50 percent of the specified minimum bandwidth but not affect the call processing to the affected site(s). This loss of bandwidth is allowable under the terms of the RFP as long as call processing is not affected.




6.2.9. Network – PSAP Interface

At each redundant network site, the demarcation interface to the PSAP local area networks (LANs) shall be two redundant 100 Mb or faster Ethernet ports. Bidder shall list and describe the Ethernet port fail-over scheme proposed.

The fail-over scheme shall be one that is typically used in the industry and complies with open standards. An acceptable solution is Open Shortest Path First (OSPF) routing protocol combined with Bidirectional Forwarding Detection (BFD). Bidder may suggest other solutions capable of achieving fast packet reroute.





6.2.10. IP Addressing

All core network devices such as switches, routers, servers (physical and virtual), Storage Area Networks (SANs), remote console devices, and similar devices, shall be assigned static addresses since dynamic address assignment leaves open some security holes. This topic is discussed in more detail under network services.




6.2.11. IP Subnetting

Private IPv4 address space shall be broken into supernets (/16, /18, or /20) by facility or region to keep the size of the core routing tables to a minimum. The supernets will actually be subnetted further into /24 networks. Given the recommendation to use private address space where address limitations are not a concern, the issuance of blocks smaller that a /24 shall be avoided. The one exception to this rule is addressing for point-to-point links, which may be accomplished with a /30 subnet. (For a frame of reference, a /8 network contains 256 /16s and a /16 contains 256 /24s.)

All devices within the network will be statically addressed. Due to security concerns, Dynamic Host Control Protocol (DHCP) shall not be implemented or allowed on the network.

Since IP address management can quickly become cumbersome, an IPAM system similar to IPplan (open source) or SolarWindsTM (commercial) shall be implemented for this network.





6.2.12. IPv6 Addressing

The proposed network shall support both IPv4 and IPv6 addressing at the network site demarcations into the PSAP LANs. The initial plan is to use private (RFC1918) IPv4 address space of 10.0.0.0/8 within the IP network as outlined above, and public IPv4 address space for interconnections to outside agencies, partners, and carriers. With the possible exception of point-to-point communications links, no IPv4 subnet smaller than a /24 shall be issued.

Should any external networks require the use of IPv6 addresses, Vendor shall configure edge devices (firewalls, SBCs…) to perform the address translation. Said devices shall have sufficient memory and processing capacity to run dual IP stacks until such time as the internal network is converted to IPv6 addresses.

Bidder shall describe their IP address space administrative procedures and provide assistance, information, and requirements for the Council to obtain an Autonomous System Number (ASN), and IPv4 and IPv6 address space allocations.

6.2.12.1. Migration to IPv6

At the time that IPv6 is implemented within the IP network, the Vendor shall be required to create a project plan and MOP for the migration from IPv4 to IPv6. The Vendor shall also work with facilities presently using only IPv4 addresses to migrate to IPv6 addresses, and to provide other support as needed to assist with IPv4/IPv6 address issues. Note that while the successful Vendor shall not be required to make changes in entity IP networks that are outside the scope of this RFP, they shall be required to fully cooperate with those facilities to provide address and subnet mask information, perform configuration changes in edge network routers, or change entries in core domain name system (DNS) services, and assist facilities with the migration to IPv6.

The cost of providing IP address migration services shall be listed in the network management component of the Pricing Proposal





6.2.13. IP Routing

The primary network view of the state IP network shall be at OSI Layer 3. Routing protocols are necessary to control traffic and ensure packets reach their proper destination. The Vendor shall implement a dynamic interior gateway IP routing protocol for routing inside the IP Network, and an exterior gateway protocol for routing to outside agencies, partners, and providers. All routing protocols shall support both IPv4 and IPv6.

6.2.13.1. Interior Gateway Routing

Vendor shall furnish Open Shortest Path First (OSPF) as defined in IETF RFCs, including RFC 2328 and as commonly implemented in the industry. Bidder may present alternative solutions for the consideration of the Council provided the solution is an open standard, supports authentication, and is not proprietary to a specific manufacturer. Vendor shall configure authentication to reduce the likelihood of a rogue router poisoning the route table. To simplify administration of the OSPF areas, the Vendor shall number the areas using dotted decimal notation, and for areas other than area 0.0.0.0, the area number shall be the IP subnet address of the area in question. The area assignments shall be managed through the IPAM, in the same manner as IP address assignments.

The IP routing protocol shall be set up to provide automatic IP rerouting in the event of a failure of any network facility or component and in the presence of a redundant path around the failure point. Of particular concern with dynamic IP rerouting is the behavior of the network in the event of a device or facility that is rapidly transitioning between an operative and an inoperative state and back again, commonly referred to as flapping. The dynamic routing protocol shall be configured to prevent instability of the network and to prevent serious loss of bandwidth due to routing table updates or other harmful behavior in the presence of a flapping device or other such intermittent problem, while still providing automatic rerouting.




6.2.13.2. Exterior Gateway Routing


For connections outside the IP network, the Vendor shall use the Border Gateway Protocol (BGP) as defined in IETF RFCs, including RFC4271, and commonly implemented for routing between disparate entities. MPLS circuits also use the BGP routing protocol. As with OSPF above, the Vendor shall implement authentication with BGP peers to reduce the likelihood of a rogue router poisoning the route table. For any MPLS circuits that may be required to implement the IP network, the BGP configuration shall use private Autonomous System Numbers (ASNs).




6.2.13.3. Multicast Routing

All routers and switches shall support multicast routing and switching. The applicable base protocols are Internet Group Management Protocol (IGMP) and Protocol Independent Multicast (PIM). These protocols handle the routing of join and leave requests for the multicast streams across both local and wide-area networks. IGMP version 3 (IGMPv3) is the most current version and is defined in RFC 3376. This RFC was amended by RFC 4604 which added Multicast Listener Discovery (MLDv2), which provides the equivalent functionality for IPv6. There are four varieties of PIM: sparse mode (RFC 4601), dense mode (RFC 3973), bidirectional mode (RFC 5015), and source-specific mode (RFC 3569).




6.2.13.4. Common Routing Requirements

The IP routing protocols shall provide for the delivery of IP packets from any IP address to any other IP address in the Kansas network or in any connected IP network or in any reachable IP network through


a connected IP network. The routing protocol shall be configured for fast packet reroute and shall work in conjunction with Bidirectional Forwarding Detection (BFD).

Vendor shall configure the IP network and work with the operators of interconnected IP networks to resolve IP routing problems as part of the supplied service.

These protocols are the primary protocols used by service providers and large enterprises, and the skillsets required for planning, configuration, and implementation are widely available. The base RFCs for these protocols are listed in Appendix B.

Incorrect configurations or changes of IP routing present a serious threat to the availability of an IP network. Bidder shall describe their change management procedure with respect to network changes and updates, and explain how they mitigate the risk of human error in managing IP routing in the proposed network.

Bidder shall provide a short narrative describing the IP routing protocol implementation. This narrative shall also describe how the network shall respond to various failure scenarios and how route instability in the network will be avoided.




6.2.14. Quality of Service

The proposed network shall implement a Quality of Service (QoS) function to assure timely delivery of critical packets even in the presence of network congestion from other non-real-time protocols, up to the limit of the available bandwidth. QoS support for RTP streams shall be configured into the network. The overall network design shall minimize excessive latency and jitter.

The QoS system shall also be able to prioritize other non-real-time traffic, such as SIP messaging traffic and network management traffic as needed. Refer to Appendix B for a Differentiated Services Code Point (DSCP) and IP Precedence chart.

The QoS schema proposed shall ensure that a specific RTP session does not share bandwidth on redundant links. This requirement is to ensure that RTP packets in User Datagram Protocol (UDP) streams do not arrive at the destination out of sequence should the redundant links have considerably


different latencies. The proposal shall include a brief narrative describing how the proposed system avoids this possible source of degradation of voice quality.

Interconnections with other IP networks will require cooperation to ensure QoS is maintained for traffic traversing these network-to-network interfaces. Vendor shall work cooperatively with the operators of interconnecting networks to resolve QoS and voice quality issues should they arise, regardless of the source of the issue, as part of the network management component of the pricing.

The development of new protocols or technologies may require modification or changes to the QoS scheme. Bidder shall address their strategy for dealing with QoS changes that may be required in the future.

It is the Council’s desire to understand how the proposed solution will provide the required QoS functionality. Bidder shall provide an overview of how they prioritize traffic across the network. The narrative should discuss topics such a:

what network elements make QoS decisions how priority packets are identified how network elements handle congestion scenarios what mechanisms are used to provide priority to media streams.

Any interaction between the QoS implementation, IP routing, or other protocols shall be explained. Bidder shall explain what mechanisms or strategies, if any, are present in the proposed network to mitigate this potential problem.




6.2.15. Network Address Translation (NAT)

The use of NAT within the proposed network solution is highly discouraged. Nevertheless, NAT capability at POIs with other IP networks may be required in order to resolve possible IP addressing issues. Bidder shall review the requirements in Section 5.7, which are intended to reduce the need for NAT.

NAT presents special problems for the reliable implementation of SIP and Real-time Transport Protocol (RTP) streams that traverse the NAT device. Bidder that propose the use of NAT shall be prepared to


demonstrate their understanding of the SIP/NAT problem, and explain how they intend to mitigate any issues that might arise. The Council may require special contract language to assure reliable operation of the network for its intended purposes in the presence of NAT.




6.3. AUXILIARY IP NETWORKS

Other IP networks may presently exist or may be constructed in the near future, for many purposes. For example, Kansas (through KCJIS) currently leases an MPLS network that connects to almost all of these same PSAP sites. This non-redundant IP network provides access to NCIC and other similar databases for the PSAPs. Wideband public Internet is also present at many PSAP sites. For purposes of this RFP, such networks are considered “auxiliary” IP networks.

The service levels associated with such existing IP networks are undetermined, and their suitability for the purposes of this RFP is unknown. For example, the Internet provides no QoS, no guaranteed service levels, no security, and no other features requested in this RFP. Generally speaking, the use of the public Internet, in itself, is not considered a viable alternative for a public safety IP network.

The Council wishes the option of leveraging auxiliary IP networks to mitigate outages, supplement bandwidth, or improve the survivability of the public safety IP network. Vendor shall provide the option of an additional Ethernet interface at specific sites that can be used to interconnect to one of these auxiliary IP networks. A static IP address from the auxiliary network’s address space is assigned to this interface for the purpose of creating an encrypted tunnel or Virtual Private Network (VPN) between the PSAP and the state data centers. This foreign IP address is not routed and is not addressable from the Kansas IP network, or vice versa.

The public safety network can then assign its own IP addresses to the tunnel interfaces, and the QoS system can route low-priority traffic via the tunnel. The encrypted tunnel is a virtual point-to-point IP connection for the public safety IP network, which uses the auxiliary network as transport, but which otherwise cannot and does not interconnect or interoperate with the auxiliary network.





6.4. NEW NETWORK EQUIPMENT

Only new equipment shall be considered. Refurbished or used equipment shall not be considered as part of the proposed solution. Proposed hardware shall be in current manufacture and currently under a warranty agreement or maintenance agreement. If a proposed device goes into end-of-life within the contract period, its equivalent or better current manufacture shall be installed. Vendor shall include the life cycle of the proposed solution or equipment, including end-of-sale, end-of-support and end-of-life dates. This is not meant to preclude the use of existing equipment when and where possible.

The network equipment in the Data Centers shall be chassis-based devices with redundant, hot-swappable power supplies, processors, and interface cards. This equipment is often referred to as “carrier grade” and typically is designed with a chassis service life of 15 years or more. Vendor shall provide their proposed replacement schedule for processors, memory, power supplies, and line cards. Smaller access switches and routers shall be included on this replacement schedule.

While there are many excellent manufacturers of network equipment, and each one conforms to recognized standards, there can sometimes be a slight difference in the implementation of those standards. For this reason, mixing of manufacturers shall be avoided, especially within and between Data Centers.




6.5. VIRTUAL LOCAL AREA NETWORKS (VLANS)

A VLAN allows network administrators to isolate traffic at Layer 2 of the OSI network model. Since the overall network view from the Council’s standpoint will be at Layer 3, this section primarily applies to the backbones and Data Centers. The Bidder shall explain their use of multiple VLANs at each Data Center to separate the network traffic by functionality. Some of this VLAN design may be influenced by future security policies and procedures, especially Criminal Justice Information Services (CJIS) compliance. The Bidder shall explain their methodology for making and managing changes.





6.5.1. VLAN Design

The internal VLANs shall have associated router interfaces to allow traffic to move between them as required. Traffic between VLANs shall be regulated to allow only the traffic pertinent to a given VLAN into or out of that VLAN.

The use of multiple VLANs also limits the impact of problems by allowing portions of the network to be isolated without taking down the whole network. Additional VLANs shall be used outside the firewalls for interconnection to partner agencies and service providers. These would not have routing interfaces associated with them on the switches as that would be handled by the firewalls and Session Border Controllers (SBCs) controlling access to those demilitarized zones (DMZs).




6.5.2. VLAN Management

VLAN information shall be accessible by authorized parties via a web portal. VLAN assignments shall be managed within the IPAM system.



Provide a detailed explanation and associated drawings explaining how the proposed solution


meets or exceeds the above requirements.

6.5.3. Multicast Routing and Switching

All routers and switches shall support multicast routing and switching. The applicable base protocols are Internet Group Management Protocol (IGMP) and Protocol Independent Multicast (PIM). These protocols handle the routing of join and leave requests for the multicast streams across both local and wide area networks.

IGMP version 3 (IGMPv3) is the most current version and is defined in RFC 3376. This RFC was amended by RFC 4604, which added Multicast Listener Discovery (MLDv2), which provides the equivalent functionality for IPv6. There are four varieties of PIM: sparse mode (RFC 4601), dense mode (RFC 3973), bidirectional mode (RFC 5015), and source-specific mode (RFC 3569).




6.6. DATA ENCRYPTION

The IP network will have interconnections with other agency, partner, and carrier networks via encrypted connections. Direct firewall-protected connections shall be provided from the Council’s partner agencies to DMZs established solely for those agencies at each Data Center. These connections shall be Ethernet at Layer 2 to keep the network as uniform as possible, and to allow for maximum network flexibility and expansion. Though this traffic will not cross the public internet, it shall be encrypted.

Service provider traffic shall be handled through a separate set of DMZs at each Data Center. The DMZs could exist on the same physical piece of equipment as the partner DMZs. The firewalls and SBCs shall be carrier grade devices (chassis-based with power, processor, and interface redundancy). The SBCs and firewalls shall be in place before the State can host the IP selective router functionality

Some wireless companies offer a private data network service across their 3G/4G data service that isolates traffic from other users’ traffic on the network. If this type of service is implemented as a


backup anywhere in the IP network, the connection between the carrier and the IP network shall be made through a firewall for security purposes.

Figure 6 illustrates partner and service provider connections to the IP network via redundant, resilient firewalls located at the three (3) Data Centers.

Figure 6 Complete Network Overview




6.6.1. Network Risks

Bidder’s solutions shall account for the mitigation of possible risks. The risks outlined are common to all participating facilities. Bidder shall discuss their mitigation strategies for:

Route poisoning


Major network upgrades or changes Service impacts due to network failure Lack of access circuit diversity, their lack of geographic route diversity for secondary access

circuits or their lack of secondary routing (case by case) Lack of alternate routing for infrastructure (core) or services Any single point of failure within the network end-to-end Unsecure PSAPs or other endpoints on the network Unauthorized or unauthenticated users or devices on the network




6.6.2. Network Diagrams

Vendor shall provide conceptual network diagrams of their proposed solution, including but not limited to the following:

Overall network interconnection, inclusive of redundant links Points of Presence (POPs) for the entire subject areas Demarcation Site specific hardware connectivity showing redundant hardware connectivity

Network diagram detail shall allow for the clear assessment of a Vendor’s solution and readily identify items such as cable or fiber elements, primary routes, backup routes, core and endpoint router types, secondary or tertiary power sources, data centers, wireless connections, and off-network connections.

6.6.2.1. Diagrams as a Deliverable upon Completion of the Network

Upon completion of the IP Network, including Regional Rings, POPs, POIs, Data Centers, and any other facilities, Vendor shall deliver complete, detailed network and facility drawings. These drawings shall show all primary and backup backbone links (Statewide and Regional), and primary and backup PSAP links. Rack diagrams shall include the devices with names and Rack Unit (RU) location designation, cable callouts, cross connect panel callouts, Power Distribution Unit (PDU) outlet numbers and breaker designations. Updated versions of these diagrams shall be provided as part of any adds, moves, and changes during the contract period.





6.7. GENERAL NETWORK DEVICE SECURITY

All switch ports not in use shall be explicitly shut down, and trunk and access ports shall be explicitly configured for the VLANs allowed on those ports. Ports shall also be limited to a single MAC address for added security. If it is necessary to allow multiple MAC addresses on a single port, that shall be handled as an exception and documented through change management. The primary reason for needing multiple MACs on a single port would be to use a network sniffer in troubleshooting a problem. An alternative might be to turn up a temporary port on the core switch and span it to the port under test. If Vendor desires a single maintenance port per device, such a provision will be considered on the condition that it is the same port on each class of device and all devices are within a secure area.

Network equipment shall be protected by security and access control systems that ensure only duly authorized individuals can access the Council’s network equipment. Any devices, power distribution, and cross connect panels feeding the cages or rooms housing the Council’s systems shall be similarly protected. Reporting requirements are detailed in Section 8.2.10.

Vendor shall track and log all attempts to access the colocation areas housing the Council’s network equipment. Monthly reports shall be provided for review as part of the problem management reporting referenced in Section 8.2.10. Security violations should be reported to the Network Operations Center (NOC) having overarching management and monitoring responsibility.

All Council network equipment shall be housed either in a locked and monitored cage within a secure Data Center, or its own locked and monitored room within a secure data center. Providing space in a common area is not permitted.





6.8. DEVICE NAMING AND LABELING, AND CABLE LABELING

The Vendor shall implement device labeling, and data cable color coding and labeling in all facilities, including PSAPs. All cabinets, racks, patch panels, and devices within the cabinets and racks shall be identified and clearly labeled front and rear. All power and data cables shall be clearly labeled with their source and destination.

Vendor shall maintain the correct color coding and labeling through additions, moves, and changes. Vendor shall avoid yellow and orange for twisted pair cables as these are standard colors for single mode and multimode fiber, respectively.

Proper spacing, typically greater than four (4) inches, shall be maintained between power and data cables. To the maximum extent possible, power and data cables shall not run parallel to each other. This rule does not apply to fiber optic cable. Fiber optic cable and jumpers shall, to the maximum extent possible, be run separately from twisted pair cable to avoid the possibility of physical damage. Where this is not possible, the fiber optic jumpers shall be protected with split cable loom (a corrugated plastic sleeve) or spiral wrap. This method of protection shall also be used at any point in the cable management system where the fiber transitions from one ladder rack or cable trough to another ladder rack or cable trough. Cable transitions to or from ladder racks shall be via a cable dump over the side, not through the rungs of the ladder rack.

Vendor shall provide documentation of their processes and procedures for maintaining the color coding and labeling standards through adds, moves, and changes. Vendor shall also provide a detailed explanation and associated drawings explaining how their proposed solution meets or exceeds the above requirements.




6.9. NETWORK PERFORMANCE

6.9.1. Network Latency

Vendor shall specify the maximum guaranteed latency across their backbone network.





6.9.1.1. POP to POP

Vendor shall specify the maximum guaranteed latency from interconnection facility to interconnection facility.




6.9.1.2. POP to Endpoints

Vendor shall specify the maximum guaranteed latency from interconnection facilities to the network interface device located at the entrance to the customer’s premise.




6.9.2. Packet Loss


Vendor shall specify the maximum guaranteed end-to-end packet loss across the respective Bidder’s network. This specification shall also include any loss characteristics associated with another carrier’s network or any applicable wireless links.




6.9.3. Network Traffic Convergence

Vendor shall specify convergence protocols and the estimated or guaranteed network convergence time (<54ms) of IP traffic at any point within the proposed solution.




6.9.4. Mean Time to Repair

Vendor shall specify their Mean Time to Repair (MTTR) characteristics of their proposed solutions. These specifications shall reflect the end-to-end solution as well as network components or subsystems that are subject to failure.





6.9.5. Mean Time Between Failure

Vendor shall specify the Mean Time Between Failure (MTBF) characteristics of their proposed solutions. These specifications shall reflect the end-to-end solution as well as network components or subsystems that are subject to failure.




6.9.6. Network Availability

Vendor shall specify the service level offered as a percentage of time when the service is available and the maximum period of total outage before remedies are activated. Availability is defined as MTBF/ (MTBF+MTTR).




6.9.7. Remedies

Vendor shall define the financial remedies to the Council and their respective specified agencies, for each event in which service levels are not maintained. Vendor’s network devices and services shall perform at a level of 99.999% uptime. Vendor shall comply with the SLAs presented in Appendix E. Failure to meet SLAs shall be measured per service-affecting outage. Penalties shall be assessed for failure to meet SLAs.





6.10. PROJECT MANAGEMENTVendor shall include in their bid and proposal a separate and tentative project plan for each subsystem bid. Vendor shall discuss their familiarity and experience with project management of projects having comparable size and scope as the subsystem bid. Bid shall discuss experience with the Kansas (KITO) Project Management Methodology, if applicable.

The project plan shall address as a minimum:

Articulate your project management methodology:o Planningo Concept definitiono Designo Requirements Definitiono Implementationo Integration o Test and Evaluation (T&E)o Project Tracking and Reportingo Project Close-outo Operations and Maintenance (O&M) including Day-2 Support

Gantt Scheduleo Identify critical path activities o Describe your schedule software tools

Major Milestoneso Identify all critical milestones o ensure that the interval between major milestones does not exceed 30 days

Resource Plano Who, by name, do you intend to assign to this projecto What are their credentials, and how will their credentials benefit to projecto How long will they be assignedo What percent of their time are they dedicated o Include and identify any and all subcontractors and / or consultants

Cost and Schedule Control System (C/SCS)o What experience do you have with C/SCSo What C/SCS tools, formal or informal, will you use

Communication Plano What is your approach for communication during project executiono Describe your jeopardy and escalation process


Change Management (CM)o Describe how your CM plan, process and procedure will integrate with our CM Plan

which is included as part of this bid package Risk Management

o Discuss significant potential riskso What is the probability of occurrenceo What is the impacto What are your tentative risk mitigation strategies

Documentation Management.o What is your documentation control processo How does it integrate with your CM process

Configuration Controlo What is your configuration control processo How does it integrate with your CM process

Facilities Managemento Describe the facilities that you intend to use for all phases of project developmento Include your Operational Security Plan including physical security, IT securityo Describe your Disaster Readiness and Recovery (DRR) plano Describe your Business Continuity Plan

Government-Furnished Deliverableso What do you need from the state of Kansas to accomplish your project including such

things as information, property or other.

Bidder shall provide a detailed explanation of how their proposed solution meets or exceeds the above requirements.



Provide a detailed explanation of how the proposed solution meets or exceeds the above requirements.

6.11. CHANGE MANAGEMENT

Vendor shall adhere to the policies, procedures, and requirements as outlined in “Kansas NG9-1-1 Change Management (CM) Policy.” This is a living document and, therefore, will be revised over time. Vendor shall explain any differences between their change management policies and procedures and those set forth in the Council’s CM Policy. Vendor shall demonstrate an understanding of the concepts


of change management as well as their implementation of change management policies, processes, procedures, and systems.






7. SYSTEM DATA CENTERS

Vendor shall furnish three (3) Data Centers. The Data Centers will meet Tier 4 standards as detailed in American National Standards Institute/Telecommunications Industry Association/Electronic Industries Association (ANSI/TIA/EIA) 942 Data Center Standards, but at a minimum shall meet Tier 3 standards to be considered as a viable location. The Data Centers shall be separated by at least 100 miles for sufficient and adequate geospatial isolation in the event of a widespread disaster.

Vendor shall explain in detail the difference between their current level of compliance with TIA-942 and the Tier 4 specifications of TIA-942 as well as any plans and associated timelines for upgrading to Tier 4 specifications.

TIA-606 lays out a complete marking standard for data centers using a 2’ grid of the room and designating each square with letters and numbers starting at AA01. While strict conformance with TIA-606 as to naming is not required, Vendor shall use an industry best practice naming convention. The naming convention shall be applied uniformly across all facilities including PSAP locations. All cabinets, racks, patch panels, and devices within said cabinets and racks shall be identified and labeled front and rear. All cables, power and data, shall be labeled at each end with source and destination.




7.1.1. Cabinets and Power Distribution

The equipment cabinets shall be 30 inches wide by 48 inches deep by 84 inches high with 19-inch spacing of the mounting rails. The rails shall be centered in the cabinet, and shall have square mounting holes to accommodate snap-in rail systems. This size cabinet provides 45 rack units (RU) of space. To accommodate devices without snap-in rails, caged nuts and matching machine screws having #12-24 thread shall be used.

The front and rear cabinet doors shall be vented. If any equipment to be mounted in the racks has side-to-side air circulation, the cabinets shall be equipped with a minimum of two (2) fans in the top to move warm air out of the cabinet. Otherwise, a mesh top is sufficient. The cabinet shall be equipped with internal power and data cable management.


The PDUs used within the cabinets shall be remotely manageable via SNMP and web browser, and provide load and other status information back to the network management system. The PDUs shall have individually controllable outlets to allow remote power-cycling of equipment that may be otherwise unresponsive. All power cords shall be labeled at both ends with their source and destination. Each cabinet shall have dual PDUs powered from separate sources.

Vendor shall design physical packaging to provide reasonable space for future growth. Vendor shall not package their system in the shortest rack possible. The Council will approve the cabinet and PDU specifications, in order to maintain a standard data center design.




7.1.2. Data and Power Cabling

The Vendor shall implement data cable color coding and labeling in all facilities, including PSAPs. All cabinets, racks, patch panels, and devices within the cabinets and racks shall be identified and labeled front and rear. Cables shall be labeled with their source and destination.

The Vendor shall maintain the correct color coding and labeling throughout the Move-Add-Change-Delete (MACD) process. The Vendor shall avoid yellow and orange for twisted pair cables as these are standard colors for single mode and multimode fiber, respectively.

At least four (4) inches of separation shall be maintained between power and data cables. To the extent possible, power and data cables shall not run parallel to each other. This does not apply to fiber optic cable. Fiber optic cable and jumpers shall, to the extent possible, be run separately from twisted pair cable to avoid the possibility of physical damage. Where this is not possible, the fiber optic jumpers shall be protected with split cable loom (a corrugated plastic sleeve) or spiral wrap. This method of protection shall also be used at any point in the cable management system where the fiber transitions from one ladder rack or cable trough to another ladder rack or cable trough. Cable transitions to or from ladder racks shall be via a cable dump over the side, not through the rungs of the ladder rack.

Vendor shall provide documentation of their processes and procedures for maintaining the color coding and labeling standards throughout the MACD process. Vendor shall also provide a detailed explanation and associated drawings explaining how their proposed solution meets or exceeds the above requirements.





7.1.3. Physical Security and Access

The Data Centers shall have security and access control systems that ensure only duly authorized individuals can access the cage or room housing the Council’s systems and network equipment. Any devices, power distribution, and cross connect panels feeding the cages or rooms housing the Council’s systems shall be similarly protected. Reporting requirements are detailed in Section 8.2.10.

Vendor shall track and log all attempts to access the colocation areas housing the Council’s systems and equipment. Monthly reports shall be provided for review as part of the problem management reporting referenced in Section 8.2.10. Security violations shall be reported to NOC having overarching management and monitoring responsibility.

All Council systems and network equipment shall be housed either in a locked and monitored cage within a secure data center, or its own locked and monitored room within a secure data center. Vendor shall place equipment in any common areas.




7.2. SERVERS AND SOFTWARE

The network and i3 services are provided by an array of firewalls, routers, gateways, and servers. The servers may also include SAN or NAS devices, which are high capacity, redundant, resilient disk storage systems. The physical servers shall be running a virtual server environment such as VMware or Citrix, which extends the redundancy and resiliency to the software level. The same theory applies to the hard disk storage systems. Implementing a SAN or NAS brings redundancy and resiliency to the data storage components.


All server and storage devices shall have redundant power supplies connected to separate remotely manageable PDUs.




7.2.1. Server and Storage Hardware and Software

Server virtualization and network storage systems, either Storage Area Networks (SANs) or Network-Attached Storage, (NAS), shall be implemented to provide a more robust environment than discrete servers. For any servers and storage systems required for implementing the IP network and its services, Vendor shall implement systems in the Unix/Linux operating environment for security reasons.

Each SAN or NAS shall have the ability to provide backup services to the devices in their neighboring Data Centers.

Server hardware shall be replaced every three (3) to five (5) years. Old servers may be relegated to less critical uses within the network, such as lab systems. Software shall be upgraded as recommended by the manufacturer and/or Vendor, or industry best practice, pursuant to testing requirements implemented under change management controls.




7.2.2. Server Installation

The servers shall be installed in the racks as specified above. One blank RU shall be left between all devices in the racks. These empty slots shall be covered with a blank panel allowing for air circulation


around the devices in the event equipment overheats. Systems that are pre-racked from the manufacturer or integrator shall meet these same specifications herein.

All devices in the racks shall be labeled front and rear with their device name. This name will be used in the power and data cable labeling as well.




7.3. NETWORK SERVICES

7.3.1. Domain Name Services

Domain Name Services, (DNS), is a core network service that shall be supported on the IP network. Use of the Linux operating system and open source software such as Internet Systems Consortium’s (ISC’s) BIND (DNS) package is preferred.




7.3.2. SNMP

Simple Network Management Protocol (SNMP) is the underlying protocol for transmitting management information such as alarms, resource utilization, network, and server statistics to one or more management systems that translate the data to usable information such as alarm notifications, bandwidth utilization graphs, and processor utilization graphs. Version 3 of SNMP (SNMPv3) is the latest release, and added cryptography and configuration enhancements. For security reasons, this shall be the version implemented. The applicable RFCs are 3411 through 3418.





7.3.3. Other Common Network Services

Other common network services include e-mail, web hosting (Hypertext Transfer Protocol [HTTP]/HTTP Secure [HTTPS]), File Transfer Protocol (FTP), Active Directory, Secure Shell (SSH), and Network Time Protocol (NTP).

NTP synchronizes the system clocks to a time standard, usually a network clock device with an Ethernet interface. These network clocks typically receive their synchronization signals from a global positioning system (GPS) satellite or similar radio signal. There are also NTP sources available via the Internet, but for the purposes of the IP network, internal network clocks shall be installed at each data center. These network clocks can also provide time synchronization to the PSAPs, either as the primary or backup clock.

As a security best-practice, only the services that are required for a given server to function and be accessible for management purposes shall be enabled on systems. For instance, SSH is preferred over telnet for command line access on servers. Telnet shall be disabled on the server(s), and the access rules for that VLAN shall block it, but pass SSH from allowed address ranges.

The network shall be monitored for services not allowed, such as DHCP, to ensure rogue devices and services are not injected into the network.




7.4. SYSTEM PERFORMANCE


7.4.1. Mean Time to Repair

Vendor shall specify their MTTR characteristics of their proposed solutions. These specifications should reflect the end-to-end solution as well as components or subsystems that are subject to failure.




7.4.2. Mean Time Between Failures

Vendor shall specify the MTBF characteristics of their proposed solutions. These specifications should reflect the end-to-end solution as well as components or subsystems that are subject to failure.




7.4.3. System Availability

Vendor shall specify the service level offered as a percentage of time when the service is available and the maximum period of total outage before remedies are activated. Availability is defined as MTBF/ (MTBF+MTTR).





7.4.4. Remedies

Vendor shall define the financial remedies to the Council and their respective specified agencies, for each event in which service levels are not maintained. Vendor’s network devices and services shall perform at a level of 99.999% uptime. Vendor shall comply with the SLAs presented in Appendix E. Failure to meet SLAs shall be measured per service-affecting outage. Penalties shall be assessed for failure to meet SLAs.




7.5. STANDARDS FOR ATTESTATION ENGAGEMENTS

Vendor shall demonstrate compliance with the Statement on Standards for Attestation Engagements Number 16 (SSAE16). This replaced Statement on Accounting Standards 70 (SAS70) in 2011. The applicable report from an SSAE16 engagement is the Service Organization Controls 1 (SOC1) report.




7.6. PROJECT MANAGEMENTBidder shall include in their bid and proposal a separate and tentative project plan for each subsystem bid. Bidder shall discuss their familiarity and experience with project management of projects having comparable size and scope as the subsystem bid. Bid shall discuss experience with the Kansas (KITO) Project Management Methodology, if applicable.


Articulate your project management methodology:o Planningo Concept definition


o Designo Requirements Definitiono Implementationo Integration o Test and Evaluation (T&E)o Project Tracking and Reportingo Project Close-outo Operations and Maintenance (O&M) including Day-2 Support


Major Milestoneso Identify all critical milestones o ensure that the interval between major milestones does not exceed 30 days









Facilities Management


o Describe the facilities that you intend to use for all phases of project developmento Include your Operational Security Plan including physical security, IT securityo Describe your Disaster Readiness and Recovery (DRR) plano Describe your Business Continuity Plan







Vendor shall adhere to the policies, procedures, and requirements of the Kansas NG9-1-1 Change Management Policy. This is a living document and will change over time. Vendor shall explain any difference between their change management policies and procedures and those set forth in the Council’s CM Policy. Vendor shall demonstrate an understanding of the concepts of change management as well as their implementation of change management policies, processes, procedures, and systems.





8. NETWORK AND APPLICATION MANAGEMENT AND MONITORING

8.1. NETWORK AND APPLICATION MANAGEMENT

Network and application monitoring will require significant attention. Having both internal and external entities, and potentially other IP networks, adds complexity to the level of monitoring that public safety IP networks require. All IP Network, i3 Call Handling, and i3 Service Providers shall demonstrate a clear and thorough understanding of the intra-state interoperability requirements of a NG9-1-1 System. As the IP networks of neighboring states are connected to the Kansas IP Network, the Monitoring and Maintenance Plan furnished by Vendor shall address inter-state interconnectivity and interoperability with the same rigor as intra-state interconnectivity and interoperability.

Given that this is a statewide endeavor, there will be a number of entities involved in building the network. Each will have their own monitoring and management system for their infrastructure, their own Network Operations Center (NOC) for trouble tickets and reporting, and their own operating policies and procedures for the aforementioned. The Council prefers a single entity having overarching monitoring and management responsibilities for the IP network. This includes monitoring out to the device at the PSAP, preferably with full device access, but at least at the port up/down level. The selected entity, be it a service provider or public agency, shall also maintain a problem management system for tracking and reporting trouble and a change management system for tracking and reporting changes to the network and systems, and shall be prepared to handle the issuance of Reason for Outage (RFO) reports when outages occur.

Management and monitoring Vendor shall provide the following services and supporting documentation:

Maintain a 24x7x365 NOC Provide Levels 1, 2, and 3 technical support Provide a service portal for opening trouble tickets and change requests, and checking status of

existing tickets/requests Provide network and server statistics including, but not limited to, uptime, latency, jitter, packet

loss, bandwidth utilization, Mean Opinion Score (MOS), and processor and memory utilization via a web portal

Provide documented escalation procedures Provide documented change management procedures Provide monthly trouble reports showing tickets opened, resolved, and unresolved Provide regular change reports showing changes requested, approved, completed, in progress,

and failed/backed out Issue RFOs within a reasonable time as defined by industry best practice.

Vendor shall provide critical network services to other customers similar in nature to 911, such as governments, hospitals, or financial institutions. Problem and change management are critical components of network and application monitoring and management and shall be addressed by a comprehensive and thorough operational support plan.





8.2. MONITORING PLAN

In the event that the Council elects to extend i3 services and i3 call handling CPE capabilities to other entities such as surrounding states and Kansas MARC, then reporting and alerting concerns would likely change. The reason is that entities would require additional reporting and alerting capabilities. In addition, deploying NG9-1-1 and other public safety-related applications across networks requires that interworking and interoperability governance agreements, processes and procedures be developed for monitoring the network before any live NG9-1-1 calls are handled at a PSAP.

Other entities connecting with Kansas’ infrastructure will require additional reporting and alerting capabilities. Administrative monitoring information that shall be documented includes, without limitation, the following:

Discovery and documentation of all devices with which the Council will be connecting. In instances where Kansas is connected to other entities, written processes and procedures for discovery and documentation of added devices, and documentation of when devices are taken off-line or changed, shall be captured and agreed upon as part of the contract or agreement.

As NG9-1-1 technology involves multiple applications, respective providers will most likely desire the ability to connect and have access to both their software and related hardware elements. This is usually part of that software and hardware provider’s support and maintenance and the contract shall include SLAs against which the Vendor’s performance commitment is evaluated.

Notification processes of hardware and software faults and alarms will need to be thoroughly described and understood. Scripts for communicating with entities shall be developed.

Processes and procedures for end-to-end monitoring of network QoS features shall be developed and implemented. QoS shall be evaluated and monitored iteratively.

Vendor solution shall have the ability to dynamically adjust bandwidth and traffic shall be considered along with other capabilities that will help avoid network saturation.

The perception of the system administrator’s ability to monitor the network will be greatly impacted by communication and information sharing processes.

The solution shall require the ability to provide historical and real-time reports on network status, malicious network activity, and other pertinent information.





8.2.1. Network Monitoring

Vendor shall monitor and report on the entire NG9-1-1 network on a 24/7 basis, including all devices attached to the network. Vendor shall furnish a Network Operations Center (NOC) staffed to support 24x7 restoral or mitigation of incidents. Vendor shall provide a 24x7 toll free number accessible to Council-authorized personnel.

Note: the use of the network-provider monitoring system does not preclude the Council from installing and using its own monitoring system for remotely monitoring PSAP equipment, using the IP Network for remote environmental monitoring of connected sites or other such applications.




8.2.2. Network Fault Management

Vendor fault management shall detect, log, and notify the network operator, and depending on severity and policy, Council staff, of IP Network problems such as failed circuits, equipment, or network functions. If the failure corrects itself within 60 seconds notification is not required, but all events shall be logged and reported. Vendor shall notify the Council Point of Contact via phone, text messaging and email.





8.2.3. Network Performance Management

Performance management shall measure the variables that affect network performance. Network performance reports describing overall network usage, congestion events, outages, and other such data shall be required on a monthly basis. This should include a review of trouble tickets and their status.

Network performance management data access is required from all manageable IP devices as specified in contractual agreements. Network performance management and reports shall be priced as an itemized option in the Cost Proposal pricing template only.

Vendor shall provide detailed descriptions of what performance data shall be collected and how this data shall be logged and reported, including such details as how alarm thresholds are determined.

All IP manageable network hardware shall support the SNMP v3 specification for performance management via standard management information base (MIB) objects forwarded to or extracted by any Council designee.




8.2.4. Information Storage and Retrieval

Vendor shall describe how their proposed solution stores and retrieves information for reporting purposes, including portal access and ad hoc reporting features. The description should include comments regarding any requirements made upon the Council for this feature. The Vendor shall maintain access to the data for the term of the contract, and any extensions.





8.2.5. Incident Management System

The incident management system of Vendor shall log all support requests, both from users and those automatically generated. The system shall interface with the change management system for correlation of outages and changes. Vendor shall provide monthly reports detailing tickets opened, resolved, and pending.




8.2.6. Change Management System

Vendor change management system shall log all change requests, both from users and those automatically generated. The system shall interface with the incident management system for correlation of changes and outages. Vendor shall provide monthly reports detailing change tickets opened, resolved, and pending.

The Vendor shall also describe any other tools they intend to use to provide access to the change management system, such as web portals, client software, etc.





8.2.7. Network Logging

Vendor IP Network shall allow historical tracking of events and event resolution. It is preferable that this system be a part of or interfaced (or contain cross-reference abilities) with the Vendor’s trouble ticketing system. Vendor shall maintain historical information for the term of the contract, and provide copies of the data to the Council at the end of the contract.




8.2.8. Security Monitoring and Management

Vendor shall have a working knowledge of security standards found in documents such as, but not limited to, National Institute of Standards and Technology (NIST) 800-53 Revision 4, NENA 75-001, NENA Security for Next-Generation 9-1-1 (NG-SEC); NENA 08-002, Functional & Interface Standards for NG9-1-1 (i3); and NENA 08-751, NENA i3 Technical Requirements Document.

Vendor’s security management solution shall control access to network resources according to public safety network security guidelines to prevent sabotage (intentional or unintentional) and the compromise of sensitive information. Security management shall use public safety network security standards to monitor users logging into network resources and refuse access to those who enter inappropriate access codes. The IP Network shall support standard security policies that may include the use of anti-virus software, virtual LANs (VLANs), VPNs, and secure sockets layer (SSL) protocols. Any system that connects to an IP Network shall be required to comply with standards, including the security standards, and demonstrate compliance through an initial and recurring audit.

Although the Kansas IP Network shall start as a closed network solution, Vendor security policies, processes and procedures shall be designed so that when the Council chooses to connect to adjacent IP networks the proposed security components shall not require a forklift replacement.

Network security performance and violations shall be reported monthly by Vendor, and in the case of violations, within 24 hours of discovery. Performance statistics may include, but are not limited to, such items as failed access attempts, locked usernames, and attacks detected.





8.2.9. Physical Access Monitoring and Management

Vendor shall track and log all attempts to access the colocation areas housing the Council’s systems and equipment referenced in Section 4.10.3. Monthly reports shall be provided for review as part of the problem management reporting referenced in Section 8.2.6. Security violations should be reported to the NOC having overarching monitoring and management responsibility, who will inform the state designee within 24 hours.




8.2.10. Management Software

Vendor shall name and describe the management software proposed including all functional modules associated with it (reporting, backup, IPAM, etc.).





8.2.11. Network Configuration Management

Vendor shall describe the processes and procedures they follow for making changes to the network configuration, such as adding a connection, re-provisioning a circuit, or changing a QoS priority in realizing 99.999 percent (five nines) network availability. Configuration Management shall follow the defined Changed Management Policy. The description should include procedures such as how proposed changes are planned, authorized, authored, reviewed, advertised, implemented, tested, backed out, and backed up, and the personnel involved. The role and any requirements upon the Council in this process shall be defined.




8.2.12. Configuration Backup and Restoration

Vendor shall describe their capability to automatically or routinely backup configuration data, and the process and conditions used to restore the configuration of network elements such as routers or switches, should the need arise.

In addition to automatic, regular backups, Vendor shall describe their ability to perform on-demand backups, such as at the end of a successful configuration change.




8.2.13. Reason for Outage Report


For major outages, Vendor shall provide the Council staff with an RFO within 24-48 hours for major outages, and upon request for minor outages. In the event a complete RFO cannot be provided with 24-48 hours, a preliminary report is required within that time frame, and a full RFO or a resolution plan is required within one (1) week. Vendor shall describe the tools and techniques at their disposal to perform troubleshooting and post-event analysis.




8.2.14. Preventive Maintenance

Vendor shall describe preventative maintenance activities to be included as part of a maintenance contract. This preventive maintenance plan shall address how preventative maintenance is handled, as well as the frequency of preventative maintenance activities. Vendor shall use support logs to drive the development of solutions to recurring issues and follow industry best practices.

All preventive maintenance activities shall be coordinated in advance with the Council and conducted in accordance with a mutually disclosed MOP and shall follow the defined Changed Management policies of the Council. Vendor shall make all attempts to assure that a remote location and its designated backup are not affected at the same time.




8.2.15. Scheduled Maintenance

Any maintenance by Vendor, including upgrades to the network, shall be coordinated in advance with the Council and conducted in accordance with a mutually disclosed MOP and shall follow the defined


Changed Management policies of the Council. Vendor shall ensure that a remote location and its designated backup are not affected at the same time.




8.2.16. Support Contracts

Vendor shall identify and specify support contracts for the life of the network contract.




8.2.17. Support Maintenance

Bidder shall furnish a 24x7x365 maintenance support for the life of purchase or leased solution.




8.2.18. Access to Technical Staff

Vendor shall detail the procedures by which selected technical personnel from participating facilities have access to the successful Vendor’s technical staff. Vendor shall specify the level of assistance


expected to participating facilities’ technical staff to resolve issues. Security personnel are expected to recommend solutions to various malicious network activities.




8.2.19. Notification

Vendor shall explain how their NOC informs participating facilities of problems with the network, scheduled outages, and upgrades. Tickets related to the services delivered to participating facilities shall be automatically forwarded.




8.2.20. Escalation Procedure

For Severity 1 incidents, the Council expects next-level escalation 30 minutes after initial response to the problem, and escalation every 30 minutes thereafter until the problem is resolved. For Severity 2 incidents, the Council expects escalation 1 hour after response and every hour thereafter until the problem is resolved. Appendix E provides minimum SLA expectations.

Bidder shall outline a detailed escalation process, including time limits between escalations, to be used during service-affecting and critical service outages. It is preferable that these procedures be maintained and accessible via an online portal.





8.2.21. Change Management Procedures

Vendor shall outline their processes for following the defined Changed Management Policy.




8.2.22. Remedies

Vendor shall provide financial remedies to the Council and their respective specified agencies, for each event in which service levels are not maintained. Vendor’s network devices and services to perform at a level of 99.999% uptime. Vendor shall meet the SLAs in Appendix E. Failure to meet SLAs shall be measured per service-affecting outage. Penalties shall be assessed for failure to meet SLAs.




8.3. VENDOR CONSIDERATIONS IN MONITORING PLANS

Vendor shall provide documented evidence of their policies, processes, and procedures for monitoring and managing their systems. Vendor contract negotiations will need to clarify Vendor network access requirements for i3 services and call handling system Vendor. Likewise, all i3-compatible call handling


and i3 services Vendor shall be aware of each other and the various entities that may require read-only status of their components.

When considering potential i3-compatible CPE Vendor and i3 service Vendor as potential providers of products and services, network critical elements, such as security, shall be kept in mind. Requirements that can impact providing secure services for all entities may impact the viability of a Vendor being considered for a potential product or as a service provider.




8.4. PROJECT MANAGEMENTVendor shall include in their bid and proposal a separate and tentative project plan for each subsystem bid. Vendor shall discuss their familiarity and experience with project management of projects having comparable size and scope as the subsystem bid. Bid shall discuss experience with the Kansas (KITO) Project Management Methodology, if applicable.




Major Milestones


o Identify all critical milestones o ensure that the interval between major milestones does not exceed 30 days

















Vendor shall adhere to the policies, procedures, and requirements of the Kansas NG9-1-1 Change Management Policy. This is a living document and will change. Vendor shall explain any differences between their change management policies and procedures and those set forth in the Council’s CM Policy. Vendor shall demonstrate an understanding of the concepts of change management as well as their implementation of change management policies, processes, procedures, and systems.





9. NG9-1-1 CALL HANDLING

9.1. CALL HANDLING ARCHITECTURE

Vendor may propose either a single manufacturer’s call handling systems in the Council’s Data Centers or a SaaS implementation, or both. SaaS incorporates the call processing being performed in a “cloud” or “service provider-hosted” format. Most SaaS solutions are accessed through a web browser, with often a browser-only or a thin-client loaded on a commercial off-the-shelf (COTS) hardware platform that only has to meet certain hardware and operating system (OS) specifications.

Manufacturers will vary on the amount of proprietary elements of hardware and software at the edge. One area where SaaS has a potential difference when compared to a solution in the regional data centers is when upgrades to the edge equipment are required: this change shall be included as part of the monthly price stated in the Cost Proposal template.




9.2. NG9-1-1 CALL HANDLING METHODOLOGY

Vendor’ Call Handling solution shall have a comprehensive roadmap evolving to NG9-1-1 capability with expected timelines. The methodology and roadmap shall include beta testing, milestone achievements or targeted goals, and monthly milestones.

Although full i3 functionality and capabilities is not part of this NG9-1-1 Call Handling, Vendor shall provide information concerning their plans to include these capabilities in the future with the proposed solution. Vendor shall provide information explaining how their proposed solution fits on the manufacturer’s roadmap, they shall clearly communicate what expected changes and modification of the proposed solution would be required to implement additional i3 functionality. Vendor shall also describe their policy for implementing these i3 elements, such as IP-based call routing including supporting documentation such as position papers, or partnerships and alliances, intended to further their methodology.





9.3. NENA INDUSTRY COLLABORATION EVENTS

NENA created a forum for different manufacturers to participate in an event to discuss and demonstrate interoperability between systems, named ICE. The Council recognizes the benefits of NENA’s NG9-1-1 Industry Collaboration Events (ICE).

Vendor shall describe: Which NENA NG9-1-1 Industry Collaboration Events has your company participated in? Which of your products did you test at the event(s)? Have you tested all of the products you are proposing in your response at the events? If not, which products have you not tested? If you have not participated in the events and/or not tested products proposed, please explain

your reason for not participating and/or testing. Do you intend to participate in future events? If so, which ones? If not, please explain.





10. NG9-1-1 CALL HANDLING REQUIREMENTS

While the requirements are the same or similar for either a state-level Data Center solution or SaaS solution, requirements differences are noted with italics.

10.1. CALL HANDLING LOCATIONS

The NG9-1-1 Coordinating Council intends to deploy the NG9-1-1 Call Handling subsystem in three (3) Data Centers. Vendor shall assume that the data centers will support resilient and redundant data transport services.

SaaS Vendor may need to connect to these locations for i3 services in the future as the State has not yet determined whether i3 services will be in the Data Centers or provided as a SaaS solution. Vendor shall propose a total solution whether in Data Centers or SaaS including any illustrations and communication paths that will be performed in a best practices model.

SaaS Vendor shall be willing to co-locate elements of their solution in the data centers. If the answer is affirmative, then a SaaS Bidder shall provide data center requirements for this co-location.




10.2. CALL HANDLING DATA CENTER REQUIREMENTS

The three Data Centers will meet Tier 4 standards as detailed in American National Standards Institute/ Telecommunications Industry Association/Electronic Industries Association (ANSI/TIA/EIA) 942 Data Center Standards, but at a minimum shall meet Tier 3 standards to be considered as a viable location. The Data Centers shall be separated a minimum of 100 miles apart for good geospatial separation in the event of a widespread disaster.

Vendor shall explain in detail the delta between their current level of compliance with TIA-942 and the Tier 4 specifications of TIA-942 along with any plans and timelines they may have to upgrade to Tier 4 specifications.

TIA-606 lays out a complete marking standard for data centers using a 2’ grid of the room and designating each square with letters and numbers starting at AA01. While strict conformance with TIA-606 as to naming is not required, use of a reasonable naming convention is required. The naming


convention shall be applied uniformly across all facilities, including PSAPs. All cabinets, racks, patch panels, and devices within said cabinets and racks shall be identified and labeled front and rear. All cables, power and data, shall be labeled at each end with source and destination.




10.2.1. Call Handling System Cabinets and Power Distribution

The equipment cabinets shall be 30 inches wide by 48 inches deep by 84 inches high with 19-inch spacing of the mounting rails. The rails shall be centered in the cabinet, and shall have square mounting holes to accommodate snap-in rail systems. This size cabinet provides 45 rack units (RU) of space. To accommodate devices without snap-in rails, caged nuts and matching machine screws #12-24 thread shall be used.

The front and rear cabinet doors shall be vented. If any equipment to be mounted in the racks has side-to-side air circulation, the cabinets shall be equipped with a minimum of two fans in the top to move warm air out of the cabinet. Otherwise, a mesh top is sufficient. The cabinet shall be equipped with internal power and data cable management. Most rack manufacturers have internal cable management options.

The PDUs used within the cabinets shall be remotely manageable via Simple Network Management Protocol (SNMP) and web browser, and provide load and other status information back to the network management system, and have individually controllable outlets to allow remote power-cycling of equipment that may be otherwise unresponsive. All power cords shall be labeled at both ends with their source and destination. Each cabinet shall have dual PDUs powered from separate sources.

Vendor shall not package their system in the shortest rack possible. The Council shall approve the cabinet and PDU specifications, in order to maintain a standard data center design.





10.2.2. Call Handling System Data and Power Cabling

The Bidder shall implement data cable color coding and labeling in all facilities, including PSAPs. All cabinets, racks, patch panels, and devices within the cabinets and racks shall be identified and labeled front and rear. Cables shall be labeled with their source and destination.

Whether Vendor chooses to use TIA-606-B or an in-house standard, the real issue comes not at installation, but as things change over time. The Vendor shall maintain the correct color coding and labeling through additions, moves, and changes. The Vendor shall avoid yellow and orange for twisted pair cables as these are standard colors for single mode and multimode fiber, respectively.

Proper spacing, typically greater than four inches, shall be maintained between power and data cables. To the extent possible, power and data cables shall not run parallel to each other. This does not apply to fiber optic cable. Fiber optic cable and jumpers shall, to the extent possible, be run separately from twisted pair cable to avoid the possibility of physical damage. Where this is not possible, the fiber optic jumpers shall be protected with split cable loom (a corrugated plastic sleeve) or spiral wrap. This method of protection shall also be used at any point in the cable management system where the fiber transitions from one ladder rack or cable trough to another ladder rack or cable trough. Cable transitions to or from ladder racks shall be via a cable dump over the side, not through the rungs of the ladder rack.

Vendor shall provide documentation of their processes and procedures for maintaining the color coding and labeling standards through adds, moves, and changes.




10.2.3. Physical Security and Access

The Data Centers shall have security and access control systems that ensure only duly authorized individuals can access the cage or room housing the Council’s systems and network equipment. Any


devices, power distribution, and cross connect panels feeding the cages or rooms housing the Council’s systems shall be similarly protected. Reporting requirements are detailed in Section 5.2.8.

All Council systems and network equipment shall be housed either in a locked and monitored cage within a secure data center, or its own locked and monitored room within a secure data center. Equipment shall not be located in a common area.




10.3. CALL HANDLING SYSTEM SERVERS AND SOFTWARE

The network and i3 services are provided by an array of firewalls, routers, gateways, and servers. The servers may also include SAN or NAS devices, which are high capacity, redundant, resilient disk storage systems. The physical servers shall be running a virtual server environment such as VMware or Citrix, which extends the redundancy and resiliency to the software level. The same theory applies to the hard disk storage systems. Implementing a SAN or NAS brings redundancy and resiliency to the data storage components.

All server and storage devices shall have redundant power supplies connected to separate remotely manageable PDUs.




10.3.1. Call-Handling Server and Storage Hardware and Software

Server virtualization and network storage systems, either Storage Area Networks (SANs) or Network-Attached Storage, (NAS), shall be implemented to provide a more robust environment than discrete


servers. For any servers and storage systems required for implementing the IP network and its services, Vendor shall implement systems in the Unix/Linux operating environment for security reasons.

Each SAN or NAS shall have the ability to provide backup services to the devices in their neighboring data centers.

Just as a replacement schedule was noted above for switches and routers, server hardware shall be replaced every three (3) to five (5) years. Old servers may be relegated to less critical uses within the network, such as lab systems. Software shall be upgraded as recommended by the Vendor, pursuant to testing requirements implemented under change management controls.




10.3.2. Call-Handling Server Installation

The servers shall be installed in the racks mentioned above. One blank RU shall be left between all devices in the racks. These empty slots shall be covered with a blank panel. This allows for air circulation around the devices in case one overheats. Systems that are pre-racked from the manufacturer or integrator shall meet this specification.

All devices in the racks shall be labeled front and rear with their device name. This name will be used in the power and data cable labeling as well.




10.4. CALL HANDLING PERFORMANCE


Vendor shall include both resiliency and redundancy in the proposed solution(s). All single points of failure shall be addressed with a documented risk analysis and mitigation strategy across the total solution. The processes and methodology for managing MOS, latency, jitter, delay and other performance measurements shall be addressed. Vendor shall provide details on the reports provided and frequency of delivery those reports are made available to the Council.

If any one of the three Data Centers is inhibited from properly functioning, the remaining two Data Centers shall function with no perceptible difference in quality or interrupted service by the callers or the NG9-1-1 call takers. This capability shall be tested at least yearly to insure this capability has not been inadvertently compromised by additions and/or changes made over the previous 12 months.

As n objective, the subsystem shall be designed and configured in a way that will allow for any one data center to handle all the NG9-1-1 calls across the state without perception of difference by the caller or telecommunicator. Bidder shall provide an option that illustrates a single center providing NG9-1-1 call handling services for the state, in a temporary manner, to provide understanding of any impact this option will cause on price (Cost Proposal template only), network capacity requirements or any other communication elements. Vendor shall describe the associated network requirements for supporting this type of resiliency.

In providing information about the ability to lose one or two of the three Data Center and continue providing NG9-1-1 call handling, Bidder shall describe how this will impact connectivity to recorders, CAD systems, and other devices and applications.




10.5. CALL HANDLING HARDWARE

Vendor shall provide information regarding connectivity required by or provided by the different servers, gateways, workstations, and other appliances that are part of the NG9-1-1 call handling solution. Vendor shall provide their proposed replacement schedule for processors, memory, power supplies, and line cards. Smaller access switches and routers shall be included on this replacement schedule.

Vendor shall document how they propose to perform hardware refreshes. Vendor shall provide documentation with specifics of how hardware refreshes have historically impacted telecommunicator and 911 callers.


Vendor shall provide documentation of their communications policy for performing these changes within the governance structure.

SaaS Bidder shall provide a footprint, power and other specific requirements for a best practice implementation of their product at the PSAP.




10.6. CALL HANDLING PROTOCOLS

Vendor shall provide a list of all routing and router protocols recommended or required for implementing “best practices” with their proposed solution.




10.7. ONGOING CALL HANDLING MONITORING AND MAINTENANCE

Vendor shall provide clear documentation that calls out all Vendor or manufacturer requirements for ongoing monitoring and maintenance. All required connectivity for monitoring and maintenance that is not part of the proposed solution pricing shall be clearly defined. An example would be circuits that Kansas would be expected to provide for monitoring and maintenance connectivity.

Vendor shall provide, at minimum, view access to solution elements to the vendor that provides maintenance and monitoring for the total Kansas solution

SaaS Bidder shall provide details on level of view they will require for best practices with performing monitoring and maintenance activities.


10.7.1. Remedies

Vendor’s network devices and services to perform at a level of 99.999% uptime. Vendor shall meet the SLAs presented in Appendix E. Failure to meet SLAs shall be measured per service-affecting outage. Penalties shall be assessed for failure to meet SLAs. Vendor shall provide financial remedies to the Council and their respective specified agencies, for each event in which service levels are not maintained.




10.8. CALL HANDLING CONNECTIVITY REQUIREMENT

Vendor shall provide connectivity requirements for ongoing management of their proposed solutions. Vendor shall provide documentation, with drawings, that illustrate connectivity to all the elements of an NG9-1-1 call handling system, including connectivity to devices such as recorders and CAD systems. As part of the connectivity information, Vendor shall clearly describe impacts on that connectivity in relationship to redundancy, resiliency and failover scenarios.

Part of these connectivity requirements shall include bandwidth requirements, including any backhaul bandwidth requirements for expected instant recall recording and other solutions.




10.8.1. Call Handling Connectivity to CAD System

Multiple CAD systems are currently being used across Kansas. Vendor shall provide information on how connectivity to the CAD systems shall be accomplished. Current connectivity requirements shall be


explained for RS232 connectivity and IP, if available. Any bandwidth required to support a CAD interface shall be provided. Drawings to support connectivity and bandwidth are required.




10.8.2. Administration Lines to Call Handling System

Bidder shall provide a minimum 4-Port standard line interface gateway for administration lines provided from a service provider or from a PBX/phone system providing standard analog lines.

In addition, Bidder shall provide optional pricing for increasing the number of analog administration line ports in their Cost Proposal pricing template.




10.8.3. ALI Links to Call Handling System

Vendor shall describe proposed connectivity of ALI links to the NG9-1-1 call handling system.

NOTE: Six (6) PSAPs in southwestern Kansas host their own ALI database. Vendor shall describe their ability to interface with these six PSAPs.






10.9. CALL HANDLING PROTOCOLS AND FIREWALL PORTS

Vendor shall provide a list of all routing and router protocols recommended or required for implementing “best practices” with their solution. This information shall include a list all protocols and ports required to transverse firewalls for all parts of the proposed solution. If a Vendor uses multicast, then the ports required for this function shall be provided.




10.10. CALL HANDLING SOLUTION SURVIVABILITY

The types of survivability options vary greatly between manufacturers. Understanding how that survivability works and the impacts to the network to support that survivability are critical information because the amount of bandwidth required will vary between manufacturers.

Vendor shall provide documentation for understanding how local PSAP survivability options functionally perform, connectivity requirements to the host, bandwidth requirements, and connectivity implications to other devices such as logging systems and CAD systems.

With a SaaS solution, Bidder shall be able to articulate and provide drawings that illustrate survivability elements required to meet performance standards.





10.11. CALL HANDLING INTER-NODE BANDWIDTH

If Kansas chooses to host Call Handling software in the Data Centers, it is recommended that they have at least two data center locations that can serve that region. The amount of bandwidth required to synchronize and otherwise communicate between the two data centers shall be understood as this varies significantly between vendors.

With a SaaS solution, the inter-node bandwidth will not be required for network design purposes. However, a clear understanding of how a Vendor will provision that connectivity and assurance that the Vendor’s design will meet expected performance is required.




10.12. CALL HANDLING UPGRADE / UPDATE PROCESSES

With the host Call Handling software located in the regional Data Centers, Vendor shall upgrade and update each site as required to satisfy all stated and implied performance requirements of NG9-1-1. Vendor shall explain empirically and historically how these requirements shall be accomplished. Vendor shall be required to document how the upgrade and update policy works within the Kansas NG9-1-1 Change Management Policy.

With a SaaS solution, Vendor shall upgrade and update as necessary to meet performance requirements. Vendor shall describe how these tasks will be performed and any potential impacts to the 911 caller or telecommunicator.

SaaS Bidder shall document how the upgrade and update policy works within the Kansas NG9-1-1 Change Management Policy.





10.13. CALL HANDLING SECURITY MANAGEMENT

There are many elements of security whether the Call Handling solution is hosted in the Data Centers or as a SaaS solution. Vendor shall document security policies including a security notifications with standard operating procedures and a communications plans consistent with the governance of Kansas NG9-1-1. As an example, Vendor shall explain support of multicast traffic since some manufacturers specify the addresses and ports they use for multicast traffic, while others use the next available port.

With a SaaS solution, Bidder shall document specifics about security policies and products deployed by the provider in their data centers and expectations for security and security management at the PSAPs.




10.14. COST FOR CALL HANDLING UPGRADES

If proposing a Call Handling solution in regional Data Centers, Vendor shall describe the cost from a historical perspective of implementing associated upgrades of NG9-1-1 using the Cost Proposal pricing template.

If proposing a SaaS solution, Vendor shall provide a detailed explanation of all services provided for the price quoted along with all additional elements and expenses that would be required for a fully functional SaaS NG9-1-1 call handling system deployed across Kansas using the Cost Proposal pricing template.

Vendor shall describe their roadmaps new features and capabilities planned for NENA i3 including any manufacturer’s i3 feature and capability roadmap. Vendor shall provide a clear and concise commitment for providing those features at no additional cost. If Vendor perceives future increase in cost, then Vendor shall provide the parameters for deciding on when they increase cost and their methodology for pricing those increases.

In addition, SaaS Bidder shall provide documentation on how new capabilities will be introduced, and if there will be any limitations on the availability of those feature being part of the solution.




10.15. CALL HANDLING SYSTEM SECURITY

10.15.1. Malware and Anti-Virus

Bidder shall describe their strategy for providing malware and anti-virus protection for all servers and workstations in their proposed solution.




10.15.2. Malware and Anti-Virus – Software Updates to Call Handling System

Vendor shall describe in detail how updates would be performed, how often, and the estimated associated costs. Vendor shall describe the malware product that has been standardized in the proposed solution. Updates to the malware product shall have the ability to be performed from one administrative or maintenance position utilizing the closed network.


0(select one) Fully Compliant, Partially Compliant, Non-Compliant


10.16. CALL HANDLING SYSTEM SINGLE-LOGON AUTHENTICATION

Vendor shall describe how their proposed solution provides an authenticated single log-on capability. That logon shall consist of a user name and password. Vendor shall describe any options available by their solution for a single authenticated log-on capability.





10.17. CALL TAKER HUMAN MACHINE INTERFACE

In 2008, the US Department of Transportation published NG9-1-1 Call Taker Human Machine Interface (HMI) documentation. In 2010, NENA 54-750, published jointly with APCO, Human Machine Interface & PSAP Display, was published.

Bidder shall identify any and all restrictions and limitations (automatic call distribution [ACD]-only, licenses, functionality…) for HMI features and capabilities.




10.17.1. Call Handling Call Controls and Display

Vendor solution shall:A. Provide programmable buttons to allow for single action access to frequently used features and

commands. B. Provide an audible and visual indicator when a call has arrived, configurable by the local system

administrator up to and including notifications to all active workstations. C. Provide capability to present multiple calls and allow the call taker to process multiple calls at the

same time. D. Provide visual and audible indication that a call remains unanswered after a configurable number

of seconds. E. Provide capability to terminate a call with a single action option. F. Provide visual and audible indication after a configurable number of seconds for a “time on two-

way mute” and/or “time in park” call. G. Provide capability to transfer any type call. H. Provide capability to transfer all call record information with a single action option. I. Provide capability to reestablish a call path to a communications device via a single action

option.


J. display the supported callback communications methods to the call taker. K. permit the call taker to select from the supported communications methods when initiating a

callback. L. provide the capability to dial, transfer, and/or conference stored telecommunications device

numbers. M. be capable of displaying the time elapsed for any individual call in the queue. N. provide the capability for a call taker to select a pending call from a call queue as configured and

permitted by the local system administrator. O. display call queues by logical group (ACD functionality) and provide indication of the number and

type of calls in queue and how long call has been in queue, configurable by the local system administrator.

P. provide line status indication, to include at a minimum: ringing, on “two-way mute,” “park,” and idle. This shall be configurable by the local system administrator to display only those conditions applicable to the PSAP.

Q. provide the capability for a call taker to take him/herself out of queue. R. provide for call taker controlled audio volume adjustment. S. provide the capability for a hook flash or equivalent for the call taker. T. provide a visual indication to the call taker identifying the PSAP from which an overflow or default

routed call originated. U. provide a visual indication to select displays at both the originating and destination PSAPs that

calls are being alternate routed due to an overload condition. V. provide the capability for a call taker to initiate a call (contact) from within an additional data field,

i.e., when a call taker places the mouse pointer over a phone number, e-mail address, etc. W. provide the capability to store, search and sort communications device numbers contact in

categorized lists, buttons, and/or tabs.




10.17.2. Call Handling System Incident Information

Vendor shall provide an explanation on how they support the following HMI requirements:A. provide a single action option for the call taker to automatically populate the calling device

location into an incident location field within the call handling or dispatch functional element. B. have the capability to filter call records.


C. provide the capability for the call taker to manually enter an incident location using an address, intersection, longitude/latitude (X, Y) or commonplace.

D. provide the capability for the call taker to initiate automatic rebids for an active call via a single action option.

E. provide the capability for a call taker to manually rebid for a location update. F. display the recommended emergency service provider(s) agencies associated with the incident

location. G. be capable of displaying the recommended emergency service provider(s) associated with the

calling device location if the emergency location is not available. H. be capable of displaying the communication capabilities of the recommended responder

agencies.




10.17.3. Call Handling System Additional Data/Call History

Vendor shall provide an explanation on how they support the following HMI requirements:A. display of additional calling device data shall be configurable by the local system administrator. B. Access to additional data shall remain available throughout the duration of the call. C. support drill-down access of additional data to obtain additional detail according to access rights. D. provide the ability to display the results of external database queries. E. provide the call taker the capability to read call records. F. make previous call history available to the call taker based on the calling party number (CPN)

when available, and shall allow the call taker to access the associated data of call history. G. provide an audio and/or visual indicator when call history or additional data is available. H. provide a pre-populated discrepancy report with a single action option.

The HMI shall provide the call taker and local system administrator the capability to correct calling device location information. A record of the calling device location in the original data shall be maintained.





10.18. ALI INTERFACE TO CALL HANDLING SYSTEM

10.18.1. Call Handling System ALI Caching

Vendor’s solution shall be configurable for storing (caching) received ALI data from the ALI database provider.




10.18.2. Call Handling System Manual ALI Request

Vendor solution shall be capable of documenting and storing all manual ALI dips. The documentation shall include the workstation and the user initiating the manual ALI dip. Sufficient events shall be generated in order for the management information system (MIS) to provide accurate ALI dip reports.

Vendor solution shall have the ability to perform a manual ALI request without an active call being present.





10.18.3. Call Handling System Supplemental ALI

Vendor solution shall support supplemental (aka additional) ALI based on the caller’s phone number. Vendor shall describe how the generation, maintenance, and display of supplemental ALI is achieved.




10.18.4. Call Handling System ANI/ALI/Caller ID Display

Vendor workstation shall be capable of displaying the ANI/ALI or Caller ID (CID) information of any active or hung up 911 call or administrative line. The workstation shall be capable of displaying all ALI data provided by the ALI database provider including, but not limited to, status of the 911 caller; emergency service number (ESN); caller name; address; X, Y coordinates; and circuit name. The workstation display shall be configurable to inform the call taker of the number of calls on hold and the number of calls in each queue.




10.18.5. Call Handling System ALI Rebids

Vendor solution shall provide automatic ALI rebidding using PSAP-defined intervals allowing the PSAP to receive updated X, Y coordinates. This feature shall be configurable, allowing the PSAP to determine the number of times and the time interval between rebids on a per-trunk or wireless-carrier basis. If a PSAP chooses to disable ALI rebid, then disabling of automatic ALI rebid shall be allowed on a per-carrier and Class of Service (CoS) basis. Manual ALI rebid shall also be supported by the solution. Vendor shall support the ability to auto rebid based on call CoS, i.e., Phase 1.





10.18.6. Call Handling System Pre-answer ALI

Vendor solution shall provide configurable options to provide the call taker with ALI information prior to the call being answered.




10.18.7. Calls in Queue – View ALI Detail

Vendor solution shall provide the call takers and supervisors detailed ALI information in real-time at each workstation. The user, at a minimum, shall easily be able to identify the type of call, status of call, and duration while the call is in queue.





10.18.8. Call Handling System ALI Display – Post Call

Vendor solution shall display the ALI information on the call taker’s screen after disconnecting from a 911 call.




10.18.9. Call Handling System ALI Display – Callback

Vendor solution shall provide the capability of displaying the ALI information on the call taker’s screen during callback.




10.18.10. Call Handling System ALI Parsing

Vendor solution shall accurately and consistently displays ALI data from multiple or third-party ALI database providers. The ALI data format could vary from different providers, and the solution shall display the ALI information in a consistent manner.





10.18.11. Call Handling System ALI Discrepancy Reporting

Vendor solution shall provide a means to report to a centralized location any ALI discrepancies, including capturing and reporting events that were identified during any 911 call and misroutes and other types of discrepancy reporting. Vendor solution shall generate a report on any ALI discrepancy for tracking purposes. Vendor solution shall allow for management of these discrepancies, from receiving them to being managed by an authority.




10.18.12. Call Handling System Incomplete ANI Spills

Vendor solution shall provide for the ability of an E911 call that is delivered to call handling equipment with an incomplete or invalid ANI spill to be delivered to a predetermined set of 10-digit codes.




10.19. CALL HANDLING ACD


10.19.1. ACD Call Delivery

Vendor solution shall support ACD in addition to standard call delivery methods. For example, Call Takers 1–4 can be configured to receive calls in a “Ring All” method, while Call Takers 5–10 can log into ACD queues.




10.19.2. ACD Hunt Types

Vendor solution shall provide support for the following ACD hunt types simultaneously: Longest Idle Top Down Round Robin Ring All




10.19.3. Call Handling Barge-In

Vendor solution shall provide an authorized PSAP call taker, supervisor or manager the ability to quietly enter into any call taker’s “live” conversation. The feature shall be activated by utilizing a mouse or an easily invoked keyboard command and not degrade the audio quality of the call. The call taker or supervisor is then part of a three-way call with the caller and original call taker.





10.19.4. Call Handling Callback

Vendor solution shall provide the call taker the ability to callback the calling party, regardless of call type (wireline, wireless, Telecommunications Device for the Deaf (TDD)/TTY, VoIP, etc.). The system shall determine the correct callback number without call taker input. The callback function shall only require a single mouse click. Any prefix digit(s) insertion/deletion (example – adding +9) shall be automatic and not require manual input.




10.20. CALL HANDLING CONFERENCE

10.20.1. Basic Call Handling Conferencing

Vendor solution shall provide the capability for the call taker to add an outside caller or inside caller to an in-progress “live” call while remaining on the line, with no limitation as to what type of call the call taker is on. The solution shall control the audio levels so there is no degradation to voice quality. The original call taker shall be able to select and drop any party from the conference. The original call taker or any of the conference parties shall be able to drop out of the conference without losing the calliNG9-1-1 party.





10.20.2. Call Handling Conference Disconnect Control

Vendor solution shall provide the ability for supervisors and call takers with the proper permissions to selectively disconnect parties from a conference. This includes conferences initiated as the result of barge-In.





10.20.3. Call Handling Conference – Mute Transmit Toward 911 Caller

Vendor solution shall provide the capability of conferencing a 911 caller with an outside line. During this call setup of this conference/transfer, the call taker shall always be able to hear the 911 caller. If the call taker desires to mute the workstation’s transmit toward the 911 caller to discuss the incident without the 911 caller, that workstation would support muting towards the 911 caller on an as needed basis.




10.21. CALL HANDLING HOLD/PARK

Vendor solution shall provide the ability to create both private and public hold and park. Vendor shall describe the public and private options available for this feature. The system workstation application shall allow the call taker to place calls on hold or park utilizing a single mouse click or key stroke with a visual graphical user interface (GUI) representation of the hold/park status to all users. The calls can be a combination of administrative calls and 911 calls. Vendor shall describe how long the call can be on hold, what notification is provided to the workstation that the call is on hold, and what solution options are available to re-present/time-out the call back to the original workstation that placed the call on hold/park or other workstations. Vendor shall also describe if their solution has a unique way of alerting the call takers that this call was previously placed on hold.




10.21.1. Call Handling Hold/Park – Retrieval

Vendor solution shall allow any call taker to access and retrieve the desired call that has been placed on public hold/park. The solution shall provide the call taker with a list of calls on hold/park. Call takers,


while reviewing the call list, shall, at a minimum, be able to see the CPN, ESN, trunk number, workstation ID that held/parked the call, and the time and date the call was placed on hold.




10.22. CALL HANDLING MERGE MEDIA

Vendor solution shall ensure that mixed media sessions are merged. For example, Call Taker A has a live video session of an incident and Call Taker B is talking to a caller (possibly the same person) about the same incident. Vendor solution shall ensure such type of sessions become merged in order for the call taker(s) to have a full understanding of the incident.




10.23. CALL HANDLING SUPERVISORY MONITOR

Vendor solution shall allow authorized PSAP call takers, supervisors or managers the ability to listen quietly to a call. There shall be no limitation on the number of licensed users that can simultaneously monitor a call taker. There shall be no interruption in monitoring as the result of the call taker’s actions (hold, transfer…) These features shall be controlled by the authorized personnel password and not be noticed by, or disturb, the monitored workstation. Monitoring shall not degrade the audio quality of the call.





10.24. CALL HANDLING SPEED DIAL

10.24.1. Access to Speed Dial Feature

Vendor solution shall provide for all workstations to have the capability to access system-wide and personal pre-programmed speed dial lists that automatically dial numbers utilizing the mouse or keyboard.




10.24.2. Speed Dial List Quantity of Numbers

Vendor shall explain the limits in quantities of the speed dial list.




10.24.3. Speed Dialing – Extra Digits

Vendor solution shall allow the speed dial list the ability to support any necessary extra digits or codes necessary to automatically dial a number and complete a call and any limitations.





10.24.4. Speed Dial Library – Search

Vendor solution shall provide for the system-wide speed dial database to have the capability of being searched, printed, and exported by entering the first few letters of the speed dial entry including wildcards and alias lists and any limitations.




10.24.5. Speed Dial – PSAP and Personal List

Vendor solution shall allow call takers to maintain their own personal speed dial list. Vendor solution shall have the ability for speed dial lists to be automatically uploaded to the data centers and propagated to all workstations. The speed dial updating process shall not affect the ability of users to access and use speed dials. Workstations shall not require restarting for any speed dial changes.




10.25. CALL HANDLING STATUS


10.25.1. Status Indicator

Vendor solution shall have the ability for a light at each workstation so that the status of call takers is easily visible across a room. For example, active calls could be red, on hold – yellow, on-hook – green, logged out/not ready – off.




10.25.2. Status Timer

Vendor solution shall provide for call timer information to be displayed to indicate how long a call taker has been on a call. Vendor solution shall indicate the format of this call timer (analog, digital, bar graph, etc.) and describe how call actions (hold/unhold, conference, etc.) affect this timer.




10.26. CALL HANDLING TRANSFER

10.26.1. Transferred Calls (Tandem)

Vendor solution shall provide for calls to be transferred from one tandem to another while also transferring the associated call information.

With a SaaS solution, any bandwidth requirements for transfers shall be provided.





10.26.2. Transferred Calls (Network)

Vendor solution shall support transport of transferred calls (voice and data) between a primary and alternate location (and between an alternate and primary location). Vendor solution shall provide for calls that are transferred from the originating primary or alternate location to another PSAP and then transferred back to the originating PSAP do not consume resources (switch ports, bandwidth...) in the other PSAP.





10.26.3. Intelligent Transfer Button

Vendor solution shall provide the capability of an Intelligent Transfer feature. This feature allows the call taker to transfer calls regardless of the type of incoming port that is supporting the call to any type of destination (PSAP, administrative line, ring down, 911 tandem transfer...) using a single, intelligent, preprogrammed transfer button; a single transfer button per destination and preprogram the transfer button to support all transfer sequences necessary so that call takers do not need to determine the correct transfer sequence. With a SaaS solution, any bandwidth requirements for transfers shall be provided.





10.26.4. Transfer via 911 Tandem

Vendor solution shall support the capability of allowing a call taker to transfer a live 911 call, via the 911 tandem, to another PSAP or destination that is supported by the 911 tandem.





10.27. TDD/TTY CALL HANDLING

10.27.1. TDD/TTY Federal Requirements

Vendor solution shall support HMI TDD/TTY and how it meets all current Federal Communications Commission (FCC) and all current Americans with Disabilities Act (ADA) requirements. The solution shall be tested and pass NENA’s TTY test site http://tty-pass.telecomxchange.com/TTY-PASS.php

A SaaS solution shall meet the above requirement(s), and any connectivity interfaces or network requirements for support of these capabilities.




http://tty-pass.telecomxchange.com/TTY-PASS.php


10.27.2. Automatic TDD/TTY Call Detection

Vendor solution shall ensure HMI provides the capability to automatically detect an incoming TDD/TTY call and alert the call taker that the call originated from a TDD/TTY device.

The proposed HMI shall have the capability to automatically send a response to the caller that they have reached a 911 center.





10.27.3. TDD/TTY Direct Connection

Vendor solution shall ensure HMI provides the call taker the capability to communicate with TDD/TTY devices directly from their workstation keyboard without the use of any external devices.






10.27.4. 911 and Administrative TDD/TTY

Vendor solution shall ensure HMI allows the call taker to manually connect the TDD/TTY application to any 911 or administrative call. A SaaS solution shall meet the above requirement(s), and any connectivity interfaces or network requirements for support of these capabilities.




10.27.5. Baudot and ASCII TDD/TTY Protocols

Vendor solution shall ensure HMI supports TDD/TTY communications using both Baudot and American Standard Code for Information Interchange (ASCII) protocols.





10.27.6. Preprogrammed TDD/TTY Messages

American Standard Code for Information Interchange support of HMI allows the ability to preprogram at least 50 TDD/TTY messages to be utilized by all workstations. Vendor solution shall provide for the


maximum number of messages supported. The messages shall be grouped into different situation types (e.g., Law Enforcement, Fire, etc.) to aid in quicker response.





10.27.7. TDD/TTY or TEXT Conferencing

American Standard Code for Information Interchange support of HMI allows the call taker to create a conference between the TDD/TTY or TEXT caller and at least six other parties. Vendor solution shall meet the conference requirement for both 911 calls and administrative calls. A SaaS solution shall meet the above requirement(s), and any connectivity interfaces or network requirements for support of these capabilities.




10.27.8. TDD/TTY HMI Message Display

Vendor solution shall ensure HMI displays the 911 caller’s and call taker’s messages separately. The display shall be in real-time. Preprogrammed messages shall also be displayed when they are used to communicate with the administrative or 911 caller.






10.27.9. TDD/TTY HMI Message Length

Vendor solution shall ensure HMI does not limit the number of characters transmitted or received, or the length of the conversation.





10.27.10. TDD/TTY or TEXT Transfer

Vendor solution shall ensure HMI provides for the transfer of a TDD/TTY or TEXT call from one workstation to another, including transfers between PSAP locations. The caller’s information shall transfer with the call. Vendor solution shall ensure that the conversation that was displayed on the original call taker’s screen transfers to the new call taker’s screen.





10.27.11. TDD/TTY – TEXT Archiving

Vendor solution shall provide a method of archiving all TDD/TTY or TEXT conversations and is retrievable by querying based on:

Date and Time ANI ALI TDD/TTY or TEXT message PSAP personnel Workstation Incoming/outgoing trunks and lines ESN Wireless carrier




10.27.12. TDD/TTY Hearing Carry Over/Voice Carry Over (HCO/VCO)

Vendor solution shall ensure HMI allows the call taker to invoke HCO and VCO at any time when the call taker is using the TDD/TTY feature. Access to HCO and VCO shall be an available selection within the TDD/TTY application window. Vendor shall describe the level of support included for speech-to-text translation back to the TDD/TTY caller.





10.28. CALL HANDLING WALL BOARD CALL STATUS MONITOR

Vendor solution shall support of wall-mounted 42-inch high-definition monitors, as an option, for displaying real-time information as determined and controlled by the PSAP.




10.29. INSTANT RECALL RECORDING

Vendor solution shall support of the following HMI requirements:A. capability to retrieve the instant recall recording based upon search criteria as configured by the

local system administrator. B. provide the capability to display references to additional data associated with a call when

accessing that call through the instant recall recorder (IRR).C. provide the ability to forward and play a call recording to the caller.D. supervisor shall have the ability to archive instant recall recording data after the end of the call

for playback on any workstation.




10.29.1. Instant Recall Recorder

Vendor solution shall support instant recall recording for multi-media (voice, radio, text, video, etc.). Bidder shall provide a detailed description of the proposed Instant Recall Recorder (IRR) feature.





10.29.2. Administrative Calls Recording

Vendor solution shall support the administrator enabling and disabling the recording of administrative calls.




10.29.3. Automatic/Manual Recording

Vendor solution shall support the capability of configurable automatic and manual recording.




10.29.4. Call Recording Storage

Vendor solution shall support the ability for all conversations to be recorded locally on the workstation.





10.29.5. Call Recording Storage Capacity

Vendor solution shall support each workstation being configurable for a minimum of 12 hours of storage.




10.29.6. Erasure of IRR Call Recordings

Vendor solution shall support each workstation’s ability to erase recordings when the workstation local storage reaches a configurable amount of capacity and/or when a recording has reached a certain age, including at the end of a shift. Vendor solution shall have the ability to turn on or off this feature.





10.29.7. Recording Radio Channel

Vendor solution shall support each workstation’s ability to record the active radio channel independently, but simultaneously, from the call.




10.29.8. Recording Call Type/Text Information

Vendor solution shall support an application for displaying a sortable list of available recordings to the call taker that includes the call type when the call taker is searching for recordings (administrative, 911, TTY, radio, etc.). The IRR application shall automatically include the caller’s CPN in the text associated with each recording.




10.29.9. Recording Playback

Vendor solution shall support playback of multi-media calls. Bidder shall also explain how their proposed system supports radio and 911 calls being played back independently, as well as in sequence. In addition, the playback function shall be invoked with a minimal number of keystrokes or mouse clicks, and take place within one second following the command sequence.

IRR shall provide the call taker with the following types of DVD-like controls, allowing the user to navigate to any portion of the recorded conversation.

Play


Pause Stop Play forward/Fast forward Rewind Repeat Variable speed control




10.29.10. Recording Export

Vendor solution shall support exporting the multi-media call session to a secure server for playback by authorized personnel.




10.29.11. Supervisor Access to Recordings

Vendor solution shall support access from the same or another workstation by a supervisor login to IRR in real-time from the beginning of the call, even when the call is still active.





10.30. MULTI-MEDIA DISPLAY

Vendor solution shall support the following HMI requirements:A. provide the capability to automatically launch the appropriate multi-media module for the call

type. B. provide the flexibility to determine screen launch location as configured by the user. C. provide the capability to restrict/minimize the display of incoming video conferencing with a single

action option. D. provide the capability to block outgoing video conferencing with a single action option. E. allow a call taker to enlarge or decrease the size of the multi-media module(s). The local system

administrator shall also have the ability to create single action options to have the multi-media module displayed at preset sizes.

F. provide the capability to notify the call taker when multi-media attachments become available and allow the call taker to choose to view or not.

G. provide the capability to establish trackable text messaging internal to the PSAP with a minimal number of actions.

H. provide the configurable option for the call taker to handle multiple text calls at the same time. I. provide the capability to visually distinguish between parties within the text conference. J. have the capability for the call taker to change the display of data within specific modules (font

type, size, color etc.) as allowed by the local system administrator. K. provide the call taker with a single action option to put an existing text call into queue status with

all call record information attached to the call. L. shall be configurable to allow either automatic or manual activation of a video call/conference

with the calling device.




10.31. CALL HANDLING SYSTEM VIDEO

Vendor solution shall support displaying video as part of their solution and provide detailed descriptions of current and planned capabilities and any costs associated with this feature.





10.32. CALL HANDLING SYSTEM MAP DISPLAY

Vendor solution shall support the following HMI requirements:A. display emergency event location and calling device location information on a map display based

upon configuration. B. provide the capability to customize the display rules for caller and event location, configurable by

the local system administrator. C. provide the capability to display location update results on a map display. D. provide the capability to accept or reject the update request results. E. provide the capability to draw geometric shapes on the map display. F. provide the capability to pan the map display. G. provide the capability to select/unselect a GIS layer type for display. H. provide the capability for the call taker to search for the emergency location using at a minimum:

a) geo-coordinates, b) civic address, c) common place, and d) cross streets.I. provide the capability for the call taker to search for the emergency location by clicking on a map

display. J. display location search results to the call taker. K. provide the capability to select an emergency location from the map display. L. provide the capability to display the emergency response agencies associated with a caller’s

location on the map display. M. provide the capability to display the emergency response agencies associated with an

emergency location on the map display. N. provide the capability to graphically display the accuracy/uncertainty associated with a given

calculated position. O. support the representation of additional location information for a mobile device.





10.32.1. Call Handling System support of ESRI

Vendor solution shall support an Environmental Systems Research Institute (ESRI) based system using the GIS data provided by Kansas’ GIS department. The Kansas NG9-1-1 GIS Data Model v1.0 establishes data standards for required and recommended data layers. It describes in detail the table attribute schema to be implemented with each layer, provides applicable domain lists, and denotes mandatory, conditional, or optional attribute items. Vendor solution shall support ESRI file formats and adheres to the Kansas NG9-1-1 GIS Data Model v1.0.





10.33. SUPPORT OF GIS DATA AND MAPPING APPLICATION

Vendor shall use Kansas’ NG9-1-1 GIS data. Vendor solution shall provide for the transition from current GIS data to Kansas NG9-1-1 data. Vendor solution shall transition from current GIS data to data stored in the Kansas NG9-1-1 GIS Data Model v1.0. Vendor solution shall support the display of mapping data via Esri and Open Geospatial Consortium (OGC) map service formats. Bidder’s Proposal Response To This Requirement(s) goes here.



10.33.1. Map Circle of Uncertainty


Vendor solution shall provide a dynamically-scaled Circle of Uncertainty on the map for wireless 911 based on the uncertainty delivered in the ALI. Different icons shall be used on the map to differentiate CoS.




10.33.2. Map Zoom

Vendor solution shall provide a dynamic display and rendering of different layers based on zoom leveI. Bidder shall provide draw-times on zoom process.




10.33.3. Map Imagery

Vendor solution shall support Pictometry® and identify all other aerial imagery formats supported.

Vendor solution shall support Pictometry® and identify all other aerial imagery formats supported. Vendor solution shall support the display of imagery via Esri and Open Geospatial Consortium (OGC) map service formats.





10.33.4. GIS Reverse Geocoding

Vendor solution shall support reverse geocoding in order to obtain addresses on vector (points, lines, and polygons) ranges.




10.33.5. Mapping of Abandoned Calls

Vendor solution shall support the display and/or callback of abandoned calls via real-time mapping. Enabling/disabling these features shall be configurable.




10.34. CALL DETAIL RECORDS

Vendor solution shall support the ability to generate a cradle to grave Call Detail Records (CDR) history detailing every transition for every incoming and outgoing call.






10.34.1. CDR Availability

Vendor solution shall provide CDR access to all PSAP personnel. Bidder shall explain if this is an “on/off” feature and how the feature is turned on and turned off.




10.34.2. CDR Content

Vendor CDR solution shall contain the following fields, at a minimum: Trunk seize time Caller's 10-digit telephone number Answer time Answering position number Operator name Queue location Line type Time in/out of queue Trunk number Trunk release time Position release time Caller release time Time call was transferred (PSAP name or number to which the call was transferred) Abandoned (Inbound/Outbound) call indicator Ringing start time Time call was placed on hold or parked Time call was taken off hold or park and by what position number Any call state change 911 user wait time


ALI CoS (searching capability) Call flow cumulative times

o Setupo Ringo Talko Hold/park

TTY conversation Text conversation Uniform resource locator (URL) for video




Discus Provide a detailed explanation and associated drawings explaining how the proposed solution meets or exceeds the above requirements.

10.35. CALL HANDLING MIS

10.35.1. Basic MIS Requirements

Vendor solution shall have a MIS application capable of providing each PSAP the ability to run vendor-developed reports and build custom reports meeting management reporting requirements to aid PSAP management:

MIS application Basic MIS is optional, integrated, or third-party integration. If it requires a third-party, support of

that third-party pricing shall be itemized in the Cost Proposal pricing template. MIS data at the site accessed reports are sent to printers (local and network) and other outputs (file formats, email) reports are scheduled for output to local files, printers or files at another network location data can be archived and restored if a primary server shall suffer a catastrophic failure.

A SaaS solution shall meet the above requirement(s), and any connectivity interfaces or network requirements for support of these capabilities





10.35.2. MIS Access – PSAP

Vendor solution shall allow for PSAPs to run reports based on login permissions and not require a dedicated special-use workstation.





10.35.3. Redacted MIS Reports

Vendor solution shall provide the ability to redact reports based on login permissions in order to protect sensitive information.






10.35.4. PSAP Group Performance MIS Reports

Vendor solution shall ensure that the MIS application is able to report on group statistics, especially call taker or PSAP ACD groups. The application shall gather and report on the number of calls answered, overflowed calls in queue, how long calls are in queue, answer time, transferred calls to other groups, tandem transfers, administrative line transfers, and lost calls. This data is important to PSAP management to ensure proper staffing and performance levels of the PSAP through report generation capabilities.

Bidder shall explain how their proposed solution meets the above requirement(s), and any connectivity interfaces or network requirements for support of these capabilities.




10.35.5. Trunk Performance MIS Reports

Vendor MIS application shall support detailed accounting of all call paths including incoming and outgoing trunks and trunk groups. The MIS application shall include traffic measurements for all answered calls as well as trunk busy and overflow statistics. Reports shall include an “All Trunks Busy in Trunk Group” report in order to assist PSAP management in determining trunking requirements. A SaaS solution shall meet the above requirement(s), and any connectivity interfaces or network requirements for support of these capabilities.





10.35.6. PSAP Performance Goals MIS Reports

Vendor MIS application shall be capable of generating the following reports based on criteria listed below to measure compliance with established departmental, NENA, APCO and National Fire Protection Association (NFPA) and other industry standards. The reports shall be configurable by administrator as standards change.

NENA standard: 90 percent of incomiNG9-1-1 calls shall be answered within 10 seconds (during busiest hour of each day)

NFPA standard: 95 percent of incomiNG9-1-1 calls shall be answered within 15 seconds (overall monthly average)

NFPA standard: 99 percent of incomiNG9-1-1 calls shall be answered within 40 seconds (overall monthly average)

Vendor solution shall state when the timing of call origination starts (ingress/egress of LNG, ingress to call handling…).




10.35.7. MIS Ad Hoc Reports

Vendor solution shall ensure that users, supervisors and maintenance personnel are provided the capability to query the data to create and print reports in an ad hoc fashion. Vendor solution shall be capable of ad hoc reporting, including a data dictionary and explanations of data fields available for reporting. If a specific data field is excluded from ad hoc reporting, Bidder shall so note. After the ad hoc reports have been developed, the system shall have the capability to save the ad hoc report template so it can be used again.

Vendor solution shall offer various options in which a report can be generated, and how their proposed solution provides the ability for reports to be scheduled for output to file, printer or other network location.





10.35.8. Multi-media MIS Reports

Vendor solution shall prepare various types of reports available for multi-media calls, including video.




10.36. CALL HANDLING WORKSTATIONS

Vendor solution shall ensure that workstations are used by call takers, dispatchers and supervisors to handle 911 and administrative calls. Bidder shall provide detail of what is expected on-site between the demarcation point inside the PSAP to the workstation. Bidder’s Proposal Response To This Requirement(s) goes here.



10.36.1. Workstation Wiring Runs per Position

Vendor solution shall accommodate various wiring requirements including any additional cable runs for the complete solution.





10.36.2. Genovation Keypad for Workstations

Vendor solution shall be capable of working with any Genovation or Genovation-style keypad. Bidder shall provide pricing for different Genovation-style keypad options in their Cost Proposal pricing template.




10.37. CALL HANDLING HEADSET/HANDSET

10.37.1. Dual Connections for Headset/Handset

Vendor solution shall have the ability and associated requirements for supporting two connections of headsets/handsets at each workstation. Inserting or removing headsets/handsets shall not affect audio quality or call audio volume. Vendor solution shall support multiple phone/jack configurations, including:

Two jacks, for training purposes Radio interface, along with headset One with both speaking and listening, with another listening only.





10.37.2. Headset/Handset Radio/Telephone Integration

Vendor solution shall have the ability and associated requirements for interfacing with various radio dispatch consoles in the PSAPs. The solution shall be capable of supporting headsets/handsets for radio and telephony. Bidder’s Proposal Response To This Requirement(s) goes here.



10.38. CALL HANDLING WORKSTATION SUPPORT APPLICATIONS

10.38.1. Workstation Audio Volume Control

Vendor solution shall have the ability to provide administrative master volume control. The call taker shall still have control over headset and microphone volume. Bidder’s Proposal Response To This Requirement(s) goes here.



10.38.2. Workstation Display Color Options

Vendor solution shall provide the ability to adjust workstation colors per profile login to aid call takers that could have difficulties with some colors. Bidder shall describe what options are available in their workstation that could allow local system administrators to be able to assist users who may need to


adjust standard screen color shades to aid them in identifying different screen displays such as calling line status, call hold, active call, etc.




10.38.3. Call Alert While in Third-Party Workstation Application

Vendor solution shall ensure that the workstation application allows the call taker to be visually and audibly alerted when working in a third-party application and an incoming call, either emergency or non-emergency, is received at the PSAP. The call taker shall be able to switch to the call answer mode with the single click of the mouse. Bidder’s Proposal Response To This Requirement(s) goes here.



10.38.4. Workstation Previous Calls Data

Vendor solution shall provide for the workstation application to be configurable to allow the call taker to view up to at least 100 previous calls and call data from the position from which the call was released. The call taker shall be able to automatically ring the caller back by utilizing a minimal amount of mouse clicks while viewing the previous call list. The previous call information shall be saved to local storage media, minimizing the potential risk of lost data. Bidder’s Proposal Response To This Requirement(s) goes here.





10.38.5. Modify Workstation Sounds

Vendor solution shall allow the local system administrator to modify the sounds.




10.38.6. Application Workstation Feature Shortcuts

Vendor solution shall provide the local system administrator with the capability to assign single or multiple keystrokes to common functions on the answering position; for example, F2 to release a call. These configuration settings shall be invoked at login.




10.38.7. Workstation Screen Configuration

Vendor solution shall provide for the capability for allowing or locking the workstation screen configuration. This feature shall be controlled by the user’s logon profile; that is, the screen configuration could be created and modified by all users or could be locked and only configurable by the local system administrator. Bidder shall describe how workstation display configuration is managed.





10.38.8. Line/Trunk Status on Workstation

Vendor solution shall ensure that the Call Handling workstation application is capable of displaying line and trunk status information on any workstation. Bidder shall describe the status information available to be displayed on the workstations.




10.38.9. Workstation-to-Workstation Dialing

Vendor solution shall provide a station-to-station dialing capability between all workstations and telephone sets that are part of the solution and is configurable by local system administrators. The station-to-station feature shall be easily accessed and used through the use of a minimal number of mouse clicks and keystrokes. The station-to-station capabilities shall be configurable by local system administration.





10.38.10. Interactive Workstation Messaging

Vendor solution shall provide a configurable means of interactive messaging between workstations that is captured as part of the call. An example would be sending a text message for “check with call taker” situations and would ideally be color-coded (red/yellow/green), with an optional audible (possibly repeating until message acknowledged) alert. Bidder shall explain the ability to archive and retrieve interactive messages. Bidder’s Proposal Response To This Requirement(s) goes here.



10.39. PROJECT MANAGEMENTBidder shall include in their bid and proposal a separate and tentative project plan for each subsystem bid. Bidder shall discuss their familiarity and experience with project management of projects having comparable size and scope as the subsystem bid. Bid shall discuss experience with the Kansas (KITO) Project Management Methodology, if applicable.



Gantt Scheduleo Identify critical path activities


o Describe your schedule software tools Major Milestones

o Identify all critical milestones o ensure that the interval between major milestones does not exceed 30 days


















Bidder shall adhere to the policies, procedures, and requirements of the Kansas NG9-1-1 Change Management Policy. This is a living document. Bidder shall explain any differences between their change management policies and procedures and those set forth in the Council’s CM Policy. Bidder shall demonstrate an understanding of the concepts of change management as well as their implementation of change management policies, processes, procedures, and systems.





Glossary

Many of the terms found in this list are from NENA’s Master Glossary.

Next Generation 9-1-1 Glossary

Back to Back User Agent (B2BUA)

A logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request shall be answered, it acts as a user agent Kansas (UAC) and generates requests. Unlike a proxy server it maintains dialog state and must participate in all requests sent on the dialogs it established.

Bidirectional Forwarding Detection (BFD)

A detection protocol designed to provide fast failure detection times for all media types, encapsulations, topologies, and routing protocols. BFD can detect failures, but the routing protocol must take action to bypass a failed peer. BFD is User Datagram Protocol (UDP)-based and provides fast routing protocol independent detection of layer-3 next hop failures. BFD provides low-overhead detection of faults even on interfaces that do not support failure detection of any kind, such as Ethernet, virtual circuits, tunnels and multi-protocol label switching (MPLS) paths.

Border Control Function (BCF)

Provides a secure entry into the Emergency Services IP network (IP network) for emergency calls presented to the network. BCF incorporates firewall, admission control, and may include anchoring of session and media as well as other security mechanisms to prevent deliberate or malicious attacks on public safety answering points (PSAPs) or other entities connected to the IP network.

Border Gateway Protocol (BGP)

An Internet Engineering Task Force (IETF) standard, and the most scalable of all routing protocols, BGP backs the core routing decisions on the Internet. BGP maintains a table of IP networks that designate network reach-ability among autonomous systems. BGP makes routing decisions based on path, network policies and/or rule-sets. BGP can carry routes for multicast, IPv6, virtual private networks (VPNs), and a variety of other data.

Coder/Decoder

In communication engineering, the term codec is used in reference to integrated circuits, or chips that perform data conversion. In this context, the term is an acronym for “coder/decoder.” This type of codec combines analog-to-digital conversion and digital-to-analog conversion functions in a single chip. In personal and business computing applications, the most common use for such a device is in a modem.

Configuration Management Database (CMDB)

A database that contains all relevant information about the components of the information system used in an organization's information technology (IT) services and the relationships between those components. CMDB provides an organized view of data and a means of examining that data from any desired perspective.

Denial of Service (DoS) Occurs when a system is overwhelmed in such a way that messages cannot be processed, or they are processed extremely slowly.

Diff-Serv Aware Traffic Engineering (DS-TE)

Differentiated services give different treatment to traffic based on the experimental (EXP) bits in the multi-protocol label switching (MPLS) label header and provide the ability for multiple classes of service. DS-TE provides traffic engineering at a per-class level rather than at an aggregate level; different bandwidth constraints for different class types (traffic classes), and different queuing behaviors per class, allowing the router to forward traffic based on the class type, making it possible to guarantee service and bandwidth across an MPLS network.

Domain Name Server (DNS)

Used in the Internet today to resolve domain names. The input to a DNS is a domain name (e.g., □elcordia.com); the response is the IP address of the domain. The DNS allows people to use easy to remember text-based addresses and the DNS translates those numbers into routable IP addresses.

Dynamic Host Configuration Protocol (DHCP)

A widely used configuration protocol that allows a host to acquire configuration information from a visited network and, in particular, an IP address.



Emergency Call Routing Function (ECRF)

Receives location information (either civic address or geo-coordinates) as input and uses this information to provide a uniform resource identifier (URI) that can be used to route an emergency call toward the appropriate public safety answering point (PSAP) for the caller’s location. Depending on the identity and credentials of the entity requesting the routing information, the response may identify the PSAP, or an Emergency Services Routing Proxy (ESRP) that acts on behalf of the PSAP to provide final routing to the PSAP itself. The same database that is used to route a call to the correct PSAP may also be used to subsequently route the call to the correct responder, e.g., to support selective transfer capabilities.

Emergency Data eXchange Language – Distribution Element (EDXL-DE)

EDXL-DE facilitates emergency information sharing and data exchange across local, regional, tribal, national, and international organizations in the public and private sectors. EDXL-DE acts as a wrapper that identifies to whom and under what circumstances emergency information is to be sent. Payloads may include a wide range of data types including geographic coordinates, text documents, and audio, video, and image files. Adoption of EDXL-DE as a standard by government agencies promotes emergency data interoperability among software and hardware systems, increasing the efficiency with which emergency managers receive information.

Emergency Services IP Network (IP network)

An IP-based inter-network (network of networks) shared by all agencies that may be involved in any emergency.

Emergency Services Routing Key (ESRK)

Either a 10-digit North American Numbering Plan (NANP) or non-NANP number that uniquely identifies a wireless emergency call, is used to route the call through the network, and used to retrieve the associated automatic location identification (ALI) data. These numbers can be dialable or non-dialable.

Emergency Services Routing Proxy (ESRP)

An i3 functional element that is a Session Initiation Protocol (SIP) proxy server that selects the next hop routing within the Emergency Services IP network (IP network) based on location and policy. There is an ESRP on the edge of the IP network. There is usually an ESRP at the entrance to an NG9-1-1 public safety answering point (PSAP). There may be one or more intermediate ESRPs between them.

Enhanced Variable Rate Codec (EVRC)

A voice coder used in code division multiple access (CDMA) networks. EVRC digitizes and compresses each 20 milliseconds of 8000 Hz, 16-bit sampled speech input into output frames of one of three different sizes through an EVRC digital signal processor, improving CDMA bandwidth utilization.

Enhanced Variable Rate Codec B (EVRC-B)

EVRC-B is an enhancement to Enhanced Variable Rate Codec (EVRC) and compresses each 20 milliseconds of 8000 Hz, 16-bit sampled speech input into output frames of one of the four different sizes.

Enhanced Variable Rate Codec Narrowband-Wideband (EVRC-NW)

Voice coder that uses different combinations of several kinds of frame rates according to specific conditions in order to lower the average data rate.

Enhanced Variable Rate Codec Wideband (EVRC-WB)

A wideband extension of Enhanced Variable Rate Codec B (EVRC-B), EVRC-WB provides speech quality that exceeds regular wireline telephony. EVRC-WB splits the speech spectrum into low frequency and high frequency bands and compresses them separately. Low frequency signal is coded based on the EVRC-B standard; high frequency signal coding is based on a linear predictive coding scheme. Principal applications of EVRC-WB include wideband telephony, video telephony, gaming, streaming, and ring-back tones.

Extensible Markup Language (XML)

An Internet specification for web documents that enables tags to be used that provide functionality beyond that in Hyper Text Markup Language (HTML). Its reference is its ability to allow information of indeterminate length to be transmitted to a public safety answering point (PSAP) call taker or dispatcher versus the current restriction that requires information to fit the parameters of pre-defined fields.

Fast Re-route (FRR) A multi-protocol label switching (MPLS) resiliency technology to provide fast traffic


Next Generation 9-1-1 Glossaryrecovery upon link or router failures for mission critical services. Upon any single link or node failures, it could be able to recover impacted traffic flows in the level of 50 ms.

Hot Standby Router Protocol (HSRP)

A networking protocol that supports the non-disruptive failover of IP traffic in special circumstances. HSRP allows network hosts to look like they are using a single router and keep connected if the first hop router being used fails to respond. HSRP guards against the failure of the first hop router in a network infrastructure when the router’s IP address cannot be found dynamically. HSRP normally joins several routers together to create a single virtual server that Kansas machines and networks use. HSRP helps to ensure that only one of the virtual server’s routers is working at any given time.

i3 The capability to receive IP-based signaling and media for delivery of emergency calls and for originating calls conformant to the NENA 08-003 i3 standards.

Initial Address Message (IAM)

The first message sent in a call set-up by a switch or exchange to another partner exchange. IAM seizes/reserves a circuit between the exchanges for the call and contains the information of numbers dialed by the calling party.

Internet Engineering Task Force (IETF)

Lead standard setting authority for Internet protocols.

Internet Protocol (IP) The method by which data is sent from one computer to another on the Internet or other networks.

IP Multimedia Subsystem (IMS)

IMS comprises all 3rd Generation Partnership Project (3GPP)/3GPP2 core network elements providing IP multimedia services comprising audio, video, text, chat, etc. and a combination of any or all of them delivered over the packet switched domain.

IP v4 The fourth iteration of IP and the first version to be widely deployed.

IP v6

A version of IP that is intended to succeed IPv4, which is the communications protocol currently used to direct almost all Internet traffic. IPv6 will allow the Internet to support many more devices by greatly increasing the number of possible addresses.

Intrusion Detection System (IDS)

A device or software application that monitors network or system activities for malicious activities or policy violations.

Intrusion Prevention System (IPS)

Network security appliance that monitors network and/or system activities for malicious activity. An IPS identifies malicious activity, logs information about said activity, attempts to block/stop activity, and reports activity.

Legacy Gateway

A signaling and media interconnection point between callers in legacy wireline/wireless originating networks and the i3 architecture, so that i3 public safety answering points (PSAPs) are able to receive emergency calls from such legacy networks.

Legacy Public Safety Answering Point (PSAP)

A PSAP that cannot process calls received via i3-defined call interfaces (IP-based calls) and still requires the use of centralized automatic message accounting (CAMA) and integrated services digital network (ISDN) trunk technology for delivery of 9-1-1 emergency calls.

Legacy PSAP Gateway AnNG9-1-1 functional element that provides an interface between an Emergency Services IP network (IP network) and an upgraded PSAP.

Location Determination and Acquisition Functions

Location determination includes the functions necessary to accurately and automatically (without input from the user) determine the position of the IP device and associate that location information uniquely with that device. Location acquisition refers to the functions necessary to make that location information available to the device on request, or to make that location information available to a proxy acting on behalf of that device so that location information can be used for emergency calling.

Location Information Server (LIS)

A LIS is a functional entity that provides locations of endpoints. A LIS can provide Location-by-Reference, or Location-by-Value, and, if the latter, in geo or civic


Next Generation 9-1-1 Glossaryforms. A LIS can be queried by an endpoint for its own location, or by another entity for the location of an endpoint. In either case, the LIS receives a unique identifier that represents the endpoint, for example an IP address, circuit-ID or MAC address, and returns the location (value or reference) associated with that identifier. The LIS is also the entity that provides the dereferencing service, exchanging a location reference or a location value.

Location Interwork Function (LIF)

The functional component of a legacy network gateway that is responsible for taking the appropriate information from the incoming signaling (i.e., calling number/automatic number identification [ANI], Emergency Services Routing Key [ESRK], cell site/sector) and using it to acquire location information that can be used to route the emergency call and to provide location information to the public safety answering point (PSAP). In a legacy PSAP gateway, this functional component takes the information from an automatic location identification (ALI) query and uses it to obtain location from a location information server (LIS).

Location to Service Translation (LoST)

A protocol that takes location information and a service uniform resource name (URN) and returns a uniform resource identifier (URI). Used generally for location-based routing. In NG9-1-1, used as the protocol for the Emergency Call Routing Function (ECRF) and Location Validation Function (LVF).

Location Validation Function (LVF)

Validates that a given description of a location is both precise enough to route a 9-1-1 call and will be recognizable by dispatchers. In NENA i3 specifications, valid locations are routable locations, such as a latitude/longitude or postal address, not necessarily Master Street Address Guide (MSAG)-validated.

Message Transfer Part

Part of the Signaling System 7 (SS7) used for communications in public switched telephone networks (PSTNs). Message transfer part is responsible for reliable, unduplicated and in-sequence transport of SS7 messages between communication partners.

Multi-protocol Label Switching (MPLS)

A mechanism that allows network administrators to perform a measure of traffic engineering within their networks.

Multi-purpose Internet Mail Extension (MIME)

An Internet standard that extends the format of email to support text in character sets other than American Standard Code for Information Interchange (ASCII), non-text attachments, message bodies with multiple parts, and header information in non-ASCII character sets. Use has grown beyond describing the content of email to describe content type in general. Request for Comment (RFC) 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 and RFC 2049 together define MIME specifications.

Network Address Translation (NAT)

In computer networking, the process of NAT, also known as network masquerading or IP-masquerading, involves re-writing the source and/or destination addresses of IP packets as they pass through a router or firewall. Most systems using NAT do so in order to enable multiple hosts on a private network to access the Internet using a single public IP address.

Network Time Protocol (NTP)

A powerful utility for synchronizing system clocks over a Transmission Control Protocol (TCP)/IP network.

Next Generation 9-1-1 (NG9-1-1)

NG9-1-1 is the next evolutionary step in the development of the 9-1-1 emergency communications system known as Enhanced 9-1-1 (E9-1-1) since the 1970s. NG9-1-1 is a system comprised of managed IP-based networks and elements that augment present-day E9-1-1 features and functions and add new capabilities. NG9-1-1 will eventually replace the present E9-1-1 system. NG9-1-1 is designed to provide access to emergency services from all sources, and to provide multimedia data capabilities for public safety answering points (PSAPs) and other emergency service organizations

NG9-1-1-specific Interwork Function (NIF)

The functional component of a legacy network gateway or legacy public safety answering point (PSAP) gateway that provides NG9-1-1-specific processing of the call not provided by an off-the-shelf protocol interwork gateway.



Open Shortest Path First (OSPF)

An adaptive routing protocol for IP networks. OSPF uses a link state routing algorithm and falls into the group of interior routing protocols, operating within a single autonomous system.

Originating IP network

The first emergency services network in the call flow. Originating networks (those initiating 9-1-1 calls) deliver their emergency calls to this network. An originating Emergency Services IP network (IP network) will make routing decisions and may forward the emergency call to another IP network for routing to the public safety answering point (PSAP).

P-Asserted-Identity (PAI)Used among trusted Session Initiation Protocol (SIP) entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication. See Request for Comment (RFC) 3325 section 9.1.

Point-of-presence (POP)

An artificial demarcation point or interface point between communications entities. An Internet POP is an access point to the Internet. It is a physical location that houses servers, routers, asynchronous transfer mode (ATM) switches and digital/analog call aggregators. It may be either part of the facilities of a telecommunications provider that the Internet service provider (ISP) rents or a location separate from the telecommunications provider.

Point-to-point Protocol (PPP)

A protocol that is used to establish a network link over a dedicated channel. It is widely used for Internet access. PPP is modular in design and can support different authentication protocols.

Policy-based Routing Function (PRF)

That functional component of an Emergency Service Routing Proxy (ESRP) that determines the next hop in the Session Initiation Protocol (SIP) signaling path using the policy of the nominal next element determined by querying the Emergency Call Routing Function (ECRF) with the location of the caller. A database function that analyzes and applies Emergency Services IP network (IP network) or public safety answering point (PSAP) state elements to route calls, based on policy information associated with the next-hop.

Premise Edge Generally a router between one network service provider's area and areas administered by other network providers.

Presence Information Data Format (PIDF)

PIDF is specified in Internet Engineering Task Force (IETF) Request for Comment (RFC) 3683; it provides a common presence data format for Presence protocols, and also defines a new media type. A presence protocol is a protocol for providing a presence service over the Internet or any IP network.

Presence Information Data Format-Location Objects (PIDF-LO)

Provides a flexible and versatile means to represent location information in a Session Initiation Protocol (SIP) header using an Extensible Markup Language (XML) schema.

Protocol Interworking Function (PIF)

That functional component of a legacy network gateway or legacy public safety answering point (PSAP) gateway that interworks legacy public switched telephone network (PSTN) signaling such as Integrated Services Digital Network (ISDN) User Part (ISUP) or centralized automatic message accounting (CAMA) with Session Initiation Protocol (SIP) signaling.

Real-time Text Protocol (RTTP)

Object-oriented bidirectional messaging protocol for delivering data over the Internet.

Real-time Transport Protocol (RTP)

A network protocol used to carry packetized audio and video traffic over an IP network that helps ensure that packets get delivered in a timely way.

Request for Assistance Interface (RFAI)

A Session Initiation Protocol (SIP) that replaces the legacy trunks between the E9-1-1 router and an IP-based 9-1-1 public safety answering point (PSAP).

Secure Shell (SSH)

A network protocol for secure data communication, remote shell services or command execution and other secure network services between two networked computers that it connects via a secure channel over an insecure network: a server and a Kansas.


Next Generation 9-1-1 GlossarySecurity Information Management (SIM)

In computer security, refers to the collection of data, such as log files, into a central repository for trend analysis.

Session Border Control

A commonly available functional element that provides security, network address translation (NAT) traversal, protocol repair and other functions to Voice over IP (VoIP) signaling such as Session Initiation Protocol (SIP). A component of a Border Control Function (BCF).

Session Description Protocol (SDP)

A format for describing streaming media initialization parameters for the purposes of session announcement, session invitation, and parameter negotiation. SDP does not deliver media itself, but is used for negotiation between end points of media type, format, and all associated properties.

Session Initiation Protocol (SIP)

An Internet Engineering Task Force (IETF)-defined protocol (Request for Comment [RFC] 3261) that defines a method for establishing multimedia sessions over the Internet. Used as the call signaling protocol in Voice over IP (VoIP), i2 and i3.

SIP User Agent The SIP user agent allows peer-to-peer calls to be made using a Kansas-server protocol.

Simple Network Management Protocol (SNMP)

A protocol defined by the Internet Engineering Task Force (IETF) used for managing devices on an IP network.

Synchronous Optical Network (SONET)

High speed digital transport over fiber optic networks using synchronous protocol.

Traffic Engineering (TE)A method of optimizing the performance of a telecommunications network by dynamically analyzing, predicting and regulating the behavior of data transmitted over that network.

Transmission Control Protocol (TCP)

The end to end reliability protocol that recognizes and corrects lower layer errors caused by connectionless networks

Transport Layer Security (TLS)

A protocol that ensures privacy between communicating applications and their users on the Internet. When a server and Kansas communicate, TLS ensures that no third-party may eavesdrop or tamper with any message. TLS is the successor to the Secure Sockets Layer (SSL).

Uniform Resource Identifier (URI)

A predictable formatting of text used to identify a resource on a network (usually the Internet).

Uniform Resource Locator (URL)

A URL is a uniform resource identifier (URI) specifically used for describing and navigating to a resource (e.g. http://www.nena.org).

Uniform Resource Name (URN)

An Internet resource with a name that, unlike a uniform resource locator (URL), has persistent significance - that is, the owner of the URN can expect that a person or program will always be able to find the resource. URN is a type of uniform resource identifier (URI).

User Agent (UA)

As defined for Session Initiation Protocol (SIP) in Internet Engineering Task Force (IETF) Request for Comment (RFC) 3162[5], the UA represents an endpoint in the IP domain, a logical entity that that can act as both a user agent Kansas (UAC) that sends requests, and as user agent server (UAS) responding to requests.

User Agent Kansas (UAC)

A Kansas application in a Session Initiation Protocol (SIP) system that initiates the SIP request that is sent to the user agent server (UAS). The combination of the UAC and the UAS is called the SIP user agent.

User Datagram Protocol (UDP)

One of several core protocols commonly used on the Internet. Used by programs on networked computers to send short messages, called datagrams, between one another. UDP is a lightweight message protocol, compared to Transmission Control Protocol (TCP), is stateless and more efficient at handling lots of short messages from many Kansass compared to other protocols like TCP. Because UDP is widely used, and also since it has no guaranteed delivery mechanism built in, it is also referred to as Universal Datagram Protocol, and as Unreliable Datagram Protocol.



Virtual Routing and Forwarding (VRF)

A technology included in IP network routers that allows multiple instances of a routing table to exist in a router and work simultaneously. This increases functionality by allowing network paths to be segmented without using multiple devices. Because traffic is automatically segregated, VRF also increases network security and can eliminate the need for encryption and authentication.


Appendix A – Standards, Guidelines and RFCs

NENA ADM-000 - Master Glossary of 9-1-1 Terminology NENA 08-002 v1 - Functional & Interface Standards for NG9-1-1 (i3) NENA 08-003 DRAFT - NENA i3 Solution NENA 08-503 v1 - VoIP Characteristics NENA 08-504 v1 - VoIP Standards Development Organizations (SDOs) NENA 08-506 - Emergency Services IP Network Design for NG9-1-1 NENA 75-001 v1 - NENA Security for Next-Generation 9-1-1 Standard (NG-SEC) NENA-INF-003 NG9-1-1 Potential Points of Demarcation NENA Baseline Next Generation 911 Description, February 22, 2011 RFC 3261 – SIP: Session Initiation Protocol RFC 3262 – SIP: Reliability of Provisional Responses in SIP RFC 3265 – SIP: Session Initiation Protocol – Specific Event Notification RFC 2328 – Open Shortest Path First (OSPF) Version 2 RFC 5340 – OSPF Version 3 (IPv6 updates) RFC 5880 – Bidirectional Forwarding Detection (BFD) RFC 5881 – Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 RFC 5882 – Generic Application of Bidirectional Forwarding Detection (BFD) RFC 4271 – Border Gateway Protocol 4 (BGP4) RFC 2474 – Differentiated Services (DS) field definition RFC 2475 – DSCP Architecture RFC 3411 – An Architecture for Describing Simple Network Management Protocol (SNMP)

Management Frameworks RFC 3412 – Message Processing and Dispatching for the Simple Network Management

Protocol (SNMP) RFC 3413 – Simple Network Management Protocol (SNMP) Applications RFC 3414 – User-based Security Model (USM) for version 3 of the Simple Network

Management Protocol (SNMPv3) RFC 3415 – View-based Access Control Model (VACM) for the Simple Network Management

Protocol (SNMP) RFC 3416 – Version 2 of the Protocol Operations for the Simple Network Management Protocol

(SNMP) RFC 3417 – Transport Mappings for the Simple Network Management Protocol (SNMP) RFC 3418 – Management Information Base (MIB) for the Simple Network Management Protocol

(SNMP)


Appendix B – DSCP Table

Example DSCP/IP Precedence Table with Typical AssignmentsDSCP Name Binary Decimal IP Precedence Type of Trafficcs0 000000 0 0 Best Effortcs1 001000 8 1af11 001010 10 1af12 001100 12 1af13 001110 14 1cs2 010000 16 2 Network Managementaf21 010010 18 2 Transaction Dataaf22 010100 20 2af23 010110 22 2cs3 011000 24 3 Call Signalingaf31 011010 26 3 Mission Criticalaf32 011100 28 3 Streaming Videoaf33 011110 30 3cs4 100000 32 4cs41 100010 34 4 Interactive Videocs42 100100 36 4cs43 100110 38 4cs5 101000 40 5ef 101110 46 5 VoIP RTP Streamscs6 110000 48 6 Routingcs7 111000 56 7 Network Control

RFP #EVT0003196 SpecificationsAppendix C – PSAP List

911 Trunk And Admin Line Count Monthly Call Volume Bandwidth

PSAP Name Address City Zip # of Seats

Combined

Landline

Wireless

Admin Lines

Wireline 911

Wireless 911

Admin Primary Backup

Allen County Communications

410 N State Iola 66749 3 3 2 5 276 104 4,106

Anderson County Communications Center

135 E 5th Avenue

Garnett 66032 2 3 - - 5 263 - -

Andover Police Department

1609 E Central Avenue

Andover 67002 2 3 2 125 292

Atchison County Communications Center

518 Parallel Street

Atchison 66002 3 4 2 3 900

Augusta Department of Public Safety

2100 N Ohio Augusta 67010 2 3 2 8 70 300 30

Barber County Sheriff's Department

124 E Washington

Medicine Lodge

67104 2 3 2 92

Barton County Communications Center (Joint City/County)

1300 Stone Street

Great Bend 67530 4 6 2 6 350 1,050 11,000

Brown County Sheriff's Office Communications

709 Utah Hiawatha 66434 2 4 - 8 40 100 555

Butler County Emergency Communications

121 S Gordy El Dorado 67042 6 11 - 7 30 70 20

Chase County Sheriff's Department

201 Walnut Cottonwood Falls

66845 2 2 3

RFP #EVT0003196 SpecificationsChautauqua County Sheriff's Department

215 N Chautauqua

Sedan 67361 2 2 2 40 77 2,094

Cherokee County Sheriff's Office

915 E Country Road

Columbus 66725 3 4 2 3 160 525 4,500

Cheyenne County Communications

212 E. Washington

St Francis 67756 2 2 2 23 32 1,917

City of Coffeyville Police Department

102 W. Seventh St.

Coffeyville 67337 2 4 - 8 50 80 1,000

City of Horton Police Department

205 E. 8th St. Horton 66439 1 - 3 15 - 150

City of Independence Police Department

120 N 6th Street Independence

67301 2 2 4 330 99 481

City of Parsons 217 N Central Parsons 67357 3 - 3 170 -

City of Pittsburg Police Department

201 N Pine Street

Pittsburg 66762 3 2 2 4 160 637 6,648

City of Wamego Police Department

408 Elm Street Wamego 66547 2 - 6 10 - 250

Clark County Sheriff's Office

221 W 9th Avenue

Ashland 67831 1 3 3 2 35 47 38

Clay County Sheriff's Department

539 Lincoln Clay Center 67432 2 4 2

Coffey County Sheriff's Office

605 W Neosho Burlington 66839 3 6 3 3 85 167 982

Comanche County Sheriff's Office

408 N. Central Coldwater 67029

Concordia Police Department Communications

401 W 6th Street

Concordia 66901 2 3 2 3 30 40 980

Cowley County Emergency Communications

321 E. 10th Ave. Winfield 67156 4 5 7 7 168 1,769 9,239

RFP #EVT0003196 SpecificationsCrawford County Sheriff's Office Communications

225 N. Enterprise Dr.

Girard 66743 3 4 2 7 200 400 7,000

Decatur County Emergency Communications

120 E Hall Street, #4

Oberlin 67749 2 2 2 4 25 50 2

Dickinson County Emergency Communications

109 E 1st Street, Suite 106

Abilene 67410 2 4 2

Doniphan County Sheriff's Office

219 S. Main Troy 66087 2 4 - - 7 92 138

Douglas County Emergency Communications

111 E 11th Street, Unit 200

Lawrence 66044 6 8 - - 27 1,185 2,518 11,502

Edwards County Sheriff's Department

312 S Massachusetts Avenue

Kinsley 67547 2 2 2 3 15 20

Elk County Treasurer's Office

127 N Pine Howard 67349 2 3 2 7 10 20 5

Ellis County 911/City of Hays

105 W 12th Hays 67601 4 5 239 508 7,724

Ellsworth County Sheriff's Office

212 N Kansas Ellsworth 67439 2 2 2 3 57 167 1,671

Emporia Police Department

518 Mechanic Street

Emporia 66801 4 4 3 602 454

Ford County Communications

100 Gunsmoke Street

Dodge City 67801 5 3 2 5 208 1,123 8,134

Fort Scott Police Department

1604 S National Fort Scott 66701 2 2 2 713

Franklin County Sheriff's Office/911

305 S Main Street

Ottawa 66067 3 2 4 8 336 1,039 4,836

RFP #EVT0003196 SpecificationsGarden City Police Department

304 N 9th Street Garden City

67846 6 6 - 6 250 1,100

Graham County Sheriff's Office

410 N Pomeroy Avenue, Suite 8

Hill City 67642 1 2 2 4 15 35 400

Grant County Law Enforcement Center

210 E Central Avenue

Ulysses 67880 1 3 3 80 88 2,451

Gray County Sheriff's Office

300 S Main Street

Cimarron 67835 1 2 2 4 27 100 960

Greeley County Sheriff's Office

208 E Harper Tribune 67879 2 3 1 2 3 8 5

Greenwood County Sheriff's Office

311 N Main Street, Suite A

Eureka 67045 2 3 2 215

Hamilton County Sheriff's Office

103 W Avenue C Syracuse 67878 1 3 2 3 12 45 5

Harper County 911 115 E Steadman Anthony 67003 2 4 2 10 166 223 1,752

Harvey County Communications

120 E 7th Street Newton 67114 5 8 2 1,750 1,750

Haskell County Sheriff's Office

300 S. Inman Sublette 67877 2 4 2 6 30 92 900

Hodgeman County Sheriff's Office

500 Main Street, 3rd Floor

Jetmore 67854 3 1 2 3 40 50 20

Hutchinson/Reno County Emergency Communications

210 W 1st Avenue

Hutchinson 67501 4 5 3 7 858 3,617 7,688

Jackson County Sheriff's Office

210 US-75 Highway

Holton 66436 2 3 1 7 57 180 39

Jefferson County 911 Communications

1230 Walnut St. Oskaloosa 66066 3 2 2 5 152 355

Jewell County Sheriff's Office

307 N Commercial Street

Mankato 66956 1 2 2 3 20 15 1,300

RFP #EVT0003196 SpecificationsJohnson County Emergency Communications

11880 S Sunset Drive

Olathe 66061 10 11 9 31 7,100 9,400 17,000

Junction City Police Department

210 E 9th Junction City

66441 4 4 2 8 266 1,556 20

Kansas City, Kansas Police Department Public Safety Communications

700 Minnesota Avenue

Kansas City 66101 17 14 9 10 2,374 13,138 17,852

Kearny County Sheriff's Office

106 E Washington Street

Lakin 67860 1 2 1 3 12 63 2,120

Kingman County Sheriff

120 N Spruce Street

Kingman 67068 2 3 2 7 66 222 1,129

Kiowa County Sheriff's Department

200 E Wisconsin Avenue

Greensburg

67054 1 3 1 5 27 77 1,117

Labette County Emergency Communications Center

718 5th Street Oswego 67356 3 4 2 12 90 1,290

Lane County Sheriff's Office

144 S. Lane Dighton 67839 2 1 2 3 5 10 5

Larned Police Department

419 Broadway Larned 67550 1 3 2 161 117 3,276

Leavenworth County Sheriff's Office

300 Walnut Leavenworth

66048 5 9 8 5 318 1,151 4,005

Leavenworth Police Department

601 S 3rd Street, Suite 2055

Leavenworth

66048

Leawood Police Department

9617 Lee Boulevard

Leawood 66206 3 3 4 332 469 4,207

Lenexa Police Department

12500 W 87th Street Parkway

Lenexa 66215 3 5 - 23 900 1,750 4,500

RFP #EVT0003196 SpecificationsLiberal/Seward County Emergency Communications

501 N. Washington

Liberal 67905-2199

4 3 3 11 187 1,023 4,873

Lincoln County Sheriff's Office

116 N 2nd Lincoln Center

67455 1 2 2 4 16 76 1,051

Linn County Sheriff's Department

107 S 4th Mound City

66056 2 3 133 133

Logan-Gove County 911 (Oakley Police Department)

209 Hudson Avenue

Oakley 67748 2 3 2 5 44 160 965

Marion County Emergency Communications

203 S 4th, Suite B

Marion 66861 3 3 2 2 77 192 359

Marshall County Sheriff's Office

1201 Broadway, Office B-4

Marysville 66508 2 7 4 80 154 2,700

McPherson County Communications

1177 W Woodside

McPherson 67460 3 5 3 6 1,048 2,444 9,552

Meade County Sheriff's Office

223 N Meade Center St

Meade 67864 1 1 3 4 17 25

Miami County Sheriff's Office

118 S Pearl Paola 66071 2 3 4

Mitchell County Communications Center

114 S Campbell Beloit 67420 2 3 2 7 35 80 1,800

Morris County Sheriff's Department

501 W Main Street

Council Grove

66846 1 8 292

Morton County Sheriff's Office

1025 Richard Street

Elkhart 67950 1 3 1 7 60 135

Nemaha Sheriff's Department

212 N 6th Seneca 66538 2 5 2 90 90

Neosho County Sheriff's Office

402 E State Street

Erie 66733 4 2 2 232 334 12,500

RFP #EVT0003196 SpecificationsNess County Sheriff's Office

221 W Main Ness City 67560 1 1 2 3 34 48 528

Norton County Sheriff's Office

101 S Kansas Ave

Norton 67654 1 2 2 4 43 97 1,849

Osage County Sheriff's Office

131 W 14th Street

Lyndon 66451 3 2 3 5 500 20,000

Osborne County Sheriff's Department

104 South Fifth St.

Osborne 67473 1 3 2 3 17 25

Ottawa County Sheriff's Department

312 N Ottawa Minneapolis

67467 3 2 2 36 70

Overland Park Police Department

12401 Hemlock Street

Overland Park

66213 10 8 6 11 18,575 62,046 165,554

Phillips County Sheriff's Department

425 F Street Phillipsburg

67661 1 4 2 5 20 100 1,600

Pottawatomie County Sheriff's Office Communications

106 Main Street Westmoreland

66549 3 3 1 6 42 289 3,885

Prairie Village Police Department

7710 Mission Road

Prairie Village

66208 2 3 4 4 400 400 2,000

Pratt County 911 1001 E 1st Pratt 67124 2 4 2 4 130 240

Rawlins County Communications

607 Main Street, #G

Atwood 67730 2 2 2 3 14 41 608

Republic County Communications Center

1815 M Street Belleville 66935 2 3 2 4 58 90 13,012

Rice County Emergency Communications

1482 W Highway 56

Lyons 67554 2 2 3 4 74 277 2,044

Riley County 911 1001 S Seth Child Road

Manhattan 66502 4 4 2 33 159 5,417

Rooks County Sherrif's Office Communications

115 N Walnut Stockton 67669 2 4 1 37 107

Rush County Sheriff's 715 Elm La Crosse 67548 1 2 2 3 29 85 1,007

RFP #EVT0003196 SpecificationsOffice CommunicationsRussell Police Department

339 E 8th St Russell 67665 2 5 5 30 60 50

Salina Police Department Emergency Communications

255 N 10th Salina 67401 4 5 5 8 590 1,143 40,000

Scott City Police Department

602 W 5th Street

Scott City 67871 1 2 2 7 14

Sedgwick County Emergency Communications

714 N Main Wichita 67203 24 15 5 7 31,390 29,259 10,871

Shawnee County Sheriff's Office

320 S. Kansas, Suite 200

Topeka 66603-3641

12 15 4 2,012 6,371

Shawnee Police Department/Justice Center

5850 Renner Road

Shawnee 66217 5 4 4 695 1,290 4,230

Sheridan County Sheriff's Office

940 Eighth St.

Hoxie 67740 1 2 2 3 8 23 410

Sherman County Communications

204 W 11th Goodland 67735 2 7 2 63 117

Smith County Communications

217 S Jefferson Street

Smith Center

66967 1 4 2 57 67 1,931

Stafford County Sheriff's Office Communications

209 N Broadway St John 67576 2 2 2 10 30 125

Stanton County Sheriff's Office

201 N Main Street

Johnson 67855 1 2 2 2 5 31 5

Stevens County Sheriff 911

505 S Monroe Hugoton 67951 1 2 3

RFP #EVT0003196 SpecificationsSumner County Emergency Communications/911

501 N Washington

Wellington 67152 4 3 2 6 466 834 2,202

Thomas County/Colby Police Department Communications

585 N Franklin Avenue

Colby 67701 2 3 2 57 172

Trego County Communications

525 Warren Avenue

WaKeeney 67672 2 1 2 8 25 158 3

Wabaunsee County Sheriff's Office Communications

215 Kansas Avenue

Alma 66401 2 2 1 29 54

Wallace County Sheriff's Department

313 N Main Street

Sharon Springs

67758 2 1 2 12

Washington County 911 Communications

301 B Street Washington

66968 2 3 2 1 35 146 9

Wichita County Sheriff's Office

411 S 4th Street Leoti 67861 1 1 2 26

Wilson County Central Dispatch

600 Madison Street

Fredonia 66736 2 3 4

Woodson County Sheriff's Office

105 W Rutledge Yates Center

66783 1 2 2 2 60 22 850


Appendix D – POPs/POIs

POP Name

Location Estimated Bandwidth

Data Center 1

200Mb

Data Center 2

200Mb

Data Center 3

200Mb

Regional POP 1

100Mb

Regional POP 2

100Mb

Regional POP 3

100Mb

Regional POP 4

100Mb

Regional POP 5

100Mb

Regional POP 6

100Mb


Appendix E – Service Level Agreements

ITIL Service Level Agreements for Incident Management

Vendor shall have processes and procedures for supporting a NOC that can rapidly triage calls. Vendor shall comply with the following ITIL guidelines for tracking, responding to, and reporting on network and system outages or failures:

Severity Level 1 Incidents resolved within 4 hours Severity Level 2 Incidents resolved within 8 hours Severity Level 1 and 2 Incidents responded to within 30 minutes Severity Level 3 Incidents resolved within 48 hours Severity Level 4 Incidents resolved within 96 hours Problems resolved within applicable time frame

Basic Service Level Agreements (SLAs) cover the vast majority of incidents. Under ITIL, the multitudes of SLAs are categorized into just a few, thus preserving penalty dollars for other metrics (like availability). ITIL’s common definitions of Severity Levels are:

Severity 1 IncidentAn incident shall be categorized as a “Severity 1 Incident” if the incident is characterized by the following attributes: the incident (a) renders a business critical system, service, software, equipment or network component unavailable or substantially unavailable, or seriously impacts normal business operations, in each case prohibiting the execution of productive work, and (b) affects either (i) a group or groups of people, or (ii) a single individual performing a critical business function.

Severity 2 IncidentAn incident shall be categorized as a “Severity 2 Incident” if the incident is characterized by the following attributes: the incident (a) does not render a business critical system, service, software, equipment or network component unavailable or substantially unavailable, but a function or functions are not available, substantially available, or functioning as they should, in each case prohibiting the execution of productive work, and (b) affects either (i) a group or groups of people, or (ii) a single individual performing a critical business function.

Severity 3 IncidentAn incident shall be categorized as a “Severity 3 Incident” if the incident is characterized by the following attributes: the incident causes a group or individual to experience an incident with accessing or using a system, service, software, equipment or network component or a key feature thereof and a reasonable workaround is not available, but does not prohibit the execution of productive work.

Severity 4 IncidentAn incident shall be categorized as a “Severity 4 Incident” if the incident is characterized by the


following attributes: the incident may require an extended resolution time, but does not prohibit the execution of productive work and a reasonable workaround is available.

Vendor shall provide financial remedies to the Council and their respective specified agencies, for each event in which service levels are not maintained. The Council expects all of Bidder’s network devices and services to perform at a level of 99.999% uptime. Failure to meet SLAs shall be measured per service-affecting outage. Penalties shall be assessed for failure to meet SLAs.

For Severity Level 1 and 2 incidents, a 10 percent penalty shall be assessed, whenever the initial period of resolution is exceeded. If the resolution period of length of time doubles, then the penalty shall increase to 20 percent. If the resolution period of length of time exceeds four times the initial period, then 50 percent of the Monthly Recurring Charges (MRC) shall be assessed.

SLA Reporting

The selected Vendor shall provide a measurement and reporting mechanism on a monthly schedule. The mechanism shall deliver SLA results to the Council and its designees on a monthly basis. The report shall include all performance items identified in the Bidder’s proposal and documented in contract negotiations.

SLA Violations

An SLA violation shall have occurred whenever:

The selected Vendor fails to meet any single performance level or

The average of any single performance item over the preceding 2-month period fails to meet the service level. This is an “early warning” of an unacceptable trend.

SLA Violation Damages

Damages shall apply whenever:

Any single performance item SLA violation occurs two consecutive months.

Any single performance item SLA violation occurs the month following an occurrence of SLA violation.

Damages are calculated as 10 percent of MRCs due the selected provider for network connectivity, maintenance or managed services as appropriate. The amount related to the damages is to be credited to the Council’s invoice the month immediately following the violation.

da.ks.govda.ks.gov/purch/contracts/default.aspx?getfile=evt... · web viewkansas ng9-1-1...

Documents