The NG9-1-1 Transition: Lessons Learned from One Year of FCC 24-78

March 25, 2026, marked the first anniversary of the FCC's announcement that 9-1-1 Authorities could begin filing Requests for Service under the NG9-1-1 Transition Framework established by FCC Order 24-78. To mark the occasion, Intrado's regulatory and technical experts convened for a candid, behind-the-scenes look at what's actually happening in the field.

A Year of Activity: Where Things Stand

On the one-year mark since the filing window opened, the FCC's electronic filing system saw 161 Requests for Service (RFSs) for Phases 1 and 2. Within those requests, the Phase 1 RFS filings collectively cover nearly 2,000 PSAPs. It’s a significant footprint that represents real interest and momentum from the public safety community. As Jerry Wilke, Intrado Director of Sales Engineering, pointed out in our recent webinar, Intrado has proactively established approximately 3,200 PSAP connections for Phase 1, moving ahead of the filing curve to stay ready for deployments as they roll through.

As a reminder, Phase 1 requires OSPs to deliver 9-1-1 calls to the ESInet via SIP, and our panel noted that this phase has proceeded relatively smoothly from a technical standpoint. That’s because the connections are more straightforward, and most challenges have been logistical (like circuit ordering delays) rather than technical barriers. That said, Phase 1 is not entirely without complications, and a looming issue has emerged in the background that deserves attention: copper retirement.

A handful of ILECs control most of the legacy copper infrastructure across the U.S., and there is active pressure to retire those networks. However, Sean Ward, VP, Deputy General Counsel, noted that discontinuance of service notices on legacy 9-1-1 circuits don't always align with Phase 1 compliance deadlines. In at least one documented case, a provider had its 9-1-1 circuits decommissioned with little warning, forcing an unplanned scramble to establish ESInet connectivity. ILECS have dual roles in the transition, both as an OSP and the underlying circuit provider. At its March open meeting, the FCC revised its rules in FCC 26-19 to facilitate overall network modernization and, for the first time, included guardrails to promote a more orderly transition away from legacy facilities.

What's Happening in the Public Dockets

Lauren Kravetz, VP, Government Affairs, led a review of the FCC's public dockets, which revealed a few clear patterns. Phase 1 RFS filings have been flowing in steadily, with the bulk coming from 9-1-1 Authorities in states that have made some NG9-1-1 infrastructure investments.

Docket activity also shows mutual agreements being filed, with almost all of them extensions of time. These modest extensions have primarily been sought by larger, nationwide providers who need a few additional months beyond their original deadlines to complete the migration, generally pushing deadlines into Q1 or Q2 2026.

Notably, the docket for challenges to validity has been quiet. No OSP has yet formally challenged the validity of an RFS filing. There is also only one waiver on file in the broader docket, involving a situation where a nationwide provider and a 9-1-1 Authority could not agree on timing.

The overall picture is one of parties working things out, though the pace of traffic actually moving to IP remains an open question. And no agreements have emerged to date that would alter other default provisions of the rules, such as waiving the in-state point of interconnection requirement. But that may change as Phase 2 complexity is revealed.

OSP Responsibilities: Don't Assume Someone Else Is Handling It

One of the most pointed messages from the webinar was that the FCC's framework makes clear that the relationship and communication between an OSP and a 9-1-1 Authority is the OSP's responsibility.

The practical advice: when an OSP completes its Phase 1 or Phase 2 obligations, it should proactively reach out to the 9-1-1 Authority to confirm completion. Contact information for the filing authority — including name, email, and phone number — is available directly in the FCC's electronic filing system. What OSPs should not do is file a representation with the FCC declaring compliance. That creates its own complications and is not a requirement of the order.

OSPs should also be clear about the scope of their obligations. If a 9-1-1 Authority communicates an RFS directly to an OSP covering an area where the OSP has no customers or no license, the OSP should communicate that, too.

Phase 2: Where the Real Complexity Lives

While Phase 1 has been a manageable first step, Phase 2, which requires full i3-compliant call flows (delivering calls, location data, and supplementary information natively through the ESInet ) is a different challenge altogether. As of the time of the webinar, two Phase 2 RFS filings are currently active and valid: one covering Massachusetts and one filed by the Illinois State Police. No new Phase 2 filings have emerged since, but OSPs should be prepared for more on the horizon.

