Executive Summary

The Minnesota Department of Transportation (MnDOT) conducted a federally funded Field Operational Test (FOT) to develop and test a MAYDAY/9-1-1 system.  The system automatically routes 9-1-1 calls initiated by Telematics Service Providers (TSP) to an appropriate Public Safety Answering Point (PSAP) based on vehicle location information provided by the instrumented vehicles.  This FOT voice routing solution is called TSP Emergency Call Routing Service (TSPECRS).  In addition, the Automatic Crash Notification (ACN) or Advanced Automatic Crash Notification (AACN) data from the TSP are shared in real-time with MnDOT in support of emergency response and management via the Conditioning Acquisition and Reporting System (CARS1).

Battelle, in association with the Melcher Group, was under contract to the Intelligent Transportation System (ITS) Joint Program Office (JPO) of the U.S. Department of Transportation (USDOT) to conduct an independent evaluation of the MAYDAY/9-1-1 FOT.  This national evaluation was performed under Battelle’s contract DTFH61-02-C-00134, Task BA34010 with the USDOT.

The scope of this evaluation is to conduct an acceptance test on the voice routing system, TSPECRS; perform an analyses on ACN/AACN data routing, solicit feedback from the users of the voice and data routing systems, and identify potential deployment issues.  This evaluation report documents the process, results, and issues encountered in this FOT, from which lessons learned can be drawn to provide guidance for the future deployment of this or a similar system.

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 vehicle2, 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 nature3 of the 9-1-1 networks.

In response to this problem, OnStar must maintain a directory of administrative numbers and the definition of jurisdictional boundaries of some 7,000 PSAPs in the U.S.  This requires OnStar to constantly verify and update the directory.  Most importantly, emergency calls to a PSAP’s administrative line may 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 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 (also known as E9-1-1) initiative4.

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

Figure E-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.

The Field Operational Test Solutions

Figure E-2 provides an illustration of the proposed FOT solutions.  These solutions are discussed below.

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 Wireless Service Providers (WSP) network to route the TSP initiated 9-1-1 calls to a local Mobile Switching Center5 (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 providers6 were modified to allow transmission of additional data, including call back number, vehicle location (in LAT/LON), and selected ACN and AACN. 

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

A limitation of the FOT voice routing solution relates to the lack of specific functionalities in the 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 E-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 the MnDOT SOAP server and further pushed to the 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).

Evaluation Scope

The scope of this evaluation, based on discussions with the FOT team and NHTSA, was determined to be:

• Conduct of a voice routing system acceptance test to assess the performance of the FOT solution for automated routing of the Telematics-initiated emergency calls to an appropriate PSAP as a native 9-1-1 call along with a call back number and call location data;
• As an ancillary interest, assess the performance of a data routing system that transmits available crash data from OnStar operation center to MnDOT for further distribution to users of the CARS; and
• Conduct a review of user acceptance and potential deployment issues.

Voice Routing Acceptance Testing Results

Description of Field Acceptance Test

A statistical acceptance sampling plan (Appendix A) was developed to assess voice routing performance.  The plan identified the testing to be performed, the measures of success or failure, and the potential conclusions about overall system acceptance test performance.  Depending on the acceptance test results, two different conclusions were possible:

• The system passes acceptance testing.  If this conclusion was reached, depending on the exact sample results, it would be highly probable (94 percent7confidence) that the overall system failure rate was at or below four percent or that it was at or below five percent.

• The system fails acceptance testing.  If this conclusion was reached, it would be highly probable (94 percent confidence) that the overall system failure rate exceeded one percent.

The acceptance test calls were carried out by MnDOT staff in the 22 FOT PSAPs over a ten day period in August of 2005.  On each sampling day, MnDOT staff proceeded to each planned location with a laptop computer (to simulate ACN/AACN data) and a portable OnStar test unit.  These are shown in Figure E-3.

Figure E-3.  Portable OnStar Test Unit in Support of Voice Routing Field Test

