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

> Briefs, arguments, decisions, and more.

URL: https://www.frixlaw.com/law-library/documents/fr%3A2026-13998

## Record

- **Collection:** Federal Register
- **Document type:** Rule
- **Published:** July 10, 2026
- **Citation:** 91 FR 42794

## 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.
1

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.

1
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.
2

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

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.
4

2

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
).

3

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
).

4

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).
5

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.
6

5
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).

6
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.
7

7
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.
8

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.
9

8
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.

9

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.
10

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.
11

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.
12

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.”
13

10

See 911 Reliability Order.

11

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.

12

911 Reliability Order,
28 FCC Rcd at 17488-89, para. 36.

13

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.
14

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

14

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.
15

15
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.
16

16

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.
17

17

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.
18

18

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.
19

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.”
20

19

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
).

20

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.
21

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.
22

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

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.
24

The Commission deferred consideration of reliability, interoperability, and accessibility
25

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

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.
27

21

See generally Next Generation 911 (NG911) Valid Requests,
PS Docket No. 25-143.

22

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.

23
47 CFR 9.28.

24

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

25

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

26

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).

27

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.
28

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.
29

28

NG911 Reliability FNPRM,
40 FCC Rcd at 2669, para. 1.

29

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.
30

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.
31

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

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.
33

The Commission also proposed in the
NG911 Reliability FNPRM
a new requirement for ESInets to be interoperable.
34

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

30

Id.
at 2691-96, paras. 59-70.

31

Id.
at 2693-95, paras. 62-66.

32

Id.
at 2695-96, paras. 67-68.

33

Id.
at 2696, paras. 69-70.

34
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.

35

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.
36

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.

36
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.
37

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.
38

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.
39

37

Derecho Report
at 12.

38

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.

39

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.
40

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.”
41

40

NG911 Transition Order,
39 FCC Rcd at 8152, para. 28.

41
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.
42

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.
43

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
44

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

42

NG911 Transition Order,
39 FCC Rcd at 8171, para. 71.

43

NG911 Reliability FNPRM,
40 FCC Rcd at 2687, para. 48.

44
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.

45

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.
46

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).
47

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.
48

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).
49

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).
50

46

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.

47
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.

48

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”).

49
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.

50

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.
51

51

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.
52

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).
53

52
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
).

53

NENA i3 Standard
at 3.

In this
Order,
we modernize our 911 reliability framework for NG911 networks.
54

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.

54
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.
55

55
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.”
56

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.
57

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.
58

56

Derecho Report
at 44.

57
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.

58

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.
59

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.
60

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

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

and work with stakeholders to share monitoring information.
63

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.
64

59
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
).

60

Id.
at 7, 11-14.

61

Id.

62

Id.
at 69-70.

63

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.

64

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.
65

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

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.
67

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.”
68

65
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
).

66

Id.
at 5.

67

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.”).

68

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.
69

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.

69

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 NG911 Reliability FNPRM
at 2676-77, paras. 16-18.

Alongside the broader IP transition, the emergence of NG911 has given rise to new classes of service providers that did not exist in legacy 911 networks but play essential roles in the NG911 ecosystem's call path. These new provider classes include third-party transport providers retained by OSPs to carry 911 traffic over high-capacity fiber networks; specialized entities that aggregate 911-only traffic for transport and delivery; and providers of IP-based signaling translation functions.
70

NG911 network providers frequently engage third-party operators to manage servers and other critical facilities supporting 911 call routing and other key functions across multiple states and jurisdictions.
71

Some of these new providers are not covered by the Commission's previous 911 reliability rules, despite their essential and expanding role in maintaining the continuity of 911 service.
72

Other NG911 capabilities fall within the category of “functional equivalents” under the prior rules, yet, as we detail below, the record demonstrates that many new providers of these capabilities have not recognized that the prior rules apply to them. Moreover, the prior reliability rules are inherently static, such that tethering NG911 “functional equivalents” to the legacy environment does not allow the rules to scale effectively to accommodate the continued evolution of IP-based NG911 call-originating technologies and exchanges of information. Without clarifying the 911 reliability framework to expressly cover all critical NG911 providers and functions, the Commission cannot effectively address or mitigate the risks of significant outages on IP-based and NG911 networks.
73