In Phase 2, challenges surrounding deployments often fall into several interconnected categories:

Interoperability: The Known Unknown

Unlike legacy telephony years ago, where a Bellcore interoperability test provided a common baseline for OSP testing, there is no equivalent universal certification for i3. The i3 standard is expansive, and multiple vendors and systems are involved. Every connection must be tested.

John Snapp, VP, Technology, discussed two specific issues that have already emerged in early deployments.

1. Location shape handling: as networks move from 2D (latitude/longitude) to 3D location data incorporating altitude, the shape used to convey that location changes from a circle to an ellipsoid. Some PSAP call handling systems were not built to receive ellipsoid-shaped location objects, causing failures in systems that otherwise passed basic i3 readiness checks.

2. Location delivery method: i3 supports both "location by value" (location embedded in the call) and "location by reference" (location retrieved via a query to a i3 LIS via HELD). Different ESInets are implementing these differently, and how a given ESInet handles location will affect what OSPs and their vendors must support.

The ALI-to-LIS Transition

Phase 2 also eliminates the traditional Automatic Location Identification (ALI) database in favor of an i3 Location Information Server (LIS). The record format is no longer MSAG — it's CLDXF (Civic Location Data Exchange Format), validated against a Location Validation Function (LVF). For OSPs and their records management teams, this is a significant operational change.

Data fields that existed in legacy ALI formats don't have direct equivalents in CLDXF, including class-of-service designations (WPH1, WPH2, VoIP, etc.). PSAPs and their call handling vendors are currently mapping incoming HELD data to legacy-style fields for CAD system compatibility. But that mapping work is nontrivial, and interoperability between LVF suppliers is not yet seamless.

Multi-Party Complexity and Cost

Phase 2 deployments involve more parties than Phase 1; the OSP, the ESInet provider, the PSAP's call-handling vendor, and the records management system all need to interoperate. One issue that has surfaced unexpectedly is the cost of interoperability testing. Some ESInet providers have begun charging for the interoperability testing required to establish Phase 2 connectivity — a cost that was not anticipated in initial planning assumptions. This dynamic is still evolving and may affect how providers approach Phase 2 deployment economics.

ESInet Provider Changes Add Another Variable

Several states have already switched ESInet providers as contracts expire, and more transitions are expected as multi-year contracts come up for renewal. When an ESInet changes hands, OSPs that had already established compliant connections may find themselves essentially starting over: retesting, reconfiguring, and revalidating connectivity with the new provider. The i3 standard's flexibility means that each ESInet implements it with its own nuances, and a connection that worked perfectly with one ESInet may require significant rework with a replacement. OSPs should treat NG9-1-1 connectivity as an ongoing operational commitment, not a one-time project. We expect questions to arise regarding how to apply the deployment timeframes in the FCC’s Transition Framework if OSPs that are already compliant are asked to reconfigure with a new ESInet provider.

What Comes Next?

The panel closed with a look beyond the immediate transition. The i3 standard continues to evolve, and the infrastructure being built now will need to grow with it. Advanced Automatic Collision Notifications (AACN) from vehicle telematics systems is already in development as a feature for ESInets, enabling structured crash data to be delivered directly to PSAPs. Medical device integration is on the horizon: a world where implanted or wearable devices could initiate a 9-1-1-like response over the public safety network without a voice call is technically conceivable, and the i3 framework is the foundation that would make it possible.

Realizing that vision requires completing the work at hand: getting Phase 2 deployments done, achieving full end-to-end IP call flows, and retiring the legacy infrastructure that has constrained public safety communications for decades. Funding remains a critical variable. There is genuine optimism that federal grant funding through NTIA may be available to help states and localities complete the transition, but the short-term window to make meaningful progress before Congress starts its summer recess in an election year is narrow.

One year into the NG9-1-1 transition framework, the field is moving. The foundations of Phase 1 are being laid broadly and, in most cases, without major incident. Phase 2 is where the real work, and the real complexity, begin.

Learn More

Watch the webinar to hear the full conversation with our experts. And stay tuned as Intrado's NG9-1-1 Conversations series continues with a follow-up session in Summer 2026.