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

Proof of Concept Test Plan

DOCUMENT CHANGE HISTORY

Table of Contents

1    Introduction

2    General Testing Methodology

3    Initial Laboratory Site Testing
4    King County, Washington PSAP Site Testing
5    Helena, Montana PSAP Site Testing
6    St. Paul, Minnesota PSAP Site Testing
7    Rochester, New York PSAP Site Testing
8    Indiana PSAP Site Network-to-Network Testing
9    Total System Testing
10  Demonstration Testing
11  Retesting (If needed)
12  Compliance Matrix Appendix A—Acronyms

Appendix B—Glossary
Appendix C—Source References
Appendix D—Use Case Tests

Appendix E—Total System Test Scripts

Appendix F—Task 3C/3D Report
Appendix G—Data Collection Results

1    Introduction

This document is the Proof of Concept (POC) Test Plan and procedures that will be used to verify that hardware and application functionality meet the requirements of the U.S. Department of Transportation (USDOT) Next Generation 9-1-1 Initiative (NG9-1-1).  It describes the test procedures and provides the base information to validate the Next Generation 9-1-1 proof of concept. This document continues to build on the work that has been completed.  The NG9-1-1 Concept of Operations (CONOPS) High-Level Requirements document and Architecture Analysis report were developed in the initial phases of the project.  These documents served as the basis for the initial POC development work.   The POC development work created the following additional documents: The Interim System Design Document, Human Machine Interface Display Design Document, and the POC Deployment Plan.  These documents are used as a basis for this document.  These documents are available for download at the USDOT NG9-1-1 website: http://www.its.dot.gov/ng911.

1.1    Overview

The POC demonstration is a culmination of several steps.  The following subsections provide a brief overview of these steps and how this demonstration will be supportive of the POC.  The subsections will be—

• The NG9-1-1 project
• The POC
• The testing to be performed.

1.1.1    Overview of the NG9-1-1 Project

The intent of the USDOT NG9-1-1 project is to provide leadership, guidance, and resources to work with the public and private 9-1-1 stakeholders, and lay out a path to achieve a phased migration of a nationally interoperable (Footnote 1) emergency services internetwork. USDOT understands that access to emergency services provided by 9-1-1 in today’s world of evolving technology will ultimately occur within a broader array of interconnected networks comprehensively supporting emergency services—from public access to those services, to the facilitation of the services, to the delivery of the emergency information to dispatchers and first responders. More specifically, USDOT views the NG9-1-1 system as a transition to enable the general public to make a 9-1-1 “call” (Footnote 2) from any wired, wireless, or Internet Protocol (IP)-based device, and allow the emergency services community to take advantage of enhanced call delivery and advanced functional and operational capabilities through new internetworking (Footnote 3) technologies based on open standards.  By enabling the general public to access 9-1-1 services through virtually any communications device, the NG9-1-1 system provides a more direct ability to request help or share critical data with emergency services provider from any location.  In addition, call takers at the Public Safety Answering Points (PSAP) will be able to transfer emergency calls to another PSAP and forward the location and other critical data, such as text messages, images, and video, with the call.

1.1.2    Overview of the Proof of Concept

The USDOT NG9-1-1 POC demonstration is envisioned to prove the feasibility of the key features and functionalities developed as part of the NG9-1-1 system.  This demonstration will demonstrate the Tier 1 next generation features of the 9-1-1 system.  These include—

• Call origination using—
• IP User Agents (UA) such as laptops, IP phones, IP wireless devices, and Session Initiation Protocol (SIP) clients (audio, data, video message, picture message, and live video)
• Cellular devices (Short Message Service [SMS]) (data and text message)
• Third-party call center (telematics, audio, and/or data)
• IP and Video Relay Services (VRS) for the deaf and hard-of-hearing community (text, and video)
• Call support and processing using—
• Standard IP access networks
• NG9-1-1 Network components such as Emergency Services Routing Proxy (ESRP) and data gateways
• NG9-1-1 databases such as Business Rules, Location-to-Service Translation Protocol (LoST), Enterprise Location Information Server (LIS), and Call Record.
• Call termination at the PSAPs using—
• IP Automatic Call Distribution (ACD) systems
• IP phones and workstations
• Human machine interface.

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

• Booz Allen Center for Network & Systems Innovation (CNSI) at One Dulles
• Texas A&M Internet2 Laboratory located in College Station, Texas
• Columbia University Next Gen laboratory located in New York, New York.

After configuration and testing at the test bed locations is complete, equipment and software will be installed at the selected PSAP locations.  The five PSAP locations are—

• City of Rochester—Emergency Communications Department, Rochester, New York
• King County E-911 System, Seattle, Washington
• Metropolitan Emergency Services Board—Ramsey County 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.

Several software and hardware components are incorporated into the POC to successfully demonstrate NG9-1-1 capabilities.  These include—

• Call origination software components such as—SIPc client, cellular, and telematics interfaces to provide voice, video, and text communications
• NG9-1-1 databases such as Business Rules, LoST, and Call Record
• Call receiving software components such as IP-based ACD and Human Machine Interface (HMI).

The POC includes the configuration management (CM), risk management, maintenance, training, and communication plans and procedures that will be used to assist in the effective and efficient development of a full NG9-1-1 system.

1.1.3    Overview of the Testing to Be Performed

The testing process is based on the Tier 1 requirements of the NG9-1-1 design documentation.  This testing will take place over a period of six to eight weeks.  The testing will be performed in phases.

Testing will be initially performed in the laboratory test bed environment.  Next, the PSAP locations will be tested.  Finally, the entire system will be tested.  To accomplish this sequence of tests, specific tasks will be completed.  All tests will be using POC equipment, systems, and test data.  At no time will live calls be handled on the POC system or will the test calls be sent to live 9-1-1 systems.

Several NG9-1-1 project documents detail selected functions of an NG9 1 1 system.  These functions are defined as “use cases” and “requirements” in these documents.  They are broken down into levels of importance, and the highest are categorized as Tier 1 requirements.  This test plan is based on those use cases and requirements.  The use cases and requirements defined in the NG9-1-1 project have been integrated into industry-standard testing methodologies.  The testing methodologies will then be applied to the laboratory test bed environment, the PSAP environment, and an end-to-end system test.

The documentation of the test results will be incorporated into the final NG9-1-1 POC test results document.

1.2    Objectives

The objective of this POC Test Plan is to define the procedures and logistics necessary to test the functionality of equipment and applications associated with the NG9-1-1 POC.  This functionality has been defined in previous documents as use cases and requirements.  The following objectives were incorporated into the test plan:

• Provide a formal testing process
• Test each Tier 1 requirement identified in the NG9-1-1 system
• Document the results of each test
• Collect data from the tests
• Provide useable information from which to develop the final documents such as—
• Final design
• Benefit-cost analysis
• Transition plan
• Provide verifiable documentation that the concept, as developed, is functional.

1.3    Scope

The scope of this document is limited to the testing of the Tier 1 requirements of the USDOT NG9-1-1 system requirements.  This test plan documents the project's activities to be performed, the schedule of activities, assigned responsibilities, and resources required, including staff, tools, and computer facilities.  The documentation of the test results will be incorporated into the final NG9-1-1 documentation. This test plan applies to the approved and stable systems, including software, hardware, and documentation that have reached a deployable state within the purview of the NG9-1-1 POC system design.  Testing will occur after the equipment and applications are tested in a laboratory environment and the team has deployed equipment to the PSAPs.

1.4    Document Overview

The NG9-1-1 POC Test Plan document is organized into the following numbered sections:

2    General Testing Methodology

This POC test plan is designed to test the high level (Tier 1) requirements as developed and documented in the USDOT NG9-1-1 Requirements document.  These requirements are not a complete list of all functions and requirements for future NG9-1-1 systems; rather they are a basic set of requirements. The NG9-1-1 POC development process has generated several documents that outline the functions of an NG9-1-1 system.  As part of the development process, the NG9-1-1 team developed a set of use cases that covers the basic functions of an NG9-1-1 system.  Each of these use cases was further refined into a set of requirements for each use case.  These were documented in the System Description and Requirements Document.  Based on these requirements, this test plan was developed. Each use case is listed with the associated requirements.  Each requirement is used to develop a test for that requirement.  Each test associated with a requirement is described, along with the test procedure.  The basic format of each requirement is—

• Test Description—Provides a brief overview of the test
• Test Procedures—Lists the test steps
• Expected Results—Describes what is expected to happen
• Pass/Fail—Will be used during the actual test to record Pass or Fail
• Results—Will be used during the actual test to document the results of the test.

While each requirement has a set of test steps associated with it, there is considerable duplication among the requirements.  Consequently, a single test call will be used to test more than one requirement at a time.  This will reduce the time needed to complete the testing.

2.1    Testing Process

The testing will proceed in phases.  Because the most complicated processes will be housed at the various laboratory sites, they will be tested first.  Next, the individual PSAPs will be tested, and last, the entire system.  These tests will be conducted by the testing team that is described in Section ‎2.2.1.  Testing team training will take place prior to the testing.

2.1.1    Initial Laboratory Site Testing

The laboratories will be tested as a group.  The equipment housed in these laboratories is intended to work together and will be tested as such.  Seven use cases will be tested at the laboratories, as described in Section 3.  This testing will last approximately 2 to 3 weeks.

During this testing phase, each technology type will be used to deliver a call to the system.  To properly test these system functions, devices to place test calls will be needed, and at least one HMI workstation will be available near or in one of the laboratories.  Four test teams will be deployed, with one at each laboratory plus a fourth team working with the HMI equipment.  The test teams will communicate and coordinate with each other through a conference bridge.

2.1.2    Individual PSAP Site Testing

The PSAPs will be tested individually.  The equipment housed in these PSAPs is intended to work independently and will be tested as such.  Nine use cases will be tested at each PSAP as described in Sections 4 through 8.  This testing will last approximately two to three weeks.

All tests will use POC equipment, systems, and test data.  At no time will live calls be handled on the POC system or will the test calls be sent to live 9-1-1 systems.

Each PSAP is expected to take two to three days to complete testing during the two- to three-week time frame.  A test team will go to each PSAP and conduct the tests while a second test team will be located at the laboratory as oversight.

During this phase, the Network-to-Network connections will be demonstrated.  The Indiana state system will have a PSAP connected to the system.

To facilitate the testing of each technology, each PSAP will be assigned primary technologies on which to focus its testing.  This approach will allow testing of all technologies during the PSAP testing phase.  Each requirement test that is not technology specific will be conducted by the PSAP using the technology assigned to it.  These assignments are listed below.

2.1.3    Total System Testing

The total system will be tested as a unit.  The equipment is intended to work together and will be tested as such.  Seven scenarios will be tested as described in Section 9.  This testing will last approximately two weeks.

During this testing, the test teams will break into smaller teams to cover each of the eight locations during the total system testing.

2.1.4    Demonstration Testing

The total system will be demonstrated as a unit.  This part of the test plan is more a demonstration than a test.  It will allow input from the public safety community to the processes and systems of the POC.  Seven scenarios will be tested.  This testing will last approximately 3 days.

A demonstration will be prepared that includes a graphical (animated) slide or slides describing the processes that each scenario uses.  This slide will be used to visualize and explain the processes that occur prior to and following placing the test call.  

It is expected that there will be two demonstrations scheduled in the 3-day period and that all eight locations will participate in the demonstrations to obtain the most feedback from the demonstration.

A survey similar to the PSAP survey developed for the data collection tasks will be used to gather data from these tests.

2.1.5    Data Collection

This test plan addresses the Tier 1 use cases and their associated requirements.  However, the tests described herein are only a part of the testing that will occur—a large amount of data will be generated and collected during the POC.  This data is described in the additional document completed for—

• Task 3C—Data Analysis Plan
• Task 3D—Data Acquisition Plan.

When this test plan is completed, the data collection reports will become a part of this test plan to provide a complete picture of the results of the POC.

2.1.6    Retesting (If needed)

Should any additional test be needed, or tests need to be redone, the final two weeks will be used.  This segment of the testing is intended to cover, for example, a guest at the public demonstration asking whether the system can perform a particular function.  A quick test can be developed and tested after the demonstration phase.

2.2    Testing Resources

The deployment test plan for the NG9-1-1 project will include the personnel and equipment required for a successful test.  Personnel required and other resources will also be specified.  

2.2.1    Testing Personnel

The testing will require participation of most of the personnel assigned to the project in order to operate and oversee the POC.  To assist in the coordination and documentation of the testing, a dedicated testing team will be selected that will have no other duties during the testing period.  This test team will oversee the testing.

Optimally, the test team will consist of a testing leader and four teams of four testers.  For each team, the senior person on the team will be assigned as the team leader.  These teams will consist of—

• PSAP Operations Specialist
• PSAP Technical Specialist
• NG9-1-1 Software Specialist
• NG9-1-1 Network Specialist.

Each team will operate as a team during the first two test phases (Laboratories and PSAPs).  During the total system test and the demonstrations, two smaller teams will be used, each consisting of two members.  The senior person on each of these smaller teams will be the team leader.  These teams will consist of—

• PSAP Technical Specialist
• NG9-1-1 Software Specialist

and

• PSAP Operations Specialist
• NG9-1-1 Network Specialist.

2.2.2    Equipment Requirements

The POC Test Plan will require the following resources:

• Test telephones and devices
• Testing devices listed in Task 3C and 3D
• Conference bridge
• Speakerphone at each site
• Computer with demonstration phase slide show
• Computer screen projector
• Handouts
• Sign-in sheets (daily, presentations, and operators)
• Copy of this test plan
• Assorted office supplies
• HMI workstation at a Laboratory location.

2.2.3    Scheduling

The POC Test Plan schedule is designed to allow flexibility in the testing as needed.  The final report will document the actual dates of the testing phases.

The Deployment Team will coordinate with the Project Manager to plan activities.

3    Initial Laboratory Site Testing

At the Laboratory sites, seven use cases will be used for testing.  All three laboratory sites will be tested at the same time.  The requirements associated with the use cases below will be tested.

The test scripts listed in Appendix D for these use cases will be used.

4    King County, Washington PSAP Site Testing

At each PSAP site, nine use cases will be used for testing.  The requirements associated with the use cases below will be tested. During the testing, PSAP staff will be involved and perform many of the tester functions.

The test scripts listed in Appendix D for these use cases will be used.

5    Helena, Montana PSAP Site Testing

At each PSAP site, nine use cases will be used for testing.  The requirements associated with the use cases below will be tested. During the testing, PSAP staff will be involved and perform many of the tester functions.

The test scripts listed in Appendix D for these use cases will be used.

6    St. Paul, Minnesota PSAP Site Testing

At each PSAP site, nine use cases will be used for testing.  The requirements associated with the use cases below will be tested. During the testing, PSAP staff will be involved and perform many of the tester functions.

The test scripts listed in Appendix D for these use cases will be used.

7    Rochester, New York PSAP Site Testing

At each PSAP site, nine use cases will be used for testing.  The requirements associated with the use cases below will be tested. During the testing, PSAP staff will be involved and perform many of the tester functions.

The test scripts listed in Appendix D for these use cases will be used.

8    Indiana PSAP Site Network-to-Network Testing

At each PSAP site, nine use cases will be used for testing.  The requirements associated with the use cases below will be tested. During the testing, PSAP staff will be involved and perform many of the tester functions.

These tests will include an additional test to show a network-to-network connection.

The test scripts listed in Appendix D for these use cases will be used.

9    Total System Testing

After the successful completion of the component testing in Phases 1 and 2, the total system will be tested.  This testing will consist of processing calls through the complete system and recording the results. During the testing, PSAP staff will be involved and perform many of the tester functions.

To cover all of the possible scenarios, the PSAPs will be configured to use the following answer types and transfer points:

Three basic scripts will be used for each technology being tested:

• Call Setup
• Call Handling
• Data Handling.

These types of test scripts are developed to cover each of the Tier 1 requirements.  The use cases covered in each type of the test script are listed below.

The specific test scripts that will be used for each use cases are listed in Appendix E.  Each test script is generic enough to be used for each of the technologies being tested.  The following technologies will be tested in the total system test:

10    Demonstration Testing

The demonstration tests will be similar to the total system tests but limited in number.  Only seven technologies will be demonstrated during this phase of testing.  This testing will consist of processing calls through the complete system and recording the results.  During the testing, PSAP staff will be involved and perform many of the tester functions.

To cover all of the possible scenarios, the PSAPs will be configured to use the following answer types and transfer points:

The test scripts used in the Total System Testing will also be used in this phase.  The test scripts listed in Appendix E for these use cases will be used.  The following technologies will be tested in this phase:

11    Retesting (If needed)

This section is reserved for use if needed during the POC.  If new tests or retests are needed, they will be documented in the section.

12     Compliance Matrix

This section will contain a spreadsheet listing each requirement and the results of the testing in a table format.

Appendix A—Acronyms

Appendix B—Glossary

Appendix C—Source References

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

1. 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 is a formal document that 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.  
2. Next Generation 9-1-1 (NG9-1-1) System Initiative: System Description and High-level Requirements Document.  USDOT ITS JPO.  July 2007.  http://www.its.dot.gov/ ng911/pdf/NG911_HighLevel_Requirements2007.pdf—This is a formal document that provides a high-level overview of NG9-1-1 system operations.
3. USDOT_NG911_POC_RequirementTableTiered_11Sept2007.xls.  This is an internal document that contains the requirements developed in previous work.  This file contains the updated Tier 1 requirements.
4. NG9-1-1 Interim System Design Document.  USDOT ITS JPO February 2008.  NOT POSTED—This is a formal document that details the interim NG9-1-1 system design.  This design was used in the preparation of the POC.
5. Proof of Concept Deployment Plan.  USDOT ITS JPO February 2008 http://www.its.dot.gov/ng911/pubs/NG911_proof_concept.htm—This is a formal document that details the plan to deploy the proof-of-concept resources and to perform the POC.
6. HMI Design Document.  USDOT ITS JPO January 2008. NOT POSTED—This is a formal document that details the Human Machine Interface.  This design was used in preparation of the POC.

Appendix D—Use Case Tests

This Appendix includes the detailed Tier 1 requirements with their associated use case tests.  Some requirements and use cases are flagged as: “Not included in POC” in this document to indicate that the feature was not included in the POC testing due to scope or schedule constraints.  Those use cases remain in this document to support future efforts.

D.1    Identify Appropriate Responding Agency or Service [CP-IDRES]

This activity involves identifying the appropriate agencies for incident response.  Based on the caller’s Automatic Location Identification (ALI) information, the Next Generation 9-1-1 (NG9-1-1) system will provide a list of responding agencies for that location.  The call taker may need to select an alternate location based on the information collected from the caller.  Responders for incident will be presented to the call taker based on the incident location and incident categorization.  A call taker will select the appropriate responders from the list presented and transmit the documented incident information to the dispatchers for the responding agencies selected.  Incident responders include, but are not limited to, Law Enforcement, Fire, and Emergency Medical Services (EMS) agencies.

D.1.1    The system shall display the emergency responder agencies associated with the emergency location

D.1.1.1    Test Description:

A call will be initiated to the test bed Public Safety Answering Point (PSAP).  This call will be monitored from the test bed PSAP location.

D.1.1.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. Tester enters emergency location.
3. System determines responder list based on emergency location.
4. System accesses responding agencies database.
5. System displays list of responders.

D.1.1.3    Expected Results:

The system will display a list of responder agencies to the test bed PSAP location.

D.1.1.4    Pass/Fail:

D.1.1.5    Results:

D.1.2    The system shall display the emergency responder agencies associated with the caller location if the emergency location is not available

D.1.2.1    Test Description:

A call that does not include emergency location information will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.

D.1.2.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System attempts to determine responder list based on emergency location.
3. System defaults to null for emergency location information.
4. System uses caller location information.
5. System accesses responding agencies database.
6. System displays list of responders.

D.1.2.3    Expected Results:

The system will display a list of responder agencies listed based on caller’s location information to the test bed PSAP location.

D.1.2.4    Pass/Fail:

D.1.2.5    Results:

D.1.3    The system shall display the emergency responder agencies associated with the nature of emergency (that is, recommended responders)

D.1.3.1    Test Description:

A call will be initiated to the test bed PSAP that includes call location and the nature of the emergency.  This call will be monitored from the test bed PSAP location.

D.1.3.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System determines responder list based on call location and nature of emergency.
3. System accesses responding agencies database.
4. System displays a list of responders.

D.1.3.3    Expected Results:

The system will display a list of recommended responders to the test bed PSAP location.

D.1.3.4    Pass/Fail:

D.1.3.5    Results:

D.1.4    The system shall display the emergency responder agencies associated with the Call Type if nature of emergency is not available 

(Use Case Not In POC Test)

D.1.4.1    Test Description:

A call will be initiated to the test bed PSAP that contains call type but not the nature of the emergency.  This call will be monitored from the test bed PSAP location.

D.1.4.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System reads emergency location information.
3. System accesses responding agencies database.
4. System accesses business rules database.
5. System displays responder list.

D.1.4.3    Expected Results:

The system will display responder list to the test bed PSAP.

D.1.4.4    Pass/Fail:

D.1.4.5    Results:

D.1.5    The system shall log the displayed responder agencies for each call 

(Use Case Not In POC Test)

D.1.5.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  The system will log responder agencies into the call detail record database.

D.1.5.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays responder list to test bed PSAP.
3. System logs displayed responder agencies into call detail record database.
4. Tester reviews call detail database record to verify log entry was created.

D.1.5.3    Expected Results:

A log entry for the displayed responder agencies will be created in the call detail record database.

D.1.5.4    Pass/Fail:

D.1.5.5    Results:

D.1.6    The system shall display call handling procedures based on business rules to the call taker

D.1.6.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.

D.1.6.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System accesses business rules server.
3. System extracts call handing rules from business rules server.
4. System displays call handling procedures to test bed PSAP.

D.1.6.3    Expected Results:

Call handing procedures extracted from the business rules server will be displayed to the test bed PSAP.

D.1.6.4    Pass/Fail:

D.1.6.5    Results:

D.1.7    The system shall display the mode of communication capabilities of the displayed responder agencies

 (Use Case Not In POC Test)

D.1.7.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  The tester will select emergency responders from the responder list.

D.1.7.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays responder list to test bed PSAP.
3. Tester selects emergency responder.
4. System accesses emergency provider access directory (EPAD) and local access database.
5. System displays mode of communication and access numbers required for agency selected.
6. Tester repeats test for a different emergency responder to verify correct data is displayed each time.

D.1.7.3    Expected Results:

Mode of communication and access numbers required for the agency selected will be displayed to test bed PSAP.

D.1.7.4    Pass/Fail:

D.1.7.5    Results:

D.1.8    The system shall provide the capability to refresh the list of responders

D.1.8.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  The tester will execute the Refresh option.

D.1.8.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays responder list to test bed PSAP.
3. Tester executes Refresh option.
4. System refreshes responder list from database.

D.1.8.3    Expected Results:

The responder list screen will be refreshed to the test bed PSAP.

D.1.8.4    Pass/Fail:

D.1.8.5    Results:

D.1.9    The system shall provide the capability to select responders from the list

D.1.9.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  The tester will select responders from the responder list.

D.1.9.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System accesses business rules database.
3. System accesses responding agencies database.
4. System displays responder agencies.
5. Tester selects responder agencies from displayed list.

D.1.9.3    Expected Results:

Responder agencies will be displayed, and tester in the test bed PSAP will select responder agencies. (for the POC this information will be stored local on the calltaker Workstation)

D.1.9.4    Pass/Fail:

D.1.9.5    Results:

D.1.10    The system shall provide the capability to select individual agents within a responding agency

 (Use Case Not In POC Test)

D.1.10.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  The tester will select specific emergency responders to be included in a conference call.

D.1.10.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System accesses business rules database.
3. System accesses responding agencies database.
4. System displays responder list to test bed PSAP.
5. Tester selects emergency responder.
6. System accesses the EPAD and local access database.
7. System displays mode of communication and access numbers required for agency selected.
8. System displays option to conference other individuals.
9. Tester selects participants for conference call.
10. System establishes conference call.

D.1.10.3    Expected Results:

Access options will be displayed at the PSAP test bed location, and a conference connection will be successfully executed.

D.1.10.4    Pass/Fail:

D.1.10.5    Results:

D.1.11    The system shall provide the capability to transmit a call record to the selected responder agencies' dispatchers

D.1.11.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  The tester will select specific emergency responder for conference call and call record will be transferred to that responder.

D.1.11.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays responder list to test bed PSAP.
3. Tester selects emergency responder.
4. System accesses EPAD and local access database.
5. System displays mode of communication and access numbers required for agency selected.
6. Tester selects responder agency dispatcher (test bed) for conference call.
7. System establishes conference call.
8. System accesses call record database.
9. System transfers call record to responding agency dispatcher (test bed).
10. Tester verifies that call record was transferred.

D.1.11.3    Expected Results:

The selected test bed responding agency dispatcher will receive the call record.

D.1.11.4    Pass/Fail:

D.1.11.5    Results:

D.1.12    The system shall provide the capability to search the responder list 

(Use Case Not In POC Test)

D.1.12.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  The tester will use search function to find alternate responder agencies.

D.1.12.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays responder list to test bed PSAP.
3. System accesses EPAD and local access database.
4. System displays list of recommended responders.
5. Tester selects Agency Info button to search for another agency.
6. System displays search function for EPAD and local access database.
7. Tester searches for alternate responder agencies.

D.1.12.3    Expected Results:

The search function will allow the tester access to the EPAD and display responder agency information.

D.1.12.4    Pass/Fail:

D.1.12.5    Results:

D.1.13    The system shall provide the capability to search the responder list using Boolean search terms 

(Use Case Not In POC Test)

D.1.13.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  Tester will search responder list using Boolean search terms.

D.1.13.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays responder list to test bed PSAP.
3. System accesses EPAD and local access database.
4. System displays list of recommended responders.
5. Tester selects Agency Info button to search for another agency.
6. System displays search function for EPAD and local access database.
7. Tester searches using Boolean search term “or” for the two terms “fire” and “animal.”
8. System performs a search using Boolean search term “and” for the two terms “fire” and “animal.”
9. Tester searches using Boolean search term “not” for the two terms “fire” and “animal.”
10. System displays results of each search.

D.1.13.3    Expected Results:

The search function will allow the tester to access to the EPAD and display responder agency information using Boolean terms.

D.1.13.4    Pass/Fail:

D.1.13.5    Results:

D.1.14    The system shall log the selected responder agencies for each call

D.1.14.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  The tester will select a responder agency from the responder list.

D.1.14.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays responder list to test bed PSAP.
3. Tester selects responder agency.
4. System logs selected responder agencies into call detail record database.
5. Tester reviews call detail record database to verify log entry was created.

D.1.14.3    Expected Results:

The call record database log will contain a record of the selected responder agency.

D.1.14.4    Pass/Fail:

D.1.14.5    Results:

D.1.15    The system shall contain a Responding Agency Repository

D.1.15.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  The tester will search for alternate responder agencies.

D.1.15.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays responder list to the test bed PSAP.
3. System accesses EPAD and local contact database.
4. System displays list of recommended responders and a search function.
5. Tester uses Search function to search EPAD and local contact database for alternate responder agencies.

D.1.15.3    Expected Results:

