2. Understanding & Defining Additional Data Interfaces in NG9-1-1
Understanding & Defining Additional Data Interfaces in NG9-1-1 Session Type: 101 Know Before You Go: NENA’s NG9-1-1 Additional Data standard Outcome: An understanding of what additional data is and how it is managed in NG9-1-1, as well as how you may participate in ongoing development work. This session introduces the audience to the additional data interface standards, describes how additional data is exchanged between NG9-1-1 components, and provides examples of how this information might be used in the future.
Matthew Serra, ENP Karl Larsen

3. 9-1-1 Today …
An individual in an abusive relationship, dials in to summon emergency responders. Their assailant quickly terminates the phone call.
A telecommunicator, who was not on the phone long enough to retrieve dispatch-quality location, wishes to contact the caller’s communication services provider to file an exigent circumstance request.

4. 9-1-1 Today …
A family member, who observes a family in distress, dials in order to summon emergency responders. A telecommunicator, who cannot ascertain basic facts from the panicked caller, seeks additional information to determine what resources should be dispatched to the caller’s address.

5. 9-1-1 Today …
A factory worker, who observes an industrial accident, dials 9-1-1, in order to summon emergency responders. A telecommunicator, who recognizes the complexity and severity of the situation, seeks more information about the location in order to dispatch and inform resources as warranted by the nature of the emergency.

6. What is meant by Additional Data?
Supplemental data above and beyond what is necessary to complete an Emergency Call.
3 types:
Additional Data for the Call
Additional Data for the Caller
Additional Data for the Location

7. What is Additional Data for the Call?
Information about the service provider or network access provider
Information about the provider’s service used to complete the call
Information about the device used to place the call
Contact information for the service subscriber

8. What is Additional Data for the Caller?
Basic Contact Information (name, address, contacts)
Emergency Contacts
Custom information such as medical or other biographic data

9. What is Additional Data for the Location?
Basic Contact Information (name, address, contacts) for site/structure
Emergency Contact Information for site/structure
Custom information such as floor plans, access information, perhaps even building telematics (e.g. alarm system, sensors, cameras)

10. Where is Additional Data Defined?
Functional Elements and Interfaces:
NENA i3 Standard: NENA STA.010.2
The data format:
IEFT RFC: Additional Data Related to an Emergency Call (RFC 7852)
IETF RFC: xCard: vCard XML Representation
(RFC 6351)
NENA Standard for NG9-1-1 Additional Data:
NENA STA (In Progress)
The NENA i3 Standard: NENA STA.010.2
Defines the Functional Elements and interfaces mechanisms used to source, share and how to access Additional Data
The IEFT RFC 7852: Additional Data Related to an Emergency Call
Provides examples of how blocks are populated into Call-Info headers and the PIDF-LO
The NENA Additional Data Standards Draft: NENA STA.012.2
Summarizes the above sources, in an Additional-Data-Centric (rather than Functional Element Centric) and NENA-i3-Centric (rather than IETF-generic) way.

11. What Does Additional Data Look Like?
Patterned after the precedent set for Additional Call Data (IETF RFC 7852)
Organized into XML “blocks”
Where possible, blocks are reused across the 3 types of Additional Data
Additional Data is carried in XML documents
Data is organized by logical “Block”
Blocks are intended to be reusable across types of Additional Data where possible
For example, defined Blocks include:
Provider Information
Service Information
Device Information
Comment
The blocks were designed specifically for Additional Data, however common/open standards are used where possible, such as the use of xCARD to carry contact-style information.
The Additional Data XML requirements are managed through two standards:
An IEFT Draft RFC: Additional Data Related to an Emergency Call
Describes Additional Data for the Call in detail
Defines the “Block” model for organizing Additional Data
Some “Blocks” are reused for Caller and Location data
A NENA Draft Standard: NENA STA.012.2
A summary of conveyance, pulled from IETF and NENA.STA.010.2
Block Definitions for Caller and Location data
Guidance on the population of xCARD
Will eventually include Schemas, once out of WG review

12. Additional Data Blocks
Provider Info
Service Info
Device Info
Subscriber Info
Comment
Caller Info
Location Info
Call X
Caller
Location

13. Where Does Additional Data Come From?
Functional Element
Type of Additional Data
Call
Caller
Location
Device or User Agent X
ADR
(Additional Data Repository)
IS-ADR
(Identity Searchable - ADR)
LIS PIDF-LO Source

14. How Is Additional Data Accessed?
“by-reference” – data accompanying the call points to an external source.
“by-value” – data is included within the call itself.
“queried” – searching to discover or retrieve data:
Searching on “Caller ID” (From URI or P-A-I)
Search on location (geodetic or civic)

15. How Do I Access Each Type of Additional Data?
“by-reference” in SIP Call-Info Header
“by-value” in SIP Call-Info Header
“by-value” in PIDF-LO
“by-reference” in PIDF-LO
Data URI ”Queried”
from a Resource
Call Data X
Location Data
Caller Data

