2.0    Description of MAYDAY/9-1-1 Field Operational Test

The partners under this FOT included the MnDOT (lead agency), the State of Minnesota 9-1-1 authority, OnStar as a TSP, SAIC as the FOT system integrator, Telcordia Technologies (developed voice routing solution), General Dynamics (developed ACN data routing interface), Coherent Solutions (developed ACN data routing interface), and Castle Rock Consultants (developer of the Condition Acquisition and Reporting System (CARS) and the SOAP server). 

Technical support was acquired from the 9-1-1 service providers Independent Emergency Service (IES) Inc. and Qwest Communications Inc., and Intrado that maintains the Automatic Location Identification (ALI) database for Qwest-supported PSAPs.  In addition, 22 PSAPs and the Mayo Clinic (serves as an Emergency Medical Service (EMS) responder and a secondary PSAP) participated in the conduct of field acceptance testing as well as other evaluation activities.

2.1       The Problems

Routing of TSP-initiated 9-1-1 Calls

The MAYDAY/9-1-1 FOT intended to resolve a set of issues TSPs have encountered in interfacing with the 9-1-1 network.  Such issues stem from the fact that 9-1-1 networks are locally operated while the TSP receives emergency calls from anywhere in the United States.  TSP calls are directed to a central facility (e.g., OnStar Operation Center (OOC) that houses 24-7 Emergency Advisors. 

Upon receipt of a distress call from an instrumented vehicle14, the OnStar Emergency Advisor first connects with the driver over the cell phone built into the TSP vehicle system, then initiates a three-way call with a PSAP corresponding to the vehicle location.  However, these long distance calls from the central TSP emergency call centers to the PSAPs can not be automatically routed due to the local nature15 of the 9-1-1 networks. 

In response to this problem, TSPs must maintain a directory of administrative numbers and the definition of jurisdictional boundaries of some 7,000 PSAPs in the U.S.  This requires the TSPs to constantly verify and update the directory.  Most importantly, emergency calls to a PSAP’s administrative line do not receive the same priority as those placed through the dedicated 9-1-1 trunk line (i.e., native 9-1-1 calls).  These calls also do not automatically transmit critical information such as a call back number (to the telematics-equipped vehicle) and vehicle location that are being required by the wireless Enhanced 9-1-1 (E9-1-1).  Nor are such calls consistent with the intent behind FCC rule making that addresses such needs for wireless 9-1-1 calls.16.

Figure 2-1 provides a graphic representation of the existing OnStar 9-1-1 call procedure without the FOT solution.

Figure 2-1.  OnStar 9-1-1 Call Procedure Without FOT Solution

Lack of Sharing of TSP Crash Data with Emergency Response

A unique resource of the TSP is the wealth of information it possesses on crashed vehicles and occupants.  Such information is potentially beneficial to public safety.  These TSP crash data come from the following sources:

• Data reported from the sensors on the telematics-equipped vehicles (e.g., deployment of airbag, severity of impact (e.g., delta velocity upon impact), rollover, vehicle location by on board Global Position System (GPS) receiver);
• Vehicle and driver data registered with TSP (e.g., basic information on the driver, special medical conditions, vehicle information such as Vehicle Identification Number (VIN), year, make, and color of the vehicle that provide useful clues for emergency response.)

These data are used only by the TSP Emergency Advisors, without violating personal privacy, in assisting three-way communications with the PSAPs during an incident.  However, this requires verbal transcription of a large amount of information which could be error-prone and time consuming.  Nonetheless, the emergency responders would receive this information from the PSAPs (in most instances PSAPs are different from emergency response entities) through further transcriptions.  This suggests a potential benefit for data sharing between the TSP and public safety entities.

2.2       The Field Operational Test Solutions

The MnDOT MAYDAY/9-1-1 FOT intended to develop and demonstrate a solution that could provide automatic routing of the TSP-initiated emergency calls connected to an appropriate PSAP as a native wireless E9-1-1 call with vehicle location data and a call back number provided.  Also, additional information available from a TSP’s ACN or AACN systems can be transmitted to the PSAPs along with the 9-1-1 calls which can be useful in support of incident response.

In parallel with the automatic voice routing, a data routing feature of the FOT transmits TSP ACN and AACN data from OnStar to MnDOT’s SOAP server and can be accessed by authorized users via the CARS.  The provision of additional crash information is expected to enhance decision-making in incident response and management by the Emergency Medical Service (EMS) and MnDOT traffic incident management.

Figure 2-2 presents a high-level architecture diagram of the FOT system.  An extensive discussion of the technical specifications and functional requirements of the FOT solution can be found in the various FOT reports [Ref 1, 2, 3, 4].

Figure 2-2.  High-Level FOT System Functions Illustrated

FOT Voice Routing Solution

The solution for routing the TSP-initiated 9-1-1 calls is called the TSP Emergency Call Routing Service (TSPECRS).  The solution has two components to it:

• Use a WSP network to route the TSP initiated 9-1-1 calls to a local Mobile Switching Center17 (MSC) based on the vehicle location data provided in the TSP calls (e.g., from OnStar Call Center in North Carolina to a MSC in Minnesota where the crash occurred);
• From the local MSC, the TSP 9-1-1 calls emulate a wireless E9-1-1 call and are fed into a local 9-1-1 trunk line and routed to the intended PSAP as a native 9-1-1 call.  In addition, the Automatic Location Identification (ALI) database and the E2 interface that bridges the different 9-1-1 service providers18 were modified to allow transmission of additional data, including call back number, vehicle location (in LAT/LON), and selected ACN and AACN.  A description of data elements included in the FOT voice routing is provided in Section3.2.1.1 Description of Field Test.

A limitation of the FOT voice routing solution relates to the lack of specific functionalities in the Wireless Service Provider (WSP) network in support of the proposed TSP emergency call routing.  This was explained in the FOT Concept of Operation and Design documents [Ref 1, 2].  Despite the technical feasibility, the deployment of the WSP specific call routing function was cost prohibitive.  Such functionalities were simulated in a lab environment provided by Telcordia in support of the FOT.

FOT Data Routing Solution

The FOT data routing implementation was relatively straight forward.  To share ACN and AACN data, a secured data connection between the OnStar data server and MnDOT’s SOAP server was established using the industry standard eXtensible Markup Language (XML) interface.  The SOAP server is accessed by MnDOT’s CARS that can be accessed by the authorized users.  Figure 2-2 (bottom portion) illustrates the connections between subsystems in support of the data routing.

Upon receiving a distress call from OnStar-instrumented vehicles in the state of Minnesota, the available crash data (SOS, ACN, or AACN) is pushed from OnStar to MnDOT SOAP server and further pushed to CARS server.  The role of the SOAP server is a “data broker” and thus has limited logical processing capability (e.g., performing complex rules for screening certain data elements).

In this FOT, CARS provides the interface for the end users of OnStar crash data, including authorized MnDOT staff/facilities and Emergency Medical Services (e.g., Mayo Clinic).  It is important to note that CARS is a system deployed by MnDOT originally to support the collection and dissemination of road condition data.  CARS is an Internet-based system.  That is, an authorized user can access CARS using an Internet browser with a password.  The majority of CARS users are within MnDOT (e.g., districts and traffic management facilities) and few are outside of MnDOT (e.g., Mayo Clinic).  The FOT data routing included OnStar crash data as part of the accident events in CARS.  The OnStar data can be viewed by all authorized CARS users along with other road condition-related events.  Figure 2-3 illustrates how OnStar crash data are displayed in CARS.  Table 2-1 summarizes the data obtained from OnStar in support of data routing.

Table 2-1.  OnStar Data in Support of Data Routing

When OnStar data are received by CARS, they are organized in the standard CARS data fields including:

Location – contains the LAT/LON in the OnStar data;

Key phrase – contains the best descriptor of the event (e.g., “accident” is used for all OnStar events);

Start/end time or duration – a default value of one hour20 is assigned to OnStar events.  The expired events are automatically removed from and archived by the CARS;

Additional information – is a free-form text comment field that includes summary text of all available OnStar crash data as discussed in Table 2-1.  This information is displayed when an OnStar event is selected by clicking on the accident icon, as shown in Figure 2‑3.

Figure 2-3.  Sharing of ACN and AACN Data on CARS

2.3       Overview of Field Operational Test Solutions

This section provides an overview of the field tests involved in the FOT.  More details of the test procedures can be found in Section 3 – Evaluation Approach and Section 4 – Evaluation Findings.  There were two components to this FOT: the field testing of the automatic voice routing of Telematics-initiated 9-1-1 calls, and a demonstration of the dissemination of OnStar crash data on MnDOT’s CARS.

Voice Routing Field Test

After the TSPECRS voice routing system was developed and preliminarily tested, a formal field acceptance test was conducted.  The acceptance test was designed based on a statistical sampling framework developed by Battelle.  The objective was to assess system reliability in terms of expected maximum system failure rate.  The evaluation and FOT teams agreed that the acceptance test must be conducted using simulated calls, instead of live OnStar emergency calls.  This decision was based on the concerns of potential liability and logistical21 issues involved.

The field acceptance test required MnDOT to provide a field test engineer to initiate simulated OnStar calls at pre-determined (thus verifiable) locations.  Such calls were made from a portable unit that provides the same functionality as those installed on an OnStar-equipped vehicle.  OnStar Emergency Advisors were trained to answer the test calls and establish a three-way call, using TSPECRS, with the participating PSAP.  Twenty-two PSAPs in the state of Minnesota participated in the acceptance test.

When the test call finally reached the PSAP, the MnDOT test engineer verified with the 9-1-1 operator, over the cell phone built in the portable OnStar unit, to determine if the correct PSAP was connected as well as the call back number and location data transmitted along with the call.  The testing process was facilitated by Battelle, and all paper and electronic logs were independently audited and results assessed with the FOT team.  The field test was conducted over a ten day period in August of 2005.  More details on the statistical sampling design, test procedure, and results are presented in Section 3 - Evaluation Approach and Section 4 – Evaluation Findings.

Data Routing Demonstration

The data routing system is functionally independent from the TSPECRS.  Live OnStar crash events in the state of Minnesota were used to support the data routing demonstration during the FOT period.  The FOT successfully demonstrated the transmission of live OnStar crash data to MnDOT’s SOAP server and further disseminated to end users (MnDOT and Mayo Clinic) via CARS.  The data routing demonstration lasted from October 15, 2004 to September 1, 2005.  The evaluation of data routing was focused on the performance (in terms of reliability and latency) of data communications between OnStar and MnDOT SOAP servers.