# 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%3A2025-09279 ## Record - **Collection:** Federal Register - **Document type:** Proposed Rule - **Published:** June 4, 2025 - **Citation:** 90 FR 23768 ## 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. 1 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. 2 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. 3 1 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”). 2 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. 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. 4 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: 4 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. 5 5 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. 6 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. 7 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. 8 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.” 9 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.” 10 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.” 11 In addition, CSPs must notify PSAPs of network outages that may affect the PSAPs' ability to receive 911 calls. 12 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.” 13 6 911 Reliability Order, 28 FCC Rcd at 17477, para. 2. 7 Id. at 17477-78, paras 2-5; Derecho Report at 1-2. 8 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). 9 47 CFR 9.19(b). 10 47 CFR 9.19(c). 11 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 2015 Reliability Recon. Order, 30 FCC Rcd at 8656-58, paras. 14-20 (confirming that, under § 12.4 (now § 9.19) of the Commission's rules, CSPs may implement and certify an alternative measure for any of the specific 911 certification elements, as long as the certification includes an explanation of how such alternative measures are reasonably sufficient to mitigate the risk of failure). 12 911 Reliability Order, 28 FCC Rcd at 17526, para. 140; 47 CFR 4.9(h). 13 911 Reliability Order, 28 FCC Rcd at 17534, para. 163. These rules improved upon the pre-existing requirement of telecommunications carriers, commercial mobile radio service providers, and interconnected voice over internet protocol providers to transmit all 911 calls to PSAPs. See 47 CFR 9.4, 9.10(b), 9.11(b). Since the adoption of the 911 reliability rules in 2013, the Commission has revisited the rules on several occasions, but has not updated them to account for the transition to NG911. In 2014, the Commission issued a Policy Statement and NPRM on improving 911 governance and reliability, which reaffirmed the importance of 911 reliability and posited that changes in 911 technologies and a recent series of “sunny day” 911 outages indicated a potential need for further action. 14 Among the proposals advanced in the NPRM, the Commission sought comment on whether to broaden the definition of CSPs in former § 12.4 (now § 9.19). 15 14 911 Governance and Accountability, Improving 911 Reliability, Policy Statement and Notice of Proposed Rulemaking, PS Dockets 14-193 and 13-75, 29 FCC Rcd 14208, 14222, para. 32 (2014), 80 FR 3191 (Jan. 22, 2015) ( 2014 Reliability NPRM ). 15 Id. at 14225, para. 42. The 2014 Reliability NPRM also sought comment on ensuring transparency in connection with major changes in 911 service; ensuring reliability of IP-based 911 capabilities and services; and situational awareness and coordination of responsibility during outages. Id. at 14228, para. 48. Although the Commission did not act on the proposals from the 2014 Reliability NPRM, we incorporate comments filed in response to the NPRM into today's item. In 2015, the Commission issued a Reconsideration Order finding that the network reliability certification framework adopted in the 2013 911 Reliability Order was intended to allow flexibility for all CSPs to rely on reasonable alternative measures in lieu of any of the enumerated reliability practices set forth in former § 12.4(c) (now § 9.19(c)) of the rules, and that such flexibility was specifically intended to apply to the transition to NG911. 16 The Commission stated that “flexibility is essential to support and encourage the transition to NG911” and pointed out that, in the 911 Reliability Order, the Commission stated that “we intend today's rules to apply to current 911 networks, as well as NG911 networks to the extent they provide functionally equivalent capabilities to PSAPs.” 17 16 2015 Reliability Recon. Order, 30 FCC Rcd at 8654, para. 10. The Commission stated that the “overarching purpose of the certification, including the attestation of a responsible corporate officer, is to `hold service providers accountable for decisions affecting 911 reliability.' ” Id. (citing 911 Reliability Order, 28 FCC Rcd at 17495-96 paras. 54, 59; 47 CFR 12.4(a)(3) (2015) (now 47 CFR 9.19(a)(3)). The Commission emphasized that “[i]nflexible insistence on specified actions as part of each certification despite technical considerations that show those actions may not be appropriate in all cases would undermine this principle of flexibility without advancing the Commission's goal of improving 911 reliability.” Id. 17 Id.; 911 Reliability Order, 28 FCC Rcd at 17479, para. 9. In 2018, the Public Safety and Homeland Security Bureau (Bureau) issued a public notice seeking comment on the effectiveness of the 911 reliability rules, fulfilling a commitment made by the Commission in 2013 to reexamine the rules after five years to consider whether the rules were still “technologically appropriate and both adequate and necessary.” 18 In response to the 2018 Reliability Public Notice, the Bureau received ten comments and six reply comments from entities representing industry, local government, and the public safety community. 19 The Commission did not take further action following the public notice, leaving the 2013 rules in place. 18 Public Safety and Homeland Security Bureau Seeks Comment on 911 Network Reliability Rules, PS Docket No. 13-75, Public Notice, 33 FCC Rcd 5987, 5988 (2018) ( 2018 Reliability Public Notice ); 911 Reliability Order, 28 FCC Rcd at 17533, para. 159. 19 The commenters to the 2018 Reliability Public Notice were the Association of Public-Safety Communications Officials-International, Inc. (APCO); NENA: The 9-1-1 Association (NENA); West Safety Service; Alaska Communications; Texas 911 Alliance; Verizon; INdigital; USTelecom-The Broadband Association (USTelecom); Alliance for Telecommunications Industry Solutions (ATIS); Motorola; the Colorado Public Utilities Commission (Colorado PUC); AT&T; T-Mobile; CenturyLink; and the National Association of State 911 Administrators (NASNA). B. 911 Reliability Practices and CSRIC Recommendations In 2018, the Bureau disseminated lessons learned from major network outages and reminded and encouraged communications service providers to review industry best practices to ensure network reliability. 20 The Bureau 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 in promoting industry best practices. 21 Based on the Bureau's analysis of several major network outages that affected subscribers, including those calling 911 for emergency assistance, the Bureau staff determined that providers could have likely prevented or mitigated the outages by employing certain network reliability best practices. 22 The Bureau encouraged communications service providers to implement certain industry best practices, as previously recommended by the Commission's Communications Security, Reliability and Interoperability Council (CSRIC), 23 including practices that could prevent or mitigate similar outages in the future. 24 20 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, 3776 (PSHSB 2018) ( 2018 Best Practices PN ). 21 Id. 22 Id. 23 For a general overview of CSRIC see FCC, Communications Security, Reliability, and Interoperability Council, https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability-council-0 (last visited Feb 14, 2025). 24 2018 Best Practices PN at 3776-77. In 2019, in anticipation of additional entities transitioning to NG911, CSRIC VI issued a report and recommendations for 911 system reliability and resiliency. 25 The recommendations included measures to improve both legacy 911 and NG911, including ways in which the Commission could further the NG911 transition and enhance the reliability and effectiveness of NG911 through routing redundancy, maintenance, and mitigation of the threat of outages in both legacy 911 and NG911 systems. 26 The CSRIC recommendations address the need for service providers to (1) monitor for events resulting in loss of service; 27 (2) understand points of failure risks to (a) call delivery, (b) location delivery, and (c) callback information; 28 and (3) consider incorporating network detection tools and working with stakeholders to share information. 29 CSRIC VI also developed and recommended action for modifying or adding best practices regarding overall monitoring, reliability, notifications, and accountability in preventing 911 outages in transitional NG911 environments 30 as well as addressing cybersecurity considerations. 31 25 CSRIC VI Working Group 1, Final Report—Recommendations for 9-1-1 System Reliability 5 and Resiliency during the NG9-1-1 Transition 6 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 ). 26 Id. at 69. 27 Id. (“There is a need for Service Providers across all industry segments (cable, wireline, wireless, Interconnected VoIP) to be able to identify within their networks service-impacting events that impair or cause a total loss of service.”). 28 Id. at 70. 29 Id. (recommending (1) “Service Providers consider incorporating network detection tools, as appropriate, to assist network operations in detecting or deterring threats to 9-1-1 before they reach the ESInet perimeter” and (2) “Service Providers and other stakeholders work together to ensure that the system monitoring information that is needed to mitigate risks, monitor elements of the NG9-1-1 infrastructure and identify 9-1-1 outages is shared between providers and that the information is available to stakeholders when needed”). Working Group 1 also assessed the use of tools for Network Monitoring/Reporting to address the FCC's question: “Are there tools commercially available that can detect or deter to mitigate an outage?” The CSRIC VI, WG 1 Report included a matrix summarizing the responses and providing information “on tools used to detect, deter and mitigate network anomalies within the 9-1-1 networks infrastructure.” Id. at 70, Appendix A. 30 Id. at Appendix B. In addition, CSRIC VI offers recommendations on how small and rural carriers can transition to NG911 while minimizing risks of the transition, such as preventative measures to avoid service outages. See CSRIC VI, Working Group 1, Transition Path to NG9-1-1, Final Report—Small Carrier NG9-1-1 Transition Considerations (2018), https://www.fcc.gov/sites/default/files/csric6wg1sept18ng911report.docx. 31 CSRIC VI, WG 1 Report at 71 (recommending that (1) “stakeholders take deliberate steps to consider the cybersecurity implications introduced by the transition to NG9-1-1” and (2) “a future CSRIC focus on NG9-1-1 related cybersecurity challenges and develop Best Practices as appropriate”). In 2020, the Bureau updated the CSRIC Best Practices database. 32 The Bureau noted that CSRIC VII 33 unanimously approved an update to the database to include best practices from CSRIC VI (addressing communications network security, emergency preparedness, and disaster recovery) as well as the deletion of best practices that had become obsolete. The Bureau reminded and encouraged communications service providers to follow industry best practices to ensure network reliability, consistent with the CSRIC's recommendations, including ensuring (1) sufficient circuit diversity and alternative routing of 911 calls; (2) validating network changes in test environment, (3) using virtual interfaces and network management controls, and (4) making spare equipment available. 34 32 See Public Safety And Homeland Security Bureau Announces Updates To The Communications Security, Reliability, And Interoperability Council Best Practices Database, Public Notice, 35 FCC Rcd 577 (PSHSB 2020). The CSRIC Best Practices database can be accessed on the FCC website at https://opendata.fcc.gov/Public-Safety/CSRIC-Best-Practices/qb45-rw2t/data (last visited Feb. 14, 2025). 33 FCC, Communications Security, Reliability, and Interoperability Council VII, https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability-council-vii (last visited Feb. 14, 2025). 34 See Public Safety and Homeland Security Bureau Encourages Communications Service Providers to Implement Important Network Reliability Practices, Public Notice, PS Docket Nos. 11-60 and 20-183, 35 FCC Rcd 13179, 13179-80 (2020). C. 911 Interoperability While the Commission has not to date adopted rules relating to 911 interoperability, in 2019, it directed CSRIC VII to survey the state of interoperability for the nation's 911 systems, including for legacy 911, transitional 911, and NG911 networks. 35 In 2020, CSRIC VII Working Group 4 issued its report and recommendation on 911 interoperability, which were adopted by CSRIC VII. The report observed that 911 systems are highly interconnected, and interoperability between call-taking and call processing components is critical. 36 In addition, the report noted that “[l]egacy, transitioning, and fully NG911-capable systems capture and exchange potentially large amounts of data and transferring such data between 9-1-1 systems potentially requires external data connections.” 37 The report concluded that the state of national NG911 interoperability was 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. 38 The report 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.” 39 35 CSRIC VII, Report on the Current State of Interoperability in the Nation's 911 Systems (2020) ( CSRIC VII WG 4 Report ), https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability-council-vii. 36 CSRIC VII WG 4 Report at 5-6. 37 CSRIC VII WG 4 Report at 5-6. 38 CSRIC VII looked to the “maturity states” adopted by the FCC's earlier Task Force on Optimal Public Safety Answering Point Architecture (TFOPA) to guide its report formulation. See TFOPA, Working Group 2, Phase II Supplemental Report: NG9-1-1 Readiness Scorecard at 13 (2016), https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG2_Supplemental_Report-120216.pdf. The TFOPA defined states of transition ranging from today's legacy state through foundational, transitional, and intermediate states, culminating in the jurisdictional and nation-wide “end states” of NG911 service. Per TFOPA, “End State” refers to the state in which PSAPs have evolved to become emergency communications centers (ECCs); are served by standards-based NG911 systems and/or elements; 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. Id. 39 CSRIC VII WG 4 Report at 21-25. D. Next Generation 911 Transition Order In July 2024, the Commission adopted the NG911 Transition Order, which established rules to create a consistent NG911 transition framework at the national level while also affording flexibility to 911 Authorities to modify the transition framework at the state, regional, local, territorial, or Tribal level. 40 The new transition rules specify a two-phased approach to guide the transition to NG911, in which 911 Authorities initiate each phase by submitting a valid request to OSPs within the relevant jurisdiction and OSPs must comply with NG911 requirements for that phase within a defined period. As part of the order, the Commission adopted a definition of “Next Generation 911” that includes interoperability, security, use of commonly accepted standards, and other criteria as core elements of the definition. 41 The Commission also noted the potential for NG911 to support improved reliability and interoperability and that some commenters had urged us to consider specific reliability and interoperability requirements. 42 While the Commission deferred consideration of these issues in the Order, it recognized that they warranted further scrutiny. 43 40 NG911 Transition Order at *2, para. 2. 41 47 CFR 9.28. 42 NG911 Transition Order at **62-68, paras. 182-197. 43 Id. The definition of Next Generation 911 adopted in the NG911 Transition Order also requires that emergency communications centers— e.g., PSAPs—be able to receive, process, and analyze “all types” of 911 requests for emergency assistance. 44 The Commission explained that this language incorporates an accessibility component into the NG911 definition, and agreed with Communications Equality Advocates (CEA) that NG911 must support accessible technologies. 45 Several commenters urged the Commission to consider additional measures to enhance NG911 accessibility. While the Commission declined to address those proposals because they were outside the scope of that proceeding, it resolved to “continue to monitor the development of NG911 systems and technologies” and “to take steps as necessary to ensure that NG911 is fully accessible to all.” 46 44 47 CFR 9.28. 45 NG911 Transition Order at *17, para. 43. 46 Id. at *61, para. 179. Discussion A. The Need for Rules To Promote the Reliability and Interoperability of NG911 Networks NG911 architecture offers distinct advantages over legacy 911 technologies, including the possibility of greater reliability, redundancy, interoperability, and accessibility. 47 In order to realize these advantages, however, NG911 networks must be designed to ensure resiliency and avoid potential single points of failure. Unlike legacy 911 networks, in which 911 call routing and delivery by a CSP typically occurs within the same service area as the destination PSAP, NG911 networks frequently aggregate traffic from various OSPs and widespread regions and transport it to geographically distant network components for processing and eventual delivery to ESInets for routing to the appropriate PSAP. In addition, NG911 network providers often contract with third parties to operate servers and other critical facilities that support 911 call routing and other key functions in multiple states and jurisdictions. 48 Without measures to ensure the resiliency of these critical components, failure of NG911 networks can lead to large, multistate outages. The introduction of NG911 and IP-based technologies therefore requires collaboration between industry, public safety participants including 911 Authorities, and the Commission to ensure that technology-enabled optimization does not introduce unacceptable risks that imperil 911 reliability, resiliency, and accessibility. 49 47 Id. at *62-64, paras. 182-183, 185-186; id. at *63, para. 185 (agreeing with 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/ (quoting the Executive Director of North Carolina's state 911 board as crediting NG911 infrastructure for ensuring the continuity of 911 service through the Hurricane Helene disaster: “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.”). 48 FCC Public Safety and Homeland Security Bureau, April 2014 Multistate 911 Outage: Cause and Impact, PS Docket No. 14-72 at 1-2 (2014) ( 2014 Multistate 911 Outage Report ), https://www.fcc.gov/document/april-2014-multistate-911-outage-report. 49 See, e.g., NG911 Transition Order at **1, 12, 25, 60, 64, paras. 1, 29, 69, 176, 188. Since the Commission adopted the 911 reliability rules for CSPs in 2013, the nation has continued to experience periodic “sunny day” outages that have impaired the ability of millions of Americans to access 911. While many of these outages have been local, some have been large, multistate outages associated with IP-based networks. • In 2014, an outage in a service provider's 911 call-routing facility in Colorado caused 11 million people to lose 911 service for up to six hours, prevented emergency calls from reaching 81 PSAPs across seven states, and resulted in more than 6,600 calls to 911 never reaching a PSAP. • In 2018, a service provider experienced a nationwide outage on its fiber network that lasted for one and a half days, affecting 22 million customers across 39 states, including approximately 17 million customers across 29 states who lacked reliable access to 911. • In December 2022, an outage affected 911 calling for a service provider's VoIP customers in much of the South, and another service provider experienced two outages in 2022 disrupting 911 service to thousands in North Dakota and South Dakota for several hours. • In February 2024, a provider experienced a nationwide wireless service outage that lasted at least twelve hours and rendered all voice and 5G data services unavailable for all users. More than 92 million voice calls were blocked, including more than 25,000 calls to PSAPs. • In April 2024, a service provider experienced an outage caused by a cut fiber optic cable adjacent to its central office in Kansas City, Missouri. The outage disabled a portion of the provider's high-capacity transport network for 911 and non-911 traffic originated by various OSPs in different states, including 911 traffic that had first been collected by a 911 aggregator—a service provider that segregates and consolidates 911 calls from OSPs and routes them to the appropriate PSAP or ESInet. Some of these recent 911 outages have exposed possible gaps in the coverage of the existing 911 reliability rules applicable to CSPs. The current rules relating to “critical 911 circuits” require CSPs to certify whether they have eliminated all single points of failure between the selective router, ALI/ANI databases, or equivalent NG911 components, and the central office serving each PSAP. However, in some of the multistate outages noted above, the vulnerabilities contributing to the outage were found to exist at points in the 911 call flow downstream from the OSP (which is already required under § 9.4, 9.10, or 9.11 to transmit all 911 calls to PSAPs) but upstream from either the selective router in legacy 911 environments or the ESInet in transitional or NG911 environments. In many cases, those points are operated by third parties that transport 911 traffic over high-capacity fiber from OSP networks to the ESInets that directly serve PSAPs. In other cases, OSPs segregate their 911 traffic and hand it off to 911 aggregation services, which deliver 911 traffic consolidated from multiple OSPs to PSAPs and ESInets. When these transport and aggregation components fail, they can interrupt 911 call flow to many PSAPs. Yet, because these components do not deliver calls directly to PSAPs at the local level, providers can argue that the components fall outside of the scope of the current reliability rules, particularly in the NG911 environment. We therefore believe Commission action is needed to address the reliability of these critical facilities in NG911 ecosystems. We seek comment on this analysis. Another indicator of the need to revisit the 911 reliability rules for CSPs is that many of the multistate 911 outages reported to the Commission are “sympathetic” outages, i.e., outages reported by one entity that are caused by a failure in the network of another entity. 50 Based on the data available in NORS, there have been at least 92 reported “sympathetic,” multistate outages in 2024 alone. 51 The Commission has noted that these “sympathy reports contain information regarding service outages that, while caused by a failure in the network of another provider, nonetheless have an effect on the reporting service provider that may have public safety implications.” 52 The high frequency and widespread scope of these sympathetic outages highlights the degree to which carriers increasingly rely upon large third-party service providers to aggregate and transport their traffic. These sympathetic outages usually are outside the scope of the existing 911 reliability rules, because CSPs can claim such outages occur in network elements that do not directly serve PSAPs and because the 911 reliability rules do not apply to OSPs. As a result, sympathetic outages expose a potential gap between our outage reporting and reliability certification rules, and the Commission currently has a limited ability to correlate reliability certifications with multistate outages reported in NORS. 50 See Amendments to Part 4 of the Commission's Rules Concerning Disruptions to Communications, PS Docket No. 15-80, Second Report and Order, 36 FCC Rcd 6136, 6160, para. 77 & n.156 (2021), 86 FR 22796 (Apr. 29, 2021) ( NORS Information Sharing Order ). 51 This is based on reports identifying multiple states impacted by a reported outage, and does not include outages due to transport or SS7. 52 NORS Information Sharing Order, 36 FCC Rcd at 6160, para. 78. When the Commission adopted the 911 reliability rules for CSPs, it committed itself to review the rules in the future “to determine whether they are still technologically appropriate and both adequate and necessary to ensure reliability and resiliency of 911 networks.” 53 The Commission stated that it would consider “how NG911 networks may differ from legacy 911 service as well as outage reporting trends, adoption of NG911 capabilities on a nationwide basis, and whether the certification approach has yielded the necessary level of compliance.” 54 Given the recurrence of major, multistate 911 outages, we believe the 2013 rules are not sufficient to safeguard 911 service in an NG911 environment, and that there are several ways that the current rules could be improved. We seek comment on this analysis. 53 911 Reliability Order, 28 FCC Rcd at 17533, para. 159. 54 Id. First, the rules could more clearly specify which types of providers of NG911 capabilities qualify as CSPs that must comply with the reliability best practices in § 9.19 and file annual reliability certifications. The current rule refers to NG911 capabilities and/or “functional equivalents” of specified legacy capabilities. Although we believe that the Commission made clear its intent that NG911 capabilities be considered equivalent if they contribute to the routing of 911 traffic or to the storage or retrieval of associated location information, the generalized nature of this definition may explain why NG911 service providers are underrepresented among providers filing annual reliability certifications; of the 290 CSPs that filed 911 reliability certifications in 2024, only a small minority were NG911 providers. To the extent providers of NG911 capabilities are uncertain about whether they fall within the definition of CSPs, they also may not be implementing the Commission's reliability best practices. The need for updating our rules regarding covered NG911 facilities is heightened by the fact that the entities operating the legacy 911 facilities that are highlighted in the rules— i.e., selective routers and ALI/ANI databases—are retiring these facilities as they are superseded by NG911 networks. 55 As a consequence, continuing to rely solely on the 2013 rules to cover the transition from legacy 911 to NG911 could lead to reduced transparency and a weakening of reliability safeguards. Updating the rules to ensure that the functional equivalent standard clearly encompasses NG911 technology therefore should provide additional certainty that NG911 service providers are covered by our rules and improve the reliability practices of NG911 networks and the accessibility of NG911 service. We seek comment on our view that updating the rules is needed to address these issues. 55 NG911 Transition Order at *64, para. 186. The reliability rules also do not address interoperability between ESInets—understandably so given that few ESInets existed when the rules were adopted in 2013. It has become clear, however, that one of the greatest potential benefits of NG911 technology is its ability to empower PSAPs to use ESInets to seamlessly transfer 911 calls and associated call data to other PSAPs that are better positioned to respond and deploy resources for emergencies. This life-saving benefit is an emerging one, but its potential will be substantially diminished if PSAPs cannot transfer calls to nearby PSAPs located across a state border, or if someone must retranslate or reformat the traffic to allow transfers to occur. In order to ensure that this capability exists nationwide, we believe we should consider adopting interoperability standards to facilitate the interstate flow of information between ESInets. We seek comment on our view that interoperability requirements are needed. B. 911 Reliability 1. Expanding the Scope and Applicability of the 911 Reliability Rules To account for the transition from legacy 911 to NG911, we propose to modify our definition of “covered 911 service provider” as follows. First, we would specify certain NG911 capabilities that satisfy the “functional equivalent” capability language of the current rule. Second, we propose to modify the current rule regarding what “direct service” to a PSAP or other answering point means, codifying language from prior Commission orders. Third, we propose to add five new NG911 CSP categories to cover both the expanding network gap between OSPs and state and local governments and the increasingly interstate and interlinked nature of NG911 ecosystem facilities. We seek comment on these proposals. When the Commission adopted the reliability rules in 2013, it focused their application on service providers that, collectively, carry out the primary function of the 911 network: routing emergency calls to the geographically appropriate PSAP based on the caller's location. 56 The Commission recognized “that overbroad rules could inadvertently impose obligations on entities that provide peripheral support for NG911 but may not play a central role in ensuring 911 reliability[.]” 57 It therefore stated that it would only consider OSPs, internet service providers (ISPs), backhaul providers, aggregators, commercial data centers, and ESInets as CSPs to the extent they provide covered 911 capabilities directly to PSAPs. 58 The Commission further interpreted “direct” service to a PSAP to require a contractual arrangement or tariff agreement with the PSAP. 59 56 911 Reliability Order, 28 FCC Rcd at 17478, para. 7 (citing the Derecho Report at 25). 57 Id. at 17489, para. 37. 58 47 CFR 9.19(4)(i)(B); 911 Reliability Order, 28 FCC Rcd at 17490, para. 39. Backhaul providers offer the infrastructure necessary to transmit data from one network point to another, often over long distances. For example, a mobile carrier may rely on a third-party backhaul provider to carry data from rural cell towers to its main network. 59 2015 911 Reliability Recon. Order, 30 FCC Rcd at 8657, para. 17 (noting that CSPs are “the entities with direct contractual relationships with PSAPs”). The 911 facilities enumerated in the current definition of CSPs correspond to the rule's definition of “critical 911 circuits,” which comprise 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). 60 Critical 911 circuits also include ALI and ANI facilities that originate at the ALI or ANI database and terminate in the central office that serves the PSAP(s) to which the ALI or ANI databases deliver 911 caller information, including all equipment in the serving central office necessary for the delivery of such information to the PSAP(s). 61 60 47 CFR 9.19(5). 61 Id. When the Commission adopted the reliability rules in 2013, it declined to enumerate specific NG911 capabilities in the rules, because NG911 was still early in its development at that time, and the Commission expected that NG911 functionalities would evolve significantly in the future. 62 Instead, the Commission stated that it would consider NG911 service providers to be CSPs if they provided capabilities “functional[ly] equivalent” to the legacy routing capabilities enumerated in the rules or if they were the last service-provider facility connecting to a PSAP. 63 62 911 Reliability Order, 28 FCC Rcd at 17489, para. 36 & n.85. 63 47 CFR 9.19(4)(i). The Bureau issued a Public Notice in 2018 that revisited the definition of “covered 911 service providers.” 64 Public safety and governmental commenters broadly agreed that the current definition of CSPs is too narrow, noting that it excludes the growing class of critical NG911 services that are provided by subcontractors and other parties that have no contractual relationship with PSAPs and therefore do not “directly” serve a PSAP under the current rules. 65 APCO, for example, asked the Commission “to include any entity that provides 9-1-1, E9-1-1, or NG9-1-1 capabilities, directly or indirectly ” and reported that “entities without a direct relationship to a PSAP have found methods to impact the ALI, routing, or supplemental data relevant to a 9-1-1 call.” 66 The Colorado Public Utility Commission (COPUC) stated that the definition of CSPs “should encompass any service or network component that could potentially impact 9-1-1 call delivery to the PSAPs, even if that service or network component is not directly contracted to deliver 9-1-1 calls and location information to the [PSAP].” Comments from service providers mostly opposed broadening the definition of CSP. For example, the Alliance for Telecommunications Industry Solutions (ATIS) stated its belief that the current rules “adequately encompass transitional and NG9-1-1 networks,” and Motorola Solutions, Inc. (Motorola) requested that the definition be clarified by adding an express requirement that CSPs must have a direct contractual relationship with a PSAP. 64 2018 Reliability Public Notice, 33 FCC Rcd at 5989. 65 APCO Comments, PS Docket No. 13-75, at 1-2 (filed July 16, 2018); Daryl Branson, Colorado Public Utilities Commission Reply Comments, PS Docket No. 13-75, at 2 (filed Aug. 8, 2018); NENA Comments, PS Docket No. 13-75, at 1-2 (filed July 17, 2018); NASNA Reply Comments, PS Docket No. 13-75, at 2 (filed Aug. 13, 2018). See also 47 CFR 9.19(4)(i). 66 APCO Comments, PS Docket No. 13-75, at 2 (filed July 16, 2018) (emphasis in original); see also NENA Comments, PS Docket No. 13-75, at 1-2 (filed July 17, 2018) (suggesting that the databases and software underpinning the infrastructure of the NG911 network should be included). The NG911 Transition Order requires OSPs to provide SIP-based 911 traffic to 911 Authorities (typically via ESInets) to enable those authorities to establish NG911 networks in their states. While establishing NG911 service brings inherent potential advantages to reliability and interoperability, the Commission did not seek to amend the 911 reliability or outage notification rules in that proceeding. Nevertheless, certain commenters suggested that the Commission update its rules to better address network reliability in an NG911 environment, including to encompass emerging classes of NG911 service providers. 67 We agree, and we accordingly propose the measures described below. 67 See, e.g., Windstream Reply Comments, PS Docket 21-479, at 2-3 (filed Sept. 8, 2023) (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 21-479, at iii, 13 & n.6 (filed Aug. 9, 2023); see also NTCA Reply Comments, PS Docket 21-479, at 7-8 (filed Sept. 8, 2023). Specification of Certain NG911 “Functional Equivalents.” We propose to amend the definition of “covered 911 service provider” to specify that NGCS Routing Facilities and NGCS Location Facilities are examples of NG911 capabilities that are functionally equivalent to the legacy facilities enumerated in the rule ( i.e., selective routers and ALI/ANI databases). 68 We further propose to define these NG911 capabilities consistently with the definitions adopted in the NG911 Transition Order. Together, these amendments would provide greater specificity for providers of these equivalent NG911 capabilities that they qualify as CSPs and are subject to the reliability standards in § 9.19 and the reporting requirements in § 4.9. We seek comment on this proposal. 68 See proposed rules at §§ 9.19(a)(4)(i)(A), (B) and 9.19(a)(15)-(16). We believe that these proposed amendments are consistent with the Commission's intent in adopting the current rule and would provide additional guidance as to the types of NG911 network functions and their associated network elements that are the “functional equivalents” of covered legacy routing facilities. The Commission explained in the 911 Reliability Order that the routing of a legacy 911 call is accomplished via an aggregation point called a selective router, which identifies the PSAP that should receive the call based on the caller's phone number and address. 69 The selective router then determines the correct routing path for the call and transmits the call, 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 ALI and ANI databases before dispatching emergency services. Wireless 911 calls are routed similarly, but the caller's location must be determined using other technologies and third-party providers. 70 We set forth a simplified graphic representation of a legacy network below. Service providers operating the legacy facilities that perform essential routing and transmission capabilities— i.e., selective routers and ALI and ANI databases—are clearly defined as CSPs in the current rule. 71 69 911 Reliability Order, 28 FCC Rcd at 17478-79, paras. 7-8 (describing the typical legacy 911 call flow); NG911 Transition Order at *4, para. 10. 70 911 Reliability Order, 28 FCC Rcd at 17478-79, paras. 7-8. 71 47 CFR 9.19(4)(i). See also NG911 Transition Order at *4, para. 10 (legacy network diagram). The acronym MSAG refers to the Master Street Address Guide, which is replaced by the LVF in NG911 networks, while ANI/ALI databases are replaced by LISs. NG911 Transition Order at *31, para. 86. EP04JN25.000 In the NG911 Transition Order, the Commission recognized that “[t]he transition to NG911 involves fundamental changes in the technology . . . use[d] to receive and process 911 traffic, and it requires equally fundamental changes in the way OSPs deliver 911 traffic to PSAPs.” 72 The default NG911 rules adopted in the NG911 Transition Order require OSPs to deliver 911 traffic to an NG911 Delivery Point that each 911 Authority may designate within its state or territory. 73 From that demarcation hand-off point, 911 Authorities are responsible for transmitting 911 traffic to the PSAP(s), which may be accomplished through a combination of interconnected NGCS provided via the 911 Authority's ESInet(s). 74 These services may include Location Validation Functions (LVFs), Geographic Information Systems (GISs), Emergency Services Routing Proxies (ESRPs), Emergency Call Routing Functions (ECRFs), and Policy Routing Functions (PRFs). 75 The LVF is a server that validates civic location information against a GIS database to deliver more dynamic and actionable information about a caller's location than legacy ALI/ANI databases can. 76 GIS is a mapping system that collects, stores, and analyzes spatial data, ensuring that emergency services can pinpoint where to send help. 77 Next, an ESRP, which is a routing engine that determines the next hop for the 911 call, queries an ECRF, which is a database function that determines the appropriate destination PSAP by mapping the caller's validated location to maps with the boundaries of emergency response zones. 78 The call then is routed to the geographically appropriate PSAP in accordance with the PRF, which is a ruleset that decides how the call should be routed based on predetermined policies ( e.g., priority levels, time of day, and load balancing). 79 We set forth a simplified graphic representation of a Phase 2 NG911 network below. 80 72 NG911 Transition Order at *12, para. 28. 73 See id. at *26, para. 71. 74 See id. at *3, para. 6. 75 See id. at **28-29, para. 79 (NG911 network diagram). 76 Id. at **28, 31, paras. 78, 86; 47 CFR 9.28 (“An LVF is functional element in NG911 Core Services (NGCS) consisting of a server where civic location information is validated against the authoritative Geographic Information System (GIS) database information. A civic address is considered valid if it can be located within the database uniquely, is suitable to provide an accurate route for an emergency call, and is adequate and specific enough to direct responders to the right location.”). 77 NG911 Transition Order at *65, para. 191; see generally NENA, NENA i3 Standard for Next Generation 9-1-1 at § 4 (Oct. 7, 2021), https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-STA-010.3e-2021_i3_Stan.pdf ( NENA i3 Standard ) (describing standard NGCS functions). 78 NG911 Transition Order at *7, para. 17 & n.57; NENA i3 Standard, § 4. 79 NG911 Transition Order at *65, para. 189, n.560; NENA i3 Standard, § 4. 80 NG911 Transition Order at *28, para. 79 (NG911 network diagram). The acronym BCF in the diagram refers to the Border Control Function, which acts as a firewall between the ESInet and external networks. EP04JN25.001 We believe the LVF and GIS core services are NG911 capabilities that are functionally equivalent to the ALI/ANI databases used in legacy networks. While they are not identical in a technical or engineering sense, we believe that these NGCS Location Facilities are equivalent in a functional sense because they similarly validate the 911 caller's location by reference to databases of geographical and civic data using information about the caller that has been provided by their OSP. 81 In turn, we believe that the ESRP, ECRF, and PRF core services are NG911 capabilities that are functionally equivalent to legacy selective routers, because they similarly determine the path along which to route 911 traffic so that it reaches the appropriate PSAP. 82 We refer to them collectively as NGCS Routing Facilities. 81 See, e.g., NG911 Transition Order at *64, para. 186 (“ALI/ANI databases will be replaced with IP-based systems with more precise location information[.]”). 82 See, e.g., id. at *64, para. 186 (“Selective routers will be replaced with NGCS IP routing at the ESInet[.]”). As has always been the case with § 9.19, this proposal, as well as those described below, are service provider agnostic. In other words, rather than designate certain entities as CSPs by virtue of regulatory status or industry category, we propose to continue to focus on the services provided and the facilities operated. We seek to preserve flexibility in a rapidly evolving technology market so that only entities that ultimately provide critical 911 functions in an NG911 environment are the ones subject to our rules. The goal is to ensure reliability, interoperability, and accessibility of critical NG911 facilities, not to predetermine market outcomes or to usurp or constrain state and local government decision-making. We seek comment on these proposals and our analysis. Does the current definition of CSPs sufficiently encapsulate NG911 service providers, or should the definition specify which NG911 capabilities are the “functional equivalent” of the covered legacy routing and transmission services? Are LVFs, GISs, ESRPs, ECRFs, and PRFs examples of such functionally equivalent capabilities? Are these capabilities usually performed by non-governmental entities ( e.g., via contracts or agreements) or are there instances where they are performed directly by governmental entities? Are there other NG911 facilities or services that constitute functional equivalents? If so, what functions do they perform, and which legacy elements do they replace? Because CSPs may not uniformly fit the definition of “telecommunications carriers,” should we clarify that, similar to the requirement in § 9.4 of the Commission's rules, CSPs are required to transmit all 911 calls they receive to PSAPs? If not, on what basis should we treat CSPs differently from telecommunications carriers? We also request estimates of any new costs that would be caused by expanding the CSP definition in this manner. As we propose to expand the classes of entities covered by our NG911 reliability rules to ensure that the rules capture entities that perform critical NG911 functions, we seek comment on whether we should conform § 4.5(e) in our outage reporting rules to similarly reflect this change. While § 4.5(e) already applies to NG911 outages, it does not specifically reference outages within the NG911 ecosystem facilities that we propose to define as critical ( e.g., Major Transport Providers, ESInet interconnection facilities, NGCS facilities, etc.). 83 Should these facilities be identified explicitly in the rule, and, if so, how? We also seek comment on whether we should amend the outage-reporting thresholds in § 4.5(e) to reflect additional outage impacts that are specific to the types of NG911 ecosystem facilities that we address in our proposed 911 reliability rules. If so, what should those NG911-specific outage effects be? The current rule includes a threshold of 900,000 user-minutes of lost communication with PSAPs. Are user-minutes (as defined in § 4.7(e)) the appropriate metric for outages that are specific to NG911 facilities? 84 If not, what metric would be appropriate? 83 We note that an outage that exhibits any of the effects of an outage described in § 4.5(e) would qualify as an “outage that potentially affects a 911 special facility,” regardless of whether the underlying 911 service is legacy 911 or NG911. See 47 CFR 4.5(e). 84 ATIS argued in a prior proceeding that the outage threshold calculations set forth in §§ 4.5(e) and 4.7(e) are unsuitable for NG911 networks and that NG911 outage thresholds should be determined based on census or population data. See ATIS Comments, PS Docket Nos. 15-80, 13-75, at 15-16 (filed Jul. 30, 2021) (“Unlike legacy 911 systems, NG911 systems using the i3 architecture do not have access to telephone number counts. Legacy systems match a caller's phone number with information in the [MSAG] to determine a caller's location. With NG911 systems, calls are validated and routed using [GIS] data rather than the MSAG. Without telephone number counts, [CSPs] cannot calculate the number of user minutes potentially affected by an outage under Section 4.7(e) and thus cannot determine whether an outage potentially affects a 911 special facility under Section 4.5(e).”). Direct vs. Indirect Relationships with PSAPs. We propose to modify the requirement in the rules that providers of NG911 equivalent functionalities must “directly” serve a PSAP or other answering point in order to qualify as a CSP. The Commission included the “direct service” limitation in the original reliability rules to avoid imposing obligations on providers that “may not play a central role in ensuring 911 reliability.” 85 The Commission also recognized, however, that the scope of the CSP definition might need to “be revised or expanded to cover . . . additional entities that provide NG911 capabilities, or in light of our understanding about how NG911 networks may differ from legacy 911 service.” 86 85 911 Reliability Order, 28 FCC Rcd at 17489, para. 37. 86 Id. at 17533, para. 159. Modern NG911 networks have evolved to route 911 calls to PSAPs very differently from legacy architectures. In legacy networks, PSAPs typically contract with a single entity (such as an ILEC) to receive routing and location information services via a selective router and access to ALI and ANI databases, and they typically contract with the same entity to receive call delivery via trunk lines from the entity's nearest central office. 87 In contrast, NG911 routing is performed by many dispersed functional elements that may be operated by a variety of service providers, including OSPs, ESInet providers, their contractors, and other parties. 88 A PSAP or 911 Authority may not have contractual relationships with any or all of these entities. 87 2014 Multistate 911 Outage Report at 1-2, 14. 88 NG911 Transition Order at *64, para. 186; 2014 Multistate 911 Outage Report at 1-2. We believe it is important that indirect providers of essential NG911 services comply with reliability best practices. As noted above, there was strong support for doing so among public safety and government commenters that responded to the 2018 Reliability Public Notice. We are concerned, however, that including all indirect service providers within the definition of CSPs could unnecessarily increase the number of service providers that must file reliability certifications each year well beyond the increase we anticipate as a result of specifying certain NG911 capabilities that are “functionally equivalent” to covered legacy capabilities. That increase could drive up the operating costs of service providers—and, consequently, the costs for individual subscribers and 911 Authorities—and could interfere with the Commission's ability to closely review reliability certifications to identify and address problems. We think the solution that best accomplishes our objective—while avoiding unnecessarily-burdensome certification and outage notification requirements—is to retain the direct service requirement but amend § 9.19 to state that CSPs directly serving PSAPs are responsible for ensuring the reliability of all of the NG911 capabilities they provide to the PSAP, whether through contractors of any tier, vendors, or via leased facilities. This proposal largely would be a codification of the longstanding principle that CSPs must comply with § 9.19 reliability practices for facilities they lease from other parties, while the lessors themselves do not become subject to § 9.19 reporting requirements by making their facilities available to a CSP. 89 We believe this codification would ensure that reliability measures apply to essential NG911 functions while avoiding unnecessary burdens on providers and unnecessary distractions to PSAPs and 911 Authorities. 89 2015 911 Reliability Recon. Order, 30 FCC Rcd at 8657, para. 17 (“ `[I]n cases where a party provides 911 services directly to a PSAP (pursuant to contract or tariff) over leased facilities, the auditing obligation would apply to that party, and not to the facilities lessor.' The Commission also suggested that [CSPs] could contract with facilities lessors, if necessary, to audit and tag leased circuits, but that the entity providing 911 service under a direct contractual relationship with each PSAP would remain responsible for certifying compliance with those requirements. We reaffirm those principles here, but clarify that [CSPs] ( i.e., the entities with direct contractual relationships with PSAPs) that rely on such contracts may implement and certify reasonable alternative measures as set forth above. We emphasize, however, that the contracting out of certain functions, or the determination of a PSAP to contract with more than one entity for various aspects of 911 service, does not absolve individual entities of their respective obligations for reliable 911 service.”) (citing 911 Reliability Order, 28 FCC Rcd at 17506, para. 90); see also, e.g., Eure Family Limited Partnership, Memorandum Opinion and Order, 17 FCC Rcd 21861, 21863-64, para. 7 (2002) (“[T]he Commission has long held that licensees and other Commission regulatees are responsible for the acts and omissions of their employees and independent contractors.”); FCC, Frequently Asked Questions: FCC 911 Reliability Certification, https://www.fcc.gov/frequently-asked-questions-fcc-911-reliability-certification#whocertify (last visited Feb. 14, 2025) (“Where a Covered 911 Service Provider provides 911 services directly to a PSAP (pursuant to contract or tariff) over leased facilities, the circuit auditing obligation applies to the Covered 911 Service Provider, and not to the facilities lessor. Companies that directly serve PSAPs over leased facilities may contract with the lessor to audit those circuits or to provide some other assurance that they are physically diverse, but only the company with a direct relationship to the PSAP is responsible for certification.”). We seek comment on this proposal. Should providers of NG911 routing and transmission services be explicitly included in the definition of CSPs if they do not serve PSAPs directly? As the transition to NG911 has advanced, how typical is it for these types of services to be provided indirectly by entities with no contractual relationships with PSAPs? How are the relationships with these entities structured or memorialized? Would retaining the “direct service” requirement provide adequate oversight to the Commission and 911 Authorities? What advantages and disadvantages would this approach bring in contrast with simply requiring third-party, indirect providers to submit their own certifications? What would the cost impact be? We also invite feedback on whether the proposed rules could hamper the flexibility of 911 Authorities to manage the implementation of NG911 in their jurisdictions. Would the rules interfere with 911 Authorities' procurement processes or unduly impact the cost of NG911 services? Would any of our proposals, if adopted, result in any existing contracts or agreements needing to be terminated or renegotiated, and, if yes, would that impact 911 service or costs or delay the transition to NG911? Would governmental entities prefer to have more or sole discretion over minimum reliability requirements or practices in their jurisdictions? How would eliminating the direct service limitation impact NG911 transition costs, and could it inadvertently slow NG911 deployments or discourage new market entrants? We note that, during investigations of 911 outages, it is common for service providers to claim that they are contractually prohibited from sharing their contractors' confidential business information. 90 In response to one such claim, BRETSA argued that “[i]f providers are contractually restricted from cooperating to provide information as to callers unable to reach 9-1-1 during an outage, then the Commission and the states must adopt rules permitting and requiring all providers to cooperate in supplying such information to PSAPs.” How should the Commission address confidentiality concerns of indirect service providers? What is the appropriate balance for protecting and safeguarding non-public information ( e.g., proprietary business information) and creating and maintaining a reliable and resilient 911 system? Should 911 Authorities be allowed access to reliability certifications, and associated information, relating to indirect providers in addition to the certifications, and associated information, of CSPs? 90 See, e.g., 2014 Multistate 911 Outage Report at 21-22 (“Intrado suggests that it is contractually precluded from providing the Commission or PSAPs with a clear understanding of what happened, adding that its business units are under contract to varying service providers and government agencies, and that `those contracts are strictly honored.' ” Intrado further asserted that “it would be improper for [it] to `cross the lines' established by its customers relative to information considered by them to be confidential in order for Intrado to `glue together' a more complete picture of an outage for other parties, including, as the case may be, PSAPs or the Commission[.]”). Encompassing Other Essential NG911 Services. In order to improve the reliability of essential NG911 ecosystem facilities, we propose to add to the definition of “covered 911 service provider” the following classes of service providers that have emerged as critical to NG911 services: (1) operators of “a Location Information Server (LIS) . . . or equivalent IP 911 location database;” (2) operators of “a Legacy Network Gateway (LNG) used for conversion of Time Division Multiplexing (TDM) 911 traffic to Session Initiation Protocol (SIP) . . .;” (3) operators of Major Transport Facilities, which are “[d]edicated SIP transport facilities meeting or exceeding Optical Carrier 3 (OC3) in capacity that collect and/or transmit IP 911 traffic, either segregated or mixed with non-911 traffic, originated from multiple OSPs and transported over interstate routes, for ultimate transport and delivery to an NG911 Delivery Point or ESInet”; (4) operators of IP Traffic Aggregation Facilities, which are “[f]acilities that collect and segregate IP 911 traffic from non-911 traffic for multiple OSPs, or transport such traffic for ultimate delivery to an NG911 Delivery Point or ESInet;” and (5) operators of “interstate interconnecting facilities between ESInets.” 91 We seek comment on this proposal, as discussed in further detail below. 91 See proposed rules at §§ 9.19(a)(4)(i)(C) through (G), 9.19(a)(12) and (13). a. Operators of LISs and LNGs The framework adopted in the NG911 Transition Order addresses technology changes that are occurring in NG911 networks over the entire course of the 911 call flow, from origination to delivery to PSAPs. The in-state or in-territory NG911 Delivery Point serves as the demarcation point that presumptively divides responsibility for processing and transmitting NG911 traffic between OSPs on the one hand and 911 Authorities on the other. 92 The NGCS Location Facilities and NGCS Routing Facilities we discuss above address NG911 core services that are being provided on the 911 Authority side of the demarcation point. 92 NG911 Transition Order at *3, 26, paras. 6, 71. The NG911 Transition Order does not place any affirmative requirements on 911 Authorities. Instead, it invites 911 Authorities to adopt the Commission's NG911 framework, and, if they do, OSPs providing NG911 service to the 911 Authorities are assigned a series of performance and cost obligations from origination to the demarcation point in the absence of an alternate agreement with the 911 Authority. See id. at *2-3, paras. 2-7. On the OSP side of the demarcation point, the NG911 Transition Order requires OSPs that receive a valid request for NG911 service to incorporate certain NG911 functional elements into their networks, because those elements are necessary in order for ESInets to be able to route and deliver NG911 traffic and to provide their full array of core services. First, the NG911 Transition Order requires OSPs to put into operation a LIS or its functional equivalent (or to acquire equivalent services from a third party) in order to verify their customers' location information. 93 That location information is then embedded with the 911 call and delivered to an NG911 Delivery Point or ESInet and is used by the ESInet's NGCS Location Facilities and NGCS Routing Facilities to route and deliver 911 calls. Second, in some cases, OSPs may be using an LNG (or acquiring equivalent services), in order to translate TDM-originated 911 traffic into SIP format before the 911 traffic is handed off to the ESInet. 94 93 Id. at *2, para. 3. 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). 94 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. 95 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. 95 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. 96 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[.]” 97 96 See proposed rules at §§ 9.19(a)(4)(i)(E), 9.19(a)(12). 97 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. 98 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.” 99 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. 98 See proposed rules at §§ 9.19(a)(4)(i)(F), 9.19(a)(13). 99 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. v. 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 Public Serv. Co. v. FCC, 328 F.3d 675, 680 (D.C. Cir. 2003) (“In its analysis, the FCC approved of the Bureau's assessment of the prevailing industry standards” to determine a reasonable pole attachment rate.). 111 47 CFR 9.19(b) (“Performance of the elements of the certification set forth in [paragraph c] of this section shall be deemed to satisfy the requirements of this paragraph.”). Importantly, our proposed approach would retain the current structure of the 911 reliability regulations, which imposes a reliability “reasonableness” standard on all CSPs, subject to equitable remediation orders by the Bureau for failure to demonstrate reasonableness of network practices. 112 We propose to continue to allow CSPs to achieve presumptive reasonableness for specified CSP facilities by affirmatively implementing network practices described in the regulations. 113 This structure is designed to enable the Bureau to investigate 114 and validate network reliability based on filed certifications which show how well and how much of a CSP's network meets the Commission's standards. This process in turn enables the Commission to take preemptive actions to prevent outages before they occur. Bureau investigations can proceed by asking CSPs to provide information about the costs they would incur to upgrade their network reliability measures and assessing, from a cost-benefit standpoint, whether incurring such cost would be reasonable in light of the increased risk of critical 911 facility failure created by the CSPs' existing measures. 112 911 Reliability Order, 28 FCC Rcd at 17492, para. 44 (“As discussed below, we adopt rules to require that Covered 911 Service Providers (1) take reasonable measures to ensure reliable 911 service and (2) certify annually that they do so by adhering either to specified, essential practices based on established industry consensus or to appropriate alternative measures demonstrated to be reasonably sufficient to mitigate the risk of failure.”). 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 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. 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 CenturyLink Communications, LLC d/b/a Lumen Technologies Group's Responses to Commission Staff's First Set of Data Requests, at 4 (Dec. 1, 2023) (“Because of this outage, impacted calls never reached the NG911 network. The outage also impacted the SS7 links that connected to the [] aggregation point, preventing some OSPs' 911 calls from completing from that aggregation point.”), https://psc.nebraska.gov/sites/psc.nebraska.gov/files/doc/Exhibit%20List%20%26%20Exhibit%201-30.pdf. Finally, we seek comment on whether our proposed reliability measure for IP physical diversity is sufficiently inclusive, and on the likely compliance costs and lives-saved benefits from adopting this rule. 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. 137 Does the explicit inclusion of major transport paths and 911 aggregator networks capture enough of the critical 911 bottleneck infrastructure to reasonably improve 911 reliability? Or does this proposal sweep too many OSP operators of IP traffic-aggregated paths into the CSP category, and if so, what metric could be used to better distinguish the most critical 911 transport and aggregation points and paths which should be covered in an NG911 environment? Should we also designate additional paths to and from the LIS as covered critical paths, or would that expand the CSP category too far to include the majority of OSPs? In the alternative, should LIS and LNG operators be at least required to ensure physically diverse ingress and egress points from their facilities? What would the additional costs be of such an expansion of this benchmark? 137 NG911 Transition Order at *47, para. 140 (commenters argue “the Commission should establish rules requiring the transport of 911 traffic over dedicated SIP lines, and highlight that there are several options available to OSPs to comply with IP delivery rules with varying reliability . . . . We decline to establish the requested rules . . . . At this time, we provide flexibility to 911 Authorities, in concert with their NG911 vendors, to determine the IP-based SIP format to request from OSPs.”); NG911 Transition Order at *47, para. 140, n.414 (commenters ask the Commission to consider the costs of routing 911 traffic over a “dedicated connection” as opposed to “best efforts public internet connections”) (internal citations omitted). (ii) Network Monitoring In the 911 reliability rules adopted in 2013, the Commission required CSPs to certify whether they have taken the following steps to ensure reliable monitoring of critical components of their networks: (a) conducting audits of aggregation points for gathering network monitoring data, (b) conducting audits of monitoring links, and (c) implementing physically diverse aggregation points and links. 138 We propose to expand this existing requirement—which requires physical diversity between monitoring points and physically diverse links to network operations center (NOC) control points—by also including appropriate NG911 monitoring technologies identified in prior Commission orders as methods of compliance. 139 138 See 47 CFR 9.19(c)(3)(i). 139 CSRIC VI, WG 1 Report at 52 (“The NG9-1-1 SSP will be responsible for monitoring IP connections for transport alarms. Where appropriate, heartbeats may be used to verify the availability of network facilities. NG9-1-1SSPs should provide the means for capturing n [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%3A2025-09279. Public record. Not legal advice.