The search will verify EPAD is present and will act as the Responding Agency Repository.

D.1.15.4    Pass/Fail:

D.1.15.5    Results:

D.1.16    The Responding Agency Repository shall contain the following information for all responding agencies in the PSAP’s jurisdiction: a) name, b) business area, c) URL, d) telephone number, e) available communications media 

(Use Case Not In POC Test)

D.1.16.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  The tester will search for alternate responder agencies.

D.1.16.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays responder list to test bed PSAP.
3. System accesses EPAD and local contact database.
4. System displays list of recommended responders and a search function.
5. Tester uses Search function to search EPAD and local contact database for alternate responder agencies.

D.1.16.3    Expected Results:

The search will display the PSAP’s responding agencies within the jurisdiction to include: a) name, b) business area, c) URL, d) telephone number, e) available communications media.

D.1.16.4    Pass/Fail:

D.1.16.5    Results:

D.1.17    All emergency responder agencies shall be uniquely identifiable nationwide

D.1.17.1    Test Description:

The EPAD database will be accessed to review the data in the POC database.

D.1.17.2    Test Procedure:

1. Administrator accesses EPAD database.
2. Administrator examines EPAD database to check that agencies listed have unique identifiers.

D.1.17.3    Expected Results:

No emergency responder agencies in the EPAD will have the same identifier.

D.1.17.4    Pass/Fail:

D.1.17.5    Results:

D.1.18    The Responding Agency Repository shall have the capability to contain individual agents within a responding agency 

(Use Case Not In POC Test)

D.1.18.1    Test Description: A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  The tester will search for individual personnel within a responder agency. D.1.18.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays responder list to test bed PSAP.
3. System accesses EPAD and local contact database.
4. System displays list of recommended responders.
5. Tester drills down to individual personnel within the agency.

D.1.18.3    Expected Results:

The EPAD or the local contact database will contain the individual personnel within a responding agency.

D.1.18.4    Pass/Fail:

D.1.18.5    Results:

D.1.19    The Business Rules Database shall contain SOPs for the display of emergency responder agency information

D.1.19.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.  An administrator will verify the accuracy of the responder list based on the applicable business rule.

D.1.19.2    Test Procedure:

1. Administrator accesses business rules database.
2. Administrator reviews business rule for display of emergency responder agencies for test bed PSAP.
3. Call initiated to test bed PSAP.
4. System displays responder list that will be presented to test bed PSAP.
5. Administrator compares this list with business rule.

D.1.19.3    Expected Results:

The business rule for the display of emergency responder agency information will match what is delivered to the test bed PSAP Human Machine Interface (HMI) screen.

D.1.19.4    Pass/Fail:

D.1.19.5    Results:

D.1.20    The Business Rules Database shall contain rules for automatically determining whether call taker is needed for a given Call Type

 (Use Case Not In POC Test)

D.1.20.1    Test Description:

A call will be initiated to the system.  This call will be monitored from the test bed laboratory location.

D.1.20.2    Test Procedure:

1. A call will be initiated to system that requires no call taker intervention.
2. System determines responders list based on caller’s location and call type.
3. System accesses responding agencies business rules database.
4. System directs call to proper handling agency without call taker intervention.
5. Tester reviews call detail record.

D.1.20.3    Expected Results:

The call will be directed to the proper agency without calltaker intervention.

D.1.20.4    Pass/Fail:

D.1.20.5    Results:

D.2    Obtain Supportive or Supplemental Data Post Call Delivery [CR-OSSDT]

This activity supports the capability for a call taker to access Supportive  (e.g., Automatic Crash Notification [ACN]) or Supplemental data  (e.g., medical history, telematics, geospatial) after the call has been delivered to the PSAP.  Data queries can be performed both automatically by the system and by the call taker.  The data sources may be external to the 9-1-1 system; external to the PSAP, but still within the 9-1-1 system; or internal to the PSAP (e.g., computer-aided dispatch [CAD] ).  The functional capability is the same regardless of the location of the data source.  Such information may be automatically accessible to the call taker based on identifiers within the Supportive Call Data, or identifiers within the Essential Call Data.  This information may also be acquired through the use of searches based on information collected from the caller.  The call taker can search Supportive or Supplemental databases.  Data may be displayed on a map as a three-dimensional rendering or as photographic imagery.  The query parameters and the results of all queries are stored in the Call Detail Record Database.  

D.2.1    The system shall provide the capability for a call taker to access Supplemental Data

D.2.1.1    Test Description:

A query for supplemental data will be initiated by the tester through his/her console, using a website address, a previously provided universal resource identifier (URI), or other access code.  This process will be monitored from the test bed PSAP location.

D.2.1.2    Test Procedure:

1. Tester queries for supplemental data using a website address, a previously provided URI, or other access code.
2. System transmits query from PSAP equipment to ESInet.
3. ESInet transmits query to an appropriate portal for the data requested, within or outside the ESInet.
4. Results of query returned through ESInet to originating tester’s position and displayed.

D.2.1.3    Expected Results:

The tester will be able to initiate a query, and the results or an error indication will be displayed.

D.2.1.4    Pass/Fail:

D.2.1.5    Results:

D.2.2    The system shall provide the capability for a call taker to access Supportive Data

D.2.2.1    Test Description:

A query for supportive data will be initiated by the tester through his/her console, using a website address, a previously provided URI, or other access code associated with system databases or other resources. This process will be monitored from the test bed PSAP location.

D.2.2.2    Test Procedure:

1. System queries for supportive data using website address, a previously provided URI, or other access code.
2. System transmits query from PSAP equipment to ESInet.
3. ESInet transmits query to an appropriate portal for data requested, within system databases or other resources.
4. Results of the query returned through ESInet to originating tester’s position and displayed.

D.2.2.3    Expected Results:

The tester will be able to initiate a query, and the results or an error indication will be displayed.

D.2.2.4    Pass/Fail:

D.2.2.5    Results:

D.2.3    The system shall provide the capability to search Supportive Data

 (Use Case Not In POC Test)

D.2.3.1    Test Description:

NOTE: Supportive data is only accessible within the system after a call or message that queries for Supportive data has occurred, this test relates to stored data.   A tester or administrator will search for supportive data from a previous call, based on various parameters, such as date and time, telephone number, or other pertinent items. This process will be monitored from the test bed laboratory and PSAP location.

D.2.3.2    Test Procedure

1. Tester launches a search for the related data using a previous call initiated to the test bed PSAP that generated supportive data.
2. Laboratory tester monitors system for search language processing.
3. Laboratory tester monitors target data for access by search routine.
4. PSAP tester determines that Supportive data was returned.

D.2.3.3    Expected Results:

The target data set will be found using the search process and displayed.

D.2.3.4    Pass/Fail:

D.2.3.5    Results:

D.2.4    The system shall provide the capability to search Supplemental Data 

(Use Case Not In POC Test)

D.2.4.1    Test Description:

A call will be initiated to the test bed PSAP that generates supplemental data.  The tester will execute a supplemental data query.  After the call is completed, a tester or administrator will search for supplemental data from the previous call, based on various parameters, such as date and time, telephone number, or other pertinent items. This process will be monitored from the test bed laboratory and PSAP location.

D.2.4.2    Test Procedure

1. Cellular call initiated to test bed PSAP that generates supplemental data.
2. PSAP tester initiates a supplemental data query during the call.
3. After call completion, PSAP tester launches a search for related data.
4. Laboratory tester monitors system for search language processing.
5. Laboratory tester monitors target data for access by search routine.
6. PSAP tester determines that supplemental data was returned.
7. Re-run for a telematics call.

D.2.4.3    Expected Results:

The target data set will be found using the search process and displayed.

D.2.4.4    Pass/Fail:

D.2.4.5    Results:

D.2.5    The system shall display Supportive Data search results to the call taker, based on business rules (Use Case Not In POC Test)

D.2.5.1    Test Description:

Multiple calls will be initiated to the test bed PSAP.  This test will verify that the system business rules can control when Supportive data query results are or are not displayed to the tester.  These calls will be monitored from the test bed PSAP location.

D.2.5.2    Test Procedure:

1. POC system administrator establishes appropriate supportive data display business rule in the system.
2. Calls initiated to test bed PSAP that contain Supportive data.  Some calls contain data that intersects with business rule logic. Other calls contain data that does not intersect with business rules logic.
3. Tester monitors displayed results.

D.2.5.3    Expected Results:

Based on the business rules, those Supportive data cases that should be displayed to the tester will be, and those that should not, will not be.

D.2.5.4    Pass/Fail:

D.2.5.5    Results:

D.2.6    The system shall support queries of supportive data from internal systems, including: call stream data, call detail record data, and GIS

D.2.6.1    Test Description:

Queries will be initiated by the tester for supportive data, and the system will transport and submit those queries to all appropriate storage locations that can contain supportive data.  This process will be monitored from the test bed PSAP location.

D.2.6.2    Test Procedure:

1. Tester initiates queries for all supportive data storage points active in POC system.
2. System transmits the test queries.
3. Target storage point monitored by system administrator for arrival and processing of the query.
4. Tester verifies that data requested or an error message is returned for display.

D.2.6.3    Expected Results:

Each query will be transmitted to the appropriate target storage point and return the appropriate data or error message to the query initiation point.

D.2.6.4    Pass/Fail:

D.2.6.5    Results:

D.2.7    The system shall support queries of supportive data from external systems, including: medical records data and other data sources

D.2.7.1    Test Description:

Calls will be initiated to the test bed PSAP.  Under business rules control, the system will monitor incoming data associated with calls or messages from various originating devices, check against the business rules, and where matches occur, take the defined business rule action to launch defined queries through the ESInet to external systems and databases.  These calls will be monitored from the test bed PSAP location.

D.2.7.2    Test Procedure:

1. Calls will be initiated to test bed PSAP with data payloads designed to trigger business rule based reactions and related queries to selected external systems and databases within design scope of POC system.
2. Tester monitors system for appropriate data responses from external systems and databases.

D.2.7.3    Expected Results:

Each test call will cause the expected reaction, logical query generation, and reaction from the involved external system or database.

D.2.7.4    Pass/Fail:

D.2.7.5    Results:

D.2.8    The system shall support drill-down queries of supportive data to obtain additional detail 

(Use Case Not In POC Test)

D.2.8.1    Test Description:

Based on supportive data brought into the system with calls, and displayed under business rule control to the tester, the tester will initiate a query for additional supportive data or detail through his/her console, using a previously provided URI or other access code associated with system databases or other resources.  This process will be monitored from the test bed PSAP location.

D.2.8.2    Test Procedure:

1. Tester initiates a query for additional supportive data or detail.
2. System transmits query from PSAP equipment into ESInet.
3. ESInet transmits query to an appropriate portal for data requested, within system databases or other resources, or to external systems and databases.
4. Results of query returned through ESInet to originating tester’s position and displayed.

D.2.8.3    Expected Results:

The tester will be able to initiate a query for expanded data and receive the results or an error indication for display.

D.2.8.4    Pass/Fail:

D.2.8.5    Results:

D.2.9    The system shall display Supplemental Data search results to the call taker, based on business rules

 (Use Case Not In POC Test)

D.2.9.1    Test Description:

The tester will verify that the system business rules can control when a supplemental data query result is or is not displayed to the tester. This process will be monitored from the test bed PSAP location.

D.2.9.2    Test Procedure:

1. Appropriate data display business rule established in system by system administrator.
2. Tester launches supplemental data queries that do and do not intersect with business rule logic.
3. Tester monitors display of correct results.

D.2.9.3    Expected Results:

Those Supplemental data sets that should be displayed to the tester will be displayed, and those that should not, will not be displayed.

D.2.9.4    Pass/Fail:

D.2.9.5    Results:

D.2.10    The system shall support queries of supplemental data from internal systems, including call stream data, call detail record data, and GIS

D.2.10.1    Test Description:

Testers or administrative personnel will make queries for data stored in the system databases. The system software will direct these queries to the appropriate point and return the requested data to the query point. This process will be monitored from the test bed laboratory or PSAP location.

D.2.10.2    Test Procedure:

1. Tester generates queries for specific data for this requirement based on the available data (as included during development) from specific databases.
2. System transmits query into ESInet.
3. ESInet transmits query to an appropriate portal for the data requested, within system databases or other resources.
4. Results of query returned through ESInet to the originating tester and displayed.

D.2.10.3    Expected Results:

Appropriate reactions and data results will occur for each query.  Improper queries will result in appropriate error indications.

D.2.10.4    Pass/Fail:

D.2.10.5    Results:

D.2.11    The system shall support queries of supplemental data from external systems, including medical records data and other data sources

D.2.11.1    Test Description:

Testers or administrative personnel will make queries for data stored in external databases. The system software will direct these queries to the appropriate point and return the requested data to the query point. This process will be monitored from the test bed laboratory or PSAP location.

D.2.11.2    Test Procedure:

1. Tester generates queries for specific data for this requirement based on the available data (as included during development)from specific external databases.
2. Query transmitted into ESInet.
3. ESInet transmits query to an appropriate portal for data requested.
4. Results of query returned through ESInet to originating tester and displayed.

D.2.11.3    Expected Results:

Appropriate reactions and data results will occur for each query.  Improper queries will result in appropriate error indications.

D.2.11.4    Pass/Fail:

D.2.11.5    Results:

D.2.12    The system shall support drill-down queries of supplemental data to obtain additional detail for matched records

D.2.12.1    Test Description:

Testers or administrative personnel will make queries for detailed data stored in external databases. The system software will direct these queries to the appropriate point and return the requested data to the query point. This process will be monitored from the test bed laboratory or PSAP location.

D.2.12.2    Test Procedure:

1. Tester generates queries for specific data for this requirement based on the available data (as included during development)from specific external databases.
2. System transmits query into ESInet.
3. ESInet transmits query to an appropriate portal for data requested.
4. Results of query returned through ESInet to originating tester and displayed, and/or detailed data stored in correspondence with the original data.

D.2.12.3    Expected Results:

Appropriate reactions and data results will occur for each test.  Improper queries will result in appropriate error indications.

D.2.12.4    Pass/Fail:

D.2.12.5    Results:

D.2.13    The system shall determine which queries are authorized for access based on established business rules 

(Use Case Not In POC Test)

D.2.13.1    Test Description:

Tester queries the system and the business rules database is consulted to determine whether the query is allowed

D.2.13.2    Test Procedure:

1. Tester launches queries that match and that do not match business rules.
2. System handling and reactions monitored by system administrator.

D.2.13.3    Expected Results:

Appropriate reactions and data results will occur for each test.  Improper queries result in appropriate error indications.

D.2.13.4    Pass/Fail:

D.2.13.5    Results:

D.2.14    The system shall record the query parameters for all queries performed in the call detail record database

 (Use Case Not In POC Test)

D.2.14.1    Test Description:

Tester will initiate a set of queries and verify that all call time queries generated by the system for Supportive data, for Supplemental data, or for stored Supportive and Supplemental data by testers or administrative personnel are logged in the call detail record database.  This process will be monitored at the test bed PSAP.

D.2.14.2    Test Procedure:

1. Tester initiates a set of queries for Supplemental data, stored Supportive data, and Supplemental data.
2. Tester verifies that appropriate logging data for each query is stored in call detail record database.

D.2.14.3    Expected Results:

All queries will be documented in the call detail record database.

D.2.14.4    Pass/Fail:

D.2.14.5    Results:

D.2.15    The system shall record the query results for all queries performed in the call detail record database

D.2.15.1    Test Description:

Tester will initiate a set of queries and verify that all call time queries generated by the system for Supportive data, results for Supplemental data queries or for stored Supportive and Supplemental data queries by testers or administrative personnel are logged in the call detail record database.  This process will be monitored in the test bed PSAP.

D.2.15.2    Test Procedure:

1. Tester initiates a set of queries for Supportive data, results for Supplemental data, stored Supportive and Supplemental data.
2. Tester verifies that appropriate query results data for each query is stored in call detail record database.

D.2.15.3    Expected Results:

All query data response results will be documented in the call detail record database.

D.2.15.4    Pass/Fail:

D.2.15.5    Results:

D.2.16    The system shall determine which queries are automatically executed based on established business rules

D.2.16.1    Test Description:

Both Supportive data queries within the system and Supplemental data queries after call delivery can be automatically triggered by business rule controls.  Such queries will be triggered based on appropriate business rule database content.  Several calls will be generated based on this data and monitored in the test bed laboratory.

D.2.16.2    Test Procedure:

1. Business rule content designed to trigger data queries by system administrator.
2. Calls and data flow generated with content that matches test business rule content.
3. Calls and data flow generated with content that does not match test business rule content.
4. Tester monitors system reactions for each test to determine whether proper queries are launched.

D.2.16.3    Expected Results:

Those queries expected to occur based on business rule content will execute.  Those that do not match will cause an error message in the log.

D.2.16.4    Pass/Fail:

D.2.16.5    Results:

D.3    Recognize Originating Location [CT-ROLOC]

This activity supports a system function to accept, acknowledge, and, potentially validate the location of the caller (which may or may not be the location of the emergency event).  Validation may occur prior to this step (perhaps, preferably) as a function of the access network or the telecommunications device, internal data stores.

D.3.1    The system shall validate Caller Location Information 

(Use Case Not In POC Test)

D.3.1.1    Test Description:

Three calls will be initiated to the test bed PSAP.  These calls will be a cellular call, a Voice over Internet Protocol (VoIP) call, and a legacy analog call.  These calls will be monitored from the test bed PSAP location.

D.3.1.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. ystem checks location against geographic information system (GIS) database to ensure it is logical and in range to validate.
5. System updates call detail record database.
6. System routes call to PSAP.
7. Procedure repeated for all three types of calls.

D.3.1.3    Expected Results:

For each call, the call detail record database will be updated, and the call will be routed to the test bed PSAP.

D.3.1.4    Pass/Fail:

D.3.1.5    Results:

D.3.2    The system shall check Caller Location for unrecognizable data type

 (Use Case Not In POC Test)

D.3.2.1    Test Description:

A call will be initiated to the test bed PSAP with an unrecognizable data type.  This call will be monitored from the test bed PSAP location.

D.3.2.2    Test Procedure:

1. Call with an unrecognizable data type initiated to test bed PSAP.
2. ystem reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System fails error check because of unrecognizable data type.
5. System checks whether fall-back location exists and assign it if present.
6. System assigns default location if fall-back location does not exist.
7. System updates call detail record database.
8. System routes call to test bed PSAP with default location.

D.3.2.3    Expected Results:

The call detail record database will be updated with an unrecognizable data error, and the call will be routed to the test bed PSAP with the fall-back location or default location listed, if no fall-back location was available.

D.3.2.4    Pass/Fail:

D.3.2.5    Results:

D.3.3    The system shall check Caller Location for garbled data

 (Use Case Not In POC Test)

D.3.3.1    Test Description:

A call will be initiated to the test bed PSAP with garbled data.  This call will be monitored from the test bed PSAP location.

D.3.3.2    Test Procedure:

1. Call with garbled data initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System fails error check because of garbled data.
5. System checks whether fall-back location exists and assign it if present.
6. System assigns default location if fall-back location does not exist.
7. System updates call detail record database.
8. System routes call to PSAP with default location listed.

D.3.3.3    Expected Results:

The call detail record database will be updated with a garbled data error, and the call will be routed to the test bed PSAP with the fall-back location or the default location listed, if no fall-back location was available.

D.3.3.4    Pass/Fail:

D.3.3.5    Results:

D.3.4    The system shall check Caller Location fields for logical data ranges 

(Use Case Not In POC Test)

D.3.4.1    Test Description:

A call will be initiated to the test bed PSAP with an invalid data range.  This call will be monitored from the test bed PSAP location.

D.3.4.2    Test Procedure:

1. Call with an invalid data range initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using GIS database.
5. System creates an error because of location invalid range.
6. System checks whether fall-back location exists and assigns it if present.
7. System assigns default location if fall-back location does not exist.
8. System updates call detail record database.
9. ystem routes call to test bed PSAP with default location listed.

D.3.4.3    Expected Results:

The call detail record database will be updated with an invalid data range data error, and the call will be routed to the test bed PSAP with the fall-back location or default location listed, if no fall-back location was available.

D.3.4.4    Pass/Fail:

D.3.4.5    Results:

D.3.5    The system shall check Caller Location fields for logical content 

(Use Case Not In POC Test)

D.3.5.1    Test Description:

A call will be initiated to the test bed PSAP with an invalid caller location field.  This call will be monitored from the test bed PSAP location.

D.3.5.2    Test Procedure:

1. Call with an invalid caller location field initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using the GIS database.
5. System creates an error because of an invalid location field.
6. System checks whether fall-back location exists and assign it if present.
7. System assigns default location if fall-back location does not exist.
8. System updates call detail record database.
9. System routes call to test bed PSAP with default location listed.

D.3.5.3    Expected Results:

The call detail record database will be updated with an invalid location error, and the call will be routed to the test bed PSAP with the fall-back location or the default location listed, if no fall-back location was available.

D.3.5.4    Pass/Fail:

D.3.5.5    Results:

D.3.6    The system shall recognize Caller Location Information formatted to NENA Standard Formats & Protocols for ALI Data Exchange, ALI Response & GIS Mapping (NENA-02-010)

D.3.6.1    Test Description:

A call will be initiated to the test bed PSAP with correct Caller Location Information formatted to National Emergency Number Association (NENA) Standard Formats and Protocols for ALI Data Exchange, ALI Response, and GIS Mapping (NENA-02-010) information.  This call will be monitored from the test bed PSAP location.

D.3.6.2    Test Procedure:

1. Call initiated to test bed PSAP with correct Caller Location Information formatted to NENA Standard Formats and Protocols for ALI Data Exchange, ALI Response, and GIS Mapping (NENA-02-010) information.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using GIS database.
5. System updates call detail record database.
6. System routes call to test bed PSAP with correct location listed.

D.3.6.3    Expected Results:

The call detail record database will be updated with correct Caller Location Information formatted to NENA Standard Formats and Protocols for ALI Data Exchange, ALI Response, and GIS Mapping (NENA-02-010) information.  The call will be routed to the test bed PSAP with the correct location listed.

D.3.6.4    Pass/Fail:

D.3.6.5    Results:

D.3.7    Caller Location shall contain a) House Number, b) House Number Suffix, c) Prefix Directional, d) Street Name, e) Street Suffix, f) Post Directional, g) MSAG Community Name, h) Postal Community Name, i) State/Province, j) Additional Free Formatted Location

D.3.7.1    Test Description:

A call will be initiated to the test bed PSAP with correct Caller Location Information formatted to NENA Standard Formats and Protocols for ALI Data Exchange, ALI Response, and GIS Mapping (NENA-02-010) information.  This call will be monitored from the test bed PSAP location.

D.3.7.2    Test Procedure:

1. Call initiated to test bed PSAP with correct Caller Location Information formatted to NENA Standard Formats and Protocols for ALI Data Exchange, ALI Response, and GIS Mapping (NENA-02-010) information.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using GIS database.
5. System updates call detail record database.
6. System routes call to test bed PSAP with correct location listed.

D.3.7.3    Expected Results:

The call detail record database will be updated with correct Caller Location Information.  The call will be routed to the test bed PSAP with correct a) House Number, b) House Number Suffix, c) Prefix Directional, d) Street Name, e) Street Suffix, f) Post Directional, g) Master Street Address Guide (MSAG) Community Name, h) Postal Community Name, i) State/Province, j) Additional Free Formatted Location listed. In the POC only the following is supported based on the GEOPRIV Working Group Format: a) House Number, d) Street Name, e) Street Suffix, h) Postal Community Name, i) State/Province.

D.3.7.4    Pass/Fail:

D.3.7.5    Results:

D.3.8    The system shall provide alternate location information in the absence of primary location information 

(Use Case Not In POC Test)

D.3.8.1    Test Description:

A call will be initiated to the test bed PSAP with no caller location field.  A fall-back location is available. This call will be monitored from the test bed PSAP location.

D.3.8.2    Test Procedure:

1. Call with no caller location field initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using GIS database.
5. System creates an error because of no caller location.
6. System checks whether fall-back location exists.
7. System assigns fall-back location.
8. System updates call detail record database.
9. System routes call to test bed PSAP.

D.3.8.3    Expected Results:

The call detail record database will be updated with an invalid location error, and the call will be routed to the test bed PSAP with the fall-back location listed.

D.3.8.4    Pass/Fail:

D.3.8.5    Results:

D.3.9    The system shall assign a default location upon Caller location and Fall-Back Location failure 

(Use Case Not In POC Test)

D.3.9.1    Test Description:

A call will be initiated to the test bed PSAP with no caller location field.  No fall-back location is available.  This call will be monitored from the test bed PSAP location.

D.3.9.2    Test Procedure:

1. Call with no caller location field initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using GIS database.
5. System creates an error because there is no caller location field.
6. System checks whether a fall-back location exists.
7. System assigns default location because no fall-back location exists.
8. System updates call detail record database.
9. System routes call to test bed PSAP.

D.3.9.3    Expected Results:

The call detail record database will be updated with an invalid location error, and the call will be routed to the test bed PSAP with the default location listed.

D.3.9.4    Pass/Fail:

D.3.9.5    Results:

D.3.10    The system shall update the Call Stream with the assigned Default Location 

(Use Case Not In POC Test)

D.3.10.1    Test Description:

A call will be initiated to the test bed PSAP with no caller location field.  No fall-back location is available. This call will be monitored from the test bed PSAP location.

D.3.10.2    Test Procedure:

1. Call with no caller location field initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using GIS database.
5. System creates an error because there is no caller location field.
6. System checks whether a fall-back location exists.
7. System assigns default location because no fall-back location exists.
8. System updates call detail record database.
9. System routes call to test bed PSAP.

D.3.10.3    Expected Results:

The call detail record database will be updated with an invalid location error, and the call will be routed to the test bed PSAP with the default location listed.

D.3.10.4    Pass/Fail:

D.3.10.5    Results:

D.3.11    The system shall store the Caller Location as part of the Call Detail Record

D.3.11.1    Test Description:

A call will be initiated to the test bed PSAP with correct caller location information.  This call will be monitored from the test bed PSAP location.

D.3.11.2    Test Procedure:

1. Call initiated to test bed PSAP with correct caller location information.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using GIS database.
5. System updates call detail record database.
6. System routes call to test bed PSAP with correct location listed.

D.3.11.3    Expected Results:

The call detail record database will be updated with correct caller location information.  The test bed PSAP will display correct caller location information.

D.3.11.4    Pass/Fail:

D.3.11.5    Results:

D.3.12    The system shall make use of Fall-Back Location Information in the event of a failed location determination attempt

  (Use Case Not In POC Test)

D.3.12.1    Test Description:

A call will be initiated to the test bed PSAP with no caller location field.  A fall-back location is available. This call will be monitored from the test bed PSAP location.

D.3.12.2    Test Procedure:

1. Call with no caller location field initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using GIS database.
5. System creates an error because there is no caller location field.
6. System checks whether a fall-back location exists.
7. System assigns the fall-back location.
8. System updates call detail record database.
9. System routes call to test bed PSAP.

D.3.12.3    Expected Results:

The call detail record database will be updated with an invalid location error and fall-back location.  Call will be routed to the test bed PSAP with the fall-back location listed.

