Facilitating Implementation of Next Generation 911 Services (NG911); Improving 911 Reliability

Federal RegisterJul 10, 2026

Ask Donna

What actually matters in this document.

Text

FEDERAL COMMUNICATIONS COMMISSION

47 CFR Parts 0 and 9

[PS Docket Nos. 21-479 and 13-75, FCC 26-39; FR ID 355738]

Facilitating Implementation of Next Generation 911 Services (NG911); Improving 911 Reliability

AGENCY:

Federal Communications Commission.

ACTION:

Final rule.

SUMMARY:

In this document, the Federal Communications Commission (the FCC or Commission) adopts rules to ensure that emerging Next Generation 911 (NG911) networks are reliable and interoperable. NG911 is replacing legacy 911 technology across the country with internet Protocol (IP)-based infrastructure that will support new 911 capabilities, including text, video, and data. However, for NG911 to be fully effective, NG911 networks must be designed to safeguard the reliability of critical components and support the interoperability needed to seamlessly transfer 911 calls and data from one network to another. The rules require entities essential to delivering emergency calls in the NG911 environment to implement common sense measures to safeguard the reliability of NG911 networks and reduce the risk of 911 outages, and require certain entities to report on their support for NG911 interoperability. The rules also eliminate unnecessary and burdensome legacy rules to increase flexibility and encourage technical innovation to make NG911 services reliable, interoperable, and accessible to all.

DATES:

Effective date:

Effective August 10, 2026.

Compliance dates:

Compliance will not be required for §§ 9.19(c)(1)(i) through (c)(3)(i) and 9.20(a)(1)(i), (a)(2)(i), and (b), until a document is published in the

Federal Register

announcing compliance dates and revising §§ 9.20(a)(1)(i), (a)(2)(i), and (b), and revising or removing §§ 9.19(d) and 9.20(h). For entities described in § 9.19(a)(4)(i)(E) through (I), compliance with § 9.19(b) will not be required until a document is published in the

Federal Register

announcing compliance dates and revising or removing § 9.19(d).

FOR FURTHER INFORMATION CONTACT:

Rachel Waxman, Deputy Division Chief, Policy and Licensing Division, Public Safety and Homeland Security Bureau, at (202) 418-1138 or

Rachel.Waxman@fcc.gov.

SUPPLEMENTARY INFORMATION:

This is a summary of the Commission's Second Report and Order (

Order

), in PS Docket Nos. 21-479 and 13-75, FCC 26-39, adopted on June 25, 2026, and released on June 26, 2026. The full text of this document is available at

https://www.fcc.gov/document/fcc-modernizes-next-generation-911-reliability-and-interoperability-0.

People with Disabilities.

To request materials in accessible formats for people with disabilities (braille, large print, electronic files, audio format), send an email to

fcc504@fcc.gov

or call the Consumer & Governmental Affairs Bureau at 202-418-0530.

Congressional Review Act. The Commission has determined, and the Administrator of the Office of Information and Regulatory Affairs, Office of Management and Budget, concurs, that this rule is non-major under the Congressional Review Act, 5 U.S.C. 804(2). The Commission will send a copy of this

Second Report and Order

to Congress and the Government Accountability Office pursuant to 5 U.S.C. 801(a)(1)(A).

Synopsis

Introduction

Today, we modernize the Commission's 911 reliability framework to reflect America's ongoing upgrade to modern high-speed telecommunications infrastructure. 911 Authorities are rapidly replacing legacy 911 systems and migrating to the Next Generation 911 (NG911) ecosystem to gain access to advanced capabilities, enhanced resilience, greater interoperability, and improved accessibility.

In this Second Report and Order (

Order),

we ensure the reliability of NG911 by leveraging the strengths of modern telecommunications networks, including high-capacity fiber, dynamic routing, automated monitoring, and real-time failover capabilities that do not exist in legacy systems.

NG911 is an Internet Protocol (IP)-based system that enables emergency communications centers to receive, process, and analyze all types of 911 requests for emergency assistance; ensures interoperability; is secure; and meets certain other requirements.

See

47 CFR 9.28.

As the nation has embarked on the transition to NG911 over the last decade, the Commission has seen a corresponding increase in major, multi-state 911 service outages that have disrupted access to life-saving emergency services for millions of Americans.

Too often, these outages have occurred in parts of transitional NG911 systems outside the scope of the 911 reliability framework adopted in 2013,

which does not address the increasingly complex array of call scenarios in the Internet Protocol (IP) call origination context we live in today. We believe that, in many of these instances, operators could have prevented or mitigated outages by implementing reliability measures appropriate for IP-based systems.

See, e.g., Facilitating Implementation of Next Generation 911 Services (NG911),

