Major Initiative > Next Generation 9-1-1 > Publications & Presentations

Proof of Concept Deployment Plan

Introduction

The U.S. Department of Transportation (USDOT) Next Generation 9-1-1 (NG9-1-1) Proof-of-Concept (POC) demonstration is envisioned to test key features and functionalities of the NG9-1-1 system. The Interim POC System Design Document defines the detailed system design of the POC demonstration test-bed. This document describes how the POC test-bed equipment will be deployed within the Booz Allen Hamilton, Texas A&M University, and Columbia University test laboratories and at selected Public Safety Answering Points (PSAP). It outlines detailed plans to develop and deploy software components required to successfully demonstrate the capabilities of the NG9-1-1 POC system design components. These include—

• Call origination software components for SIPc client, public switched telephone network (PSTN) gateway software, Internet Protocol (IP) gateway software, cellular gateway software, and telematics gateway software
• NG9-1-1 databases such as Identity and Access Management (IdAM), Business Rules, Location-to-Service-Translation (LoST), and Call Record
• Call receiving software components for IP-based Automatic Call Distribution (ACD) and Human Machine Interface (HMI).

The plan includes a detailed timeline and milestones for developing, testing, and deploying the POC test-bed components. In addition, it lists the configuration management (CM), risk management, maintenance, training, and communication plans and procedures that will be used to ensure effective and efficient deployment of the POC test-bed components.

1.1 Document Objective

The objective of this document is to define a comprehensive plan to deploy the POC test-bed components. The plan will assist the NG9-1-1 Project Team in monitoring and managing deployment activities. The schedule and milestones in this plan will serve as key checkpoints for ensuring that the POC test-bed infrastructure is appropriately deployed at the test facilities and the PSAPs.

1.2 Scope

The scope of this document includes developing detailed plans to deploy the following NG9-1-1 POC demonstration system design components:

• Call origination devices, including IP User Agents (UA) (laptop computers, IP wireless devices, and IP phones), cellular telephones (text, Short Message Service [SMS]), third-party call center (telematics), and IP Video Relay Services (VRS) for the deaf and hard of hearing community
• IP access and NG9-1-1 networks, including routers, switches, firewalls, and servers
• NG9-1-1 PSAPs, including routers, switches, HMI, and call termination infrastructure.

In addition, this document includes a detailed list of equipment that will be deployed in the POC test facilities and the PSAPs.

1.3 Document Overview

This document includes the high-level design, software development schedule, infrastructure deployment plan, and program management plans to deploy the NG9-1-1 POC system design. The remainder of this document is organized as follows:

• Section 2—POC Deployment Overview: Provides a high-level overview of the POC Deployment Plan
• Section 3—POC Demonstration Test Facilities and Sites: Outlines plan for selecting the test facilities and the PSAPs for the POC demonstration
• Section 4—NG9-1-1 POC System Design Component Deployment Plan: Outlines a detailed plan to deploy POC system design components at the test facilities and the PSAPs
• Section 5—POC Management and Administration Plan: Outlines a plan to monitor and manage the POC deployment activities
• Appendix A—Acronyms: Lists acronyms used in this document
• Appendix B— Source References: Provides a list of published documents that were referenced while developing this document
• Appendix C—Detailed Deployment Project Schedule : Includes the detailed schedule for managing the deployment activities
• Appendix D— Detailed Deployment Diagram: Depicts the detailed deployment layout of POC test-bed infrastructure that will be deployed at the test facilities and the PSAPs.

2 POC Deployment Overview

The infrastructure for the NG9-1-1 POC demonstration will be hosted in three test laboratories and at the selected PSAPs. The test facilities selected for the POC are—

• Booz Allen Center for Network & Systems Innovation (CNSI) at One Dulles
• Texas A&M Internet2 Laboratory
• Columbia University Next Gen laboratory.

Figures 2-1 depicts the high-level design of the NG9-1-1 POC environment

As shown, wide area network (WAN) circuits will provide connectivity between the laboratories and the PSAPs. The test facilities will host the following key components of the NG9-1-1 system design—

• Booz Allen CNSI—Call Origination and IP Access Network
• Texas A&M and Columbia University laboratories—NG9-1-1 Network.

The infrastructure required to receive the simulated 9-1-1 calls will be hosted at the PSAPs participating in the POC. Appendix D provides a detailed deployment diagram depicting equipment that will be deployed at the test facilities and the PSAPs.

PSAP equipment will be initially staged and tested to ensure that all potential implementation issues are identified and resolved prior to deploying it at the test facilities and the PSAPs. The team also intends to conduct site surveys at the selected PSAPs to ensure that the POC local area network (LAN) and WAN infrastructure can be deployed seamlessly. All deployment activities will be conducted based on the Project Schedule developed for the POC, which is included as Appendix C of this document. Milestones in the Project Plan will serve as key checkpoints for measuring progress on a regular basis.

2.1 POC Deployment Approach

