In previous posts, I’ve discussed how some “Legacy ALI” data will be sourced through NG9-1-1 Additional Data, and options for how 9-1-1 might control how Additional Data is delivered. However I still get questions on what is (and is not) considered Additional Data. Maybe it’s worth taking a step back:
Additional Data as Defined by NENA:
Per NENA’s 08-003 i3 Specification, Additional Data is “Data which further describes the nature of how the call was placed, the person(s) associated with the device placing the call, or the location the call was placed from. There are three types of Additional Data: Additional Call Data, Additional Caller Data and Additional Location Data”
Additional Data Examples:
“Additional Call Data” is information provided by a service provider (such as a VoIP “carrier”), or by an access provider (such as an internet service provider), to describe the nature of the caller’s communications service, who the service is billed to, and 24x7 contact information for the service provider’s help desk. Those familiar with ALI will see a lot of overlap here. The format of Additional Call Data is fairly mature, and is in the review process managed by the IETF’s ECRIT work group.
“Additional Caller Data” is information which describes the person placing the call. This may carry information about more than one person. A common example would be where a 9-1-1 call is placed from a land-line phone accessible to all members of the household. Additional Caller Data typically includes the caller’s name, biographical statistics, common addresses, emergency contacts, and preexisting medical conditions. This information is used to supplement the real-time information communicated by the caller through the call itself. How this data will be formatted is currently under development.
“Additional Location Data” is information which is used to further describe the caller’s location. This includes information about the building or environment that may be relevant to the call. By and large, I anticipate this information will be fairly “static” - in that it determined before the call is placed. However there are provisions to make “dynamic” data available as well. Dynamic data could include sensor data (perhaps describing the state of a fire alarm panel). As you will see, this is a gray area, and there is a need for further clarification. Here too, the data format is under development. NENA will first look to existing data formats to fill this need.
Not Additional Data:
Sometimes it helps to define something by saying what it is not. NG9-1-1 introduces an extraordinary amount of “data” or “information” beyond what is described above. It’s tempting to categorize much of this new information as “Additional Data”, as it is all new to us. However, it is important to carefully define our terms so we can communicate clearly with one another. Here are a few examples of information I feel are sometimes incorrectly referred to as “Additional Data”
Telemetry Data: NG9-1-1 provides mechanisms to deliver telemetry data, such as that generated by in-vehicle crash sensors, alongside a 9-1-1 call. A student of NG9-1-1 might say “Hey, telemetry data can be passed inside Additional Call Data!” This is true. However I still view telemetry data as its own type of data for a few reasons:
- Technically, telemetry data can also come via other routes, such as carried by a SIP MESSAGE
- In time, telemetry data will be the call itself. The i3 specification describes how a non-human initiated call can be generated, allowing vehicle crash notification systems or smart-buildings to directly notify 9-1-1 of an incident.
- The IETF Additional Call Data specification allows for a registry to grow in response to the various types of telemetry data
- It is defined outside of NENA’s Additional Data Work Group
Data Collected by the 9-1-1 Community: Information which originates from any point AFTER the call-taker is not considered Additional Data. Who answered the call, what resources were dispatched, what was returned by a NCIC search is information generated by actions of the 9-1-1 community. Most, if not all, of this information is captured within the Emergency Incident Data Document (EIDD) generated in response to the incident.
Caller Address / Location: The location (latitude and longitude) or civic address associated with a call is central to 9-1-1 call processing, and as such, stands as its own category of information in NG9-1-1. Today we refer to this as “ALI”, but in NG9-1-1 it will be carried in a format referred to as the Presence Information Data Format-Location Object (PIDF-LO).
In my next blog, I’ll finish this discussion by describing how the above Additional Data is sourced and associated with a given call.
I hope this overview was helpful, and that it will make future discussions more meaningful. I encourage you to ask questions or provide feedback here.
If you are attending NENA National, please stop by both #1143 to say “Hi”, and attend the Additional Data Today: A Window Into the Future of NG9-1-1 Panel, on Wednesday June 13th at 1:30pm in room 101B.
you may also like
How California's Disaster Communication Plan Failed Residents During Deadly Wildfires
Matt Serra, ENP
March 28, 2018
“People didn’t die from the smoke. People didn’t die from the fire. People died because they didn’t know something was coming.”
-Joseph Solis, former 911 dispatcher employee...