Mayday/9-1-1 Field Operational Test (FOT) Results and Path Forward Report
For the PDF version of this document, please click here.
Document Number: 232004
Revision B
March 10, 2006
Prepared for:
Minnesota Department of Transportation
This document was prepared by:
Melvin Gail Linnell, PhD
Telcordia Technologies
mlinnell@telcordia.com
Stan Wainberg, PhD
Telcordia Technologies
swainber@telcordia.com
Anand Akundi
Telcordia Technologies
aakundi@telcordia.com
For further information, please contact:
Stan Wainberg
Project Manager
Telcordia Technologies
swainber@telcordia.com
Bradley Estochen, P.E.
ITS Project Manager
Office of Traffic, Security and Operations
Minnesota Department of Transportation
Bradley.estochen@dot.state.mn.us
Lawrence Haynes
Program Manager
SAIC
haynesla@saic.com
Trademark Acknowledgments
Telcordia® is a registered trademark of Telcordia Technologies, Inc.
All other brand or product names are trademarks of their respective companies or organizations.
Table of Contents
1. INTRODUCTION 1.1 Purpose 1.2 Scope 1.3 Intended Audience 1.4 Relationship to Other Documents 1.5 Document Organization 1.6 Acknowledgements 1.7 Definitions
2. FOT TEST PLAN 2.1 Test Network Overview 2.1.1 Test Call Execution 2.2 Geographic Areas and PSAPs Addressed 2.3 Battelle's Acceptance Plan Overview
3. FOT TEST RESULTS 3.1 Overview of Test Results 3.2 Mayday/9-1-1 FOT Evaluation 3.3 Issues and Lessons From Mayday/9-1-1 FOT
4. PROPOSED PATH FORWARD 5. REFERENCES
APPENDIX A: ACRONYMS
APPENDIX B: PSAP SCREEN SHOTS
C. TSPECRS AND FOT ARCHITECTURE COMPARISON WITH STANDARDS C.1 Wireless Standards C.1.1 TIA TR45.2 C.1.2 European eCall Initiative C.2 E9-1-1 Evolution in IP-Based Next Generation Networks (NGNs) C.2.1 NENA i2 Solutions C.2.1.1 Description of i2 Soultion Elements C.2.1.2 TSPECRS and NENA i2 Solution Comparative Analysis C.2.2 NENA i3 Solution C.2.2.1 Functional Elements of the i3 Solution C.2.2.2. TSPECRS and NENA i3 Solution Comparative Analysis
List of Figures
Figure 2-1: Onstar Test Unit Figure 2-2: State Wide View of Included PSAPs Figure B-1: PSAP Screen Shot (1 of 3) Figure B-2: PSAP Screen Shot (2 of 3) Figure B-3: PSAP Screen Shot (3 of 3) Figure C-1: eCall Network Architecture Figure C-2: i2 Solution Architecture Figure C-3: NENA LTD View of i3 Functional Architecture
1. Introduction
Within the United States, there are significant, well-acknowledged challenges in routing and delivering Telematics Service Provider (TSP) emergency calls, and associated vehicle location and crash data information, across the nation to the appropriate local Public Safety Answering Points (PSAPs) using the local, native 9-1-1 networks. The 9-1-1 networks are local, disconnected from each other, and are not coordinated at a national level. Telematics calls traverse long distances, far from the location of the emergency, to the national, centrally located Telematics Call Center (TCC) of the TSP. Once at the TCC, there is no existing, effective way to route these calls back to the appropriate, local 9-1-1 network as an emergency call. Today, the TSP emergency calls are routed via the Public Switched Telephone Network (PSTN) to an administrative line on the appropriate PSAP. This is accomplished by the TCC using a lookup table for these administrative telephone numbers in a database that must be kept up to date. Since these calls come in on the administrative line, the PSAP may not give them the same priority as normal arriving 9-1-1 calls. Since these calls are PSTN voice only, many of the data features associated with 9-1-1 networks interconnecting to wireless and wireline networks are not available between the TCC and PSAPs. All of the emergency information must be provided to the PSAP operator verbally which can lead to mistakes and delays. The TSP Emergency Call Routing Service (TSPECRS) System Specification [1] and Concept of Operations [2] provide more details on this service, and the type of information and data that the TSPs wish to send to the PSAPs.
In addition to the basic 9-1-1 data/information related to call back number, vehicle location, and vehicle identification, the TSP subscribed vehicle is able to send to the TCC various crash data during an emergency call. Telematics emergency calls can be of three types: emergency-key-press calls, Automatic Crash Notification (ACN) calls and Advanced Automatic Crash Notification (AACN) calls. Emergency-key- press calls are also known as SOS calls. ACN calls are also known as airbag calls. Further details are in Concept of Operations Report [2].
The TSP Emergency Call Routing Service (TSPECRS) System Specification specifies the architecture, interfaces/protocol and system requirements to facilitate routing of a TSP emergency call to the appropriate 9-1-1 network and PSAP, by utilizing the Serving Wireless Service Provider (WSP) network. TSPECRS allows a TCC to make TSP emergency calls via the wireless network (and the PSTN), and make them appear as wireless E9-1-1 Phase 2 calls to the PSAPs. In addition, the TSPECRS System Specification describes procedures that would facilitate transmission of TSP crash data to the PSAPs via the signaling network of the WSP. This solution relies on the ongoing partnership of TSPs with WSPs to leverage existing wireless network resources with special enhancements for TSPECRS. TSPECRS specific enhancements are required at the PSAPs and in the 9-1-1 databases to retrieve Telematics vehicle crash data from the TSPs to allow the display on PSAP screens. The Mayday/9-1-1 FOT Design Report [4] describes in detail the network architecture, network connectivity, lab facilities/systems at Telcordia and OnStar, test procedures, call flows and sample test data/information used to demonstrate and test TSPECRS. In particular, the call connection arrangement are shown starting at the OnStar test vehicle through the WSP, to the OnStar Call Center, Telcordia lab (simulates Serving WSP), and then to the 9-1-1 networks in Minnesota.
This effort, including field testing, was done under an SAIC contract with the State of Minnesota, called "Voice Routing for Mayday Field Operational Test," and contract number SC # ONS02807. The overall Mayday Field Operational Test also includes testing on the data routing that is possible from a TSP, and a separate series of reports are available for that portion of the test [8],[9]. The state of Minnesota received the funding and sponsorship for this program from the United States Department of Transportation - ITS Joint Program Office - Public Safety Program and the National Highway Traffic Safety Administration - Emergency Medical Services Division. In particular, SAIC and Telcordia teamed with the Minnesota Department of Transportation (MNDOT) and OnStar to set up this Field Operational Test (FOT), and perform the demonstrations and testing. In addition, this latter operational team was supported by Qwest, Hutchinson Telephone, Intrado and Independent Emergency Services (IES), in providing connectivity and 9-1-1 service access, including access to twenty-two (22) PSAPs. Further, IES enhanced their 9-1-1 systems to accept additional AACN information sent to their PSAPs. This operational team also coordinated with Battelle, which was responsible for the evaluation of the voice routing capabilities of the Mayday/9-1-1 FOT, and sponsored by the USDOT ITS - Joint Program Office, Public Safety Program. In particular, the operational team provided input and feedback to Battelle in the development of the "Detailed Evaluation Plan," [3] and coordinated efforts during the actual testing and evaluation test phase. Battelle will provide the final report on the Mayday/9-1-1 FOT Evaluation Results. This document, written by the operational team, describes Mayday/9-1-1 FOT test results from the operational team's viewpoint and lessons learned. In addition, this document describes TSPECRS-related industry activities, and then provides analysis and potential path forward considerations for TSPECRS.
The following subsections detail the document purpose, scope, intended audience, document organization, and definitions.
This document presents results from the Mayday/9-1-1 FOT effort from the point of view of the operational team conducting the FOT. The final, official results will be provided by the evaluation team.
This document supports the proof of concept demonstration and testing environment of the Mayday/9-1-1 Field Operational Test (FOT) for the voice routing functionality, as described in references [1][2]. The Mayday/9-1-1 FOT Design Report [4] provides a description of the proposed architecture for TSPECRS, and modifications specific to the demonstration and test procedures used for the FOT, and subsequent FOT evaluation process. The TSPECRS System Specification is a basis for this document and all other corresponding Mayday/9-1-1 FOT efforts and documentation.
This document supports the evaluation process of the TSPECRS solution, providing information and detail on the Mayday/9-1-1 FOT results, analysis of industry activities, and potential path forward. The document "Test Plan: Mayday/9-1-1 Field Operations Test Independent Testing of Voice Routing Functions," authored by Battelle, lays out the evaluation and acceptance test plan, including the supporting statistical analysis to determine the success of the Mayday/9-1-1 FOT demonstration [3].
This document provides the Mayday/9-1-1 FOT test results from the FOT operational team's point of view, lessons learned, industry activities, analysis, and path forward. It is expected that Battelle will provide the final report on the Mayday/9-1-1 FOT evaluation.
1.2 ScopeThis document provides an overview of the test plan and test results from the FOT execution team point of view. The definitive and final evaluation of the test results will be provided by the independent evaluation team led by Battelle. Additionally, this document relates the overall TSPECRS concept with the current ongoing related standards efforts. Finally, the document suggests additional steps that could assist the industry in reaching a workable solution in meeting the TSP emergency calling needs.
The intended audience of this document or parts thereof includes:
1.4 Relationship to Other Documents
This document is a companion document to and builds on the Mayday/9-1-1 FOT Design Report [4]. All efforts within this program are based on the original specification of TSPECRS [1]. The FOT testing was performed and based on the detailed evaluation and acceptance test plan developed by the independent evaluation team [3].
The data portion of the Mayday/9-1-1 Project has corresponding documentation in the following two documents: 1) Mayday/9-1-1 Field Operational Test Data Routing Concept of Operations Report [8] and 2) Mayday/9-1-1 Field Operational Test Data Routing Project Final Report [9].
The organization of the remainder of this document is as follows:
The Minnesota Department of Transportation gratefully acknowledges the invaluable contributions of the following individuals and organizations. Without their generous donation of time, experience, and expertise, the success of this project would not have been possible:
This section provides the definition of key terms used in the document. The definitions are intended to clarify the meaning of the terms.
2. FOT Test Plan
As described in the Mayday/9-1-1 FOT Design Report [4], the FOT demonstration/test network was created using a combination of (a) real 9-1-1 networks, (b) operational PSAPs and secondary PSAPs, (c) the PSTN, (d) real network equipment, laboratory equipment and simulators at Telcordia, (e) the Verizon Wireless network and (f) real and lab equipment at OnStar in order to demonstrate, test and evaluate the capabilities that would be realized with TSPECRS. The FOT demonstration network will be described by walking the reader through a test call. The test calls are initiated using a specially constructed portable OnStar test unit. The OnStar test unit is designed to allow the user to initiate a test call from the vehicle and emulate one of several crash scenarios, specified by the test call initiator. The OnStar test unit derives its location by using GPS technology. Figure 2 1 shows one of the OnStar test units used during the testing.
Figure 2 1 OnStar Test Unit
When the call is initiated, the OnStar unit makes a wireless network call through the Verizon Wireless network to the OnStar lab in Detroit, Michigan. OnStar's Telematics Call Center (TCC) laboratory receives the Telematics data from the OnStar unit via the call, and forwards the voice call connection to the live OnStar TCC where it is answered by an OnStar Emergency Advisor (or operator). While the call is being delivered to the Emergency Advisor, the OnStar prototype equipment accesses a web service at the Tandem MSC (T-MSC) located in the Telcordia lab. The web service function on the T-MSC accepts the Telematics data from OnStar and returns a 10-digit telephone number to the OnStar Emergency Advisor. This number is the Temporary Location Directory Number (TLDN) to dial and route the call to the simulated T-MSC, and subsequently to the simulated Serving MSC (S-MSC) at the Telcordia lab. The OnStar Emergency Advisor places a three-way (conference) call between the provided telephone number and the vehicle based calling user. The call segment from the TCC is routed over the PSTN to the Primary Rate Interface (PRI) of the Telcordia lab 5ESS switch, which is part of the T-MSC model.
When the call enters the 5ESS switch, it encounters an AIN trigger that initiates an AIN SS7 TCAP query to the simulator, based on the Network Services Test System (NSTS). The NSTS is used to simulate the ANSI 41 TCAP wireless signaling and control processing at and between the T-MSC, the Home Location Register (HLR), the S-MSC and the Mobile Positioning Center (MPC). The ANSI 41 exchange of TCAP messages, and related call set-up messages, between these entities take place as if the TSPECRS systems were actually deployed in the public networks. Using the actual location (i.e., latitude and longitude) provided to the OnStar Lab TCC and passed to the web service of the T-MSC, the call is routed from the T-MSC to one of three simulated S-MSCs, and then to the live 9-1-1 network in Minnesota.
The Mayday/9-1-1 FOT network included Selective Routers (SRs) from Qwest and IES, the two companies that provide 9-1-1 services to the State of Minnesota. Two Qwest SRs and one IES SR were used to access 22 PSAPs (18 in Qwest and 4 in IES) in the Minnesota 9-1-1 networks that participated in this project. The specific PSAPs are discussed in Section 2.2. The voice trunk circuits to the SRs from the S-MSCs (i.e., 5ESS) used Centralized Automated Message Accounting (CAMA)/ Multi-Frequency (MF) signaling. In the signaling to the SR, the called number is 911 and the calling number is an Emergency Services Routing Key (ESRK) based on the latitude and longitude received from the MPC, allowing the SR to route the call to the appropriate PSAP. The set of ESRKs that were used in the FOT were provided on a temporary basis by the Minnesota 9-1-1 administrator. In addition to the voice call and routing functions, Telcordia maintained three (TCP/IP) data circuits, connecting the simulated MPC to the three live ALI databases that serve the selected PSAPs. IES manages their ALI databases internally while Qwest's ALI databases are maintained through an agreement with Intrado. The E2 application protocol on these data circuits supported the transport of the required 9-1-1 call information, in addition to the AACN data to the IES ALI. More details on the call flows and associated messaging can be found in references [1]and [4]
2.2 Geographic Areas and PSAPs Addressed
The state of Minnesota E9-1-1 networks includes a total of 13 Selective Routers (6 Qwest, 7 IES) and 128 PSAPs. The SRs and PSAPs are spread over a large geographic area. In order to limit the scope of the FOT and demonstration effort, three of the SRs and 22 of the PSAPs were selected as representative samples of 9-1-1 systems in Minnesota. These selections were representative of population density and technology considerations (that is, 9 city PSAPs, 13 county PSAPs, 7 rural PSAPs, 15 urban/suburban PSAPs). Two SRs from Qwest were selected since Qwest serves a large proportion of the population of Minnesota. The SRs selected were in Minneapolis and Rochester. These two sites were selected because they serve the largest population center in Minnesota, and the Rochester SR also serves the Mayo Clinic secondary PSAP. The Minneapolis SR serves the seven county metropolitan area encompassing Minneapolis and St. Paul. Although this area has two SRs deployed for redundancy, the FOT only connected to one. There are 26 PSAPs served by the Minneapolis/St. Paul SRs. Fifteen (15) of these PSAPs were selected to be included in the FOT. The Rochester SR serves 8 primary PSAPs. Three of these PSAPs were selected for inclusion in the FOT with one secondary PSAP (Mayo Clinic) used for demonstration of the end to end call delivery, including the E9-1-1 information such as call back number and location. The PSAPs included are:
Minneapolis SR
Rochester SR
Independent Emergency Services (IES) is a company jointly owned by several independent telephone companies that serve the more rural areas in Minnesota. The Hutchinson Telephone/IES SR was selected because of its proximity to the headquarters of IES (i.e., co-located) and it's proximity to Minneapolis. Four PSAPs (out of nine) were selected in the area served by this SR. The PSAPs selected were:
IES also maintains a test PSAP at its headquarters that was used for integration testing and demonstration purposes.
Figure 2 2 State Wide View of Included PSAPs
Red – IES Service Provider, Hutchinson Selective Router
Blue – Qwest Service Provider, Minneapolis/St. Paul Selective Router (Note: City PSAPs not displayed)
Green – Qwest Service Provider, Rochester Selective Router
2.3 Battelle's Acceptance Plan Overview
Battelle, acting as the independent evaluator of the Mayday/9-1-1 FOT for the USDOT (per the current USDOT policy on field tests), developed a formal acceptance test plan [3]. This section provides a brief overview of the acceptance test plan. The concept of the acceptance test plan is to provide a statistically valid sample of test calls to accept or reject a hypothesis that the probability of failing a test call is less than one percent. The acceptance test plan describes in detail the criteria for considering a test call as a successful call, a failed call or a non-counted call. The category of "non-counted" was created to include calls that encounter a problem that is outside of the control of the FOT team (more will be discussed about this category in the results section). Successful calls are considered to be test calls that are routed to the correct PSAP and provide the PSAP with the location and callback information. A select set of PSAPs (Renville, McLeod, Kandiyohi) served by IES also received the AACN data on the dispatcher's screen. A call would be considered failed if 1) the call is routed to an incorrect PSAP or 2) if incorrect or no 9-1-1 related information is displayed at the PSAP. For the FOT, logs of the 9-1-1 information, crash data, and call set-up messaging at various points in the call was provided to Battelle for detailed analysis. In addition, an electronic form developed by the test call initiator was provided for each test call, recording the test call characteristics, as seen by the PSAP operator and the call initiator (e.g., location).
A multi-stage testing design was used to determine the sample size necessary to test the hypothesis. The multi-stage approach was used to minimize the potential number of calls that may interfere with actual 9-1-1 emergency calls occurring during the field test. Initially, twenty (20) unique test calls were made to 3 PSAPs. If no failures were observed during the first 20 calls, the operational test would begin. However, if one or more failures were observed, the FOT team would have the opportunity to identify and fix the problem before the official start of the operational test. If no failures were observed, the initial 20 calls would be counted as part of the first stage of the statistical design. Each stage of the testing was designed to include 147 calls with either 6 or 7 calls to each of the 22 PSAPs. At the conclusion of each stage, up to a maximum of three stages,, the independent evaluation team would declare the Mayday/9-1-1 FOT stage a pass, fail or inconclusive (i.e., additional stage needed). The decision would be made based on the total number of failures observed. Full details of the pass/fail criteria are contained in the acceptance test plan [3].
3. FOT Test Results
This section provides the results from the FOT testing.
All 147 test calls that were considered valid for the FOT were completed successfully, that is, meeting the required success criteria. These test calls were routed to the correct PSAP and provided the PSAP with the 9-1-1 information expected. The following table shows in detail the dates and numbers of successful/failed calls to each of the selected PSAPs.
Table 1 - Test Dates and FOT Call Results (successful calls/unsuccessful calls)
| PSAP | Aug 10 | Aug 11 | Aug 12 | Aug 15 | Aug 16 | Aug 17 | Aug 18 | Aug 19 |
|---|---|---|---|---|---|---|---|---|
| Meeker | 7/0 | |||||||
| Kandiyohi | 6/0 | |||||||
| McLeod | 7/0 | |||||||
| Renville | 7/0 | |||||||
| Olmsted | 7/0 | |||||||
| Steele | 7/0 | |||||||
| Mower | 6/0** | |||||||
| Anoka | 5/0* | 2/0 | ||||||
| Carver | 7/0 | |||||||
| Dakota | 6/0 | |||||||
| Hennepin | 7/0 | |||||||
| Scott | 7/0 | |||||||
| Washington | 7/0 | |||||||
| Apple Valley | 7/0 | |||||||
| Burnsville | 6/0 | |||||||
| Eagan | 6/0 | |||||||
| Eden Praine | 7/0 | |||||||
| Edina | 7/0 | |||||||
| Lakeville | 7/0 | |||||||
| Minneapolis | 6/0 | |||||||
| St. Paul | 7/0 | |||||||
| Minnetonka | 6/0 |
* Anoka County PSAP had two call instances on the first set of tests where the E2 data was not forwarded from the ALI DB to the PSAP. Logs indicate that the required information was sent from the MPC to the ALI DB for these calls. As such, these initial calls were not counted for the FOT but the corresponding calls were repeated on the last day of testing.
** Mower County PSAP was initially scheduled to receive 7 test calls. However, the last test call of the day did not have the GPS updated due to power being recycled on the OnStar vehicle unit. As such, the last call was retested but the call was made from Washington County instead (Washington was originally scheduled for 6 calls).
Appendix B of this report shows a screen (dual monitor) of the test PSAP at IES headquarters. The screen view shows the information that is passed to the IES ALI DB over the E2 interface from the (Telcordia) Mobile Positioning Center (MPC). This information is received by the Telcordia systems and from the OnStar Lab TCC application, which in turn pulled the data from the vehicle test unit. The view is just as an E9-1-1 PSAP operator would see the information at a live PSAP. The small box in the lower right hand corner of the screen is a special application that IES had developed on their ALI DB and 3 PSAPs to receive the extra AACN data. A sample screen is shown in Appendix B.
A complete set of data was gathered at Telcordia for all test calls. This data consists of:
The XML files and a summary of the call content were provided to Battelle during the FOT testing period at the end of each test day. The above data is available upon request to MNDOT and Telcordia. In addition, the test call initiator provided the completed forms for each test call, describing the call origination information and the PSAP interactions. This form is described in the Mayday/9-1-1 FOT Design Report [4].
3.2 Mayday/9-1-1 FOT Evaluation
Battelle developed the experimental design as part of its comprehensive independent evaluation of the Mayday/9-1-1 FOT. The final evaluation report will highlight several aspects of the project, including the final results.
Based on the Mayday/9-1-1 FOT call routing results as shown in section 3.1 above, and supported by an evaluator's email information described below, the FOT operational team viewed the FOT successful. The final Mayday/9-1-1 FOT evaluation is to be provided in the independent evaluator's report.
This email information below was received, on completing the testing, from the Battelle statistician who was analyzing the FOT calling test results:
A total of 147 acceptance test sample calls were made from August 10, 2005 through August 19, 2005. The sample calls were placed in a variety of geographic locations throughout all 22 PSAPs in the FOT area. Either six or seven calls were placed from each PSAP, reflecting the original sample plan to obtain as closely as possible an equal sample in each PSAP.
The first 20 test calls constituted the Initial Validation phase of the acceptance test. Since all 20 of these calls were successful, in accordance with the acceptance sampling test plan, they were counted toward the Final Validation phase. An additional 127 test calls were then placed to complete the first stage of the Final Validation phase. The 147 total calls represent the first full decision point for the complete acceptance test.
Based on initial review of data, all 147 test calls were successfully routed to the correct PSAP with the correct accompanying data on call back number and latitude and longitude of the sample location from which the call was placed.
Before beginning the test, the system was asserted to have a true failure rate of no more than 1%. The result from this test does not provide evidence to contradict the initial hypothesis and by the provisions of the original acceptance sampling plan, it is concluded that the FOT voice routing function passes the acceptance test criteria. The absence of failures means that the observed failure rate for the system based on this test is 0%. The acceptance test was designed so that it was unlikely (less than 6% probability) that the system would falsely pass acceptance if the true failure rate was greater than 4%.
Note that this is a preliminary conclusion and the final statement will be given in the Evaluator's final report. Additional details of the evaluation will also be provided by the Evaluators in their final report.
3.3 Issues and Lessons from the Mayday/9-1-1 FOT
During the Mayday/9-1-1 FOT testing, several observations were made by the FOT operational team concerning call-related issues where the test calls were not considered as call failures for the purposes of the testing:
In addition to the above issues, setting up the Mayday/9-1-1 FOT environment was a challenge, particularly the connectivity to the live 9-1-1 networks in Minnesota. The trunk connectivity to the SRs and the data connections to the ALI DBs required the use of the 9-1-1 Service Provider interconnection specifications. However, some lack of clarity on the E2-based ALI interface specifications required some added interactions between the Telcordia developers and the ALI providers to make this protocol work properly. The imprecise E2 interface caused error messages at the ALI, resulting in some management/system disruption, until the E2 connections were corrected. This suggests that the ALI interface specifications may need a slight enhancement in clarity.
Since Mayday/9-1-1 FOT network/Telcordia was treated as a carrier interconnecting to the Qwest and Intrado 9-1-1 systems, Telcordia was required to fill out and provide many forms and files to set up the network arrangements, and allow for the provisioning of the SRs and ALI DBs. This turned out to be a challenge since the forms and files are intended for carriers, required precision, and no simple guidance existed to help fill out the required documentation.
A preliminary view indicates that the Mayday/9-1-1 FOT was successful from the viewpoint of the operational team conducting the FOT, in that for all test calls evaluated:
In addition, significant benefit was demonstrated in that all the information and data was transmitted automatically and electronically to the PSAP operator as compared to today’s process where everything is verbally transmitted to the PSAP operator by the TCC operator. TSPECRS will be faster and potentially less error prone in its routing and data/information transmission which would facilitate and improve the response to the emergency. Since TSPECRS uses the same wireless network serving the originating caller, it is expected to be very reliable in routing the emergency call to the caller’s E9-1-1 serving network and appropriate PSAP.
Although the focus of TSPECRS is on supporting the emergency call routing capabilities for Telematics Service Providers, there is potential to use this or similar capability for other centralized service providers that handle emergency situations. This is particularly true since many calls today from the outside or at home use cellular telephones/handsets. Thus, this concept could be applied to any central service provided via telephone at a central call center (e.g., poison control center, suicide hot line, N-1-1 services) who need to reroute calls to a local PSAP on a consistent basis. Further study is required to determine what protocol and system enhancements would be needed to support this additional application.
TSPECRS or a similar concept should be advanced further, including attaining support by the other TSPs, the E9-1-1 community and the appropriate Service Providers. TSPECRS does require enhancements to the wireless Service Provider networks, in addition to the ALI and PSAP enhancements for the AACN support. TSPECRS is one of a number of industry initiatives (e.g., E9-1-1 for VoIP) that are creating E9-1-1 service evolutionary pressures. If the USDOT considers TSPECRS to be a valuable service, it should help coordinate and facilitate the industry process to advance the concept since this is a national issue, must be coordinated with other initiatives, and will help to meet their overall goal of improving highway safety. In addition, state agencies should work with the USDOT in this effort to take into consideration the local E9-1-1 service needs. In addition to the direct industry business and technical interactions, the national standards arena is critical to advance TSPECRS and related E9-1-1 services. In particular, NENA and TIA TR45.2 [for CDMA] would have to be worked to standardize TSPECRS [since OnStar uses Verizon Wireless, a CDMA network]. More detail is provided in Appendix C.
There are other standards activities underway within the US and internationally that may support or compliment the spirit of TSPECRS, or provide an alternative solution. Efforts such as Europe's wireless eCall and NENA's VoIP i2 and i3 solutions should as a minimum be monitored to ensure cross compatibility and evolvability, whenever practical. However, the TSPs should be more proactive and input to the i3 solution to make sure their needs are considered. Appendix C examines each of these initiatives and compares them with the TSPECRS solution. The longer-term vision would be a system of solutions that incorporates the spirit of TSPECRS and other emergency call routing needs that technology is expected to present in the future.
5. References
[1] Telematics Service Provider Emergency Call Routing Service (TSPECRS) System Specification, Telcordia Technologies, SAIC and OnStar, November 14, 2003
[2] Telematics Service Provider Emergency Call Routing Service (TSPECRS) Concept of Operations, Telcordia Technologies, SAIC, July 8, 2004.
[3] Detailed Test Plan - Mayday/9-1-1 Field Operation Test Independent Testing of Voice Routing Functions, Battelle, August 4, 2005
[4] Mayday/9-1-1 Field Operational Test (FOT) Design Report, Telcordia Technologies, SAIC, March 2006.
[5] i2 Solution: Interim VoIP Architecture For Enhanced 9-1-1 Services NENA 08-001
[6] i3 Solution: NENA-VoIP-LTD-i3-Requirements-Draft
[7] eCall in ETSI and 3GPP: http://www.escope.info
[8] Mayday/9-1-1 Field Operational Test Data Routing Concept of Operations Report, Minnesota Department of Transportation, June 1, 2004
[9] Mayday/9-1-1 Field Operational Test Data Routing Project Final Report, Minnesota Department of Transportation, TBD
Figure B-1 PSAP Screen Shot (1 of 3)
Figure B-2 PSAP Screen Shot (2 of 3)
Figure B-3 PSAP Screen Shot (3 of 3)
C. TSPECRS and FOT Architecture Comparison with Standards
This section provides an overview of current standards industry activities relating to E9-1-1 evolution. This covers E9-1-1 standards activities in the wireless and IP-based Next Generation Network (NGN) areas. In particular, there are no specific TSPECRS standards activities to date in the U.S. This section identifies and discusses the various activities that are relevant, or potential alternatives to the TSPECRS solution, and provides some comparative analysis that could support an understanding of the path forward.
This section examines wireless standards that are currently in place or being developed in support of wireless E9-1-1. In addition, this section also examines related industry standards activities in support of the transport of Advanced Automatic Crash Notification (AACN) types of information to PSAPs.
TIA TR45.2 Ad Hoc on Emergency Services (AHES) is the North American Standards body responsible for creating Standards in support of wireless E9-1-1 calls. The deployment of wireless E9-1-1 in North America has been defined in two Phases, Wireless Phase I and Wireless Phase II. Wireless Phase I solutions route 9-1-1 calls to the appropriate PSAP based on the cell site serving the Mobile Station (MS). In Wireless Phase I, the only location information that is received at the PSAP is the location of the cell site serving the MSC. This solution was developed by TR45.2 AHES and was published as TIA/EIA J-STD-034. TR45.2 AHES also developed the Wireless Phase II solution published as TIA/EIA J-STD-036-B. This solution routes wireless E9-1-1 calls to the appropriate PSAP and allows the PSAP to query for MS location information. The solution provides the PSAP with the actual lat/long of the calling MS. The TR45.2 AHES group is currently dormant and may be reactivated if any new work is needed to support wireless E9-1-1 service. The TSPECRS System Specification was based on the Phase II solution. However, the TSPECRS concept has not been brought to this group.
C.1.2 European eCall Initiative
In September 2001, the European Commission released a report on European transport policy titled "European Transport Policy for 2010: Time to Decide." This report set a target of 50% reduction in road fatalities in Europe by 2010. In response to this report, the European Commission established the eSafety Working Group in 2002 composed of automotive industry and other stakeholders. The group proposed 28 recommendations which gave guidelines to accelerate the research, development, deployment, and use of Intelligent Integrated Safety Systems.
One of the recommendations from the eSafety Working Group was to establish a framework to enable in-vehicle emergency calls (eCall). In cases where a vehicle is involved in an accident, an emergency call or e-call can be initiated automatically or manually, and vehicle location and other information can be passed to the PSAP. eCall is being developed such that the call initiated from the vehicle can be an emergency call, dialed as an E112 (European emergency number). The European Commission’s goal is to ensure that all new cars in Europe are equipped with eCall technology as early as 2009 [7].
The technical standards work in support of this initiative is still in its preliminary stages but the following paragraphs provide a general overview of the framework being adopted to progress this work in the European Telecommunications Standards Institute (ETSI) and the 3rd Generation Partnership Project (3GPP) standards arenas. Figure C-1 depicts the eCall architecture that is currently being contemplated.
Figure C-1 eCall Network Architecture
As shown in Figure C-1, when a vehicle is involved in an accident, the in-vehicle system (IVS) generates an emergency call directly to the PSAP. The IVS sets up a call with two separate components, a regular voice call and a data call that contains a minimum set of vehicle data. The eCall (data and voice) is first handled by the wireless networks [GSM - Global System for Mobile Communications ; GSM - Global System for Mobile Communications ] . Additional call information such as Calling Line Identification and caller's location is delivered to the appropriate PSAP for the call. If the IVS user is a subscriber of a private Service Provider (SP), the IVS will also send additional vehicle crash data to the Service Provider for storage to enable subsequent retrieval. The PSAP could access additional crash data from the SP if the IVS user is subscribed to a SP. In addition to location information, the IVS is expected to send the following minimum set of data to the PSAP (regardless of whether the caller is subscribed to an SP):
The Service Provider Identifier is expected to provide enough information to the PSAP to enable the PSAP to get additional crash data from the SP if the user is a SP subscriber. The crash data is not expected to be sent with the call to the PSAP but will available from the SP if the user is a service subscriber.
The decision on the protocols to be used by the vehicle to the PSAP and SP is being discussed. One candidate protocol is the Global Telematics Protocol (GTP). This network architecture is currently under review by major mobile telecom operators. European Telecommunication Standards Institute (ETSI) has been tasked to standardize the interfaces and protocols.
The main difference between the TSPECRS solution and the eCall solution is the role of the TSP. In TSPECRS, an emergency call is first routed to the TSP and a TSP advisor makes the determination of whether the call needs to be routed to a PSAP using a three-way conference call. In the eCall model, the call is first routed to the PSAP and a Service Provider is used only if the user is subscribed to value-added services. In the eCall model, location data and other vehicle identification data are provided directly to the PSAP but vehicle crash data is retrieved if the user is a SP subscriber. In both models, the mobile network is involved determining the appropriate PSAP for the call. As indicated, TSPECRS requires enhancements to all the main elements of the wireless SP network. Since the eCall starts as a 9-1-1 call from the IVS, it is possible that the network impacts for the eCall solution will be less than that for TSPECRS, but there may be a larger impact on the PSAPs, since they must receive data directly from the IVS. A benefit of setting up the call from the IVS is that (if in the US) the wireless Phase II capabilities would provide the location information automatically.
TSPECRS has the TCC operator as part of the 9-1-1 call. The eCall model may have the TCC operator involved in the call later on. This may be an issue, particularly if the vehicle driver is unconscious due to the accident.
The eCall initiative is still in its preliminary stages and work has just begun in ETSI to define the interfaces needed to support the eCall solution. ETSI has begun sending liaisons to other industry bodies such as 3rd Generation Partnership Project (3GPP), which will do protocol. It is expected that changes will be needed to GSM networks in support of this solution. It is important to note that if the eCall solution is adopted in Europe, it implies that GSM carriers will have the required network functionality to support E112 calls from vehicles. This solution could potentially be considered as an alternative to the TSPECRS model if applied to the US wireless GSM networks. Since this work is in its preliminary state, it is hard to determine if the eCall solution has all the functionality required by the TSPECRS model. Since the eCall initiative is still in its preliminary stages, the U.S. industry should participate in this initiative as various components of this solution could be used by the TSP and wireless communities in the U.S. Note that this eCall activity has not been considered by the wireless Code Division Multiple Access (CDMA) and E9-1-1 standards community in TIA and 3GPP2.
C.2 E9-1-1 Evolution in IP-Based Next Generation Networks (NGNs)
Enhanced 9-1-1 (E9-1-1) service is a public safety feature that allows callers to report an emergency or request emergency assistance by dialing the 3-digit telephone number “ 9-1-1.” Emergency calls originated in this manner are then routed to the appropriate Public Safety Answering Point (PSAP) based on the location from which the call originated.
There is currently activity in the industry focused on defining mechanisms to support 9-1-1 call originations from VoIP customers. Because VoIP callers may be fixed, nomadic, or fully mobile, there are a number of challenges associated with providing E9-1-1 service to VoIP callers. As for wireless callers, identification of a nomadic or mobile VoIP caller's location is critical to routing 9-1-1 calls to the appropriate PSAP, as well as facilitating the dispatch of emergency personnel to the caller's location without relying on the caller to provide the location information.
The National Emergency Number Association (NENA) is one industry organization that is in the process of defining solutions that will enable VoIP emergency calls to be routed to and through existing Emergency Services Networks (i.e., current 9-1-1 network infrastructures) to the appropriate PSAP, based on the location of the caller. These solutions describe a migratory path for the support of VoIP-based E9-1-1 service, and are referred to by NENA as i2 and i3.
The VoIP Migratory Working Group (VMWG) of NENA is in the process of finalizing a near-term migratory solution for addressing emergency call originations by VoIP callers, referred to as the i2 Solution [5]. The i2 Solution is expected to support the fundamental E9-1-1 service capabilities that are available to wireline and wireless customers today. For example, the VoIP network must determine and provide access to selective routing functionality to ensure that the call is routed to the appropriate PSAP associated with the caller's location. The VoIP network must provide to the PSAP the necessary callback and customer location information related to the calling party to facilitate the dispatch of the appropriate emergency service personnel to the caller's location. Due to the similarities between 9-1-1 calls originating from wireless callers and those originating from nomadic or mobile VoIP callers, a number of concepts in wireless E9-1-1 have been re-used in the i2 Solution to support 9-1-1 calls from VoIP callers. One such concept is use of a routing/query key, which is the key to the selective routing data accessed by the SR to identify the appropriate PSAP for the call, as well as the key used by the PSAP to query the ALI database. As with wireless Phase II calls, this key will also trigger the ALI database to query a database in the VoIP network, referred to as a VoIP Positioning Center (VPC), to obtain current caller location information. The E2 interface defined for use between ALI databases and wireless Mobile Positioning Centers (MPCs) provides a basis for the exchange of information between ALI databases and VPCs to support the communication of location information associated with VoIP callers.
The i2 Solution being defined by the NENA VMWG, specifies the interconnection of VoIP domains with the existing Emergency Services Network infrastructure for the purpose of routing and delivering emergency calls originated in the IP domain to the appropriate PSAP, based on the caller's location. This solution is described in some detail in a final draft of a document, "Interim VoIP Architecture for E9-1-1 Services (i2)", which is under technical review by NENA.
For emergency calls originated by a VoIP caller in an i2 environment, the Call Server/Proxy is responsible for identifying that a call is an emergency call, based on information received in incoming signaling (i.e., the destination address/dialed digits). The Call Server/Proxy will subsequently launch a routing request to a VPC. The routing request is expected to contain call-related information (e.g., callback number), as well as the current position of the VoIP endpoint that originated the emergency call. (The Call Server/Proxy may include a Location Key instead of location information in the routing request, depending on the VoIP network implementation. The Location Key will then be used by the VPC to determine the location information for the call.) The VPC interacts with an Emergency Services Zone (ESZ) Routing Database (ERDB) to obtain routing information for the call based on the caller's location, and provides the routing information to the Call Server/Proxy. The Call Server/Proxy uses the routing information provided in the response to the routing request (i.e., the Emergency Services Routing Number (ESRN)) to route the call forward. In addition, the Call Server/Proxy will include the Emergency Services Query Key (ESQK), received from the VPC in the routing response, as the caller's identity in outgoing signaling associated with the emergency call. The Call Server/Proxy will route the call to an Emergency Services Gateway (ESGW), which will use the ESRN to select a path to the appropriate E9-1-1 Selective Router (SR) in the Emergency Services Network. The ESGW will signal the ESQK to the E9-1-1 SR as the calling number/ANI for the call. The E9-1-1 SR will use the ESQK to identify the PSAP to which the call should be delivered.
Once the PSAP has been identified, the call will be delivered to that PSAP, along with the query key. The PSAP will use the information received with the call to query an ALI database. Specifically, for emergency call originations in an i2 environment, the PSAP will include the ESQK in the query to the ALI database. The ALI database will then query a VPC to retrieve the location information associated with the call. The ALI database will then return the location information to the PSAP, which in turn conveys this information to the appropriate emergency services agency to support the dispatch of personnel to the caller's location.
Figure C-2 depicts the network elements and interfaces needed to support VoIP emergency call originations.
Figure C-2 i2 Solution Architecture
C.2.1.1 Description of i2 Solution Elements
C.2.1.2 TSPECRS and NENA i2 Solution Comparative Analysis
As described, the NENA i2 Solution uses concepts from the Wireless Phase II 'Wireline Compatibility Mode (WCM)" standard to enable routing of VoIP E9-1-1 calls to the appropriate PSAP. The main driver behind using the WCM model was to ensure that minimal changes are required in the E9-1-1 network and no changes are required at the PSAP to support the NENA i2 Solution. In the i2 Solution, VoIP E9-1-1 calls are treated like Wireless Phase II calls. The ESQK provided with the call is used by the Selective Router to choose the appropriate PSAP, and the PSAP uses the ESQK to retrieve location information from the VPC via the ALI. The VPC is equivalent to the MPC function in wireless networks.
Similarly, the TSPECRS solution uses concepts from Wireless Phase II to set up calls to the appropriate PSAP. The ESRK chosen by the MPC is used to route the calls to the appropriate PSAP and the ESRK is used by the PSAP to retrieve location information. One of the main differences between the i2 Solution and the TSPECRS solution is that the i2 Solution requires new network elements and functionality in the VoIP network while keeping changes in the E9-1-1 network to a minimum. The TSPECRS solution requires changes in the wireless network but keeps changes in the E9-1-1 network to a minimum.
The i2 Solution could potentially be viewed as an alternate solution to deliver calls from TCCs to the appropriate PSAP. In the current TSPECRS model, the TCC uses the wireless SP network to route calls to the appropriate PSAP. The TSP could alternatively use the services of a VoIP Service Provider to route calls to the appropriate PSAP. In the i2 Solution, the VoIP Service Provider (VSP) has a relationship with a VPC provider and an ESGW provider. When the VSP receives an E9-1-1 call, it queries the VPC with location information (either civic location or geodetic location) and the VPC responds with routing information. The VSP uses the received routing information to route the call to the appropriate ESGW which provides the interconnection needed to the appropriate Selective Router. The Selective Router uses the ESQK to route the call to the appropriate PSAP. The TSP could potentially use this same process to get TMS calls to the appropriate PSAP. The TSP could potentially have a relationship with a VSP and route emergency calls to the VSP for further handling. When a TCC gets a call from a TMS, it could forward the call directly to the VSP . The VSP would query the VPC with the received location information (lat/long). The VPC would provide an ESRN and ESQK appropriate for the location of the TMS and would store the received location information. The VSP would then route the call to the ESGW using the ESRN that is provided. Once the call is routed to the PSAP, the TCC would be connected to the PSAP via the VSP network. As previously described, the PSAP would use the received ESQK to query for location information from the VPC via the ALI. The current i2 Solution architecture allows for only location information to be sent to the ALI. If a unique set of ESQKs are chosen for TSP calls, and the appropriate steering information is loaded into the ALI DBs, it is possible to have the appropriate ALI query another database (e.g., NEDR) instead of the VPC to get access to both location data and vehicle crash information. No effort is taking place in NENA to address the enhancement of the i2 Solution to support transport of AACN type of information to the PSAPs.
A possible advantage of using the i2 Solution for supporting TSP calls is that the i2 infrastructure is being developed in support of VoIP. The use of the i2 Solution may be more cost effective than using a solution that is specifically developed for TSPs. This aspect will have to be addressed in technical, business and standards discussions for TSPECRS. Potential disadvantages of going through a secondary network, i.e., VoIP network, to get to the 9-1-1 network will also have to be considered.
The i3 Solution is considered a longer-term solution for supporting emergency call originations by a wider variety of VoIP customers [6]. The i3 Solution assumes end-to-end IP signaling from the VoIP endpoint to an IP-capable PSAP. It is expected that traditional E9-1-1 Selective Routers will no longer be needed in the i3 Solution. Emergency calls will continue to be routed to the correct PSAP based on the location of the caller, but the routing information will be determined by the originating carrier/VoIP Service Provider (VSP), enterprise, or other entity (e.g., an Emergency Services Routing Proxy (ESRP) in an Emergency Services IP Network). The i3 Solution assumes that the location information and callback information will be provided with the call. For the i3 Solution, PSAPs may not have to access an ALI database to get caller location information, they may wish to access other systems and databases to obtain additional data or to access services that will help them to better process emergency calls.\
The NENA Long Term Definition (LTD) Working Group (WG) is in the process of defining the longer-term i3 Solution for VoIP emergency calling. The focus of the LTD WG to date has been on identification of the underlying requirements for the i3 Solution. This section suggests a high-level view of a possible i3 Solution functional architecture, based on the current state of these requirements and on discussions held by the LTD WG. Further work will be needed within the LTD and elsewhere before a comprehensive i3 Solution architecture can be defined.
The goal of the i3 Solution is to provide at least wireline/wireless-equivalent functionality to support emergency call originations from fixed, nomadic, and mobile IP users, and to build on those capabilities to improve performance and extend feature functionality (e.g., delivery of data and text-based emergency service requests to PSAPs).
For the i3 Solution, it is assumed that the existing Emergency Services infrastructure will be transformed, with the functionality currently provided by Selective Routers distributed across multiple components and potentially provided by different entities. It is assumed that an i3 PSAP will support new capabilities, including new signaling approaches to receiving and managing calls, as well as new approaches to receiving or accessing location and other call-related information.
Figure C-3 illustrates a view of the network architecture that the NENA LTD WG has identified to date as being necessary to support end-to-end VoIP emergency calling to i3 PSAPs.
Figure C-3 NENA LTD View of i3 Functional Architecture
C.2.2.1 Functional Elements of the i3 Solution
There are a number of functional elements associated with the i3 architecture that also exist outside of the i3 architecture, and some that are specific to the needs and goals of the i3 Solution. This section describes the various elements of the i3 Solution, and identifies those elements that have counterparts in the i2 Solution that can be used or adapted to support an i3 Solution.
C.2.2.2 TSPECRS and NENA i3 Solution Comparative Analysis
As described earlier, the NENA i3 Solution is under development in the NENA Long Term Definition (LTD) Work Group. One of the basic assumptions made by the NENA i3 Solution group is that the location of the caller will be carried with the call setup signaling and will be delivered to the PSAP with the call. The current NENA i3 requirements recognize the fact that some calls to the PSAPs will be from TSPs and the i3 Solution will allow for this scenario. It is expected that when a TSP bridges a call to an i3 PSAP, the call originated by the TSP will look like a 9-1-1 call. The TSP could use the ECRF to determine routing information to route the call to the appropriate i3 PSAP. It is assumed that the call routed to the i3 PSAP from the TSP will contain location information. The i3 Solution also allows for a key to be sent with a call. The key could be used by the i3 PSAP to retrieve additional information about an incident. For example, the TSP could store vehicle crash data on a database and send the key to retrieve this information by the i3 PSAP. The i3 PSAP could use the key to retrieve this additional data from the TSP or a database shared by TSPs.
TSPs should pay close attention and contribute to the NENA i3 Solution development. Since the i3 Solution is currently being defined, TSPs have an opportunity to ensure that the i3 Solution is developed with their services in mind. A key issue for the TSPs is whether to pursue a TSPECRS solution rather than the i3 Solution, or both. On initial consideration, the TSPECRS solution seems more reliable since it is using the same network as the original TMS call. Cost considerations and the level of wireless industry support may influence pursuit of an i3 Solution or both. The USDOT should support the TSPs in developing a coordinated industry perspective based on strategic USDOT and industry considerations.
Footnote:
[2] In this case, the TCC would require a SIP/IP interface to the VSP and would need to provide the three-way conference calling capability. This solution may facilitate the sending of ACN information through the VSP to the ALI (this implies changes to the i2 Solution to support the sending of ACN information to the ALI).