Figure 2–2 depicts the Deployment Plan approach. As shown, the POC System Design, Tier 1 requirements, and NG9-1-1 Concept of Operations (CONOPS) were key sources of input for the Deployment Plan.

Figure 2-2 - Deployment Plan Approach

The team’s approach for developing the Deployment Plan was to prepare a comprehensive equipment list and timeline highlighting key milestones for deploying POC test-bed infrastructure at the test facilities and the PSAPs. To track software development activities, the team has created a prioritization matrix that includes two major software builds for the POC. The timeline for developing the software builds is provided in the Deployment Project Schedule in Appendix C.

In addition, several plans describing risk management, CM, maintenance, and training have been defined to manage the deployment activities effectively and efficiently.

2.2 Overall POC Deployment Timeline

Figure 2–3 depicts the high-level deployment timeline for establishing the Booz Allen CNSI, Texas A&M, and Columbia University test facilities and for deploying POC test-bed infrastructure at the PSAPs. It also shows the timeline for developing and deploying POC software components. More precise dates can be found in the project’s master schedule.

Figure 2-3 - Deployment Timeline Overview

The software components are grouped into two major builds—Build 1 and Build 2. Figure 2–4 depicts the sub-components included under each build, along with their prioritization.

Figure 2 - 4 —Software Development Build Overview

As shown, Build 1 will be developed during November–December 2007, and Build 2 will be developed during January–February 2008. Subsequent sections of this document outline, in detail, activities that will be performed under each subtask.

2.3 Key Schedule Constraints

Several key schedule constraints exist for developing, testing, and deploying the POC test-bed hardware and software components. These constraints must be met in the time frame outlined in the Deployment Schedule in Appendix C. Failure to comply with these constraints could lead to delays in the implementation and testing of the POC. These include—

• Generation of purchase order for equipment
• Sufficient lead time for equipment delivery
• Timely ordering of circuits
• Sufficient lead time for circuit provisioning
• Ability of software developers from Texas A&M and Columbia University, as well as technical experts from Booz Allen, to code, test, and deploy all software components included under Build 1 and 2 within the specified time frame
• Need for software refinement and troubleshooting to continue for at least 2 weeks after the POC demonstration officially begins.

It is critical that equipment and circuit orders are timed to avoid delay in receiving, staging, testing, and deploying the equipment at the test facilities and the PSAPs.

2.4 Key Assumptions

The following assumptions have also been made for developing, testing, and deploying the POC test-bed hardware and software components—

• Multiple teams will deploy equipment at the PSAPs simultaneously.
• OnStar™ is the telematics service provider and will provide technical expertise to assist in the interface development efforts.
• Verizon will provide service and technical expertise for the SMS interface development effort.
• AT&T will provide WAN connectivity between laboratories and PSAPs, and Internet2 connectivity will serve as the WAN backbone.
• Additional project documentation will guide certain POC activities—
  • The System Design Documentation identifies the components and features of the POC.
  • The POC Test Plan specifies the test configuration and activities for determining how the system will be tested.
  • The CM Plan guides the change control process.

3 POC Demonstration Test Facilities and Sites

The following sites have been selected for the NG9-1-1 POC demonstration:

• Booz Allen CNSI
• Texas A&M and Columbia University test laboratories
• Specific number of operational PSAPs that meet pre-defined criteria

The following sections describe, in detail, how these sites were selected and the specific requirements involved for participating in the POC demonstrations.

3.1 Test Facilities Selection Plan

The centralized IP hardware and custom software applications that will simulate switching and data collection, and that will permit testing of the POC design with simulated call traffic, will be physically located at Booz Allen’s CNSI, Texas A&M, and Columbia University laboratories. Key criteria considered in selecting these locations included—

• Laboratory capabilities to host POC infrastructure
• Software development capabilities at these locations
• Ability to leverage work currently being performed at these locations
• Ability to leverage existing hardware and software components
• Existing relationships between these location and vendors and other entities.

The laboratory sites will provide the foundation for supporting the POC test-bed infrastructure. Each location will be configured in accordance with the design included in the POC System Design Document. A high-level summary of the components that will be hosted in the test facilities is provided below:

• Booz Allen CNSI
  • Telematics interface
  • Cellular network interface
  • LoST (public facing)
  • Location Information Server (LIS)
  • Domain Name System (DNS)/Dynamic Host Configuration Protocol (DHCP) server
  • Session Initiation Protocol (SIP) proxy server
  • IP UAs
  • IP Video Relay Agent.
• Texas A&M Laboratory
  • NG9-1-1 Network’s routers, switches, and firewalls
  • Emergency Services Routing Proxy (ESRP)
  • LoST (Private)
  • NG9-1-1 routing components
  • Legacy data gateway
  • Legacy responder gateway.
• Columbia University Laboratory
  • Automatic Number Identification (ANI)/ALI data
  • Data Rights information
  • Business Rules database
  • Call Record information
  • IdAM.

