General Format Information

weightwelloffΚινητά – Ασύρματες Τεχνολογίες

12 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

130 εμφανίσεις


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
1

of
68


F
ollowing are the sections of the Technical
Requirements
Document that should be filled in by the
Working Group

that

is

building or updating a
TR
D
.



When completed
,

this form shall be returned to NENA’s Committee Resource Manager
:

Sophie Vick

who can be reached at
svick@nena.org


Please contact
Sophie

with ANY questions about this form.


General Format Informati
on



The CRM will establish the
document cover page, headers and footers based on the information
provided by the Working group in this form’s “Specific Document Information” section.



The CRM will place the Working Groups supplied text for each identified secti
on into the
appr
opriate section of the latest TR
D template and apply the appropriate template section header,
body text and spacing formats.



The CRM will establish the
Table of Contents after document formatting is completed.



The document editor need not b
e concerned with specific
section
formatting of the form
contents.



The document editor should be

consistent with the use of bullets

or item numbering.



The document editor should c
learly identify level 2
-
4 headings for sub
-
sections within the
“Technical De
scription” section.



The document editor should verify that drawings placed into the Working Group’s text are
formatted as a Windows enhanced metafile (.wmf).



The document editor shall review the form prior to sending it to the CRM for formatting. Each
sup
plied section
that includes the phrase “
Work Group
TEXT her
e…”
requires Work Group text.


Specific
Document
Informati
on

(required information)


Name of Document

NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA Do
cument # (If assigned)
(ex: 08
-
75X
)

NENA 04
-
xxx

Document Version #

Version 0.2
9

Latest date of document update (ex: 11/15/08)

09/14
/12


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
2

of
68


Name of this Working Group’s Parent
Committee ( ex: NENA Network Committee)

Agency Systems

Committee

Working group name: (ex: XYZ Working
group)

NG9
-
1
-
1

PSAP CPE

Work Group contact name

Michael Smith


Work Group contact number

606.877.2788


Work Group contact email address

msmith@DSS
-
CORP.COM



The following sections of the
TRD

require Working Group supplied text:



Black text is to remain unchanged and is supplied so the WG understands the
standard text

of the
specific section
; or to identify the text which is included in the document that the work group
may need to know
.

This text will be preceded
by
NOTE to document editor:
The follow
ing

statem
ent will be included in every TR
D.



[B
racketed red text requires
update by the work group]
based on directions

provided in blue text
.
The directions can be removed prior to
submitting the form to the CRM
.



Work Group
TEXT here…

is where the Work Group shall pla
ce their text for the section. If the

identifier is not present, the Work Group does not supply text.

1

EXECUTIVE

OVERVIEW

................................
................................
................................
..............................

6

1.1

S
COPE

................................
................................
................................
................................
................................
...

6

2

INTRODUCTION

................................
................................
................................
................................
..............

7

2.1

O
PERATIONA
L
I
MPACTS
S
UMMARY

................................
................................
................................
......................

7

2.2

S
ECURITY
I
MPACTS
S
UMMARY

................................
................................
................................
.............................

8

2.3

D
OCUMENT
T
ERMINOLOGY

................................
................................
................................
................................
..

8

2.4

R
EASON FOR
I
SSUE
/R
EISSUE

................................
................................
................................
................................
.

8

2.5

R
ECOMMENDATION FOR
A
DDITIONAL
D
EVELOPMENT
W
ORK

................................
................................
..............

9

2.6

D
ATE
C
OMPLIANCE

................................
................................
................................
................................
...............

9

2.7

A
NTICI
PATED
T
IMELINE

................................
................................
................................
................................
......

10

2.8

C
OSTS
F
ACTORS

................................
................................
................................
................................
..................

10

2.9

F
UTURE
P
ATH
P
LAN
C
RITERIA FOR
T
ECHNICAL
E
VOLUTION

................................
................................
..............

10

2.10

C
OST
R
ECOVERY
C
ONSIDERATIONS

................................
................................
................................
...............

10

2.11

A
DDITIONAL
I
MPACTS
(
NON COST RELATED
)

................................
................................
................................
.

11


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
3

of
68


2.12

I
NTELLECTUAL
P
ROPERTY
R
IGHTS
P
OLICY

................................
................................
................................
....

11

2.13

A
CRONYMS
/A
BBREVIATIONS
/D
EFINITIONS

................................
................................
................................
....

12

3

TECHNICAL DESCRIPTIO
N

................................
................................
................................
.......................

15

3.1

A
RCHITECTURE

................................
................................
................................
................................
...................

15

3.1.1

Assumptions

................................
................................
................................
................................
..............

15

3.1.2

Functional Elements

................................
................................
................................
................................
.

15

3.2

G
ENERAL
T
OPICS

................................
................................
................................
................................
................

19

3.2.1

Emergency Incident Data Document

................................
................................
................................
........

19

3.2.2

General Display

................................
................................
................................
................................
........

19

3.2.3

Management Console

................................
................................
................................
...............................

19

3.3

N
ETWORK
L
AYER
F
UNCTIONAL
E
LEMENTS

................................
................................
................................
........

20

3.3.1

NG9
-
1
-
1 PSAP Network

................................
................................
................................
...........................

20

3.
3.2

Emergency Call Routing Function and Emergency Services Routing Proxy Functional Elements

..........

21

3.3.3

Location Validation Function

(LVF)

................................
................................
................................
........

25

3.3.4

Border Control Function (BCF)

................................
................................
................................
...............

25

3.3.5

PSAP Administrative PBX

................................
................................
................................
........................

25

3.3.6

Radio Interface

................................
................................
................................
................................
.........

26

3.4

................................
................................
................................
................................
................................
................

27

3.5

C
OMMUNICATIONS
F
UNCTIONAL
E
LEMENTS

................................
................................
................................
......

27

3.5.1

Emergency Call Handling

................................
................................
................................
........................

27

3.5.2

TTY/TDD

................................
................................
................................
................................
..................

32

3.5.3

Void (To be renumbered before all committee review)

................................
................................
.............

32

3.5.4

Emergency Notification System

................................
................................
................................
................

32

3.5.5

Physical Considerations

................................
................................
................................
...........................

32

3.5.6

System Alarms

................................
................................
................................
................................
...........

33

3.5.7

Installation

................................
................................
................................
................................
................

33

3.5.8

Quality and Reliability

................................
................................
................................
..............................

34

3.5.9

Security

................................
................................
................................
................................
.....................

35

3.5.10

Interactivity Media Response FE

................................
................................
................................
.........

35

3.6

I
NCIDENT
A
PPLICATION
S
ERVICE
L
AYER
F
UNCTIONAL
E
LEMENTS

................................
................................
....

35

3.6.1

PSAP Incident Record Handling Functional Element

................................
................................
..............

35

3.6.2

Map Display Software Functional Element Description

................................
................................
..........

38

3.6.3

Management Information System (MIS)

................................
................................
................................
...

41

3.6.4

Dispatch System
Functional Element

................................
................................
................................
.......

44


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
4

of
68


3.6.5

Records Management System (RMS)

................................
................................
................................
........

47

3.6.6

Mobile Data Computer System

................................
................................
................................
.................

50

3.6.7