The MnDOT staff placed a call to the OnStar call center.  OnStar established a three-way call with the PSAP of the originating call location as a wireless 9-1-1 call.  This was done in the FOT through a laboratory environment (Telcordia) simulating a call in a wireless service provider network.  The PSAPs were alerted that this was a test call so that they could defer it if there were any true 9-1-1 calls coming through at the same time.  The PSAP was then asked to identify its location and what data it had received on the incoming test call.  Figure E-4 below provides a visual example of the data coming in to the PSAPs.  This specific image is unique to PSAPs with Independent Emergency Services (IES) as the service provider.

After completing each call, the MnDOT staff recorded required information on a data collection form then moved to the next sample location.

Voice Routing Acceptance Test Findings

• A total of 147 acceptance test sample calls were made from August 10, 2005 through August 19, 2005.  Either six or seven calls were placed from each of the 22 PSAPs, reflecting the original sample plan to obtain as closely as possible an equal sample in each PSAP.  All 147 of the acceptance sample calls passed the acceptance test criteria. 

Figure E-4.  Sample PSAP Incoming Call Screen (IES)

The FOT passed acceptance testing with 94% confidence that the true system failure rate is no more than four percent.

• Those test calls were delivered along with vehicle location data (LAT/LON), call back number (to OnStar unit), and ACN/AACN data (on IES supported PSAPs only). 
• For the 20 acceptance sample calls made to PSAPs with the Mayo Clinic as secondary PSAP, the Mayo Clinic PSAP correctly received the call back number and latitude/longitude coordinates of the sample calls in all cases.

Data Routing Performance Evaluation Results

The data routing portion of the FOT sought to develop and test a system for a telematics service provider (e.g., OnStar) to push ACN and AACN data into a MnDOT SOAP server for further distribution to CARS. 

Due to data availability, this evaluation only examined the performance of the first link of the data distribution between OnStar and SOAP server, as illustrated in the bottom portion of Figure E-2.  The system performance is defined as the reliability and latency of the data transfer.  Different from the voice routing evaluation, the data routing involved the transmission of actual OnStar crash data throughout the state of Minnesota.

Data Routing Evaluation Summary of Findings

• Over 41 weeks for which data were available, OnStar successfully transmitted 1,247 crash records to the MnDOT SOAP server, including 1093 SOS (emergency button pushing), 137 ACN, and 17 AACN crash records.
• Analyses of transmission logs indicated a small percent (3.9) of records failed in the transmission.  However, those failures were attributable to known technical problems that arose during the FOT period (see Section 4.2.1).  The FOT data routing solution has demonstrated a high reliability of 96.1%.
• The mean latency for data transmission from OnStar to MnDOT SOAP server is 0.9 seconds.

User Acceptance and Deployment Issue Evaluation Results

PSAP, Emergency Medical Service, Traffic Management Feedback