D.3.12.4    Pass/Fail:

D.3.12.5    Results:

D.3.13    The system shall check Fall-Back Location for unrecognizable data type 

 (Use Case Not In POC Test)

D.3.13.1    Test Description:

A call will be initiated to the test bed PSAP with an unrecognizable data type for both location information and the fall-back location.  This call will be monitored from the test bed PSAP location.

D.3.13.2    Test Procedure:

1. Call with an unrecognizable data type for both location and fall-back location initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System fails error check because unrecognizable data type in location.
5. System checks whether a fall-back location exists.
6. System error checks format to make sure it is not garbled or unintelligible.
7. System fails error checks because unrecognizable data type in fall-back location.
8. System assigns default location.
9. System updates call detail record database.
10. System routes call to test bed PSAP with default location listed.

D.3.13.3    Expected Results:

The call detail record database will be updated with unrecognizable data type errors for both the location information and the fall-back location.  The call will be routed to the test bed PSAP with the default location listed.

D.3.13.4    Pass/Fail:

D.3.13.5    Results:

D.3.14    The system shall check Fall-Back Location for garbled data

 (Use Case Not In POC Test)

D.3.14.1    Test Description:

A call will be initiated to the test bed PSAP with garbled data for both location information and the fall-back location.  This call will be monitored from the test bed PSAP location.  

D.3.14.2    Test Procedure:

1. Call with garbled data for both location and fall-back location initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System fails error check because of garbled data in location.
5. System checks whether a fall-back location exists.
6. System error checks format to make sure it is not garbled or unintelligible.
7. System fails error check because of garbled data in fall-back location.
8. System assigns default location.
9. System updates call detail record database.
10. System routes call to PSAP with default location listed.

D.3.14.3    Expected Results:

The call detail record database will be updated with a garbled data error for both the location information and the fall-back location.  The call will be routed to the test bed PSAP with the default location listed.

D.3.14.4    Pass/Fail:

D.3.14.5    Results:

D.3.15    The system shall check Fall Back Location fields for logical data ranges

 (Use Case Not In POC Test)

D.3.15.1    Test Description:

A call will be initiated to the test bed PSAP with both caller location information and fall-back location out of logical range.  This call will be monitored from the test bed PSAP location.

D.3.15.2    Test Procedure:

1. Call with both caller location information and fall-back location out of logical range initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using the GIS database.
5. System creates an error because caller location information is out of logical range.
6. System checks whether fall-back location exists within logical range.
7. System creates an error because fall-back location information is out of logical range.
8. System assigns default location.
9. System updates call detail record database.
10. System routes call to test bed PSAP.

D.3.15.3    Expected Results:\

The call detail record database will be updated with an out of logical range error for both the caller location and the fall-back location and the fact that a default location was used.  The call will be routed to test bed PSAP with the default location listed.

D.3.15.4    Pass/Fail:

D.3.15.5    Results:

D.3.16    The system shall check Fall Back Location fields for logical content 

(Use Case Not In POC Test)

D.3.16.1    Test Description:

A call will be initiated to the test bed PSAP with invalid caller location information content and invalid fall-back location content.  This call will be monitored from the test bed PSAP location.

D.3.16.2    Test Procedure:

1. Call with invalid Caller location Information content and invalid fall-back location content initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using the GIS database.
5. System creates an error record because Caller Location information content is invalid.
6. System checks whether fall-back location exists.
7. System error checks format to make sure it is not garbled or unintelligible.
8. System fails error check because of invalid content in fall-back location.
9. System assigns default location.
10. System updates call detail record database.
11. System routes call to test bed PSAP.

D.3.16.3    Expected Results:

The call detail record database will be updated with results of fall-back location database comparison with location information.  Call detail database will be updated indicating that the fall-back location was not used.  The call will be routed to test bed PSAP with either fall-back or default location listed.

D.3.16.4    Pass/Fail:

D.3.16.5    Results:

D.3.17    The system shall supply the user with an error diagnosis in the event of a failed location determination attempt 

(Use Case Not In POC Test)

D.3.17.1    Test Description:

A call with invalid caller location information content will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.

D.3.17.2    Test Procedure:

1. Call with invalid caller location information content initiated to test bed PSAP.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using the GIS database.
5. System creates an error record because Caller Location information content is invalid.
6. System checks if fall-back location exists.
7. System validates Caller location information content against fall-back location database.
8. System assigns default location if fall-back location does not exist.
9. System displays error to tester.

D.3.17.3    Expected Results:

The call detail record database will be updated with results of fall-back location database comparison with location information.  Call detail database will be updated indicating whether the fall back location existed or the default location was used.  Call will be routed to the test bed PSAP with either fall-back or default location listed.  An error will be displayed to tester.

D.3.17.4    Pass/Fail:

D.3.17.5    Results:

D.3.18    The system shall support representations of location that include the capability to identify altitude 

(Use Case Not In POC Test)

D.3.18.1    Test Description:

A call will be initiated to the test bed PSAP with correct caller location information formatted to NENA Standard Formats and Protocols for ALI Data Exchange, ALI Response, and GIS Mapping (NENA-02-010) information, including altitude.  This call will be monitored from the test bed PSAP location.

D.3.18.2    Test Procedure:

1. Call initiated to test bed PSAP with correct caller location information formatted to NENA Standard Formats and Protocols for ALI Data Exchange, ALI Response, and GIS Mapping (NENA-02-010) information, including altitude.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using GIS database.
5. System updates call detail record database.
6. System routes call to test bed PSAP with correct location listed.

D.3.18.3    Expected Results:

The call detail record database will be updated with correct caller location information.  The call will be routed to the test bed PSAP with correct a) House Number, b) House Number Suffix, c) Prefix Directional, d) Street Name, e) Street Suffix, f) Post Directional, g) MSAG Community Name, h) Postal Community Name, i) State/Province, j) Additional Free Formatted Location listed, and altitude. The call will be routed to the test bed PSAP with the same information.

D.3.18.4    Pass/Fail:

D.3.18.5    Results:

D.3.19    The system shall support the use of Fall-Back Location Information when measurement-based location determination is not available

 (Use Case Not In POC Test)

D.3.19.1    Test Description:

A call with caller location information content but no measurement-based location determination will be initiated to the test bed PSAP.  This call will be monitored from the test bed PSAP location.

D.3.19.2    Test Procedure:

1. Call with caller location information content but no measurement-based location determination initiated to test bed PSAP.
2. System attempts to read location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using the GIS database.
5. System creates an error record because no measurement-based location determination information exists.
6. System checks whether fall-back location exists and assigns it if present.
7. System assigns default location if fall-back location does not exist.
8.  System updates call detail record database.
9. System routes call to test bed PSAP.

D.3.19.3    Expected Results:

The call detail record database will be updated with no measurement-based location determination information available error and whether the fall-back location existed or the default location was used.  The call will be routed to test bed PSAP with either the fall-back or default location listed.

D.3.19.4    Pass/Fail:

D.3.19.5    Results:

D.3.20    The system shall support representations of location that include the capability to identify structural floor designation

D.3.20.1    Test Description:

A call will be initiated to the test bed PSAP with correct caller location information formatted to NENA Standard Formats and Protocols for ALI Data Exchange, ALI Response, and GIS Mapping (NENA-02-010) information.  This call will also include structural floor designation. This call will be monitored from the test bed PSAP location.

D.3.20.2    Test Procedure:

1. Call initiated to test bed PSAP with correct caller location information formatted to NENA Standard Formats and Protocols for ALI Data Exchange, ALI Response, and GIS Mapping (NENA-02-010) information, including structural floor designation.
2. System reads location information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System error checks location using GIS database.
5. System updates call detail record database.
6. System routes call to test bed PSAP with correct structural floor information listed.

D.3.20.3    Expected Results:

The call detail record database will be updated with correct caller location information and include structural floor designation. Call will be routed to the test bed PSAP with correct a) House Number, b) House Number Suffix, c) Prefix Directional, d) Street Name, e) Street Suffix, f) Post Directional, g) MSAG Community Name, h) Postal Community Name, i) State/Province, j) Additional Free Formatted Location listed, and structural floor designation.

D.3.20.4    Pass/Fail:

D.3.20.5    Results:

D.4    Recognize Call Type [CT-REGCT]

This activity addresses system and network capability to automatically identify types or classifications of calls (like telematics, ACN, silent alarms, and similar automated calls).  Call type will then contribute to or help guide call treatment, routing, and processing, depending on the characteristics of the call type involved.  The intent is to facilitate that process, maximize performance, and minimize response time.

D.4.1    The system shall use call type data as defined in NENA Standard Formats & Protocols for ALI Data Exchange, ALI Response & GIS Mapping (NENA-02-010) to perform call treatment

D.4.1.1    Test Description:

A call will be initiated to the test bed PSAP using the call type data defined in NENA 02-010 and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH). This call will be monitored from the test bed PSAP location.

D.4.1.2    Test Procedure:

1. Call initiated to test bed PSAP and passes steps defined in Recognize Originating Location procedures (CT-CAUTH).
2. System reads data to determine call type.
3. System determines whether ANI data or limited pointer data is included in call stream.
4. If ANI data or limited pointer data is included in call stream, system accesses ALI database and adds ALI data to call stream.
5. System determines call type and priority for call routing by accessing business rules database and updates call detail database indicating call was in NENA Standard Formats and Protocols for ALI Data Exchange, ALI Response, and GIS Mapping (NENA-02-010).
6. System error checks call to ensure it is not garbled or unrecognizable.
7. System compares call type against the business rules database to ensure match against defined call types.
8. System assigns a default call type if call type does not match business rules database.
9. System updates call type data, adds call type to call stream, and updates Call Detail Record database.
10. System routes call to test bed PSAP.

D.4.1.3    Expected Results:

The call detail records database will indicate the call was in NENA Standard Formats and Protocols for ALI Data Exchange, ALI Response, and GIS Mapping (NENA-02-010).

D.4.1.4    Pass/Fail:

D.4.1.5    Results:

D.4.2    The system shall use the following data to determine Call Type: A) Emergency Location, B) Class of Service, C) Type of Service

D.4.2.1    Test Description:

A call will be initiated to the test bed PSAP and use the call data to determine the call type. This call will be monitored from the test bed PSAP location.

D.4.2.2    Test Procedure:

1. Call initiated to test bed PSAP and passes the steps defined in Recognize Originating Location procedures (CT-CAUTH).
2. System reads data to determine call type.
3. System determines whether ANI data or limited pointer data is included in call stream.
4. If ANI data or limited pointer data is included in call stream, system accesses ALI database and adds ALI data to the call stream.
5. System determines call type a) Emergency Location, b) Class of service, and c) Type of service; and priority for call routing by accessing business rules database and updates call detail database.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. System compares call type against business rules database to ensure match against defined call types.
8. System assigns a default call type if call type does not match business rules database.
9. System updates call type data, adds call type to call stream, and updates call detail record database.
10. System routes call to test bed PSAP.

D.4.2.3    Expected Results:

The call detail records database will indicate an update to call detail with a) Emergency Location, b) Class of service, and c) Type of service.   

D.4.2.4    Pass/Fail:

D.4.2.5    Results:

D.4.3    The system shall validate incoming Call Type 

(Use Case Not In POC Test)

D.4.3.1    Test Description:

A call will be initiated to the test bed PSAP and verify the call type. This call will be monitored from the test bed PSAP location.

D.4.3.2    Test Procedure:

1. Call initiated to test bed PSAP and passes the steps defined in Recognize Originating Location procedures (CT-CAUTH).
2. System reads data to determine call type.
3. System determines whether ANI data or limited pointer data is included in call stream.
4. If ANI data or limited pointer data is included in call stream, system accesses ALI database and adds ALI data to the call stream.
5. System determines call type and priority for call routing by accessing business rules database and updates call detail database.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. System compares (Validate) call type against business rules database to ensure match against defined call types.
8. System assigns a default call type if call type does not match business rules database.
9. System updates call type data, adds call type to call stream, and updates call detail record database.
10. System routes call to test bed PSAP.

D.4.3.3    Expected Results:

The call detail records database will indicate an update to call detail that the call type was validated against the business rules database.  

D.4.3.4    Pass/Fail:

D.4.3.5    Results:

D.4.4    The system shall ensure that the incoming call includes the fields delineated in NENA 02-010 

(Use Case Not In POC Test)

D.4.4.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps determining for all fields delineated in NENA 02-010 are included.  This call will be monitored from the test bed PSAP location.

D.4.4.2    Test Procedure:

1. Call initiated to test bed PSAP and passes steps defined in the Recognize Originating Location procedures (CT-CAUTH).
2. System reads data to determine call type.
3. System determines whether ANI Data or limited pointer data is included in call stream.
4. If ANI data or limited pointer data is included in call stream, system accesses ALI database and adds ALI data to the call stream.
5. System determines call type.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. System compares call type against business rules database to ensure match against defined call types as delineated in NENA 02-010.
8. System assigns a default call type if call type does not match business rules database.
9. System updates call type data, adds call type to call stream, and updates Call Detail Record database.
10. System routes call to test bed PSAP.

D.4.4.3    Expected Results:

The call detail records database will indicate an update to call detail that the call type was NENA 02-010 format and validated against the business rules database.

D.4.4.4    Pass/Fail:

D.4.4.5    Results:

D.4.5    The system shall ensure that the incoming call matches a predefined Call Type 

(Use Case Not In POC Test)

D.4.5.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps determining the call matches a predefined call type.  This call will be monitored from the test bed PSAP location.

D.4.5.2    Test Procedure:

1. Call initiated to test bed PSAP and passes the steps defined in Recognize Originating Location procedures (CT-CAUTH).
2. System reads data to determine call type.
3. System determines whether ANI data or limited pointer data is included in call stream.
4. If ANI data or limited pointer data is included in call stream, system accesses ALI database and adds ALI data to the call stream.
5. System determines call type.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. System compares call type against the business rules database to ensure match against defined call types.
8. System assigns a default call type if call type does not match business rules database.
9. System updates call type data, adds call type to call stream, and updates call detail record database.
10. System routes call to test bed PSAP.

D.4.5.3    Expected Results:

The call detail records database will indicate an update to the call detail that the call type matched a predefined call type and was validated against the business rules database.

D.4.5.4    Pass/Fail:

D.4.5.5    Results:

D.4.6    The system shall provide the capability to allow a system administrator to create new Call Type definitions

 (Use Case Not In POC Test)

D.4.6.1    Test Description:

The system administrator will login, access the business rules database, and create a new call type definition. This process will be monitored from the test bed PSAP location.

D.4.6.2    Test Procedure:

1. Tester logs in as system administrator on server containing business rules database.
2. Tester accesses business rules database.
3. Tester creates new call type definition.

D.4.6.3    Expected Results:

The new call type definition will be visible through the system administrator login in the business rules database.

D.4.6.4    Pass/Fail:

D.4.6.5    Results:

D.4.7    The system shall provide the capability to allow a system administrator to read an expected Call Type definition

 (Use Case Not In POC Test)

D.4.7.1    Test Description:

The system administrator will login, access business rules database, and view call type definitions. This process will be monitored from the test bed PSAP location.

D.4.7.2    Test Procedure:

1. Tester logs in as system administrator on server containing business rules database.
2. Tester accesses business rules database.
3. Tester views call type definitions.

D.4.7.3    Expected Results:

The call type definitions will be visible through the system administrator login in the business rules database.

D.4.7.4    Pass/Fail:

D.4.7.5    Results:

D.4.8    The system shall provide the capability to allow a system administrator to update Call Type definition 

(Use Case Not In POC Test)

D.4.8.1    Test Description:

The system administrator will login, access business rules database, and update call type definition. This process will be monitored from the test bed PSAP location.

D.4.8.2    Test Procedure:

1. Tester logs in as system administrator on server containing business rules database.
2. Tester accesses business rules database.
3. System displays current call type definitions.
4. Tester selects a call type definition to update.
5. Tester updates selected call type definition.

D.4.8.3    Expected Results:

The selected call type definition will be visible as updated through the system administrator login in the business rules database.

D.4.8.4    Pass/Fail:

D.4.8.5    Results:

D.4.9    The system shall provide the capability to allow a system administrator to delete Call Type definition  (Use Case Not In POC Test)

D.4.9.1    Test Description:

The system administrator will login, access business rules database, and delete the call type definition. This process will be monitored from the test bed PSAP location.

D.4.9.2    Test Procedure:

1. Tester logs in as system administrator on server containing business rules database.
2. Tester accesses business rules database.
3. System displays current call type definitions.
4. Tester selects a call type definition to delete.
5. Tester deletes selected call type definition.

D.4.9.3    Expected Results:

The deleted call type definition should no longer be visible through the system administrator login in the business rules database.

D.4.9.4    Pass/Fail:

D.4.9.5    Results:

D.4.10    The system shall provide the capability to allow a system administrator to save Call Type definition 

(Use Case Not In POC Test)

D.4.10.1    Test Description:

The system administrator will login, access business rules database, create a new call type definition, and save that call type definition.  This process will be monitored from the test bed PSAP location.

D.4.10.2    Test Procedure:

1. Tester logs in as system administrator on server containing business rules database.
2. Tester accesses business rules database.
3. Tester creates new call type definition.
4. Tester saves new call type definition.

D.4.10.3    Expected Results:

A new call type definition will be visible through the system administrator login in the business rules database as saved.

D.4.10.4    Pass/Fail:

D.4.10.5    Results:

D.4.11    The system shall assign a default Call Type for calls received with an undefined Call Type 

(Use Case Not In POC Test)

D.4.11.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH). This call will have an undefined call type and the system will assign a default call type. This call will be monitored from the test bed PSAP location.

D.4.11.2    Test Procedure:

1. Call initiated to test bed PSAP and pass steps defined in the Recognize Originating Location procedures (CT-CAUTH).
2. System reads data to determine call type.
3. System determines whether ANI data or limited pointer data is included in call stream.
4. If ANI data or limited pointer data is included in call stream, system accesses ALI database and adds ALI data to the call stream.
5. System determines call type.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. System compares call type against the business rules database to ensure match against defined call types.
8. System assigns a default call type if call type does not match business rules database.
9. System updates call type data, adds call type to call stream, and updates call detail record database.
10. System routes call to test bed PSAP.

D.4.11.3    Expected Results:

The call detail records database will indicate an update to the call detail that the call type did not match a predefined call type in the business rules database and a default call type was added.

D.4.11.4    Pass/Fail:

D.4.11.5    Results:

D.4.12    The system shall determine an appropriate Call Type for calls received with an undefined Call Type

D.4.12.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH). This call will have an undefined call type and the system will determine an appropriate call type.  This call will be monitored from the test bed PSAP location.

D.4.12.2    Test Procedure:

1.  Call initiated to test bed PSAP and passes the steps defined in Recognize Originating Location procedures (CT-CAUTH).
2. System reads data to determine call type.
3. System determines whether ANI data or limited pointer data is included in call stream.
4. If ANI data or limited pointer data is included in call stream, system accesses ALI database and adds ALI data to the call stream.
5. System determines call type.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. System compares call type against the business rules database to ensure match against defined call types.
8. System assigns a default call type if call type does not match business rules database.
9. System updates call type data, adds call type to call stream, and updates call detail record database.
10. System routes call to test bed PSAP.

D.4.12.3    Expected Results:

The call detail records database will indicate an update to the call detail that the call type did not match a predefined call type in the business rules database and a default call type was added.

D.4.12.4    Pass/Fail:

D.4.12.5    Results:

D.4.13    The system shall indicate to the call taker whether the Call Type of a call was changed by the system as the result of a received undefined Call Type

 (Use Case Not In POC Test)

D.4.13.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH). This call will have a changed call type. This call will be monitored from the test bed PSAP location.

D.4.13.2    Test Procedure:

1. Call initiated to test bed PSAP and passes the steps defined in Recognize Originating Location procedures (CT-CAUTH).
2. System reads data to determine call type.
3. System determines whether ANI data or limited pointer data is included in call stream.
4. If ANI data or limited pointer data is included in call stream, system accesses ALI database and adds ALI data to the call stream.
5. System determines call type.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. System compares call type against business rules database to ensure match against defined call types.
8. System assigns a default call type if call type does not match business rules database.
9. System updates call type data, adds call type to call stream, and updates call detail record database.
10. System routes call to test bed PSAP.

D.4.13.3    Expected Results:

The call detail records database will indicate an update to call detail that the call type did not match a predefined call type in the business rules database and a default call type was added.  The call will appear at the test bed PSAP location indicating call type was changed by the system.

D.4.13.4    Pass/Fail:

D.4.13.5    Results:

D.4.14    The system shall assign a default Call Type for calls received with an unrecognizable Call Type 

 (Use Case Not In POC Test)

D.4.14.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH). This call will have an unrecognizable call type and the system will assign a default cal type. This call will be monitored from the test bed PSAP location.

D.4.14.2    Test Procedure:

1. Call initiated to test bed PSAP and passes the steps defined in Recognize Originating Location procedures (CT-CAUTH).
2. System reads data to determine call type.
3. System determines whether ANI data or limited pointer data is included in call stream.
4. If ANI data or limited pointer data is included in call stream, system accesses ALI database and adds ALI data to the call stream.
5. System determines call type.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. System compares call type against business rules database to ensure match against defined call types.
8. System assigns a default call type if call type does not match business rules database or is unrecognizable.
9. System updates call type data, adds call type to call stream, and updates call detail record database.
10. System routes call to test bed PSAP.

D.4.14.3    Expected Results:

The call detail records database will indicate an update to call detail that the call type was unrecognizable and did not match a predefined call type in the business rules database and a default call type was added.  Call will appear at the test bed PSAP location indicating call type was changed by the system.

D.4.14.4    Pass/Fail:

D.4.14.5    Results:

D.4.15    The system shall indicate to the call taker whether the Call Type of a call was changed by the system as the result of a received unrecognizable Call Type 

(Use Case Not In POC Test)

D.4.15.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH). This call will have an unrecognizable call type. This call will be monitored from the test bed PSAP location.

D.4.15.2    Test Procedure:

1. Call initiated to test bed PSAP and passes the steps defined in Recognize Originating Location procedures (CT-CAUTH).
2. System reads data to determine call type.
3. System determines whether ANI data or limited pointer data is included in call stream.
4. If ANI data or limited pointer data is included in call stream, system accesses ALI database and adds ALI data to the call stream.
5. System determines call type.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. System compares call type against business rules database to ensure match against defined call types.
8. System assigns a default call type if call type does not match business rules database or is unrecognizable.
9. System updates call type data, adds call type to call stream, and updates call detail record database.
10. System routes call to test bed PSAP.

D.4.15.3    Expected Results:

The call detail records database will indicate an update to the call detail that the call type was unrecognizable and did not match a predefined call type in the business rules database and a default call type was added.  The call will appear at the test bed PSAP location indicating the call type was changed by the system because of an unrecognizable call type.

D.4.15.4    Pass/Fail:

D.4.15.5    Results:

D.4.16    The system shall provide the capability to add identified data items according to NENA Technical Information Document on the Interface between the E9-1-1 Service Provider Network and the Internet Protocol (IP) PSAP (NENA-08-501) to data associated with Call Stream 

(Use Case Not In POC Test)

D.4.16.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH) and the Identify initial call type (CT-REGCT).  This call will contain ANI data and limited pointer data. This call will be monitored from the test bed PSAP location.

D.4.16.2    Test Procedure:

1. Call initiated to test bed PSAP and passes the steps defined in Recognize Originating Location procedures (CT-CAUTH) and Identify initial call type (CT-REGCT). Call will contain ANI data and limited pointer data.
2. System determines whether call has only ANI data or has limited pointer data.
3. If call data complete, system reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
4. If call data is ANI only or limited pointer data, system updates call against ALI database, updates call stream information, and updates call records database.  Data items added to call formatted according to NENA Technical Information Document on the Interface between the E9-1-1 Service Provider Network and the Internet Protocol (IP) PSAP (NENA-08-501).
5. System reads call stream and compare against business rules database to add call type and priority to assist with call routing.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. If call is unrecognizable, system uses business rules database to ensure call type matches a defined call type and assigns a default call type if not valid.
8. System updates call type if necessary, updates call stream, and updates call detail record database.
9. System routes call to test bed PSAP.

D.4.16.3    Expected Results:

The call records database will be updated.  Data items added to the call will be formatted according to NENA Technical Information Document on the Interface between the E9-1-1 Service Provider Network and the Internet Protocol (IP) PSAP (NENA-08-501).

D.4.16.4    Pass/Fail:

D.4.16.5    Results:

D.4.17    The system will check the supporting data to determine if the Call Type or Priority needs to be updated

(Use Case Not In POC Test)

D.4.17.1    Test Description:

A call will be initiated to the test bed PSAP and check supporting data to determine if call type or priority needs to be updated.  This call will be monitored from the test bed PSAP location.

D.4.17.2    Test Procedure:

1. Call initiated to test bed PSAP and passes the steps defined in Recognize Originating Location procedures (CT-CAUTH) and Identify initial call type (CT-REGCT).
2. System determines whether call has only ANI data or has limited pointer data.
3. If call data complete, system reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
4. If call data is ANI only or limited pointer data, system updates call against ALI database, updates call stream information, and updates call records database.
5. System reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. If call is unrecognizable, system uses business rules database to ensure call type matches a defined call type and assign a default call type if not valid.
8. System updates call type if necessary, updates call stream, and updates call detail record database.
9. System routes call to test bed PSAP.

D.4.17.3    Expected Results:

The call detail records database will be updated indicating call type priority was checked and set if required.  

D.4.17.4    Pass/Fail:

D.4.17.5    Results:

D.4.18    The system shall determine additional supportive data for the call based on the Essential Call Data

D.4.18.1    Test Description:

A call will be initiated to the test bed PSAP and determine additional supportive data.  This call will be monitored from the test bed PSAP location.

D.4.18.2    Test Procedure:

1. Call initiated to test bed PSAP and passes steps defined in Recognize Originating Location procedures (CT-CAUTH) and Identify initial call type (CT-REGCT).
2. System determines whether call has only ANI data or has limited pointer data.
3. If call data complete, system reads call stream compare it against business rules database to add call type and priority to assist with call routing.
4. If call data is ANI only or limited pointer data, system updates call against ALI database, updates call stream information, and updates call records database.
5. System reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. If call is unrecognizable, system uses business rules database to ensure call type matches a defined call type and assigns a default call type if not valid.
8. System updates call type if necessary, updates call stream, and updates call detail record database.
9. System examines business rules database and call detail records database to identify sources of additional information. If none, call continues processing and appears at test bed PSAP.
10. If additional sources of information are available, system checks supporting data sources and business rules database. System adds this information to call stream, accesses business rules database to recalculate priority and call type, and updates call detail record database.
11. System routes call on to test bed PSAP.

D.4.18.3    Expected Results:

The call detail records database will indicate whether additional sources of information were available for the call and whether the information was added to the call stream.  

D.4.18.4    Pass/Fail:

D.4.18.5    Results:

D.4.19    The system shall identify how to access the supporting data (e.g., IP address of server)

D.4.19.1    Test Description:

A call will be initiated to the test bed PSAP and identify how to access supporting data.  This call will be monitored from the test bed PSAP location.

D.4.19.2    Test Procedure:

1. Call initiated to test bed PSAP and passes steps defined in Recognize Originating Location procedures (CT-CAUTH) and Identify initial call type (CT-REGCT).
2. System determines whether call has only ANI data or has limited pointer data.
3. If call data complete, system reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
4. If call data is ANI only or limited pointer data, system updates call against ALI database, updates call stream information, and updates call records database.
5. System reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. If the call is unrecognizable, system uses business rules database to ensure call type matches a defined call type and assigns a default call type if not valid.
8. System updates call type if necessary, updates call stream, and updates call detail record database.
9. System examines business rules database and call detail records database to identify sources of additional information. If none, call continues processing and appears at test bed PSAP.
10. If additional sources of information are available, system checks supporting data sources and business rules database. System adds this information to call stream, accesses business rules database to recalculate priority and call type, and updates call detail record database.
11. System routes call to test bed PSAP.

D.4.19.3    Expected Results:

The call detail records database will indicate whether additional sources of information were available for the call and whether the information was added to the call stream.  The details records database will also indicate the IP address of servers accessed for additional call information.

D.4.19.4    Pass/Fail:

D.4.19.5    Results:

D.4.20    The system shall maintain the credentials to allow access to the supporting data 

(Use Case Not In POC Test)

D.4.20.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH) and the Identify initial call type (CT-REGCT).  The logs will be checked to determine if credentials in the system allow the access to supporting data.  This call will be monitored from the test bed PSAP location.

D.4.20.2    Test Procedure:

1. Call initiated to test bed PSAP and passes steps defined in Recognize Originating Location procedures (CT-CAUTH) and Identify initial call type (CT-REGCT).
2. System determines whether call has only ANI data or has limited pointer data.
3. If call data complete, system reads call stream and compare it against business rules database to add call type and priority to assist with call routing.
4. If call data is ANI only or limited pointer data, system updates call against the ALI database, updates call stream information, and updates call records database.
5. System reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. If call is unrecognizable, system uses business rules database to ensure call type matches a defined call type and assigns a default call type if not valid.
8. System updates call type if necessary, updates call stream, and updates call detail record database.
9. System examines business rules database and call detail records database to identify sources of additional information. If none, call continues processing and appears at test bed PSAP.
10. If additional sources of information are available, system checks supporting data sources and business rules database for credentials to access these sources. System adds this information to call stream, accesses business rules database to recalculate priority and call type, and updates call detail record database.
11. System routes call to test bed PSAP.

D.4.20.3    Expected Results:

The call detail records database will indicate whether additional sources of information were available for the call and whether the information was added to the call stream.  The details records database will also indicate the credentials were valid to access the additional servers available for additional call information.

D.4.20.4    Pass/Fail:

D.4.20.5    Results:

D.4.21    The system shall be able to automatically retrieve or query data from supporting data sources

D.4.21.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH) and the Identify initial call type (CT-REGCT).  The system will automatically query and retrieve supporting data.  This call will be monitored from the test bed PSAP location.

D.4.21.2    Test Procedure:

1. Call initiated to test bed PSAP and passes steps defined in Recognize Originating Location procedures (CT-CAUTH) and Identify initial call type (CT-REGCT).
2. System determines whether call has only ANI data or has limited pointer data.
3. If call data complete, system reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
4. If call data is ANI only or limited pointer data, system updates call against the ALI database, updates call stream information, and updates call records database.
5. System reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. If the call is unrecognizable, system uses business rules database to ensure call type matches a defined call type and assigns a default call type if not valid.
8. System updates call type if necessary, updates call stream, and updates call detail record database.
9. System examines business rules database and call detail records database to identify sources of additional information. If none, call continues processing and appears at test bed PSAP.
10. If additional sources of information are available, system checks supporting data sources and business rules database. System adds this information to call stream, accesses business rules database to recalculate priority and call type, and updates call detail record database.
11. System routes call to test bed PSAP.

D.4.21.3    Expected Results:

The call detail records database will indicate whether additional sources of information were available for the call and whether the information was added to the call stream.  The details records database will also indicate what additional data sources were queried and accessed for call processing.

D.4.21.4    Pass/Fail:

D.4.21.5    Results:

D.4.22    The system shall be able to automatically process the retrieved data and make a decision on whether or not to change the Call Type or Priority, based on business rules  (Use Case Not In POC Test)

D.4.22.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH) and the Identify initial call type (CT-REGCT).  The system will process the data.  This call will be monitored from the test bed PSAP location.

D.4.22.2    Test Procedure:

1. Call initiated to test bed PSAP and passes steps defined in Recognize Originating Location procedures (CT-CAUTH) and Identify initial call type (CT-REGCT).
2. System determines whether call has only ANI data or has limited pointer data.
3. If call data complete, system reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
4. If call data is ANI only or limited pointer data, system updates call against ALI database, updates call stream information, and updates call records database.
5. System reads call stream and compares against business rules database to add call type and priority to assist with call routing.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. If call is unrecognizable, system uses business rules database to ensure call type matches a defined call type and assigns a default call type if not valid.
8. System updates call type if necessary, updates call stream, and updates call detail record database.
9. System examines business rules database and call detail records database to identify sources of additional information. If none, call continues processing and appears at test bed PSAP.
10. If additional sources of information are available, system checks supporting data sources and business rules database. System adds this information to call stream, accesses business rules database to recalculate priority and call type, and updates call detail record database.
11. System routes call to test bed PSAP.

D.4.22.3    Expected Results:

The call detail records database will indicate whether additional sources of information were available for the call and whether the information was added to the call stream.  The details records database will indicate what additional data sources were queried and accessed for call processing.  The details record database will also indicate whether a decision was processed to change the Call Type or Priority based on business rules.  The call will continue processing and appear at the test bed PSAP.

D.4.22.4    Pass/Fail:

D.4.22.5    Results:

D.4.23    The system shall not make any changes to the Call Type or Priority if nothing in the supplemental information retrieved affects call routing rules 

(Use Case Not In POC Test)

D.4.23.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH) and the Identify initial call type (CT-REGCT).  This call will retrieve additional call information that will not affect call type or priority. This call will be monitored from the test bed PSAP location.

D.4.23.2    Test Procedure:

1. Call initiated to test bed PSAP and passes steps defined in Recognize Originating Location procedures (CT-CAUTH) and Identify initial call type (CT-REGCT).
2. System determines whether call has only ANI data or has limited pointer data.
3.  If call data complete, system reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
4. If call data is ANI only or limited pointer data, system updates call against ALI database, updates call stream information, and updates call records database.
5. System reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. If call is unrecognizable, system uses business rules database to ensure call type matches a defined call type and assigns a default call type if not valid.
8. System updates call type if necessary, updates call stream, and updates call detail record database.
9. System examines business rules database and call detail records database to identify sources of additional information. If none, call continues processing and appears at test bed PSAP.
10. If additional sources of information are available, system checks supporting data sources and business rules database. System adds this information to call stream, accesses business rules database to recalculate priority and call type, and updates call detail record database.
11. System routes call to test bed PSAP.

D.4.23.3    Expected Results:

The call detail records database will whether indicate additional sources of information were available for the call and whether the information was added to the call stream.  The details records database will indicate what additional data sources were queried and accessed for call processing.  The details record database will also indicate whether a decision was processed not to change the Call Type or Priority, based on business rules.

D.4.23.4    Pass/Fail:

D.4.23.5    Results:

D.4.24    The system shall have the ability to update the call stream (i.e., Call Type, Priority) to affect call routing

D.4.24.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH) and the Identify initial call type (CT-REGCT).  This call will retrieve additional call information that will affect call type and priority. This call will be monitored from the test bed PSAP location.

D.4.24.2    Test Procedure:

1. Call initiated to test bed PSAP and passes steps defined in Recognize Originating Location procedures (CT-CAUTH) and Identify initial call type (CT-REGCT).
2. System determines whether call has only ANI data or has limited pointer data.
3. If call data complete, system reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
4. If call data is ANI only or limited pointer data, system updates call against ALI database, updates call stream information, and updates call records database.
5. System reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. If call is unrecognizable, system uses business rules database to ensure call type matches a defined call type and assigns a default call type if not valid.
8. System updates call type if necessary, updates call stream, and updates call detail record database.
9. System examines business rules database and call detail records database to identify sources of additional information. If none, call continues processing and appears at test bed PSAP.
10. If additional sources of information are available, system checks supporting data sources and business rules database. System adds this information to call stream, accesses business rules database to recalculate priority and call type, and updates call detail record database.
11. System routes call to test bed PSAP.

D.4.24.3    Expected Results:

The call detail records database will indicate whether additional sources of information were available for the call and whether the information was added to the call stream.  The details records database will indicate what additional data sources were queried and accessed for call processing.  The details record database will also indicate a decision was processed to change the Call Type and Priority, based on business rules.

D.4.24.4    Pass/Fail:

D.4.24.5    Results:

D.4.25    The system shall be able to update the call detail record with selective data, based on business rules, from supporting data sources and a pointer to the full data set, in order to document the functions performed in this activity

D.4.25.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH) and the Identify initial call type (CT-REGCT).  The call detail record will be updated with supporting data.This call will be monitored from the test bed PSAP location.

D.4.25.2    Test Procedure:

1. Call initiated to test bed PSAP and passes steps defined in Recognize Originating Location procedures (CT-CAUTH) and Identify initial call type (CT-REGCT).
2. System determines whether call has only ANI data or has limited pointer data.
3. If call data complete, system reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
4. If call data is ANI only or limited pointer data, system updates call against ALI database, updates call stream information, and updates call records database.
5. System reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. If the call is unrecognizable, system uses business rules database to ensure call type matches a defined call type and assigns a default call type if not valid.
8. System updates call type if necessary, updates call stream, and updates call detail record database.
9. System examines business rules database and call detail records database to identify sources of additional information. If none, call continues processing and appears at test bed PSAP.
10. If additional sources of information are available, system checks supporting data sources and business rules database. System adds this information to call stream, accesses business rules database to recalculate priority and call type, and updates call detail record database.
11. System routes call to test bed PSAP.

D.4.25.3    Expected Results:

The call detail records database will indicate whether additional sources of information were available for the call and whether the information was added to the call stream based on business rules database.  The details records database will indicate what additional data sources were queried and accessed for call processing, along with a pointer to the full data set.  The details record database will also indicate a decision was processed to change the Call Type and Priority, based on business rules.  (For the POC only the links to the data will be recorded.)

D.4.25.4    Pass/Fail:

D.4.25.5    Results:

D.4.26    The system shall be able to detect any unrecognizable formats or garbled data in the Call Type 

(Use Case Not In POC Test)

D.4.26.1    Test Description:

A call with garbled data will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH) and the Identify initial call type (CT-REGCT).  This call will be monitored from the test bed PSAP location.

D.4.26.2    Test Procedure:

1. Call initiated to test bed PSAP and passes steps defined in Recognize Originating Location procedures (CT-CAUTH) and Identify initial call type (CT-REGCT).
2. System determines whether call has only ANI data or has limited pointer data.
3. If call data complete, system reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
4. If call data is ANI only or limited pointer data, system updates call against ALI database, updates call stream information, and updates call records database.
5. System reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. If call is unrecognizable, system uses business rules database to ensure call type matches a defined call type and assigns a default call type if not valid.
8. System updates call type if necessary, updates call stream, and updates call detail record database.
9. System examines business rules database and call detail records database to identify sources of additional information. If none, call continues processing and appears at test bed PSAP.
10. If additional sources of information are available, system checks supporting data sources and business rules database. System adds this information to call stream, accesses business rules database to recalculate priority and call type, and updates call detail record database.
11. System routes call to test bed PSAP.

D.4.26.3    Expected Results:

The call detail records database will indicate any unrecognizable formats or garbled data in the call type.  The details record database will also indicate what decision was processed to change the call type and priority, based on business rules.

D.4.26.4    Pass/Fail:

D.4.26.5    Results:

D.4.27    The system shall record the original Call Type when a received call type is a) unrecognizable, b) undefined 

(Use Case Not In POC Test)

D.4.27.1    Test Description:

A call with undefined call type will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH) and the Identify initial call type (CT-REGCT).  The system will record the original call type.  This call will be monitored from the test bed PSAP location.

D.4.27.2    Test Procedure:

1. Call initiated to test bed PSAP and passes steps defined in Recognize Originating Location procedures (CT-CAUTH) and the Identify initial call type (CT-REGCT).
2. System determines whether call has only ANI data or has limited pointer data.
3. If call data complete, system reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
4. If call data is ANI only or limited pointer data, system updates call against ALI database, updates call stream information, and updates call records database.
5. System reads call stream and compares it against business rules database to add call type and priority to assist with call routing.
6. System error checks call to ensure it is not garbled or unrecognizable.
7. If call is unrecognizable, system uses business rules database to ensure call type matches a defined call type and assigns a default call type if not valid.
8. System update call type if necessary, updates call stream, and updates call detail record database.
9. System examines business rules database and call detail records database to identify sources of additional information. If none, call continues processing and appears at test bed PSAP.
10. If additional sources of information are available, system checks supporting data sources and business rules database. System adds this information to call stream, accesses business rules database to recalculate priority and call type, and updates call detail record database.
11. System routes call to test bed PSAP.

D.4.27.3    Expected Results:

The call detail records database will indicate any unrecognizable formats or garbled data in the call type. The details record database will also indicate what decision was processed to change the call type and priority, based on business rules.  The original call type will be recorded in the call detail records database.  The call will continue processing and appear at the test bed PSAP.

D.4.27.4    Pass/Fail:

D.4.27.5    Results:

D.5    Route Call to PSAP [CT-RTPSP]

This activity reflects the actual routing of a 9-1-1 call event to one or more appropriate PSAPs based on initial call treatment and the determined location (civic or geospatial) of the incident or event.  Multiple PSAPs may be involved in a coordinated relationship depending on the nature of the event (e.g., a large-scale disaster event) and its location (e.g., if the determined location accuracy is not sufficient to specifically identify a single PSAP).

D.5.1    The system shall route calls based on the associated call treatment process

D.5.1.1    Test Description:

Calls will be initiated to the test bed PSAP with defined call parameter data organized to generate a specific call treatment and terminating PSAP.  Results will be monitored at the involved databases and PSAPs.

D.5.1.2    Test Procedure:

1. Call treatments defined and call data parameters for each identified.
2. Calls initiated to test bed PSAP with data arranged for each treatment.
3. System accesses location routing database to determine normal PSAP identification and routing termination point.
4. System accesses business rules database to determine modifying information on terminating PSAP.
5. System generates call detail record documenting data and identifying actions.
6. System routes call to proper PSAP.

D.5.1.3    Expected Results:

The system will route the calls to the PSAPs designed to receive them based on the defined call parameters and the content of the databases.

D.5.1.4    Pass/Fail:

D.5.1.5    Results:

D.5.2    The system shall be able to read fields from the call stream as input to determine how to route the call

D.5.2.1    Test Description:

Calls will be initiated to the test bed PSAP with designed data fields content.  Call detail records will be inspected to ensure that appropriate data fields were read and recorded.  These calls will be monitored from the test bed PSAP location.

D.5.2.2    Test Procedure:

1. Calls with designed data fields content initiated to test bed PSAP.
2. System reads data information from call stream.
3. System error checks format to make sure it is not garbled or unintelligible.
4. System updates call detail record database.
5. System routes call to test bed PSAP.

D.5.2.3    Expected Results:

The call detail record will contain data from the appropriate data fields for each test call.

D.5.2.4    Pass/Fail:

D.5.2.5    Results:

D.5.3    The system shall determine the proper treatment for calls that involve error cases (garbled ANI, ANI failure, no location data)

D.5.3.1    Test Description:

Calls will be initiated to the test bed PSAP with appropriate combinations of empty fields or garbled data.  These calls will be monitored from the test bed PSAP location.

D.5.3.2    Test Procedure:

1. Call with an unrecognizable data type initiated to test bed PSAP.
2. System reads appropriate information fields from call stream.
3. System error checks format to determine whether data is garbled or missing.
4. System fails error check because of unrecognizable data type.
5. System checks whether fall-back location exists and assign it if present.
6. System assigns default location if fall-back location does not exist.
7. System updates call detail record database.
8. System routes call to test bed PSAP with default data listed.

D.5.3.3    Expected Results:

Calls will be delivered to expected PSAPs and with expected default data for error case call data content.

D.5.3.4    Pass/Fail:

D.5.3.5    Results:

D.5.4    The system shall determine the call treatment for each call based on call type, location, and service routing rules

D.5.4.1    Test Description:

Calls will be initiated to the test bed PSAP with appropriate call type data for the POC scope.  These calls will be monitored from the originating and terminating PSAPs.

D.5.4.2    Test Procedure:

1. Call for each POC-applicable call type initiated to test bed PSAP.
2. System reads appropriate information field from call stream.
3. System error checks format to determine whether data is garbled or missing.
4. System fails error check because of unrecognizable call type data.
5. System checks whether fall-back location exists and assign it if present.
6. System assigns default location if fall-back location does not exist.
7. System updates call detail record database.
8. System uses hard-coded and business rules information for each call type to determine treatment of the call.
9. As appropriate, for each call type, system generates messaging back to caller and delivery to expected PSAP based on business rules database content, with the display of call type or equivalent wording.

D.5.4.3    Expected Results:

Each call type will result in the expected call treatment and routing decision, and response to the caller if appropriate.

D.5.4.4    Pass/Fail:

D.5.4.5    Results:

D.5.5    The system shall determine the proper treatment for incomplete Call Type records 

(Use Case Not In POC Test)

D.5.5.1    Test Description:

A call will be initiated to the test bed PSAP with incomplete call type data.  This call will be monitored from the test bed PSAP location.

D.5.5.2    Test Procedure:

1. Call with an incomplete call type initiated to test bed PSAP.
2. System reads appropriate information field from call stream.
3. System error checks format to determine whether data is complete.
4. System fails error check because of unrecognizable call type data.
5. System assigns routing based on business rules (or hard coding if applicable).
6. System updates call detail record database.
7. System routes call to PSAP assigned for incomplete call type.
8. PSAP display indicates lack of call type data availability.

D.5.5.3    Expected Results:

The call detail record will document lack of call type data and resulting decision on routing.

D.5.5.4    Pass/Fail:

D.5.5.5    Results:

D.5.6    The system shall determine the proper treatment for fragmented Call Type records 

(Use Case Not In POC Test)

D.5.6.1    Test Description:

A call will be initiated to the test bed PSAP with fragmented call type data.  This call will be monitored from the test bed PSAP location.

D.5.6.2    Test Procedure:

1. Call with a fragmented call type initiated to test bed PSAP.
2. System reads appropriate information field from call stream.
3. System error checks format to determine whether data is complete.
4. System fails error checks because of unrecognizable call type data.
5. System assigns routing based on business rules (or hard coding if applicable).
6. System updates call detail record database.
7. System routes call to PSAP assigned for unavailable call type.
8. PSAP display indicates lack of call type data availability.

D.5.6.3    Expected Results:

The call detail record will document lack of call type data and resulting decision on routing.

D.5.6.4    Pass/Fail:

D.5.6.5    Results:

D.5.7    The system shall send a status message to the telecommunications device based on identified call treatment 

(Use Case Not In POC Test)

D.5.7.1    Test Description:

A test message from the system will be sent to appropriate devices, and the defined response monitored at the originating device and in the call detail record.  This call will be monitored from the test bed PSAP location.

D.5.7.2    Test Procedure:

1. Call initiated to test bed PSAP intended to generate a status message from system to the caller device.
2. System reads appropriate information field from call stream.
3. System errors check format to determine whether data is complete.
4. System fails error check if unrecognizable call type data.
5. System assigns status message based on business rules (or hard coding if applicable).
6. System updates call detail record database.
7. System sends status message to the caller device.

D.5.7.3    Expected Results:

An appropriate message to the caller will be returned to the caller device and documented in the detail call record.

D.5.7.4    Pass/Fail:

D.5.7.5    Results:

D.5.8    The system shall be able to provide an alternate call treatment when a call cannot be immediately answered because of call volume

D.5.8.1    Test Description:

A target PSAP will experience all positions busy and increasing call answer time as new calls are presented.  A threshold established by the PSAP or 9-1-1 Authority will invoke alternate call treatment that causes calls to be routed to options such as another pre-defined PSAP, 10-digit lines, or a recording. This call will be monitored from the test PSAP location.

D.5.8.2    Test Procedure:

1. Multiple calls initiated to system for delivery to a test PSAP, and testers hold those calls as active.
2. When all positions are busy, system checks for business rules database content regarding alternate call treatment.
3. When call volume exceeds business rule defined level for an all positions busy condition, system activates defined alternate treatment action.
4. System directs succeeding calls to alternate treatment routing path.
5. System sends a message to test bed PSAP that calls are being sent to alternate treatment route.
6. System sends a message to alternate treatment route, if it is a PSAP, to indicate that alternatively treated calls are arriving.
7. System updates detail call record content.
8. System displays messages or indicators of alternate treatment condition at both PSAPs.

D.5.8.3    Expected Results:

Alternate call treatment will be invoked and executed in accordance with the business rule threshold instructions.

D.5.8.4    Pass/Fail:

D.5.8.5    Results:

D.5.9    The system shall provide the capability for the network administrator to dynamically make changes to the routing policy

D.5.9.1    Test Description:

Calls will be initiated to the system to establish normal routing patterns.  Both the location-based routing and business rules databases will be changed to modify routing controls.  Test calls before and after the changes will verify that the changes are active in the system.  Test PSAPs, the system, and call record logs will be monitored.

D.5.9.2    Test Procedure:

1. Calls initiated to system to establish normal routing patterns.
2. POC network (probably actually the database) administrator makes changes to routing rules for Call Type and alternate routing controls in appropriate databases.
3. System updates detail call record to indicate changes.
4. Same pattern of test calls initiated to system again.
5. Each test call sent to PSAP defined by changed routing policies.
6. System updates detail call record.

D.5.9.3    Expected Results:

Changes in routing policy will cause equivalent changes in call routing.

D.5.9.4    Pass/Fail:

D.5.9.5    Results:

D.5.10    The system shall support the ability to establish a pre-determined limit on the total number of simultaneous 9-1-1 calls presented to the PSAP, regardless of what technology was used to deliver each individual call; and, at the option of the PSAP, when the pre-determined limit has been reached, provide alternate call treatments.

D.5.10.1    Test Description:

A simultaneous call limit will be set in the business rules database, and test calls will be initiated to the system to determine whether the alternate routing action is taken by the system under the intended call volume conditions. This will be monitored at the test bed laboratory and PSAPs.

D.5.10.2    Test Procedure:

1. Multiple calls initiated to system for delivery to a test PSAP, and testers hold those calls as active.
2. For each call, if PSAP or other authority has activated the feature, system checks for business rule database content regarding simultaneous call counts and alternate call treatment.
3. When simultaneous call volume exceeds business rule defined level, system activates defined alternate treatment action.
4. System directs succeeding calls to alternate treatment routing path.
5. System sends a message to test bed PSAP that calls are being sent to alternate treatment route.
6. System sends a message to alternate treatment route, if it is a PSAP, to indicate that alternative call treatment has been invoked.
7. System updates detail call record content.
8. System displays messages or indicators of alternate treatment condition status at both PSAPs.

D.5.10.3    Expected Results:

Calls will be redirected in accordance with the business rule content when the simultaneous calls threshold is exceeded.

D.5.10.4    Pass/Fail:

D.5.10.5    Results:

D.5.11    The system shall be designed with sufficient bandwidth to support the predetermined limit of simultaneous calls using the type of call technology supported that has the highest bandwidth requirement

D.5.11.1    Test Description:

An appropriate simultaneous call limit for a test PSAP will be defined in the business rules database, and a number of high bandwidth calls will be generated to determine whether bandwidth is sufficient to support the predetermined limit on number of calls without call quality degradation, as measured by packet-oriented test equipment at the test PSAP.  (Video-based calls are assumed to have the highest bandwidth requirement expectation.) This will be monitored in the test bed laboratory.

D.5.11.2    Test Procedure:

1. A business rule defined to indicate limit of simultaneous calls allowed.
2. Multiple high bandwidth calls initiated to system.
3. As each call is added, tester tests call quality to determine whether quality deteriorates before or after the simultaneous call limit is reached.

D.5.11.3    Expected Results:

Designed bandwidth will fully support call quality level for at least the number of simultaneous calls specified.

D.5.11.4    Pass/Fail:

D.5.11.5    Results:

D.5.12    The system shall be capable of negotiating for the highest quality of service supported by the 9-1-1 caller’s equipment and the PSAP’s 911 system in order to get the best audio /video available

D.5.12.1    Test Description:

Because determination of standards and testing of quality of service for voice calling over networks is currently under discussion and consideration by standards development organizations, this requirement will not be tested as part of the POC.

D.5.12.2    Test Procedure:

D.5.12.3    Expected Results:

D.5.12.4    Pass/Fail:

D.5.12.5    Results:

D.5.13    The system shall be able to overflow 9-1-1 calls directly to another designated backup IP PSAP, or multiple PSAPs, using agreed upon, predetermined criteria at both the sending and receiving PSAPs, including the receiving PSAP’s total call load

D.5.13.1    Test Description:

Appropriate overflow route criteria will be defined in the business rules database, and calls will be initiated to the system to evaluate the system’s ability to adhere to these criteria.  This will be monitored in the test bed laboratory.

D.5.13.2    Test Procedure:

1. Business rule conditions defined for overflow at some percentage or 100 percent of PSAP call capacity at each PSAP in overflow routing chain.
2. Simultaneous calls initiated to system, directed at initial PSAP.
3. When first PSAP’s limit is reached, system routes calls to next PSAP in overflow routing chain of first PSAP, if that receiving PSAP’s call limit has not been reached.
4. f second PSAP’s call limit has been reached, system routes calls to next PSAP designated in overflow routing chain of first PSAP.
5. If all PSAPs in routing chain have reached their limits, system keeps additional calls in queue for first PSAP, or directs them to a last route choice, such as recording (see requirement SR-RTPSP-01-07).
6. System updates call detail record throughout this test.

D.5.13.3    Expected Results:

Overflow to successive PSAPs will occur at the call volume limit of each PSAP in the overflow routing chain defined for the initial target PSAP.

D.5.13.4    Pass/Fail:

D.5.13.5    Results:

D.5.14    The system shall determine the next available PSAP pointer if the current is not available or accessible for any reason

D.5.14.1    Test Description:

Appropriate overflow route criteria will be defined in the business rules database, and calls will be initiated to the system to evaluate the system’s ability to adhere to these criteria if the initial target PSAP is out of service.  PSAP condition as test calls are initiated to the system and the presence of the call at the alternate PSAP will be monitored.

D.5.14.2    Test Procedure:

1. Business rule conditions set for alternate routing for a specific PSAP.
2. Calls initiated to system, directed to initial PSAP.
3. After system makes initial routing choice, it checks condition of the network to PSAP and service status of the PSAP.
4. If either network to PSAP or PSAP is out of service, system checks business rules for alternate routing instructions.
5. System routes call to alternate route PSAP.
6. New PSAP receives a message that alternate routing from specific initial PSAP has been activated.
7. System updates call detail record.
8. System continues to direct calls to alternate PSAP until system recognizes that the error condition has been corrected and service is restored to the PSAP.

D.5.14.3    Expected Results:

When the initial route PSAP is not accessible, calls will be directed to the alternate PSAP.

D.5.14.4    Pass/Fail:

D.5.14.5    Results:

D.5.15    The system shall track when Fall-Back Location Information is presented to the call taker as location data 

(Use Case Not In POC Test)

D.5.15.1    Test Description:

When the system must use the fall-back location for a call, the system will document that fact in the call detail record and display that information to the tester.  The PSAP and the call detail record content will be monitored.

D.5.15.2    Test Procedure:

1. Call initiated to system with no caller location data.
2. System uses defined fall-back location data in place of missing caller location.
3. System sends a flag or message to tester’s display to indicate condition.
4. System updates call detail record to reflect use of fall-back location.

D.5.15.3    Expected Results:

The tester will be notified and the call detail record content will be updated to reflect use of the fall-back location.

D.5.15.4    Pass/Fail:

D.5.15.5    Results:

D.5.16    The system shall provide a visual indication at the original PSAP that calls are overflowing

D.5.16.1    Test Description:

Calls will be initiated to the system with a specific PSAP target.  When call overflow conditions exist, the original target PSAP will receive a flag that can drive a visual indicator.  This will be monitored in the test bed PSAP.

D.5.16.2    Test Procedure:

1. Calls initiated to system with a specific PSAP target.
2. When overflow is invoked, system generates a flag added to call stream data, along with identification of original target PSAP.
3. System or PSAP equipment uses flag to activate a visual indicator at PSAP.

D.5.16.3    Expected Results:

When overflow occurs, a flag will trigger an appropriate visual indicator.

D.5.16.4    Pass/Fail:

D.5.16.5    Results:

D.5.17    The system shall provide a visual indication at the designated overflow PSAP that they are now receiving overflow calls from the original PSAP with identification of the original PSAP

D.5.17.1    Test Description:

Calls will be initiated to the system with a specific PSAP target. When call overflow conditions exist, the overflowed-to PSAP will receive an overflow flag and identification of the original target PSAP as part of the call stream data.  This will be monitored in the test bed PSAPs.

D.5.17.2    Test Procedure:

1. Calls initiated to system with a specific PSAP target.
2. When overflow is invoked, system adds a flag to call stream data, along with identification of original target PSAP.
3. System or PSAP equipment uses flag to activate a visual indicator and identification of initial PSAP at overflowed-to PSAP.

D.5.17.3    Expected Results:

The PSAP receiving overflow will also receive an indicator that overflow is in effect from the original PSAP.

D.5.17.4    Pass/Fail:

D.5.17.5    Results:

D.5.18    The system shall be able to overflow IP 9-1-1 calls to a traditional 9-1-1 PSAP, with the associated location data, to the extent the traditional 9-1-1 network supports connectivity (i.e., shares access to the same selective router, can transfer calls and data between selective routers, etc.)  

(Use Case Not In POC Test)

D.5.18.1    Test Description:

Because there are no selective routers in POC system or connectivity between the POC system and a parallel E9-1-1 system, this requirement cannot be tested as part of the POC.

D.5.18.2    Test Procedure:

D.5.18.3    Expected Results:

D.5.18.4    Pass/Fail:

D.5.18.5    Results:

D.5.19    The system shall be able to physically route the call to the determined destination PSAP

D.5.19.1    Test Description:

A call will be initiated to the system for a targeted PSAP.  The system will use the transport network to deliver that call to the designated PSAP.  This will be monitored in the test bed laboratory and PSAP.

D.5.19.2    Test Procedure:

1. Call initiated to system intended for a targeted PSAP.
2. System identifies a LoST route and intended PSAP, which may be modified by system conditions or business rules, and sends call toward that PSAP.
3. If connectivity exists, intended PSAP receives call.
4. System updates call detail record.

D.5.19.3    Expected Results:

If connectivity exists and is in service condition, the call will be received at the appropriate PSAP.

D.5.19.4    Pass/Fail:

D.5.19.5    Results:

D.6    Provide Network Bridging Services [CT-PNWBS]

This activity addresses network and system service functions necessary for system call taking and response entities to conference and share data as appropriate and beneficial to call treatment, processing, and incident management.  The service functions involved should allow any PSAP to conference and share data with any other PSAP (available through all interconnections, both domestic and international), and to manage that conferencing and sharing.  Network bridging services are implemented by the system when business rules cause or a call taker establishes a conference call [CP-ECONF] connecting multiple parties.

D.6.1    The system shall provide the capability to automatically connect multiple parties based on Call Detail Record  (Use Case Not In POC Test)

D.6.1.1    Test Description:

A call will be initiated that requires automatic conferencing of a third party.  Business rules will indicate a need to automatically conference in a third party on a call, based on call type.  The system will establish bridging for defined additional parties after determining final routing but prior to call arrival at the PSAP.  The destination PSAP and the call detail record content will be monitored.

D.6.1.2    Test Procedure:

1. Business rules established in business rules database regarding test call type.
2. Call initiated to system from a device that requires a translation service.
3. System determines route-to PSAP and checks business rules.
4. Business rules define that system should add on translation service.
5. System activates an appropriate bridging service and provides connecting Telephone Number (TN) for translation service.
6. Bridging service dials TN and brings translation service into call.
7. System routes call to PSAP.
8. System updates call detail record.
9. PSAP answers call and verifies that caller and translation service are active on call.

D.6.1.3    Expected Results:

Conferencing will be established under system and business rules control prior to call arrival at the PSAP.

D.6.1.4    Pass/Fail:

D.6.1.5    Results:

D.6.2    The system shall provide the capability to identify all bridged parties  

(Use Case Not In POC Test)

D.6.2.1    Test Description:

A call will be initiated to the system that requires automatic bridging.  All to-be-bridged parties other than the caller and the PSAP will be listed in the business rules.  Because bridging takes place automatically, these identifications will be added to the call stream data for display as a list on the tester’s screen.  Monitoring of the test will occur at the PSAP.

D.6.2.2    Test Procedure:

1. Call initiated to system that requires automatic bridging.
2. After system makes routing determinations, it accesses bridging instructions in business rules based on call type and/or other data.
3. As each bridging party is successfully or unsuccessfully added to call, system adds related identification data to call data stream with connection status.
4. System sends identification data to PSAP to cause a list to be displayed to tester.
5. Optimally, system forwards connection status data to PSAP when status changes take place (party drops off or goes on hold) to update list at PSAP.

D.6.2.3    Expected Results:

PSAP tester will see a list of bridged parties and their connection status.

D.6.2.4    Pass/Fail:

D.6.2.5    Results:

D.6.3    The system shall provide the capability to allow all bridged parties access to the unique call identifier

D.6.3.1    Test Description:

A call will be initiated to the system that requires automatic bridging.  All bridged parties will query for the call identifier.  Results at each bridged party’s equipment will be monitored.

D.6.3.2    Test Procedure:

1. Call initiated to system that requires automatic bridging.
2. System establishes bridge with all necessary parties.
3. A bridged party sends a call identifier query to system.
4. System accesses call detail record for active call.
5. System returns call identifier to query originator.

D.6.3.3    Expected Results:

Querying party will see proper call identifier at his/her position.

D.6.3.4    Pass/Fail:

D.6.3.5    Results:

D.6.4    The system shall provide the capability to allow all bridged parties to identify all bridged parties

D.6.4.1    Test Description:

A call will be initiated to the system that requires automatic bridging.  Each bridged party will see a list of all bridged parties associated with a call.  Results at each bridged party’s equipment will be monitored.

D.6.4.2    Test Procedure:

1. Call initiated to system that requires automatic bridging.  
2. System establishes bridge with all necessary parties.
3. For all parties on IP network (such as other PSAPs), system sends bridged party identification update data to each party as others are connected.
4. Each party’s equipment displays identification data.

D.6.4.3    Expected Results:

Each bridged party will see a list of all other bridged parties’ ID data.

D.6.4.4    Pass/Fail:

D.6.4.5    Results:

D.6.5    The system shall provide the capability to bridge requested parties into a conference call

D.6.5.1    Test Description:

A call will be initiated to the system that requires automatic bridging.  When automatic bridging based on call data and business rules has been established, the PSAP or other bridged party will bring additional parties into the conference call.  Monitoring will occur at the PSAP.

D.6.5.2    Test Procedure:

1. Call initiated to system that requires automatic bridging.
2. System establishes bridge with all necessary parties.
3. PSAP accesses bridging services and provides access number or code for an additional desired party.
4. Bridge accesses desired party and adds him/her into bridge connection.
5. System updates call detail record.
6. System sends new party identification data to all other parties to bridge.

D.6.5.3    Expected Results:

Requested party will join the bridge connection.

D.6.5.4    Pass/Fail:

D.6.5.5    Results:

D.6.6    The system shall provide the capability for the call taker to control the communication and data received by the caller 

(Use Case Not In POC Test)

D.6.6.1    Test Description:

A call will be initiated to the system that requires automatic bridging.  System will query the tester (call taker) for permission to send data that could be received by the caller, and provide the ability to block transmission to the caller.  Tester will be able to mute voice to the caller as needed.  This will be monitored in the test bed PSAP and the caller’s location.

D.6.6.2    Test Procedure:

1. Call initiated to system that requires automatic bridging.
2. System establishes bridge with all necessary parties.
3. Tester queries for Supplemental data or data from call detail record.
4. System queries tester for clearance to send data to all parties on bridge or to exclude caller.
5. Tester responds that data should not be sent to caller.
6. System successfully blocks data transmission to caller connection.
7. Tester triggers bridging service to mute caller connection.
8. Voice traffic initiated on bridge.
9. Caller does not hear voice traffic until tester triggers bridge service to un-mute caller connection.

D.6.6.3    Expected Results:

Data and voice will be blocked to the caller when system is instructed to do so by the tester.

D.6.6.4    Pass/Fail:

D.6.6.5    Results:

D.6.7    The system shall provide the capability to accept bridge requests

D.6.7.1    Test Description:

A call will be initiated to the system that requires automatic bridging.  The system will allow any party on an automatically established bridge to initiate requests to the bridging service for the inclusion of additional parties to the bridged call.  Monitoring will occur at the PSAP.

D.6.7.2    Test Procedure:

1. Call initiated to system that requires automatic bridging.
2. System establishes bridge with all necessary parties.
3. PSAP tester sends a query to system to contact bridging service to add parties.
4. Tester supplies number or code for desired party.
5. Bridging service accepts data from system.
6. Bridging service initiates contact with desired party.
7. Bridging service adds desired party to bridged call.

D.6.7.3    Expected Results:

System will communicates with the bridging service, which adds desired party to the bridged call.

D.6.7.4    Pass/Fail:

D.6.7.5    Results:

D.6.8    The system shall have the capability to automatically initiate a bridge request 

(Use Case Not In POC Test)

D.6.8.1    Test Description:

A call will be initiated that requires conferencing of a third party.  System will read the business rules, access the appropriate bridging service for the call type, and cause bridging to take place in accordance with the business rules.  This will be monitored in the PSAP and the caller’s location.

D.6.8.2    Test Procedure:

1. Business rules established in business rules database regarding the test call type.
2. Call initiated to system from a device that requires a third party.
3. System determines route-to PSAP and checks business rules.
4. Business rules define that system should add third party.
5. System activates an appropriate bridging service and provides identifying code for third party.
6. Bridging service activates addition of third party to call.
7. System routes call to PSAP.  
8. System updates call detail record.

D.6.8.3    Expected Results:

PSAP will answer the call and verify that caller and the appropriate third party are active on the call.

D.6.8.4    Pass/Fail:

D.6.8.5    Results:

D.6.9    The system shall determine the appropriate entities with which to initiate an automatic bridge request 

(Use Case Not In POC Test)

D.6.9.1    Test Description:

A call will be initiated to the system that requires automatic bridging.  The system will read the business rules, identify the defined entities for automatic bridging, access the appropriate bridging service for the call type, and cause bridging to take place for the entities defined in the business rules.  PSAP and call detail record content will be monitored.

D.6.9.2    Test Procedure:

1. Business rules established in business rules database regarding test call type.
2. Call initiated to system from a device that requires a third party.
3. System determines route-to PSAP and checks business rules.
4. Business rules define that system should add specific entities.
5. System activates an appropriate bridging service and provides identifying codes for defined entities.
6. Bridging service activates addition of third party to call.
7. System routes call to PSAP.
8. System updates call detail record.

D.6.9.3    Expected Results:

System will read business rules and identify entities to be bridged.

D.6.9.4    Pass/Fail:

D.6.9.5    Results:

D.6.10    The system shall determine the contact method for the parties with whom a bridge is requested

D.6.10.1    Test Description:

A call will be initiated to the system that requires automatic bridging.  The system will read the business rules, and identify the defined entities for automatic bridging and the contact method.  The system will access the appropriate bridging service for the call type and cause bridging to take place for the entities defined in the business rules.  The PSAP and call detail record content will be monitored.

D.6.10.2    Test Procedure:

1. Business rules established in business rules database regarding the test call type.
2. Call initiated to system from a device that requires a third party.
3. System determines route-to PSAP and check business rules.
4. Business rules define that system should add specific entities and contact method.
5. System activates an appropriate bridging service and provides identifying codes for defined entities.
6. Bridging service activates addition of third party into call.
7. System routes call to PSAP.
8. System updates call detail record.

D.6.10.3    Expected Results:

System will read business rules and identify entities to be bridged and the proper contact method.

D.6.10.4    Pass/Fail:

D.6.10.5    Results:

D.6.11    The system shall determine the contact information for the parties with whom a bridge is requested

D.6.11.1    Test Description:

A call will be initiated to the system that requires automatic bridging.  The system will read the business rules, identify the contact information for the defined entities for automatic bridging, access the appropriate bridging service for the call type, and cause bridging to take place for the entities defined in the business rules.  PSAP and call detail record content will be monitored.

D.6.11.2    Test Procedure:

1. Business rules established in business rules database regarding the test call type.
2. Call initiated to system from a device that requires a third party.
3. System determines route-to PSAP and check business rules.
4. Business rules define that system should add specific entities contact information.
5. System activates an appropriate bridging service and provides identifying codes for defined entities.
6. Bridging service activates addition of third party into call.
7. System routes the call to PSAP.
8. System updates call detail record.

D.6.11.3    Expected Results:

System will read business rules and identify entities to be bridged and the contact information.

D.6.11.4    Pass/Fail:

D.6.11.5    Results:

D.6.12    The system shall choose a bridge type based on Call Type of the call

D.6.12.1    Test Description:

Test calls requiring automatic bridging will be initiated to the system.  The system will access a bridge type as identified in business rules for the call type read from the call stream data.  Monitoring will occur at the system level using test data collection equipment.

D.6.12.2    Test Procedure:

1. Calls of various types that are pre-established to require automatic bridging initiated to the system.
2. System reads call type from the call data stream.
3. System compares Call Type with business rules content describing what type of bridging service is needed for each Call Type.
4. System accesses the bridge type.

D.6.12.3    Expected Results:

System will access the proper bridge type for each call type.

D.6.12.4    Pass/Fail:

D.6.12.5    Results:

D.6.13    The system shall be capable of establishing bridges of the following types: a) voice, b) video, c) interactive data sharing

D.6.13.1    Test Description:

Test calls requiring automatic bridging will be initiated to the system from voice, video, interactive data types.  The system will access a bridge type as identified in business rules for call type as read from the call stream data.  Monitoring will occur at system level using test data collection equipment.

D.6.13.2    Test Procedure:

1. Calls of various types that are pre-established to require automatic bridging initiated to system.
2. System reads call type from call data stream.
3. System compares call type with business rules content describing what type of bridging service is needed for each call type.
4. System accesses appropriate bridge type.
5. Steps 1 through 4 are repeated for each media type.

D.6.13.3    Expected Results:

A bridge will be established for each call type.  In the POC Video bridging of more than two parties is not supported.

D.6.13.4    Pass/Fail:

D.6.13.5    Results:

D.6.14    The system shall log conference bridge requests, including: a) time/date, b) all bridge participants, c) bridge type, d) bridge status

D.6.14.1    Test Description:

A call will be initiated to the system that requires automatic bridging.  The system will add the required data items to the call detail record.  Monitoring will occur through inspection of the call detail record content.

D.6.14.2    Test Procedure:

1. Call requiring bridging initiated to system.
2. Automatic bridging processes take place.
3. When bridging parties are established, system updates call record with time/date, all bridge participants, bridge type, and bridge status.

D.6.14.3    Expected Results:

Call detail record will contain all defined data for each bridging test.  For the POC c) bridge type, d) bridge status are not supported.

D.6.14.4    Pass/Fail:

D.6.14.5    Results:

D.6.15    The system shall alert the call taker in the event of an successful bridge setup

D.6.15.1    Test Description:

A call will be initiated to the system that requires automatic bridging.  Either by transmission or query, each bridged party will see a list of all bridged parties associated with a call.  Monitoring will occur at each party’s site.

D.6.15.2    Test Procedure:

1. Call requiring automatic bridging initiated to system.  
2. For all parties on IP network (such as other PSAPs), system sends bridged party identification update data to each party as others are connected.
3. Each party’s equipment displays identification data.

D.6.15.3    Expected Results:

Each bridged party will see a list of all other bridged party ID data.

D.6.15.4    Pass/Fail:

D.6.15.5    Results:

D.6.16    The system shall alert the call taker in the event of an unsuccessful bridge setup

D.6.16.1    Test Description:

A call will be initiated to the system that requires automatic bridging.  Tester will attempt to bridge a call to a party who is not available.  Either by transmission or query, each bridged party will see a list of all bridged parties associated with a call.  Monitoring will occur at each party’s site.

D.6.16.2    Test Procedure:

1. Call requiring automatic bridging initiated to system.  
2. Tester attempts to bridge to another party who is not available.
3. System sends message to tester that bridge is unsuccessful.
4. For all parties on IP network (such as other PSAPs), system sends bridged party identification update data to each party as others are connected.
5. Each party’s equipment displays the identification data.

D.6.16.3    Expected Results:

Tester will see an alert that the bridge was unsuccessful.

D.6.16.4    Pass/Fail:

D.6.16.5    Results:

D.7    Call Authentication [CT-CAUTH]

The call authentication process will include checking for the appropriate credential information in the incoming call stream against a list of approved provider credentials and other authorization lists.  If the provider credential is verified successfully, the call will be allowed to enter the NG9-1-1 system and will be directed to the appropriate PSAP.  If the credential is not successfully verified because it is not on the approved provider list, is explicitly blocked by the PSAP, or is not verified for various other reasons, the system will generate an error message and the call will be distributed based on authentication policy.  Unverified calls may be directed to a particular PSAP or other entity for handling and call analysis.  The call is authenticated both at the point of entry of the NG9-1-1 system as well as at a PSAP, and the authentication rules may be different for each entry point. The rules can explicitly permit or deny access to the NG9-1-1 system or PSAP. For example, a PSAP may need to deny access to a specific caller based on local policy or statute (e.g., a device making repeated and malicious false calls).

D.7.1    The system shall be able to read call source information from the call stream

D.7.1.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH), the Identify initial call type (CT-REGCT) procedure, and the Route call to PSAP procedure (CT-RTPSP).  The system will read the call source information.  This call will be monitored from the test bed PSAP location.

D.7.1.2    Test Procedure:

1. Call initiated to test bed PSAP and passes to Call authentication procedure (CT-CAUTH) from Route Call to PSAP procedure (CT-RTPSP).
2. System reads call provider source from call stream and updates call detail record database.
3. System validates provider certificate against a database of provider certificates and updates call detail record database.
4. System updates system audit database with results of certificate query.
5. For a valid certificate, system routes call to PSAP.
6. For an invalid certificate, system generates a call refusal with an error message.  Business rules database governs rules. System notifies caller of failed authentication.  System terminates call.

D.7.1.3    Expected Results:

The call detail record database will be updated indicating call source information was read from the call stream. Review of the call detail record database will indicate call source information.

D.7.1.4    Pass/Fail:

D.7.1.5    Results:

D.7.2    The system shall be able to create a call detail record to start storing detailed call information

D.7.2.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH), the Identify initial call type (CT-REGCT) procedure, and the Route call to PSAP procedure (CT-RTPSP).  The system will create a call detail record.  This call will be monitored from the test bed PSAP location.

D.7.2.2    Test Procedure:

1. Call initiated to test bed PSAP and passes to Call authentication procedure (CT-CAUTH) from Route Call to PSAP procedure (CT-RTPSP).
2. System reads call provider source from call stream and updates call detail record database.
3. System validates provider certificate against a database of provider certificates and updates call detail record database.
4. System updates system audit database with results of certificate query.
5. For a valid certificate, system generates acknowledgement message and routes call to PSAP.
6. For an invalid certificate, system generates a call refusal with an error message. Business rules database governs rules. System notifies caller of failed authentication. System terminates call.

D.7.2.3    Expected Results:

Call detail record database will be updated with provider source information from the call stream.

D.7.2.4    Pass/Fail:

D.7.2.5    Results:

D.7.3    The system shall write the certificate authentication details (successful and failed) to the call detail record 

(Use Case Not In POC Test)

D.7.3.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH), the Identify initial call type (CT-REGCT) procedure, and the Route call to PSAP procedure (CT-RTPSP).  The call detail record will be updated with authentication information. This call will be monitored from the test bed PSAP location.

D.7.3.2    Test Procedure:

1. Call initiated to test bed PSAP and passes to Call authentication procedure (CT-CAUTH) from Route Call to PSAP procedure (CT-RTPSP).
2. System reads call provider source from call stream and updates call detail record database.
3. System validates provider certificate against a database of provider certificates and updates call detail record database.
4. System updates system audit database with results of certificate query.
5. For a valid certificate, system generates acknowledgement message and routes call to PSAP.
6. For an invalid certificate, system generates a call refusal with an error message. Business rules database governs rules.  System notifies caller of failed authentication. System terminates call.

D.7.3.3    Expected Results:

The call detail record database will be updated with certificate authentication details and if the authentication was successful or failed.

D.7.3.4    Pass/Fail:

D.7.3.5    Results:

D.7.4    The system shall certify/authenticate that the originating provider or other responsible party has been granted permission to deliver calls 

(Use Case Not In POC Test)

D.7.4.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH), the Identify initial call type (CT-REGCT) procedure, and the Route call to PSAP procedure (CT-RTPSP).  The originating call will be authenticated.  This call will be monitored from the test bed PSAP location.

D.7.4.2    Test Procedure:

1. Call initiated to test bed PSAP and passes to Call authentication procedure (CT-CAUTH) from Route Call to PSAP procedure (CT-RTPSP).
2. System reads call provider source from call stream and updates call detail record database.
3. System validates provider certificate against a database of provider certificates and access control database. System updates call detail record database with validation results.
4. System updates system audit database with results of certificate query.
5. For a valid certificate, system routes call to PSAP.
6. For an invalid certificate, system generates a call refusal with an error message. Business rules database governs rule. System notifies caller of failed authentication. System terminates call.

D.7.4.3    Expected Results:

The call detail record database will be updated with the results from the validation of provider certificate against the database of provider certificates and the access control database.

D.7.4.4    Pass/Fail:

D.7.4.5    Results:

D.7.5    The system of authenticating provider certificates shall be deployed with strong authentication (RSA-1024 or better, as documented in RFC2313 [14]) using X.509 certificates and Certificate Revocation Lists as profiled in RFC 3280 [15] and best current practice (08-001) 

(Use Case Not In POC Test)

D.7.5.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH), the Identify initial call type (CT-REGCT) procedure, and the Route call to PSAP procedure (CT-RTPSP).  The authentications methods will be reviewed in the system This call will be monitored from the test bed PSAP location.

D.7.5.2    Test Procedure:

1. Call initiated to test bed PSAP and passes to Call authentication procedure (CT-CAUTH) from Route Call to PSAP procedure (CT-RTPSP).
2. System reads call provider source from call stream and updates call detail record database.
3. System validates provider certificate against a database of provider certificates and access control database. System updates call detail record database with validation results. Certificates comply with RSA-1024 or better, as documented in RFC2313 [14]) using X.509 certificates and Certificate Revocation Lists as profiled in RFC 3280 [15] and best current practice.
4.  System updates system audit database with results of certificate query.
5. For a valid certificate, system routes call to PSAP.
6. For an invalid certificate, system generates a call refusal with an error message. Business rules database govern rules. System notifies caller of failed authentication. System terminates call.

D.7.5.3    Expected Results:

The call detail record database will be updated with the results from the validation of provider certificate against the database of provider certificates and the access control database.  The certificates will be deployed with strong authentication (RSA-1024 or better, as documented I RFC2313[14]) using X.509 certificates and Certificate Revocation Lists as profiled in RFC 3280[15] and best current practices.

D.7.5.4    Pass/Fail:

D.7.5.5    Results:

D.7.6    The system shall not accept un-certified or un-authenticated calls (beyond this initial step)

(Use Case Not In POC Test)

D.7.6.1    Test Description:

An un-certified call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH), the Identify initial call type (CT-REGCT) procedure, and the Route call to PSAP procedure (CT-RTPSP). Test will be repeated with an un-authenticated call.  These calls will be monitored from the test bed PSAP location.

D.7.6.2    Test Procedure:

1. Un-certified call initiated to test bed PSAP and passes to Call Authentication procedure (CT-CAUTH) from Route Call to PSAP procedure (CT-RTPSP).
2. System reads call provider source from call stream and updates call detail record database.
3. System validates provider certificate against a database of provider certificates and access control database. System updates call detail record database with validation results.
4. System updates system audit database with results of certificate query.
5. For a valid certificate, system routes call to PSAP.
6. For an invalid certificate, system generates a call refusal with an error message. Business rules database governs rules.  System notifies caller of failed authentication. System terminates call.
7. Test repeats with an un-authenticated call.

D.7.6.3    Expected Results:

An un-certified call or un-authenticated call will generate a call refusal with an error message. Caller will be notified of failed authentication.  Rules will be governed by the business rules database.  Call will be terminated. This occurs in the initial step of the Call Authentication [CT-CAUTH] procedure.

D.7.6.4    Pass/Fail:

D.7.6.5    Results:

D.7.7    The system shall generate a call refusal or error message for the user (e.g., voice recording) if the call is not successfully authenticated

(Use Case Not In POC Test)

D.7.7.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH), the Identify initial call type (CT-REGCT) procedure, and the Route call to PSAP procedure (CT-RTPSP). This will be a call that cannot be authenticated.  This call will be monitored from the test bed PSAP location.

D.7.7.2    Test Procedure:

1. Call initiated to test bed PSAP and passes to the Call authentication procedure (CT-CAUTH) from Route Call to PSAP procedure (CT-RTPSP). Call is one that cannot be authenticated.
2. System reads call provider source from call stream and updates call detail record database.
3. System validates provider certificate against a database of provider certificates and access control database. System updates call detail record database with validation results.
4. System updates system audit database with results of certificate query. Call is not authenticated.
5. System generates a call refusal with an error message. System notifies caller of failed authentication. Business rules database governs rules. System terminates call.

D.7.7.3    Expected Results:

An un-authenticated call will generate a call refusal with an error message (e.g., voice recording). Caller will be notified of failed authentication.  Rules will be governed by the business rules database.  Call will be terminated.

D.7.7.4    Pass/Fail:

D.7.7.5    Results:

D.7.8    The system shall generate a notice when the call is successfully authenticated

(Use Case Not In POC Test)

D.7.8.1    Test Description:

A call will be initiated to the test bed PSAP and pass the steps defined in the Recognize Originating Location procedures (CT-CAUTH), the Identify initial call type (CT-REGCT) procedure, and the Route call to PSAP procedure (CT-RTPSP).  The system will generate a notice the call has been authenticated.  This call will be monitored from the test bed PSAP location.

D.7.8.2    Test Procedure:

1. Call initiated to test bed PSAP and passes to Call authentication procedure (CT-CAUTH) from Route Call to PSAP procedure (CT-RTPSP).
2. System reads call provider source from call stream and updates call detail record database.
3. System validates provider certificate against a database of provider certificates and access control database. System updates call detail record database with validation results.
4. System updates system audit database with results of certificate query.
5. A valid certificate will generate acknowledgement message and notify caller of successful authentication.
6. System routes call to PSAP.

D.7.8.3    Expected Results:

The call detail record database will be updated with the results from the validation of provider certificate against the database of provider certificates and the access control database. System audit database will be updated with database query results.

D.7.8.4    Pass/Fail:

D.7.8.5    Results:

D.8    Answer Call [CA-ANSCL]

This activity allows a call taker to respond to an audible or visual indication of an incoming call by depressing a key (or its functional equivalent), picking up a handset, or tapping an answer graphic on a touch screen. A circuit is completed between the caller and the call taker.  The call taker greets the caller, usually with a standard query, e.g., "9-1-1, where is your emergency?" or "9-1-1, what is your emergency?"

D.8.1    The system shall provide the capability to answer an incoming call

D.8.1.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the PSAP location.

D.8.1.2    Test Procedure:

1. Call initiated to test bed PSAP from any device.
2. System displays a visual and audible alert at tester’s workstation.
3. Tester activates a button to accept call.
4. Tester receives call.
5. Test repeats with call initiated from a cellular telephone, a landline telephone, and a VoIP telephone.

D.8.1.3    Expected Results:

The tester will be able to manually answer a call and communicate with the caller.

D.8.1.4    Pass/Fail:

D.8.1.5    Results:

D.8.2    The system shall be configurable to automatically answer the call for the call taker

D.8.2.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the PSAP location.

D.8.2.2    Test Procedure:

1. Tester (or supervisor) sets his/her workstation to automatically answer calls.
2. Call initiated to test bed PSAP (any device).
3. System displays a visual and audible alert at tester’s workstation.
4. Workstation answers call.
5. Tester communicates with caller.

D.8.2.3    Expected Results:

Calls will be answered automatically at the tester’s workstation.

D.8.2.4    Pass/Fail:

D.8.2.5    Results:

D.8.3    The system shall provide the capability for a call taker to select a call from a call queue

(Use Case Not In POC Test)

D.8.3.1    Test Description:

Several calls will be initiated to the test bed PSAP.  These calls will be monitored from the PSAP location.

D.8.3.2    Test Procedure:

1. Several calls initiated to test bed PSAP (any device).
2. System displays a visual and audible alert at tester’s workstation.
3. Tester opens or views pending queue.
4. Calls appear in pending queue.
5. Tester selects a call from queue.
6. Tester communicates with caller.

D.8.3.3    Expected Results:

The tester will be able to select a call and have two-way communications with a caller from the pending queue.

D.8.3.4    Pass/Fail:

D.8.3.5    Results:

D.8.4    The system shall permit an authorized call taker to select any pending call from the queue

(Use Case Not In POC Test)

D.8.4.1    Test Description:

Several calls will be initiated to the test bed PSAP.  These calls will be monitored from the PSAP location.

D.8.4.2    Test Procedure:

1. Several calls initiated to test bed PSAP (any device).
2. System displays a visual and audible alert at tester’s workstation.
3. Tester opens or views pending queue.
4. Calls appear in pending queue.
5. Tester selects a call from queue.
6. Tester communicates with caller.
7. Test repeats with tester selecting a different call from the queue.

D.8.4.3    Expected Results:

The tester will be able to select a call and have two-way communications with a caller from the pending queue.

D.8.4.4    Pass/Fail:

D.8.4.5    Results:

D.8.5    The system shall record when a call taker has selected a call and overridden ACD rules

(Use Case Not In POC Test)

D.8.5.1    Test Description:

Several calls will be initiated to the test bed PSAP.  These calls will be monitored from the PSAP location.

D.8.5.2    Test Procedure:

1. Tester selects a specific ACD category.
2. Several calls initiated to test bed PSAP (any device).  These calls are from within and outside tester’s ACD category.
3. System displays a visual and audible alert at tester’s workstation.
4. Tester views queue.
5. Tester selects call outside of his/her ACD category.
6. Tester examines call record after call.

D.8.5.3    Expected Results:

All calls will be routed to the PSAP, but only the calls from the proper ACD category will be delivered to the tester and alert at the workstation.  The calltaker will be able to open the pending call queue to see the other calls pending even those not assigned to alert the calltaker’s workstation.  The call record will show that the tester selected the call and that this was not next in line with the ACD rules.

D.8.5.4    Pass/Fail:

D.8.5.5    Results:

D.8.6    The system shall provide the capability to place a call on hold

D.8.6.1    Test Description:

Two calls will be initiated to the test bed PSAP.  These calls will be monitored from the PSAP location.

D.8.6.2    Test Procedure:

1. Two calls initiated to test bed PSAP (any device).
2. System displays a visual and audible alert at tester’s workstation.
3. Tester answers a call.
4. Tester places call on hold.
5. Tester takes second call.

D.8.6.3    Expected Results:

The tester will place the first call on hold and answer the second call.

D.8.6.4    Pass/Fail:

D.8.6.5    Results:

D.8.7    The system shall record the time a call is placed on hold

D.8.7.1    Test Description:

A call will be initiated to the test bed PSAP.  This call will be monitored from the PSAP location.

D.8.7.2    Test Procedure:

1. Call initiated to test bed PSAP (any device).
2. System displays a visual and audible alert at the tester’s workstation.
3. Tester answers the call.
4. Tester places call on hold.
5. Tester examines call record.

D.8.7.3    Expected Results:

Tester will see the time the call was placed on hold displayed in the call record.

D.8.7.4    Pass/Fail:

D.8.7.5    Results:

D.8.8    The system shall provide the capability to take a call off hold

D.8.8.1    Test Description:

A call will be initiated to the test bed PSAP for the tester to receive and place on hold.  This call will be monitored from the PSAP location.

D.8.8.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays a visual and audible alert at tester’s workstation.
3. Tester answers call.
4. Tester places call on hold.
5. Tester selects a second call to answer.
6. Tester releases the second call.
7. Tester selects call on hold.
8. Tester communicates with the caller.

D.8.8.3    Expected Results:

Tester will be able to take a call off hold and communicate.

D.8.8.4    Pass/Fail:

D.8.8.5    Results:

D.8.9    The system shall record the time a call taken off hold

D.8.9.1    Test Description:

A call will be initiated to the test bed PSAP for the tester to receive and place on hold.  This call will be monitored from the PSAP location.

D.8.9.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays a visual and audible alert at tester’s workstation.
3. Tester answers call.
4. Tester places call on hold.
5. Tester selects call on hold.
6. Tester communicates with caller.
7. Tester examines call record.

D.8.9.3    Expected Results:

Tester will see the time the call was taken off hold in the call record.

D.8.9.4    .Pass/Fail:

D.8.9.5    Results:

D.8.10    The system shall re-read and redisplay the call detail record each and every time a call is taken off hold

D.8.10.1    Test Description:

A call will be initiated to the test bed PSAP for the tester to receive and place on hold.  The tester will take the call off hold and view the call record.  This call will be monitored from the PSAP location.

D.8.10.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays a visual and audible alert at the tester’s workstation.
3. Tester answers call.
4. Tester places call on hold.
5. Tester opens a previous call record
6. Tester selects call on hold.
7. Tester examines call record.

D.8.10.3    Expected Results:

The workstation will display the information on the call that is taken off hold.

D.8.10.4    Pass/Fail:

D.8.10.5    Results:

D.8.11    The system shall display a time on hold alert after TBD-01 seconds

D.8.11.1    Test Description:

A call will be initiated to the test bed PSAP for the tester to receive and place on hold.  The call will be placed on hold until the alert occurs.  This call will be monitored from the PSAP location.

D.8.11.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. System displays a visual and audible alert at tester’s workstation.
3. Tester answers call.
4. Tester places call on hold.
5. System sends an alert after time defined in system.
6. System records time on hold in call detail record.

D.8.11.3    Expected Results:

The alert will occur at the time defined in the system.

D.8.11.4    Pass/Fail:

D.8.11.5    Results:

D.8.12    The system shall be configurable to specify the elapsed time before the “time on hold” alert will be generated

D.8.12.1    Test Description:

An administrator will change the time on hold alert time. A call will be initiated to the test bed PSAP for the tester to receive and place on hold.  The call will be placed on hold until the alert occurs.  This call will be monitored from the PSAP location.

D.8.12.2    Test Procedure:

1. Administrator changes time on hold alert time in system.
2. Call initiated to test bed PSAP.
3. System displays a visual and audible alert at tester’s workstation.
4. Tester answers call.
5. Tester places call on hold.
6. System sends an alert after time defined in system.
7. System records time on hold in call detail record.

D.8.12.3    Expected Results:

The alert will occur at the new time defined in the system.

D.8.12.4    Pass/Fail:

D.8.12.5    Results:

D.8.13    The system shall be configurable to deliver an audible and/or visual alert when the “time on hold” alert has been generated

D.8.13.1    Test Description:

An administrator will change the alert type for a call on hold to visual only in the system. A call will be initiated to the test bed PSAP for the tester to receive and place on hold.  The call will be placed on hold until the alert displays.  This call will be monitored from the PSAP location.

D.8.13.2    Test Procedure:

1. Administrator changes alert type for a call on hold to visual only in system.
2. Call initiated to test bed PSAP.
3. System displays a visual and audible alert at tester’s workstation.
4. Tester answers call.
5. Tester places call on hold.
6. System sends a visual alert only after time defined in system.
7. System records time on hold in call detail record.

D.8.13.3    Expected Results:

The alert will be only visual and occur at the time defined in the system.

D.8.13.4    Pass/Fail:

D.8.13.5    Results:

D.8.14    The system shall display the default call handling procedure based upon Call Type upon call answer

D.8.14.1    Test Description:

A call will be initiated to the test bed PSAP for the tester to receive.  The tester will use the call handling procedures. This call will be monitored from the PSAP location.

D.8.14.2    Test Procedure:

1. Call initiated to test bed PSAP from any device.
2. Tester answers call.
3. Tester activates Call standard operating procedures (SOP).
4. Tester activates call script.
5. Tester changes the incident type.
6. Tester activates call SOPs.
7. Tester activates call scripts.

D.8.14.3    Expected Results:

The system will display the call SOPs and scripts for the call type displayed on the HMI screen.

D.8.14.4    Pass/Fail:

D.8.14.5    Results:

D.8.15    The system shall permit the Call Taker to indicate a status of “Not Ready” for the situation where the user is signed-on (but not available to answer queue calls)

D.8.15.1    Test Description:

A tester will change his/her status to “Not Ready,” and calls will be initiated to the test bed PSAP.  These calls will be monitored from the PSAP location.

D.8.15.2    Test Procedure:

1. Tester changes his/her status to “Not Ready” in the ACD fields.
2. Two calls initiated to test bed PSAP.
3. Calls do not alert the tester.
4. Tester views call queue.
5. Tester selects a call from call queue.

D.8.15.3    Expected Results:

Calls will not alert the calltaker’s workstation while the tester is in “Not Ready” status.  The tester will be able to select a call from the queue.

D.8.15.4    Pass/Fail:

D.8.15.5    Results:

D.9    Initiate Call Back [CA-INTCB]

The activity allows a call taker to attempt to reestablish contact with a caller who has been disconnected or has abandoned a call.  The call taker depresses a key on a keyboard or dial pad, or taps callback graphic on touch screen (or its functional equivalent). If a circuit is reestablished, the call taker proceeds to process the call in accordance with established standards and operational best practices; if a circuit cannot be reestablished, the call taker uses established standards and operational best practices to follow through.

D.9.1    The system shall provide the capability to reestablish call path to a telecommunications device

D.9.1.1    Test Description:

The tester will call back a caller who was disconnected.  This call will be monitored from the PSAP location.

D.9.1.2    Test Procedure:

1. Tester selects any previous call from call record.
2. Tester activates callback feature.
3. Tester communicates with caller.

D.9.1.3    Expected Results:

The tester will be able to re-connect to a caller and communicate.

D.9.1.4    Pass/Fail:

D.9.1.5    Results:

D.9.2    The system shall read the Call Stream to determine the supported call back communications method(s)

D.9.2.1    Test Description:

The tester will review the call record of a previous call to determine what call-back methods were captured.  This process will be monitored from the PSAP location.

D.9.2.2    Test Procedure:

1. Tester selects any previous call from call record.
2. Tester reviews call record to determine what call-back methods are available.

D.9.2.3    Expected Results:

The call-back methods for a call will be in the call record.

D.9.2.4    Pass/Fail:

D.9.2.5    Results:

D.9.3    The system shall provide the option to read from the call detail record DB to display any supportive or supplemental data that exists that provides additional call back methods

(Use Case Not In POC Test)

D.9.3.1    Test Description:

The tester will review the call record of a previous call to determine what additional call-back methods were captured. This process will be monitored from the PSAP location.

D.9.3.2    Test Procedure:

1. Tester selects any previous call from call record.
2. Tester reviews additional call data screen to see what call back methods are available.

D.9.3.3    Expected Results:

All call back methods will be listed the additional call data screen.

D.9.3.4    Pass/Fail:

D.9.3.5    Results:

D.9.4    The system shall display the supported call back communications methods to the call taker, when a call back has been requested

(Use Case Not In POC Test)

D.9.4.1    Test Description:

The tester will begin the call back of a call that had been disconnected.  This process will be monitored from the PSAP location.

D.9.4.2    Test Procedure:

1. Tester selects any previous call from call record.
2. Tester activates callback feature.
3. Tester views call back methods available in call detail record.

D.9.4.3    Expected Results:

All of the call-back methods will be displayed in the call detail record.

D.9.4.4    Pass/Fail:

D.9.4.5    Results:

D.9.5    The system shall permit the call taker to select from the supported communications methods when initiating a call back

(Use Case Not In POC Test)

D.9.5.1    Test Description:

The tester will call back a call that was disconnected.  This call will be monitored from the PSAP location.

D.9.5.2    Test Procedure:

1. Tester selects any previous call from call record.
2. Tester activates callback feature.
3. Tester views call back methods available in call detail record.
4. Tester selects a secondary method of call back.
5. Tester communicates with caller.

D.9.5.3    Expected Results:

The tester will be able to communicate with the caller when call back is to another method that is different than used to call originally.

D.9.5.4    Pass/Fail:

D.9.5.5    Results:

D.9.6    The system shall store the results of the call back attempt in the call detail record

(Use Case Not In POC Test)

D.9.6.1    Test Description:

After a call back is completed, the tester will review the call record. This process will be monitored from the PSAP location.

D.9.6.2    Test Procedure:

1. Tester releases previous call that had to be called back.
2. Tester opens call record.
3. Tester reviews call record.

D.9.6.3    Expected Results:

The call record will list the steps taken for the call-back process.

D.9.6.4    Pass/Fail:

D.9.6.5    Results:

D.9.7    The system shall provide the capability to establish a call path between a call taker and a telecommunications device if a call is abandoned before a call taker can answer the call

(Use Case Not In POC Test)

D.9.7.1    Test Description:

A call will be initiated to the test bed PSAP that is not answered, and the caller will abandon the call (hang up).  The tester will call back.  This call will be monitored from the PSAP location.

D.9.7.2    Test Procedure:

1. Call initiated to test bed PSAP.
2. Tester does not answer.
3. Caller releases call.
4. Tester activates callback feature.
5. Tester communicates with caller.

D.9.7.3    Expected Results:

The tester will be able to call back a caller who abandoned a call and communicate with that caller.

D.9.7.4    Pass/Fail:

D.9.7.5    Results:

D.10    Determine Nature of Emergency [CP-DTNAT]

This activity involves obtaining the necessary information to route the caller to the proper person or agency, or to dispatch the proper emergency response.  At the same time, the call taker screens out those calls that are not considered emergencies.  To do this, the call taker asks a series of questions that elicit the most information in the least amount of time.  Calls received are documented in the system and assigned to appropriate categories based on standards and policies (e.g., fire emergency, law enforcement emergency, medical emergency, non-emergency, prank).

D.10.1    The system shall provide the capability to document the nature of the emergency for each call

D.10.1.1    Test Description:

A call will be initiated to the test bed PSAP.  The tester will record the nature of the emergency in the call record.  This call will be monitored from the test bed PSAP location.

D.10.1.2    Test Procedure:

1. Call initiated to test bed PSAP using any device.
2. Tester receives call.
3. Tester reviews emergency type assigned by system, if available.
4. Tester enters a different emergency type into call record.
5. Tester terminates call.
6. Tester reviews call record.

D.10.1.3    Expected Results:

The tester will be able to see data from the system, enter new data, and view all data in the call record.

D.10.1.4    Pass/Fail:

D.10.1.5    Results:

D.10.2    The system shall provide the capability to document additional information for a call

D.10.2.1    Test Description:

A call will be initiated to the test bed PSAP.  The tester will enter additional information into the call record.  This call will be monitored from the test bed PSAP location.

D.10.2.2    Test Procedure:

1. Call initiated to test bed PSAP using any device.
2. Tester answers call.
3. Tester enters additional information in comments fields.
4. Tester adds a location to call record.
5. Tester terminates call.
6. Tester reviews call record.

D.10.2.3    Expected Results:

The tester will be able to enter data and view that data in the call record.

D.10.2.4    Pass/Fail:

D.10.2.5    Results:

D.10.3    The system shall provide the capability to aggregate call records

(Use Case Not In POC Test)

D.10.3.1    Test Description:

A call will be initiated to the test bed PSAP.  The tester will add information from this call to a previous call regarding the same incident. This call will be monitored from the test bed PSAP location.

D.10.3.2    Test Procedure:

1. Call initiated to test bed PSAP using any device.
2. Tester answers call.
3. Tester adds information to call record.
4. Tester terminates call
5. Second call initiated to the test bed PSAP.
6. Tester answers call.
7. Tester adds information to call record.
8. Tester terminates call.
9. Tester adds current record information to call record of first call regarding this incident.
10. Tester views call record of first and second calls.

D.10.3.3    Expected Results:

Tester will be able to attach the call data from the second call to the first call and view it in the call records.

D.10.3.4    Pass/Fail:

D.10.3.5    Results:

D.10.4    The system shall provide the capability to update the nature of the emergency

D.10.4.1    Test Description:

A call will be initiated to the test bed PSAP.  The tester will change the nature of the emergency in the call record and add a secondary emergency type. This call will be monitored from the test bed PSAP location.

D.10.4.2    Test Procedure:

1. Call initiated to test bed PSAP using any device.
2. Tester receives call.
3. Tester reviews emergency type assigned by system, if available.
4. Tester enters a different emergency type in call record.
5. Tester changes secondary emergency type.
6. Tester terminates call.
7. Tester reviews call record.

D.10.4.3    Expected Results:

The tester will be able to see data from the system, enter new data, and view all data in the call record.

D.10.4.4    Pass/Fail:

D.10.4.5    Results:

D.10.5    The system shall display call handling procedures to a call taker

D.10.5.1    Test Description:

A call will be initiated to the test bed PSAP using any device.  The tester will open the call SOPs and call scripts during the call to gather data. This call will be monitored from the test bed PSAP location.

D.10.5.2    Test Procedure:

1. Call initiated to test bed PSAP using any device.
2. Tester receives call.
3. Tester opens Call SOP screen.
4. Tester opens Call Scripts screen.
5. Tester enters information in Call Scripts screen into the call record.
6. Tester terminates call.
7. Tester reviews call record.

D.10.5.3    Expected Results:

Call SOPs and Call Scripts will be available to the tester.  All information from the Call Scripts screen will be shown in the call record.

D.10.5.4    Pass/Fail:

D.10.5.5    Results:

D.10.6    The system shall provide the capability to read call records

D.10.6.1    Test Description:

The tester will attempt to open three call records to view the data. This process will be monitored from the test bed PSAP location.

D.10.6.2    Test Procedure:

1. Tester opens call record of previous call.
2. Tester opens a call from a previous day or time (if available).
3. Tester searches for calls from another PSAP.

D.10.6.3    Expected Results:

The tester will be able to view the call records from his/her PSAP but not from the other PSAP.

D.10.6.4    Pass/Fail:

D.10.6.5    Results:

D.11    Determine and Verify Location of Emergency [CP-VFLOC]

The call taker uses established standards and operational best practices to query caller about the location of the emergency.  Once a call taker has answered an incoming call, the call taker is presented with initial call information.  The call taker proceeds to verify the information presented and determine the location of the emergency.  Included in this activity is the verification of ALI information presented to the call taker.  A call taker will be able to identify incorrect ALI information for an update or change request.

D.11.1    The system shall provide the call taker with a capability to document the location of the emergency

D.11.1.1    Test Description:

A call will be initiated to the test bed PSAP (any device).  While on this active call, the tester will enter a location in the call record. This call will be monitored from the test bed PSAP location.

D.11.1.2    Test Procedure:

1. Call initiated to test bed PSAP from any device.
2. Tester answers call.
3. Tester enters a location in record (other than that provided to tester by system).
4. Tester terminates call.
5. Tester views call record.

D.11.1.3    Expected Results:

The tester will be able to enter a location into the call record and view it in the call record after the call.

D.11.1.4    Pass/Fail:

D.11.1.5    Results:

D.11.2    The system shall write the caller location to the call stream and call detail record as the emergency location when the call taker accepts caller location as the emergency location

D.11.2.1    Test Description:

A call will be initiated to test bed PSAP.  The tester will verify the location provided by the system for the caller location is the location of the emergency. This call will be monitored from the test bed PSAP location.

D.11.2.2    Test Procedure:

1. Call initiated to test bed PSAP from any device.
2. Tester answers call.
3. Tester verifies with caller that location provided by system as caller’s location is location of the emergency.

D.11.2.3    Expected Results:

The call location provided to the tester will be the same as the device location.

D.11.2.4    Pass/Fail:

D.11.2.5    Results:

D.11.3    The system shall provide the capability for the call taker to search for the emergency location using a) geo-coordinates, b) civic address location, c) by clicking a location on an interactive map

D.11.3.1    Test Description:

A tester will enter various location types and view the map to determine whether they provide appropriate locations. The tester will select a location on the map and view the HMI locations fields to determine whether the fields reflect the location selected. This process will be monitored from the test bed PSAP location.

D.11.3.2    Test Procedure:

1. Tester enters a civic address into HMI.
2. Tester views map.
3. Tester enters geo-coordinates.
4. Tester views map.
5. Tester selects a location on map.
6. Tester views HMI location fields.

D.11.3.3    Expected Results:

The locations entered into the HMI will appear on the map in the correct location, and the location information associated with the click on the map will appear on the HMI with correct information.  For the POC the interaction from the map to the HMI software is not supported.  Addresses and locations provided by the system or calltaker will be displayed on the map.

D.11.3.4    Pass/Fail:

D.11.3.5    Results:

D.11.4    The system shall validate all locations entered by the call taker against a GIS database

(Use Case Not In POC Test)

D.11.4.1    Test Description:

The tester will enter several locations in and outside the area.  The system will validate these locations. This process will be monitored from the test bed PSAP location.

D.11.4.2    Test Procedure:

1. Tester enters an address within tester’s jurisdiction.
2. Tester enters an address outside tester’s jurisdiction.
3. Tester enters geo-coordinates within tester’s jurisdiction.
4. Tester enters geo-coordinates outside tester’s jurisdiction.
5. Tester enters a location within jurisdiction of another test PSAP.

D.11.4.3    Expected Results:

The system will properly validate locations within the jurisdiction.  System will not validate locations outside the jurisdiction.  Validation is defined as providing appropriate response agency recommendations.

D.11.4.4    Pass/Fail:

D.11.4.5    Results:

D.11.5    The system shall display caller location to the call taker

D.11.5.1    Test Description:

A call will be initiated to the test bed PSAP.  The tester will review the location information provided.  This call will be monitored from the test bed PSAP location.

D.11.5.2    Test Procedure:

1. Call initiated to test bed PSAP from any device.
2. Tester answers call.
3. Tester verifies with caller location provided by system.
4. Tester selects “additional addresses” button.
5. Tester looks to see whether additional locations provided.
6. Tester verifies additional locations with caller.

D.11.5.3    Expected Results:

The system-provided locations will be displayed to the tester.

D.11.5.4    Pass/Fail:

D.11.5.5    Results:

D.11.6    The system shall provide the capability to customize the display rules for caller location

(Use Case Not In POC Test)

D.11.6.1    Test Description:

An administrator will change the settings for the display of locations.  A call will be initiated to the test bed PSAP to verify that the change took place.  This process will be monitored from the test bed PSAP location.

D.11.6.2    Test Procedure:

1. Call initiated to test bed PSAP from any device.
2. Tester answers call.
3. Tester verifies with caller location provided by system.
4. Administrator changes location display settings.
5. A second call initiated from public side of network using any device.
6. Tester answers call.
7. Tester verifies with caller location provided by the system.

D.11.6.3    Expected Results:

The changes made by the administrator between the calls will be applied to the tester’s display for the second call.

D.11.6.4    Pass/Fail:

D.11.6.5    Results:

D.11.7    The system shall display caller location based upon display rules

(Use Case Not In POC Test)

D.11.7.1    Test Description:

A call will be initiated to the test bed PSAP from a device with multiple locations associated with it.  The tester will view the location provided by the system to verify that the displays rules were followed.  This call will be monitored from the test bed PSAP location.

D.11.7.2    Test Procedure:

1. Call initiated to test bed PSAP from any device with multiple locations associated with it.
2. Tester answers call.
3. Tester verifies location provided is correct according to display rules.

D.11.7.3    Expected Results:

The system will follow the display rules correctly.

D.11.7.4    Pass/Fail:

D.11.7.5    Results:

D.11.8    The system shall convert caller location from geo-coordinates to civic address

(Use Case Not In POC Test)

D.11.8.1    Test Description:

A call to the test bed PSAP will be initiated from a geo-coordinate device. The tester will review the locations provided by the system. This call will be monitored from the test bed PSAP location.

D.11.8.2    Test Procedure:

1. Call initiated to test bed PSAP from any device with geo-coordinate location associated with it.
2. Tester answers call.
3. Tester verifies with caller that location provided by system is correct.
4. Tester selects “Additional Addresses” button.
5. Tester reviews civic address.

D.11.8.3    Expected Results:

The geo-coordinate location is properly displayed as a civic address.

D.11.8.4    Pass/Fail:

D.11.8.5    Results:

D.11.9    The system shall convert caller location from civic address to geo-coordinates

(Use Case Not In POC Test)

D.11.9.1    Test Description:

A call to the test bed PSAP from a civic-addressed device will be initiated, and the locations provided by the system will be reviewed.  This call will be monitored from the test bed PSAP location.

D.11.9.2    Test Procedure:

1. Call initiated to test bed PSAP from any device with civic address location associated with it.
2. Tester answers call.
3. Tester verifies with caller that location provided by system is correct.
4. Tester selects “Additional Addresses” button.
5. Tester reviews geo-coordinate location.

D.11.9.3    Expected Results:

The civic address is properly displayed as a geo-coordinate location.

D.11.9.4    Pass/Fail:

D.11.9.5    Results:

D.12    Update Mobile Caller's Location Information [CP-UCLOC]

The call taker uses the customer-premises equipment (CPE) software application function in concert with the 9-1-1 network to obtain more accurate location information or to monitor changes in caller's location.

D.12.1    The system shall provide the capability to automatically update the caller location

D.12.1.1    Test Description:

The (one-time) automatic location update option will be set in the system. A mobile call will be initiated to the test bed PSAP.  After the tester answers the call and receives the initial caller location, which may be phase I (cell site/face) information, the system will initiate a second location query. A phase II location will be received, and the displayed location will be automatically updated.  This call will be monitored from the test bed PSAP location.

D.12.1.2    Test Procedure:

1. Call initiated to test bed PSAP from a mobile device.
2. Tester accepts call.
3. Initial caller location provided (possibly phase I information).
4. System queries and receives location update.
5. System provides updated location to PSAP/tester equipment.
6. Tester receives visual indicator of updated location.
7. Tester activates update location display function on workstation.
8. Updated caller location displays.

D.12.1.3    Expected Results:

The system will automatically update caller location.

D.12.1.4    Pass/Fail:

D.12.1.5    Results:

D.12.2    An automatic update shall only be performed once, unless otherwise specified in the business rules

(Use Case Not In POC Test)

D.12.2.1    Test Description:

Business rules will be established for two automatic updates.  A mobile call will be initiated to the test bed PSAP. After the tester answers the call and receives the initial caller location, which may be phase I (cell site/face) information, the system will initiate a location query. A phase II location will be received, and the original location will be automatically updated after being authorized by the tester.  After TBD seconds (mobile provider dependent), the system will initiate a second updated location query. When the upd ated location is received, the tester will receive an updated location visual indicator and once activated, the PSAP/tester screen location will be updated.  This call will be monitored from the test bed PSAP location.

D.12.2.2    Test Procedure:

1. Call initiated to test bed PSAP from a mobile device.
2. Tester accepts call.
3. Initial caller location provided (possibly phase I information).
4. System queries and receives location update.
5. System provides updated location to PSAP/tester equipment.
6. Tester receives visual indicator of updated location on workstation.
7. Tester activates location update display function.
8. Updated caller location displays.
9. System queries and receives second location update.
10. System provides updated location to PSAP/tester equipment.
11. Tester receives visual indicator of updated location on workstation.
12. Tester activates location update display function.
13. Updated caller location displays.

D.12.2.3    Expected Results:

The system will seek and receive two location updates as provided in business rules, provide an indicator of their availability to the tester, and when prompted by the tester, display the updated location information on the tester’s workstation.

D.12.2.4    Pass/Fail:

D.12.2.5    Results:

D.12.3    The system shall provide the capability for a call taker to manually initiate a location update

D.12.3.1    Test Description:

A mobile call will be initiated to the test bed PSAP.  After the tester answers the call and initial caller location is received, which may be phase I (cell site/face) information, the tester will initiate a location update query.  When updated location is received, the tester will receive an updated location visual indicator and once activated, the PSAP/tester screen location will be updated.  This call will be monitored from the test bed PSAP location.

D.12.3.2    Test Procedure:

1. Call initiated to test bed PSAP from a mobile device.
2. Tester accepts call.
3. Initial caller location is provided (possibly phase I information).
4. Tester queries system for updated location information via tester workstation option.
5. System provides updated location to PSAP/tester equipment.
6. Tester receives visual indicator of updated location.
7. Tester activates location update display function.
8. Updated caller location displays.

D.12.3.3    Expected Results:

The system will seek and receive a location update after receiving an updated location query activated by the tester, provide an indicator of its availability to the tester and when prompted by the tester, display the updated location information on the tester workstation.

D.12.3.4    Pass/Fail:

D.12.3.5    Results:

D.12.4    The system shall provide the capability for the call taker to manually initiate continuous location updates, at provider-defined update intervals

(Use Case Not In POC Test)

D.12.4.1    Test Description:

After provider-defined update intervals are set in the system, a mobile call will be initiated to the test bed PSAP.  After the tester answers the call and receives initial caller location, which may be phase I (cell site/face) information, the tester will initiate a location update query.  When updated location is received, the tester will receive an updated location visual indicator and once activated, the PSAP/tester screen location will be updated.  This call will be monitored from the test bed PSAP location.

D.12.4.2    Test Procedure:

1. Provider-defined update interval set in system.
2. Call initiated to test bed PSAP from a mobile device.
3. Tester accepts call.
4. Initial caller location is provided (possibly phase I information).
5. Tester queries system for updated location information via tester workstation option.
6. System queries provider for updated location after provider-defined interval is met.
7. System provides updated location to PSAP/tester equipment.
8. Tester receives visual indicator of updated location.
9. Tester activates location update display function.
10. Updated caller location displays.
11. Tester checks call record to ensure provider-defined update interval is used for system’s location query to provider.

D.12.4.3    Expected Results:

The system will seek a provider-defined update interval after receiving an updated location query activated by the tester, provide an indicator of its availability to tester when received and when prompted by tester, and display the updated location information on the tester workstation.

D.12.4.4    Pass/Fail:

D.12.4.5    Results:

D.12.5    The system shall provide the capability to activate the automatic location update function on a call-by-call basis

(Use Case Not In POC Test)

D.12.5.1    Test Description:

After provider-defined update intervals are set in the system, a mobile call will be initiated to the test bed PSAP.  After the tester answers the call and receives initial caller location, which may be phase I (cell site/face) information, the tester will initiate an automatic location update query. When updated location is received, the tester will receive an updated location visual indicator and once activated, the PSAP/tester screen location will be updated.  This query and update process will be repeated continuously at provider-defined update intervals until the automatic location update query is de-activated by the tester for the call. This call will be monitored from the test bed PSAP location.

D.12.5.2    Test Procedure:

1. Provider-defined update interval set in system.
2. Call initiated to test bed PSAP from a mobile device.
3. Tester accepts call.
4. Initial caller location is provided (possibly phase I information)
5. Tester activates automatic location update function via tester workstation option.
6. System queries provider for updated location after provider-defined interval is met.
7. System provides updated location to PSAP/tester equipment.
8. Tester receives visual indicator of updated location.
9. Tester activates location update display function.
10. Updated caller location displays.
11. Steps 6–10 repeat continuously until tester de-activates automatic location update function via tester workstation option.
12. Tester checks call record to ensure provider-defined update intervals have been used for system’s location queries to provider.

D.12.5.3    Expected Results:

The system will successfully seek a provider-defined update interval for location updates after receiving an automatic location update function activation by the tester, provide an indicator of updated location availability to the tester when received, and when prompted by the tester, display the updated location information on the tester workstation.  This will occur automatically until the automatic location update function is de-activated by the tester.

D.12.5.4    Pass/Fail:

D.12.5.5    Results:

D.12.6    The system shall archive automatic location updates as part of the Call Record

D.12.6.1    Test Description:

The tester will check the call record for Section D.12.5 test to verify that the automatic location updates have been archived as part of the call record.  This process will be monitored from the test bed PSAP location.

D.12.6.2    Test Procedure:

1. Tester views call record of Section D.12.5 test via workstation display option.
2. Tester verifies that all automatic location updates for that test are included in call record.

D.12.6.3    Expected Results:

The system will successfully archive automatic location updates as part of the call record and will display them as part of the call record.

D.12.6.4    Pass/Fail:

D.12.6.5    Results:

D.12.7    The system shall provide the capability to automatically update the caller location

D.12.7.1    Test Description:

The (one-time) automatic location update option will be set in the system. A mobile call will be initiated to the test bed PSAP.  After the tester answers the call and receives initial caller location, which may be phase I (cell site/face) information, the system will initiate a second location query. A phase II location will be received.  The location will be automatically updated on the PSAP/tester screen after tester activation.  This call will be monitored from the test bed PSAP location.

D.12.7.2    Test Procedure:

1. Call initiated to test bed PSAP from a mobile device.
2. Tester accepts call.
3. Initial caller location is provided (possibly phase I information).
4. System queries and receives location update.
5. System provides updated location to PSAP/tester equipment.
6. Tester receives visual indicator of updated location.
7. Tester activates update location display function on workstation.
8. Updated caller location displays.

D.12.7.3    Expected Results:

The system will automatically update caller location.

D.12.7.4    Pass/Fail:

D.12.7.5    Results:

D.12.8    The system shall archive manual continuous location updates as a part of the Call Record so the entire location history can be reconstructed

D.12.8.1    Test Description:

A mobile call will be initiated to the test bed PSAP.  After the tester answers the call and receives initial caller location, which may be phase I (cell site/face) information, the tester will initiate manual location update queries. The tester will receive updated locations, and the PSAP/tester screen location will be automatically updated after activation by the tester for each.  The tester will review the call record for its inclusion of all manual location updates. This call will be monitored from the test bed PSAP location.

D.12.8.2    Test Procedure:

1. Call initiated to test bed PSAP from a mobile device.
2. Tester accepts call.
3. Initial caller location is provided (possibly phase I information)
4. Tester manually queries system for updated location information via tester workstation option.
5. System provides updated location to PSAP/tester equipment.
6. Tester receives visual indicator of updated location.
7. Tester activates location update display function.
8. Updated caller location displays.
9. Tester repeats steps 4–8 two more times.
10. Tester checks call record to verify that three location updates sought and received are included.

D.12.8.3    Expected Results:

The system stores, as part of the call record, all manual location updates sought and received by the tester.

D.12.8.4    Pass/Fail:

D.12.8.5    Results:

D.12.9    The system shall support the following representations of location information for a mobile device: a) latitude, b) longitude, c) altitude, and d) floor designation

D.12.9.1    Test Description:

A mobile call will be initiated to the test bed PSAP.  After the tester answers the call and receives initial caller location, which may be phase I (cell site/face) information, the system will initiate a second location query.  A phase II location will be received, and the original location will be automatically updated.  Both received locations (first and update) will be checked to verify that they include fields for latitude, longitude, altitude, and floor designation.  Those fields, where applicable, will be checked to verify that they include correctly formatted information.  This call will be monitored from the test bed PSAP location.

D.12.9.2    Test Procedure:

1. A phase I cell site/face location record created with inclusion of fields for its latitude, longitude, altitude, and floor designation.
2. Correctly formatted data entered into those four fields as part of record.
3. Call initiated to test bed PSAP from a mobile device.
4. Tester accepts call.
5. Initial caller location provided (phase I information).
6. Four fields (latitude, longitude, altitude, and floor designation) checked to verify that their data is correctly formatted as displayed.
7. Tester seeks location update via manual location option on workstation.
8. System queries and receives location update.
9. System provides updated location to PSAP/tester equipment.
10. Tester advised via workstation visual indicator that updated location is available.
11. Tester activates update caller location display function on workstation.
12. Updated caller location displays.
13. Four fields (latitude, longitude, altitude, and floor designation) checked to verify that their data is correctly formatted as displayed, where available.  Currently, only latitude and longitude are sent as part of caller location by provider—the other two fields should be blank for this update.
14. Tester checks call record data to ensure that four fields are correctly displayed with proper formatted data where available for first location provided and updated location provided.

D.12.9.3    Expected Results:

The system will successfully support representations of location information for a mobile device for four fields: a) latitude, b) longitude, c) altitude, and d) floor designation. That information will be correctly stored as part of call record and correctly displayed on the tester’s workstation during call processing.  ( The POC does not support c) altitude, and d) floor designation.)

D.12.9.4    Pass/Fail:

D.12.9.5    Results:

D.12.10    The system shall provide the capability to display update request results on a map

D.12.10.1    Test Description:

A mobile call will be initiated to the test bed PSAP.  The system will send the initial location to the map display program for display.  When the system receives the updated location, it will also be sent to the map display program for it to update the display of the call’s location.  This call will be monitored from the test bed PSAP location.

D.12.10.2    Test Procedure:

1. Call initiated to test bed PSAP from a mobile device.
2. System sends initial location received from provider to appropriate map program system where call is displayed.
3. Tester accepts call.
4. Tester queries system for updated location information via workstation option.
5. System queries and receives location update.
6. System sends updated location received from provider to appropriate map program system where call’s updated location replaces initial location display.
7. System provides updated location to PSAP/tester equipment.
8. Tester receives updated caller location.
9. Tester checks call record location data (first and update) against map program system data to ensure both were successfully received and correctly displayed.

D.12.10.3    Expected Results:

The system will provide updated location information to map system program.

D.12.10.4    Pass/Fail:

D.12.10.5    Results:

D.12.11    The system shall notify the call taker before displaying automatic rebid requests

(Use Case Not In POC Test)

D.12.11.1    Test Description:

The (one-time) automatic location update option will be set in the system. A mobile call will be initiated to the test bed PSAP.  After the tester answers the call and receives the initial caller location, which may be phase I (cell site/face) information, the system will initiate a second location query. A phase II location will be received.  The location will be automatically updated after tester activation.  This call will be monitored from the test bed PSAP location.

D.12.11.2    Test Procedure:

1. Call initiated to test bed PSAP from a mobile device.
2. Tester accepts call.
3. Initial caller location is provided (possibly phase I information).
4. System queries and receives location update.
5. System provides updated location to PSAP/tester equipment.
6. Tester received visual indicator of updated location.
7. Tester activates update location display function on workstation.
8. Updated caller location displays.

D.12.11.3    Expected Results:

The system will provide a tester with a visual indicator and seek tester input prior to displaying updated location.

D.12.11.4    Pass/Fail:

D.12.11.5    Results:

D.12.12    The system shall request updated caller location from a mobile call service provider at least every TBD-02 seconds

(Use Case Not In POC Test)

D.12.12.1    Test Description:

After provider-defined update intervals (TBD seconds) are set in the system, a mobile call will be initiated to the test bed PSAP. After the tester answers the call and receives initial caller location, which may be phase I (cell site/face) information, the tester will initiate an automatic location update query. When the updated location is received, the tester will receive an updated location visual indicator and once activated, the PSAP/tester screen location will be updated.  This query and update process will be repeated continuously at provider-defined update intervals until the automatic location update query is de-activated by the tester for the call. This call will be monitored from the test bed PSAP location.

D.12.12.2    Test Procedure:

1. Provider-defined update interval (TBD seconds) set in system.
2. Call initiated to test bed PSAP from a mobile device.
3. Tester accepts call.
4. Initial caller location is provided (possibly phase I information)
5. Tester activates automatic update location function via tester workstation option.
6. System queries provider for updated location after provider-defined interval (TBD seconds) is met.
7. System provides updated location to PSAP/tester equipment.
8. Tester receives visual indicator of updated location.
9. Tester activates location update display function.
10. Updated caller location displays.
11. Steps 6–11 repeat continuously until tester de-activates automatic update location function for call.
12. Tester checks call record to ensure provider-defined update interval (TBD seconds) is used for the system’s location query to the provider.

D.12.12.3    Expected Results:

The system will successfully seek a provider-defined update interval (TBD seconds) for location updates after receiving an automatic location update function activation by the tester.

D.12.12.4    Pass/Fail:

D.12.12.5    Results:

D.13    Establish Conference Call [CP-ECONF]

The call taker initiates a call transfer or conference session. The call taker stays on the line to ensure caller and dispatcher establish communication. The call taker informs the dispatcher of the need to mobilize responders. This activity enables the call taker to establish conference sessions with other entities as required.  PSAP call taker stays on the line with the caller and dispatcher to assist the caller and provide updated information to the dispatcher.

D.13.1    The system shall provide the capability to establish a call path to one or more telecommunication devices

D.13.1.1    Test Description:

Voice, video, and text messaging outbound calls to numbers outside the system will be initiated and verified.  These calls will be monitored from the test bed PSAP location.

D.13.1.2    Test Procedure:

1. Tester places a voice call to an entity/number outside system and verifies that connection is established.
2. Tester places a video call an entity/number outside system and verifies that connection is established.
3. Tester places an interactive text messaging call to an entity/number outside system and verifies that connection is established.

D.13.1.3    Expected Results:

The system successfully establishes the appropriate call paths.

D.13.1.4    Pass/Fail:

D.13.1.5    Results:

D.13.2    The system shall provide the capability to store frequently used conference call participant numbers

(Use Case Not In POC Test)

D.13.2.1        Test Description:

Telecommunication numbers will be stored in the system via the tester screen and keyboard/mouse in the conference call category. This process will be monitored from the test bed PSAP location.

D.13.2.2    Test Procedure:

1. Tester enters a telecommunication number and appropriate title for it in system’s conference call category via appropriate tester screen option using keyboard/ mouse.
2. Tester enters a second telecommunication number and appropriate title for it in system’s conference call category via appropriate tester screen option using keyboard/mouse
3. Tester clicks on speed dial button and verifies that new numbers are listed.

D.13.2.3    Expected Results:

Telecommunication numbers and appropriate titles will be successfully stored in the system’s conference call category.

D.13.2.4    Pass/Fail:

D.13.2.5    Results:

D.13.3    The system shall provide the capability to store frequently used telecommunications device numbers

(Use Case Not In POC Test)

D.13.3.1    Test Description:

Telecommunication numbers will be stored in the system via the tester screen and keyboard/ mouse. This process will be monitored from the test bed PSAP location.

D.13.3.2    Test Procedure:

1. Tester enters a telecommunication number and appropriate title for it in system via appropriate tester screen option using keyboard/mouse.
2. Tester enters a second telecommunication number and appropriate title for it in system via appropriate tester screen option using keyboard/mouse
3. Tester clicks on speed dial button and verifies that new numbers are listed.

D.13.3.3    Expected Results:

Telecommunication numbers and appropriate titles will be successfully stored in the system category.

D.13.3.4    Pass/Fail:

D.13.3.5    Results:

D.13.4    The system shall provide the capability to establish a call path to a third-party call center associated with the call

D.13.4.1    Test Description:

A call will be initiated to the test bed PSAP from a third-party call center.  The call will include connection to both the third-party call center and the originating caller.  This call will be monitored from the test bed PSAP location.

D.13.4.2    Test Procedure:

1. Third-party call center receives a call from public side of network.
2. Third-party call center, keeping originating caller on the connection, calls PSAP.
3. Tester answers call.
4. Tester confirms that both third-party call center and originating caller are on call.

D.13.4.3    Expected Results:

The system will establish the call path involving a third-party call center and an originating caller.

D.13.4.4    Pass/Fail:

D.13.4.5    Results:

D.13.5    The system shall provide the ability to query the EPAD DB for emergency provider contact method and access data

(Use Case Not In POC Test)

D.13.5.1    Test Description:

The tester will query the EPAD database for emergency provider information, including contact method and access data.  This process will be monitored from the test bed PSAP location.

D.13.5.2    Test Procedure:

1. Tester accesses EPAD database.
2. Tester queries EPAD database with provider name.
3. Tester receives appropriate information, including emergency contact method and access data.

D.13.5.3    Expected Results:

The tester will access the EPAD database and receive emergency provider information.

D.13.5.4    Pass/Fail:

D.13.5.5    Results:

D.13.6    The system shall provide media options to the Call Taker when establishing the call path

D.13.6.1    Test Description:

The system’s media options will be accessed and used to initiate calls (voice, video, and text options).  These calls will be monitored from the test bed PSAP location.

D.13.6.2    Test Procedure:

1. Tester accesses system’s media options and chooses voice call.
2. Tester places a voice call and verifies that connection is established.
3. Tester accesses system’s media options and chooses video call.
4. Tester places a video call and verifies that connection is established.
5. Tester accesses system’s media options and chooses short message service (SMS) text messaging call.
6. Tester places an SMS text messaging call and verifies that connection is established.
7. Tester accesses system’s media options and chooses Instant Messaging (IM) text messaging call.
8. Tester places an IM text messaging call and verifies that connection is established.

D.13.6.3    Expected Results:

The system’s media options will be provided and used to place outbound calls.

D.13.6.4    Pass/Fail:

D.13.6.5    Results:

D.13.7    The system shall provide the capability to establish voice conferencing

D.13.7.1    Test Description:

A voice call will be initiated to the test bed PSAP.  The tester will establish a three-way voice conference call.  This call will be monitored from the test bed PSAP location.

D.13.7.2    Test Procedure:

1. Voice call initiated to test bed PSAP.
2. Visual and audible alert displays at tester’s workstation.
3. Tester activates a button to accept call.
4. Tester receives call.
5. Tester chooses workstation conference call option.
6. Tester initiates call to another entity outside system.
7. When second entity answers, tester verifies that first caller is still on line and that other parties can hear each other.

D.13.7.3    Expected Results:

The tester will establish a three-way voice conference call.

D.13.7.4    Pass/Fail:

D.13.7.5    Results:

D.13.8    The system shall provide the capability to establish video conferencing

(Use Case Not In POC Test)

D.13.8.1    Test Description:

A video call will be initiated to the test bed PSAP.  The tester will establish a three-way video conference call. This call will be monitored from the test bed PSAP location.

D.13.8.2    Test Procedure:

1. Video call initiated to test bed PSAP.
2. Visual and audible alert displays at tester’s workstation.
3. Tester activates a button to accept call.
4. Tester receives call.
5. Tester chooses workstation conference call option.
6. Tester initiates call to another entity having video call capability (such as video interpreter) outside system.
7. When that entity answers, tester verifies that first caller is still on line and that both parties can view each other.
8. Tester also verifies that audio works with all three parties on call.

D.13.8.3    Expected Results:

The tester will establish a three-way video conference call and also verify that audio works for all three parties.

D.13.8.4    Pass/Fail:

D.13.8.5    Results:

D.13.9    The system shall provide the capability to establish interactive text conferencing

D.13.9.1    Test Description:

An interactive text messaging call will be initiated to the test bed PSAP.  The tester will establish a three-way interactive text messaging conference call. This call will be monitored from the test bed PSAP location.

D.13.9.2    Test Procedure:

1. Interactive text messaging call initiated to test bed PSAP.
2. Visual and audible alert displays at tester’s workstation.
3. Tester activates a button to accept call.
4. Call received by tester.
5. Tester chooses workstation conference call option.
6. Tester initiates interactive text messaging call to another entity outside system.
7. When entity answers, tester verifies that first caller is still on line and that all parties can view each other’s text messages.

D.13.9.3    Expected Results:

The tester will establish a three-way interactive text messaging conference call.

D.13.9.4    Pass/Fail:

D.13.9.5    Results:

D.13.10    The system shall provide teleconferencing features including mute based on NENA 58-001

(Use Case Not In POC Test)

D.13.10.1    Test Description:

A voice call will be initiated to the test bed PSAP, and the tester will conference in a third party.  The voice conference call will be used to test the system’s hold and mute options for three-way conference calls.  This call will be monitored from the test bed PSAP location.

D.13.10.2    Test Procedure:

1. Voice call initiated to test bed PSAP.
2. Visual and audible alert displays at tester’s workstation.
3. Tester activates a button to accept call.
4. Call is received by tester.
5. Tester chooses the workstation conference call option.
6. Tester initiates call to another entity outside system.
7. When that entity answers, tester verifies that first caller is still on line and that both other parties can hear each other.
8. Tester places call on hold via tester workstation and verifies that remaining two parties can still talk to each other.
9. Tester places call on partial mute, testing that other two parties cannot hear tester but can still talk to each other.
10. Tester places original caller on full mute and verifies that tester and third party can talk to each other but cannot be heard by original caller.
11. Tester verifies that original caller can still be heard by remaining two parties.

D.13.10.3    Expected Results:

The system is successfully tested for conference call hold option and for both partial and full mute options, the latter two as detailed in NENA 58-001.

D.13.10.4    Pass/Fail:

D.13.10.5    Results:

D.13.11    The system shall select an outgoing line

D.13.11.1    Test Description:

The tester will access the tester workstation to choose the option for placing an outbound call. The system will select an available outgoing line.  This call will be monitored from the test bed PSAP location.

D.13.11.2    Test Procedure:

1. Tester chooses tester workstation option for placing an outbound call.
2. Tester verifies that an outbound line has been selected by system (audio tone).

D.13.11.3    Expected Results:

The system will select an outgoing line when prompted by input from the tester workstation.

D.13.11.4    Pass/Fail:

D.13.11.5    Results:

D.13.12    The system shall provide the capability to dial a telecommunications device number

D.13.12.1    Test Description:

The tester will access the tester workstation and use the appropriate option to enter a telecommunications device number to be dialed.  Tester will place an outgoing call.  This call will be monitored from the test bed PSAP location.

D.13.12.2    Test Procedure:

1. Tester chooses tester workstation option for placing an outbound call.
2. Tester verifies that an outbound line has been selected by system (audio tone).
3. Tester inputs a telecommunications device number to tester workstation.
4. Tester places an outgoing call.
5. Tester verifies that call completes to correct telecommunications device number.

D.13.12.3    Expected Results:

The system will place an outgoing call based on tester input of a telecommunications device number entered via the tester workstation.

D.13.12.4    Pass/Fail:

D.13.12.5    Results:

D.13.13    The system shall provide the capability to select a telecommunications device number from a list

(Use Case Not In POC Test)

D.13.13.1    Test Description:

The tester will access the tester workstation and use the telecommunications device number list option to select a telecommunications device number to be dialed.  Tester will place an outgoing call.  This call will be monitored from the test bed PSAP location.

D.13.13.2    Test Procedure:

1. Tester chooses tester workstation option for placing an outbound call.
2. Tester verifies that an outbound line has been selected by system (audio tone).
3. Tester activates telecommunications device number list option on tester workstation.
4. Tester selects a telecommunications device number from tester workstation list.
5. Tester places an outgoing call.
6. Tester verifies that call completes to correct telecommunications device number.

D.13.13.3    Expected Results:

The system will place an outgoing call based on tester selection of a telecommunications device number chosen from the tester workstation telecommunications device number list option.

D.13.13.4    Pass/Fail:

D.13.13.5    Results:

D.13.14    The system shall store the results of the conference or transfer attempt in the call detail record

D.13.14.1    Test Description:

The tester will check the call detail records for the test calls in Sections D.13.7 (voice conferencing), D.13.8 (video conferencing), and D.13.9 (interactive text messaging conferencing) to verify that the conferencing attempts are stored in the call detail record for each.  This call will be monitored from the test bed PSAP location.

D.13.14.2    Test Procedure:

1. Tester accesses call detail record for Section D.13.7 (voice conferencing) test call.
2. Tester checks its information to verify that voice conferencing information is included.
3. Tester accesses call detail record for Section D.13.8 (video conferencing) test call.
4. Tester checks information to verify that video conferencing information is included.
5. Tester accesses call detail record for Section D.13.9 (interactive test messaging conferencing) test call.
6. Tester checks information to verify that interactive text messaging conferencing information is included.

D.13.14.3    Expected Results:

The system will have included conference call attempt information in the appropriate call records for three test calls (voice, video, and interactive text messaging).

