By Steve O’Conor

During the past decade, much work on standards has been done to prepare our industry to move from circuit-switched, CAMA-based, analog voice technology to the next generation: packet-switched, SIP-based, IP-voice technology. But “NextGen” is more than just moving from analog to IP; simply replacing PSAP equipment today with IP-enabled customer premise equipment (CPE) may not be a cost-effective solution. The end state of Next Generation 9-1-1 has been designed from scratch, borrowing tools used by the Internet Engineering Task Force (IETF), and using similar protocols.

Last June, NENA issued the document, Detailed Functional and Interface Specification for the NENA i3 Solution—Stage 3, describing the network, components and interfaces required for NG9-1-1 service. In issuing this document, commonly known as the i3 Standard, NENA was quick to point out that it only describes the end-state architecture, not a build-to specification for a complete NG9-1-1 system. Additional standards, requirements and information documents are needed for areas not covered by the i3 document, and many of these documents have already been developed.

In this month’s article, I’ll provide an overview of the i3 end-state architecture and describe how call delivery differs from what we know today.

The basic element of the i3 architecture is an Emergency Services IP network (ESInet), designed as an IP-based inter-network (network of networks) that can be shared by all public safety agencies involved in an emergency. No longer are PSAPs isolated from one another, or only connected to other PSAPs that share the same selective router. They can communicate with each other seamlessly, over an interconnected network, using a common communications protocol: Session Initiation Protocol (SIP).

SIP is a signaling protocol used to start, change and end telephone and multimedia communication sessions over IP networks. Because SIP signaling is used to send calls from the originating TSPs to the PSAP, all calls entering the ESInet must be converted to SIP. Traditional providers must employ a legacy network gateway (LNG) for conversion purposes. Similarly, until the PSAP is capable of receiving IP-based signaling and media that conform to the i3 Standard, a legacy PSAP gateway (LPG) must be used. The LPG also supports the transfer of emergency calls between i3 PSAPs and legacy PSAPs.

In addition to designing an all IP-based telephony system with a corresponding IP-based ESInet, the i3 architecture includes a significant change in how calls are routed to the PSAP. In the legacy 9-1-1 system, the master street address guide (MSAG) groups street segments into Emergency Service Zones (ESZ), and each zone is assigned a unique Emergency Services Number (ESN) identifying the primary PSAP for that zone. The selective router uses this information to route the call to the PSAP. When the call and its corresponding ANI are received, the ANI-ALI controller initiates a query to the automatic location information (ALI) database, which associates the caller’s telephone number with the location information and then provides the location to the PSAP.

In NG9-1-1, the tabular MSAG is replaced with a geographic information system (GIS), and GIS polygons describe the former ESZs. Local GIS map data are used to provision new functional elements: the location validation function (LVF) and emergency call routing function (ECRF). These functional elements replace the MSAG validation process and selective routing used in today’s system. An advantage of this process in NG9-1-1 is that as changes are made to the local GIS system, these changes can automatically propagate to the ECRF and LVF, and this immediately affects call routing.

When telephone service is initially provisioned or modified, the customer address is pre-validated against the local GIS (using the LVF) to ensure the address is valid, which also ensures that the call can be geospatially routed.

When a 9-1-1 call is placed, location information is included in the Geolocation header. This information can either be “by value,” which is actually the civic address (known in the IETF world as presence information document format—location object [PIDF-LO]), or “by reference,” which is a geographic point identified by latitude and longitude (described by the IETF as a location uniform resource identifier [URI]).

This location information, along with the requested service (described by the IETF as a service uniform resource name, i.e., urn:service:sos) is passed by the emergency services routing proxy (ESRP) to the ECRF using a location to service translation (LoST) protocol. The ECRF determines the appropriate PSAP to receive the call based on location, applies the policy routing rules (PRR) determined by the PSAP, and routes the call.

Next month, I’ll describe the impact of NG9-1-1 on PSAP operations.

Steve O’Conor is the immediate past president of NENA and a member of APCO’s Standards Development Committee. He is the director of government and industry relations for Synergem Emergency Services LLC.

This article originally appeared in October 2012 Public Safety Communications.