The equipment deployed at these locations will permit implementation of the POC design in a distributed architecture. Calls will be originated from the Booz Allen CNSI laboratory and will be routed over the WAN to the NG9-1-1 Network hosted at the Texas A&M/Columbia test facilities. Subsequently, the NG9-1-1 Network will route the call to an appropriate PSAP as determined by the ESRP and LoST functions.

3.2 POC PSAP Selection Plan

The three-step approach depicted in Figure 3–1 was adopted to select PSAPs for participation in the POC demonstration.

Figure 3 - 1 —POC PSAP Selection Approach

The first step involved developing selection criteria and category weights. A detailed survey questionnaire was developed and sent to PSAPs nationwide. The response to the questionnaire enabled the selection team to identify PSAPs interested in participating in the POC demonstration. A weighted average scoring methodology was used to determine the overall selection score for each PSAP. The PSAPs were evaluated based on several selection criteria, including—

• Partnership—willingness to participate in the POC demonstration and provide geographical information system (GIS) data
• Technical—capability to support technical POC infrastructure, IP edge routers, T1 circuits, and next-generation HMI platform
• Financial—cost of travel to and circuit costs at the PSAP location.

Respondents were instructed to provide detailed responses for each of the identified criteria to—

• Establish the location’s willingness to participate in the POC demonstration
• Provide the reviewing team with an understanding of the location’s readiness to support the NG 9-1-1 system
• Identify the costs associated with deploying the POC test-bed infrastructure at their location.

Survey participants were also encouraged to offer additional information (such as telephony, computer aided dispatch [CAD], and ALI vendors and network overviews) that would provide the evaluation team with an understanding of the location’s overall technical capabilities.

Based on analysis of the responses and considering the cost and logistical impact of selecting a particular PSAP for the POC, the team short-listed the top 10 PSAPs. A joint project plan (JPP) will be provided to each of the chosen PSAPs that outlines terms and conditions for participating in the POC demonstration.

3.2.1 Specific Requirements with Partners and Participants

Some key requirements for entities that will participate in the POC are described below.

Test Facilities
Each site involved in the POC demonstration is required to provide secure access to the equipment. This will include ensuring access to all of the POC test-bed equipment is restricted. Booz Allen, Texas A&M, and Columbia University must be assured that the equipment will not allow open access to the public domain (Internet) during the POC demonstration. In addition, physical access to the test facilities will be maintained through escort only, card access, key access, or other security mechanism.

PSAP
During the PSAP selection process, respondents were asked whether they were willing to sign a Memorandum of Understanding (MOU) or a JPP with the NG9-1-1 Project Team. The team will enter into an agreement with each PSAP included in the POC demonstration. The JPP/MOU will outline the terms, conditions, and rules of engagement of the POC and document the PSAP’s assurance of a good faith effort to maintain security of the test data during the POC demonstration.

3.2.2 PSAP Selection Timeline

Figure 3–2 depicts the high-level PSAP selection timeline.

Figure 3 - 2 —PSAP Selection Timeline

The PSAP selection process commenced with the development of selection criteria and a questionnaire. Once USDOT approved the questionnaire, it was distributed to a large number of stakeholders within the public safety community to determine interest in participating in the POC. For those agencies wishing to be considered, details about their willingness to participate and technical information about their center was requested. More than 50 interested parties responded with completed questionnaires.

After review, the field of PSAPs was weighted and reduced to fewer than 12 for final consideration. Circuit costs for connectivity were also requested from service providers during the selection process. Once USDOT approved a list of PSAPs, the Project Team met with prospective PSAPs to discuss the participation requirements. After the complete set of PSAPs was selected for the POC, a general notification was distributed about the PSAP selection process and those PSAPs that would be participating.

3.3 Selected PSAP POC Participants

Based on the criteria outlined in the PSAP Selection Process, the following PSAPs were selected for the NG9-1-1 POC:

• City of Rochester—Emergency Communications Department, Rochester, New York
• King County E-911 System, Seattle, Washington
• Metropolitan Emergency Services Board— Ramsey Co. Emergency Communications Center, St. Paul, Minnesota
• State of Montana—Public Safety Services Bureau, Helena, Montana
• State of Indiana—Office of State Treasurer, Indiana Wireless 911 Board.

Additional PSAPs may be included at a later time to facilitate further testing. It is planned that the State of Indiana Network will also be integrated into the NG9-1-1 POC to further facilitate testing of unique security and integration challenges posed by the NG9-1-1 infrastructure. This effort will generate best practices for integrating an existing IP-enabled emergency network into the NG9-1-1 Network. However, it should be noted that the Indiana Network is not planned to be available for “Day 1” testing.

4 NG9-1-1 POC System Design Component Deployment Plan

The NG9-1-1 POC System Design includes several key components—

1. Call Origination
2. IP Access Network
3. NG9-1-1 Network
4. NG9-1-1 PSAP
5. NG9-1-1 Databases.