• Few of the PSAPs maintained 9-1-1 call history data in sufficient detail to statistically compare historical operational experiences with trial events.  However, based upon experience, all indicated a preference for native 9-1-1 call delivery for such calls, noting that the latter insures more accurate routing, the automatic delivery of call-related data (like Automatic Number Identification8 (ANI), ALI9 and class of service10) and priority processing (i.e., call into 9-1-1 trunk as opposed to the administrative line).
• Most PSAPs were either wireless 9-1-1 Phase II ready, or deployed with one or more carriers11.  That is, they are able to receive wireless 9-1-1 calls with a call back number and call location (LAT/LON) provided.  The FOT calls were designed to emulate a wireless 9-1-1 call and thus can display call back number and location with Phase II ready PSAPs. 
• Several of the PSAPs continue to work on mapping and GIS resources to support the processing of wireless-based calls.  The GIS tool is part of the wireless 9-1-1 PSAP solutions to make use of the call location data for visual representation using electronic maps.
• While limited, most PSAPs had historically received telematics-based emergency calls (including OnStar) on the administrative line, and they cited positive experiences and outcomes with those calls.  Also cited was the unique capability for OnStar emergency advisors to remotely flash the vehicle head lights in assisting the identification of the crashed vehicle, in the case of run-off-the-road accidents with unconscious drivers.  In addition, OnStar Emergency Advisors can provide continuous update of vehicle location for incidents involving a moving vehicle (e.g., car-jacking).
• Most PSAPs stated that the location of the calling party provided by telematics service providers (historically, and, as part of the FOT) appeared to be accurate.  Historically, the location information was described by the OnStar Emergency Advisor as the street address, or in the case of rural area, the main route and the nearest cross street or landmark.  The FOT automatically provided the location data in LAT/LON that can be plotted using a GIS tool – conceivably a less time consuming and less error-prone approach.
• All the PSAPs interviewed currently receive telematics-initiated calls on so-called “administrative lines,” or on non-native 9-1-1 trunks dedicated for such purposes.  In all instances, while calls on these lines are processed identically to native 9-1-1 calls, they do receive lower call-handling priority than calls on 9-1-1 trunks (though that only becomes an operational issue when 9-1-1 call-takers are busy on other calls).  Since such lines generally do not automatically provide ANI and ALI data, the PSAPs involved attempt to capture the “caller ID” of the calling party, and then poll their ALI database for location.  There is a limitation of OnStar-initiated three-way calls in that they only display the number of the OnStar Operation Center in the caller ID, not the cell phone number of the crashed vehicle. 
• A few PSAPs noted that a telematics-initiated call involving a three-way conversation between the calling party, the telematics service center, and the PSAP can be complicated, but beneficial with training.
• The Minneapolis/St. Paul Metropolitan Emergency Services Board noted that the FOT voice delivery solution appeared to be a clean solution, minimizing infrastructure requirements and impact on existing 9-1-1 network configurations.
• PSAPs served by Independent Emergency Services (IES) were able to receive advanced ACN data as part of the FOT.  Kandiyohi County (as the IES PSAP involved in the interviews) cited the importance of such data in processing an ACN-type emergency event, though the use of such enhanced data will require additional call-taker training.
• In a few instances, where FOT test calls failed to execute as planned, it appeared that the casual factors were outside the scope of the trial, and thus did not negatively impact the results of the FOT.
• Mayo Medical Transport, as both a secondary PSAP and a CARS data user, specifically cited the benefit of ACN/AACN incident data in responding to an emergency event.  While the CARS data are limited, as is the means of access, the timely notification of an incident, along with descriptive data about the event, does facilitate emergency response.
• All interviewees agreed that the FOT appeared to reflect a successful solution to delivering a telematics-initiated 9-1-1 call to the appropriate PSAP over the existing 9-1-1 infrastructure with a call back number and call location.
• All interviewees also agreed that exploring and fostering the wider deployment of such a solution would be beneficial, both within Minnesota and elsewhere.
• The Regional Transportation Management Center (RTMC) in Roseville, MN makes effective use of the CARS data, both in support of traffic management during incidents and Department of Public Safety’s (co-located with RTMC) emergency response.  This center is a model for similar efforts around the country.
• The OnStar ACN/AACN data on CARS supplements the information and many resources currently possessed by the RTMC in support of traffic-related incident management.  Such resources include the large number of traffic detectors and Closed Circuit Television (CCTV) cameras for detection and verification of incidents, and the ability to control traffic signals and provide traffic advisories using Dynamic Message Signs (DMS), the MnDOT web site, and the 511 traveler information system. 

Telematics Service Provider Feedback

OnStar, as the telematics service provider involved in the FOT, has a long history servicing customer emergency calls and interacting with the 9-1-1 community.  The Emergency Advisors receive special training in processing such calls, and specifically interfacing with 9-1-1 call takers.  The following is a summary of the interview findings: 

