1. ENP Study Group Next Generation 9-1-1
Brought to you by: The Florida NENA Education committee
Steve O’Conor, ENP

2. 9-1-1 Going to “Next Gen”… Next Gen migration: What is it?
How do I get there?
Where do I start?
RFAI or i3?
Interim or end state?
9-1-1
- Smart phones have revolutionized the communications industry. * Unfortunately, communications hasn’t kept pace with the changes in technology, …and is * behind the 8-ball trying to catch up.
* To help us understand the migration path to Next Generation, we’ll
* Describe Next Generation 9-1-1, including the difference between traditional and “Next Gen” Call Routing
* Review the steps needed to move from a legacy system to a Next Gen system
* Identify the options to be considered when determining a starting point for the transition.
* Explain the differences between an i3 and RFAI implementation
* Describe the potential impact of interim versus end-state implementations

3. What is Next Generation 9-1-1?
An IP-based replacement for E9-1-1 features and functions
Operating on managed, multipurpose IP network
Based on Open Standards for true interoperability
Seamless data sharing
GIS is core database for routing and
delivering calls
Providing multimedia and advanced
data capabilities for and 
other emergency entities
NG9-1-1 is an IP-based system comprised of managed IP-based networks (ESInets), functional elements (applications), and databases that replicate traditional E9-1-1 features and functions and provide additional capabilities.
It is an underlying IP-based, managed, multipurpose internetwork, based on open standards, which enables NG9-1-1 as well as radio interoperability over IP and permits seamless data sharing among all emergency response entities. This system architecture significantly improves call routing and information-sharing between PSAPs and other public safety agencies.
Next Generation introduces a fundamental, strategic change to the method of call routing and delivery. As we all know, the legacy infrastructure is based on a tabular database - the Master Street Address Guide – and analog, circuit-switched hardware – the telephone company’s Selective Router. In the Next Generation, Geographic Information Systems – developed locally – form the basis for caller location determination and for call routing. With GIS at its core, Next Generation becomes a location-driven system, using the local GIS data to verify location and to route calls.
NG9-1-1 is designed to provide access to emergency services from all connected communications sources, and provide multimedia data capabilities for Call Centers and other emergency service organizations.

4. What is Next Generation 9-1-1?
The hottest “NextGen” topic right now is handling text messages. In an agreement with APCO and NENA, the major wireless carriers agreed to deliver text to beginning in This agreement only covers native SMS (or Short Message Service), not Multimedia Messaging Service (MMS) which include photo & videos. Work is underway developing standards to support Multimedia Emergency Services (MMES), which will allow for simultaneous use of pictures, videos, text, and voice between an emergency caller and a PSAP. Ad hoc solutions to provide text, images and video to the PSAP have already been developed, so PSAPs have the opportunity to be early adopters.
As we consider moving toward NextGen, what is necessary on the PSAP side is the ability to process and display multimedia messages in a graphical user interface. *
In an emergency people expect to communicate with the public safety community in the same way that they communicate with others in their daily lives. They expect to be able to text or share video and images with just as they commonly do with their smartphones. The end state of Next Generation provides the support for these devices.

5. What is Next Generation 9-1-1?
Better service to everyone
Supports a wide range of devices and services
Competition – non-proprietary solutions that are available “off-the-shelf”
Improved services in disaster situation
So from the PSAP perspective, Next Gen is the ability to communicate with callers in the same way that they communicate in their daily lives. Our “migration to Next Gen” is simply catching up with the technology the rest of the world has been using for years.
One of the most significant impacts of the migration process is the availability of non-proprietary, commercial off the shelf applications. If a pizza delivery service can find someone who called for a large pepperoni, why can’t 9-1-1? One big difference is that fact that commercial ventures have been using integrated mapping solutions with their call-handling solutions for a long time. In the next generation, NENA’s i3 solution takes this one step further, using GIS to assist in call routing.
Geospatial call routing, along with other elements of the i3 architecture, can vastly improve our ability to provide mutual aid in the event of large scale disasters, an improve our ability to obtain and share information on a daily basis.