70

See
Letter from Frank Pozniak, Executive Director, Massachusetts State 911 Department, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 21-479, 13-75, at 2-3 (filed Jun. 18, 2026) (
Massachusetts Ex Parte
) (endorsing inclusion of third-party 911 service providers as CSPs based on Massachusetts' experience that most OSPs are heavily reliant on CSPs in NG911).

71
FCC Public Safety and Homeland Security Bureau, April 2014 Multistate 911 Outage: Cause and Impact, PS Docket No. 14-72 at 1-2 (2014),
https://www.fcc.gov/document/april-2014-multistate-911-outage-report.

72
NENA Comments at 1-2; COPUC Comments at 2. One of the 911 aggregation service providers has “deployments of NG911 call aggregation service in states and counties across the country” and claims to serve over 30% of the U.S. population. Sinch,
Inteliquent exceeds 30% of population with recent next generation call aggregation deployments, https://sinch.com/news/ng911-call-aggregator-inteliquent-leads-us-public-safety/?UTM-Inteliquent
(last visited May 19, 2026) (Sinch acquired Inteliquent in 2021.); Sinch,
Bring public safety to the digital age with NG911, https://sinch.com/voice/next-generation-911/
(last visited May 19, 2026).

73

See
COPUC Comments at 4; NENA Comments at 1-3; National Association of State 911 Administrators (NASNA) Comments at 1-2.
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.
74

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.
75

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.
76

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.
77

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

74

See NG911 Reliability FNPRM,
40 FCC Rcd at 2676-77, paras. 16-17.

75
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/.

76
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.

77

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

78

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.
79

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.

79

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, e.g.,
StateScoop,
North Carolina officials say next-generation 911 network withstood Hurricane Helene
(October 21, 2024),
https://statescoop.com/north-carolina-next-generation-911-hurricane-helene/
(“Had the old technology and analog network still been in place, the infrastructure would have been destroyed and we would not have had the capability to route calls to other PSAPs and connect people to critical emergency services . . . . Thanks to the resiliency and redundancy of this network, we had no reports of 911 calls not being delivered.”).

The record also underscores the importance of updating our 911 reliability framework now, while the NG911 transition is still in a relatively formative phase, rather than waiting for further NG911 deployments or full completion of the transition.
80

We agree with 911 Authorities, national public safety organizations, and some OSPs that an orderly transition to the NG911 ecosystem requires prompt updating of the definition of CSPs and the 911 reliability standards.
81

We disagree with industry commenters who argue that such action is premature.
82

We conclude that waiting until the transition is completed to see what problems remain to be addressed ignores demonstrated risks to 911 reliability and needlessly delays implementation of available solutions.
83

The stakeholder community has already developed detailed and well-established technical architecture and commonly accepted standards for NG911 systems,
84

and the reliability framework we adopt today is based on well-documented best practices for IP networks that can readily be implemented by CSPs as part of their network build-outs.

80
Association of Public-Safety Communications Officials, International (APCO) Reply at 14-15; COPUC Comments at 1-2.

81

See, e.g.,
NYSPSC Comments at 1-2; Texas 9-1-1 Entities Comments at 2-3; COPUC Comments at 1-2; Michigan State 911 Committee Comments at 1; Colorado Council of Authorities, Inc. (CCOA) Reply at 2-3; NASNA Comments at 1; NENA Comments at 1; APCO Reply at 14-15; Palmetto Broadband Coalition Reply at 3; Home Telephone ILEC, LLC (Home Telephone) Comments at 11.
See also
Public Knowledge Comments at 4.

82
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.

83
Lumen Comments at 2; iCERT Reply at 2.

84

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),
85

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.
86

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.
87

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.

85

Seventeenth Annual 911 Fee Report
at 3.

86

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.

87
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.
88

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.
89

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

89

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.
90

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.
91

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.