• OnStar’s experience in processing customer 9-1-1 calls has been positive, as has been their working relationship with the 9-1-1 community and PSAPs.
• While the current process of handling 9-1-1 destined calls works (i.e., calling into PSAP administrative lines), the FOT solution would provide a more effective way of accomplishing the same task for the reasons cited elsewhere in this report.
• In spite of the perceived benefits of the FOT solution, OnStar indicated the need to preserve the ability to contact the PSAP via the administrative line, citing a significant portion of customer requests or events are of non-emergency nature.
• The data routing portion of the FOT was perceived as a success.  OnStar indicated increased demands in recent years to provide their data to the Department of Transportation (of various levels) and emergency response community in light of management of regional natural disaster-related events.
• The deployment of FOT voice routing solution would involve significant cost, a factor impacting the potential adoption and rollout of the approach nationwide.  It was evident that the WSP-specific call routing solution was cost prohibitive and a simulated approach must be used by the FOT.  The cost for implementing and operating such a nation-wide system is disproportionately high considering the very small representation of telematics-initiated 9-1-1 calls.  OnStar suggested broadening the users of the FOT solution to include other national security or regional public safety entities that require long distance routing of 9-1-1 calls.

• It was unfortunate that the voice routing portion of the FOT ultimately was not able to use a real wireless service provider, and was forced to simulate those functions within a lab environment.  While the simulation did not negate the results of the FOT, it did impact the “field” emphasis of the operational test.
• While the setup of the FOT voice routing required an OnStar Emergency Advisor to manually dial a Temporary Location Directory Number (in order to route the call to the simulated WSP hosted in Telcordia’s New Jersey facility), it was noted that that part of the process could be easily automated.
• Considerations should now be given to real world deployment of the FOT solution, recognizing wireless network functionality and impact, cost, and migration to NG9-1-1 IP-based infrastructure.

Third-Party Technical Expert Feedback

In accordance with the evaluation plan, the FOT concept, technical design, and results of the FOT were reviewed with Mr. Roger Hixson, NENA’s Technical Issues Director.  The interview specifically related to NENA’s work in the area of Next Generation E9-1-1 systems, recognizing that the latter will ultimately generate or facilitate enhanced solutions for the objective of this FOT. 

Mr. Hixson observed that, while the design involved would require new TSPECRS-specific functionality in the wireless network, a potentially challenging matter in light of evolving wireless networks, the concept and solution being tested by the FOT represented a “viable interim method” to automatically route emergency calls being generated by customers through telematics call centers to “native enhanced 9-1-1 systems in the USA.”  Ultimately, Mr. Hixson indicated, IP based, NG 9-1-1 systems are likely to offer “more effective and seamless solutions for ACN calls and basic data delivery, and subsequent PSAP access to supportive data from Telematics provider databases.” 

FOT Deployment Team Feedback

• While the development of TSPECRS voice routing was challenging, the field test was conducted successfully, and the concept/solution involved does represent a viable approach for delivering telematics-based emergency calls to the PSAP as native 9-1-1 calls.

• Several technical issues did arise during the voice routing field test, but they related to factors either outside the scope of the project, or beyond operational control of the project team.  Consequently, such calls were not considered failures.  For example, test calls transmitted incorrect LAT/LON were caused by incorrect use of the portable OnStar test unit and thus not counted as failures.  This was discussed under the non-counted calls in Section 4.1.1.

• The TSPECRS test experiences emphasized the need for robust and redundant networks to support reliable call delivery.
• 9-1-1 call relay at the telematics provider service center should be automated to avoid manual miss-dials, a feature consistent with the intent of this FOT (i.e., to automate as much of the call delivery process as possible).
• Beyond the native delivery of 9-1-1 calls, the system also provides an opportunity to deliver additional emergency event information and data important to emergency response.
• The opportunity for real world deployment should be examined further, particularly as a migratory step to NG9-1-1 network infrastructure that may ultimately provide long-range solutions to accomplishing the goals of the FOT.

Conclusions

FOT voice routing solution, TSPECRS, passed the acceptance test