6. What is Next Generation 9-1-1?
Location Information arrives with the call
Geographic or Civic Address
Calls are geospatially routed to the PSAP.
Additional Data available with calls, such as Vehicle Telematics
As we have said, one fundamental change between the legacy and next generation systems is the way we receive the caller’s location. In the legacy system, we retrieve the location using the ALI Controller from the Service Provider’s database. Next Generation Systems provide the caller’s location with the voice call. Since the caller’s location is delivered with the call, GIS becomes a core function of Next Generation 9-1-1, and calls are geospatially routed to the destination PSAP based on the location of the caller.
Equally as important, since we have moved from an analog to an IP based system, we can now send the PSAP and emergency responders additional information and data including enhanced multi-media messages, telematics, text, video, images, and additional data associated with the caller, the location of the call, and the type of call being placed… providing, of course, that the user interface is capable of handling the additional data.

7. Additional Data Data is associated with a location
Data can be acquired from multiple locations and provided to the Emergency Responders, when they need it, to assist with their needs
Floor Plans
Fire Control Panels
Ingress, Egress, Stairwells
Fire Code Inspections
Past historical data (law and fire)
Building Inspections
Hazardous Materials
Sensor Locations and Data
Historical Data
Surveillance Camera Locations
Campus / Facilities Layouts
Data is associated with a location
In addition to obtaining location information with the call, we can now query other data bases for additional information about the call, the caller, and call location, including pre-planned fire response, hazardous material locations, floor plans, special needs individuals, and the like.
Other applications and services can work seamlessly with our Next Generation system, such as automotive telematics service providers like OnStar and Agero. Individual data subscription services such as “Smart ” can provide additional information about the caller when they call
To understand how all this is possible, we should take a look at the difference between our legacy system and the next generation of

8. Legacy vs. Next Generation
To help understand how Next Generation will streamline the delivery of calls, let’s take a look at the way calls are delivered in the legacy system, and how they will be delivered in the Next Generation.

9. Legacy Enhanced 9-1-1 Call
Calling
Telephone Number
(ANI)
Voice CO
Tandem
Selective Routing
(With MSAG)
Voice
& Data
Voice
& Data
ANI
ANI
PSAP
(Public Safety
Answering Point)
DBMS
* In the legacy system, when a call is placed
* the local telephone company Central Office (CO)
* routes the call to the network.
* The call is routed to a local Trunk between the local CO (also known as the End Office) and the Tandem, or Selective Router. * The Tandem then routes the Call
* to the appropriate Public Safety Answering Point (PSAP) via a PSAP E9-1-1 Trunk.
* The Automatic Number Identification (ANI) is sent over the Trunk to the PSAP.
* The PSAP sends the ANI (9-1-1 caller’s telephone number)
* to the Automatic Location Identification (ALI) computer (the Service Provider’s Data Base Management System) via a data circuit to obtain the caller’s address.
* The telecommunicator receives this information, and can then transfer the caller to the appropriate emergency service agency for dispatch if necessary.
Data
ALI
(Civic Location Info)

