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

Federal RegisterJun 4, 2025

Ask Donna

What actually matters in this document.

Text

FEDERAL COMMUNICATIONS COMMISSION

47 CFR Parts 0 and 9

[PS Docket Nos. 21-479 and 13-75, FCC 25-21; FR ID 295635]

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

AGENCY:

Federal Communications Commission.

ACTION:

Proposed rule.

SUMMARY:

In this document, the Federal Communications Commission (the FCC or Commission) proposes rules that would help 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 safeguard the reliability of critical components and support the interoperability needed to seamlessly transfer 911 calls and data from one network to another. When the Commission first adopted 911 reliability rules in 2013, the transition to NG911 was in its very early stages. Since then, many state and local 911 Authorities have made significant progress in deploying NG911 capabilities in their jurisdictions. This Further Notice of Proposed Rulemaking (FNPRM) is the next step in fulfilling the Commission's commitment to facilitate the NG911 transition and to ensure that the transition does not inadvertently create vulnerabilities in the nation's critical public safety networks. The FNPRM proposes to update the definition of “covered 911 service provider” in the Commission's existing 911 reliability rules to ensure that the rules apply to service providers that control or operate critical pathways and components in NG911 networks. It also proposes to update the reliability standards for providers of critical NG911 functions to ensure the reliable delivery of 911 traffic to NG911 delivery points, and proposes to establish NG911 interoperability requirements for interstate transfer of 911 traffic between Emergency Services IP Networks (ESInets). In addition, the FNPRM proposes to modify the certification and oversight mechanisms in the current 911 reliability rules to improve reliability and interoperability in NG911 systems while minimizing burdens on service providers, and proposes to empower state and local 911 Authorities to obtain reliability and interoperability certifications directly from covered 911 service providers.

DATES:

Comments are due on or before July 21, 2025, and reply comments are due on or before August 18, 2025.

ADDRESSES:

Pursuant to §§ 1.415 and 1.419 of the Commission's rules, 47 CFR 1.415, 1.419, interested parties may file comments and reply comments on or before the dates indicated on the first page of this document. Comments may be filed using the Commission's Electronic Comment Filing System (ECFS). See Electronic Filing of Documents in Rulemaking Proceedings, 63 FR 24121 (1998),

https://www.govinfo.gov/content/pkg/FR-1998-05-01/pdf/98-10310.pdf.

You may submit comments, identified by PS Docket Nos. 21-479 and 13-75, by any of the following methods:

•

Electronic Filers:

Comments may be filed electronically using the internet by accessing the ECFS:

https://www.fcc.gov/ecfs.

•

Paper Filers:

Parties who choose to file by paper must file an original and one copy of each filing.

• Filings can be sent by hand or messenger delivery, by commercial courier, or by the U.S. Postal Service. All filings must be addressed to the Secretary, Federal Communications Commission.

• Hand-delivered or messenger-delivered paper filings for the Commission's Secretary are accepted between 8:00 a.m. and 4:00 p.m. by the FCC's mailing contractor at 9050 Junction Drive, Annapolis Junction, MD 20701. All hand deliveries must be held together with rubber bands or fasteners. Any envelopes and boxes must be disposed of before entering the building.

• Commercial courier deliveries (any deliveries not by the U.S. Postal Service) must be sent to 9050 Junction Drive, Annapolis Junction, MD 20701. Filings sent by U.S. Postal Service First-Class Mail, Priority Mail, and Priority Mail Express must be sent to 45 L Street NE, Washington, DC 20554.

•

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.

FOR FURTHER INFORMATION CONTACT:

Chris Fedeli,

Christopher.Fedeli@fcc.gov

or 202-418-1514, or Daniel Spurlock,

Daniel.Spurlock@fcc.gov

or 202-418-0212, Attorney-Advisors, of the Public Safety and Homeland Security Bureau, Policy and Licensing Division.

SUPPLEMENTARY INFORMATION:

This is a summary of the Commission's Further Notice of Proposed Rulemaking (FNPRM), in PS Docket Nos. 21-479 and 13-75, FCC 25-21, adopted on March 27, 2025, and released on March 28, 2025. The full text of this document is available at

https://docs.fcc.gov/public/attachments/FCC-25-21A1.pdf.

Ex Parte Presentations—Permit-But-Disclose.

The Commission will treat this proceeding as a “permit-but-disclose” proceeding in accordance with the Commission's

ex parte

rules. Persons making

ex parte

presentations must file a copy of any written presentation or a memorandum summarizing any oral presentation within two business days after the presentation (unless a different deadline applicable to the Sunshine period applies). Persons making oral

ex parte

presentations are reminded that memoranda summarizing the presentation must (1) list all persons attending or otherwise participating in the meeting at which the

ex parte

presentation was made, and (2) summarize all data presented and arguments made during the presentation. If the presentation consisted in whole or in part of the presentation of data or arguments already reflected in the presenter's written comments, memoranda, or other filings in the proceeding, the presenter may provide citations to such data or arguments in his or her prior comments, memoranda, or other filings (specifying the relevant page and/or paragraph numbers where such data or arguments can be found) in lieu of summarizing them in the memorandum. Documents shown or given to Commission staff during

ex parte

meetings are deemed to be written

ex parte

presentations and must be filed consistent with rule 1.1206(b). In proceedings governed by rule 1.49(f) or for which the Commission has made available a method of electronic filing, written

ex parte

presentations and memoranda summarizing oral

ex parte

presentations, and all attachments thereto, must be filed through the electronic comment filing system available for that proceeding, and must be filed in their native format (

e.g.,

.doc, .xml, .ppt, searchable .pdf). Participants in this proceeding should familiarize themselves with the Commission's

ex parte

rules.

Providing Accountability Through Transparency Act.

Consistent with the Providing Accountability Through Transparency Act, Public Law 118-9, a summary of this FNPRM will be available on

https://www.fcc.gov/proposed-rulemakings.

Synopsis

Introduction

In this Further Notice of Proposed Rulemaking (FNPRM), we propose to update existing Commission rules to ensure the resiliency, reliability, interoperability, and accessibility of Next Generation 911 (NG911) networks. With the transition to NG911, dedicated 911 networks are evolving from Time Division Multiplexing (TDM)-based architectures to Internet Protocol (IP)-based architectures, which will provide state and local 911 authorities with significant new capabilities to respond to those in need of emergency assistance and to improve system resilience in comparison to legacy 911. These new capabilities include multimedia NG911 calls that allow the transmission of texts, photos, videos, and data, which persons with disabilities depend on for full and equal access to emergency services. However, for NG911 to be fully effective and accessible, it is essential that NG911 networks are designed to ensure the reliability of critical components and applications and interoperability to enable seamless transfer of 911 calls and data.

Today, we propose certain reliability and interoperability requirements that would apply to “covered 911 service providers” (CSPs), the providers that support essential functions within 911 networks such as call routing and automatic caller location, with particular emphasis on entities that provide these capabilities in the NG911 environment.

Our proposals build on the 911 reliability rules that the Commission adopted in 2013, which require CSPs to take measures to provide reliable 911 service to Public Safety Answering Points (PSAPs) with respect to circuit diversity, central-office backup power, and diverse network monitoring.

We propose to modify and update these rules to keep pace with the ongoing transition to NG911, improve NG911 network reliability and resilience, reduce the risk of outages, and ensure accessibility to the life-saving improvements that NG911 is uniquely capable of delivering. We also propose to adopt rules that would require Emergency Services IP Network (ESInet) providers to support interoperability in the interstate transfer of 911 calls and data, which will strengthen the ability of state and local 911 Authorities to ensure continued access to NG911 services during major emergencies by deploying resources in support of one another.

See

47 CFR 9.19(a)(4) (defining a CSP as any entity that (A) “[p]rovides 911, E911, or NG911 capabilities such as call routing, automatic location information (ALI), automatic number identification (ANI), or the functional equivalent of those capabilities, directly to a [PSAP] . . . ; and/or (B) [o]perates one or more central offices that directly serve a PSAP”).

See