Logging Service

................................
................................
................................
................................
........

54

3.6.8

Incident Data Exchange

................................
................................
................................
...........................

60

3.7

I
NCIDENT
S
UPPORTING
L
AYER
F
UNCTIONAL
E
LEMENTS

................................
................................
....................

63

3.7.1

Time Server Functional Element

................................
................................
................................
..............

63

3.7.2

Alarm Systems

................................
................................
................................
................................
...........

63

3.7.3

Responder Alerting Systems
................................
................................
................................
......................

63

3.7.4

Data Services

................................
................................
................................
................................
............

63

3.8

C
OLLABORATION
C
LIENT
FE

R
EQUIREMENTS

................................
................................
................................
....

64

4

RECOMMENDED READING
AND REFERENCES

................................
................................
..................

65

5

EXHIBITS

................................
................................
................................
................................
........................

66

6

PREVIOUS ACKNOWLEDGM
ENTS

................................
................................
................................
..........

66


Acknowledgements

NOTE to document editor:
The follow
ing

statem
ent will be included in every TR
D.

NENA recognizes the following industry experts and their companies for their contributions in
development of this document.



[
The table below will only contain the names of
Technical Committee leadership and WG members who
contribut
ed (verbally and written) to this version of the

document.

Add additional table lines as needed
]


Members

Company

Mike Vislocky

Committee Chair

Network Orange, Inc.

Robert Walthall
Committee
Vice
-
Chair

AT&T

Charles Corprew
WG Lead

AT&T

Delaine Arnold

NENA

Sam Bard

MicroData

Holly Barkwell
-
Holland

BH Group

Rick Blackwell

Greenville County

Glenn Bowers

Zetron, Inc

Glenn Burdett


Theresa Carrasco

Riverside County Fire


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
5

of
68


Graham Chloupk


Bob

Connell

Zetron

Jeroen de Witte


Richard Frye

Frye Communications

Joe Gallelli

Zetron

Martin Harnois

Plant CML

Kevin Haynie

MicroData

Kevin Kleck

Tarrant County 9
-
1
-
1

Dave Hopkins


Garry Hutchins

Intrado

Nate Kirschman

Intergraph

Glenna
Johnson

DeKalb County

Rick Jones

NENA

Nate Kirschman

Intergraph

Kevin Kleck

Tarrant County

Jared Lamere

State of Vermont

Ben Lightner

AT&T

Jim Lipinski

State of Vermont

Kathy McMahon
-
Ruscitto

APCO

Christian Milteau

Intrado

Linda Ogilvie

Integraph

Kantu Patel

Kantu Patel

Perry Prozeniuk

Nortel

Brian Rosen

Neustar

Robert Russo

AT&T

Richard St. Jean

Plant CML

Imas Sakin

Zetron

Jerry Schlesinger

RCC

Robert Sherry

Intrado


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
6

of
68


Jeremy Smith

Kimball

Mike Smith

DSS

Barb Thornburg

NENA

Henry
Unger

Hitech

Richard Van Tieghem

Verint

Mike Vislocky

Network Orange

Robert Walthall

National Public Safety Solutions

Nate Wilcox

MicroData

Marc Wise

AT&T

Dan Mongrain

Frequentis USA


This committee would also
thank
Tom Breen
,
Tony Busam

and
Roger
Hixson

for th
eir support and
assistance.



1

Executive Overview

Major changes in the existing emergency services architecture are being driven by the rapid evolution of
the types of devices and services that can be used to
request emergency services
. Also
there is an
increasing volume and diversity of information that can be made available to assist PSAPs and
responders in an emergency. NENA recognizes this is a fundamental update to the North American 9
-
1
-
1 system, and is addressing the challenge with a sy
stem design called “Next Generation 9
-
1
-
1” (NG9
-
1
-
1). NG9
-
1
-
1 is the evolut
ion of Enhanced 9
-
1
-
1 to an all
IP
-
based emergency communications system.

This technical requirements document introduces requirements for a NG9
-
1
-
1 Public Safety Answering
Point (
PSAP) that is capable of receiving IP
-
based signaling and media for delivery of emergency calls
conformant to the i3 standard.

An emergency call

enters the
NG9
-
1
-
1

PSAP

using Session Initiation
Protocol (SIP) signaling. NG9
-
1
-
1 encourages the creation of m
any new coordination and information
access services to enrich collaborative interactions between all agencies involved in processing
emergency service requests. This document is issued as the NENA
’s

recommended
requirements
for
functions and interfaces be
tween
an ESInet and
NG9
-
1
-
1

PSAP, and among Functional Elements
associated with the
NG9
-
1
-
1

PSAP
.

1.1

Scope

The scope of this document is intended to provide the detailed technical requirements for an
NG9
-
1
-
1

PSAP that is capable of interoperating with an Em
ergency Services IP Network (ESInet)
.

It also
describes the application service environment of the
NG9
-
1
-
1

PSAP and the interfaces required for
processing of an
Incident
. In this context a PSAP is not intended to indicate a single physical premise.

NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
7

of
68


A PSAP

may consist of
Telecommunicators
, Dispatchers,
a
pplications and
services
within a single
physical location or geographically distributed using IP connectivity
.


The lifecycle of
an incident

begins at the moment
an emergency call

is initiated. For the pur
poses of this
document
,

the
life cycle
of the
PSAP Incident

starts
with the arrival of the
emergency call
at the PSAP
and ends with
its final archiving and closure.



An emergency call
encompasses all communication(s) between the originator (caller) and th
e NG9
-
1
-
1
PSAP including voice.

This document uses the word “call” to refer to a session established by signaling
with two way real
-
time media and involves a human making a request for help,
or an automated device
sending a notification or other data
. We
sometimes use “voice call”, “video call”, or “text call” when
specific media is of primary importance.

The Functional Elements
described in

this document

interact from
PSAP Incident
initiation to closure.
The interfaces identified in this section are those

necessary to facilitate this interaction.

The requirements in this document apply to any features that are used to operate in a NG9
-
1
-
1
environment.

This document is not intended to define the requirements for transitioning from a legacy
PSAP into an oper
ational
NG9
-
1
-
1

PSAP.


Editors notes:

Ops Requirements.


The technical requirements are supposed to include provisions that would be
necessary to implement operational requirements that are being created by the NENA Operations
Committee and published in a
document.


The Operations document was not published before the
completion of the first version of this document.


The elements of this TRD needed to support the
operational requirements will not be completed until the Operations Committee document is publ
ished.

i3 Design.


The PSAP functional elements described in this TRD interface with other functional elements
and the ESInet. These elements have not yet been completely defined at the completion of the first
version o this document.


These requirements w
ill not be completed in the TRD until the i3 design is
completed and published.

2

Introduction

2.1

Operational Impacts Summary

NG9
-
1
-
1

encompasses a complete redesign of the entire 9
-
1
-
1 system

within a PSAP
, affecting all
elements, protocols, processes and pro
cedures. It will have far reaching impacts on all participants in the
9
-
1
-
1 system. The requirements in this
document

reflect the long
-
term view
of

the networks that connect
the
caller

to PSAP
s and

PSAPs to
alternate destinations
, including

responders
,

