CTR055790_Contract_Documents_-_Vesta.pdf

Cover Sheet

Contract No.: CTR055790

Supplier Name: Vesta Solutions, Inc.

Solicitation No.: BPM003444

Statewide Procurement Manager:

Michael Hillebrand

Statewide Procurement Manager State Procurement Office Arizona Department of Administration 100 North 15th Avenue, Suite 402 Phoenix, AZ 85007 Michael.Hillebrand@azdoa.gov Office: 602-542-4229

Contents:

Executed Offer and Acceptance Form

Scope, Pricing and Terms and Conditions

Conformance Statements mailto:Michael.Hillebrand@azdoa.gov

Attachment 1

Offer and Acceptance Form

SUBMISSION OF OFFER: Undersigned hereby offers and agrees to provide ESInet and CHE Products and Services in compliance with the Solicitation indicated above and our Offer indicated by the latest dated version below:

Initial Offer:

1. 9/03/2020 x

Date initial

Revised Offers:

2. x 3. x x 4. x x date #1 initial date #2 initial date #3 initial

5.

4/26/2021 x 6. x x 7. x x date #4 initial date #5 initial date #6 initial

Best and Final Offer:

8. 3/26/2021 x

Date initial

Vesta Solutions, Inc. x

Offeror company name Signature of person authorized to sign Offer

42555 Rio Nedo Rd. Travis Boettcher, MSSSI VP

Address Printed name and title

Temecula, CA 92590 Katharine Gard, Strategic Executive Account Manager

City | State | ZIP Contact name and title

95-2580952 katharine.gard@motorolasolutions.com 615.456.5070

Federal tax identifier (EIN or SSN) Contact Email Address Contact phone number

CERTIFICATION: By signature in the above, Offeror certifies that it:

1. will not discriminate against any employee or applicant for employment in violation of Federal Executive Order 11246, [Arizona] State Executive Order 2009-9 or A.R.S. §§ 41−1461 through 1465;

2. has not given, offered to give, nor intends to give at any time hereafter any economic opportunity, future employment, gift, loan, gratuity, special discount, trip, favor, or service to a public servant in connection with the submitted offer. Failure to provide a valid signature affirming the stipulations required by this clause will result in rejection of the Offer. Signing the Offer with a false statement will void the Offer, any resulting contract, and may be subject to legal penalties under law;

3. complies with A.R.S. § 41-3532 when offering electronics or information technology products, services, or maintenance; and

4. is not debarred from, or otherwise prohibited from participating in any contract awarded by federal, state, or local government.

ACCEPTANCE OF OFFER: State hereby accepts the initial Offer, Revised Offer, or Best and Final Offer identified by the latest date and number at the top of this form (the Accepted Offer). Offeror is now bound (as Contractor) to carry out the Work under the attached Contract, of which the Accepted Offer forms a part. Contractor is cautioned not to commence any billable work or to provide any material or perform any service under the Contract until Contractor receives the applicable Order or written notice to proceed from Procurement Officer.

State’s Contract No. is: ________________ The effective date of the Contract is: __________ Contract awarded _________ Date Date

Procurement Officer Signature Procurement Officer Printed Name x

Michael Hillebrand

CTR055790 06/21/2021 06/18/2021

Request for Proposal Solicitation No. BPM003444

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office 100 N 15th Ave., Suite 402

Phoenix, AZ 85007

PART 2 of the Solicitation Documents

Table of Contents

Page 1 of 116 2 A v a i l a b l e o n l i n e a t A P P . A Z . g o v

Part 2: Scope, Pricing and Terms and Conditions

TABLE OF CONTENTS

SECTION 2-A: SCOPE OF WORK

SECTION 2-B: PRICING DOCUMENT

SECTION 2-C: SPECIAL TERMS AND CONDITIONS

SECTION 2-D: UNIFORM TERMS AND CONDITIONS

https://procure.az.gov/bso/

NG911 ESInet/NGCS and Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

SECTION 2-A: Scope of Work

Page 2 of 116 2

Section 2-A: Scope of Work

1.0 Introduction

The Arizona Department of Administration (ADOA) Arizona Strategic Enterprise Technology (ASET) Office on behalf of the State of Arizona (hereinafter referred to as the “State”) is responsible for administering the State 911 Program (911 Program) and is the statewide authority responsible for funding, implementing, and coordinating 911 services in the state.

To assist ASET in administering and maintaining a comprehensive and cost effective 911 Program, the State is seeking proposals from qualified organizations to establish statewide contracting vehicles to allow PSAPs across the state to procure NENA i3-compliant call-handling equipment (CHE).

2.0 Purpose and Background

The purpose of this solicitation is to select multiple NENA i3-compliant call-handling equipment (CHE) solutions allowing Arizona PSAPs the ability to procure from a statewide contract. The Contractor will work with ASET’s 911 Program to implement CHE solutions to ensure continuity of the State’s 911 service levels.

Key Solution Elements

The following subsection summarize the key elements of the solution being sought by the State.

2.1.1 Call-Handling Equipment (on-premise) and as a Service

The 911 Program seeks to establish a statewide contracting vehicle to allow PSAPs across Arizona to procure NENA i3-compliant CHE. The 911 Program intends to select a small number of CHE vendors as procurable options to allow PSAPs to select a CHE solution with capabilities that best meet a PSAP’s specific operational needs.

