The Technical Backbone of NG911: Exploring Key Functional Entities

In the previous blog (Next-Generation 911 in Canada: Revolutionizing Emergency Response), we explored how NG 911 addresses the challenges the existing 911 system faces. This time we will dive into the technical aspects of NG 911.

Let’s start with an overview of the key components that make up the NG911 system. The backbone of the NG911 system is the ESInet (Emergency Services IP Network) the transport network that delivers emergency calls to PSAPs. It supports Next Generation Core Services (NGCS) which provides for the accurate locating, routing, and delivery of emergency calls to public safety answering points (PSAPs). Databases containing Geospatial Information Systems (GIS) data and policy rules are crucial components that enable accurate location and call routing within the NG911 system.

Now, let’s go into details of each NG 911 Functional entities.

Functional entities

The NG911 system comprises several critical functional entities, each playing a unique role in ensuring the seamless operation of emergency services. Below are some of the key entities and their responsibilities.

BCF (Border Control Function)

The Border Control Function (BCF) serves as a gateway between external networks and the ESInet/NGCS. It works for network edge control and SIP message handling. These include:

• Border Firewall

• Session Border Control

• Call Suspicion/Bad Actor functions

To provide these functionalities, BCF supports security-related techniques: Prevention, Detection, and Reaction. Additionally, it may work as SIP B2BUA or Media anchoring.

ESRP (Emergency Services Routing Proxy)

• The Emergency Service Routing Proxy (ESRP) is the routing function for emergency calls. Several ESRP are used in an emergency call.

The “Originating ESRP” is the initial routing element in the ESInet. It accepts calls from the BCF at the edge of the ESInet and contains one or more “Intermediate ESRPs” at different hierarchical levels. The Originating ESRP may be a state-level function, whereas a county agency may run an intermediate ESRP. The “Terminating ESRP” is often located at the NGCS edge, immediately before the PSAP BCF.

Policy Routing Function

Policy Routing determines the next hop where a call or event is forwarded by an ESRP (Emergency Services Routing Proxy). The PRF (Policy Routing Function) evaluates one or more sets of policy rules. These rules can be based on the queue where the call arrives or the result of an ECRF (Emergency Call Routing Function) query, which provides the caller’s location. Additionally, one policy can trigger another policy. The PRF in an ESRP is responsible for handling calls directed to a specific queue URI.

ECRF (Emergency Call Routing Function)

• Emergency Call Routing Function (ECRF) provides routing information to the various querying entities. Emergency calls are routed to the appropriate PSAP based on the caller location. Also, PSAPs may use the same routing functionality to determine how to forward emergency calls to the correct responder.

LVF (Location Validation Function)

• When location information is provided in civic form, it must be verified as sufficient for routing and dispatch before a call is placed. This verification ensures the location is “valid” for the call. The Location Validation Function (LVF) work for this purpose. The LVF is only used for civic location validation. There is no validation process for geodetic locations
• The ECRF/LVF system supports a mechanism where location information (either civic address or geo-coordinates) and a Service URN are used as inputs for a mapping function. This function returns a URI to route an emergency call to the appropriate PSAP based on the caller’s location (for an ECRF) and provides validation information (for an LVF). In an ECRF, depending on the identity and credentials of the requesting entity, the response may identify either the PSAP or an ESRP that acts on behalf of the PSAP to ensure final routing towards the PSAP.

PSAP

Public Safety Answering Points (PSAPs) are dedicated call centers that operate 24/7 to answer 911 emergency calls, dispatch emergency assistance, and transmit calls to other specialized organizations. PSAPs can send units in the field, such as police officers, firemen, and ambulance/paramedic services, in accordance with specified operational procedures. PSAPs serve a diverse demographic and may be found in major cities as well as small communities.

Some interfaces a PSAP provides towards the ESInet are following.

• SIP Call interface
• Media (support all media, voice, video, and text.)
• LoST (Location to Service Translation) interface to achieve “selective transfer” operations.
• LIS Interfaces
• Bridge Interface
• ElementState
• ServiceState
• Test Call

LIS (Location Information Server)

A Location Information Server can provide location in the form of a PIDF-LO (location by value) or a location URI. The LIS additionally offers a “dereference” function for the location URIs it provides: given the URI, the LIS returns the location value as a PIDF-LO.

In NG9–1–1, the LIS provides location (by value or reference) to the endpoint or a proxy acting on behalf of the endpoint. The generated PIDF-LO or location URI must be included in the initial SIP message in the Geolocation header field.

LNG/LPG

A legacy Network Gateway serves as a signaling and media interface point between callers on legacy networks and the i3 architecture. The legacy Network Gateway sits logically between the originating network and the ESInet, enabling i3 PSAPs to receive emergency calls from legacy originating networks. Calls from legacy networks require signaling interworking to convert incoming Multi-Frequency (MF) or Signaling System Number 7 (SS7) signaling to the IP-based signaling supported by the ESInet.

The Legacy Network Gateway is also in charge of routing emergency calls to the relevant ESRP on the ESInet.

The Legacy PSAP Gateway connects an ESInet and a legacy PSAP, providing signaling and media interaction. It contributes in the delivery of emergency calls that travel through an i3 ESInet to a legacy PSAP, as well as the transfer and alternate routing of emergency calls between legacy PSAPs and i3 PSAPs. The legacy PSAP Gateway has an IP (i.e., SIP) interface to the ESInet on one side and a classic MF or Enhanced MF interface (similar to the interface between a traditional Selective Router (SR) and a historical PSAP). The legacy PSAP Gateway also has an ALI interface that can receive ALI queries from the legacy PSAP.

Basic Call Flow

Last but not least, let’s see a very high-level Basic Call flow

1. The device acquires location before making a call
2. Location Query to Location Information Server(LIS)
3. Pre-validated Location response (civic or geo-coordinate format)
4. Device (or network) queries ECRF for routing
5. ECRF provides next-hop routing — ESRP 1
6. Call placed
7. Call with the location information sent to ESRP 1
8. LIS is re-queried from ESRP1 for any updates to the location
9. LIS respond with location information
10. ESRP1 queries ECRF for the next hop
11. ECRF provides next-hop routing — ESRP 2
12. Policy Rules are evaluated at each hop
13. Call with location information sent to ESRP 2
14. LIS is re-queried from ESRP2 to update the location
15. LIS respond with location information
16. ESRP2 queries ECRF for the next hop
17. ECRF provides next-hop routing — PSAP
18. Policy Rules are evaluated at each hop
19. Call with location sent to PSAP
20. PSAP queries LIS to obtain any updated location information
21. LIS respond with location information
22. Call Connected to PSAP
23. Media is established between PSAP and the caller Media can be any combination of Voice, text, data, video, etc…
24. LIS is queried for any updated location information

Overall, we’ve walked through the overview of NG 911 technical aspects, and fundamentals of functional entities and learned how the 911 call is established on NG 911 systems. In the next blog, we will explore the latest and future technologies shaping public safety telecommunications.

For those interested in exploring NG911 standards and guidelines in greater detail, consider reviewing the NENA i3 Standard. This document provides a comprehensive overview of the protocols and requirements for NG911 systems, offering valuable insights into their design and implementation.