will evolve to be IP
-
based. Location of the caller (or a reference to it) will be conveyed with the
emergency call

so that
location is available as soon as the
request
is answered.
The PSAP must

support both civic and geodetic
forms of location
; which imp
lies a GIS system
.

This has impacts on system management, system
integrity, training and a host of methods and procedures.


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
8

of
68


2.2

Security Impacts Summary

As the PSAP
s

evolve from the existing E9
-
1
-
1 processes and procedures into an IP
-
based network a
multitude
of security topics arise. While security is beyond the scope of this TRD, further requirements
can b
e obtained via

the
NENA
Security for Next
-
Generation 9
-
1
-
1

standard

[
6
]
.

2.3

Document Terminology

NOTE to document editor:
The follow
ing

statem
ent will be included in every TR
D.

The terms "shall", "must" and "required" are
to be
used throughout this document to indicate required
parameters and to differentiate from those parameters that are recommendations. Recommendations are
identified by the words "desirable" or "preferably".

2.4

Reason for Issue/Reissue

This is the first
version of this Technical Requirements Document.


Version

Approval
Date

Reason For Changes

0.1

5/21
/09

Review Document for May 27
-
28 Face to Face.

0.2

5/27/09

Review from May 27 F2F

0.3

5/28/09

Review from May 28 F2F

0.4

6/4/09

Minor editorial fixes

0.5

6/25/09

Edits from 6/25 call

0.6

7/16/09

New text in section 3.2.1.

0.7

8/24/09

Added Data Object and
PSAP Incident Creation

0.8

09/17/09


0.9

9/2
4
/09

Added all contributed text. Text in tracked changes is that which
has been submitted and
distributed by email, but not formally
reviewed in conference calls.

0.10

9/28/09

Review toward baseline

0.11

9/29/09

Added TTY section

0.12

12/18/09

Updated contributors, added BC
F, IPV4/6
, Installation

and
Quality
and Reliability sections

0.13

1/29/10

Add
Mobile Data Computer System

FE

0.14

3/19/10

Updated
Mobile Data Computer System
, ESRP/ECRF, BCF and
Admin PBX

0.15

7/1/10

Update figure, time server, MIS, ECRF/ESRP


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
9

of
68


0.16

7/23/10

Update EIDD section (3.2.1)

0.17

9/17/10

Modify section 3.2.2
and 3.1.2

0.18

12/20/10

Add Incident Data Exchange

in section 3.5.8

0.19

2/24/11

Update
3.3.1

NG9
-
1
-
1 PSAP Network

0.20

2/24/11

Updated Figure 3
-
1

0.21

3/14/11

Updated sections 3.1, 3.1.1, 3.1.2

0.22

4/4/11

Add i3 requirements to Call Handling,
Dispatch and Incident
Creation FEs

0.23

4/15/11

Added requirements to sections 3.4.1,
3.2.3 and 3.5.4

0.24

6/23/11

Added requirements in 3.1.2 Gen FE Req, 3.2.3 Management
Console,
3.4.1 Emergency Call Handling
, 3.5.1 Incident Creation,


0.25

10/14/11

Edits to MGMT Console, Call Handling, Scope, Bridging, Floor
MGMT, Media and Callback

0.2
6

10/28/11

Edits to General Display in section 3

0.27

1/26/12

Update

Dispatch
and BCF
FE
s

0.28

4/25/12

Update Call Handling FE

0.29

9/14/12

Update
Management
Console

FE

Update System Alarms

Update Radio Interface FE

Update Incident Record Handling FE

Update Figure 1

2.5

Recom
m
endation for
Additional

Development
W
ork

This document is intended to be a reference document to guide CPE vendors in the development of
equipment and/or interfaces that can be utilized within an
NG9
-
1
-
1

PSAP.

Additional specifications may
be derived from the requirements in this document.

2.6

Date C
ompliance

NOTE to document editor:
The follow
ing

statem
ent will be included in every TR
D.

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.


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
10

of
68


2.7

Anticipated Timeline

The evolution to NG9
-
1
-
1 is a major change to the 9
-
1
-
1 system and adoption of this standard will take
several years. Experience with major change to 9
-
1
-
1 (i.e., Phase II wireless) suggests that unless
consensus amon
g government agencies at the local, state and federal levels, as well as carriers, vendors
and other service providers is reached, implementation for the majority of PSAPs could take a decade.
The adoption of these requirements will be coincident with the
evolution of the ESInet since there is an
inherit dependency upon the network being available to support the functionality specified in this
document.

2.8

Costs Factors

This is an all
-
new 9
-
1
-
1 system; the cost
of all components
will change. Since the scope
of NG9
-
1
-
1
introduces new functional
ity

and interfaces there will be costs associated with introducing these.
At the
time of the writing of this document it is difficult to predict the costs of the system and more work will
be needed by vendors and service

providers to determine the impact of the changes on their products and
operations.

2.9

Future Path Plan Criteria for Technical Evolution

NOTE to document editor:
The follow
ing

statem
ent will be included in every TR
D.

In present and future applications of
all technologies used for 9
-
1
-
1 call and data delivery, it is a
requirement to maintain the same level or improve on the reliability and service characteristics inherent
in present 9
-
1
-
1 system design.

New methods or solutions for current and future servic
e needs and options should meet the criteria
below.


This inherently requires knowledge of current 9
-
1
-
1 system design factors and concepts, in order
to evaluate new proposed methods or solutions against the Path Plan criteria.

Criteria to meet the Definit
ion/Requirement:

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 resul
ts in fewest components to achieve needs
(simplicity, maintainable)

4.


Maximum probabilities for call and data delivery with least cost approach

5.


Documented procedures, practices, and processes to ensure adequate implementation and
ongoing maintenance for 9
-
1
-
1 systems

This basic technical policy is a guideline to focus technical development work on maintaining
fundamental characteristics of E9
-
1
-
1 service by anyone providing equipment, software, or services.

2.10

Cost Recovery Considerations

Not applicable.


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
11

of
68


2.11

Additional Impacts (non cost related)

[
This section is to contain verbiage intended
to provide a summary of potential system or application
impacts regarding the subject of this NENA document. Generally one of the following four paragraphs
will suffice as “starting text” for this section.
]


NOTE to document editor:
Replace the “Additional Impacts” section’s wording with wording
appropriate to

your particular document’s content by choosing
one

of these four, or provide appropriate
wording if none of these four apply. Pick
one

of these four, and insert the words “9
-
1
-
1 technical” or
“9
-
1
-
1 Center operations” as applicable in place of the “XXX”:

a.

The information or requirements contained in this NENA document are not expected to have
XXX impacts, based on the analysis of the authoring group.


b.

The information or requirements contained in this NENA document are expected to have XXX
impacts, based on

the analysis of the authoring group. At the date of publication of this
document, development had not started. The primary impacts are expected to include:




(
Lists

impacts as bullets, in a referenced appendix, if lengthy
.
)


c.

The information or re
quirements contained in this NENA document are known to have XXX
impacts, based on the analysis of the authoring group, and development has been started. The
primary impacts include:


(
List

impacts as bullets, with the status of development, and in what g
roup
.
)


d.