The call origination component will generate test calls from various devices such as IP UAs, cellular telephones, telematics devices, and PSTN telephones. The IP Access Network will simulate a service provider’s network and route calls generated by the call origination devices to the NG9-1-1 Network. The NG9-1-1 Network will determine the appropriate PSAP based on the location and other information and route the call to it. The NG9-1-1 PSAP will receive the call using the HMI tool developed for the POC demonstration. The HMI tool will run on the call taker’s workstation.

4.1 Call Origination and IP Access Network Deployment Plan

The call origination component of the NG9-1-1 POC demonstration environment will host endpoints that will generate 9-1-1 test calls. These will include—

1. IP UAs (laptop computers, IP telephones, IP wireless devices)
2. Cellular telephones
3. PSTN telephones
4. Telematics devices.

The PSTN telephones and IP UAs will physically connect to an integrated voice over IP (VoIP) telephony gateway/switch. The cellular telephones and the telematics devices will connect to interfaces that connect to the cellular and telematics service providers’ networks, respectively. Telematics and cellular software components will be developed that interface between a service provider’s network and the NG9-1-1 Network. This interface software will be responsible for providing transition mechanisms from the current technologies’ interfaces (cellular and telematics) to the NG9-1-1 signaling interfaces (SIP-based).

The IP access network will also be simulated at the Booz Allen CNSI test facility. Devices such as firewalls, routers, DNS, DHCP, LIS, SIP gateways, and the LoST (Public) server will serve as the IP access network’s core infrastructure. The following subsections outline the deployment design and timeline for implementing the POC call origination and IP access network components.

4.1.1 High-Level Test-Bed Design

The test-bed for the Call Origination and IP Access Network will be hosted at the Booz Allen CNSI laboratory. Figure 4–1 depicts the test-bed layout. Please note that while specific hardware and software have been chosen for the POC, the USDOT and the NG9-1-1 Initiative in no way endorse a specific vendor as the preferred hardware and software provider.

Figure 4 - 1 —Call Origination and IP Access Network Deployment Diagram

The POC System Design Document provides the detailed specification and design of the call origination and IP access network.

4.1.2 Software Development Plan

Several software-based sub-components will be developed to build the call origination and IP access network test-bed. These include—

Call Origination

1. SIP agents
2. Telematics interface
3. Cellular interface.

IP Access Network

• LIS server
• LoST server
• SIP gateways.

These sub-components have been grouped into the software Builds 1 and 2. The timeline and milestones for the software development activities can be found in the Deployment Project Schedule in Appendix C.

4.1.3 Test-Bed Equipment and Circuit Procurement Plan

To build the call origination and IP access network test-beds, network equipment and servers must be procured and deployed. Table 4–1 lists the equipment that will be procured, along with the deadlines for generating the purchase order.

Table 4 - 1 —Call Origination and IP Access Network Equipment List

A service provider’s WAN will be used to connect the IP Access Network to the NG9-1-1 Network. Table 4–2 lists the circuit details for providing this connectivity.

Table 4 - 2 —IP Access Network WAN Circuit Details

The Project Team will stage, test, configure, and deploy all equipment for the Call Origination and IP Access Network test-beds. The detailed deployment activities are included in the Deployment Project Schedule in Appendix C.

4.2 NG9-1-1 Network Deployment Plan

The NG9-1-1 Network includes the following key components:

• ESRP server
• NG9-1-1 databases
• NG9-1-1 routing function.

The ESRP will serve as the routing engine for the NG9-1-1 Network, routing all voice and data traffic to the appropriate PSAP. The term ESRP is interchangeable with SIPd, which is a SIP redirect client that provides name mapping, user location, and scripting services. The NG9-1-1 Network will require key databases to store, support, and control voice and data information. The following subsections outline the deployment design and timeline for implementing the POC NG9-1-1 Network components.

4.2.1 High-Level Test-Bed Design

The test-bed for the NG9-1-1 Network will be hosted at Texas A&M and Columbia universities. Figures 4–2 and 4–3 depict the test-bed layout at Texas A&M and Columbia universities, respectively. Please note that while specific hardware and software has been chosen for the POC, the USDOT and the NG9-1-1 Initiative in no way endorse a specific vendor as the preferred hardware and software provider.

Figure 4 - 2 —NG9-1-1 Network Layout at Texas A&M Laboratory

Figure 4 - 3 —NG9-1-1 Network Layout at Columbia University Laboratory

The POC System Design Document provides detailed system design and specification of the NG9-1-1 network components.

4.2.2 Software Development Plan

For the POC, the PSAPd client developed by the Columbia University will be used to provide the ESRP function. However, some enhancement will be required to the software to demonstrate features and functionalities listed in the Tier 1 requirements. The development effort for the NG9-1-1 databases is included in the software Builds 1 and 2.

4.2.3 Test-Bed Equipment and Circuit Procurement Plan

Table 4–3 lists the equipment required to establish the NG9-1-1 network test-bed at Texas A&M and Columbia universities.

