What is Next Generation 911 (NG911), and how is it different from E911?

Next Generation 911, written NG911 or NG9-1-1, is an Internet Protocol based emergency calling system that is replacing the circuit-switched network behind 911 in the United States. Federal rules define NG911 as an IP-based system built on commonly accepted standards that is secure and interoperable, and that lets emergency communications centers handle every type of 911 request rather than voice alone [1]. Enhanced 911, shortened to E911, is the system being replaced, so the two names describe different generations of infrastructure rather than two services a caller chooses between.

What E911 does

A legacy E911 call reaches an aggregation point, the selective router. The router compares the caller's location information against an internal routing table built from a Master Street Address Guide and an ANI/ALI database, identifies the public safety answering point whose service area covers that address, and sends the call down dedicated trunks to the central office serving that PSAP [2]. The call taker then queries the ALI database using the calling number to see the address and callback number [2]. Every step assumes a voice call and a telephone number tied to a fixed address.

What NG911 puts in its place

NG911 carries the same call as a SIP session into an Emergency Services IP Network, which the FCC defines as an IP-based network managed or operated by a 911 authority or its agents and vendors [1]. Inside that ESInet, a group of NG911 Core Services takes over the work the selective router, the MSAG, and the ANI/ALI database used to do. A Location Validation Function checks civic addresses against a Geographic Information System database, an Emergency Call Routing Function maps a validated location inside the boundaries of emergency response zones to identify the destination PSAP, and an Emergency Services Routing Proxy delivers the call according to a Policy Routing Function's rules [3].

How far along the change is

About 217 million calls reach 911 in the United States each year [2], and the network under them is being rebuilt jurisdiction by jurisdiction rather than on one cutover date. Forty-two states plus the District of Columbia, Guam, and Puerto Rico reported spending on NG911 programs in calendar year 2024, totaling roughly $535 million [3]. When the FCC adopted its transition rules in 2024, no fully enabled NG911 system was yet operating, though many jurisdictions had already deployed ESInets and other transitional pieces [2].

Routing in NG911 is geospatial rather than tabular. The Emergency Call Routing Function takes a validated caller location and determines the destination PSAP by mapping that location inside the boundaries of emergency response zones, after which an Emergency Services Routing Proxy delivers the call according to the policy rules a 911 authority has configured [3]. Legacy E911 does the same job with a lookup table inside the selective router, populated from MSAG and ANI/ALI data, so the decision is only as good as the address record attached to the telephone number [2].

The difference is most visible on wireless calls. Wireless 911 calls have historically been routed on the location of the cell tower handling the call, so a call placed near a county line can land at the wrong PSAP because the tower sits in a different jurisdiction, and the receiving center then has to transfer it [9]. The FCC treated part of that problem separately in 2024 by requiring wireless providers to use location-based routing on their IP networks [9]. NG911 applies the same logic to every call type by making mapped geography, rather than a stored table, the routing input.

For a business, the consequence is that address accuracy stops being a billing detail. Under the NENA i3 architecture, once transition is complete the selective routers and existing ALI systems are decommissioned and calls route through the ECRF over SIP [4], so an address that fails GIS validation has nothing to fall back on. Reconciling every site, floor, and suite record your provider holds against the authoritative address data for that jurisdiction is work best done before your carrier's Phase 2 deadline.

NG911 moves location into the call itself. Phase 2 of the FCC's transition framework requires an originating service provider to deliver 911 traffic in SIP with location embedded in the signaling using Presence Information Data Format Location Object, known as PIDF-LO, or its functional equivalent, and to run a Location Information Server for verifying customer location records [1]. That replaces the legacy pattern, where the PSAP pulls an address from an ALI database once the call has landed [2].

The underlying method is an IETF best current practice. Emergency calls are marked with a service URN, location travels between SIP entities in either civic or geodetic form using the extension defined in RFC 6442, and the call is routed on that location through the Location-to-Service Translation protocol [10]. Providers already move location this way in production, passing it through PIDF-LO headers for customers whose phones move around a network rather than sitting at one fixed jack [13][10].

E911 has its own location obligations, and they remain in force. Wireless providers still owe either dispatchable location or horizontal accuracy within 50 meters for a rising share of calls, plus vertical location within 3 meters of the handset for 80 percent of calls from z-axis capable devices [6]. Interconnected VoIP providers still owe automated dispatchable location for fixed service, and for nomadic service either a registered location the customer can update, alternative location information, or routing to a national emergency call center [7]. Multi-line telephone systems still owe direct 911 dialing and dispatchable location under Kari's Law and section 506 of RAY BAUM'S Act [8]. NG911 changes how those obligations are met, not whether they apply.

NG911 accepts text, photos, video, and data alongside voice. The FCC describes the end state as one in which the circuit-switched architecture of legacy 911 is entirely replaced by IP technologies providing all of the same functions plus new ones, including transmission of text, photos, videos, and data to PSAPs by people seeking help [2][3]. Legacy 911 networks were built narrowband and circuit switched, carrying voice and very limited data, which is why emergency text, images, video for American Sign Language users, and telematics feeds were all awkward to support [5].