Certain of the information or requirements contained in this NENA document are known to have
XXX impacts, and others are not expected to have XXX impacts. At the date of publication of
this document, some development work had begun.


(List impacts
as bullets, with the status of development, and in what group
.
)


Work Group

TEXT here…



2.12

Intellectual Property Rights Policy

NOTE to document editor:
The follow
ing

statem
ent will be included in every TR
D.

NENA

takes no position regarding the validity or scope of any Intellectual Property Rights or other
rights that might be claimed to pertain to the implementation or use of the technology described in this

NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
12

of
68


document or the extent to which any license under s
uch rights might or might not be available; nor does
it represent that it has made any independent effort to identify any such rights.

NENA invites any interested party to bring to its attention any copyrights, patents or patent applications,
or other prop
rietary rights that may cover technology that may be required to implement this standard.

Please address the information to:

National Emergency Number Association

4350 N Fairfax Dr, Suite 750

Arlington, VA 22203
-
1695

800
-
332
-
3911

or:
techdoccomments@nena.org


2.13

Acronyms/Abbreviations/Definitions

NOTE to document editor:
The follow
ing

statem
ent will be included in every TR
D.

Some acronyms/abbreviations used in this document have not yet been

included in the master glossary.
After initial approval of this document, they will be included. See NENA 00
-
001
-

NENA Master
Glossary of 9
-
1
-
1 Terminology located on the NENA web site for a complete listing of terms used in
NENA documents.

NOTE to docum
ent editor:
Fill in the following

WORD “table”
structure to display
Acronyms/Abbreviations/Definitions for this document
, add table rows as needed
.
E
nsure that any
Acronyms/Abbreviations/Definitions used in this document are consistent with the Master
Glo
ssary.

**
Required entry of New or Update. Any change made to an existing Master Glossary
Acronym/Abbreviation, constitutes an Update.


The following Acronyms
/Abbreviations

are used in this document:

Acronym

Description

** N)ew

(U)pdate

[
ALI
]

[
Automatic
Location Identification
]


[
U
]

[
ANI
]

[
Automatic Number Identification
]


[
U
]

[
ATIS
]

[
Alliance for Telecommunications Industry Solutions
]

[
N
]

[Acronym]

[De
scription

of term]

[N/U]







ACD

Automatic Call Distribution


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
13

of
68


The following Acronyms
/Abbreviations

are used in this document:

ALI

Automatic Location
Identification

BCF

Border Control Function

CAD

Computer Aided Dispatch

CPE

Customer Premises Equipment

ECRF

Emergency C
all

Routing Function

EISI

Emergency Information Services Interface

ELT

English Language Translation

ESInet

Emergency Services IP
network

ESMI

Emergency Services Messaging Interface

ESRP

Emergency Services Routing Proxy

GIS

Geographical Information System

LVF

Location Validation Function

IP

Internet Protocol

LoST

Location to Service Translation

MIS

Management Information
System

NENA

National Emergency Numbering Association

NTP

Network Time Protocol

PIDF
-
LO

Presence Information Data Format


ioca瑩潮⁏扪ect

mp䅐

m畢汩c⁓a晥ty⁁湳 e物r朠g潩湴

pBC

pe獳s潮⁂潲摥爠䍯湴牯汬er

p䑏

p瑡湤t牤猠re癥汯灭e湴n佲ga湩na瑩潮

piA

pe牶楣e ieve氠l
g牥e浥湴

pfm

pe獳s潮of湩n楡瑩潮⁐牯瑯r潬

呃qLfm

呲a湳nc瑩潮⁃潮瑲潬⁐牯瑯r潬of湴n牮r琠t牯瑯r潬

呒q

呥c桮楣h氠le煵楲e浥湴猠䑯a畭敮u

塍i

e塴u湳楢ne⁍ 牫異rian杵g来


NOTE to document editor:
L
ist any “document specific” new terms/definitions
in the following

WORD “table” structure
,

add table rows as needed.

These would be any new terms or definitions that

NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
14

of
68


are introduced as a result of the new or revised document, that do not already exist in t
he NENA Master
Glossary of 9
-
1
-
1 Terminology. Be sure to include NEW Definitions in the verbiage of this document.

These new terms & definitions will remain in this section as long as the document is in a “
DRAFT

state. Once approved, the terms &
definitions will be transferred to the NENA Master Glossary of 9
-
1
-
1 Terminology, while the Acronyms will remain in this section.


**
Required entry of New or Update. Any change made to an existing Master Glossary Term or
Definition constitutes an Update
.







The following Terms and Definitions are used in this document:

Term

Definition

**
N)ew

(U)pdate

Incident

From i3 definition “An Incident is a real world event, like a car crash, a
heart attack, or a fire in a building.”

J



䅮⁥癯汵v楯湡iy
獴sge⁤e晩湥搠dy 久乁⁷ ere⁥浥m来湣y ca汬猠sre
routed based upon the caller’s location and calls are delivered with that
汯捡瑩潮o


乇k
J
N
J
ㄠNp䅐

This term is used to denote a PSAP capable of receiving VoIP calls and
accessing data services as defined in
NENA’s i3 specification.


mp䅐⁉nc楤敮琠
䵡湡ge浥湴

mp䅐⁉nc楤敮琠䵡湡来me湴

楳⁴桡琠灯牴t潮o⁴桥⁩湣楤敮琠汩晥⁣ycle⁴桡琠
楳⁰牯ie獳敤⁢y⁡渠楮摩癩摵d氠乇l
J
N
J
ㄠNp䅐⸠

k

mp䅐⁉nc楤敮琠
oec潲o

周楳⁩猠瑨攠sec潲搠瑨o琠t猠畳u搠瑯⁴牡c欠瑯⁴桥⁩湣楤e湴⁴桲潵
g栠瑨攠偓䅐A
fnc楤敮琠䵡湡来浥湴mfe⁣yc汥⸠周ere y潴⁢e

mp䅐Afnc楤敮琠
oec潲搠o潲oeac栠
e浥m来ncy ca汬
.

䵡y⁢ 牥fe牲e搠d漠o猠s⁃䅄

⡯E
䑩獰a瑣栩

牥c潲搮

k

mp䅐A
oe煵q獴s
oec潲o

周楳⁩猠s⁲ c潲搠o映fcce灴a湣e映a渠
e浥rgency⁣all
Ⱐ楮捬畤楮I
a汬
楮景i浡瑩潮⁰牯癩摥⁷楴栠 桥
e浥mgency⁣a汬

a湤n
s異灬敭u湴慬n
楮景i浡瑩潮扴a楮敤⁦牯洠m桥⁣a汬er

楦⁰ie獥湴⸠fnc汵摥猠畮楱略⁲ c潲搠
楤敮瑩晩i爮

k

“five
J
nines”
牥汩a扩b楴y

〰㨰㔺ㄶN湵瑥猠潦⁤潷湴業e⁰ 爠yea爩

k

pe牶楣e⁒e煵q獴

䄠卥A癩捥⁒e煵e獴ay

be⁡ny⁲ 煵e獴⁦潲 e浥mge湣y a獳s獴慮se.

k



NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
15

of
68


3

Technical
Description


This section defines a reference model for the
NG9
-
1
-
1

