Emergency Incident Data
Document (EIDD) Transfer
Protocols
Jerry Schlesinger, PMP – City of Portland OR
Daniel Mongrain –Bell Canada
Brian Rosen – Neustar
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
Session Topics
 EIDD
Evolution and Current Status
 EIDD
Queries
 EIDD
Transport Mechanisms
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
What is an EIDD?
A
standardized format for exchanging
Emergency Incident Information
 Defines
the data elements that characterize
emergency incidents (incident type, location,
etc.)
 Groups
data elements into logical data
components (caller, incident, dispatch, etc.)
 Establishes
the relationship between data
components
 Developed
N E N A
D e v e l o p m e n t
by a joint APCO/NENA WG
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
What is an EIDD? (Cont.)
 National
Information Exchange Model
(NIEM) conformant
 XML
Schema
 Information
Exchange Package
Documentation (IEPD)
 In
the process of becoming an American
National Standard (ANS)
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
Why Do We Need an EIDD?
 NG9-1-1systems
normally communicate
with each other over IP-based networks

Core services applications typically
communicate via SIP through the ESInet
 Functional
elements (FEs) within a PSAP normally
communicate over LANs and WANs
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
Why Do We Need an EIDD? (Cont.)
 FEs
in different PSAPs need to communicate
with each other through the ESInet and/or
private networks
 SIP
and Web Services are the preferred
methods for exchanging data through these
networks
A
standardized, non-proprietary
method for exchanging incident
information is needed
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
FEs Defined by NG-PSAP WG
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
EIDD Exchange Rules
EIDDs are required for information exchanges between two or
more disparate manufacturer’s systems
Dispatch
Call
Handling
Management
Console
Incident
Record
Handling
EIDDs
Mobile Data
Computer
Login Service
Vendor A
Vendor B
EIDDs are not required within a
single manufacturer’s system
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
More EIDD Exchange Rules
 EIDD
Users must be authorized to receive or
view EIDD content
 Need
to authenticate before receiving EIDDs
 EIDD contents filtered based on User’s role
 EIDDs
should be validated against the
forthcoming EIDD ANS XML Schema
 EIDDs should be validated against the
business rules included in the EIDD IEPD ANS
 Significant changes to an incident require an
EIDD to be issued
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
Typical EIDD Exchanges within PSAPs
 Call
Handling to Incident Handling
 Incident
Handling to Dispatch
 Dispatch
to Incident Handling
 Dispatch
to Mobile Data
 Mobile
 All
Data to Dispatch
FEs to Logging Services (recorder)
 Most
interactions between FEs involve EIDD
exchanges
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
Typical EIDD Exchanges between PSAPs
 Call
transfers – additional information collected
at the original PSAP
 Secondary PSAPs – Call takers to dispatchers
located in a secondary PSAP
 Dispatch/Incident Handling to Dispatch in
different PSAP – Automatic/Mutual aid, responder
status updates, etc.
 Major Incidents – sharing incident information,
requesting resources
 Most interactions between NG9-1-1 systems
involve EIDD exchanges
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
Other EIDD Exchanges
 PSAP
to Emergency Management (filtered)
 PSAP to News Media (highly filtered)
 PSAP to Towing company

This can also be any company outside Public Safety
that provide services on the scene of an Incident
 CAD
to RMS – follow up reports, archived
information
 Others we haven’t thought of yet
 Responders
to hospital
 Suggestions?
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
EIDD ANS Status
 EIDD
Information Document published on
NENA Website (NENA-INF-005, 2/21/14)
 EIDD
WG moved from NENA to APCO to
complete the EIDD ANS process
 SEARCH
developed a NIEM conformant IEPD
based on the EIDD INF
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
EIDD ANS Status (Cont.)
 WG
reviewing/adjusting EIDD INF and IEPD
 Identifying
done
person and vehicle data elements –
 Updating
IEPD and XML Schema as required –
In progress
 Insuring
compatibility with i3 schemas
 EIDD
transport not currently addressed in the
EIDD ANS
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
EIDD ANS Status (Cont.)
 IJIS
and APCO EIDD Springboard
 Test
 13
feasibility of EIDD IEPD
Vendors currently participating
 Will
certify vendor conformance with EIDD ANS
 EIDD
ICE event – to be planned
 EIDD
ANS public review – 1st quarter of 2015*
* Estimate
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
Transport Mechanism Status

STA-010.2 (08-003 V2) has EIDD transport in a SIP
transaction (as part of a call transfer) as well as a
“dereference” mechanism for EIDD-by-reference

Brian Rosen contributed a document to i3-arch that
contains a proposal for additional transport options:

Subscribe/Notify

Asynchronous Push
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
EIDD Queries

Supported through proposed subscription filters:
 Incident Tracking ID – current status of incident
 Active incident within an agency – returns list of
incident tracking IDs
 Active incident within a geographic area – returns
list of incident tracking IDs
 All EIDDs for an Incident Tracking ID within a time
interval – returns latest updates

Not supported:
 All agencies involved in an incident
 Others?
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
EIDD Transport in 9-1-1 Calls

Required during a conference and/or transfer with
another agency

EIDD is found in the Call-Info header, with a
purpose of “eidd”

The INVITE includes the EIDD by value (actual data)
or by reference (a link where to get the data)
 Reference
embedded in Call’s SIP and EIDD retrieved via
dereferencing (HTTP GET)
 Embedded
EIDD requires prior filtering
 Dereferencing
authentication
N E N A
D e v e l o p m e n t
enables filtering based on real-time
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
Subscribe/Notify
 FEs
subscribe with each other for EIDD
updates

Subscribe by Incident ID to get all updates for an
Incident

Subscribe for one NOTIFY per new Incident to find
out about incidents
 Filter
mechanism for subscriber to control
NOTIFYs it gets

Rate Controls

Content Controls (notify when certain sections
change)
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
EIDD Transport – Subscribe/Notify
 FE
sends a notify to all subscribed systems
meeting filter criteria that an EIDD is available
 Two
protocol bases are being discussed to
provide the Subscription/Notification service:
 SIP
SUBSCRIBE/NOTIFY – EIDD included in the
body of SIP messages
<Mime header of application/emergencyincident-data-document+xml >
 Web
N E N A
service
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
Asynchronous EIDD Transport

EIDDs are “pushed” to systems, requesting actions from the
receiving entities
 Normal
“dispatch” type actions
 Request
specific resources or actions

Receiving agencies set policies on the types of asynchronous
EIDDs that they will receive, if any

Proposal uses the SIP MESSAGE method
 This
leverages the ESRP’s Policy Routing Function to route
the request to the most appropriate agency at that time,
similar to how calls are routed
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
Async EIDD Transport (Cont.)

Normal generic Dispatch request just has an EIDD

Receiving Agency Use OASIS EDXL-RM 1.0 resource
management mechanism for incident in which the
response is not obvious
 Uses
 EDXL
the EDXL “Distribution Element”
message included in the SIP MESSAGE body
 Mime
header of application/emergency-data-exchangelanguage+xml
 Plus
N E N A
the EIDD
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a
EDXL Message Types
OASIS has specified appropriate EDXL message
types and responses
 Message types and responses included in EIDD
transport specifications
 Typical message types:

 Request
resource – request to receiving agency to
dispatch resources to an incident
 RespondToRequest – will agency provide requested
resource; type and number provided
 Requisition resource – can agency provide resources for
incident
 Wealth of other message types are available
N E N A
D e v e l o p m e n t
C o n f e r e n c e
|
O c t o b e r
2 0 1 4
|
O r l a n d o ,
F l o r i d a