Table 4 - 3 —NG9-1-1 Network Equipment List

A service provider’s WAN will be used to connect the NG9-1-1 Network to the PSAPs. Table 4–4 lists the circuit details for providing this connectivity.

Table 4 - 4 —NG9-1-1 Network Circuit Provisioning

The Project Team will stage, test, configure, and deploy all equipment for the NG9-1-1 Network test-bed. The detailed deployment activities are included in the Deployment Project Schedule in Appendix C.

4.3 NG9-1-1 Database Deployment Plan

The NG9-1-1 databases that will be deployed for the POC demonstration will include—

• ALI information (subset)
• Business Rules
• LoST.

Each of these databases will be deployed within the NG9-1-1 Network and will be used to demonstrate NG9-1-1 system capabilities. The NG9-1-1 Network will deliver the call information to the appropriate database and route the call to the relevant PSAP based on the information stored in the NG9-1-1 databases. The following subsections outline the deployment plan for each database.

4.3.1 ALI Database Deployment Plan

The ALI database will be simulated for the POC. This database will contain real-world information; however, data look-ups using live ALI servers will not be performed for the POC. The ALI database will be deployed within the network prior to the staging of the equipment. During the staging, ALI look-ups will be tested to ensure that the data are correctly retrieved.

The ALI database service will be installed at the Texas A&M laboratory. This configuration will allow it to interface with the other databases and NG9-1-1 system components. Location information contained in the database will include sample data provided by the selected PSAPs. These data will be used for the POC demonstration only.

The ALI data will be used to ensure that the location information can be captured using the ANI, as it is done today, and to demonstrate the call delivery process, as defined in the Architecture Analysis and System Design Documents.

Sample ALI data will be required from the PSAPs participating in the POC. The Project Team will use the data only for the POC demonstration and will delete the information upon completion of the POC.

4.3.2 Data Rights Database Deployment Plan

Data Rights controls which users of the NG9-1-1 system can access each type of data within the system, and to what degree they can share or pass on each data type to others within or outside the NG9-1-1 system.

Because the presumed Data Rights Management system (a segment of the Emergency Provider Access Directory [EPAD]) is not yet completely defined and has not been prototyped by a service provider, the POC will leverage existing data rights management capabilities of the respective devices and software. The data content will be chosen and established to allow demonstration of data controls, which will allow or disallow access to the various users involved in the POC—from PSAP personnel to those representing database managers, 9-1-1 authority groups, or service providers.

4.3.3 Business Rule Database Deployment Plan

The concept of providing business policies or rules in modifiable database form, rather than largely hard coding them or using switch translations, is new with NG9-1-1. Preparing the POC system will require that defined project requirements be converted to appropriate database content and then verified by the project team. The appropriate database server design will be defined based on the structure identified above.

A portion of a POC system server will represent the business rules management system. The location for this server will depend on what other functions are housed in this server and how they relate to the overall POC system segments, but the expected location is either the Texas A&M or Columbia laboratory.

A database management system (DBMS) data structure appropriate to the Business Rules fields and content will be researched and defined, based on the planned business rules methodology. Once the database framework is available, a representative set of data representing Business Rules controls will be loaded and verified. Testing for functional interaction with POC test plans will precede the demonstration phase.

4.3.4 LoST Database Deployment Plan

The LoST database will be segregated into LoST (Public) and LoST (Private) databases. The LoST (Public) will simulate the national level (root) structure and will be located at the Booz Allen CNSI laboratory. The LoST (Private) database will be part of the NG9-1-1 Network and will be deployed at the Columbia University laboratory. Dell servers will be used to support the LoST databases. The POC System Design Document includes detailed database structure and specifications.

4.4 NG9-1-1 PSAP Deployment Plan

As described in Section 3, PSAPs will be selected to participate in the NG9-1-1 POC demonstration. T1 circuits will be provisioned to connect the PSAPs to the NG9-1-1 Network test-bed located at Texas A&M and Columbia universities. Site visits will be conducted to determine the effort required to deploy the POC test-bed equipment at the PSAPs. The PSAP test-bed equipment includes—

• Router and switch
• T1 circuit
• Call server and IP ACD software
• Call taker workstation.

The following subsections outline the high-level design and deployment timeline for establishing the PSAP POC test-bed.

4.4.1 High-Level Test-Bed Design

The test-bed for the NG9-1-1 PSAP will be deployed at five active PSAP locations. The test-bed will have the ability to receive the voice and data traffic from the following call origination device types:

1. IP UAs (IP telephone, IP video devices, and laptop computers)
2. IP Video for Deaf and Hard-of-Hearing
3. PSTN UAs
4. Cellular (SMS)
5. Telematics.

Figure 4–4 depicts the high-level design of the POC PSAP test-bed. Please note that while specific hardware and software has been chosen for the POC, the USDOT and the NG9-1-1 Initiative in no way endorse a specific vendor as the preferred hardware and software provider.