PS Docket Nos. 21-479 and 13-75, Further Notice of Proposed Rulemaking, 40 FCC Rcd 2668, 2676-77, para. 16 (2025) (

NG911 Reliability FNPRM

See Improving 911 Reliability; Reliability and Continuity of Communications Networks, Including Broadband Technologies,

PS Docket Nos. 13-75 and 11-60, Report and Order, 28 FCC Rcd 17476 (2013) (

911 Reliability Order

NG911 Reliability FNPRM

at 2677, para. 17.

Because the 2013 911 reliability framework cannot reliably support modern 911 call flows, we take the following actions to reduce the risk of future outages in transitional and end-state NG911 networks and to streamline and reduce the burdens of our approach:

•

Covered 911 service providers.

We update our definition of covered 911 service providers (CSPs) to identify categories of providers whose operations are essential to NG911 call delivery, whose failure could cause significant outages, and who therefore must meet enhanced reliability standards under the Commission's framework. Our updated CSP definition includes operators of Emergency Services IP networks (ESInets), Next Generation Core Services (NGCS) providers, and providers of real-time location services, major IP transport, IP 911 traffic aggregation, and essential gateways for converting legacy and IP traffic.

•

Reliability standards.

We modernize and streamline the 911 reliability benchmarks applicable to CSPs to reflect widely recognized best practices appropriate to IP-based 911 networks. These benchmarks incorporate well-established IP best practices in the areas of physical diversity, operational integrity, and network monitoring and reflect achievable standards identified by the Commission's Communications Security, Reliability, and Interoperability Council (CSRIC).

We also make clear that CSPs can satisfy their reliability obligations by adopting reasonable alternative measures, including measures requested by state,

territorial, local, or tribal 911 Authorities.

CSRIC is a federal advisory committee that provides recommendations to the Commission on ways it can help ensure the security, reliability, and interoperability of communications systems. FCC,

Communications Security, Reliability, and Interoperability Council, https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability-council-0

(last visited May 19, 2026).

A 911 Authority is 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 from that point to PSAPs.” 47 CFR 9.28. 911 Traffic is “[t]ransmissions consisting of all 911 calls . . . and/or 911 text messages,” as well as location information, callback numbers, and routing information sent with the call and/or text message. 47 CFR 9.28.

•

Interoperability.

To support the seamless transfer of 911 calls and associated data across the NG911 ecosystem, we require NGCS and ESInet CSPs to report their recent actions to enable interstate NG911 interoperability, while seeking further comment on more detailed interoperability requirements. We also adopt a definition of “interoperability” specific to NG911 to provide clarity for both CSPs and 911 Authorities as NG911 deployments progress.

•

Certification Process.

We eliminate the requirement that CSPs file annual compliance certifications and adopt a streamlined filing process for CSPs going forward. We provide for an 18-month transition period, after which CSPs will file initial reliability certifications in conformance with the new rules, which they will need to update only in the event of material changes. This will reduce unnecessary regulatory burdens on CSPs while focusing the certification process on essential information relevant to ensuring NG911 reliability.

•

Oversight.

We allow 911 Authorities to access CSP certifications and reports subject to confidentiality safeguards, and we codify the process of the Public Safety and Homeland Security Bureau (PSHSB or the Bureau) for investigating and remediating noncompliance, providing transparency to service providers.

When outages do occur or are potentially imminent, the Commission imposes a distinct set of reporting, notification, and response requirements on various classes of service providers.

See, e.g.,

47 CFR 4.9(a)-(g), 4.11 (requiring cable, satellite, wireless, wireline, interconnected Voice over Internet Protocol (VoIP), and other providers to submit reports to the Commission if they experience significant outages on their networks), 4.9(h) (requiring these providers and CSPs to notify PSAPs that may be affected by significant outages), 4.17-4.18 (requiring certain providers to cooperate during disaster declarations and to submit status reports to the Commission). Nothing in this

Order

modifies those part 4 rules; this

Order

strictly addresses the CSP reliability requirements in part 9 of the Commission's rules.

Background

The FCC's 911 Reliability Framework

The Commission first required CSPs to improve the reliability and resiliency of 911 communications networks following an unanticipated and severe derecho storm in 2012. The storm struck the Midwest and Mid-Atlantic regions of the United States, leaving millions of Americans without 911 service for up to several days.

The Bureau conducted a comprehensive inquiry and found that the impacts to 911 service largely could have been mitigated or avoided had more providers adopted then-current industry best practices for network reliability to protect their facilities.

FCC Public Safety and Homeland Security Bureau, Impact of the June 2012 Derecho on Communications Networks and Services: Report and Recommendations at 1 (2013) (

Derecho Report

http://www.fcc.gov/document/derecho-report-and-recommendations.

The effects were particularly severe in northern Virginia, where four PSAPs in the densely-populated National Capital Region lost service completely, and in West Virginia, where eleven PSAPs could not receive 911 calls for as long as twelve hours.

Id.

at 28-34.

Id.

at 1-2.

1. In 2013, the Commission adopted rules requiring CSPs to implement these best practices and other sound engineering principles on their networks in order to prevent future 911 outages.

At that time, most CSPs provided 911 functions and connectivity on the networks of Incumbent Local Exchange Carriers (ILECs) between legacy selective routers or location databases and PSAPs.

The Commission defined CSPs to include entities that operate central offices directly serving PSAPs, as well as providers of 911, Enhanced 911 (E911), or NG911 capabilities such as call routing, automatic location information (ALI), automatic number identification (ANI), or the functional equivalent of those capabilities.

While recognizing the emergence of NG911, the Commission was not persuaded at that time “that NG911 technologies ha[d] evolved to the point that reliability certification rules should apply to entities beyond those that offer core services functionally equivalent to [legacy] 911 and E911 capabilities.”

See 911 Reliability Order.

911 Reliability Order,

28 FCC Rcd at 17489, para. 37. A public safety answering point (PSAP) is “[a]n answering point that has been designated to receive 911 calls and route them to emergency services personnel.” 47 CFR 9.3.

911 Reliability Order,

28 FCC Rcd at 17488-89, para. 36.

Id.

at 17491, para. 42.

The Commission required CSPs to annually certify their efforts to provide reliable 911 service with respect to circuit diversity, central-office backup power, and diverse network monitoring.

Specifically, CSPs must make efforts to achieve the following goals:

Id.

at 17503-26, paras. 80-138.

•

Circuit diversity:

Eliminating all single points of failure in critical 911 circuits; tagging those circuits; and conducting diversity audits annually.

47 CFR 9.19(c)(1).

•

Central-office backup power:

Provisioning central offices that serve PSAPs directly or that host selective routers with sufficient backup power to sustain full functionality in the event of power outages and testing and maintaining all backup power equipment.

Id.

§ 9.19(c)(2).

•

Network Monitoring:

Implementing physically diverse network monitoring links and aggregation points where monitoring data are collected and conducting diversity audits of monitoring links and aggregation points annually.

Id.

§ 9.19(c)(3).

The Commission delegated oversight of the reliability rules and certification process to PSHSB. The Bureau established the 911 Reliability Certification System (911RCS) to receive filings and certifications, and it was empowered to review certifications, revise certification forms and procedures, investigate noncompliance, and order remedial action.

Id.

§ 0.392(j).

Since adopting the reliability rules in 2013, the Commission has consistently observed that the rules would need to be updated to keep pace with the NG911 transition. For example, in a 2014 Policy Statement and Notice of Proposed Rulemaking on improving 911 governance, the Commission noted that it might need to update the rules to address changes in 911 technologies and the persistence of “sunny day” 911 outages.

And in 2015, the Commission reiterated its intent to consider “whether [the rules] should be revised or expanded to cover new best practices or additional entities that provide NG911 capabilities, or in light of our understanding about how NG911 networks may differ from legacy 911 service.”

911 Governance and Accountability, Improving 911 Reliability,

Policy Statement and Notice of Proposed Rulemaking, PS Docket Nos. 14-193 and 13-75, 29 FCC Rcd 14208, 14222, para. 32 (2014) (

2014 911 Reliability NPRM

Improving 911 Reliability; Reliability and Continuity of Communications Networks, Including Broadband Technologies,

PS Docket Nos. 13-75 and 11-60, Order on Reconsideration, 30 FCC Rcd 8650, 8655, para. 11 (2015) (

2015 911 Reliability Recon. Order

) (explaining further that providing CSPs with the flexibility to implement alternative measures was “essential to support and encourage the transition to NG911,” because the 2013 rules do not afford another option for most NG911 CSPs to

demonstrate their reliability).

See also

47 CFR 9.19(c)(1)(ii), 9.19(c)(2)(ii), 9.19(c)(3)(ii) (If necessary, a CSP may certify that one or more of the reliability requirements does not apply to its network and provide a supporting explanation.).

In July 2024, the Commission adopted a national NG911 transition framework that has accelerated the growth of the NG911 ecosystem.

The new transition framework specifies a two-phased approach to guide the transition to NG911, in which 911 Authorities initiate each phase by submitting a valid request to originating service providers (OSPs) within the relevant jurisdiction, and OSPs must comply with NG911 requirements for that phase within a defined period.

In the

NG911 Transition Order,

the Commission defined “Next Generation 911” to include interoperability, security, use of commonly accepted standards, and other criteria.

It also noted the potential for NG911 to support improved reliability and interoperability and that some commenters had urged it to consider specific reliability and interoperability requirements.

The Commission deferred consideration of reliability, interoperability, and accessibility

proposals because at the time they were beyond the scope of the proceeding. The NG911 transition framework rules took effect in March 2025,

and since then, 911 Authorities have issued more than 190 requests to begin Phase 1 service and one request for Phase 2 service. The requests cover parts or all of twenty-eight states and encompass more than 2,200 PSAPs.

See generally Next Generation 911 (NG911) Valid Requests,

PS Docket No. 25-143.

Facilitating Implementation of Next Generation 911 Services (NG911),

PS Docket No. 21-479, PS Docket No. 18-64, Report and Order, 39 FCC Rcd 8137, 8139, para. 3 (2024) (

NG911 Transition Order

). “Originating service providers” are defined for purposes of the NG911 transition rules as “[p]roviders that originate 911 traffic, specifically wireline providers; commercial mobile radio service (CMRS) providers, excluding mobile satellite service (MSS) operators to the same extent as set forth in § 9.10(a); covered text providers, as defined in § 9.10(q)(1); interconnected Voice over internet Protocol (VoIP) providers, including all entities subject to subpart D of this part; and internet-based Telecommunications Relay Service (TRS) providers that are directly involved with routing 911 traffic, pursuant to subpart E of [part 9].” 47 CFR 9.28.

47 CFR 9.28.

NG911 Transition Order,

39 FCC Rcd at 8220-28, paras. 182-197.

Id.

at 8217, 8218-19, paras. 174, 176, 179.

Public Safety and Homeland Security Bureau Announces Compliance Date and Provides Guidance on Information Collection for the Implementation of Next Generation 911,

Public Notice, 40 FCC Rcd 2057 (PSHSB 2025).

See

PS Docket No. 25-143.

2025 NG911 Reliability FNPRM.

In March 2025, the Commission proposed to modernize the 911 reliability framework to better ensure the resiliency, reliability, interoperability, and accessibility of NG911 networks.

In particular, the Commission proposed to expand the definition of covered 911 service providers so that IP-based providers and facilities that have emerged as essential to NG911 are subject to FCC reliability standards. The Commission proposed to clarify that it had already defined certain NG911 core services as CSPs under the 2013 reliability rules, because they provide NG911 capabilities that are functionally equivalent to the call routing, automatic location information, and automatic number identification functions of covered legacy facilities.

NG911 Reliability FNPRM,

40 FCC Rcd at 2669, para. 1.

Id.

at 2680, para. 29.

The Commission proposed to update the three 911 reliability benchmarks (physical diversity, network monitoring, and backup power) that identify presumptively-reasonable measures to reflect sound, industry-standard network practices that support the reliability of modern NG911 networks.

The proposed updated physical diversity benchmark included ensuring automatic rerouting capabilities, load balancing, and the geographic distribution of routing facilities, transport nodes, and node links sufficient to eliminate all single points of failure.

The network monitoring proposal included monitoring critical NG911 facilities using geographically distributed automatic disruption detection and alarm mechanisms appropriate for IP systems.

The Commission proposed to update the backup power benchmark by renaming it “operational integrity” and defining it to include providing location information server (LIS) and legacy network gateway (LNG) facilities with continuous power to maintain operations and the capability to automatically switch over to geographically diverse facilities.

The Commission also proposed in the

NG911 Reliability FNPRM

a new requirement for ESInets to be interoperable.

Finally, the Commission proposed several reforms to its oversight of the CSP reliability certification process.

Id.

at 2691-96, paras. 59-70.

Id.

at 2693-95, paras. 62-66.

Id.

at 2695-96, paras. 67-68.

Id.

at 2696, paras. 69-70.

An ESInet is an “(IP)-based network that is managed or operated by a 911 Authority or its agents or vendors and that is used for emergency services communications, including Next Generation 911.” 47 CFR 9.28.

NG911 Reliability FNPRM,

40 FCC Rcd at 2702-10, paras. 88-110.

Evolution of 911 Architecture

Like telecommunications networks generally, 911 networks are evolving from Time-Division Multiplex (TDM)-based architectures to IP-based architectures. As 911 Authorities transition to the NG911 ecosystem, they must entirely replace the circuit-switched architecture of legacy 911 with IP-based technologies and applications that provide all of the same functions as the legacy 911 system, as well as new capabilities. In its end state, NG911 will facilitate interoperability and system resilience, improve connections between PSAPs, and support the transmission of text, photos, videos, and data to PSAPs by individuals seeking emergency assistance. Many 911 Authorities have made significant progress to implement the transition to NG911.

As 911 architectures evolve, the entities that support essential functions and control critical components and pathways on 911 networks also change. In considering the CSPs that must take reasonable measures to provide reliable 911 service, the Commission has monitored the changing roles and responsibilities of different entities within legacy, transitional, and NG911 network architectures.

Forty-two states, the District of Columbia, Guam, and Puerto Rico reported expenditures on NG911 programs in calendar year 2024. FCC, Seventeenth Annual Report to Congress on State Collection and Distribution of 911 and Enhanced 911 Fees and Charges at 3 (2026),

https://www.fcc.gov/sites/default/files/17thAnnual911FeeReport-021326.pdf.

The total amount of reported NG911 expenditures in 2024 was $535,126,846.47.

Id.

Legacy 911 Networks

In 2013, when the Commission adopted the

911 Reliability Order,

the legacy networks of incumbent wireline providers typically connected PSAPs to those seeking help, whether the call for assistance originated on a landline or a wireless phone.

In these call flows, OSPs originate and transmit 911 calls placed by their customers, together with information about the callers' locations, to legacy 911 networks, where the calls are collected at an aggregation point called a selective router.

The selective router identifies the appropriate PSAP to receive each call by accessing an internal routing table that compares the caller's location information to the service areas of local PSAPs. The routing table data are populated with the assistance of a Master Street Address Guide (MSAG), a database that stores all

valid physical addresses within each PSAP's service area, and an ANI/ALI database that pairs provisioned phone numbers with MSAG addresses. After the selective router identifies the appropriate PSAP for each call, it determines the correct routing path for the call and transmits it, together with the caller's location and telephone number, to the central office serving the PSAP. Finally, the central office transmits the 911 call and associated caller information to the PSAP, typically along dedicated trunk lines. The PSAP validates the caller's location and callback number by querying ANI/ALI databases, and dispatches emergency services to the identified location.

Derecho Report

at 12.

911 Reliability Order,

28 FCC Rcd at 17478-79, paras. 7-8;

NG911 Reliability FNPRM,

40 FCC Rcd at 2680-81, para. 30.

See also

Appendix B.

NG911 Reliability FNPRM,

40 FCC Rcd at 2680-81, para. 30.

NG911 Networks

As part of the broader IP transition, 911 Authorities are deploying new, IP-based NG911 networks to receive, process, and deliver 911 traffic to PSAPs, and OSPs are changing how they transmit 911 traffic to those networks.

At the core of NG911 networks are ESInets that receive and process 911 traffic from OSPs and forward that traffic to PSAPs. 911 traffic enters the ESInet at one or more points of interconnection (POIs). When 911 Authorities designate a POI under our NG911 transition framework, it is called an “NG911 Delivery Point.”

NG911 Transition Order,

39 FCC Rcd at 8152, para. 28.

47 CFR 9.28.

OSP IP infrastructure.

To reach the POI, OSPs may connect directly in IP or convert their TDM legacy 911 voice traffic to an IP format using an LNG.

In some cases, OSPs may contract with third parties providing high-capacity IP-based fiber networks to carry 911 traffic to an ESInet's POI.

This traffic may be combined with other telecommunications traffic over major IP transport, or it may be segregated and combined with 911 traffic from other OSPs over 911-specific IP traffic aggregation facilities. OSPs use LISs

to store and manage customer location information and records, replacing functions of ANI/ALI databases.

NG911 Transition Order,

39 FCC Rcd at 8171, para. 71.

NG911 Reliability FNPRM,

40 FCC Rcd at 2687, para. 48.

A LIS is a functional element that provides locations of endpoints. A LIS can provide Location-by-Reference or Location-by-Value, and, if the latter, in geodetic or civic forms. A LIS can be queried by an endpoint for its own location, or by another entity for the location of an endpoint. 47 CFR 9.28.

NG911 Transition Order,

39 FCC Rcd at 8179-80, para. 86.

NG911 network infrastructure.

ESInets process 911 traffic through a series of interconnected NG911 Core Services (NGCS) that collectively replace the caller location and routing functions of selective routers, ANI/ALI databases, and the MSAG in legacy 911 networks.

These services typically include Location Validation Functions (LVFs), Emergency Call Routing Functions (ECRFs), and related technologies that enable the real-time provision of 911 caller location information to PSAPs (together, NGCS Location Facilities).

The LVF is a server that validates civic location information against a Geographic Information System (GIS) database to deliver more dynamic and actionable information about a caller's location than legacy ALI/ANI databases can, and the ECRF is a database function that determines the appropriate destination PSAP by mapping the caller's validated location within the boundaries of emergency response zones.

NGCS also include Emergency Services Routing Proxies (ESRPs), Policy Routing Functions (PRFs), and other technologies that enable the real-time routing, delivery, and transfer of 911 traffic to PSAPs along with callback information and other associated data (together, NGCS Routing Facilities).

The ESRP is a routing engine that queries the ECRF and routes the traffic to the geographically appropriate PSAP in accordance with the PRF, which is the rule set that decides how traffic should be routed based on predetermined policies (

e.g.,

priority levels, time of day, and load balancing).

NG911 Reliability FNPRM,

40 FCC Rcd at 2680-83, paras. 29-32;

NG911 Transition Order,

39 FCC Rcd at 8179, para. 86. The Border Control Function (BCF) acts as a firewall between the ESInet and external networks.

NG911 Reliability FNPRM,

40 FCC Rcd at 2682, para. 31 & n.84.

NGCS location facilities are NG911 IP facilities connected to an ESInet that enable the real-time provision of 911 caller location information to the PSAPs, including but not limited to the Emergency Call Routing Function (ECRF), the Location Validation Function (LVF), and successor technologies. Appendix A (§ 9.19(a)(14), defining “NGCS location facilities”);

NG911 Reliability FNPRM,

40 FCC Rcd at 2681-82, para. 31.

NG911 Reliability FNPRM,

40 FCC Rcd at 2681-82, para. 31. GIS is a mapping system that collects, stores, and analyzes spatial data, ensuring that emergency services can pinpoint where to send help.

Id. See also

47 CFR 9.28 (“Location Validation Function”).

NGCS routing facilities are NG911 IP facilities connected to an ESInet that enable the real-time routing, delivery, or transfer of 911 traffic to the PSAPs along with callback information and other associated data, including but not limited to the Emergency Services Routing Proxy (ESRP), the Policy Routing Function (PRF), and successor technologies. Appendix A (§ 9.19(a)(15), defining “NGCS routing facilities”);

NG911 Reliability FNPRM,

40 FCC Rcd at 2681-82, para. 31.

NG911 Reliability FNPRM,

40 FCC Rcd at 2681-82, para. 31.

NG911 networks also may connect with ESInets in other states or with other ESInets serving different regions in the same state. ESInet interconnecting facilities act as bridges between ESInets and support the rerouting of 911 traffic in the event of outages, which enhances the overall resiliency of the NG911 ecosystem across the interconnected service areas.

Id.

at 2689-90, paras. 54-55.

Transitional NG911 Networks

While nationwide end-state NG911 remains the Commission's goal, it is necessary to recognize and accommodate intermediate architectures during the nationwide transition to NG911. The commonly-accepted transition path for NG911 envisions that NG911 will reach a mature “end state” after all PSAPs have migrated from legacy E911 systems based on TDM circuit-switched telephony to all-IP systems that operate over ESInets and provide the full array of NGCS.

Achieving end-state NG911 will take time, and transitional NG911 networks need significant intermediate and transitional mechanisms in the interim. Transitional NG911 networks blend some legacy network components with IP-based infrastructure while the transition to end-state NG911 is still ongoing. Consequently, such deployments may retain selective routers, ANI/ALI, and other legacy elements as part of the call path even while implementing ESInets and NGCS. Transitional NG911 deployments also typically include gateway facilities that translate 911 traffic between TDM and IP formats as needed, including LNGs, emergency services gateways (ESGWs), legacy selective router gateways (LSRGs), and legacy PSAP gateways (LPGs).

NENA: The 9-1-1 Association (NENA), NENA i3 Standard for Next Generation 9-1-1 at 2 (Oct. 7, 2021),

https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-STA-010.3e-2021_i3_Stan.pdf

(

NENA i3 Standard

); Task Force on Optimal PSAP Architecture (TFOPA), An FCC Federal Advisory Committee, Adopted Final Report at 17, 37-38, 138 (2016),

https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_FINALReport_012916.pdf

(

TFOPA Final Report

NENA i3 Standard

at 3.

In this

Order,

we modernize our 911 reliability framework for NG911 networks.

We seek to ensure that

entities essential to delivering emergency calls in the NG911 environment implement common sense reliability measures to minimize risk of 911 outages, particularly catastrophic multi-state outages. To this end, we clarify and expand the CSP definition to identify which entities in the NG911 environment fall under the Commission's 911 reliability framework; update the reliability standards to reflect the capabilities and architectures of IP networks; adopt a definition for interoperability specifically tailored to NG911; and improve oversight processes available to the Bureau and 911 Authorities. The purpose of these actions is to ensure the continued resiliency, reliability, interoperability, and accessibility of the NG911 ecosystem.

In today's

Order,

“NG911 networks” refers to both transitional NG911 and end-state NG911 networks and ecosystems unless otherwise specified.

Today's

Order

also eliminates the annual certification requirement for 911 reliability that the Commission imposed in 2013. Going forward, we establish a streamlined filing process in which CSPs will submit a one-time reliability certification subject to updates only in the event of material changes. This revised approach recalibrates our 911 reliability framework to focus on critical aspects of the NG911 transition while reducing regulatory burdens. The new certification process will allow CSPs to certify to reliability at the network level on a per-state basis and will no longer require submission of detailed site-based data for thousands of different facilities. These changes will substantially lighten the burden of previous compliance measures in place since 2013 and will enable providers to redirect those resources to implementing reliable networks for the transmission of NG911 traffic.

Exec. Order No. 14,192, § 1, Unleashing Prosperity Through Deregulation, 90 FR 9065, 9065 (Feb. 6, 2025).

Development of 911 Network Reliability Practices

The required NG911 reliability practices we adopt today are based on two decades of investigations by the Commission into major network outages, studies and recommendations by federal advisory committees, rulemakings, and ongoing collaboration with industry stakeholders. For example, the Bureau found during its investigation into widespread 911 outages caused by the 2012 derecho that several reliability measures available to NG911 networks—including IP routers with automatic fail-over capability, diverse IP paths to PSAPs, interoperability between PSAPs, and diverse network monitoring—“likely could have significantly lessened the derecho's impact on emergency communications.”

In 2018, following its investigation into several major network outages, PSHSB identified increased monitoring of 911 network components and faster failovers to redundant network equipment as key mitigating measures.

And in 2020, following another series of major communications outages affecting 911, the Bureau encouraged CSPs to follow industry best practices for network reliability including circuit diversity and auditing, rerouting capabilities, and active network monitoring.

Derecho Report

at 44.

See

Public Safety and Homeland Security Bureau Encourages Communications Service Providers to Follow Best Practices to Help Ensure Network Reliability,

Public Notice, 33 FCC Rcd 3776 (PSHSB 2018). The Bureau also created a new network reliability page (

http://www.fcc.gov/network-reliability-resources

) to help ensure that network providers, public safety entities, and the general public can readily access the Bureau's work promoting industry best practices.

Id.

at 3776.

See Public Safety and Homeland Security Bureau Encourages Communications Service Providers to Implement Important Network Reliability Practices,

PS Docket Nos. 11-60 and 20-183, Public Notice, 35 FCC Rcd 13179 (PSHSB 2020) (

2020 Best Practices Public Notice

CSRIC regularly advises the Commission on ways to ensure the security, reliability, and interoperability of communications systems and to safeguard 911 service. In 2019, CSRIC VI provided recommendations to the Commission and to service providers concerning needed improvements to the reliability and resiliency of 911 systems during the transition to NG911.

CSRIC based its report on information from a wide variety of sources, including industry subject matter experts, 911 Authorities, public safety groups, CSRIC best practices and other CSRIC efforts, industry documents related to NG911 reliability, and FCC reports.

CSRIC recommended, for example, that service providers monitor for events that could result in a loss of service;

incorporate network monitoring tools on originating and transport networks specifically, to protect 911 traffic before it reaches the ESInet perimeter;

and work with stakeholders to share monitoring information.

CSRIC's updated best practices for NG911 included: geographic separation of network redundancy facilities; configuring backup power at critical sites to auto-engage in the event of a failover; development of standards for network interconnections; securing transport over the public internet with authentication and confidentiality mechanisms such as digital signatures and Virtual Private Network (VPN) tunneling; logical diversity for NG911 signaling networks, confirmed with regular diversity audits; dedicated, geo-diverse, and redundant IP connection points; geographically diverse 911 location servers; functional redundancy and geographic diversity for critical network elements; physical and geographic redundancy for critical facilities links; diverse routing from OSPs to the ESInet; and redundant connectivity from the ESInet to PSAPs.

CSRIC VI Working Group 1, Final Report—Recommendations for 9-1-1 System Reliability and Resiliency during the NG9-1-1 Transition; Version 2.0—March 8, 2019 (Addition of Best Practices) (2019),

https://www.fcc.gov/sites/default/files/csric6wg1_finalreport_030819.pdf

(

CSRIC VI WG 1 Report

Id.

at 7, 11-14.

Id.

at 69-70.

Id.

CSRIC also provided information on commercially-available tools used “to detect, deter and mitigate network anomalies within the 9-1-1 networks infrastructure.”

Id.

at 75, Appendix A.

Id.

at 86, 87, 109, 114, 122, 124.

Separately, the Commission asked CSRIC VII to survey the state of interoperability for the nation's 911 systems, including for legacy 911 networks, transitional 911 networks, and NG911.

CSRIC observed that 911 systems are highly interconnected and that interoperability between call-taking and call processing components is critical.

CSRIC concluded that the state of national NG911 interoperability is highly dependent on the degree of progress made by state and local 911 authorities in transitioning their respective systems to mature or end-state NG911 capability.

CSRIC

identified interoperability challenges and indicators of successful interoperability and recommended that the U.S. “continue to move forward with the deployment of NG9-1-1, with a strong focus on achieving interoperability, as defined in this report, which includes industry standards-based solutions.”

CSRIC VII, Working Group 4, Report on the Current State of Interoperability in the Nation's 911 Systems (2020),

https://www.fcc.gov/CSRICReports

(

CSRIC VII WG 4 Report

Id.

at 5.

Id.

at 22-23. CSRIC utilized the “maturity states” defined by the FCC's earlier TFOPA in crafting its report formulation.

See

TFOPA, Working Group 2, Phase II Supplemental Report: NG9-1-1 Readiness Scorecard at 13 (Dec. 2, 2016),

https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG2_Supplemental_Report-120216.pdf.

(

TFOPA Scorecard

). The scorecard defined states of transition ranging from legacy state, through foundational, transitional, and intermediate states, culminating in the jurisdictional and nation-wide “end state” of NG9-1-1 service. Per TFOPA, “End State” refers to the state in which PSAPs have evolved to become emergency communications centers (ECCs) and are served by standards-based NG911 systems and/or elements and OSPs are providing SIP interfaces with location information during call setup, and ESInets are interconnected providing interoperability on a national basis, supported by established agreements, policies and procedures.

See also

James Careless,

PSAP & Emergency Communications Centers Explained,

Public Safety Broadband Technology Association (Jun. 16, 2025),

https://thepsbta.org/psap-emergency-communications-centers-explained-psbta/

(“[A]n ECC performs the 911 call center functions of a PSAP, but can offer additional capabilities as well. For instance, an ECC can

handle non-emergency calls, assist in coordinating responses to multiple emergencies, and manage multi-agency communications during large-scale incidents.”).

CSRIC VII WG 4 Report

at 25.

The Need for Changes to the 911 Reliability Framework

NG911 provides significant advantages over legacy 911 systems, including enhanced reliability, redundancy, interoperability, and accessibility. However, without robust design, NG911 networks can heighten the risk to the public of widespread outages due to their increased aggregation and consolidation of traffic. In contrast to legacy 911 networks, in which call origination, routing, and delivery occur locally and are managed by a small set of providers, the NG911 ecosystem typically aggregates traffic from OSPs across broad geographic regions, transports this traffic over long distances, and relies on multiple operators. This aggregation makes the NG911 ecosystem more capable and flexible but also larger and more complex than the legacy ecosystem, with higher traffic volumes carried over longer transport paths than in legacy networks. Additionally, as noted above, the transitional NG911 ecosystem depends on functional elements that translate 911 calls between TDM and IP formats—elements often located far from the point where calls originate or are handed off to ESInets and PSAPs. The risks posed by substandard implementation of this new network architecture are not theoretical, as evidenced by recent 911 outages attributable to vulnerabilities in heretofore unregulated network elements.

As NG911 deployment accelerates, close coordination between industry, public safety entities, 911 Authorities, and the Commission is essential to ensure against vulnerabilities that could undermine 911 reliability, resiliency, and accessibility.

See, e.g.,

New York Public Service Commission (NYPSC) Comments at 2 (attesting to widespread 911 outages in New York originating in major transport networks that “took significantly longer to identify and understand” because the networks were not covered by the 911 reliability rules); NENA Comments at 1-2 (reporting that “failures downstream of the [OSP] but upstream of the [ESInet]” have been the cause for “several states that have had repeated widespread outages” resulting in “wide swaths of the state [being] unable to place 9-1-1 calls”); Colorado Council of Authorities, Inc. (CCOA) Comments at 2 (stating that unregulated “aggregators and operators of high-capacity transport facilities” have been the source of recent vulnerabilities, which “disrupts critical 911 functions and impacts multiple” PSAPs); Colorado Public Utilities Commission (COPUC) Comments at 2; Brian Rosen Comments at 3.

See also

47 CFR 9.19(4)(i).

As the Commission observed in the

NG911 Reliability FNPRM,

the landscape of 911 outage risk has evolved significantly since 2013. The

FNPRM

specifically cited examples of major 911 outages affecting millions of Americans in multiple states as 911 Authorities seek to transition from legacy 911 to NG911.

Moreover, since the release of the

FNPRM,

additional 911 outages have occurred in Pennsylvania, Mississippi, Louisiana, Alabama, Wyoming, and Montana, highlighting continued vulnerabilities that can affect statewide and multi-state NG911 deployments.

Some of these outages were triggered by single fiber cuts, which indicates that NG911 networks have not yet consistently implemented the geographically-distributed reliability measures we adopt in our

Order

today. Several failures originated in portions of the NG911 call flow located downstream of originating providers' owned-and-operated networks but upstream of ESInet and NGCS elements covered as “functional equivalents” under the 2013 reliability rules.

Failures in these

uncovered transport and aggregation segments can interrupt 911 service to dozens or hundreds of PSAPs, yet, to date, both the Commission and 911 Authorities have lacked visibility into the reliability practices employed by providers operating in this segment.

Without remedial action, these vulnerabilities could contribute to the continued occurrence of major “sunny day” 911 outages.

See NG911 Reliability FNPRM,

40 FCC Rcd at 2676-77, paras. 16-17.

Meir Rinde,

Pennsylvania's 911 service experiencing statewide outage

(Jul. 11, 2025),

https://whyy.org/articles/pennsylvania-911-calls-philadelphia-emergency-response/; 911 emergency lines restored in Mississippi, still down in parts of Louisiana

(Sept. 25, 2025),

https://www.cbsnews.com/news/911-emergency-lines-down-mississippi-louisiana/; AT

T Attributes Mass 911 Outages in 3 States to Fiber Cuts Made by `Third Parties'

(Sept. 26, 2025),

https://www.usnews.com/news/best-states/mississippi/articles/2025-09-26/at-t-attributes-mass-911-outages-in-3-states-to-fiber-cuts-made-by-third-parties;

Renée Jean,

Broken Fiber Line In Park County Exposes Fragility In Wyoming's 911 System

(Jan. 7, 2026),

https://cowboystatedaily.com/2026/01/07/broken-fiber-line-in-park-county-exposes-fragility-in-wyomings-911-system/;

Jenn Rowell,

Fiber Optic Line Maintenance Causes 911 Outage in Cascade County,

The Electric (Mar. 4, 2026),

https://theelectricgf.com/2026/03/04/fiber-optic-line-maintenance-causes-911-outage-in-cascade-county/.

The Commission requires certain OSPs to transmit 911 calls with appropriate location information to a PSAP, to a designated statewide default answering point, or to an appropriate local emergency authority. 47 CFR 9.4, 9.8, 9.10, 9.11,

9.14, 9.18. Under the Commission's NG911 transition framework, OSPs also have the obligation to deliver 911 traffic to the NG911 delivery point, which is a logical demarcation dividing the responsibilities of OSPs and 911 Authorities for the delivery of 911 traffic.

See

47 CFR 9.29, 9.32, 9.33.

NG911 Reliability FNPRM,

40 FCC Rcd at 2676-77, paras. 16-18.

See 2014 911 Reliability NPRM,

29 FCC Rcd at 14222, para. 32 (noting that the 2013 rules may need to be updated to address changes in 911 technologies and the persistence of “sunny day” 911 outages).

The framework we adopt today is narrowly tailored to strengthen NG911 networks while eliminating unnecessary regulatory burdens. By eliminating the requirement that CSPs file annual certifications and replacing it with a streamlined certification process, we maintain accountability while reducing the administrative burden on CSPs. We further align this streamlined regulatory oversight with the actual flow of 911 traffic in NG911 networks to ensure the rules remain appropriately limited to demonstrated areas of vulnerability. Our updated definition of “covered 911 service provider” focuses on those entities that play essential roles in routing, validating, or transporting 911 traffic in real time and whose failure would pose the most significant risk to service availability. Our updated reliability benchmarks address the principal vulnerabilities in NG911 architecture without imposing unnecessary or overly prescriptive requirements on CSPs. These benchmarks incorporate reliability measures recommended by CSRIC and recognized in the record as prevailing best practices, while also leveraging the inherent strengths of IP-based systems to adapt and self-heal in real time.

The new framework will optimize NG911 to meet operational needs today and tomorrow and ensure that actionable location and call back information and other data reliably move from callers to PSAPs and enable PSAPs to dispatch emergency responders quickly and effectively.

NG911 Transition Order,

39 FCC Rcd at 8222, para. 186 & n.546. (citing Intrado's assertion that “establishing direct OSP connectivity via SIP to ESInets `will materially reduce the number of 911 outages through improved network reliability and availability'”).

See also

Public Knowledge Comments at 4.

Lumen Comments at 2.

See also

Intrado Life & Safety, Inc. (Intrado) Comments at 1-2, 16-17; USTelecom—The Broadband Association (USTelecom) Comments at 2-4; Bandwidth Inc. and

Bandwidth.com

(Bandwidth) Comments at 1-2; NCTA—The internet and Television Association (NCTA) Comments, PS Docket No. 21-479, WC Docket Nos. 04-36, 10-90, 17-97, GN Docket No. 13-5 at 2-3 (rec. Jun. 11, 2025) (NCTA Comments); Intrado Reply at 2-3; Industry Council for Emergency Response Technologies (iCERT) Reply at 2; Comtech Telecommunications Corp. (Comtech) Reply at 4-5.

Lumen Comments at 2; iCERT Reply at 2.

See TFOPA Final Report; NENA i3 Standard.

In July 2021, NENA released the third version of the i3 standard for NG911. NENA, NENA Releases New Version of the i3 Standard for Next Generation 9-1-1 (July 12, 2021)

https://www.nena.org/news/572966/NENAReleases-New-Version-of-the-i3-Standard-for-Next-Generation-9-1-1.htm.

In October 2021, the NENA i3 standard was approved by the American National Standards Institute (ANSI). NENA, ANSI Approves NENA's i3 Standard for Next Generation 9-1-1 (Oct. 7, 2021),

https://www.nena.org/news/582667/ANSI-Approves-NENAs-i3-Standard-for-Next-Generation-9-1-1.htm.

Concurrently, many 911 Authorities have initiated the implementation of NG911 functional elements, made substantial investments in NG911 systems (spending over $500 million on NG911 programs in 2024 alone),

and submitted valid requests for NG911 service covering a significant portion of the United States. These collective efforts demonstrate that the NG911 ecosystem has reached a level of maturity where uniform expectations for reliability are both feasible and necessary. These efforts have also provided us with ample guidance to modernize the reliability framework in a way that reflects current operational realities and keeps pace with the fast-moving technological evolution of the capabilities inherent in IP-based networks. Adopting an updated framework now ensures that NG911 networks will be designed according to reasonable reliability standards from the outset and avoids the need for inefficient and costly retrofits in the future.

Early action also provides 911 Authorities with tools to engage in appropriate oversight of newly deployed NG911 services, enabling more effective planning and management of subsequent system performance and resiliency.

We revise our oversight framework in a streamlined manner, ensuring transparency and accountability while minimizing burdens and protecting sensitive operational information. In addition, we are providing an 18-month transition period for implementation of the new framework to afford CSPs time to integrate the updated reliability benchmarks into their ongoing NG911 deployments and to refine their networks, operations, and reliability practices accordingly. These actions reaffirm our commitment to ensuring that 911 remains dependable, resilient, and available when Americans need it most.

Seventeenth Annual 911 Fee Report

at 3.

See, e.g.,

APCO Reply at 14 (“[R]eliability measures must be built into these systems from the outset.”); COPUC Comments at 1-2; NASNA Comments at 1-2.

NASNA Comments at 6 (“CSPs should not be permitted under the rules to omit critical functional elements during procurement and then lay the responsibility at the feet of the local 911 jurisdiction citing

caveat emptor.”

); NYSPSC Comments at 2.

911 Reliability

Covered 911 Service Providers

As proposed in the

NG911 Reliability FNPRM,

we update the definition of

“covered 911 service provider” to accurately reflect the modern NG911 ecosystem and ensure that providers of critical NG911 services design their networks to safeguard 911 traffic.

We preserve the reliability requirements for legacy covered 911 services while more specifically defining the NG911 routing and location capabilities covered as part of this definition. We do this by clarifying that NGCS that provide NG911 location and routing capabilities are the “functional equivalent” of legacy selective routing and ANI/ALI services. We also expand the covered 911 services definition to include transport and aggregation facilities carrying substantial 911 traffic from two or more OSPs as well as some other shared facilities. These actions ensure that the term “covered 911 service provider” encompasses entities providing 911, E911, or NG911 services for which a failure would impede the real-time routing, delivery, or transfer of 911 traffic.

Appendix A (§ 9.19(a)(4)).

NG911 Reliability FNPRM,

40 FCC Rcd at 2686-2687, 2689, paras. 44-45, 53.

While the transition to NG911 is progressing alongside broader IP modernization, 911 Authorities and OSPs will continue for some time to rely on legacy selective routers and other TDM-based infrastructure for delivery of 911 calls to PSAPs.

In transitional NG911 systems, these legacy 911 network elements (selective routers; ANI/ALI databases; and TDM 911 circuits between selective routers, ALI/ANI databases, and the last central office serving a PSAP) will be treated as covered 911 facilities as they were under the 2013 reliability rules.

NGCS facilities and ESInet IP paths to PSAPs will also be covered 911 facilities, as will ESInet paths between NG911 delivery points and NGCS facilities. The definition of covered 911 services includes operation of NG911 and transitional elements serving two or more OSPs, such as LNGs, ESGWs, LSRGs, LISs, and LPGs.

Reducing Barriers to Network Improvements and Service Changes; Accelerating Network Modernization,

WC Docket Nos. 25-209 and 25-208, Report and Order, FCC 26-19, 2026 WL 1016892 (Mar. 27, 2026). The Commission's goal during this period is to encourage the development and deployment of advanced IP networks and services, including NG911, while ensuring seamless 911 connectivity.

Id.

at *25, para. 69. To that end, among other protections, the Commission requires carriers seeking to discontinue services supporting interconnection trunks or exchange of traffic to provide impacted 911 Authorities, 911 service providers defined as an entity that provides 911, E911, or NG911 capabilities or the functional equivalent of those capabilities directly to a PSAP, and directly interconnecting local exchange service providers that support essential functions within 911 networks with advance notice and a point of contact with which to coordinate an orderly transition away from legacy facilities that support 911.

Id.

at *24-25, paras. 67, 69 (“[W]e expect that carriers and service providers will engage in a planned and managed process for the orderly shutdown or reduction of services to . . . 911 Authorities handling live traffic, while ensuring compliance with regulatory requirements and a smooth transition to alternative providers.”).

Appendix B provides three illustrative network diagrams that demonstrate the application of our updated 911 reliability framework for legacy and transitional environments as well as for more mature NG911 configurations. The diagrams include an overlay of the presumptive cost allocation between OSPs and 911. Historically, the Commission has found that OSPs should bear the costs associated with transmitting legacy 911 calls from their end users to the points where they hand off such calls to selective routers used to transmit those calls to appropriate PSAPs.

NG911 Transition Order,

39 FCC Rcd at 8202-03, para. 146 (citing

Revision of the Commission's Rules to Ensure Compatibility with Enhanced 911 Emergency Calling Systems; Request of King County, Washington,

CC Docket No. 94-102, Order on Reconsideration, 17 FCC Rcd 14789 (2002)). Under the Commission's NG911 transition framework, OSPs similarly are financially responsible for the costs of transmitting 911 traffic from their end users to NG911 Delivery Points, in the absence of an alternative cost arrangement with the relevant 911 Authority.

Id.

at 8201-06, paras. 145-153.

In more mature NG911 systems, in which the selective router, legacy ANI/ALI facilities, and covered 911 TDM circuits connecting selective routers are no longer part of the call flow, the updated definition of covered 911 services includes ESInets, NGCS facilities, and ESInet IP covered 911 paths, as well as NGCS routing and location facilities such as the ESRP, PRF, ECRF, and LVF.

Covered 911 services also include several multi-OSP services, including IP 911 traffic aggregation, major IP transport, and shared LIS and LNG facilities.

See

Appendix B.

See id.

(Figure 3 also shows LPGs and interstate interconnecting ESInet facilities as covered 911 services).

Technologically neutral regulation of 911 reliability.

Historically, the Commission has allowed providers to use various proven technologies and approaches to comply with 911 reliability rules rather than prescribing specific solutions.

We reaffirm this commitment to a technologically neutral approach for regulating covered 911 providers in order to “future-proof” our framework, an approach that is strongly supported by commenters in this proceeding and will provide regulated entities compliance flexibility. Consistent with this principle, we define a CSP as any entity that provides covered 911 services, which are 911, E911, or NG911 services for which a failure would impede the real-time routing, delivery, or transfer of 911 traffic.

This definition uses informative, non-normative examples,

with reference to functional elements featured in current commonly accepted NG911 standards, in order to clearly delineate the types of services that are critical to 911 reliability today. Our technologically-neutral approach also serves to ensure that we do not “inadvertently stifle innovation, create misalignment with standards-based implementations, or sweep in entities whose operations do not materially impact the delivery of emergency services.”

We believe that our approach is flexible enough to not only ensure clear compliance today but also to guide future compliance as technologies change.

See, e.g.,

NG911 Transition Order,

39 FCC Rcd at 8159-60, paras. 39-40.

USTelecom Comments at 6 (“USTelecom recommends that the Commission define CSPs based on core NG911 functionalities—namely, whether a service enables the selective routing or delivery of 911 calls or the associated transmission of caller location and call-back information.”); iCERT Comments at 7 (stating the FCC's CSP definition “should cover providers that enable the real-time routing, delivery, or transfer of 911 calls or texts, along with location or callback information, and other associated data (collectively, the `NG911 Core Functions'), rather than stipulating whether a particular service falls into a predefined category”). Appendix A (§ 9.19(a)(4)(i)).

ATIS Reply at 3.

USTelecom Comments at 5.

See also

CTIA Reply at 2-3, 5; Verizon Comments at 3.

Preserving State and Local Government Flexibility.

Today's action leaves in place the exemption for state and local governments operating their own facilities that would otherwise be covered 911 services. Thus, no PSAP, 911 Authority, or other governmental authority directly providing 911, E911, or NG911 capabilities is a CSP or is otherwise subject to these regulations.

Further, we emphasize that we do not preclude states from adopting their own 911 reliability approaches that do not conflict with the Commission's goals in this proceeding, for example, by adopting reliability measures for smaller transport facilities than those we regulate today.

In addition, for CSPs that directly serve 911 Authorities, today's framework leaves in place the ability to implement alternative reliability measures to mitigate the risk of failure in certain situations, taking

into account the level of service ordered by the PSAP or 911 Authority.

100

We make non-substantive, clarifying edits to the language in section 9.19(a)(4)(ii) setting forth this exemption. The revised rule now specifies that 911 Authorities are exempt governmental authorities and that the 911 capabilities that are exempted include E911 and NG911 capabilities. Appendix A (§ 9.19(a)(4)(ii)(A)).

COPUC Comments at 2 (explaining the Commission's and states' “shared concurrent jurisdiction” over 911, where “the Commission sets a baseline for 911 networks and call delivery and the states add to this through statute, regulation, and service level agreements”).

100

911 Reliability Order,

28 FCC Rcd at 17497, para. 62 (“The Bureau will consider a number of factors in determining whether the particular alternative measures are reasonably sufficient to ensure reliable 911 service. Such factors may include the technical characteristics of those measures, the location and geography of the service area, the level of service ordered by the PSAP, and state and local laws (such as zoning and noise ordinances).”).

see also

Indiana Statewide 911 Board, The History of Accomplishments of 911 in Indiana, at 17 (Nov. 2020)

https://www.in911.net/uploads/1/2/4/9/124957688/2020_history_and_accomplishments_final.pdf

(“INdigital customers receive ALI via a distributed IP ALI system (INDB). This will change with the full deployment of the dual ESInets.”).

Some commenters question whether certain NGCS elements—such as MSAG Conversion Service, GeoCode Service, and Mapping Data Service—are needed for 911 live-call routing or location information.

135

The functional definition we adopt today resolves the issue by including these functions only when the NGCS provider uses them for live-call routing or location information. We also agree with NENA and other commenters that recommend against including GIS as an example of covered NGCS Location Facilities. GIS is a “a system for capturing, storing, displaying, analyzing, and managing data and associated attributes which are spatially referenced” to map and visualize data such as the locations of streets and buildings.

136

While GIS plays an important role in NG911, we exclude it because it is not used for the delivery of real-time 911 caller location information. Instead, GIS is a data resource that supplies information to a LIS or NGCS element only periodically so that those covered elements can perform the live caller location function.

137

135

NENA Comments at 5-6; iCERT Comments at 10.

136

NENA,

NENA Knowledge Base, https://kb.nena.org/wiki/GIS_(Geographic_Information_System)

(last visited May 19, 2026);

See also

Michigan State 911 Committee Comments at 1 (encouraging the Commission to hold indirect providers accountable “either through direct certification or through clear responsibility by the contracting [CSP]”).

Finally, as recommended by several commenters, we replace the word “PSAP” with “911 Authority” to ensure all necessary NGCS entities are covered. This change is necessary to account for the variety of state and local governance structures for 911,

143

and we incorporate the definition of “911 Authority” adopted in the

NG911 Transition Order.

144

143

NENA Comments at 3; Brian Rosen Reply at 2.

144

NG911 Transition Order,

39 FCC Rcd at 8164, para. 50; 47 CFR 9.28.

Administrative Lines.

Some commenters advocate revisions to

remove administrative lines from the definition of essential facilities to be maintained by legacy CSPs.

145

We decline to revise the legacy 911 reliability definition at this time, because TDM-based administrative lines continue to be used in legacy PSAPs as a backup option during outages as well as for PSAP-to-PSAP calls.

146

However, we anticipate that this requirement will become moot as legacy PSAPs replace TDM administrative lines with VoIP connectivity delivered by ESInets.

147

Accordingly, we encourage 911 Authorities, PSAPs, CSPs, and OSPs to work together to quickly migrate and retire legacy TDM facilities consistent with the overall goals of the NG911 transition and the IP transition. As the NG911 transition progresses, the Commission may re-evaluate the continued importance of reliability requirements for legacy administrative lines.

145

NASNA Comments at 3;

see also

NCTA Reply at 6 & n.20. The term “legacy CSP”, when used in this

Order,

refers to providers of TDM-based 911 or E911 covered services under the original 2013 reliability rules.

See

47 CFR 9.19(a)(4)(i)(A)-(B).

146

See 2020 Best Practices Public Notice,

35 FCC Rcd at 13179-81 (“If primary and secondary routing to . . . [PSAPs] are not available, [CSPs] and [OSPs] should take steps to ensure that the 911 caller receives assistance, such as routing 911 calls to the administrative lines of destination PSAP(s)[.]”).

147

NC 911 Board, North Carolina 911 Board Meeting Minutes for Aug. 28, 2020 at 7 (2020),

https://it.nc.gov/20200828-nc911-board-minutes-approved/download?attachment

(discussing the “conversion of PSAP administrative lines to SIP to provide additional capabilities and protection” and stating that doing so “would also provide cost savings in the long run. Not all administrative lines could be converted . . . and this could only be done for those utilizing a hosted call handling solution on the ESInet.”).

ESInets and Legacy PSAP Gateways

As proposed in the

NG911 Reliability FNPRM,

we designate the operation of ESInets, as covered 911 services subject to our 911 reliability framework.

148

The Commission has historically treated ESInet providers as CSPs to the extent they provide covered 911 services.

149

The Commission has also recognized that ESInet paths to PSAPs are “critical 911 circuits” under the 2013 rules.

150

The

NG911 Reliability FNPRM

proposed to explicitly identify ESInet transport paths to PSAPs as covered facilities.

151

We adopt this proposal in today's

Order,

affirming that operation of an ESInet is a covered 911 service. This recognizes the fact that ESInet operators typically manage critical NG911 circuits and paths needed to receive and process 911 calls from OSPs and transmit them to 911 telecommunicators, forming the “backbone” of NG911.

152

As a practical matter, identifying ESInet operators as CSPs is not a major rule change, because most current ESInet operators have already filed 911 reliability certifications under the prior rules.

148

Appendix A (§ 9.19(a)(4)(i)(D)).

149

911 Reliability Order,

28 FCC Rcd at 17491, para. 43 (“[W]e decline at this time to cover all operators of [ESInets][.] . . . ESInet operators will be required to certify reliability only to the extent they qualify as Covered 911 Service Providers under our rules.”).

150

Id.

at 17503, para. 81 & n.179 (“NG911 networks may use IP-based ESInets to interconnect the selective router function to the PSAP. The facilities that compose these ESInets would be considered `critical 911 circuits.'”).

151

NG911 Reliability FNPRM,

40 FCC Rcd at 2694, para. 65 (NG911 data paths subject to physical diversity “include[] IP traffic paths from NGCS facility capabilities . . . .”);

id.

at 2689, para. 53 (asking if the proposed rules would “capture instances where ESInet operators accept 911 traffic at an NG911 Delivery Point, send the traffic out of state for processing, and then back in-state to the ESInet for ultimate delivery to a PSAP”).

152

NENA,

NENA Knowledge Base, https://kb.nena.org/wiki/ESInet_(Emergency_Services_IP_Network)

(last visited May 19, 2026).

Because of the central and critical role of transport performed by ESInets in the NG911 ecosystem, we classify all ESInet providers as CSPs regardless of whether they provide services directly or indirectly to a 911 Authority. As NENA notes, there may be instances where a regulation covering NGCS providers “directly serving” a 911 Authority may not capture corresponding ESInet providers, as the two entities might be separate with only one of the two having a contract with the 911 Authority.

153

To accommodate potential variation in state and local government NG911 deployments and ensure that all ESInets meet reliability standards, we include the operation of an ESInet as a covered 911 service whether the service is provided directly or indirectly to 911 Authorities.

153

NENA Comments at 12.

Transitional Legacy PSAP Gateways.

We also include NG911 transitional gateways used with ESInets as covered 911 services.

154

Specifically, we include legacy PSAP gateways (LPGs) as covered transitional elements, which link NGCS and ESInet facilities to legacy PSAPs, permitting 911 Authorities to upgrade PSAPs to NG911 on a graduated basis as funding and resources become available.

155

As with all of the CSP categories we adopt today, if an LPG is operated directly by the PSAP or 911 Authority instead of a private vendor, it is excluded from our covered 911 services definition and no certification is required.

154

Appendix A (§ 9.19(a)(4)(i)(F)).

155

See

Mike Guerra, Director of NG9-1-1 Products, AT&T,

Keeping 9-1-1 Connected as Networks Evolve: How T9-1-1 Bridges the Gap for PSAPs

(Jan. 20, 2026),

https://about.att.com/blogs/2026/t911.html

(describing a solution with which AT&T will use legacy PSAP gateways to maintain connectivity with legacy PSAPs during the IP transition).

Other services.

Some commenters claim they lack visibility into the network path diversity of their downstream or leased transport providers and therefore cannot implement 911 reliability measures with respect to those facilities.

156

Some of these commenters ask the Commission to directly regulate the ESInets' underlying transport providers or Multiprotocol Label Switching (MPLS) vendors as CSPs.

157

While we decline to classify such underlying transport or MPLS providers as CSPs independently, we agree that ESInet providers should not be required to certify to the network architecture of IP paths beyond the information they can reasonably obtain in service level agreements.

158

Accordingly, and as discussed further below, we adopt additional safeguards and certification processes to ensure that all CSPs, including ESInet operators, can certify to the Commission that they satisfy reasonable reliability based on measures that they themselves can implement.

156

Comtech Comments at 14-15; Intrado Comments at 20; iCERT Comments at 13.

157

Comtech Comments at 15; NENA Comments at 9.

See also

NENA, NENA Knowledge Base,

https://kb.nena.org/wiki/MPLS_(Multiprotocol_Label_Switching)

(last visited May 19, 2026) (defining MPLS).

158

iCERT Comments at 13.

Location Information Servers and Transitional Gateways

In the

NG911 Reliability FNPRM,

the Commission proposed to include Location Information Servers (LISs) and Legacy Network Gateways (LNGs) in the definition of covered 911 services because these services are critical to the call path of 911 traffic.

159

A LIS is an NG911 functional element that allows OSPs to send caller location information to PSAPs for IP networks, replacing the legacy ALI/ANI database.

160

An LNG converts TDM 911 traffic from OSPs to IP format before it reaches an NG911 ESInet, and as such it is critical to ensure 911 reliability during the NG911 transition.

161

Unlike LISs, LNGs are transitional facilities that will be phased out when the NG911 transition is complete.

159

NG911 Reliability FNPRM,

40 FCC Rcd at 2686-87, paras. 44-46.

160

NG911 Transition Order,

39 FCC Rcd at 8170-71, para. 70;

see also

47 CFR 9.28 (defining “LIS”).

161

NG911 Reliability FNPRM,

40 FCC Rcd at 2687, paras. 45-46.

We adopt the

FNPRM

proposal to include LISs and LNGs in the definition of covered 911 services, but only for operators that provide LIS or LNG

services to two or more OSPs.

162

This modification addresses concerns raised by wireless industry commenters that operate LIS and LNG facilities for their own traffic only.

163

We clarify that the 911 reliability framework does not apply to OSPs that self-provision a LIS or LNG, to OSPs that contract with providers of aggregated LIS or LNG services, or to LIS/LNG providers that only serve a single OSP.

164

162

Appendix A (§ 9.19(a)(4)(i)(E)-(F)).

163

See, e.g.,

CTIA Comments at 3-4.

164

NCTA Reply at 6; Letter from Steven Morris, Vice President and Deputy General Counsel, NCTA, to Marlene H. Dortch, Secretary, FCC, PS Docket No. 21-479

et al.,

at 2 (filed May 4, 2026) (NCTA May 4, 2026

Ex Parte

To provide additional clarity as to the 911 services addressed in our 911 reliability framework, we also include operators of emergency services gateways (ESGWs), which provide critical connectivity between IP paths and legacy trunks connecting to a selective router, and operators of legacy selective router gateways (LSRGs), which provide an interface between legacy selective routers and ESInets during the transition until IP facilities are installed to replace all TDM facilities in the 911 call path between the OSP and the ESInet.

165

Similarly to the LNG and LIS, we limit coverage of transitional gateways on the OSP side of the call path to those that serve two or more OSPs. Therefore, OSPs that self-provision their own transitional gateways without offering service to other OSPs, while subject to the OSP 911 transmission rules, are not subject to the 911 reliability framework.

165

CSRIC VI WG 1 Report

at 129 (“The LSRG provides an interface between a 9-1-1 Selective Router and an ESInet, enabling calls to be routed and/or transferred between Legacy and NG networks. A tool for the transition process from Legacy 9-1-1 to NG9-1-1.”); NENA, NENA Legacy Selective Router Gateway (LSRG) Standard at 2 (2022),

https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/nena-sta-034.1-2022_lsrg_202.pdf. See also

NENA, NENA Knowledge Base, ESGW (Emergency Services Gateway),

https://kb.nena.org/wiki/ESGW_(Emergency_Services_Gateway)

(last visited May 30, 2026).

We disagree with commenters who argue against including shared LIS and LNG facilities as covered 911 services, as they are unambiguous chokepoints in NG911 architecture, not subject to state and local governmental or Commission direct visibility and oversight under the 2013 reliability rules, and can benefit from reasonable reliability measures. At the same time, we agree with commenters that it is not necessary to apply the full array of reliability obligations to LIS and LNG facilities that apply to other critical NG911 elements. Therefore, we are not imposing automatic rerouting or load balancing obligations on LIS, LNG, or similar transitional covered 911 facilities—which are IP path reliability standards—but only the operational integrity benchmarks which apply to server facilities and similar equipment. We also acknowledge that the LNG is a mixed TDM-IP transitional network element that may not always be able to provide automatic switchover to redundant facilities depending on behaviors of the “sending carrier's” facilities.

166

We reiterate that CSPs may certify to the Commission that they are using alternative reliability measures based on technology or customer limitations. In addition, as will be the case with similar transitional mixed TDM-IP facilities like the LPG, we will not dictate to CSPs whether their LNGs, LSRGs, or ESGWs should satisfy IP reliability practices or legacy reliability practices; so long as they satisfy one or the other, we will deem the practices presumptively reasonable. We defer to CSPs to implement the most reasonable combination of practices under the circumstances, including practices that pick and choose from both categories as alternative measures.

166

Intrado Comments at 18.

Finally, we agree with Intrado that “the aim should be to eliminate these LNGs as quickly as possible by accelerating end-to-end NG911.”

167

The Commission is actively engaged in multiple proceedings to expedite the NG911 and IP transitions.

168

We take this opportunity to encourage all CSPs, OSPs, and 911 Authorities to continue to work expeditiously and cooperatively to retire their legacy TDM-based facilities to upgrade and replace them with IP and NG911 facilities as fast as possible. The NG911 and IP transitions are interdependent and necessitate stakeholders in the NG911 ecosystem to coordinate, including around ensuring the reliability of 911 for the benefit of consumers. Today's 911 reliability framework will provide greater visibility into how the NG911 transition is working for state and local governments and for the Commission and will allow us to exercise better oversight into these transition processes, and to help resolve problems where they arise.

167

Id.

168

See, e.g.,

NG911 Transition Order,

39 FCC Rcd at 8137, para. 1;

Advancing IP Interconnection et al.,

WC Docket No. 25-304 et al., Notice of Proposed Rulemaking, FCC 25-73, 2025 WL 3677909 (Oct. 29, 2025);

Reforming Legacy Rules for an All-IP Future; Accelerating Network Modernization,

WC Docket Nos. 25-311 and 25-208, Notice of Proposed Rulemaking, FCC 26-11, 2026 WL 567517 (Feb. 19, 2026).

Major IP Transport Facilities and IP 911 Traffic Aggregation Facilities

We categorize providers of both major IP transport facilities and 911 IP aggregation facilities as CSPs, consistent with the Commission's proposals in the

NG911 Reliability FNPRM.

169

However, in response to the record, we have narrowed the scope of our definitions of major IP transport facilities and 911 IP traffic aggregation facilities to focus on large-scale transport and aggregation facilities that would have the most significant impact on 911 service in the event of an outage. For major IP transport facilities, we raise the capacity threshold of services that would be subject to the 911 reliability framework. Moreover, for both major IP transport and 911 IP aggregation, we include such providers within our definitions only if they provide services to two or more OSPs, excluding any 911 traffic originated on the provider's own network.

169

Appendix A (§ 9.19(a)(4)(i)(G)-(H));

NG911 Reliability FNPRM,

40 FCC Rcd at 2687-89, paras. 47-53.

In legacy 911, most OSPs deliver 911 calls directly to their local ILEC, which uses selective routers to receive and route the calls to the appropriate PSAP. When the Commission identified selective routers as critical 911 facilities in the 2013

911 Reliability Order,

it recognized that selective routers perform not only the routing function but also aggregate 911 calls from multiple OSPs.

170

In the

NG911 Reliability FNPRM,

the Commission recognized that, in NG911 architecture, the routing and aggregation functions previously performed by ILEC selective routers are performed by an entirely new set of routing and aggregation facilities. Moreover, many of these routing and aggregation facilities are provided by third parties who operate downstream from OSPs but upstream from the POIs where 911 traffic is handed off to ESInets for routing to the appropriate PSAP.

171

In the

FNPRM,

the Commission noted that these facilities were not subject to the Commission's 911 transmission rules or the then-current 911 reliability rules because providers of third-party transport and aggregation services did not meet the definition of either CSPs or OSPs.

172

The Commission tentatively concluded that these providers had become sufficiently crucial to the provision of NG911 service that they should be

subject to the same reliability requirements as other providers of covered 911 services.

173

The Commission also proposed to focus reliability requirements on major transport and aggregation providers and not to extend them to smaller providers whose facilities do not pose a risk of widespread 911 outages.

174

170

NG911 Reliability FNPRM

at 2694, para. 65 & n.141 (citing

911 Reliability Order,

28 Rcd at 17478, para. 7 (“The local switch then sends the call to an

aggregation point

called a selective router[.]”)).

171

Id.

at 2677, para. 17.

172

Id.

At 2687-88, para. 48.

173

Id.

at 2687, para. 47.

174

Id.

at 2688, para. 49.

Public safety commenters emphasize the importance of including third-party transport and aggregation services in the definition of covered 911 services.

175

These commenters also confirm that several recent significant 911 outages have resulted from failure of these facilities.

176

To date, neither the Commission nor 911 Authorities have had sufficient visibility into or oversight of these critical NG911 market participants to ensure reliable 911 services.

177

Designating the operators of these facilities as CSPs will ensure that the reliability practices of these critical providers in the 911 call path are visible to 911 Authorities and the Commission in the event that problems or call failures arise.

178

175

NYPSC Comments at 2; CCOA Comments at 2; NENA Comments at 1-2.

176

NENA Comments at 1-2; COPUC Comments at 2.

177

Brian Rosen Reply at 2; CCOA Comments at 2.

178

NYSPSC Comments at 1-2; COPUC Comments at 7.

Our action also provides greater certainty for OSPs contracting with third-party CSPs to provide 911 transport or aggregation. OSPs express concern that they could face increased risk of liability for 911 outages caused by failures of third-party NG911 transport providers and aggregators if such entities are not subject to FCC regulation and oversight.

179

Today's 911 reliability framework extending FCC oversight to transport providers will allow OSPs to better vet their NG911 third-party CSPs based on the FCC's NG911 reliability benchmarks. Similarly, strengthening the reliability of third-party aggregation services benefits OSPs by providing additional assurances that entities responsible for aggregating their customers' 911 calls are taking measures to support reliability.

180

179

Home Telephone NG911 Transition Comments, PS Docket 21-479, at 5 (rec. Aug. 9, 2023) (“[S]everal large Aggregators will be consolidating massive portions of the country's critical emerging NG911 services on their systems with little Commission oversight.”);

id.

at 13 & n.6, 16-17; Windstream NG911 Transition Reply, PS Docket 21-479, at 2-3 (rec. Sep. 8, 2023).

180

Home Telephone NG911 Transition Comments, PS Docket 21-479, at iii (rec. Aug. 9, 2023) (“The Commission should establish standards and reporting requirements for these `Aggregators' to ensure the NG911 network is safe and reliable for IP emergency transmissions destined to local PSAPs.”); Windstream NG911 Transition Reply, PS Docket 21-479, at 2-3 (rec. Sep. 8, 2023).

We disagree with commenters who contend that the 911 transmission rules applicable to OSPs are sufficient to ensure reliability of third-party 911 transport and aggregation between OSPs and ESInets.

181

While the 911 transmission rules, in conjunction with the NG911 transition framework, hold OSPs responsible for delivering 911 calls originated on their networks to ESInets and PSAPs, they do not impose any specific reliability obligations on the third parties that many OSPs rely on to accomplish such delivery. Moreover, as the Commission recognized in the

NG911 Reliability FNPRM,

the reliability practices of these third parties may be invisible to OSPs until after an outage has occurred.

182

By applying the 911 reliability framework to third-party providers, we enable 911 Authorities and the Commission to work collaboratively with industry and state and local governments to

prevent

these kinds of 911 outages before they happen.

183

The Commission's goal, through the application of this 911 reliability framework to major IP transport and IP 911 traffic aggregation facilities, is to reduce the risk of multistate or multi-OSP 911 outages such that there are fewer instances in which callers cannot reach their local PSAP in case of emergency.

181

Verizon Comments at 6-7; CTIA Comments at 4; USTelecom Reply at 2-3.

182

NG911 Reliability FNPRM,

40 FCC Rcd at 2677, para. 18.

183

NYSPSC Comments at 2; Virginia State Corporation Commission Comments, PS Docket No. 13-75 et al., at 4 (rec. Mar. 23, 2015) (“[I]n the public safety arena the priority must be on prevention versus determining blame after a tragic event.”).

We also disagree with commenters who contend that extending our 911 reliability framework to third-party providers will result in OSPs necessarily bearing unwarranted additional costs for NG911 reliability.

184

Under the NG911 transition framework, OSPs are presumptively responsible for the costs of 911 transport to NG911 delivery points, whether they provide such transport directly or through a third-party provider. However, requiring third-party providers to take reliability measures gives OSPs more options, not fewer, for controlling such costs while reducing their outage risk.

185

OSPs retain flexibility to use dedicated third-party CSP transport or aggregation services or to directly connect to ESInets. OSPs that choose to use third-party CSPs will have greater assurance that the CSPs are providing reliable dedicated service. OSPs also have cost-effective options to purchase geo-diverse cloud-based paths or VPN circuits over the public internet—neither of which is itself a covered 911 service, but both of which, with suitable precautions, can help OSPs or CSPs to achieve 911 path diversity and ensure reliable 911 traffic delivery. OSPs may also reduce costs by reaching agreements to use the same IP paths between ESInets and PSAPs to send originating customer 911 traffic upstream to reach the NGCS facilities.

186

184

NTCA and the RLEC Parties Comments at 2, 4-5.

185

Id.

at 4-5.

186

Home Telephone Comments at 10-11 & n.32 (“The concept would utilize the connection between the ESInet provider and the PSAP which is used to transmit information down to the PSAP on a two-way basis to transmit traffic from the OSP back to the ESInet. . . . Thus, the need for new or separate facilities for the transmission from the OSP to the ESInet is eliminated, reducing cost, complexity, and potential failure points.”).

Major IP transport facilities.

In the

NG911 Reliability FNPRM,

the Commission proposed to apply reliability requirements to major transport facilities providers, defined as providers offering OC3 or higher capacity (155 Mbps), and to exclude smaller transport providers with capacity below this threshold. Some commenters argue that the proposed threshold for major IP transport is too low and could be costly when applied to rural areas, or even impossible to achieve in some cases.

187

We agree with these commenters that compliance with the reliability requirements imposes some costs, and that IP transport providers serving small and rural areas may face a greater cost burden. To address these concerns, we are raising the threshold for IP major transport to focus on the largest transport facilities that pose the greatest risk of causing multistate or multi-OSP 911 outages.

188

187

Lumen Comments at 4-5; Verizon Comments at 13-14; Verizon Reply at 4 & n.12.

188

NG911 Reliability FNPRM,

40 FCC Rcd at 2689, para. 53 (asking if the OC capacity threshold should be updated with a Gbps equivalent).

We define major IP transport facilities as dedicated SIP voice and text transport facilities meeting or exceeding Optical Carrier 48 (OC48)/2.5 Gbps in capacity that collect and/or transmit IP 911 traffic mixed with non-911 traffic from two or more OSPs, and transport it over interstate dedicated SIP routes, for ultimate delivery to an NG911 Delivery Point or equivalent ESInet point of interconnection. The threshold for major IP transport facilities includes any 2.5 Gbps equivalent or higher capacity transport facilities, whether

using OC, ethernet, or another technology. We clarify that this CSP definition of major IP transport capacity does not alter any existing Network Outage Reporting System obligations under part 4 of our rules.

189

See

47 CFR 4.7(d) (defining OC3 user minutes for determining NORS outage reporting threshold criteria). Under the NORS reporting requirements, cable communications providers, IXC or LEC tandem facilities providers, satellite operators, SS7 providers, wireless service providers, and wireline communications providers must submit electronically a notification to the Commission when the outage threshold criteria pertaining to each service have been met.

See

47 CFR 4.9(a)-(g). While an entity defined as a CSP may be required to report in NORS, it would be by virtue of its status as one of the entities regulated under § 4.9(a)-(g) and not because of its status as a CSP.

Consistent with the

NG911 Reliability FNPRM

proposals and goals, we differentiate between major IP transport providers, which we designate as CSPs, and general internet transit providers, which we do not designate as CSPs.

190

Major IP transport providers are those network operators that meet the OC48/2.5 Gbps threshold and offer dedicated SIP service that includes voice and/or text to two or more OSPs for 911 traffic. General internet transit includes public internet, VPN, or cloud-based service products and their underlying transport networks that provide IP connectivity but do not offer dedicated voice or text service.

191

For the reasons NENA explains, we anticipate that OSPs, CSP major IP transport providers, and other CSPs may use general internet paths as diverse pathways for transport of 911 traffic to ensure 911 reliability.

192

We seek to encourage and not to foreclose use of these available paths to support diversity and redundancy in the NG911 ecosystem.

193

Therefore, while we apply our 911 reliability framework to CSPs even if they choose to use general internet transit paths for redundancy or downstream transmission, we do not classify the internet transit providers or their underlying transport networks as CSPs, and we exclude them from the CSP regulatory framework. Such regulation is unnecessary and would be highly burdensome; in addition, no commenter has requested regulation of internet paths.

190

NG911 Reliability FNPRM,

40 FCC Rcd at 2688, para. 49 (“[W]e propose to limit the definition Major Transport Facilities to providers that operate dedicated SIP transport facilities . . . .”);

id.

at 2695, para. 66 (“We note that today's proposed rules are not meant to capture every single transit provider of general internet traffic, but rather dedicated transport providers that carry

substantial

911 traffic.”) (italics added);

id.

at 2729, Appendix A, Proposed Rule 9.19(a)(12) (defining “Major Transport” as “Dedicated SIP transport facilities”).

191

NENA Comments at 10-11.

192

Id.

193

Id.

We provide relief to some OSPs offering IP transport facilities that otherwise meet the OC48/2.5 Gbps threshold by further limiting the definition of major IP transport facilities to those transporting the 911 traffic of two or more OSPs. To account for instances in which a major IP transport facility provides transport to another OSP on an incidental basis, we exclude 911 traffic originated on the provider's network in the determination of whether a particular facility is transporting the 911 traffic of two or more OSPs. Accordingly, an OSP that transports its own voice and text 911 traffic, plus the 911 traffic of one other OSP, is not a provider of major IP transport facilities, regardless of whether it meets the increased threshold definition. We agree with NCTA that this change helps us achieve our goals of balanced regulation by requiring reliability best practices only for network facilities carrying substantial risk of multi-OSP outages.

194

This change also avoids imposing undue burdens on OSPs that provide limited and incidental third-party transport services.

195

To harmonize our 911 reliability framework and ensure consistency, we apply these same changes to the definition of IP 911 traffic aggregation facilities, which must carry 911 traffic for two or more OSPs, not counting any 911 traffic originated on the facility provider's own network.

194

NCTA May 20, 2026

Ex Parte

at 3.

195

Id.

We further exclude any dedicated SIP transport that is exclusively used to carry data traffic with no dedicated OSP voice or text to avoid capturing non-911 transport, as requested by NCTA and Intrado.

196

We believe these exclusions narrow the proposal sufficiently to avoid unnecessary burdens.

197

Accordingly, our definition of major IP transport facilities includes providers that comingle 911 traffic transport from two or more OSPs with general OSP voice traffic. We believe this revised definition reasonably ensures reliability of major NG911 traffic conduits to ESInets without overburdening industry. Our priority is the reliability of the largest interstate transport routes and facilities carrying 911 traffic from two or more OSPs, the failure of which poses the greatest risk to the transmission of 911 traffic for the public. Today's modifications accomplish this goal, while also creating regulatory certainty for business and avoiding undue burdens and costs for entities that provide IP transport but carry little or no dedicated 911 traffic.

196

NCTA Reply at 7 (quoting Intrado Comments at 18).

197

NCTA May 4, 2026

Ex Parte

at 2.

Our implementation of these exclusions, and raising of the IP transport capacity threshold, mitigate concerns raised by commenters that some IP transport providers may be unable to ascertain whether they carry 911 traffic.

198

Because only large providers that serve two or more OSPs fall under the major IP transport definition, we believe it is reasonable to expect them to inquire as to whether or infer that they carry 911 traffic. Under the Commission's robocall mitigation and know-your-customer rules, voice service providers have an affirmative responsibility to know their upstream providers and the nature of the traffic they are receiving from those providers to ensure their networks or services are not being used to transmit illegal calls.

199

The Commission's call blocking rules also require or permit providers to block calls under certain conditions, but place robust restrictions on blocking of 911 and other emergency calls.

200

At most, the downstream providers of high-capacity, interstate long-haul dedicated

SIP transport must ask OSPs or upstream providers whether their traffic includes 911 traffic, or if the OSP has segregated out its 911 traffic prior to handoff. To the extent major IP transport providers are not already inquiring about this from their upstream customers, we believe it is a reasonable measure to reduce the risk of large-scale 911 outages.

198

Verizon Comments at 7-8; Lumen Comments at 6-8.

199

See

47 CFR 64.1200(n)(5) (requiring that all voice service providers “[t]ake reasonable and effective steps to ensure that any originating provider or intermediate provider, foreign or domestic, from which it directly receives traffic is not using the provider to carry or process a high volume of illegal traffic onto the U.S. network”);

see also

Sophia Fox-Sowell,

North Carolina officials say next-generation 911 network withstood Hurricane Helene,

(Oct. 21, 2024),

https://statescoop.com/north-carolina-next-generation-911-hurricane-helene/.

223

Verizon Comments at 15 (stating that the Commission articulated reasonable alternative measures for legacy 911 in 2013 and similar clarity is needed for NG911);

911 Reliability Order,

28 FCC Rcd at 17510, paras. 98-99 (reasonable alternative measures could include spreading out equipment and trunks within a single building to “provide a modest level of diversity” and that “may be considered reasonably sufficient to mitigate the risk of insufficient physical diversity, depending on the facts”).

224

911 Reliability Order,

28 FCC Rcd at 17497, para. 62 (“Because the decision whether to order diverse access through multiple selective routers, or the functional equivalent, typically rests with the PSAP and is driven by budgetary and other local concerns, we agree that service providers should not be inflexibly required to install costly, redundant circuits where a PSAP has not ordered that level of service.”).

Public safety commenters strongly support the Commission's overall approach, stating, for example, that it “fully aligns with sound public policy by giving the Commission reasonable oversight of NG911 network reliability without micromanaging the construction and operation of the various aspects of the network.”

225

We disagree with those commenters that suggest replacing our 911 reliability framework with a requirement for CSPs to stay compliant with reliability standards developed by external standards bodies, such as NENA and ATIS.

226

Commenters advocating this view do not agree on which external standards the Commission should endorse, nor do they explain why those standards are preferable to the Commission's reliability framework, which draws heavily from cumulative recommendations made by CSRIC. We believe CSRIC is an ideal source of guidance because it is dedicated to NG911 reliability and other public safety communications issues, and its membership includes expert representatives from major service providers, industry trade groups, manufacturers, government agencies, public safety interest groups, and industry- and public safety-led standards bodies.

227

CSRIC's work is collaborative and consensus-driven, and so the best practices it recommends generally involve aspects of service that most providers are already adopting consistently.

228

Using the Commission's rulemaking process to periodically update reliability standards ensures transparency and affords CSPs the opportunity to help inform our actions. The Commission will continue to monitor the root causes of 911 outages, the reliability practices that CSPs report that they have implemented, and CSRIC's future recommendations regarding 911 reliability best practices, and will consider updating the 911 reliability framework as necessary.

225

Texas 9-1-1 Entities Comments at 3;

See also

NENA, NENA Knowledge Base,

https://kb.nena.org/wiki/SIP

(last visited May 19, 2026) (“Single Point of Failure is a failure of a hardware or software component or sub-system which causes a system to fail.”).

232

See, e.g.,

911 Reliability Order,

28 FCC Rcd at 17504, para. 83 (“Physical diversity, sometimes called route diversity, means that two circuits follow different routes separated by some physical distance so that a single failure such as a power outage, equipment failure, or cable cut will not result in both circuits failing.”); 47 CFR 9.19(a)(8) (defining physical diversity); NENA Comments at 23 (“When considering physical diversity, conventional wisdom within telecom has always been `two of everything at each of two sites.' ”).

233

47 CFR 9.19(c)(1)(i).

In contrast, NG911 and IP networks create physical diversity primarily by being capable of automatically and dynamically rerouting 911 traffic throughout a web of alternate paths.

234

The IP routers or nodes in the network decide where to forward packetized call data based on internal routing tables, connected by IP paths and node links.

235

If a router or node detects a failure in the primary path, it automatically and instantly reroutes the call along a secondary path. This capability means that, “[i]f there is any path between two points in an IP network, then the network will automatically find and use that path.”

236

Because NG911 networks can deliver traffic along numerous possible routes, physical separation of individual IP paths may not be essential in all locations to achieve reasonable network reliability.

237

Instead, NG911 networks create resiliency by maintaining redundant routers or nodes and node links that automatically failover to redundant elements and paths. These networks typically space redundant elements widely in different geographic locations and different physical facilities to protect them from failing due to the same external event.

238

These networks practice load balancing by dynamically distributing network traffic across multiple available databases or call processing facilities so that the network maintains continuity of service to prevent redundant elements from becoming overwhelmed even when traffic surges.

239

The physical diversity benchmark we adopt today is broadly worded to reflect these prevailing approaches while remaining technology-neutral so as to provide legacy and NG911 CSPs a high degree of flexibility when choosing their implementation strategies.

234

Intrado Comments at 20 (“NG911 routing . . . presents a spiderweb-like, nearly infinite matrix of physical and virtual connections over which disassembled packets traverse.”).

235

NG911 Reliability FNPRM,

40 FCC Rcd at 2693, para. 62.

236

NENA Comments at 10. An IP network's ability to automatically detect failures and reroute traffic is sometimes referred to as “self-healing.”

See, e.g.,

USTelecom Comments at 7.

237

USTelecom Comments at 7-8; NENA Comments at 10.

238

See, e.g.,

BRETSA Reply at 3 (“With geographically diverse network paths, loss of service on a single network path due to an equipment failure or the severing of a fiber line by a backhoe, for example, will not disrupt service. In the event one of two diverse paths is disrupted, all traffic will flow across the second path.

Network path diversity significantly reduces the likelihood of an outage.”

) (emphasis in original); USTelecom Comments at 7-8.

239

2014 Reliability NPRM,

29 FCC Rcd at 14227, para. 45 & n.107;

NG911 Reliability FNPRM,

40 FCC Rcd at 2693, para. 62.

The specific capabilities we incorporate into the physical diversity benchmark—automatic rerouting and failover across geographically-distributed routing facilities, transport nodes, and node links, supported by load balancing—are well-recognized strategies that are synonymous with sound IP architecture. In its 2013

Derecho Report,

the Bureau found that NG911 networks would likely have mitigated the 911 outages caused by the 2012 derecho due to the resiliency and redundancy these networks provide using IP routers with automatic fail-over; automatic rerouting; and diverse IP paths.

240

When CSRIC updated its best practice recommendations for NG911 in 2019, it assumed that the design of transitional and end-state ESInets would ensure “all network elements and transport facilities are deployed with redundancy.”

241

CSRIC explained that “[t]ypically, network redundancy is achieved through the addition of alternate network paths, which are implemented through redundant standby network elements, routers and switches. When the primary path is unavailable, the alternate path

can be instantly deployed to ensure continuity of network services.”

242

240

Derecho Report

at 44.