16. Simplistic Data “By-Value”
ESINet
SIP INVITE urn:service:test.sos
Call-Info: ;purpose=EmergencyCallData.ProviderInfo
Content-Type: application/EmergencyCallData.ProviderInfo+xml Content-ID:
. . .
<pi:EmergencyCallData.ProviderInfo xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
. . .
</pi:EmergencyCallData.ProviderInfo>

17. Simplistic Data “By-Reference”
ESINet
SIP INVITE urn:service:test.sos
Call-Info: purpose=EmergencyCallData.ProviderInfo
ref="
Curious FE
ADR
<pi:EmergencyCallData.ProviderInfo xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
. . .
</pi:EmergencyCallData.ProviderInfo>

18. Simplistic Data “Queried”
ESINet
SIP INVITE urn:service:test.sos
From: Matt
Curious FE
IS-ADR
From: Matt
<pi:EmergencyCallData.CallerInfo xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:NENA-CallerInfo">
. . .
</pi:EmergencyCallData.CallerInfo>

19. Simplistic Data “Queried”
ESINet
findService:additionalData
<location>
</location>
Curious FE
ECRF
ADR
<pi:EmergencyCallData.NENA-LocationInfo xmlns:pi="urn:ietf:params:xml:ns:EmergencyCallData:NENA-LocationInfo">
. . .
</pi:EmergencyCallData.LocationInfo>

20. Sample Use Case: Additional Data for the Call
An individual, who is in an abusive relationship, dials in to summon emergency responders. However their assailant quickly terminates the phone call.
A telecommunicator, who was not on the phone long enough to retrieve dispatch-quality location, wishes to contact the caller’s communication services provider to file an exigent circumstance request.
Example Flow:
The calling device provides the ESInet with coarse (Phase-I style) location information to support call routing. The SIP invite also contains Call-Info headers containing Additional Data for the Call, conveyed “by-value”.
The call is routed to the provisioned PSAP, and answered by a telecommunicator.
The telecommunicator’s workstation displays various information for to the call, including contact information for the caller’s communication services provider as conveyed within the Additional Call Data.
The telecommunicator hears background noise typical of a struggle, and the call is terminated.
The telecommunicator contacts the Communication Service Provider identified in step 3, issuing an exigent circumstance request to retrieve dispatch quality location for the caller.
The telecommunicator uses the information gained through step 5 to dispatch law enforcement to the identified location.

21. Sample Use Case: Additional Data for the Caller
A family member, who observes a family in distress, dials in order to summon emergency responders.
A telecommunicator, who cannot ascertain basic facts from the panicked caller, seeks additional information to determine what resources should be dispatched to the caller’s address.
Primary Functional Flow:
The calling device’s From-URI is presented to the ESInet within the SIP INVITE. The call is routed to the provisioned PSAP, and answered by a telecommunicator.
The telecommunicator’s workstation client queries the IS-ADR’s known to the PSAP to determine if there is any information associated with the calling device.
The IS-ADR returns the Additional Data for the Caller Blocks previously registered against the From-URI.
The PSAP workstation presents the telecommunicator with the Additional Data for the Caller content, formatted for human consumption.
The telecommunicator, now informed of extensive pre-existing medical conditions associated with a household member, decides to immediately dispatch Advanced Life Support rather than Basic Life Support, to shorten the time to deliver life-saving medical intervention.

22. Sample Use Case: Additional Data for the Location
A factory worker, who observes an industrial accident, dials 9-1-1, in order to summon emergency responders.
A telecommunicator, who recognizes the complexity and severity of the situation, seeks more information about the location in order to dispatch and inform resources as warranted by the nature of the emergency.
Primary Functional Flow:
Incident reporter dials Device location is presented to the ESInet through the PIDF-LO, and is adequate to locate the caller within the bounds of the factory.
The call is routed to the provisioned PSAP, and answered by a telecommunicator
The telecommunicator’s workstation client queries the ECRF to discover any Additional Location Information that may be available to for the caller’s location.
The ECRF discovers it has an Additional Location Data URI for the proffered location. This URI is returned to the telecommunicator’s workstation client.
The telecommunicator’s workstation client dereferences the URI against the ADR that hosts provided URI.
The ADR returns the Additional Data for the Location Blocks associated with the URI
The PSAP workstation presents the telecommunicator with the Additional Data for the Location content, formatted for human consumption.
The telecommunicator, now informed of Location details, dispatches a fire truck that can deploy foam fire suppressant, and directs this equipment to the gate nearest the incident.

23. The Roadmap for Additional Data
Release the NENA Standard for Additional Data NENA STA (approaching 2nd round of Authoring Committee Review).
Test vendor implementations at NENA Industry Collaboration Event (ICE-7), Spring 2017.
Scope and timeframe NENA STA.012.3

24. Questions
Q & A