Using a statistical acceptance sampling approach, the FOT solution passed the acceptance test with no observed failures.  A sequential sampling approach was used to determine if the FOT solution passed acceptance.  Ultimately, this approach resulted in high confidence (i.e., 94 percent) that the true system failure rate does not exceed a relatively low value (four percent).  The true system failure rate may well be even lower (e.g., the observed failure rate was zero percent), but the sample size available for the test was only sufficient to make conclusions at a level of four percent.

FOT voice routing solution leverages the phase 2 E9-1-1 implementation 

The FOT voice routing solution relies on a wireless service provider to route long distance 9-1-1 calls originated from a TSP to a local MSC corresponding to the LAT/LON of the vehicle location.  From there, the calls enter the 9-1-1 trunk using a modified E2 interface and emulate a wireless E9-1-1 call.  This allows a phase 2 compliant PSAP to receive the calls as a native 9-1-1 call along with the LAT/LON of the vehicle location, and a call back number (to the telematics unit).

With the exception of WSP call routing, the final segment of the call delivery solution is consistent with the phase 2 E9-1-1 initiative.  Feedback from the FOT team suggested that minor clarifications of ALI interface are needed due to the ambiguity in current E212 interface definition, in support of the call and data routing on the local 9-1-1 trunks.

The implementation of WSP call routing will require additional standards13 development and commitments from a WSP to implement the solution on all switches across the U.S.  Given the competition from other standards development activities in the telecommunication community, the telematics-specific standards might not receive priority because of its small market share.  Nevertheless, the FOT solutions are technically feasible and are consistent with wireless E-9-1-1 standards in the final call delivery stage.

It is noted, however, that WSP migration to Third and Fourth Generation wireless service may facilitate this process by providing more effective and flexible switching and routing platforms for such matters.

FOT data routing achieved high reliability

Over the 41 week period of the operational test, the FOT demonstrated it could reliably and quickly transmit OnStar crash data to a MnDOT SOAP server, from where it could be accessed by CARS and other third parties.  The reliability was 96.1% and the few failures observed were traced to a known computer problem that would not be expected to occur in a production system.  The average latency of data transmission was less than one second (i.e., 0.9 seconds).

The data routing evaluation reflects only a portion of the system’s reliability from an end user perspective since it does not include information for the links between the MnDOT SOAP server and other servers that ultimately make the information available to users (e.g., CARS).  Nevertheless, it can be concluded that the first step in the data routing process does not introduce any lack of reliability or speed.

Favorable user acceptance to the FOT voice routing service (PSAP)

The PSAP user community generally found both the intent and nature of the trial to be beneficial to the effective delivery of a telematics-based emergency call that must be delivered to a Public Safety Answering Point.  The routing of such calls to the correct PSAP is more accurate and reliable, and the time involved to process the calls is minimized by automatically identifying the location.  The native delivery of calls in this manner also insures that the calls involved will receive the same priority as any other 9-1-1 calls.

While nearly all the PSAPs involved in the trial indicated positive historical experiences with OnStar calls, they also indicated that this type of delivery would enhance service and minimize confusion in terms of the description of location.

FOT data routing solution is a cost effective way for sharing ACN data

While the migration of the emergency response community to next generation IP-based network infrastructure may provide the ultimate solution to sharing voice and data conducive to emergency services, the data sharing mechanism utilized in the FOT does provide an effective and immediate way to take advantage of data generated during a telematics emergency event.  Deploying new and advanced network infrastructure may take time, particularly in a ubiquitous way, this FOT offers an immediate step in that direction.

This solution can be deployed with minimum cost, and states should explore the opportunity represented here to take advantage of their highway and traffic information systems to benefit both incident management and emergency response.

FOT voice routing benefits OnStar operations

Finally, FOT voice routing capability substantially enhances the quality of service OnStar provides to its customers.  Having the service available in times of emergency is an important reason why many customers subscribe to the telematics service.  Insuring more accurate and timely response to customer emergency requests improves the service involved.  It also enhances the opportunity for a mutually beneficial relationship with the PSAP community, a matter of equal importance.