10. Next Generation 9-1-1 Call
Voice
Text
Video
Image
Data
Calling
Telephone Number
(ANI)
GIS-LIS
ECRF
Location Comes with the Call
Tandem
Selective Routing
(With MSAG) CO
Voice
Voice
& Data
Call coming in as SIP
VoIP
Cellular
PSTN
9-1-1 Call
Enterprise
Voice
Text
Video
Image
Data
Voice
& Data
ANI
ANI
PSAP
(Public Safety
Answering Point)
DBMS
NG9-1-1 (i3)
PSAP
Data
However, in NG9-1-1, when an emergency call is placed, the origination network sends the call, with location, into the Emergency Services IP Network, or ESInet.
We are no longer limited to the “plain old telephone” * as the sole source of calls; * the call may come from a variety of networks, both traditional and non-traditional. *
Instead of “voice only” or voice with limited data, * there may be a variety of data that constitute what we mean by a "call“: *voice, text, video, images and other data.
* The location of the calling device comes with the call, and the call comes in as a Session Initiation Protocol (SIP) *
Since location comes in with the call, the legacy ALI database and Selective Routers are decommissioned. *
* The caller is located, either by civic address or by geographic coordinates, depending on the device making the call, using the local GIS database.
* The Location Information Server then provides the IP address of the appropriate PSAP, * and the call is delivered using the Emergency Call Routing Function.
* The connection is made to the device placing the call,
* And additional data and multi-media is sent to the Emergency Services IP Network (ESInet), which can provide it to the PSAP or other members of the emergency response enterprise.
* If a call is transferred, all related data can be provided with the voice call to the appropriate agency.
ALI
(Civic Location Info)

11. NENA i3 Model
NENA Detailed Functional and Interface Standards for the NENA i3 Solution (TSD), NENA v1, June 14, 2011
“the i3 standard is not, by itself, the same thing as an NG9-1-1 System. The i3 standard describes only the network, components, and interfaces required to establish Next Generation service.”
Steve O’Conor, ENP
NENA President
For the past decade, members of NENA’s technical and operations committees been preparing for the transition to Next Generation 9-1-1, and have developed numerous information documents, requirements and standards, culminating with the issuance of the Detailed Functional and Interface Standards for the NENA i3 Solution, commonly known as the i3 Standard, in June of 2011.
The importance of this document was noted by the fact that this marked the first time in NENA’s history that a NENA Standard was publicly posted with a letter of transmittal from the NENA President.
In his comments, he said that this standard “intentionally describes an end state NG9-1-1 architecture, rather than an immediate “build to” specification for a complete NG9-1-1 system”. Some people may have stopped reading there, assuming that this specification was incomplete. What was said was that this specification did not describe a complete Next Generation system, because, as he went on,
* “the i3 standard is not, by itself, the same thing as an NG9-1-1 System. The i3 standard describes only the network, components, and interfaces required to establish Next Generation service.” In order to deploy a fully-operational NG9-1-1 system, additional specifications are necessary that are out-of-scope of the i3 standard. As the leading standards development organization for the sector, NENA has already developed many of these specifications among the 70 or so technical documents already produced.
“…intentionally describes an end state NG9-1-1 architecture, rather than an immediate ‘build to’ specification for a complete NG9-1-1 system.”
Steve O’Conor, ENP
NENA President

12. NENA i3 Model
NENA Detailed Functional and Interface Standards for the NENA i3 Solution, NENA-STA (Originally )
Differentiate ESInet and Next Generation Core Services (NGCS)
Clarified Emergency Incident Data Document (EIDD)
Replaced Call Information Database (CIDB) with Add’l Data Repository (ADR)
Standardized the Spatial Interface (SI) to provide for the provisioning of GIS data to those Core Services using it.
Provided other technical changes to the NGCS
Over the next five years, NENA’s i3 Architecture Working Group worked on version 2 of the architecture, as cities, counties and states began looking at early implementation of IP networks to replace the legacy analog infrastructure. During that time, NENA also changed their document numbering scheme, and version 2 was given a new number. In September of 2016 version 2 was issued, with several substantive changes and enhancements to the architecture.
The term “ESInet” – Emergency Services IP Network – was incorrectly being used to refer to the network and all of the functional elements providing Next Generation service. The ESInet is simply the physical network - the transport path for the voice calls and media. Version 2 introduced a new term, Next Generation Core Services (NGCS) to describe the base set of services need to process a call on that network. These services include the ESRP, ECRF, LVF, BCF, Bridge, Policy Store, Logging Services.
Version 2 also clarified the use of the term EIDD, or Emergency Incident Data Document, as the mechanism by which data generated by a PSAP while handling an emergency call is captured and passed to other agencies that are involved with the incident (essentially replacing the term “Additional Data Associated with a PSAP”). If the PSAP receives a call via a transfer from another agency, the location of the caller will be found in the EIDD included in the transfer and not in a Geolocation header.
Version 1 differentiated between Additional Data about a call, caller or location. The repository for additional call data was the Call Information Database (CIDB). In this version, there is only “Additional Data” which is provided as a series of blocks regardless of the source of the data. To support providing Additional Data, NENA –STA defines a new term, Additional Data Repository (ADR), which is a data storage facility for Additional Data. The ADR replaces the concept of Call Information Database (CIDB).
It is recognized that Geospatial data stored in a GIS must be provisioned into ECRFs, LVFs, the Map Database and other functions. Accordingly, STA refines the concept of a Spatial Interface Function (SIF) into a Spatial Interface (SI), which provides a standardized interface from the GIS to the i3 functional elements that need GIS data.
This document also provided technical changes to the Border Control Function, Legacy Gateway, Agency Locator and Logging Service sections.

