emergency calling · published

NG911 and i3 architecture transition

Verified 2026-09-24 · 60 sources · tier 1–4

Also known as NG911.

47 CFR 9.28 defines Next Generation 911 (NG911) as an IP-based system that ensures interoperability and security and enables emergency communications centers to receive, process and analyze all types of 911 requests for emergency assistance 18. The regulatory framework establishes requirements for originating service providers to transition 911 traffic to IP-based formats across designated delivery points connecting to Emergency Services Internet Protocol Networks (ESInets) 151643.

Transition architecture and definitions

Federal regulations establish core definitions governing the transition to NG911 under 47 CFR 9.28 141618151917:

911 Authority: 47 CFR 9.28 defines a 911 Authority as a State, territorial, regional, Tribal, or local governmental entity that operates or has administrative authority over all or any aspect of a communications network for the receipt of 911 traffic at NG911 Delivery Points and for the transmission of such traffic to PSAPs 14.
ESInet: 47 CFR 9.28 defines an Emergency Services Internet Protocol Network (ESInet) as an IP-based network managed or operated by a 911 Authority that is used for emergency communications, including NG911 services 16.
NG911 Delivery Point: 47 CFR 9.28 defines an NG911 Delivery Point as a geographic location, facility or demarcation point designated by a 911 Authority where originating service providers deliver 911 traffic in an IP-based format to an ESInet 15. A 911 Authority may designate NG911 Delivery Points only if each is located in the same State or territory as the PSAPs connected to the ESInet 21. An NG911 Delivery Point designation also requires that the 911 Authority or ESInet provider supplies facilities at the input to the Delivery Point to receive 911 traffic for the applicable phase 20.
Location Information Server (LIS): 47 CFR 9.28 defines a Location Information Server (LIS) as a functional element that provides locations of endpoints in geodetic or civic form and can be queried by endpoints or other entities 17.
Originating service providers: Under 47 CFR 9.28, originating service providers subject to the NG911 rules are wireline providers, CMRS providers (with a conditional exclusion for mobile-satellite service operators), covered text providers, interconnected VoIP providers and internet-based TRS providers 19.

From an industry standard perspective, NENA defines i3 as its NG9-1-1 system architecture, which standardizes the functional elements, software services, databases and interfaces used to process multimedia emergency calls 27. The i3 standard is published as NENA-STA-010, the NENA i3 Standard for Next Generation 9-1-1 28. NENA publishes an i3 Common OpenAPI schema on GitHub (NENA911/i3-Common) that lets i3 interfaces advertise supported versions, interface condition and a JWS signature, tied to NENA-STA-010.3 26.

Emergency calling over IP references several foundational IETF specifications:

RFC 4119: PIDF-LO, the location format the FCC requires in NG911 Phase 2 signaling, is defined in RFC 4119 (December 2005, Proposed Standard), updated by RFCs 5139, 5491 and 7459 47.
LoST (RFC 5222): LoST (RFC 5222, August 2008) is the IETF protocol that maps a service identifier and civic or geodetic location to a service contact URI, such as the right emergency answering point; RFCs 6848, 8917 and 9036 update it 34.
RFC 6881: RFC 6881 (BCP 181, March 2013), updated by RFCs 7840 and 7852, is the IETF best current practice for devices, networks and services supporting emergency calling over IP 51.

Phase 1 and Phase 2 requirements

Under 47 CFR 9.29, the transition proceeds through Phase 1 and Phase 2 requirements 4346:

Phase 1: Under NG911 Phase 1 (47 CFR 9.29), after a valid request an originating service provider must deliver all 911 traffic in the IP-based SIP format requested by the 911 Authority 43. Under NG911 Phase 1, the originating service provider must route its 911 traffic to the NG911 Delivery Points designated by the 911 Authority 42. NG911 Phase 1 compliance includes completing connectivity testing that confirms 911 traffic is received in the requested IP-based SIP format 41.
Phase 2: Under NG911 Phase 2 (47 CFR 9.29), originating service providers must deliver 911 traffic in IP-based SIP format with location information embedded in the call signaling using PIDF-LO 46. NG911 Phase 2 obligations include meeting all Phase 1 requirements in addition to the Phase 2 location and standards requirements 44. NG911 Phase 2 requires the originating service provider to install or acquire a Location Information Server (LIS) or its functional equivalent to support location verification 45.

Valid requests and mutual agreements

A Phase 1 valid request must certify that the 911 Authority has installed and placed into operation all infrastructure needed to receive 911 traffic in IP-based SIP format and transmit it to the PSAPs 58. A Phase 1 valid request must certify that the 911 Authority has commitments from its ESInet, NG911 Core Services and/or call handling equipment providers to complete connectivity testing within the compliance deadlines 59. A Phase 1 valid request must certify that the 911 Authority is authorized to submit the request and must identify the designated NG911 Delivery Point(s) 57. A Phase 2 valid request additionally requires certification that the 911 Authority's infrastructure complies with NG911 commonly accepted standards 60.