90

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.”).

91
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.
92

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

92

See
Appendix B.

93

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.
94

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.
95

This definition uses informative, non-normative examples,
96

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.”
97

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

94

See, e.g.,

NG911 Transition Order,
39 FCC Rcd at 8159-60, paras. 39-40.

95
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)).

96
ATIS Reply at 3.

97
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.
98

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.
99

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

98
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)).

99
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 id.
at 17504, 17510, paras. 83, 98.

Applicability to OSPs.
The Commission requires OSPs—by which we generally mean entities that offer end users the ability to originate 911 calls—to transmit such calls with appropriate location information to a PSAP, to a designated statewide default answering point, or to an appropriate local emergency authority.
101

As part of the NG911 transition framework, the Commission also requires OSPs to deliver all 911 traffic to NG911 Delivery Points following the receipt of a valid request from a 911 Authority for Phase 1 or 2 service.
102

This
Order
does not alter the scope or applicability of such OSP requirements, nor does it apply 911 CSP reliability requirements to OSPs. However, as discussed below, we revise the 911 reliability framework to address third-party transport and aggregation of 911 traffic from OSPs to NG911 delivery points.

101
We call the relevant provisions at sections 9.4, 9.8, 9.10, 9.11, 9.14, and 9.18 the “911 transmission rules” in this
Order. See
47 CFR 9.4 (requiring telecommunications providers to transmit all 911 calls to a PSAP, designated statewide default answering point, or appropriate local emergency authority; rule does not address transmission of location information); 47 CFR 9.8 (requiring fixed telephony service providers to transmit caller location information with 911 calls); 47 CFR 9.10(b) (requiring CMRS providers to transmit all wireless 911 calls and provide certain location information to a PSAP, designated statewide default answering point, or appropriate local emergency authority); 47 CFR 9.11(b)(2)(ii) (requiring interconnected VoIP providers to transmit all 911 calls and provide certain location information to a PSAP, designated statewide default answering point, or appropriate local emergency authority); 47 CFR 9.14(d)(iii) (requiring VRS and IP relay providers to transmit all 911 calls, certain location information, and other information to a PSAP, designated statewide default answering point, or appropriate local emergency authority); 47 CFR 9.14(e) (requiring IP CTS providers to transmit all 911 calls, certain location information, and other information to a PSAP, designated statewide default answering point, or appropriate local emergency authority); 47 CFR 9.18(a) (requiring providers of Mobile-Satellite Service to provide Emergency Call Center service, where personnel must “determine the emergency caller's phone number and location and then transfer or otherwise redirect the call to an appropriate public safety answering point”).

102

See
47 CFR 9.28 (defining OSPs); 47 CFR 9.29(a), (b) (NG911 delivery rules).

The 911 transmission rules already in place are distinct from the measures to support 911 reliability that we adopt today. As an initial matter, the 911 transmission rules and the 911 reliability framework apply to two different classes of providers. The 911 transmission rules apply to telecommunications carriers and certain other providers that originate 911 traffic,
i.e.,
OSPs. CSPs, on the other hand, provide 911, E911, or NG911 capabilities that do not include call origination.
103

Originators of 911 calls have been explicitly excluded from the 911 reliability framework where another service provider, typically a CSP, transmits the calls to a PSAP.
104

We maintain this exemption while updating it to reflect the reality that, in NG911 networks, 911 traffic is delivered to 911 Authorities at their ESInet POI.
105

However, to fulfill their transmission obligations under our rules, OSPs frequently contract with third parties to pick up 911 traffic from their networks and transport it to 911 Authorities' 911 networks.
106

Under the framework adopted in this
Order,
some of these third parties—specifically major IP transport providers and IP 911 traffic aggregators—will now be CSPs.

103
47 CFR 9.19(a)(4); iCERT Comments at 12 (“While OSPs are responsible for originating 911 calls or texts, they do not perform the core NG911 functions that the Commission has historically tied to CSP obligations, such as the routing, delivery, or location processing of 911 calls and associated data to the appropriate PSAP.”).

104
47 CFR 9.19(a)(4)(ii)(b).

105
Appendix A (§ 9.19(a)(4)(ii)(B)); Letter from Steve Morris, Vice President and Deputy General Counsel, NCTA, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 21-479, 13-75, at 2 (filed May 4, 2026) (encouraging the Commission “to clarify that OSPs that contract with third parties for regulated functions are not themselves covered by the new rules.”).

106

NG911 Reliability FNPRM,
40 FCC Rcd at 2677, para. 17. OSPs may, as an alternative, directly connect to 911 networks.
Id.

Some commenters contend that extending the scope of the CSP requirements to entities that contract with OSPs creates a substantial new regulatory burden without a corresponding benefit to 911 systems.
107

We disagree. It is reasonable to assume that OSPs already consider, when selecting transport and aggregation vendors, whether those vendors have implemented reasonable reliability measures in order to support their 911 transmission obligations.
108

Today, we add an additional level of assurance for OSPs if they select an entity providing major IP transport or IP 911 traffic aggregation services, because our new framework now requires these entities to implement basic resiliency and reliability measures. Since these new types of CSPs consolidate enough 911 traffic that an outage affecting them would severely impact the availability of 911 services to the public, ensuring that these entities implement basic reliability measures is a reasonable step. Additionally, extending reliability requirements to these new types of CSPs supports the ability of OSPs to fulfill their 911 transmission obligations.

107
Lumen Reply at 2 & n.5; USTelecom Comments at 6 (“[B]ecause [OSPs] are further away from PSAPs than entities currently falling within the definition of a CSP, they have less direct control over public safety outcomes[.]”).

108

Amendments to Part 4 of the Commission's Rules Concerning Disruptions to Communications,
PS Docket No. 15-80, Order on Reconsideration, 39 FCC Rcd 7362, 7368, para. 14 (2024) (
911 Outage Notification Recon. Order
) (noting “long-held Commission precedent that licensees and other regulatees are responsible for the acts and omissions of their contractors, and that it does not serve the public interest to create a means for OSPs to `contract away' their obligations”); 47 U.S.C. 217 (“[T]he act, omission, or failure of any officer, agent, or other person acting for or employed by any common carrier or user, acting within the scope of his employment, shall in every case be also deemed to be the act, omission, or failure of such carrier or user as well as that of the person.”);
Lumen Technologies,
Notice of Apparent Liability for Forfeiture, 38 FCC Rcd 9750, 9752, para. 8 (2023).

For these reasons, we disagree with comments contending that our amendments to section 9.19 will duplicate obligations that OSPs already have under the 911 transmission rules and that the 911 transmission rules are sufficient to ensure reliability on the OSP side of the NG911 call path.
109

In reality, our updated reliability framework empowers the Commission to apply its 911 oversight authority preventatively to facilities instead of after an outage when transmission rule violations have already occurred. Moreover, as discussed in greater detail below, we have addressed these commenters' concerns by adjusting the proposed definitions of the newly-covered CSP facilities so that they apply exclusively to high-volume, third-party services provided to two or more OSPs and not to transmission capabilities that OSPs provide via their own networks. Far from imposing duplicative burdens on OSPs, our amendments to section 9.19 provide greater certainty for OSPs that contract with third-party CSPs to provide 911 transport or delivery services. OSPs will now be able to easily assess the reliability of these service providers based on their implementation of the Commission's requirement to provide reasonably reliable 911 services.

109

See
Verizon Comments at 9; iCERT Reply at 5 (urging the Commission not to impose overlapping, duplicative requirements between OSPs and CSPs); CTIA Comments at 2-4; T-Mobile Comments at 2-4.

NG911 cost allocation.
In legacy 911 networks, ILECs operate most or all of the network infrastructure used to route and deliver 911 calls to PSAPs under tariff or contractual agreement with

PSAPs and emergency authorities.
110

When the Commission adopted the 2013 reliability rules, these tariff and contractual arrangements were well-established, so the Commission did not address cost issues at that time. Instead, the Commission focused on enhancing the reliability of the 911 capabilities being provided through these relationships.
111

When the Commission established its NG911 Transition framework in 2024, it found it necessary to expressly allocate NG911 costs between OSPs and 911 Authorities, because uncertainty and disagreements over the basic terms on which OSPs would begin to provide NG911 service were delaying the nationwide transition to NG911.
112

Under the NG911 Transition framework, OSPs are presumptively responsible for the costs of translating 911 traffic into SIP format and the costs of delivering 911 traffic and associated routing and location information to the NG911 Delivery Points designated by 911 Authorities.
113

In other words, OSPs are “responsible for the costs of complying with their own 911 service obligations,”
114

while 911 Authorities bear the costs incurred beyond NG911 Delivery points to process and transmit 911 traffic to the appropriate PSAP.
115

OSPs and 911 Authorities may, however, modify these default cost allocations by mutual agreement.
116

110

2014 911 Reliability NPRM,
29 FCC Rcd at 14214, para. 16.

111

See generally
47 CFR 9.19(a)(4) (defining CSPs as entities that directly serve PSAPs).

112

NG911 Transition Order,
39 FCC Rcd at 8197, para. 134.

113

Id.
at 8196, para. 132.

114

Id.
at 8202-03, para. 146 (noting that making OSPs responsible for the cost of meeting their service obligations “is analogous to the cost requirement the Commission adopted over two decades ago during the implementation of wireless E911”) (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, 14789, 14792-93, paras. 1, 8-10 (2002)).

115

NG911 Transition Order,
39 FCC Rcd at 8196, para. 132.

116

Id.
at 8180, para. 87; 47 CFR 9.34.

As the national transition to IP-based telecommunications has advanced and NG911 network architectures have evolved, the array of entities providing 911 capabilities has become more complex. The contractual arrangements through which NG911 service is provided have become more complex as well. For example, we identify today several new classes of IP-based CSPs that have become essential to the routing and delivery of 911 traffic in the NG911 environment. Among them are CSPs that provide processing and transport of 911 traffic from OSPs' networks to NG911 Delivery Points or ESInet POIs. These entities often have contractual relationships with OSPs rather than direct relationships with PSAPs or 911 Authorities. Several commenters question which entities should bear the costs of newly designated CSP services in the NG911 environment.
117

We therefore clarify that nothing in this
Order
changes the default cost allocation the Commission adopted in the
NG911 Transition Order.
OSPs remain presumptively responsible for costs of delivery to the NG911 Delivery Point or other ESInet POI, regardless of whether they deliver traffic entirely over their own networks or hire third-party CSPs to provide intermediate transport and/or aggregation.
118

911 Authorities remain presumptively responsible for completing 911 calls after they are handed off at the NG911 Delivery Point and therefore bear the costs of ESInets, NGCS, and other NG911-related CSP services beyond that point.
119

We emphasize, however, that the framework's division of cost responsibilities is not prescriptive, and 911 Authorities and OSPs may agree to alternative cost structures.
120

117

See, e.g.,
NTCA and the RLEC Parties Comments at 4-5 (“[T]he Commission should reaffirm the carriers' relative responsibilities for the costs they will incur under the new NG911 regime . . . and specifically clarify that state 911 [A]uthorities and NG911 [CSPs] cannot pass on to OSPs any compliance costs the former assume associated with the adoption of the proposed reliability framework.”); USTelecom Reply at 4-6 (requesting clear distinctions between OSPs and CSPs to avoid unfair cost burdens); Intrado Comments at 16-17.

118

NG911 Transition Order,
39 FCC Rcd at 8196, 8202-03, paras. 132, 146.

119

Id.
at 8196, para. 132.

120

Id.
at 8180, para. 87; 47 CFR 9.34.

NG911 Functional Equivalents

As proposed in the
NG911 Reliability FNPRM,
we define NG911 location and routing capabilities that are part of NGCS as covered 911 services because they are the functional equivalents of legacy selective routing and ANI/ALI services that were identified as covered services under the original CSP definition.
121

The Commission adopted the “functional equivalent” language in 2013 to ensure that the CSP definition would be flexible enough to capture emerging NG911 entities while avoiding overbroad regulation.
122

While this approach has been effective to a degree, the recent acceleration of the NG911 transition requires us to provide additional clarity to aid in compliance with 911 reliability framework. NENA points out that some companies operating critical NG911 facilities have argued the “functional equivalent” language in the 2013 rules does not include their facilities, and so no specific reliability measures are required.
123

CCOA also cites a service provider that has argued the original circuit diversity rules only apply to circuits from routing facilities in central offices and not to critical circuits elsewhere in the 911 call path.
124

121
47 CFR 9.19(a)(4)(i)(A) (CSPs are entities that provide 911 call routing or location information “or the functional equivalent of those capabilities.”).

122

911 Reliability Order,
28 FCC Rcd at 17489, para. 37.

123
NENA Comments at 2.

124

NG911 Reliability FNPRM,
40 FCC Rcd at 2684, para. 36.

To address these concerns, we reference specific NGCS location and routing functions to make the updated 911 reliability framework clearly applicable to critical NGCS services and facilities.
125

We define NGCS location facilities as functional elements connected to an ESInet that enable the real-time provision of 911 caller location information to PSAPs, including but not limited to the LVF, the ECRF, and successor technologies. We define NGCS routing facilities as functional elements connected to an ESInet that enable the real-time routing, delivery, or transfer of 911 traffic to PSAPs along with callback information and other associated data, including but not limited to the ESRP, the PRF, and successor technologies.
126

We emphasize that these listed NGCS elements are merely examples of transitional and future technologies performing routing and location functions, and are not intended to be exclusive.

125
Appendix A (§ 9.19(a)(4)(i)(C), 9.19(a)(14), (15)).

126
COPUC Comments at 3; Michigan State 911 Committee Comments at 1.
But see
NENA Comments at 5 (stating the PRF should be integrated with the ESRP and need not be listed). We include the PRF in light of the comment record reflecting variations in how NGCS systems are being deployed.
Compare
NENA Comments at 4,
with
iCERT Comments at 9 (disagreeing whether the LVF requires reliability in NGCS configurations);
compare
NENA Comments at 5-6,
with
iCERT Comments at 10 (disagreeing whether the MSAG Conversion Service, GeoCode Service, and Mapping Data Service functional elements require reliability in NGCS configurations).

We provide these clarifications because NG911 systems process routing and location information differently than legacy 911 systems. For example, the caller location function in NG911 does not rely on legacy ANI/ALI databases or MSAGs
127

to perform live-call location; instead, the LIS and LVF supply location data to other 911

functional elements through periodic updates typically.
128

As iCERT explains, while the LIS is functionally equivalent to legacy ALI/ANI databases and the LVF is functionally equivalent to the MSAG, the LVF may perform live-call critical functions in NG911 of validating location addresses as a 911 call is made.
129

As such, the prior rule does not perfectly correlate critical NG911 location and routing elements to their “functionally equivalent” legacy 911 service in every instance.
130

127
NENA,
NENA Knowledge Base, https://kb.nena.org/wiki/MSAG_(Master_Street_Address_Guide),
(last visited May 19, 2026).

128
iCERT Comments at 10; NASNA Comments at 2.

129
iCERT Comments at 10.

130
APCO Comments at 8; NENA Comments at 1.

We agree with commenters that suggest we include LVF and similar location validation functional elements as examples of covered NGCS functional elements, but only when used in live-call processing.
131

This modification addresses variation in how NGCS providers configure the LVF to interface with other functional elements.
132

If an NGCS provider is using its location validation facilities for real-time location queries, those facilities are subject to our 911 reliability framework. If a NGCS provider has chosen to arrange its system so that its location validation facilities only periodically send information to a LIS or other NGCS element, then the LVF is being used more like the GIS, and thus there is no need to include it as a covered 911 facility.

131

See, e.g.,
NASNA Comments at 2 (urging the exclusion of GIS as an NGCS Location Facility due to its “distance from the real time call flow” and acknowledging that an LVF can replicate legacy ALI/ANI real time location functionality); iCERT Comments at 9 (LVF “utilize[s] GIS information and data that are critical to the real-time routing and delivery of 911 calls within an NG911 environment”); Intrado Comments at 15 (Capabilities should not be covered if they are “outside the call flow and [are] not directly related to real-time call routing or transmission of caller location information.”).

132
NENA Comments at 4; iCERT Comments at 9.

In addition to the LVF, we include the ECRF as an example of covered live-call NGCS location facilities, and the ESRP and the PRF as examples of covered live-call NGCS routing facilities. While we provide these specific examples, we also retain the “functional equivalent” language from the prior rule to capture both transitional NG911 elements and future technologies that may be developed to perform NGCS functions. As NASNA notes, including transitional routing and location functional elements as covered 911 facilities is important to ensure transitional 911 systems remain reliable.
133

For example, IP selective routers and IP ALI databases are examples of transitional architecture that may perform basic IP routing and location functions at an ESInet before a 911 Authority has built and deployed full NGCS routing and location capabilities.
134

133
NASNA Comments at 1 (noting the importance of protecting reliability during the NG911 transition).

134
NENA NG9-1-1 Transition Plan, Considerations Information Document, at 56 (Nov. 20, 2013)
https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/standards1/NENA-INF-008.2_NG9-1-1Transi.pdf
(“[A]n internet Protocol Selective Router (IPSR) function . . . is an IP-based Selective Router that that provides E9-1-1 functionality while incorporating the ability to receive native SIP emergency calls” and deliver them to PSAPs);
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 NG911 Transition Order,
39 FCC Rcd at 8224-25, para. 191 & n.566.

137
NASNA Comments at 2; NENA Reply at 2; DATAMARK Technologies (DATAMARK) Reply at 4-5.

Direct Service to 911 Authorities.
As proposed in the
NG911 Reliability FNPRM,
we require providers of NGCS covered 911 services to comply with the 911 reliability framework when providing such services directly, by contract or tariff, to a 911 Authority, whether via owned and operated facilities or leased or contracted facilities.
138

While some commenters support extending reliability requirements for NGCS functional elements to services provided indirectly as well as directly to 911 Authorities, we are persuaded by commenters who argue that the Commission should avoid adopting overbroad regulations that could increase 911 Authorities' and PSAPs' costs.
139

We agree with NASNA that CSP obligations should fall on the NGCS “primary provider” in a jurisdiction, instead of on every NGCS subcontractor.
140

We also agree with APCO and other commenters that direct regulation of NGCS subcontractors is excessive and unnecessary, because the CSP providing direct service is best positioned to ensure reliability and because direct regulation of a CSP's third-party contractors could unnecessarily increase costs.
141

We therefore decline to follow the suggestion of NENA and other commenters asking to directly cover any NGCS routing and location service subcontractor regardless of its relationship to 911 Authorities.
142

However, as discussed in more detail below, we apply the 911 reliability framework independently to a narrow subset of critical NG911 facilities (ESInets and associated transitional gateways) that may be provided by the NGCS provider or its subcontractors.

138

NG911 Reliability FNPRM,
40 FCC Rcd at 2684-85, paras. 36, 39.

139
City of Coconut Creek, FL July 21, 2025 Comments at 1.

140
NASNA Comments at 2 (“The FNPRM delves into the complexities of layers within the NG911 ecosystem and contractual/sub contractual relations, and the rules need to be clear that the responsibility for the 911 jurisdiction's network reliability lies within the primary provider as defined and set forth by the 911 jurisdiction.”).

141
APCO Comments at 7; Texas 9-1-1 Entities Comments at 3; Intrado Comments at 14; T-Mobile Comments at 2; NCTA Reply at 4-5.

142
NENA Comments at 3; CCOA Comments at 2-3; Comtech Comments at 14-15.
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

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 traff

[Text truncated at 120,000 characters. The full text is on the page linked above.]

---

Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3A2026-13998. Public record. Not legal advice.