13. NENA i3: the System Architecture
ESRP
LIS
LoST
ECRF
LVF
PRF
Emergency Service IP Network (ESInet) with
Next Generation Core Services (NGCS)
NENA
NG9-1-1
PSAP
Origination Network
VoIP
Cellular
PSTN
Enterprise
Next Generation 9-1-1
9-1-1 Call w/Location
BCF IP
BCF
The NENA i3 Next Generation System architecture supports end-to-end IP connectivity. Non-IP networks are accommodated via gateways. The i3 standard describes the Emergency Services IP network (or ESInet) and the Core Services that process calls, such as the Location Information Server (LIS) and Location Validation Function (LVF), the Emergency Service Routing Proxy (ESRP) and Policy Routing Function (PRF) and the Emergency Call Routing Function and Location to Service Translation (LoST) protocol. There are additional pieces and parts which we will describe later, but this is a high-level overview.
All calls presented to the ESInet from the originating network service providers must use SIP signaling (Session Initiation Protocol) to deliver the call and include the location with the call. NENA has adopted the Internet Engineering Task Force (IETF) definition of location, which is the Presence Information Data Format – Location Object, or PIDF-LO, and we use a Border Control Function to regulate entry into the ESInet, and provide Call Detail Recording.
The Next Generation System Architecture also describes i3 PSAP, which can receive multimedia via IP-based SIP signaling.
* Together, these elements comprise Next Generation
NENA i3 Specification

14. i3
Core Services
(call flow example)

15. Protocol Interworking Function (PIF)
NENA i3: Call Flow
Origination Network
ESInet
Conversion to SIP
Protocol Interworking Function (PIF)
VoIP
Cellular
PSTN
Enterprise
Legacy Network Gateway (LNG)
9-1-1 Call w/Location
Border Control Function (BCF)
Now that we have described the System Architecture, let’s take a look at the flow of a typical call as it makes its way from the Originating Network to the destination PSAP.
As we said earlier, * Origination Network Providers send location with the call.
*The civic location is pre-validated by the access network against the local GIS using the LVF prior to an emergency call being placed. This is analogous to MSAG validation, and ensures that the location delivered with the call is synchronized with the local GIS records.
*Typically, the call will be delivered to the Legacy Network Gateway, and converted to SIP, or Session Initiation Protocol, using the Protocol Interworking Function (PIF).
*Sitting between external networks and the ESInet is the BCF, which contains the Border Firewall and Session Border Controller. These elements provide security for the ESInet and Call Detail Recording.
*Legitimate traffic is admitted to the ESInet.
Pre-validated using LVF
NENA i3 Specification