D.13.14.4    Pass/Fail:

D.13.14.5    Results:

D.14    Record Call [CR-RCCAL]

Recording equipment captures each call in real time.  The record of the call may include audio, video, text, still imagery, and other data types.  Call recording is automatically initiated when a call taker answers a call.  Any non-audio information provided to the call taker will be preserved and identified as part of the call recording.

D.14.1    The system shall archive a detailed recording of each call locally

D.14.1.1    Test Description:

A call will be initiated to the test bed PSAP and answered by a tester.  After disconnect of call by the tester, the system will be checked for the locally archived detailed recording.  This call will be monitored from the test bed PSAP location.

D.14.1.2    Test Procedure:

1. Call initiated to test bed PSAP from any device.
2. Call answered by tester.
3. Call initiator will read predetermined script.
4. Call disconnected by tester.
5. Tester checks system to verify detailed recording is archived locally.
6. Test will be repeated for a cellular telephone call, a landline telephone call, and an IP telephone call.

D.14.1.3    Expected Results:

The archived detailed recording will be found stored by the system. (For the POC the call records will be stored centrally, but available locally)

D.14.1.4    Pass/Fail:

D.14.1.5    Results:

D.14.2    The system shall record incoming a)voice, b) video, c) interactive text, d) still imagery, e) interactive data as part of the Call Recording

D.14.2.1    Test Description:

Three calls will be initiated to the test bed PSAP and answered by a tester.  After disconnect of the calls by the tester, the system will be checked and recordings verified for a) voice, b) video, c) interactive text, d) still imagery, and e) interactive data. These calls will be monitored from the test bed PSAP location.

D.14.2.2    Test Procedure:

1. First call (voice with attached still imagery) initiated to test bed PSAP.
2. Call answered by tester.
3. Call disconnected by tester.
4. Tester checks system to verify that call recording exists and that it includes both voice and still imagery.
5. Second call (video) initiated to test bed PSAP.
6. Call answered by tester.
7. Call disconnected by tester.
8. Tester checks system to verify that call recording exists and that it includes video.
9. Third call (interactive text with interactive data) initiated to test bed PSAP.
10. Call answered by tester.
11. The interactive data viewed by tester.
12. Call disconnected by tester.
13. Tester checks system to verify that both interactive text and interactive data are included in call recording.

D.14.2.3    Expected Results:

The system check will verify that there are call recordings that include a) voice, b) video, c) interactive text, d) still imagery, and e) interactive data.

D.14.2.4    Pass/Fail:

D.14.2.5    Results:

D.14.3    The system shall provide the capability to archive a Call Recording at a remote location

D.14.3.1    Test Description:

A call will be initiated to the test bed PSAP and answered by a tester.  After disconnect of call by the tester, the system will be checked for the remotely archived detailed recording.  This will be monitored from the test bed PSAP location.

D.14.3.2    Test Procedure:

1. Call initiated from to test bed PSAP (any device)
2. Call answered by tester.
3. Call disconnected by tester.
4. Tester checks system to verify detailed recording is archived remotely.

D.14.3.3    Expected Results:

The detailed recording will be remotely archived by the system.

D.14.3.4    Pass/Fail:

D.14.3.5    Results:

D.14.4    The system shall provide the capability to access a Call Recording from a remote location

D.14.4.1    Test Description:

The tester will access the call recording to verify that it was archived remotely during test described in Section D.14.3 will be accessed by tester.  This will be monitored from the test bed PSAP location.

D.14.4.2    Test Procedure:

1. Tester accesses call recording that was archived remotely as part of test described in Section D.14.3.

D.14.4.3    Expected Results:

Tester will access call recording that was remotely archived during the D.14.3 test.

D.14.4.4    Pass/Fail:

D.14.4.5    Results:

D.14.5    The system shall record all calls

D.14.5.1    Test Description:

A series of three calls will be initiated to the test bed PSAP and answered by a tester.  After disconnect of the calls by the tester, the system will be checked to verify that all three call were recorded.  These calls will be monitored from the test bed PSAP location.

D.14.5.2    Test Procedure:

1. A series of three calls initiated to test bed PSAP from any device.
2. Calls answered by tester.
3. Calls disconnected by tester.
4. Tester checks system to verify that call recordings exist for each call.

D.14.5.3    Expected Results:

The system check will verify that all calls tested were recorded.

D.14.5.4    Pass/Fail:

D.14.5.5    Results:

D.14.6    The system shall record calls while the call is a) in a call queue b) assigned c) in process.  Please refer to the state diagram included with the CT-LGCAL activity to identify these states

(Use Case Not In POC Test)

D.14.6.1    Test Description:

A call will be initiated to the test bed PSAP.  The caller will begin a test count as soon as the call is initiated.  The tester will answer and disconnect call. The call recording will be checked to verify that it began when the call was initiated in the PSAP queue and continued until the tester disconnected.  This will be monitored from the test bed PSAP location.

D.14.6.2    Test Procedure:

1. Voice call initiated to test bed PSAP.
2. Caller begins a test count.
3. Three seconds after tester receives indication of call, calls answered by tester.
4. Call disconnected by tester.
5. Tester will check system to verify that call recording began when call was initiated in queue at PSAP and ended when call was disconnected by tester.

D.14.6.3    Expected Results:

The call recording will exist and will cover the time span from PSAP queue placement to tester disconnect.

D.14.6.4    Pass/Fail:

D.14.6.5    Results:

D.14.7    The system shall provide the capability to access a Call Recording

D.14.7.1    Test Description:

A tester will access a call recording from any previous test.  This will be monitored from the test bed PSAP location.

D.14.7.2    Test Procedure:

1. Tester accesses call recording from any previous test.

D.14.7.3    Expected Results:

Call recording access will be successful.

D.14.7.4    Pass/Fail:

D.14.7.5    Results:

D.14.8    The system shall provide the capability to transfer a Call Recording with its Call Record to a third party

D.14.8.1    Test Description:

A call recording and its related call record will be transferred from the originating PSAP to another PSAP via a screen option chosen by a tester.  This will be monitored from both test bed PSAP locations involved in the transfer.

D.14.8.2    Test Procedure:

1. Call initiated to test bed PSAP (any device)
2. Call answered by tester.
3. Call disconnected by tester.
4. Tester activates screen option to transfer call recording and related call record to another PSAP.
5. Call recording and its related call record received by other PSAP.

D.14.8.3    Expected Results:

Remote PSAP will receive transferred call recording and related call record.

D.14.8.4    Pass/Fail:

D.14.8.5    Results:

D.14.9    The system shall provide the capability to locally access a Call Recording

(Use Case Not In POC Test)

D.14.9.1    Test Description:

A call recording will be created and then locally accessed by the tester.  This will be monitored from the test bed PSAP location.

D.14.9.2    Test Procedure:

1. Call initiated to test bed PSAP from any device.
2. Call answered by tester.
3. Call disconnected by tester.
4. Tester accesses locally stored call recording.

D.14.9.3    Expected Results:

Call recording stored locally will be accessed.

D.14.9.4    Pass/Fail:

D.14.9.5    Results:

D.14.10    The system shall provide the capability to display TBR previous Call Recording for instant playback

D.14.10.1    Test Description:

A call recording will be created and then locally accessed by tester via instant playback feature.  This will be monitored from the test bed PSAP location.

D.14.10.2    Test Procedure:

1. Call initiated to test bed PSAP from any device.
2. Call answered by tester.
3. Call disconnected by tester.
4. Tester accesses the call recording via instant playback feature.

D.14.10.3    Expected Results:

Call recording will be accessed via instant playback feature.

D.14.10.4    Pass/Fail:

D.14.10.5    Results:

D.14.11    The system shall link a Call Recording with its call record

D.14.11.1    Test Description:

A call recording will be created, and the tester will check the system to verify that it is linked with the correct call record.  This will be monitored from the test bed PSAP location.

D.14.11.2    Test Procedure:

1. Call initiated to test bed PSAP from any device.
2. Call answered by tester.
3. Call disconnected by tester.
4. Tester checks call recording information to verify that it is linked with correct call record.

D.14.11.3    Expected Results:

Call recording will be linked with the correct call record.

D.14.11.4    Pass/Fail:

D.14.11.5    Results:

D.14.12    The system shall provide the capability to retrieve a Call Recording with its Call Record

D.14.12.1    Test Description:

A call recording will be created, and the tester will check the system to verify that it is linked with the correct call record.  This will be monitored from the test bed PSAP location.

D.14.12.2    Test Procedure:

1. Call initiated to test bed PSAP from any device.
2. Call answered by tester.
3. Call disconnected by tester.
4. Tester will check call recording information to verify that it is linked with correct call record.

D.14.12.3    Expected Results:

Call recording will be linked with correct call record.

D.14.12.4    Pass/Fail:

D.14.12.5    Results:

D.14.13    The system shall provide the capability to search the Call Recording repository

D.14.13.1    Test Description:

The tester will check the appropriate system component to verify that it has a call recording repository search function.  (Actual retrieval based on search criteria will occur in Section D.14.14 test.)  This will be monitored from the test bed PSAP location.

D.14.13.2    Test Procedure:

1. The tester will check appropriate system component to verify it has a search function for call recording retrieval.

D.14.13.3    Expected Results:

System will provide the capability to search the call recording repository.

D.14.13.4    Pass/Fail:

D.14.13.5    Results:

D.14.14    The system shall retrieve call recording based upon search criteria

D.14.14.1    Test Description:

The appropriate system component call recording repository search function will be used to search based on varied criteria.  This will be monitored from the test bed PSAP location.

D.14.14.2    Test Procedure:

1. Tester enters date/time as search criterion for a call recording retrieval (date/time based on date/time of a call recording created in one of earlier tests).
2. Call recording retrieved and verified as correct one.
3. Tester enters a telephone number as search criterion for a call recording retrieval (telephone number is one for a call recording created in one of earlier tests).
4. Call recording retrieved and verified as correct one.
5. Tester enters text message identifier as search criterion for a call recording retrieval (text message identifier is one for a call recording created in one of earlier tests).
6. Call recording retrieved and verified as correct one.

D.14.14.3    Expected Results:

The three search criterion tests (date/time, telephone number, and text message identifier) will return the correct call recordings.

D.14.14.4    Pass/Fail:

D.14.14.5    Results:

D.14.15    The system shall be able to correlate recordings of different media types to construct a single recording set

(Use Case Not In POC Test)

D.14.15.1    Test Description:

A video/voice call that includes an attached still image and interactive data will be initiated to the test bed PSAP. The call recording retrieval will be checked to verify that the different media types are included in the call recording set.  This will be monitored from the test bed PSAP location.

D.14.15.2    Test Procedure:

1. Video/voice call initiated to test bed PSAP.
2. Call answered by tester.
3. Tester receives and accepts attached still image.
4. Tester receives and accepts attached data information.
5. Call disconnected by tester.
6. Call recording repository accessed for call recording set.
7. Call recording set checked to ensure it contains video/voice call, still image, and data information.

D.14.15.3    Expected Results:

The call recording set will include the different media types that were part of the call.

D.14.15.4    Pass/Fail:

D.14.15.5    Results:

D.14.16    The system shall provide the capability to play a call recording

D.14.16.1    Test Description:

Three calls (voice, video and interactive text) will be initiated to the test bed PSAP and answered by a tester.  After disconnect of calls by the tester, the call recordings will be accessed.  This will be monitored from the test bed PSAP location.

D.14.16.2    Test Procedure:

1. Voice call initiated to test bed PSAP.
2. Call answered by tester.
3. Call disconnected by tester.
4. Tester accesses system to play call recording.
5. Video call initiated to test bed PSAP.
6. Call answered by tester.
7. Call disconnected by tester.
8. Tester accesses system to play call recording.
9. Text messaging call initiated to test bed PSAP.
10. Call answered by tester.
11. Call ended by tester.
12. Tester accesses system to play call recording.

D.14.16.3    Expected Results:

The system will record and play back voice, video, and text messaging calls.  (For the POC Video and Audio is stored separately.  The audio for a video will be played separately)

D.14.16.4    Pass/Fail:

D.14.16.5    Results:

D.14.17    The system shall provide the capability to pause a Call Recording

D.14.17.1    Test Description:

The tester will access the voice and video call recordings created in the Section D.14.16 test and will request a pause from the system for each of the call recordings.  This will be monitored from the test bed PSAP location.

D.14.17.2    Test Procedure:

1. Tester accesses voice call recording created in Section D.14.16 test.
2. Tester activates system call recording pause function.
3. Tester de-activates system pause function.
4. Tester accesses video call recording created in Section D.14.16 test.
5. Tester activates system call recording pause function.
6. Tester de-activates system pause function.

D.14.17.3    Expected Results:

The system call recording pause capability will be activated and stopped by the tester for both a voice call and a video call.  (For the POC Video and Audio is stored separately.  The audio for a video will be played separately)

D.14.17.4    Pass/Fail:

D.14.17.5    Results:

D.14.18    The system shall provide the capability to rewind a Call Recording

D.14.18.1    Test Description:

The tester will access the voice and video call recordings created in the Section D.14.16 test and will request rewind from the system for each of the call recordings.  This will be monitored from the test bed PSAP location.

D.14.18.2    Test Procedure:

1. Tester accesses voice call recording created in Section D.14.16.
2. Tester activates system call recording rewind function.
3. Tester activates system rewind stop function.
4. Tester accesses video call recording created in Section D.14.16 test.
5. Tester activates system call recording rewind function.
6. Tester activates system rewind stop function.

D.14.18.3    Expected Results:

The system call recording rewind and rewind stop capability will be activated for both a voice call and a video call.  (For the POC Video and Audio is stored separately.  The audio for a video will be played separately)

D.14.18.4    Pass/Fail:

D.14.18.5    Results:

D.14.19    The system shall provide the capability to fast forward a Call Recording

D.14.19.1    Test Description:

The tester will access the voice and video call recordings created in the Section D.14.16 test and will request fast forward from the system for each of the call recordings.  This will be monitored from the test bed PSAP location.

D.14.19.2    Test Procedure:

1. Tester accesses voice call recording created in Section D.14.16 test.
2. Tester activates system call recording fast forward function.
3. Tester activates system fast forward stop function.
4. Tester accesses video call recording created in Section D.14.16 test.
5. Tester activates system call recording fast forward function.
6. Tester activates system fast forward stop function.

D.14.19.3    Expected Results:

The system call recording fast forward and fast forward stop capability will be activated and stopped by the tester for both a voice call and a video call.  (For the POC Video and Audio is stored separately.  The audio for a video will be played separately)

D.14.19.4    Pass/Fail:

D.14.19.5    Results:

D.14.20    The system shall play a Call Recording

D.14.20.1    Test Description:

The tester will access and play the three call recordings created in Section D.14.16 test.  This will be monitored from the test bed PSAP location.

D.14.20.2    Test Procedure:

1. Tester accesses voice call recording created in Section D.14.16 test.
2. Tester activates system call recording play function.
3. System plays call recording.
4. Tester accesses video call recording created in Section D.14.16 test.
5. Tester activates system call recording play function.
6. System plays call recording.
7. Tester accesses text messaging call created in Section D.14.16 test.
8. Tester activates system call recording play function.
9. System plays call recording (text scrolling).

D.14.20.3    Expected Results:

The system call recording play capability will be activated, and the call recordings will play.

D.14.20.4    Pass/Fail:

D.14.20.5    Results:

D.14.21    The system shall pause a Call Recording

D.14.21.1    Test Description:

The tester will access the voice and video call recordings created in Section D.14.16 and will request pause and then play from the system for each of the call recordings.  This will be monitored from the test bed PSAP location.

D.14.21.2    Test Procedure:

1. Tester accesses voice call recording created in Section D.14.16 test.
2. Tester activates system call recording pause function.
3. Tester activates system call recording pause stop function.
4. Tester activates system call recording play function (from point of pause).
5. Tester accesses video call recording created in Section D.14.16 test.
6. Tester activates system call recording pause function.
7. Tester activates system call recording pause stop function.
8. Tester activates system call recording play function (from point of pause)

D.14.21.3    Expected Results:

The system will pause the call recordings, and the call recordings will play from the point paused.

D.14.21.4    Pass/Fail:

D.14.21.5    Results:

D.14.22    The system shall rewind a Call Recording

D.14.22.1    Test Description:

The tester will access and rewind the voice and video call recordings created in the Section D.14.16 test.  This will be monitored from the test bed PSAP location.

D.14.22.2    Test Procedure:

1. Tester accesses voice call recording created in Section D.14.16 test.
2. Tester activates system call recording rewind function.
3. Tester activates system call recording rewind stop function.
4. Tester activates system call recording play function (from point of rewind).
5. Tester accesses video call recording created in Section D.14.16 test.
6. Tester activates system call recording rewind function.
7. Tester activates call recording rewind stop function.
8. Tester activates system call recording play function (from point of rewind).

D.14.22.3    Expected Results:

The system will rewind the call recordings, and the call recordings will play from the rewind point.

D.14.22.4    Pass/Fail:

D.14.22.5    Results:

D.14.23    The system shall fast forward a Call Recording

D.14.23.1    Test Description:

The tester will access and fast forward the voice and video call recordings created in Section D.14.16 test will be accessed and fast forwarded.  This will be monitored from the test bed PSAP location.

D.14.23.2    Test Procedure:

1. Tester accesses voice call recording created in Section D.14.16 test.
2. Tester activates system call recording fast forward function.
3. Tester activates system call recording fast forward stop function.
4. Tester activates system call recording play function (from point of pause).
5. Tester accesses video call recording created in Section D.14.16 test.
6. Tester activates system call recording fast forward function.
7. Tester activates system call recording fast forward stop function.
8. Tester activates system call recording play function (from point of fast forward).

D.14.23.3    Expected Results:

The system will fast forward the call recordings, and the call recordings will play from the fast forwarded point.

D.14.23.4    Pass/Fail:

D.14.23.5    Results:

D.15    Transfer Call Records [CR-TRCIN]

This activity supports the capability for a call taker to electronically transfer or forward call records to other call takers, dispatchers, responders, or other authorized entities with or without a simultaneous conference call.

D.15.1    The system shall provide the capability to transfer a call record

(Use Case Not In POC Test)

D.15.1.1    Test Description:

The tester will transfer a call record to another PSAP.  This will be monitored from the test bed PSAP location.

D.15.1.2    Test Procedure:

1. Call initiated to test bed PSAP using any technology.
2. Tester receives call.
3. Tester enters data into call record.
4. Tester releases call.
5. Tester opens call record.
6. Tester transfers call record to another PSAP.

D.15.1.3    Expected Results:

All call data associated with the call record will be received by the receiving PSAP.

D.15.1.4    Pass/Fail:

D.15.1.5    Results:

D.15.2    The system shall provide the capability to transfer call records only to those permitted

(Use Case Not In POC Test)

D.15.2.1    Test Description:

The tester will attempt to transfer a call record to an agency that does not have the necessary permissions.  This will be monitored from the test bed PSAP location.

D.15.2.2    Test Procedure:

1. Call initiated to test bed PSAP using any technology.
2. Tester receives call.
3. Tester enters data into call record.
4. Tester releases call.
5. Tester opens call record.
6. Tester transfers call record to a responding agency without permissions to receive data.

D.15.2.3    Expected Results:

The call record will not be transferred to the agency.

D.15.2.4    Pass/Fail:

D.15.2.5    Results:

D.15.3    The system shall log the transfer of call records

(Use Case Not In POC Test)

D.15.3.1    Test Description:

The call records created in D.15.1 and D.15.2 tests will be reviewed.  This will be monitored from the test bed PSAP location.

D.15.3.2    Test Procedure:

1. Tester transfers a call to another PSAP.
2. Tester opens call record.
3. Tester reviews call record.
4. Tester transfers a call to another agency without permissions.
5. Tester open call record.
6. Tester reviews call record.

D.15.3.3    Expected Results:

The call record will show that the call record was transferred to the other PSAP with permissions, and that transfer was attempted, but not completed to the agency without proper permissions.

D.15.3.4    Pass/Fail:

D.15.3.5    Results:

D.15.4    The system shall log data transfer attempts, including: a) transfer request date/time, b) notification of transfer success/failure date/time, c) transfer requestor, d) intended recipient, e) transferred data

(Use Case Not In POC Test)

D.15.4.1    Test Description:

After a call record is transferred, the call record and the log file will be reviewed.  This will be monitored from the test bed PSAP location.

D.15.4.2    Test Procedure:

1. Tester transfers a call to another PSAP.
2. Tester opens the call record.
3. Tester reviews call record.
4. Tester transfers a call to another agency without permissions.
5. Tester will open the call record
6. Tester reviews call record.
7. An administrator views log file.

D.15.4.3    Expected Results:

The call record will show that the call record was transferred to the other PSAP with permissions, and that the transfer was attempted, but not completed to the agency without proper permissions.   The log will contain the following information: a) request date/time, b) notification of transfer success/failure date/time, c) transfer requestor, d) intended recipient, e) transferred data.

D.15.4.4    Pass/Fail:

D.15.4.5    Results:

D.15.5    The system shall display an acknowledgement message of data receipt to the originating requestor upon successful call record transfer

(Use Case Not In POC Test)

D.15.5.1    Test Description:

The tester will transfer a call record to an agency that has permissions to receive the data.  This will be monitored from the test bed PSAP location.

D.15.5.2    Test Procedure:

1. Call initiated to test bed PSAP using any technology.
2. Tester receives call.
3. Tester enters data into call record.
4. Tester releases call.
5. Tester opens call record.
6. Tester transfers call record to a PSAP with permissions to receive data.

D.15.5.3    Expected Results:

After the tester transfers the call record, the tester will receive a message that the transfer was successful.

D.15.5.4    Pass/Fail:

D.15.5.5    Results:

D.15.6    The system shall display a message that data was not received to the originating requestor upon failed call record transfer

(Use Case Not In POC Test)

D.15.6.1    Test Description:

The tester will attempt to transfer a call record to an agency that does not have permissions to receive data.  This will be monitored from the test bed PSAP location.

D.15.6.2    Test Procedure:

1. Call initiated to the PSAP using any technology.
2. Tester receives call.
3. Tester enters data into call record.
4. Tester releases call.
5. Tester opens call record.
6. Tester transfers call record to a responding agency without permissions to receive data.

D.15.6.3    Expected Results:

After the tester attempts to transfer the call record, the tester will receive a message that the transfer was not successful.

D.15.6.4    Pass/Fail:

D.15.6.5    Results:

D.15.7    The Business Rules DB shall contain permission rules for data transfers

(Use Case Not In POC Test)

D.15.7.1    Test Description:

An administrator will review the business rules database for the permission rules for the transfer of data.  The administrator will make changes to the database and test those changes.  This will be monitored from the test bed PSAP location.

D.15.7.2    Test Procedure:

1. Tester opens call record.
2. Tester transfers call record to a PSAP with permissions to receive data.
3. Administrator opens business rules database.
4. Administrator reviews database records.
5. Administrator changes permission level of receiving PSAP.
6. Tester opens call record again.
7. Tester attempts to transfer call record to same PSAP without permissions to receive data.

D.15.7.3    Expected Results:

The data will transfer properly initially but will be blocked after the rules are changed.

D.15.7.4    Pass/Fail:

D.15.7.5    Results:

Appendix E—Total System Test Scripts

E.1    Call Setup

E.1.1    Test Description:

This test will provide a system test of the processing of calls to the Next Generation 9-1-1 (NG9-1-1) system from various technologies outlined in Sections 9 and 10.  This will be monitored from the test bed PSAP location.  This test will cover the following use cases in general terms for the tested technology:

• Call Authentication
• Recognize Originating Location
• Recognize Call Type
• Route Call to PSAP.

E.1.2    Test Procedure:

1. Two calls initiated from this technology to PSAP approximately 30 seconds apart.
2. First call processed through NG9-1-1 network.
3. First call delivered to proper PSAP.
4. Second call processed through NG9-1-1 network.
5. Second call delivered to proper PSAP.

E.1.3    Expected Results:

The call will be properly routed through the NG9-1-1 network to the correct PSAP without delay.

E.1.4    Pass/Fail:

E.1.5    Results:

E.2    Call Handling

E.2.1    Test Description:

This test will provide a system test of the processing of 9-1-1 calls from various technologies outlined in sections 9 and 10 to the NG9-1-1 system and PSAP.  This will be monitored from the test bed PSAP location.  This test will cover the following use cases in general terms for the tested technology:

• Answer Call
• Determine and Verify Location of Emergency
• Determine Nature of Emergency
• Identify Appropriate Responding Agency or Service
• Establish Conference Call & Provide Network Bridging Services.

E.2.2    Test Procedure:

Continue using the calls initiated in E.1:

1. First call delivered to the tester workstation.
2. System displays a visual and audible notification at tester workstation.
3. Tester selects (or automatically answers) call.
4. Tester reviews data associated with call (nature of emergency, location, response agencies).
5. Tester enters updated information.
6. Tester places call on hold to answer second call.
7. Tester reviews data associated with call.
8. Tester enters updated information.
9. Tester conferences call to another PSAP.
10. Tester transfers call to another PSAP.
11. Tester reviews how long first call was on hold.
12. Tester waits for indicator that call has been on hold too long.

E.2.3    Expected Results:

Both calls will be sent to the tester’s workstation with the proper information, and the tester will be able to add more information.  The call and the information will be received at the second PSAP.  The tester will be able to place the call on hold and see the time on hold.  The call on hold will activate a visual and audio notification to the tester that the pre-set threshold time limit has been exceeded.  

E.2.4    Pass/Fail:

E.2.5    Results:

E.3    Data Handling

E.3.1    Test Description:

This test will provide a system test of the processing of 9-1-1 calls from various technologies outlined in Sections 9 and 10 to the NG9-1-1 system and PSAP.  This will be monitored from the test bed PSAP location.  This test will cover the following use cases in general terms for the tested technology:

• Update Mobile Caller’s Location Information (if caller is mobile)
• Record Call
• Obtain Supportive or Supplemental Data post call delivery
• Initiate Callback
• Transfer Call Record.

E.3.2    Test Procedure:

Continue using calls initiated in E.1 and used in E.2:

1. Tester picks up call on hold.
2. Tester communicates with caller.
3. Tester enters updated information in call.
4. Tester queries a supplemental database for information.
5. Tester releases call.
6. Tester opens record of call to verify data.
7. Tester transfers the call record to another agency.
8. Secondary agency verifies receipt of call record.
9. Tester initiates a call back to caller.

E.3.3    Expected Results:

The tester will pick up the call on hold and communicate with the caller.  The tester will add more information after the call is on hold.  Tester will update the caller’s location and query supplemental databases.  The tester will review and transfer the call record.  The tester will call back the calling device.

E.3.4    Pass/Fail:

E.3.5    Results:

Appendix F—Task 3C/3D Report

Appendix G—Data Collection Results

Footnotes:

1) The emergency services internetwork will be “interoperable” in that the networks and systems that comprise the NG9 1 1 architecture system of systems will have the ability to work together using standard formats and protocols.

2) The term “call” is used in this document to indicate any real-time communication—voice, text, or video—between a person or sensor needing assistance and a Public Safety Answering Point (PSAP) call taker.

3) “Internetwork”—to go between one network and another; a large network made up of a number of smaller networks.