The building block that makes the difference is the ESInet itself. NENA describes ESInets as engineered, managed, packet-switched networks intended to be multi-purpose, supporting public safety communications beyond 911 alone, and designed as a network of networks spanning local through national authorities [5]. Once emergency traffic sits on a general-purpose IP network, adding a media type becomes a software question instead of a new physical circuit.

Two caveats matter for planning. Capability in the network does not mean capability at the answering position, because a PSAP still needs call handling equipment and procedures that can act on a video stream. And text-to-911 already exists outside NG911 as a separately mandated capability with its own FCC readiness registry [2], so a jurisdiction advertising text-to-911 is not necessarily running NG911.

The failure modes change, so the rules changed with them. In July 2026 the FCC adopted a Second Report and Order, effective August 10, 2026, redefining which companies count as covered 911 service providers in an IP environment: operators of ESInets, NG911 Core Services providers, and providers of real-time location services, major IP transport, traffic aggregation, and the gateways converting between legacy and IP formats [3].

Legacy and IP networks deal with single points of failure by different strategies. A legacy 911 network fixes the circuits and switches a call will traverse at setup, so a fault anywhere along that path can drop the transmission, and the standard mitigation is at least two physically separated sets of circuits and switches [3]. IP-based NG911 architecture is geographically distributed and load balanced, with automatic reroutes to backup equipment when hardware, software, or a database fails, so the FCC's benchmarks focus on physical diversity, operational integrity, and network monitoring suited to IP systems [3].

Interoperability received a formal definition for the first time. The FCC defines it as the capability of NG911 systems, networks, and services to exchange 911 voice, text, data, and multimedia between jurisdictions, PSAPs, and service providers in real time without proprietary interfaces [3]. The Commission stopped short of a performance benchmark, instead requiring NGCS and ESInet providers to file a one-time report describing what they have done to enable interstate interoperability, and replacing annual reliability certifications with a one-time filing updated only on material change after an 18-month transition [3].

There is no single national NG911 deadline. The FCC's framework is request-driven, so the clock starts when a 911 authority sends an originating service provider a valid Phase 1 or Phase 2 request, and the authority may only send that request after certifying that it has placed into operation the infrastructure needed to receive 911 traffic in the requested IP format and pass it to its PSAPs [1].

Phase 1 obliges the provider to deliver all 911 traffic in the IP-based SIP format the authority asked for, to send it to the NG911 Delivery Points the authority designated, and to complete connectivity testing [1]. Phase 2 adds conformance with the commonly accepted NG911 standards the authority identifies, location embedded in the signaling as PIDF-LO or its functional equivalent, and a Location Information Server in operation for verifying customer location records [1].

The deadlines run from the request rather than from a calendar date. Non-rural wireline providers, nationwide CMRS providers, covered text providers, and interconnected VoIP providers get six months for each phase, while rural incumbent local exchange carriers, non-nationwide CMRS providers, and internet-based TRS providers get 12 months [1].

Cost responsibility is split in the rules themselves. Originating service providers pay to transmit traffic to the delivery point, to deliver it in the required SIP format including conversion through a Legacy Network Gateway, and to obtain and deliver location and routing information. They are not responsible for furnishing, maintaining, or upgrading delivery points, ESInets, core services networks, or PSAPs [1]. If you buy voice service, the useful question for your provider is which jurisdictions covering your sites have issued valid requests, and which phase the clock is running on.

Several common misreadings are worth clearing up first.

It is not a different number to dial

Callers still dial 911. NG911 changes the network behind the number, and NENA notes the concept is international in scope and designed to support the other emergency access codes used worldwide, because the underlying processes are the same whatever digits a caller presses [5].

It is not the same subject as wireless location accuracy

E911 indoor location rules and NG911 are separate tracks that often get merged. The 50 meter horizontal and 3 meter vertical standards apply to CMRS providers under the E911 rules whether or not a jurisdiction has built an ESInet [6]. NG911 changes how location is carried and used for routing, not how accurate a handset's position estimate is.

It is not a finished product in most places

Transitional NG911 networks blend legacy and IP components, so many live deployments still carry selective routers, ANI/ALI, and translation gateways inside the call path while ESInets and core services are being stood up [3]. NASNA scores state progress across three separate domains, covering the 911 network, originating service providers, and PSAPs, so a state can be well advanced in one domain while lagging in another [12].

What to watch

Compliance dates for several of the new reliability benchmarks were not set by the July 2026 order and will be announced in a later Federal Register document, so the effective date and the compliance date differ [3]. The further notice attached to that order asks whether multi-party interstate interoperability testing should be required, with comments due August 10, 2026 and replies due September 8, 2026 [3]. On the enterprise side, dispatchable location for a mobile workforce depends on tooling inside your own systems: Microsoft ties dynamic emergency calling in Teams to validated addresses carrying geo codes that are mapped to network identifiers, which works only while someone keeps that map current [11].