PSAP and requirements associated with them.
The elements defined are functional and may or may not represent specific physical equip
ment. The
functional elements may reside with equipment at the PSAP or may be hosted as a service.

3.1

Architecture

An IP
-
based inter
-
network, the ESInet,
is the foundation upon which an NG9
-
1
-
1 PSAP is implemented.
The Functional Elements (FEs) described herein are interconnected, and communicate, via this
ESInet
.
The NG9
-
1
-
1 PSAP architecture
consists

of
these FEs, their interfaces, and the
ESInet

t
o which

they are
connected. This

architecture
must

support multimedia, enabling communication with callers via voice,
video, and text
-
based methods, as well as non
-
human
-
initiated communication with devices. The
architecture allows
for the FEs to be collocated, a
nd also
for the concept of the "virtual PSAP"
,

i.e.
a
PSAP where personnel and the
FEs
do not have to be
collocated
.

3.1.1

Assumptions

This document assumes an i3
-
compliant PSAP and ESInet. This document does not cover the
transitional states involved in moving
to an i3 PSAP. The NENA NG9
-
1
-
1 Transition Planning
Committee (NGTCP) has produced a Transition Plan

[
11
]

describing transition options and procedures.

3.1.2

Functional
Elements

This document uses the concept of Functional Elements (FEs) to describe the functionality present in an
NG9
-
1
-
1 PSAP. A Functional Element does not correspond to a specific product or system. In fact, a
product may include more than one FE. Also a
n FE may be offered by multiple products at the same
PSAP.


Also an FE does not correspond to a specific type of position at the PSAP; e.g.
Telecommunicator, Dispatcher, Supervisor.

The purpose of an FE is to define a set of functions and the external in
terfaces to those functions that can
be implemented independently. The current structure is logical and understandable and will allow the
functionality to be described and assigned requirements.
This document describes the NG9
-
1
-
1 PSAP
Functional Elements,

their interfaces, and their requirements. Many of the FEs described in this
document use the
Emergency Incident Data Document (EIDD), a proposed XML document standard, to

exchange emergency incident related data.

The assignment of technical requirements

to an FE through this document sets the framework to allow
an FE to function as a part of an NG9
-
1
-
1 PSAP. The requirements were chosen to avoid unnecessary
constraints. Every effort was made to allow vendors the freedom of innovation in designing their
products to be competitive in NG9
-
1
-
1 and to give PSAP management the flexibility to configure their
PSAP as they choose.

Many of these requirements address interface protocols and data formats for FEs. Conforming to these
requirements is essential for NG9
-
1
-
1 to operate in a plug and play fashion. A product offering one or
more FEs must meet the interface requirements for interfacing to FEs

not contained in the product
specified for that FE.
Functional Elements interact to allow efficient processing of em
ergency calls.


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
16

of
68


A Functional Element does not correspond to a specific product. In fact, a product may include more
than one FE. Also an FE may be offered by multiple products at the same PSAP. Also an FE does not
correspond to a specific type of position
at the PSAP; e.g. Telecommunicator, Dispatcher, Supervisor.
Multiple FEs will be present at the same position and an FE may be present at multiple positions.

Figure 1
shows the network reference model used in this document. Some of the functional elements
r
eside totally within a managed ESInet (e.g. the Emergency Services Routing Proxy). Other functional
elements shown can be implemented in a variety of ways including as a service within an ESInet, within
the PSAP premises, etc.


Figure
1

Functional Elements


General Functional Element Requirements

The following nomenclature is used in specifying requirements.

TOPIC XXXX
-
YYYY

Where


TOPIC denotes a functional area (e.g. GENERAL)

XXXX represents the top level (parent) requirement

YYYY represents the secondary level requirement. Child elements clarify

or expand

a

parent
requirement (e.g. XXXX
-
0100, XXXX
-
0101, etc.)
.


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
17

of
68


GEN 0100
-
0100
A Product offering a Functional Element as described in this document, shall support
the interfaces requ
ired for that FE,

when interfacing with FEs offered by other vendors.

GEN 0200
-
0100
PSAP Functional Elements shall synchronize their internal clocks to the Time Server
Functional Element described in section
3.7.1
. PSAP Functional Elements must maintain an accuracy of
±.25 seconds relative to the Time Server FE.

GEN 0300
-
0100
If
an FE provides a GIS server interface, the FE must support the
Spatial

Information
Function server interface as described in the
Spatial

Information Function section of NENA08
-
003.

GEN 0400
-
0100
If
an FE provides a GIS client interface, the FE must support the Spatial Information
Function client interface as described in the

Spatial

Information Function section of NENA08
-
003.

GEN 0500
-
0100 If an FE provides a GIS replica, the FE must support both the
Spatial

Information
Function server and client interfaces as described in the SIF section of NENA08
-
003.

GEN 0600
-
0100 If a PSA
P FE provides the MSAG conversion service, the FE must use the server
-
side
interface as described in the

MSAG Conversion Service section of the Spatial Information Function
section of NENA08
-
003.

GEN 0700
-
0100 If a PSAP FE uses an ESInet based MSAG Convers
ion Service it must implement the
client
-
side interface as described in the

MSAG Conversion Service section of the Spatial Information
Function section of NENA08
-
003.

GEN 0800
-
0100 Any FE that implements a Policy Store as described in the Policy section of

NENA08
-
003 must implement the server side of the policy storage function as described in the Policy section of
NENA08
-
003.

GEN 0900
-
0100 Any FE that uses a policy store outside the PSAP

must implement the client side of the
policy retrieval functions as
described in NENA08
-
003.

GEN 1000
-
0100 Any FE that needs to dereference Additional Data URIs shall provide an Additional
Data dereference interface as described in the
Data Associated with call/caller/location/PSAP

section of
NENA 08
-
003.

GEN 1100
-
0100 An
y FE may implement the Discrepancy Reporting client functionality to provide a
convenient method for users of that FE to file a Discrepancy Report.

GEN 1200
-
0100 An FE may send a discrepancy report automatically if it has sufficient data available to
compl
ete the report.

GEN 1300
-
0100
All FEs must support emitting SNMP traps for alarm notification. The required MIBs
and traps will be specified in future work.

GEN 1400
-
0100
An FE must be able to notify another FEs of a change to its state.

GEN 1500
-
0100 An F
E must respond to a request for its current state.

GEN 1600
-
0100
A log event must be posted by all
FE
s for any transaction that would result in a new
EIDD being issued.



NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
18

of
68


Requirements for FEs sending or receiving EIDDs

SEND
-
EIDD 0100
-
0100
All EIDDs must

be logged as specified in the Logging Service section of
NENA 08
-
00

3

[
4
]
.

SEND
-
EIDD 0200
-
0100
Whenever an EIDD is sent, a notice of the exchange must be logged.

SEND
-
EIDD 0300
-
0100
Whenever an EIDD is received, a notice of the exchange must be logged.

SEND
-
EIDD 0400
-
0100
When a relevant change in Incident information occurs, an EIDD must be sent
to subscribed FEs, within the constraints of any installed filter on
the subscription.
What constitutes a
relevant change will be determined in future work.


SEND
-
EIDD 0500
-
0100
When an agency receives a call, the first FE handling the associated Incident
must
send