Figure 4 - 4 —POC PSAP Test-Bed

The POC System Design Document lists detailed design and specifications of the POC test-bed sub-components.

4.4.2 Software Development Plan

NG9-1-1 PSAPs will require several software sub-components to process and display call data on the call taker workstation. The following software will be deployed within the NG9-1-1 PSAP test-bed:

1. IP ACD client
2. Conference Server client
3. GIS software
4. HMI.

IP ACD and conference server client developed by Texas A&M and Columbia University will be used to log, record, and search data for the call taker. Standard GIS software will be used to map, capture, store, analyze, and manage data and associated attributes. In addition, the Project Team will develop the HMI software for the POC, which will assist call takers in receiving call and efficiently displaying call data from IP UAs, cellular telephones, telematics devices, and PSTN telephones. The Deployment Project Schedule in Appendix C outlines the key activities and milestones for the POC software development.

4.4.3 PSAP Test-Bed Equipment and Circuit Procurement Plan

The POC PSAP test-bed equipment will be staged in one of the test facilities prior to deploying it at the PSAPs. All sub-components will be configured and tested to ensure seamless deployment. A call taker’s user access to the required servers and applications will be tested and validated to ensure secure access to NG9-1-1 system components. Initial site visits will be conducted to document and validate the following elements—

• T1 demarcation point
• Rack space availability
• Power requirements
• Heating/cooling requirements
• Wiring required to router and PSAP seat locations.

A second site visit will be conducted to install PSAP test-bed equipment and to train call takers to operate the NG9-1-1 HMI tool. Key activities that will be performed during installation are—

• Wiring and cabling
• Installing IP ACD/call server in the rack
• Installing call taker workstation
• Loading and testing HMI software
• Testing end-to-end connectivity using ping and other troubleshooting tools
• Training call takers.

Table 4–5 lists the equipment that will be procured and deployed at the PSAPs.

Table 4 - 5 —NG9-1-1 PSAP Equipment Procurement

Table 4–6 lists details of the circuits that will be provisioned at the PSAPs.

Table 4 - 6 —NG9-1-1 PSAP Circuit Provisioning

The POC Deployment Project Schedule in Appendix C lists detailed activities that will be performed to successfully deploy the POC test-bed equipment at the PSAPs. The high-levels activities are—

1. Selecting PSAPs for the POC
2. Agreeing to an MOU/JPP with the PSAPs
3. Conducting site surveys
4. Procuring equipment
5. Ordering circuits to the PSAPs
6. Provisioning circuits at the PSAPs
7. Staging and testing equipment
8. Deploying equipment
9. Executing acceptance test plan
10. Initiating execution of POC test scripts.

The deadlines and milestones are listed in the Deployment Project Schedule in Appendix C.

5 POC Management and Administration Plan

The Project Team will monitor and manage all POC deployment activities. Several plans have been developed to ensure efficient and successful deployment of the POC test-bed infrastructure at the test facilities and at the PSAPs. These include—

• Program management plan
• Communications plan
• CM plan
• Risk management plan
• Maintenance plan
• Training plan.

The following subsections provide a high-level summary of each plan and describe key activities to be performed to effectively and efficiently manage the POC deployment schedule.

5.1 POC Program Management

The Project Team’s organization chart is depicted in Figure 5–1. The Program Management team will provide the program management services.

Figure 5 - 1 —Project Team Task 3 Organization Chart

Detailed roles and responsibilities of the Program Management team and activities that it will perform are listed in the NG9-1-1 Initiative Program Management Plan.

5.2 Communications Plan

Regular communications with both internal and external stakeholders is important to the success of the POC deployment. The Project Team will use a mix of communication methods to help ensure relevant information is shared with those interested parties at appropriate times.

5.2.1 Internal Communications

Internal communications strive to keep project team members and the USDOT abreast of current project activities, action items, and key decisions.

Regular and Standing Meetings/Conference Calls include—

POC Status Update

Timing: Weekly (Tuesdays—2 p.m.)
Method: In-Person/Conference Call
Participants: Booz Allen, Kimball, NENA, Texas A&M/Columbia
Goal: Discuss tactical day-to-day activities (issues, action items, risks)

Monthly Leadership Meeting

Timing: Monthly, prior to the Monthly Progress Report
Method: Conference Call
Participants: USDOT, Project Team Leadership
Goal: Discuss high-level issues/risks, travel plans, resource planning, strategic issues

Monthly Progress Report (MPR)

Timing: Monthly
Method: In-Person—USDOT HQ
Participants: USDOT, Booz Allen, Kimball, NENA
Goal: Review current project status, identify action items, etc.

5.2.2 External Communications

Communications with external stakeholders is key to the success of the POC.

POC Status Update

Timing: Weekly (during POC)
Method: Conference Call
Participants: Project Team, Participating PSAPs
Goal: Discuss tactical activities (issues, action items, timing)

Stakeholder Engagement