The Contractor shall be responsible for designing, documenting, installing, securing, operating), maintaining, monitoring, and evolving (in alignment with ongoing industry standards development) all call-handling design, architecture, and capabilities throughout the duration of the contract. End-user training shall be provided (as appropriate). Further, the Contractor(s) shall be responsible for developing PSAP-specific configurations (including speed dials, screen layouts, access and permissions schemes, and combinations of features and functionality) for each and, as requested, by each PSAP that makes a call-handling procurement under this contract.

Keeping the options to a small number is intended to minimize the risk of interoperability issues between CHE solutions and the ESInet/NGCS solution covered under a separate procurement. Additionally, due to the logistical challenges of providing centralized call handling to every PSAP across Arizona, ASET is seeking proposals from Offerors offering CHaaS, sometimes referred to as hosted or cloud-based, as well as the more traditional on-premise deployment model of call handling. To simplify the procurement process and minimize the number of CHE options to be supported across the state, ASET requires any Offeror providing a proposal in response to this RFP to support the deployment of their solution as both CHaaS as well as customer premise CHE. Call handling solutions that

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 3 of 116 2 support only one or the other deployment model will not be considered. To be clear, proposals that include one CHE solution as a service and a different CHE solution for customer premise deployment will not be considered.

Technical Requirements for call handling may be found in Section 3-A, subsection 3.2, of Part 3 of this solicitation package.

2.1.2 Interoperability

To ensure interoperability among all components of the Arizona statewide ESInet/NGCS, existing MR911 ESInet, existing CHE solutions (until current contracts expire), and the i3 CHE solutions selected as part of this procurement, all Offerors must commit to, and document (prior to completion of contract negotiation), interoperability with all other awardees’ solutions (ESInet/NGCS or CHE). If, as required, all solutions are truly NENA i3-compliant, this should not impose undue burden on the Contractor. Documentation of interoperability may take the form of any of the following (listed in order of probative value, from highest to lowest):

References from joint customers where solutions from multiple Offerors have been deployed and made operational for a minimum of six months.

Documentation of interoperability efforts undertaken within a non-production (i.e., laboratory) environment with the participation and support of all organizations represented in the combined solution.

Documentation of interoperability efforts undertaken within a non-production (i.e., laboratory) environment and by only one solution provider as a proof-of-concept exercise.

2.1.3 Bundled Solutions

ASET recognizes that some Offerors may offer both ESInet/NGCS (BPM 003445 Emergency Services Internet Protocol Network (ESInet) and Next Generation Core Services (NGCS)) as well as CHE in response to this RFP. Further, Offerors offering proposals in both areas may be able to provide some cost savings or other advantages by “bundling” their solutions together. While the 911 Program is very interested in the advantages of these bundled proposals, to conduct the necessary pricing analysis between all proposals from all Offerors (and in the event an Offeror offering a bundled solution is only awarded a contract for ESInet/NGCS or CHE, but not both), ASET requires that any Offeror proposing a bundled solution must ALSO provide pricing for the separate, “unbundled” (i.e., à la carte) procurement of the proposed ESInet/NGCS and CHE solutions.

Current Environment

Arizona has a population of 7.37 million residents, with most of the population density along the interstate (I) 10 and I-17 corridors. Maricopa County, home of the state’s capital, the city of Phoenix, contains 60% of the population. Tucson, located in Pima County, is the second largest city with almost 1 million residents. Arizona is a popular tourist destination for snowbirds and outdoor enthusiasts, with another 43.9 million visiting the state each year. The nation’s fourteenth largest state population continues to grow by 1.51% each year. Arizona also has a large rural area that is diverse in topography and population. This, along with a large tourist population visiting both remote and densely populated areas of the state, presents an ongoing challenge for existing 911 systems in operation across the state.

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 4 of 116 2

The Arizona PSAP community is comprised of city, county, state, tribal, federal, and private PSAPs.

Currently 80 PSAPs are funded by the 911 Program. There are 21 federally recognized tribes in the state and each acts as an independent sovereign nation. The availability of 911 services in tribal areas varies from some tribes having 911 capabilities similar to urban areas to non-existent in more remote areas. While parts of the state are served by first generation ESInet and NGCS solutions, there are still parts of the state served by enhanced and basic 911 services. It is of primary importance to the 911 Program that anyone calling 911 from any part of the state, and from any device, has reliable and equal access to emergency communications services.

Geographic Information Systems

The State and PSAPs have expended a considerable effort in developing the geographic information system (GIS) datasets necessary for the implementation of geospatial routing. While public safety GIS and GIS-supporting programs currently exist in Arizona at the local, regional, and state levels, these programs vary widely in maturity, capability, and focus. Existing geospatial data, in most jurisdictions, is not NG911-ready.

There is active engagement by two important statewide organizations. In 2009, the Arizona Geographic Information Council (AGIC) was established in legislation as Arizona's primary forum and oversight group for geographic information and geographic information technology (IT) issues and coordination efforts.1 This body of decision-makers is, among other things, tasked with the facilitation of coordination between GIS programs in Arizona. This responsibility is key to the success of the NG911 Public Safety GIS program, as a large percentage of the goals for supporting NG911 reach far beyond the 911 Program and require statewide effort at all levels of government.