an EIDD
to the logger
. This requirement also applies when a
n Incident is communicated
through some means other than a call.

SEND
-
EIDD 0600
-
0100
All EIDDs must conform to the EIDD schema.

SEND
-
EIDD 0700
-
0100
The transmission of an EIDD must comply with the data rights management
policy of the agency that created th
e data.

SEND
-
EIDD 0800
-
0100
The Incident Data Exchange FE may present a discoverable query point to
other agencies and FEs through which incident information may be obtained regarding incidents handled
by FEs registered with the Incident Data Exchange FE.

SEND
-
EIDD 0900
-
0100
The FE may respond to a request for incident information by replying with an
EIDD containing data extracted from its own internal databases. The Incident Data Exchange FE may
reply with an EIDD obtained by querying appropriate FEs.

SEND
-
EIDD 1000
-
0100
The Incident Data Exchange FE must be able to determine the proper FE and
agency to send an incident EIDD to, based on the service type and location of that incident. An EIDD is
only sent to an Agency who subscribes to an Incident or re
ceives a command from another Agency that
informs them of an Incident of which they had no prior knowledge.

SEND
-
EIDD 1100
-
0100
An FE must respond to all requests for an EIDD. The FE must implement a
Subscribe

Notify messaging

mechanism for sending EIDD data.

SEND
-
EIDD 1200
-
0100
The FE must implement a Request
-
Response messaging mechanism for
sending EIDD data.

SEND
-
EIDD 1300
-
0100

Incidents can be merged as specified in NENA 08
-
003, and conflicts in merges
can occur. The FE must be able to handle this conflict situation in a way that minimizes any negative
impact.





This document uses the word “call” to refer to a session established by signaling wit
h two way
real
-
time media and involves a human making a request for help. We sometimes use “voice
call”, “video call” or “text call” when specific media is of primary importance.


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
19

of
68



3.2

General Topics

3.2.1

Emergency Incident Data
Document

An Emergency I
ncident Data Document (EIDD) is an XML document that is used in a structured data
exchange between a source and one or more destinations regarding the current state of an incident. The
current state is defined as the information known by an FE at the time

that an EIDD is sent. The
transmitted EIDD must contain the mandatory data elements defined in the EIDD XML schema and one
or more optional elements as dictated by the status of the incident and nature of the exchange. All of
the data elements containe
d in the exchange must conform to the EIDD XML schema. An EIDD can be
exchanged via two methods:

1.

A notification EIDD is sent in response to specific triggering events. When an Agency or FE needs to
communicate the current state of an incident to one or m
ore subscribing FEs or agencies, e.g. Call
arrival triggers EIDD to be sent from the Call Handling FE to the PSAP Incident Creation FE.

2.

A solicited EIDD is sent in response to a request to provide the state of a specific incident.

EIDDs are always sent to

specific destinations. The destination of an EIDD is a Functional Element of a
specific agency. Access to specific data is dependent upon the role/s of the intended recipient. Possible
destinations for an EIDD include:

1.

Other local functional elements such

as dispatch, logging, RMS etc.

2.

Functional Elements in external agencies such as other PSAPs, FBI, hospitals, etc.

The Incident data Exchange (IDE)

FE may be used to facilitate the transmission of the EIDD. See the
Incident data Exchange (IDE) FE section f
or further Information.

The Emergency Incident Data Document format specifications will be documented
in a

revision
of
NENA

Standard For NG9
-
1
-
1 Ad
ditional Data NENA 71
-
001 ver.1
. See section Additional Data
Associated with a PSAP.

3.2.2

General Display

All F
Es
that present displays to a user
must meet the
applicable
display requirements

in
NENA
54
-
750
[
9
]
.


All FEs that render
or generate
any media type must support the media formats required for that type.
Required media formats are described in the Media section of NENA 08
-
003
[
4
]
.

All F
E
s that present displays to a user must meet the applicable requirements in
NENA
54
-
750
[
9
]
.


3.2.3

Management Console

The Management Console
-
supports general management functions for the PSAP, including reporting
PSAP Security Posture and PSAP Element State through the Call Handling FE. It also sends and
receives Discrepancy Reports on behalf of the PSAP, and may impleme
nt a Policy Editor.


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
20

of
68


Management 0100
-
0100
An interface between

the Management Console FE and the
Call Handling FE is
required to allow the Management Console FE to report the PSAP Element State through the Call
Handling FE
.

Management 02
00
-
0100
An

interface between

the Management Console FE and the
Call Handling FE is
required to allow the Call Handling FE to report requests for diversion and the Management Console to
approve or deny such requests.
Reference the Call Diversion sub
-
section of the PS
AP Interface section
in NENA 08
-
003.

Management
0300
-
0100

An interface between the Management Console FE and all PSAP FEs is
required so those FEs can report their Element State to the Management
Console
.

Management 0
4
00
-
0100.
The Management Console FE
must implement an interface to the Call
Handling FE to allow it to report the PSAP Security Posture through the Call Handling FE.

Management 0
5
00
-
0100
An interface between

the Management Console FE and the
Call Handling FE is
required to allow the Manag
ement Console FE to control whether diverted calls are accepted by the Call
Handling FE,
as described in the Dequeue Registration Event Package section of NENA 08
-
003.

The
Call Handling FE is responsible for informing the Terminating ESRP of this status.

M
anagement 0
6
00
-
0100 When an Incident is closed, the Management Console FE may be used to
initiate logging of a ClearIncident LogEvent to the Logging Service as specified in the Logging Service
section of NENA 08
-
003.

Management 0
7
00
-
0100
If
Discrepancy Rep
orts
are sent by the Management Console, they
must be sent
using the format specified in
the Discrepancy Reporting section of
NENA 08
-
003.

Management
08
00
-
0100 The Management Console must host a Discrepancy Report Web Service for the
agency as described

in the Discrepancy Reporting section of NENA 08
-
003.

Management
0900
-
0100

The Management Console must receive discrepancy reports from sources
outside and inside of the Agency.

Management 1
0
00
-
0100 All discrepancy reports

received or sent by the Manageme
nt Console

must be
logged in the
appropriate

Logging
Service
.

Management 1
1
00
-
0100 All discovered discrepancies must be reported to the upstream FE responsible
for receiving the
D
iscrepancy
R
eport.

Management 1
2
00
-
0100
The Management Console shall s
upport sending and receiving Status Updates
and Status Update Requests as
described in the Discrepancy Reporting section of NENA 08
-
003


3.3

Network Layer
Functional Elements

3.3.1

NG9
-
1
-
1 PSAP

Network

The NG9
-
1
-
1 PSAP Network may be described as an overlay network consisting of ESInets, local LANs
and additional IP functionality supporting a PSAP or Jurisdiction. NG9
-
1
-
1 PSAP Networks are private,
managed, routed IP networks. An NG9
-
1
-
1 PSAP Network se
rves a PSAP which is not necessarily

NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
21

of
68


restricted to single physical premises. That is, Telecommunicators may be located remotely from the
main premises and connected to the NG9
-
1
-
1 PSAP Network via IP.