A valid request is completed by written notice to the originating service provider, either through the Commission's registry or by other written notification reasonably acceptable to the provider 55. 911 Authorities and originating service providers may by mutual consent set terms that differ from the requirements of 47 CFR 9.29 through 9.33 35. The originating service provider must notify the FCC within 30 days of executing, amending, modifying or terminating an NG911 mutual agreement, identifying each affected rule and how the agreement differs from it 36.

Cost boundaries

Originating service providers bear the cost of transmitting 911 traffic to the NG911 Delivery Points designated by the 911 Authority 6. Originating service provider cost responsibility includes delivering 911 traffic in the required IP-based SIP format, including the cost of IP conversion through a Legacy Network Gateway 5. Originating service providers are not responsible for the cost of furnishing, maintaining or upgrading NG911 Delivery Points, ESInets, NG911 Core Services networks or PSAPs 4.

Implementation deadlines and rulemaking timeline

The FCC's NG911 Report and Order, FCC 24-78, was adopted on July 18, 2024 and released on July 19, 2024 in PS Docket Nos. 21-479 and 18-64 39. The NG911 transition rules adopted in FCC 24-78 were published at 89 FR 78066 on September 24, 2024 with an effective date of November 25, 2024 38. OMB approved the NG911 information collection requirements on March 11, 2025 37. The FCC announced March 25, 2025 as the compliance date for 47 CFR 9.31(a)-(c) and 9.34(a)-(b), the valid-request and mutual-agreement information collections 3.

Implementation timeframes following a valid request are categorized by provider tier under 47 CFR 9.30 1213:

Provider group	47 CFR rule	Phase 1 & Phase 2 deadlines
Non-rural wireline providers, nationwide CMRS providers, covered text providers, interconnected VoIP providers	9.30(a) 12	6 months after valid request 910
Rural local exchange carriers (RLECs), non-nationwide CMRS providers, internet-based TRS providers	9.30(b) 13	12 months after valid request 810

As stated in the June 2026 FCC 26-39 order, 911 Authorities had issued more than 190 Phase 1 valid requests and 1 Phase 2 valid request, covering all or parts of 28 states and more than 2,200 PSAPs 50.

Reliability requirements and location-based routing

FCC 26-39, a Second Report and Order on NG911 reliability adopted June 25, 2026 and released June 26, 2026 in PS Docket Nos. 21-479 and 13-75, was published at 91 FR 42794 on July 10, 2026 and took effect August 10, 2026 49:

FCC 26-39 eliminates the annual 911 reliability certification and replaces it, after an 18-month transition, with an initial reliability certification that must be updated only on material change 2.
FCC 26-39 requires NGCS and ESInet covered 911 service providers to report their recent actions to enable interstate NG911 interoperability 30.

The Second FNPRM in FCC 26-39 proposes, but has not adopted, requiring NGCS and ESInet providers to test interstate transfer of 911 voice, video, data and text within 3 years 25. The Second FNPRM in FCC 26-39 seeks comment on integrating direct video calling into NG911 networks for accessibility but does not propose specific rules for it 24. Comments on the FCC 26-39 Second FNPRM were due August 10, 2026 and reply comments September 8, 2026 23.

Separately, 47 CFR 9.10(s) establishes location-based routing requirements:

47 CFR 9.10(s) required nationwide CMRS providers to deploy location-based routing for 911 voice calls on IP-based (4G LTE, 5G and later) networks by November 13, 2024 33.
47 CFR 9.10(s) set May 13, 2026 as the deadline for non-nationwide CMRS providers to support location-based routing for 911 voice and for CMRS providers to support it for real-time text 31.
For location-based routing, 47 CFR 9.10(s)(3) requires device location with horizontal uncertainty within 165 meters at 90% or higher confidence, available at routing time; otherwise the provider routes on the best available location 32.

Applicability

Applies to: FCC 47 CFR Part 9 Subpart J, NENA i3, NENA i3 common schema, IETF PIDF-LO, IETF LoST, IETF Emergency calling BCP, FCC NG911 Report, FCC NG911 rules, FCC NG911 registry, FCC Second Report, Second FNPRM FCC 26-39, and FCC 47 CFR 9.10(s). Deployments: all. Sources checked 2026-09-24.

What remains uncertain

UCaaS vendor NG911 Phase 2 PIDF-LO and LIS delivery across platforms is not covered by the sources below.
MLTS dispatchable location interaction with NG911 PIDF-LO delivery is not covered by the sources below.
Text-to-911 and RTT delivery obligations under NG911 for covered text providers are not covered by the sources below.
The outcome of the Second FNPRM regarding interstate interop testing and direct video calling is not covered by the sources below.
Compliance-date notice for FCC 26-39 sections needing OMB approval and start of the 18-month transition are not covered by the sources below.
Location-based routing as its own topic beyond 47 CFR 9.10(s) is not covered by the sources below.
Federal NG911 grant funding and legislation status under the NTIA/NHTSA 911 Grant Program are not covered by the sources below.
ESInet and NGCS cybersecurity requirements are not covered by the sources below.