The AZGeo Clearinghouse (AZGeo) is an initiative of AGIC. AZGeo is designed to provide GIS users with links to Internet map services, Federal Geographic Data Committee (FGDC)-compliant metadata, and geospatial data downloads. AZGeo is maintained and hosted by the Arizona State Land Department. Data on AZGeo includes GIS layers for administrative boundaries, demographics, environmental factors, hydrology, imagery, indices, mining, natural features, transportation, and more.2 AZGeo already has established itself as the de facto standard for GIS data sharing in Arizona.

Organization

The Arizona 911 community mostly is organized by county, with a few exceptions. Each county contains multiple PSAPs organized into a 911 system. There are 18 911 systems in the state, with a total of 80 PSAPs. Although the migration to NG911 is occurring by 911 system, the State plays a critical role in developing the implementation path and the final NG911 architecture for Arizona.

There are 44 PSAPs connected to the CenturyLink CHaaS and ESInet/NGCS and 3 PSAPs connected to the CenturyLink NGCS that are not part of the CHaaS solution. There are 24 PSAPs connected to the MR911 NG911 system. There are 9 PSAPs connected to Frontier’s legacy 911 selective router.

Text-to-911

All PSAPs have deployed text-to-911. There is a combination of “over the top” as well as integrated solutions. The 911 Program’s goal is to provide an integrated solution to all PSAPs through this procurement.

1 https://gis.azgeo.az.gov/agic/about-agic 2 https://azgeo.az.gov/azgeo/about-azgeo https://procure.az.gov/bso/ https://gis.azgeo.az.gov/agic/about-agic https://azgeo.az.gov/azgeo/about-azgeo

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 5 of 116 2

Management Information Systems

The 911 Program is in the process of implementing RapidDeploy’s Eclipse Analytics for use statewide. This tool provides a statewide dashboard that gives visibility regarding the status of PSAPs across the state and supplements individual management information system (MIS) solutions used by the PSAPs.

Goals of the Project

The primary goal of the 911 Program is to eliminate disparate 911 service levels by standardizing the delivery of NG911 capabilities to all geographic areas within the state, including tribal lands.

The secondary goal is interoperability among the state’s PSAPs and neighboring PSAPs in other states that support Arizona citizens, as well as Mexico.

3.0 Scope of Work

Industry Standards

ASET seeks standards-based services and solutions that comply with nationally accepted standards and requirements applicable to IP network architecture, cyber and data security, and interface functionality, in general, as well as public safety communications and NG911, specifically. All aspects of the Contractor’s proposed solution and service design, deployment, operation, and security should comply with the standards, requirements, and recommendations identified in the following table of documents. In addition, solutions and services should align, generally, with standards and recommendations of the following organizations, to the extent that such standards and recommendations are applicable to the Offeror’s proposed solution or services.

Alliance for Telecommunications Industry Solutions (ATIS)

Association of Public-Safety Communications Officials-International (APCO)

Central Station Alarm Association (CSAA)

Department of Justice (DOJ)

Internet Engineering Task Force (IETF)

National Emergency Number Association (NENA)

National Institute of Standards and Technology (NIST)

North American Electric Reliability Corporation (NERC)

Telecommunications Industry Association (TIA)

Further, Offeror’s solutions and services should comply with any additional standards, requirements, statutes, and policies as identified in specific sections throughout this document. The State received consultation from a third party in developing the Scope of Work for this solicitation. Please review the specifications and requirements to inform the State prior to the Closing Date of any concerns or issues related to the competitiveness of the requirements and their currency in terms of reflecting the developments of the industry standards that the state wants to incorporate into its next generation solution.

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 6 of 116 2

Table 1: Applicable Foundational Standards

SDO Standard ID Standard Title Standard

Description

Latest Revision/

Release Date3

Department of

Justice (DOJ)

CJISD-ITS-DOC-

08140-5.8

Criminal Justice

Information Services

(CJIS) Security Policy

Provides information security requirements, guidelines, and agreements reflecting the will of law enforcement and criminal justice agencies for protecting the sources, transmission, storage, and generation of criminal justice information

Version 5.8

June 1, 2019

IETF RFC 3261

SIP: Session

Initiation Protocol

(and its updates

RFC 3265, RFC 3853,

RFC 4320, RFC 4916,

RFC 5393, RFC 5621,

RFC 5626, RFC 5630,

RFC 5922, RFC 5954,

RFC 6026, RFC 6141,

RFC 6665, RFC 6878,

RFC 7462, RFC 7463,

RFC 8217, RFC 8591,

and RFC 8760)

Describes SIP, an application-layer control (signaling) protocol for creating, modifying, and terminating sessions (including

Internet telephone calls, multimedia distribution, and multimedia conferences) with one or more participants

Version 1

July 7, 2002 (RFC

3261) through

March, 2020

IETF RFC 3986

Uniform Resource

Identifier (URI):