While it has been common to have multiple physical ne
tworks for separate functions, this practice is
strongly discouraged. Best practices in network engineering dictate that a single physical network
infrastructure is used and any necessary separation for security or functional purposes is accomplished
logic
ally in network devices. Where possible, the same configuration is encouraged in PSAP
networking. Best practices in network management dictate centralized network management.

During the transition from legacy to NG networking in existing PSAPs, it is likel
y that multiple, limited
-
purpose networks will already exist. One NG transition goal should be to consolidate the legacy
networks into a single network and accommodate any required separation logically. Vendors and system
architects should not design produ
cts or systems that rely on single purpose networks unless no other
alternatives exist. The architecture of the NG9
-
1
-
1 PSAP Network must allow access to all systems that
conform to the specifications stated in the network requirements section below.

Netw
ork management is responsible for setting network policy for all parts of the NG9
-
1
-
1 PSAP
Network, including acceptable use
policies and

information security. Because the NG9
-
1
-
1 PSAP
Network connects with many other networks and systems, much thought wil
l need to go into network
policy development (e.g. if connectivity to the FBI’s Law Enforcement Online (LEO) databases and
systems or to the National Crime Information Center (NCIC
) is

provided, then compliance with the
FBI’s Criminal Justice Information S
ystem (CJIS) security policy will have to be implemented). NG9
-
1
-
1 PSAP Networks that communicate with other local, state and national networks may have to
accommodate various and, possibly, conflicting network policies. APCO/NENA cannot arbitrate
between
various network policies; the best that APCO/NENA can do is offer guidance in best practices
for the development of network policy.

Requirements


The NG9
-
1
-
1 PSAP Network design shall adhere to the following specifications:

N
ENA 08
-
003
:

Detailed Function
al and Interface Standards for the NENA i3 Solution

[
4
]

NENA 75
-
001:
NENA Security for Next
-
Generation 9
-
1
-
1 (NG
-
SEC)

[
6
]

NENA
xx
-
xxx
:
NENA

Emergency Services IP Network Design

for NG9
-
1
-
1



[
10
]

3.3.2

Emergency C
all

Routing Function and
Emergency Services Routing Proxy
Functional
Elements

The ECRF and ESRP functional elements are documented in detail in
NENA 08
-
003

[
3
]

and are covered
here to describe how they function in the context of the PSAP.

The RFEA FE of the PSAP uses the ESRP when

making a call to another agency or transferring or
conferencing an existing call outside of the PSAP. The RFEA FE determines the intended destination
of the call or transfer request, possibly using the ECRF, and forwards the call to its normal ESRP. The
ESRP will route the call, possibly through one or more intermediate ESRPs to the terminating ESRP of

NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
22

of
68


the answering User Agent. The ESRP and ECRF are also used for routing calls from a PSAP FE to a
Service. The needed Service may be located outside of the
PSAP or within the PSAP. For example a
dispatch Service Request may be routed from the PSAP Incident Creation FE to a Dispatch FE.

The ECRF and ESRP function together on the ESInet for the purpose of routing calls and other data to
the correct PSAP. Th
e ECRF provides the normal destination for a call or other data based on the type
of service needed and the location. The ESRP queries the ECRF to obtain the destination URI. The
ESRP may route to that destination URI or may route to a different URI. Thi
s decision is based on
business rules and the state of the destination. A Policy Routing Function (PRF) is used by the ESRP to
apply the business rules. A call is routed through one or more ESRPs to its final destination. See the
ESRP and ECRF Sections i
n the
NENA 08
-
003

document for more information.

The ECRF processes queries containing a location in PIDF
-
LO format and a Service URN; it returns the
URI of the normal service agency for this location. Routes obtained by the ESRP querying the ECRF
norma
lly lead to an ESRP serving the intended destination. The ESRP uses the information obtained
from its own queries to the ECRF, using a different service URN to obtain the correct URI for the next
hop of the route. The ECRF will return either the URI of t
he Service agency itself or the URI of an
intermediate ESRP. For this reason the ECRF cannot be used directly by a PSAP FE. The ESRP will
not always route two identical requests to the same URI. This can be caused by a change in the state of a
destination

agency. For this reason, PSAP FEs using the ESRP to route a service request must use a SIP
session.


The PSAP Incident Record Creation FE, the Dispatch FE or other PSAP Services must use the ESRP to
route a location based Service Request if an internal ro
uting mechanism is not available between the two
FEs. The destination location may be inside or outside of the local jurisdiction of the PSAP. Routing the
request through an ESRP for any location based services allows the ESInet to take advantage of the PR
F
feature. For this reason the use of an internalized ESRP FE should be considered by vendors as an
internal routing mechanism. An Internal mechanism must duplicate the results that an ESRP/ECRF FE
would return.

ESRP Interfaces

Input From

Applicable Sta
ndards

Comment

A

-

RFEA

NENA
08
-
002

[
3
]

NENA 08
-
003

[
4
]


Request to route call

C
-

Dispatch FE

SIP reference

08
-
002


[
3
] and
NENA 08
-
003
[
4
]

Request to route dispatch request.

This may be any sort of Service Request

R
-

PSAP Incident

Creation

SIP reference

[
3
] and

NENA 08
-
003
[
4
]

Reques
t to route dispatch request.

This may be any sort of Service Request

Notification
System FE

NENA 08
-
002

[
3
]
,

NENA 08
-
003

[
4
]

A location based Service Request


NENA 08
-
002

[
3
]
,

NENA 08
-
003
[
4
]

There may be other PSAP FEs that will
need to use the ESRP for location based

NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
23

of
68


se
rvice requests

Output to

Applicable Standards

Comment

D
-

ESRP

NENA 08
-
002
002
[
3
]
,

NENA 08
-
003
[
4
]

Call Routing

E


Logging
Service

NENA 08
-
002
002
[
3
]
,

NENA 08
-
003
[
4
]

Log All routing requests and errors

Destination
Service which may
be an PSAP FE

NENA 08
-
002
002
[
3
]
,

NENA 08
-
003
[
4
]


Queries to

Applicable Standards

Comment

Q
-

ECRF

LoST (IETF RFC 5222)

[
7
]

Used to
determine next hop in routing
process.

Direct query, properly formatted LoST
find service request containing service
URN and location
.

Returns URI of normal service


Queries from

Applicable Standards

Comment








ECRF Interfaces

Input From

Applicable Standards

Comment

Output to

Applicable Standards

Comment

Any PSAP FE
using
A
gency
Polygons

OGC Layer Replication Protocol


Standard Pending
-

NENA 08
-
003
[
4
]

Synchronization of Agency Polygons.

Queries to

Applicable Standards

Comment

Queries from

Applicable Standards

Comment

D
-
ESRP

LoST (IETF RFC 5222)

[
7
]

To determine next hop in routing process.

Direct query, properly formatted LoST
find service request containing service
URN and location


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
24

of
68



Returns URI of service






NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
25

of
68


Requirements

-

note that these requirements are requirements
for

any PSAP FE that uses the
ESRP
/ECRF
.

ESRP 0100
-
0100 All FEs providing or requesting location based services shall support ESRP based
message/request routing both for input and output.

ESRP 0200
-
0100 All location based routing requests between PSAP FEs shall use the ESRP to route.
This does not apply to communication between FEs that have an internal routing mechanism
established.