47 CFR 9.19;

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, 17477-78, paras. 2-5 (2013), 79 FR 3123 (Jan. 17. 2014) (

911 Reliability Order

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

Derecho Report

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

PSAP refers to “[a]n answering point that has been designated to receive 911 calls and route them to emergency services personnel.” 47 CFR 9.3.

An ESInet is “[a]n internet Protocol (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. 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.”

Id.

It is particularly important that we take action on these issues now. When the Commission adopted the current 911 reliability rules in 2013, the transition to NG911 was in its very early stages. However, as the Commission observed in its July 2024

NG911 Transition Order,

the NG911 transition has now progressed to the point that most states have invested in NG911 technology, and many states and local jurisdictions have operating ESInets.

Moreover, many public safety commenters in the

NG911 Transition

proceeding expressed strong support for the Commission taking further action to strengthen NG911 reliability, interoperability, and accessibility. Finally, while NG911 has inherent reliability and accessibility advantages over legacy 911, our experience with recent outages affecting 911 suggests that some critical elements of NG911 networks may not be adequately covered by our existing 911 reliability rules. To address these issues, we propose and seek comment on the following measures:

Facilitating Implementation of Next Generation 911 Services (NG911); Location-Based Routing for Wireless 911 Calls,

PS Docket Nos. 21-479 and 18-64, Report and Order, FCC 24-78, 2024 WL 3507091 at *12, para. 29 (Jul. 19, 2024), 89 FR 78066 (Oct. 17, 2024) (

NG911 Transition Order

•

Covered 911 Service Providers.

First, we propose to update the definition of “covered service provider” in the Commission's existing 911 reliability rules to specify how the rules apply to service providers that control or operate critical pathways and components of NG911 networks.

○ The current CSP definition focuses on providers of certain network facilities and capabilities that are specific to legacy 911 systems and states that the rules also apply to their “functional equivalents” in the NG911 environment. We propose to specify that certain critical NG911 facilities and capabilities (

e.g.,

Location Validation Functions (LVFs), Geographic Information Systems (GISs), Emergency Call Routing Functions (ECRFs), Emergency Services Routing Proxies (ESRPs), and Policy Routing Functions (PRFs)) are among the functional equivalents referred to in the current rule and that providers of these capabilities therefore fall within the definition of CSPs.

○ We also propose to expand the CSP definition to encompass the following types of providers of critical connectivity in the NG911 environment: (1) operators of Location Information Servers (LISs) or equivalent IP 911 location databases; (2) operators of Legacy Network Gateways (LNGs); (3) operators of interstate Major Transport Facilities that meet or exceed Optical Carrier 3 (OC3) capacity and carry 911 traffic from multiple OSPs for ultimate delivery to NG911 Delivery Points or ESInets; (4) operators of IP Traffic Aggregation Facilities that carry segregated 911 traffic from multiple OSPs towards ultimate transmission to an NG911 Delivery Point or ESInet; and (5) operators of interstate interconnecting facilities between ESInets.

OSPs are “[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 this part.” 47 CFR 9.28. The term “911 traffic” means “[t]ransmissions consisting of all 911 calls (as defined in §§ 9.3, 9.11(b)(2)(ii)(A), 9.14(d)(2)(iii)(A), and 9.14(e)(2)(ii)(A)) and/or 911 text messages (as defined in § 9.10(q)(9)), as well as information about calling parties' locations and originating telephone numbers and routing information transmitted with the calls and/or text messages.”

Id.

•

Reliability Standards.

Second, we propose to update the reasonable reliability standards that providers of critical NG911 functions must employ to ensure the reliable delivery of 911 traffic to NG911 delivery points. We believe such action is needed to ensure the reliability of critical transport, aggregation, and data facilities in the NG911 ecosystem at the interstate and national level and the accessibility of NG911 services.

•

Interoperability.

Third, we propose to establish NG911 interoperability requirements for interstate transfer of 911 traffic between ESInets to optimize PSAP call transfer capabilities during service disruptions. We seek to ensure that PSAPs can transfer calls to nearby PSAPs located across state borders with minimal need for the traffic to be retranslated or reformatted in order for such transfers to occur. We further propose to harmonize this action with our current 911 reliability certification rules by adding an interoperability certification to the rules. We also seek updated information on interstate interoperability by type of service, with particular emphasis on services used by consumers, including those with accessibility needs.

•

Oversight.

Finally, we propose to modify the certification and oversight mechanisms in our 911 reliability rules to improve implementation of reliability and interoperability in NG911 systems. Additionally, we propose to enable state and local 911 Authorities to obtain reliability and interoperability certifications directly from CSPs, so that 911 Authorities can more easily exercise their existing authority to address reliability, interoperability, and accessibility needs within their jurisdictions.

Together, these proposals are intended to improve transparency and accountability during the NG911 transition and help ensure that the nation's 911 system functions effectively and reliably. We believe that these proposals will make the nation's 911 service more accessible, reliable and interoperable, while striking an appropriate balance between costs and benefits of such regulation. We seek comment on the tentative conclusions, proposals, and analyses set forth in this FNPRM, as well as on any alternative approaches.

Background

A. 911 Reliability Framework

The Commission adopted certain, specific 911 reliability rules for “covered 911 service providers” or CSPs in 2013 following the devastating impact on 911 services of the June 2012 mid-Atlantic derecho storm.

In the 2013 911 Reliability Order, the Commission determined that the reliability, resiliency, and availability of 911 service could be improved through implementation of network reliability practices and other sound engineering principles, and it accordingly adopted 911 reliability certification rules for CSPs.

CSPs are entities that provide 911, E911, or NG911 capabilities such as call routing, automatic location information (ALI), automatic number identification (ANI), or the functional equivalent of those capabilities, directly to a PSAP, statewide default answering point, or appropriate local emergency authority.

The rules mandate that all CSPs “shall take reasonable measures to provide reliable 911 service with respect to circuit diversity, central-office backup power, and diverse network monitoring.”

To demonstrate that they are taking such reasonable measures, the rules require CSPs to annually certify that they have “perform[ed] all the specific certification elements outlined in our rules regarding 911 circuit auditing, backup power at central offices that directly service PSAPs, and diverse network monitoring links.”

CSPs may also meet these certification requirements by showing that they have implemented “alternative measures . . . that are reasonably sufficient to mitigate the risk of failure, or that one or more certification elements are not applicable to its network.”

In addition, CSPs must notify PSAPs of network outages that may affect the PSAPs' ability to receive 911 calls.

The Commission delegated authority to the Bureau “to order appropriate remedial action on a case-by-case basis where 911 reliability certifications indicate such actions are necessary to protect public safety.”

911 Reliability Order,

28 FCC Rcd at 17477, para. 2.

Id.

at 17477-78, paras 2-5;

Derecho Report

at 1-2.

47 CFR 9.19(a)(4)(i)(A)-(B). For ease of reference, we sometimes refer herein to PSAPs, statewide default answering points, and appropriate local emergency authorities collectively as “PSAPs.” The term “covered 911 service provider” does not include PSAPs or governmental authorities to the extent they provide 911 capabilities or entities that offer the capability to originate 911 calls where another service provider delivers those calls and associated number or location information to the appropriate PSAP. 47 CFR 9.19(a)(4)(ii)(A)-(B).

47 CFR 9.19(b).

47 CFR 9.19(c).

47 CFR 9.19(b);

see 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. 12 (2015), 80 FR 60548 (Oct. 7, 2015) (

2015 Reliability Recon. Order

). The designated corporate officer may fulfill the certification requirement by explaining how the communications service provider has undertaken alternative measures that mitigate the risk of 911 network failure. 47 CFR 9.19(c)(1)(ii)(A), 9.19(c)(2)(ii)(A), and 9.19(c)(3)(ii)(A).

See also

47 CFR 9.19(4)(i).

APCO Comments, PS Docket No. 13-75, at 2 (filed July 16, 2018) (emphasis in original);

See also

47 CFR 9.28 (formally defining a LIS as 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.”). “A LIS [may] be a database, or [may] be a protocol interworking function to an access network-specific protocol. In NG9-1-1, the LIS supplies location (by value or reference) to the endpoint, or to a proxy operating on behalf of the endpoint.”

NENA i3 Standard,

§ 4.10 (emphasis removed).

NG911 Transition Order

at *26, para. 71.

Because all 911 traffic must access LISs and all TDM-based 911 traffic must be converted to SIP format via LNGs, we believe it is critical that operators of these facilities employ reasonable reliability practices. The need for reliability is especially significant given that national carriers appear to be relying on a relatively small number of these facilities to service large portions of their networks and to deliver 911 traffic to ESInets across many states. We seek comment on our proposal to designate operators of LISs (or equivalent IP 911 location databases) and LNGs as CSPs.

b. Operators of Major Transport Facilities and IP Traffic Aggregation Facilities

When the Commission adopted the reliability rules in 2013, it excluded third-party transport providers and 911 aggregation services from the definition of CSPs because, at that time, they did not play a central role in the provision of 911 service.

We tentatively conclude that, in the decade that has since passed, these providers have become crucial to the provision of NG911 service at the interstate and national level, and, therefore, they should be subject to the same reliability and transparency requirements as other providers of covered services. We seek comment on this tentative conclusion.

911 Reliability Order,

28 FCC Rcd at 17490, para. 39;

id.,

at n.90 (noting a commenter's argument that the reliability rules “should apply to backhaul providers and aggregators of 911 call traffic”).

Our understanding is that many OSPs now rely on high-capacity, IP-based fiber networks provided by third parties—which we refer to as Major Transport Facilities—to carry their 911 traffic to ESInets and PSAPs. These transport networks aggregate traffic (both 911 traffic and non-911 traffic) from multiple OSPs located in various states and carry it over long distances. The degree to which the 911 ecosystem has become dependent on these intermediate transport services is reflected in the outage investigations conducted by the Commission and by the outage reports submitted by OSPs through NORS. As we describe above, a number of multistate “sunny day” 911 outages have been caused by failures arising in or otherwise compromising Major Transport Facilities. Despite their outsized impact on 911 service, these networks currently fall within a gap in the Commission's rules; as providers of third-party transport service, they are neither CSPs nor OSPs, meaning they are not covered by the 911 reliability rules that are focused on routing and transmission services near the end of the 911 call flow nor by the Part 4 outage reporting rules relating to call originators and CSPs.

We wish to be cautious in how we define Major Transport Facilities so that § 9.19 continues to be focused on only the most critical 911 and NG911 elements and does not encompass smaller transport providers whose facilities do not pose a risk of widespread 911 outages. Accordingly, we propose to limit the definition Major Transport Facilities to providers that operate dedicated SIP transport facilities meeting or exceeding OC3 capacity; that also collect or transmit 911 traffic originated by multiple OSPs; and that also carry 911 traffic over interstate routes for ultimate delivery to an NG911 Delivery Point or ESInet.

We derive the proposed OC3 capacity from the outage reporting requirements in § 4.9. That rule requires “outage reporting for communication disruptions impacting major transport facilities, specifically those with significant traffic-carrying capacity[.]”

See proposed rules at §§ 9.19(a)(4)(i)(E), 9.19(a)(12).

In the Matter of Amends. to Part 4 of the Commission's Rules Concerning Disruptions to Commc'ns; New Part 4 of the Commission's Rules Concerning Disruptions to Communications; The Proposed Extension of Part 4 of the Commission's Rules Regarding Outage Reporting to Interconnected Voice Over Internet Protocol Service Providers and Broadband internet Service Providers,

PS Docket Nos. 15-80, 11-82, 31 FCC Rcd 5817, 5822, para. 11 (2016), 81 FR 45055 (July 12, 2016), 81 FR 45095 (July 12, 2016);

see also In the Matter of Amends. to Part 4 of the Commission's Rules Concerning Disruptions to Commc'ns; New Part 4 of the Commission's Rules Concerning Disruptions to Communications,

PS Docket No. 15-80, 30 FCC Rcd 3206, 3212-13, para. 19 (2015), 80 FR 34321 (June 16, 2015), 80 FR 34350 (June 16, 2015).

Operators of IP Traffic Aggregation Facilities provide a niche service to OSPs: they segregate or collect segregated 911 traffic from OSPs and process and transmit the traffic towards the appropriate NG911 Delivery Points or ESInets.

We allowed the use of such services in the

NG911 Transition Order

because they “enable multiple small carriers to bundle their data streams and share the cost of transporting the pooled data stream to a common destination, resulting in lower overall costs than if each OSP paid for separate transport.”

As with Major Transport Facilities, a large percentage of 911 traffic now passes through IP Traffic Aggregation Facilities. For example, one of these providers claims that it has “deployments of NG911 call aggregation service in states and counties across the country”

100

and that its 911 aggregation network serves 40% of the U.S. population. The provider claims to process more than 1.8 million 911 calls per month and to deliver the calls to more than 5,000 PSAPs.

See proposed rules at §§ 9.19(a)(4)(i)(F), 9.19(a)(13).

NG911 Transition Order

at *47, para. 138.

100

Sinch,

NG911 call aggregator, Inteliquent, leads U.S. public safety, https://sinch.com/news/ng911-call-aggregator-inteliquent-leads-us-public-safety/?UTM-Inteliquent

(last visited Feb. 14, 2025). Sinch acquired Inteliquent in 2021.

We expect the roles of Major Transport Facilities and IP Traffic Aggregation Facilities to only increase as a result of the

NG911 Transition Order,

because it requires OSPs to deliver the 911 traffic they originate to NG911 Delivery Points that 911 Authorities may designate at any location within their state or territorial borders.

101

If these newly-designated traffic hand-off points are located outside of an OSPs' certificated service areas, OSPs may choose to procure the services of Major Transport Facilities and/or IP Traffic Aggregation Facilities rather than incur the high cost of building out their own networks.

101

NG911 Transition Order

at *55, para. 163.

We tentatively conclude that Major Transport Facilities and IP Traffic Aggregation Facilities have become critical to the overall reliability of the 911 ecosystem and that their operators therefore should comply with reasonable reliability standards. We

seek comment on this tentative conclusion. Commenters in the

NG911 Transition

proceeding observed the important roles that these third-party entities have come to have.

102

We also believe that federal-level oversight of Major Transport Facilities and IP Traffic Aggregation Facilities is appropriate because they typically have multi-state or national footprints that exceed the scope of regulation or contractual terms imposed by any individual state or local government.

102

See, e.g.,

USTelecom Comments, PS Docket No. 21-479, at 5 (filed Aug. 9, 2023) (noting that NG911 systems will make it more challenging for wireline providers to comply with the Commission's 911 reliability rules, because 911 call traffic will be traveling over third-party networks); Windstream Reply Comments, PS Docket No. 21-479, at 2-3 (filed Sep. 8, 2023) (arguing that NG911 traffic aggregators should be subject to the Commission's rules relating to disruption notification requirements, which currently apply to OSPs); Home Telephone Comments, PS Docket No. 21-479, at 8, 14-17 (filed Aug. 9, 2023) (asserting that the use of NG911 call aggregators needs to be addressed to ensure reliability); NTCA Comments, PS Docket No. 21-479, at 4-5, 6-7 (filed Aug. 9, 2023) (predicting that NG911 will expand OSPs' use of third-party networks).

We seek comment on the inclusion of these providers in the definition of CSPs. Have Major Transport Facilities and IP Traffic Aggregation Facilities become critical to the reliable and interoperable transmission of 911 traffic to PSAPs? How frequently have outages impacting 911 originated within these facilities, and what were the causes and consequences of the outages? Would one or both of these definitions 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? Do our proposed definitions appropriately describe these providers, or should they be defined more narrowly or broadly? For example, should we update the “OC3 and equivalent” standard for Major Transport Facilities to “1 Gbps (or 10 Gbps) Ethernet and equivalent,” to better reflect modern IP transport facilities in use today?

103

Should we further limit the definition of Major Transport Facilities so that it refers only to facilities that carry a minimum volume of 911 traffic? If so, what is an appropriate minimum threshold? Should it be based on the number of 911 calls handled by the facility, on the number of OC3 minutes of 911 traffic, or some other metric?

104

Also, what specific costs would these providers incur if they were included as CSPs, and what would be the benefits to the reliability of the NG911 network? Are there other classes of providers that should be included as well, and why?

105

103

Is OC3 Bandwidth Still a Good Choice?,

GigaPackets,

https://www.gigapackets.com/articles/oc3bandwidth.php

(“The SONET family of line rates spans OC-1 at 52 Mbps on up to OC-768 at 40 Gbps. But in practice, only a few optical carrier levels are standard and readily available. These are OC-3 at 155 Mbps, OC-12 at 622 Mbps, OC-48 at 2.5 Gbps, OC-192 at 10 Gbps and OC-768 at 40 Gbps . . . Standard Ethernet WAN services mirror the standard Ethernet LAN speeds of 10 Mbps, 100 Mbps, 1 Gbps and 10 Gbps.”) (last visited Feb. 18, 2025).

104

Note that we also are proposing to modify the 911 reliability certification form to ask NG911 CSPs to report the volume of 911 traffic handled by their facilities that do not conform to the Commission's reliability best practices.

105

Bandwidth, Inc. argues that “local exchange carriers' discontinuance of TDM services” and a lack of “alternative interconnection facilities, such as Ethernet” is negatively impacting 911 reliability and the NG911 transition.

See

Bandwidth, Inc.

Ex Parte,

PS Docket 21-479, at 1-2 (filed Mar. 20, 2025). The broader TDM to IP technology transition is outside of the scope of today's

Further Notice.

c. Operators of ESInet Interconnection Facilities

Finally, we propose to designate interstate interconnecting facilities between ESInets as critical 911 facilities. As we explain in greater detail below, while ESInets are providing greater PSAP-to-PSAP interoperability within their areas of deployment compared to legacy networks, there is a concerning lack of interoperability between different ESInet providers. Interstate interoperability is especially low for the types of data associated with the advanced features that NG911 is meant to deliver, such as GIS-based location information, SMS text, and Multimedia Emergency Services (MMES), that enhance the accessibility of emergency services to persons with disabilities.

We do not propose requiring ESInets to adopt any particular technological solution to the interoperability problem, only that they take reasonable measures to provide reliable and interoperable 911 service and confirm their interoperability with other ESInets by conducting conformance testing. We expect, however, that whatever solutions ESInets adopt to become interoperable will require the exchange of potentially large amounts of data and may also require external data connections and therefore will be critical to the resiliency of NG911 service.

106

We therefore propose that these interconnection facilities should be treated as critical facilities that are subject to § 9.19 reliability standards and certification requirements. We seek comment on this proposal and on our analysis above. We also seek comment on how designating providers of interconnecting facilities between ESInets as CSPs would affect the accessibility of advanced, multimedia NG911 services for persons with disabilities, as well as estimates of cost impacts.

106

CSRIC VII WG 4 Report

at 5-6.

2. Reliability Requirements

a. Reasonableness Standard

We propose that any entity providing the foregoing critical NG911 capabilities or facilities be subject to the current requirement in § 9.19 to take “reasonable measures” to ensure reliability.

107

We believe moving to IP-based architecture in NG911 inherently improves reliability by enabling greater redundancy and geodiversity.

108

We further believe that it is reasonable for NG911 CSPs to ensure network reliability by adhering to prevailing industry standards.

109

We therefore tentatively conclude that these prevailing industry standards are achievable for CSPs at acceptable additional cost.

110

We further propose that CSPs may presumptively meet this

reasonableness requirement by adopting reliability practices in three broad areas: physical diversity, network monitoring, and operational integrity (which as proposed will subsume and replace backup power).

111

We seek comment on these proposals.

107

47 CFR 9.19(a)(4)(i)(A) and 9.19(a)(4)(i)(B) (applying rules to “functional equivalent” facilities and “equivalent NG911 capabilities”); 47 CFR 9.19(b) (“All covered 911 service providers shall take reasonable measures to provide reliable 911 service with respect to circuit diversity, central-office backup power, and diverse network monitoring.”).

108

NG911 Transition Order

at *64, para. 185, n.546 (“NG911 materially reduces the number of 911 outages by improving network availability and reliability as IP allows for greater redundancy. It provides greater geodiversity for PSAPs—no longer will there be a single point of failure at a selective router.”) (internal citation omitted);

See also

Sophia Fox-Sowell,

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

State Scoop (Oct. 21, 2024) (“ `Had the old technology and analog network still been in place, the infrastructure would have been destroyed . . . . Thanks to the resiliency and redundancy of this network, we had no reports of 911 calls not being delivered.' ”), at

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

109

CSRIC VI, WG 1 Report

at 115 (“Network Operators . . . should implement a continuous engineering process to identify and record single points of failure and any components that are critical to the continuity of the infrastructure . . . [and] pursue architectural solutions to mitigate the identified risks . . . .”), p. 124 (providers should “design networks with redundant interconnectivity to” ESInets), p. 122 (“Network Operators . . . should identify and manage critical network elements and architecture that are essential for network connectivity and subscriber services considering . . . functional redundancy and geographical diversity.”).

110

See e.g. Interstate Nat. Gas Ass'n of Am.

Pipeline & Hazardous Materials Safety Admin.,

2024 U.S. App. Lexis 20710, *22 (D.C. Cir. 2024) (“[T]he final rule invokes certain consensus industry standards that most operators already successfully utilize, so the incremental cost . . . would be negligible.”) (cleaned up);

See also

47 CFR 0.392(j), 9.19(b).

113

47 CFR 9.19(b).

114

47 CFR 0392(h).

While we propose to keep the reasonableness standard that the Commission adopted in 2013, we propose to identify new “best practice” benchmarks for NG911 providers to allow them to presumptively satisfy the reasonableness requirement. We also propose to modify the process by which CSPs report alternative reliability measures to enable the Bureau to better assess reasonableness of network practices. We seek comment on this proposed framework, in tandem with the proposed reliability benchmarks below.

b. Benchmarks for CSP Demonstration of Presumptive Reasonableness

We propose to expand the range of required network reliability practices to ensure they better capture all relevant factors in the reliability of NG911 networks.

115

The Commission based its original 2013 rules “on the

Derecho Report

and other prior experiences with natural disasters” and therefore required reliability certifications only for circuit diversity, central-office backup power, and diverse network monitoring.

116

However, the Commission observed that as technologies evolve, “categories based on legacy 911 networks may not adequately reflect reasonable measures to provide reliable service, particularly in an NG911 environment.”

117

115

2014 Reliability NPRM,

29 FCC Rcd at 14223-24, para. 37 ([“W]e seek to ensure that the Commission remains equipped, consistent with its statutory mandates and existing legal authority, with the proper regulatory tools to enforce continued and clear lines of accountability for reliable 911 call completion, including as the nation transitions to an IP-based NG911 architecture.”). The Commission noted, for example, the April 2014 multistate 911 outage resulted from a software coding error that disrupted routing of 911 calls and inadequate alarm management, which resulted in “significant delays in determining the software fault and restoring 911 service to full functionality.”

2014 Reliability NPRM,

29 FCC Rcd at 14226, para. 43,

citing 2014 Multistate Outage Report

at 3.

116

2014 Reliability NPRM,

29 FCC Rcd at 14226, para. 43 (internal quotations omitted).

117

Id.

at 14226, para. 43.

We intend for today's proposed benchmarks for presumptive reasonability to capture the IP network engineering principles of reliability, resiliency, redundancy, physical diversity, and geographic diversity, which we believe most responsible NG911 network operators should be implementing. We wish to preserve the flexibility of PSAPs, 911 Authorities, and state governments regarding how best to allocate resources to meet their reliability needs,

118

while still adequately capturing the increasingly interstate and interlinked nature of NG911 where national standards may aid 911 Authorities.

119

Finally, our intent is that these NG911 reliability benchmarks would not apply to the origination of 911 traffic by OSPs, but would apply to service providers who aggregate 911 traffic or perform other critical NG911 functions and services for multiple OSPs.

120

118

See, e.g.,

Texas 9-1-1 Entities Reply Comments, PS Docket No. 14-193, at 2, n.6 (filed April 21, 2015) (FCC reliability regulation of state contractors could increase the costs for PSAPs and state governments to hire contractors and delay NG911 transitions and deployments); NASNA Comments, PS Docket No. 14-193, at 2 (filed March 17, 2015) (PSAPs and 911 Authorities should be responsible for ensuring the reliability of 911 network services provided by their contractors); Washington Utilities and Transportation Commission Comments, PS Docket No. 14-193, at 3-4 (filed March 17, 2015) (911 oversight in Washington state is already shared by the Utilities and Transportation Commission, the Washington Military Department, and the E91l County Coordinators.”).

119

Pennsylvania Public Utilities Commission Reply Comments, PS Docket No. 14-193, at 9 (filed April 21, 2015) (“The Pa PUC does support the development of a federal regulatory `backstop' to eliminate gaps between federal and State authority. Where multi-state aspects of interlinked 911 network architectures exist, or where technology trends make vulnerabilities more likely or cause confusion to PSAPs and end-users, the Commission is best positioned to forge resolutions and develop national standards.”); Washington Utilities and Transportation Commission Comments, PS Docket No. 14-193, at 4 (filed March 17, 2015) (“Although it is true that technological and marketplace changes are altering the manner in which some components of 911 service are handled, including increasing reliance on network components and technology that are multi-state in nature, the vast majority of 911 calls originate and terminate within or to nearby PSAPs within each state and county and are jurisdictionally intrastate in nature. Accordingly, federal efforts should be dedicated to measures that assist, or complement, state and local governance efforts, rather than act to supersede them.”).

120

NG911 Transition Order

at *69, para. 202 (“. . . OSPs could significantly lower the overall costs of transmitting 911 calls to ESInets by taking advantage of third-party aggregators' services.”);

NG911 Transition Order

at *71, para. 206 (“CSRIC explains that LIS as a service is contemplated as an NG911 solution at `minimal expense' to small OSPs, as it relieves OSPs of most costs beyond monthly services, and an LNG and can be provided either by a commercial vendor or the 911 authority.”); Home Telephone NG911 Notice Comments at iii (“[T]he Commission should focus on the back-end for-profit entities that aggregate front-end 911 transmissions from multiple jurisdictions, process, and then deliver via back-end connections IP-based information to the appropriate local [PSAPs]. 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.”); Bandwidth NG911 Notice Comments at 2-3 (“Bandwidth predominately acts as a VoIP Positioning Center (`VPC') where it provides stand-alone emergency location and 911 call routing capabilities for its VoIP service provider customers . . . . Bandwidth has a robust network that reaches across the United States and Canada and delivers around 3 million calls a year from 26.7 million end points . . . . To date, Bandwidth established network aggregation capabilities to route its customers' 911 traffic through 16 ESInets.”).

The purpose of these benchmark and certification proposals is to give the Commission reasonable oversight of CSP reliability practices while avoiding micromanagement of the network construction and design decisions of private entities. Accordingly, we do not propose to specify the details of reliable network practices down to the level of daily operational decisions and practices. Rather, we seek to articulate the kinds of measures that would demonstrate presumptive reliability when requesting certification. We seek comment on how best to improve 911 reliability and gather information that is reasonably actionable for efficient and

effective Commission and 911 Authority oversight, while also ensuring robust notice of “reasonable” reliability compliance expectations for CSPs. We also seek comment on whether adopting a reasonable reliability standard of “five nines” availability would be another valuable measure for determining compliance, or whether annual CSP facility availability time should be reported in addition to these benchmarks.

121

How should “five nines” availability be calculated?

122

121

See In the Matter of the Nebraska Public Service Commission, on its own motion, conducting an investigation into the 911 service outage that began on August 31, 2023 in areas of Nebraska served by Lumen,

Application Nos. 911-075/PI-248 and 911-077/C-5581/PI-252, Order Issuing Findings and Closing Investigation, p. 24 (Jan. 15, 2025),

https://www.nebraska.gov/psc/orders/state911/2025-01-14%20911-075%20PI-248%20911-077%20C-5581%20PI-252%20Order%20Issuing%20Findings%20and%20Closing%20Investigation.pdf

(“Mr. Rosen then explained that five nines is a term used in 911 systems to determine reliability of a 911 system, and the term refers to a 911 system being available 99.999% of the time. Mr. Rosen said there are two ways to determine availability. One way is to determine the actual availability of the system based on the period of time the system has been operational. In the alternative, availability can be determined by calculating two quantities: the mean time between failures and the mean time to repair for each component in the network.”) (

Nebraska PSC Order

122

FCC, Task Force on Optimal PSAP Architecture (TFOPA), Adopted Final Report, p. 103, (2016),

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

(“While `five nines' is the generally accepted minimum availability service level, it should be noted that this equates to 5.26 minutes of unscheduled downtime or service unavailability per year. Another important factor when comparing network availability to consider is specifically how different network service providers define availability and how it is calculated. For example, scheduled maintenance events are typically not included/classified as downtime. The ESInet by design incorporates multiple paths for voice and data transmission. The failure of a single element within the network or congestion along a path will not necessarily limit the ability to deliver traffic.”)

(i) Physical Diversity

We propose specifying that the critical IP paths subject to the rules be subject to physical diversity requirements appropriate to NG911 and transitional networks.

123

For legacy 911 circuits, the best practice benchmark of audits and tagging will remain the same. For NG911 facilities, we propose that “physical diversity” would mean that critical paths established by CSPs must be geographically diverse,

124

load-balanced,

125

and capable of automatic failover to the backup element (

e.g.,

redundant routers or node connections and links) and automatic reroutes to redundant paths in the transport layer in the event of path failure.

126

Redundant routers or node paths and links should be located in different geographic locations (

i.e.,

in different physical facilities). We seek comment on this proposal.

123

CSRIC VI, WG 1 Report

at 51 (“It is assumed in this Report that all network elements and transport facilities are deployed with redundancy”).

124

2014 Reliability NPRM,

29 FCC Rcd at 14227, para. 45, n.106 (“For example, network architectures utilizing . . . databases in different geographic locations . . . will be more reliable and resilient than those that route all calls through a single active database . . . .”).

125

Id.

at 14227, para. 45, n.107 (“A 911 network is `load balanced' if call volume is dynamically distributed among all available databases or call processing facilities rather than concentrated in one location. Calls assigned to each database should be automatically rerouted to the other in the event of a fault with the primary route. Furthermore, if two or more PSAPs share the same 911 service provider and rely on each other as a backup PSAP for rerouting of 911 calls, the 911 service provider should consider assigning each PSAP to a different primary routing database.”).

126

Id.

at 14227, para. 45.

In general, “physical diversity” means that data between two points in a network can be transmitted over diverse routes that do not share any common physical segments, such as fiber-optic cables, conduits, or structures, so that a single failure at any point on one of those data paths, such as a power outage, equipment failure, or cable cut, would not cause both paths to fail and disrupt the transmission of data between those points. Importantly, we propose to add geographic diversity as a necessary part of this updated definition for IP paths, to ensure service providers can automatically re-route 911 traffic to travel over a different path that is both physically diverse

and

geographically separated. We seek comment on the appropriateness of geographical diversity as part of the physical diversity requirement for IP-based networks.

In 2013, the Commission included “circuit auditing and tagging” as an element of the 911 reliability rules, which requires CSPs to certify annually whether they have (1) audited the physical diversity of critical 911 circuits

127

or equivalent data paths to any PSAP served, (2) tagged such circuits to reduce the probability of inadvertent loss of diversity between audits,

128

and (3) eliminated all single points of failure in critical 911 circuits or equivalent data paths serving each PSAP.

129

If a CSP has not implemented the third element (

i.e.,

the elimination of all single points of failure), it must certify “[w]hether it has taken alternative measures to mitigate the risk of critical 911 circuits that are not physically diverse or is taking steps to remediate any issues that it has identified with respect to 911 service to the PSAP.”

130

Respondents also may certify that the circuit auditing requirement is not applicable because they do not operate any critical 911 circuits.

131

127

Critical 911 circuits are defined as “911 facilities that originate at a selective router or its functional equivalent and terminate in the central office that serves the PSAP(s) to which the selective router or its functional equivalent delivers 911 calls, including all equipment in the serving central office necessary for the delivery of 911 calls to the PSAP(s).” They also include automatic location information (ALI) and automatic number information (ANI) connecting circuits that originate at the ALI or ANI database and terminate in the central office that serves the PSAP.

See

47 CFR 9.19(a)(5).

128

The rules define tagging as “[a]n inventory management process whereby critical 911 circuits are labeled in circuit inventory databases to make it less likely that circuit rearrangements will compromise diversity.” Covered 911 Service Providers may use any system they wish to tag circuits so long as it tracks whether those circuits are physically diverse and identifies changes that would compromise such diversity.

See

47 CFR 9.19(a)(11).

129

See

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

130

47 CFR 9.19(c)(1)(ii)(A).

131

For example, small or rural local exchange carriers (LECs) may provide administrative lines to PSAPs but do not typically operate selective routers or control the facilities that connect selective routers to the central offices serving each PSAP. In such cases, they could respond that the circuit auditing element of the certification is not applicable.

In 2013, the Commission required CSPs to certify to circuit diversity measures for paths between a selective router or its functional equivalent and the central office serving a PSAP. The Commission further identified routing and 911 traffic aggregation as distinct functions performed by the selective router.

132

While this standard always applies to aggregated circuits when service is directly provided to a PSAP, under today's proposals if 911 traffic aggregation and routing are occurring at different points, both functions would trigger the requirement under our rules specify the examples that “functional equivalence” includes IP traffic paths from NGCS facility capabilities (when provided directly to PSAPs), or from an aggregation point located in a different central office from the selective router.

133

In 2014, the Commission introduced concepts such as dynamic routing, load balancing, automatic re-routing, and geographic facility diversity as reliability best practices for IP network paths and facilities.

134

2015, the Commission observed that NG911 networks achieve reliability and resiliency with geographic diversity and dynamic routing instead of traditional TDM circuit auditing and tagging.

135

Today we propose to add critical paths of major transport facilities and 911 aggregation network facilities as subject to our physical diversity rules regardless of whether the provider has direct service contracts with a PSAP or other answering point.

136

Furthermore, we propose to codify additional physical diversity technical standards to encompass both legacy and NG911 facilities, to ensure that NG911 entities will no longer have to explain each year that they are using the IP “alternative” to legacy TDM 911 reliability. We seek comment on our assessment.

132

911 Reliability Order,

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

aggregation point

called a selective router . . .”) (italics added).

133

See proposed rules at § 9.19(a)(4)(i)(A)-(B), § 919(a)5(i).

134

2014 Reliability NPRM,

29 FCC Rcd at 14227, para. 45, nn.106, 107 (proposing to expand reliability certifications for NG911 to ensure IP-based 911 architecture is geographically distributed, load-balanced, and capable of automatic reroutes.”);

Id.,

29 FCC Rcd at 14243-44, Appx. A, Proposed Rules 12.4(a)(12) to (14), 12.4 (c)(4).

135

2015 Reliability Recon. Order,

30 FCC Rcd at 8656, para. 15.

136

See e.g. Nebraska PSC Order,

p. 40 (“While the Commission recognizes the failures were all between the aggregation point and the LNG, and not the ESInet nor core services, Lumen designed, installed and implemented this system and continues to be responsible for its failing infrastructure.”);

see also 2014 Reliability NPRM,

29 FCC Rcd at 14227, para. 45.

144

See e.g. FCC Urges Companies Using UPS Devices to Take Action Against Threats,

Public Notice (Apr. 7, 2022),

https://docs.fcc.gov/public/attachments/DOC-382138A1.pdf.

145

2014 Reliability NPRM,

29 FCC Rcd at 14227, para. 45, n.106.

C. Interoperability

As noted above, the lack of interoperability is a known concern in NG911, which impairs and increases the cost of call and data transfer. CSRIC VII observed that the “transition from legacy to IP-based networks, may result in hybrid system settings that commingle legacy and IP network elements. While in this hybrid state, the 911 systems operate at higher risk. For example, these systems may encounter challenges in ensuring interoperability with respect to 911 calls and related data.”

146

CSRIC VII also observed that data collected by NASNA from showed low levels of interstate interoperability, particularly for data associated with NG911 such as location or SMS text as well as for features that enhance accessibility, (

e.g.,

Multimedia Emergency Services (MMES).

147

CSRIC VII found that “[t]he more advanced technologies used day to day by the general public such as multi-media services had a very low level of respondents indicating interoperability.”

148

As the NG911 transition progresses, these interoperability issues are likely to manifest into incompatibilities detrimental to the processing and receipt of 911 traffic and related information by 911 Authorities across state lines.

149

146

CSRIC VII, WG 4 Report

at 5.

147

Id.

at Appendix B.

148

Id.

at 25.

149

See

Jackie Mines,

How is NG911 progressing?

(Feb. 11. 2025),

https://urgentcomm.com/911/how-is-ng911-progressing-

(“While the [NG911 i3] standards were written with interoperability in mind, if Vendor A interprets them differently than Vendor B, interfacing the systems doesn't go well and sometimes is nearly impossible.”).

To address these concerns, we propose to adopt interstate interoperability requirements to support the reliable exchange of interstate 911 traffic between ESInets. Specifically, we propose to require that CSPs certify whether their interstate interconnecting ESInet facilities achieve interoperability for exchanged 911 traffic sufficiently to enable complete interstate transfers between ESInets.

150

In that connection, CSPs would annually certify whether their interstate interconnecting ESInet facilities use conformance-tested equipment and whether they have tested their interstate interoperability capabilities. If a CSP cannot certify to these elements, we propose to require the CSP to certify with respect to those facilities: (1) whether it (or its ESInet facility operator) has taken alternative measures to ensure interoperability between ESInets in multiple states and between providers; (2) whether it believes that one or more of the requirements of this paragraph are not applicable to its facilities; and (3) to additional questions about the non-conforming facilities as directed by the Bureau. We also propose to apply the definition of “NG911” adopted in the

NG911 Transition Order

to CSPs. Finally, we seek comment on the scope of our proposed interoperability requirements relative to other NG911 elements and whether to define interoperability to cover those elements.

150

Under our proposal, ESInet interconnecting facilities operator refers to an entity that provides communication capabilities between ESInets.

1. Interstate Interoperability, Conformance and Interoperability Testing, and Interoperability Certification

Conformance and Interoperability Testing.

We propose to adopt an interoperability best practice benchmark of testing and verification to support interstate interoperability. We recognize that there have been voluntary efforts to promote interoperability across NG911 vendors through best practices, standards development and conformance testing, but no national rules are in place for providers of NG911 capabilities. Conformance testing, a process generally planned and developed by industry organizations and conducted by certified labs, is a mechanism that could be used to ensure that devices and network equipment that are deployed are compliant with commonly accepted standards.

Consistent with our existing framework for reliability certifications, we propose that CSPs submit an annual certification of whether the equipment in their networks has undergone conformance testing and if not, whether they are using alternative measures to ensure interstate interoperability. Under our proposed approach, CSPs would be required to certify that they are able to process and share interstate 911 requests for emergency assistance and all associated information consistent with commonly accepted standards. We seek comment on this proposal. Is a certification approach sufficient to ensure that interoperability between ESInets across multiple states can be achieved without the need for proprietary interfaces, and regardless of jurisdiction, equipment, device, software, service provider, or other relevant factors? Should we require CSPs to certify that they are capable of maintaining interstate interoperability during a “sunny day” outage or disaster scenario?

We also seek comment on whether to adopt additional interoperability benchmarks, such as requirement to conduct interoperability testing between ESInets in addition to conformance testing of technology used by ESInets. Interoperability testing is an important mechanism for ensuring that CSPs are technically capable of supporting interoperability between states and different service providers. Unlike conformance testing, which can be used by a service provider to demonstrate its NG911 solution conforms to a standard and increases the likelihood of interoperability, interoperability testing involves two or more service providers to demonstrate the exchange of information. We therefore seek comment on adopting a benchmark that CSP perform interoperability testing with two or more ESInets in different states. To this end, we seek comment on requiring that CSPs annually test and certify that they have performed interoperability testing with at least two different providers in two different states, or if they are using alternative measures to satisfy interstate interoperability.

Interoperability Certification and Alternative Measures.

We propose that CSPs submit an annual certification attesting to both conformance testing and interoperability testing starting one year after OMB approval of any associated information collection requirements. We seek comment on whether CSPs will be reasonably able to conduct the required testing within this time period. What processes or standards for test labs need to be in place before conformance testing can begin? Are there any other barriers to either conformance testing or interoperability testing that would impact being able to submit this certification?

Our proposed annual certification approach is consistent with our existing requirement under § 9.19(c).

151

We also propose to require CSPs to update their certifications annually to reflect any

changes in their interoperability solutions that render prior certifications outdated. In addition, we seek comment on whether there are other methods, in addition to conformance testing and interoperability testing, for verifying that CSPs comply with “commonly accepted standards” and allow them to demonstrate that they are technically capable of providing interoperability. For example, is it necessary to specify end-to-end testing (typically required by the customer) and/or performance testing (testing that simulates a real world scenario)?

152

Are any such methods more reliable than conformance and interoperability testing for verifying interstate interoperability? What are the potential costs of, and challenges with, implementing any such methods?

151

47 CFR 9.19(c).

152

See, e.g., iCERT Interoperability Testing Report

at 10; Brian Rosen Comments, PS Docket 21-479, at 4 (filed Jul. 28, 2023) (“Call transfer across ESInets is now standardized in NENA STA-010.3, which is the standard that all current NGCS implementations are currently at or are expected to be upgraded to soon. Vendor testing at NENA ICE events and bilateral testing between vendors are proving interoperability today.”).

Finally, we propose to adopt an alternative “reasonable” interoperability requirement for providers of interstate ESInet interconnecting facilities, following the same framework of § 9.19 for reliability. As with the current § 9.19 reliability certifications, CSPs would be allowed to either certify to meeting the interoperability benchmarks specified in the rules or to certify that they have achieved reasonable interoperability using alternative measures. We seek comment on this proposal. What alternative measures in lieu of our benchmarks would likely be used to certify and demonstrate “reasonable” interoperability? Should we require that CSPs successfully test the transfer of interstate calls between ESInets in order to demonstrate “reasonable” interoperability? What other alternative measures would demonstrate reasonable interoperability?

NG911 and Commonly Accepted Standards.

We propose to amend § 9.19 of the rules to define providers of “NG911” capabilities by cross-referencing the definition of NG911 in § 9.28 of the rules. The definition adopted in the

NG911 Transition Order

helps define common sets of features and parameters at various points in the 911 call flow to allow any 911 call or text to be able to reach 911 call takers. We believe our proposal, consistent with the

NG911 Transition Order,

will help lay foundational elements to realizing interoperability between OSPs to 911 Authorities in multiple states. Under this proposal, CSPs would “ensure interoperability” and comply with “commonly accepted standards” similar to OSPs. Our proposed rule amendment would therefore ensure CSPs operate from the same baseline requirements to facilitate interstate interoperability and promote cooperation with OSPs. We seek comment on our proposal, including potential costs.

In addition, we seek comment on alternative approaches to ensure interstate interoperability. In response to the

NG911 NPRM,

some commenters urged us to clarify the roles of OSPs and providers of NG911 services.

153

APCO proposed that in addition to focusing on the delivery of 911 traffic by OSPs, the Commission should take the “next step toward achieving public safety's vision for NG9-1-1” by initiating a further notice of proposed rulemaking to address “interoperability requirements for 9-1-1 service providers

and other elements of the emergency communications chain.

”

154

In that connection, we seek comment from 911 Authorities and others as to whether we should expand the scope of our proposed interoperability requirement, and, if so, to what other elements of the emergency communications chain? Similarly, we seek comment on whether to amend § 9.19(a) of the rules to add a definition for “interoperability” for purposes of clarifying the obligations of NG911 service providers, including the definition of interoperability from the Spectrum Auction Reauthorization Act of 2023 (H.R. 3565), or some variation, for purposes of defining the scope of our interoperability requirements; and the potential benefits and costs of adopting such a definition.

153

See, e.g.,

APCO Comments, PS Docket 21-479, at 4-5 (filed Aug. 9, 2023) (“The greatest impact the Commission can have on facilitating the transition to NG9-1-1 would be to require interoperability between OSPs and 9-1-1 service providers, and among 9-1-1 service providers.”); Jack Varnado, Livingston Parish Sheriff Comments, PS Docket 21-479, at 1 (filed Aug. 9, 2023) (urging the Commission to require all OSPs and 9-1-1 service providers achieve interoperability); Michael Coonfield, Oklahoma 911 Management Authority Comments, PS Docket 21-479, at 2 (filed Aug. 8, 2023) (stating that interoperability between ESInet and core services must be required and included in the forest guide); Texas 9-1-1 Entities Reply Comments, PS Docket 21-479, at 17 (filed Sept. 8, 2023) (“[T]he Commission should consider a notice of inquiry regarding interoperability between NG911 service providers, with emphasis on 911 call transfers between ESInets and within ESInets.”).

154

APCO

Ex Parte,

PS Docket 21-479, at 2 (filed Apr. 18, 2024) (emphasis added). APCO previously urged the Commission to require interoperability between OSPs and NG911 service providers as part of the current proceeding. APCO Comments, PS Docket 21-479, at 2-4 (filed Aug. 9, 2023). However, in its

ex parte,

APCO expressed support for moving forward with the OSP requirements that the Commission proposed in the

NG911 Notice.

APCO

Ex Parte,

PS Docket 21-479, at 1 (filed Apr. 18, 2024). In a more recent

ex parte,

APCO urges the Commission to “seek comment on a rule that would require 9-1-1 service providers to enable the ECCs they serve to exchange all forms of 9-1-1 traffic with ECCs in different states and/or served by different 9-1-1 service providers. Each 9-1-1 service provider could demonstrate compliance with this interoperability requirement by certifying that the ECCs it serves are able to exchange 9-1-1 traffic with at least three ECCs located in different states and/or served by other 9-1-1 service providers. Such a certification should include an attestation that the 9-1-1 service provider has confirmed interoperability through real-world testing at its sole cost.” APCO

Ex Parte,

PS Docket 21-479, at 3 (filed Nov. 1, 2024).

Intrastate Interoperability.

Today's proposals cover interstate interoperability between ESInets. With respect to intrastate interoperability, we believe that 911 Authorities can address NG911 interoperability within their jurisdictions pursuant to contracts and tariffs with providers of NG911 services and have the ability to order necessary testing and resolve interoperability disputes, including with sub-contractors, pursuant to such instruments. In addition, 911 Authorities are in the best position to address intrastate interoperability from the border control function at the in-state or in-territory NG911 Delivery Point through ingress to ESInet connected PSAPs and between PSAPs. We seek comment on our view.

2. Interstate Interoperability for Text and Video Accessibility

We seek comment on whether interoperability certifications relating to ESInet interconnection facilities should include specific certifications regarding interoperability of 911 text messaging and video accessibility consistent with the benchmarks discussed above. We believe that ensuring interoperability for non-voice NG911 communications is equal in importance to ensuring interoperability for voice NG911 calls. In the

NG911 Transition Order,

the Commission extended NG911 requirements to OSPs providing non-voice 911 services, including covered text providers and internet-based Telecommunications Relay Service (TRS) providers. NG911 is specifically intended to provide improved support for the full range of 911 voice, text, data, and video communications, including promoting and enabling 911 access for individuals with disabilities.

155

In its end state, NG911 will facilitate interoperability and system resilience, improve connections between 911 call centers, and support the transmission of text, photos, videos, and data to PSAPs

by individuals seeking emergency assistance.

156

155

NG911 Transition Order

at *74, para. 215.

156

NG911 Transition Order

at *6, para. 14;

NG911 Notice,

38 FCC Rcd at 6209, para. 10.

We seek comment on how best to ensure that NG911 systems support interoperability for non-voice 911 services, with specific emphasis on text, video, and multimedia capabilities that support 911 access for people with disabilities. As noted above, NASNA's 2020 Interoperability Matrix reflected higher levels of interstate interoperability for 911 voice calls but no or low levels of interstate interoperability for all other services, including text-to-911 and MMES. We ask commenters to provide updated information on interstate 911 interoperability by type of service, with particular emphasis on services used by those with accessibility needs. For example, what are the current levels of interstate interoperability for the following types of service: (1) 911 voice calls; (2) location data; (3) text-to-911, including real-time text (RTT); and (4) MMES?

Text Messaging.

Regarding text messaging, in response to the

NG911 NPRM,

Google and NENA proposed that we consider the implementation of new interoperable messaging protocols, such as Rich Communications Service (RCS).

157

We seek comment on Google's view that, “[b]y addressing interoperable text messaging as part of its NG911 efforts, the Commission can further enable members of the public to connect to lifesaving resources, family members, and friends in a more effective and secure manner.” Do commenters agree with NENA and Google's concerns about text interoperability and comments about RCS, and if so, would RCS fall under our definition of “commonly accepted standards”? We seek comment more generally as to whether the public interest is better served by the Commission making such determinations in the short term or allowing the marketplace to make such determinations over a longer period of time. We also seek comment on whether there are interoperability problems in the commercial wireless market that are impeding end state end-to-end NG911? We invite commenters to comment on the specific connectivity, data transmission, and security issues Google describes as inherent in SMS/MMS. What options are currently available to address the aforementioned concerns as part of our certification requirements for CSPs, including intrastate interoperability requirements, and issues and what options do commenters foresee becoming available in the near-term and long-term?

157

Google Comments, PS Docket 21-479, at 9-11 (filed Aug. 10, 2023); NENA Reply Comments, PS Docket 21-479, at 9-10 (filed Sept. 6, 2023). RTT is available in some locations as a text-based communications technology for 911 purposes.

See

FCC,

Real-Time Text, www.fcc.gov/rtt

(Nov. 5, 2024).

Video.

Point-to-point video calls can be instrumental to demonstrate the emergency at hand in order to expedite the provision of appropriate emergency assistance. Additionally, people with disabilities may benefit from video calling in order to communicate more clearly in conjunction with other modalities such as text communications. We seek comment concerning accessibility with particular focus on measures we can take to promote interstate interoperability between ESInets.

158

In response to the

NG911 NPRM,

commenter Brian Rosen suggested that the Commission could adopt requirements to ensure ESInets support three-way video for Video Relay Service (VRS) within a reasonable period of time, such as 12 months. Further, three-way video has the potential to support individuals with speech disabilities relying on speech-to-speech relay services.

159

Rosen claims that many vendors of NGCS systems plan to support video in upcoming releases and suggests imposing a regulatory deadline to do so. In addition, Communication Service for the Deaf, Inc. states that video sign-language communications in NG911 systems could occur in different ways, including through standard VRS, three-way video relay services,

160

or direct video calling (DVC). DVC would allow a caller who uses sign language to place a call to a call taker who is both fluent in sign language and trained in handling emergency calls, potentially eliminating the need for a third-party intermediary.

161

Should we amend our rules to require that NGCS systems support three-way video for relay services, and support DVC? If so, within what time frame should such support be required for either service? What conditions or qualifications, if any, should be included in requirements associated with these video calls? We seek updated data on interstate interoperability needed to meet the needs of the accessibility community, including the feasibility of providing DVC or three-way video 911 calls that include VRS, and challenges with implementation during the transition to NG911 and relevant timelines.

162

158

NG911 Transition Order

at *17, para. 43. In the

NG911 Transition Order,

the Commission adopted an NG911 definition that includes accessibility as an essential requirement, consistent with the definition in the Spectrum Auction Reauthorization Act of 2023 (H.R. 3565), which requires that NG911 “be capable of processing `all types' of requests.” The Commission agreed that this requirement mandates that NG911 standards support accessible technologies.

NG911 Transition Order

at **14, 61, paras. 34, 179. The Commission declined, however, to expand the scope of the proceeding to consider accessibility issues raised in comments, but consistent with its authority under the CVAA, committed to monitor the development of NG911 systems and technologies and be prepared to take necessary steps to ensure that NG911 is fully accessible to all.

159

See, e.g.,

FCC,

Speech-to-Speech Relay Service (STS), www.fcc.gov/sts

(Jan. 28, 2025).

160

Communication Service for the Deaf, Inc.,

et al. Ex Parte,

PS Docket 21-479, at 2-3 (filed Mar. 12, 2025) (stating that traditional VRS uses a communications assistant fluent in sign language to enable a 911 caller to communicate through an intermediary, so that the VRS interpreter voices what the caller signs and signs back the call taker's response, while three-way video would allow the VRS caller, the 911 call taker, and the video interpreter to all be visible to each other on the same video call).

161

Id.

at 3.

See also Structure and Practices of the Video Relay Service Program,

CG Docket 10-51, Further Notice of Proposed Rulemaking, 32 FCC Rcd 2436, 2484, para. 125 (2017), 82 FR 17613 (Apr. 12, 2017), 82 FR 17754 (Apr. 13, 2017) (“A direct video calling (DVC) customer support service . . . permits individuals who are deaf, hard of hearing, deaf-blind, or have a speech disability . . . to engage in real-time video communication in ASL without using VRS. The purpose of DVC is to provide direct telephone service to such individuals that is functionally equivalent to voice communications service provided to hearing individuals who do not have speech disabilities.”).

162

Brian Rosen Comments, PS Docket 21-479, at 5 (filed July 28, 2023) (stating that from the very first version (NENA 08-003), three-way video was a firm requirement and that the requirement was there expressly for VRS: a VRS user should be able to dial 9-1-1 and be placed in a 3-way video call with the caller, the 911 call taker, and a sign language interpreter).

We further seek comment on any potential efficiencies that three-way video and DVC, respectively, would achieve for PSAPs in NG911 systems. Could three-way video improve accuracy and efficiency for 911 call handlers to take an emergency call and dispatch the right assistance? Could DVC improve accuracy and efficiency in the handling of emergency calls? Could emergency calling-trained DVC call handlers located at regional or nationwide PSAPs send electronic dispatchable reports directly to the local PSAP, eliminating the need for intermediary interpretation? To what extent would three-way video and DVC services need to rely on each other's facilities and capabilities?

163

What role

should Emergency Call Relay Centers play in processing DVC calls? Would it be possible to route these calls to a call taker at an Emergency Call Relay Center (ECRC), who would then transmit the caller's information to a dispatcher at the appropriate PSAP? Should the Commission require all VRS providers to direct all incoming 911 calls to an ECRC upon receipt, to facilitate such direct communication? What are the costs and benefits associated with each of these services? What modifications to the NG911 architecture would be needed to enable DVC calls? What modifications would be needed to enable three-way video?

163

Communication Service for the Deaf, Inc.,

et al. Ex Parte,

PS Docket 21-479, at 4 (filed Mar. 20, 2025) (“. . . ASL users use either a VRS app or a video communications device provided by their VRS provider to access 911 services. Each VRS company in turn contracts with an `Emergency Call Relay Center' provider to facilitate the routing and processing of their 911 calls to the caller's appropriate PSAP . . . If the ability to use DVC is integrated into the NG911 infrastructure, could 911 calls placed by ASL-fluent callers be placed directly

to an ASL-fluent 911 call taker without being routed through a VRS provider?”).

We also seek comment regarding current IP-based relay

164

provider capabilities and how to expand them. Do commenters agree that IP-based relay services providers currently supply a VoIP audio connection through a VPC, and that, to support video 911 calls, these providers would have to provide a video and audio connection, which current VPCs cannot handle? To enable IP-based relay services providers to support such calls, should we amend our rules to require ESInets to support internet connections, including video, via VPNs, to the ESInets, and if so, within what time frame, and subject to what conditions or qualifications? In that connection, do commenters agree with Brian Rosen that, to support three-way 911 video calls, IP-based relay providers would need to use the NGCS bridge, because bridges are used extensively in NG911 system to support attended transfer (so the call taker(s) can hear/see the call while they are completing the transfer—911 calls are not placed on hold)? If so, would this represent a change to their current process, which uses a Provider bridge, at least when supporting Voice carryover/hearing carryover? What are the costs associated with requiring three-way video support at the ESInet, and would such a requirement ensure equivalence for callers who are deaf or hard of hearing or have a speech disability?

164

This would include VRS, IP Relay Services, and certain forms of IP Captioned Telephone Services.

D. Implementation and Oversight

In order to assist in monitoring compliance with our proposed rules for NG911 reliability and interoperability, we propose to update our 911 reliability data collections and oversight mechanisms. In the

911 Reliability Order,

the Commission stated that “if a Covered 911 Service Provider certifies that it has taken alternative measures to mitigate the risk of failure, or that a certification element is not applicable to its network, its certification is subject to a more detailed Bureau review.”

165

If the Bureau's review indicates that a provider's alternative measures are not reasonably sufficient to ensure reliable 911 service, the Commission stated that the Bureau should first engage with the provider and other interested stakeholders (

e.g.,

affected PSAPs) to address any shortcomings. To the extent that such a collaborative process does not yield satisfactory results, the Commission stated that the Bureau may order remedial action consistent with its delegated authority.

166

The Commission intended this process to allow flexibility to employ alternative—but reliable—network designs and technologies, not to create an exception that would swallow the rule.

167

165

See

47 CFR 0.392(j);

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

166

See 911 Reliability Order,

28 FCC Rcd at 17497 para. 63.

167

2015 Reliability Recon. Order,

30 FCC Rcd at 8654-55, paras. 2, 10-11.

As discussed below, we believe that revised reporting requirements would be helpful to Commission staff and 911 Authorities in identifying risks to the reliability and interoperability of 911 traffic, including single points of failure, and ask commenters to identify specific information that providers should include in their certifications. We also seek comment on measures the Commission could take to limit the burden of reporting on NG911 reliability and interoperability. We also seek comment on how to better identify single points of failure that could have cascading effects on 911 traffic in multiple states. To what extent could the Commission limit the burden of any reporting requirements by providing increased flexibility for providers or businesses identified as small by the Small Business Administration?

168

We also propose to require disclosure of reliability and interoperability certifications to 911 Authorities. In that connection, we seek comment on establishing procedures for 911 Authorities to report concerns to the Bureau to conserve limited resources and focus attention on critical elements that could result in multistate outages or hamper interstate interoperability. We tentatively conclude that improving 911 Authorities' access to information about the 911 reliability measures in place within their states would amplify the Commission's ability to address potential risks to NG911 service and enable 911 Authorities to assess taking their own measures to prevent and mitigate disruptions to 911 service in their jurisdictions. We seek comment on this tentative conclusion and on the specific proposals below. In addition to enhancing reporting requirements for providers and improving information sharing with 911 Authorities, we seek comment on whether we should establish a dedicated consumer portal for 911-related outage complaints. Such a portal could provide the public with a clear and accessible means to report concerns about 911 service disruptions directly to the FCC. This approach may improve the Commission's ability to identify and address potential risks to NG911 reliability while empowering consumers to play a more active role in ensuring public safety. We invite input on the potential benefits of this proposal, including how it could complement existing reporting mechanisms and enhance transparency in addressing 911 service reliability.

168

For example, the Commission's requirements for live call data reporting provide a reduced reporting schedule for non-nationwide CMRS providers. 47 CFR 9.10(i)(3)(ii)(D).

1. Reform of Reliability Certification Process

Traditionally, NG911 CSPs select “alternative measures” to report reliability practices that differ from the legacy 911-specific best practice benchmarks articulated in our existing regulations, but which the Commission deemed reliable in the

2015 Reliability Recon. Order.

169

We seek comment on whether one potential improvement from today's proposed changes of both defining NG911 equivalents and functional equivalents and codifying the best practice measures applicable to IP-based networks would be allowing NG911 CSPs to directly certify that they meet the benchmarks specified in our regulations, instead of having to use the alternative measures option to report IP-based network reliability practices. We seek comment on the impact of this change, and on related proposed minor changes described below.

169

2015 Reliability Recon. Order,

30 FCC Rcd at 8656-57, paras. 12, 15.

In 2015, the Commission observed that NG911 networks achieve reliability and resiliency with geographic diversity and dynamic routing instead of traditional TDM circuit auditing and tagging, so the existing 911 reliability certification rules did not apply well to

NG911 networks.

170

The Commission similarly observed that the existing monitoring benchmark was appropriate for legacy 911 facilities but not IP facilities, as IP-based service providers do not “audit” monitoring circuits the way TDM providers do, but rather use the automated network monitoring capab

This text is long and has been trimmed here. Open the source document for the complete record.

This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.