Timing: Ad Hoc (coordinated with other stakeholder events as possible)
Method: In-Person (typically)
Participants: Project Team, Invited Stakeholders
Goal: Discuss POC status, data and information gathering sessions or workgroups

As needed, POC status may be delivered via other means (e-mail, conference calls, briefings, etc.) to larger groups.

5.3 Configuration and Change Management Plan

The Project Team has developed a detailed CM Plan that outlines steps and procedures for making configuration changes. This plan will be used to perform configuration and change management during the POC demonstration. The NG9-1-1 Change Proposal Process is illustrated in Figure 5–2, below.

Figure 5 - 2 —NG9-1-1 Change Control Process

One of the Project Team members will serve as the Configuration Manager and will coordinate activities with the Task Leads to document configuration items and to perform configuration changes. All activities will be logged in a CM Schedule of Activities table. The status of all CM efforts will be presented to USDOT monthly in the MPR. Steps and procedures defined in the CM Plan will be followed to conduct configuration and change management.

5.4 Risk Management Plan

Table 5–1 lists potential risks identified by the Project Team. For each risk, the table lists the probability of occurrence, level of impact on POC deployment activities, and a mitigation plan.

Table 5 - 1 —POC Deployment Risks and Mitigation Plan

The Project Team diligently captures risks in the Risk Mitigation Matrix and presents them to USDOT during the MPR. The Project Team is committed to developing a mitigation strategy for any new risk identified in the future.

5.5 Maintenance Plan

Hardware purchases for the POC will include standard 1-year hardware and software maintenance contracts with the manufacturer. These maintenance contracts will be coordinated through the Task Leads and the Configuration Manager. Hardware and software failures covered by maintenance will be coordinated through CM procedures.

Software maintenance purchases will follow industry standard practices. Software patches and revisions covered by the maintenance plan will be coordinated through CM.

5.6 Training Plan

Training of PSAP call takers will be conducted after installing and testing POC test-bed equipment at the PSAPs. PSAP call takers will be trained to use the HMI software tool. Access to the required systems will be reviewed, and system functionality will be demonstrated to the PSAP call takers. Documentation on system operation procedures will be delivered to PSAP personnel, and contact information for further training will be provided, if necessary. In addition, schedule for future testing will be provided to the PSAP Director.

Appendix A—Acronyms

Appendix B—Source References

The following published documents are primary sources of information used in this document.