Generic Syntax (and its updates

Defines the generic

URI syntax and a process for resolving URI references, along

Version 1

January 2005 (RFC

3986) through July

3 For any standards, if a newer version is available at the time of publication of this RFP, compliance will be judged relative to the latest version.

The exception to this being NENA/APCO-INF-005.1-2014 for which compliance will be judged relative to NENA’s updated Emergency Incident Data Object STA document https://procure.az.gov/bso/ https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center https://www.ietf.org/rfc/rfc3261.txt http://www.rfc-editor.org/info/rfc3265 http://www.rfc-editor.org/info/rfc3853 http://www.rfc-editor.org/info/rfc4320 http://www.rfc-editor.org/info/rfc4916 http://www.rfc-editor.org/info/rfc5393 http://www.rfc-editor.org/info/rfc5621 http://www.rfc-editor.org/info/rfc5626 http://www.rfc-editor.org/info/rfc5630 http://www.rfc-editor.org/info/rfc5922 http://www.rfc-editor.org/info/rfc5954 http://www.rfc-editor.org/info/rfc6026 http://www.rfc-editor.org/info/rfc6141 http://www.rfc-editor.org/info/rfc6665 http://www.rfc-editor.org/info/rfc6878 http://www.rfc-editor.org/info/rfc7462 http://www.rfc-editor.org/info/rfc7463 http://www.rfc-editor.org/info/rfc8217 http://www.rfc-editor.org/info/rfc8591 http://www.rfc-editor.org/info/rfc8760 https://www.ietf.org/rfc/rfc3986.txt

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 7 of 116 2

Standard

Description

Latest Revision/

Release Date3

RFC 6874 and

RFC 7320)

with guidelines and security considerations for the use of URIs on the Internet

NENA/ APCO REQ-001.1.2-2018

Next Generation

9-1-1 PSAP

Requirements

Provides requirements for functions and interfaces between an i3 PSAP and

NGCS, and among functional elements associated with an i3 PSAP

Version 1.1.2

June 10, 2018

NENA/ APCO INF-005

Emergency Incident

Data Document

(EIDD) Information

Document

Provides a recommended list of data components, their relationships to each other, the data elements contained within each data component, and the registries that control the available values for appropriate data elements. Initiates the process to create a National

Information

Exchange Model

(NIEM)

January 8, 2014

Scheduled to be replaced by an

Emergency

Information Data

Object (EIDO) standards document

NENA STA-015.10-2018

Standard Data

Formats for 9-1-1

Data Exchange & GIS

Mapping

Establishes standard formats for Automatic

Location

Identification (ALI) data exchange

Version 10

August 12, 2018 https://procure.az.gov/bso/ http://www.rfc-editor.org/info/rfc6874 http://www.rfc-editor.org/info/rfc7320 https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-REQ-001.1.2-2018_NG-PSA.pdf https://c.ymcdn.com/sites/www.nena.org/resource/resmgr/Standards/EIDD_INF-005_FINAL_20140221.pdf https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/nena-sta-015.10-2018_datafor.pdf

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 8 of 116 2

Description

Latest Revision/

Release Date3 between service providers and database management system (DBMS) providers, a GIS data model, a data dictionary, and formats for data exchange between the ALI database and PSAP controller equipment

NENA STA-008.2-2014

Registry System

Standard

Describes how registries (lists of values used in

NG911 functional element standards) are created and maintained

Version 2

October 6, 2014

NENA STA-010.2-2016

Detailed Functional and Interface

Specifications for the NENA i3

Solution

Builds upon prior

NENA publications including i3 requirements and architecture documents and provides additional detail on functional standards

Version 2

September 10, NENA INF-016.2-2018

Emergency Services

IP Network Design

(ESIND) for NG9-1-1

Provides information that will assist in developing the requirements for and/or designing an i3-compliant ESInet

Version 1

April 5, 2018

NENA 08-751

Technical

Requirements

Document

Provides requirements for

ESInet architecture

Version 1

September 28, https://procure.az.gov/bso/ https://c.ymcdn.com/sites/www.nena.org/resource/resmgr/Standards/NENA-STA-008.2-2014_(origina.pdf http://c.ymcdn.com/sites/www.nena.org/resource/resmgr/standards/NENA-STA-010.2_i3_Architectu.pdf http://c.ymcdn.com/sites/www.nena.org/resource/resmgr/standards/NENA-INF-016.2-2018_ESIND_20.pdf http://c.ymcdn.com/sites/www.nena.org/resource/resmgr/Standards/NENA_08-751.1_i3_Requirement.pdf

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 9 of 116 2

Description

Latest Revision/

Release Date3 and security, among other i3 PSAP functions, and establishes a foundation for future i3 standards development

NENA 75-001

Security for Next

Generation 9-1-1

(NG-SEC)

Establishes the minimal guidelines and requirements for levels of security applicable to NG911 entities

Version 1

February 6, 2010

NENA 75-502

Next Generation

9-1-1 Security

(NG-SEC) Audit

Checklist

Provides the educated user a method to document an

NG-SEC Audit

Version 1

December 14, 2011

NENA INF-015.1-2016

NG9-1-1 Security

Information

Document

Provides mechanisms and best practices for cybersecurity for i3 systems

Version 1

December 8, 2016

NIST FIPS 140-3

Security

Requirements for

Cryptographic

Modules

Specifies security requirements that will be satisfied by a cryptographic module utilized with a security system protecting sensitive but unclassified information

Version 2

March 22, 2019

NIST

Cybersecurity

Framework

Framework for

Improving Critical

Infrastructure

Cybersecurity

Provides standards, guidelines, and best practices that promote the

Version 1.1