16. Emergency Service IP Network
NENA i3: Call Flow
Emergency Service IP Network
(ESInet)
NENA
NG9-1-1
PSAP
urn:service:sos
LVF
ECRF
LoST
LIS
9-1-1 Call w/Location
So the call, with location information, * enters the ESInet through the BCF.
*The emergency call has a Route header based on the location of the call, and a Service URN (or Uniform Resource Name) of urn:service:sos.
*After passing through the BCF, the first element inside the ESInet is the *Emergency Service Routing Proxy (ESRP). The ESRP receives the call, with the Service URN and location information, and *passes this information *via the LoST interface to an *Emergency Call Routing Function (ECRF), which determines the next hop in routing the call.
The ECRF maps the call to a *“PSAP URI” and then returns the *URI to the ESRP. Using the returned URI and other information (time-of-day, PSAP state, etc.), the ESRP then applies policy from a Policy-based Routing Function (PRF)*. The PRF contains the Policy Routing Rules to determine the appropriate routing URI.
In NG9-1-1, *the LIS supplies location (by value or reference) to the endpoint. While the Location Information Server (LIS) and the *Location Validation Function (LVF) are not – strictly speaking – within the ESInet, if a location is provided by reference, rather than by value, the LIS provides the capability to “dereference” the URI and provides the value.
*Once the routing URI is identified, the call is sent to the destination PSAP*, passing though another BCF*. If the PSAP is i3-compliant*, the PSAP CPE processes and displays the information received to the call taker.
In the event an ESInet is provisioned before the Originating Networks or PSAPs are i3 capable, NENA has suggested a transition model.
ESRP
PRF

17. NENA i3 Transition Model
ESRP
LIS
LoST
ECRF
LVF
PRF
Emergency Services IP Network
(ESInet)
Origination Network
Legacy PSAP
CAMA Trunks
CAMA, TDM, SS7
RS232
VoIP
Cellular
PSTN
Enterprise
LNG
LPG
In this case, the Legacy Network has been replaced by the Emergency Services IP Network (ESInet) with all of the functional elements previously described. On either end is the legacy environment. To provide connectivity to both the legacy networks and the legacy PSAPs, we need only to install gateways – the Legacy Network Gateway* and the Legacy PSAP Gateway* to convert the data to and from SIP messaging until such time as they become i3 capable.
No modification of origination networks required.
No modification of Legacy PSAP equipment required.

18. Migration to Next Gen

19. Migration Considerations
i3 end-state:
Selective Routers decommissioned
Existing ALI systems replaced
Calls arrive at ESInet via SIP
9-1-1 calls routed by the Emergency Service Routing Proxy (ESRP) using data supplied by the Emergency Call Routing Function (ECRF)
What steps are required to get there?
Begin with the end in mind…
In the end-state, the Selective Routers are decommissioned and the existing ALI systems are replaced. All calls arrive at the ESI net using Session Initiation Protocol and calls are routed by the Emergency Service Routing Proxy using data supplied by the Emergency Call Routing Function (ECRF). So how do we get there?

20. Migration Considerations
Call routing (ECRF) requires the local jurisdiction GIS data.
MSAG must be reconciled with local GIS
NENA , Synchronizing Geographic Information System Databases with MSAG & ALI Information Document
One of the first considerations is the aspect of transitioning data from the legacy environment to the NG9-1-1 environment. Assuming that a Authority is likely starting with an environment consisting of traditional components such as an ALI system, Selective Router(s), a Database Management System (DBMS), tabular MSAG, and a legacy network, the Authority should develop a set of GIS data to a level that approximates the contents of their MSAG.
In preparation for migration, each Authority should perform some preliminary reconciliation between their GIS data and their MSAG. The Authority should also perform further reconciliation work between their GIS and Postal data. If an Authority that provides GIS data for use has not performed this reconciliation work it should take up the task at the earliest opportunity as such reconciliation is viewed as a first step in NG9-1-1 data transition.

21. Migration Considerations
Operation:
Multimedia functionality – training needs
Management:
Expanded Responsibilities – multidisciplinary; LMR, Policy Rules, shared resources
Interoperability:
Interconnected networks – information sharing
Funding & Governance:
New funding models & governance structures