automatic collision notification and vehicle telematics ......2.2.3 telematics data and sources...
TRANSCRIPT
05/05/2016: This document is not subject to further review or
revision, but is available as a reference.
Automatic Collision Notification
and
Vehicle Telematics
Technical Information Document
(TID)
NENA Technical Information Document
NENA 07-504, June 1, 2007
Prepared by: David Irwin
National Emergency Number Association (NENA) and Non-traditional Communications Committee
Published by NENA
Printed in USA
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 2 of 44
NENA
TECHNICAL INFORMATION DOCUMENT
NOTICE
The National Emergency Number Association (NENA) publishes this document as an information
source for the designers and manufacturers of systems to be utilized for the purpose of processing
emergency calls. It is not intended to provide complete design specifications or parameters or to
assure the quality of performance for systems that process emergency calls.
NENA reserves the right to revise this TID for any reason including, but not limited to:
conformity with criteria or standards promulgated by various agencies
utilization of advances in the state of the technical arts
or to reflect changes in the design of network interface or services described herein.
It is possible that certain advances in technology will precede these revisions. Therefore, this TID
should not be the only source of information used. NENA recommends that members contact their
Telecommunications Carrier representative to ensure compatibility with the 9-1-1 network.
Patents may cover the specifications, techniques, or network interface/system characteristics
disclosed herein. No license expressed or implied is hereby granted. This document shall not be
construed as a suggestion to any manufacturer to modify or change any of its products, nor does this
document represent any commitment by NENA or any affiliate thereof to purchase any product
whether or not it provides the described characteristics.
This document has been prepared solely for the voluntary use of E9-1-1 Service System Providers,
network interface and system vendors, participating telephone companies, etc.
By using this document, the user agrees that NENA will have no liability for any consequential,
incidental, special, or punitive damages arising from use of the document.
NENA’s Technical Committee has developed this document. Recommendations for change to this
document may be submitted to:
National Emergency Number Association
4350 North Fairfax Drive, Suite750
Arlington, VA 22203-1695
800-332-3911
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 3 of 44
Acknowledgments:
This document has been developed by the National Emergency Number Association (NENA) Non-
traditional Communications Technical Committee and its ACN Sub-committee.
The following industry experts and their companies are recognized for their contributions in
development of this document.
Members: Company
David Irwin – Non-Trad Vice Chair – ACN
Telematics Chair
Washington State E911 Program Office
Tony Busam – Chair Non-Trad RCC Consultants, Inc.
David Acton – Vice Chair ACN/Telematics Connexis
Cynthia Manley Cross Country Auto
David Aylward COMCARE
Bob Gojanovich HBF Group
Dick Dickinson TCS
Dwight Purtle Johnson County Kansas Emergency Communications
Edward Willhaus Noblis
Gail Wicks Intrado
Gordon Gipson Doctor 911 Consultant
Holly Barkwell-Holland Fire Monitoring Technologies International Inc.
John Hunt AT&T
Kevin Dopart Noblis
Michael Ceglia MJC Thomas, Inc.
Nancy Pollock Minnesota Metropolitan 911 Board
Robert Miller Miller and Miller, LLC
Robert Iwaszko Verizon Wireless
Doug Rollender Lucent
Sheryl Wilkerson Ygomi
William Ball OnStar
William Italia OnStar
Thomas Madden Verizon Wireless
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 4 of 44
TABLE OF CONTENTS
1 EXECUTIVE OVERVIEW ............................................................................................................................... 6
1.1 PURPOSE AND SCOPE OF DOCUMENT ............................................................................................................... 6 1.1.1 Telematics Services ..................................................................................................................................... 6 1.1.2 Emergency Services .................................................................................................................................... 6 1.1.3 Telematics Call Centers .............................................................................................................................. 6
1.2 REASON TO IMPLEMENT ................................................................................................................................... 7 1.3 BENEFITS ......................................................................................................................................................... 7 1.4 DOCUMENT TERMINOLOGY .............................................................................................................................. 7 1.5 REASON FOR ISSUE ........................................................................................................................................... 7 1.6 REASON FOR REISSUE ...................................................................................................................................... 7 1.7 DATE COMPLIANCE .......................................................................................................................................... 8 1.8 ANTICIPATED TIMELINE ................................................................................................................................... 8 1.9 COST FACTORS ................................................................................................................................................. 8 1.10 COST RECOVERY CONSIDERATIONS ................................................................................................................. 8 1.11 ACRONYMS/ABBREVIATIONS ........................................................................................................................... 8
2 TECHNICAL DESCRIPTION ....................................................................................................................... 10
2.1 VEHICLE TELEMATICS .................................................................................................................................... 11 2.1.1 Vehicle Telematics Participants ............................................................................................................... 11 2.1.2 Telematics Services ................................................................................................................................... 11 2.1.3 Emergency Services .................................................................................................................................. 11 2.1.4 Navigation Services: ................................................................................................................................. 12 2.1.5 Convenience Services: .............................................................................................................................. 12 2.1.6 Vehicle Services: ...................................................................................................................................... 12 2.1.7 Dealer/Manufacturer Services: ................................................................................................................ 12
2.2 CURRENT TSP CALL CENTER OPERATIONS .................................................................................................... 13 2.2.1 TSP to PSAP Call Flow Diagram ............................................................................................................. 14 2.2.2 TSP Call Center Protocols ....................................................................................................................... 15 2.2.3 Telematics Data and Sources ................................................................................................................... 15 2.2.4 Data that may be received from the vehicle involved in an incident: ....................................................... 15 2.2.5 Data Maintained at the TSPs Call Center May Include: .......................................................................... 16 2.2.6 Databases That May be Maintained by Others and Remotely Accessed to Provide Data During the Incident:
17 2.2.7 Real-time Supplemental Data Sources That May be Available on Demand as needed During an Incident:
17 2.3 TSP/PSAP COMMUNICATIONS ....................................................................................................................... 18
2.3.1 Location and Callback Number ................................................................................................................ 18 2.3.2 Telematics Calls ....................................................................................................................................... 18
2.4 COMMUNICATIONS STANDARDS ..................................................................................................................... 19 2.4.1 National Mayday Readiness Initiative (NMRI) - Standards ..................................................................... 19 2.4.2 Vehicle to PSAP Communication ............................................................................................................. 20 2.4.3 Delivery Outcomes ................................................................................................................................... 20 2.4.4 Network Considerations ........................................................................................................................... 21
2.5 SUGGESTED COMMUNICATIONS PLANS .......................................................................................................... 21 2.6 NENA NG9-1-1 ............................................................................................................................................. 22
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 5 of 44
2.7 ENVIRONMENTAL CHANGES IMPACTING 9-1-1 ............................................................................................... 23 2.7.1 Network Considerations ........................................................................................................................... 23 2.7.2 Analog Telematics .................................................................................................................................... 23
2.8 INDUSTRY PARTICIPANTS MAY IMPACT TSP-TSP COMMUNICATIONS ........................................................... 23 2.9 SUMMARY ...................................................................................................................................................... 24
3 EXHIBITS ........................................................................................................................................................ 24
3.1 NATIVE 9-1-1 DELIVERY USING A POSITION SERVER (INTRADO INC.) ............................................................ 24 3.1.1 Overview ................................................................................................................................................... 24 3.1.2 Solution Description ................................................................................................................................. 25 3.1.3 Call Flow .................................................................................................................................................. 26 3.1.4 Support ..................................................................................................................................................... 28 3.1.5 Benefits ..................................................................................................................................................... 28
3.2 REMOTE CONFERENCE CALLING (MJC THOMAS INC.) ................................................................................... 28 3.2.1 Overview ................................................................................................................................................... 28 3.2.2 Remote Conference Calling Procedure .................................................................................................... 29 3.2.3 Application ............................................................................................................................................... 29 3.2.4 Impact ....................................................................................................................................................... 31 3.2.5 Advantages ............................................................................................................................................... 31
3.3 ACN COMMUNICATIONS USING TTY (ACNOVATIONS) ................................................................................. 31 3.3.1 Overview ................................................................................................................................................... 31 3.3.2 Background .............................................................................................................................................. 32 3.3.3 Introduction .............................................................................................................................................. 32 3.3.4 Application ............................................................................................................................................... 33 3.3.5 Impact ....................................................................................................................................................... 37 3.3.6 Advantages ............................................................................................................................................... 38 3.3.7 Reference Notes ........................................................................................................................................ 38
3.4 NATIVE 9-1-1 DELIVERY USING VOICE OVER INTERNET PROTOCOLS (VOIP), (TCS) .................................... 40 3.4.1 Overview ................................................................................................................................................... 40 3.4.2 Solution Description ................................................................................................................................. 41 3.4.3 Call Flow .................................................................................................................................................. 42 3.4.4 Benefits ..................................................................................................................................................... 43
4 REFERENCES ................................................................................................................................................. 44
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 6 of 44
1 Executive Overview
1.1 Purpose and Scope of Document
The purpose of this “Automatic Collision Notification and Vehicle Telematics Technical
Information Document” is to understand and describe in both technical and operational terms the
current telematics industry and telematics emergency calls and associated information delivered to
Public Safety Answering Points (PSAPs). The document scope also reflects on the current 9-1-1
infrastructure, the next generation emergency networks, and it discusses the integration of telematics
emergency calls and information into those networks. This Technical Information Document (TID)
will provide information to allow the National Emergency Number Association (NENA) and other
interested parties to develop new communications methodologies and protocols to facilitate
emergency communications between Telematics Service Providers (TSP) and PSAPs.
1.1.1 Telematics Services
A variety of services are available through telematics suppliers. Some services are only available
using specific equipment and/or service vendors. Generally the services fall in five categories:
emergency, navigation, convenience, vehicle, and dealer/manufacturer services. This document will
address only two specific services within the Emergency Services category, and those are:
Emergency Services and Telematics Call Centers.
1.1.2 Emergency Services
Mayday calls – Occupant pushes button in the car to summon help
Automatic Collision Notification – Call is initiated by a collision’s characteristics, without
occupant intervention, usually air bag deployment or seat belt tensioning system deployment.
Newer systems may be activated by impact with the car, from any direction without airbag
deployment.
1.1.3 Telematics Call Centers
Telematics require that highly sophisticated technology be installed at the TSP call center. This
technology enables the call center to interface with the telematics equipment installed in vehicles.
The call center telephone equipment must be designed to match the equipment installed in the
vehicles so that the appropriate connection is established and maintained. When on-vehicle
equipment and call center equipment are connected and communicating, ancillary hardware and
software must allow database lookups to determine the range of services available to the caller (per
their subscriber agreement), and validate that their contract is current. Upon validation, the call
center equipment and software will link the voice call, location, vehicle owner/occupant and vehicles
database information, to the service provider’s console using sophisticated Computer Telephony
Integration (CTI) and Automatic Call Distributor (ACD) equipment.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 7 of 44
1.2 Reason to Implement
The Telematics industry has developed rapidly, as has the number of emergency calls forwarded to
public safety dispatch facilities and PSAPs from TSP call centers on behalf of their telematics
service clients. While telematics remains a very small proportion of emergency communications to
PSAPs, the telematics issues are essentially the same as other sources of emergency information.
Most of these emergency calls do not travel to the PSAP through existing 9-1-1 networks, and
PSAPs are not receiving the increasingly available vehicle data and additional data that are available
from in-vehicle telematics systems This document will review current practice and ideas for future
communication.
1.3 Benefits
Use of this “Automatic Collision Notification and Telematics Technical Information Document” will
provide a basis for future consideration of communications policies and related matters, including
protocols, procedures, network communications, PSAP CPE and other matters relating to the receipt
of emergency calls and associated information from TSPs. This document attempts to describe in
some detail the processes in use by TSPs at this time, as well as suggestions for future developments
that will use the new information available to improve emergency response service to the public.
Operational Impacts Summary
The goal of this TID is to support the implementation of future communications infrastructure and
processes that will limit the impact of those changes upon PSAPs; wireless, ILEC, IXC, other
carriers, and upon the telematics industry as well, while taking advantage of these new services and
new information to improve emergency response.
1.4 Document Terminology
The terminology used in this document has been aligned to designate definitions used within the
American National Standard for Telecommunications technical standard T1.628 Emergency Calling
Service, issued by the Alliance for Telecommunications Industry Solutions (ATIS).
1.5 Reason for Issue
This document is issued to consolidate information for future NENA technical activities relating to
telematics, automatic collision notification and communications of telematics emergency calls to
PSAPs.
1.6 Reason for Reissue
NENA reserves the right to modify this document. Whenever it is reissued, the reason(s) will be
provided in this paragraph.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 8 of 44
1.7 Date Compliance
All systems that are associated with the 9-1-1 process shall be designed and engineered to ensure that
no detrimental, or other noticeable impact of any kind, will occur as a result of a date/time change up
to 30 years subsequent to the manufacture of the system. This shall include embedded application,
computer based or any other type application. To ensure true compliance the manufacturer shall upon
request provide verifiable test results to an industry acceptable test plan such as Telcordia GR-2945
or equivalent.
1.8 Anticipated Timeline
This document provides information related to vehicle telematics emergency calling and associated
information sharing. Since multiple solutions are suggested and it is not known which may be
applied, timelines will be dictated by the solutions chosen for implementation.
1.9 Cost Factors
The discussion herein provides basic information that may be useful in the development of
communications solutions for vehicle telematics emergency calling and associated information
sharing. The document includes discussion of items that may impact costs of those solutions.
1.10 Cost Recovery Considerations
The discussion of cost recovery considerations is beyond the scope of this document. Once solutions
are in the process of design and implementation, cost recovery can be addressed appropriately. In
Next Generation E9-1-1 systems, telematics calls and data will “look” no different than other forms
of emergency communication. They will approach PSAPs in a standardized IP format. There should
be few marginal telematics costs to the PSAPs.
1.11 Acronyms/Abbreviations
This is not a glossary! See NENA 01-002 - NENA Master Glossary of 9-1-1 Terminology located
on the NENA web site for a complete listing of terms used in NENA documents.
The following Acronyms are used in this document:
ACCDEN Access Denied
ACD Automatic Call Distributor
ACN
Automatic Collision Notification and also known as Automatic Crash
Notification
ALI Automatic Location Identification
AMPS Advanced Mobile Phone System
ANI Automatic Number Identification
ANSI American National Standards Institute
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 9 of 44
The following Acronyms are used in this document:
ATIS Alliance for Telecommunications Industry Solutions
BASK Binary Amplitude Shift Key
CAD Computer Aided Dispatch
CAMA Centralized Automatic Message Accounting
CAS Call path Associated Signaling
CBN Call Back Number
CPE Customer Premises Equipment
CRDB Coordinate Routing Database
DOS Denial of Service
DOT Department of Transportation
E9-1-1 Enhanced 9-1-1
EO End Office
ESC Emergency Services Call
ESGW Emergency Services Gateway
ESIF Emergency Services Interconnection Forum
ESME Emergency Services Messaging Entity
ESN Electronic Serial Number
ESNE Emergency Services Network Entity
ESRD Emergency Services Routing Digits
ESRK Emergency Services Routing Key
ESRN Emergency Services Routing Number
FCC Federal Communications Commission
GPOSDIR GeoPositionDirective INVOKE (see JSTD-036)
gposdir GeoPositionDirective RETURN RESULT (see JSTD-036)
GPOSREQ GeoPositionRequest INVOKE (see JSTD-036)
gposreq GeoPositionRequest RETURN RESULT (see JSTD-036)
GPS Global Positioning System
HLR Home Location Register (see ANSI-41)
IAM Initial Address Message
IID Incident Identification
ISDN Integrated Services Digital Network
ISUP Integrated Services Digital Network User Part
LEC Local Exchange Carrier
LOCREQ Location Request
LRO Last Routing Option
MDN Mobile Directory Number
MIN Mobile Identification Number
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 10 of 44
The following Acronyms are used in this document:
MapInfo
Mobile Information (see JSTD-036) (MapInfo is a trademark registered
name!)
MPC Mobile Positioning Center
MPCAP Mobile Position Capability (see JSTD-036)
MSC Mobile Switching Center
NCAS Non-Call path Associated Signaling
NENA National Emergency Number Association
NG9-1-1 Next Generation 91-1
OEM Original Equipment Manufacturer
ORREQ Origination Request Invoke (see JSTD-036)
orreq Origination Request RETURN RESULT (see JSTD-036)
PAM PSAP to ALI Message
PCS Personal Communications System
PSAP Public Safety Answering Point
PSTN Public Switched Telephone Network
ROUTREQ Route Request (see ANSI-41)
RTP Real-time Transport Protocol
SR Selective Router
SCP Service Control Point (see ANSI-41)
SIP Session Initiated Protocol
SMDPP SMS Delivery Point to Point INVOKE (see ANSI-41)
SRDB Selective Router Database
SS7 Signaling System 7
STP Signal Transfer Point
TDM Time Division Multiplexing
TCU Telematics Control Unit
TSP Telematics Service Provider
TTY Telecommunications Device for the Deaf and Hard-of-Hearing
VE2 Voice over Internet Protocol E2 Interface
VLR Visitor Location Register
VoIP Voice over Internet Protocol
VEDS Vehicle Emergency Data Sets
VIN Vehicle Identification Number
VPC Voice over Internet Protocol Positioning Center
XML Extensible Markup Language
2 Technical Description
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 11 of 44
2.1 Vehicle Telematics
Telematics are a suite of services, some location-based, offering benefits to the automakers, dealers,
commercial fleets and consumers. Consumer services include navigation and convenience assistance
to the driver and emergency help. To gain access to these services the vehicle must have telematics
hardware installed and, currently, contracts between the user and the telematics firms must be
enacted to provide requested services.
2.1.1 Vehicle Telematics Participants
Telematics devices are available as original equipment on some new vehicles. Telematics services
are provided by specialty call centers under contract with the telematics services or automaker.
Currently, subscriber agreements are required to enact the services. The telematics services or
automaker designates services and their elements. Subscribers then choose which of the offered
services they desire to utilize. All of the above are parties to the services provided telematics
subscribers.
2.1.2 Telematics Services
A variety of services are available through telematics suppliers. Some services are only available
using specific equipment and/or service vendors. Generally the services fall in five categories:
emergency, navigation, convenience, vehicle, and dealer/manufacturer services. Throughout this
document only emergency services will be addressed other than below in 2.1.4 through 2.1.7.
2.1.3 Emergency Services
Possible life threatening:
“MayDay”/Emergency Calls – Occupant pushes button in car to summon emergency help.
Automatic Collision Notification – Call is initiated by a collision’s characteristics, without
occupant intervention, usually air bag deployment or seat belt tensioning system deployment.
Newer systems can be activated by impact with the car, without airbag deployment.
Non life threatening:
Breakdown Assistance – Is a location based service and occupant pushes designated button
to request roadside assistance with vehicle.
Stolen Vehicle Location – Owner provides stolen vehicle report number and password with
request to TSP to find stolen vehicle.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 12 of 44
2.1.4 Navigation Services:
Operator assisted routing to a known address or business place
Interactive voice response (IVR) or download to a navigation screen in the vehicle routing to
a known address (no TSP operator involved)
Point of Interest (POI) Lookup to find local business or visitor attractions
2.1.5 Convenience Services:
Reservations at restaurants, hotels, airlines, tours and attractions
Gift orders and delivery
Personal messaging
Personal Calling
Remote Door Unlock
2.1.6 Vehicle Services:
Diagnostic Code Notification
Remote storage of intermittent problem data
Tire pressure sensing and monitoring
Diagnostic health check
Real-time Preventive Maintenance
Maintenance triage and scheduling
Over-the-air software updates
2.1.7 Dealer/Manufacturer Services:
New Sales Prospecting
Relationship Marketing Assistance
Dealer Connect services
Owners website
Maintenance History data and storage
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 13 of 44
Remote emissions testing
2.2 Current TSP Call Center Operations
Telematics require that highly sophisticated technology be installed at the TSP call center. This
technology enables the call center to interface with telematics equipment installed in vehicles. Call
center telephone equipment must be designed to match the equipment installed in the vehicles so that
the appropriate connection is established and maintained. When the in-vehicle equipment and the
call center equipment are connected and communicating, ancillary hardware and software must allow
database lookups to determine the range of services available to the caller (per their subscriber
agreement), and validate that their contract is current. Upon validation, the call center equipment and
software will link the voice call, location, and owner and vehicle database information to the service
provider’s console, using sophisticated Computer Telephony Integration (CTI) Automated Call
Distributor (ACD) capability will allow the call to be routed to an operator possessing the skills
needed to handle the incoming call type. MayDay and ACN calls go to special operators. Location
data (latitude/longitude coordinates) are interrogated to display a map at the console to indicate the
calling party’s location. This map is automatically scaled to display the right combination of detail
to help the operator describe the location to a PSAP, if needed. It should be noted that the map data
of the TSP may not match that of the PSAP. In the background, the latitude/longitude data is reverse
geocoded against the map database to provide the operator with one of the following location
parameters; the street address; the street address range or the street or cross street and distance.
Separately, the location coordinates are used to determine the nearest or jurisdictionally appropriate
PSAP and/or other public safety dispatch facility to support this incident. One or more PSAPs or
dispatch facilities are listed along with their telephone numbers, which may be auto-dialed by
pressing the appropriate command key. An incident record is initiated during this process and
captured and time-stamped. Each and every keystroke, transfer, link or other action that takes place
throughout the incident, is logged. Typically, in Mayday/emergency and ACN cases, full audio
records are made of each incident.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 14 of 44
2.2.1 TSP to PSAP Call Flow Diagram
at the Current Time
FD
Fire department
Mobile Switch (MSC)
Cell Tower
Long Distance Switch(IXC)
Local Exchange
Switch (LEC)
Telematics PBX
Workstation
Workstation
Workstation
Workstation
Workstation
Workstation
Responding Agerncies
Incoming Call
Outgo
ing Emerege
nyCall
PSAP
Telematics ACN Call Flow
TSP
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 15 of 44
2.2.2 TSP Call Center Protocols
Because TSPs must provide services to multiple makes and year models of vehicles, offering a
variety of services, individually selected by the calling consumer customer, protocols for call center
operations must be simple and driven by the console software suite. Protocols are initially directed
by data included in the incoming call, such as type of call (emergency, navigation, etc); automaker or
manufacturer suite of services; location of the call (English or French speaking Canadians, etc.) and
other factors identified within the software/database applications.
In the case of emergency calls, the protocols help the operator determine if there are life threatening
injuries or medical emergencies, immediate peril or special circumstances involving the need for
public safety intervention. Based upon the resolution of those questions, public safety is
immediately engaged, if available, and the caller is patched into the call taker/dispatcher if requested.
An overriding requirement of telematics emergency calls is that the operator is required to stay
connected to the calling party until emergency help arrives or the caller specifically asked them to
disconnect. TSPs consider these calls important opportunities to provide comfort and
companionship to customers in distress.
Other types of calls have protocols to assist the operator in quickly and completely fulfilling the
required needs. These protocols may involve special messaging, data transfer, looking up nearby
businesses, getting reservations, mapping the fastest or most direct route to a desired destination, or
other actions, many of which are stored within personal data files so that individual desires are
already know at the call center operator’s console.
2.2.3 Telematics Data and Sources
Telematics vehicle events generate data. Data is received from the telematics unit in the vehicle,
correlated to database records maintained at the TSP, and linked to remote databases maintained by
other contractors at other sites. In a crash, the data flow is increasingly rich, depending on the model
and decisions of the manufacturer. Some of this data is provided at the TSP call center workstation
to support the handling of the emergency incident. At least one of the major TSPs provides crash
data to PSAPs or other emergency agencies as available.
2.2.4 Data that may be received from the vehicle involved in an incident:
The following identifies data elements and their sources that may exist in any telematics emergency
incident. Values for these data elements and those described in the following section are contained in
the Vehicular Emergency Data Set (VEDS) developed cooperatively by EMS, 9-1-1, industry, and
other affected entities. See www.comcare.org/standards.
Unique telematics identification – an embedded code in on-board memory provided the TSP to link
the unit to its vehicle and other data. This code could be either arbitrary, the electronic serial number
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 16 of 44
(ESN) of the embedded cell phone, the Vehicle Identification Number (VIN) of the vehicle or a code
assigned or downloaded at the time the subscription was approved. It can invoke other useful
information, such as the location of electrical connections, airbag trip wires for a particular car, and
other hazards to responders.
Global Positioning System (GPS) data, including at a minimum the time and date of incident
initialization; the latitude and longitude location of the vehicle at that time; the speed and direction
of travel of the vehicle at the instant of initialization (press of the emergency button or trigger of the
ACN sensors). Call type designation, based upon which button was pushed or whether the call was
initiated by the ACN system (and whether that device was triggered by the air bags or the seat belt
tensioning system).
Collision sensor data may be provided by the vehicle’s event data recorder or dedicated on-board
devices specifically for incident use. This data may include crash pulse, delta velocity, rollover
indicator, rollover count, principal direction of force, final resting position, number of occupants,
number of occupants wearing seat belts, video or still imagery from on-board cameras, vicinity radar
signature (nearby obstacles/vehicles, etc), and other details related to the incident or vehicle at the
time of this call.
The system has a two way audio connection to the hands-free, embedded communications (or to a
cell phone) within the vehicle providing real-time verification and incident details from the
occupants themselves or passersby. Diagnostic data generated within the diagnostic bus onboard the
vehicle providing failure, component values and error codes relating to the performance of the
vehicle.
2.2.5 Data Maintained at the TSPs Call Center May Include:
Vehicle records including Vehicle Identification Number (VIN), year, make, model, style, color,
equipment features, and other details that are usually provided by the Original Equipment
Manufacturer (OEM) automaker when the vehicle is sent to the dealer. This data provides a record
of the vehicle as manufactured and may be updated to include modifications, service records,
customer service details, and other details.
Subscription database records including owner name, address, services subscribed, emergency
contact list, contract expiration date, telephone numbers, and the subscription agreement number.
Incident data records developed as the incident transpires including date and time of notification,
time of dispatch, dispatch details, TSP actions, related records, workstation(s) assigned, specialists
involved, dispatcher and call taker details, etc.
Public Safety Notification database including the name of each agency; the office street address and
latitude/longitude location; agency type and type of response; agency administrative and emergency
telephone numbers; date of last data verification.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 17 of 44
Working map database(s) providing streets and roads, names and official designations, waterways
and lakes, place names, municipal, county and state boundaries, railroads and other forms of mass
transit, airports, and seaports
2.2.6 Databases That May be Maintained by Others and Remotely Accessed to Provide Data
During the Incident:
A points of interest (or common name) database including businesses, government offices and other
points of interest (such as museums, landmarks), their address and lat/long locations, telephone
numbers, description and other details. Map database updates collected by the supplier and made
available on a regular basis.
Manufacturers could make available other useful information, such as the location of electrical
connections, airbag trip wires for a particular car, and other hazards to responders.
Patient information sources:
There are commercial data bases (e.g. Medic Alert) where individuals have registered key
medical conditions of interest to responders. Similarly, electronic health records may be
available. The most accessible initial version of these is the databases of EMS ambulance
providers.
Decision support tools:
Emergency Medical Dispatch (EMD) is the most common of these. New versions of EMD
will be developed to take advantage of external sources of data. These include telematics
data from TSPs, and predictive algorithms developed to interpret advanced automatic crash
data and related information from PSAPs and bystanders (age, gender, etc).
2.2.7 Real-time Supplemental Data Sources That May be Available on Demand as needed
During an Incident:
Traffic Conditions:
Traffic reports including incidents, their location, incident details, time of notification, time
cleared; current traffic flow, by speed and direction.
Construction Information:
Construction and maintenance activities, locations, and timeframes during which they will
influence traffic flow, etc.
Weather Information:
Weather conditions, forecasts, and special alerts including roadway conditions, weather
alerts, wind, rain, temperatures, etc.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 18 of 44
2.3 TSP/PSAP Communications
Telematics subscribers’ emergency calls are connected directly to the TSP call center where they are
pre-screened and those true emergency calls are transferred to public safety facilities according to 10-
digit telephone number information the TSPs have acquired. Percentage of emergency calls sent to
PSAPs is approximately 87%, which means TSPs screen out about 13% of the calls. One TSP
reports that they screened out approximately 20 percent of the emergency calls in 2006.
One TSP reports that their OEMs provide a cover over the emergency button, thus reducing the
likelihood of inadvertently hitting the button. While another TSP does not follow this practice
because they feel that it can make it harder for individuals, especially older citizens, to place an
emergency call in a crisis.
Telematics emergency calls are transferred to PSAPs and Public Safety Agencies via the Public
Switched Telephone Number (PSTN) using 10-digit telephone numbers provided by the emergency
agencies themselves. In a few cases, dialable numbers have been provided that connect directly to
the 911 network trunks. Calls received at the PSAP on 10-digit administrative lines may not receive
the same priority as 9-1-1 calls, and could result in delays for telematics emergency calls. Moreover,
the increasingly rich data available from TSPs are not typically automatically transferred to PSAPs
and other emergency responders in digital data format.
Industry and PSAP consensus is that the communications be routed through the 911 network with
ANI, and ALI delivered on every call. Given the very small number of telematics calls relative to the
overall number of calls to 9-1-1 (less than 1000 per day nationally), ACN/PSAP solutions should be
cost-effective, non-disruptive, and shown to be fully compatible with future NG9-1-1 networks.
2.3.1 Location and Callback Number
For most telematics emergency calls today, the incident location (as an approximate street address;
street and cross street or latitude, longitude coordinates) and the callback number of the TSP are
reported to the PSAP verbally. A TSP can bridge a 3 way conference call across its own private
telephone switch for a PSAP to be able to talk directly to the occupants of a vehicle involved in the
emergency. TSPs have the ability to provide location and callback number as data with the call along
with other information. When PSAPs are able to receive it, this will allow PSAPs to utilize existing
protocols, equipment, network and procedures. Doing so may allow uniformity between classes of
calls that will allow PSAPs to standardize their procedures, using existing protocols, or develop new
ones to take advantage of the new information available to them.
2.3.2 Telematics Calls
TSPs received 2,090,321 calls in 2006 and of these about 35,000 telematics emergency calls were
transferred to PSAPs for emergency assistance. Each of those calls was handled entirely with verbal
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 19 of 44
communications and the incident location and the callback number of the TSP were provided along
with other details. In some cases the telematics call was not the first report of the incident, although,
in all cases, they included location information. PSAPs were required to manually input the verbal
information received from the TSP, in order to include that data with the call when it was transferred
to responding agencies. PSAPs not equipped with CAD or older CAD systems that can’t handle
latitude/longitude can utilize their normal call referral protocols when handling these calls.
Today, more that 200 million calls reach 9-1-1 PSAPs across the nation each year. Approximately
50 percent of those calls are from wireless phones, many of these calls do not provide related
location information. Currently, TSPs receive 35,000 telematics emergency calls annually. While
this may be only one telematics call for every 5700 other 9-1-1 calls, it nevertheless comprises
35,000 calls for emergency assistance. These numbers will increase as more vehicles are equipped
with telematics devices.
2.4 Communications Standards
PSAPs have expressed a desire to have telematics emergency calls delivered in a fashion consistent
with other incoming 9-1-1 emergency calls. TSPs have agreed and several approaches to provide
this integration of communications have been explored (see exhibits in section 3). There are,
however, no existing standards (other than the VEDS data standard) relating to the provision of
commercial call center emergency traffic within the public 9-1-1 network infrastructure. The current
consensus in the NENA NG9-1-1 process, NRIC Focus Group 1B and Focus Group 1D, and other
broad architecture efforts is that the emergency systems of the future will be IP based. Voice and
data from all emergency sources will be handled in generally the same way. In other words, there
will be no special treatment of telematics. The payload coming from a TSP may include more
information than from some other source, and thus the information technology in a PSAP may
handle it in certain ways, but conceptually it will be the same as a 9-1-1 call or weather alert.
2.4.1 National Mayday Readiness Initiative (NMRI) - Standards
The National Mayday Readiness Initiative (NMRI), sponsored by COMCARE and the Department
of Transportation, assessed the then-existing standards relating to TSP-PSAP communications.
NRMI included NENA, APCO, telematics suppliers, and other emergency response professions. In
this process they concluded that then-existing standards were inadequate for voice and data
communications to emergency agencies. See www.comcare.org/NMRI
In 2002, the NMRI participants and others launched a collaborative effort to address the standards
gap. Over 20 national organizations, including NENA, emergency physicians, EMS, all telematics
leaders and others developed the Vehicular Emergency Data Set (VEDS), an XML standard for
communicating all telematics data to PSAPs and other emergency agencies. This was first issued in
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 20 of 44
2003, when OnStar and ATX committed to using it. OnStar has been using it since 2004 in trials
(e.g. Minnesota, Alabama), and now delivers actual crash data to DOT-sponsored websites in more
than 10 states. A new, updated version is about to be circulated to interested parties. See
www.comcare.org/telematics.html.
It is now intended that the VEDS “payload” (like all other emergency messages) would be routed by
a new international standard the Organization for the Advancement of Structured Information
Standards (OASIS ) “Emergency Data Exchange Language (EDXL) Distribution Element” (i.e.
would have the DE as a “header”). This draft standard was developed by an even broader group of
emergency practitioners (including NENA) in a process sponsored by the Department of Homeland
Security. It was approved as an international standard by OASIS on April 30, 2006. See
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency
2.4.2 Vehicle to PSAP Communication
NMRI members discussed at length the question of whether telematics emergency calls and data
should be sent directly to PSAPs (as opposed to going through a TSP first). The NMRI final report
(2000) said:
“9. We encourage extensive field testing of sophisticated ACN systems, including research
funded by the Federal Government, to confirm initial findings that such systems can function
without significant levels of false positives, that crash data can distinguish between serious
crashes and “fender benders”, and indeed can predict the probabilities of severe injury. “10.
Direct delivery of telematics emergency calls and data to PSAPs should be accomplished when
the affected parties agree that it is feasible and will enhance public safety.”
“10. Direct delivery of telematics emergency calls and data to PSAPs should be accomplished
when the affected parties agree that it is feasible and will enhance public safety.”
“11. Direct delivery of telematics calls and data to PSAPs” simply means that the intervention of
a human being at a private call center would no longer be required. Special data residing on a
call center server (e.g. personal medical information) could still be “picked up” and added to the
data being sent to a PSAP or EMS agency if the subscriber had paid a TSP for such a service.”
2.4.3 Delivery Outcomes
PSAPs have indicated a desire to improve communications with TSPs such as but not limited to:
Incident location and callback number delivered as data with the call
Incoming telematics emergency call delivered within the 911 network
Additional telematics or ACN data delivered to the PSAP
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 21 of 44
2.4.4 Network Considerations
The 9-1-1 service was structured around the architecture and infrastructure of the wireline telephone
system. Even before Basic 9-1-1 was approved, Bell Labs and some of the AT&T operating
companies had been working on an enhanced 9-1-1. In 1975, Bell Labs patented a system which
incorporated what is known as Automatic Number Identification (ANI) and Selective Routing. In
1980, AT&T introduced Automatic Location Identification (ALI) and Selective Transfer services
that completed the minimum array of features that were associated with true wireline enhanced
9-1-1.
Over the last 40 years, technological, institutional and behavioral changes have overtaken the AT&T-
dominated PSTN and its emergency call model. When 9-1-1 was introduced in 1968, the PSTN was
already in the early stages of the long technological transition from an analog, electro-mechanical,
circuit-switched system to a digital, electronic, packet-switched system. Today, voice, text, data,
graphics, and video are being transmitted by all manner of devices in fixed, nomadic, and mobile
situations. Most of these devices lack direct access to the PSTN local emergency sub-network, and
useful location information is frequently problematic, or non-existent.
At present, calls such as wireless E9-1-1, ACN/TSP, and VoIP 9-1-1 use a variety of approaches for
gaining access to an emergency call-handling facility and for determining caller location; these
approaches have not always provided completely successful solutions. Cell phone caller location has
been a challenge of long standing, yet significant progress has been made only in the last few years,
and universal deployment has not been realized.
In the case of ACN/TSP calls, direct access to the PSTN-based local emergency sub-network has
been lacking, and the 10-digit, dialup solution frequently employed is not ideal. (Note that while
current telematics systems are digital, past telematics technology is based upon an outdated cellular
technology, analog AMPS networks that are slated to be phased out within five years.)
It is anticipated that in the future, a comprehensive Internet protocol (IP) -based approach will
address the access and location issues (and many others) for most communications devices and
situations. While this approach will necessitate the replacement of some legacy equipment and
procedures by government, enterprise, and individuals, it will greatly expand the range of options
that people will have for making contact with emergency assistance services using 9-1-1 (and caller-
interface surrogates).
2.5 Suggested Communications Plans
Several approaches are summarized below and included as Exhibits, in Section 3.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 22 of 44
One suggests a Positioning Server which will utilize the latitude/longitude coordinates of the
incident site to query a database of routing instructions which are then appended to the call,
re-directed to the appropriate selective router and directed to the appropriate PSAP.
Another would utilize a network-switch-based 3 way conference call, directed by the TSP to
be placed through the cell phone in the caller’s vehicle to contact the local 9-1-1 directly
through the serving wireless carrier’s switch.
Yet another suggestion would send an SS7 message to the wireless carrier’s MSC directing it
to invoke its 3 way conference feature to dial “9-1-1” (placing the call to local PSAPs
according to the method in use at that particular cellular tower site) and append the callback
number and provide ALI steering to obtain the location information.
The last suggestion includes placing a Centrex block regionally to direct emergency calls to
the appropriate PSAPs, as an interim method to get these calls into the 911 trunks.
These systems are focused on transmitting calls. In addition, there are relatively simple interim ways
of transmitting data alone so that those agencies (911, EMS, hospitals, etc) that want it can access it,
either directly on their emergency systems (e.g. CAD), or on a shared, secure web site with an
electronic map.
2.6 NENA NG9-1-1
Any communications standards or protocols developed as a result of this TID should fall within the
guidelines developed by NENA for technical development in 9-1-1. Several years ago, NENA
developed a Future Path Plan. This outlined the criteria any proposed technology should meet to be
considered as viable for incorporation into the national emergency networks. The five criteria
expressed in this plan were:
NENA Future Path Plan Criteria
1 – Reliability/dependability as governed by NENA’s technical standards, and other generally
accepted base characteristics of E9-1-1 service
2 – Service parity for all potential 9-1-1 callers
3 – Least complicated system design that results in fewest components to achieve needs
4 – Maximum probabilities for call and data delivery with least cost approach
5 – Documented procedures, practices, and processes to insure adequate implementation and
ongoing maintenance for 9-1-1 systems.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 23 of 44
More recently, NENA and a diverse group of partners are developing the Next Generation
architecture for emergency communications. See www.nena.org. One of the key findings of that
process is to recognize that telematics and similar emergency communications involve far more
organizations that just TSPs and PSAPs. Where they involve communications between agencies in
addition to 9-1-1, standards and protocols for this purpose should be developed cooperatively with
such agencies.
2.7 Environmental Changes Impacting 9-1-1
When terrorists struck in New York City, Washington, DC and the Pennsylvania countryside, the
impact of these acts alerted us that there was an immediate need to link every level of public safety
nationwide. 9-1-1 is no longer a strictly local issue and improvements made to satisfy the telematics
requirements or others must consider these national implications. We need a national inter-network
linking all public safety and emergency response agencies and organizations to make data available
at every level during any crisis.
2.7.1 Network Considerations
Network technologies have and are advancing at a rapid pace and that their implementation will
impact solutions proposed to PSAP/TSP communications
Internet Networks: Rapid and successful growth of the Internet has dramatically demonstrated the
capabilities of new network technologies to connect 9-1-1 and other emergency agencies to external
data sources. Internet protocol (IP) technologies need to be applied to emergency voice and data
traffic as rapidly as possible, using backbone networks, secure servers, gateways and other
infrastructure to accomplish the needs of today’s emergency agencies.
2.7.2 Analog Telematics
The FCC decision to allow CMRS carriers to begin replacing their analog cellular ports with digital
ports, over the next five years, is already resulting in lower availability of analog circuits in cities.
The 6 million legacy telematics vehicles in the field today are ALL analog cellular equipped, making
them potentially obsolete in the very near future. Digital upgrades are likely to be offered for these
legacy systems. AMPS communications have been favored by the telematics industry because of
that service’s large coverage footprint. Simply said, where there is no cellular coverage, there are no
telematics services and there are no ACN alarms.
2.8 Industry Participants May Impact TSP-TSP Communications
In addition to TSPs, PSAPs, and other emergency response agencies, there are a host of other
disciplines involved in or impacted by changes in telematics to public safety communications. There
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 24 of 44
are the telematics manufacturers, who need to concur with proposed or recommended standards for
telematics. The automakers decide what to install in new cars and what services will be provided to
the consumer buying public. Not all telematics equipped vehicles provide emergency calling
services. There are also the multiple telephone carriers involved in handling calls from telematics
vehicles to the PSAP, including: wireless carriers; long distance carriers, local exchange carriers.
2.9 Summary
A few years ago less than one percent of the cars on the road carried telematics equipment, so the
frequency of receiving telematics emergency calls in PSAPs was low. A the industry expands,
however, more PSAPs will be receiving these ACN and “mayday” calls. The current systems and
practices work reasonably well and emergency services are delivered to those who call through
telematics. Improving the chain of communications will improve results and will make the work
easier for PSAPs.
3 Exhibits
Several companies and individuals have considered the technologies needed to improve TSP to
PSAP communications. They have submitted their suggestions in the form of white papers, which
are attached hereto, without comment or editing, for further consideration as exhibits to this
document.
3.1 Native 9-1-1 Delivery Using a Position Server (Intrado Inc.)
3.1.1 Overview
This solution provides a means to route emergency calls from a TSP Call Center (CC) to the correct
E9-1-1 Tandem and have the call treated as a native 9-1-1 call. This solution allows delivery of the
Telematics data once the call arrives at the PSAP and an Emergency Services Query Key (ESQK) to
enable additional data to be retrieved, if required. It utilizes the existing local ALI database network
and makes use of the Public Switch Telephone Network (PSTN) for routing of the voice path. This
solution utilizes a Position Server, to provide routing instructions based upon the latitude and
longitude of the caller. The TSP CC, through an Extensible Markup Language (XML) over TCP/IP
interface, accesses the Position Server. The specification for this interface is provided in a separate
document entitled “TSP Routing Interface using XML Elements (TRIXE)”. This interface is an open
specification and has been made available to NENA.
This solution was demonstrated at the NENA national conference held June 2002 in Indianapolis,
Indiana. This solution is also in operation in PSAPs within greater Harris County in Texas, and the
position server is part of Intrado’s current production E9-1-1 network.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 25 of 44
3.1.2 Solution Description
When an emergency call from a Telematics equipped car arrives at a TSP CC, it contains data that is
pertinent to the location of the caller as well as collision information. The collision information
provides data elements including: number of occupants, were they wearing seat belts, velocity of the
vehicle, did it roll, etc. All this information is critical in evaluating the potential severity of the
emergency. When the TSP attendant receives these calls, they first determine if the call is an
emergency by talking with the person(s) within the vehicle (if the person is not speaking, the
attendant can view the collision data for an indication of an accident). If it is determined to be an
emergency, then processing the call to route based on location begins. The following paragraphs
describe the solution.
When the TSP CC attendant determines the call is an emergency, they request routing instructions
from a Position Server by querying the server with the latitude and longitude (and any other data
relevant to the emergency) via the TRIXE interface. This is an automated process for the attendant
and utilizes a Computer Telephony Integration (CTI) application to both query the Position Server
and set up an outbound Conference call. Based on the latitude and longitude provided as part of the
query, the Position Server determines the serving PSAP and the E9-1-1 Tandem. The Position
Server stores all the received data and returns to the TSP CTI application an Emergency Service
Query Key (ESQK), used to identify the serving PSAP (similar to an Emergency Service Routing
Key (ESRK)), and an Emergency Service Routing Number (ESRN), used to route the call to the
correct E9-1-1 Tandem. Both numbers, the ESRN and ESQK, follow the North American
Numbering Plan (NANP) format.
Using the ESRN and ESQK from the Position Server response message, the TSP CTI application
populates an outgoing Q.931 Call Setup message with the Called Party Number (ESRN) and the
Calling Party Number (ESQK). This call is originated over a Primary Rate Interface (PRI)
connection to the local End Office to establish a conference call to the PSAP. The PSTN then takes
over routing of the emergency call to the E9-1-1 Tandem based on the ESRN using standard NPA-
NXX routing translations.
Once the call is recognized at the E9-1-1 Tandem as an emergency, the Wire-line mode of
emergency call processing takes over. That is, the ESQK (Automatic Number Identification (ANI))
is used to query the Selective Routing Data Base (SRDB) to determine the correct PSAP. The call is
then routed to the PSAP and the ANI (ESQK) is out-pulsed. The PSAP queries the Automatic
Location Identification Database (ALI DB) with the ESQK. The ALI DB is provisioned to steer
ESQK queries to the Position Server using the existing PSAP to ALI Messaging (PAM) protocol (in
the future, XML). Data that is associated with the ESQK is retrieved from the Position Server and
sent back to the ALI DB, which in turn forwards the ALI record to the PSAP.
The ALI record presented to the PSAP at the NENA demonstration included the location
(latitude/longitude), TSP 24x7 call back number, and minimal collision data as provided in the
Supplemental data fields. The telephone number assigned to the vehicle is non-dialable and the only
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 26 of 44
access to the person in the vehicle is through the TSP CC; hence why the TSP 24x7 call back
number is essential.
The interface between the Position Server and the ALI DB is expected to eventually evolve to XML
to allow for a larger set of data to be available to the PSAP and other Public Safety service providers.
3.1.3 Call Flow
The below diagram depicts what the above text describes:
Position
Server
Cell TowerMSC
ALI
DB
2
4. X
/Y
3. incoming call
(data/voice)
E911 Tandem PSAP
1. Collision
occurs
8. ESQK (ANI) 9. ESQK
10. E
SQK
6. CdPN & CPN
(ESRN & ESQK)
11. X/Y
12. ALI record
EO
PRI
5. E
SR
N &
ES
QK
TSP CC
7. c
all R
oute
d th
roug
h PSTN b
ased
on E
SR
N d
irect
ly to
E91
1 Tan
dem
PAM Protoco.l
TRIXE
XML
Interface
Call Flow conditions: The collision is in Greater Harris County, Texas and the TSP CC is in
Boston, Massachusetts. The call flow details follow:
1. A vehicle crashes into a tree, which activates the ACN from within the Telematics device.
This causes a wireless call to be sent to the PSTN network.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 27 of 44
2. The call is routed through a Mobile Switching Center (MSC) to the local End Office (EO)
serving the TSP CC.
3. The call received at the TSP CC consists of the location, data from the collision, and the
voice call. The TSP CC stores the data and then converts the call to a voice call to be
serviced by an attendant.
4. The attendant at the TSP CC receives the call and determines emergency help is required. An
emergency conference call through a CTI application is initiated. This causes a query
containing the location (X/Y) and data to be sent to the Position Server.
5. Based on the location of the caller (X/Y), the Position Server obtains the routing number
(ESRN) to the serving E9-1-1 Tandem and ESQK and returns them to the TSP CC.
6. The TSP CTI application populates the outgoing Q.931 Call Setup Message with the Calling
Party Number parameter containing the ESQK and the Called Party Number parameter with
the ESRN, and sends the call out over the Primary Rate Interface (PRI) interface to the PSTN
to establish a conference call.
7. The call is routed through the PSTN network to the correct E9-1-1 Tandem based on the
ESRN. The E9-1-1 Tandem recognizes the ESRN as an emergency number and processes the
call by invoking the E9-1-1 Feature.
8. The E9-1-1 software takes over processing of the call and selectively routes the call to the
PSAP based on the ESQK and transmits the ESQK to the PSAP.
9. Using the ESQK as the ANI, the PSAP launches a query to the local ALI DB to obtain the
ALI record. The ALI DB steers the query request to the Position Server.
10. An ALI request message is sent to the Position Server with the ESQK as the ANI.
11. The location information and data is returned to the ALI DB in a PAM ALI response
message.
12. The ALI record is displayed at the PSAP. The Supplemental data field contains the collision
related data. Example ALI record as demonstrated at NENA:
Cross Country Automotive Svcs
ALT#= TELCO=CCAS
X=-92.125432 CNF= 0100
Y=+24.587323 S=000 D=000
VERIFY
VERIFY
VERIFY
IID=0010001234 ORNT=Normal
MAKE=CHEVY MDL=BLAZER
COL=BLUE HDG=190 ROLL=N
SPD=050 DVELV=99 FORCE=12 OCC=03
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 28 of 44
3.1.4 Support
Implementation of this solution will require support from the Local Exchange Carrier serving
the PSAP and/or the Number Routing Authority to define the following:
Define the ESQK ranges for each PSAP required to support TSP calls
Define ESRN for each E9-1-1 Tandem Switch (routing number to switch)
Switch translations required to recognize an ESRN as an emergency number
3.1.5 Benefits
Delivers the call as native 9-1-1 using the ESRN over existing voice facilities (PSTN and/or,
in the future, VoIP)
Passes a key with the initial voice call that allows for retrieval of ALI data when the call is
delivered to the PSAP
ALI data includes location of the vehicle, IID(IID- incident ID), a callback number to the TSP
CC, TSP provider name and, optionally, collision information
The IID can be used to retrieve additional data, if applicable
No new software to any 9-1-1 entity or PSTN node; all software modifications required are to
the TSP CC and the Position Server
Position Server can interface to with any ALI system using existing or evolving protocols
(XML) and through a secure network interface.
Utilizing existing 9-1-1 network
Minimizes changes at the PSAP
3.2 Remote Conference Calling (MJC Thomas Inc.)
3.2.1 Overview
This solution consists of a procedure for connecting TSPs with PSAPs during telematics/ACN-
triggered emergency events. Currently, when an ACN-equipped vehicle is involved in an airbag-
deployed collision, the vehicle’s Telematics Control Unit (TCU) automatically contacts a TSP,
employing cellular technology. TSPs, however, receive incoming telematics and ACN calls
originating over enormous geographic areas, and the remote distances involved present a problem.
When a TSP answers a qualifying, collision-triggered call, there would be no better way to establish
quick and reliable connection with a PSAP than via the nation’s existing and ever improving E9-1-1
infrastructure. Yet typically, E9-1-1 infrastructures are local, in both form and function. As a
consequence, ACN calls, though confirmed as potentially life threatening emergencies, are not
currently being routed through the 9-1-1 network to the appropriate PSAP. Instead, they are being
bridged to PSAPs through equipment at the TSP Call Centers via 10-digit dial-up numbers over the
Public Switched Telephone Network (PSTN).
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 29 of 44
This method of routing can be improved without changes of any kind to the existing E9-1-1
infrastructure. The solution involves a standard cellular service feature, a 3-way calling process that
is implemented to conference a PSAP into a 2-party, collision-triggered call between an
ACN-equipped vehicle and a TSP. The process has been called “Remote Conference Calling”.
Remote Conference Calling allows direct connection of ACN calls between TSPs and PSAPs using
the nation’s dialed 9-1-1 infrastructures. By dialing 9-1-1 from the vehicle, the process makes full
use of the end-to-end benefits of the existing, local E9-1-1 infrastructure, including delivery of the
specific call-back number of the involved vehicle.
Vehicles are being equipped with telematics systems having ACN features at an increasing rate, and
it is important that 9-1-1 standards be established.
3.2.2 Remote Conference Calling Procedure
3-way calling (aka 3-party calling) is an existing, ubiquitous service offered by cellular carriers as a
standard feature of their service packages. The feature allows a party on any 2-party call to
“conference” a third party into the call so that all three are able to communicate. Remote Conference
Calling takes advantage of this feature in such a way as to allow direct 3-way connection between an
ACN-equipped vehicle, its associated TSP, and the vehicle’s local PSAP … connecting to the PSAP
over existing, local 9-1-1 trunks maintaining high level carrier quality audio through the carrier’s
conferencing bridge.
3.2.3 Application
Assume that an ACN-equipped vehicle has just been involved in a serious collision, and that its
ACN TCU has made cellular contact with the TSP serving the vehicle. The TCU would then set up
a 3-party conference call with 9-1-1, and two important things would result. First, it is the vehicle’s
local PSAP that would be enjoined in the call, since 9-1-1 would have been dialed from the vehicle;
and second, a conference connection would be established between the TSP, the vehicle, and the
vehicle’s local PSAP. Please see the illustration, below.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 30 of 44
MSC
LOCAL PSAP
GPS Receiver
TCU (with Cell Phone)
TSP
Remote Conference Calling
9 - 1 - 1 Switch
PSTN
1 2 3 4
1 1 2 2
4 4
4
4
1. Collision occurs, and TCU establishes conventional 2-party call with TSP.
2. TSP sends in-band command to TCU to implement 3-party call to enjoin vehicle-local PSAP in conference.
3. TCU implements 3-party call process, dialing 9-1-1 to add vehicle-local PSAP to call through Mobile Service Center (MSC).
4. All 3 parties conferenced through MSC.
This action by the TCU can be initiated in any of the following ways:
the TCU can set up the 3-party call upon receiving a signal from the TSP agent to do so
following confirmation by the agent of a need for PSAP intervention; or
the TCU can immediately set up the 3-party call on its own; or
a combination of these two methods, based on predetermined severity protocols/priorities
pre-programmed into the TCU.
Manually, the reader can set up a 3-way call as follows. In the midst of any 2-party wireless call,
clear the dialing display, dial the number of the party to be conferenced into the call (9-1-1, if an
actual ACN event), and press [Send]. When the third party (PSAP, if an actual ACN event) answers
(or after 2 seconds), press [Send], again. All three parties are then enjoined in the conversation. The
connection is made by the carrier’s wireless switch.
Upon receiving an in-band command from the TSP to set up a 3-way conference call with 9-1-1, a
distressed vehicle’s ACN TCU fully and automatically implements the “manual” process just
described, enjoining the TSP, the vehicle, and the PSAP in a carrier quality, 3-way conference call ...
set up by dialing 9-1-1 from the vehicle, itself.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 31 of 44
The PSAP may disconnect from the call at any time without affecting the connection between the
TSP and the vehicle. Similarly, the TSP may disconnect from the call at any time without affecting
the connection between the PSAP and the vehicle. The call is terminated in its entirety when the
vehicle disconnects from it. The TSP can choose to maintain control over the call by simply staying
on the line, and continuing its remote control of the vehicle’s ACN System and associated cellular
subsystem.
3.2.4 Impact
No changes of any kind are required in the E9-1-1 infrastructure or in the cellular network to
implement this procedure. Nor are any hardware changes or additions required in the TCUs that are
being installed in vehicles. The only change that must be made is that the programming of
Telematics Control Units must incorporate the ability to perform the functions described.
3.2.5 Advantages
9-1-1 is dialed directly from the vehicle. Consequently:
call routing is determined by local 9-1-1 authorities, conforming to local practice for wireless
calls
call is completely routed and delivered on the Nation’s high priority 9-1-1 network
vehicle’s 10-digit call-back number is delivered with the call
wireless Phase I and Phase II data is delivered as available
9-1-1 emergency dialing greatly reduces reliance on, and need for, 10-digit PSAP
databases
no changes need to be made to the network or at the PSAPs
3.3 ACN Communications Using TTY (ACNovations)
3.3.1 Overview
This proposal describes a method for directly
communicating digital text data from a
vehicle to a PSAP in a form that can be
received, understood, processed, and
recorded by the PSAP. The method also
supports the sending of key-tap commands
(see 3.3.8g) from a PSAP to an ACN-capable
vehicle to control predetermined functions of
the vehicle.
The method uses only equipment and infrastructures
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 32 of 44
that are already fully in-place and in-operation. This method does not require any changes or
additions to PSAPs, nor does it require any changes or additions to telecommunications
infrastructures or processes.
To accomplish these ends, the method promotes the shared use of existing TTY equipment and
procedures ubiquitous to the nation’s PSAPs. It has been dubbed ACN/TTY. See 3.3.8f for
background information on TTY.
3.3.2 Background
The concept of a vehicle’s Telematics Control Unit (TCU) dialing directly into the 9-1-1 network has
been difficult to bring to fruition for lack of a universal way to deliver data to PSAPs without
modifications to the 9-1-1 network and/or receiving equipment at the PSAP. If a 9-1-1 call were to
be received without data today from an ACN vehicle, and if the vehicle's occupants were
unconscious or incoherent, the PSAP calltaker would answer a silent line, and would most likely
terminate the call.
In 1990, the Americans with Disabilities Act (ADA) were signed into law. The Act prohibits
discrimination against people with disabilities in employment (Title I), in public services (Title II), in
public accommodations (Title III) and in telecommunications (Title IV). Title IV has been and is
being enforced to require that all PSAPs be equipped with TTY equipment in order to be capable of
telecommunicating with hearing and speech impaired persons. Consequently, all PSAPs must
already be equipped for TTY telecommunications, as required by Federal law since 1990.
3.3.3 Introduction
Not all ACN-equipped vehicles will necessarily be subscribed to a Telematics Service Provider
(TSP). Consequently, it is essential that ACN-capable TCUs be able to dial directly into 9-1-1 and to
directly convey helpful data to PSAPs in the absence of a TSP.
It is essential to the nation's 9-1-1 systems that any ACN/PSAP process be ubiquitously compatible.
What works when 9-1-1 is dialed in Pennsylvania must also work when 9-1-1 is dialed in California
… or Michigan, etc. There are more than 6,500 PSAPs in the United States. Upgrading all of the
nation's PSAPs and network infrastructures to accommodate technologies not now in place for
receiving and processing downloaded ACN data would be prohibitively expensive and disruptive.
Realistically, it seems unlikely it would happen anytime in the near future.
Additionally, it would be quite beneficial for a PSAP calltaker to be able to remotely execute certain
command functions over a remote, crashed vehicle. A couple of examples include: unlocking the
vehicle’s doors; and switching back/forth between voice and data. Commands are simple key tap
sets that may be executed manually or automated (see 3.3.7g). Initiation of a 9-1-1 call by a
vehicle’s ACN TCU would automatically enable its (normally disabled) remote-command-
compliance function for the duration of the incident. In some cases, such remote, PSAP-initiated
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 33 of 44
command functions will help prevent complications from escalating into problems that could have
been totally avoided.
3.3.4 Application
The already-fully-in-place ubiquity of TTY throughout the nation’s E9-1-1 systems provides an
established infrastructure that can be exploited for ACN data communications. Configuring ACN-
capable vehicles to transmit telematics ACN data to a PSAP in TTY format requires only that the
necessary programming code be added to a TCUs expanded firmware. Doing so represents an
essentially insignificant cost and disrupts no existing services or infrastructures. Since the nation's
PSAPs and communications infrastructures are already TTY capable, all necessary information could
then be transferred directly from a vehicle's telematics system to any PSAP in the nation with no
changes or additions required in the operation or equipment of those PSAPs.
Additionally, this process does not depend upon a national spatial routing database that requires
constant, non-regulated updating. Implementation requires only an application software upgrade in
vehicle telematics devices. The process has been successfully field-demonstrated on multiple
occasions (see 3.3.7a). This solution, in and of itself, provides a means by which ACN data can be
communicated today to a PSAP in digitized text form without any action by the occupants of the
vehicle.
Direct ACN/TTY 9-1-1 dialing would be triggered in conformance with pre-approved multi-factor
algorithms approved by the public safety community to eliminate any incident created by accidental
air bag deployment … or by any single, uncorroborated indicator of a collision.
Incident data, arriving at a PSAP via TTY signaling, can be read off the screen immediately … as it’s
arriving. Consequently, there is no perceptual delay in the receipt and comprehension of the
information being delivered. TTY signaling proceeds at a rate of a little over 6 characters per
second. That’s about a word and a half per second, which is just about the average rate of reading
comprehension for most people. In other words, the data comes in just about as quickly as it can be
read and absorbed by the average person.
A typical, conventional TTY call begins with the repetitive sending of two Baudot bit frequencies
(1400 and 1800 Hz), comprising a message precursor. The exact content of this message precursor
is unimportant, and no formal standard exists for it (see 3.3.7b); however, the “warbling” presence of
repetitive Baudot frequencies on a call is distinctive and easily identifiable, both by the human ear
and by automated detection devices.
Once TTY communications have been established, the PSAP calltaker can send TTY commands
back to the ACN system in the vehicle from any standard TTY keyboard, causing both ends to
switch back-and-forth between Voice Mode and TTY Mode … at will … and under PSAP control.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 34 of 44
With subsequent, optional upgrades at PSAPs, voice and TTY data can be multiplexed and
transmitted simultaneously, eliminating any need to switch between the two. This process is
accomplished by separating the 300-to-3000 Hz. (see 3.3.7c) telephony audio band into two sub-
bands/channels: a band centered on 1400 Hz. (ranging from about 1300-to-1500 Hz.) dedicated
exclusively to TTY digital data; and the entire remainder of the audio band dedicated exclusively to
voice. See 3.3.7d for detailed, background information.
In this multiplex mode, only the 1400 Hz. frequency need be used to transmit data. Its 1800 Hz.
conventional TTY counterpart is unnecessary. A technique known as Binary Amplitude Shift Keyed
(BASK) modulation is employed to define the data bits in the data stream. Using only the single
1400 Hz. frequency optimizes the bandwidth dedicated to voice by narrowing the bandwidth that
must be dedicated to data (i.e., a 200 Hz. slice centered on 1400 Hz.). Utilizing the 1400 Hz.
frequency, as opposed to the 1800 Hz. frequency, avoids defiling the critical 1800-to-2500 Hz.
“strongest consonant range” of speech (see 3.3.7e).
Complementing conventional TTY signaling with multiplexing to transfer ACN data provides an
ideal, fully transitional solution to the problem. Conventional “basic” TTY signaling (see
“Illustration 1”) is used to initiate ACN contact with 9-1-1 facilities, via which method any existing
PSAP can receive and display any/all ACN information transmitted, whether or not upgraded to
multiplexing capabilities.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 35 of 44
MSC 9-1-1
SR
1a
1b 1c 1d
2a2b2c
2d
Cell TowerACN/TTY-EquippedCrashed Vehicle
TTY Equipment
In Local PSAP
EXISTING: ALREADY-IN-PLACE AND IN-USE
ILLUSTRATION 1: BASIC ACN/TTY
This illustration describes ACN/TTY in its most basic form. See 3.3.7h.
1. When crashed vehicle’s ACN-capable Telematics Control Unit (ACN/TCU) detects and confirms a collision, it dials 9-1-1, is placed in direct contact with Local PSAP (1a, 1b, 1c, and 1d), and sends predetermined ACN data to TTY Equipment in Local PSAP.
2. PSAP can then send keytap TTY commands back to vehicle’s ACN/TCU (2a, 2b, 2c, and 2d). A few examples include: switch to voice mode; unlock car doors; turn engine off; (re)send location; etc. PSAP can continue issuing commands to
vehicle, including switching back-and-forth between voice and TTY modes at will. Vehicle’s ACN/TCU self-enables its remote-command-compliant mode when it automatically dials 9-1-1.
If/when a PSAP does decide to upgrade its equipment to enable multiplexing and automated
detection of ACN data on the line, such a PSAP can instantly and automatically switch to the
multiplexing mode on a call, whereupon it can immediately initiate voice communication while
simultaneously receiving ACN data on the data channel. Thus, such “upgraded” PSAPs can start to
receive data and initiate voice contact with the occupants of a crashed vehicle immediately upon
answering an incoming ACN call (see “Illustration 2”).
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 36 of 44
1400
KEEP
OUT
1400
ONLY
1400
KEEP
OUT
FULL VOICE
[VOICE W/O 1400]
BANDPASS FILTER
SLOT FILTER
[VOICE W/O 1400] + [TTY 1400]
SLOT FILTER
TTY 1400[VOICE W/O 1400]
+ [TTY 1400]
VOICE WITH-
OUT 1400
COMM LINK
ILLUSTRATION 2: (OPTIONAL) MULTIPLEXED VOICE + TTY (ADVANCED ACN/TTY)
1. Full-spectrum, normal voice frequencies are generated, ‘a’, at the Sending End and passed through slot filter ‘b’. The filter blocks a tight
band of frequencies, centered on 1400 Hz., but passes all other voice frequencies.
2. TTY-capable device ‘c’ can send signals at the same time, generating (only) a precise 1400 Hz. Signal (TTY 1400).
3. At point ‘d’, the voice signal (which has no 1400 Hz. component) is merged with the TTY 1400 signal, and the mixed signals are
transmitted over communications link ‘e’ to the Receiving End.
4. At the Receiving End, the mixed signals are passed through two filters, ‘g’ and ‘j’.
5. Filter ‘g’ is a 1400 Hz. bandpass filter, which allows only the 1400 Hz. TTY signal through, blocking all of the transmitted voice
frequencies, and passing the clean 1400 Hz. Signals to TTY-capable device ‘h’ at the Receiving End.
6. Filter ‘j’ blocks the 1400 Hz. TTY signal, but passes all of the transmitted voice signals to speaker ‘k’, producing voice audio devoid of
TTY 1400 signal tones.
7. For ACN communications, the PSAP is the Receiving End when the vehicle is the Sending End, and the vehicle is the Receiving End
when the PSAP is the Sending End. Vehicle and PSAP must each be equipped for both Sending and Receiving.
ab
c
df
gh
jk
e
RECEIVING ENDSENDING END
[TTY 1400]
Further, if a PSAP has upgraded its equipment to be able to communicate in multiplex mode, there is
no reason why the same upgrade standard cannot also switch communications protocols … to any
other set of protocols. As one example, Binary Amplitude Shift Key (BASK)/Baudot signaling
might still be used, but the Baud rate increased to facilitate more rapid data transfer, such as 110
Baud instead of the conventional 45.45 Baud rate. Similarly, such an upgrade standard can also
incorporate an error detection process (checksum) to flag data bit errors, automatically
recognizing/rejecting bad data, and initiating corrective action (e.g., request resends, etc).
A comprehensive preliminary set of protocols already exists, created to govern the Connexis field
demos described briefly in 3.3.8a. Representatives of the automotive and telematics industries can
join with representatives of the E9-1-1 sector in a cooperative effort to modify or replace these
existing protocols.
Capabilities beyond “Basic ACN/TTY”, described above, will be referred to as Advanced ACN/TTY
capabilities. Such Advanced ACN/TTY capabilities should be incorporated in TCUs integrally with
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 37 of 44
Basic ACN/TTY. Then, at any subsequent time, a simple runtime command from an “advanced”
PSAP will automatically switch a vehicle’s ACN TCU from Basic TTY mode into Advanced
ACN/TTY mode. Such a scheme allows an easy, smooth transition from current to more advanced
equipment and technology at each individual PSAPs own best rate … when each individual PSAP is
ready to upgrade (if ever) … without affecting any other entities, systems, or infrastructures.
Co-applying TTY resources for the transmission of ACN data is a process that is particularly well
suited to PC-based E9-1-1 Intelligent Work Stations. Typically, such PC-based terminals directly
import TTY communications, displaying the results on their screens. Many also incorporate
integrated mapping capabilities. Such terminals can easily parse location information from the
incoming ACN/TTY data stream, and automatically map the location on the screen for the calltaker.
This function-ability has been successfully demonstrated in field tests [see 3.3.7a, sub-notes 1) and
2)].
3.3.5 Impact
As stated previously, the nation's PSAPs are already TTY capable, and all necessary information can
be transferred directly from a vehicle's telematics system to any PSAP in the nation as is … i.e.,
requiring no changes or additions to the operation or equipment of those PSAPs. If/when a PSAP
facility upgrades its equipment to permit multiplexing, simultaneous voice and data communications
are made possible, and data communications can be made at increased Baud rates.
Perhaps most important is the fact that a migration path is inherent in this methodology, thereby
permitting the most basically equipped PSAP to upgrade to Advanced ACN/TTY at its own pace. If
and when it’s ready to do so, it needs simply to upgrade its own equipment … requiring no changes
to the infrastructure (i.e., the existing PSTN and then-existing vehicular telematics systems). In the
meantime, any PSAP can still receive all transmitted ACN data and can send back commands to
ACN-equipped vehicles.
Regardless of evolving technology as we move forward to NG9-1-1, it seems unlikely voice-band
TTY communications will become obsolete in the foreseeable future. Existing voice-band TTY
equipment and its use are too deeply invested in the traditions and pocketbooks of the speech-and-
hearing-impaired community. Consequently, whether viewed as a currently deployed medium that
can be exploited to transmit ACN data or as no more than a transitional step to more advanced
means, it seems highly unlikely the use of TTY will become obsolete for a very long time.
Even next generation 911 (VoIP) networks must maintain the logical voice channel … the channel
also used for ACN/TTY.
In summary the viable direct dialing of 9-1-1 by a vehicle's telematics/ACN system is completely
feasible and ready-for-use today and in the future without any changes to the 9-1-1 network or to the
nation’s PSAPs.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 38 of 44
3.3.6 Advantages
Once firmware (application program) has been included in a vehicle’s TCU, all other equipment and
elements required for complete functioning are already in place and in use.
Consequently, ACN/TTY:
requires no funding
is immediately ubiquitous
is immediately usable
is fully compatible with all systems delivering voice
is compatible with the transmission of ACN and/or supplemental text data:
directly from a crashed vehicle to a PSAP
directly from a TSP to a PSAP
3.3.7 Reference Notes
a. All of the following demonstrations were conducted successfully. Each included multiple
transmissions of ACN Data via 9-1-1 cellular calls routed by the local E9-1-1 system to the
PSAP indicated. All transmissions successfully communicated predetermined ACN
parameters to the PSAP. All transmitted ACN Data was simulated … i.e., vehicles were not
actually crashed. Pre-recorded, canned data was transmitted in Demo Items 1 and 2. Real-
time data was transmitted in all other demo items. TTY commands were successfully
transmitted from PSAP-to-vehicle in Demo Items 3 and 4. Demo Items 3 and 4 were
conducted by Connexis (see http://www.connexis.com).
1) Demonstrations at Gloucester County PSAP (New Jersey) on 10/4/05.
2) Separate demonstrations at Burlington and Camden Counties’ PSAPs (New Jersey)
on 10/5/05.
3) Expanded demonstrations at Burlington County PSAP (New Jersey) on 3/8/06.
Expanded capabilities included concepts complementing and providing a redundant
back-up source for the direct transmission of data from vehicles to PSAPs (details are
outside the scope of this paper).
4) Demonstrations similar to those on 3/8/06 were conducted in Michigan on 5/24/06
and 5/25/06.
b. The informal standard for the TTY “message precursor” comprises repeated taps on the space
bar.
c. Typically, the telephony voice band is considered to encompass 300-to-3000 Hz.
d. Back in the 1970’s, Motorola developed a frequency-division-multiplexing process for
sending telemetry signals completely within the telephony voice audio band. EKG traces were
transmitted, simultaneously with voice and mutually without interference, from remote on-site
paramedic units to overseeing doctors in emergency rooms. This process is still in use today.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 39 of 44
This voice-plus-EKG process is accomplished by separating the 300-to-3000 Hz. (see 3.3.7c,
above) telephony voice audio band into two sub-bands/channels: a band centered on 1400 Hz.
(ranging from about 1300-to-1530 Hz.) is dedicated exclusively to the telemetry channel; and
the entire remainder of the audio band is dedicated exclusively to voice. A 1400Hz. carrier is
amplitude-modulated by the (very low frequency) EKG signal and transmitted on the
telemetry channel from the remote paramedic unit to the hospital. Usurping this particular
slice of the voice spectrum from the voice channel leaves the critical speech “intelligibility
ranges”e untouched (see 3.3.7e, below).
Paramedics at a remote treatment site can converse, free of mutual interference, with an
overseeing doctor in a hospital ER as that doctor simultaneously views the patient’s EKG in
real-time.
Similarly, for this ACN/TTY application, the 300-to-3000 Hz. telephony audio band can be
separated into two voice-plus-TTY sub-bands/channels: a band centered on 1400 Hz. (ranging
nominally from 1300-to-1500 Hz.) dedicated exclusively to TTY digital data; and the entire
remainder of the audio band dedicated exclusively to voice.
In the multiplex mode, only the 1400 Hz. frequency is used to transmit data. As explained in
the text, the Binary Amplitude Shift Keyed (BASK) modulation technique is employed to
define the data bits in the data stream.
e. More information on the topic of speech intelligibility can be gleaned from a 2005 paper by
Meyer Sound Laboratories, Inc., entitled "Factors That Affect Intelligibility in Sound
Systems". The paper states that the two "heavy" voice bands are 135-to-400 Hz. (fundamental
range) and 1800-to-2500 Hz. (strongest consonant range).
f. The acronym "TTY" describes devices, protocols, and systems used for two-way text
conversation over the PSTN. Such devices (with associated protocols) are also referred to as
text telephones. The term TTY came into use in the U.S. because the technology was
borrowed from the Teletypewriter industry. TTY devices and protocols are the primary tools
used by speech or hearing impaired people for telephone conversation. The dominant TTY
protocol is ANSI/TIA/EIA 825, entitled "A 45.45 Baud FSK Modem"; however, other
protocols are also used. Some examples include: TurboCode; HiSpeed; and Bell 103. The
ITU/CCITT (the International Telecommunications Union, formerly the International
Telegraph and Telephone Consultative Committee) has approved V.18, a standard that
promotes universal design by incorporation of TTY into digital products. In addition to
supporting 45.45 and 50 TTY Baud rates, it supports DTMF, EDT, V.21, and V.23 standards,
which are used in Europe. As used herein, the term TTY refers to any and all such devices
and protocols used for text conversation over the PSTN by speech or hearing impaired people.
g. ACN/TTY key tap commands are 4-character commands of the form s[]s[], where []
represents a command-specific text character (occurring twice in the code sequence). Each
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 40 of 44
such code set can be quickly/easily entered on a keyboard by rocking two fingers back-and-
forth, (at least) twice, between the “s” key and the command-specific key represented by the
square brackets []. A few sample commands used in prior demonstrations (see 3.3.7a, above)
include:
stst, which means “switch to Talk (voice) mode;
slsl, which means (re)send Location; and
sksk, which means goodbye, hang up and terminate the call.
Obviously, many other commands can be sent in the same format. The key combinations
are selected to be unique, and not normally found in ordinary human text. Another
important example is smsm, which means switch to Multiplex mode (or any other
communications protocol predetermined by a combined telematics and 9-1-1 cooperative
group).
h. Illustration 1 depicts the most basic form of ACN/TTY. Basic ACN/TTY requires no
upgrades to function fully at a PSAP. It also comprises the initial contact mode for switching
to multiplexed TTY mode … or to some other communications protocol (see 3.3.7g,
immediately above). Protocol switching applies only to PSAPs that have elected to upgrade to
more sophisticated communications. In such cases, the initial contact phase of an ACN/TTY
communication can be fully automated so that it occurs transparently to the calltaker within
the first 1 or 2 seconds of the call. Similarly, an appropriately upgraded system can parse the
incoming text for location information, and then map it automatically on the calltaker’s
screen.
3.4 Native 9-1-1 Delivery Using Voice over Internet Protocols (VOIP), (TCS)
3.4.1 Overview
This solution provides a means to route emergency calls from a TSP Call Center (CC) to the correct
E9-1-1 Tandem via Voice over Internet Protocols (VoIP) and a nationwide network of Emergency
Service Gateway (ESGWs). Based upon the NENA VoIP i2 architecture, emergency wireless calls
arriving at the TSP CC can be converted to VoIP, and thus transported to any local ESGW, to be
converted back to Time Division Multiplex (TDM) and delivered to the E911 Selective Router for
delivery to the PSAP via the E911 network. Through the use of Emergency Service Query Key
(ESQKs), this solution allows the PSAP to retrieve ALI data via steered queries to a VoIP
Positioning Center (VPC). This solution requires no changes in the current operational procedures at
the TSP CC, although it is possible to enhance the current operations if the TSP CC desired to do so
via an Extensible Markup Language (XML) over TCP/IP interface to access the VPC. The
specification for this interface could be Vehicle Emergency Data Set (VEDS), developed by
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 41 of 44
ComCare and various telematics providers. This interface is an open specification and has been made
available to NENA.
3.4.2 Solution Description
When an emergency call from a Telematics equipped car arrives at a TSP CC, it contains data that is
pertinent to the location of the caller as well as collision information. The collision information
provides that is critical in evaluating the potential severity of the emergency. When the TSP
attendant receives these calls, they first determine if the call is an emergency by talking with the
person(s) within the vehicle (if the person is not speaking, the attendant can view the collision data
for an indication of an accident). If it is determined to be an emergency, then processing the call to
route based on location begins. The following paragraphs describe the solution.
When the TSP CC attendant determines the call is an emergency, they request routing instructions
from an Emergency Routing Data Base (ERDB). The ERDB can be an existing local database used
by the TSP CC for determining call routing, or it can be a remote ERDB provided by a third party.
The telematics equipment in the vehicle will generate a lat/long. The ERDB will enter the lat/long
into the ERDB database, which will identify the correct PSAP for that location. Alternatively, this
process can be automated. The PSAP will be identified by a dialable 10-digit number. The TSP CC
operator will initiate a three-way conference with that PSAP by dialing the designated number.
The call will be routed to a VoIP call server. The server can be accessed via the Public Switch
Telephone Network (PSTN) or it may be internal to the equipment at the TSP CC. If the call server
is accessed via the PSTN, the call server will query a VPC for call routing instructions, and provide
the VPC with the callback number of the TSP CC. If the call server is accessed via VoIP, the TSP
CC could forward location info and other call details using VEDS or NENA i2 standards.
Based on the dialed phone number from the TSP CC, the VPC determines the intended PSAP and
selective router and then assigns an ESQK, ESRN, and Last Routing Option (LRO), per NENA i2
standards. The VPC stores all the received data and returns to the call server an Emergency Service
Query Key (ESQK), used to identify the serving PSAP (similar to an Emergency Service Routing
Key (ESRK)), and an Emergency Service Routing Number (ESRN), used to route the call to the
correct E9-1-1 Tandem.
Using the ESRN and ESQK from the VPC response message, the VoIP call server establishes Real-
time Transport Protocol (RTP) across the internet and delivers the call to the appropriate ESGW,
which converts the call from Session Initiated Protocol (SIP) to TDM and routes the call to the
correct selective router as determined by the ESRN. The Selective Router uses the ESQK to query
the Selective Routing Data Base (SRDB) to determine the correct PSAP. The call is then routed to
the PSAP and the ANI (ESQK) is transmitted with the call to the PSAP. The PSAP queries the
Automatic Location Identification Database (ALI DB) with the ESQK. The ALI DB is provisioned to
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 42 of 44
steer ESQK queries to the VPC using the existing ALI protocol (PAM, VE2, NENA or XML). The
data associated with the ESQK is retrieved from the VPC and sent back to the ALI DB, which in turn
forwards the ALI record to the PSAP.
In the most rudimentary form, the ALI record presented to the PSAP would include the TSP 24x7
call back number (CBN), and identification of the TSP. The telephone number assigned to the
vehicle is non-dialable and the only access to the person in the vehicle is through the TSP CC; hence,
why the TSP 24x7 call back number is essential. Depending upon the data transmitted from the TSP
CC to the VPC, additional ALI data could include the lat/long of the incident, plus some minimal
additional data that could be parsed into various supplemental fields in the ALI message.
3.4.3 Call Flow
The figure below depicts what the above text described:
PSAP ALI
VPC
Cell Site
1 2 4
TCS
CRDB
Telematics
Call Center
Selective
Router
3
5
8
910
Wireless
MSC
12Telematics
PSAP DB
Media
gateway/
VoIP Call
Server
ESGW
6
7
11
13
14
900-xxx-yyyy=lat/lon=PSAP A PSAP A=ESQK/ESRN/LRO
Staged Record:
ESQK=CBN, ID
Lat/lon=PSAP A=900-xxx-yyyy
The call flow details follow:
1. A telematics device initiates a call to a local cellular tower which is forwarded to the serving
MSC. This causes a wireless call to be sent to the PSTN network.
2. The call is routed through a Mobile Switching Center (MSC) to the local End Office (EO)
serving the TSP CC.
3. The call received at the TSP CC consists of the location, data from the collision, and the
voice call. The attendant at the TSP CC receives the call and determines emergency help is
required. The attendant queries the local ERDB with the location of the caller (lat/long) to
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 43 of 44
determine which PSAP should receive this call. The ERDB provides the PSAP info and a 10-
digit phone number for that PSAP.
4. The attendant establishes a conference call by dialing the 10-digit number. The call is passed
via the PSTN to a VoIP call server.
5. Based upon the dialed digits, the VoIP call server determines that this is an emergency call
and queries the VPC for routing instructions by forwarding the dialed digits.
6. The VPC queries the ERDB to determine the proper PSAP based upon the forwarded digits.
7. The VPC assigns an ESQK designated for that PSAP and stages a record with the ESQK and
CBN and NENA ID of the telematics provider.
8. The VPC responds to the routing query with the ESQK, ESRN and LRO.
9. The VoIP call server uses the ESRN to determine the appropriate ESGW and routes the call
appropriately.
10. The ESGW converts the SIP protocol to TDM, and uses the ESQK to determine the correct
PSAP and routes the call appropriately.
11. The selective router delivers the call and the ESQK to the PSAP
12. The PSAP queries the ALI database with the ESQK.
13. The ALI steers the query to the correct VPC per the ESQK. The VPC responds to the ALI
query with the staged ALI record for that ESQK.
14. The ALI forwards the data to the PSAP.
3.4.4 Benefits
Delivers the call as native 9-1-1 using the ESRN over existing voice facilities.
Passes a key with the initial voice call that allows for retrieval of ALI data when the call is
delivered to the PSAP
ALI data includes a callback number to the TSP CC, TSP provider name, Incident ID (IID)
and, optionally, lat/long and collision information
The IID can be used to retrieve additional data, if applicable (possible web interface from
PSAP to a secure site for the collision data or other)
No new software to any 9-1-1 entity or LEC interfaces.
A single, nationwide solution using existing infrastructure that is not reliant upon individual
LECs to adopt new procedures or routing protocols.
Treatment of enhanced vs. basic PSAPs is transparent to the TSP CC.
NENA Technical Information Document on
Automatic Collision Notification and Vehicle Telematics
NENA 07-504, June 1, 2007
NENA 07-504, June 1, 2007
05/05/2016: This document is not subject to further review or revision, but is available as a
reference.
Page 44 of 44
4 References
Hatfield, Dale N. (2002). A Report on Technical and Operational Issues Impacting the
Provisions of Wireless Enhanced 911 Services
TIA/EIA IS-JSTD-36. (2000). Enhanced Wireless Emergency Services (E-911 phase 2)
ANSI/TIA/EIA-41-D-Standard. (1997). Cellular Radio Telecommunications
U.S. Department of Transportation/ComCare Alliance. (2000). National Mayday
Readiness Initiative (NMRI) Final Report, p. 6-7