April 16, 2018 https://procure.az.gov/bso/ http://c.ymcdn.com/sites/www.nena.org/resource/resmgr/Standards/NENA_75-001.1_NG-Security_20.pdf https://cdn.ymaws.com/www.nena.org/resource/resmgr/Standards/NENA_75-502.1_NG-SEC_Audit_C.pdf https://c.ymcdn.com/sites/www.nena.org/resource/resmgr/standards/NENA-INF-015_NGSEC_INF_20161.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf https://www.nist.gov/cyberframework https://www.nist.gov/cyberframework

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 10 of 116 2

Description

Latest Revision/

Release Date3 protection of critical infrastructure

TIA TIA-942-A

Telecommunications

Infrastructure

Standard for Data

Centers

Specifies the minimum requirements for telecommunications infrastructure of data centers and computer rooms, including single-tenant enterprise data centers and multi-tenant

Internet-hosting data centers

Revision A

March 2014

ESInet

3.2.1 Architecture

Figure 1 below depicts the demarcation points between the segments of the Arizona ESInet, NGCS, and call handling equipment. For drawing clarity, redundant components and facilities are not shown but redundancy is required. This solicitation covers the call handling portion and ESInet services that may be required to implement the Offeror’s solution, either the on-premise or the CHaaS implementation.

https://global.ihs.com/doc_detail.cfm?&rid=TIA&item_s_key=00414811&item_key_date=860905&input_doc_number=TIA-942&input_doc_title=#abstract

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 11 of 116 2

Figure 1 - NG911 Demarcation Points

Offeror’s ESInet solution should comply with the following:

Must be aligned with NENA “Detailed Functional and Interface Specifications for the NENA i3 Solution”

STA-010.2-2016 (or its successor document, when ratified).

Have diverse entrance facilities for aggregation sites (if different than core sites), core sites, and hosted call-handling facilities.

Primary (of at least two) connection into each facility should be terrestrial (copper or optical circuit); secondary connection(s) may be wireless (e.g., Long-Term Evolution (LTE), microwave, etc.).

Should offer optional network connectivity options to support call and data delivery to existing emergency communications district (ECD) mobile command and control assets.

Use open standards.

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 12 of 116 2

Offeror’s ESInet solution should comply with the following:

Support and enforce quality of service (QoS) marking using Differentiated Service Code Point (DSCP).

Should have a network traffic convergence of less than 54 milliseconds (ms).

Should maintain the Mean Opinion Score (MOS) of 4.0.

Is scalable to support growth by 50% without replacement of any critical hardware component.

Failure of any single instance of a hardware or software element, or physical connection, should not impact overall solution performance.

All network-connected elements should support at least two redundant network interfaces with automatic failover between them.

All powered devices should include a minimum of two redundant power supplies (each should be able to power the device alone) that would be connected to separate circuits OR be connected to a power-transfer device that allows a single power supply to be connected to two isolated power sources (i.e., circuits) with automatic, uninterrupted failover, in the event the primary circuit fails.

Meet the performance requirements of Appendix C, IP Network Measurement and Reporting Requirements.

3.2.2 Security

Offeror should:

Describe how their security in-depth approach embodies the best practices outlined in the latest version of

NENA’s Security for Next-Generation 9-1-1 Standard (NG-SEC) standard and whether security is treated as an integral function of each solution element from the initial design stage or if security is treated holistically as a separate overarching functional element of the solution.

Include a security plan (physical, applications, and network).

Utilize encryption in all communications across the ESInet

Ensure that all components and/or functional elements providing NG911 services, under a contract from this solicitation, carry credentials traceable to the national PSAP Credentialing Agency (PCA).

Have a credentialing plan/process for external entities with staff requiring access to ESInet elements or NGCS services.

Perform proactive analysis of the network for vulnerabilities including independent security audits of solution.

Possess a defined continuity of operations (COOP) plan as well as a disaster recovery (DR) plan and make those plans available for review at ASET’s request.

Provide access reports from facilities (physical access) down to the individual device level (physical or virtual access), upon request, when a service-impacting issue has occurred.

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 13 of 116 2

Require multifactor authentication for any access to externally accessible portals, user interfaces (UIs), etc.

(Policy Routing Function [PRF] portal, reporting portal, system dashboards, etc.).

Describe security software update policy, frequency, and procedures.

Describe plan/approach for adopting evolving security best practices.

Describe method and approach for complying with the requirements outlined in Appendix E – State of Arizona

IT Security Requirements.

Complete, and submit for approval, the Arizona Baseline Infrastructure Security Controls assessment spreadsheet, as described in Appendix E – State of Arizona IT Security Requirements. For this procurement, Offerors will need to comply with the Moderate requirements, i.e., all requirements designated as Required in column labeled “MODERATE [Control and Control Enhancement]” (column F) of the spreadsheet.

3.2.3 Documentation

Offeror should provide the following documentation for their proposed ESInet, NGCS, or both, as applicable:

Proposed network design (transitional and end state).

As-built documentation depicting circuit path and equipment diversity within 30 days of system acceptance.

Network interface specifications for interoperating with CHE.

As-built solution design documentation to include configured parameters and policy-routing flow-downs

(planned design and actual implemented design).

3.2.4 Monitoring and Alarming

Offeror should provide the following monitoring and alarming:

Physical access monitoring and reporting for all ESInet and CHE facilities.

Automated network node monitoring and alarming in real- or near-real-time.

Event logging and reporting in real- or near-real-time.

Ability to replicate select alerts to a third-party monitoring/reporting system.

User-definable notification levels and recipients with text and email delivery options.