ESRP 0300
-
0100 A PSAP FE that uses Agency Polygon GIS d
ata shall keep this data synchronized with
the ECRF data.

ESRP 0400
-
0100 The OGC Layer Replication Protocol

NENA 08
-
003

[
4
]

shall be used to synchronize
Agency
GIS data with the ECRF.


3.3.3

Location Validation Function (LVF)

General specification
s

for the LVF are defined in
NENA 08
-
003

[
3
]. Specific requirements for NG9
-
1
-
1
P
SAP are for future study.

3.3.4

Border Control Function (BCF)

A BCF sits between external networks and the ESInet and between the ESInet and
PSAP

networks.
The
BCF provides a secure entry point into the PSAP from outside networks such as the ESInet. The BCF
incorporates firewall and admission control functions, and may include other security functions,
including functions designed to recognize and block external attacks on PSAP infrastructure.

The ESInet
will
provide BCF functionality between the ESInet and t
he outside origination networks
including the Internet.

It is highly recommended that a BCF exist between the ESInet and the PSAP.

A BCF must exist between the PSAP NG9
-
1
-
1 Network and any other external networks to which it is
connected
.

This does not i
mply that a virtual PSAP necessarily requires a BCF between any part of that
virtual PSAP and the network that connects them together.

Refer to the i3 documents [
3
] and [
4
] for a detailed description of BCF functionality and interfaces.

3.3.5

PSAP Administrative
PBX

The PSAP Administrative PBX
includes telecommunication equipment that handles processing of
administrative, non
-
emergency telephone communications.


This PBX can also be integrated with other
systems within the organization in order to provide additional administrative services such
as email,
instant messaging, voicemail and other non
-
emergency related processing.


The administrative PBX
could utilize some of the same core physical elements (including call processing and networking) as the
communication equipment supporting NG9
-
1
-
1 as

long as the processing of administrative tasks does
not affect the performance of the emergency services.

Requirements


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
26

of
6
8


PBX 0100
-
0100 If the PSAP Administrative PBX is involved in handling NG9
-
1
-
1 calls, then
processing of administrative tasks shall not af
fect the performance of the emergency services.

3.3.6

Radio Interface

While an Agency’s radio system and its over
-
the
-
air interface is out of scope for this document, s
ome
FEs will need to interface to the radio system. A Logging Service must be able to recor
d radio traffic. A
Mobile Data Computer System FE
must
be able

to send and receive
media

and data. Since these FEs
may be located on a remote network such as the ESInet, a Radio over IP (RoIP) interface is needed. One
example of such an

RoIP interface is the Project 25 (P25)
ISSI
(Inter rf Sub System Interface). Because
ISSI only supports P25 radio systems, gateway protocols would be required to interface to the many
types of legacy radio systems that will continue to be used in Publi
c Safety. One example of such a
gateway protocol is the U.S. Department of Homeland Security’s
Bridging Systems Interface
. Future
support for LTE (
Long Term Evolution
) will also be required.

On “conventional” radio systems, a radio is tuned to a freq
uency, transmits on that frequency; and all
other radios monitoring that frequency will hear the transmission. On “trunked” radio systems, a radio
selects a “talkgroup”, transmits on that talkgroup, and all other radios monitoring that talkgroup will
hear
the transmission. The talkgroup can appear on different frequencies


the radio system sends
commands to all radios, and radios in that talkgroup jump to that frequency at the beginning of the
transmission. The frequency, talkgroup, and ID of the radio tha
t is transmitting is important metadata
that other interested FEs will need to receive along with the audio, video or data payload being
transmitted.

When addressing a specific unit or responder, the technology used by the radio system determines the
form
of address. This address could be a radio channel, a talkgroup, an IP address, a telephone number
or any other form of address for a specific technology.

Requirements

RADIO

0100
-
0100 The Radio Interface shall support transmitting audio, video and text (bo
th two
-
way
interactive and streaming), and associated metadata to and from a radio system and other FEs.

RADIO 0
2
00
-
0100 The Radio Interface shall support a mechanism for other FEs to register for specific
addresses that it wishes to receive traffic from.

RADIO
0300
-
0100

The Radio Interface shall support a mechanism for other FEs to specify an address
that it wishes to send traffic to.

RADIO 0400
-
0100 The Radio Interface shall support authentication and authorization of client FEs that
wish to use supported

radio system features.

RADIO 0500
-
0100 The Radio Interface shall support privacy and message integrity of all traffic.

RADIO 0600
-
0100 The Radio Interface shall support anything else that comes to the NG9
-
1
-
1 PSAP
working group’s collective mind.


RAD
IO
0700
-
0100

The Radio Interface shall support bridging of emergency and other calls to the radio

.


NENA Recommended Generic Standards for
NG9
-
1
-
1

PSAP Equipment

NENA 04
-
xxx
Version 0.29

09/14
/1
2





Page
27

of
68


3.4


3.5

Communications
Functional
Elements

These functional elements are involved in communications and call handling.

3.5.1

Emergency C
all

Handling


The
Emergency
Call Handling

functional element

is concerned with the details of the management of
emergency calls
. It handles all communication from the caller.
It includes the interfaces, devices and
applications utilized by the Telecommunicators to handle the call.

It receives and may display
the
content of
multimedia calls such as text and video to the Telecommunicator.

Requirements

Telecommunicator

Registration

REGISTRATION 0100
-
0100
Telecommunicators

authenticate

using single sign on authentication as
defined
in
NENA 08
-
003

[
4
]

Receiving
E
mergency
C
all
s

CALL 01
00
-
0100 The Call Handling FE
shall

deploy the SIP call interface as defined in the SIP Call
sub
-
section of the

Interfaces section in NENA 08
-
003

[
4
]
.


CALL 0200
-
0100 Location shall be received with Calls with location spec
ified in the Geolocation
Header.

CALL 0200
-
0
101

If a call is received with location by reference, the
Call Handling

FE
shall

use
the reference to retrieve (dereference) the location via HELD or SIP per NENA 08
-
003.

CALL 0200
-
0
102

The NG9
-
1
-
1 PSAP shall be able to receive and display eit
her geo or civic
information received in the PIDF
-
LO.

CALL 0200
-
0
103

The location reference, if received, may also be used for subsequent location
updates.

CALL 03
00
-
0100
Call Handling FE shall implement at least one incoming call queue

[as defined in
NENA

08
-
003
[
4
]
.

CALL 03
00
-
0
101

The Call Handling FE shall support the queueState notification function for its
queues so it can notify as described in the QueueState E
vent Package section of NENA 08
-
003
[
4
].

CALL
03
00
-
0102

The Call Handling FE may support the QueueState Subscribe function for
downstream queues in

other elements as described in the QueueState Event Package section of
NENA 08
-
003 [
4
].

CALL 04
00
-
0100 the Call Handling FE shall support the dequ
eue registration function as described in
the DequeueRegistration Event Package section of NENA 08
-
003 [
4
]
.

CALL 05
00
-
0100 In order to support call diversion for other PSAPs in overload conditions, the Call
Handling FE shall support the dequeue function with standby flag set to true as described in the