• Next Generation 9-1-1 (NG9-1-1) System Initiative: Concept of Operations. USDOT ITS JPO. April 2007. http://www.its.dot.gov/ng911/pdf/NG911ConOps_April07.pdf—This formal document provides a user-oriented vision of NG9-1-1 in the context of an emergency services internetwork that can be understood by stakeholders with a broad range of operational and technical expertise. It is intended to communicate the vision of this system to stakeholders so that they can be actively engaged in its development and deployment.
• Next Generation 9-1-1 (NG9-1-1) System Initiative: System Description and Requirements Document. USDOT ITS JPO. November 2007. http://www.its.dot.gov/ng911/pdf/NG911_HI_RES_Requirements_v2_20071010.pdf—This formal document identifies NG9-1-1 user and system needs. Operational, systems, and data behaviors to support NG9-1-1 required activities are also detailed in this document.
• Network Architecture Properties in 2010, Extending E9-1-1 to Satellites, and Generic Architectures to Support Video and Advanced Service . NRIC VII Focus Group 1B, FCC. June 2005. http://www.nric.org/meetings/docs/meeting_20050329/FG1B%200305%20Report.pdf Long Term Issues for Emergency/E9-1-1 Services (Draft) http://www.nric.org/meetings/docs/meeting_20051019/NRICVII_FG1B_Report_September_2005.pdf—These documents are designed to provide a set of specific recommendations regarding future emergency communications network properties and their capabilities by 2010 to support the exchange of voice, data, text, photographs, and live video through the emergency services internetwork to the PSAP and beyond.
• Communication Issues for Emergency Communications Beyond E911: Final Report—Properties and network architectures for communications between PSAPs and emergency services organizations and personnel. NRIC VII Focus Group 1D, FCC. December 2005. http://www.nric.org/meetings/docs/meeting_20051216/FG1D_ Dec%2005_Final%20Report.pdf —The purpose of these documents is to describe the properties that network architectures for communications between PSAPs and emergency services personnel must meet.
• NENA i3 Technical Requirements Document [NENA i3] . NENA VoIP/Packet Technical Committee Long-Term Definition Working Group. September 2006. http://www.nena.org/media/files/08-751_20060928.pdf—This document provides requirements for the National Emergency Number Association (NENA)-recommended standard for the i3 architecture underlying NG9-1-1 for end-to-end emergency calling over IP networks (Voice over IP [VoIP]).
• Requirements for Emergency Context Resolution with Internet Technologies [ECRIT]. IETF. August 2006. http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-12.txt—This document enumerates requirements for emergency calls placed by the public using VoIP and general Internet multimedia systems, where Internet protocols are used end-to-end.
• The ATIS-ESNet Next Generation Emergency Services (NGES) Subcommittee will define a new messaging and interaction protocol between PSAPs and Emergency Services Networks to significantly expand the paradigms that provide those services today. Various summaries and briefing materials are available at the NGES Subcommittee website at http://www.atis.org/esif/nges.asp. The NGES messaging and interaction protocol will be specified as an American National Standard (ANS). Messaging interfaces have been adopted for trial use.
• NENA Technical Information Document (TID) on the Network Interface to IP Capable PSAP [NENA 08-501]. NENA Migration Working Group of the Network Technical Committee. June 2004. http://nena.org/9%1e1%1e1TechStandards/ TechInfoDocs/NENATIDIPPSAPIF.pdf—This TID provides information to guide manufacturers of network equipment and PSAP Customer Premises Equipment (CPE) in the development of IP-based interfaces between the network and PSAP CPE and to assist E9-1-1 network service providers and PSAPs in implementing such interfaces.
• NENA IP-Capable PSAP Minimum Operational Requirements Standard [58-001]. Issue 2, June 2007. http://www.nena.org/media/files/NENA58-001OpsIP-PSAPStd-final06092007.pdf—This standard contains a list of capabilities or features that are expected to be supported in a PSAP using IP-based 9-1-1 equipment, and software developed in an open architecture environment that will allow interoperability at all levels of the 9-1-1 network, regardless of vendors.
• NENA Data Standards for Local Exchange Carriers, ALI Service Providers, & 9-1-1 Jurisdictions [NENA 02-011]. NENA Technical Committee Chairs. November 2006. http://www.nena.org/media/files/02-011_20061121.pdf—This document establishes technical standards for all service providers involved in providing telephone services.
• NENA Data Standards for the Provisioning and Maintenance of MSAG Files to VDBs and ERDBs [NENA 02-013]. NENA Data Technical Committee, VDB/MSAG Working Group. January 2007. http://www.nena.org/media/files/02-013_20070109.pdf—This document contains system and process requirements for the Validation Database (VDB), ESZ Routing Database (ERDB), and system administrator to maintain the Master Street Address Guide (MSAG) and ALI required in i2 system architecture.
• NENA Technical Information Document on Future 9-1-1 Models [NENA 07-501]. NENA Future Models Working Group. June 2004. http://www.nena.org/ media/files/07-501_20040601_1.pdf—This TID lays out the framework for 9-1-1 systems that will provide the functionalities that public safety responder agencies need or foreseeably will need to respond to emergency 9-1-1 calls.
• A Framework for Inter-Domain Route Aggregation [RFC 2519]. IETF Network Working Group. February 1999. http://www.ietf.org/rfc/rfc2519.txt—This document presents and analyzes a framework for inter-domain route aggregation, a flexible and scalable solution.
• A Border Gateway Protocol (BGP-4) [RFC 1771]. IETF Network Working Group. March 1995. http://www.ietf.org/rfc/rfc1771.txt—This document defines an Internet routing protocol.
• Interim VoIP Architecture for Enhanced 9-1-1 Services (i2) [NENA 08-001]. December 2005. www.nena.org/9-1-1TechStandards/Standards_PDF/NENA_08-001_V1_12-06-05.pdf—This document is the NENA recommended standard to support the interconnection of VoIP domains with the existing Emergency Services Network infrastructure furthering end-to-end emergency VoIP calling between citizens and PSAPs.
• HTTP Enabled Location Delivery (HELD) [draft]. IETF Geopriv Working Group. January 2008. http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-04.txt—This draft document outlines a Layer 7 Location Configuration Protocol (L7 LCP) that is used for retrieving location information from a server within an access network.
• RTP: A Transport Protocol for Real-Time Applications [RFC 3550]. IETF Network Working Group. July 2003. http://www.ietf.org/rfc/rfc3550.txt—This document RTP, the real-time transport protocol that provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio or video.
• Session Initiation Protocol (SIP): Locating SIP Servers [RFC 3263]. IETF Network Working Group. June 2002. http://www.ietf.org/rfc/rfc3263.txt—This document describes how SIP uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact.
• SDP: Session Description Protocol [RFC 4566]. IETF Network Working Group. July 2006. http://www.ietf.org/rfc/rfc4566.txt—This document defines the Session Description Protocol (SDP) which is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.
• LoST: A Location-to-Service Translation Protocol [draft]. IETF ECRIT Working Group. August 2007. http://tools.ietf.org/html/draft-ietf-ecrit-lost-06.txt— This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services.

Appendix C—High Level Task 3 Deployment Schedule

Appendix D—Detailed Deployment Diagram

Please note that while specific hardware and software has been chosen for the POC, the USDOT and the NG9-1-1 Initiative in no way endorse a specific vendor as the preferred hardware and/or software provider.

Updated August 20, 2008 10:23 AM