Have an executive dashboard with (near) real-time updates of tickets and network status.

https://aset.az.gov/sites/default/files/Arizona%20Baseline%20Security%20Controls%202017_v2.xls

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 14 of 116 2

3.2.5 NOC/SOC

Offeror should provide the following functions:

24 x 7 x 365 staffed NOC/SOC with hot (preferred) or warm backup.

Ability for users to submit, track, and modify tickets by phone, email, and direct IT service management (ITSM) user access for incidents, problems, and changes.

Perform outward notifications and updates of customer tickets through phone, email, and text.

Fully documented escalation procedures with contact information for all primary and secondary responsible personnel at all levels of escalation.

Reason for outage (RFO) reports and regulatory compliance according to Federal Communications Commission

(FCC) standards.

Preliminary RFO reports are due to ASET within five business days of initial report of the issue; final root-cause analysis within 30 calendar days of root cause determination.

Media contact for any outage or service failure.

Service management contact for any outage or service failure.

Documented and maintained COOP plan.

Access to technical and executive staff for escalations.

NOC/SOC staff trained or experienced with 911 issues with regular refresher/update training plan.

Ability to access and troubleshoot, diagnose, and repair network remotely.

Ability and commitment to support the troubleshooting of all service affecting issues, even when it is determined that the root cause of the issue is outside the scope of the Contractor’s solution or service. (e.g., provide call traces and log analysis to assist in troubleshooting a third-party CHE location display issue).

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 15 of 116 2

Call Handling Requirements

ASET desires to establish a contract vehicle to allow PSAPs within the state to procure a variety of NENA i3-compliant CHE solutions. The intent is to negotiate contracts for a handful of Offerors’ solutions, in order to allow PSAPs to select a call-handling solution that best fits their unique operational needs.

3.3.1 Adopted Standards

Table 2: Adopted Standards

SDO

Document

Number Document Title Standard Description

Latest Revision/

Release Date

APCO/

NENA

1.102.2-2010

Public Safety

Answering Point

(PSAP) Service

Capability Criteria

Rating Scale

APCO and NENA jointly have developed an assessment tool to evaluate current capabilities of the

PSAP against models representing the best level of preparedness, survivability, and sustainability amidst a wide range of natural and manmade events

Version 2

July 28, 2010

NENA 75-001

NENA Security for

Next Generation

9-1-1 Standard

(NG-SEC)

The purpose of this document is to establish the minimum guidelines and requirements for the protection of NG9-1-1 assets or elements within a changing business environment

Version 1

February 6, 2010

NENA 08-751

NENA i3 Technical

Requirements

Document

Intended to specify the requirements the i3 (Long Term

Definition) Standard should meet

Issue 1

September 28, NENA

STA-010.2-

NENA Detailed

Functional and

Interface Standards for the NENA i3

Solution

This Standard Document (STA) is published by NENA as an information source for the designers, manufacturers, administrators and operators of systems to be utilized for the purpose of processing emergency calls

August 16, 2016

APCO/

NENA

54-750

Human Machine

Interface & PSAP

Display Requirements

NENA and APCO have jointly developed this document for the purpose of prescribing requirements for the human machine interface

(HMI) display for the NG9-1-1 system

Version 1

October 20, 2010

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 16 of 116 2

3.3.2 Common Call-Handling Requirements

Architecture

Offeror should support the following:

To simplify the procurement process and minimize the number of CHE options to be supported across the state, ASET requires any Offeror providing a proposal in response to the CHE portion of this RFP to support the deployment of their solution as both CHaaS as well as customer premise CHE. Call handling solutions that support only one or the other deployment model will not be considered. To be clear, proposals that include one

CHE solution as a service and a different CHE solution for customer premise deployment will not be considered.

Industry Standards Evolution

Offeror should support the following:

As industry standards evolve, Offeror’s solution should be upgraded to maintain conformance with the current version of established industry standards. Offeror’s solution should support new call-handling and security industry standards within 18 months of ratification of applicable industry standards. Conformance requirements apply also to the supporting standards referenced within each standard.

As solution updates are made to maintain conformance, the solution should not abandon services, features, or functionality in place at the time of the solution upgrade. Offeror must divulge and justify any performance or feature changes prior to the upgrade and report them to ASET and the affected PSAP(s) for approval.

I3 Conformance

Offeror’s solution should be an i3-conformant call-handling system.

Offeror should support the following:

Offeror’s solution should conform to the latest published/ratified version of NENA-STA-010.2-2016.

Offeror’s solution should interface with any NENA i3-conformant NGCS/ESInet.

Offeror should provide the number of their operational call-handling installations that utilize Presence

Information Data Format Location Object (PIDF-LO), HTTP-enabled location delivery (HELD), Location-to-Service

Translation (LoST), ADR queries, and other i3 protocols.

Call Handling Technical Support

Offeror should provide a 24 x 7 NOC/SOC for reporting and escalating software and hardware issues beyond

Tier 2.

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 17 of 116 2

Offeror should provide a redundant/secondary/backup NOC/SOC or equivalent support capabilities and capacity in the event the primary center is offline or otherwise unusable.

Offeror should provide a NOC/SOC COOP that provides for situations when NOC/SOC staff are unable to work onsite (such as the COVID-19 pandemic environment).

Solution Validation

Offeror should support:

At the discretion of each PSAP procuring call handling under this contract, independent third-party validation of all mandatory solution requirements and feature functionality prior to cutover of the site.

Provide transparency and access to all SIP messaging, CDRs, KPIs (e.g., MOS, delay, jitter, and packet loss at ingress and egress of delivering network), call logs, and any other data determined to be necessary in order to verify compliance with contractual obligations or to troubleshoot issues.

Documentation of completed results from ATPs.

Multi-tenant Capability

Offeror’s solution should support partitioning of tenants’ (i.e., agencies’) call-handling resources:

All ASET PSAPs should be able to create their own unique set of configurations (e.g., agent identifications [IDs, roles, permissions, and groups], screen layouts, speed-dial catalogs, MIS reports, system status screen layouts, etc.) that are not accessible to any other PSAP configured in the solution.

Authorized ASET administrative personnel should have full visibility into the enterprise, including configuration control and reporting.

Integrated Text-to-911

Offeror’s solution should support an integrated SMS-based text-to-911 solution via SIP/MSRP.

Offeror should:

Explain how text calls are received, queued, answered, and tracked in the system.

Explain disposition of attached multimedia and how text calls are handled by the MIS.

Explain how text calls are transferred and shared, as well as any limitations.

Provide examples of the applicable UIs (e.g., screenshots).

Provide the ability to text outbound from the 911 system.

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 18 of 116 2

Be able to accept SMS delivery via the existing ESInet connection (i.e., not require a separate connection for

SMS delivery).

Describe SMS foreign language translation capability.

Real-Time Text

Offeror's solution should support real-time text:

Offeror should describe its current implementation, if applicable, and any current beta or field trials.

If not currently developed, Offeror should provide details of when this capability will be included in the proposed solution as a no-charge upgrade/deliverable.

User Profiles

Offeror should support the following user profile characteristics:

Provide user profile settings, which are retained between logins, during upgrades. and between sessions (i.e., logoff and return next day).

Profiles should be stored on the network and be available from any workstation on the same call-handling system.

Solution should be capable of establishing skills-based profiles.

Access to call-handling assets (e.g., trunks, lines, queues, speed dials, configurations, screen layouts, etc.) may be controlled by a user’s profile.

Redundancy, Reliability, Availability

Offeror’s proposed solution should satisfy the following redundancy, availability, and diversity requirements:

Automatically (i.e., without manual intervention) transfer or failover core processing functionality upon detection of a problem that impacts the system’s ability to meet the 99.999% SLA.

During such an event, call-handling capacity and performance should not be degraded.

It should be possible to manually switch core processing functionality back to its normal operating state, as well as to have the system automatically recover and resync once the problem is corrected.

Provide a detailed description of how the solution achieves 99.999% availability.

Core processing functionality may be distributed across two or more call-handling centers (CHCs) provided (at the tenant PSAP’s discretion) by either the Offeror or the PSAP(s).

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 19 of 116 2

Offeror’s proposed solution should satisfy the following redundancy, availability, and diversity requirements:

Each CHC should have sufficient configured capacity to support 125% of busy-hour 911 call volume and call-mapping functionality for all PSAPs served by that call-handling system.

Should support the use of laptops as fully functional call-handling workstations with virtual private network

(VPN) capability to provide remote call taking via FirstNet or other broadband connectivity.

Describe solution’s hot-seating capabilities (i.e., the ability for a telecommunicator from one PSAP or agency to login at a workstation at a different PSAP or agency, provided both PSAPs/agencies are co-tenants on the same system, and have their “home” assets [e.g., trunks, lines, queues, speed dial lists, screen layouts, map, etc.] available at the other PSAP).

Security

Offeror should support the following security requirements:

Proposal should comply with NENA 75-001.1, Security for Next-Generation 9-1-1 Standard (NG-SEC). Offeror should detail how its solution addresses the requirements of the following sections of the standard:

1. Section 6 – General Security.

2. Section 7 – Safeguarding Information Access.

3. Section 9 – Network and Remote Access Security Guidelines.

Describe CHE security software update policy, frequency, and procedures (include frequency of antivirus updates).

Describe policy/approach to independent system security audits.

Describe method and approach for complying with the requirements outlined in Appendix E – State of Arizona

IT Security Requirements in Part 2 of this solicitation package.

Complete, and submit for approval, the Arizona Baseline Infrastructure Security Controls assessment spreadsheet, as described in Appendix E – State of Arizona IT Security Requirements in Part 2 of this solicitation package. For this procurement, Offerors will need to comply with the Moderate requirements, i.e., all requirements designated as Required in column labeled “MODERATE [Control and Control Enhancement]”

(column F) of the spreadsheet.

Long-term Availability

Offeror should commit to the following:

Six-month (minimum) advance written notification to ASET for any end-of-life (EOL) or end-of-support (EOS) component, with a plan for how the affected component(s) will be replaced without affecting service.

https://procure.az.gov/bso/

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 20 of 116 2

Offeror should commit to the following:

Proposed solution should be supported by the manufacturer(s) for a minimum of five years (plus any optional contract extensions) from the date of full system acceptance by Contracting Authority.

CAD Interoperability

Support for the CAD interface as described in NENA-STA-027.3-2018, NENA E9-1-1 PSAP Equipment Standards

ANS Candidate (originally NENA 04-001), July 2, 2018.

Support for IP-based connections.

