Home/Federal/Federal Register/2025-09279

Proposed Rule2025-09279

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

Primary source

Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.

Published

June 4, 2025

Effective

July 21, 2025

Issuing agencies

Federal Communications Commission

Abstract

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.

Full Text

<html>
<head>
<title>Federal Register, Volume 90 Issue 106 (Wednesday, June 4, 2025)</title>
</head>
<body><pre>
[Federal Register Volume 90, Number 106 (Wednesday, June 4, 2025)]
[Proposed Rules]
[Pages 23768-23811]
From the Federal Register Online via the Government Publishing Office [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2025-09279]

[[Page 23767]]

Vol. 90

Wednesday,

No. 106

June 4, 2025

Part II

Federal Communications Commission

-----------------------------------------------------------------------

47 CFR Parts 0 and 9

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

Federal Register / Vol. 90 , No. 106 / Wednesday, June 4, 2025 /
Proposed Rules

[[Page 23768]]

-----------------------------------------------------------------------

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 Sec. Sec. 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), <a href="https://www.govinfo.gov/content/pkg/FR-1998-05-01/pdf/98-10310.pdf">https://www.govinfo.gov/content/pkg/FR-1998-05-01/pdf/98-10310.pdf</a>. You may submit comments,
identified by PS Docket Nos. 21-479 and 13-75, by any of the following
methods:
<bullet> Electronic Filers: Comments may be filed electronically
using the internet by accessing the ECFS: <a href="https://www.fcc.gov/ecfs">https://www.fcc.gov/ecfs</a>.
<bullet> Paper Filers: Parties who choose to file by paper must
file an original and one copy of each filing.
<bullet> 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.
<bullet> 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.
<bullet> 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.
<bullet> People With Disabilities: To request materials in
accessible formats for people with disabilities (braille, large print,
electronic files, audio format), send an email to <a href="/cdn-cgi/l/email-protection#4f292c2c7a7f7b0f292c2c61282039">[email&#160;protected]</a> or
call the Consumer & Governmental Affairs Bureau at 202-418-0530.

FOR FURTHER INFORMATION CONTACT: Chris Fedeli,
<a href="/cdn-cgi/l/email-protection#c784afb5aeb4b3a8b7afa2b5e981a2a3a2abae87a1a4a4e9a0a8b1">[email&#160;protected]</a> or 202-418-1514, or Daniel Spurlock,
<a href="/cdn-cgi/l/email-protection#9adefbf4f3fff6b4c9eaefe8f6f5f9f1dafcf9f9b4fdf5ec">[email&#160;protected]</a> 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 <a href="https://docs.fcc.gov/public/attachments/FCC-25-21A1.pdf">https://docs.fcc.gov/public/attachments/FCC-25-21A1.pdf</a>.
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 <a href="https://www.fcc.gov/proposed-rulemakings">https://www.fcc.gov/proposed-rulemakings</a>.

[[Page 23769]]

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), <a href="http://www.fcc.gov/document/derecho-report-and-recommendations">http://www.fcc.gov/document/derecho-report-and-recommendations</a>. 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).
---------------------------------------------------------------------------

<bullet> 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.
[cir] 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.
[cir] 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 Sec. 9.10(a); covered text
providers, as defined in Sec. 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 Sec. Sec. 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 Sec. 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.
---------------------------------------------------------------------------

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

[[Page 23770]]

<bullet> 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.
<bullet> 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 Sec. 12.4 (now Sec. 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 Sec. 12.4 (now Sec. 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 Sec. 12.4(c) (now
Sec. 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

[[Page 23771]]

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 (<a href="http://www.fcc.gov/network-reliability-resources">http://www.fcc.gov/network-reliability-resources</a>) 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, <a href="https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability-council-0">https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability-council-0</a> (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), <a href="https://www.fcc.gov/sites/default/files/csric6wg1_finalreport_030819.pdf">https://www.fcc.gov/sites/default/files/csric6wg1_finalreport_030819.pdf</a> (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), <a href="https://www.fcc.gov/sites/default/files/csric6wg1sept18ng911report.docx">https://www.fcc.gov/sites/default/files/csric6wg1sept18ng911report.docx</a>.
\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 <a href="https://opendata.fcc.gov/Public-Safety/CSRIC-Best-Practices/qb45-rw2t/data">https://opendata.fcc.gov/Public-Safety/CSRIC-Best-Practices/qb45-rw2t/data</a> (last visited Feb. 14,
2025).
\33\ FCC, Communications Security, Reliability, and
Interoperability Council VII, <a href="https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability-council-vii">https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability-council-vii</a> (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,

[[Page 23772]]

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), <a href="https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability-council-vii">https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability-council-vii</a>.
\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), <a href="https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG2_Supplemental_Report-120216.pdf">https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG2_Supplemental_Report-120216.pdf</a>. 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), <a href="https://statescoop.com/north-carolina-next-generation-911-hurricane-helene/">https://statescoop.com/north-carolina-next-generation-911-hurricane-helene/</a> (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), <a href="https://www.fcc.gov/document/april-2014-multistate-911-outage-report">https://www.fcc.gov/document/april-2014-multistate-911-outage-report</a>.
\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.
<bullet> 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,

[[Page 23773]]

and resulted in more than 6,600 calls to 911 never reaching a PSAP.
<bullet> 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.
<bullet> 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.
<bullet> 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.
<bullet> 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 Sec. 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 Sec. 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

[[Page 23774]]

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

[[Page 23775]]

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
Sec. 9.19 and the reporting requirements in Sec. 4.9. We seek comment
on this proposal.
---------------------------------------------------------------------------

\68\ See proposed rules at Sec. Sec. 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.
[GRAPHIC] [TIFF OMITTED] TP04JN25.000

[[Page 23776]]

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 Sec. 4 (Oct. 7,
2021), <a href="https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-STA-010.3e-2021_i3_Stan.pdf">https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-STA-010.3e-2021_i3_Stan.pdf</a> (NENA i3 Standard) (describing
standard NGCS functions).
\78\ NG911 Transition Order at *7, para. 17 & n.57; NENA i3
Standard, Sec. 4.
\79\ NG911 Transition Order at *65, para. 189, n.560; NENA i3
Standard, Sec. 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.
[GRAPHIC] [TIFF OMITTED] TP04JN25.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

[[Page 23777]]

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 Sec. 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 Sec. 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 Sec. 4.5(e) in our outage reporting rules to similarly reflect
this change. While Sec. 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 Sec. 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 Sec. 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 Sec. 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 Sec. Sec. 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
Sec. 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

[[Page 23778]]

must comply with Sec. 9.19 reliability practices for facilities they
lease from other parties, while the lessors themselves do not become
subject to Sec. 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, <a href="https://www.fcc.gov/frequently-asked-questions-fcc-911-reliability-certification#whocertify">https://www.fcc.gov/frequently-asked-questions-fcc-911-reliability-certification#whocertify</a> (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 Sec. Sec. 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

[[Page 23779]]

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, Sec. 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 Sec. 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 Sec. 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 Sec. Sec. 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 Sec. Sec. 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, <a href="https://sinch.com/news/ng911-call-aggregator-inteliquent-leads-us-public-safety/?UTM-Inteliquent">https://sinch.com/news/ng911-call-aggregator-inteliquent-leads-us-public-safety/?UTM-Inteliquent</a> (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

[[Page 23780]]

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,
<a href="https://www.gigapackets.com/articles/oc3bandwidth.php">https://www.gigapackets.com/articles/oc3bandwidth.php</a> (``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 Sec. 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
Sec. 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

[[Page 23781]]

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 <a href="https://statescoop.com/north-carolina-next-generation-911-hurricane-helene/">https://statescoop.com/north-carolina-next-generation-911-hurricane-helene/</a>.
\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

[[Page 23782]]

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), <a href="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">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</a>
(``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), <a href="https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_FINALReport_012916.pdf">https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_FINALReport_012916.pdf</a> (``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

[[Page 23783]]

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 Sec. 9.19(a)(4)(i)(A)-(B), Sec.
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.''), <a href="https://psc.nebraska.gov/sites/psc.nebraska.gov/files/doc/Exhibit%20List%20%26%20Exhibit%201-30.pdf">https://psc.nebraska.gov/sites/psc.nebraska.gov/files/doc/Exhibit%20List%20%26%20Exhibit%201-30.pdf</a>.
---------------------------------------------------------------------------

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 network traffic, generating alarms, and producing other
metrics for monitoring and troubleshooting outages within NG
Emergency Services Networks, as well as those impacting the ability
of an NG Emergency Services Network to deliver calls to the target
PSAP.'')
---------------------------------------------------------------------------

We believe this revised rule should apply equally to both legacy
and NG911 architectures. NG911-appropriate standards for network
monitoring rely on automatic disruption detection and alarms.\140\ The
legacy 911 best practice of network monitoring via link and aggregation
point audits \141\ would continue to be a means of compliance for
legacy facilities. In either case, network monitoring should ensure the
performance of the critical NG911 ecosystem facilities of routers,
LISs, and LNGs in real time by detecting failures, disruptions, or
degradations in 911 service. We also propose that this new monitoring
benchmark for IP networks should specify IP-appropriate monitoring of
critical NG911 ecosystem facilities we identify today, including LNGs,
LISs, and the IP routers responsible for path diversity. Should the IP
monitoring benchmark be expanded further to interoperability
capabilities, where applicable? We seek comment on our assessments and
on this proposed benchmark.
---------------------------------------------------------------------------

\140\ 2014 Reliability NPRM, 29 FCC Rcd at 14243, Appendix A,
Proposed Rule 12.4(c)(3)(i)(D); Id., 29 FCC Rcd at 14244-45,
Appendix A, Proposed Rule 12.4(c)(5)(i)(A).
\141\ 47 CFR 9.19(c)(3)(i)(1)-(2).
---------------------------------------------------------------------------

(iii) Operational Integrity
The current ``backup power'' portion of the 911 reliability
certification requires CSPs to indicate whether they provide at least
24 hours of backup power at any central office that directly serves a
PSAP or at least 72 hours at any central office that hosts a selective
router, and whether they have implemented certain design and testing
procedures for backup power equipment.\142\ We propose to retain this
requirement for legacy central office facilities. However, we believe a
modified requirement should be applied to NG911 networks to ensure
continued operation in the event of a power outage.
---------------------------------------------------------------------------

\142\ See 47 CFR 9.19(c)(2)(i).
---------------------------------------------------------------------------

IP-based NG911 facilities, especially when cloud-based, can
reasonably be expected to have redundant and geographically distributed
backups located in different facilities sufficient to ensure that a
failure of any localized facility will not interrupt 911 traffic,\143\
and should have appropriate continuous power, such as an
uninterruptible power supply (UPS) device.\144\ In 2014 the Commission
observed that network architectures using ``two active databases in
different geographic locations, each of which is capable of handling
all 911 call traffic in the event of a fault in the other database,
will be more reliable and resilient than those that route all calls
through a single active database with backup equipment on passive
``standby'' mode.'' \145\ We seek comment on whether to codify this
geographic diversity standard as a best practice benchmark to improve
reliability. We also seek comment on whether requiring geographic
diversity

[[Page 23784]]

at different physical facilities is robust enough to ensure reasonable
reliability. Should we go further and require geographic diversity to
mean redundant functionality housed in different cities or states, not
just in different physical locations? Given the increasing size of
natural disasters, what would be an appropriate distance requirement?
Should we further expand the same IP operational integrity benchmark to
monitoring interoperability facilities, diverse IP paths, and redundant
routers, as well as to LIS and LNG facilities?
---------------------------------------------------------------------------

\143\ CSRIC VI, WG 1 Report at 51 (``When the primary path is
unavailable, the alternate path can be instantly deployed to ensure
continuity of network services. As such the switching to a backup
configuration, in general, does not cause service degradation.'');
see also 2014 Reliability NPRM, 29 FCC Rcd at 14227, para. 45.
\144\ See e.g. FCC Urges Companies Using UPS Devices to Take
Action Against Threats, Public Notice (Apr. 7, 2022), <a href="https://docs.fcc.gov/public/attachments/DOC-382138A1.pdf">https://docs.fcc.gov/public/attachments/DOC-382138A1.pdf</a>.
\145\ 2014 Reliability NPRM, 29 FCC Rcd at 14227, para. 45,
n.106.
---------------------------------------------------------------------------

C. Interoperability

As noted above, the lack of interoperability is a known concern in
NG911, which impairs and increases the cost of call and data transfer.
CSRIC VII observed that the ``transition from legacy to IP-based
networks, may result in hybrid system settings that commingle legacy
and IP network elements. While in this hybrid state, the 911 systems
operate at higher risk. For example, these systems may encounter
challenges in ensuring interoperability with respect to 911 calls and
related data.'' \146\ CSRIC VII also observed that data collected by
NASNA from showed low levels of interstate interoperability,
particularly for data associated with NG911 such as location or SMS
text as well as for features that enhance accessibility, (e.g.,
Multimedia Emergency Services (MMES).\147\ CSRIC VII found that ``[t]he
more advanced technologies used day to day by the general public such
as multi-media services had a very low level of respondents indicating
interoperability.'' \148\ As the NG911 transition progresses, these
interoperability issues are likely to manifest into incompatibilities
detrimental to the processing and receipt of 911 traffic and related
information by 911 Authorities across state lines.\149\
---------------------------------------------------------------------------

\146\ CSRIC VII, WG 4 Report at 5.
\147\ Id. at Appendix B.
\148\ Id. at 25.
\149\ See Jackie Mines, How is NG911 progressing? (Feb. 11.
2025), <a href="https://urgentcomm.com/911/how-is-ng911-progressing-">https://urgentcomm.com/911/how-is-ng911-progressing-</a> (``While
the [NG911 i3] standards were written with interoperability in mind,
if Vendor A interprets them differently than Vendor B, interfacing
the systems doesn't go well and sometimes is nearly impossible.'').
---------------------------------------------------------------------------

To address these concerns, we propose to adopt interstate
interoperability requirements to support the reliable exchange of
interstate 911 traffic between ESInets. Specifically, we propose to
require that CSPs certify whether their interstate interconnecting
ESInet facilities achieve interoperability for exchanged 911 traffic
sufficiently to enable complete interstate transfers between
ESInets.\150\ In that connection, CSPs would annually certify whether
their interstate interconnecting ESInet facilities use conformance-
tested equipment and whether they have tested their interstate
interoperability capabilities. If a CSP cannot certify to these
elements, we propose to require the CSP to certify with respect to
those facilities: (1) whether it (or its ESInet facility operator) has
taken alternative measures to ensure interoperability between ESInets
in multiple states and between providers; (2) whether it believes that
one or more of the requirements of this paragraph are not applicable to
its facilities; and (3) to additional questions about the non-
conforming facilities as directed by the Bureau. We also propose to
apply the definition of ``NG911'' adopted in the NG911 Transition Order
to CSPs. Finally, we seek comment on the scope of our proposed
interoperability requirements relative to other NG911 elements and
whether to define interoperability to cover those elements.
---------------------------------------------------------------------------

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

1. Interstate Interoperability, Conformance and Interoperability
Testing, and Interoperability Certification
Conformance and Interoperability Testing. We propose to adopt an
interoperability best practice benchmark of testing and verification to
support interstate interoperability. We recognize that there have been
voluntary efforts to promote interoperability across NG911 vendors
through best practices, standards development and conformance testing,
but no national rules are in place for providers of NG911 capabilities.
Conformance testing, a process generally planned and developed by
industry organizations and conducted by certified labs, is a mechanism
that could be used to ensure that devices and network equipment that
are deployed are compliant with commonly accepted standards.
Consistent with our existing framework for reliability
certifications, we propose that CSPs submit an annual certification of
whether the equipment in their networks has undergone conformance
testing and if not, whether they are using alternative measures to
ensure interstate interoperability. Under our proposed approach, CSPs
would be required to certify that they are able to process and share
interstate 911 requests for emergency assistance and all associated
information consistent with commonly accepted standards. We seek
comment on this proposal. Is a certification approach sufficient to
ensure that interoperability between ESInets across multiple states can
be achieved without the need for proprietary interfaces, and regardless
of jurisdiction, equipment, device, software, service provider, or
other relevant factors? Should we require CSPs to certify that they are
capable of maintaining interstate interoperability during a ``sunny
day'' outage or disaster scenario?
We also seek comment on whether to adopt additional
interoperability benchmarks, such as requirement to conduct
interoperability testing between ESInets in addition to conformance
testing of technology used by ESInets. Interoperability testing is an
important mechanism for ensuring that CSPs are technically capable of
supporting interoperability between states and different service
providers. Unlike conformance testing, which can be used by a service
provider to demonstrate its NG911 solution conforms to a standard and
increases the likelihood of interoperability, interoperability testing
involves two or more service providers to demonstrate the exchange of
information. We therefore seek comment on adopting a benchmark that CSP
perform interoperability testing with two or more ESInets in different
states. To this end, we seek comment on requiring that CSPs annually
test and certify that they have performed interoperability testing with
at least two different providers in two different states, or if they
are using alternative measures to satisfy interstate interoperability.
Interoperability Certification and Alternative Measures. We propose
that CSPs submit an annual certification attesting to both conformance
testing and interoperability testing starting one year after OMB
approval of any associated information collection requirements. We seek
comment on whether CSPs will be reasonably able to conduct the required
testing within this time period. What processes or standards for test
labs need to be in place before conformance testing can begin? Are
there any other barriers to either conformance testing or
interoperability testing that would impact being able to submit this
certification?
Our proposed annual certification approach is consistent with our
existing requirement under Sec. 9.19(c).\151\ We also propose to
require CSPs to update their certifications annually to reflect any

[[Page 23785]]

changes in their interoperability solutions that render prior
certifications outdated. In addition, we seek comment on whether there
are other methods, in addition to conformance testing and
interoperability testing, for verifying that CSPs comply with
``commonly accepted standards'' and allow them to demonstrate that they
are technically capable of providing interoperability. For example, is
it necessary to specify end-to-end testing (typically required by the
customer) and/or performance testing (testing that simulates a real
world scenario)? \152\ Are any such methods more reliable than
conformance and interoperability testing for verifying interstate
interoperability? What are the potential costs of, and challenges with,
implementing any such methods?
---------------------------------------------------------------------------

\151\ 47 CFR 9.19(c).
\152\ See, e.g., iCERT Interoperability Testing Report at 10;
Brian Rosen Comments, PS Docket 21-479, at 4 (filed Jul. 28, 2023)
(``Call transfer across ESInets is now standardized in NENA STA-
010.3, which is the standard that all current NGCS implementations
are currently at or are expected to be upgraded to soon. Vendor
testing at NENA ICE events and bilateral testing between vendors are
proving interoperability today.'').
---------------------------------------------------------------------------

Finally, we propose to adopt an alternative ``reasonable''
interoperability requirement for providers of interstate ESInet
interconnecting facilities, following the same framework of Sec. 9.19
for reliability. As with the current Sec. 9.19 reliability
certifications, CSPs would be allowed to either certify to meeting the
interoperability benchmarks specified in the rules or to certify that
they have achieved reasonable interoperability using alternative
measures. We seek comment on this proposal. What alternative measures
in lieu of our benchmarks would likely be used to certify and
demonstrate ``reasonable'' interoperability? Should we require that
CSPs successfully test the transfer of interstate calls between ESInets
in order to demonstrate ``reasonable'' interoperability? What other
alternative measures would demonstrate reasonable interoperability?
NG911 and Commonly Accepted Standards. We propose to amend Sec.
9.19 of the rules to define providers of ``NG911'' capabilities by
cross-referencing the definition of NG911 in Sec. 9.28 of the rules.
The definition adopted in the NG911 Transition Order helps define
common sets of features and parameters at various points in the 911
call flow to allow any 911 call or text to be able to reach 911 call
takers. We believe our proposal, consistent with the NG911 Transition
Order, will help lay foundational elements to realizing
interoperability between OSPs to 911 Authorities in multiple states.
Under this proposal, CSPs would ``ensure interoperability'' and comply
with ``commonly accepted standards'' similar to OSPs. Our proposed rule
amendment would therefore ensure CSPs operate from the same baseline
requirements to facilitate interstate interoperability and promote
cooperation with OSPs. We seek comment on our proposal, including
potential costs.
In addition, we seek comment on alternative approaches to ensure
interstate interoperability. In response to the NG911 NPRM, some
commenters urged us to clarify the roles of OSPs and providers of NG911
services.\153\ APCO proposed that in addition to focusing on the
delivery of 911 traffic by OSPs, the Commission should take the ``next
step toward achieving public safety's vision for NG9-1-1'' by
initiating a further notice of proposed rulemaking to address
``interoperability requirements for 9-1-1 service providers and other
elements of the emergency communications chain.'' \154\ In that
connection, we seek comment from 911 Authorities and others as to
whether we should expand the scope of our proposed interoperability
requirement, and, if so, to what other elements of the emergency
communications chain? Similarly, we seek comment on whether to amend
Sec. 9.19(a) of the rules to add a definition for ``interoperability''
for purposes of clarifying the obligations of NG911 service providers,
including the definition of interoperability from the Spectrum Auction
Reauthorization Act of 2023 (H.R. 3565), or some variation, for
purposes of defining the scope of our interoperability requirements;
and the potential benefits and costs of adopting such a definition.
---------------------------------------------------------------------------

\153\ See, e.g., APCO Comments, PS Docket 21-479, at 4-5 (filed
Aug. 9, 2023) (``The greatest impact the Commission can have on
facilitating the transition to NG9-1-1 would be to require
interoperability between OSPs and 9-1-1 service providers, and among
9-1-1 service providers.''); Jack Varnado, Livingston Parish Sheriff
Comments, PS Docket 21-479, at 1 (filed Aug. 9, 2023) (urging the
Commission to require all OSPs and 9-1-1 service providers achieve
interoperability); Michael Coonfield, Oklahoma 911 Management
Authority Comments, PS Docket 21-479, at 2 (filed Aug. 8, 2023)
(stating that interoperability between ESInet and core services must
be required and included in the forest guide); Texas 9-1-1 Entities
Reply Comments, PS Docket 21-479, at 17 (filed Sept. 8, 2023)
(``[T]he Commission should consider a notice of inquiry regarding
interoperability between NG911 service providers, with emphasis on
911 call transfers between ESInets and within ESInets.'').
\154\ APCO Ex Parte, PS Docket 21-479, at 2 (filed Apr. 18,
2024) (emphasis added). APCO previously urged the Commission to
require interoperability between OSPs and NG911 service providers as
part of the current proceeding. APCO Comments, PS Docket 21-479, at
2-4 (filed Aug. 9, 2023). However, in its ex parte, APCO expressed
support for moving forward with the OSP requirements that the
Commission proposed in the NG911 Notice. APCO Ex Parte, PS Docket
21-479, at 1 (filed Apr. 18, 2024). In a more recent ex parte, APCO
urges the Commission to ``seek comment on a rule that would require
9-1-1 service providers to enable the ECCs they serve to exchange
all forms of 9-1-1 traffic with ECCs in different states and/or
served by different 9-1-1 service providers. Each 9-1-1 service
provider could demonstrate compliance with this interoperability
requirement by certifying that the ECCs it serves are able to
exchange 9-1-1 traffic with at least three ECCs located in different
states and/or served by other 9-1-1 service providers. Such a
certification should include an attestation that the 9-1-1 service
provider has confirmed interoperability through real-world testing
at its sole cost.'' APCO Ex Parte, PS Docket 21-479, at 3 (filed
Nov. 1, 2024).
---------------------------------------------------------------------------

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

2. Interstate Interoperability for Text and Video Accessibility

We seek comment on whether interoperability certifications relating
to ESInet interconnection facilities should include specific
certifications regarding interoperability of 911 text messaging and
video accessibility consistent with the benchmarks discussed above. We
believe that ensuring interoperability for non-voice NG911
communications is equal in importance to ensuring interoperability for
voice NG911 calls. In the NG911 Transition Order, the Commission
extended NG911 requirements to OSPs providing non-voice 911 services,
including covered text providers and internet-based Telecommunications
Relay Service (TRS) providers. NG911 is specifically intended to
provide improved support for the full range of 911 voice, text, data,
and video communications, including promoting and enabling 911 access
for individuals with disabilities.\155\ In its end state, NG911 will
facilitate interoperability and system resilience, improve connections
between 911 call centers, and support the transmission of text, photos,
videos, and data to PSAPs

[[Page 23786]]

by individuals seeking emergency assistance.\156\
---------------------------------------------------------------------------

\155\ NG911 Transition Order at *74, para. 215.
\156\ NG911 Transition Order at *6, para. 14; NG911 Notice, 38
FCC Rcd at 6209, para. 10.
---------------------------------------------------------------------------

We seek comment on how best to ensure that NG911 systems support
interoperability for non-voice 911 services, with specific emphasis on
text, video, and multimedia capabilities that support 911 access for
people with disabilities. As noted above, NASNA's 2020 Interoperability
Matrix reflected higher levels of interstate interoperability for 911
voice calls but no or low levels of interstate interoperability for all
other services, including text-to-911 and MMES. We ask commenters to
provide updated information on interstate 911 interoperability by type
of service, with particular emphasis on services used by those with
accessibility needs. For example, what are the current levels of
interstate interoperability for the following types of service: (1) 911
voice calls; (2) location data; (3) text-to-911, including real-time
text (RTT); and (4) MMES?
Text Messaging. Regarding text messaging, in response to the NG911
NPRM, Google and NENA proposed that we consider the implementation of
new interoperable messaging protocols, such as Rich Communications
Service (RCS).\157\ We seek comment on Google's view that, ``[b]y
addressing interoperable text messaging as part of its NG911 efforts,
the Commission can further enable members of the public to connect to
lifesaving resources, family members, and friends in a more effective
and secure manner.'' Do commenters agree with NENA and Google's
concerns about text interoperability and comments about RCS, and if so,
would RCS fall under our definition of ``commonly accepted standards''?
We seek comment more generally as to whether the public interest is
better served by the Commission making such determinations in the short
term or allowing the marketplace to make such determinations over a
longer period of time. We also seek comment on whether there are
interoperability problems in the commercial wireless market that are
impeding end state end-to-end NG911? We invite commenters to comment on
the specific connectivity, data transmission, and security issues
Google describes as inherent in SMS/MMS. What options are currently
available to address the aforementioned concerns as part of our
certification requirements for CSPs, including intrastate
interoperability requirements, and issues and what options do
commenters foresee becoming available in the near-term and long-term?
---------------------------------------------------------------------------

\157\ Google Comments, PS Docket 21-479, at 9-11 (filed Aug. 10,
2023); NENA Reply Comments, PS Docket 21-479, at 9-10 (filed Sept.
6, 2023). RTT is available in some locations as a text-based
communications technology for 911 purposes. See FCC, Real-Time Text,
<a href="http://www.fcc.gov/rtt">www.fcc.gov/rtt</a> (Nov. 5, 2024).
---------------------------------------------------------------------------

Video. Point-to-point video calls can be instrumental to
demonstrate the emergency at hand in order to expedite the provision of
appropriate emergency assistance. Additionally, people with
disabilities may benefit from video calling in order to communicate
more clearly in conjunction with other modalities such as text
communications. We seek comment concerning accessibility with
particular focus on measures we can take to promote interstate
interoperability between ESInets.\158\ In response to the NG911 NPRM,
commenter Brian Rosen suggested that the Commission could adopt
requirements to ensure ESInets support three-way video for Video Relay
Service (VRS) within a reasonable period of time, such as 12 months.
Further, three-way video has the potential to support individuals with
speech disabilities relying on speech-to-speech relay services.\159\
Rosen claims that many vendors of NGCS systems plan to support video in
upcoming releases and suggests imposing a regulatory deadline to do so.
In addition, Communication Service for the Deaf, Inc. states that video
sign-language communications in NG911 systems could occur in different
ways, including through standard VRS, three-way video relay
services,\160\ or direct video calling (DVC). DVC would allow a caller
who uses sign language to place a call to a call taker who is both
fluent in sign language and trained in handling emergency calls,
potentially eliminating the need for a third-party intermediary.\161\
Should we amend our rules to require that NGCS systems support three-
way video for relay services, and support DVC? If so, within what time
frame should such support be required for either service? What
conditions or qualifications, if any, should be included in
requirements associated with these video calls? We seek updated data on
interstate interoperability needed to meet the needs of the
accessibility community, including the feasibility of providing DVC or
three-way video 911 calls that include VRS, and challenges with
implementation during the transition to NG911 and relevant
timelines.\162\
---------------------------------------------------------------------------

\158\ NG911 Transition Order at *17, para. 43. In the NG911
Transition Order, the Commission adopted an NG911 definition that
includes accessibility as an essential requirement, consistent with
the definition in the Spectrum Auction Reauthorization Act of 2023
(H.R. 3565), which requires that NG911 ``be capable of processing
`all types' of requests.'' The Commission agreed that this
requirement mandates that NG911 standards support accessible
technologies. NG911 Transition Order at **14, 61, paras. 34, 179.
The Commission declined, however, to expand the scope of the
proceeding to consider accessibility issues raised in comments, but
consistent with its authority under the CVAA, committed to monitor
the development of NG911 systems and technologies and be prepared to
take necessary steps to ensure that NG911 is fully accessible to
all.
\159\ See, e.g., FCC, Speech-to-Speech Relay Service (STS),
<a href="http://www.fcc.gov/sts">www.fcc.gov/sts</a> (Jan. 28, 2025).
\160\ Communication Service for the Deaf, Inc., et al. Ex Parte,
PS Docket 21-479, at 2-3 (filed Mar. 12, 2025) (stating that
traditional VRS uses a communications assistant fluent in sign
language to enable a 911 caller to communicate through an
intermediary, so that the VRS interpreter voices what the caller
signs and signs back the call taker's response, while three-way
video would allow the VRS caller, the 911 call taker, and the video
interpreter to all be visible to each other on the same video call).
\161\ Id. at 3. See also Structure and Practices of the Video
Relay Service Program, CG Docket 10-51, Further Notice of Proposed
Rulemaking, 32 FCC Rcd 2436, 2484, para. 125 (2017), 82 FR 17613
(Apr. 12, 2017), 82 FR 17754 (Apr. 13, 2017) (``A direct video
calling (DVC) customer support service . . . permits individuals who
are deaf, hard of hearing, deaf-blind, or have a speech disability .
. . to engage in real-time video communication in ASL without using
VRS. The purpose of DVC is to provide direct telephone service to
such individuals that is functionally equivalent to voice
communications service provided to hearing individuals who do not
have speech disabilities.'').
\162\ Brian Rosen Comments, PS Docket 21-479, at 5 (filed July
28, 2023) (stating that from the very first version (NENA 08-003),
three-way video was a firm requirement and that the requirement was
there expressly for VRS: a VRS user should be able to dial 9-1-1 and
be placed in a 3-way video call with the caller, the 911 call taker,
and a sign language interpreter).
---------------------------------------------------------------------------

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

[[Page 23787]]

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

\163\ Communication Service for the Deaf, Inc., et al. Ex Parte,
PS Docket 21-479, at 4 (filed Mar. 20, 2025) (``. . . ASL users use
either a VRS app or a video communications device provided by their
VRS provider to access 911 services. Each VRS company in turn
contracts with an `Emergency Call Relay Center' provider to
facilitate the routing and processing of their 911 calls to the
caller's appropriate PSAP . . . If the ability to use DVC is
integrated into the NG911 infrastructure, could 911 calls placed by
ASL-fluent callers be placed directly to an ASL-fluent 911 call
taker without being routed through a VRS provider?'').
---------------------------------------------------------------------------

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

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

D. Implementation and Oversight

In order to assist in monitoring compliance with our proposed rules
for NG911 reliability and interoperability, we propose to update our
911 reliability data collections and oversight mechanisms. In the 911
Reliability Order, the Commission stated that ``if a Covered 911
Service Provider certifies that it has taken alternative measures to
mitigate the risk of failure, or that a certification element is not
applicable to its network, its certification is subject to a more
detailed Bureau review.'' \165\ If the Bureau's review indicates that a
provider's alternative measures are not reasonably sufficient to ensure
reliable 911 service, the Commission stated that the Bureau should
first engage with the provider and other interested stakeholders (e.g.,
affected PSAPs) to address any shortcomings. To the extent that such a
collaborative process does not yield satisfactory results, the
Commission stated that the Bureau may order remedial action consistent
with its delegated authority.\166\ The Commission intended this process
to allow flexibility to employ alternative--but reliable--network
designs and technologies, not to create an exception that would swallow
the rule.\167\
---------------------------------------------------------------------------

\165\ See 47 CFR 0.392(j); 911 Reliability Order, 28 FCC Rcd at
17497 para. 62 (``The Bureau will consider a number of factors in
determining whether the particular alternative measures are
reasonably sufficient to ensure reliable 911 service. Such factors
may include the technical characteristics of those measures, the
location and geography of the service area, the level of service
ordered by the PSAP, and state and local laws (such as zoning and
noise ordinances).'').
\166\ See 911 Reliability Order, 28 FCC Rcd at 17497 para. 63.
\167\ 2015 Reliability Recon. Order, 30 FCC Rcd at 8654-55,
paras. 2, 10-11.
---------------------------------------------------------------------------

As discussed below, we believe that revised reporting requirements
would be helpful to Commission staff and 911 Authorities in identifying
risks to the reliability and interoperability of 911 traffic, including
single points of failure, and ask commenters to identify specific
information that providers should include in their certifications. We
also seek comment on measures the Commission could take to limit the
burden of reporting on NG911 reliability and interoperability. We also
seek comment on how to better identify single points of failure that
could have cascading effects on 911 traffic in multiple states. To what
extent could the Commission limit the burden of any reporting
requirements by providing increased flexibility for providers or
businesses identified as small by the Small Business Administration?
\168\ We also propose to require disclosure of reliability and
interoperability certifications to 911 Authorities. In that connection,
we seek comment on establishing procedures for 911 Authorities to
report concerns to the Bureau to conserve limited resources and focus
attention on critical elements that could result in multistate outages
or hamper interstate interoperability. We tentatively conclude that
improving 911 Authorities' access to information about the 911
reliability measures in place within their states would amplify the
Commission's ability to address potential risks to NG911 service and
enable 911 Authorities to assess taking their own measures to prevent
and mitigate disruptions to 911 service in their jurisdictions. We seek
comment on this tentative conclusion and on the specific proposals
below. In addition to enhancing reporting requirements for providers
and improving information sharing with 911 Authorities, we seek comment
on whether we should establish a dedicated consumer portal for 911-
related outage complaints. Such a portal could provide the public with
a clear and accessible means to report concerns about 911 service
disruptions directly to the FCC. This approach may improve the
Commission's ability to identify and address potential risks to NG911
reliability while empowering consumers to play a more active role in
ensuring public safety. We invite input on the potential benefits of
this proposal, including how it could complement existing reporting
mechanisms and enhance transparency in addressing 911 service
reliability.
---------------------------------------------------------------------------

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

1. Reform of Reliability Certification Process
Traditionally, NG911 CSPs select ``alternative measures'' to report
reliability practices that differ from the legacy 911-specific best
practice benchmarks articulated in our existing regulations, but which
the Commission deemed reliable in the 2015 Reliability Recon.
Order.\169\ We seek comment on whether one potential improvement from
today's proposed changes of both defining NG911 equivalents and
functional equivalents and codifying the best practice measures
applicable to IP-based networks would be allowing NG911 CSPs to
directly certify that they meet the benchmarks specified in our
regulations, instead of having to use the alternative measures option
to report IP-based network reliability practices. We seek comment on
the impact of this change, and on related proposed minor changes
described below.
---------------------------------------------------------------------------

\169\ 2015 Reliability Recon. Order, 30 FCC Rcd at 8656-57,
paras. 12, 15.
---------------------------------------------------------------------------

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

[[Page 23788]]

NG911 networks.\170\ The Commission similarly observed that the
existing monitoring benchmark was appropriate for legacy 911 facilities
but not IP facilities, as IP-based service providers do not ``audit''
monitoring circuits the way TDM providers do, but rather use the
automated network monitoring capabilities for their resilient IP-
enabled networks.'' \171\ At the time, the Commission did not undertake
revision of the certification form, but rather instructed NG911 CSPs to
report that they are using ``alternative measures'' for reliable IP
best practices, since the CSPs could not realistically certify to using
TDM-specific best practices on IP networks.\172\ Accordingly, NG911
providers currently answer the legacy 911 certification questions in
the negative, but then provide narrative descriptions of how IP network
reliability differs from legacy 911 reliability.\173\
---------------------------------------------------------------------------

\170\ 2015 Reliability Recon. Order, 30 FCC Rcd at 8656, para.
15 (``The circuit auditing requirement adopted in the 911
Reliability Order was based upon a CSRIC best practice urging
network operators to `periodically audit the physical and logical
diversity . . . of their network segment(s) . . . .' [H]owever,
appropriate measures to preserve physical and logical diversity may
differ between circuit-switched time division multiplexing (TDM) and
IP-based networks because IP-based routing and . . . re-routing can
occur dynamically over many possible paths.'').
\171\ 2015 Reliability Recon. Order, 30 FCC Rcd at 8659, para.
20.
\172\ 2015 Reliability Recon. Order, 30 FCC Rcd at 8656, para.
12 (``[W]e clarify that the certification framework adopted in the
911 Reliability Order allows flexibility for all Covered 911 Service
Providers--legacy and IP-based--to certify reasonable alternative
measures to mitigate the risk of failure in lieu of specified
certification elements.''); 2015 Reliability Recon. Order, 30 FCC
Rcd at 8657, para. 16 (``Technology transitions have already
resulted in a variety of hybrid 911 network architectures in which
some functions are provided over legacy TDM circuits and others are
provided over IP-based infrastructure. In such cases, our rules as
revised will permit the provider to certify reasonable alternative
measures with respect to either portion of the network.'').
\173\ 2015 Reliability Recon. Order, 30 FCC Rcd at 8657, para.
16 (``[E]xplanations of alternative measures with respect to circuit
audits and tagging should . . . describe affirmative steps in lieu
of audits and tagging to mitigate the risk of a service disruption.
. . .'').
---------------------------------------------------------------------------

We seek comment on whether specifying NG911 and IP-based network
benchmarks directly in the rules will allow NG911 CSPs to more easily
certify to meeting reasonable reliability best practices without having
to describe alternative measures for the compliant IP-based network
facilities they operate, reserving alternative measures for deviations
from the best practice benchmarks. If so, will this proposed change
improve Commission collection and analysis of certification reliability
data? What are the pros and cons of this approach in terms of data
reported and collected? What drawbacks are there to this approach?
Should the certification form be revised to require drop-down
selections for the kind of legacy or NG911 facilities being certified
to (e.g., selective router central office, path from selective router
to central office serving PSAP, major transport path to ESInet, LIS
facility, etc.) to ensure clarity of which best practice standard
(legacy or NG911) is being certified to? \174\ We propose to direct
PSHSB to consider revisions the certification form so that CSPs can
specify which type(s) of 911 facilities they are operating--legacy and/
or NG911--in a way that constrains which best practice standard they
are certifying to. We further direct PSHSB to consider revisions to the
certification form in ways that will ensure NG911 CSPs do not have to
submit narrative explanations of alternative measures for IP-based
facilities if those facilities meet the regulatory best practice
benchmarks for IP-based networks. Will this change help the Commission
identify which filers are proving NG911 services, which are providing
legacy 911 services, and which are providing both? Would these changes
also reduce the number of times CSPs have to answer portions of the
certification form with ``not applicable,'' if the kind of facilities
they operate and select from the drop-down menu automatically constrain
which reliability and interoperability benchmarks they may certify to?
We seek comment on these assessment and proposals.
---------------------------------------------------------------------------

\174\ See Public Safety and Homeland Security Bureau Seeks
Comment on Modifications to Network Outage Reporting system and 911
Reliability Certification System, PS Docket Nos. 15-80, 13-75,
Public Notice, 35 FCC Rcd 4409, 4413 (seeking comment on adding
``drop-down fields to 911 reliability certifications that will
require covered 911 service providers to indicate whether they
provide'' specified 911, E911, or NG911 services) (PSHSB 2020).
---------------------------------------------------------------------------

Accordingly, we propose to direct PSHSB to revise the reliability
and interoperability certification form to replace the current free-
form text reporting option for alternative measures or ``not
applicable'' answers with specified drop-down selection answers as
determined by the Bureau, and to seek comment on a revised
certification form. We tentatively conclude that this approach will
best illuminate network practices for Commission staff and potentially
reduce burdens on CSP filers. Similarly, if the updated form asks CSPs
to select alternative measures and then list all facilities that employ
them instead of vice-versa as it is now, we believe this will also
improve reporting. We seek comment on this proposal.
We further propose modifying the certification form to ask NG911
CSPs to report on the volume of 911 call traffic that their non-
conforming facilities handle. In response to a previous request for
comment,\175\ state government parties suggested improvements to the
certification system to enable the Commission to determine the size of
potentially impacted populations from critical 911 facility
failures.\176\ We believe most CSPs handling NG911 traffic from
multiple OSPs have this data readily available,\177\ and so such
reporting would constitute a minimal burden to providers while
providing valuable data to the Commission and to 911 Authorities.\178\
We therefore believe such a change would improve 911 reliability and
oversight with minimal additional burden on regulated entities. We seek
comment on this proposal, on the best metric and reporting format to
use for 911 traffic volume data, and on any additional suggestions for
improving the certification form. Should the proposal be expanded to
require 911

[[Page 23789]]

traffic volume reporting for conforming facilities as well?
---------------------------------------------------------------------------

\175\ See Public Safety and Homeland Security Bureau Seeks
Comment on Modifications to Network Outage Reporting system and 911
Reliability Certification System, PS Docket Nos. 15-80, 13-75,
Public Notice, 35 FCC Rcd 4409, 4414-5 (PSHSB 2020).
\176\ NASNA Comments, PS Docket 13-75, at 3 (filed July 17,
2020) (recommending changes to the reliability certification form to
``allow the FCC to analyze filed Reliability Certification Systems
to know what populations are being made vulnerable to outages due to
lack of redundancy or diversity in 911 networks.''); Colorado Public
Utility Commission Comments, PS Docket 13-75, at 2 (filed July 8,
2020) (same).
\177\ See e.g., Bandwidth Comments, PS Docket 21-479, at 2-3
(filed Aug. 9, 2023) (``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.''); Inteliquent Reply
Comments, PS Docket 21-479, at 1 (filed Sept. 8, 2023) (``Sinch
provides a Voice over Internet Protocol (`VoIP') Positioning Center
(`VPC') service to VoIP providers. Sinch's VoIP customers contract
with Sinch to facilitate VoIP 911 call delivery to the appropriate
Public Safety Answering Points (`PSAP').'')
\178\ Inteliquent Ex Parte, PS Docket 21-479, at 1 (filed Oct.
10, 2023) (''. . . Sinch explained that a subset of Next Generation
Core Services Providers (`NGCS Providers') rely on Sinch to assist
with steering Automatic Location Information (``ALI'') queries
between PSAPs and Sinch's Voice over Internet Protocol Positioning
Center (`VPC') platform via the ALI Database or Location Database
(`ALI/LDB'). These NGCS Providers are considered Covered 911 Service
Providers under the FCC's rules.'').
---------------------------------------------------------------------------

We further propose to direct the Bureau to consider additional ways
to improve the certification forms pursuant to its delegated
authority.\179\ The 911 reliability and interoperability certification
submission form and data should simultaneously: (1) ensure the Bureau
can reasonably perform its investigation \180\ and Remediation Order
\181\ delegated responsibilities to facilitate 911 reliability and
interoperability; (2) provide similar reasonable oversight for 911
Authorities; and (3) impose no greater reporting burdens on CSPs than
is necessary for these purposes. We direct the Bureau to prepare to
appropriately implement such improvements bearing these factors in
mind, consistent with today's rule proposals.
---------------------------------------------------------------------------

\179\ 47 CFR 0.392(j) (``The Chief of the Public Safety and
Homeland Security Bureau is delegated authority to . . . develop and
revise forms and procedures as may be required for the
administration of part 9, subpart H, of this chapter. . . .'').
\180\ 47 CFR 0.392(h) (``The Chief, Public Safety and Homeland
Security Bureau or her/his designee is authorized to issue non-
hearing related subpoenas for the attendance and testimony of
witnesses and the production of books, papers, correspondence,
memoranda, schedules of charges, contracts, agreements, and any
other records deemed relevant to the investigation of matters within
the jurisdiction of the Public Safety and Homeland Security
Bureau.'').
\181\ 47 CFR 0.392(j) (``The Chief of the Public Safety and
Homeland Security Bureau is delegated authority to . . . order
remedial action on a case-by-case basis to ensure the reliability of
911 service in accordance with such rules and policies.'').
---------------------------------------------------------------------------

In connection with the above, we propose minor amendments to
consolidate rule 9.19 in some instances, to minimize the burden on
regulated entities subject to these rules by making it easier for them
to identify and comply with all 911 reliability and interoperability
requirements. For example, propose to consolidate the alternative
measures reporting paragraphs at Sec. 9.19(c)(1) to (3) to similarly
capture both legacy and NG911 providers, and to better ensure the
Bureau can revise the annual certification form to best respond to 911
Authorities' needs and obtain necessary data to make a reasonableness
determination under its delegated authority.\182\ We also propose to
consolidate and streamline the record retention paragraphs under Sec.
9.19(d)(3) to better apply across all legacy and NG911 CSPs. We seek
comment on these modifications, and any other advisable non-substantive
or conforming edits to rule 9.19.
---------------------------------------------------------------------------

\182\ 47 CFR 0.392(j).
---------------------------------------------------------------------------

Finally, we seek comment on whether there are measures in addition
to annual certification that would promote 911 reliability and
interoperability. For example, could the Commission implement an
outcome-based standard that establishes how many annual user minutes of
911 traffic could be interrupted by network or facility outages and
still be considered reasonable, beneath which a CSP is subject to
remediation orders? Could the Commission adopt a similar
interoperability standard based on percentage of interstate 911 call
transfers which fail completely, or fail to include caller location or
other data?
2. Access to Reliability Certifications
We propose amending the rules to provide that any 911 Authorities
are entitled to receive, upon request to the CSP, the annual
reliability and interoperability certifications filed with the
Commission directly from CSPs operating in their jurisdictions.
Furthermore, we propose to adopt the same process for NORS access that
state and local governments may follow for access to the 911
reliability and interoperability certificate system. Accordingly, 911
Authorities will have options for accessing 911 reliability and
interoperability certification data, and may use the option that best
suits their local needs and relationships with CSPs. We seek comment on
these proposals.
Under existing rules, 911 reliability certifications are
presumptively confidential.\183\ The Commission adopted the rule in
2013 after balancing the interests of CSPs to protect proprietary and
sensitive information and the public's access to 911 reliability
information.\184\ The Commission recognized that ``PSAPs and state 911
authorities have a strong interest in obtaining relevant information
about the reliability and resiliency of their 911 service.'' \185\ The
Commission noted that PSAPs identified a limited set of information
they believed to be important in assessing reliability of their service
(e.g., circuit audits), and accordingly, the Commission found no reason
to address the need for disclosure of additional information to PSAPs
and/or state 911 authorities.\186\ Nonetheless, the Commission expected
that CSPs ``will, at the request of the PSAP (or state 911 authority,
as relevant), enter into discussions concerning the content of the
provider's 911 circuit auditing certification with respect to the
PSAP.'' \187\ In light of the wide variety of circumstances involved in
how PSAPs nationwide purchase 911 service, the Commission declined ``to
require specific disclosure by rule, preferring to allow parties to
negotiate reasonable and appropriate terms for assuring protection of
proprietary information.'' \188\ The Commission made clear, however,
that CSPs ``should respond promptly to a PSAP request in this area''
and reiterated its belief ``that PSAPs should have access to the
details of circuit-auditing certifications, as long as the sensitive
and proprietary nature of the information can be maintained.'' \189\
---------------------------------------------------------------------------

\183\ Specifically, Rule 0.457(d)(1)(viii) states: ``Information
submitted with a 911 reliability certification pursuant to 47 CFR
12.4 [now 47 CFR 9.19] that consists of descriptions and
documentation of alternative measures to mitigate the risks of
nonconformance with certification elements, information detailing
specific corrective actions taken with respect to certification
elements, or supplemental information requested by the Commission
with respect to such certification.'' 47 CFR 0.457(d)(1)(viii). See
47 CFR 9.19(d)(2)(i) and (ii).
\184\ 911 Reliability Order, 28 FCC Rcd at 17533, paras. 157-
158.
\185\ For example, NENA stated that ``PSAPs may be in the best
position to use this information to prompt 911 service providers to
make specific reliability improvements in their networks, but they
may not otherwise be able to negotiate reliable access to this
information through their contracts or tariffs.'' 911 Reliability
Order, 28 FCC Rcd at 17533, para. 157.
\186\ 911 Reliability Order, 28 FCC Rcd at 17533, para. 158.
\187\ 911 Reliability Order, 28 FCC Rcd at 17533, para. 158.
\188\ 911 Reliability Order, 28 FCC Rcd at 17533, para. 158.
\189\ 911 Reliability Order, 28 FCC Rcd at 17533, para. 158.
---------------------------------------------------------------------------

We seek comment on whether there is an increased need for state and
local government access to 911 reliability and interoperability
certification data today, particularly in light of the advancing NG911
transition and the new roles being adopted by 911 Authorities and
private network operators. Do other changes in network architecture
evolution also change the need for state and local access to Commission
data concerning 911 reliability and interoperability? For example in
2021, the Commission concluded that directly sharing NORS data with
state and federal agencies, subject to appropriate and sufficient
safeguards, is in the public interest, and the Commission extended this
finding to include the sharing of DIRS data.\190\ The

[[Page 23790]]

Commission limited eligibility for direct access to our NORS and DIRS
databases to ``need to know'' agencies acting on behalf of the federal
government, the 50 states, the District of Columbia, Tribal Nations,
and the U.S. territories.\191\ In discussing sharing of complete NORS
and DIRS reports and filings, the Commission noted ``that sympathy
reports and reports containing information about TSPs contain
actionable information on outages that could be of use to public safety
officials for emergency response or service restoration and declined to
exclude these reports from NORS filings. For example, 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.'' \192\
---------------------------------------------------------------------------

\190\ See NORS Information Sharing Order, 36 FCC Rcd 6136. By
way of background, the Commission collects network outage
information in the Network Outage Reporting System (NORS) and
infrastructure status information in the Disaster Information
Reporting System (DIRS). This information is sensitive for reasons
concerning national security and commercial competitiveness, and the
Commission thus treats it as presumptively confidential. The
Commission makes this information available to the Department of
Homeland Security's (DHS) National Cybersecurity and Communications
Integration Center but does not share the information more broadly
with other federal, state, or local partners. New Part 4 of the
Commission's Rules Concerning Disruptions to Communications, ET
Docket No. 04-35, Report and Order and Further Notice of Proposed
Rulemaking, 19 FCC Rcd 16830, 16856, para. 47 (2004), 69 FR 68859
(Nov. 26, 2004), 69 FR 70316 (Dec. 3, 2004) (making NORS reports
available to DHS ``in encrypted form and immediately upon
receipt'').
\191\ NORS Information Sharing Order, 36 FCC Rcd at 6141, para.
16.
\192\ NORS Information Sharing Order, 36 FCC Rcd at 6160, para.
78.
---------------------------------------------------------------------------

Under our proposal, we would retain the existing requirements under
Sec. 9.19(d)(2)(i) and (ii), but would add that 911 Authorities will
be eligible to accessing the 911 reliability and interoperability
certification database under the same conditions as NORS access, and
also require CSPs to provide their annual certifications to 911
Authorities in their CSP service areas upon the request of a 911
Authority.\193\ For example, if a 911 Authority issues a request to
contacts a CSP, including a CSP that delivers 911 traffic to the in-
state NG911 Delivery Point, the CSP would be required to provide the
information applicable to that 911 Authority and within that 911
Authority's jurisdiction. We believe that 911 Authorities have a strong
interest in accessing certification filings to ensure the reliability
of 911 traffic in their jurisdictions during the NG911 transition.\194\
In addition, we believe 911 Authorities would benefit from having 911
reliability and interoperability certifications to assist with
developing emergency response plans in advance of an outage.
---------------------------------------------------------------------------

\193\ In that connection, we would also retain the existing
record retention requirements under 47 CFR 9.19(d)(3) with updates
to cover interoperability certifications and streamlining as noted
above.
\194\ See, e.g., Washington Utilities and Transportation
Commission Comments, PS Docket No. 14-193, p. 8 (filed March 17,
2015) (``Additionally, as part of the cooperative framework with
state and local partners the Commission seeks to maintain, the UTC
suggests the proposed expanded certification requirements of Rule
12.4 be modified to require that all covered entities that submit
annual certification, compliance, or audit reports, should also be
required to simultaneously submit such information to designated
state governance officials, such as the UTC and the Washington State
E911 Coordinator's Office, that are actively involved or have some
oversight responsibilities with respect to reliable 911 service
delivery at the state level. Access to such information by state
officials would greatly assist in understanding and tracking
marketplace developments affecting 911 service delivery within the
scope of their jurisdictions. State access could also greatly assist
officials during times of emergency, like the April 2014 multi-state
outage, in understanding and interacting with such entities as
events unfold. The UTC urges the Commission to modify the
certification and reporting requirements of Rule 12.4 by requiring
covered 911 service providers to submit certification and compliance
information and reports to the Commission's state partners.'').
---------------------------------------------------------------------------

We acknowledge that certifications are presumptively confidential
under our existing rules, and CSPs and 911 Authorities must agree to
confidentiality for sharing certifications. Under today's proposed
approach, CSPs must share relevant portions of certifications, but may
omit or redact information relating to portions of their networks that
are not located within and not providing any service directly to the
requesting 911 Authority's jurisdiction. CSPs may condition providing
their certifications on the 911 Authority executing a confidentiality
agreement.
We also propose extending our NORS/DIRS information sharing
framework to 911 reliability and interoperability certifications to 911
Authorities only. 911 Authorities who prefer not to request
confidential certifications directly from CSPs may request access to
certifications from the Bureau under the same terms currently provided
under rule 4.2.\195\ CSPs receiving a request to provide a
certification to a 911 Authority must provide it within 14 days under
confidentiality terms no more restrictive than the same rule.\196\ We
seek comment on whether this proposal would best help ensure 911
Authorities' access to valuable information. Would this proposal
incentivize cooperation between states and CSPs? Do 911 Authorities
prefer having the option to seek this information either directly from
CSPs or from PSHSB? We seek comment on this proposal and any
alternatives.
---------------------------------------------------------------------------

\195\ 47 CFR 4.2.
\196\ To protect sensitive communications status data,
Participating Agencies and Downstream Agencies must preserve the
confidentiality of certification filings. The Commission will grant
access to certification filings only after 911 Authorities certify
that they will comply with requirements for maintaining the
confidentiality of the data and the security of the databases. 911
Authorities will also be responsible for ensuring downstream
agencies certify that they, too, will maintain the confidentiality
of the data they receive. See 47 CFR 4.2.
---------------------------------------------------------------------------

Finally, we propose to amend Sec. 9.19(d) of the rules to require
CSPs to notify their 911 Authority of cessation of service at the same
time they notify the Commission. Under our current rules, CSPs that
cease covered operations under this section must notify the FCC by
filing a notification under penalty of perjury no later than 60 days
after the cessation of service.\197\ For the reasons discussed above,
we believe that 911 Authorities would benefit from having situational
awareness of when CSPs cease providing services to their jurisdictions,
and seek comment on this proposal, including alternatives, and
potential costs to CSPs.
---------------------------------------------------------------------------

\197\ 47 CFR 9.19(d)(4).
---------------------------------------------------------------------------

3. Remedial Action and Petition Process
To promote accountability and transparenc

[…truncated; see source link]

View on FederalRegister.gov →Plain-text source

Indexed from Federal Register on June 4, 2025.

This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.