Support for the CAD systems listed in the supplementary PSAP information packet, to be provided to all registered Offerors.

LIS/LDB

Support interface(s) with LIS and LDB as defined in NENA-STA-010.2-2016, NENA Detailed Functional and

Interface Standards for the NENA i3 Solution, (or its successor document, once published).

Describe how the proposed solution will address any transition period, during which both legacy ALI services and i3-compliant LDB/LIS services may need to be accessed by Offeror’s call-handling solution.

PSAP Hardware

All PSAP hardware (e.g., monitors, keyboards, mice, headsets, phones) must be new and covered by (extended) manufacturer warranty for no less than five years from the date the device is placed into operation.

Whenever supported by the device manufacturer, all servers, switches, routers, firewalls, and other devices within the solution should be configured with redundant power supplies and redundant network interfaces.

Offeror should work with interested PSAPs to interface/integrate CHaaS positions in their existing mobile command and control assets with wireless ESInet connectivity to the NGCS for call delivery.

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 21 of 116 2

Human-Machine Interface (HMI)

Offeror’s solution should comply with NENA 54-750, NENA/APCO Human Machine Interface & PSAP Display

Requirements, Version 1, October 20, 2010, and provide explanation of any areas of non-compliance with the standard.

If a call is default-routed or otherwise diverted to a destination other than the normally intended destination, the call-handling solution should recognize and present the originally intended destination and the reason why the call was diverted (ref. sections 3.3.CC of NENA 54-750).

Distinctive Ring Tones

Offeror's solution should support distinctive ring tones:

Offeror’s solution should provide a ring tone for 911 calls that is distinctly different than the ring tones for administrative calls and text messages.

Offeror’s solution should provide a ring tone for text messages that is distinctly different than the ring tones for administrative and 911 calls.

Offeror’s solution should support user-selected, distinctive ring tones for each automatic call distribution (ACD) queue or call type.

Offeror’s solution should provide distinctive ring tones to be customized by agent role or login.

Conference Controller

Offeror should support the following conferencing capabilities:

Conference controller should enable the telecommunicator 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 telecommunicator is handling.

Conference controller should automatically control the audio levels (AGC) of the calling parties so that no degradation of voice quality occurs.

Original telecommunicator should be able to mute/unmute (i.e., disable/enable the microphone of) any party on the conference.

Original telecommunicator should be able to deafen/undeafen (i.e., disable/enable the earpiece/speaker of) any party on the conference without muting that party’s audio (i.e., allow the telecommunicator to speak to others on the conference, without that party hearing, while still able to hear that party).

Original telecommunicator should be able to select and drop any party from the conference.

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 22 of 116 2

Offeror should support the following conferencing capabilities:

Original telecommunicator, or any of the conference parties, should be able to drop out of the conference without disconnecting the original caller.

Conferencing feature should support, at a minimum, any combination of up to six parties.

Call Monitoring

Offeror’s solution should allow authorized PSAP personnel to listen quietly to another telecommunicator’s live conversation.

Monitoring feature should be controlled by the authorized personnel’s credentials.

Monitoring should include the option as to whether the telecommunicator being monitored is made aware

(visually or audibly) when their call is being monitored.

Monitoring should not degrade the audio quality of the call.

Offeror should describe its options, or future plans for supporting a call-monitoring-like functionality for text-to-

911 sessions.

Call Barge-In

Offeror’s solution should allow authorized PSAP personnel to listen quietly and mute/unmute (barge-in) while listening to another telecommunicator’s live conversation.

The feature should be activated by utilizing a mouse or an easily invoked keyboard command.

This feature should not degrade the audio quality of the call.

This feature should be configurable to provide a tone to announce the barge-in.

The telecommunicator or supervisor is then part of a three-way call with the caller and original telecommunicator.

Offeror should describe options or plans for supporting a barge-in-like capability for text-to-911 sessions.

Callback

Offeror should support the following callback capabilities:

Callback of any 911 “call” (i.e., wireline, wireless, telecommunications device for the deaf/teletypewriter

[TDD/TTY], text, and VoIP callers) based on the calling party number.

NG911 Call-Handling Equipment (CHE)

Arizona Department of

Administration

State Procurement Office

Page 23 of 116 2

Offeror should support the following callback capabilities:

Should utilize the calling party’s number (CPN) of a 911 caller to invoke the callback process.

Should callback wireless or VoIP 911 calls utilizing the caller’s telephone number, located within the PIDF-LO fields.

Should use the Caller ID (CID) information to allow a callback to an administrative caller.

Any required dialing prefix digit(s) insertion/deletion (e.g., adding +9 or removing the area code) should be automatic and not require manual input.

Callback function should require only a single mouse click.

Abandoned Calls

Offeror's solution should support the following regarding abandoned calls:

Provide a visual and audible indication for abandoned calls.

Display the number of abandoned calls from the same callback number.

Clear the abandoned call count display upon successful callback and answer of the telephone number.

Provide a configurable option allowing for an automatic response to an abandoned call.

Provide each individual agency with the ability to configure the automatic-callback option to be enabled or disabled by the agency.

Allow the system to automatically attempt to return a call and/or text message to an abandoned call, and to prompt the recipient of the call to take an action (e.g., press 1 to notify the agency that no assistance is needed;

press 2 to be routed to 911).

Provide abandoned call reports as part…