[Federal Register Volume 89, Number 185 (Tuesday, September 24, 2024)]
[Rules and Regulations]
[Pages 78066-78131]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2024-18603]



[[Page 78065]]

Vol. 89

Tuesday,

No. 185

September 24, 2024

Part III





 Federal Communications Commission





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





47 CFR Part 9





Facilitating Implementation of Next Generation 911 Services (NG911); 
Location-Based Routing for Wireless 911 Call; Final Rule

  Federal Register / Vol. 89, No. 185 / Tuesday, September 24, 2024 / 
Rules and Regulations  

[[Page 78066]]


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

FEDERAL COMMUNICATIONS COMMISSION

47 CFR Part 9

[PS Docket Nos. 21-479, 18-64; FCC 24-78; FR ID 238221]


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

AGENCY: Federal Communications Commission.

ACTION: Final rule.

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

SUMMARY: In this document, the Federal Communications Commission (the 
FCC or Commission) adopted a Report and Order to advance the nationwide 
Next Generation 911 (NG911) transition rules that define the 
responsibilities and set deadlines for originating service providers 
(OSPs) to implement NG911 capabilities on their networks and deliver 
911 calls to NG911 systems established by 911 authorities. In addition, 
the rules preserve the authority of state, territorial, regional, 
Tribal, and local government to adopt alternative approaches to the 
configuration, timing, and cost responsibility for NG911 implementation 
within their jurisdictions.

DATES: Effective date: November 25, 2024.
    Compliance date: Compliance will not be required for Sec. Sec.  
9.31(a) through (c) and 9.34(a) and (b) until a document is published 
in the Federal Register announcing a compliance date and revising or 
removing Sec. Sec.  9.31(d) and 9.34(c).

FOR FURTHER INFORMATION CONTACT: For additional information on this 
proceeding, contact John Evanoff of the Public Safety and Homeland 
Security Bureau, Policy and Licensing Division, at [email protected] 
or 202-418-0848.

SUPPLEMENTARY INFORMATION: This is a summary of the Commission's Report 
and Order in PS Docket Nos. 21-479 and 18-64, FCC 24-78, adopted on 
July 18, 2024, released on July 19, 2024, and corrected via an Erratum 
released on September 5, 2024. The full text of this document is 
available for public inspection at https://docs.fcc.gov/public/attachments/FCC-24-78A1.pdf. To request materials in accessible formats 
for people with disabilities (braille, large print, electronic files, 
audio format), send an email to [email protected] or call the Consumer & 
Governmental Affairs Bureau at 202-418-0530 (voice).

Congressional Review Act

    The Commission has determined, and the Administrator of the Office 
of Information and Regulatory Affairs, Office of Management and Budget, 
concurs, that this rule is major under the Congressional Review Act, 5 
U.S.C. 804(2). The Commission will send a copy of the Report and Order 
to Congress and the Government Accountability Office pursuant to 5 
U.S.C. 801(a)(1)(A).

Synopsis

I. Introduction

    This document is a summary of the Commission's Report and Order 
(Order). In the Order, we take steps that will advance the nationwide 
transition to Next Generation 911 (NG911). Like communications networks 
generally, dedicated 911 networks are evolving from Time Division 
Multiplexing (TDM)-based circuit-switched architectures to internet 
Protocol (IP)-based architectures. With the transition to NG911, legacy 
911 networks will be replaced by IP-based technologies and 
applications, which provide new capabilities and improved 
interoperability and system resilience. Most states have begun to 
invest significantly in NG911, but some have experienced delays in 
communications providers connecting to these IP-based networks. As a 
result of these delays, state and local 911 authorities incur prolonged 
costs because of the need to maintain both legacy and IP networks 
during the transition. Managing 911 traffic on both legacy and IP 
networks at the same time may also result in increased vulnerability 
and risk of 911 outages.
    To facilitate the NG911 transition, we adopt rules that will 
require wireline providers, Commercial Mobile Radio Service (CMRS) 
providers, covered text providers, providers of interconnected Voice 
over internet Protocol (VoIP) services, and providers of internet-based 
Telecommunications Relay Service (internet-based TRS) (collectively 
``originating service providers'' or ``OSPs'') \1\ to take actions to 
start or continue the transition to NG911 in coordination with 911 
Authorities.\2\ The rules 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.
---------------------------------------------------------------------------

    \1\ For purposes of this document and the Order and the rules we 
adopt, ``wireline provider'' means ``[a] local exchange carrier (as 
defined in 47 U.S.C. 153(32)) that provides service using wire 
communication (as defined in 47 U.S.C. 153(59)),'' and ``covered 
text provider'' has the meaning given such term under 47 CFR 
9.10(q)(1). The terms ``CMRS,'' ``interconnected VoIP service,'' and 
``internet-based TRS'' have the meanings identified in 47 CFR 9.3.
    \2\ ``911 Authority'' means ``[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.''
---------------------------------------------------------------------------

    We implement a two-phased approach to guide the transition to 
NG911. Each phase is initiated by a 911 Authority submitting a valid 
request to OSPs within the jurisdiction where the 911 Authority is 
located for the OSPs to comply with NG911 requirements, including:
     Phase 1: Upon receiving a valid Phase 1 request from a 911 
Authority, an OSP must commence delivery of 911 traffic in IP-based 
Session Initiation Protocol (SIP) format to one or more in-state NG911 
Delivery Points designated by the 911 Authority. Phase 1 will enable 
911 Authorities to deploy Emergency Services IP Networks (ESInets) in a 
cost-effective manner by selecting convenient delivery points to 
receive 911 traffic; will improve 911 reliability by using an IP-based 
format, rather than legacy format, to deliver 911 traffic; and will 
establish the transmission platforms necessary for upgrading to Phase 
2.
     Phase 2: Upon receiving a valid Phase 2 request from a 911 
Authority, an OSP must commence delivery of 911 traffic to the 
designated in-state NG911 Delivery Point(s) in an IP-based SIP format 
that complies with NG911 commonly accepted standards identified by the 
911 Authority, including having location information embedded in the 
call signaling using Presence Information Data Format--Location Object 
(PIDF-LO) \3\ or the functional equivalent. In Phase 2, the OSP must 
install and put into operation all equipment, software applications, 
and other infrastructure, or acquire all services, necessary to use a 
Location Information Server (LIS) or its functional equivalent for the 
verification of its customer location information and records.\4\ Phase 
2 will facilitate use of

[[Page 78067]]

the functional elements of Next Generation 911 Core Services (NGCS), 
which can deliver dynamic information to Public Safety Answering Points 
(PSAPs), enabling them to use policy routing functions to dynamically 
reroute 911 traffic to avoid network disruptions, thus reducing the 
impact of outages on 911 continuity.
---------------------------------------------------------------------------

    \3\ See Internet Engineering Task Force (IETF), Dynamic 
Extensions to the Presence Information Data Format Location Object 
(PIDF-LO) (Sept. 2010), https://datatracker.ietf.org/doc/html/rfc5962 (RFC 5962), and A Presence-based GEOPRIV Location Object 
Format (Dec. 2005), https://datatracker.ietf.org/doc/html/rfc4119 
(RFC 4119).
    \4\ ``Location Information Server (LIS)'' means ``[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.''
---------------------------------------------------------------------------

    For both Phase 1 and Phase 2, 911 Authorities must meet specific 
readiness criteria in order to make a valid request for OSP delivery of 
NG911 traffic. For Phase 1, the 911 Authority must certify that it has 
all the necessary infrastructure installed and operational to receive 
911 traffic in SIP format and to transmit such traffic to the PSAPs 
connected to it. The 911 Authority must also identify the NG911 
Delivery Points that it has designated and notify the OSP(s) of these 
delivery points via a registry or direct written notification. For 
Phase 2, the 911 Authority must certify: (1) that it has all of the 
necessary infrastructure installed and operational to receive 911 
traffic in SIP format that complies with NG911 commonly accepted 
standards and to transmit such traffic to the PSAPs connected to it; 
and (2) that its ESInet is connected to a fully functioning NGCS 
network that can provide access to a Location Validation Function (LVF) 
and interface with the LIS or functional equivalent provided by the 
OSP.\5\
---------------------------------------------------------------------------

    \5\ In the NG911 environment, a LVF works with the LIS to 
validate the location of a civic address prior to a call being 
placed to 911. See, e.g., NENA: The 9-1-1 Association (NENA), The 
Next Generation 9-1-1 Guide for 9-1-1 Authorities at 38 (Apr. 21, 
2020) https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/nena-ref-005.1-2020_ng911_gu.pdf (NENA NG911 Guide for 911 
Authorities). The functionality of the LVF within NG911 replaces the 
E911 master street address guide (MSAG) validation in legacy 911 
environments. Id. In this document and the Order, we define 
``Location Validation Function'' (LVF) as ``[a] Functional Element 
in an 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.''
---------------------------------------------------------------------------

    Nationwide CMRS providers,\6\ covered text providers,\7\ 
interconnected VoIP providers, and wireline providers other than rural 
incumbent local exchange carriers (RLECs) will have six months 
following a 911 Authority's valid Phase 1 request to comply with Phase 
1 requirements, and six months following a valid Phase 2 request to 
comply with Phase 2 requirements. RLECs,\8\ non-nationwide CMRS 
providers,\9\ and internet-based TRS providers will have one year 
following a 911 Authority's valid Phase 1 request to comply with Phase 
1 requirements, and one year following a valid Phase 2 request to 
comply with Phase 2 requirements. Completion of Phase 1 is a 
prerequisite to commencement of Phase 2; however, if Phase 1 has 
already been achieved or an OSP completes Phase 1 in less than the 
allotted six-month or one-year period, the Phase 2 implementation 
period can commence immediately, provided the 911 Authority has met the 
Phase 2 readiness criteria. To facilitate collaboration between 911 
Authorities and OSPs, we also permit 911 Authorities and OSPs to enter 
into mutual agreements that modify the Phase 1/Phase 2 terms and 
timelines, and our rules presumptively do not alter or invalidate such 
agreements that already exist.
---------------------------------------------------------------------------

    \6\ The term ``nationwide CMRS provider'' has the meaning given 
such term under 47 CFR 9.10(i)(1)(iv).
    \7\ The term ``covered text provider'' has the meaning given 
such term under 47 CFR 9.10(q)(1).
    \8\ ``Rural incumbent local exchange carrier (RLEC)'' has the 
meaning given such term under 47 CFR 54.5.
    \9\ A ``non-nationwide CMRS provider'' has the meaning given 
such term under 47 CFR 9.10(i)(1)(v).
---------------------------------------------------------------------------

    The rules presumptively address cost allocation between OSPs and 
911 Authorities for implementation of NG911. In the absence of an 
alternative cost arrangement implemented by a 911 Authority at the 
state or local level, OSPs will be financially responsible for the 
costs of transmitting 911 traffic to the NG911 Delivery Points 
designated by 911 Authorities starting at Phase 1. Thus, by default, 
our rules establish NG911 Delivery Points as the demarcation points 
where the OSP's responsibility for the cost of transmitting 911 traffic 
ends and the 911 Authority's responsibility begins. In addition, in 
both Phase 1 and Phase 2, OSPs will be presumptively responsible for 
the costs associated with translating 911 traffic into the required IP-
based format, including associated routing and location information.
    The rules are intended to expedite the NG911 transition and help 
ensure that the nation's 911 system functions effectively and reliably, 
with advanced capabilities. In addition, the rules respond to the 
petition filed in 2021 by the National Association of State 911 
Administrators (NASNA),\10\ which urged the Commission to take actions 
to resolve uncertainty and disputes between OSPs and state 911 
Authorities regarding the NG911 transition. The rules create a 
consistent framework for ensuring that OSPs take the necessary steps to 
implement the transition to NG911 capabilities in coordination with 911 
Authorities. At the same time, we recognize and do not preempt the 
long-standing authority of State and local government over the 
provision of 911 service. Thus, 911 Authorities at the State, local, 
and Tribal level remain free to establish alternative provisions within 
their jurisdictions for the implementation of NG911, definition of 
demarcation points, and allocation and recovery of costs.
---------------------------------------------------------------------------

    \10\ Petition for Rulemaking; Alternatively, Petition for Notice 
of Inquiry, CC Docket No. 94-102, PS Docket Nos. 18-64, 18-261, 11-
153, and 10-255 (filed Oct. 19, 2021), https://www.fcc.gov/ecfs/document/1019188969473/1 (NASNA Petition).
---------------------------------------------------------------------------

II. Background

    911 service is a vital part of our nation's emergency response and 
disaster preparedness system. Since the first 911 call was placed in 
1968,\11\ the American public has increasingly come to depend on 911 
service. The National Emergency Number Association (NENA) estimates 
that some form of 911 service is available to over 98 percent of the 
population and to over 97 percent of the counties in the United 
States,\12\ and data collected in our annual 911 fee report indicate 
that over 217 million calls are made to 911 in the United States each 
year.\13\ The availability of this critical service is due largely to 
the dedicated efforts of State, local, territorial, and Tribal 
authorities and providers, who have used the 911 dialing code to 
provide access to increasingly advanced and effective emergency service 
capabilities.\14\
---------------------------------------------------------------------------

    \11\ Federal Communications Commission (FCC), 911 and E911 
Services, https://www.fcc.gov/general/9-1-1-and-e9-1-1-services (May 
15, 2024).
    \12\ NENA, 9-1-1 Statistics, https://www.nena.org/page/911Statistics (last visited May 29, 2024).
    \13\ FCC, Fifteenth Annual Report to Congress on State 
Collection and Distribution of 911 and Enhanced 911 Fees and Charges 
at 16, tbl.3 (2023), https://www.fcc.gov/sites/default/files/15th-annual-911-fee-report-2023.pdf (Fifteenth Annual 911 Fee Report).
    \14\ See Implementation of 911 Act; The Use of N11 Codes and 
Other Abbreviated Dialing Arrangements, WT Docket No. 00-110, CC 
Docket No. 92-105, Fourth Report and Order and Third Notice of 
Proposed Rulemaking (65 FR 56752 (Sept. 19, 2000)), and Notice of 
Proposed Rulemaking (65 FR 56757 (Sept. 19, 2000)), 15 FCC Rcd 
17079, 17084, para. 9 (2000) (911 Implementation Notice).
---------------------------------------------------------------------------

A. 911 Implementation

    The Universal Emergency Number. In 1999, Congress amended section 
251(e) of the Communications Act of 1934, as amended (the Act), and 
directed the Commission to designate ``911'' as the nationwide 
abbreviated dialing code for wireline and wireless voice services in 
order to obtain public safety and emergency services.\15\ In 2000, the

[[Page 78068]]

Commission designated 911 as the national emergency telephone number to 
be used for reporting emergencies and requesting emergency 
assistance.\16\ In 2001, the Commission established a period for 
wireline and wireless carriers to transition to routing 911 calls to a 
PSAP in areas where one had been designated or, in areas where a PSAP 
had not yet been designated, either to an existing statewide default 
point or to an appropriate local emergency authority.\17\
---------------------------------------------------------------------------

    \15\ Wireless Communications and Public Safety Act of 1999, 
Public Law 106-81, sec. 3(a), 113 Stat. 1286, 1287 (911 Act) 
(codified at 47 U.S.C. 251(e)(3)). The purpose of the 911 Act is to 
enhance public safety by encouraging and facilitating the prompt 
deployment of a nationwide, seamless communications infrastructure 
for emergency services that includes wireless communications. 911 
Implementation Notice, 15 FCC Rcd at 17081, para. 1 (citing 911 Act 
sec. 2(b)). The 911 Act further directs the Commission to encourage 
and support the states in developing comprehensive emergency 
communications throughout the United States so that all 
jurisdictions offer seamless networks for prompt emergency service. 
Id.
    \16\ 911 Implementation Notice, 15 FCC Rcd at 17084-85, para. 
11.
    \17\ See Implementation of 911 Act; The Use of N11 Codes and 
Other Abbreviated Dialing Arrangements, WT Docket No. 00-110, CC 
Docket No. 92-105, Fifth Report and Order, First Report and Order, 
and Memorandum Opinion and Order on Reconsideration, 16 FCC Rcd 
22264, 22293-95, app. B (2001), 67 FR 1643 (Jan. 14, 2002) (911 
Implementation Order). The Commission codified in former Sec.  
64.3001 the obligation of telecommunications carriers to transmit 
all 911 calls to a PSAP, to a designated statewide default answering 
point, or to an appropriate local emergency authority. Id. In 
addition, the Commission codified in former Sec.  64.3002 the 
periods for transition to 911 as the universal emergency telephone 
number. Id. The Commission subsequently renumbered Sec. Sec.  
64.3001 and 64.3002 as current Sec. Sec.  9.4 and 9.5, respectively. 
Implementing Kari's Law and Section 506 of RAY BAUM'S Act; Inquiry 
Concerning 911 Access, Routing, and Location in Enterprise 
Communications Systems; Amending the Definition of Interconnected 
VoIP Service in Section 9.3 of the Commission's Rules, PS Docket 
Nos. 18-261 and 17-239, GN Docket No. 11-117, Report and Order, 34 
FCC Rcd 6607, 6742, app. B (2019), 84 FR 66716 (Dec. 5, 2019) 
(Kari's Law/RAY BAUM'S Act Order), corrected by Erratum, 34 FCC Rcd 
11073 (PSHSB 2019), 85 FR 9390 (Feb. 19, 2020), also corrected by 
Second Erratum, 37 FCC Rcd 10274 (PSHSB 2022), 87 FR 60104 (Oct. 4, 
2022); see 47 CFR 9.4, 9.5.
---------------------------------------------------------------------------

    Legacy 911 Call Routing. In legacy E911 systems, 911 calls are 
typically routed through the use of a wireline network element--called 
a selective router--to a geographically appropriate PSAP based on the 
caller's location.\18\ The selective router serves as the entry point 
for wireline 911 calls originated from competitive and incumbent Local 
Exchange Carrier (LEC) central offices over dedicated trunks,\19\ as 
well as 911 calls originated by wireless \20\ and interconnected VoIP 
\21\ callers that are delivered by wireless and interconnected VoIP 
networks to the selective router. In legacy architectures, PSAPs are 
connected to telephone switches in the selective router by dedicated 
trunk lines.\22\ Historically, the selective router and connecting 
trunk lines have been implemented, operated, and maintained by a subset 
of incumbent LECs and largely paid for by state or local 911 
authorities through state tariffs or contracts.\23\ Network 
implementation has varied from carrier to carrier and jurisdiction to 
jurisdiction, but legacy E911 has typically been based on traditional 
circuit-switched architecture and implemented with legacy components 
that place significant limitations on the functions that can be 
performed over the network.\24\ Below is a simplified diagram that 
demonstrates legacy 911 architecture.
---------------------------------------------------------------------------

    \18\ See IP-Enabled Services; E911 Requirements for IP-Enabled 
Service Providers, WC Docket Nos. 04-36 and 05-196, First Report and 
Order (70 FR 37273 (June 29, 2005)) and Notice of Proposed 
Rulemaking (70 FR 37307 (June 29, 2005)), 20 FCC Rcd 10245, 10251, 
10252, paras. 13, 15 (2005) (VoIP 911 Order), aff'd sub nom. Nuvio 
Corp. v. FCC, 473 F.3d 302 (D.C. Cir. 2006). In the event a 911 
Authority has only implemented basic 911, or utilizes a standalone 
ANI/ALI database, the 911 Authority may or may not utilize selective 
routers in its architecture. See Letter from Alexandra Mays, 
Assistant General Counsel & Director, Regulatory Affairs, 
Competitive Carriers Association (CCA), to Marlene H. Dortch, 
Secretary, FCC, at 2 (received July 12, 2024) (CCA July 12, 2024 Ex 
Parte).
    \19\ VoIP 911 Order at 10252, para. 15.
    \20\ See id. at 10252-53, para. 17.
    \21\ See id. at 10269, paras. 40-41.
    \22\ See id. at 10250-51, para. 12.
    \23\ Id. at 10251, para. 14.
    \24\ Id. at 10252, para. 14.
    [GRAPHIC] [TIFF OMITTED] TR24SE24.001
    
    Legacy Demarcation Point. Although the Commission has not 
previously set a cost demarcation point for wireline, interconnected 
VoIP, or internet-based TRS providers in the E911 environment, the 
Commission has set a demarcation point for purposes of the wireless 
transition to E911. Early in the implementation of E911 Phase I by 
wireless carriers, King County, Washington sought clarification of the 
demarcation point for costs in wireless

[[Page 78069]]

E911 Phase I implementation.\25\ In 2001, the Wireless 
Telecommunications Bureau (WTB) issued a decision (King County Letter) 
identifying the input to the 911 selective router maintained by the 
incumbent LEC as the ``proper demarcation point'' for allocating 
wireless E911 Phase I information delivery responsibilities and costs 
in instances when CMRS providers and 911 authorities could not agree on 
an appropriate demarcation point.\26\ In 2002, the Commission issued an 
Order on Reconsideration (King County Order on Reconsideration) 
affirming WTB's decision.\27\ The Commission affirmed that for a 
wireless carrier to satisfy its obligation to provide E911 Phase I 
information to the PSAP under section 20.18(d) (now section 9.10(d)), 
the wireless carrier must deliver and bear the costs to deliver E911 
Phase I information to the equipment in the existing 911 system that 
``analyzes and distributes it,'' i.e., the 911 selective router.\28\ 
The Commission also affirmed that PSAPs were required to bear E911 
Phase I costs for delivery beyond the 911 selective router.\29\ 
Finally, the Commission extended this determination to apply to CMRS 
providers' delivery of wireless E911 Phase II information to selective 
routers.\30\ Together, these decisions provided guidance to facilitate 
implementation of E911 in TDM networks. However, the Commission has not 
previously sought to address the demarcation of service providers' cost 
responsibilities in the NG911 environment.
---------------------------------------------------------------------------

    \25\ Letter from Marlys R. Davis, E911 Program Manager, King 
County E-911 Program Office, Department of Information and 
Administrative Services, to Thomas J. Sugrue, Chief, Wireless 
Telecommunications Bureau, Federal Communications Commission (May 
25, 2000).
    \26\ Letter from Thomas J. Sugrue, Chief, Wireless 
Telecommunications Bureau, FCC, to Marlys R. Davis, E911 Program 
Manager, King County E-911 Program Office, Department of Information 
and Administrative Services, King County, Washington, 2001 WL 
491934, at *1 (WTB May 7, 2001) (King County Letter) (clarifying 
that ``wireless carriers are responsible for the costs of all 
hardware and software components and functionalities that precede 
the 911 Selective Router'' and that ``PSAPs . . . must bear the 
costs of maintaining and/or upgrading the E911 components and 
functionalities beyond the input to the 911 Selective Router'').
    \27\ Revision of the Commission's Rules to Ensure Compatibility 
with Enhanced 911 Emergency Calling Systems; Request of King County, 
Washington, CC Docket No. 94-102, Order on Reconsideration, 17 FCC 
Rcd 14789, 14789, 14793, paras. 1, 9-10 (2002) (King County Order on 
Reconsideration) (affirming the King County Letter on 
reconsideration and extending WTB's analysis to E911 Phase II 
service).
    \28\ King County Order on Reconsideration, 17 FCC Rcd at 14790, 
14792-93, paras. 4, 7-8.
    \29\ See id. at 14790-91, 14792-93, paras. 4, 7-8.
    \30\ Id. at 14793, paras. 9-10.
---------------------------------------------------------------------------

    Interconnected Voice Over Internet Protocol (VoIP). Regarding 
interconnected VoIP, the Commission has recognized that consumers 
expect certain types of emerging voice technology to have the same 
ability to reach emergency services when dialing 911 as traditional 
wireline and wireless services.\31\ This recognition resulted in the 
2005 VoIP 911 Order, in which the Commission imposed 911 service 
obligations on providers of interconnected VoIP.\32\ The Commission 
declined to establish an E911 demarcation point for interconnected VoIP 
service, but it stated that ``[t]o the extent that it becomes a 
concern, we believe that the demarcation point that the Commission 
established for wireless E911 cost allocation would be equally 
appropriate for VoIP.'' \33\
---------------------------------------------------------------------------

    \31\ See, e.g., VoIP 911 Order, 20 FCC Rcd at 10247-48, paras. 
4-5.
    \32\ Id. at 10246, 10256, paras. 1, 22; see also 47 CFR 9.3 
(defining interconnected VoIP service), 9.11-9.12 (giving 
interconnected VoIP providers duties and rights with respect to 
provision of 911 service). The Commission later clarified that the 
911 VoIP requirements extended to ``outbound only'' interconnected 
VoIP providers, that is, VoIP providers that permit users to 
initiate calls that terminate to the PSTN even if they do not also 
allow users to receive calls from the PSTN. Kari's Law/RAY BAUM'S 
Act Order, 34 FCC Rcd at 6670-71, 6675, paras. 174, 183. While 
section 615b uses the term ``IP-enabled voice service,'' it defines 
this term as having the same meaning as ``interconnected VoIP'' in 
Sec.  9.3 of the Commission's rules. 47 U.S.C. 615b(8). We refer to 
both of these terms in this document and the Order as 
``interconnected VoIP service'' (and to providers of such a service 
as ``interconnected VoIP providers'') and in doing so intend to 
encompass all VoIP services subject to 911 obligations under part 9 
of our rules, including providers of internet Protocol Captioned 
Telephone Service (IP CTS), who are also the providers of the 
associated interconnected VoIP service. IP CTS is a form of 
Telecommunications Relay Service (TRS) ``that permits an individual 
with a hearing or a speech disability to communicate in text using 
an internet Protocol-enabled device via the internet, rather than 
using a text telephone (TTY) and the public switched telephone 
network.'' 47 CFR 64.601(a)(24). We also include other providers of 
internet-based TRS, video relay service (VRS), and Internet Protocol 
Relay Service (IP Relay).
    \33\ VoIP 911 Order, 20 FCC Rcd at 10274, para. 53 n.164.
---------------------------------------------------------------------------

    911 Parity. By 2008, Congress recognized that the nation's 911 
system was ``evolving from its origins in the circuit-switched world 
into an IP-based network'' \34\ and that for interconnected VoIP 
providers to fulfill their 911 service obligations to subscribers, they 
must have access to the same emergency services capabilities and 
infrastructure as other voice providers.\35\ Congress passed the New 
and Emerging Technologies Improvement Act of 2008 (NET 911 Act) to 
facilitate the rapid deployment of VoIP 911 services and encourage the 
transition to a national IP-enabled emergency network.\36\ The NET 911 
Act extended critical 911 service-related rights, protections, and 
obligations to VoIP service providers,\37\ and mandated parity for VoIP 
providers vis-[agrave]-vis other voice providers subject to 911 
obligations with respect to the rates, terms, and conditions applicable 
to exercising their rights and obligations to provision VoIP 911 
service.\38\
---------------------------------------------------------------------------

    \34\ Implementation of the NET 911 Improvement Act of 2008, WC 
Docket No. 08-171, Report and Order, 23 FCC Rcd 15884, 15893, para. 
22, 74 FR 31860 (July 6, 2009) (citing New and Emerging Technologies 
911 Improvement Act of 2008, Pub. L. 110-283, Preamble, sec.102, 122 
Stat. 2620 (2008) (NET 911 Act).
    \35\ See H.R. Rep. No. 110-442, at 6-7 (2007).
    \36\ NET 911 Act, Preamble.
    \37\ Id. secs. 101, 201(a).
    \38\ Id. sec. 101(2) (codified at 47 U.S.C. 615a-1(b)).
---------------------------------------------------------------------------

B. Transition to Next Generation 911

1. Legal and Policy Landscape
    Like communications networks generally, 911 networks are evolving 
from TDM-based architectures to IP-based architectures. With the 
transition to NG911, the circuit-switched architecture of legacy 911 
will eventually be entirely replaced by IP-based technologies and 
applications that provide all of the same functions as the legacy 911 
system, as well as new capabilities. In its end state, NG911 will 
facilitate interoperability and system resilience, improve connections 
between 911 call centers, and support the transmission of text, photos, 
videos, and data to PSAPs by individuals seeking emergency 
assistance.\39\
---------------------------------------------------------------------------

    \39\ See, e.g., City of New York Office of Technology & 
Innovation, 2022 Annual Report on Implementation of Next Generation 
9-1-1 in NYC at 4 (2022), https://www.nyc.gov/assets/oti/downloads/pdf/reports/annual-report-next-generation-911-2022.pdf (listing the 
primary technical benefits of NG911); see also NENA, Why NG9-1-1 at 
1-2 (2009), https://cdn.ymaws.com/www.nena.org/resource/resmgr/ng9-1-1_project/whyng911.pdf (identifying the purposes of NG911).
---------------------------------------------------------------------------

    Congress has recognized the Commission's role in facilitating the 
transition to NG911. As part of the 2010 National Broadband Plan, the 
Commission recommended that Congress consider developing a new ``legal 
and regulatory framework for development of NG911 and the transition 
from legacy 911 to NG911 networks.'' \40\ Also in 2010, Congress 
enacted the Twenty-First Century Communications and Video Accessibility 
Act (CVAA), which authorized the Commission to implement regulations 
necessary to achieve reliable and interoperable communication that 
ensures access to

[[Page 78070]]

an IP-enabled emergency network by individuals with disabilities, where 
achievable and technically feasible.\41\ In 2012, Congress enacted the 
Next Generation 9-1-1 Advancement Act of 2012 (NG911 Act) as part of 
the Middle Class Tax Relief and Job Creation Act of 2012, and directed 
the Commission to prepare and submit a report to Congress on 
recommendations for the legal and statutory framework for NG911 
services.\42\ In 2013, the Commission submitted that report, 
recommending among other things that Congress: (1) facilitate the 
exercise of existing authority over NG911 by certain federal agencies 
(including the Commission); and (2) consider enacting legislation that 
would ensure there is no gap between federal and state authority over 
NG911.\43\ The Commission stated that ``[t]he Commission already has 
sufficient authority to regulate the 911 and NG911 activity of, inter 
alia, wireline and wireless carriers, interconnected VoIP providers, 
and other IP-based service providers.'' \44\
---------------------------------------------------------------------------

    \40\ FCC, Connecting America: The National Broadband Plan, 
Recommendation 16.14 at 326 (2010), http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-296935A1.pdf (last visited May 16, 
2023) (National Broadband Plan).
    \41\ Twenty-First Century Communications and Video Accessibility 
Act of 2010, Public Law 111-260, 124 Stat 2751 sec. 106(g) (2010) 
(CVAA) (codified at 47 U.S.C. 615c(g)).
    \42\ Middle Class Tax Relief and Job Creation Act of 2012, 
Public Law 112-96 (2012), Title VI, Subtitle E, Next Generation 9-1-
1 Advancement Act (NG911 Act) sec. 6509.
    \43\ FCC, Legal and Regulatory Framework for Next Generation 911 
Services, Section 4.1.2.2 at 28-29 (2013), https://transition.fcc.gov/Daily_Releases/Daily_Business/2013/db0227/DOC-319165A1.pdf (last visited May 16, 2023) (2013 NG911 Framework 
Report).
    \44\ Id. at 28.
---------------------------------------------------------------------------

    The technological and regulatory landscape underlying 911 has 
evolved significantly since 2013. The Commission has adopted 
requirements for text-to-911, real-time text, wireless indoor location 
accuracy, and dispatchable location.\45\ In addition, the Commission 
has updated 911 outage and reliability rules, including establishing 
reliability requirements for covered 911 service providers.\46\ With 
respect to technology, E911 Phase II is now widely implemented,\47\ and 
many state and local jurisdictions have deployed ESInets and taken 
other transitional steps towards NG911.\48\ Although the NG911 
transition remains ongoing and there are no fully enabled NG911 systems 
yet operating,\49\ the technical architecture of NG911 systems has been 
developed in detail and is well-established,\50\ and one service 
provider--Verizon--states that it has achieved end-to-end readiness 
with two local jurisdictions based on the NENA i3 standard.\51\
---------------------------------------------------------------------------

    \45\ E.g., Facilitating the Deployment of Text-to-911 and Other 
Next Generation 911 Applications; Framework for Next Generation 911 
Deployment, PS Docket Nos. 11-153 and 10-255, Second Report and 
Order (79 FR 55367 (Sept. 16, 2014)) and Third Further Notice of 
Proposed Rulemaking (79 FR 55413 (Sept. 16, 2014)), 29 FCC Rcd 9846 
(2014) (T911 Second Report and Order); Transition from TTY to Real-
Time Text Technology; Petition for Rulemaking to Update the 
Commission's Rules for Access to Support the Transition from TTY to 
Real-Time Text Technology, and Petition for Waiver of Rules 
Requiring Support of TTY Technology, CG Docket No. 16-145, GN Docket 
No. 15-178, Report and Order(82 FR 7699 (Jan. 23, 2017)) and Further 
Notice of Proposed Rulemaking (82 FR 7766 (Jan. 23, 2017)), 31 FCC 
Rcd 13568 (2016); Wireless E911 Location Accuracy Requirements, PS 
Docket No. 07-114, Fourth Report and Order, 30 FCC Rcd 1259 (2015), 
80 FR 11806 (Mar. 4, 2015); Wireless E911 Location Accuracy 
Requirements, PS Docket No. 07-114, Fifth Report and Order (85 FR 
2660 (Jan. 16, 2020)) and Fifth Further Notice of Proposed 
Rulemaking (85 FR 2683 (Jan. 16, 2020)), 34 FCC Rcd 11592 (2019); 
Wireless E911 Location Accuracy Requirements, PS Docket No. 07-114, 
Sixth Report and Order and Order on Reconsideration, 35 FCC Rcd 7752 
(2020), 85 FR 53234 (Aug. 28, 2020); Kari's Law/RAY BAUM'S Act 
Order, 34 FCC Rcd 6607.
    \46\ E.g., Amendments to Part 4 of the Commission's Rules 
Concerning Disruptions to Communications; Improving 911 Reliability; 
New Part 4 of the Commission's Rules Concerning Disruptions to 
Communications, PS Docket Nos. 15-80, 13-75, and 04-35, Second 
Report and Order, 37 FCC Rcd 13847 (2022), 88 FR 9756 (Feb. 15, 
2023).
    \47\ NENA, 9-1-1 Statistics, https://www.nena.org/page/911Statistics (last visited May 16, 2023).
    \48\ According to the most recent National 911 Annual Report, 
2,287 PSAPs reported using an ESInet across 47 states in 2021, 
nearly a 5% increase from the 2020 data. National 911 Program, 
National 911 Annual Report, 2021 Data at 8, 60, 64 (2023), https://www.911.gov/assets/2021-911-Profile-Database-Report_FINAL.pdf 
(National 911 Annual Report).
    \49\ Association of Public-Safety Communications Officials-
International, Inc. (APCO) Comments at 1-2 (rec. Jan. 19, 2022) 
(APCO Comments) (``ECCs should be able to receive, process, and 
share appropriate information with responders in the field and with 
other ECCs in a secure and fully interoperable fashion [but] no part 
of the country can be described as having achieved this vision of 
NG9-1-1 with end-to-end broadband communications for ECCs.''); see 
also APCO, APCO International's Definitive Guide to Next Generation 
9-1-1 at 9 (2022), https://www.apcointl.org/ext/pages/APCOng911Guide/APCO_NG911_Report_Final.pdf (noting that 
comprehensive, end-to-end NG911 ``does not yet exist anywhere in the 
country'').
    \50\ See FCC, Task Force on Optimal PSAP Architecture (TFOPA), 
Adopted Final Report (2016), https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_FINALReport_012916.pdf (TFOPA Final Report).
    \51\ See Press Release, Verizon continues industry leadership 
with additional NG911 i3 deployment (June 20, 2023), https://www.verizon.com/about/news/verizon-continues-industry-leadership-additional-ng911-i3-deployment (discussing i3 deployment in 
Livingston Parish, LA); Press Release, NGA, NGA, Verizon, Logan 
County (W. Va.) deploy nation's first End State NENA i3 (Dec. 16, 
2022), https://www.prnewswire.com/news-releases/nga-verizon-logan-county-w-va-deploy-nations-first-end-state-nena-i3-301705551.html 
(discussing i3 deployment in Logan County, WV).
---------------------------------------------------------------------------

2. Standards Work and Federal Advisory Committee Reports
    NENA i3 Transitional and End State NG911. The public safety 
community has recognized the need to evolve to NG911, and industry 
associations and standards bodies have worked toward defining standard 
architectures and protocols for NG911. For example, NENA's ``i3'' 
standard describes a system architecture for NG911 that standardizes 
the structure and design of the software services, databases, network 
elements, and interfaces needed to process multimedia emergency calls 
and data for NG911.\52\ The i3 standard is intended to ``support[ ] 
end-to-end IP connectivity,'' while using ``gateways . . . to 
accommodate legacy wireline and wireless originating networks that are 
non-IP as well as legacy PSAPs that interconnect to the i3 solution 
architecture.'' \53\ In addition, NENA i3 addresses the concept of the 
ESInet, ``an IP-based inter-network (network or networks) that can be 
shared by all public safety agencies that may be involved in any 
emergency,'' and identifies ``a set of core services that process 9-1-1 
calls on that network (NGCS-NG9-1-1 Core Services).'' \54\ The i3 
standard envisions that NG911 will reach a mature ``end state'' \55\ 
after all PSAPs have migrated from legacy E911 systems based on TDM 
circuit-switched telephony to all-IP systems that operate over ESInets 
and provide the full array of NGCS.\56\ The standard

[[Page 78071]]

also recognizes that achieving end state NG911 will take time and that 
significant intermediate and transitional mechanisms are needed in the 
interim. Accordingly, the i3 standard provides for Legacy Network 
Gateways (LNGs) and other transitional network elements to ensure that 
TDM-based OSPs can originate 911 calls and that legacy PSAPs can 
receive them while the NG911 transition is ongoing.
---------------------------------------------------------------------------

    \52\ NENA, NENA i3 Standard for Next Generation 9-1-1 at 2 (Oct. 
7, 2021), https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-STA-010.3e-2021_i3_Stan.pdf (NENA i3). In July 2021, 
NENA released the third version of the i3 standard for NG911. See 
NENA, NENA Releases New Version of the i3 Standard for Next 
Generation 9-1-1 (July 12, 2021) https://www.nena.org/news/572966/NENA-Releases-New-Version-of-the-i3-Standard-for-Next-Generation-9-1-1.htm. In October 2021, the NENA i3 standard was approved by the 
American National Standards Institute (ANSI). See NENA, ANSI 
Approves NENA's i3 Standard for Next Generation 9-1-1 (Oct. 7, 
2021), https://www.nena.org/news/582667/ANSI-Approves-NENAs-i3-Standard-for-Next-Generation-9-1-1.htm.
    \53\ NENA i3 at 2.
    \54\ NENA i3 at 2 (footnote omitted).
    \55\ The NENA i3 standard describes how NG911 works after 
transition, including ongoing interworking requirements for IP-based 
and Time Division Multiplexed (TDM)-based PSAPs and originating 
networks. The i3 standard does not provide solutions for how legacy 
PSAPs, originating networks, Selective Routers (SRs), and Automatic 
Location Identification (ALI) systems evolve. Rather, the i3 
standard describes the end state when transition is complete. 
According to the NENA i3 standard, ``[a]t that point, SRs and 
existing ALI systems are decommissioned and all 9-1-1 calls are 
routed using the Emergency Call Routing Function (ECRF) and arrive 
at the ESInet/NGCS via Session Initiation Protocol (SIP).'' NENA i3 
at 2.
    \56\ Id. at 2. To get to this ``end state,'' the NENA i3 
standard observes that it is critical to understand several 
underlying assumptions. For example, ``[a]ll calls entering the 
ESInet are SIP-based. Gateways, if needed, are outside of, or on the 
edge of, the ESInet. Calls that are IP-based, but use a protocol 
other than SIP or are not fully i3-compliant, must be interworked to 
i3-compliant SIP prior to being presented to the ESInet.'' NENA i3 
at 3.
---------------------------------------------------------------------------

    Task Force on Optimal PSAP Architecture. In 2014, the FCC 
established the Task Force on Optimal PSAP Architecture (Task Force or 
TFOPA) to provide recommendations regarding actions that PSAPs can take 
to optimize their security, operations, and funding as they implement 
NG911.\57\ In its Final Report, TFOPA noted that the transition to 
NG911 requires comprehensive changes across the ``Originating Service 
Environment (OSE),'' which includes originating service providers as 
part of a broader environment that provides the 911 caller's location 
as part of the call setup.\58\ This environment includes IP call set-
up, location determination, validation, and delivery to ESInets across 
the country.\59\ In addition, the three TFOPA Working Groups issued 
supplemental reports in 2016 concerning (1) an ``Optimal Cybersecurity 
Approach for PSAPs''; \60\ (2) an ``NG 9-1-1 Readiness Scorecard''; 
\61\ and (3) a ``Funding Sustainment Model.'' \62\
---------------------------------------------------------------------------

    \57\ See T911 Second Report and Order, 29 FCC Rcd at 9881, 
paras. 79-80 (2014).
    \58\ TFOPA Final Report at 114.
    \59\ Id. at 105.
    \60\ FCC, Task Force on Optimal PSAP Architecture, Working Group 
1 Supplemental Report (2016), https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG1_Supplemental_Report-120216.pdf (TFOPA WG 1 Report).
    \61\ FCC, Task Force on Optimal PSAP Architecture, Working Group 
2 Supplemental Report (2016), https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG2_Supplemental_Report-120216.pdf (TFOPA WG 2 Report). 
Regarding readiness, TFOPA WG 2, for example, observed that the 
NG911 transition process followed a ``maturity continuum'' ranging 
from a ``legacy state'' through ``foundational, transitional, and 
intermediate'' stages, on the way to a goal of full ``end state'' 
NG911 relative to PSAPs. TFOPA WG 2 Report at 12-14. Specifically, 
the WG 2 Report defined ``Jurisdictional End State'' (noting that a 
jurisdiction could be a Local, Regional, State or Tribal Authority 
and could be intrastate or interstate) as ``the state in which PSAPs 
are served by i3 standards-based systems and/or elements, from 
ingress through multimedia `call' handling. Originating Service 
Providers are providing SIP interfaces and location information 
during call set-up time. Within the jurisdiction, ESInets are 
interconnected providing interoperability which is supported by 
established agreements, policies and procedures. Systems in the End 
State are NG9-1-1 Compliant.'' TFOPA WG 2 Report at 13. Based on 
anecdotal information, including based on ESInet and NG911 early 
adopter case studies, TFOPA WG 2 noted that a ``phased'' 
implementation model offers the greatest opportunity for success, as 
opposed to a one-step implementation. TFOPA WG 2 Report at 12, 76-
88.
    \62\ FCC, Task Force on Optimal PSAP Architecture, Working Group 
3 Supplemental Report (2016), https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG3_Supplemental_Report-120216.pdf (TFOPA WG 3 Report). 
TFOPA WG 3 discusses among other things, 911 network and call 
routing, including providing historical context regarding the 
relationship between 911 networks and 911 jurisdictions relative to 
selective routing, and the role of FCC rules and state policies 
relative to originating service provider cost responsibilities. 
TFOPA WG 3 Report at 19-20.
---------------------------------------------------------------------------

    Communications Security, Reliability, and Interoperability Council 
(CSRIC) VI and Small Carrier NG911 Considerations. In 2017, the 
Commission directed CSRIC VI to recommend measures to improve both 
legacy 911 and NG911 systems, including recommending ways in which the 
Commission can further the NG911 transition, enhance the reliability 
and effectiveness of NG911, and assist small originating service 
providers as they transition to providing NG911 service.\63\ The CSRIC 
VI Working Group 1 considered four types of small originating service 
providers: wireless carriers, LECs, television cable operators, and 
internet/Data Service Providers.\64\ The CSRIC NG911 Transition Report 
describes the issues these carriers face as they update their networks 
to support NG911, and it advises the FCC on small carrier concerns 
related to NG911 implementation.\65\ The Transition Report is organized 
into three major sections, dealing with the scope and nature of the 
report; \66\ analysis, findings and recommendations; \67\ and a small 
carrier readiness checklist \68\ structured around service provider 
support for migration to NG911. The report's recommendations relating 
to small carriers address: (1) transition timelines; \69\ (2) the 
regulatory environment; \70\ (3) NG911 funding; \71\ (4) 
interconnection options; \72\ and (5) delivering caller location to the 
NG911 ESInet.\73\ The report includes advice on how small carriers 
should prepare to deliver their 911 traffic in an NG911 compatible 
manner; what economic challenges small carriers may face; and what 
barriers to implementation, if any, the FCC should address.\74\
---------------------------------------------------------------------------

    \63\ CSRIC VI Working Group 1, Transition Path to NG9-1-1 Final 
Report--Small Carrier NG9-1-1 Transition Considerations, secs. 1.1, 
3.1 (Sept. 2018), https://www.fcc.gov/sites/default/files/csric6wg1sept18ng911report.docx (CSRIC NG911 Transition Report). The 
FCC charged CSRIC VI with defining the long term network 
requirements for transmitting emergency services information to 
emergency services organizations and personnel that is beyond 
communications between PSAPs, and between the public and PSAPs. Id. 
sec. 1.1. CSRIC VI Working Group 1 was charged to specifically look 
at service provider support for public safety transition to NG911. 
Id.
    \64\ Id. sec. 1.1.
    \65\ Id.
    \66\ Id. sec. 3.
    \67\ The ``Analysis, Findings and Recommendation'' section 
builds on a review of today's legacy environment and addresses 
service provider interconnection with both transitionary and ``end-
state'' NG9-1-1 systems, call and data related matters, security, 
and regulatory/policy factors. Id. sec. 5.1.
    \68\ The small carrier checklist is structured around three 
stages of small carrier ``readiness'' to support NG9-1-1. Id. sec. 
5.2. Essential ``elements'' of readiness are identified, ranging 
from public safety governance and regulatory matters, to routing and 
location matters, geographic information system (GIS) needs, network 
considerations, security and operational planning requirements. Id.
    \69\ CSRIC advises that small carrier transition timelines will 
vary by carrier depending on the resources they have available to 
focus on the transition and notes that it is important that small 
carriers work with their state or regional 911 Authority to 
coordinate their transition timelines and expectations. Id. sec. 
5.1.6.1.
    \70\ Historically, state and Federal statutes or regulations 
regarding time division multiplex (TDM) network interconnection to a 
legacy 9-1-1 selective router in a particular Local Access and 
Transport Area (LATA) by small carriers has often been based on the 
process for interconnecting with the largest incumbent Local 
Exchange Carrier (ILEC) in an area. Id. sec. 4.1 As traffic exchange 
evolves into full IP environment, regulatory and technical 
expectations and responsibilities may change. Id. sec. 1.1.
    \71\ CSRIC advises that 911 Authorities should understand 
historical cost recovery models for rural carriers and remain 
flexible to accommodate any economic challenges caused by the 
migration to NG911. Id. sec. 1.1.
    \72\ Id. sec. 1.1 (``Small carriers need to evaluate the 
interconnection options to the NG9-1-1 ESInet based upon 
negotiations with the NG9-1-1 System Service Provider (SSP). They 
may interconnect with native IP or via gateways based upon their own 
network transition plans.'').
    \73\ Id. sec. 5.2.2 (``[A] `pure' or `end-state' NG9-1-1 
implementation assumes OSPs have changed the means by which they 
deliver 9-1-1 calls, however it is not realistic or expected that 
all small carrier OSPs will change at the same time. Therefore, the 
model is complicated by mechanisms to `transition' from legacy 
methods to NG9-1-1 methods. The LNG is required until all OSPs 
deliver location information with their 9-1-1 call setup messages 
(location-by-value) or provide location databases that may be 
queried (location-by-reference).'').
    \74\ See id. secs. 1.1, 3.2.
---------------------------------------------------------------------------

    One of CSRIC's chief recommendations was for the Commission to 
``explore opportunities to resolve [the] cost recover[y] debate,'' 
referring to disputes between carriers and 911 Authorities over how to 
fairly allocate the costs of NG911 networks.\75\ CSRIC suggested that 
the Commission update its King County decision in order to resolve 
ongoing uncertainty about cost responsibilities in the NG911 
environment.\76\ CSRIC also suggested a three-stage structure for the 
transition to NG911, ranging from current legacy 911 systems; through a 
``transitionary phase'' in which carriers may not yet

[[Page 78072]]

originate 911 traffic in IP but are able to interconnect with a 911 
Authority's ESInet and deliver IP-based traffic via IP translation; and 
an ``End State . . . where the small carrier has deployed an IP-based 
network.'' \77\ In CSRIC's transitionary phase, the originating service 
provider would deliver 911 calls in IP via one of two options--either 
(1) by providing an LNG itself and converting its TDM signaling to SIP 
before interconnecting with the ESInet using native SIP and converting 
the legacy data access protocols (e.g. E2) to those used by the ESInet, 
or (2) by using legacy signaling (e.g., TDM) and data access protocols 
(e.g., E2) to interconnect with the ESInet at an LNG provided by the 
ESInet vendor.\78\ CSRIC also suggested that smaller carriers with 
fewer resources may need a longer timeline to transition to NG911, and 
it stressed the importance of coordination between carriers and 911 
Authorities.\79\ Overall, the CSRIC NG911 Transition Report called on 
the FCC to provide structure and certainty to the NG911 transition via 
rulemaking while maintaining some flexibility and accounting for 
smaller carriers' more-limited resources.
---------------------------------------------------------------------------

    \75\ Id. sec. 5.1.5.
    \76\ Id.
    \77\ Id. sec. 5.2.1.
    \78\ Id. sec. 5.2.1. At the transitionary phase, CSRIC 
anticipates that the ESInet vendor would have ``deployed aspects of 
NG9-1-1 as discussed in the Transitional State, Intermediate State 
or Jurisdictional End State as defined by the TFOPA Report.'' Id.
    \79\ Id. sec. 5.1.6.
---------------------------------------------------------------------------

C. Recent Regulatory Changes

    NASNA Petition. In October 2021, NASNA filed a petition asking the 
Commission to initiate a rulemaking or notice of inquiry to facilitate 
the transition to NG911 (NASNA Petition).\80\ Specifically, NASNA asked 
the Commission to assert authority over the delivery of 911 
communications by OSPs to ESInets and to amend the Commission's rules 
as needed to advance the transition to NG911.\81\ As part of its 
petition, NASNA urged the Commission to set a default cost demarcation 
point in the NG911 environment analogous to its King County ruling in 
the E911 environment.\82\ NASNA also asked the Commission to set 
deadlines for OSPs to begin delivering 911 traffic in NG911 format when 
the relevant state or local 911 Authority achieves NG911 readiness, and 
to establish a registry through which 911 authorities would notify OSPs 
of their NG911 readiness status.\83\ The Public Safety and Homeland 
Security Bureau (PSHSB or Bureau) placed the Petition on public notice 
in December 2021, and received twenty-two comments, eight replies, and 
seven ex partes.\84\
---------------------------------------------------------------------------

    \80\ NASNA Petition at 1.
    \81\ Id. at 2, 4-5.
    \82\ Id. at 2-3, 5-7.
    \83\ Id. at 3, 7-8.
    \84\ Public Safety and Homeland Security Bureau Seeks Comment on 
Petition for Rulemaking Filed by the National Association of State 
911 Administrators, CC Docket No. 94-102 and PS Docket Nos. 21-479, 
18-261, 18-64, 11-153, and 10-255, Public Notice, 36 FCC Rcd 17805 
(PSHSB 2021), https://www.fcc.gov/document/pshsb-seeks-comment-nasna-petition-rulemaking (Public Notice). Comments, replies, and ex 
partes in this proceeding may be viewed in the Commission's 
Electronic Comment Filing System (ECFS): https://www.fcc.gov/ecfs/search/search-filings/results?q=(proceedings.name:(%2221-479%22)).
---------------------------------------------------------------------------

    Wireless Location-Based Routing. In December 2022, the Commission 
issued the Location-Based Routing Notice proposing to require CMRS and 
covered text providers to implement location-based routing for 911 
calls and texts nationwide.\85\ As part of that proceeding, the 
Commission sought comment on aspects of the NG911 transition raised by 
the NASNA Petition as they applied to CMRS and covered text providers. 
Specifically, the Commission proposed to require CMRS and covered text 
providers to deliver 911 calls, texts, and associated routing 
information in IP format upon request of 911 Authorities that have 
established the capability to accept NG911-compatible IP-based 911 
communications.\86\ In addition, the Commission proposed to establish 
time frames for CMRS and covered text providers to deliver IP-based 911 
traffic.\87\ Further, the Commission sought comment on whether to make 
available a registry or database that would allow state and local 911 
authorities to notify CMRS and covered text providers of the 911 
authorities' readiness to accept IP-based communications.\88\ The 
Commission noted that these proposals, if adopted, would effectively 
implement a key element of NASNA's petition with respect to transition 
to NG911 for wireless 911 calls and texts, which represent an estimated 
80 percent of 911 traffic in many areas.\89\
---------------------------------------------------------------------------

    \85\ Location-Based Routing for Wireless 911 Calls, PS Docket 
No. 18-64, Notice of Proposed Rulemaking, 37 FCC Rcd 15183, 15184, 
para. 1 & n.1 (2022), 88 FR 2565 (Jan. 17, 2023) (LBR Notice).
    \86\ Id. at 15185, 15202, paras. 4, 46.
    \87\ Id. at 15203, para. 50.
    \88\ Id. at 15204, para. 52.
    \89\ NENA, 9-1-1 Statistics, https://www.nena.org/page/911Statistics (last visited May 30, 2024).
---------------------------------------------------------------------------

    NG911 Notice Proposed Framework. In June 2023, the Commission 
issued the NG911 Notice seeking to establish a framework that would 
expedite the nation's transition to NG911 by proposing comprehensive 
requirements that would apply to wireline, CMRS, interconnected VoIP, 
and internet-based TRS providers.\90\ First, the Commission proposed to 
require wireline, interconnected VoIP, and internet-based TRS providers 
to complete all translation and routing to deliver 911 calls, including 
associated location information, in the requested IP-based format to an 
ESInet or other designated point(s) that allow emergency calls to be 
answered upon request of 911 authorities who have certified the 
capability to accept IP-based 911 communications.\91\ Second, as state 
and local 911 authorities transition to IP-based networks, the 
Commission proposed to require wireline, interconnected VoIP, CMRS, and 
internet-based TRS providers to transmit all 911 calls to destination 
point(s) designated by a 911 Authority.\92\ Third, the Commission 
proposed that in the absence of agreements by states or localities on 
alternative cost recovery mechanisms, wireline, interconnected VoIP, 
CMRS, and internet-based TRS providers must cover the costs of 
transmitting 911 calls to the point(s) designated by a 911 Authority, 
including any costs associated with completing the translation and 
routing necessary to deliver such calls and associated location 
information to the designated destination point(s) in the requested IP-
based format.\93\
---------------------------------------------------------------------------

    \90\ Facilitating Implementation of Next Generation 911 Services 
(NG911), PS Docket No. 21-479, Notice of Proposed Rulemaking, 38 FCC 
Rcd 6204, 6205-06, para. 2 (2023), 88 FR 43514 (July 10, 2023) 
(NG911 Notice).
    \91\ Id. at 6205-06, para. 2.
    \92\ Id. at 6205-06, para. 2. In the NG911 Notice, ``destination 
point'' includes ``a public safety answering point (PSAP), 
designated statewide default answering point, local emergency 
authority, ESInet, or other point(s) designated by 911 authorities 
that allow emergency calls to be answered, upon request of 911 
authorities who have certified the capability to accept IP-based 911 
communications.'' Id.
    \93\ NG911 Notice, 38 FCC Rcd at 6205-06, para. 2. Under this 
proposal, the Commission noted that ``states and localities would 
remain free to establish alternative cost allocation arrangements 
with providers. However, in the absence of such arrangements, 
providers would be presumptively responsible for the costs 
associated with delivering traffic to the destination point(s) 
identified by the appropriate 911 authority.'' Id.
---------------------------------------------------------------------------

    In the NG911 Notice, the Commission explained that it sought to 
create a consistent framework for ensuring that all originating service 
providers take the necessary steps to implement the transition to NG911 
in coordination with 911 Authorities.\94\ In addition, the Commission 
sought to align the NG911 transition rules for wireline,

[[Page 78073]]

interconnected VoIP, and internet-based TRS providers with similar 
requirements that the Commission had proposed for CMRS and covered text 
providers in the LBR Notice, thereby promoting consistency across 
service platforms.\95\ The Commission also explained that the 
demarcation point and cost allocation proposals sought to address what 
NASNA described in its Petition as ``the critical component, and 
biggest regulatory roadblock, to transitioning to NG911 services.'' 
\96\ PSHSB announced the comment and reply comment filing deadlines for 
the NG911 Notice on July 10, 2023, and the Commission received 47 
comments, 28 replies, and a number of ex partes.\97\
---------------------------------------------------------------------------

    \94\ NG911 Notice, 38 FCC Rcd at 6206, para. 3.
    \95\ Id.
    \96\ Id (citing NASNA Petition at 6).
    \97\ Public Safety and Homeland Security Bureau Announces 
Comment and Reply Comment Dates for the Notice of Proposed 
Rulemaking on Facilitating Implementation of Next Generation 911 
Services (NG911), PS Docket No. 21-479, Public Notice, DA 23-596, 
2023 WL 4503161 (PSHSB July 10, 2023). A list of entities that filed 
comments, replies, and ex partes may be found in Appendix C of the 
Order. Comments, replies, and ex partes in this proceeding may be 
viewed in the Commission's Electronic Comment Filing System (ECFS): 
https://www.fcc.gov/ecfs/search/search-filings/results?q=(proceedings.name:(%2221-479%22)). We note that there are 
also comments, replies, and ex partes filed in response to the LBR 
Notice pertaining to issues that we address in this proceeding. 
Those filings can be viewed in the location-based routing docket (PS 
Docket No. 18-64) in the Commission's ECFS: https://www.fcc.gov/ecfs/search/search-filings/results?q=(proceedings.name:(%2218-
64*%22)).
---------------------------------------------------------------------------

    LBR Order. In 2024, we issued the LBR Order requiring all CMRS 
providers to implement location-based routing nationwide for wireless 
calls and real-time text (RTT) communications to 911 call centers.\98\ 
Under those rules, most 911 voice calls and RTT texts will be routed 
based on the location of the caller as opposed to the location of the 
cell tower that handles that call.\99\ However, we deferred to this 
docket consideration of NG911-related proposals and issues raised in 
the LBR Notice concerning IP-formatted delivery of wireless 911 voice 
calls, texts, and associated routing information.\100\ Accordingly, we 
incorporate comments received on these issues and proposals in response 
to the LBR Notice into this proceeding, and we address the NG911 
requirements applicable to all originating service providers in this 
document and the Order.
---------------------------------------------------------------------------

    \98\ Location-Based Routing for Wireless 911 Calls, PS Docket 
No. 18-64, Report and Order, FCC 24-4, 2024 WL 356874 (Jan. 26, 
2024), https://www.fcc.gov/document/fcc-adopts-rules-improve-wireless-911-call-routing-0, 89 FR 18488 (Mar. 13, 2024) (LBR 
Order).
    \99\ See LBR Order at *2, para. 3.
    \100\ Id. at *2, *24, *32, *37, *38, paras. 3, 66, 92, 110, 113.
---------------------------------------------------------------------------

III. Discussion

    In this document and the Order, we require OSPs to support the 
NG911 transition. In the sections below and in the Order, we explain 
the basis for adopting NG911 transition rules, including the 
significant and potentially life-saving benefits that NG911 affords, 
and we set forth the scope and extent of our NG911 requirements. We 
also find that the deadlines adopted are achievable and technically 
feasible for OSPs.

A. The Need for Rules To Facilitate the NG911 Transition

    In the NG911 Notice and LBR Notice, the Commission proposed to 
expedite the nationwide transition to NG911 by adopting certain 
requirements that would apply to wireline, CMRS, covered text, 
interconnected VoIP, covered text providers, and internet-based TRS 
providers.\101\ Together, our proposals were intended not only to 
expedite this vital transition, but also to help ensure that the 
nation's 911 system functions effectively and utilizes advanced 
capabilities.\102\ In addition, the proposed rules in the NG911 Notice 
responded to the petition from NASNA, the organization that represents 
state 911 administrators, urging the Commission to adopt rules to 
facilitate the transition to NG911.\103\
---------------------------------------------------------------------------

    \101\ NG911 Notice, 38 FCC Rcd at 6205-06, paras. 1-2; LBR 
Notice, 37 FCC Rcd at 15201, para. 46.
    \102\ NG911 Notice, 38 FCC Rcd at 6206, para. 3; LBR Notice, 37 
FCC Rcd at 15202, para. 48.
    \103\ NG911 Notice, 38 FCC Rcd at 6206, para. 3; NASNA Petition.
---------------------------------------------------------------------------

    As the Commission noted in the NG911 Notice, to achieve the 
transition to NG911, state and local 911 authorities must implement IP-
based technologies and applications that will provide all of the 
functions of the legacy E911 system as well as new capabilities.\104\ 
NG911 relies on IP-based architecture to provide an expanded array of 
emergency communications services that encompasses both the core 
functionalities of legacy E911 and additional functionalities that take 
advantage of the enhanced capabilities of IP-based devices and 
networks.\105\ The transition to NG911 involves fundamental changes in 
the technology that 911 Authorities use to receive and process 911 
traffic, and it requires equally fundamental changes in the way OSPs 
deliver 911 traffic to PSAPs.\106\ The benefits that result from the 
transition to NG911 include improvements to 911 network reliability and 
resilience,\107\ improvements to interoperability between PSAPs, and 
location information that is available to PSAPs more quickly. As the 
Commission observed in the NG911 Notice, in its end state, NG911 will 
also support the transmission of text, photos, video, and data.\108\
---------------------------------------------------------------------------

    \104\ NG911 Notice, 38 FCC Rcd at 6212, para. 15.
    \105\ Id.; Framework for Next Generation 911 Deployment, PS 
Docket No. 10-255, Notice of Inquiry, 25 FCC Rcd 17869, 17877, para. 
18 (2010), 76 FR 2297 (Jan. 13, 2011) (NG911 NOI).
    \106\ See NG911 Notice, 38 FCC Rcd at 6212-13, para. 16.
    \107\ Letter from Lauren Kravetz, Vice President, Government 
Affairs, Intrado Life & Safety, Inc. (Intrado), to Marlene Dortch, 
Secretary, FCC, PS Docket No. 21-479, at 1 (filed Mar. 26, 2024) 
(Intrado Mar. 26, 2024 Ex Parte); Industry Council for Emergency 
Response Technologies, Inc. (iCERT) NG911 Notice Comments at 1 (rec. 
Aug. 9, 2023) (iCERT NG911 Notice Comments).
    \108\ NG911 Notice, 38 FCC Rcd at 6209, para. 10 (citing City of 
New York Office of Technology & Innovation, 2022 Annual Report on 
Implementation of Next Generation 9-1-1 in NYC at 4 (2022), https://www.nyc.gov/assets/oti/downloads/pdf/reports/annual-report-next-generation-911-2022.pdf (listing the primary technical benefits of 
NG911)).
---------------------------------------------------------------------------

    Most states have already made significant commitments to 
implementing NG911.\109\ Thirty-seven states and jurisdictions reported 
to the FCC in 2023 that they had ESInets operating in 2022.\110\ 
Despite investments in these new capabilities, however, some states 
report experiencing delays in OSPs connecting to their ESInets.\111\ 
Disputes with OSPs include issues of both cost allocation and the 
points to which the OSPs will deliver 911 traffic.\112\ In addition, 
some commenters contend that some OSPs have financial incentives to 
delay transitioning from legacy 911 to NG911, resulting in protracted 
disputes and mounting costs for 911 Authorities, and

[[Page 78074]]

further contributing to delays.\113\ As a result of these delays, 911 
Authorities incur prolonged and compounded costs because they must 
maintain both legacy and IP networks during the transition.\114\ 
Managing 911 traffic on both legacy and IP networks may also result in 
increased vulnerability and risk of 911 outages.\115\
---------------------------------------------------------------------------

    \109\ Forty-four states, the District of Columbia, Guam, and 
Puerto Rico reported expenditures on NG911 programs in calendar year 
2022. Fifteenth Annual 911 Fee Report at 3. The total amount of 
reported NG911 expenditures in 2022 was $512,168,670.94. Id.
    \110\ Id.
    \111\ See also, e.g., Minnesota Department of Public Safety/
Emergency Communication Networks Division (Minnesota DPS-ECN) NG911 
Public Notice Comments at 1 (rec. Jan. 19, 2022) (Minnesota DPS-ECN 
NG911 Public Notice Comments); Pennsylvania Emergency Management 
Agency (Pennsylvania Emergency Mgmt. Agency) NG911 Public Notice 
Comments at 4-5 (rec. Jan. 19, 2022) (Pennsylvania Emergency Mgmt. 
Agency NG911 Public Notice Comments).
    \112\ See also, e.g., AT&T Services, Inc. (AT&T) NG911 Notice 
Comments at 7 (rec. Aug. 9, 2023) (AT&T NG911 Notice Comments); 
Comtech Telecommunications Corp. (Comtech) NG911 Notice Comments at 
7 (rec. Aug. 9, 2023) (Comtech NG911 Notice Comments) (``[D]isputes 
relating to [point of interconnection] locations and cost 
demarcations are a major source of OSP disputes and delays.''); 
Pennsylvania Emergency Mgmt. Agency NG911 Public Notice Comments at 
4 (``One ILEC is requesting that Pennsylvania build the network all 
the way out to their switch(es) and that [Pennsylvania Emergency 
Mgmt. Agency], or Pennsylvania's NG911 system service provider 
assume all costs associated with this effort.'').
    \113\ See, e.g., Inteliquent, Inc. (Inteliquent) NG911 Notice 
Reply at 2 (rec. Sept. 8, 2023) (``The current arrangement provides 
a disincentive to efficiently migrate to an NG911 system because it 
increases the revenue for a [Covered 911 Service Provider] to 
operate legacy/transitionary 911 services.''); Letter from Susan 
Ornstein, Senior Director, Legal & Regulatory Affairs, Comtech, to 
Marlene H. Dortch, Secretary, FCC, PS Docket No. 21-479, Attach. at 
8 (filed Nov. 6, 2023) (Comtech Nov. 6, 2023 Ex Parte) (reporting 
that it is ``[e]xclusively seeing RLEC resistance to NG911 
transitions,'' that ``[n]otices around NG911 connectivity are 
ignored, not respected or responded to in a timely manner,'' and 
that RLECs have ``[f]inancial incentive for noncooperation with 911 
Authorities''); Comtech NG911 Public Notice Comments at 4-5 (rec. 
Jan. 19, 2022) (Comtech NG911 Public Notice Comments) (``Currently, 
in the absence of an FCC-defined framework for NG911 deployments, 
911 Authorities and NG911 service providers are effectively held 
hostage by OSPs and Legacy 911 Providers' willingness to cause 
delays in the transition process, as such activity is without 
regulatory consequence--and in certain cases--to a delaying 
company's financial benefit.'').
    \114\ See, e.g., iCERT NG911 Notice Reply at 3 (rec. Sept. 8, 
2023) (iCERT NG911 Notice Reply) (``[T]he need to accommodate TDM-
based 911 calls creates added costs for State and local 911 
authorities.''); id. at 4 (``[A]doption of the proposed rule would 
reduce the cost burdens of maintaining and operating legacy 911 
infrastructure''); Comtech NG911 Notice Reply at 4 (rec. Sept. 8, 
2023) (Comtech NG911 Notice Reply) (arguing that maintaining both 
legacy and IP-based systems for delivery of 911 traffic involves 
significant costs); Minnesota DPS-ECN NG911 Notice Comments at 3 
(discussing the costs of maintaining duplicative legacy and NG911 
network components); Nebraska Public Service Commission (Nebraska 
PSC) NG911 Notice Comments at 2 (rec. Aug 9, 2023) (Nebraska PSC 
NG911 Notice Comments) (discussing increased costs until NG911 
transition is complete); South Carolina Revenue and Fiscal Affairs 
Office (South Carolina RFA) NG911 Notice Comments at 4 (rec. Aug. 8, 
2023) (South Carolina RFA NG911 Notice Comments) (providing an 
analysis of cost savings in South Carolina to complete the 
transition to NG911).
    \115\ Motorola Solutions Connectivity, Inc. (MSCI) NG911 Notice 
Comments at 2 (rec. Aug. 9, 2023) (MSCI NG911 Notice Comments); 
Comtech NG911 Notice Comments at 4 (citing MSCI NG911 Notice 
Comments at 2). Specifically, the introduction of IP based elements 
requires dedicated monitoring and security measures separate from 
legacy systems, and the continued presence of legacy components of 
911 networks presents a risk of outages. For example, as noted by 
NASNA, the 911 Authority for the State of California tracks 
reliability and availability of the legacy 911 system and their 
statistics indicate an increase in the rate of downtime. ``In 2017 
the average number of minutes of outage was 17,000 minutes per 
month, but in 2022 the average increased to over 59,000 outage 
minutes per month.'' National Association of State 911 
Administrators (NASNA) LBR Notice Comments at 7-8 (rec. Feb. 16, 
2023) (NASNA LBR Notice Comments). This decrease in the reliability 
of legacy systems will best be offset when NG911 is fully 
implemented.
---------------------------------------------------------------------------

    Adopting rules in this proceeding is necessary to advance the 
critical transition to NG911, with its vital public safety benefits for 
the entire American public. Currently, as 911 Authorities deploy NG911 
infrastructure, there are no rules at the federal level describing what 
OSPs must do to support the transition. The lack of rules creates 
uncertainty for 911 stakeholders and increases delays in the 
transition. In addition, the increased costs incurred to support both 
911 and NG911 systems concurrently while the transition to NG911 is 
delayed reduce the limited amount of funding actually available to 
implement NG911 itself, further stalling the eventual transition to 
lifesaving NG911 technology across the country. The magnitude of delays 
and costs in the national transition to NG911 to date demonstrates the 
necessity and importance of the Commission taking action to establish a 
regulatory framework for the orderly and efficient implementation of 
NG911. In addition, we believe that promulgating a consistent 
regulatory approach to 911 for all OSPs reflects the reality that 
distinctions between OSP types are becoming less relevant as 
technologies converge and advance.\116\ This ``all platforms'' approach 
promotes accountability, transparency, and certainty.
---------------------------------------------------------------------------

    \116\ See CCA July 12, 2024 Ex Parte at 2 (noting that non-
nationwide CMRS providers may also be covered text providers or 
interconnected VoIP providers); but see Letter from Robert G. Morse, 
Associate General Counsel, Federal Regulatory and Legal Affairs, 
Verizon, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 21-
479, 18-64 at 3 (Verizon July 10, 2024 Ex Parte) (arguing that the 
record only reflects interconnection delays for RLECs).
---------------------------------------------------------------------------

    Numerous commenters on the NG911 Notice have voiced support for the 
Commission's goals in this rulemaking and have acknowledged the need 
for rules to facilitate the transition to NG911, although some have 
advocated for changes to the proposed rules.\117\ For example, NASNA 
says it is ``grateful'' to the Commission for its ``forward-thinking 
action in facilitating NG911,'' says ``[t]his rulemaking will be 
instrumental'' in moving NG911 forward, and ``urges timely 
implementation of effective rules to make NG911 a reality nationwide.'' 
The Maine PUC ``applauds the FCC for undertaking this rulemaking to 
expedite the much-needed transition to NG911.'' \118\ The Pennsylvania 
Emergency Management Agency notes that Pennsylvania's ability to 
successfully and completely implement NG911 service and retire legacy 
E911 technologies is hampered by the current lack of rules clarifying 
roles and responsibilities among stakeholders, and that a regulatory 
framework is needed.\119\ Similarly, Communications Equality Advocates 
(CEA) ``[a]pplauds'' the Commission's efforts to pave the way for full 
migration to NG911.\120\ NENA supports the Commission's NG911 
rulemaking proceeding and ``commends'' the Commission for initiating a 
proceeding ``to build a framework to make NG9-1-1 in our nation a 
reality.'' \121\ APCO indicates support of the Commission adopting 
NG911 rules, noting the Commission's proposals ``have the potential to 
accelerate the transition'' to NG911.\122\

[[Page 78075]]

Commenter iCERT notes its ``strong support for accelerating the 
implementation of NG911 across the country,'' urges the FCC ``to 
establish a clear regulatory framework,'' and urges the FCC ``to act 
promptly in this proceeding'' due to the ``urgent need to implement 
NG911 throughout the nation.'' \123\ Comtech expresses support for the 
Commission's proposed NG911 rules and notes ``the urgent need for swift 
adoption of these rules to help mitigate NG911 deployment delays.'' 
\124\ Other commenters note the benefits of transitioning to NG911 and 
support Commission action to facilitate that transition.\125\ Only one 
commenter appears to be opposed to the Commission adopting rules in 
some form to facilitate the transition to NG911.\126\
---------------------------------------------------------------------------

    \117\ See, e.g., Alaska Telecom Association (Alaska Telecom 
Assoc.) NG911 Notice Comments at 1 (rec. Aug. 9, 2023) (Alaska 
Telecom Assoc. NG911 Notice Comments) (``ATA supports the 
Commission's efforts to encourage the transition to NG911 technology 
but cautions that any requirements adopted by the FCC must afford 
adequate flexibility to reflect the complexities associated with IP 
delivery and the realistic capabilities of providers.''); NASNA 
NG911 Notice Comments at 8 (rec. Aug. 8,2023) (NASNA NG911 Notice 
Comments) (supporting various proposed rules from the NG911 Notice 
but suggesting revisions, e.g., ``[w]hile the commission's proposed 
rules facilitate the 911 authorities' transition to i3 SIP 
capabilities with all originating service providers, the rules 
should also support the interoperability needs of the call delivery 
process''); Association of Public-Safety Communications Officials-
International, Inc. (APCO) NG911 Notice Comments at 2 (rec. Aug. 9, 
2023) (APCO NG911 Notice Comments) (indicating support of Commission 
NG911 rulemaking but recommending modifications to proposals); 
Letter from Don Brittingham, Policy Committee Chair, iCERT, to 
Marlene H. Dortch, Secretary, FCC, PS Docket No. 21-479, Attach. at 
5 (filed Nov. 2, 2023) (iCERT Nov. 2, 2023 Ex Parte), (``While end-
state NG9-1-1 is the goal, FCC rules should recognize and 
accommodate various stages of NG9-1-1 implementation.'').
    \118\ Maine Public Utilities Commission (Maine PUC) NG911 Notice 
Comments at 1 (rec. Aug. 9, 2023) (Maine PUC NG911 Notice Comments); 
accord id. at 3.
    \119\ Letter from Gregory R. Kline, Deputy Director for 911, 
Pennsylvania Emergency Mgmt. Agency, to Marlene H. Dortch, 
Secretary, FCC, PS Docket No. 21-479, at 1, 4 (filed June 24, 2024) 
(encouraging the FCC to establish uniform timelines and requirements 
for all technologies to connect to the NG911 system utilizing the 
IP-based format and emphasizing that without uniform regulation, 
``achieving the NG911 end state will be hampered by the application 
of different standards among the various 911 stakeholders'').
    \120\ Communications Equality Advocates (CEA) NG911 Notice 
Comments at 5 (rec. Aug. 9, 2023) (CEA NG911 Notice Comments). 
Mission Critical Partners also ``applauds'' the Commission ``for 
taking this essential next step toward facilitating NG911 
nationwide'' and states that ``MCP encourages the Commission to move 
forward with this rulemaking forthwith.'' Mission Critical Partners, 
LLC (Mission Critical Partners) NG911 Notice Comments at 12 (rec. 
Aug. 9, 2023) (Mission Critical Partners NG911 Notice Comments).
    \121\ NENA NG911 Notice Comments at 16 (rec. Aug. 7, 2023) (NENA 
NG911 Notice Comments); accord id. at 1 (``applaud[ing] the 
Commission for initiating a rulemaking proceeding to expedite the 
NG9-1-1 transition'').
    \122\ APCO NG911 Notice Comments at 2; see id. at 1-2 
(discussing recommended changes to the Commission's proposals and 
arguing that implementation of NG911 ``will save lives'').
    \123\ iCERT Nov. 2, 2023 Ex Parte at 1-2; see also Letter from 
Don Brittingham, Policy Committee Chair, iCERT, to Marlene H. 
Dortch, Secretary, FCC, PS Docket No. 21-479, at 1 (filed Dec. 13, 
2023) (iCERT Dec. 13, 2023 Office of Commissioner Starks Ex Parte); 
Letter from Don Brittingham, Policy Committee Chair, iCERT, to 
Marlene H. Dortch, Secretary, FCC, PS Docket No. 21-479, at 1 (filed 
Dec. 13, 2023) (iCERT Dec. 13, 2023 Office of Commissioner Carr Ex 
Parte); Letter from Don Brittingham, Policy Committee Chair, iCERT, 
to Marlene H. Dortch, Secretary, FCC, PS Docket No. 21-479, at 1 
(filed Dec. 13, 2023) (iCERT Dec. 13, 2023 Office of Commissioner 
Gomez Ex Parte); iCERT NG911 Notice Comments at 1-2; iCERT NG911 
Notice Reply at 1-2.
    \124\ Comtech Nov. 6, 2023 Ex Parte at 1; see also Letter from 
Susan Ornstein, Senior Director, Legal & Regulatory Affairs, 
Comtech, to Marlene H. Dortch, Secretary, FCC, PS Docket No. 21-479, 
at 1 (filed Nov. 2, 2023); Letter from Susan Ornstein, Senior 
Director, Legal & Regulatory Affairs, Comtech, to Marlene H. Dortch, 
Secretary, FCC, PS Docket No. 21-479, at 1 (filed Nov. 8, 2023).
    \125\ See, e.g., Hamilton Relay, Inc. (Hamilton Relay) NG911 
Notice Comments at 1 (rec. Aug. 9, 2023) (Hamilton Relay NG911 
Notice Comments) (``Hamilton supports the Commission's efforts to 
expedite the NG911 transition and ensure that the nation's emergency 
call handling systems function effectively and with the most 
advanced capabilities available.''); CCA NG911 Notice Comments at 1 
(rec. Aug. 9, 2023) (CCA NG911 Notice Comments) (stating that CCA 
supports efforts to facilitate the nationwide transition to NG911 
and to make NG911 requirements consistent across the industry and 
noting that ``[u]ltimately, NG911 can lead to greater consistency 
and efficiency, lower costs, and better 911 capabilities and public 
safety outcomes''); CTIA NG911 Notice Reply at 1, 11 (rec. Sept. 10, 
2023) (CTIA NG911 Notice Reply) (``The FCC can help by establishing 
a national, uniform framework for the NG911 transition that provides 
certainty and flexibility to address complex technical and 
operational issues, including key terms, conditions, and processes, 
and by encouraging collaboration among stakeholders.''); Jack 
Varnado NG911 Notice Comments at 1-2 (rec. Aug. 9, 2023) (filed on 
behalf of Livingston Parish Sheriff's Office and Livingston Parish 
Communications District (Livingston Parish)) (Livingston Parish 
NG911 Notice Comments) (supporting the need for NG911 and certain 
Commission rules); PTI Pacifica Inc. dba IT&E (IT&E) NG911 Notice 
Comments at 1-3 (rec. Aug. 9, 2023) (IT&E NG911 Notice Comments) 
(saying ``fully supports'' the transition to NG911 and indicating 
support for the Commission's adoption of rules); Windstream 
Services, LLC (Windstream) NG911 Notice Reply at 1-4 (rec. Sept. 8, 
2023) (Windstream NG911 Notice Reply) (saying ``fully supports the 
transition'' to NG911 but urging changes to the Commission's 
proposed approaches); AT&T NG911 Notice Comments at 2-3, 12 
(indicating support for the Commission to adopt rules and saying the 
NG911 Notice's policy goals for NG911 deployment are ``highly 
laudable,'' but urging modifications to the proposed rules); South 
Carolina Telephone Coalition (South Carolina RLECs) NG911 Notice 
Comments at 1-4, 16 (rec. Aug. 9, 2023) (South Carolina RLECs NG911 
Notice Comments) (supporting ``an orderly and rapid transition to 
NG911 and commend[ing] the Commission for its leadership,'' but 
advocating for modifications to the proposed rules). See also Letter 
from National Association of Counties (NACo), National Association 
of Regulatory Utility Commissioners (NARUC), National Association of 
State Utility Consumer Advocates (NASUCA), NASNA, National States 
Geographic Information Council (NSGIC), NENA, Urban and Regional 
Information Systems Association (URISA), iCERT, World Institute on 
Disability (WID), to Charles E. Schumer, Senator, Senate Democratic 
Leader, United States Senate, et al., at 2 (Jan. 23, 2024), https://cdn.ymaws.com/www.nena.org/resource/resmgr/govaffairs/Joint_Letter_Congress_1_23_2.pdf (stating that ``full, nationwide 
implementation of NG911'' remains an important national priority 
that is ``critical to the safety and security of our nation'').
    \126\ Letter from Steve Samara, President, Pennsylvania 
Telephone Association, and Norman J. Kennard, Counsel on behalf of 
the Pennsylvania Telephone Association, to Marlene H. Dortch, 
Secretary, FCC, PS Docket No. 21-479, at 8-9 (Pennsylvania Telephone 
Association July 2, 2024 Ex Parte).
---------------------------------------------------------------------------

    Therefore, based on the foregoing and the record as a whole, we 
conclude that there is a need for the Commission to establish rules to 
facilitate the NG911 transition. We believe the rules provide a 
regulatory framework that will assist in expediting the critical 
transition to NG911 nationwide, which will serve to greatly promote 
public safety in the years to come.

B. Definitions of Key Terms

    In this section, we discuss and adopt definitions for certain key 
terms, such as ``Next Generation 911 (NG911),'' ``commonly accepted 
standards,'' ``Emergency Services internet Protocol Network (ESInet),'' 
and other terms. The definitions we adopt for additional key terms, 
such as ``911 Traffic,'' ``NG911 Delivery Point,'' ``Session Initiation 
Protocol (SIP),'' ``Functional Element,'' ``Location Validation 
Function (LVF),'' and ``Location Information Server (LIS)'' are 
discussed in subsequent sections of this document and the Order.
    Next Generation 911 (NG911). In the NG911 Notice, the Commission 
sought comment on defining the term ``Next Generation 911.'' \127\ As 
reflected in relevant proposed legislation and the comments of parties 
in the NG911 and LBR proceedings, stakeholders have varying views on 
how, or even whether, to define Next Generation 911 in the Commission's 
rules. In the NG911 Notice, the Commission noted that there are 
multiple definitions of ``NG911'' in proposed federal legislation and a 
definition of ``Next Generation 9-1-1 services'' in federal law.\128\ 
The Spectrum Auction Reauthorization Act of 2023 (H.R. 3565), a bill 
introduced in May 2023, proposed the following definition of ``Next 
Generation 9-1-1'':
---------------------------------------------------------------------------

    \127\ See, e.g., NG911 Notice, 38 FCC Rcd at 6229-30, para. 51.
    \128\ NG911 Notice, 38 FCC Rcd at 6229-30, para. 51.

    [A]n internet Protocol-based system that--(A) ensures 
interoperability; (B) is secure; (C) employs commonly accepted 
standards; (D) enables emergency communications centers to receive, 
process, and analyze all types of 9-1-1 requests for emergency 
assistance; (E) acquires and integrates additional information 
useful to handling 9-1-1 requests for emergency assistance; and (F) 
supports sharing information related to 9-1-1 requests for emergency 
assistance among emergency communications centers and emergency 
response providers.\129\
---------------------------------------------------------------------------

    \129\ Spectrum Auction Reauthorization Act of 2023, H.R. 3565, 
118th Cong. sec. 159(d)(12) (2023); Press Release, U.S. House of 
Representatives Energy and Commerce Committee, Chair Rodgers 
Announces Full Committee Markup of 19 Bills (May 22, 2023), https://energycommerce.house.gov/posts/chair-rodgers-announces-full-committee-markup-of-19-bills (linking to text of H.R. 3565).

    Several other pieces of recent proposed federal legislation have 
used the same or a very similar definition of NG911.\130\
---------------------------------------------------------------------------

    \130\ The same definition of NG911 used in H.R. 3565 was also 
used in a March 2023 House bill, H.R. 1784 (the Next Generation 9-1-
1 Act of 2023), and in a 2022 House bill, H.R. 7624 (the Spectrum 
Innovation Act of 2022). See H.R. 1784, 118th Cong. sec. 159(d)(12) 
(2023), https://www.congress.gov/bill/118th-congress/house-bill/1784/text; H.R. 7624, 117th Cong. sec. 159(d)(11) (2022), https://www.congress.gov/bill/117th-congress/house-bill/7624/text. In 
addition, a bill introduced in the Senate in July 2023, S. 2712, 
proposes a similar definition of NG911: ``NEXT GENERATION 9-1-1.--
The term `Next Generation 9-1-1' means an interoperable, secure, 
internet Protocol-based system that--(A) employs commonly accepted 
standards; (B) enables emergency communications centers to receive, 
process, and analyze all types of 9-1-1 requests for emergency 
assistance; (C) acquires and integrates additional information 
useful to handling 9-1-1 requests for emergency assistance; and (D) 
supports sharing information related to 9-1-1 requests for emergency 
assistance among emergency communications centers and emergency 
response providers.'' S. 2712, 118th Cong. sec. 4(9) (2023), https://www.congress.gov/bill/118th-congress/senate-bill/2712/text?s=1&r=72. Congress used a somewhat different definition of 
NG911 in the Next Generation 9-1-1 Advancement Act of 2012, for 
purposes of administration of Federal 911 implementation grants. 
That earlier statute provides that ``Next Generation 9-1-1 
services'' means ``an IP-based system comprised of hardware, 
software, data, and operational policies and procedures that--(A) 
provides standardized interfaces from emergency call and message 
services to support emergency communications; (B) processes all 
types of emergency calls, including voice, data, and multimedia 
information; (C) acquires and integrates additional emergency call 
data useful to call routing and handling; (D) delivers the emergency 
calls, messages, and data to the appropriate public safety answering 
point and other appropriate emergency entities; (E) supports data or 
video communications needs for coordinated incident response and 
management; and (F) provides broadband service to public safety 
answering points or other first responder entities.'' 47 U.S.C. 
942(e)(5).

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

[[Page 78076]]

    Some commenters on the LBR Notice argued that the Commission should 
adopt a definition of NG911.\131\ For example, APCO urged the 
Commission to adopt the definition of NG911 ``as defined by the public 
safety community with support from a variety of stakeholders'' that 
appeared in legislation passed by the House of Representatives in 2022 
but that was not enacted into law.\132\ By contrast, NENA urged the 
Commission to ``be cautious in adopting formal definitions [of terms 
such as NG911] . . . without full industry-wide support and without 
considering all potential consequences of such definitions.'' \133\ 
NENA also asked the Commission to consider using the term ``i3 
compatible'' or some other mutually agreed upon terminology rather than 
``IP-enabled'' to describe standards-based NG911.\134\
---------------------------------------------------------------------------

    \131\ NG911 Notice, 68 FCC Rcd at 6229-30, para. 51.
    \132\ APCO LBR Notice Comments, at 5 (rec. Feb. 16, 2023). In 
its LBR comments, APCO urged the Commission to define NG911 as ``an 
IP-based system that: (A) ensures interoperability; (B) is secure; 
(C) employs commonly accepted standards; (D) enables emergency 
communications centers to receive, process, and analyze all types of 
9-1-1 requests for emergency assistance; (E) acquires and integrates 
additional information useful to handling 9-1-1 requests for 
emergency assistance; and (F) supports sharing information related 
to 9-1-1 requests for emergency assistance among emergency 
communications centers and emergency response providers.'' Id. 
(citing Spectrum Innovation Act of 2022, H.R. 7624, 117th Cong. sec. 
301 (2022)). As noted, this is the same NG911 definition included in 
the Spectrum Auction Reauthorization Act of 2023 (H.R. 3565) and the 
Next Generation 9-1-1 Act of 2023 (H.R. 1784).
    \133\ NENA LBR Notice Reply at 7-8 (rec. Mar. 20, 2023) (NENA 
LBR Notice Reply) (noting that such definitions may have 
``substantial impacts'' on state statutes, Federal and state 
regulatory bodies, future grant programs, and future case law).
    \134\ NENA LBR Notice Comments at 11 (rec. Feb. 15, 2023) (NENA 
LBR Notice Comments).
---------------------------------------------------------------------------

    In the NG911 Notice, the Commission sought comment on whether it 
should adopt one of these definitions or incorporate elements of these 
or other definitions of NG911 into our rules.\135\ The Commission asked 
whether a definition of NG911 is necessary for compliance with its 
proposed NG911 rules and, if so, sought input on crafting a definition 
that would be technologically neutral.\136\ The Commission noted that 
recent proposed legislative definitions include qualitative descriptors 
of NG911 systems, such as security, interoperability, and use of 
commonly accepted standards, as well as specific technical 
capabilities.\137\ The Commission asked if it should include any or all 
of these elements in a definition of NG911 adopted by the Commission, 
and whether the definitions discussed encompass current NG911 networks 
and technologies as well as possible future NG911 technologies.\138\
---------------------------------------------------------------------------

    \135\ NG911 Notice, 38 FCC Rcd at 6229-30, para. 51.
    \136\ Id.
    \137\ Id.
    \138\ Id.
---------------------------------------------------------------------------

    In comments on the NG911 Notice, APCO contends that a definition of 
NG911 is necessary. APCO again urges the Commission to adopt the same 
definition of NG911 proposed in the Spectrum Auction Reauthorization 
Act of 2023 (H.R. 3565), calling this a ``comprehensive definition . . 
. crafted by the public safety community,'' and stating that adopting 
this definition is important for aligning the rules with public 
safety's needs and the Commission's objectives.\139\ Similarly, NASNA 
indicates a definition of NG911 is needed and advocates adopting the 
NG911 definition used in H.R. 3565.\140\ Mission Critical Partners also 
believes that a definition of NG911 is needed, stating that, to speed 
up the process of migrating to NG911, ``it would be best to have the 
Commission define, for purposes of the rulemaking, what NG911 means.'' 
However, Mission Critical Partners states that ``NG911 has been defined 
differently by many groups,'' and advocates for a different and more 
detailed definition of NG911 than that recommended by APCO and 
NASNA.\141\ NENA notes that a definition of NG911 and other terms ``can 
provide stakeholders with clarity'' as the transition to NG911 
progresses, and recommends that an NG911 definition be standards based. 
Nevertheless, NENA again cautions the Commission only to adopt formal 
definitions for terms with public and private 911 industry-wide 
support.\142\
---------------------------------------------------------------------------

    \139\ APCO NG911 Notice Comments at 3; see also APCO NG911 
Notice Reply at 2-3 (rec. Sept. 8, 2023) (APCO NG911 Notice Reply) 
(noting that commenters offer a variety of opinions on how to define 
NG911, which ``underscores the need for the Commission to provide a 
common understanding of the public safety community's goals and 
expectations for NG9-1-1''; stating that providing a comprehensive 
NG911 definition is necessary to achieve the Commission's objectives 
and that adopting ``the public safety community's comprehensive 
definition'' of NG911 will provide ``a north star''). APCO also 
advocates that adopting this specific NG911 definition ``is a basic 
step to ensure that, should Congress pass NG9-1-1 funding 
legislation, the Commission's rules facilitating NG9-1-1 will align 
with the $15 billion grant program for communities across the 
country to deploy NG9-1-1.'' APCO NG911 Notice Comments at 3. We 
note, however, that should Congress pass NG911 funding legislation 
in the future, Congress will not necessarily use this particular 
definition of NG911 and may instead adopt a different definition.
    \140\ NASNA NG911 Notice Comments at 4-5 (NASNA believes the 
Commission's proposed rule should reflect the following NG911 
definition: ``A tiered system consisting of multiple IP-based 
networks that: (A) ensures interoperability; (B) is secure; (C) 
employs commonly accepted standards; (D) enables emergency 
communications centers and Public Safety Answering Points to 
receive, process, and analyze all types of 911 requests for 
emergency assistance; (E) acquires and integrates additional 
information useful to handling 911 requests for emergency 
assistance; and (F) supports sharing information related to 911 
requests for emergency assistance among emergency communications 
centers and emergency response providers.''). NASNA explains that it 
believes the standards suggested by APCO and the standards suggested 
by NENA ``both have applicability as it relates to the proposed 
rules,'' but ``we believe it is important to acknowledge that an 
end-to-end NG911 `system' consists of multiple networks and systems 
which are subject to different, but complementary interoperable 
standards.'' NASNA further explains that, ``[w]ith this perspective, 
NASNA offers a revision to the Next Generation 911 definition as it 
relates to the rules of this NPRM which recognizes the various 
networks at work.'' NASNA NG911 Notice Comments at 4-5.
    \141\ Mission Critical Partners suggests, ``[f]or example,'' the 
following definition: ``Next Generation 911, commonly referred to as 
NG911, is a system of interconnected systems that delivers and 
processes calls for help from the public and delivers the media to 
the appropriate [Emergency Communications Center]/PSAP. NG911 must 
include at a minimum: An IP-based transport ability that 
interconnects the system components, ECCs/PSAPs, and disparate NG911 
systems. This should be a robust, properly sized, resilient 
network.[;] Ability to receive SIP sessions to include all types of 
media (voice, video, picture, Real-Time Text [RTT], etc.). While the 
Commission could limit this requirement to specific types of media, 
that would require future rule changes.[;] Ability to receive and 
process call-routing and location data from the geolocation SIP 
header.[;] Ability to process routing and location data by value and 
by reference.[;] Ability to have authoritative geographic 
information system (GIS) information, including address points, 
street centerlines, and boundary polygons, needed to process calls 
and sessions.[;] Ability to deliver calls and sessions to ECCs/
PSAPs.[;] Ability to bridge additional users into calls in progress, 
e.g., language services, other ECCs/PSAPs.[;] Ability to apply rules 
to the routing of calls and sessions using all available data 
provided in the SIP messaging, including routing and location data 
that is dereferenced.[;] Ability to provide cybersecurity functions 
at the edges of all interconnected networks and throughout the inner 
workings of each NGCS.[;] Ability to transfer calls and sessions 
between ECCs/PSAPs on the network and to other NG911 systems without 
the loss of location data.[;] Ability to log, and report on, call 
data and associated network, service, and system activity.'' Id. at 
10-11.
    \142\ NENA NG911 Notice Comments at 13-14. NENA sets forth its 
own definition of NG911, but acknowledges that a variety of other 
definitions have been proposed and that the NENA definition ``is not 
sufficient for the specific scope of the Commission's proceeding 
without modification,'' including adding reference ``an i3-centric 
architecture.'' Id.
---------------------------------------------------------------------------

    Commenters also express differing views on whether a codified 
definition of NG911 should reference the NENA i3 standard or any 
specific technical standard. To ensure compatibility and

[[Page 78077]]

interoperability of NG911 systems, NENA argues that any definition of 
NG911 should reference ``an i3-centric architecture.'' \143\ Colorado 
PUC agrees that the Commission should consider including language 
regarding ``i3 standard compatibility'' in the NG911 definition, 
stating that ``[t]he vast majority, if not all'' implementations of 
NG911 technology across the country have the goal of deploying i3-based 
NG911 systems.\144\ In contrast, APCO opposes incorporating i3 or any 
other specific NG911 standard into the Commission's rules, noting that 
there are alternative potential standards, that the telecommunications 
ecosystem and technology continue to evolve, and that Emergency 
Communications Centers (ECCs) should have flexibility to pursue their 
preferred approaches with a ``technology-neutral approach'' that 
ensures ``ECCs can continually benefit from ongoing innovation.'' \145\ 
APCO urges that the Commission must avoid rules or assumptions that 
might ``lock ECCs into a particular approach to implementing NG9-1-1'' 
and should not adopt rules ``that bake in specific architectures for 
NG9-1-1.'' APCO states that this is why the public safety community's 
``comprehensive definition of NG9-1-1 [i.e., the definition in H.R. 
3565, H.R. 1784, and H.R. 7624] references the use of `commonly 
accepted standards' rather than identify[ing] a particular standard for 
NG9-1-1.'' \146\ Mission Critical Partners also advocates for a 
``technology-neutral definition'' of NG911 ``to reduce any ambiguity by 
providers or 911 authorities regarding compliance with the proposed 
NG911 rulemaking.'' \147\
---------------------------------------------------------------------------

    \143\ Id. See also NENA, NENA Releases New Version of the i3 
Standard for Next Generation 9-1-1 (July 12, 2021), https://www.nena.org/news/572966/NENA-Releases-New-Version-of-the-i3-Standard-for-Next-Generation-9-1-1.htm.
    \144\ Colorado Public Utilities Commission (Colorado PUC) NG911 
Notice Comments at 10 (rec. Aug. 9, 2023) (Colorado PUC NG911 Notice 
Comments).
    \145\ Letter from Jeffrey S. Cohen, Chief Counsel, Mark S. 
Reddish, Senior Counsel, and Alison P. Venable, Government Relations 
Counsel, APCO International, to Marlene H. Dortch, Secretary, FCC, 
PS Docket No. 21-479, at 2 (filed Oct. 31, 2023) (APCO Oct. 31, 2023 
Ex Parte); APCO NG911 Notice Reply at 2 & n.5; APCO NG911 Notice 
Comments at 1-2.
    \146\ APCO NG911 Notice Reply at 2; see also APCO Oct. 31, 2023 
Ex Parte at 2 (noting ``the public safety community's legislative 
efforts to require the use of `commonly accepted standards' rather 
than a particular method for achieving the capabilities envisioned'' 
for NG911); APCO NG911 Notice Comments at 1-3 (``The public safety 
community has coalesced around a comprehensive vision for NG9-1-1 
based on a technology-neutral approach that fosters a competitive 
marketplace and is pursuing significant federal funding legislation 
that has received broad bipartisan support on Capitol Hill.'').
    \147\ Mission Critical Partners NG911 Notice Coments at 10; 
accord Intrado Mar. 26 Ex Parte at 4-5 (Intrado ``typically 
respond[s] to RFPs by proposing the use of a `mutually agreed 
industry standard,' with the intention to base the deployment on a 
foundation of i3 methodology tailored to the circumstances.'').
---------------------------------------------------------------------------

    We find that adopting a definition of NG911 will facilitate 
compliance with the NG911 rules, as it will help promote clarity and 
certainty about the Commission's NG911 requirements. Accordingly, we 
adopt the definition of NG911 used in the Spectrum Auction 
Reauthorization Act of 2023 (H.R. 3565), a definition that is supported 
by multiple stakeholders in the public safety community and that has 
been used in several recent pieces of proposed Federal legislation. 
Although not all commenters to this proceeding support this specific 
definition, we believe that it comes closest to reflecting a broad 
consensus as to the essential elements that should be included in a 
definition of NG911. In particular, the definition will advance our 
goal of a technology-neutral approach to implementation of NG911, and 
it contains the important requirements that an NG911 system ensure 
interoperability, be secure, and employ commonly accepted standards.
    We decline to reference any specific standard or set of standards 
as part of the codified definition of NG911. Although NENA and Colorado 
PUC advocate for including a reference to the i3 standard in the rules, 
we conclude that the better approach is to adopt a technology-neutral 
definition that avoids referencing any specific standard. As discussed 
below, we believe commenters' concerns that NG911 development be 
standards-based are fully addressed by including ``commonly accepted 
standards'' as an element of our NG911 definition.\148\
---------------------------------------------------------------------------

    \148\ We agree with commenters that the i3 standard meets the 
definition of a ``commonly accepted standard'' under the definition 
in this document and the Order.
---------------------------------------------------------------------------

    We have also considered, but decline to adopt, the more detailed 
NG911 definition suggested by Mission Critical Partners. Mission 
Critical Partners' proposed NG911 definition identifies many specific 
operational and technical functions, such as the ability to ``bridge 
additional users into calls in progress;'' ``provide cybersecurity 
functions at the edges of all interconnected networks and throughout 
the inner workings of each NGCS,'' ``transfer calls and sessions 
between ECCs/PSAPs on the network and to other NG911 systems without 
the loss of location data,'' and ``log, and report on, call data and 
associated network, service, and system activity.'' While we anticipate 
that many NG911 networks will support these capabilities, incorporating 
this level of detail into the codified definition of NG911 appears 
unnecessary and could cause confusion to the extent that it goes beyond 
the level of detail in the draft legislative definition supported by 
most commenters.\149\
---------------------------------------------------------------------------

    \149\ We note, however, that some of the elements of Mission 
Critical Partners' proposed ``NG911'' definition are already 
included in the ``NG911'' definition. For example, Mission Critical 
Partners' element of ``[a]n IP-based transport ability that 
interconnects the system components, ECCs/PSAPs, and disparate NG911 
systems'' appears to match our final definition's requirement of 
``ensures interoperability,'' and its required element of 
``[a]bility to provide cybersecurity functions at the edges of all 
interconnected networks and throughout the inner workings of each 
NGCS'' appears to match our final definition's requirement of ``is 
secure.'' Mission Critical Partners NG911 Notice Comments at 10-11.
---------------------------------------------------------------------------

    The definition of NG911 addresses other concerns raised by 
commenters on the NG911 Notice. In the NG911 Notice, the Commission 
sought comment on how to ensure that its proposed rules would support 
interoperability in the NG911 environment.\150\ Commenters confirm the 
importance of interoperability in NG911 to enable the efficient 
transfer of emergency calls, texts, and data between ESInets, PSAPs, 
and first responders.\151\ In addition, commenters note that the 
uniform use of commonly accepted standards by OSPs and NG911 vendors is 
a necessary prerequisite to interoperability,\152\ although it is not 
enough by itself to achieve interoperability.\153\ Consistent with 
commenters' views, the definition of NG911 in this document and the

[[Page 78078]]

Order therefore specifies that NG911 systems shall ``ensure 
interoperability.'' \154\
---------------------------------------------------------------------------

    \150\ NG911 Notice, 38 FCC Rcd at 6216, para. 24.
    \151\ See, e.g., H.R. 3565, sec. 301 (defining interoperability 
as ``the capability of emergency communications centers to receive 
9-1-1 requests for emergency assistance and information and data 
related to such requests, such as location information and callback 
numbers from a person initiating the request, then process and share 
the 9-1-1 requests for emergency assistance and information and data 
related to such requests with other emergency communications centers 
and emergency response providers without the need for proprietary 
interfaces and regardless of jurisdiction, equipment, device, 
software, service provider, or other relevant factors'').
    \152\ Colorado PUC NG911 Notice Comments at 10; NENA NG911 
Notice Comments at 5 (stating that the Commission can address 
interoperability concerns through the adoption of i3 compatible 
standards in its rules); MSCI LBR Notice Reply at 2 (rec. Mar. 20, 
2023) (MSCI LBR Notice Reply) (supporting requiring delivery of 911 
calls using the NENA i3 format to ``advance the NG911 transition, 
standardize location information delivery, and promote 
interoperability'').
    \153\ NENA Oct. 24, 2023 Ex Parte at 1; see also APCO NG911 
Notice Reply at 3 (``The Commission should reject assertions that 
interoperability will be achieved as a result of requiring delivery 
of 9-1-1 traffic in an IP-based format or by requiring use of the i3 
standard.'').
    \154\ Livingston Parish NG911 Notice Comments at 1; APCO Sept. 
22, 2023 Ex Parte; iCERT Nov. 2, 2023 Ex Parte at 4; Letter from 
Jeffrey S. Cohen, Chief Counsel, et al., APCO, to Marlene H. Dortch, 
Secretary, FCC, PS Docket No. 21-479, at 2-3 (filed May 20, 2024).
---------------------------------------------------------------------------

    Google and EPIC urge the importance of security, with Google 
stating that ``security has to be built into NG911 and should be part 
of the Commission's definition of NG911.'' \155\ The definition of 
NG911 adopted here specifically includes that the system ``is secure.'' 
\156\ CEA urges the Commission to adopt an NG911 definition ``that 
includes accessibility as an essential characteristic,'' and notes 
favorably that the NG911 definition in the Spectrum Auction 
Reauthorization Act of 2023 (H.R. 3565) requires that NG911 ``be 
capable of processing `all types' of requests.'' CEA states that ``[w]e 
read this requirement as mandating that NG911 standards support 
accessible technologies.'' We agree with CEA's reading and find that 
adopting the same language used in H.R. 3565 is sufficient to 
incorporate the accessibility component into the NG911 definition.
---------------------------------------------------------------------------

    \155\ Google NG911 Notice Comments at 8 (rec. Aug. 9, 2023) 
(Google NG911 Notice Comments); Electronic Privacy Information 
Center (EPIC) NG911 Notice Comments at 3, 5 (rec. Aug. 9,2023) (EPIC 
NG911 Notice Comments) (agreeing that a definition of NG911 should 
include ``an emphasis on security''; also stating, as a broader 
observation, that the Commission must address privacy issues for 
NG911 data, not merely cybersecurity).
    \156\ See also Google NG911 Notice Comments at 8 (acknowledging 
that, ``[i]ndeed, the Spectrum Auction Reauthorization Act of 2023 
(H.R. 3565) introduced in May 2023 includes a definition of `Next 
Generation 9-1-1' as an IP-based system that `is secure' '').
---------------------------------------------------------------------------

    Commonly Accepted Standards. The NG911 definition specifies that 
NG911 systems and technology must be based on ``commonly accepted 
standards.'' In the NG911 Notice, we discussed the concept of commonly 
accepted standards but did not propose a specific definition of that 
term.\157\
---------------------------------------------------------------------------

    \157\ NG911 Notice, 38 FCC Rcd at 6216, 6229-30, paras. 24, 51. 
In addition, several potential definitions of NG911 that were 
proposed by commenters or discussed in the NG911 Notice included the 
term ``commonly accepted standards.'' See, e.g., NG911 Notice, 38 
FCC Rcd 6229-30, para. 51 & n.166; NASNA NG911 Notice Comments at 4-
5.
---------------------------------------------------------------------------

    Commenters generally support including a definition of ``commonly 
accepted standards'' in the rules. The proposed legislation in H.R. 
3565 provides a definition of ``commonly accepted standards.'' \158\ 
NENA offers a similar definition that ``very closely aligns with the 
definitions as promulgated in multiple NG9-1-1 funding bills as 
introduced in Congress.'' \159\ We find that requiring that the 
commonly accepted standards be developed and approved by an accredited 
standards development organization will help ensure that there is a 
minimum threshold for ensuring the integrity and validity of such 
standards, as technology continues to evolve over time. Accordingly, we 
adopt the following definition of ``commonly accepted standards'':
---------------------------------------------------------------------------

    \158\ H.R. 3565 states: ``The term `commonly accepted standards' 
means the technical standards followed by the communications 
industry for network, device, and internet Protocol connectivity 
that--(A) enable interoperability; and (B) are--(i) developed and 
approved by a standards development organization that is accredited 
by an American standards body (such as the American National 
Standards Institute) or an equivalent international standards body 
in a process--(I) that is open to the public, including open for 
participation by any person; and (II) provides for a conflict 
resolution process; (ii) subject to an open comment and input 
process before being finalized by the standards development 
organization; (iii) consensus-based; and (iv) made publicly 
available once approved.''
    \159\ NENA NG911 Notice Reply at 12-13 & nn.39-40 (rec. Sept. 6, 
2023). NENA's proposed definition requires that the technical 
standards be ``developed and approved by a recognized standards 
development organization, that may be accredited by a United States 
or international standards accreditation body.''

    The technical standards followed by the communications industry 
for network, device, and internet Protocol connectivity that--(1) 
enable interoperability; and (2) are--(i) developed and approved by 
a standards development organization that is accredited by a United 
States standards body (such as the American National Standards 
Institute) or an equivalent international standards body in a 
process that--(A) is open to the public, including open for 
participation by any person; and (B) provides for a conflict 
resolution process; (ii) subject to an open comment and input 
process before being finalized by the standards development 
organization; (iii) consensus-based; and (iv) made publicly 
---------------------------------------------------------------------------
available once approved.

    This definition tracks the definition of ``commonly accepted 
standards'' set forth in H.R. 3565, with minor non-substantive 
revisions.\160\
---------------------------------------------------------------------------

    \160\ The definition we adopt refers to accreditation by a 
``United States standards body'' rather than an ``American standards 
body.'' In addition, we have moved the word ``that'' to precede the 
(2)(i)(A) provision, so that it modifies both subsections that 
follow. Finally, we have made non-substantive changes to the 
introductory wording and numbering of the definition for consistency 
with adjacent rule provisions.
---------------------------------------------------------------------------

    As noted above, this definition of ``commonly accepted standards'' 
does not specify a particular standard or set of standards to which 911 
Authorities or networks must adhere. This approach gives parties 
flexibility to implement changes or improvements as more advanced 
technologies become available and allows industry standards to evolve 
without the need for rule changes. Equally important, our approach 
discourages the use of ``proprietary . . . standards,'' \161\ which do 
not meet the definition of ``commonly accepted standards'' as they (1) 
would not enable interoperability; and (2) would not be developed and 
approved by a standards development organization accredited by a United 
States standards body or equivalent international standards body, 
subject to an open, consensus-based comment and input process prior to 
finalization, or made publicly available once approved.
---------------------------------------------------------------------------

    \161\ USTelecom-The Broadband Association (USTelecom) NG911 
Notice Comments at 5 (rec. Aug. 9, 2023) (USTelecom NG911 Notice 
Comments) (discussing that proprietary standards ``may vary vendor-
by-vendor.'').
---------------------------------------------------------------------------

    We also emphasize that the NENA i3 standard qualifies as a 
``commonly accepted standard'' under the definition in this document 
and the Order. \162\ As numerous commenters indicate, the i3 standard 
is the prevailing standard adopted by all NG911 systems currently being 
deployed in the U.S. (and in Canada and Europe) is the NENA i3 
standard.\163\ The i3 standard has been approved by the American 
National Standards Institute (ANSI),\164\ following an open comment and 
input process, and was made publicly available once approved.\165\ In 
addition, work is ongoing to improve and augment the i3 standard as the 
NG911 transition proceeds.\166\ While we do not specifically reference 
the i3 standard in our rules, as some commenters advocate,\167\ we 
regard the widespread

[[Page 78079]]

adoption of i3 as a positive trend that will help ensure that the 
development of NG911 is in accordance with ``commonly accepted 
standards'' as defined in our rules. At the same time, our rules 
provide flexibility that will ``help promote a technology-neutral 
approach that ensures that ECCs can continually benefit from ongoing 
innovation.''
---------------------------------------------------------------------------

    \162\ See, e.g., Brian Rosen NG911 Notice Comments at 1 (rec. 
July 28, 2023) (Brian Rosen NG911 Notice Comments); iCERT Nov. 2, 
2023 Ex Parte at 4; MSCI NG911 Notice Comments at 3; Comtech NG9111 
Notice Comments at 7; Texas 9-1-1 Alliance, Texas Commission on 
State Emergency Communications, and Municipal Emergency 
Communication Districts Association (Texas 9-1-1 Entities) NG911 
Notice Comments at 2 (rec. Aug. 8, 2023) (Texas 9-1-1 Entities NG911 
Notice Comments).
    \163\ NENA Oct. 26, 2023 Ex Parte at 1 (``[A]ll known NG9-1-1 
deployments today adopt the i3 standard, including across Canada, 
all deployments in the United States, and the regional version 
adopted in Europe.''); iCERT Nov. 2, 2023 Ex Parte, Attach. at 4 
(``All current NG9-1-1 implementations are based on NENA i3.''); 
Brian Rosen NG911 Notice Reply at 1 (rec. Sept. 8, 2023) (Brian 
Rosen NG911 Notice Reply) (``[T]here is a single accepted industry 
standard, and that is the i3 standard.'').
    \164\ NENA, NENA Standards and Documents, https://www.nena.org/page/standards (last visited Apr. 11, 2024) (noting that NENA's i3 
is an ANSI-approved standard).
    \165\ Id.
    \166\ Id. (listing published corrections to the NENA i3 
standard).
    \167\ NENA LBR Notice Comments at 11 (supporting ``i3 
compatible'' or some other mutually-agreed upon terminology to 
describe standards-based NG911); iCERT Nov. 2, 2023 Ex Parte, 
Attach. at 4 (promoting ``full interoperability and the use of 
commonly accepted standards, such as i3''); NASNA NG911 Notice Reply 
at 2 (rec. Sept. 8, 2023) (NASNA NG911 Notice Reply) (``recognizing 
the NENA i3 standard as the benchmark standard will improve 
competition in the marketplace, ensure a standards-based approach, 
provide a consistent benchmark for a phased path forward for NG911, 
align the US with other global access to emergency calling, and 
improve the deployment timeline''); USTelecom NG911 Notice Reply at 
5-6 (rec. Sept. 8, 2023) (USTelecom NG911 Notice Reply); Colorado 
PUC NG911 Notice Comments at 9; Verizon NG911 Notice Comments at 5 
(rec. Aug. 9, 2023); Ad Hoc NG911 Service Providers Coalition NG911 
Notice Comments at 8 (rec. Aug. 9, 2023) (Ad Hoc NG911 Service 
Providers Coalition NG911 Notice Comments); Brian Rosen NG911 Notice 
Comments at 2; Comtech NG911 Notice Comments at 7; Boulder Regional 
Emergency Telephone Service Authority (BRETSA) NG911 Notice Reply at 
6 (rec. Sept. 8, 2023) (BRETSA NG911 Notice Reply) (stating that the 
``Commission should open a rulemaking docket to adopt the i3 
standard for NG911, along with any corollary standards'').
---------------------------------------------------------------------------

    911 Authority. In the NG911 Notice, the Commission proposed to 
define ``911 Authority'' as ``[t]he state, territorial, regional, 
Tribal, or local agency or entity with the authority and responsibility 
under applicable law to designate the point(s) to receive emergency 
calls.'' \168\ The Commission asked if this definition encompassed the 
diverse set of authorities in the United States that have authority and 
responsibility to designate the point(s) to receive emergency 
calls.\169\
---------------------------------------------------------------------------

    \168\ NG911 Notice, 38 FCC Rcd at 6230, 6244, para. 53, app. A 
(Sec.  9.28 ``Definitions'').
    \169\ NG911 Notice, 38 FCC Rcd at 6230, para. 53.
---------------------------------------------------------------------------

    The South Carolina Revenue and Fiscal Affairs Office (South 
Carolina RFA) agrees that the NG911 Notice's proposed definition 
``sufficiently encompasses the roles and responsibilities of the 911 
Authority for the State.'' Other commenters, however, propose to modify 
the definition. NASNA states that the definition should reference 911 
Authorities' broader responsibilities for coordinating the deployment 
of the ESInet and its data inputs and proposes to define ``911 
authority'' as ``[t]he state, territorial, regional, Tribal, or local 
agency or entity with the authority and responsibility under applicable 
law to procure and administer an ESInet and NG911 core services on 
behalf of one or more PSAPs and to designate the point(s) to receive 
emergency calls.'' Commenter Brian Rosen similarly states that the 
Commission should define ``911 Authority'' as ``the entity contracting 
for the ESInet and the NGCS service.'' \170\ Colorado PUC notes that 
there may be 911 Authorities with concurrent jurisdiction over the same 
geographic area but ``having different roles and responsibilities'' 
over the 911 system and suggests including language indicating this 
possibility.\171\ We agree with these commenters and include a 
reference in our definition of ``911 Authority'' to the operation or 
administration 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.'' This definition better captures the 
range of responsibilities that 911 Authorities have and is broad enough 
to accommodate the possibility of overlapping authorities--for example, 
a state's public safety agencies and its public utility commission--
over various aspects of the state's 911 network(s).
---------------------------------------------------------------------------

    \170\ Brian Rosen NG911 Notice Reply at 15 (also stating that 
``[a] PSAP should not be declaring they are ready, it is the 9-1-1 
Authority, often a state entity'').
    \171\ Colorado PUC NG911 Notice Comments at 10 (``For instance, 
a state may have a single state-level 911 authority, but each region 
may also have a local 911 authority, with the state and local 
authorities having different roles and responsibilities.'').
---------------------------------------------------------------------------

    We find that this modified definition of ``911 Authority'' will 
provide greater clarity and assist parties in complying with our rules. 
Accordingly, we adopt the following definition of ``911 Authority'':

    ``911 Authority'': 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.\172\
---------------------------------------------------------------------------

    \172\ The term ``NG911 Delivery Point'' is also defined in this 
rulemaking.

    Emergency Services internet Protocol Network (ESInet). In the NG911 
Notice, the Commission proposed to adopt a definition of ``Emergency 
Services internet Protocol Network (ESInet)'' that would define the 
term ``in reference to the protocol used on the network, the entities 
that manage the network, and the use of the network for purposes of 
emergency services communications.'' \173\ The Commission's proposed 
definition was ``[a]n internet Protocol (IP)-based network managed by 
public safety authorities and used for emergency services 
communications, including Next Generation 911.'' \174\
---------------------------------------------------------------------------

    \173\ NG911 Notice, 38 FCC Rcd at 6230, para. 52.
    \174\ NG911 Notice, 38 FCC Rcd at 6244, app. A (Sec.  9.28 
``Definitions''); see id. at 6230, para. 52 (proposing to define 
``Emergency Services internet Protocol Network (ESInet)'' as ``[a]n 
internet Protocol (IP)-based network used for emergency services 
communications, including Next Generation 911'').
---------------------------------------------------------------------------

    Mission Critical Partners generally supports this definition of 
ESInet but notes that the ESInet is ``simply a transport mechanism.'' 
\175\ NASNA proposes to define ESInet as: ``[t]he internet Protocol 
(IP)-based network tier of a Next Generation 911 system that exists 
between the points designated by the 911 authority and a PSAP, which is 
used for emergency services communications, including Next Generation 
911.'' NENA states that ``[w]ithin the confines of this proceeding,'' 
it concurs with NASNA's proposed definition for ESInet.\176\ Alaska 
Telecom notes that the Commission seeks comment on the definitions of 
both ``NG911'' and ``ESInet,'' and says that any definitions adopted 
should reference ``statewide, or at least regional, ESInet 
development,'' as doing so will ensure that deployment of NG911 
networks ``is coordinated with a statewide (or at a minimum, partially 
statewide) rollout,'' not conducted solely on a PSAP-by-PSAP, provider-
by-provider basis.\177\
---------------------------------------------------------------------------

    \175\ Mission Critical Partners NG911 Notice Comments at 11 
(stating that ``it is the core services that perform the critical 
functions that make NG911 work'').
    \176\ NENA NG911 Notice Reply at 11 (also noting that NENA has 
its own different ``official definition of an ESInet'' that it does 
not recommend adopting in this proceeding, but that NENA will 
continue to use that other definition in ``other forums''). See also 
Brian Rosen NG911 Notice Reply at 16-17 (discussing whether the 
ESInet should be the default demarcation point for cost allocation, 
and stating that ``[c]loud deployments of NGCS services complicate 
the definition of what is the ESInet'').
    \177\ Alaska Telecom Assoc. NG911 Notice Comments at 15-16 
(``Furthermore, deploying NG911 networks in coordination with an in-
state ESInet (or ESInets) in Alaska will help prevent scenarios in 
which a 911 authority contracts with an NG911 provider in the 
contiguous United States rather than Alaska, requiring service 
providers to somehow deliver traffic to a demarcation point far 
outside their service areas or in the Lower 48. Such a configuration 
would impose high costs on carriers serving remote areas and would 
jeopardize the redundancy and reliability of the 911 communications 
system in Alaska.'').
---------------------------------------------------------------------------

    We adopt a definition of ``ESInet'' similar to that proposed in the 
NG911 Notice, with slight revisions to add greater clarity and 
certainty to what constitutes an ESInet for purposes of these NG911 
rules. The modifications in this final definition are consistent with 
the criteria set forth by the Commission in the NG911 Notice, and also 
reflect wording that NASNA and NENA support and recommend in their 
proposed ``ESInet'' definition. The definition is as follows:

    Emergency Services internet Protocol Network (ESInet). An 
internet Protocol (IP)-

[[Page 78080]]

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.

    The adopted definition of ``ESInet'' reflects the three criteria 
that we proposed in the NG911 Notice for the definition of ``ESInet''--
the protocol used on the network, the entities that manage the network, 
and the use of the network for purposes of emergency services 
communications.\178\ In addition, while our proposed definition 
provided that the network must be managed by ``public safety 
authorities,'' the final definition adopted provides greater clarity by 
specifying that the network must be managed or operated by a ``911 
Authority or its agents or vendors,'' with ``911 Authority'' being a 
term specifically defined elsewhere in the rules.
---------------------------------------------------------------------------

    \178\ NG911 Notice, 38 FCC Rcd at 6230, para. 52.
---------------------------------------------------------------------------

    NASNA and NENA propose stating in the definition that the ESInet is 
the ``internet Protocol (IP)-based tier of a Next Generation 911 system 
that exists between the points designated by the 911 authority and a 
PSAP.'' While ESInets typically operate in the manner described by 
NASNA and NENA, we believe that ESInets should be defined functionally 
without reference to any particular ``tier'' or network configuration. 
Alaska Telecom recommends that the ``ESInet'' definition reference 
``statewide, or at least regional, ESInet development'' to ensure that 
NG911 networks are not deployed on a PSAP-by-PSAP, provider-by-provider 
basis. We find that it is not necessary to include specific wording on 
this issue. The ``ESInet'' definition is intended to be flexible and 
leaves the scale of ESInet deployment (e.g., local, state, or regional) 
to the discretion of stakeholders.
    Originating Service Providers. The NG911 Notice discussed wireline 
providers, rural wireline providers, and non-rural telecommunications 
wireline providers,\179\ but it did not propose specific definitions 
for ``Wireline Provider'' or ``Non-Rural Wireline Provider.'' 
Similarly, the NG911 Notice did not specifically propose to define the 
terms ``Nationwide CMRS Provider,'' ``Non-Nationwide CMRS Provider,'' 
and ``Rural Incumbent Local Exchange Carrier (RLEC).'' In addition, the 
Commission noted that it had previously defined the term ``Covered Text 
Provider'' at 47 CFR 9.10(q)(1),\180\ but did not specifically propose 
to adopt a definition of that term in this proceeding. However, in the 
NG911 Notice the Commission sought comment on whether there are ``any 
other terms that we should define for purposes of the cost allocation 
and IP-delivery rules.'' \181\ The terms ``Wireline Provider,'' ``Non-
Rural Wireline Provider,'' ``Covered Text Provider,'' ``Nationwide CMRS 
Provider,'' ``Non-Nationwide CMRS Provider,'' and ``Rural Incumbent 
Local Exchange Carrier (RLEC)'' are used in certain NG911 rules. We 
find that specifically defining these terms will ensure greater clarity 
and certainty, and will help parties to comply with our regulations. 
Accordingly, we incorporate and adopt the definitions for these terms 
that have previously been set forth in other existing statutes and 
regulations.
---------------------------------------------------------------------------

    \179\ NG911 Notice, 38 FCC Rcd at 6230-31, para. 55.
    \180\ Id. at 6205, para. 2 n.2.
    \181\ Id. at 6230, para. 54.
---------------------------------------------------------------------------

    The NG911 Notice and the LBR Notice did not specifically propose a 
defined term that would encompass all providers that would be 
specifically subject to NG911 rules. We define the term ``Originating 
Service Providers'' for purposes of this rulemaking and the new NG911 
rules as follows:

    Originating Service Providers. Providers 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.

    Other Definitions. Some commenters suggest that the Commission 
codify definitions of additional terms, such as ``Associated Location 
Information,'' \182\ ``IP-based format,'' \183\ and ``Phases of 
Readiness.'' \184\ We conclude that adopting formal definitions of 
these terms is unnecessary, but we note that some of the suggested 
additional terms are discussed and explained in other sections of this 
document and the Order.\185\ We believe that the formal definitions we 
adopt in this proceeding provide sufficient certainty, clarity, and 
guidance for stakeholders at this time.
---------------------------------------------------------------------------

    \182\ iCERT NG911 Notice Comments at 4 (urging that ``the 
Commission should clarify what it means to ``include associated 
location information'' with a 911 call'').
    \183\ T-Mobile USA, Inc. (T-Mobile) NG911 Notice Comments at 5 
(rec. Aug. 9, 2023) (T-Mobile NG911 Notice Comments); Texas 9-1-1 
Entities NG911 Notice Comments at 2; iCERT NG911 Notice Comments at 
4 (stating ``iCERT recommends that delivery of 911 calls in IP-based 
format require conformance to `commonly accepted standards for 
NG911''').
    \184\ NASNA NG911 Notice Comments at 6-7; T-Mobile NG911 Notice 
Reply at 9-10 (rec. Sept. 8, 2023) (T-Mobile NG911 Notice Reply); 
NENA NG911 Notice Reply at 2.
    \185\ For example, in this document and section III.C.1.a of the 
Order, we note that ``associated location information'' means ``the 
location information that OSPs are required to determine and 
transmit under current part 9 rules,'' and we clarify that ``nothing 
in our rules is intended to change location determination 
requirements for OSPs.'' In this document and in section 
III.C.1.b.ii of the Order, we discuss the term ``IP-based format,'' 
noting that using and defining the technical term ``SIP'' to 
describe IP delivery and 911 Authority readiness will provide 
clarity regarding the Commission's NG911 rules, as ``SIP'' is a 
technically more precise term than ``IP-based format'' and similar 
terms. In this document and in section III.C.2 of the Order, we 
discuss and adopt two phases of readiness ``to promote clarity and 
specificity regarding the readiness that 911 Authorities must 
achieve to prepare to accept Phase 1 and Phase 2 delivery by OSPs.''
---------------------------------------------------------------------------

C. Service Providers' Obligation To Deliver 911 Traffic in IP Format 
Upon Request

1. Two-Phased Implementation of IP-Based Transmission Formats
a. Overview
    For the transition to NG911, we adopt rules that require OSPs to 
take steps in two phases to complete all translation and routing to 
deliver 911 traffic, including associated routing and location 
information, in the requested IP-based format. These requirements are 
intended to correspond to and complement the readiness phases for 911 
Authorities, such that once a 911 Authority is ready to receive NG911 
traffic in a specific IP format, the OSP will be required to deliver it 
in that format.
    In the LBR Notice, the Commission proposed to require CMRS and 
covered text providers to deliver 911 calls, texts, and associated 
location information in IP-based format to NG911-capable PSAPs that 
request it.\186\ The Commission reasoned that such a requirement would 
advance the transition to NG911 by helping address operational and 
routing issues for jurisdictions that have implemented NG911.\187\ The 
Commission also noted that the 2016 TFOPA Report concluded that a 
significant impediment to NG911 service was that originating service 
providers were not prepared to deliver 911 calls via IP technology with 
location information to NG911 service providers.\188\ The Commission 
reasoned that requiring OSPs to deliver IP-formatted calls and routing 
information to NG911-capable PSAPs would alleviate the burden on state 
and local

[[Page 78081]]

911 Authorities of maintaining transitional gateways and other networks 
to process and convert legacy calls \189\ and would help jurisdictions 
realize additional public safety benefits available on NG911 
networks.\190\
---------------------------------------------------------------------------

    \186\ LBR Notice, 37 FCC Rcd at 15201, para. 46.
    \187\ Id.
    \188\ Id. (citing TFOPA Final Report at 37).
    \189\ Id. at 15202, para. 47.
    \190\ Id. at 15202, para. 48.
---------------------------------------------------------------------------

    In the NG911 Notice, the Commission proposed to require wireline, 
interconnected VoIP, and internet-based TRS providers to complete all 
translation necessary to deliver 911 calls, including associated 
location information, in the requested IP-based format to an ESInet or 
other designated point(s) that allow emergency calls to be answered 
upon request of 911 Authorities who have established the capability to 
accept NG911-compatible, IP-based 911 communications.\191\ The 
Commission reasoned that its proposal would help jurisdictions that are 
seeking to implement NG911 by alleviating the burden on 911 Authorities 
to maintain transitional gateways and other network elements to process 
and convert legacy calls \192\ and would complement its IP-delivery 
proposal in the LBR Notice.\193\ In the NG911 Notice, the Commission 
sought comment on achieving regulatory parity in its requirements for 
delivery of IP-based 911 calls by CMRS, wireline, interconnected VoIP, 
and internet-based TRS providers, and asked whether there were reasons 
to apply different requirements to 911 calls from different 
platforms.\194\ In addition, the Commission sought specific comment on 
how its proposal should extend to 911 calls that originate on non-IP 
wireline networks \195\ and how to extend its proposed requirement to 
internet-based TRS.\196\
---------------------------------------------------------------------------

    \191\ NG911 Notice, 38 FCC Rcd at 6215, para. 21.
    \192\ Id. at 6215, para. 22.
    \193\ Id. at 6216, para. 23 (``Although CMRS providers originate 
75 to 80 percent of 911 calls in the U.S., successful implementation 
of NG911 for all 911 calls cannot occur without similar steps being 
taken by wireline, interconnected VoIP, and internet-based TRS 
providers. Therefore, we propose that wireline, interconnected VoIP, 
and internet-based TRS providers should be subject to similar 
requirements to deliver 911 communications in IP-based format to 
those we have proposed for CMRS and covered text providers.'').
    \194\ Id. at 6216, para. 23.
    \195\ Id. at 6216-17, para. 25.
    \196\ Id. at 6217-18, para. 26.
---------------------------------------------------------------------------

    In both the LBR Notice and NG911 Notice, the Commission proposed to 
require OSPs to complete all NG911 transition steps in a single 
phase.\197\ In the NG911 Notice, the Commission also sought comment on 
whether to consider different or additional phases, including NASNA's 
proposal for three phases based on TFOPA's ``NG911 Readiness 
Scorecard.'' \198\ In addition, the Commission asked related questions 
regarding the costs and benefits associated with NASNA's 
suggestion.\199\
---------------------------------------------------------------------------

    \197\ Id. at 6215, para. 21; LBR Notice, 37 FCC Rcd at 15201, 
para. 46. In the LBR Order, the Commission deferred to this 
proceeding, PS Docket No. 21-479, consideration of proposals for 
CMRS and covered text providers to deliver wireless 911 voice calls, 
texts, and associated routing information in IP format. LBR Order at 
*2, para. 3.
    \198\ NG911 Notice, 38 FCC Rcd at 6224-25, para. 41 (citing the 
NASNA Petition at 7-8).
    \199\ Id. at 6224-25, para. 41.
---------------------------------------------------------------------------

    In response to the NG911 Notice, several commenters, including 
NASNA, USTelecom, Intrado, MSCI, iCERT, and the Colorado PUC, advocate 
for regulations that account for multiple phases in the transition to 
NG911.\200\ Several of these commenters indicate that a phased approach 
would better reflect the realities of the ongoing, typically phased, 
implementation of NG911 thus far. NASNA states that the implementation 
of NG911 is ``typically a multi-phase transition process'' and that 
``there is not just one phase of readiness.'' Intrado states that ``a 
phased-in approach . . . account[s] for, on the one hand, the 
significant difference between delivering IP-formatted traffic to the 
NG911 POI and delivering i3-formatted traffic and, on the other hand, 
differences in OSP type.'' iCERT states that ``FCC rules should 
recognize and accommodate various stages of NG911 implementation.'' 
MSCI argues that requiring immediate implementation of full NG911 
capabilities in a single phase would ``complicate, if not frustrate, 
the Commission's goal to more quickly transition TDM-based 
communications to IP-based communications.'' However, some commenters 
support implementation of the transition in a single phase,\201\ urge 
the Commission to seek further comment on phased approaches, or urge 
the Commission to create an industry task force to further study 
NG911.\202\
---------------------------------------------------------------------------

    \200\ NASNA NG911 Notice Comments at 3, 6-7; USTelecom NG911 
Notice Reply at 6 (citing NASNA NG911 Notice Comments at 9 and 
Intrado NG911 Notice Comments at 4 (rec. Aug. 9, 2023) (Intrado 
NG911 Notice Comments)); iCERT Nov. 2, 2023 Ex Parte, Attach. at 5; 
MSCI NG911 Notice Comments at 4; iCERT Dec. 13, 2023 Office of 
Commissioner Gomez Ex Parte, Attach. at 4; iCERT Dec. 13, 2023 
Office of Commissioner Carr Ex Parte, Attach. at 4; iCERT Dec. 13, 
2023 Office of Commissioner Starks Ex Parte, Attach. at 4; Colorado 
PUC NG911 Notice Comments at 4.
    \201\ Letter from Brandon Abley, Director of Technology, and 
Jonathan Gilad, Director of Government Affairs, NENA, to FCC, PS 
Docket No. 21-479, at 3 (filed Dec. 8, 2023); Brian Rosen NG911 
Notice Reply at 11-12.
    \202\ Bandwidth Communications, Inc. (Bandwidth) NG911 Notice 
Reply at 4-5 (rec. Sept. 8, 2023) (Bandwidth NG911 Notice Reply).
---------------------------------------------------------------------------

    We require OSPs to complete in two phases all translation and 
routing to deliver 911 traffic, including associated location 
information, in the requested IP-based format.\203\ In Phase 1, OSPs 
will be required to deliver 911 traffic in a basic SIP format, thereby 
implementing the fundamental IP translation or transport that is a 
prerequisite for the delivery of 911 traffic in SIP format that 
complies with commonly accepted standards. In Phase 2, OSPs will be 
required to deliver 911 traffic in SIP format that complies with NG911 
commonly accepted standards. This approach represents a division of the 
one phase approach proposed in the LBR Notice and NG911 Notice.
---------------------------------------------------------------------------

    \203\ Associated location information means the location 
information that OSPs are required to determine and transmit under 
current part 9 rules. We clarify that nothing in our rules is 
intended to change location determination requirements for OSPs, 
meaning the accuracy or reliability of the location information 
provided with 911 calls. See, e.g., 47 CFR 9.8 (indicating the 
dispatchable location requirement for wireline providers); 
9.10(i)(2)(i) (indicating horizontal dispatchable location 
requirements for CMRS providers); 9.10(i)(2)(ii) (indicating 
vertical dispatchable location requirements for CMRS providers); 
9.11(b)(4) (indicating dispatchable location requirements for 
interconnected VoIP providers); 9.14(d)(4) (indicating dispatchable 
location requirements for VRS and IP Relay providers); 9.14(e)(4) 
(indicating dispatchable location requirements for IP CTS 
providers).
---------------------------------------------------------------------------

    We adopt two phases for all OSPs--i.e., wireline providers, CMRS 
providers, covered text providers, interconnected VoIP providers, and 
internet-based TRS providers--to facilitate an ordered and synchronized 
transition to NG911, to better reflect the transition to NG911 as it 
currently is progressing, and to achieve regulatory parity in the 
requirements for the delivery of IP-based 911 calls across different 
platforms. We agree with Colorado PUC that ``every implementation of 
NG911 is being accomplished on a phased basis, so allowing for multiple 
iterations of requirements to be established is necessary.'' \204\ This 
approach recognizes that OSPs will need additional time to achieve 
delivery of 911 traffic using NG911 commonly accepted standards in 
Phase 2.
---------------------------------------------------------------------------

    \204\ Colorado PUC NG911 Notice Comments at 4 (emphasis 
omitted).
---------------------------------------------------------------------------

    The phased approach we adopt is consistent with phased approaches 
recommended by Intrado and MSCI, with minor adjustments to accommodate 
our regulatory goal of encompassing current and future NG911 commonly 
accepted standards. Intrado states that ``NG911 delivery is divisible 
into two distinct stages--(1) IP transit (i.e., SIP delivery to the 
POI) and (2) NG911-formatted call information under

[[Page 78082]]

the i3 standard, with the former being a prerequisite for the latter.'' 
MSCI suggests that the Commission consider ``a two-step approach to 
NG911 deployment. The first step would involve a requirement that an 
OSP deliver 911 calls in IP format [upon request of a 911 Authority] . 
. . . The second step would involve a requirement that an OSP deliver 
911 calls consistent with NENA i3 standard . . . .'' The rules are very 
similar to Intrado's and MSCI's recommendations.
    NASNA proposed a three-phase approach in which the initial phase 
would be triggered when the 911 Authority has an ESInet that is ready 
to receive 911 calls from the OSPs via an LNG. Colorado PUC similarly 
contemplates a phase in which 911 Authorities would maintain an LNG. We 
conclude that incorporating this initial phase into our rules is 
unnecessary and potentially counterproductive, as it merely describes 
the earliest transitional stage in which 911 Authorities continue to 
maintain LNGs to accommodate OSPs that have not transitioned to IP. We 
agree with MSCI that including this ``legacy phase'' could ``prolong 
the migration.'' \205\ Instead, Phase 1 and Phase 2 in our rules 
correspond to the second and third phases proposed by NASNA, which call 
for OSPs to first support basic SIP and then support SIP that complies 
with NG911 commonly accepted standards.
---------------------------------------------------------------------------

    \205\ Mission Critical Partners NG911 Notice Comments at 8-9 
(citing NASNA Petition).
---------------------------------------------------------------------------

    We prefer the two-phase approach to the single-phase approach 
proposed in the LBR Notice and NG911 Notice because a single-phase 
approach is less capable of encompassing the sequencing of steps that 
both 911 Authorities and OSPs must take during the NG911 transition. As 
discussed by several commenters, a phased regulatory approach aligns 
with the typical multi-phased implementation of NG911. In addition, we 
find it unnecessary to seek further comment on whether to adopt a 
phased approach, given that the Commission sought comment on NASNA's 
phased recommendation in the NG911 Notice and has gathered an adequate 
record for decision.\206\ We additionally conclude that, in light of 
the extensive record in this proceeding, an industry task force is not 
needed to further study these NG911 rules. We also find that a two-
phased approach will not needlessly slow the transition to NG911, as 
argued by APCO, as the phased approach we adopt will ensure that OSPs 
and 911 Authorities take the necessary steps at each phase of the 
transition to NG911.
---------------------------------------------------------------------------

    \206\ NG911 Notice, 38 FCC Rcd at 6224-25, para. 41.
---------------------------------------------------------------------------

    We affirm the Commission's reasoning in the LBR Notice and NG911 
Notice that IP delivery requirements will advance the transition to 
NG911 by alleviating the burden on 911 Authorities to maintain 
transitional gateways and helping 911 Authorities realize the public 
safety benefits of NG911 networks. We agree with iCERT's assertion that 
the need to accommodate TDM-based 911 calls creates added costs for 
state and local 911 authorities, and that the adoption of IP delivery 
requirements will reduce the cost burdens of maintaining and operating 
legacy 911 infrastructure. We also agree 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.'' \207\ We agree with Comtech that 
maintaining both legacy and IP-based systems for the delivery of 911 
traffic involves significant costs and creates increased vulnerability 
and risk of 911 outages. NENA also states that it is prohibitively 
expensive to maintain TDM and IP networks for 911 simultaneously.
---------------------------------------------------------------------------

    \207\ Letter from Lauren Kravetz, Vice President, Government 
Affairs, Intrado, to Marlene Dortch, Secretary, FCC, PS Docket No. 
21-479, at 1 (filed Oct. 24, 2023) (Intrado Oct. 24, 2023 Ex Parte).
---------------------------------------------------------------------------

    In addition, we affirm the principle of parity in NG911 
requirements for OSPs at Phases 1 and 2, though as discussed in this 
document and section III.C.3 of the Order, differences among types of 
OSPs regarding their current NG911 transition progress and capabilities 
merit adjustment of compliance timelines for some classes of OSPs. 
NENA, iCERT, NASNA, Maine PUC, Colorado PUC, Mission Critical Partners, 
and the Ad Hoc NG911 Service Providers Coalition support parity among 
different types of OSPs. Several commenters indicate that the 
Commission should decline to extend IP delivery requirements to 
wireline and VoIP providers as these services deliver location 
information to 911 Authorities differently than CMRS providers.\208\ We 
note that interconnected VoIP providers already use a LIS functional 
element to transmit location information to 911 Authorities, subject to 
the NENA i2 standard,\209\ and we therefore find arguments that 
interconnected VoIP providers cannot provide location information to 
NG911 networks via a LIS to be unsupported. The record also confirms 
that it is technically feasible for wireline providers to use a LIS to 
transmit location information to 911 Authorities, even when they do not 
originate calls in IP. We also note that nothing under these rules 
changes the existing obligations that all OSPs have to determine the 
location of the 911 caller under the OSP-specific rules in part 9.
---------------------------------------------------------------------------

    \208\ South Carolina RLECs NG911 Notice Reply at 13 (rec. Sept. 
8, 2023) (South Carolina RLECs NG911 Notice Reply) (stating that it 
is premature to extend IP delivery requirements to fixed wireline 
carriers, and that such rules should not be applied to wireline and 
VoIP because this would be expensive and unnecessary due to 
differences in how fixed and mobile 911 location data is delivered); 
Home Telephone ILEC LLC (Home Telephone) NG911 Notice Comments at 
15-16 (rec. Aug. 9, 2023) (Home Telephone NG911 Notice Comments) 
(stating that the Commission should not require wireline providers 
to deliver location data in IP format, as RLECs lack that 
capability); USTelecom NG911 Notice Comments at 3 (rec. Aug. 9, 
2023) (USTelecom NG911 Notice Comments) (stating that it is 
technically infeasible for some wireline carriers to include 
location information in IP call headers, requiring continued 
reliance on ALI databases); Five Area Telephone Cooperative, Inc. 
and Mid-Plains Rural Telephone Cooperative, Inc. (Five Area 
Telephone) NG911 Notice Comments at 5 (rec. Aug. 9, 2023) (Five Area 
Telephone NG911 Notice Comments) (arguing that wireline and VoIP 
carriers cannot provide the same automated location data as CMRS); 
NTCA-The Rural Broadband Association (NTCA) NG911 Notice Comments at 
16-17 (rec. Aug. 9, 2023) (NTCA NG911 Notice Comments) (arguing that 
wireline providers should be allowed to continue to rely on ALI for 
location information and should not have to provide the location 
information proposed in the LBR proceeding for CMRS and covered text 
providers).
    \209\ NENA, Interim VoIP Architecture for Enhanced 9-1-1 
Services (i2) at page 58 (Dec. 6, 2005), https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards-archived/nena_08-001-v1_interim_voip_.pdf (``The i2 solution proposes a Location 
Information Server (LIS) be the source for distributing location 
information within an access network.'').
---------------------------------------------------------------------------

b. Phase 1
(i) Requirement
    Upon receipt of a valid Phase 1 request from a 911 Authority, OSPs 
must (i) deliver all 911 traffic bound for the relevant PSAPs in the 
IP-based SIP format requested by the 911 Authority, (ii) obtain and 
deliver 911 traffic to enable the ESInet and other NG911 network 
facilities to transmit all 911 traffic to the destination PSAP, (iii) 
deliver all such 911 traffic to one or more in-state NG911 Delivery 
Points designated by the 911 Authority, and (iv) complete connectivity 
testing to confirm that the 911 Authority receives 911 traffic in the 
IP-based SIP format requested by the 911 Authority. OSPs are not 
required to originate 911 traffic in an IP format, and therefore may 
use a legacy TDM-to-IP gateway (LNG) to achieve compliance with these 
Phase 1 requirements.
    The diagram below demonstrates the main high-level functions 
covered at Phase 1. This diagram is not meant to

[[Page 78083]]

represent required network architectures in an ``as built'' 
configuration and is not prescriptive in nature. The call flow is 
illustrated by blue lines representing SIP 911 traffic and red lines 
indicating legacy 911 traffic. In the diagram below, 911 traffic 
originates on the left side of the diagram and flows from left to 
right.
[GRAPHIC] [TIFF OMITTED] TR24SE24.002

    The above diagram uses the following acronyms:

 ANI = Automatic Number Identification
 ALI = Automatic Location Information
 BCF = Border Control Function
 ESInet = Emergency Services IP Network
 IMS = IP Multimedia Subsystem
 LIS = Location Information Server
 LNG = Legacy Network Gateway
 LPG = Legacy PSAP Gateway
 LSRG = Legacy Selective Router Gateway
 MSAG = Master Street Address Guide
 NG PSAP = Next Generation 911 PSAP
 NGCS = NG911 Core Services
 TDM = Time Division Multiplex

    Implementing Phase 1 will help reduce costs and improve 911 
reliability by moving 911 traffic from legacy to IP transmission 
facilities, and will establish the foundation necessary for subsequent 
implementation of Phase 2. MSCI and iCERT argue, and we agree, that 
delivery in IP is a critical first step before compliance with NG911 
commonly accepted standards.\210\ Intrado asserts that IP delivery will 
``materially reduce the number of 911 outages through improved network 
reliability.'' Mission Critical Partners, iCERT, Comtech, and the State 
of Minnesota Department of Public Safety-Emergency Communication 
Networks (Minnesota DPS-ECN) indicate that relieving 911 Authorities of 
the burden of supporting TDM traffic from OSPs will materially reduce 
costs to those 911 Authorities.
---------------------------------------------------------------------------

    \210\ MSCI NG911 Notice Comments at 2 (stating that the most 
urgent element of NG911 is the delivery of 911 calls in IP-based 
format, and compliance with the NENA i3 standard should not hinder 
such delivery); iCERT NG911 Notice Comments at 5 (stating that full 
implementation of end state NG911 capabilities should not be a 
prerequisite for PSAPs to have 911 delivered in IP format); iCERT 
Dec. 13, 2023 Office of Commissioner Gomez Ex Parte, Attach. at 4; 
iCERT Dec. 13, 2023 Office of Commissioner Carr Ex Parte, Attach. at 
4; iCERT Dec. 13, 2023 Office of Commissioner Starks Ex Parte, 
Attach. at 4.
---------------------------------------------------------------------------

    To the extent that OSPs originate 911 traffic in TDM, we find that 
they should be responsible in Phase 1 for translating such traffic to 
SIP when delivering it to the designated NG911 Delivery Point. We 
disagree with Verizon's argument that requiring each individual TDM-
based OSP to provide an LNG ``imposes unnecessary costs on OSPs'' and 
that ``LNG capabilities should thus presumptively remain the PSAP/NG911 
provider's responsibility.'' \211\ As most OSPs already transmit 
traffic via SIP, it is unreasonable to require 911 Authorities to 
maintain LNGs for the small number of OSPs that continue to originate 
and transmit their traffic in TDM. In addition, we find that it is not 
unreasonably costly for OSPs that originate and transmit traffic in TDM 
to maintain an LNG or contract with a third party to translate 911 
traffic. We find that it should be the responsibility of the OSP to 
translate 911 traffic from legacy formats and deliver 911 traffic in 
the SIP format requested by the 911 Authority. However, nothing in our 
rules prevents a 911 Authority from continuing to host an LNG for OSPs 
to use, either through an alternative agreement with an OSP or by 
choosing not to use the valid request mechanism in our rules. This 
possibility was noted by CSRIC, which observed that a 911 Authority's 
ESInet provider ``can provide the LNG as a service and

[[Page 78084]]

accommodate small carriers coming on board with minimal expense to the 
smaller carrier.'' \212\
---------------------------------------------------------------------------

    \211\ Verizon NG911 Notice Reply at 5 (rec. Sept. 8, 2023) 
(Verizon NG911 Notice Reply).
    \212\ CSRIC NG911 Transition Report, sec. 5.1.1.2.2.3.
---------------------------------------------------------------------------

    Connectivity Testing. As part of Phase 1, we require OSPs to 
conduct connectivity testing to confirm that the 911 Authority receives 
911 traffic in the IP-based SIP format requested by the 911 Authority. 
Such testing will help to ensure that the connection from the OSP to 
the 911 Authority is implemented correctly and meets the requirements 
of the 911 Authority. The Commission sought comment on testing related 
to NG911 delivery in the LBR Notice and NG911 Notice.\213\ Several 
commenters emphasize the importance of connectivity testing as part of 
the process of initiating delivery of 911 traffic to ESInets.\214\ 
Commenters also note that connectivity testing will require 
cooperation, coordination, and collaboration among multiple parties, 
including OSPs, NG911 vendors, and 911 Authorities.\215\ Because the 
ability of OSPs to complete testing within the required time period 
depends on such cooperation, we condition the testing requirement on 
911 Authorities securing commitments from their NG911 vendors to ensure 
that such vendors are available to complete connectivity testing by the 
compliance deadline applicable to the OSP.
---------------------------------------------------------------------------

    \213\ LBR Notice, 37 FCC Rcd at 15208, para. 64; NG911 Notice, 
38 FCC Rcd at 6228, para. 47.
    \214\ See, e.g., T-Mobile LBR Notice Comments at 12 (rec. Feb. 
16, 2023) (``Carriers cannot unilaterally deliver traffic in IP--
they must first ensure that PSAPs are ready to receive it, which is 
verified through comprehensive testing.'') (T-Mobile LBR Notice 
Comments); Verizon LBR Notice Reply at 4 (rec. Mar. 20, 2023) 
(``[M]any of the technical and operational details will inevitably 
need to be addressed as part of the [NG911] implementation 
process'') (Verizon LBR Notice Reply); CCA NG911 Notice Comments at 
7-8 (noting that it is important for OSPs to ``meaningfully 
collaborate'' with 911 Authorities on IP traffic delivery by 
ensuring that sufficient testing occurs to minimize real world 
issues when IP traffic is exchanged and NG911 is implemented).
    \215\ CCA NG911 Notice Comments at 7-8 (``It is important for 
OSPs to meaningfully collaborate with 911 authorities on IP traffic 
delivery and NG911 to ensure readiness, account for any unique local 
circumstances or complexities, and ensure that sufficient planning 
and testing occurs to minimize real world issues when IP traffic is 
exchanged and NG911 is implemented.''); BRETSA NG911 Notice Reply at 
i (``The ESInet or NGCS provider is also the party which can confirm 
that the PSAPs are IP-ready, and which must cooperate in 
provisioning and testing IP call delivery.''); T-Mobile LBR Notice 
Comments at 12.
---------------------------------------------------------------------------

(ii) Definitions
    To facilitate compliance with our rules for Phase 1 delivery, we 
adopt definitions for ``911 traffic,'' ``NG911 Delivery Point,'' and 
``Session Initiation Protocol (SIP).'' Adopting functional definitions 
of these terms will provide guidance to OSPs in complying with our cost 
allocation and IP-delivery rules and will assist both OSPs and 911 
Authorities by providing baseline definitions of important technical 
terms relevant to their needs. We define the term ``911 traffic'' as a 
convenient descriptor of the transmissions regulated under these rules. 
We similarly define the term ``NG911 Delivery Point'' as a convenient 
descriptor of the point to which an OSP's 911 traffic is delivered. 
While several commenters called for definitions of the terms ``IP-
capable,'' ``IP-based,'' and ``NG911-capable,'' \216\ the term ``SIP'' 
is a standard technical term used in NG911 reference materials.\217\ 
``SIP'' was also used by several other commenters in the record.\218\ 
We believe that referencing ``SIP'' to describe IP delivery and 911 
Authority readiness at Phases 1 and 2 and defining that term will 
provide clarity regarding the Commission's NG911 rules, as it is a 
technically more precise term than ``IP-based format'' and similar 
terms.
---------------------------------------------------------------------------

    \216\ Comtech NG911 Notice Comments at 7; CTIA LBR Notice Reply 
at 2, 9-10; NENA LBR Notice Reply at 4-5; Southern Communications 
Services, Inc. d/b/a Southern Linc (Southern Linc) LBR Notice Reply 
at 8-9 (rec. Mar. 20, 2023).
    \217\ See, e.g., NENA i3 at 3; NENA, NENA Knowledge Base (May 
17, 2024), https://kb.nena.org/wiki/SIP_(Session_Initiation_Protocol).
    \218\ See, e.g., USTelecom NG911 Notice Reply at 4 (discussing 
the NG911 Notice's ``proposal to require OSPs to provide location 
data with the SIP message''); T-Mobile NG911 Notice Comments at 4 
(``SIP connectivity is a foundational building block for NG911.''); 
Intrado NG911 Notice Reply at 3 (rec. Sept. 8, 2023) (Intrado NG911 
Notice Reply) (explaining its proposal that the first stage of PSAP 
readiness would be that a 911 Authority is ``ready to certify that 
it can receive IP-formatted (i.e., SIP) traffic at the designated IP 
POI''). Regarding IP Service Delivery, NASNA urged the Commission to 
assist with the transition to NG911 by, among other things, amending 
the Commission's rules to ``specifically address NG911, including 
the standardized requirements associated with NG911 (e.g., Session 
Initiation Protocol [SIP] format and provide location information 
attached to the SIP header of the call using Presence Information 
Data Format Location Object [PIDF-LO]).'' NG911 Notice, 38 FCC Rcd 
at 6214-15, para. 20 (citing NASNA Petition at 4-5).
---------------------------------------------------------------------------

    We find that defining these terms will help to clarify our NG911 
requirements and assist parties with compliance. Accordingly, we adopt 
the following definitions:

 911 traffic. Transmissions 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 information about calling parties' locations and 
originating telephone numbers and routing information transmitted with 
the calls and/or text messages.
 NG911 Delivery Point. A geographic location, facility, or 
demarcation point designated by a 911 Authority where an originating 
service provider shall transmit and deliver 911 traffic in an IP format 
to ESInets or other NG911 network facilities.
 Session Initiation Protocol (SIP). A signaling protocol used 
for initiating, maintaining, modifying, and terminating communications 
sessions between internet Protocol (IP) devices. SIP enables voice, 
messaging, video, and other communications services between two or more 
endpoints on IP networks.
c. Phase 2
(i) Requirement
    Upon receipt of a 911 Authority's valid Phase 2 request, OSPs must 
deliver all 911 traffic bound for the relevant PSAPs to NG911 Delivery 
Points designated by the 911 Authority in an IP-based SIP format that 
complies with NG911 commonly accepted standards identified by the 911 
Authority, including having location information embedded in the call 
signaling using Presence Information Data Format--Location Object 
(PIDF-LO) \219\ or its functional equivalent. OSPs must also either (1) 
install and put into operation all equipment, software applications, 
and other infrastructure necessary to use a LIS or its functional 
equivalent for the verification of their customer location information 
and records, or (2) acquire services that can be used for the same 
purpose. In addition, OSPs must complete connectivity testing to 
confirm that the 911 Authority receives 911 traffic in the IP-based SIP 
format that complies with the identified NG911 commonly accepted 
standards. Because Phase 2 builds upon Phase 1, and completion of Phase 
1 is a prerequisite for Phase 2, the OSP must also continue to comply 
with Phase 1 requirements during Phase 2, including the requirement to 
deliver all such 911 traffic to NG911 Delivery Points designated by the 
911 Authority. Phase 2 will facilitate the full use of the functional 
elements of NGCS, including LVF, which can deliver more dynamic and 
actionable information to PSAPs than legacy ALI databases, and policy 
routing functions that can dynamically reroute 911 calls and texts in 
response to real-time events. This will eliminate the need for 911 
Authorities to maintain legacy ANI and ALI components and will provide 
PSAPs with greater

[[Page 78085]]

flexibility to avoid network disruptions and reduce the impact of 
outages on 911 continuity.
---------------------------------------------------------------------------

    \219\ See RFC 4119.
---------------------------------------------------------------------------

    We provide the below illustrative diagram to demonstrate the main 
high-level functions covered at Phase 2. This diagram is not meant to 
represent required network architectures in an ``as built'' 
configuration and is not prescriptive in nature. The call flow is 
illustrated by blue lines representing SIP 911 traffic and red lines 
indicating legacy 911 traffic. In the below diagram, 911 traffic 
originates on the left side of the diagram and flows from left to 
right.
[GRAPHIC] [TIFF OMITTED] TR24SE24.003

    The above diagram uses the following acronyms:

 ANI = Automatic Number Identification
 ALI = Automatic Location Information
 BCF = Border Control Function
 ECRF = Emergency Call Routing Function
 ESInet = Emergency Services IP Network
 ESRP = Emergency Services Routing Proxy
 GIS = Geographic Information System
 IMS = IP Multimedia Subsystem
 LIS = Location Information Server
 LNG = Legacy Network Gateway
 LPG = Legacy PSAP Gateway
 LVF = Location Validation Function
 MSAG = Master Street Address Guide
 NG PSAP = Next Generation 911 PSAP
 NGCS = NG911 Core Services
 PRF = Policy Routing Function

    OSPs may comply with Phase 2 either by originating 911 traffic in 
IP format or by maintaining or accessing an LNG to convert the traffic 
in order to deliver 911 traffic in SIP format that complies with the 
NG911 commonly accepted standards identified by the requesting 911 
Authority. This addresses a concern raised by several commenters that 
requiring IP origination, as opposed to delivery, could be burdensome 
for some wireline providers.\220\ Although some commenters support an 
origination requirement,\221\ AT&T notes that this could require 
certain OSPs to make ``inefficient alterations to network components 
that are nearing end-of-life.'' USTelecom states that in some instances 
OSPs would have to ``overbuild their existing networks with fiber on an 
abbreviated timeline, a proposition that is not only unnecessary but 
would be extremely costly.'' USTelecom also notes that some wireline 
providers have carrier of last resort (COLR) obligations ``prohibiting 
them from retiring legacy networks and technology.'' We agree that in 
light of these considerations, IP origination should be encouraged but 
not required, so long as OSPs ensure that 911 calls originated in TDM 
are translated and delivered in SIP format. Therefore, in both Phase 1 
and Phase 2, we permit OSPs to choose between upgrading networks to 
enable IP origination or converting their TDM traffic to IP before 
delivery to the NG911 network.\222\
---------------------------------------------------------------------------

    \220\ USTelecom NG911 Notice Comments at 2-3; US Telecom NG911 
Notice Reply at 2; Steven Samara NG911 Notice Comments at 8 (rec. 
Aug. 9, 2023) (filed on behalf of Pennsylvania Telephone 
Association) (Pennsylvania Telephone Association NG911 Notice 
Comments); Fastwyre Broadband (Fastwyre) NG911 Notice Reply at 4 
(rec. Sept. 7, 2023); AT&T NG911 Notice Comments at 6; Bandwidth 
NG911 Notice Reply at 2-3; NENA NG911 Notice Reply at 7.
    \221\ WTA-Advocates for Rural Broadband (WTA) NG911 Notice 
Comments at 8 (rec. Aug. 9, 2023)) (WTA NG911 Notice Comments); 
Letter from Brandon Abley, Director of Technology, and Jonathan 
Gilad, Director of Government Affairs, NENA, to FCC, PS Docket No. 
21-479, at 1 (filed Jan. 17, 2024).
    \222\ Verizon indicates that its current approach for deploying 
NG911 includes working with NGCS providers to implement and test 
capabilities, which results in a ``fairly straightforward process'' 
for delivering 911 calls to the NGCS provider's PSAP customers as 
those jurisdictions implement their own NG911 capabilities. Letter 
from Robert G. Morse, Associate General Counsel, Federal Regulatory 
and Legal Affairs, Verizon, to Marlene H. Dortch, Secretary, FCC, PS 
Docket Nos. 18-64 and 21-479, at 1-2 (filed July 13, 2023) (Verizon 
July 13, 2023 Ex Parte). OSPs may wish to consider Verizon's 
approach in order to prepare for the timelines adopted under these 
rules, but we do not specifically require OSPs to take this 
approach.

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

[[Page 78086]]

    The Competitive Carriers Association (CCA) questions whether the 
Commission provided sufficient notice of a proposed requirement for 
wireless carriers to translate 911 traffic to IP.\223\ We find that 
both the NG911 Notice and LBR Notice clearly proposed requirements for 
TDM-based wireless carriers to translate 911 traffic to IP. The 
proposed rules in the LBR Notice specified that CMRS providers would be 
required to deliver calls in the requested IP-based format.\224\ In the 
NG911 Notice, the Commission proposed that valid requests by 911 
Authorities for IP-based service would trigger obligations for all 
OSPs, including CMRS providers.\225\ Therefore, there has been 
sufficient notice, and the Commission finds CCA's concern unwarranted.
---------------------------------------------------------------------------

    \223\ CCA NG911 Notice Comments at 3-4 (stating that ``the draft 
implementing regulations in the [NG911] NPRM contain clear language 
about the requirement of TDM-based wireline carriers to translate 
911 traffic to IP, but there is no such language related to wireless 
carriers'').
    \224\ LBR Notice, 37 FCC Rcd at 15216, app. A; accord id. at 
15201, para. 46 (``We propose to require CMRS and covered text 
providers to deliver 911 calls, texts, and associated routing 
information in IP-based format to NG911-capable PSAPs that request 
it.'').
    \225\ NG911 Notice, 38 FCC Rcd at 6224-25, para. 41.
---------------------------------------------------------------------------

    Some wireline commenters argue that it is not technically feasible 
for wireline carriers to translate 911 calls from TDM to IP with the 
inclusion of location data that is required for Phase 2.\226\ We 
disagree. There are several commercially available solutions that offer 
LIS services to wireline providers, as well as gateway products for 
translating calls from TDM to IP with the inclusion of location 
data.\227\ We therefore find that it is technically feasible for 
wireline providers to provide location information to 911 Authorities 
in a format that complies with NG911 commonly accepted standards. 
Further, we agree with NCTA that ``any provider that continues to 
originate traffic in TDM format should bear responsibility for adding 
appropriate location information and converting such calls to IP format 
before delivering them to the demarcation point.'' \228\
---------------------------------------------------------------------------

    \226\ Home Telephone NG911 Notice Comments at 15-16 (arguing 
that the Commission should not require wireline providers to deliver 
location data in IP format, as RLECs lack that capability); 
USTelecom NG911 Notice Comments at 3 (stating that it is technically 
infeasible for some wireline carriers to include location 
information in IP call headers); South Dakota Telecommunications 
Association NG911 Notice Comments at 12-14 (rec. Aug. 9, 2023) 
(South Dakota Telecommunications Association NG911 Notice Comments) 
(asking that carriers be exempt from delivering IP location until 
technically feasible); Five Area Telephone Notice Comments at 5-7, 
15 (arguing that wireline and VoIP carriers cannot provide the same 
automated location data as CMRS providers and so should allow more 
time for OSPs to provide location information in the call path).
    \227\ See, e.g., Virginia Department of Emergency Management, 
MSAG and ALI Maintenance After Next Generation 9-1-1 Go-Live (2022), 
https://gismaps.vdem.virginia.gov/websites/PSC/RegionalAdvisoryCommittee/Documents/20221117MSAGALIMaint.pdf 
(indicating that AT&T and Intrado offer this gateway translation 
service to wireline OSPs).
    \228\ NCTA-The internet & Television Association (NCTA) NG911 
Notice Reply at 2 (rec. Aug. 9, 2023) (NCTA NG911 Notice Reply).
---------------------------------------------------------------------------

    APCO urges the Commission to explore options for ensuring that 
PSAPs receive actionable location information in the form of 
dispatchable location.\229\ We clarify that nothing in our rules is 
intended to change existing location accuracy requirements for OSPs, 
including rules that require provision of dispatchable location when 
feasible.\230\
---------------------------------------------------------------------------

    \229\ Letter from Jeffrey S. Cohen, Chief Counsel, APCO 
International, to Marlene Dortch, Secretary, FCC, PS Docket Nos. 21-
479, 18-64, and 07-114, at 1 (filed Sept. 22, 2023) (APCO Sept. 22, 
2023 Ex Parte).
    \230\ See, e.g., 47 CFR 9.8 (indicating the dispatchable 
location requirement for wireline providers); 9.10(i)(2)(i) 
(indicating horizontal dispatchable location requirements for CMRS 
providers); 9.10(i)(2)(ii) (indicating vertical dispatchable 
location requirements for CMRS providers); 9.11(b)(4) (indicating 
dispatchable location requirements for interconnected VoIP 
providers); 9.14(d)(4) (indicating dispatchable location 
requirements for VRS and IP Relay providers); 9.14(e)(4) (indicating 
dispatchable location requirements for IP CTS providers).
---------------------------------------------------------------------------

    We decline to adopt the Texas 9-1-1 Entities' alternative proposal 
to establish different requirements for OSPs that already are capable 
of originating 911 calls in IP format versus OSPs that continue to rely 
on legacy TDM switching facilities for voice traffic within their 
networks.\231\ Under the Texas 9-1-1 Entities proposal, IP-capable OSPs 
would be required to fully support delivery of 911 calls in Phase 2 
NG911 format, but non-IP capable OSPs would deliver calls to LNGs 
designated by 911 Authorities or their NG911 service providers. The 911 
Authorities or their service providers would be responsible for 
operating the LNGs, which would translate the 911 calls into IP format. 
We decline to adopt this proposal because it would require 911 
Authorities to continue to operate and maintain LNGs to support a small 
number of TDM-based OSPs, thereby incentivizing OSPs to continue to 
maintain legacy infrastructure, increase costs, and lengthen the time 
to transition to NG911.\232\ Instead, our rules appropriately shift the 
burden of maintaining translation gateways to those OSPs that continue 
to originate legacy 911 calls that require translation.\233\
---------------------------------------------------------------------------

    \231\ See NG911 Notice, 38 FCC Rcd at 6221, para. 32; Texas 9-1-
1 Entities NG911 Public Notice Comments at 7-8 (rec. Jan. 19, 2022).
    \232\ NENA NG911 Notice Comments at 10 (``[L]ong-term 
maintenance of NG9-1-1 compliant services is much more cost 
effective than maintaining legacy systems in perpetuity.''); Comtech 
NG911 Notice Reply at 5 (noting the importance of ``replacing the 
circuit-switched [TDM] architecture of legacy 911 networks with 
[IP]-based technologies and applications''); Brian Rosen NG911 
Notice Reply at 20-21) (stating that 911 Authorities should not 
remain responsible for LNGs).
    \233\ See, e.g., NENA NG911 Notice Comments at 10; Ad Hoc NG911 
Service Providers Coalition NG911 Notice Reply at 6 (rec. Sept. 8, 
2023) (urging the Commission to ``refrain from establishing two sets 
of rules to accommodate the long-anticipated sunsetting of TDM 
technology''); Comtech NG911 Notice Reply at 5; Brian Rosen NG911 
Notice Reply at 20-21; South Carolina RFA NG911 Notice Comments at 
6-7; NCTA NG911 Notice Comments at 2 (rec. Aug. 9, 2023) (NCTA NG911 
Notice Comments) (the Commission ``generally should not establish 
exceptions that would encourage companies to continue to rely on 
legacy TDM technology after the 911 Authority has transitioned to 
NG911.''); see also BRETSA NG911 Notice Reply at i (warning against 
``build[ing] layers of delay into the . . . deployment of NG911''); 
MSCI NG911 Notice Reply at 7 (rec. Sept. 8, 2023) (MSCI NG911 Notice 
Reply) (opposing ``proposals to allow different parties to play by 
different rules, which will only serve to increase costs and 
lengthen the time it takes to reach end-state NG911 deployment'').
---------------------------------------------------------------------------

    Connectivity testing. In Phase 2, we require OSPs to complete 
connectivity testing to confirm that the 911 Authority receives 911 
traffic in the IP-based SIP format that complies with the NG911 
commonly accepted standards identified by the requesting 911 Authority. 
Such testing is important to ensure that the connection from the OSP to 
the 911 Authority is implemented correctly and meets the requirements 
of the 911 Authority. Several commenters raise the importance of 
testing as part of the process of initiating delivery of 911 traffic to 
ESInets in a way that complies with NG911 commonly accepted standards. 
As with Phase 1 valid requests, we also adopt a condition prerequisite 
that 911 Authorities secure commitments from their NG911 vendors at 
Phase 2 in order to ensure that such vendors are available to complete 
connectivity testing by the compliance deadline applicable to the OSP.
(ii) Definitions
    To facilitate Phase 2 implementation, there are definitions of 
``Functional Element,'' ``Location Information Server (LIS),'' and 
``Location Validation Function (LVF)'' in the NG911 regulations in this 
document and the Order. In the LBR Notice and NG911 Notice, the 
Commission proposed to

[[Page 78087]]

require OSPs to complete all translation necessary to deliver 911 
calls, including associated location information, in the requested IP-
based format to an ESInet or other designated point(s) that allow 
emergency calls to be answered upon request of 911 authorities who have 
established the capability to accept NG911-compatible, IP-based 911 
communications.\234\ We are establishing functional requirements to 
facilitate the provision of location information with 911 traffic for 
Phase 2.\235\ Under our Phase 2 default rules, LIS based location 
validation uses LVF, and this interaction is analogous to the 
interaction between the ANI/ALI database and MSAG in the E911 context. 
However, in the NG911 environment, LVF replaces the functionality of 
the MSAG. Given the extent to which our rules use these terms, we find 
that defining them will provide greater certainty and clarity regarding 
our NG911 requirements and will assist parties in complying with our 
rules. To codify our approach, we adopt a definition of ``functional 
elements'' that will be part of our definitions for LIS and LVF. 
Accordingly, we adopt the following definitions for these terms:
---------------------------------------------------------------------------

    \234\ LBR Notice, 37 FCC Rcd at 15203, 15215, para. 52, app. A; 
NG911 Notice, 38 FCC Rcd at 6215, para. 21.
    \235\ Under our part 9 rules, dispatchable location refers to 
``[a] location delivered to the PSAP with a 911 call that consists 
of the validated street address of the calling party, plus 
additional information such as suite, apartment or similar 
information necessary to adequately identify the location of the 
calling party, except for Commercial Mobile Radio Service providers, 
which shall convey the location information required by Subpart C of 
this Part.'' 47 CFR 9.3. Under rule 9.10(i), dispatchable location 
refers to ``[a] location delivered to the PSAP by the CMRS provider 
with a 911 call that consists of the street address of the calling 
party, plus additional information such as suite, apartment or 
similar information necessary to adequately identify the location of 
the calling party. The street address of the calling party must be 
validated and, to the extent possible, corroborated against other 
location information prior to delivery of dispatchable location 
information by the CMRS provider to the PSAP.'' 47 CFR 9.10(i).
---------------------------------------------------------------------------

     Functional Element. A set of software features that may be 
combined with hardware interfaces and operations on those interfaces to 
accomplish a defined task.
     Location Information Server (LIS). 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.
     Location Validation Function (LVF). A Functional Element 
in an 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.
d. Modification of Phase Requirements by Mutual Agreement
    We encourage OSPs and 911 Authorities to collaborate throughout the 
transition to NG911. To facilitate such collaboration, and consistent 
with our proposals in the NG911 Notice and LBR Notice, we permit 911 
Authorities and OSPs to enter into mutual agreements specifying 
requirements, timetables, and other terms that are different from the 
Phase 1 and Phase 2 rules in this document and the Order. Commenters 
confirm that such flexibility is important to address unique or 
unforeseen challenges that OSPs may face in transitioning from legacy 
911 to NG911.\236\ The alternative agreement rule provides additional 
flexibility beyond what was proposed in the NG911 Notice and LBR 
Notice, which focused on alternative agreements establishing different 
compliance timeframes for OSPs, as well as different cost recovery 
mechanisms for certain providers.\237\ The rules allow 911 Authorities 
and OSPs to mutually address specific concerns beyond timeframes for 
compliance, including designation of NG911 delivery points or cost 
allocation for OSPs. We find that this additional flexibility should be 
beneficial to both 911 Authorities and OSPs.
---------------------------------------------------------------------------

    \236\ See, e.g., NENA NG911 Notice Comments at 9 (stating that 
the rules should permit a more lenient timeline if a state or local 
911 authority determines that a different timeline is appropriate); 
BRETSA NG911 Notice Reply at ii (recommending that states be given 
the flexibility to adopt rules that diverge from the Commission's 
default requirements as necessitated by state policy); Verizon NG911 
Notice Reply at 3 (stressing the need for flexibility in deadlines 
due to unforeseen challenges); CTIA NG911 Notice Reply at 7 (stating 
that OSPs and PSAPs need flexibility to work through various 
implementation and testing issues); AT&T NG911 Notice Comments at 7 
(stating that timetables should be adaptable to unforeseen 
circumstances); and Alaska Telecom Assoc. NG911 Notice Comments at 7 
(discussing unique challenges in Alaska).
    \237\ NG911 Notice, 38 FCC Rcd at 6205-06, 6224, 6226-28, 6243-
48, paras. 2, 39, 45, 47, app. A (Sec.  9.29(a)(2), (c)(2), (d)(2), 
(e)); LBR Notice, 37 FCC Rcd at 15202, 15216, para. 50, app. A 
(Sec.  9.10(s)(6)(iii)).
---------------------------------------------------------------------------

    When OSPs and 911 Authorities enter into an alternative agreement, 
we require OSPs to notify the Commission of the agreement and its 
pertinent terms, as was proposed in the NG911 Notice and LBR 
Notice,\238\ within 30 days of the date of execution of the agreement. 
We also require that the notice specifically identify each provision of 
the agreement that differs from the rules. Mission Critical Partners 
recommends that for certain deployment agreements, ``an explanation and 
detailed plan with a timeline should be included and provided to the 
Commission and the 911 authority requesting the service.'' We permit 
but do not require that the actual plans and timeline documents 
themselves be provided to the Commission. We delegate authority to 
PSHSB to issue instructions for OSPs to provide notification to the 
Commission of the modification of the agreement and its pertinent 
terms.
---------------------------------------------------------------------------

    \238\ NG911 Notice, 38 FCC Rcd at 6243-48, app. A (Sec.  
9.29(a)(2), (c)(2), (d)(2)); LBR Notice, 37 FCC Rcd at 15216, app. A 
(Sec.  9.10(s)(6)(iii)).
---------------------------------------------------------------------------

e. Internet-Based TRS Providers
    The Phase 1 and Phase 2 requirements apply to internet-based TRS 
providers. However, ClearCaptions and Hamilton Relay point out that 
whereas most internet-based TRS providers directly support 911 calling, 
internet Protocol Captioned Telephone Service providers generally rely 
on underlying providers for routing emergency calls.\239\ We therefore 
clarify that Phase 1 and Phase 2 requirements only apply to internet-
based TRS providers that are directly involved with routing 911 
traffic, pursuant to part 9, subpart E of the Commission's rules.
---------------------------------------------------------------------------

    \239\ ClearCaptions, LLC (ClearCaptions) NG911 Notice Comments 
at 1 (rec. Aug. 9, 2023); Hamilton Relay NG911 Notice Comments at 2.
---------------------------------------------------------------------------

    Brian Rosen suggests that the Commission take additional steps to 
impose additional requirements on IP CTS, IP Relay, and 
videoconferencing services. We did not make such proposals in the NG911 
Notice and therefore decline to take such steps at this time as they 
are outside the scope of this proceeding.
2. Valid Requests for Delivery of 911 Traffic in IP-Based Transmission 
Formats
    We adopt rules defining the prerequisites that 911 Authorities must 
meet in order to make a valid request to OSPs for compliance with the 
requirements of Phase 1 and Phase 2. In the LBR Notice and NG911 
Notice, the Commission proposed that for a 911 Authority request to be 
deemed valid, the 911 Authority would certify that it (1) is 
technically ready to receive 911 calls and texts in the IP-based format 
requested, (2) is specifically authorized

[[Page 78088]]

to accept calls and/or texts in the IP-based format requested, and (3) 
has provided notification to the OSPs receiving the request that it 
meets these requirements.\240\ The Commission also sought comment on 
whether other prerequisites were needed to determine a 911 Authority's 
readiness.\241\
---------------------------------------------------------------------------

    \240\ LBR Notice, 37 FCC Rcd at 15202-03, para. 51; NG911 
Notice, 38 FCC Rcd at 6224, para. 40.
    \241\ LBR Notice, 37 FCC Rcd at 15203, para. 51; NG911 Notice, 
38 FCC Rcd at 6225-26, para. 42.
---------------------------------------------------------------------------

    For both Phases 1 and 2, we adopt the three general prerequisites 
for a valid request proposed in the LBR Notice and NG911 Notice: 
technical readiness, authorization, and notification. We adopt a valid 
request definition at each phase that specifies the functional 
requirements that NG911 networks must achieve prior to OSP compliance. 
In order to facilitate communication between 911 Authorities and OSPs, 
valid requests must indicate the location of NG911 Delivery Point(s) 
designated by the 911 Authority. Finally, we implement a process by 
which OSPs may file a petition contesting whether the 911 Authority has 
met the prerequisites for a Phase 1 or Phase 2 valid request, but we 
decline to automatically toll OSP compliance deadlines based on 
submission of such a petition.
a. Phase 1 Valid Requests
    In order for a Phase 1 request to be valid for purposes of our 
rules, the requesting 911 Authority must certify that it has all of the 
necessary infrastructure installed and operational to receive 911 
traffic in a basic SIP format and transmit such traffic to the PSAP(s) 
connected to it. We believe that this certification is sufficient to 
establish that the 911 Authority is technically ready for Phase 1. We 
agree with Intrado that ``there is normally party consensus regarding a 
911 Authority's technical capability to receive 911 traffic in IP-
format (i.e., SIP),'' and we therefore do not believe that establishing 
additional specific technical requirements to meet the elements of a 
Phase 1 valid request is necessary.
    We believe that Phase 1 is a reasonable interim step in 911 
Authority readiness to establish the ingress of IP traffic to an 
ESInet. While Verizon argues that establishing IP connectivity at the 
ESInet is ``not always necessary for the PSAP and its NG911 vendor to 
migrate to NG911'' and that ``full NG911 implementation is a viable and 
potentially better alternative to the two-stage approach,'' the record 
indicates that most 911 Authorities have implemented or plan to 
implement IP connectivity as a transitional step in their 
implementation of NG911. For OSPs that wish to deliver Phase 2 without 
implementing Phase 1 first, we note that OSPs and 911 Authorities may 
mutually agree on such an approach. As our goal is a prompt transition 
to NG911, to the extent that 911 Authorities and OSPs are ready to 
proceed directly to Phase 2, we encourage them to take that step using 
the mutual agreement process.
b. Phase 2 Valid Requests
    For a Phase 2 request to be deemed valid, the requesting 911 
Authority must certify that it has all of the necessary infrastructure 
installed and operational to receive 911 traffic in SIP format that 
complies with NG911 commonly accepted standards and to transmit such 
traffic to the PSAP(s) connected to it. The 911 Authority also must 
certify that its ESInet is connected to a fully functioning NGCS 
network that can provide access to a LVF and interface with a LIS or 
its functional equivalent provided by the OSP. We believe that these 
elements functionally describe the prerequisites for an NG911 network 
to accept traffic in SIP format that complies with NG911 commonly 
accepted standards.
    The readiness prerequisites that we adopt for a valid Phase 2 
request are generally supported by commenters.\242\ For example, T-
Mobile provides a checklist of elements that it uses when considering 
``i3 NG911 Readiness.'' \243\ T-Mobile's checklist asks questions 
regarding whether the PSAP's NGCS supports standards-based NG911 
connectivity to T-Mobile's LIS. This element is similar to the Phase 2 
prerequisite that the 911 Authority be able to interface with the LIS 
or functionally equivalent capability provided by the OSP. Our 
readiness prerequisites additionally stipulate that the ESInet is 
connected to a fully functioning NGCS network, which is similar to T-
Mobile's checklist questions regarding the extent of NGCS deployment. 
While the Phase 2 readiness elements we in this document and the Order 
are less granular and do not specify every element in T-Mobile's 
checklist, the two are substantially consistent.
---------------------------------------------------------------------------

    \242\ Texas 9-1-1 Entities NG911 Notice Reply at 10 (rec. Sept. 
8, 2023) (Texas 9-1-1 Entities NG911 Notice Reply); NASNA NG911 
Notice Reply at 3-4; Bandwidth NG911 Notice Comments at 6.
    \243\ Letter from Kristine Laudadio Devine, Counsel, T-Mobile, 
to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-64 and 21-
479, at 7-9, Exh. B (filed July 26, 2023) (T-Mobile July 26, 2023 Ex 
Parte).
---------------------------------------------------------------------------

    Several wireless industry commenters support the completion of an 
HTTP-Enabled Location Delivery (HELD) certification as a prerequisite 
of 911 Authority readiness.\244\ While 911 Authorities need not certify 
to the Commission that they or their NGCS providers have a HELD 
certification, we recognize that use of the HELD protocol may enable 
providers to access location information from a LIS, depending on 
technical requirements. We decline to include this certification as a 
required element because it is not clear that a HELD certification is 
necessary in every situation for a 911 Authority to access a LIS. ATIS 
indicates that it is working to develop technical documentation to 
include ``readiness checklists and guidelines for PSAPs/911 Authorities 
to request NG911 connectivity,'' and we encourage such work to the 
extent that it serves to provide technical guidance to 911 Authorities 
in achieving readiness to initiate a Phase 1 or 2 request.\245\ We also 
encourage OSPs, 911 service providers, and 911 Authorities to 
collaborate to develop methods, processes, and best practices to 
facilitate responses to 911 Authorities' valid requests, as suggested 
by APCO.\246\
---------------------------------------------------------------------------

    \244\ Id. at 7-9, Exh. B; Verizon NG911 Notice Comments at 6; 
Alaska Telecom Assoc. NG911 Notice Comments at 11. See IETF, HTTP-
Enabled Location Delivery (HELD) (Sept. 2010), https://datatracker.ietf.org/doc/rfc5985/ (RFC 5985) (describing HELD as an 
application-layer protocol that may be ``used for retrieving 
location information from a server within an access network'').
    \245\ Alliance for Telecommunications Industry Solutions (ATIS) 
NG911 Notice Comments at 6-7 (rec. Aug. 9, 2023) (ATIS NG911 Notice 
Comments).
    \246\ Letter from Jeffrey S. Cohen, Chief Counsel, Mark. S. 
Reddish, Senior Counsel, and Alison P. Venable, Government Relations 
Counsel, APCO, to Marlene Dortch, Secretary, FCC, PS Docket No. 21-
479, at 2 (filed Apr. 18, 2024) (APCO Apr. 18, 2024 Ex Parte).
---------------------------------------------------------------------------

c. Other Readiness Considerations
    Designation of NG911 Delivery Points. As part of a Phase 1 or 2 
valid request, the requesting 911 Authority includes the designated 
location of NG911 Delivery Point(s) relevant to Phase 1 or 2. We agree 
with Verizon that the establishment of NG911 Delivery Points is a 
threshold capability for technical readiness; however, as discussed in 
this document and section III.D.1 of the Order, we disagree that such a 
designation should be the result of a ``mutual agreement regarding the 
location and terms and conditions governing'' the NG911 Delivery 
Points. The inclusion of the location of NG911 Delivery Point(s) as 
part of a Phase 1 and 2 valid request will facilitate OSPs'

[[Page 78089]]

compliance with Phase 1 and 2 by the relevant deadline.
    Readiness established at time of request. A Phase 1 or 2 valid 
request indicates that the 911 Authority is ready at the time the 
request is made to receive 911 traffic from an OSP in Phase 1 or 2 
format. Several commenters support this approach. We agree with T-
Mobile that a valid request also includes the readiness of any vendors 
used by the 911 Authority to implement NG911 services. We require 
readiness at the time of the valid request in order to address concerns 
that a valid request indicating future readiness could slow the NG911 
transition. We agree with Verizon that readiness at the time of a valid 
request is an ``appropriate departure from the trigger for six-month 
deployment of wireless E911 Phase 1 and 2, which allowed a PSAP to 
certify that it would be capable within that period.'' \247\ For the 
foregoing reasons, we decline to implement Comtech's suggestion that a 
valid request ``is one in which the applicable 911 Authority certifies 
that it will be technically ready to receive 911 calls in the requested 
IP-based format.'' \248\
---------------------------------------------------------------------------

    \247\ Verizon NG911 Notice Comments at 7 (emphasis omitted).
    \248\ Comtech NG911 Notice Reply at 7 (emphasis omitted).
---------------------------------------------------------------------------

    Individual PSAP readiness not a required part of a valid request. 
Neither phase would require individual PSAPs connected to the ESInet to 
be NG911-ready. The 911 Authority is responsible for ensuring that all 
connected PSAPs can receive 911 communications via the ESInet, either 
by implementing NG911 upgrades or by translating/converting the 
communications after they have transited the ESInet via a Legacy PSAP 
Gateway. BRETSA, NASNA, and Mission Critical Partners agree with this 
approach.\249\ As such, we decline to specifically require that 911 
Authorities implement NG911 call handling equipment at the PSAP prior 
to the initiation of a valid request for either Phase 1 or 2, as 
suggested by some commenters.\250\ This will provide flexibility to 911 
Authorities in upgrading PSAPs while enabling the NG911 network to 
capture the benefits of receiving 911 traffic in either a basic SIP 
format at Phase 1 or SIP format that complies with NG911 commonly 
accepted standards at Phase 2. iCERT states that criteria for readiness 
should include ``details about any arrangements that have been entered 
into with NG911 service providers to secure equipment, interconnection 
agreements, and other service arrangements that will ensure PSAPs are 
ready to accept IP-based 911 calls.'' We disagree that 911 Authorities 
must provide such details to OSPs as a component of a valid request, as 
the 911 Authority remains responsible for the delivery of 911 calls and 
texts to PSAPs connected to the ESInet.
---------------------------------------------------------------------------

    \249\ BRETSA NG911 Notice Comments at 4 (``The fact that PSAPs 
served by the ESInet may receive calls via LPG is a distinction 
without a difference.''); NASNA NG911 Notice Reply at 4 & n.5 
(stating that PSAPs are ready to receive ``Phase III 99 calls for 
service'' ``[w]ith or without the use of legacy PSAP gateways''); 
Mission Critical Partners NG911 Notice Comments at 7-8 (``While IP 
call delivery should be deployed by ECCs/PSAPs, their readiness for 
doing so should not be a major factor in the overall level of NG911 
readiness for requiring OSPs to provide IP connectivity.'').
    \250\ ATIS NG911 Notice Comments at 6 (``[A] 911 authority 
should be required to demonstrate that PSAP call handling equipment 
in their jurisdiction is capable of accepting and processing 911 
calls that are routed via an ESInet.''); T-Mobile NG911 Notice Reply 
at 3 (quoting ATIS NG911 Notice Comments at 6); Verizon NG911 Notice 
Comments at 5 (``Capable PSAP call-handling equipment is a long-
acknowledged component of PSAP readiness, and the NG911 environment 
is no exception.'').
---------------------------------------------------------------------------

    Connectivity testing not required prior to a valid request. As 
noted above, for both Phase 1 and 2 valid requests, we require the 911 
Authority to certify that it has obtained commitments from an ESInet 
vendor, NGCS vendor, and/or call handling equipment vendor needed to 
facilitate and complete connectivity testing within the compliance 
timeframe applicable to the originating service provider. However, we 
decline to require testing as a prerequisite to a 911 Authority's valid 
request, as suggested by some commenters. In order to meet the 
readiness element to receive 911 traffic at Phase 1 or 2, we believe 
that it is highly likely that 911 Authorities would need to have 
completed at least some internal testing of their network elements to 
ensure that they are operational and functioning effectively. The 
nature and extent of this testing is likely to vary based on the 
specific NG911 vendors the 911 Authority has selected. We believe that 
our approach to require 911 Authorities to demonstrate readiness for 
connectivity testing with OSPs accomplishes our goal of facilitating 
timely OSP compliance with NG911 rules.
    We permit flexible compliance timelines, subject to mutual 
agreement of OSPs and 911 Authorities, to accommodate variability in 
the length of testing, as suggested by some commenters.\251\ We 
emphasize that our rules function as a default. In situations in which 
connectivity testing takes longer than the time allotted under our 
default NG911 rules, OSPs and 911 Authorities may wish to consider 
establishing by mutual agreement extended deployment timelines.
---------------------------------------------------------------------------

    \251\ See, e.g., CTIA NG911 Notice Reply at 2 (``Implementation 
variables and testing will be unique to each PSAP and OSP, and thus 
flexible timeframes and deadlines are necessary.''); Verizon NG911 
Notice Reply at 3 (``Flexibility will be necessary to account for 
the unforeseen challenges that NG911 vendors and OSPs can face in 
procuring, deploying and testing the network facilities and 
equipment necessary to support NG911.'').
---------------------------------------------------------------------------

d. Authorized Requesting Entities
    For purposes of the rules in this document and the Order, only 
``911 Authorities'' as defined in our rules may make a valid request to 
OSPs for compliance with the requirements of Phase 1 or 2. The 
Commission stated in the NG911 Notice that the appropriate authority to 
request IP-based service from OSPs would be ``the local or state entity 
with the authority and responsibility to designate the point(s) that 
allow emergency calls to be answered.'' \252\ The Commission also 
proposed that a valid request would be made by a local or state entity 
that certifies that it is ``specifically authorized to accept calls in 
the IP-based format requested.'' \253\ We adopt these proposals with 
minor modifications to the structure of the rule for clarity.
---------------------------------------------------------------------------

    \252\ NG911 Notice, 38 FCC Rcd at 6229, para. 50.
    \253\ Id. at 6224, para. 40.
---------------------------------------------------------------------------

    We limit valid requests to 911 Authorities, as defined in the 
Commission's NG911 rules. We recognize that the entity with sufficient 
jurisdiction and authority to request the delivery of NG911 service 
from OSPs depends on the governance structure that applies to that 911 
jurisdiction. We decline to assume that a request should come from a 
state-level entity, as suggested by Maine PUC and Colorado PUC.\254\ We 
also decline to limit authorized requests to statewide authorities or 
ESInets, as suggested by Bandwidth. In declining to limit or prioritize 
requests from statewide authorities, we acknowledge that some NG911 
networks are local or regional, rather than state-wide.\255\ In some 
instances, the appropriate jurisdictional authority may be a state 911 
administrator, and in other instances, the local or regional 911 office 
may be the appropriate requesting entity. Texas 9-1-1 Entities states, 
and we agree, that

[[Page 78090]]

``there are various potential governance and ESInet/NGCS deployment 
scenarios nationwide.'' \256\ We also agree with NENA that the ``entity 
having sufficient jurisdiction to make the request to deliver NG9-1-1 
calls depends entirely on how the local 9-1-1 service is governed, 
designed, and configured.'' We decline to require, as argued by 
Verizon, that ``to the extent a valid request is dependent on a 
vendor's actions'' certifications submitted by 911 Authorities should 
include an affidavit signed by the director or officer of the vendor 
``subject to the same affidavit standards'' as an OSP's petition 
challenging the validity of a request.'' We emphasize that 911 
Authorities are responsible for ensuring the readiness of their vendors 
prior to making a Phase 1 or Phase 2 request. We believe that the 
petition process for OSPs challenging the validity of a request is 
sufficient to guard against premature requests.
---------------------------------------------------------------------------

    \254\ Maine PUC NG911 Notice Comments at 2 (stating that ``a 
request should come from the respective state, unless the state 
indicates that there is another 911 jurisdictional authority 
designated and that additional 911 jurisdictional authority has 
coordinated with other authorities within the state''); Colorado PUC 
NG911 Notice Comments at 7 (arguing that a registry should be 
structure to assume a state-level 911 Authority will make the 
request).
    \255\ See, e.g., Livingston Parish NG911 Notice Comments at 1 
(describing how individual local parishes in Louisiana coordinate to 
contract for NG911 solutions).
    \256\ Texas 9-1-1 Entities LBR Notice Comments at 6 (rec. Feb. 
16, 2023) (Texas 9-1-1 Entities LBR Notice Comments).
---------------------------------------------------------------------------

    We decline to allow parties other than a 911 Authority to submit 
Phase 1 and 2 requests. BRETSA argues that 911 Authorities ``should 
have the discretion to appoint'' other parties, such as the NGCS 
provider, ``to negotiate, implement, and test the delivery of 9-1-1 
calls in the requested format.'' Several other commenters argue that 
NGCS providers should play a role in determining readiness to receive 
NG911 traffic.\257\ We agree with Verizon that our rules do not 
prohibit a 911 Authority and its vendor from entering into a letter of 
authorization or similar arrangement to facilitate ``technical and 
operational business-to-business discussions.'' We recognize that NGCS 
providers have an important role and encourage 911 Authorities to work 
closely with their NGCS providers in establishing readiness. However, 
consistent with prior 911 technology transitions \258\ and to minimize 
confusion, we identify a governmental entity as the appropriate entity 
to initiate a valid request.
---------------------------------------------------------------------------

    \257\ Mission Critical Partners NG911 Notice Comments at 9 
(stating that ``the deployment phase [should] be negotiated between 
the OSP and NGCS provider and approved by the 911 authority''); MSCI 
NG911 Notice Comments at 5 (stating that providers like MSCI are 
often best positioned to determine whether a particular 911 
Authority is ready to accept calls in IP format, and urging the 
Commission to encourage close collaboration''); CCA NG911 Notice 
Comments at 8-9 (arguing for collaboration between 911 Authorities 
and OSPs to communicate NG911 readiness); NENA NG911 Notice Reply at 
2 (``The timing of the formal request to originate NG9-1-1 calls 
should rest squarely with the ESInet operator.'').
    \258\ See 47 CFR 9.10(q)(10)(iii)(B).
---------------------------------------------------------------------------

e. Notification Mechanism for Valid Requests
    As part of a valid Phase 1 or Phase 2 request to an OSP, the 
requesting 911 Authority must provide notification to each OSP provider 
that includes the certifications and information required by our rules. 
In the LBR Notice and the NG911 Notice, the Commission proposed that 
911 Authorities could provide this notification either by submission to 
a Commission-provided registry or by written notification to individual 
OSPs.\259\ As discussed below, we adopt this proposal and allow 911 
Authorities to use either notification method.
---------------------------------------------------------------------------

    \259\ NG911 Notice, 38 FCC Rcd at 6224, para. 40; LBR Notice, 37 
FCC Rcd at 15202-03, para. 51.
---------------------------------------------------------------------------

    Several commenters support the proposal to establish a voluntary 
centralized registry for submission of valid requests from 911 
Authorities.\260\ A centralized registry will reduce the administrative 
burden on 911 Authorities to make individual requests to OSPs for Phase 
1 and 2. It will also reduce the administrative burden on OSPs to track 
valid requests; we disagree with RWA and CTIA that monitoring a 
centralized registry is a burdensome requirement for small, rural 
OSPs.\261\ RWA's members, as covered text providers, already monitor a 
similar registry on the Commission's website in the text-to-911 
context, and checking the NG911 registry requires only incremental 
additional resources. We agree with Maine PUC that the registry will 
provide ``clarity and predictability, as well as a similar expectation 
for all providers.'' We also agree with Mission Critical Partners that 
a voluntary registry may help resolve challenges 911 Authorities face 
in identifying all OSPs in their coverage area. Therefore, we provide 
the option of the voluntary registry as an efficient mechanism to 
submit requests to all OSPs within a 911 Authority's jurisdiction. We 
also decline to require 911 Authorities to use a direct notification 
mechanism to inform OSPs of their valid requests, as requested by CCA, 
as 911 Authorities may not be aware of all of the OSPs within their 
jurisdiction and requiring them to identify and separately notify each 
OSP is unduly burdensome and inefficient. We direct PSHSB to develop, 
implement, and maintain a centralized electronic registry for 
submission of Phase 1 and Phase 2 requests by 911 Authorities. We leave 
to the Bureau's discretion whether to consolidate the registry with 
existing Bureau registries for PSAPs and text-to-911 notifications, if 
the Bureau determines such a step to be necessary or beneficial.\262\ 
We further direct PSHSB to open a new docket and issue guidance 
regarding filing of NG911 valid requests, and to work with OSPs, 911 
Authorities, and industry organizations such as CTIA \263\ to ensure 
that all OSPs receive timely notice of valid requests.
---------------------------------------------------------------------------

    \260\ Maine PUC NG911 Notice Comments at 3; Colorado PUC NG911 
Notice Comments at 8; Michael Coonfield NG911 Notice Comments at 1 
(rec. Aug. 9, 2023) (filed on behalf of Oklahoma 9-1-1 Management 
Authority (Oklahoma 9-1-1 Management Authority NG911 Notice 
Comments); Minnesota DPS-ECN NG911 Notice Comments at 7, 8; Texas 9-
1-1 Entities LBR Notice Comments at 6 n.23; Bandwidth NG911 Notice 
Comments at 9; Intrado NG911 Notice Reply at 5; Mission Critical 
Partners NG911 Notice Comments at 7; Jon Marcy, Kevin Brown, and 
John Holloway, Defense Information Systems Agency (DISA) LBR Notice 
Comments at 2 (rec. Feb. 8, 2023); NENA NG911 Notice Reply at 3; 
NENA LBR Notice Comments at 9.
    \261\ Rural Wireless Association, Inc. (RWA) NG911 Notice 
Comments at 3 (rec. Aug 9, 2023) (RWA NG911 Notice Comments); CTIA 
July 10, 2024 Ex Parte at 5.
    \262\ FCC, 911 Master PSAP Registry (May 15, 2024), https://www.fcc.gov/general/9-1-1-master-psap-registry; FCC, PSAP Text-to-
911 Readiness and Certification Registry (Text-to-911 Registry) 
(Apr. 30, 2024), https://www.fcc.gov/general/psap-text-911-readiness-and-certification-form. Oklahoma, Minnesota DPS, Intrado, 
and AT&T support the combination of the Commission's NG911 
centralized database with other registry functions. Oklahoma 9-1-1 
Management Authority NG911 Notice Comments at 1; Minnesota DPS-ECN 
NG911 Notice Comments at 7, 8; Intrado NG911 Notice Comments at 9; 
AT&T LBR Notice Comments at 5-6 (rec. Feb. 16, 2023) (AT&T LBR 
Notice Comments); but see Verizon July 10, 2024 Ex Parte at 8 
(urging the Commission to establish a stand-alone registry 
``dedicated solely to NG911 implementation'' given material 
differences between existing Commission rules and NG911 rules, and 
governance structures specific to NG911).
    \263\ CTIA July 10, 2024 Ex Parte at 5 (committing to working 
with Bureau staff to ensure that a registry is sufficiently robust 
and reliable to ensure that OSPs have sufficient notice of 911 
Authority requests for Phase 1 or Phase 2.
---------------------------------------------------------------------------

    We do not require 911 Authorities to use the registry to notify 
OSPs of Phase 1 and Phase 2 requests. As an alternative to providing 
notice in the registry, 911 Authorities may notify OSPs of Phase 1 and 
Phase 2 requests by direct written notification. Direct notification is 
permitted at any time after the rules take effect, regardless of when 
the registry is made available.
    CTIA and ATIS argue that notification in the registry should not be 
the trigger for OSP compliance deadlines.\264\ CTIA argues that any 
deadlines imposed should be ``triggered only when OSPs and PSAPs have 
agreed that a PSAP is capable of receiving NG911-compatible traffic.'' 
Similarly, ATIS argues that 911 Authorities should ``engage directly'' 
with OSPs to ``become technically ready and capable to receive IP 
format calls in the first instance.'' We find that

[[Page 78091]]

notification of a valid request is sufficient to trigger OSP compliance 
deadlines. However, we encourage 911 Authorities and OSPs to 
communicate directly with one another both before and after valid Phase 
1 and Phase 2 requests.
---------------------------------------------------------------------------

    \264\ CTIA NG911 Notice Comments at 7; ATIS LBR Notice Comments 
at 5 (rec. Feb. 16, 2023).
---------------------------------------------------------------------------

    We decline to adopt several notification alternatives proposed by 
commenters. NENA suggests that the national ``Forest Guide,'' a 
component of NG911 architecture specified in the i3 standard, could 
serve as a centralized database for NG911 transition 
notifications.\265\ However, it is unclear whether a national Forest 
Guide is operational or could be used for the purpose suggested. We 
also decline to implement a ``push notification feature,'' as suggested 
by Intrado. We have not previously determined that such a feature is 
necessary and the Commission does not maintain the information required 
in order to implement such a feature. We therefore instead require OSPs 
to monitor the central registry, as is the case for the existing Text-
to-911 Registry.
---------------------------------------------------------------------------

    \265\ NENA NG911 Notice Comments at 11; see also NENA i3 at 285 
(describing the Forest Guide).
---------------------------------------------------------------------------

f. OSP Petitions Challenging Validity of 911 Authority Requests
    Some commenters convey concerns regarding attestations they have 
received from 911 Authorities as part of the ongoing NG911 transition; 
namely, that attestations of readiness do not translate to actual 
readiness.\266\ To address circumstances in which an OSP believes that 
a 911 Authority has submitted an invalid Phase 1 or 2 request, an OSP 
may submit a petition challenging the 911 Authority's request. The 
petition must be submitted within 60 days of receipt of the request and 
must document the basis for the OSP's assertion that the request does 
not satisfy a requirement or requirements of a Phase 1 or 2 valid 
request. This petition process is subject to procedural requirements 
set forth in 47 CFR 1.41, 1.45, and 1.47. The petition must be in the 
form of an affidavit and include specific information relating to the 
progress of NG911 implementation. In particular, the affidavit must be 
signed by a director or officer of the OSP and include the basis for 
the OSP's assertion that the 911 Authority's request does not satisfy 
one or more of the conditions for a Phase 1 or Phase 2 valid request; 
each of the specific steps that the OSP has taken to implement Phase 1 
or Phase 2 requirements; the basis for the OSP's assertion that it 
cannot make further implementation efforts until the 911 Authority 
satisfies the conditions for a Phase 1 or Phase 2 valid request; and 
the specific steps that must be completed by the OSP and, to the extent 
known, the 911 Authority or other parties before the OSP can implement 
the Phase 1 or Phase 2 requirements. All affidavits must be correct, 
and the director or officer who signs the affidavit has the duty to 
personally determine that the affidavit is correct. An OSP that 
challenges a 911 Authority's valid request must describe the steps it 
has taken toward implementing Phase 1 or Phase 2 requirements that are 
not dependent on the readiness of the 911 Authority. We anticipate that 
this requirement will deter OSPs from using the request challenge 
process as a pretext to delay implementation, while ensuring that OSPs 
are able to successfully use the challenge process when it is 
necessary.\267\ We do not adopt the suggestion by some commenters that 
a petition should automatically toll the compliance deadline triggered 
by the request.\268\ We delegate authority to PSHSB to review and 
decide petitions, including whether to pause implementation deadlines 
for the OSP that has submitted the petition, affirm the request of the 
911 Authority as valid, or take other action as necessary. If the 
Bureau upholds the 911 Authority request as valid, the OSP may be 
subject to enforcement of the original Phase 1 or Phase 2 compliance 
date. We direct PSHSB to open a new docket and issue guidance regarding 
OSP petitions challenging the validity of 911 Authority requests.
---------------------------------------------------------------------------

    \266\ T-Mobile NG911 Notice Comments at 4 (``In T-Mobile's 
experience, while many PSAPs request SIP connectivity, PSAPs are not 
always prepared to actually receive SIP calls.''); AT&T NG911 Notice 
Comments at 8 (``[I]t is not uncommon for a state or local 911 
authority to believe in good faith that it is prepared to trigger a 
technology transition, only for unforeseen readiness issues to arise 
later.'').
    \267\ See Letter from Michael Beirne, Director, Regulatory 
Affairs, CTIA to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 
21-479, 18-64 at 3 (filed July 10, 2024) (CTIA July 10, 2024 Ex 
Parte) (recommending that the Commission adopt a version of Sec.  
9.31(c)(5) that would require OSPs to describe steps taken that are 
not dependent on the 911 Authority as part of a challenge, as 
opposed to a version that would require OSPs to take all steps 
toward implementation that are not dependent on the readiness of the 
911 Authority as a prerequisite to a challenge); Verizon July 10, 
2024 Ex Parte at 2, 7 (requesting that the Commission remove a 
requirement for OSPs to take all steps toward implementation not 
dependent on the readiness of the 911 Authority as a prerequisite to 
a challenge).
    \268\ T-Mobile NG911 Notice Reply at 4; Alaska Telecom Assoc. 
NG911 Notice Comments at 4, 11; Bandwidth NG911 Notice Reply at 4 
(stating that ``if a deadline is adopted, it must include dispute 
resolution and tolling mechanisms''); CTIA NG911 Notice Comments at 
7-8; Intrado NG911 Notice Comments at 7.
---------------------------------------------------------------------------

    We anticipate that the availability of the petition process will 
deter 911 Authorities from making premature Phase 1 and Phase 2 
requests and will provide reasonable recourse for OSPs that believe 
that they have received an invalid request. A 911 Authority may file an 
opposition to the OSP's petition and the OSP may file a reply to that 
opposition in accordance with 47 CFR 1.45. A copy of the document 
(petition, opposition, or reply) must be served on the other party (911 
Authority or OSP) at the time of filing in accordance with 47 CFR 1.47. 
We decline, as suggested by Comtech, to adopt ``attestation 
requirements'' in which a 911 Authority would certify specific elements 
in response to an OSP dispute of a request. 911 Authorities already are 
required to certify their readiness when submitting a Phase 1 or 2 
request, and a requirement to submit further attestations would do 
little to resolve the dispute while entrenching parties in their 
positions. We believe that the OSP petition regarding requests, an 
option for the 911 Authority to respond, and a chance for the Bureau to 
consider such requests provide both OSPs and 911 Authorities with a 
clear pathway to resolve disputes.
3. OSP Implementation Timeframes
a. Default Timeframes
    At Phase 1, we require non-rural wireline providers, nationwide 
CMRS providers, covered text providers, and interconnected VoIP 
providers to comply with NG911 requirements within six months after 
receiving a Phase 1 valid request. We provide additional time to RLECs, 
non-nationwide CMRS providers, and internet-based TRS providers, which 
must comply with our NG911 requirements within 12 months after 
receiving a Phase 1 valid request.
    At Phase 2, we require non-rural wireline providers, nationwide 
CMRS providers, covered text providers, and interconnected VoIP 
providers to comply with our N911 requirements within six months after 
the latest of: (1) the 911 Authority's Phase 2 valid request; or (2) 
the date when the OSP is required to comply with Phase 1 requirements, 
or when it does comply with those requirements (whichever is earlier). 
Similarly, RLECs, non-nationwide CMRS providers, and internet-based TRS 
providers must comply with our NG911 requirements within 12 months 
after the latest of: (1) the 911 Authority's Phase 2 valid request; or 
(2) the date when the OSP is required to comply with Phase 1 
requirements, or when it does comply with those requirements (whichever 
is earlier).

[[Page 78092]]

    Our rules also allow 911 Authorities and OSPs to negotiate 
alternative agreements regarding the timelines for compliance with 
NG911 requirements at either Phase 1 or 2. This approach will help 
expedite the transition to NG911 while providing 911 Authorities and 
OSPs flexibility to manage the transition at the state and local level.

         Table Summarizing NG911 Compliance Timeframes for OSPs
------------------------------------------------------------------------
                                               Compliance timeframe
                Providers                -------------------------------
                                           Phase 1 \269\   Phase 2 \270\
------------------------------------------------------------------------
Non-rural Wireline Providers............               6               6
RLECs...................................              12              12
CMRS Providers (Nationwide).............               6               6
CMRS Providers (Non-nationwide).........              12              12
Covered Text Providers..................               6               6
Interconnected VoIP Providers...........               6               6
Internet-based TRS Providers............              12              12
------------------------------------------------------------------------

    Wireline and Interconnected VoIP Providers. In the NG911 Notice, 
the Commission proposed that all wireline and interconnected VoIP 
providers be required to deliver 911 calls in IP format within six 
months after a valid request or six months from the effective date of 
such requirement.\271\ Public safety commenters and NG911 vendors 
express general support for this timeline,\272\ and there is specific 
support for the proposed timeframes for interconnected VoIP providers. 
However, some commenters recommend longer compliance timeframes.\273\ 
For example, South Carolina recommends that local exchange carriers be 
given between six and twelve months to convert their technology to IP-
based transmission. NCTA similarly states that ``[a] twelve-month 
transition period should be sufficient for most providers once they 
receive notice that the 911 Authority has implemented NG911.'' Some 
wireline commenters recommend longer timeframes of between two and 
three years for RLECs, ILECs, or smaller providers.\274\ Several 
commenters indicate that the time required will be variable based on 
several factors, including the responsiveness of third-party transport 
providers, whether the NG911 implementation is standards-based, the 
availability of suppliers and installation personnel, resource 
constraint, and supply chain issues.\275\
---------------------------------------------------------------------------

    \269\ Expressed in months after Phase 1 valid request.
    \270\ Expressed in months after the latest of: (1) the 911 
Authority's Phase 2 valid request; or (2) the date when the OSP is 
required to comply with Phase 1 requirements, or when it does comply 
with those requirements (whichever is earlier).
    \271\ NG911 Notice, 38 FCC Rcd at 6226, para. 45.
    \272\ Colorado PUC NG911 Notice Comments at 8-9 (agreeing with 
six-month time frames for deployment); Maine PUC NG911 Notice 
Comments at 2; NENA NG911 Notice Comments at 9; Ad Hoc NG911 Service 
Providers Coalition NG911 Notice Comments at 13 (stating that 
``[t]he Coalition supports the six-month timeframe for OSPs to 
deliver SIP-based calls to IP-ready PSAPs''); MSCI NG911 Notice 
Reply at 6, 7 (calling six months ``sufficient''); Comtech NG911 
Notice Comments at 8 (stating that six months ``constitutes ample 
notice''). See also USTelecom NG911 Notice Comments at 5 (stating 
that six months is reasonable only if 911 Authorities must meet 
substantial technical readiness requirements, including a 
demonstration of actual capability to receive and process NG911 IP 
calls); Mission Critical Partners NG911 Notice Comments at 10 
(stating that six months is appropriate for SIP-only deployment, but 
a different timeline may be appropriate to get to full end-state 
NG911); NASNA NG911 Notice Comments at 9 (agreeing with six-month 
timeframes but recommending that the Commission adopt a phased 
approach); Letter from Frank Rainwater, Executive Director, South 
Carolina RFA, to Marlene H. Dortch, Secretary, FCC, PS Docket No. 
21-479, at 2 (filed Apr. 19, 2024).
    \273\ South Dakota Telecommunications Association NG911 Notice 
Comments at 13-14 (stating that 18 months following a request would 
be reasonable); Jonathan Cannon NG911 Notice Comments at 2-3 (rec. 
Aug. 8, 2023) (filed on behalf of Rally Networks) (Rally Networks 
NG911 Notice Comments) (stating that ``[m]odernizing a TDM based 
switch from planning to changeover can take 6-18 months depending on 
complexity''); South Carolina RFA NG911 Notice Comments at 8, 11 
(recommending a compliance timeframe of between six and twelve 
months for a local exchange carrier to convert their technology to 
IP-based transmission, and that less than six months may not be 
enough time for a local exchange carrier to upgrade, and more than 
twelve months will minimize the incentive for a local exchange 
carrier to implement network improvements); NCTA NG911 Notice Reply 
at 2 (stating that ``[a] twelve-month transition period should be 
sufficient for most providers once they receive notice that the 911 
Authority has implemented NG911''); Bandwidth NG911 Notice Reply at 
4 (stating that 12-18 months is needed to implement delivery of 
traffic in IP format because 911 Authorities and NG911 vendors lack 
standardized implementations and because of difficulties 
coordinating across multiple ESInets and complying with state 
requirements); ATIS NG911 Notice Comments at 2, 8 (stating that 18 
months should be allowed if implementation of new Legacy Network 
Gateways and support of associated location data (replacing legacy 
ALI systems) is required, and that six months is insufficient for 
implementing functional enhancements or the proposed circuit 
changes); AT&T NG911 Notice Comments at 10 (stating that 18 to 24 
months may be a more reasonable deadline for completing the 
transition); CTIA NG911 Notice Comments at 7 (recommending 18 to 24 
months from PSAP readiness to provide the time needed for OSPs and 
PSAPs to work through the various implementation issues and testing 
that will be necessary to deliver 911 calls in IP-format). Texas 9-
1-1 Entities states that the 911 Authorities in Texas are ``willing 
to agree to provide for a minimum of eighteen months advance 
notice.'' Texas 9-1-1 Entities NG911 Notice Reply at 16.
    \274\ Intrado NG911 Notice Reply at 4 (recommending that the 
Commission adopt rules that incent and accelerate RLECs and ILECs to 
retire their TDM networks over a reasonable period of time, such as 
24 months, with sufficient safeguards to avoid inadvertent impacts 
to 911 networks); Pennsylvania Telephone Association NG911 Notice 
Comments at 8 (stating that installing new switches and upgrading to 
IP format can take between nine months and three years); Alaska 
Telecom Assoc. NG911 Notice Comments at 8 (``[T]he FCC should afford 
additional time to smaller providers for any NG911 rules it may 
adopt.''); Texas 9-1-1 Entities NG911 Notice Reply at 15 (stating 
that some rural wireline carriers raise concerns that there should 
be at least 24 months to the transition from being able to use an 
ALI database); Rally Networks NG911 Notice Comments at 2-3 (stating 
that ``[m]odernizing a TDM based switch from planning to changeover 
can take 6-18 months depending on complexity''); NCTA NG911 Notice 
Reply at 2 & n.7 (stating that the Commission should consider 
whether different treatment is warranted in extremely remote areas 
where unique circumstances have impaired the ability of a provider 
to transition to IP-based network equipment); CCA NG911 Notice 
Comments at 2-3 (stating that additional time is needed for smaller 
and rural carriers to comply with new NG911 requirements).
    \275\ Alaska Telecom. Assoc. NG911 Notice Comments at 7; 
Bandwidth NG911 Notice Reply at 4; Frontier Communications Parent, 
Inc. (Frontier) NG911 Notice Reply at 6 (rec. Sept. 8, 2023) 
(Frontier NG911 Notice Reply); WTA NG911 Notice Comments at 7; 
Pennsylvania Telephone Association NG911 Notice Comments at 8 
(``RLECs will often have limited options for third-party transport 
providers, so timeframes will be dependent on other carriers' 
schedules and limitations.''); Verizon NG911 Notice Comments at 5 
(``[I]f a PSAP/NG911 provider requests and insists on a non-
standards-based NG911 solution or use of a non-standards-based IP 
format, implementation will require far more than six months given 
the need to engage in further end-to-end testing.''); Intrado NG911 
Notice Comments at 5 (stating that the lack of standardized 
implementations across 911 Authorities and vendors contributes to 
varied implementation requirements); ATIS NG911 Notice Comments at 8 
(stating that the service provider should be able to receive a 
waiver if it experiences supply chain issues); CCA NG911 Notice 
Comments at 2-3 (stating that smaller and rural carriers have 
significant resource complaints and supply chain challenges that 
lead them to need additional time and flexibility to comply with FCC 
requirements); USTelecom NG911 Notice Reply at 6 (indicating that 
implementation takes longer than six months if a 911 Authority uses 
a non-standard IP format or NG911 solution).

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

[[Page 78093]]

    We determine that six months per phase provides adequate time for 
non-RLEC wireline providers and interconnected VoIP providers to 
transition first to basic SIP at Phase 1, and second to SIP format that 
complies with NG911 commonly accepted standards at Phase 2. By 
splitting the transition into two six-month phases, we provide a longer 
total transition timeframe for wireline and interconnected VoIP 
providers than was originally proposed. We find that this approach 
balances the concerns raised by commenters that sought a longer total 
timeframe than six months with the need to ensure an expeditious 
transition, which could be complete under these rules within a year of 
the 911 Authority's Phase 1 request. The time period we implement for 
non-RLEC wireline providers and interconnected VoIP providers takes 
into account the various factors raised by commenters.
    We adopt an extended timeframe of 12 months per phase for RLECs to 
complete Phase 1 and Phase 2. As RLEC commenters note, RLECs operate in 
rural and sometimes remote areas and can face resource limitations and 
other challenges when transitioning to NG911, e.g., finding vendors 
that can perform the required work, negotiating and executing 
contracts, and upgrading networks (e.g., installation of new 
switches).\276\ Compliance with NG911 requirements at each phase may 
take longer for RLECs to complete given these factors.
---------------------------------------------------------------------------

    \276\ See, e.g., Alaska Telecom Assoc. NG911 Notice Comments at 
7-9 (stating that smaller providers should be afforded additional 
time than proposed in the NG911 Notice); CCA NG911 Notice Comments 
at 2-3 (stating that ``smaller and rural carriers have significant 
resource constraints and supply chain challenges that lead them to 
need additional time and flexibility to comply with FCC 
requirements''); Five Area Telephone NG911 Notice Comments at 7, 12, 
13, 15 (discussing cost recovery concerns and stating that need at 
least twenty-four months is needed to comply following a 911 
Authority request because OSPs must hire contractors or third 
parties or upgrade their networks); Intrado NG911 Notice Comments at 
4 (stating that, except in the case of certain ILECs/RLECs, 
interconnecting parties typically can establish IP-formatted (i.e., 
SIP) delivery relatively quickly); Rural Telephone Company 
Consortium (RTCC) NG911 Notice Comments at 11 n.25 (rec. Aug. 9, 
2023) (RTCC NG911 Notice Comments) (discussing the availability of 
middle-mile transport facilities in an area, the cost of ``cross-
connects'' for transport, and the technical capability of service 
providers); Pennsylvania Telephone Association NG911 Notice Comments 
at 8 (stating that installing new switches and upgrading to an IP 
format can take between nine months and three years); South Dakota 
Telecommunications Association NG911 Notice Comments at 12-14 
(discussing the potential need for different customer premises 
equipment and the technical feasibility of embedding location 
information in TDM-originated calls); USTelecom NG911 Notice 
Comments at 3 (discussing issues for some wireline providers to 
include location information in IP call headers); Letter from 
Derrick B. Owens, Senior Vice President of Government and Industry 
Affairs, and Gerard J. Duffy, Regulatory Counsel, WTA--Advocates for 
Rural Broadband (WTA), to Marlene H. Dortch, Secretary, FCC, PS 
Docket No. 21-479 (filed Feb. 7, 2024).
---------------------------------------------------------------------------

    CMRS Providers. In the LBR Notice, the Commission proposed that 
nationwide CMRS providers would have six months and non-nationwide CMRS 
providers would have 12 months to deliver IP-formatted calls, texts, 
and location information following the effective date of the rule or a 
valid request, whichever is later.\277\ Some commenters support the 
timelines as proposed in the LBR Notice, while other commenters support 
longer timeframes.\278\ Verizon indicates that a six-month timeline is 
feasible only if ``the PSAP has fully implemented i3 in its network 
through a NG911 provider that has deployed its service in coordination 
with Verizon.'' \279\ Non-nationwide CMRS providers requested longer 
timeframes to comply with NG911 delivery requirements.\280\ T-Mobile 
opposes the implementation of Commission deadlines for the transition 
to NG911 altogether.
---------------------------------------------------------------------------

    \277\ LBR Notice, 37 FCC Rcd at 15202, para. 50.
    \278\ AT&T LBR Notice Comments at 7 (stating that ``the 
Commission should allow 18-24 months before requiring provision of 
LBR information in IP-based format''); Verizon LBR Notice Reply at 4 
(stating that ``the NPRM's proposed strict six-month period is not 
consistent with Verizon's real-world experience'' and ``a minimum 
implementation of 18 months from a request would be reasonable 
provided that the PSAP's vendor has initiated the most critical 
hardware, software and network implementation efforts'').
    \279\ Verizon LBR Notice Comments at 6 (rec. Feb. 16, 2023).
    \280\ RWA LBR Notice Comments at 3-4 (rec. Feb. 16, 2023) 
(arguing that non-nationwide CMRS providers should have 30 months 
from a valid PSAP request); CCA NG911 Notice Comments at 2-3 
(``[S]maller and rural carriers have significant resource 
constraints and supply chain challenges that lead them to need 
additional time and flexibility to comply with FCC requirements.''); 
CCA July 12, 2024 Ex Parte at 1-2 (stating that compliance will 
require outside vendors, and that multiple delivery points may place 
``significant burdens on providers'').
---------------------------------------------------------------------------

    We determine that six months per phase provides adequate time for 
nationwide CMRS providers to transition to basic SIP in Phase 1 and to 
SIP format that complies with NG911 commonly accepted standards in 
Phase 2. By adopting a phased approach, we address concerns raised by 
commenters while balancing the needs of 911 Authorities to complete the 
NG911 transition in a timely manner. We also determine that 12 months 
per phase (for twenty-four months total) provides adequate time for 
non-nationwide CMRS providers to transition to Phase 1 and 2. This 
longer timeframe accounts for the unique challenges raised by non-
nationwide CMRS providers in their comments, while ensuring that the 
NG911 transition proceeds in a timely manner in order to provide 
crucial benefits to public safety. Longer timelines for non-nationwide 
CMRS providers, such as the 18 months per phase favored by RWA and CCA, 
would result in significant and unwarranted additional delay for users 
of these non-nationwide CMRS providers' services and for 911 
Authorities. We disagree with T-Mobile's opposition to implementation 
deadlines; the record indicates that timelines are needed to provide 
certainty for both OSPs and 911 Authorities and to expedite the 
transition to NG911.\281\
---------------------------------------------------------------------------

    \281\ See, e.g., NASNA Petition at 5.
---------------------------------------------------------------------------

    Internet-based TRS providers. The Commission proposed in the NG911 
Notice that internet-based TRS providers would be required to deliver 
911 calls in IP format within 12 months after a valid request or 12 
months from the effective date of such requirement, consistent with 
previous Commission action regarding these services.\282\ We determine 
that 12 months per phase provides adequate time for internet-based TRS 
providers to comply with NG911 requirements at Phase 1 and 2. Internet-
based TRS providers are primarily small entities and have operational 
differences that distinguish them from other types of providers,\283\ 
warranting a longer timeframe for compliance.
---------------------------------------------------------------------------

    \282\ NG911 Notice, 38 FCC Rcd at 6226, para. 45.
    \283\ See Kari's Law/RAY BAUM'S Act Order, 34 FCC Rcd at 6687-
89, paras. 208, 210, 21; 47 CFR 64.601(a)(23), (24), (51).
---------------------------------------------------------------------------

    Covered Text Providers. The Commission proposed in the LBR Notice 
that covered text providers would have six months to deliver IP-
formatted texts and location information following the effective date 
of the rule or a valid request, whichever is later.\284\ No commenter 
to either the LBR Notice or NG911 Notice addressed compliance timelines 
for covered text providers to deliver 911 texts to 911 Authorities that 
have implemented NG911. We therefore adopt the six-month transition 
timeline at each phase for covered text providers. We believe this 
timeframe to be reasonable in light of prior Commission transition 
periods for covered text providers to implement technology 
changes.\285\
---------------------------------------------------------------------------

    \284\ LBR Notice, 37 FCC Rcd at 15202, para. 50.
    \285\ T911 Second Report and Order, 29 FCC Rcd at 9871, para. 
47.
---------------------------------------------------------------------------

    Sequencing of Phase 1 and Phase 2. Under the rules for all OSPs, 
compliance with Phase 1 requirements

[[Page 78094]]

is a prerequisite for Phase 2, meaning that an OSP's transition to 
Phase 1 must be completed before the implementation period can start 
for Phase 2 for a particular requesting 911 Authority. We recognize 
that the NG911 transition is ongoing and that many OSPs have already 
achieved Phase 1 connectivity with NG911 networks.\286\ In such 
scenarios, 911 Authorities may initiate a Phase 2 request without 
having to first issue a Phase 1 request. We decline to adopt NASNA's 
recommended 18-month waiting period between valid requests at each 
phase, which we believe could unnecessarily slow the transition to 
NG911.\287\
---------------------------------------------------------------------------

    \286\ For example, T-Mobile states that it ``has deployed SIP 
connectivity for a total of 3,415 PSAPs (comprising 1,448 wireless 
PSAPs and 1,967 VoIP PSAPs), with an additional 1,178 wireless PSAPs 
that are in the process of or are planning for IP connectivity.'' T-
Mobile NG911 Notice Comments at 1.
    \287\ NASNA NG911 Notice Comments at 9 (indicating that there 
should be at least 18 months between requests to OSPs to move 
between its recommended phases).
---------------------------------------------------------------------------

    In other instances, a 911 Authority may have met the conditions for 
providing a valid request for Phase 2 as well as Phase 1, but an OSP 
may not yet have implemented either phase of the transition. In such a 
case, the 911 Authority may send the OSP valid requests for both Phase 
1 and Phase 2 simultaneously, or it may send the OSP a Phase 2 valid 
request after it has issued the Phase 1 request but before the OSP's 
deadline for complying with it. In such scenarios, the six- or twelve-
month period of time for the OSP to come into compliance with the Phase 
2 request would begin on the date of its Phase 1 compliance deadline or 
when it complies with the Phase 1 requirements, whichever is earlier, 
rather than on the earlier date when the Phase 2 request was issued. 
For example, if the 911 Authority issues both Phase 1 and Phase 2 
requests to a nationwide CMRS provider on January 2, 2026, then the 
provider's deadline for implementing the Phase 1 request would be six 
months later (on July 2, 2026), and its deadline for implementing Phase 
2 would be six months after that (on January 2, 2027). However, if the 
nationwide CMRS provider complied with its Phase 1 requirements on June 
2, 2026, then its deadline for implementing Phase 2 would be six months 
after that (on December 2, 2026). This provision should benefit both 
OSPs and 911 Authorities and could accelerate the implementation of 
Phase 2 NG911 in some circumstances. It accounts for the practical 
hurdles facing some OSPs that have not yet implemented the Phase 1 
requirements and accommodates their need to do so before they start 
implementing Phase 2. It also relieves 911 Authorities of a potentially 
burdensome procedural hurdle by making it unnecessary to issue 
separate, sequential Phase 1 and Phase 2 requests to OSPs that have not 
yet implemented Phase 1. A 911 Authority would not need to wait until 
an OSP finishes implementing the Phase 1 requirements to issue a Phase 
2 request to that OSP. Instead, the 911 Authority could issue both 
valid requests to the OSP simultaneously and establish firm milestone 
dates for the OSP to comply with both phases in sequence. As discussed 
in this document and section III.C.3.b of the Order, 911 Authorities 
and OSPs may also reach alternative agreements regarding timelines.
    CTIA and CCA suggest that there are instances in which an 
originating service provider may provide more than one type of service 
across the same network, which could potentially subject that 
originating service provider to inconsistent compliance deadlines.\288\ 
We clarify that when an originating service provider is subject to both 
six- and twelve- month timelines for different services on the same 
network as the result of a 911 Authority's valid request, the 
originating service provider may comply with its obligations under the 
later of the two deadlines. This approach ensures the full benefit of 
extended NG911 transition deadlines for specific types of OSPs where an 
OSP uses a combination of network elements in a local area.
---------------------------------------------------------------------------

    \288\ CTIA July 10, 2024 Ex Parte at 4-5 (non-nationwide CMRS 
providers may also be covered text providers); CCA July 12, 2024 Ex 
Parte at 2 (non-nationwide CMRS providers may also be covered text 
providers or interconnected VoIP providers).
---------------------------------------------------------------------------

    As an alternative to setting timelines for OSPs to complete the 
transition to NG911, AT&T and ATIS propose that we focus our rules on 
setting timelines for OSPs to take specific affirmative steps toward 
transitioning to IP delivery, such as placing circuit orders. We 
recognize that setting deadlines for individual implementation steps 
could provide additional certainty, but focusing on individual steps 
without requiring completion of all necessary steps is unlikely to 
achieve our objectives. In addition, the concerns raised by AT&T and 
ATIS are addressed by other modifications that we have made to our 
proposals from the NG911 Notice, including adopting a two-phase 
approach and lengthening the amount of time for OSPs to comply with 
NG911 obligations, ensuring 911 Authority readiness at the time of 
valid request, and providing flexibility to agree to alternative 
timelines for compliance with 911 Authorities.
    Brian Rosen, RWA, and Verizon suggest that OSPs may need a longer 
timeline to make the required transition the first time that an OSP 
connects to an ESInet or NG911 vendor. These commenters recommend 
increasing the time frame for OSPs to connect to the first ESInet and 
then retaining a six-month timeline for subsequent connections. RWA 
argues that the Commission should extend the timeline for the first 
connection to an ESInet but revert to a shorter timeline for subsequent 
valid requests. Verizon similarly indicates that the onboarding process 
for the first time it connects to an NG911 vendor can take several 
months to a year, but that lead time is not needed for the vendor's 
subsequent 911 Authority customers. We decline to establish different 
timelines for ``first-time'' transition by OSPs. Although such 
transitions may take longer as OSPs connect with ESInets and NG911 
service providers for the first time, our rules provide ample 
flexibility for OSPs and 911 Authorities to address these issues. We 
encourage 911 Authorities to collaborate with OSPs that are connecting 
to ESInets and NG911 vendors in the first instance. In addition, the 
Commission's waiver process is available to providers facing 
extraordinary circumstances.\289\
---------------------------------------------------------------------------

    \289\ See 47 CFR 1.3.
---------------------------------------------------------------------------

    Rally Networks proposes that instead of a six-month compliance 
period, the Commission should require 911 authorities to pre-notify any 
OSPs that will need technology upgrades in order to comply with the 
NG911 rules, or that we should allow RLECs to propose and negotiate 
compliance timelines with 911 Authorities after a 911 Authority 
request. With regards to the first proposal, nothing in our rules 
prevents 911 Authorities from pre-notifying OSPs, including RLECs, as 
they take steps to prepare for the transition to NG911. In addition, 
the steps that 911 Authorities take to prepare for NG911, including 
selecting contractors for their NG911 network, are typically public and 
accessible on 911 Authorities' websites. We find that these resources 
are sufficient to provide OSPs with notice of the transition and make 
it unnecessary to require pre-notification by 911 Authorities before 
transmittal of a Phase 1 or Phase 2 request. With regards to the second 
proposal, under the rules, OSPs and 911 Authorities may agree to 
alternative timelines for compliance with NG911 requirements. Nothing 
in our rules would prevent an

[[Page 78095]]

RLEC, for example, from proposing and negotiating compliance timelines 
with a 911 Authority following the 911 Authority's valid request.
    Due to unique challenges in Alaska, Alaska Telecom Association 
(Alaska Telecom. Assoc.) requests ``an implementation extension or 
exemption for non-IP networks, or portions of networks'' and ``longer 
implementation timelines as well as an opportunity for waivers of 
timing requirements.'' Alaska Telecom. Assoc. also requests that ``any 
NG911 rules should provide carriers in Alaska with a presumptive waiver 
of mandated IP-delivery deadlines, provided such a carrier can 
demonstrate that it is working in good faith with the PSAP to complete 
the request.'' \290\ We observe that NG911 implementation timelines are 
tied to the readiness of the 911 Authority, and Alaska Telecom. Assoc. 
notes that ``PSAPs in Alaska have not yet launched NG911 service.'' We 
decline to provide additional time specifically for Alaska 
telecommunications providers as part of these rules, but reiterate that 
OSPs may negotiate with 911 Authorities for separate compliance 
timelines under our rules. We also decline to provide a presumptive 
waiver of compliance deadlines for Alaska OSPs. Providers facing 
extraordinary circumstances may request relief under the Commission's 
existing waiver process.\291\
---------------------------------------------------------------------------

    \290\ Alaska Telecom Assoc. NG911 Notice Comments at 7 
(alternatively recommending an explicit mention of the option to 
request a waiver or extension).
    \291\ See 47 CFR 1.3.
---------------------------------------------------------------------------

b. Modification of Deadlines by Agreement
    We allow 911 Authorities and OSPs to mutually agree on 
implementation deadlines that are different from the default compliance 
deadlines in this document and the Order. This approach addresses 
commenter requests that we allow flexibility in our compliance 
timelines, and it is supported by AT&T,\292\ Colorado PUC,\293\ 
CTIA,\294\ Mission Critical Partners,\295\ NENA,\296\ and RWA.\297\ 
This approach is also consistent with the proposals in the NG911 Notice 
and LBR Notice to permit the modification of deadlines by 
agreement.\298\ We encourage OSPs to communicate with 911 Authorities 
if they experience situations that may warrant alternative agreements. 
We also encourage 911 Authorities and OSPs to reach an alternative 
agreement in instances in which challenges are encountered by 911 
Authorities and their vendors.\299\ If an alternative agreement is 
reached, the OSP must notify the Commission of the key terms of the 
agreement and the alternative deadline within 30 days of the execution 
of the agreement so that the Commission is aware of any changes to the 
default obligations of OSPs. We direct PSHSB to open a new docket and 
issue guidance to OSPs about notifying the Commission regarding 
alternative agreements.
---------------------------------------------------------------------------

    \292\ AT&T NG911 Notice Comments at 10 (stating that ``any rules 
should permit OSPs and 911 authorities to adopt alternative 
timetables upon mutual agreement'').
    \293\ Colorado PUC NG911 Notice Comments at 9 (recommending that 
state and local jurisdictions be allowed to provide reasonable 
extensions upon request and that this would allow for parties to 
mutually establish alternative timetables).
    \294\ CTIA NG911 Notice Comments at 7-8 (stating that tolling 
mechanisms that enable OSPs and PSAPs to collaboratively extend any 
deadlines as they work through challenges should be permitted).
    \295\ Mission Critical Partners NG911 Notice Comments at 9 
(stating that it supports the ability for parties to enter into 
agreements for other timelines).
    \296\ NENA NG911 Notice Comments at 9 (stating that the rules 
should permit a more lenient timeline if a state or local 911 
Authority determines a different timeline is appropriate).
    \297\ RWA NG911 Notice Comments at 3 (stating that it support 
the proposal for OSPs to be able to enter into agreements with local 
and state entities to establish an alternate time frame as ``a 
commonsense alternative'' to any deadline codified by the rules).
    \298\ NG911 Notice, 38 FCC Rcd at 6226-7, para. 45; LBR Notice, 
37 FCC Rcd at 15202, para. 50.
    \299\ See CTIA July 10, 2024 Ex Parte at 4, n.12 (arguing that 
``technical challenges and delays are also encountered by 911 
Authorities and their vendors'' and citing to Texas 9-1-1 Entities 
NG911 Notice Comments at 5; T-Mobile NG911 Reply at 3; AT&T NG911 
Notice Comments at 7; Verizon July 13, 2023 Ex Parte at 2).
---------------------------------------------------------------------------

    Mission Critical Partners suggests that there be a mechanism 
``whereby these agreements could be canceled and a return to the 
mandated timeline executed if needed.'' Although the rules do not 
provide for cancellation or termination of alternative agreements, 
there is nothing in the rules prohibiting such an outcome, and parties 
are free to include a cancellation or termination provision in their 
agreements as they see fit. We also clarify that, upon cancellation or 
termination of an alternative agreement, the NG911 rules and deadlines 
will apply when a valid request is in effect, in the absence of any 
alternative provision.\300\
---------------------------------------------------------------------------

    \300\ See Verizon July 10, 2024 Ex Parte at 1, 6 (seeking 
clarification of the application of NG911 rules when contract is 
terminated).
---------------------------------------------------------------------------

D. NG911 Delivery Points and Cost Responsibilities

    We adopt default rules requiring that, starting at Phase 1, OSPs 
must transmit and deliver 911 traffic to NG911 Delivery Points 
designated by 911 Authorities and must bear the financial 
responsibility for such transmission, including costs associated with 
completing any needed TDM-to-IP translation and the costs of delivering 
associated routing and location information in the requested IP-based 
format. Beyond these NG911 Delivery Points, 911 Authorities will be 
responsible for processing and transmitting such traffic to PSAPs. We 
emphasize that these are default rules that do not preclude alternative 
arrangements between 911 Authorities and OSPs at the state or local 
level. Moreover, our rules presumptively do not alter or invalidate 
existing agreements between state or local 911 Authorities and 
OSPs,\301\ but will apply in the absence of such agreements.
---------------------------------------------------------------------------

    \301\ Our rules do not address NG911-related arrangements 
previously reached by OSPs and 911 Authorities or their vendors. See 
CTIA NG911 Notice Comments at 5 (``[T]he Commission should also 
ensure that any new rules adopted in this proceeding do not 
undermine existing arrangements between wireless providers and 911 
[A]uthorities.''); Verizon NG911 Notice Reply at 3 (requesting that 
existing agreements will not be disrupted by NG911 rules). We 
realize that some NG911 agreements may include ``change in law'' or 
``change in regulation'' clauses, which call for changes to an 
agreement's terms in the event the subject matter of the agreement 
is affected by newly-enacted laws or regulations. We take no 
position on the extent to which the NG911 rules should trigger such 
clauses. The RLEC Coalition asks us to clarify that 911 Authorities' 
agreements with ESInet providers may not be altered by our rules 
regardless of ``change of law'' provisions, but we decline. Letter 
from Brian Ford, Vice President-Federal Regulatory, NTCA (filed on 
behalf of NTCA and the RLEC Parties (RLEC Coalition)), to Marlene H. 
Dortch, Secretary, FCC, PS Docket No. 21-479, at 8 (filed July 5, 
2024) (RLEC Coalition July 5, 2024 Ex Parte). The rules in no way 
limit 911 Authorities' power to modify terms or agreements with 
ESInet providers or OSPs, nor do we presume to evaluate an 
unspecified number of existing contracts with varying terms and 
state law requirements that are not before us.
---------------------------------------------------------------------------

    The NG911 traffic delivery and cost responsibility requirements in 
this document and the Order are essentially the same as those proposed 
in the NG911 Notice, subject to a few modifications in response to the 
record.\302\ Specifically, as discussed below, OSPs will be obligated 
to deliver 911 traffic only to NG911 Delivery Points located in the 911 
Authority's state or territory; in providing for such delivery, OSPs 
retain the right to decide which transmission routes to use and which 
transport, aggregation, and other services to obtain from third 
parties, if any. Finally, we clarify that OSPs who use the services of 
third parties will continue to remain ultimately

[[Page 78096]]

responsible for any acts of their agents that violate the Commission's 
911 rules.
---------------------------------------------------------------------------

    \302\ See NG911 Notice, 38 FCC Rcd at 6218-24, paras. 27-39.
---------------------------------------------------------------------------

    We adopt these requirements in light of clear record evidence that 
the transition to NG911 nationwide is being delayed by uncertainty and 
disagreements between OSPs and 911 Authorities over the basic terms on 
which NG911 service is to be provided.\303\ Many of these disagreements 
concern the location of delivery points for 911 traffic and the 
allocation of cost responsibilities in the NG911 environment.\304\ We 
find that the default rules in this document and the Order will help 
resolve these disputes by eliminating key points of disagreement and 
facilitating discussions between OSPs and 911 Authorities concerning 
the issues that they need to coordinate. As a result, we expect these 
rules to accelerate the rollout of IP-based NG911 service to 911 
callers nationwide.
---------------------------------------------------------------------------

    \303\ The Colorado PUC, for example, reports that ``obtaining 
cooperation and compliance from OSPs'' is a ``common hurdle that all 
states must face prior to full implementation of NG911.'' Colorado 
PUC NG911 Notice Comments at 2; see also, e.g., Mission Critical 
Partners NG911 Notice Comments at 12; iCERT Nov. 2, 2023 Ex Parte at 
2; Intrado NG911 Notice Comments at 1; Comtech NG911 Notice Comments 
at 7; South Carolina RFA NG911 Notice Comments at 8; Comtech Nov. 6, 
2023 Ex Parte at Attach. at 5; Livingston Parish NG911 Notice 
Comments at 1; Brian Rosen NG911 Notice Comments at 7; Comtech NG911 
Public Notice Comments at 7; Travis Jensen NG911 Public Notice 
Comments at 1 (rec. Jan. 21, 2022) (filed on behalf of Arizona 
Department of Administration 9-1-1 Program Office (Arizona Dept. of 
Administration)); Pennsylvania Emergency Mgmt. Agency NG911 Public 
Notice Comments at 4-5.
    \304\ See, e.g., Comtech NG911 Notice Comments at 7 (``Comtech 
supports FCC adoption of the Proposed NG911 Rules as disputes 
relating to [point of interconnection] locations and cost 
demarcations are a major source of OSP disputes and delays.'' 
(emphasis omitted)); South Carolina RFA NG911 Notice Comments at 16 
(describing two and a half years of ongoing negotiations).
---------------------------------------------------------------------------

1. Originating Service Providers' Default Responsibility for 
Transmitting and Delivering 911 Traffic to NG911 Delivery Points 
Designated by 911 Authorities
    Consistent with the proposal in the NG911 Notice, our default rule 
establishes that 911 Authorities may designate the locations of the 
NG911 Delivery Points where OSPs will be required to transmit and hand 
off NG911 traffic starting at Phase 1.\305\ Many commenting parties, 
including OSP representatives as well as members of the public safety 
community, support the default delivery rule proposed in the NG911 
Notice.\306\ However, a number of parties, including a coalition of 
RLECs and organizations representing RLECs led by NTCA (collectively, 
RLEC Coalition), suggest modifications to the proposed rule or argue 
for alternative approaches.\307\ Based on the record, we adopt several 
of the requested modifications to the proposed default rule and decline 
to adopt others, as discussed below.
---------------------------------------------------------------------------

    \305\ NG911 Notice, 38 FCC Rcd at 6218-9, para. 28.
    \306\ See, e.g., BRETSA NG911 Notice Reply at 6 (``The 
governmental entity with authority over 9-1-1 service in the state, 
should set the parameters for acceptable POIs with the ESInet, which 
will constitute the demarcation point between OSP and ESInet/NGCS 
provider responsibility for routing and delivery of 9-1-1 calls.'' 
(emphasis omitted)); NCTA NG911 Notice Reply at 1-2; NENA NG911 
Notice Comments at 7-8; South Carolina RFA NG911 Notice Comments at 
8; Brian Rosen NG911 Notice Comments at 7; AT&T NG911 Notice 
Comments at 6-7; Mission Critical Partners NG911 Notice Comments at 
4; Nebraska PSC NG911 Notice Comments at 2; Oklahoma 9-1-1 
Management Authority NG911 Notice Comments at 1 (rec. Aug. 8, 2023).
    \307\ See, e.g., Five Area Telephone NG911 Notice Comments at 8-
9; Home Telephone NG911 Notice Comments at 16-18; Letter from Brian 
Ford, Vice President-Federal Regulatory, NTCA (filed on behalf of 
the RLEC Coalition)), to Marlene H. Dortch, Secretary, FCC, PS 
Docket No. 21-479, at 7 (filed Mar. 6, 2024) (RLEC Coalition Mar. 6, 
2024 Ex Parte); South Carolina RLECs NG911 Notice Comments at 14-16; 
South Dakota Telecommunications Association NG911 Notice Comments at 
10-12.
---------------------------------------------------------------------------

    Home State NG911 Delivery Points. First, we modify the proposed 
default rule to require OSPs to transmit and deliver 911 traffic to 
NG911 Delivery Points designated by a 911 Authority only if those 
points are located within the same state or territory as the PSAPs 
connected to the 911 Authority's ESInet.\308\ This addresses the 
concern expressed by some RLECs that they could incur unreasonably high 
transport costs if 911 Authorities had unlimited discretion to require 
OSPs to deliver traffic to NG911 Delivery Points located anywhere in 
the country.\309\ We believe that any such costs would likely be far 
less substantial than these parties fear, both because the costs of 
transmitting calls in IP format are not primarily based on the distance 
the calls must travel and because OSPs could mitigate the distance-
related costs to transmit calls in TDM format by converting calls into 
IP format prior to sending them over any long-distance transmission 
paths.\310\ OSPs could also mitigate their costs by originating calls 
in IP format before transmitting them anywhere, entering into cost-
sharing arrangements, or using other means.\311\ Nonetheless, requiring 
OSPs to deliver 911 traffic only to designated NG911 Delivery Points 
within 911 Authorities' home states or territories will provide OSPs, 
particularly RLECs, with greater certainty regarding potential costs. 
This requirement is unlikely to increase costs for 911 Authorities 
given that the cost of transmitting IP traffic to a potentially distant 
point in a different state or territory is not appreciably greater than 
the cost of transmitting such traffic over a shorter distance to 
locations within the same state or territory.
---------------------------------------------------------------------------

    \308\ NG911 Delivery Points designated by a local, regional, or 
Tribal 911 Authority will satisfy this criterion even if they are 
located outside the boundaries of the 911 Authority's local, 
regional, or Tribal area, so long as they are located in the same 
state. NG911 Delivery Points designated by a territorial 
government's 911 Authority must be located within the same territory 
to qualify.
    \309\ See, e.g., Five Area Telephone NG911 Notice Comments at 8-
9 (requesting in-state limitation to limit OSP costs); South Dakota 
Telecommunications Association NG911 Notice Comments at 10-12. The 
RLEC Coalition acknowledges that the home state requirement ``may 
very well ameliorate but not eliminate the cost onsets for an RLEC 
to either establish facilities or procure transport service beyond 
its boundary.'' RLEC Coalition July 5, 2024 Ex Parte at 5 n.18.
    \310\ See, e.g., Letter from Sarah N. Galioto, Director of 
Regulatory, and Cheng-yi Liu, Senior Regulatory Counsel, MSCI, to 
Marlene H. Dortch, Secretary, FCC, PS Docket No. 21-479, at 1-3 
(filed May 28, 2024) (MSCI May 28, 2024 Ex Parte) (demonstrating the 
cost savings available to OSPs that choose to transport traffic in 
IP format).
    \311\ See, e.g., Letter from Lauren Kravetz, Vice President, 
Government Affairs, Intrado, to Marlene H. Dortch, Secretary, FCC, 
PS Docket No. 21-479, at 2 (filed Jan. 30, 2024) (stating that ``the 
POI cost/distance issue raised by several commenters in the docket 
will no longer apply because IP circuits are priced based on 
capacity/bandwidth versus Time Division Multiplexing (TDM) circuits, 
which are priced based on distance/capacity'').
---------------------------------------------------------------------------

    This home-state NG911 Delivery Point qualification also addresses 
concerns that RLECs could face increased risk of liability if they were 
required to transport 911 calls to locations in out-of-state 
jurisdictions. As discussed in more detail below, we believe that the 
obligation to transmit and deliver 911 calls to NG911 Delivery Points 
will have little, if any, impact on RLECs' exposure to liability under 
state tort law. Nonetheless, the home-state qualification may make it 
easier for RLECs to anticipate and manage those risks without having to 
evaluate differing tort law standards in multiple states. The home-
state qualification also should address RLECs' concerns that an 
obligation to deliver calls out-of-state would compel them to retain 
third-party long distance transmission vendors and render them 
potentially liable for 911 rule violations committed by these vendors. 
The home-state qualification will reduce the need for RLECs to retain 
third-party vendors and make it easier for them to monitor the 
performance of any third-party vendors they do retain.
    Finally, we believe it is reasonable to expect 911 Authorities to 
locate NG911 Delivery Points within the states or territories where 
they are responsible for the provision of 911 services. By definition, 
911 Authorities are state, local, regional, territorial, or Tribal

[[Page 78097]]

government entities that typically are responsible for implementing 
NG911 systems that serve PSAPs within an individual state, a local 
jurisdiction within a state, or a territory.\312\ Moreover, the end 
users who initiate 911 communications and the PSAPs that those users 
are seeking to reach typically are located in the same state or 
territory. Therefore, from a network design and cost perspective, it 
would appear logical for a 911 Authority to provide an in-state point 
where OSPs are required to deliver NG911 traffic, particularly for 
small OSPs that operate only within that state or territory.\313\ 
However, our rules do not preclude 911 Authorities and OSPs from 
mutually agreeing on out-of-state delivery points. For example, if a 
911 Authority retains the same ESInet provider that neighboring 
authorities have retained, that 911 Authority may agree with an OSP in 
its state that the OSP's existing connections to the ESInet provider's 
network in the neighboring states are sufficient NG911 Delivery Points.
---------------------------------------------------------------------------

    \312\ In rare cases, the PSAPs overseen by a 911 Authority may 
be physically located in multiple states. In such cases, 911 
Authorities may designate NG911 Delivery Points in each state where 
its PSAPs are located.
    \313\ In rare cases, a 911 Authority may be responsible for 911 
traffic bound for PSAPs in multiple states. In such cases, the 911 
Authority could establish NG911 Delivery Points in each of the 
states that it serves in order to ensure that OSPs in each of those 
states have a home-state NG911 Delivery Point where they will be 
required to deliver 911 traffic.
---------------------------------------------------------------------------

    OSPs' Use of Aggregation Services and Other Cost-Saving Measures. 
Our default NG911 delivery rule does not prohibit OSPs from using 
aggregation services, and it allows OSPs to choose the methods of 
transport they will use to deliver 911 traffic to ESInets. Some RLEC 
commenters report that ESInet providers have tried to restrict their 
choices of network arrangements, such as by opposing their shared use 
of aggregation services.\314\ Such services 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. We 
agree that OSPs should be allowed to implement such reasonable cost-
saving measures, and we find that this approach could help avoid 
disputes between OSPs and 911 Authorities.\315\
---------------------------------------------------------------------------

    \314\ See Pennsylvania Telephone Association NG911 Notice 
Comments at 7 (``[S]ome RLECs with multiple state presence[s] prefer 
to aggregate NG911 traffic for multiple states, sharing in transport 
costs. However, some NG911 service providers are unwilling to allow 
RLEC third[-]party carrier providers to use these national POIs and 
require RLEC carrier providers to deliver NG911 traffic within the 
state.''); South Dakota Telecommunications Association NG911 Notice 
Comments at 11; Five Area Telephone NG911 Notice Comments at 7-8, 
13.
    \315\ See, e.g., AT&T NG911 Notice Comments at 7 (``Notably, 
disputes arising over transition costs might also be reduced if 
local 911 authorities use aggregation services, which would expand 
the number of POIs available to OSPs.'').
---------------------------------------------------------------------------

    We encourage OSPs, NGCS providers, ESInet providers, and 911 
Authorities to work together to enable OSPs to comply with Phase 1 and 
2 delivery obligations. We also expect OSPs to select transport options 
that are reliable, secure, and comply with industry standards for 
reliability and security. NTCA, WTA, and Home Telephone argue that 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, including third-party IP transport, dedicated SIP, and 
public internet.\316\ We decline to establish the requested rules at 
this time. We also decline to condition OSP obligations on an ESInet 
operator permitting VPN/internet connections, as suggested by Brian 
Rosen. 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.
---------------------------------------------------------------------------

    \316\ NTCA NG911 Notice Comments at 4-5 (urging the Commission 
to consider the costs of routing 911 traffic over a ``dedicated 
connection'' as opposed to ```best efforts' public internet 
connections''); WTA NG911 Notice Comments at 3-5 (urging the 
Commission to consider the benefits of dedicated SIP lines, as 
opposed to standard internet delivery); Home Telephone NG911 Notice 
Comments at 10-13 (encouraging the Commission to require ``a 
dedicated physical trunk for both front-end connections and back-end 
connections''); see also APCO Oct. 31, 2023 Ex Parte at 3 
(identifying as an open issue whether 911 traffic must be delivered 
over traditional dedicated lines or the internet).
---------------------------------------------------------------------------

    Other Restrictions on Designation of NG911 Delivery Point 
Locations. We decline to impose any restrictions on 911 Authorities' 
selection of NG911 Delivery Point locations other than the home-state 
qualification discussed above. For example, we disagree with proposals 
to relieve a LEC of its NG911 traffic delivery obligations unless the 
911 Authority establishes at least one NG911 Delivery Point within the 
LEC's local service area, or within a specified distance of such 
service area's boundary. Such a restriction, in effect, would require 
911 Authorities in states with many small RLECs to establish individual 
NG911 Delivery Points for each of those RLECs, which could be 
inefficient and unreasonably costly to implement.\317\ We decline to 
adopt a restriction that, in effect, would compel 911 Authorities to 
structure their networks in a potentially inefficient manner to 
accommodate the RLECs' historic service area boundaries, rather than in 
a more efficient and cost-effective manner to ensure the reliable 
delivery of public safety emergency services.\318\
---------------------------------------------------------------------------

    \317\ See Colorado PUC NG911 Notice Comments at 6 (``Requiring 
ESInet design to include potentially dozens of additional points of 
interface for local wireline providers is simply unreasonable and 
would greatly add to the costs of implementing and maintaining an 
ESInet.'').
    \318\ We also are adopting other measures to address the RLECs' 
cost concerns, such as permitting OSPs to continue to originate 
calls in TDM and convert such calls to SIP format that complies with 
commonly accepted standards. As discussed above, such transitional 
architectures are permitted under commonly accepted standards. See, 
e.g., NENA i3 at 3 (``[T]he scope [of i3] includes gateways for 
legacy wireline and wireless originating networks (the Legacy 
Network Gateway) used by originating networks that cannot yet create 
call signaling matching the interfaces described in this document 
for the ESInet/NGCS.''); TFOPA Final Report at 112-13, 116-17. In 
addition, we enable RLECs to minimize their costs by protecting 
their flexibility to select the vendors and routes for transmitting 
traffic to NG911 Delivery Points.
---------------------------------------------------------------------------

    For similar reasons, we reject proposals to restrict the number of 
NG911 Delivery Points a 911 Authority may designate. While some 
commenters advocate limiting delivery points to two per OSP, a limited 
number per state, or two per Local Access and Transport Area 
(LATA),\319\ we see no reason to limit the flexibility of 911 
Authorities to determine the number of delivery points available to 
OSPs. Increasing the number of delivery points can contribute to the 
resiliency of NG911 networks by providing more options for routing 
calls to ESInets, while limits on the number of delivery points may 
create network vulnerabilities or needlessly drive up costs. Moreover, 
some states have chosen to implement multiple regional ESInets, and it 
would be reasonable for them to designate a greater number of NG911 
Delivery Points than states that have implemented a single statewide 
ESInet.\320\
---------------------------------------------------------------------------

    \319\ See, e.g., Five Area Telephone NG911 Notice Comments at 8-
9, 15; South Dakota Telecommunications Association NG911 Notice 
Comments at 8-9; Brian Rosen NG911 Notice Comments at 7; Verizon 
NG911 Notice Comments at 3; Mission Critical Partners NG911 Notice 
Comments at 5; Letter from John Kuykendall, JSI Regulatory Advisor 
on behalf of the South Carolina RLECs, to Marlene H. Dortch, 
Secretary, FCC, PS Docket No. 21-479, at 2 (filed Oct. 12, 2023).
    \320\ See, e.g., South Carolina RLECs NG911 Notice Comments at 7 
(reporting that South Carolina has selected a primary, statewide 
ESInet service provider but that some PSAPs will connect to local 
ESInets or NG911 service solutions).
---------------------------------------------------------------------------

    We also reject proposals to require 911 Authorities to designate 
NG911 Delivery Points that are ``reasonable'' or not ``excessive'' or 
to require 911 Authorities to negotiate with OSPs ``in good faith'' 
over the locations of

[[Page 78098]]

interconnection points.\321\ While we expect 911 Authorities to act 
reasonably, codifying such conditions in the rules is unnecessary and 
likely to lead to protracted negotiations that enable OSPs to delay the 
NG911 transition by refusing to deliver 911 traffic to states' and 
localities' NG911 networks in a manner that facilitates efficient 
network design and deployment. The rule will reduce uncertainty, assist 
with resolving deadlocks in negotiations, and expedite the nationwide 
transition to NG911.\322\
---------------------------------------------------------------------------

    \321\ See, e.g., Verizon NG911 Notice Comments at 2-4; T-Mobile 
NG911 Notice Comments at 2-3; CCA NG911 Notice Comments at 5 
(warning against ``excessive points of delivery''); CTIA NG911 
Notice Reply at 8; iCERT NG911 Notice Comments at 8; South Dakota 
Telecommunications Association NG911 Notice Comments at 9-10 
(suggesting duty to negotiate); NCTA NG911 Notice Comments at 3; 
South Carolina RLECs NG911 Notice Reply at 9-10; USTelecom NG911 
Notice Comments at 5 (suggesting reasonableness requirement); Alaska 
9-1-1 Advisory Board NG911 Notice Reply at 3 (rec. Sept. 7, 2023); 
ATIS NG911 Notice Comments at 1, 3. Public safety commenters 
strongly disagree, arguing that unreasonable limitations on the 
selection of NG911 Delivery Points could interfere with 911 
Authorities' autonomy to plan and design their NG911 infrastructures 
in a way that meets their individualized needs. See, e.g., South 
Carolina RFA NG911 Notice Comments at 9; NENA NG911 Notice Comments 
at 8; Texas 9-1-1 Entities NG911 Notice Comments at 12; MSCI NG911 
Notice Comments at 5; Ad Hoc NG911 Service Providers Coalition NG911 
Notice Comments at 12-13.
    \322\ We decline to adopt BRETSA's suggestion to require 
national and regional OSPs to establish separate call paths to the 
data centers operated by providers of NGCS in order to provide 
additional call-path diversity. See BRETSA NG911 Notice Comments at 
3. This proposal is beyond the scope of the NG911 Notice. It also 
conflicts with our decision that NG911 Delivery Points should be 
located within the same state where a 911 Authority is located; 
NG911 service providers typically operate only a few data centers in 
disparate locations across the country, meaning that an OSP 
potentially would be required to transmit 911 traffic hundreds or 
thousands of miles to reach the nearest data center serving the 
relevant 911 Authority. Id. (noting the limited number of data 
center locations). Nonetheless, nothing in our rules would prevent 
national and regional OSPs from voluntarily establishing 
connectivity to NGCS core data centers or from negotiating with 911 
Authorities to establish such alternative NG911 Delivery Points, and 
we encourage such steps if doing so would improve 911 resiliency.
---------------------------------------------------------------------------

    Finally, we do not adopt a modification requested by one commenter 
that 911 Authorities be required to provide certain equipment at the 
NG911 Delivery Point or to comply with the hardware specifications of 
OSPs or their transport vendors. The record lacks evidence that 
disagreements over connection hardware have interfered with NG911 
adoption, and we expect that OSPs and 911 Authorities will continue to 
be able to coordinate such logistical details on their own without 
regulatory intervention. We also are concerned that any default rule 
concerning hardware might interfere with 911 Authorities' network 
architecture plans or impose unwarranted burdens on 911 Authorities if 
we allowed OSPs to dictate these decisions in all circumstances. While 
we do not impose any specific hardware requirements, we note that our 
default rules assign 911 Authorities the responsibility to furnish all 
NG911 Delivery Point facilities, which includes the connection hardware 
necessary to receive 911 traffic from the OSP.
2. Default Cost Responsibilities
    We adopt the default requirement proposed in the NG911 Notice and 
confirm that OSPs will be responsible for the cost of transmitting 911 
traffic from their end users to the points of interconnection 
designated by 911 Authorities (i.e., NG911 Delivery Points).\323\ 
Conversely, our default rule provides that OSPs are not responsible for 
the cost of transmitting calls from NG911 Delivery Points to PSAPs or 
for any reformatting or call translation within the NG911 network 
beyond the point where the OSP has handed off the call.\324\ To 
maintain this allocation, OSPs may not charge 911 Authorities or their 
vendors for providing the NG911 services that our rules require OSPs to 
provide, and once OSPs hand off 911 traffic to the 911 Authorities, the 
911 Authorities and their vendors are responsible for delivering 911 
traffic to PSAPs. OSPs must also bear the cost of compatibility testing 
for connecting to and using facilities at the NG911 Delivery Points to 
ensure compliance with NG911 commonly accepted standards specified by 
911 Authorities. This clear allocation of financial responsibilities 
should resolve delays in the transition to NG911 caused by OSP 
uncertainty or unwillingness to take responsibility for the cost of 
transmitting 911 traffic originated by their own users.\325\ Most 
public safety agencies, NG911 service providers, and OSP industry 
representatives support this default cost responsibility rule as fair, 
rational, consistent with longstanding regulatory requirements and 
industry practice, and conducive to expediting the NG911 
transition.\326\
---------------------------------------------------------------------------

    \323\ NG911 Notice, 38 FCC Rcd at 6221-6224, paras. 33-39. See 
also LBR Notice, 37 FCC Rcd at 15198, para. 36 (proposing to 
``identify ESInets as an example of an end point that state or local 
911 authorities can designate for delivery of calls where location-
based routing is used'' and noting that this would not modify CMRS 
providers' existing obligations to transmit 911 calls to delivery 
points designated by 911 authorities, potentially including legacy 
selective routers); King County Order on Reconsideration, 17 FCC Rcd 
at 14789, 14792-93, paras. 1, 8-10 (establishing that CMRS providers 
are responsible for cost of transmitting and delivering calls to 
selective routers).
    \324\ In addition, as discussed in greater detail below, OSPs 
also are responsible for the cost of the hardware and software 
components needed to transform TDM transmissions into the 
appropriate IP-based format (if necessary), to retrieve location 
information, and to route traffic to the appropriate PSAPs. At Phase 
1, these components will typically include LNG facilities, ANI/ALI 
databases, and selective routers; at Phase 2, these components will 
include NG911 location information-related systems and 
functionalities. At both phases, however, 911 Authorities, their 
ESInet vendors, and/or PSAPs will be responsible for deploying, 
maintaining, or upgrading the NG911 Delivery Point facilities, the 
transmission of 911 traffic from NG911 Delivery Points to the 
appropriate PSAPs, PSAP customer premises equipment, and all other 
NG911 components or functionalities at and beyond the NG911 Delivery 
Points. Accordingly, OSPs will not be responsible for the costs 
associated with the latter set of functions unless the parties agree 
to alternative arrangements.
    \325\ See NG911 Notice, 38 FCC Rcd at 6221, para. 33 n.118; AT&T 
NG911 Notice Comments at 7 (``Disputes over the delivery and/or 
demarcation point and cost allocation have led to delays in NG911 
implementation, as the NPRM indicates.'').
    \326\ See, e.g., NCTA NG911 Notice Reply at 2-3 (``[U]sing the 
911 Authority's chosen physical point of demarcation as the 
demarcation point for purposes of assessing financial responsibility 
is wholly rational and consistent with industry practice.''); NASNA 
NG911 Notice Reply at 4; APCO NG911 Notice Comments at 6; Nebraska 
PSC NG911 Notice Comments at 2; iCERT NG911 Notice Comments at 7; 
Comtech NG911 Notice Reply at 8-9; Letter from Wesley K. Wright, 
Counsel on behalf of Inteliquent, to Marlene H. Dortch, Secretary, 
FCC, PS Docket No. 21-479, at 1 (filed Oct. 10, 2023); CEA NG911 
Notice Comments at 7-8; Mission Critical Partners NG911 Notice 
Comments at 4; Livingston Parish NG911 Notice Comments 2; AT&T NG911 
Notice Comments at 6-7 (agreeing ``with cost obligations for OSPs 
extending to the designated demarcation point'' and noting that this 
approach is ``consistent with standing precedent in the wireless 
context established in the King County Letter'' and ``consistent 
with how AT&T has responded (in its OSP capacity) to requests from 
PSAPs to date''); Maine PUC NG911 Notice Comments at 2-3; Colorado 
PUC NG911 Notice Comments at 6-7.
---------------------------------------------------------------------------

    The NG911 cost responsibility default rule is analogous to the cost 
requirement the Commission adopted over two decades ago during the 
implementation of wireless E911. In its 2002 King County Order on 
Reconsideration, the Commission established a default requirement that 
CMRS providers bear the costs associated with transmitting 911 calls 
from their end users to the points where they hand off such calls to 
the selective routers used to transmit those calls to the appropriate 
PSAPs.\327\

[[Page 78099]]

Like those E911 requirements, the NG911 default rule reasonably holds 
OSPs responsible for the costs of complying with their own 911 service 
obligations.\328\ By continuing to adhere to our historical approach to 
E911 cost responsibility, we ensure that the NG911 transition will 
proceed on the same core principles that have defined prior iterations 
of 911 service. We provide continuity to the entities whose customers 
originate more than 80% of 911 calls--the CMRS providers that have been 
operating under the comparable E911 cost allocation rule for more than 
20 years.
---------------------------------------------------------------------------

    \327\ King County Order on Reconsideration, 17 FCC Rcd at 14789, 
14792-93, paras. 1, 8-10. CMRS providers are obligated to provide 
911 service to their subscribers and to transmit their subscribers' 
911 calls, together with information regarding subscribers' 
location, to the appropriate PSAP, statewide default answering 
point, or local emergency authority where such emergency calls can 
be answered. 47 CFR 9.10(b). The rules identify selective routers as 
the component of the networks that route E911 calls with location 
information to PSAPs or other locations where emergency calls can be 
answered. See 47 CFR 9.3. All other OSPs are subject to the same 
obligations. See, e.g., 47 CFR 9.4 and 9.5 (all telecommunications 
carriers); id. Sec.  9.11(b)(2)(ii) (interconnected VoIP providers).
    \328\ Our adoption of NG911 default cost responsibilities 
modeled on the Commission's King County decision is consistent with 
CSRIC VI's recommendation that we revisit that ruling ``[g]iven the 
vast changes in technology since the Commission's original wireless 
demarcation decision.'' CSRIC NG911 Transition Report, sec. 5.1.5 
(``Absent the Commission updating the King County Ruling to 
accommodate NG9-1-1 IP environments, [it] exacerbates the debate of 
`who pays.' '').
---------------------------------------------------------------------------

    Adopting a single default cost standard also promotes our goal to 
facilitate a technology-neutral implementation of NG911. In NG911 
networks, the distinctions between originating service provider types--
CMRS, covered text providers, wireline, interconnected VoIP, and 
internet-based TRS--disappear, as all providers will terminate 911 
traffic in an IP-based SIP format that complies with NG911 commonly 
recognized standards. This uniformity in service will reduce emergency 
response times; increase reliability and interoperability; and 
facilitate the integration of life-saving NGCS into emergency response 
systems. Adopting an ``all-platforms'' regulatory approach in our NG911 
rulemaking is not only possible, but necessary, and we therefore adopt 
the default cost rule proposed in the NG911 Notice to ensure regulatory 
parity across service platforms.\329\
---------------------------------------------------------------------------

    \329\ See, e.g., Mission Critical Partners NG911 Notice Comments 
at 5 (supporting ``equalizing a demarcation point for all OSPs''); 
NENA NG911 Notice Comments at 3 (supporting ``regulatory parity 
among originating service providers for the delivery of 9-1-1 
calls''); iCERT NG911 Notice Reply at 6; Ad Hoc NG911 Service 
Providers Coalition NG911 Notice Comments at 2.
---------------------------------------------------------------------------

    By contrast, we decline to adopt the proposal advanced by the RLEC 
Coalition, which argues that cost allocation for wireline carriers, and 
particularly for RLECs, should operate under different rules from those 
applicable to wireless providers and all other OSPs.\330\ The RLEC 
Coalition proposes that for 911 calls originated by RLEC end users, the 
911 Authorities, rather than the RLECs themselves, should be 
financially responsible for the cost of delivering their end user's 911 
traffic from the RLEC local network to the designated NG911 Delivery 
Point. The RLECs justify this proposed approach by suggesting that 911 
Authorities (or their ESInet vendors) are the RLECs' ``customers'' and 
therefore should pay for the services that the RLECs provide.\331\ This 
mischaracterizes the nature of the relationship between these entities. 
In the 911 context, the RLECs' customers are the end users who purchase 
their communications services and use them to initiate 911 calls, not 
the PSAPs that receive 911 calls or the ESInet operators that receive 
and transmit those calls on the PSAPs' behalf. The United States Court 
of Appeals for the District of Columbia Circuit (D.C. Circuit) has 
previously affirmed the Commission's E911 requirements that result in 
CMRS providers bearing financial responsibility for E911 
implementation, noting that the Commission has ``imposed upon wireless 
carriers an obligation to implement a service in the public interest,'' 
and ``[w]hether it does this directly or with the cooperation of other 
governmental safety organizations [e.g., PSAPs], it has no obligation 
to compensate carriers for their costs.'' \332\ Just as ``PSAPs are not 
the cost causers for wireless E911 implementation,'' \333\ PSAPs (and 
ESInet vendors that act on their behalf) are not the cost causers for 
wireline carriers' NG911 implementation. Indeed, rather than adopting 
the RLECs' suggestion that OSPs be treated as providing a service to 
the ESInet vendors, we could reasonably treat the OSPs as receiving a 
service from the ESInet vendors, since it is the ESInet vendors that 
enable the OSPs to satisfy their own obligation to deliver 911 traffic 
to PSAPs.\334\
---------------------------------------------------------------------------

    \330\ See, e.g., Letter from Michael R. Romano, Executive Vice 
President-Federal Regulatory, NTCA, et al. (RLEC Coalition), to 
Marlene H. Dortch, Secretary, FCC, PS Docket No. 21-479, at 1-3, 
Exh. 1 (filed Feb. 6, 2023) (RLEC Coalition Alternative Proposal).
    \331\ See, e.g., Letter from Brian Ford, Vice President-Federal 
Regulatory, NTCA, to Marlene H. Dortch, Secretary, FCC, PS Docket 
No. 21-479, Attach. at 5 (filed May 21, 2024) (``Ultimately, if a 
NG911 network provider is not a `telecommunications carrier,' then 
the only classification left is that the NG911 network provider is a 
`customer' of the RLEC.'') (emphasis omitted).
    \332\ U.S. Cellular Corp. v. FCC, 254 F.3d 78, 85 (D.C. Cir. 
2001); see id. at 83-86.
    \333\ Id. at 84.
    \334\ 47 CFR 9.4.
---------------------------------------------------------------------------

    We also reject RLECs' argument that it would be unreasonable to 
require RLECs to bear the cost of transporting 911 traffic to NG911 
Delivery Points because some ESInet operators may be entitled to 
payment for the same transport services under their contracts with 911 
Authorities. This claim is speculative and premature for several 
reasons. First, the record does not reflect the terms of the many 
contractual arrangements that have been negotiated between 911 
Authorities and their ESInet vendors to date. Even if that information 
were available, the Commission still would be required to speculate as 
to whether those agreements will remain in place in future years when 
the RLECs become responsible for providing NG911 service, which will 
not occur until after the NG911 rules become effective; 911 Authorities 
issue valid requests, and the RLECs' one-year period for compliance has 
passed. By that that time, ESInet operators' current contracts may have 
lapsed, been renegotiated, or been amended pursuant to change-in-law or 
change-in regulation provisions, among other possibilities. The RLECs' 
concern over possible unwarranted payments to ESInet providers for 
transport services also may become moot depending on where 911 
Authorities choose to locate their NG911 Delivery Points; whether 911 
Authorities agree to depart from the default NG911 rules as permitted 
by section 9.34; and whether state laws and regulations prohibit such 
payments under contracts with state agencies. We decline to adopt any 
rule to address this hypothetical future issue given the numerous 
unknown variables and because we will not intrude on states' 911 
implementation regimes; the rules are limited to the 911-related 
services and obligations of OSPs. Moreover, the possibility that some 
ESInet providers may potentially benefit from our NG911 rules is 
irrelevant to the Commission's well-established authority to enact 
public safety rules as well as the RLECs' legal obligation to comply 
with them.
    We encourage 911 Authorities and their ESInet service providers not 
to impose unreasonable fees on OSPs for connecting to or using 
facilities at NG911 Delivery Points.\335\ This is consistent with 
historic practice and the King County Order on Reconsideration, in 
which the Commission held that wireless OSPs satisfy their obligation 
to deliver E911 calls by delivering them to ILEC selective routers and 
that PSAPs are responsible for all subsequent costs, including the 
costs to maintain and upgrade the facility itself and all of its

[[Page 78100]]

components and functionalities.\336\ However, we decline to adopt a 
rule prohibiting such fees, because doing so would impose on the 
inherent regulatory and oversight powers that 911 Authorities, 
including PUCs, have over the operations of intrastate emergency 
communications networks.
---------------------------------------------------------------------------

    \335\ See IT&E NG911 Notice Comments at 3 (expressing concern 
that ``the [NG911 Notice's] broad language . . . could support a 
range of charges on [OSPs], like PTI, that are not clearly necessary 
to support the delivery of 911 communications and data to the PSAP 
demarcation point''); RLEC Coalition July 5, 2024 Ex Parte at 8.
    \336\ King County Order on Reconsideration, 17 FCC Rcd at 14789, 
14792-93, paras. 1, 8-10. The interconnection facility at issue in 
the King County Order on Reconsideration was the selective router, 
which is the equipment in legacy 911 systems that analyzes and 
distributes E911 caller information. Id. at 14790, para. 4. In NG911 
networks, this function typically will be performed by NG911 service 
providers connected to ESInets.
---------------------------------------------------------------------------

    The default cost responsibilities of OSPs and 911 Authorities will 
mirror their respective service obligations at Phase 1 and Phase 2. At 
Phase 1, our rules require OSPs to deliver 911 traffic in the IP-based 
SIP format requested by the 911 Authority, using either IP origination 
or IP translation through an LNG or other solution; obtain and deliver 
911 traffic to enable the ESInet and other NG911 network facilities to 
transmit all 911 traffic to the destination PSAP; and to transmit the 
911 traffic to NG911 Delivery Points designated by the 911 Authority, 
which we anticipate will be located at an ESInet as a general matter. 
We expect that, at Phase 1, OSPs that rely on TDM architecture will 
continue to obtain location and routing information from ALI/ANI 
databases connected to selective routers; and accordingly, OSPs will be 
responsible for the costs of hardware and software components 
associated with delivering location and routing information, as well as 
the costs of transmitting 911 traffic to NG911 Delivery Points. At 
Phase 1, 911 Authorities are responsible for furnishing the necessary 
infrastructure at the NG911 Delivery Points and for transporting NG911 
traffic from the NG911 Delivery Points to the appropriate PSAPs. Given 
these service responsibilities, OSPs will not be responsible for the 
costs associated with deploying, maintaining, or upgrading the NG911 
Delivery Point facilities, transport of 911 traffic to the appropriate 
PSAPs, PSAP customer premises equipment, or any other components or 
functionalities at or beyond the NG911 Delivery Points.
    However, if an OSP relies on IP translation functionalities that a 
911 Authority (or its vendor) provides using LNGs or other facilities 
to comply with its SIP delivery obligation at Phase 1, then the OSP may 
be required to pay for its use of such facilities. These provisions 
ensure that OSPs bear the cost of delivering traffic in the required 
IP-based SIP format. They also give OSPs appropriate incentives to 
comply with their IP delivery obligation by originating traffic in IP 
format, since translating TDM calls to IP using LNGs usually will be a 
more expensive option.
    At Phase 2, OSPs will be required to deliver all 911 traffic to 
NG911 Delivery Points in the IP-based SIP format that complies with 
commonly accepted NG911 standards identified by the 911 Authority, as 
well complying with the Phase 1 requirements. In addition, OSPs will be 
required to put into operation a LIS or functional equivalent or to 
acquire equivalent services. Accordingly, OSPs will be presumptively 
responsible for the costs associated with these functions at Phase 2 
(as well as the costs associated with their obligations continuing from 
Phase 1, including IP origination or translation and transport to the 
input to the NG911 Delivery Point). OSPs, however, will not be 
responsible for the costs of the functions that 911 Authorities will 
carry out at Phase 2, such as deploying NGCS. Moreover, as at Phase 1, 
OSPs will not be responsible for the costs of functions such as 
furnishing the necessary infrastructure at the NG911 Delivery Points 
and transmitting 911 traffic beyond the NG911 Delivery Points, which 
911 Authorities will continue to carry out at Phase 2. As discussed 
above, OSPs and 911 Authorities may negotiate and agree to alternative 
financial arrangements that differ from these default responsibilities. 
We will monitor developments in the NG911 marketplace to ensure that 
additional NG911 costs are not unreasonably shifted under this 
framework to either OSPs or 911 Authorities.\337\
---------------------------------------------------------------------------

    \337\ Verizon July 10, 2024 Ex Parte at 1, 5 (asking that the 
Commission monitor the NG911 marketplace to ensure that the new 
regulatory framework is not used to unreasonably shift costs and 
facility responsibilities to originating service providers).
---------------------------------------------------------------------------

E. Legal Authority

1. The Commission's Authority To Promulgate NG911 Rules
    The rules in this document and the Order are grounded in the 
Commission's broad authority to ``promot[e] safety of life and property 
through the use of wire and radio communications,'' including through 
use of the nation's 911 system.\338\ Congress has enacted numerous 
provisions in the Act and other 911-related statutes ``that, taken 
together, establish an overarching federal interest in ensuring the 
effectiveness of the 911 system.'' \339\ One of the main purposes of 
the Act is ``promoting safety of life and property through the use of 
wire and radio communications,'' \340\ and public safety is one of the 
Commission's most important responsibilities.\341\ This statutory 
objective informs the Commission's exercise of its other statutory 
authority pursuant to Congress's other directives. Beyond this general 
mandate, section 251(e)(3) confirms the Commission's authority and 
responsibility for designating 911 as the universal emergency telephone 
number for both wireline and wireless telephone service,\342\ 
demonstrating Congress's intent to grant the Commission broad authority 
for ``ensuring that 911 service is available throughout the country.'' 
\343\ In a

[[Page 78101]]

subsequent statute, Congress found that ``for the sake of our Nation's 
homeland security and public safety, a universal emergency telephone 
number (911) that is enhanced with the most modern and state-of-the-art 
telecommunications capabilities possible should be available to all 
citizens in all regions of the Nation.'' \344\ The D.C. Circuit has 
consistently affirmed the Commission's duty to consider public safety 
under the Act and to impose obligations to protect public safety in the 
public interest.\345\
---------------------------------------------------------------------------

    \338\ See, e.g., Revision of the Commission's Rules to Ensure 
Compatibility With Enhanced 911 Emergency Calling Systems; Amendment 
of Parts 2 and 25 to Implement the Global Mobile Personal 
Communications by Satellite (GMPCS) Memorandum of Understanding and 
Arrangements; Petition of the National Telecommunications and 
Information Administration to Amend Part 25 of the Commission's 
Rules to Establish Emissions Limits for Mobile and Portable Earth 
Stations Operating in the 1610-1660.5 MHz Band, CC Docket No. 94-
102, IB Docket No. 99-67, Report and Order (69 FR 6578 (Feb. 11, 
2004)) and Second Further Notice of Proposed Rulemaking (69 FR 6595 
(Feb. 11, 2004)), 18 FCC Rcd 25340, 25345, para. 13 (2003) (``We 
find that Congress has given the Commission broad authority to deal 
with public safety concerns in wire and radio communications.''); 
Revision of the Commission's rules to ensure compatibility with 
enhanced 911 emergency calling systems, CC Docket No. 94-102, Notice 
of Proposed Rule Making, 9 FCC Rcd 6170, 6171, para. 7 (1994), 59 FR 
54878 (Nov. 2, 1994) (``It is difficult to identify a nationwide 
wire or radio communication service more immediately associated with 
promoting safety of life and property than 911.''); H.R. Rep. 
No.110-442, at 13 (In the Net 911 Act's legislative history, 
Congress recognized that ``[s]hould changes in the marketplace or in 
technology merit, the Committee expects that the Commission will 
reexamine its regulations as necessary, consistent with the 
Commission's general authority under section 1 of the Communications 
Act of 1934 to promote the `safety of life and property' through the 
use of wire and radio communications.''); Nuvio Corp., 473 F.3d at 
312 (Kavanaugh, J., concurring) (stating that Congress has granted 
the Commission ``broad public safety and 911 authority'').
    \339\ See, e.g., 911 Fee Diversion; New and Emerging 
Technologies 911 Improvement Act of 2008, PS Docket Nos. 20-291 and 
09-14, Report and Order, 36 FCC Rcd 10804, 10810-11, para. 16 & n.41 
(2021), 86 FR 45892 (Aug. 17, 2021) (911 Fee Diversion Order).
    \340\ 47 U.S.C. 151.
    \341\ The Act also provided the Commission, inter alia, 
authority to make rules and regulations, issue orders, and prescribe 
restrictions and conditions. See, e.g., 47 U.S.C. 154(i), 303(r).
    \342\ 47 U.S.C. 251(e)(3).
    \343\ Nuvio Corp., 473 F.3d at 311 (Kavanaugh, J., concurring). 
We reject Pennsylvania Telephone Association's contention that 47 
U.S.C. 615 narrowly restricts the Commission's regulatory authority 
over the 911 system expressed in section 251(e)(3) and the other 
authorities cited herein and in the Order. See Pennsylvania 
Telephone Association July 2, 2024 Ex Parte at 2-5; 47 U.S.C. 615 
(``Nothing in this section shall be construed to authorize or 
require the Commission to impose obligations or costs on any 
person.''). Section 615 is not the basis of the Commission's 
affirmative authority for the rules in this document and the Order, 
which renders PTA's argument moot. In addition, the limiting 
language in section 615 only applies when the Commission is acting 
under that specific section; it does not purport to limit the 
Commission's powers under its other authorities. Congress enacted 
section 615 and section 251(e)(3) together in the 911 Act, the 
purpose of which was to ``facilitate the prompt deployment'' of a 
nationwide 911 network. 47 U.S.C. 615 note. While section 615 
includes limiting language that the Commission may not ``impose 
obligations or costs'' while carrying out its directive in that 
section to ``encourage each State to develop and implement 
coordinated statewide [911] deployment plans,'' Congress did not 
include such language in section 251(e)(3), which relates to the 
Commission's broader responsibility to ensure the existence of a 
seamless and ubiquitous nationwide 911 network. Congress would not 
intentionally have used section 615 to create such a consequential 
gap in the FCC's otherwise sweeping authority over 
telecommunications without clearer statutory language which is more 
capacious in scope. See, e.g., Whitman v. Am. Trucking Ass'ns, 531 
U.S. 457, 468 (2001) (``Congress . . . does not alter the 
fundamental details of a regulatory scheme in vague terms or 
ancillary provisions--it does not, one might say, hide elephants in 
mouseholes.'').
    \344\ ENHANCE 911 Act of 2004, Public Law No. 108-494, sec. 102, 
118 Stat. 3986, 3986 (2004) (codified at 47 U.S.C. 942 note); see 
Nuvio Corp., 473 F.3d at 311 (Kavanaugh, J., concurring).
    \345\ See, e.g., Nuvio Corp., 473 F.3d at 307-08 (upholding new 
E911 requirements on the basis of (among other things) the 
Commission's statutory duty to ``promot[e] safety of life and 
property through the use of wire and radio communications'' (quoting 
47 U.S.C. 151; emphasis omitted)); see also U.S. Cellular Corp., 254 
F.3d at 85 (upholding the Commission's E911 default cost allocation 
rule based, in part, on the fact that ``the Commission . . . imposed 
upon wireless carriers an obligation to implement a service in the 
public interest'').
---------------------------------------------------------------------------

    In addition to these authorities, the CVAA directly authorizes the 
Commission to promulgate the NG911 rules and reflects statutory 
criteria that circumscribe that authority. Congress enacted the CVAA to 
ensure that people with disabilities have ``equal access to emergency 
services . . . as a part of the migration to a national [IP]-enabled 
emergency network[.]'' \346\ To further that goal, Congress required 
the FCC to establish an Emergency Access Advisory Committee (EAAC) to 
survey people with disabilities and make recommendations to the 
Commission regarding ``the most effective and efficient technologies 
and methods'' by which to achieve the CVAA's purpose.\347\ Importantly, 
however, Congress also provided the Commission ``the authority to 
promulgate regulations to implement the recommendations proposed by the 
[EAAC],'' as well as the authority to promulgate ``any other 
regulations, technical standards, protocols, and procedures as are 
necessary to achieve reliable, interoperable communication that ensures 
access by individuals with disabilities to an [IP]-enabled emergency 
network, where achievable and technically feasible.'' \348\
---------------------------------------------------------------------------

    \346\ 47 U.S.C. 615c(a).
    \347\ 47 U.S.C. 615c(c).
    \348\ 47 U.S.C. 615c(g). This broad mandate rebuts the 
Pennsylvania Telephone Association's narrow reading of the CVAA as 
authorizing the Commission only to `` `establish an advisory 
committee' to address closed captioning.'' Pennsylvania Telephone 
Association July 2, 2024 Ex Parte at 5. We note that the discussion 
in this document and the Order and the record as a whole amply 
demonstrate that the regulations are ``achievable and technically 
feasible.'' 47 U.S.C. 615c(g); see also CEA NG911 Notice Comments at 
8 (supporting the NPRM and observing that the objectives of the CVAA 
``are now both achievable and technically feasible and thus should 
be mandated without further delay'').
---------------------------------------------------------------------------

    The rules we adopt comport with the CVAA's mandate because they 
advance the nationwide transition to NG911--the IP-enabled emergency 
network addressed in the CVAA--and promote equal and universal access 
to that network. Expediting the implementation of NG911 will 
significantly promote IP-based 911 access for people with disabilities, 
including through the use of internet-based TRS, which is used 
primarily by persons who are deaf, hard of hearing, deafblind, or have 
a speech disorder, as well as through the use of wireline, CMRS, 
covered text, and interconnected VoIP services with multimedia 
capabilities that cannot be supported on legacy TDM-based 
networks.\349\ Indeed, one of EAAC's recommendations to the Commission 
was to ensure an ``[a]ccessible NG9-1-1 Network'' that could ``support 
features, functions and capabilities . . . to enable individuals with 
disabilities to make multimedia NG9-1-1 emergency calls.'' \350\ 
Communications Equality Advocates supports the Commission's proposed 
regulations, noting the importance of NG911 implementation for enabling 
people with disabilities to access 911, and agreeing that ``ubiquitous 
deployment of NG911 will yield many benefits, including . . . support 
for transmission of texts, photos, videos, and data, all of which are 
essential for CEA's constituents.'' \351\
---------------------------------------------------------------------------

    \349\ See Emergency Access Advisory Committee (EAAC) Report and 
Recommendations (Dec. 6, 2011), available at http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-312161A1.doc (EAAC 
Report) at 21-25 (describing NG911 functions that can be available 
to persons with disabilities).
    \350\ EAAC Report at 19 (Recommendation P1.1).
    \351\ CEA NG911 Notice Comments at 5 (footnote omitted); see id. 
at 1-2, 5, 12.
---------------------------------------------------------------------------

    As the Commission previously observed when it used its authority 
under the CVAA shortly after its enactment to require CMRS and 
interconnected text messaging services to implement text-to-911, the 
Commission's regulatory authority under the CVAA is not limited to 
services that are used exclusively by people with disabilities.\352\ 
Nor does the CVAA ``requir[e] the FCC to ensure that any rules we adopt 
confer zero benefits on consumers outside the disability community[.]'' 
\353\ Rather, the rules adhere to and advance the CVAA's mandate 
precisely because they promote access to NG911 equally between people 
with and without disabilities on a platform-neutral basis. Moreover, in 
an emergency situation, many people with disabilities will use the same 
wireline, CMRS, covered text, and interconnected VoIP services as those 
without disabilities,\354\ or they may rely on a caretaker or other 
person using such services.\355\ The Commission's NG911 access rules 
therefore must broadly cover different types of service providers in 
order to ensure that persons with disabilities will have full and equal 
access to emergency services when they are needed.
---------------------------------------------------------------------------

    \352\ Facilitating the Deployment of Text-to-911 and Other Next 
Generation 911 Applications; Framework for Next Generation 911 
Deployment, PS Docket Nos. 11-153, 10-255, Report and Order, 28 FCC 
Rcd 7556, 7598, para. 119 (2013), 78 FR 32169 (May 29, 2013) 
(``[T]he FCC has authority under the CVAA to require action that is 
not limited to the disability community.'') (Bounce-Back Order); see 
also T911 Second Report and Order, 29 FCC Rcd at 9878, para. 71 
(affirming that ``the CVAA vests the Commission with direct 
authority to impose 911 bounce-back requirements on both CMRS 
providers and other providers of interconnected text messaging 
applications, including [over-the-top] providers'').
    \353\ T911 Second Report and Order, 29 FCC Rcd at 9878, para 71.
    \354\ EAAC Report at 19 (Recommendation P1.2); see id. at 14 
(finding that 14.7% of persons with disabilities have a ``mobility 
disability that does not affect [their] ability to use 
communications devices''). EAAC found that the respondents to its 
survey ``overwhelmingly want to be able to call PSAPs using the same 
technologies they use daily and know how to use reliably (just as 
all other citizens can).'' Id. at 19 (``Users need to use familiar 
technologies and methods, such as text/audio/video communication, 
when calling in an emergency and therefore both want and need to be 
able to access NG9-1-1 from the same devices they will use every 
day.'').
    \355\ See also Bounce-Back Order, 28 FCC Rcd at 7598, para. 120 
(``In emergency situations, persons with disabilities may need to 
access emergency services quickly and this may require them to use 
mobile devices owned by others.'').
---------------------------------------------------------------------------

    Other 911-related statutes confirm the Commission's authority and 
responsibility to establish and maintain

[[Page 78102]]

a comprehensive and effective 911 system.\356\ For example, the NET 911 
Act articulated the congressional goal ``[t]o promote and enhance 
public safety by facilitating the rapid deployment of IP-enabled 911 
and E-911 services, encourage the Nation's transition to a national IP-
enabled emergency network, and improve 911 and E-911 access to those 
with disabilities.'' \357\ The NET 911 Act also acknowledged that the 
Commission may modify its 911 regulations from time to time, including 
to address changes in the market or technology.\358\ Similarly, RAY 
BAUM'S Act further acknowledged the Commission's authority to adopt 
rules to ensure that dispatchable location information is conveyed with 
911 calls ``regardless of the technological platform used.'' \359\
---------------------------------------------------------------------------

    \356\ 911 Fee Diversion Order, 36 FCC Rcd at 10810-11, para. 16 
(stating that Federal 911-related statutes and the Act's provisions 
``establish an overarching federal interest in ensuring the 
effectiveness of the 911 system'').
    \357\ NET 911 Act, Preamble.
    \358\ See 47 U.S.C. 615a-1(a), (c)(3); see also 47 U.S.C. 
615b(10) (defining ``enhanced 9-1-1 service'' to include services 
designated by the Commission in future proceedings, as well as 
services over ``equivalent or successor networks and 
technologies'').
    \359\ RAY BAUM'S Act, Public Law 115-141, div. P, sec. 506(a), 
(c)(1), 132 Stat. 1080, 1095 (2018) (codified at 47 U.S.C. 615 
note).
---------------------------------------------------------------------------

    Together, the foregoing statutes give the Commission broad 
authority to ensure that the 911 system is available and accessible and 
functions effectively to process and deliver 911 calls and texts from 
all people in need of aid using any type of service, authorize the 
Commission to adopt the rules herein and in the Order, and represent 
the repeated endorsement by Congress of the Commission's ability to act 
in this context.\360\ The Commission has previously concluded that 
``[i]n light of these express statutory responsibilities, regulation of 
additional capabilities related to reliable 911 service, both today and 
in an NG911 environment, would be well within Commission's . . . 
statutory authority.'' \361\ The Commission also has stated that 
``[t]he Commission already has sufficient authority to regulate the 911 
and NG911 activity of, inter alia, wireline and wireless carriers, 
interconnected VoIP providers, and other IP-based service providers'' 
and that its jurisdiction to regulate 911 extends to the regulation of 
NG911 across different technologies.\362\
---------------------------------------------------------------------------

    \360\ 911 Fee Diversion Order, 36 FCC Rcd at 10810-11, para. 16.
    \361\ 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, 17529, 
para. 150 (2013), 79 FR 3123 (Jan. 17, 2014) (Improving 911 
Reliability Order).
    \362\ 2013 NG911 Framework Report, sec. 4.1.2.2 at 28-29; 911 
Governance and Accountability; Improving 911 Reliability, PS Docket 
Nos. 14-193 and 13-75, Policy Statement and Notice of Proposed 
Rulemaking, 29 FCC Rcd 14208, 14223, para. 34 (2014), 80 FR 3191 
(Jan. 22, 2015) (``[T]he Commission has the public safety imperative 
to oversee each of the increasingly complex component pieces of the 
nation's 911 infrastructure.'').
---------------------------------------------------------------------------

    The Commission sought comment on this legal framework in the NG911 
Notice, and few commenters disagreed with its analysis or its findings 
that ``Congress has given the Commission broad authority to ensure that 
the 911 system, including 911, E911, and NG911 calls and texts from all 
providers, is available and functions effectively,'' and that ``its 
jurisdiction to regulate 911 extends to the regulation of NG911 across 
different technologies.'' \363\ The NG911 rules are well within the 
scope of this authority, and we reject arguments to the contrary raised 
by commenters that advocate for a different conclusion. In addition, 
our action here to adopt NG911 rules is consistent with Congress's 
public safety and 911 policy objectives.\364\
---------------------------------------------------------------------------

    \363\ NG911 Notice, 38 FCC Rcd at 6233, para. 61. See, e.g., 
NENA NG911 Notice Comments at 15 (``NENA agrees that Congress has 
given the Commission broad authority to ensure that the 9-1-1 
system, including 9-1-1, E9-1-1, and NG9-1-1 calls and texts from 
all providers, is available and functions effectively, and that the 
FCC's jurisdiction to regulate 9-1-1 extends to the regulation of 
NG9-1-1 across different technologies.''); CEA NG911 Notice Comments 
at 4-5; WTA NG911 Notice Comments at 7.
    \364\ See, e.g., 47 U.S.C. 615 note, 942 note; NG911 Act, sec. 
6509; 911 Act, Preamble; ENHANCE 911 Act of 2004, Preamble; NET 911 
Act, Preamble.
---------------------------------------------------------------------------

2. Our Rules Are Not Contrary to Sections 251 and 252
    We reject the contention of some RLEC commenters that sections 251 
and 252 of the Act \365\ govern OSPs' transmission of 911 traffic to 
ESInets or that sections 251 and 252 preclude our adoption of these 
NG911 rules.\366\ In particular, we reject the arguments that those 
statutory provisions foreclose our default requirement that RLECs must 
transmit traffic to 911 Authorities' designated NG911 Delivery Points 
regardless of whether such delivery points are located outside of the 
RLECs' traditional local service boundaries.
---------------------------------------------------------------------------

    \365\ 47 U.S.C. 251 and 252.
    \366\ See, e.g., RLEC Coalition Alternative Proposal at 3; 
Kansas RLECs NG911 Notice Reply at 1-2 (rec. Sept. 8, 2023) (Kansas 
RLECs NG911 Notice Reply). Contra NG911 Notice, 38 FCC Rcd at 6230-
31, paras. 55-56; Colorado PUC NG911 Notice Comments at 10-11; 
BRETSA NG911 Notice Reply at 11; Verizon NG911 Notice Reply at 5; 
Comtech NG911 Notice Comments at 10; Texas 9-1-1 Entities NG911 
Notice Comments at 3-4; iCERT Nov. 2, 2023 Ex Parte, Attach. at 9; 
Pennsylvania Telephone Association July 2, 2024 Ex Parte at 6-7.
---------------------------------------------------------------------------

    These commenters misunderstand the statutory foundation for our 
actions here, and its relationship to sections 251 and 252 of the Act. 
In sections 251(a) through (d) and 252 of the Act, Congress adopted a 
range of obligations for telecommunications carriers focused on the 
objective of opening the marketplace for telecommunications services to 
increased competition.\367\ But we are not implementing those 
provisions of sections 251 and 252 in this document and the Order. 
Rather, as discussed above, we are exercising the Commission's 
distinct, broad authority over the nation's 911 system. Thus, sections 
251(a) through (d) and 252 do not govern our actions as a legal 
matter.\368\ Further, we are not exercising our statutory authority in 
the advancement of local competition, but to preserve and enhance a 
vital part of our nation's emergency response and disaster preparedness 
system, consistent with our statutory 911 authorities, and also our 
more general duties under the Act.\369\ As important as local

[[Page 78103]]

competition is, ``whenever public safety is involved, lives are at 
stake.'' \370\ Thus, we also are not persuaded that judgments Congress 
made when calibrating regulatory requirements designed to promote 
marketplace competition should limit the tools we employ under other 
statutory provisions that we find necessary to the public safety 
objectives of 911.\371\
---------------------------------------------------------------------------

    \367\ See, e.g., Implementation of the Local Competition 
Provisions in the Telecommunications Act of 1996; Interconnection 
between Local Exchange Carriers and Commercial Mobile Radio Service 
Providers, CC Docket Nos. 96-98 and 95-185, First Report and Order, 
11 FCC Rcd 15499, 15507, para. 6 (1996), 61 FR 45476 (Aug. 29, 
1996).
    \368\ We agree with Pennsylvania Telephone Association that the 
interconnection provisions in sections 251 and 252 of the Act retain 
their full force and effect, and nothing in the NG911 rules prevents 
LECs from utilizing them in circumstances where they apply. See 
Pennsylvania Telephone Association July 2, 2024 Ex Parte at 7. 
However, Pennsylvania Telephone Association argues that by adding 
the Commission's 911 authority to section 251(e) of the Act, 
Congress intended 911 regulation to be subject to the 
interconnection requirements elsewhere in sections 251 and 252. See 
Pennsylvania Telephone Association July 2, 2024 Ex Parte at 6-7. 
Section 251(e) concerns numbering and number administration in 
general, and section 251(e)(3) deals with 911 in particular. Some of 
section 251(e)'s numbering administration requirements, such as 
those providing for number portability, share the purpose of opening 
the marketplace for telecommunications service competition, and 
therefore are consistent with and may be interpreted alongside the 
other subsections in section 251 which serve the same purpose. The 
establishment of 911 as an emergency number in section 251(e)(3), 
however, relates specifically to numbering administration in section 
251(e), and not to the remainder of section 251 that addresses 
opening the telecommunications marketplace. Reinforcing our 
conclusion that the interpretation of section 251(e)(3) is not 
intended to be constrained by the market-opening provisions of 
section 251 is the fact that Congress granted the Commission other 
911-related authority--which we also rely on here--without 
incorporating it in section 251 of the Act at all. See also United 
States v. Seun Banjo Ojedokun, 16 F.4th 1091, 1103-04 (4th Cir. 
2021) (Congress amending one subsection of a statute but not another 
does not prove intent by inaction), citing United States v. Price, 
361 U.S. 304, 332 (1960).
    \369\ 47 U.S.C. 151 (The Commission was established, among other 
things, ``so as to make available, so far as possible, to all the 
people of the United States, . . . a rapid, efficient, Nation-wide, 
and world-wide wire and radio communication service . . . for the 
purpose of promoting safety of life and property through the use of 
wire and radio communications''). Given their very different 
purposes, the NG911 rules and the statutes authorizing them are not 
in pari materia (of the same matter) with sections 251(a) through 
(d) and 252 of the Act and therefore should not be construed 
together ``as if they were one law.'' See Wachovia Bank v. Schmidt, 
546 U.S. 303, 305 (2006); cf. Pennsylvania Telephone Association 
July 2, 2024 Ex Parte at 6.
    \370\ Mozilla Corp. v. FCC, 940 F.3d 1, 62 (D.C. Cir. 2019).
    \371\ We decline to address the argument advanced by some 
parties that ESInets' NG911-related offerings should be classified 
as ``information services'' or as ``telecommunications services.'' 
See, e.g., Comtech NG911 Notice Reply at 10; Kansas RLECs NG911 
Notice Reply at 2; NTCA NG911 Notice Reply at 11-12; Windstream 
NG911 Notice Reply at 3; South Carolina RLECs NG911 Notice Reply at 
6; Pennsylvania Public Utility Commission (Pennsylvania PUC) NG911 
Notice Comments at 6; MSCI NG911 Notice Reply at 1-2; Letter from 
Brian Ford, Vice President-Federal Regulatory, NTCA, to Marlene H. 
Dortch, Secretary, FCC, PS Docket No. 21-479, at 3-5 (filed June 17, 
2024); Letter from John Kuykendall, JSI Regulatory Advisor on behalf 
of the South Carolina RLECs, to Marlene H. Dortch, Secretary, FCC, 
PS Docket No. 21-479, at 4-5, 7 (filed June 20, 2024) (South 
Carolina RLECs June 20, 2024 Ex Parte). We need not discuss those 
issues because they are not necessary to our decision and would have 
broader implications beyond this proceeding. Accordingly, we make no 
finding as to the regulatory classification of ESInets or other 
NG911-related service providers.
---------------------------------------------------------------------------

    We also reject the RLECs' argument that the Commission may not 
require them to transport 911 traffic to interconnection points outside 
their state-certificated service areas or that their ``network edges'' 
should coincide with the boundaries of those service areas. The 
definitions of RLECs' state-certificated service area boundaries are 
entirely irrelevant to the Commission's authority, under the Federal 
statutory provisions discussed above, to adopt rules concerning the 
implementation of NG911, including the locations where OSPs must 
deliver 911 traffic in an IP-based format. Indeed, RLECs have long been 
responsible for ensuring that their subscribers' 911 calls reach their 
intended destinations whether or not those destinations lie within the 
RLECs' own service area boundaries.\372\ Moreover, the RLECs 
mischaracterize the term ``network edge.'' In the Commission's 
intercarrier compensation precedent, ``network edges'' need not (and 
often do not) coincide with service area boundaries. In any event, the 
default cost rule does not require RLECs to extend their physical 
networks; it only defines their financial responsibilities for the 
delivery of 911 traffic in the context of NG911 systems. As we make 
clear above, our NG911 rules do not require RLECs to extend their 
network facilities; all OSPs are free to satisfy their responsibility 
for the transmission of 911 calls to the NG911 Delivery Points 
specified by the 911 Authorities either using the OSPs' own facilities 
or using transmission services purchased from others.
---------------------------------------------------------------------------

    \372\ See, e.g., 47 CFR 9.4, 9.5; contra Pennsylvania Telephone 
Association July 2, 2024 Ex Parte at 3-4, 6-7; RLEC Coalition July 
5, 2024 Ex Parte at 6. Pennsylvania Telephone Association asserts 
that Sec.  9.4 ``merely sets forth a broad statement of the OSPs' 
obligation to `transmit' 911 calls,'' and that ``[t]he key word -
`transmit'--simply means to `forward' or `convey.''' Pennsylvania 
Telephone Association July 2, 2024 Ex Parte at 3. However, 
Sec. Sec.  9.4 and 9.5, taken together, require that carriers do 
more with 911 calls than ``transmit towards'' or ``transmit in the 
direction'' of a certain location--these sections require carriers 
to be responsible for the transmission of 911 calls to that 
location. Section 9.5 clearly discusses the requirement that 911 
calls are to be delivered and not just transmitted forward. Further, 
the 911 Implementation Order discusses carriers' responsibility to 
deliver 911 calls, as well as addresses the specific limitation 
imposed by section 3(b) of the 911 Act (47 U.S.C. 615). 16 FCC Rcd 
at 22271-78, 22282, 22284, paras. 15, 16, 18, 21, 22, 24-27, 30, 31, 
34, 46, 50.
---------------------------------------------------------------------------

3. Preservation of State Authority
    The Commission historically has shared authority over the 911 
system with state and local government. State and local governance of 
911 is exercised by various types of agencies, including public safety 
agencies and, in some instances, state public utility commissions 
(PUCs). The rules are consistent with our statutory charge to support 
911 Authorities' efforts to ensure that their public safety 
infrastructures are connected to reliable networks that enable callers 
to reach public safety agencies by dialing 911.\373\ We find that these 
NG911 rules ``str[ike] [an] appropriate balance between federal 
guidance and state and local autonomy.'' As discussed above, we rely on 
state and local 911 Authorities to determine the locations where OSPs 
must deliver 911 calls, to select the NG911 technical standards that 
OSPs must implement in Phase 2, and to decide when and how they wish to 
transition to NG911. These rules thus ensure that 911 Authorities, 
including PUCs, will retain broad decision-making authority regarding 
the configuration, timing, and cost responsibility for NG911 
implementation within their jurisdictions.\374\
---------------------------------------------------------------------------

    \373\ 47 U.S.C. 151-152, 251(e)(3), 615.
    \374\ Pennsylvania Telephone Association discusses the role of 
state legislatures and PUCs and asserts that ``[t]he proposed order 
improperly preempts state legislatures and commissions from 
exercising their authority over intrastate 911 calls and the 911 
authority as conferred by state law and the provisions of Sec. Sec.  
251 and 252.'' Pennsylvania Telephone Association July 2, 2024 Ex 
Parte at 2-5, 7-8. The RLEC Coalition also discusses state PUC 
authority and requests that ``should the Commission pursue the 
approach taken by the In-State Default Rule . . . , it should at the 
very least preserve state commissions' authority to address the 
facts and circumstances specific to their jurisdictions.'' RLEC 
Coalition July 5, 2024 Ex Parte at 2-7. These concerns are 
unfounded. We acknowledge that 911 Authorities, when considering and 
applying our default NG911 rules, may be subject to, and limited by, 
other non-Federal laws and entities, such as PUCs. Moreover, the 
Commission is not preempting the authority of either state 
legislatures or PUCs, and nothing in this document or the Order 
prohibits PUCs from addressing issues that fall under their 
jurisdiction. In addition, we decline to adopt the RLEC Coalition's 
proposed amendments to the NG911 rules. Letter from Brian Ford, Vice 
President-Federal Regulatory, NTCA (filed on behalf of the RLEC 
Coalition), to Marlene H. Dortch, Secretary, FCC, PS Docket No. 21-
479, at Attach. B (filed July 8, 2024).
---------------------------------------------------------------------------

    Nor do the rules intrude upon state PUCs' authority over the 
``charges, classifications, practices, services, facilities, or 
regulations for or in connection with intrastate communication 
service.'' \375\ The rules do not affect state PUCs' authority to 
``address the terms and conditions and potential additional cost 
recovery mechanisms that may be necessary for 911-related end-to-end 
intrastate calls.'' The 911 calls subject to these rules are 
``intrastate,'' in that the OSP customers who initiate the 911 calls 
will be located in the same state as the NG911 Delivery Points where 
OSPs deliver the calls and the PSAPs to which 911 traffic is routed. As 
a result, the rules governing Federal/state cost allocation, 
jurisdictional separations, and other matters involving rate-of-return 
regulation will treat the costs of transmitting these calls as 
jurisdictionally intrastate, and hence, subject to state PUCs' 
authority.\376\ Like all of the Commission's 911-related rules, our 
NG911 rules govern the manner in which OSPs provide 911 services and 
their responsibilities for transmitting their subscribers' 911 calls. 
But nothing in the pre-existing 911 rules or in the NG911 rules 
restricts state PUCs' authority to determine whether and how regulated 
carriers may recover the costs of compliance.\377\ The Act and

[[Page 78104]]

our regulations require all local carriers that qualify for high-cost 
universal service support (i.e., Eligible Telecommunications Carriers 
(ETCs)) to provide their subscribers with access to 911 as part of 
their basic local telecommunications service offerings,\378\ but these 
requirements do not interfere with state PUCs' authority over the rates 
for these local services.
---------------------------------------------------------------------------

    \375\ 47 U.S.C. 152(b).
    \376\ See, e.g., 47 CFR parts 32, 36, 61, 65, 69.
    \377\ This document and the Order do not preempt state PUCs' 
authority to review interconnection disputes in general under 
section 252 of the Act. See Pennsylvania Telephone Association July 
2, 2024 Ex Parte at 7. State PUCs continue to have any existing 
authority to review 911-related interconnection disputes under 
applicable state law. As noted above in this document and in the 
Order, these default rules do not preclude alternative arrangements 
between 911 Authorities and OSPs that may be subject to state PUC 
authority.
    \378\ See, e.g., 47 U.S.C. 214(e)(1) (``A common carrier 
designated as an eligible telecommunications carrier . . . shall, 
throughout the service area for which the designation is received[,] 
(A) offer the services that are supported by Federal universal 
service support mechanisms under section 254(c) of this title.''); 
47 CFR 54.101(a) (``Eligible voice telephony services must provide . 
. . access to the emergency services provided by local government or 
other public safety organizations, such as 911 and enhanced 911.'').
---------------------------------------------------------------------------

    We also reject the argument that the Commission's rules improperly 
intrude upon state authority by regulating ``the network arrangements 
associated with . . . purely intrastate 911 calls carried over 
dedicated 911 trunking.'' This argument is unfounded because our rules 
do not constrain OSPs' ability to configure their own 911 network 
arrangements, including dedicated trunking. To the contrary, our rules 
specifically preserve OSPs' right to make their own decisions about the 
routing and network facilities they use to deliver 911 traffic to NG911 
Delivery Points. Thus, an OSP could comply with any existing or new 
state requirements that govern the configuration or deployment of its 
network facilities without violating any Commission rule. There can be 
no preemption where there is no conflict or inconsistency between 
Federal and state requirements.
    Finally, some RLECs challenge the proposed NG911 rules on the 
grounds that the rules will impose substantial costs that effectively 
would compel RLECs or their regulators to raise subscribers' rates for 
intrastate services. There is no basis for this contention. As an 
initial matter, the RLECs ignore (or decline to dispute) the fact that 
they have full recourse to address such concerns at the state level, 
because state PUCs retain full authority to increase, decrease, or 
allow changes to regulated carriers' rates. More importantly, the RLECs 
have failed to establish that they will incur higher costs due to these 
rule changes or that such costs would lead to higher rates. The record 
in this proceeding gives us no basis for predicting with any confidence 
whether, and to what extent, NG911 implementation would ``affect 
monthly or annual charges to subscribers'' and whether ``there [is] a 
range or specific dollar amount that would be newly reflected on 
customers' monthly bills'' \379\ across the board. This is due in part 
to the very different ways RLECs are regulated (or deregulated) in 
various jurisdictions across the country: different state PUCs apply 
different statutes, regulations, and procedures that affect rate 
levels, and even in any individual state, various categories of 
carriers may be subject to different pricing requirements or policies. 
Moreover, our NG911 rules will affect different carriers' rates 
differently depending on the factual circumstances. For some carriers, 
any increased costs to implement one aspect of the NG911 rules may be 
offset by cost savings due to some other impact of these rules. Other 
carriers' costs may not change at all, or change only minimally, 
because they have already implemented the network upgrades or other 
changes needed to comply with 911 Authorities' valid requests and are 
already transporting 911 traffic to locations outside their service 
areas. Finally, we believe it is unlikely that any entity's rates would 
increase substantially as a result of the rules because, as discussed 
in the cost/benefit analysis below, we expect that any cost increase is 
likely to be minimal.
---------------------------------------------------------------------------

    \379\ NG911 Notice, 38 FCC Rcd at 6223, para. 38. Commenters 
that speculated on how the NG911 rules would affect RLECs' rates 
presumed that we would adopt rules as proposed in the NG911 Notice, 
but the in-state NG911 Delivery Point rule substantially reduces any 
cost increases that RLECs might incur. For example, Kansas RLECs 
state that customer billing increases for its members, assuming 
$5,000 in monthly transport costs, will range between 53 cents per 
month for its largest RLEC to $38.76 per month for its smallest 
member RLEC. Kansas RLECs NG911 Notice Comments at 4 (rec. Aug. 9, 
2023) (Kansas RLECs NG911 Notice Comments). However, these estimates 
were based on Kansas' proposal to ``rehom[e] Kansas 911 traffic to 
two of four disparate points outside of the state['s] plan,'' 
including NG911 Delivery Points in California and Texas. Id. at 2-3. 
In addition, we find that other assumptions underlying these 
commenters' estimates do not reflect foreseeable conditions in the 
real world, and we thus do not find them to be credible. See, e.g., 
South Carolina RLECs NG911 Notice Comments at 10 & n.17 (arguing 
that landline carriers cannot recover 911 costs from customers); 
Kansas RLECs NG911 Notice Comments at 3-5; Letter from Colleen R. 
Jamison, Jamison Law LLC, to Marlene H. Dortch, Secretary, FCC, PS 
Docket No. 21-479, at 2 (filed July 3, 2024) (arguing that RLECs 
cannot recover costs and that the Kansas in-state USF is currently 
capped by legislation at $30 million for all entities receiving 
support). While carriers may be prohibited from imposing separate 
per-call or per-minute charges for 911 calls, the cost of providing 
911 service is part of the total cost they incur to provide local 
exchange service to their subscribers. In addition, the rules 
provide 911 Authorities and OSPs flexibility to reach alternative 
arrangements.
---------------------------------------------------------------------------

    In any event, the Commission is under no obligation to protect 
carriers from each and every policy change that might have a collateral 
impact on subscribers' rates.\380\ As discussed below, any adverse cost 
impacts of our rules are likely to be far outweighed by their 
substantial benefits to the public. Depending on the circumstances, the 
same conclusion that we reach for the country as a whole may also apply 
to specific geographic areas served by any given RLEC. 
Telecommunications consumers in rural areas ought to receive the same 
benefits of a modernized 911 system as consumers in other parts of the 
country.
---------------------------------------------------------------------------

    \380\ See U.S. Cellular Corp. v. FCC, 254 F.3d 78, 84-85 (D.C. 
Cir. 2001) (holding that, where ``it is the Commission's Order that 
requires wireless carriers to provide E911 services in the public 
interest,'' the Commission ``has no obligation to compensate 
carriers for their costs'' and ``it is ludicrous to suggest that 
government cannot pass these costs along to regulated entities.'').
---------------------------------------------------------------------------

4. Other Challenges to the Commission's Authority Are Unsound
    Sections 201 and 202. We reject the argument that our NG911 rules 
would burden RLECs with unjust and unreasonable transport costs in 
violation of sections 201(b) and 202(a) of the Act.\381\ The provisions 
in those sections regarding unjust and unreasonable rates and terms 
\382\ pertain only to common carriers' interstate services, not 
intrastate 911 transmission services that OSPs will provide to their 
subscribers under these rules. There is thus no need for us to conduct 
a

[[Page 78105]]

supplemental ``Section 201-202 analysis'' before enacting the 
rules.\383\
---------------------------------------------------------------------------

    \381\ See, e.g., RTCC NG911 Notice Comments at 15 (``No showing 
has been made that the NPRM's default cost recovery framework that 
would assign NG911-related transport costs to the RLECs, results in 
`just and reasonable' charges as required by 47 U.S.C. 201(b).''); 
NTCA NG911 Notice Reply Comments at 14; South Carolina RLECs NG911 
Notice Comments at 8.
    \382\ 47 U.S.C. 201(b) (``All charges, practices, 
classifications, and regulations for and in connection with such 
communication service, shall be just and reasonable.''); 47 U.S.C. 
202(a) (``It shall be unlawful for any common carrier to make any 
unjust or unreasonable discrimination in charges, practices, 
classifications, regulations, facilities, or services for or in 
connection with like communication service.''); see also 47 U.S.C. 
152(b) (restricting Commission's authority over rates and terms for 
carriers' intrastate communications services). The Supreme Court has 
made clear that, while the ``unjust and unreasonable'' restrictions 
in the first proviso of section 201(b) apply only to the rates, 
terms and conditions of carriers' interstate services, not their 
intrastate services, the final proviso in section 201(b) authorizes 
the Commission to ``prescribe such rules and regulations as may be 
necessary in the public interest'' to carry out any of the 
provisions of the Act, including those pertaining to intrastate 
services (such as the provisions that pertain to the intrastate 911 
traffic at issue here). See AT&T Corp. v. Iowa Utils. Bd., 525 U.S. 
366, 377-81 (1999); 47 U.S.C. 201(b).
    \383\ NTCA NG911 Notice Reply at 14 (quoting RTCC NG911 Notice 
Comments at 14-15); RLEC Coalition July 5, 2024 Ex Parte at 2 
(acknowledging that ``the calls at issue are indeed intrastate in 
nature'') (emphasis omitted). If an OSP believes it is being 
subjected to unjust or unreasonable rates or terms for its 
intrastate communications services, the PUC for its state or another 
911 Authority has the legal authority to address the issue.
---------------------------------------------------------------------------

    Cost responsibility. We disagree with the argument made by the RLEC 
Coalition and the Pennsylvania Telephone Association that we have no 
authority to cause RLECs to bear costs associated with providing NG911 
service. These commenters overlook the CVAA's authorization for us to 
enact ``any . . . regulations'' needed to ``achieve reliable, 
interoperable communication that ensures access by individuals with 
disabilities to an internet protocol-enabled emergency network, where 
achievable and technically feasible.'' \384\ The regulations to advance 
the nationwide transition to NG911 will significantly enable vital 911 
access for people with disabilities, including through internet-based 
TRS and other service types. Thus, the Commission has clear statutory 
authority to adopt these NG911 regulations. Moreover, rural wireless 
carriers presented essentially the same arguments to challenge the 
Commission's E911 rules, and those arguments were squarely rejected. 
The D.C. Circuit held that the Commission was not required to ensure 
that states maintained a funding mechanism to support rural wireless 
carriers' provision of E911 and observed that it was ``ludicrous to 
suggest that government cannot pass these costs along to regulated 
entities.'' \385\
---------------------------------------------------------------------------

    \384\ 47 U.S.C. 615c(g).
    \385\ U.S. Cellular Corp., 254 F.3d at 80, 85.
---------------------------------------------------------------------------

    Takings. We disagree with the assertion of some commenters that the 
NG911 rules constitute a taking of property in violation of the Fifth 
Amendment.\386\ First, our rules do not represent a physical or per se 
taking because they do not appropriate property owned by OSPs or deny 
them all economically beneficial use of their property.\387\ They also 
do not represent a regulatory taking. The principal factors that courts 
review in determining whether a governmental regulation effects a 
taking are: (1) the character of the governmental action; (2) the 
economic impact of the regulation on the claimant; and (3) the extent 
to which the regulation has interfered with distinct investment-backed 
expectations.\388\ Regarding the first factor, as noted above, the 
rules adopted in the Order do not appropriate any property for 
government use, but instead promote a significant common good by 
promoting life and safety and enhancing the capabilities and 
reliability of the nation's 911 system.\389\ With respect to the second 
factor, a ``mere diminution in the value of property, however serious, 
is insufficient to demonstrate a taking.'' \390\ Nor will our rules 
interfere with reasonable investment-backed expectations under the 
third factor. OSPs' networks have long been subject to Commission 911-
related regulations, including analogous requirements to transmit 911 
calls in specified formats to locations designated by 911 
Authorities.\391\ The Supreme Court has recognized that, for property 
that has ``long been subject to federal regulation,'' there is no 
``reasonable basis to expect'' that the regulatory regime will not 
change,\392\ and the D.C. Circuit has held that the Commission may 
properly require OSPs to incur the costs of providing 911 service 
without ensuring them compensation.\393\ Particularly in light of ``the 
heavy burden placed upon one alleging a regulatory taking,'' we find no 
basis to find a regulatory taking on the record here.\394\
---------------------------------------------------------------------------

    \386\ Home Telephone NG911 Notice Comments at 21-22 (claiming 
the NG911 rules would ``arbitrarily `take' from RLECs'' and ``force 
RLECs to purchase services that it [sic] is then required to provide 
for free to a governmental entity''). The Takings Clause states: 
``nor shall private property be taken for public use, without just 
compensation.'' U.S. Const. amend. V.
    \387\ See, e.g., Horne v. Dep't. of Agric., 576 U.S. 350, 352, 
359-61 (2015) (stating that per se takings implicated when the 
government appropriates real or personal property for its own use); 
Lucas v. S.C. Coastal Council, 505 U.S. 1003, 1019 (1992) (stating 
that a real property owner ``has suffered a taking'' if he ``has 
been called upon to sacrifice all economically beneficial uses in 
the name of the common good, that is, to leave his property 
economically idle'') (emphasis omitted).
    \388\ Penn Cent. Transp. Co. v. City of New York, 438 U.S. 104, 
124-25 (1978).
    \389\ Penn Cent. Transp. Co., 438 U.S. at 124 (stating that, as 
to the first factor, a taking ``may more readily be found when the 
interference with property can be characterized as a physical 
invasion by government . . . than when interference arises from some 
public program adjusting the benefits and burdens of economic life 
to promote the common good'') (citation omitted).
    \390\ Concrete Pipe & Prods. of Cal., Inc. v. Constr. Laborers 
Pension Tr. for S. Cal., 508 U.S. 602, 645 (1993); see also A&D Auto 
Sales, Inc. v. United States, 748 F.3d 1142, 1157 (Fed. Cir. 2014) 
(``In order to establish a regulatory taking, a plaintiff must show 
that his property suffered a diminution in value or a deprivation of 
economically beneficial use. . . . `[I]f the regulatory action is 
not shown to have had a negative economic impact on the 
[plaintiff's] property, there is no regulatory taking.' '' (quoting 
Hendler v. United States, 175 F.3d 1374, 1385 (Fed. Cir. 1999))).
    \391\ See, e.g., 47 CFR 9.10(i)(2)(ii)(G), 9.11, 9.14 (E911 
provisions requiring transmission of the caller's location and phone 
number); id. Sec. Sec.  9.4, 9.5 (requiring all telecommunications 
carriers to ``transmit all 911 calls to a PSAP, to a designated 
statewide default answering point, or to an appropriate local 
emergency authority as set forth in Sec.  9.5'').
    \392\ Concrete Pipe & Prods., 508 U.S. at 645-46 (discussing 
degree of interference with ``reasonable investment-backed 
expectations'' and noting that ``those who do business in the 
regulated field cannot object if the legislative scheme is 
buttressed by subsequent amendments to achieve the legislative end'' 
(quoting FHA v. Darlington, Inc., 358 U.S. 84, 91 (1958))).
    \393\ U.S. Cellular Corp., 254 F.3d at 85.
    \394\ Keystone Bituminous Coal Ass'n v. DeBenedictis, 480 U.S. 
470, 493 (1987).
---------------------------------------------------------------------------

    Liability. We disagree with some commenters' claims that the NG911 
rules will unreasonably expose RLECs to significantly greater liability 
risks, and hence unjustified costs. RLEC commenters express concern 
that they will face increased liability costs for 911 call failures 
occurring within the networks of the third-party transport services 
they will retain to deliver 911 calls beyond their service areas, 
``particularly to distant, out-of-state interconnection points.'' \395\ 
As discussed above, the home-state qualification addresses the concern 
that RLECs could face liability under out-of-state tort law. More 
fundamentally, RLECs have failed to provide any record support for 
their purported tort liability concerns. State statutes generally grant 
liability protections to parties involved in transmitting and 
responding to 911 calls, including not only OSPs but also their third-
party vendors, and Federal law guarantees parity in liability 
protection within the state for all OSPs.\396\ To illustrate, the South 
Carolina RLECs characterize their state's statute as providing ``broad 
immunity from liability,'' and indicate the statute's protections 
extend to the ``officers, employees, assigns, [and] agents'' of an 
OSP.\397\ Against this backdrop, no commenter has identified any 
instance of a state court judgment in which an OSP has been held liable 
under tort law for failing to deliver 911 calls.
---------------------------------------------------------------------------

    \395\ South Carolina RLECs NG911 Notice Comments at 14-16; see 
also, e.g., NTCA NG911 Notice Comments at 4-8 (IP 911 call delivery 
poses risks for OSP call delivery by too widely expanding the use of 
third-party networks); Windstream NG911 Notice Reply at 2-3; Home 
Telephone NG911 Notice Comments at 16-18; RLEC Coalition Mar. 6, 
2024 Ex Parte at 7; South Carolina RLECs June 20, 2024 Ex Parte at 
5-6.
    \396\ 47 U.S.C. 615a(a).
    \397\ South Carolina RLECs NG911 Notice comments at 14-16 
(discussing S.C. Code Ann. sec. 23-47-70(A)). We do not offer our 
own legal interpretation of the South Carolina statute, nor will we 
state that liability for a third party's actions or inactions can 
never lead to liability, as some commenters request. We note, 
however, that no commenter explains why an OSP's transport services 
provider, as the OSP's agent, would not be covered by such liability 
protection provisions.

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

[[Page 78106]]

    Even assuming there is some increased risk of liability, RLECs may 
mitigate that risk by more closely monitoring their vendors' network 
performance or by increasing their insurance coverage, as one commenter 
suggests. Commenters do not provide estimates of the costs of these 
mitigation measures, however, much less demonstrate that these costs 
would be significant. And as discussed above, if an RLEC faces 
increased exposure to liability for dropped 911 calls, it may seek 
authorization from its state PUC to recover these costs in the same 
manner as other incremental cost increases resulting from its 
implementation of NG911.
    Most importantly, the implementation of NG911 is far more likely to 
reduce the risk of dropped 911 calls than to increase it. OSPs that 
make the necessary changes to fully implement NG911 will be able to 
leverage improvements to 911 security and reliability, including the 
ability to reroute 911 calls in response to network congestion or 
outages. Indeed, OSPs may face greater exposure to liability due to the 
risk of dropped 911 calls if they fail to implement NG911 in a timely 
and prudent manner as the NG911 rules require. Finally, certain 
commenters suggest that we should apply 911 network reliability and 
PSAP outage notification requirements to additional categories of 
service providers in an NG911 environment.\398\ We defer consideration 
of such issues to a future proceeding.
---------------------------------------------------------------------------

    \398\ See, e.g., Windstream NG911 Notice Reply at 2-3 (NG911 
traffic aggregators should be subject to the Commission's rules 
relating to disruption notification requirements, which currently 
apply to OSPs); Home Telephone NG911 Notice Comments at iii, 13 & 
n.6; see also NTCA NG911 Notice Reply at 7-8.
---------------------------------------------------------------------------

F. Other Proposals

    Several commenters raised additional issues or proposals in 
response to the NG911 Notice. We discuss each of these issues or 
proposals in turn below.
    Interoperability. Some commenters suggest that we take additional 
action in this proceeding with respect to NG911 interoperability. APCO 
proposes 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.'' \399\ Texas 9-1-1 Entities propose that ``separate from this 
NPRM, the Commission should consider a notice of inquiry regarding 
interoperability between NG911 service providers, with emphasis on 911 
call transfers between ESInets and within ESInets.'' Google and NENA 
urge us to consider the implementation of new interoperable messaging 
protocols. Because these proposals are beyond the scope of this 
proceeding, we decline to address them here. However, we agree with 
these commenters that facilitating interoperability between 911 service 
providers and in all portions of the NG911 emergency communications 
chain are important goals that warrant further scrutiny. We therefore 
encourage 911 Authorities, NG911 service providers, and OSPs to support 
conformance and compliance testing, functional testing of network 
connections between NG911 systems, appropriate business and policy 
implementation, and continued standards development.
---------------------------------------------------------------------------

    \399\ APCO Apr. 18, 2024 Ex Parte at 2. APCO previously urged 
the Commission to require interoperability between OSPs and NG911 
service providers as part of the current proceeding. APCO NG911 
Notice Comments at 2-4. However, in its latest ex parte, APCO 
expresses support for moving forward with the OSP requirements that 
the Commission proposed in the NG911 Notice. APCO Apr. 18, 2024 Ex 
Parte at 1.
---------------------------------------------------------------------------

    Cybersecurity and Privacy. In its comments to the NG911 Notice, the 
Electronic Privacy Information Center (EPIC) suggests that the 
Commission adopt additional cybersecurity and privacy measures in this 
proceeding.\400\ We believe it is premature to consider additional 
measures at this time, but we will continue to monitor the 
implementation of cybersecurity measures in NG911 networks. We also 
note that the Commission has previously adopted privacy protections for 
personal information used to support 911, and that these protections 
will continue to protect the privacy of such information in the NG911 
environment.\401\ We encourage 911 Authorities, NG911 service 
providers, and OSPs to take steps that support the security, and 
specifically the cybersecurity, of these systems during the transition 
to NG911. In particular, we encourage OSPs and 911 Authorities to 
implement the cybersecurity recommendations and best practices put 
forward by TFOPA and CSRIC VII. Both TFOPA and CSRIC VII recommended 
adherence to the recognized and widely adopted approach to cyber 
defense detailed in the National Institute of Standards and Technology 
(NIST) Cybersecurity Framework (NCF).\402\ CSRIC VII also recommended 
that 911 Authorities implement specific cybersecurity mitigation 
techniques, including: continuous cyber monitoring, regular 
vulnerability assessments, minimum backups, a written cyber response 
plan, cyber-hygiene training, and other techniques.\403\ Finally, we 
encourage 911 Authorities, NG911 service providers, and OSPs to 
leverage resources made available by other Federal agencies, most 
notably CISA, to foster and enhance public safety cybersecurity.\404\
---------------------------------------------------------------------------

    \400\ EPIC NG911 Notice Comments at 3 (stating that the 
Commission ``should require improved cybersecurity practices, 
assessed as part of a readiness determination,'' and provide 
guidelines for the collection and use of NG911 data).
    \401\ LBR Order at *35, para. 102; Wireless E911 Location 
Accuracy Requirements, PS Docket No. 07-114, Fifth Report and Order 
and Fifth Further Notice of Proposed Rulemaking, 34 FCC Rcd 11592, 
11614-16, paras. 49-52 (2019), corrected by Erratum (PSHSB Jan. 15, 
2020).
    \402\ TFOPA WG 1 Report at 23-24; CSRIC VII, Report on Security 
Risks and Best Practices for Mitigation in 9-1-1 in Legacy, 
Transitional, and NG 9-1-1 Implementations, sec. 6.2 (Sept. 16, 
2020), https://www.fcc.gov/sites/default/files/csric7_report_secuirtyrisk-bestpracticesmitigation-legacytransitionalng911.pdf (CSRIC VII Report on 911 Security Risks 
and Best Practices for Mitigation).
    \403\ CSRIC VII, Report Measuring Risk Magnitude and Remediation 
Costs in 9-1-1 and Next Generation 9-1-1 (NG911) Networks, sec. 
5.2.1 (Mar. 10, 2021), https://www.fcc.gov/file/20607/download 
(CSRIC VII 911 Risk and Remediation Report).
    \404\ See, e.g., Cybersecurity & Infrastructure Security Agency, 
911 Cybersecurity Resource Hub, https://www.cisa.gov/911-cybersecurity-resource-hub (last visited Apr. 11, 2024).
---------------------------------------------------------------------------

    Over-the-Top Services. NENA asks the Commission to consider 
extending some requirements for NG911 to over-the-top messaging 
services, which ``provide robust multimedia capabilities and would 
enhance NG9-1-1 availability to individuals regardless of their 
underlying telecommunications/internet provider.'' \405\ Because the 
Commission only considered requirements for OSPs in the NG911 Notice, 
the role of providers of over-the-top services is outside the scope of 
this proceeding, as NENA acknowledges,\406\ and we therefore decline to 
consider this request at this time.
---------------------------------------------------------------------------

    \405\ NENA NG911 Notice Comments at 6; see also APCO Oct. 31, 
2023 Ex Parte at 3 (``[W]e discussed the value of engaging with 
companies that provide over-the-top solutions that enable the 
receipt, processing, and sharing of `Next Generation' data such as 
multimedia communications from 9-1-1 callers to ECCs.'')
    \406\ NENA NG911 Notice Comments at 6 (acknowledging that the 
request is ``far afield of the Commission's current scope under this 
proceeding'').
---------------------------------------------------------------------------

    Additional Accessibility Proposals. Several parties urge the 
Commission to expand this proceeding to consider NG911 accessibility 
issues beyond the scope of the proposals in the NG911 Notice. CEA 
encourages the Commission to seek further comment on

[[Page 78107]]

requiring that ``NG911 systems be capable of handling text, data, and 
video communications that are accessible to members of the Deaf, Deaf 
Disabled, DeafBlind, Hard of Hearing, and Late-Deafened communities.'' 
Hamilton Relay requests that the Commission adopt a 2019 proposal that 
would require IP CTS providers transmitting 911 calls to provide a 
call-back telephone number while also ensuring that the user receives 
captions on the callback.\407\ Richard Ray requests that the FCC 
collaborate with the Federal Emergency Management Agency, the U.S. 
Department of Transportation's National 911 Program, and the U.S. 
Department of Justice to implement Next Generation 911 features that 
will ``ensure effective communication with individuals with 
disabilities in NG9-1-1 environments.'' \408\ Because these proposals 
are beyond the scope of this proceeding, we decline to address them 
here. However, consistent with our authority under the CVAA, we will 
continue to monitor the development of NG911 systems and technologies 
and are prepared to take steps as necessary to ensure that NG911 is 
fully accessible to all.
---------------------------------------------------------------------------

    \407\ Hamilton Relay NG911 Notice Comments at 2-3 n.4; see also 
Misuse of internet Protocol (IP) Captioned Telephone Service; 
Telecommunications Relay Services and Speech-to-Speech Services for 
Individuals with Hearing and Speech Disabilities, CG Docket Nos. 13-
24 and 03-123, Report and Order (84 FR 8457 (Mar. 8, 2019)), Further 
Notice of Proposed Rulemaking (84 FR 9276 (Mar. 14, 2019)), and 
Order, 34 FCC Rcd 691, 710, para. 38 (2019) (setting forth the 2019 
Commission proposal referenced by Hamilton Relay).
    \408\ Filing from Richard Ray, PS Docket No. 21-479, at 3, 7-8 
(Sept. 15, 2023) (Richard Ray Sept. 15, 2023 Ex Parte). These 
recommendations include, for example, that the Department of Justice 
update its Americans with Disabilities Act regulations to require 
public entities, including 911 services, to communicate with persons 
with disabilities using direct Synchronous Communication and equally 
effective Telecommunication Technologies. Id. at 3. Richard Ray also 
notes that in 2011, the Commission established the Emergency Access 
Advisory Committee (EAAC) as required by the CVAA, which recommended 
that Media Communication Line Services (MCLS) become a nationally 
recognized certified standard service in NG911 environments. Id. at 
7-8 (``MCLS is a translation service for people with disabilities 
and telecommunicators using video, voice, text, and data during NG9-
1-1 calls.''); see also FCC, Emergency Access Advisory Committee 
(EAAC) Working Group 3 Recommendations on Current 9-1-1 and Next 
Generation 9-1-1: Media Communication Line Services Used to Ensure 
Effective Communication with Callers with Disabilities at 4-5, 12 
(2013), https://docs.fcc.gov/public/attachments/DOC-319394A1.pdf.
---------------------------------------------------------------------------

G. Benefits and Costs

    We find that the benefits of the rules will overwhelmingly exceed 
the costs. As discussed below, we have extensive evidence that supports 
this conclusion, and we reject parties' unsupported arguments to the 
contrary. We estimate that the rules will generate substantial 
improvements in the efficiency and reliability of the 911 public safety 
response system that will likely result in a reduction of mortality 
risk equivalent to saving over 16,800 lives per year after the end of 
the fifth year following the effective date of the Order.\409\ As a 
result, we estimate that the rules will save more than 84,000 lives 
within a ten-year period after the effective date of the rules, 
conservatively estimating that most benefits will begin to accrue at 
the end of the fifth year.\410\ In addition, these improvements will 
likely reduce nonfatal injuries and property damage by even larger 
amounts that we have not attempted to quantify.
---------------------------------------------------------------------------

    \409\ These benefits are based on an extremely conservative 
assumption that the benefits resulting from the Order will not begin 
to accrue until the end of the fifth year after the effective date, 
even though benefits actually will likely start to accrue sooner. We 
estimate that, nationwide, both NG911 transition phases will be 
complete within five years, due in significant part to the 
provisions of the Order that remove obstacles to completion of the 
transition, but this estimate is quite conservative because the full 
transition will likely be completed sooner in many states and 
regions. Consistently, several 911 Authorities indicate that they 
have already completed all or parts of the necessary NG911 
technology acquisition on their end for Phase 1 readiness or beyond; 
the six-month and one-year deadlines that we adopt for OSPs to 
satisfy these entities' valid requests will enable these entities 
(as well as the OSPs and PSAPs that serve their citizens) to 
complete the NG911 transition significantly more quickly than the 
five-year benchmark on which we base our estimates of the benefits 
resulting from the Order. Minnesota DPS-ECN NG911 Notice Comments at 
2; Livingston Parish NG911 Notice Comments at 1-2; Letter from Susan 
C. Ornstein, Senior Director, Legal & Regulatory Affairs, Comtech, 
to Marlene H. Dortch, Secretary, FCC, PS Docket No. 21-479, Attach. 
at 2 (filed Mar. 25, 2024) (Comtech Mar. 25, 2024 Ex Parte); see 
also Intrado Mar. 26, 2024 Ex Parte at 3 (estimating that the NG911 
transition could be completed within three to five years).
    \410\ We estimate the ten-year benefit of reducing the mortality 
risk to be around $617 billion (including $616 billion from faster 
emergency medical responses and $840 million from reduction in call 
failures) using a 7% discount rate, or $834 billion using a 3% 
discount rate for 10 years following past orders. See, e.g., 
Implementation of the National Suicide Hotline Improvement Act of 
2018, WC Docket No. 18-336, Report and Order, 35 FCC Rcd 7373, 7416-
17, para. 75 & n.332 (2020), 85 FR 57767 (Sept. 16, 2020) 
(estimating the present value of benefits over 10 years using a 7% 
discount rate).
---------------------------------------------------------------------------

    By contrast, applying conservative assumptions, we estimate that 
OSPs will incur total costs of no more than $321 million over the same 
ten-year period to implement the rules. These expenditures would be 
fully justified even if they resulted in reducing mortality risks 
equivalent to preventing the loss of only 26 lives. This cost estimate 
at the nationwide aggregate level is based on an assessment that the 
cost to OSPs of implementing Phase 1 will be approximately $4.4 million 
in total one-time non-recurring costs and no more than $5.5 million in 
annual recurring costs, and that OSPs will incur non-recurring one-time 
costs of approximately $24 million and approximately $50 million per 
year to implement Phase 2 requirements, for a total net present value 
of $321 million over a ten-year period to implement the rules required 
for both phases. Taking into account these estimated benefits and 
costs, it is evident that the benefits far exceed the costs. We discuss 
each of these findings below.

1. Benefits

    Evidence in the record strongly supports our tentative conclusion 
in the NG911 Notice that the benefits of accelerating the overall NG911 
transition will include real-time call routing flexibility, faster call 
delivery, and improved service reliability.\411\ For example, data from 
Indiana confirm that 911 calls have been delivered substantially more 
quickly following Indiana's initial deployment of NG911.\412\ Further, 
we find APCO's observation that NG911 implementation will greatly 
improve neighboring PSAPs' ability to transfer calls to one another and 
improve interoperability to be highly credible.\413\ Likewise, NENA,

[[Page 78108]]

APCO, and Peninsula Fiber Network demonstrate that legacy PSAP call 
transfers are slow and cumbersome and that the improvements to this 
process resulting from NG911 will be significant.\414\ The use of NG911 
features to transfer and share incident information seamlessly and in 
real time will not only reduce response times, but it also will improve 
the quality of response by ensuring that the right assets are 
dispatched as quickly as possible once the need for them is identified. 
Currently, emergency responses are typically ``upgraded'' (i.e., public 
safety resources are added or the level of priority is increased) only 
after the first unit arrives on the scene. If an incident requires 
action by multiple PSAPs and/or emergency response agencies, then all 
the information (including caller and incident specifics) must be 
coordinated among these PSAPs and emergency responders by telephone, 
radio, and/or mobile data terminals. The ability to use NG911 features 
to share that information more quickly and accurately through immediate 
transfers, rather than through a chain of intermediate communications 
methods, will substantially improve response quality and outcomes. No 
commenter argues that the NG911 transition will not result in 
substantial overall benefits.
---------------------------------------------------------------------------

    \411\ See, e.g., NG911 Notice, 38 FCC Rcd at 6234-35, para. 65; 
Comtech NG911 Public Notice Reply at 4 (rec. Feb. 3, 2022) (stating 
the ``incredible benefits'' of NG911 systems include ``real-time 
call routing flexibility, faster call delivery, additional data for 
improved situational awareness, capabilities such as integrated text 
messages (and other multi-media messages soon), and significantly 
improved service reliability''); BRETSA NG911 Public Notice Reply at 
4-7 (rec. Feb. 3, 2022) (detailing benefits including conferencing-
in telephone or video relay and language interpretation services 
during 911 call setup, interstate 911 call transfer and CAD incident 
data transfer, geospatial routing, and transfer of CAD data with 
call transfer); NTCA NG911 Public Notice Comments at 2 (rec. Jan. 
19, 2022) (indicating that NG911 will provide increased situational 
awareness to first responders, which will benefit rural consumers).
    \412\ National 911 Program, NG911 for Fire Service Leaders at 9 
(undated), https://www.911.gov/assets/National_911_Program_NG911_Guide_for_Fire_Service_Leaders.pdf (NG911 
for Fire Service Leaders) (``The year before Indiana began the 
transition to NG911, a citizen dialing 911 waited 23 to 27 seconds 
for the call to be routed to a 911 operator. With NG911, that's now 
less than three seconds.'').
    \413\ APCO, APCO International's Definitive Guide to Next 
Generation 9-1-1 at 33-34 (2022), https://www.apcointl.org/ext/pages/APCOng911Guide/APCO_NG911_Report_Final.pdf (APCO NG911 Guide) 
(``NG9-1-1 technology will make marked improvements in the ability 
and ease of transferring information between ECCs and responders in 
the field. . . . Not only will ECCs be capable of transferring CAD 
and 9-1-1 information to other ECCs, but they will also be capable 
of sending that information to multiple agencies, regardless of 
jurisdictional boundaries.'').
    \414\ NENA LBR Public Notice Comments at 4, 11 (rec. July 11, 
2022) (NENA LBR Public Notice Comments) (saying ``the general 
anecdotal consensus was that a call transfer typically takes `about 
a minute,''' and NG911 Policy Routing Functions avoid the need for a 
transfer because they ``evaluate[] various conditions and may make a 
Policy Routing decision that supplements or overrides an LBR query 
[] [d]epending on conditions and Policy Routing rules'') (emphasis 
omitted); APCO LBR Public Notice Comments at 2-3 (rec. July 11, 
2022) (transfers take ``a minute or longer,'' and ``NG9-1-1 needs to 
mean the ability of ECCs to . . . share incident data in a fully 
interoperable manner''); Peninsula Fiber Network LBR Public Notice 
Comments at 1 (rec. July 8, 2022) (``Each transfer takes between 15 
to 90 seconds to set up and complete.''); see also NG911 for Fire 
Service Leaders at 7 (``NG911 will improve response times when calls 
are transferred from other referring agencies, because a caller's 
location is automatically matched to the appropriate 911 call 
center, or public safety answering point (PSAP), serving that area--
limiting delays and misdirected calls.'').
---------------------------------------------------------------------------

    These benefits are confirmed by numerous commenting parties. For 
example, Rally Networks states that ``[r]ural communities will receive 
significant benefits from the transition'' because, ``[i]n a rural 
community, it takes longer for emergency responders to arrive on scene 
and evaluate and request the additional emergency response resources 
that may be required,'' and ``NG911 provides an opportunity for 
resources to be more appropriately dispatched before first responders 
arrive on scene and evaluate the need.'' Comtech agrees that the 
enormous technology benefits of NG911 will ``dramatically improve 
emergency response.'' \415\ Brian Rosen states that interconnected 
ESInets enable call transfers beyond local areas, and allow the 
transfer of ``much richer data'' than in a legacy environment.
---------------------------------------------------------------------------

    \415\ Comtech NG911 Notice Comments at 1 (quoting Press Release, 
FCC, FCC Chairwoman Proposes Plan for Next Gen 911, 2022 WL 565819 
(Feb. 22, 2022), https://docs.fcc.gov/public/attachments/DOC-380566A1.pdf).
---------------------------------------------------------------------------

    We estimate the public safety benefits based on three types of 
impacts of the accelerated NG911 implementation that likely will result 
from the rules: (1) increased network reliability and resiliency, which 
will reduce the number of dropped 911 calls; (2) more efficient routing 
and delivery of 911 calls as a result of introducing new policy routing 
capabilities; and (3) improvements in the delivery of location 
information with 911 calls. We also note that additional benefits (or 
avoided costs) will be realized by 911 Authorities, PSAPs, and some 
OSPs due to retiring legacy 911 network facilities that are costly to 
operate.
    Network Reliability and Resiliency. The record confirms our 
tentative conclusion in the NG911 Notice that the NG911 transition will 
improve the reliability of the 911 system, and thus improve public 
safety. Accelerating the implementation of NG911 will reduce the 
likelihood of 911 service outages because it will facilitate deployment 
of new facilities to replace the aging and failure-prone infrastructure 
used to operate the legacy 911 system.\416\ NASNA reports that a recent 
study of California 911 calls showed that ``[i]n 2017[,] the average 
number of minutes of outage was 17,000 minutes per month, but in 2022 
the average increased to over 59,000 outage minutes per month.'' \417\ 
NASNA states that legacy 911 call routing and network infrastructure 
``is beyond end-of-life and has an increasing failure rate.'' \418\ 
Intrado confirms that establishing direct OSP connectivity via SIP to 
ESInets ``will materially reduce the number of 911 outages through 
improved network reliability and availability.'' \419\ Comtech agrees 
that full implementation of NG911 will eliminate the need for 
maintaining both legacy and IP-based systems for the delivery of 911 
traffic, which involves significant costs and creates ``increased 
vulnerability and risk of 911 outages.'' \420\
---------------------------------------------------------------------------

    \416\ See, e.g., NG911 Notice, 38 FCC Rcd at 6236, para. 67.
    \417\ NASNA LBR Notice Comments at 7-8 (Feb. 16, 2023) (NASNA 
LBR Notice Comments); NG911 Notice, 38 FCC Rcd at 6236, para. 67 
(noting the California data cited by NASNA).
    \418\ NASNA LBR Notice Comments at 7; NG911 Notice, 38 FCC Rcd 
at 6236, para. 67.
    \419\ Intrado Oct. 24, 2023 Ex Parte at 1; see also Intrado Mar. 
26, 2024 Ex Parte at 1 (``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. It also increases the speed of delivery for 
location information because location information is part of 
Emergency Services IP Network (ESInet) design and adds the ability 
for secure VPN, encryption, and certification.''); iCERT NG911 
Notice Comments at 1 (confirming that the transition to NG911 will 
provide greater 911 system resilience).
    \420\ Comtech NG911 Notice Reply at 4 (quoting MSCI NG911 Notice 
Comments at 2 and NG911 Notice, 38 FCC Rcd at 6205, para. 1).
---------------------------------------------------------------------------

    The Commission has previously observed that an aging legacy 911 
system is prone to increasing failures.\421\ The rules will accelerate 
the full retirement of the legacy TDM-based 911 system and facilitate 
use of an NG911 architecture that uses newer and less failure-prone 
facilities. Selective routers will be replaced with NGCS IP routing at 
the ESInet, ALI/ANI databases will be replaced with IP-based systems 
with more precise location information, TDM trunks will be replaced 
with IP transmission to provide faster connections, and traffic will be 
routed to more reliable and efficient IP-based NG911 Delivery Points. 
Migrating 911 call traffic from aging legacy infrastructure to newer IP 
infrastructure creates a reliability benefit of traffic delivery by 
newer and more recently built facilities.\422\ Furthermore, the more

[[Page 78109]]

extensive use of IP routing in the Phase 2 architecture is inherently 
more reliable than legacy TDM selective routing because of the greater 
capability of IP traffic to be dynamically rerouted among various 
available paths.\423\
---------------------------------------------------------------------------

    \421\ See, e.g., Improving 911 Reliability Order, 28 FCC Rcd at 
17477, para. 2 (stating ``the unanticipated `derecho' storm in June 
2012,'' which left millions of Americans without 911 service, 
``reveal[ed] significant, but avoidable, vulnerabilities in 911 
network architecture, maintenance, and operation''); see also NASNA 
LBR Notice Comments at 7 (``The transition to NG911 is no longer a 
choice; legacy 911 call routing and legacy network infrastructure is 
beyond end-of-life and has an increasing failure rate.''); Minnesota 
DPS-ECN NG911 Public Notice Comments at 1 (stating that ``the LSRs 
[legacy selective routers] are end-of-service, end-of-life and 
starting to fail''); Texas 9-1-1 Entities NG911 Public Notice Reply 
at 4 (rec. Feb. 3, 2022). See generally NG911 Notice, 38 FCC Rcd at 
6236, para. 67 (``The proposed actions will move 911 calls off of 
the aging legacy 911 system that commenters indicate is increasingly 
unreliable, thus improving public safety.'').
    \422\ See, e.g., APCO, Broadband Implications for the PSAP: 
Analyzing the Future of Emergency Communications at 52 (2017), 
https://www.apcointl.org/~documents/report/p43-report-broadband-
implications-for-the-psap?layout=default (APCO Broadband 
Implications for the PSAP) (``In a next generation environment, 
PSAPs can transition premises-based call handling to distributed 
systems using ESInet connectivity to establish a robust and unified 
system among numerous PSAPs. This configuration enables a higher 
level of reliability by placing core systems at redundant hosted 
locations to protect operational continuity from local outages to 
large-scale disasters.'').
    \423\ 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, 
8656, para. 15 (2015), 80 FR 60548 (Oct. 7, 2015).
---------------------------------------------------------------------------

    NG911 IP Policy Routing Capabilities. The implementation of NG911 
will facilitate greater use of policy routing--i.e., systems that 
enable calls to be diverted automatically from their default routing 
paths to alternative paths for dynamic reasons, such as congestion or 
call volume surges.\424\ In the 911 context, policy routing can also be 
used to implement failover plans so that calls can be directed to 
alternative PSAPs in instances when temporary surges in call volumes 
exceed the capability of 911 telecommunicators at the default 
PSAPs.\425\ Policy routing thus can be used to enable the best situated 
PSAPs to receive calls and direct emergency responses.\426\
---------------------------------------------------------------------------

    \424\ NENA, NENA NG9-1-1 Policy Routing Rules Operations Guide 
(NENA-INF-011.2-2020) at 9-10 (2020), https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/nena-inf-011.2-2020_ng_prr_o.pdf (NENA NG911 Policy Routing Guide); Comtech LBR 
Public Notice Comments at 9-10 (rec. July 11, 2022) (Comtech LBR 
Public Notice Comments) (``NG911 systems have flexible policies with 
granular control for delivering 911 calls to a PSAP (i.e., alternate 
routing).'').
    \425\ NENA NG911 Policy Routing Guide at 2 (PSAP call diversion 
can ensure 911 calls are answered during ``significant spikes for 
incoming 9-1-1 calls due to a large-scale disaster.'').
    \426\ Id. (Policy routing allows calls to be automatically 
rerouted to different PSAPs based on, e.g., ``when a PSAP needs to 
be evacuated for an environmental building issue (e.g., odor of 
smoke in the building) . . . . The legacy method of diverting calls 
is a less flexible capability than what is envisioned in NG9-1-1. 
The ability to enable a multi-layered call treatment policy for call 
diversion within NG9-1-1 using Policy Routing Rules (PRRs) provides 
more options to a PSAP to institute consideration of multiple 
conditions (e.g., policies), with greater flexibility, and to adjust 
the call diversion policies on a near real-time basis when 
needed.'').
---------------------------------------------------------------------------

    We find that the improved policy routing that NG911 makes possible 
will result in substantial improvements over legacy TDM selective 
routers, which will reduce 911 call failures and save lives. NG911 
architecture provides far more routing options than legacy TDM because 
IP traffic is not constrained by the location of the caller or the PSAP 
that serves the caller.\427\ In legacy 911 networks, selective routers 
must be relatively close to the PSAPs they serve, whereas in NG911, 
traffic can be easily rerouted to servers and locations outside the 
affected area, providing more resiliency and redundancy in disaster 
situations.\428\ APCO has observed that IP-based NG911 systems' policy 
routing functions will significantly improve local authorities' 
emergency response capabilities.\429\ Mission Critical Partners states 
that Phase 2 NG911 will improve the reliability of 911 call routing, 
further facilitating interoperability between ESInets and allowing for 
the retirement of legacy network elements. First, NG911 facilitates 
more precise routing than legacy selective routers using ALI/ANI 
location information because NG911 systems can implement ``geospatial 
routing'' and update GIS data more frequently than legacy location 
databases.\430\
---------------------------------------------------------------------------

    \427\ NG911 NOI, 25 FCC Rcd at 17879-81, paras. 26, 29.
    \428\ Id.
    \429\ See, e.g., APCO NG911 Guide at 11 (``NG9-1-1 will 
facilitate the dynamic routing of emergency service requests to 
alternate ECCs based on a variety of factors. For example, ECCs 
could establish an overflow condition in which a maximum capacity of 
requests has been reached, a wait time threshold for answer or hold 
has been met, or during an outage or damage to an ECC's operational 
capability.''); APCO Broadband Implications for the PSAP at 51 (``In 
an IP environment, however, calls can be rerouted quickly and easily 
based upon established call handling system capabilities in 
conjunction with policies that are designed to distribute call loads 
efficiently and effectively across numerous PSAPs as desired by the 
9-1-1 authority.'').
    \430\ LBR Notice, 37 FCC Rcd at 15202, para. 48 & n.130 (citing 
Comtech LBR Public Notice Comments at 9).
---------------------------------------------------------------------------

    Furthermore, as NENA explains, NG911 policy routing rules 
facilitate automated ``mutual aid agreements'' between PSAPs that allow 
intelligent call diversion processes for 911 calls to be re-directed or 
redistributed among PSAPs based on outages, maintenance, or other 
emergencies.\431\ NG911 policy routing also ``provides more options to 
a PSAP to institute consideration of multiple conditions (e.g., 
policies), with greater flexibility, and to adjust the call diversion 
policies on a near real-time basis . . . to address a wide range of 
operational situations to ensure 9-1-1 calls are delivered to a PSAP 
that can provide assistance consistent with established mutual aid 
agreements.'' \432\ NG911 thus will ``help jurisdictions realize . . . 
enhanced policy routing functions,'' which ``flexibly route[] calls to 
PSAPs based on variables such as call volume, available 
telecommunicator resources, or the need for specialized response to 
particular emergencies.'' \433\ Those ``specialized responses'' could 
include advanced automatic policy routing directives to send certain 
911 calls straight to call handlers with American Sign Language 
expertise, foreign language skills, or real-time text capabilities, 
which would dramatically reduce the response times to many 911 
calls.\434\
---------------------------------------------------------------------------

    \431\ NENA Policy Routing Guide at 2 (``PSAPs sometimes 
establish mutual aid agreements (or Inter-Agency agreements) with 
other jurisdictions to take calls under certain conditions when the 
PSAP is unable to take calls. These mutual aid agreements vary in 
nature but often cover pre-planned conditions (e.g., scheduled 
equipment maintenance windows, or after-hours coverage for a smaller 
PSAP where normal staffing levels are reduced). Many outage 
conditions, however, are unscheduled and are due to unforeseen 
equipment breakdowns and network outages, significant spikes for 
incoming 9-1-1 calls due to a large-scale disaster, or when a PSAP 
needs to be evacuated for an environmental building issue (e.g., 
odor of smoke in the building). When the calls originally meant for 
one PSAP need to be sent to another PSAP, Call Diversion is the 
generally adopted term for this conditional situation.'').
    \432\ Id. at 2-3. Even during transitional NG911 phases, Legacy 
PSAP Gateways will be able to automatically notify the NGCS Policy 
Routing Function if the PSAP becomes unavailable, allowing for 
instant rerouting of 911 calls and texts to avoid network 
disruptions. Id. at 25-26 (``In the transition period, a legacy PSAP 
would be connected to the NGCS/ESInet via a Legacy PSAP Gateway 
(LPG). The LPG would, by definition, provide `State' to the PRF 
[Policy Routing Function] of the NGCS and thus could implement some 
basic PRRs [Policy Routing Rules]. One of the PRRs a PRF could 
implement for a legacy PSAP would be to know the availability of a 
PSAP (by using SIP OPTIONS message to determine if a PSAP was 
reachable). Knowing if a PSAP is reachable would allow the PRF to 
make a routing decision on whether to send Calls to the legacy 
PSAP.'').
    \433\ LBR Notice, 37 FCC Rcd at 15202, para. 48 & n.130-31 
(citing Comtech LBR Public Notice Comments at 9-10); NENA LBR Public 
Notice Comments at 11-12.
    \434\ NENA LBR Public Notice Comments at 11-12 (``For example, 
the Policy Routing Function could determine that the call only 
supports American Sign Language over video, and based on this 
information the system can make an informed routing decision that 
better accommodates the caller. This could drastically reduce the 
time involved in handling calls from the deaf and hard of hearing. 
Policy Routing decisions could be made based on other factors. Calls 
can be routed to a telecommunicator who understands the caller's 
native language; a call may signal that the speaker prefers Spanish, 
but understands English, and make a routing decision based on that. 
RTT calls may be routed to a call queue dedicated to RTT, reducing 
call handling time.'').
---------------------------------------------------------------------------

    Improved Delivery of Caller Location Information. In NG911 systems, 
the legacy ALI/ANI caller location technology will be replaced with IP-
based LVF and LIS for the verification of customer records and delivery 
of caller location information to PSAPs. This will facilitate full use 
of the functional elements of NG911, which can deliver higher-quality 
actionable information to PSAPs than legacy ALI/ANI databases, even 
after CMRS providers finish implementing location-based routing under 
existing rules.\435\ Mission Critical Partners states that full NG911 
will reduce location delivery

[[Page 78110]]

failures because it is more reliable than the current legacy system 
dependent on ALI data.\436\ MSCI argues that the NG911 IP caller 
location delivery systems will standardize location information 
delivery, improving PSAP use of caller location data over the legacy 
ALI/ANI system.\437\
---------------------------------------------------------------------------

    \435\ See Mission Critical NG911 Notice Comments at 6; MSCI LBR 
Notice Reply at 2; see generally LBR Order.
    \436\ Mission Critical Partners NG911 Notice Comments at 6 
(``Currently, MCP has observed most ESInet to ESInet transfers are 
using transitional methods which require both systems to maintain 
duplicate legacy ALI records. The use of legacy methods along with 
interim, transitional, and/or proprietary interface protocols can 
create uncertainty . . . . When the solution is migrated to full 
NG911 using SIP with routing and location information, it is more 
reliable than the present workaround . . . and it eliminates the 
need to maintain legacy ALI records.'').
    \437\ MSCI LBR Notice Reply at 2 (``Requiring delivery of 911 
calls in IP-based format . . . standardizes delivery of location 
information, and promotes interoperability.'').
---------------------------------------------------------------------------

    Additionally, the location data transmitted via IP features such as 
LIS databases will enable PSAPs and other public safety agencies to 
utilize GIS technology more extensively to give emergency responders 
the capacity to visually map caller locations for more precise and 
accurate emergency responses.\438\ Upgrading 911 location technology 
from ALI/ANI servers to LIS or comparable IP databases will also enable 
the implementation of PIDF-LO technology. PIDF-LO embeds location 
information into IP-based NG911 calls, allowing ``instant, accurate 
location provisioning as a caller moves around a campus or high-rise 
environment'' \439\ for hyper-targeted emergency response from public 
safety agencies.
---------------------------------------------------------------------------

    \438\ See Next Generation Advanced (NGA), NG911 GIS: The Role of 
Geographic Information Systems in Next Generation 911 (July 17, 
2023), https://nga911.com/blogs/post/ng911-gis-role-geographic-information-systems-next-generation-911 (``GIS is a powerful tool 
that can be used to provide accurate and precise location data for 
emergency services. By combining GIS with NG9-1-1, the public safety 
industry has a system capable of accurately pinpointing a caller's 
location and providing responders with vital information about the 
surrounding area, such as the location of fire hydrants or the 
fastest route to someone in need'').
    \439\ See RFC 4119 and 5962; Bandwidth, Presence Information 
Data Format Location Object (PIDF-LO) (Jan. 23, 2024), https://www.bandwidth.com/glossary/presence-information-data-format-location-object-pidf-lo/.
---------------------------------------------------------------------------

    Calculation of Public Safety Benefits. We conclude, based on the 
available evidence, that the expeditious implementation of NG911 will 
yield enormous public safety benefits. We estimate these benefits by 
assessing the likely number of lives saved in 911 emergency responses 
due to the more efficient and reliable delivery of actionable 
information with 911 calls due to the factors described above--i.e., 
the greater reliability and resilience of 911 facilities, the increased 
use of policy routing, and possibly the delivery of higher-quality 
location information. As noted above, a study in Indiana showed that 
``[t]he year before Indiana began the transition to NG911, a citizen 
dialing 911 waited 23 to 27 seconds for the call to be routed to a 911 
operator. With NG911, that's now less than three seconds.'' \440\ These 
improvements to the 911 systems will reduce the 911 routing time by an 
appreciable amount and thus will enable 911 call responders to dispatch 
ambulances more rapidly in response to 911 callers' requests for 
emergency medical assistance.
---------------------------------------------------------------------------

    \440\ NG911 for Fire Service Leaders at 9.
---------------------------------------------------------------------------

    The Commission has previously relied on a study examining 73,706 
emergency incidents in the Salt Lake City area that found that, on 
average, a one-minute decrease in ambulance response times would reduce 
the total number of post-incident deaths from 4,386 deaths to 3,640 
deaths within 90 days after the incident (746 lives saved), 
representing a 17% reduction in mortality.\441\ If reducing the 
response time by one minute results in reducing mortality rates by 17%, 
then we can estimate that reducing the response time by one-third of a 
minute (20 seconds) could lead to a reduction in mortality by one-third 
of 17%--i.e., 5.67% per year--because the regression in the Salt Lake 
City Study is linear.
---------------------------------------------------------------------------

    \441\ See Elizabeth Ty Wilde, Do Emergency Medical System 
Response Times Matter for Health Outcomes?, 22(7) Health Econ. 790-
806 (2013), http://www.ncbi.nlm.nih.gov/pubmed/22700368 (Salt Lake 
City Study). The study examined 73,706 emergency incidents during 
2001 in the Salt Lake City area. Id. at 794. The study found that 
the one-minute increase in response time caused mortality to 
increase 17% at 90 days past the initial incidence, i.e., an 
increase of 746 deaths, from a mean of 4,386 deaths to 5,132 deaths. 
Id. at 795. Because the regression is linear, this result implies 
that a one-minute reduction in response time also saves 746 lives, 
i.e., a 17% reduction from a mean of 4,386 deaths to 3,640 deaths. 
LBR Notice, 37 FCC Rcd at 15206-07, para. 61 & n.159 (``The Salt 
Lake City Study shows a one-minute decrease in ambulance response 
times reduced the likelihood of 90-day mortality from approximately 
6% to 5%, representing a 17% reduction in the total number of 
deaths.'').
---------------------------------------------------------------------------

    According to the National Association of State Emergency Medical 
Services Officials (NASEMSO), local Emergency Medical Services (EMS) 
agencies respond to nearly 28.5 million 911 dispatches each year.\442\ 
In the LBR Order, we relied on calculations set forth in the LBR Notice 
that assumed 80% or more of the total calls to 911 annually are from 
wireless devices.\443\ Since the LBR Order already accounts for some 
benefits accrued from faster emergency medical service responses to 
wireless 911 calls with improved location information, we 
conservatively consider the impact to wireline and VoIP calls only to 
estimate the benefits of improved 911 responses due to the NG911 rules. 
According to calculations based on the data in the Fifteenth Annual 911 
Fee Report, approximately 17.5% (or 5 million) of all EMS dispatches 
are associated with wireline and VoIP 911 calls.\444\ While we do not 
know when the transition to NG911 will be completed, we estimate that, 
if approximately 6% of emergency medical dispatches would have resulted 
in a death, a 5.67% reduction in mortality is equivalent to saving at 
least 16,868 lives per year as a result of the NG911 rules.\445\ This 
implies a total of 84,340 lives saved over the entire ten-year period 
following the effective date of the rules.\446\
---------------------------------------------------------------------------

    \442\ EMS1 (Laura French), National Association of State EMS 
Officials releases stats on local agencies, 911 Calls (Apr. 10, 
2020), https://www.ems1.com/ambulance-service/articles/national-association-of-state-ems-officials-releases-stats-on-local-agencies-911-calls-LPQTHJrK2oIpxuR1/.
    \443\ See LBR Order at *40, para. 119 & n.388 (``Assuming that 
80% of these calls are from wireless devices . . .'').
    \444\ The Commission, in its Fifteenth Annual 911 Fee Report, 
reported that at least 21,194,035 and 12,262,577 voice calls made to 
911 in 2022 originated from wireline and VoIP phones, respectively. 
Fifteenth Annual 911 Fee Report at 16, tbl.3. These figures likely 
understate the actual numbers of wireline and VoIP calls, because 
they do not include counts from Delaware, Georgia, Tennessee, and 
the U.S. Virgin Islands, which did not break down service categories 
separately. Id. at 13. This is equivalent to approximately 17.5% of 
all 911 voice calls when divided by the total number of wireline, 
wireless, and VoIP 911 calls from states which reported break out 
service categories ((21,194,035 wireline calls + 12,262,577 VoIP 
calls)/(21,194,035 wireline calls + 157,999,298 wireless calls + 
12,262,577 VoIP calls) = 17.474% [ap] 17.5%). See Fifteenth Annual 
911 Fee Report at 16, tbl.3-Total 911 Calls by Service Type and 911 
Texts. We assume that the share of the 28.5 million EMS dispatches 
each year that can be attributed to wireline and VoIP is the same as 
the share of all 911 calls attributed to wireline and VoIP, i.e., 
17.5%, or 5 million (28,500,000 x 17.5% = 4,987,500 [ap] 5 million 
dispatches).
    \445\ We calculate the reduction in deaths as follows: 5 million 
dispatches x 5.95% (90 day mortality in Salt Lake City Study) x 
5.67% (mortality reduction) = 16,868 lives saved. In order to arrive 
at an even more conservative estimate of the benefits, we also 
estimate the reduction in deaths for a one-second decrease in 
ambulance response time. If reducing the response time by one minute 
results in reducing mortality by 17%, then we can estimate that 
reducing the response time by one second could lead to a reduction 
in mortality by one-sixtieth of 17%, i.e., 0.28% per year. We find 
that a one-second reduction in ambulance response time is equivalent 
to saving approximately 833 lives (5 million dispatches x 5.95% (90 
day mortality in Salt Lake City Study) x 0.28% (mortality reduction) 
= 833 lives saved).
    \446\ Although we believe the benefit due to the improvements in 
public safety would start accruing in the first year after the 
effective date of the rules (``year 1''), as some states are more 
advanced in migrating to NG911, we conservatively assume that all 
life-saving benefits would only accrue starting in year six through 
year ten. With 16,868 lives saved per year, we estimate that the 
total lives saved during years 6 through 10 would be 84,340 lives 
(16,868 lives per year x 5 years = 84,340 lives). While we do not 
attempt to place a value on human life, we note that the amount 
consumers are willing to pay to reduce mortality risk is 
approximately $12.5 million, using a methodology developed by the 
U.S. Department of Transportation (DOT) that we have relied on in 
past orders. See, e.g., LBR Order at *39, para. 118 & n.384 (citing 
the value of $12.5 million in 2022 based on U.S. Department of 
Transportation, Departmental Guidance on Valuation of a Statistical 
Life in Economic Analysis (May 7, 2024), https://www.transportation.gov/office-policy/transportation-policy/revised-departmental-guidance-on-valuation-of-a-statistical-life-in-economic-analysis). This implies a present value of the reduction of 
mortality risk of approximately $616 billion, a figure calculated 
using a 7% discount rate, consistent with Office of Management and 
Budget (OMB) guidance. See OMB, Circular A-4, Regulatory Analysis, 
sec. E, Discount Rates, Real Discount Rates of 3 Percent and 7 
Percent (Sept. 17, 2003), https://obamawhitehouse.archives.gov/omb/circulars_a004_a-4/ (``As a default position, . . . a real discount 
rate of 7 percent should be used as a base-case for regulatory 
analysis.'').

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

[[Page 78111]]

    The improvements to the 911 system associated with implementation 
of NG911 also will reduce 911 call failures and outages. We estimate 
that, from 2019 through 2023, an average of 4.1 billion user-hours of 
telecommunication voice service outages per year were reported to the 
Commission.\447\ If these 4.1 billion user-hours of outages were 
distributed evenly across the total U.S. population (approximately 335 
million people),\448\ this is equivalent to each person in the country 
experiencing an average of 12 hours of voice telecommunications service 
outages per year.\449\ Hence, we estimate that on average, consumers 
experience telecommunications outages 0.14% of the time per year.\450\ 
As noted above, available evidence shows that 911 calls resulted in 
28.5 million EMS dispatches per year during the most recent year when 
data was available. If service outages prevent 0.14% of these 911 calls 
from going through, that means 39,900 potentially life-saving emergency 
911 calls would be dropped per year as a result of legacy 911 system 
failures.\451\ If we conservatively estimate that our rules speeding 
the NG911 transition result in improved 911 emergency system 
reliability and thus reduce the number of 911 outages and call failures 
by just 1%, this would translate to an additional reduction in 
mortality risks associated with emergency medical situations for which 
ambulances were dispatched in response to 911 calls roughly equivalent 
to 23 lives saved per year (i.e., up to 115 lives saved over a five-
year period).\452\ Moreover, these benefits will continue to accrue 
beyond the completion of the transition of both phases.
---------------------------------------------------------------------------

    \447\ We estimate the average time consumers were affected by 
outages was approximately 4.1 billion user-hours per year based on 
data from the Commission's Network Outage Reporting System (NORS) 
between 2019 and 2023. Staff calculation. FCC, Network Outage 
Reporting System (NORS) (Nov. 30, 2023), https://www.fcc.gov/network-outage-reporting-system-nors.
    \448\ See U.S. Census Bureau, National Population Totals and 
Components of Change: 2020-2023 (Dec. 18, 2023), https://www.census.gov/data/tables/time-series/demo/popest/2020s-national-total.html (Census Population Estimates) (referring to Annual 
Estimates of the Resident Population for the United States, Regions, 
States, District of Columbia and Puerto Rico: April 1, 2020 to July 
1, 2023 (NST-EST2023-POP) on the page, which estimates U.S. 
population around 334,914,895 as of July 1, 2023).
    \449\ We calculate the average outages a U.S. resident 
experience as follows: 4.1 billion user-hours/335 million residents 
= 12.24 hours per resident, which we round to 12 hours.
    \450\ We estimate the average percentage of time U.S. consumers 
experience telecommunication network outages as follows: average 
12.24 hours of outages/(24 hours per day x 365 days per year) = 
0.14% outage per year.
    \451\ We estimate the life-threatening emergency 911 calls that 
would be dropped due to call failures or system outages as: 28.5 
million EMS dispatches x 0.14% outages = 39,900 potentially life-
saving emergency 911 calls dropped per year.
    \452\ A 1% reduction in call failures results in 23 lives saved 
(39,900 dropped calls per year x 1% reduction in call failures x 
5.95% (90 day mortality in Salt Lake City Study) = 23.74, rounded 
down to 23). Note that this calculation conservatively equates a 
dropped call with an approximately 3.5-second savings in response 
time based in the Salt Lake City Study. The study finds that the 
one-minute increase in response time caused mortality to increase 
17% at 90 days past the initial incidence, meaning that a 3.5-second 
increase in response time would cause a 1% (roughly 3.5/60 x 17%) 
mortality increase. The equivalent present value of the reduction in 
mortality risk is $840 million, calculated as follows: (23 lives x 
$12.5 million)/(1+7%)\6\ + (23 lives x $12.5 million)/(1+7%)\7\ + . 
. . + (23 lives x $12.5 million)/(1+7%)\10\ = $840 million. This 
uses the 7% discount rate. If we instead discount the life-saving 
benefit using a 3% discount rate, the estimated benefit would be 
$1.14 billion.
---------------------------------------------------------------------------

    We believe that our calculations above are likely a significant 
underestimate of the benefit of the rules and that the actual life-
saving rate from improved emergency responses will likely be higher 
than that used in our calculations. Whereas our analysis is based on 
saved lives in the context of emergency medical response, it does not 
account for lives saved due to more expeditious dispatch of police, 
firefighters, and other first responders in response to 911 emergency 
calls.\453\ Also, our estimate of the life-saving benefits of more 
expeditious and accurate completion of 911 calls (discussed above) 
excludes benefits from improvements to wireless 911 calls. The improved 
NG911 systems also are likely to yield benefits that go beyond the 
lives saved due to improved emergency medical responses (the primary 
basis for the benefit estimates discussed above); the analysis does not 
account for injuries prevented, other improved public health outcomes, 
and averted property damage due to quicker response to 911 calls 
associated with non-life-threatening events. Finally, our estimate 
includes 911 voice calls only and does not include text-to-911.
---------------------------------------------------------------------------

    \453\ See, e.g., Gregory DeAngelo, Marina Toger, & Sarit 
Weisburd, Police Response Time and Injury Outcomes, 133 The Economic 
Journal 2147 (2023); Brandon del Pozo, Reducing the Iatrogenesis of 
Police Overdose Response: Time Is of the Essence, 112(9) American 
Journal of Public Health 1236 (2022).
---------------------------------------------------------------------------

    911 Authorities' Cost Savings from Retiring Legacy 911 Network 
Components. Several commenting parties submit information indicating 
that our rules will enable 911 Authorities to realize cost savings by 
more rapidly decommissioning expensive legacy 911 network elements and 
replacing them with more cost-efficient IP networks. For instance, 
South Carolina RFA estimates that, when the NG911 transition is 
complete, enabling it to transmit all 911 traffic over its ESInet, it 
will no longer need to pay for the legacy selective routers, circuits, 
and trunks to provide TDM connectivity, which currently costs the state 
approximately $1.4 million per year. Minnesota DPS-ECN estimates the 
proposed rules will save the state over $1.1 million per year by 
avoiding paying for legacy 911 facilities that will become unnecessary 
when the NG911 transition is complete.\454\ The Ad Hoc NG911 Service 
Providers Coalition estimates that Florida will be able to avoid paying 
$1.6 million annually for selective routers and ANI/ALI databases 
supplied by the state's largest carrier once the NG911 transition is 
complete. Extrapolating these figures from commenters, we estimate the 
total cost saving nationwide would be between $24 million to $87 
million per year.\455\

[[Page 78112]]

Assuming these cost savings will not materialize until end of the fifth 
year following the effective date of the rules, we estimate that the 
present value of this cost-saving benefit over 10 years, using a 7% 
discount rate, is approximately $69 million to $255 million.\456\
---------------------------------------------------------------------------

    \454\ Minnesota DPS-ECN NG911 Notice Comments at 3 (stating that 
Minnesota spent $2.2 million on both legacy (LNG/LSR) and next 
generation (POIs) network components in 2022, with over 50% of the 
cost coming from supporting the legacy components).
    \455\ We calculate the range of cost savings by extrapolating 
from the figures reported by commenters. We divide each commenter's 
state level estimates by its state population to estimate the cost 
saving per person and multiply it by the U.S. population to get the 
nationwide cost-saving estimate. The upper bound of the range is 
calculated by dividing South Carolina RFA's cost saving estimate by 
its population: ($1,400,000/5,373,555 South Carolina population) x 
334,914,895 U.S. population = $87,257,105, rounded to $87 million. 
See South Carolina RFA NG911 Notice Comments at 4 (estimating the 
cost saving to be around $1.4 million per year); see also Census 
Population Estimates (estimating South Carolina population around 
5,373,555 and the U.S. population around 334,914,895 as of July 1, 
2023). The lower bound of the range is calculated by dividing NG911 
Service Providers Coalitions cost saving estimate for Florida by its 
population: ($1,600,000/22,610,726 Florida population) x 334,914,895 
U.S. population = $23,699,541, rounded to $24 million. See Ad Hoc 
NG911 Service Providers Coalition NG911 Notice Comments at 11-12 
(estimating a cost saving of $1.6 million per year); see also Census 
Population Estimates (estimating Florida population around 
22,610,726 persons and the U.S. population around 334,914,895 
persons as of July 1, 2023).
    \456\ To be conservative with the benefits estimates, we assume 
no accrual of benefits up to the end of year five, i.e., benefits 
only accrue from year six through year ten. The present value of the 
upper bound of total cost savings, using a 7% discount rate, is 
calculated as: $87,257,105/(1+7%) \6\ + $87,257,105/((1+7%) \7\) + . 
. . + $87,257,105/((1+7%) \10\) = $255,086,034 [ap] $255 million. 
The lower bound of the range is calculated using Florida's cost 
saving estimated by the Ad Hoc NG911 Service Providers Coalition: 
$23,699,541/(1+7%) \6\ + $23,699,541/((1+7%) \7\) + . . . + 
$23,699,541/((1+7%) \10\) = $69,282,861 [ap] $69 million. See Ad Hoc 
NG911 Service Providers Coalition NG911 Notice Comments at 11-12. 
Using a 3% discount rate, the present value over 10 years is 
approximately $94 million to $345 million.
---------------------------------------------------------------------------

2. Costs
    We sought comment on the costs that the 2,327 OSPs in the country 
would incur to comply with our proposed rules,\457\ and multiple 
parties submitted information in response. Based on information in the 
record and from other public sources, as well as data in service 
providers' most recent Form 477 filings,\458\ we conservatively 
estimate that, at the nationwide level, affected OSPs will likely incur 
approximately $4.4 million in one-time costs and $5.5 million in annual 
recurring costs to implement Phase 1, and $24 million in one-time costs 
and $50 million in annual recurring costs to implement Phase 2 
following adoption of our rules.\459\ Using a 7% discount rate, we 
estimate the present value of the total cumulative costs over the next 
10 years to be approximately $321 million.\460\ These expenditures 
would be fully justified even if they resulted in reducing mortality 
risks equivalent to preventing the loss of only 26 lives.\461\ 
Considering the substantial benefits to the improvement in public 
safety attributable to the rules, we conclude that the total benefits 
significantly outweigh the total costs.\462\
---------------------------------------------------------------------------

    \457\ NG911 Notice, 38 FCC Rcd at 6237-40, paras. 69-74.
    \458\ Based on FCC Form 477 data as of June 2023, there are a 
total of 2,287 OSPs, including 1,996 small/medium OSPs that serve up 
to 10,000 subscribers each and 291 large OSPs that serve more than 
10,000 subscribers each. The 1,996 small/medium OSPs include 16 
wireline OSPs that do not offer any form of IP services (e.g., 
broadband or VoIP services), 394 wireline OSPs that also provide 
broadband services, 14 internet-based TRS OSPs, 1,554 VoIP OSPs, and 
18 wireless OSPs. Among the 291 large OSPs, there are 2 wireline 
OSPs that do not offer any form of IP services (e.g., broadband or 
VoIP services), 20 wireline OSPs that also provide broadband 
services, 232 VoIP OSPs, and 37 wireless OSPs. Staff Calculation. 
FCC Form 477 Data as of June 2023. See also FCC, internet-Based TRS 
Providers (June 12, 2024), https://www.fcc.gov/general/internet-based-trs-providers (the 14 certified internet-based TRS providers 
are: CaptionCall, CaptionMate, ClearCaptions, Global Caption, 
Hamilton Relay, InnoCaption, Nagish, NexTalk, Rogervoice, T-Mobile 
USA, Convo Communications, Sorenson Communications, Tive, and ZP 
Better Together).
    \459\ We note that our cost estimates do not account for the 
fact that a number of OSPs have already complied with Phase 1 and/or 
Phase 2. To the extent that some OSPs have complied, there would be 
a reduction in estimated costs.
    \460\ We assume that it takes two years to complete Phase 1 and 
three years to complete Phase 2. To be conservative with the cost 
estimates, we assume all the costs of Phase 1 occur by the end of 
year one and the costs of Phase 2 occur by the end of year 3 instead 
of spreading it out through the remaining years during each phase. 
We calculate the present value of the total costs over a ten-year 
period using a 7% discount rate as follows: Phase 1 one-time cost 
$4,408,583/(1+7%) = $4,120,171; Phase 1 annual costs $5,544,000/
(1+7%) + $5,544,000/((1+7%) \2\) + . . . + $5,544,000/((1+7%) \10\) 
= $38,938,736; Phase 2 one-time cost $23,590,000/((1+7%) \3\) = 
$19,256,467; and Phase 2 annual costs $49,539,000/((1+7%) \3\) + . . 
. + $49,539,000/((1+7%) \10\) = $258,373,794. The present value of 
total costs over the 10 years is approximately $321 million 
($4,120,171+ $38,938,736 + $19,256,467 + $258,373,794 = 
$320,689,168, rounded to $321 million). If we instead discount the 
costs by 3%, the present value of the total costs over the next 10 
years is $401 million.
    \461\ We estimate that an expenditure of $321 million would 
justify the reduction of mortality risk by over 26 lives ($321 
million/$12.5 million = 25.68, rounded up to 26). If we calculate 
the total costs using a 3% discount rate, the present value of total 
costs increases to $401 million, which requires reducing mortality 
risks by 33 lives ($401 million/$12.5 million = 32.08, rounded up to 
33) to justify the adoption of the rules. We note that, using a 3% 
discount rate, the corresponding increase in benefits is even 
greater than the increase in costs.
    \462\ Our analysis does not include costs that 911 Authorities 
and other entities that have overwhelmingly supported the Proposals 
in the NG911 Notice have or would need to incur to effectuate the 
transition to NG911, including installing and placing into operation 
infrastructure needed to receive 911 traffic in an IP-based SIP 
format (Phase 1) and in an IP-based SIP format that complies with 
NG911 commonly accepted standards (Phase 2). We emphasize that the 
rules encourage 911 Authorities to effectuate the transition, but do 
not impose any requirements on 911 Authorities. As such, we do not 
include these additional costs in our analysis. Moreover, the rules 
are contingent on the transition to NG911 by 911 Authorities and the 
benefits and costs that we calculate cannot occur without said 
transition.
---------------------------------------------------------------------------

    Significantly, we believe that all of the quantitative cost 
estimates below are likely to be overstated, for several reasons. 
First, they do not take into account the fact that 911 calls make up 
only a very small portion of the overall number of voice calls that 
these OSPs will transmit using some of the same infrastructure. Second, 
they are based on estimated expenditures that cannot reasonably be 
attributed entirely to our NG911 rules because most OSPs are already on 
the path of transitioning to full modern IP networks for other reasons. 
Third, the assumed incremental expenditures for IP conversion may not 
materialize because many of the OSPs that have not yet completed IP 
network upgrades are likely to complete them before the deadlines for 
complying with any 911 Authorities' valid requests.
    Phase 1 Recurring Costs: Transport for IP Delivery Costs. OSPs will 
be required to transmit 911 calls to designated NG911 Delivery Points 
in IP format over SIP trunks within a specified period of time after 
911 Authorities issue valid Phase 1 requests. Because CMRS providers, 
interconnected VoIP providers, internet-based TRS providers, and non-
RLEC wireline providers are already delivering most calls in IP format, 
typically transported through SIP trunks,\463\ we believe that the 
Phase 1 IP transport requirement would not

[[Page 78113]]

impose material incremental costs on these OSPs.
---------------------------------------------------------------------------

    \463\ Based on FCC Form 477 data as of June 2023, there are a 
total of 2,287 OSPs, including 1,996 small/medium OSPs that serve up 
to 10,000 subscribers each and 291 large OSPs that serve more than 
10,000 subscribers each. The 1,996 small/medium OSPs include 16 
wireline OSPs that do not offer any form of IP services (e.g., 
broadband or VoIP services), 394 wireline OSPs that also provide 
broadband services, 14 internet-based TRS OSPs, 1,554 VoIP OSPs, and 
18 wireless OSPs. Among the 291 large OSPs, there are 2 wireline 
OSPs that do not offer any form of IP services (e.g., broadband or 
VoIP services), 20 wireline OSPs that also provide broadband 
services, 232 VoIP OSPs, and 37 wireless OSPs. Staff Calculation. 
FCC Form 477 Data as of June 2023. TelecomTrainer, What is VoLTE, 
and how does it enable voice communication in 4G networks? (Jan. 8, 
2024), https://www.telecomtrainer.com/what-is-volte-and-how-does-it-enable-voice-communication-in-4g-networks/ (``Voice over Long-Term 
Evolution (VoLTE) is a technology standard that allows voice calls 
to be transmitted over 4G LTE (Long-Term Evolution) networks, which 
are primarily designed for high-speed data transmission. VoLTE 
replaces the traditional circuit-switched voice calls used in older 
2G and 3G networks with packet-switched data to enable voice 
communication over LTE networks. . . . VoLTE relies on an IP 
(Internet Protocol) network to transmit voice data.''); TechTarget, 
What is 4G (fourth-generation wireless)?, https://www.techtarget.com/searchmobilecomputing/definition/4G (``4G is also 
an all-IP (internet protocol)-based standard for both voice and 
data, different from 3G, which only uses IP for data, while enabling 
voice with a circuit-switched network.'') (visited June 18, 2024); 
Jessica Dine and Joe Kane, The State of US Broadband in 2022: 
Reassessing the Whole Picture, Information Technology & Innovation 
Foundation (Dec. 5, 2022), https://itif.org/publications/2022/12/05/state-of-us-broadband-in-2022-reassessing-the-whole-picture/ (``U.S. 
mobile coverage is ubiquitous. 4G covers almost 100 percent of the 
population.''); CTIA, What to Know About the Sunsetting of 2G/3G 
Networks in Preparation for 5G, https://www.ctia.org/what-to-know-about-the-sunsetting-of-2g-3g-networks-in-preparation-for-5g (last 
visited June 18, 2024) (``Today, fewer than 9% of U.S. wireless 
connections are 2G or 3G subscriptions.'').
---------------------------------------------------------------------------

    Nonetheless, we recognize that some OSPs--primarily RLECs--will 
incur some incremental recurring cost of IP transport via SIP trunks, 
even if those RLECs already have IP switches, can convert TDM to IP on 
their own networks, and can provide broadband service using their own 
IP switching facilities. As some parties point out, these RLECs might 
incur some SIP call transport costs if they do not have settlement-free 
peering agreements and cannot hand off IP voice traffic to existing 
interconnection partners. We estimate that the total of these costs 
will be below $5.5 million per year. This estimate is based on 
assumptions that the transport cost would be $2,000 per month for the 
16 OSPs that currently only offer TDM-based voice services (i.e., they 
do not offer broadband or VoIP services) and serve fewer than 10,000 
subscribers, and 50% more (i.e., $3,000 per month) for the two OSPs 
that provide no broadband or VoIP but serve more than 10,000 
subscribers.\464\ We further assume that the 414 OSPs that offer both 
voice and broadband services--including the 394 that serve fewer than 
10,000 subscribers and the 20 that serve 10,000 or more subscribers--
would incur 50% of the transport cost because they are already 
delivering a portion of their regular calls in IP format via SIP 
trunks.\465\
---------------------------------------------------------------------------

    \464\ Comtech estimates that the transport cost per IP POI would 
be between $678.39 and $977.84 per month and the total 
interconnection cost would be $19,672.51 for 12 RLECs ($19,672.51/12 
~ $1,639.38 per RLEC), and MSCI estimates the IP transport cost per 
POI is $400 per month. See Letter from Susan C. Ornstein, Senior 
Director, Legal & Regulatory Affairs, Comtech, to Marlene H. Dortch, 
Secretary, FCC, PS Docket No. 21-479, Attach. at 11 (filed Mar. 8, 
2024) (estimating the IP-based connectivity cost per LEC POI site is 
between $678.39 and $977.84); Comtech Mar. 25, 2024 Ex Parte, 
Attach. at 22 (estimating a total cost, including NRC, MRC #1, and 
MRC #2, of 12 RLEC interconnections to be $19,672.51); Letter from 
Bennett L. Ross, Counsel on behalf of MSCI, to Marlene H. Dortch, 
Secretary, FCC, PS Docket No. 21-479, Attach. at 6 (filed Apr. 17, 
2024) (MSCI Apr. 17, 2024 Ex Parte); MSCI May 28, 2024 Ex Parte. We 
find the cost estimates submitted by Comtech and MSCI credible. To 
be conservative, we assume the SIP transport cost to be $2,000 per 
month for each small/medium OSP that serves no more than 10,000 
subscribers, and $3,000 per month for a large OSP that serve more 
than 10,000 subscribers. These estimates are consistent with those 
proposed by the majority of commenters. See Kansas RLECs NG911 
Notice Comments at 2, 4 (rec. Aug. 9, 2023) (Kansas RLECs NG911 
Notice Comments) (estimating between $1,200 and $5,000 per month in 
IP transport costs for its members); Home Telephone NG911 Notice 
Comments at 10 n.4 (estimating third-party IP transport of $1,500 to 
$3,000 per month); NTCA NG911 Notice Comments at 3 (stating the 
estimated cost is $1,400 for an RLEC in rural Kansas to deliver IP 
formatted 911 traffic to delivery points in California or Texas); 
South Dakota Telecommunications Association NG911 Notice Comments at 
11-12 (IP transport costs per RLEC could be between $1,000 and 
$13,000 per month per connection depending on distance); RTCC NG911 
Notice Comments at 25 (Nebraska RLECs would each have to pay 
approximately $1,350 per month for reliable SIP transport to connect 
to the IP delivery points in Colorado and Illinois).
    \465\ The figures on the number of OSPs that do not offer any 
form of IP services (e.g., broadband or VoIP services), and the 
numbers of subscribers that these and other OSPs serve are based on 
FCC Form 477 data as of June 2023. We calculate the recurring cost 
as follows: ($2,000 per month x 12 months x 16 small/medium 
telephone voice only wireline OSPs) + ($3,000 per month x 12 months 
x 2 large telephone voice only wireline OSPs) + ($2,000 per month x 
12 months x (50% partial transport) x 394 small/medium telephone 
voice and broadband wireline OSPs) + ($3,000 per month x 12 months x 
(50% partial transport) x 20 large telephone voice and broadband 
wireline OSPs) = $5,544,000, rounded to $5.5 million.
---------------------------------------------------------------------------

    We conclude that most of the RLECs' and other commenting parties' 
estimates of the recurring costs of IP transport \466\ to NG911 
Delivery Points are unduly high. Almost all of these cost estimates for 
911 IP transport are premised on assumptions that OSPs will be required 
to transmit 911 calls over long distances across multiple states to 
faraway NG911 Delivery Points.\467\ These assumptions are unfounded in 
light of the rules, which require OSPs to transport 911 calls only to 
in-state NG911 Delivery Points designated by 911 Authorities. Moreover, 
most of these cost estimates assume that the cost of IP transport is 
distance-sensitive. This assumption is clearly incorrect. Indeed, given 
the ample evidence showing that IP transport costs are significantly 
lower than TDM transport costs, we believe that the rules might 
actually reduce the overall transport costs for OSPs. For example, 
South Carolina RFA submits data indicating that IP transport of 911 
traffic is generally 27% cheaper than TDM call delivery, regardless of 
where the calls are delivered.\468\ iCERT points out that, to avoid the 
higher cost of transporting TDM calls, RLECs could convert their 
traffic from TDM to IP format prior to transporting them.\469\ Five 
Area Telephone also points out that OSPs could significantly lower the 
overall costs of transmitting 911 calls to ESInets by taking advantage 
of third-party aggregators' services.
---------------------------------------------------------------------------

    \466\ See, e.g., Kansas RLECs NG911 Notice Comments at 2, 4 
(estimating between $1,200 and $5,000 per month in IP transport 
costs for its members); Home Telephone NG911 Notice Comments at 10 
n.4 (estimating third-party IP transport of $1,500 to $3,000 per 
month); Letter from John Kuykendall, JSI Regulatory Advisor on 
behalf of the South Carolina Telephone Coalition, and Margaret M. 
Fox, Counsel to South Carolina Telephone Coalition, to Marlene H. 
Dortch, Secretary, FCC, PS Docket No. 21-479, at 1-2 (filed Nov. 17, 
2023) (asserting that South Carolina RLEC Sandhill Telephone 
Cooperative received estimates of approximately $2,700 per month and 
$3,500 per month for third-party IP transport).
    \467\ Five Area Telephone NG911 Notice Comments at 9, 11 
(estimating almost $3,000 per month for transport to ESInet points 
``hundreds of miles away in other states'' which would cost OSPs 
collectively over $83 million annually nationwide); NTCA NG911 
Notice Comments at 3 (stating an RLEC in rural Kansas has been 
ordered by the 911 authority to deliver IP formatted 911 traffic to 
delivery points in California or Texas, which would cost $1,400 per 
month); South Dakota Telecommunications Association NG911 Notice 
Comments at 11-12 (stating that IP transport costs per RLEC could be 
between $1,000 and $13,000 per month per connection depending on 
distance, and that cost could increase at least 30% for out-of-state 
connections); USTelecom NG911 Notice Comments at 4 (indicating that 
distance impacts IP transport prices, and one carrier is paying 
$750,000 in annual cost (or equivalent to $62,500 per month) to 
deliver 911 traffic to the state-designated delivery point hundreds 
of miles away); RTCC NG911 Notice Comments at 25 (stating that 
Nebraska RLECs would each have to pay approximately $1,350 per month 
for reliable SIP transport to connect to the IP delivery points in 
Colorado and Illinois, with an aggregate cost of $360,000 per year 
for the 24 RLECs); WTA NG911 Notice Comments at 6 (stating that it 
is not possible to fairly estimate transport costs without knowing 
where the delivery points are located and at what distance from 
RLECs).
    \468\ South Carolina RFA NG911 Notice Comments at 4-5 (stating 
that the network transport costs for ILECs in its state to deliver 
TDM traffic to two delivery points inside South Carolina are 
approximately $236,000 per year, while its analysis of the transport 
costs for the same South Carolina ILECs to deliver SIP traffic even 
further to two delivery points in Dallas, Texas and Raleigh, North 
Carolina are less--$172,000 per year, resulting in a 27% cost saving 
utilizing SIP). Comtech similarly estimates that transport costs for 
OSPs are likely to be far lower than the estimates provided in the 
record by RLECs. Comtech Mar. 25, 2024 Ex Parte, Attach. at 22.
    \469\ iCERT Dec. 13, 2023 Office of Commissioner Gomez Ex Parte 
at 2; see also Mission Critical Partners NG911 Notice Comments at 5; 
MSCI Apr. 17, 2024 Ex Parte, Attach. at 5 (estimating the annual 
transport cost for one POI through TDM is $42,810, compared to 
$4,800 for the transport through IP).
---------------------------------------------------------------------------

    Phase 1 Non-Recurring Costs: Reconfiguring Network Facilities for 
IP Delivery. We estimate Phase 1 non-recurring costs based on an 
assumption that some OSPs will incur some material and labor costs 
prior to initiating IP transport. We estimate a total of $4.4 million 
in one-time material and labor costs, including approximately $4 
million to convert TDM calls to IP format and $343,000 to configure the 
delivery to new NG911 Delivery Points. Because the majority of OSPs are 
capable of transmitting calls in IP format, we estimate that only a 
subset of OSPs that do not offer full IP-related services would need to 
incur the cost of facilities needed to convert TDM calls to IP format; 
other OSPs that already originate traffic in IP format would incur no 
up-front IP conversion costs. We conservatively estimate an upper bound 
of the IP conversion cost to be no more than $17,600 for voice-only 
OSPs with no more than 10,000

[[Page 78114]]

subscribers; \470\ a 50% higher unit cost for voice-only OSPs with more 
than 10,000 subscribers; and half of these amounts for OSPs that offer 
broadband as well as voice services and likely have some capability to 
convert TDM calls to IP format but might need to acquire more. We 
estimate that the total one-time cost that all OSPs would incur to 
obtain the facilities needed to convert TDM calls to IP format would be 
approximately $4 million, including $334,400 for the 18 OSPs that do 
not offer any IP services and $3.7 million for the 414 OSPs that offer 
broadband as well as voice services.\471\ We believe that our estimate 
is conservative because it does not take into account the many non-911 
calls that these OSPs would transmit using the same equipment.
---------------------------------------------------------------------------

    \470\ Five Area Telephone asserts that the up-front costs for 
RLECs to connect to ESInets are $17,600 each. Five Area Telephone 
NG911 Notice Comments at 11. We believe this estimate would be an 
upper bound, as OSPs may, instead of upgrading their systems with 
new circuits and switching equipment, choose to acquire an LNG 
gateway at a much lower cost to convert calls from TDM to IP format. 
Brian Rosen NG911 Notice Reply at 2 (``The RLECS commenting on this 
proceeding wildly overestimate the cost of the gateway required to 
convert TDM to SIP. An Audiocodes Mediant 500 gateway, for example, 
costs approximately $1,000, and a Mediant 1000, which has much more 
capability than a smaller carrier requires is approximately $5,000. 
There will need to be some software, which could run on a commodity 
server . . . which would add to the costs, and these carriers may 
not have enough expertise . . . necessitating a support contract 
with an appropriate vendor.'').
    \471\ We calculate the recurring cost as follows: ($17,600 per 
OSP x 16 small/medium telephone voice only wireline OSPs) + ($17,600 
per OSP x (1 + 50% for large OSP) x 2 large telephone voice only 
wireline OSPs) + ($17,600 per OSP x (50% partial transport) x 394 
small/medium telephone voice and broadband wireline OSPs) + ($17,600 
per OSP x (1 + 50% for large OSP) x (50% partial transport) x 20 
large telephone voice and broadband wireline OSPs) = $4,065,600, 
which we round to $4 million.
---------------------------------------------------------------------------

    We use Five Area Telephone's estimate of $17,600 as the upper bound 
for the up-front equipment costs for small OSPs to connect to ESInets--
an estimate that, according to Five Area Telephone, includes the costs 
of ``establishing network connectivity, procurement of private line 
circuits, configuration assistance, switching equipment configuration, 
testing, cutover, and final testing,'' equaling over $40 million if 
applied to all 2,327 carriers. We believe that this estimate 
substantially overstates the cost of the network equipment required to 
convert TDM calls to IP format, because it assumes a major system 
upgrade would be required, and we reject Five Area Telephone's 
assertion that the total cost would exceed $40 million because that 
erroneously assumes that all 2,327 OSPs would incur the same amount. 
Nonetheless, we apply Five Area Telephone's $17,600 one-time cost 
estimate as the basis to calculate the upper bound of our IP conversion 
cost estimate, because other commenters' estimates are even less 
credible. Most of them include the non-recurring cost of system 
upgrades that are not required by the rules; many of them rely on 
unsupported cost figures for specific OSPs without providing any basis 
for us to examine whether these costs are typical; and some include no 
cost figures at all.\472\
---------------------------------------------------------------------------

    \472\ See, e.g., Kansas RLECs NG911 Notice Comments at 2 
(contending that one NG911 service provider (AT&T) has proposed a 
plan that could require some Kansas RLECs to acquire SIP equipment 
at a cost of $50,000); RWA NG911 Notice Comments at 2 (contending 
that the Commission's estimate ignores the possibility that a small 
CMRS carrier would first need to obtain and install a session border 
control gateway for a cost of $100,000 to allow for the connection 
from the carrier's IP-cable network to a PSAP that remains only TDM-
capable); USTelecom NG911 Notice Comments at 4-5 (asserting that one 
Northern California carrier, prior to initiating IP transport, would 
need to expend an ``initial cost of $378,000 to aggregate traffic 
from multiple exchanges''); Frontier NG911 Notice Reply at 3-4 
(stating that central office facilities upgrades plus labor is in 
the ``millions'' to begin delivering IP call traffic outside its 
footprints, and equipment costs for SIP delivery are substantial); 
Alaska Telecom Assoc. NG911 Notice Comments at 4-5 (identifying 
costs for ``creating a dedicated IP trunk group to the ESInet,'' 
along with wireline network reconfigurations to reroute calls to the 
carriers' IP switch, updating the routing for subscriber lines, and 
similar SIP network architecture reconfigurations for wireless 
carriers).
---------------------------------------------------------------------------

    We estimate that the one-time costs of reconfiguring and changing 
911 traffic delivery points would require all affected OSPs to incur 
labor costs totaling $343,000. This is based on the Bureau of Labor 
Statistics' estimate that the average wage for telecommunications 
equipment installers and repairers is $32.26 per hour,\473\ as well as 
an estimate, based on evidence in the record, that OSPs serving fewer 
than 10,000 subscribers would need to pay for up to three hours of 
labor and OSPs serving more than 10,000 subscribers would need to pay 
50% more in labor costs due to the potentially more complex tasks these 
entities might need to undertake to reconfigure, and change the 
delivery points for their 911 traffic. We rely on the assertion of RWA 
that ``the number of person-hours required will typically be closer to 
two or three,'' \474\ rather than the one hour estimated in the NG911 
Notice,\475\ and we adjust this amount upward by 50% more for OSPs 
serving more than 10,000 subscribers to account for the greater 
complexity of the task. Based on these assumptions, we arrive at the 
total one-time labor cost of $343,000 for all the OSPs to change the 
delivery points.\476\
---------------------------------------------------------------------------

    \473\ See Bureau of Labor Statistics, Occupational Employment 
and Wages, May 2023 (Apr. 3, 2024), https://www.bls.gov/oes/current/oes492022.htm. According to the Bureau of Labor Statistics, as of 
December 2023, civilian wages and salaries averaged $31.29/hour and 
benefits averaged $14.13/hour. Total compensation therefore averaged 
$31.29 + $14.13 = $45.42. Press Release, Bureau of Labor Statistics, 
Employer Costs for Employee Compensation--December 2023 at 1 (Mar. 
13, 2024), https://www.bls.gov/news.release/archives/ecec_03132024.pdf. Using these figures, benefits constitute a markup 
of $14.13/$31.29 = 45%. We therefore mark up wages by 45% to account 
for benefits. $32.26 x 1.45 = $46.78, which we round to $47.
    \474\ RWA NG911 Notice Comments at 2 & n.5; South Carolina RLECs 
NG911 Notice Comments at 9-10 (arguing that one hour of labor to 
change delivery points is unrealistic, as this task requires 
``consulting with the ESInet regarding technical requirements, 
figuring out how transport will be handled and an appropriate 
demarcation point, procuring transport circuits to connect, 
configuring the lines and switching equipment, and then managing cut 
over of existing 911 traffic and testing to ensure the trunk is 
operable''). Frontier's assertion that the costs of labor plus 
facilities upgrades needed to begin delivering IP call traffic 
outside its network footprint will be ``millions'' is unfounded and 
implausible. Frontier NG911 Notice Reply at 3-4.
    \475\ NG911 Notice, 38 FCC Rcd at 6237-8, para. 71.
    \476\ We calculate the total one-time IP delivery configuration 
cost in Phase 1 as follows: ($47/hour x 3 hours x 1,996 small/medium 
OSPs serving no more than 10,000 subscribers) + ($47/hour x 3 hours 
x (1 + 50%) x 291 large OSPs serving more than 10,000 subscribers) = 
$342,982.50, rounding to $343,000.
---------------------------------------------------------------------------

    Phase 2 Costs. We estimate that wireline carriers, interconnected 
VoIP providers, and other OSPs that are not CMRS providers (and thus 
not subject to the LBR Order) will incur approximately $24 million in 
one-time costs and $50 million in annual recurring costs to comply with 
911 Authorities' Phase 2 requests to transmit and maintain accurate 
location information with 911 calls in IP format using LIS databases. 
The rules allow OSPs to use ``LIS as a service'' from a third-party 
vendor as an option instead of creating their own LIS or equivalent 
databases. This LIS service may either involve native IP LIS or LIS 
equivalent database population, or a database conversion of OSPs' 
existing ALI/ANI/MSAG data to LIS formats. 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.\477\ This is a substantial cost-savings measure,

[[Page 78115]]

especially for smaller OSPs with TDM networks, who may not be ready to 
decommission older legacy equipment and modernize their networks for 
IP/VoIP.\478\
---------------------------------------------------------------------------

    \477\ CSRIC NG911 Transition Report at secs. 5.1.1.2.2.3, 
5.1.2.1 (``LIS or equivalent elements may be operated directly by 
originating service providers, by their chosen vendors, or possibly 
by a 9-1-1 Authority, a set of 9-1-1 Authorities, or their vendors 
as a service to carriers.'').
    \478\ See, e.g., Brian Rosen NG911 Notice Reply at 17 (``The LNG 
contains the Location Database (LIS) which is analogous to the ALI 
in that there is a record per subscriber (for wireline subscribers) 
typically indexed by telephone number. The TDM signaling contains 
all the information needed for the LNG to retrieve the location from 
its database and insert it in the SIP signaling towards the ESInet. 
As above, there are data format and provisioning changes wireline 
OSPs will need to make, but there are many ESInets with functioning 
LNGs that handle RLECs well. And, as above, wireline OSPs will 
continue to use street address (civic) location formats, albeit 
those formats are different than the current MSAG based 
standards.'').
---------------------------------------------------------------------------

    We conservatively base these figures on Five Area Telephone's 
estimates that, to comply with location-based routing-type requirements 
to insert location information into call paths, wireline and VoIP 
providers would need to incur non-recurring costs of approximately 
$10,000 and monthly recurring costs of $1,750. Extrapolating these 
statistics and increasing the costs by 50% for larger OSPs serving more 
than 10,000 subscribers, we estimate that compliance with the Phase 2 
rules would require non-CMRS OSPs to incur a total of $24 million in 
one-time costs and $50 million in annual recurring costs.\479\ We 
conclude that the location information requirement does not result in 
any additional costs for CMRS providers because they will have already 
implemented such upgrades.\480\
---------------------------------------------------------------------------

    \479\ We calculate the one-time cost as follows: ($10,000 per 
OSP x 1,978 small/medium wireline and VoIP OSPs) + ($10,000 x (1 + 
50%) x 254 large wireline and VoIP OSPs) = $23,590,000. Staff 
Calculation. FCC Form 477 Data as of June 2023. We calculate the 
annual cost following the same approach: ($1,750 per month x 12 
months x 1,978 small/medium wireline and VoIP OSPs) + ($1,750 per 
month x 12 months x (1 + 50%) x 254 large wireline and VoIP OSPs) = 
$49,539,000, rounding to $50 million.
    \480\ LBR Notice, 37 FCC Rcd at 15210, para. 70 n.176 (``AT&T's 
implementation of location-based routing uses Intrado's `Locate 
Before Route' feature and `implemented several timer changes in the 
GMLC housing AT&T [Location Information Server (LIS)],' '' citing 
AT&T LBR Public Notice Comments at 2, 5 (rec. July 11, 2022)); T-
Mobile July 26, 2023 Ex Parte, Exh. B (asking if the PSAP requesting 
NG911 service is served by an ESInet/NGCS capable of supporting 
standards based NG911 connectivity to T-Mobile's LIS).
---------------------------------------------------------------------------

    We reject AT&T's cost estimate submitted in the record. AT&T 
alleges that ``requiring the introduction of a Location Information 
Server (`LIS') would be extremely expensive and inefficient'' for 
carriers with legacy TDM switching facilities and ``could cost several 
billion dollars on an industry-wide basis.'' AT&T, in its role as the 
lead NGCS and ESInet contractor in Virginia,\481\ has already provided 
a solution that allows legacy OSP wireline ALI and MSAG location data 
to be used for NG911-compliant LIS as a service,\482\ which eliminates 
TDM OSPs' needs to upgrade their networks to IP. We therefore find 
AT&T's record assertion was based on an assumption of an IP origination 
requirement, which we decline to impose.
---------------------------------------------------------------------------

    \481\ Virginia Department of Emergency Management, NG9-1-1 
Deployment-Summary of the project, https://ngs.vdem.virginia.gov/pages/ng9-1-1-deployment (last visited June 21, 2024) (``The project 
contractor, AT&T, tracks status for 19 project items, such as AVPN 
ordered and trunk complete.''); see also Virginia Department of 
Emergency Management (VDEM) 9-1-1 and Geospatial Services Bureau 
(NGS), [no title] (Aug. 29, 2022), https://gismaps.vdem.virginia.gov/websites/ngs/NG9-1-1%20Deployment/documents/FFXVBComp_NGS.pdf (summarizing ``high level information 
about the Fairfax County and VA Beach Next Generation 9-1-1 (NG9-1-
1) contracts'').
    \482\ Virginia Department of Emergency Management, MSAG and ALI 
Maintenance After Next Generation 9-1-1 Go-Live at 1 (Nov. 2022), 
https://gismaps.vdem.virginia.gov/websites/PSC/RegionalAdvisoryCommittee/Documents/20221117MSAGALIMaint.pdf 
(``Wireline phone providers require the MSAG and ALI information 
until they upgrade their systems to the NG9-1-1 end state 
environment. Therefore, after NG9-1-1 go live, Virginia localities 
must continue to maintain MSAG and ALI databases, now in the AT&T 
and Intrado environment''); id. at 3 (describing solution for ``when 
a PSAP is live on NG9-1-1 and their legacy 9-1-1 provider still 
requires a legacy ALI database'').
---------------------------------------------------------------------------

    Our Phase 2 cost estimate does not include the costs of originating 
traffic in IP format. WTA claims that ``obtaining the full benefits of 
NG911 service will not be possible unless 911 calls originate in IP 
format,'' and that converting networks from TDM to IP carries ``not 
only significant network and customer equipment changes and 
reconfigurations, but also substantial customer service and education 
costs.'' Although we agree that converting TDM networks to IP networks 
can be costly, we reject the contention that such system upgrade costs 
should be attributed to the requirements in these rules. The transition 
from TDM to IP technology has been ongoing for over a decade as the 
subscriptions to voice-only local exchange telephone service (switched 
access lines) has fallen from nearly 141 million lines in December 2008 
to 27 million in June 2022.\483\ A linear model predicts that switched 
access lines will be fully phased out in the near future.\484\ 
Therefore, since we can reasonably expect that these system upgrades 
will occur organically as part of the natural technological evolution, 
regardless of whether OSPs are required to comply with Phase 2 
requests, the cost of the upgrades cannot be attributed to these 
requirements. Instead, they should be considered baseline costs of 
operating telecommunications business. Furthermore, even if a handful 
of RLECs delayed their system upgrades for idiosyncratic reasons, the 
6- to 12-month timeline to comply with the requirements for each of the 
two phases would be sufficient for RLECs to move away from the legacy 
systems that are beyond end of their life.
---------------------------------------------------------------------------

    \483\ See FCC, Voice Telephone Services Report, (Aug. 18, 2023), 
https://www.fcc.gov/voice-telephone-services-report (linking to 
Nationwide and State-Level Data for 2008-Present (Zip), https://www.fcc.gov/sites/default/files/vts_june_22_hist.zip (containing 
``VTS_subscriptions_hist.csv;'' Reference row 13 ``Local exchange 
telephone service (Switched Access Lines)'' shows that there were 
140,958,000 subscriptions in December 2008 which declined steadily 
year-over-year to 27,207,000 subscriptions in June 2022)). 
Relatedly, the RLEC Coalition states that ``current discussions 
suggest'' that purchasing LIS services from a third party could cost 
as much as 1 dollar per month per telephone location for RLEC 
subscriber lines. RLEC Coalition July 5, 2024 Ex Parte at 8 (stating 
that the cost would be approximately $0.50 to $1.00 per telephone 
number location per month). However the RLEC Coalition provides no 
support for this estimate beyond unnamed ``discussions'' with 
parties unknown. Id. Accordingly, we continue to find Five Area 
Telecom's detailed breakout and analysis of LIS cost elements 
reliable. Five Area Telecom NG911 Notice Comments at 5-6. 
Furthermore, even if LIS costs were near the RLEC Coalition's 
figure, we observe that these costs will decline rapidly because 
OSPs migrating to IP and retiring their TDM facilities can also 
retire the LNGs they need to use LIS with ALI/ANI/MSAG data. See 
Brian Rosen NG911 Notice Reply at 17; Virginia Department of 
Emergency Management, MSAG and ALI Maintenance After Next Generation 
9-1-1 Go-Live at 3 (Nov. 2022), https://gismaps.vdem.virginia.gov/websites/PSC/RegionalAdvisoryCommittee/Documents/20221117MSAGALIMaint.pdf.
    \484\ A linear model estimates Expected Subscriptions = 
17,117,250.6-8,455.4 Year, which implies the Expected Subscriptions 
= 0 when Year = 2024.4 (or May in 2024 because 0.4 x 12 months = 4.8 
months). The linear model fits the data well with a R\2\ = 0.97, 
meaning 97% of the data variation is explained by the linear model. 
A linear model predicts the switched access lines would have been 
fully phased out in May 2024. Therefore, if the system upgrades 
would have happened organically as part of the natural technological 
evolution, they should be considered costs of operating 
telecommunications business. Furthermore, even if a handful of RLECs 
delayed their system upgrades for idiosyncratic reasons, the 6- to 
12-month timeline to comply with the requirements for each of the 
two phases would be sufficient for RLECs to move away from the 
legacy systems that are beyond end of their life.
---------------------------------------------------------------------------

    We emphasize that the rules do not require OSPs to originate 911 
calls in IP format, and hence OSPs can choose other alternative 
solutions to send 911 calls in the format that can be interoperable 
with the industry standards in Phase 2. Moreover, our rules do not 
preclude OSPs from negotiating with 911 Authorities for alternative 
arrangements. If the costs of upgrading network systems are as high as 
some OSPs claim, those entities could offer 911 Authorities 
alternative, less costly arrangements, such as offering to pay the 911 
Authorities to

[[Page 78116]]

maintain the costly legacy conversion components for these OSPs to use 
in order to fulfill the requirements. Nonetheless, in light of the 
ample record evidence that most 911 Authorities are eager to 
decommission these legacy facilities due to the high cost of 
maintaining them (as well as the limitations on these facilities' 
functionality), we believe it is highly unlikely that any OSP would 
find such an arrangement to be cost-effective, especially when compared 
with the cost of upgrading their own networks--upgrades that they 
almost certainly will need to implement within the applicable time 
frame for reasons that have nothing to do with these NG911 rules.

H. Implementation, Monitoring, and Compliance

    In the NG911 Notice, the Commission sought comment on whether the 
Commission should implement any new data collections to assist in 
monitoring compliance with our proposed rules for NG911.\485\ The 
Commission tentatively concluded that public safety entities and 
members of the public seeking to report non-compliance with the 
proposed rules would be able to file complaints via the Public Safety 
and Homeland Security Bureau's Public Safety Support Center or through 
the Commission's Consumer Complaint Center.\486\ The Commission did not 
propose any rule for monitoring the transition to NG911 or addressing 
compliance with the new requirements.
---------------------------------------------------------------------------

    \485\ NG911 Notice, 38 FCC Rcd at 6231, para. 57.
    \486\ Id. at 6232, para. 58. The Public Safety Support Center is 
a web-based portal that enables PSAPs and other public safety 
entities to request support or information from the Public Safety 
and Homeland Security Bureau and to notify it of problems or issues 
impacting the provision of emergency services. Public Safety and 
Homeland Security Bureau Announces Opening of Public Safety Support 
Center, Public Notice, 30 FCC Rcd 10639 (PSHSB 2015); FCC, Public 
Safety Support Center, https://www.fcc.gov/general/public-safety-support-center (last visited June 6, 2024). The Consumer Complaint 
Center handles consumer inquiries and complaints, including consumer 
complaints about access to 911 emergency services. See FCC, Consumer 
Complaint Center, https://consumercomplaints.fcc.gov/hc/en-us (last 
visited June 6, 2024).
---------------------------------------------------------------------------

    We believe the existing complaint mechanisms should be sufficient 
and that the Commission would be able to address complaints in a timely 
manner. A handful of commenters state that existing mechanisms of 
oversight should be sufficient.\487\ AT&T and Hamilton Relay agree that 
the Commission should decline to adopt any new data collections. 
Colorado PUC states that the Commission ``should be prepared to engage 
with complaints in a timely manner.'' \488\ WTA, on the other hand, 
requests that the Commission ``establish one or more mechanisms that 
will encourage and enable the negotiation of and dispute resolution for 
more efficient and equitable ESInet location arrangements and/or more 
equitable distribution of or compensation for the additional costs of 
the ultimate NG911 configuration.'' \489\ As we discuss above, we 
establish a procedure in which an OSP, within 60 days of the receipt of 
a Phase 1 or Phase 2 valid request, may submit a petition to PSHSB 
asserting that the 911 Authority has failed to meet the requirements of 
a Phase 1 or 2 valid request. In cases where OSPs and 911 Authorities 
negotiate alternative arrangements, we require that OSPs notify the 
Commission of any alternative agreement and the pertinent terms of that 
agreement. This requirement ensures the Commission maintains proper 
oversight of the nationwide NG911 transition and awareness of any 
technical implementation issues that may arise. Furthermore, in 
addition to the OSP petition procedure we adopt, we believe that the 
existing avenues within the Commission, as well as the rules, are 
sufficient for monitoring the transition and compliance, and for 
addressing disputes.
---------------------------------------------------------------------------

    \487\ Maine PUC NG911 Notice Comments at 3 (``[E]xisting 
mechanisms of oversight should be sufficient.''); NASNA NG911 Notice 
Comments at 11 (``NASNA agrees that existing mechanisms of oversight 
should be sufficient. However, in the event actual implementation of 
the States' NG911 deployments are delayed and existing mechanisms 
are found to be ineffective, NASNA will urge the Commission's 
reconsideration.''); see AT&T NG911 Notice Comments at 11 
(indicating that additional compliance reporting is not required).
    \488\ Colorado PUC NG911 Notice Reply at 11 (stating that 
``COPUC believes that states and jurisdictions are in the best 
position to monitor compliance and inform the Commission if there 
are providers who refuse to comply'').
    \489\ WTA NG911 Notice Comments at 7 (suggesting that the 
Commission ``could establish a process whereby a state's voice 
service providers could request and obtain Commission oversight and 
mediation of negotiations regarding proposed revisions to a state or 
regional ESInet location plan'').
---------------------------------------------------------------------------

    Finally, Comtech ``urges the Commission to place formal complaints 
regarding OSP noncompliance on the Commission's Accelerated Docket,'' 
\490\ which is a complaint mechanism that is available for selected 
formal complaints.\491\ Proceedings on the Accelerated Docket must be 
concluded within 60 days, and are therefore subject to shorter pleading 
deadlines and other modifications to the procedural rules that govern 
formal complaint proceedings.\492\ Given that our rules afford 
Commission staff the discretion to decide whether a complaint, or 
portion of a complaint, is suitable for inclusion on the Accelerated 
Docket,\493\ we decline Comtech's suggestion to default to the 
Accelerated Docket for complaints regarding OSP noncompliance.
---------------------------------------------------------------------------

    \490\ Comtech NG911 Notice Comments at 11 (``Specifically, 
Comtech encourages the Commission to establish an expedited process 
when formal complaints are filed related to disputes in order to 
minimize extensive delays in the deployment of NG911 services.'').
    \491\ FCC, A Guide to Public Safety Enforcement, https://www.fcc.gov/reports-research/guides/guide-public-safety-enforcement 
(last visited June 6, 2024); see 47 CFR 1.736.
    \492\ 47 CFR 1.736(a).
    \493\ 47 CFR 1.736(d).
---------------------------------------------------------------------------

I. Promoting Digital Equity and Inclusion

    As noted in the NG911 Notice, the Commission is engaged in a 
continuing effort to advance digital equity for all, including people 
of color, persons with disabilities, persons who live in rural or 
Tribal areas, and others who are or have been historically underserved, 
marginalized, or adversely affected by persistent poverty or 
inequality.\494\ The NG911 Notice invited comment on equity-related 
considerations and benefits, if any, that may be associated with the 
proposals and issues under consideration.\495\ Specifically, the 
Commission sought comment on how its proposals may promote or inhibit 
advances in diversity, equity, inclusion, and accessibility.\496\
---------------------------------------------------------------------------

    \494\ NG911 Notice, 38 FCC Rcd at 6234, para. 63.
    \495\ Id.
    \496\ Id.
---------------------------------------------------------------------------

    Several parties submitted comments indicating that the transition 
to NG911 would promote digital equity and inclusion. Richard Ray 
``support[s] the implementation and deployment of NG9-1-1 to provide 
direct, equal, and meaningful access to emergency services for 
everyone, including individuals with disabilities, using all four 
elements: voice, video, text, and data.'' \497\ CEA concurs with a 
previous Commission statement that adding video, text, and image 
capabilities to the 911 system will ``make the system more accessible 
to the public,'' including ``for people with disabilities.'' \498\ NENA

[[Page 78117]]

states that NG911 introduces a variety of capabilities to support 
persons with disabilities and marginalized groups.\499\ NASNA states 
that it ``believes in providing equal access to 911 services to all 
citizens through local NG911 systems.'' These regulations to advance 
the nationwide transition to NG911 will significantly promote and 
enable vital 911 access for individuals with disabilities, including 
through internet-based TRS and video/data capabilities.
---------------------------------------------------------------------------

    \497\ Richard Ray Sept. 15, 2023 Ex Parte at 3; id. at 8 (``When 
NG9-1-1 is deployed, it will give individuals who are deaf, 
deafblind, late-deafened, hard of hearing, or who have speech 
disabilities the opportunity to call a PSAP directly rather than via 
internet-based relay services such as Video Relay Service and 
Internet Protocol Relay Service.'').
    \498\ CEA NG911 Notice Comments at 10 (quoting Facilitating the 
Deployment of Text-to-911 and Other Next Generation 911 
Applications, Framework for Next Generation 911 Deployment, PS 
Docket Nos. 11-153 and 10-255, Notice of Proposed Rulemaking, 26 FCC 
Rcd 13615, 13616, para. 1 (2011), 76 FR 63257 (Oct. 12, 2011)).
    \499\ NENA NG911 Notice Comments at 14-15 (discussing an NG911 
capability that allows callers to directly connect with a caller 
that supports their language and media).
---------------------------------------------------------------------------

    Certain RLEC commenters contend that the NG911 rules will have 
adverse effects on one particular group included in the Commission's 
initiative to promote digital equity and inclusion: persons who live in 
rural areas. South Carolina Telephone Coalition argues that imposing 
additional costs on RLECs without simultaneously changing high-cost 
universal service support would result in ``a system that 
disproportionately benefits wireless callers through enhanced texting 
and video capabilities makes no sense and will ultimately hurt rural 
Americans.'' South Dakota Telecommunications Association states that 
requiring ``transport to out-of-state points of interconnection (POIs) 
will add cost, which will need to be recovered from either the 
Universal Service Fund (USF) or the end-user's customers.'' As we 
discuss above, we are tempering costs to RLECs and other OSPs by 
requiring 911 Authorities to designate NG911 Delivery Points within 
their own states. Moreover, the rules we adopt do not require RLECs and 
other OSPs to extend their physical networks, and RLECs and other OSPs 
may retain other entities to transmit 911 traffic to the NG911 Delivery 
Points specified by the 911 Authorities. Accordingly, we expect that 
RLECs' increased NG911-related costs are likely to be relatively 
modest, thus limiting the cost increases to be passed on to rural 
subscribers.
    On the other hand, Rally Networks argues that, especially in rural 
communities, ``NG911 provides an opportunity for resources to be more 
appropriately dispatched before first responders arrive on scene and 
evaluate the need.'' We agree. As we discuss above, NG911 
implementation will yield substantial benefits to consumers, including 
rural subscribers, due to the improved functionalities it supports, its 
capacity to deliver a greater range of information from 911 callers to 
PSAPs and first responders, the increased security, reliability, and 
interoperability of NG911 networks, and the likelihood that 911 calls 
will be delivered to first responders more rapidly and accurately, thus 
saving lives. We conclude that our NG911 rules would advance digital 
equity for all, including for persons who live in rural areas.
    In sum, we acknowledge the importance of the continuing effort to 
advance digital equity for all. We believe that the rules, requiring 
OSPs to take actions to start the transition to NG911 in coordination 
with 911 Authorities, will help to advance those goals.

IV. Procedural Matters

    Regulatory Flexibility Act. The Regulatory Flexibility Act of 1980, 
as amended (RFA),\500\ requires that an agency prepare a regulatory 
flexibility analysis for notice and comment rulemakings, unless the 
agency certifies that ``the rule will not, if promulgated, have a 
significant economic impact on a substantial number of small 
entities.'' \501\ Accordingly, we have prepared a Final Regulatory 
Flexibility Analysis (FRFA) concerning the possible impact of the rule 
changes contained in this document and the Order on small entities. The 
FRFA is set forth in Appendix B of the Order.
---------------------------------------------------------------------------

    \500\ See 5 U.S.C. 604. The RFA, 5 U.S.C. 601-612. The RFA was 
amended by the Small Business Regulatory Enforcement Fairness Act of 
1996 (SBREFA), Public Law 104-121, Title II, 110 Stat. 857 (1996).
    \501\ 5 U.S.C. 605(b).
---------------------------------------------------------------------------

    Paperwork Reduction Act of 1995 Analysis. This document and the 
Order contain new information collection requirements in Sec.  9.31(a), 
(b), and (c), and Sec.  9.34(a) and (b), that are subject to the 
Paperwork Reduction Act of 1995 (PRA), Public Law 104-13. These rules 
will be submitted to the Office of Management and Budget (OMB) for 
review under section 3507(d) of the PRA.\502\ OMB, the general public, 
and other Federal agencies will be invited to comment on the new 
information collection requirements contained in this proceeding. In 
addition, we note that, pursuant to the Small Business Paperwork Relief 
Act of 2002,\503\ we previously sought specific comment on how the 
Commission might further reduce the information collection burden for 
small business concerns with fewer than 25 employees. We received a few 
such comments. South Carolina states that ``a simple certification by 
providers that they are in compliance with requirements for delivery of 
calls in IP format to the designated demarcation points is sufficient 
rather than creating additional burdens on the providers for reporting 
requirements.'' As we indicate above, we are not imposing requirements 
to report compliance with the rules. We received a comment relevant to 
our new information collection requirement for OSPs and 911 Authorities 
that enter into agreements, which requires the OSP to notify the 
Commission. Alaska Telecom Assoc. ``agrees'' that providing OSPs and 
911 Authorities ``the flexibility to negotiate an alternative time 
frame'' is ``a significant step to minimize the economic impact for 
small entities.'' \504\ The Commission does not believe that the new 
information collection requirements in Sec.  9.31(a), (b), and (c), and 
Sec.  9.34(a) and (b), will be unduly burdensome on small businesses. 
We describe impacts that might affect small businesses, which includes 
most businesses with fewer than 25 employees, in the FRFA in Appendix B 
of the Order.
---------------------------------------------------------------------------

    \502\ 44 U.S.C. 3507(d).
    \503\ Public Law 107-198, 116 Stat. 729 (2002) (codified at 44 
U.S.C. 3506(c)(4)).
    \504\ Alaska Telecom Assoc. NG911 Notice Comments at 9 (also 
stating that even if the FCC provides such flexibility, ``the FCC 
should still adopt longer implementation timeframes than proposed in 
the NPRM'' for smaller providers'').
---------------------------------------------------------------------------

V. Final Regulatory Flexibility Analysis

    As required by the Regulatory Flexibility Act of 1980, as amended 
(RFA), an Initial Regulatory Flexibility Analysis (IRFA) was 
incorporated in NG911 Notice adopted in June 2023. The Commission 
sought written public comment on the proposals in the NG911 Notice, 
including comments on the IRFA. One comment was filed addressing the 
IRFA. This Final Regulatory Flexibility Analysis (FRFA) conforms to the 
RFA.

A. Need for, and Objectives of, the Final Rules

    In the NG911 Notice, the Commission proposed a framework to advance 
the nationwide transition to NG911. Like communications networks 
generally, dedicated 911 networks are evolving from TDM-based 
architectures to IP-based architectures. With the transition to NG911, 
911 Authorities (i.e., 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 the PSAPs) will replace the circuit-switched 
architecture of legacy 911 networks with IP-based technologies and 
applications, which provide new capabilities and improved 
interoperability and system

[[Page 78118]]

resilience. Most States have invested significantly in NG911, but some 
report that they are experiencing delays in providers connecting to 
these IP-based networks. As a result of these delays, the transition to 
NG911 is being delayed, and State and local 911 authorities incur 
prolonged costs because of the need to maintain both legacy and IP 
networks during the transition. Managing 911 traffic on both legacy and 
IP networks also results in increased vulnerability and risk of 911 
outages.
    In the Order, the Commission adopted rules and procedures to 
expedite the NG911 transition that will apply to all wireline, 
Commercial Mobile Radio Service (CMRS), covered text, interconnected 
Voice over Internet Protocol (VoIP), and internet-based 
Telecommunications Relay Service (TRS) providers (collectively, 
Originating Service Providers or OSPs for purposes of this proceeding) 
as 911 Authorities transition to IP-based networks and develop the 
capability to support NG911 elements and functions. Specifically, we 
require OSPs to complete necessary network upgrades to complete the 
transition to NG911 in two phases, triggered at each phase by separate 
valid requests of 911 Authorities who have completed their required 
NG911 technology upgrade readiness for that phase. At Phase 1, OSPs 
must deliver 911 traffic in IP format to NG911 Delivery Points 
designated by 911 Authorities, such as an Emergency Services IP network 
(ESInet) or similar designated point. All Phase 1 requirements must be 
completed in order to progress to Phase 2. At Phase 2, OSPs must 
deliver traffic in fully compliant NG911 format to include information 
that enables routing to the correct Public Safety Answering Point 
(PSAP), as well as caller location information, in the IP Session 
Initiation Protocol (SIP) header of the IP-delivered 911 call.
    Smaller wireline providers (such as Rural Incumbent Local Exchange 
Carriers (RLECs)), non-nationwide CMRS providers, and internet-based 
TRS providers will have one year following a 911 Authority request to 
comply with each phase of the transition. Larger wireline providers, 
nationwide CMRS providers, covered text providers, and interconnected-
VoIP providers will have six months to comply with a valid request with 
each phase of the transition. For all OSPs, the initial compliance date 
will be extended based on the effective date of the rules--i.e. no OSP 
must comply with a 911 Authority Phase 1 request sooner than one year 
after the effective date of these rules, regardless of the timing of 
the 911 Authority's request. This timing rule is similar to the 
requirements adopted for CMRS and covered text providers in our recent 
proceeding on wireless location-based routing.
    The Commission's two-phased approach allows OSPs and states or 
localities to negotiate alternate agreements on cost recovery terms. 
However, in the absence of alternate agreements by states or 
localities, OSPs must cover the costs of transmitting 911 calls to the 
NG911 Delivery Points designated by a 911 Authority starting in Phase 
1. OSPs bear responsibility for any costs associated with completing 
the TDM-to-IP translation necessary to deliver such calls and 
associated routing and location information in the requested IP-based 
format. Thus, the NG911 Delivery Point becomes the network demarcation 
point for allocating all 911 network costs between the OSP portions of 
the network and the state and local government portions of the network. 
States and localities can establish alternative cost allocation 
arrangements with OSPs. However, OSPs are presumptively responsible for 
all the costs associated with delivering traffic to the NG911 Delivery 
Point identified by the appropriate 911 Authority in the absence of any 
such alternative arrangements.
    Expediting the NG911 transition will help ensure that the nation's 
911 system functions effectively and reliably, and with the most 
advanced capabilities available. In the Order, the Commission's actions 
also respond to the petition filed in 2021 by the National Association 
of State 911 Administrators (NASNA), urging the Commission to resolve 
uncertainty and disputes between OSPs and state 911 Authorities 
regarding the NG911 transition. With the rules we adopt, the Commission 
creates a consistent framework for ensuring that OSPs take the 
necessary steps to implement the transition to NG911 capability in 
coordination with state and local 911 Authorities. The rules also align 
the NG911 transition requirements for all OSPs with similar Commission 
requirements adopted for CMRS in the LBR Order, thereby promoting 
consistency across service platforms. Finally, the demarcation point 
and cost allocation rules the Commission adopted in the Order address 
``the critical component, and biggest regulatory roadblock, to 
transitioning to NG911 services.''

B. Summary of Significant Issues Raised by Public Comments in Response 
to the IRFA

    One commenter, RTCC, raises significant issues in response to the 
IRFA. RTCC states that the Commission's initial estimate in the NG911 
Notice that only 8.5% of RLECs would incur 911 IP call transport costs 
``lack[s] a factual foundation'' and therefore ``call[s] into question 
the reliability and sustainab[ility]'' of the IRFA. We disagree. 
Further, while not raised in response to the IRFA, comments filed by 
RLECs also raise cost-related concerns associated with the IP transport 
rule proposed in the NG911 Notice. Following the Commission's review of 
comments from multiple parties associated with our cost estimates in 
the NG911 Notice, including comments submitted in the record by RLECs, 
the Order adjusted the cost estimates to implement the requirements to 
advance the nationwide transition to Next Generation 911. In response 
to comments, the Order also modified the proposed rules to 
substantially minimize any significant cost impacts on small 
businesses. We discuss RTCC and RLECs concerns in Section E of the 
FRFA, as well as modifications adopted in the Order in Section F of the 
FRFA. Accordingly, the Commission concludes that the IRFA included in 
the NG911 Notice was sound and has fulfilled its purposes in 
satisfaction of the requirements of the RFA.

C. Response to Comments by the Chief Counsel for Advocacy of the Small 
Business Administration

    Pursuant to the Small Business Jobs Act of 2010, which amended the 
RFA, the Commission is required to respond to any comments filed by the 
Chief Counsel for Advocacy of the Small Business Administration (SBA), 
and to provide a detailed statement of any change made to the proposed 
rules as a result of those comments. The Chief Counsel did not file any 
comments in response to the proposed rules in this proceeding.

D. Description and Estimate of the Number of Small Entities to Which 
the Rules Will Apply

    The RFA directs agencies to provide a description of and, where 
feasible, an estimate of the number of small entities that may be 
affected by the rules adopted in the Order. The RFA generally defines 
the term ``small entity'' as having the same meaning as the terms 
``small business,'' ``small organization,'' and ``small governmental

[[Page 78119]]

jurisdiction.'' In addition, the term ``small business'' has the same 
meaning as the term ``small business concern'' under the Small Business 
Act.'' A ``small business concern'' is one which: (1) is independently 
owned and operated; (2) is not dominant in its field of operation; and 
(3) satisfies any additional criteria established by the SBA.
    Small Businesses, Small Organizations, Small Governmental 
Jurisdictions. Our actions, over time, may affect small entities that 
are not easily categorized at present. We therefore describe, at the 
outset, three broad groups of small entities that could be directly 
affected herein. First, while there are industry specific size 
standards for small businesses that are used in the regulatory 
flexibility analysis, according to data from the Small Business 
Administration's (SBA) Office of Advocacy, in general a small business 
is an independent business having fewer than 500 employees. These types 
of small businesses represent 99.9% of all businesses in the United 
States, which translates to 33.2 million businesses.
    Next, the type of small entity described as a ``small 
organization'' is generally ``any not-for-profit enterprise which is 
independently owned and operated and is not dominant in its field.'' 
The Internal Revenue Service (IRS) uses a revenue benchmark of $50,000 
or less to delineate its annual electronic filing requirements for 
small exempt organizations. Nationwide, for tax year 2022, there were 
approximately 530,109 small exempt organizations in the U.S. reporting 
revenues of $50,000 or less according to the registration and tax data 
for exempt organizations available from the IRS.
    Finally, the small entity described as a ``small governmental 
jurisdiction'' is defined generally as ``governments of cities, 
counties, towns, townships, villages, school districts, or special 
districts, with a population of less than fifty thousand.'' U.S. Census 
Bureau data from the 2022 Census of Governments indicate there were 
90,837 local governmental jurisdictions consisting of general purpose 
governments and special purpose governments in the United States. Of 
this number, there were 36,845 general purpose governments (county, 
municipal, and town or township) with populations of less than 50,000 
and 11,879 special purpose governments (independent school districts) 
with enrollment populations of less than 50,000. Accordingly, based on 
the 2022 U.S. Census of Governments data, we estimate that at least 
48,724 entities fall into the category of ``small governmental 
jurisdictions.''
    All Other Telecommunications. This industry is comprised of 
establishments primarily engaged in providing specialized 
telecommunications services, such as satellite tracking, communications 
telemetry, and radar station operation. This industry also includes 
establishments primarily engaged in providing satellite terminal 
stations and associated facilities connected with one or more 
terrestrial systems and capable of transmitting telecommunications to, 
and receiving telecommunications from, satellite systems. Providers of 
internet services (e.g. dial-up ISPs) or Voice over internet Protocol 
(VoIP) services, via client-supplied telecommunications connections are 
also included in this industry. The SBA small business size standard 
for this industry classifies firms with annual receipts of $40 million 
or less as small. U.S. Census Bureau data for 2017 show that there were 
1,079 firms in this industry that operated for the entire year. Of 
those firms, 1,039 had revenue of less than $25 million. Based on this 
data, the Commission estimates that the majority of ``All Other 
Telecommunications'' firms can be considered small.
    Advanced Wireless Services (AWS)--(1710-1755 MHz and 2110-2155 MHz 
bands (AWS-1); 1915-1920 MHz, 1995-2000 MHz, 2020-2025 MHz and 2175-
2180 MHz bands (AWS-2); 2155-2175 MHz band (AWS-3); 2000-2020 MHz and 
2180-2200 MHz (AWS-4)). Spectrum is made available and licensed in 
these bands for the provision of various wireless communications 
services. Wireless Telecommunications Carriers (except Satellite) is 
the closest industry with an SBA small business size standard 
applicable to these services. The SBA small business size standard for 
this industry classifies a business as small if it has 1,500 or fewer 
employees. U.S. Census Bureau data for 2017 show that there were 2,893 
firms that operated in this industry for the entire year. Of this 
number, 2,837 firms employed fewer than 250 employees. Thus, under the 
SBA size standard, the Commission estimates that a majority of 
licensees in this industry can be considered small.
    According to Commission data as of December 2021, there were 
approximately 4,472 active AWS licenses. The Commission's small 
business size standards with respect to AWS involve eligibility for 
bidding credits and installment payments in the auction of licenses for 
these services. For the auction of AWS licenses, the Commission defined 
a ``small business'' as an entity with average annual gross revenues 
for the preceding three years not exceeding $40 million, and a ``very 
small business'' as an entity with average annual gross revenues for 
the preceding three years not exceeding $15 million. Pursuant to these 
definitions, 57 winning bidders claiming status as small or very small 
businesses won 215 of 1,087 licenses. In the most recent auction of AWS 
licenses 15 of 37 bidders qualifying for status as small or very small 
businesses won licenses.
    In frequency bands where licenses were subject to auction, the 
Commission notes that as a general matter, the number of winning 
bidders that qualify as small businesses at the close of an auction 
does not necessarily represent the number of small businesses currently 
in service. Further, the Commission does not generally track subsequent 
business size unless, in the context of assignments or transfers, 
unjust enrichment issues are implicated. Additionally, since the 
Commission does not collect data on the number of employees for 
licensees providing these services, at this time we are not able to 
estimate the number of licensees with active licenses that would 
qualify as small under the SBA's small business size standard.
    Wired Telecommunications Carriers. The U.S. Census Bureau defines 
this industry as establishments primarily engaged in operating and/or 
providing access to transmission facilities and infrastructure that 
they own and/or lease for the transmission of voice, data, text, sound, 
and video using wired communications networks. Transmission facilities 
may be based on a single technology or a combination of technologies. 
Establishments in this industry use the wired telecommunications 
network facilities that they operate to provide a variety of services, 
such as wired telephony services, including VoIP services, wired 
(cable) audio and video programming distribution, and wired broadband 
internet services. By exception, establishments providing satellite 
television distribution services using facilities and infrastructure 
that they operate are included in this industry. Wired 
Telecommunications Carriers are also referred to as wireline carriers 
or fixed local service providers.
    The SBA small business size standard for Wired Telecommunications 
Carriers classifies firms having 1,500 or fewer employees as small. 
U.S. Census Bureau data for 2017 show that there were 3,054 firms that 
operated in this industry for the entire year. Of this number, 2,964 
firms operated with fewer than 250 employees. Additionally, based on

[[Page 78120]]

Commission data in the 2022 Universal Service Monitoring Report, as of 
December 31, 2021, there were 4,590 providers that reported they were 
engaged in the provision of fixed local services. Of these providers, 
the Commission estimates that 4,146 providers have 1,500 or fewer 
employees. Consequently, using the SBA's small business size standard, 
most of these providers can be considered small entities.
    Local Exchange Carriers (LECs). Neither the Commission nor the SBA 
has developed a size standard for small businesses specifically 
applicable to local exchange services. Providers of these services 
include both incumbent and competitive local exchange service 
providers. Wired Telecommunications Carriers is the closest industry 
with an SBA small business size standard. Wired Telecommunications 
Carriers are also referred to as wireline carriers or fixed local 
service providers. The SBA small business size standard for Wired 
Telecommunications Carriers classifies firms having 1,500 or fewer 
employees as small. U.S. Census Bureau data for 2017 show that there 
were 3,054 firms that operated in this industry for the entire year. Of 
this number, 2,964 firms operated with fewer than 250 employees. 
Additionally, based on Commission data in the 2022 Universal Service 
Monitoring Report, as of December 31, 2021, there were 4,590 providers 
that reported they were fixed local exchange service providers. Of 
these providers, the Commission estimates that 4,146 providers have 
1,500 or fewer employees. Consequently, using the SBA's small business 
size standard, most of these providers can be considered small 
entities.
    Competitive Local Exchange Carriers (LECs). Neither the Commission 
nor the SBA has developed a size standard for small businesses 
specifically applicable to local exchange services. Providers of these 
services include several types of competitive local exchange service 
providers. Wired Telecommunications Carriers is the closest industry 
with an SBA small business size standard. The SBA small business size 
standard for Wired Telecommunications Carriers classifies firms having 
1,500 or fewer employees as small. U.S. Census Bureau data for 2017 
show that there were 3,054 firms that operated in this industry for the 
entire year. Of this number, 2,964 firms operated with fewer than 250 
employees. Additionally, based on Commission data in the 2022 Universal 
Service Monitoring Report, as of December 31, 2021, there were 3,378 
providers that reported they were competitive local service providers. 
Of these providers, the Commission estimates that 3,230 providers have 
1,500 or fewer employees. Consequently, using the SBA's small business 
size standard, most of these providers can be considered small 
entities.
    Incumbent Local Exchange Carriers (Incumbent LECs). Neither the 
Commission nor the SBA have developed a small business size standard 
specifically for incumbent local exchange carriers. Wired 
Telecommunications Carriers is the closest industry with an SBA small 
business size standard. The SBA small business size standard for Wired 
Telecommunications Carriers classifies firms having 1,500 or fewer 
employees as small. U.S. Census Bureau data for 2017 show that there 
were 3,054 firms in this industry that operated for the entire year. Of 
this number, 2,964 firms operated with fewer than 250 employees. 
Additionally, based on Commission data in the 2022 Universal Service 
Monitoring Report, as of December 31, 2021, there were 1,212 providers 
that reported they were incumbent local exchange service providers. Of 
these providers, the Commission estimates that 916 providers have 1,500 
or fewer employees. Consequently, using the SBA's small business size 
standard, the Commission estimates that the majority of incumbent local 
exchange carriers can be considered small entities.
    Interexchange Carriers (IXCs). Neither the Commission nor the SBA 
have developed a small business size standard specifically for 
Interexchange Carriers. Wired Telecommunications Carriers is the 
closest industry with an SBA small business size standard. The SBA 
small business size standard for Wired Telecommunications Carriers 
classifies firms having 1,500 or fewer employees as small. U.S. Census 
Bureau data for 2017 show that there were 3,054 firms that operated in 
this industry for the entire year. Of this number, 2,964 firms operated 
with fewer than 250 employees. Additionally, based on Commission data 
in the 2022 Universal Service Monitoring Report, as of December 31, 
2021, there were 127 providers that reported they were engaged in the 
provision of interexchange services. Of these providers, the Commission 
estimates that 109 providers have 1,500 or fewer employees. 
Consequently, using the SBA's small business size standard, the 
Commission estimates that the majority of providers in this industry 
can be considered small entities.
    Local Resellers. Neither the Commission nor the SBA have developed 
a small business size standard specifically for Local Resellers. 
Telecommunications Resellers is the closest industry with an SBA small 
business size standard. The Telecommunications Resellers industry 
comprises establishments engaged in purchasing access and network 
capacity from owners and operators of telecommunications networks and 
reselling wired and wireless telecommunications services (except 
satellite) to businesses and households. Establishments in this 
industry resell telecommunications; they do not operate transmission 
facilities and infrastructure. Mobile virtual network operators (MVNOs) 
are included in this industry. The SBA small business size standard for 
Telecommunications Resellers classifies a business as small if it has 
1,500 or fewer employees. U.S. Census Bureau data for 2017 show that 
1,386 firms in this industry provided resale services for the entire 
year. Of that number, 1,375 firms operated with fewer than 250 
employees. Additionally, based on Commission data in the 2022 Universal 
Service Monitoring Report, as of December 31, 2021, there were 207 
providers that reported they were engaged in the provision of local 
resale services. Of these providers, the Commission estimates that 202 
providers have 1,500 or fewer employees. Consequently, using the SBA's 
small business size standard, most of these providers can be considered 
small entities.
    Broadband Personal Communications Service. The broadband personal 
communications services (PCS) spectrum encompasses services in the 
1850-1910 and 1930-1990 MHz bands. The closest industry with an SBA 
small business size standard applicable to these services is Wireless 
Telecommunications Carriers (except Satellite). The SBA small business 
size standard for this industry classifies a business as small if it 
has 1,500 or fewer employees. U.S. Census Bureau data for 2017 show 
that there were 2,893 firms that operated in this industry for the 
entire year. Of this number, 2,837 firms employed fewer than 250 
employees. Thus under the SBA size standard, the Commission estimates 
that a majority of licensees in this industry can be considered small.
    Based on Commission data as of November 2021, there were 
approximately 5,060 active licenses in the Broadband PCS service. The 
Commission's small business size standards with respect to Broadband 
PCS involve eligibility for bidding

[[Page 78121]]

credits and installment payments in the auction of licenses for these 
services. In auctions for these licenses, the Commission defined 
``small business'' as an entity that, together with its affiliates and 
controlling interests, has average gross revenues not exceeding $40 
million for the preceding three years, and a ``very small business'' as 
an entity that, together with its affiliates and controlling interests, 
has had average annual gross revenues not exceeding $15 million for the 
preceding three years. Winning bidders claiming small business credits 
won Broadband PCS licenses in C, D, E, and F Blocks.
    In frequency bands where licenses were subject to auction, the 
Commission notes that as a general matter, the number of winning 
bidders that qualify as small businesses at the close of an auction 
does not necessarily represent the number of small businesses currently 
in service. Further, the Commission does not generally track subsequent 
business size unless, in the context of assignments or transfers, 
unjust enrichment issues are implicated. Additionally, since the 
Commission does not collect data on the number of employees for 
licensees providing these, at this time we are not able to estimate the 
number of licensees with active licenses that would qualify as small 
under the SBA's small business size standard.
    Narrowband Personal Communications Services. Narrowband Personal 
Communications Services (Narrowband PCS) are PCS services operating in 
the 901-902 MHz, 930-931 MHz, and 940-941 MHz bands. PCS services are 
radio communications that encompass mobile and ancillary fixed 
communication that provide services to individuals and businesses and 
can be integrated with a variety of competing networks. Wireless 
Telecommunications Carriers (except Satellite) is the closest industry 
with an SBA small business size standard applicable to these services. 
The SBA small business size standard for this industry classifies a 
business as small if it has 1,500 or fewer employees. U.S. Census 
Bureau data for 2017 show that there were 2,893 firms that operated in 
this industry for the entire year. Of this number, 2,837 firms employed 
fewer than 250 employees. Thus under the SBA size standard, the 
Commission estimates that a majority of licensees in this industry can 
be considered small.
    According to Commission data as of December 2021, there were 
approximately 4,211 active Narrowband PCS licenses. The Commission's 
small business size standards with respect to Narrowband PCS involve 
eligibility for bidding credits and installment payments in the auction 
of licenses for these services. For the auction of these licenses, the 
Commission defined a ``small business'' as an entity that, together 
with affiliates and controlling interests, has average gross revenues 
for the three preceding years of not more than $40 million. A ``very 
small business'' is defined as an entity that, together with affiliates 
and controlling interests, has average gross revenues for the three 
preceding years of not more than $15 million. Pursuant to these 
definitions, 7 winning bidders claiming small and very small bidding 
credits won approximately 359 licenses. One of the winning bidders 
claiming a small business status classification in these Narrowband PCS 
license auctions had an active license as of December 2021.
    In frequency bands where licenses were subject to auction, the 
Commission notes that as a general matter, the number of winning 
bidders that qualify as small businesses at the close of an auction 
does not necessarily represent the number of small businesses currently 
in service. Further, the Commission does not generally track subsequent 
business size unless, in the context of assignments or transfers, 
unjust enrichment issues are implicated. Additionally, since the 
Commission does not collect data on the number of employees for 
licensees providing these services, at this time we are not able to 
estimate the number of licensees with active licenses that would 
qualify as small under the SBA's small business size standard.
    Offshore Radiotelephone Service. This service operates on several 
UHF television broadcast channels that are not used for television 
broadcasting in the coastal areas of states bordering the Gulf of 
Mexico. Wireless Telecommunications Carriers (except Satellite) is the 
closest industry with an SBA small business size standard applicable to 
this service. The SBA small business size standard for this industry 
classifies a business as small if it has 1,500 or fewer employees. U.S. 
Census Bureau data for 2017 show that there were 2,893 firms that 
operated in this industry for the entire year. Of this number, 2,837 
firms employed fewer than 250 employees. Thus under the SBA size 
standard, the Commission estimates that a majority of licensees in this 
industry can be considered small. Additionally, based on Commission 
data, as of December 2021, there was one licensee with an active 
license in this service. However, since the Commission does not collect 
data on the number of employees for this service, at this time we are 
not able to estimate the number of licensees that would qualify as 
small under the SBA's small business size standard.
    Radio and Television Broadcasting and Wireless Communications 
Equipment Manufacturing. This industry comprises establishments 
primarily engaged in manufacturing radio and television broadcast and 
wireless communications equipment. Examples of products made by these 
establishments are: transmitting and receiving antennas, cable 
television equipment, GPS equipment, pagers, cellular phones, mobile 
communications equipment, and radio and television studio and 
broadcasting equipment. The SBA small business size standard for this 
industry classifies businesses having 1,250 employees or less as small. 
U.S. Census Bureau data for 2017 show that there were 656 firms in this 
industry that operated for the entire year. Of this number, 624 firms 
had fewer than 250 employees. Thus, under the SBA size standard, the 
majority of firms in this industry can be considered small.
    Rural Radiotelephone Service. Neither the Commission nor the SBA 
have developed a small business size standard specifically for small 
businesses providing Rural Radiotelephone Service. Rural Radiotelephone 
Service is radio service in which licensees are authorized to offer and 
provide radio telecommunication services for hire to subscribers in 
areas where it is not feasible to provide communication services by 
wire or other means. A significant subset of the Rural Radiotelephone 
Service is the Basic Exchange Telephone Radio System (BETRS). Wireless 
Telecommunications Carriers (except Satellite), is the closest 
applicable industry with an SBA small business size standard. The SBA 
small business size standard for Wireless Telecommunications Carriers 
(except Satellite) classifies firms having 1,500 or fewer employees as 
small. For this industry, U.S. Census Bureau data for 2017 show that 
there were 2,893 firms that operated for the entire year. Of this 
total, 2,837 firms employed fewer than 250 employees. Thus under the 
SBA size standard, the Commission estimates that the majority of Rural 
Radiotelephone Services firm are small entities. Based on Commission 
data as of December 27, 2021, there were approximately 119 active 
licenses in the Rural Radiotelephone Service. The Commission does not 
collect employment data from these entities holding these licenses and 
therefore we cannot estimate how many of these

[[Page 78122]]

entities meet the SBA small business size standard.
    Wireless Communications Services. Wireless Communications Services 
(WCS) can be used for a variety of fixed, mobile, radiolocation, and 
digital audio broadcasting satellite services. Wireless spectrum is 
made available and licensed for the provision of wireless 
communications services in several frequency bands subject to Part 27 
of the Commission's rules. Wireless Telecommunications Carriers (except 
Satellite) is the closest industry with an SBA small business size 
standard applicable to these services. The SBA small business size 
standard for this industry classifies a business as small if it has 
1,500 or fewer employees. U.S. Census Bureau data for 2017 show that 
there were 2,893 firms that operated in this industry for the entire 
year. Of this number, 2,837 firms employed fewer than 250 employees. 
Thus under the SBA size standard, the Commission estimates that a 
majority of licensees in this industry can be considered small.
    The Commission's small business size standards with respect to WCS 
involve eligibility for bidding credits and installment payments in the 
auction of licenses for the various frequency bands included in WCS. 
When bidding credits are adopted for the auction of licenses in WCS 
frequency bands, such credits may be available to several types of 
small businesses based average gross revenues (small, very small and 
entrepreneur) pursuant to the competitive bidding rules adopted in 
conjunction with the requirements for the auction and/or as identified 
in the designated entities section in part 27 of the Commission's rules 
for the specific WCS frequency bands.
    In frequency bands where licenses were subject to auction, the 
Commission notes that as a general matter, the number of winning 
bidders that qualify as small businesses at the close of an auction 
does not necessarily represent the number of small businesses currently 
in service. Further, the Commission does not generally track subsequent 
business size unless, in the context of assignments or transfers, 
unjust enrichment issues are implicated. Additionally, since the 
Commission does not collect data on the number of employees for 
licensees providing these services, at this time we are not able to 
estimate the number of licensees with active licenses that would 
qualify as small under the SBA's small business size standard.
    Wireless Telecommunications Carriers (except Satellite). This 
industry comprises establishments engaged in operating and maintaining 
switching and transmission facilities to provide communications via the 
airwaves. Establishments in this industry have spectrum licenses and 
provide services using that spectrum, such as cellular services, paging 
services, wireless internet access, and wireless video services. The 
SBA size standard for this industry classifies a business as small if 
it has 1,500 or fewer employees. U.S. Census Bureau data for 2017 show 
that there were 2,893 firms in this industry that operated for the 
entire year. Of that number, 2,837 firms employed fewer than 250 
employees. Additionally, based on Commission data in the 2022 Universal 
Service Monitoring Report, as of December 31, 2021, there were 594 
providers that reported they were engaged in the provision of wireless 
services. Of these providers, the Commission estimates that 511 
providers have 1,500 or fewer employees. Consequently, using the SBA's 
small business size standard, most of these providers can be considered 
small entities.
    Wireless Telephony. Wireless telephony includes cellular, personal 
communications services, and specialized mobile radio telephony 
carriers. The closest applicable industry with an SBA small business 
size standard is Wireless Telecommunications Carriers (except 
Satellite). The size standard for this industry under SBA rules is that 
a business is small if it has 1,500 or fewer employees. For this 
industry, U.S. Census Bureau data for 2017 show that there were 2,893 
firms that operated for the entire year. Of this number, 2,837 firms 
employed fewer than 250 employees. Additionally, based on Commission 
data in the 2022 Universal Service Monitoring Report, as of December 
31, 2021, there were 331 providers that reported they were engaged in 
the provision of cellular, personal communications services, and 
specialized mobile radio services. Of these providers, the Commission 
estimates that 255 providers have 1,500 or fewer employees. 
Consequently, using the SBA's small business size standard, most of 
these providers can be considered small entities.
    700 MHz Guard Band Licensees. The 700 MHz Guard Band encompasses 
spectrum in 746-747/776-777 MHz and 762-764/792-794 MHz frequency 
bands. Wireless Telecommunications Carriers (except Satellite) is the 
closest industry with an SBA small business size standard applicable to 
licenses providing services in these bands. The SBA small business size 
standard for this industry classifies a business as small if it has 
1,500 or fewer employees. U.S. Census Bureau data for 2017 show that 
there were 2,893 firms that operated in this industry for the entire 
year. Of this number, 2,837 firms employed fewer than 250 employees. 
Thus under the SBA size standard, the Commission estimates that a 
majority of licensees in this industry can be considered small.
    According to Commission data as of December 2021, there were 
approximately 224 active 700 MHz Guard Band licenses. The Commission's 
small business size standards with respect to 700 MHz Guard Band 
licensees involve eligibility for bidding credits and installment 
payments in the auction of licenses. For the auction of these licenses, 
the Commission defined a ``small business'' as an entity that, together 
with its affiliates and controlling principals, has average gross 
revenues not exceeding $40 million for the preceding three years, and a 
``very small business'' an entity that, together with its affiliates 
and controlling principals, has average gross revenues that are not 
more than $15 million for the preceding three years. Pursuant to these 
definitions, five winning bidders claiming one of the small business 
status classifications won 26 licenses, and one winning bidder claiming 
small business won two licenses. None of the winning bidders claiming a 
small business status classification in these 700 MHz Guard Band 
license auctions had an active license as of December 2021.
    In frequency bands where licenses were subject to auction, the 
Commission notes that as a general matter, the number of winning 
bidders that qualify as small businesses at the close of an auction 
does not necessarily represent the number of small businesses currently 
in service. Further, the Commission does not generally track subsequent 
business size unless, in the context of assignments or transfers, 
unjust enrichment issues are implicated. Additionally, since the 
Commission does not collect data on the number of employees for 
licensees providing these services, at this time we are not able to 
estimate the number of licensees with active licenses that would 
qualify as small under the SBA's small business size standard.
    Lower 700 MHz Band Licenses. The lower 700 MHz band encompasses 
spectrum in the 698-746 MHz frequency bands. Permissible operations in 
these bands include flexible fixed, mobile, and broadcast uses, 
including mobile and other digital new broadcast operation; fixed and 
mobile wireless commercial services (including FDD- and TDD-based 
services); as well as fixed and mobile wireless uses for

[[Page 78123]]

private, internal radio needs, two-way interactive, cellular, and 
mobile television broadcasting services. Wireless Telecommunications 
Carriers (except Satellite) is the closest industry with an SBA small 
business size standard applicable to licenses providing services in 
these bands. The SBA small business size standard for this industry 
classifies a business as small if it has 1,500 or fewer employees. U.S. 
Census Bureau data for 2017 show that there were 2,893 firms that 
operated in this industry for the entire year. Of this number, 2,837 
firms employed fewer than 250 employees. Thus under the SBA size 
standard, the Commission estimates that a majority of licensees in this 
industry can be considered small.
    According to Commission data as of December 2021, there were 
approximately 2,824 active Lower 700 MHz Band licenses. The 
Commission's small business size standards with respect to Lower 700 
MHz Band licensees involve eligibility for bidding credits and 
installment payments in the auction of licenses. For auctions of Lower 
700 MHz Band licenses the Commission adopted criteria for three groups 
of small businesses. A very small business was defined as an entity 
that, together with its affiliates and controlling interests, has 
average annual gross revenues not exceeding $15 million for the 
preceding three years, a small business was defined as an entity that, 
together with its affiliates and controlling interests, has average 
gross revenues not exceeding $40 million for the preceding three years, 
and an entrepreneur was defined as an entity that, together with its 
affiliates and controlling interests, has average gross revenues not 
exceeding $3 million for the preceding three years. In auctions for 
Lower 700 MHz Band licenses seventy-two winning bidders claiming a 
small business classification won 329 licenses, twenty-six winning 
bidders claiming a small business classification won 214 licenses, and 
three winning bidders claiming a small business classification won all 
five auctioned licenses.
    In frequency bands where licenses were subject to auction, the 
Commission notes that as a general matter, the number of winning 
bidders that qualify as small businesses at the close of an auction 
does not necessarily represent the number of small businesses currently 
in service. Further, the Commission does not generally track subsequent 
business size unless, in the context of assignments or transfers, 
unjust enrichment issues are implicated. Additionally, since the 
Commission does not collect data on the number of employees for 
licensees providing these services, at this time we are not able to 
estimate the number of licensees with active licenses that would 
qualify as small under the SBA's small business size standard.
    Upper 700 MHz Band Licenses. The upper 700 MHz band encompasses 
spectrum in the 746-806 MHz bands. Upper 700 MHz D Block licenses are 
nationwide licenses associated with the 758-763 MHz and 788-793 MHz 
bands. Permissible operations in these bands include flexible fixed, 
mobile, and broadcast uses, including mobile and other digital new 
broadcast operation; fixed and mobile wireless commercial services 
(including FDD- and TDD-based services); as well as fixed and mobile 
wireless uses for private, internal radio needs, two-way interactive, 
cellular, and mobile television broadcasting services. Wireless 
Telecommunications Carriers (except Satellite) is the closest industry 
with an SBA small business size standard applicable to licenses 
providing services in these bands. The SBA small business size standard 
for this industry classifies a business as small if it has 1,500 or 
fewer employees. U.S. Census Bureau data for 2017 show that there were 
2,893 firms that operated in this industry for the entire year. Of that 
number, 2,837 firms employed fewer than 250 employees. Thus, under the 
SBA size standard, the Commission estimates that a majority of 
licensees in this industry can be considered small.
    According to Commission data as of December 2021, there were 
approximately 152 active Upper 700 MHz Band licenses. The Commission's 
small business size standards with respect to Upper 700 MHz Band 
licensees involve eligibility for bidding credits and installment 
payments in the auction of licenses. For the auction of these licenses, 
the Commission defined a ``small business'' as an entity that, together 
with its affiliates and controlling principals, has average gross 
revenues not exceeding $40 million for the preceding three years, and a 
``very small business'' an entity that, together with its affiliates 
and controlling principals, has average gross revenues that are not 
more than $15 million for the preceding three years. Pursuant to these 
definitions, three winning bidders claiming very small business status 
won five of the twelve available licenses.
    In frequency bands where licenses were subject to auction, the 
Commission notes that as a general matter, the number of winning 
bidders that qualify as small businesses at the close of an auction 
does not necessarily represent the number of small businesses currently 
in service. Further, the Commission does not generally track subsequent 
business size unless, in the context of assignments or transfers, 
unjust enrichment issues are implicated. Additionally, since the 
Commission does not collect data on the number of employees for 
licensees providing these services, at this time we are not able to 
estimate the number of licensees with active licenses that would 
qualify as small under the SBA's small business size standard.
    Wireless Resellers. Neither the Commission nor the SBA have 
developed a small business size standard specifically for Wireless 
Resellers. The closest industry with an SBA small business size 
standard is Telecommunications Resellers. The Telecommunications 
Resellers industry comprises establishments engaged in purchasing 
access and network capacity from owners and operators of 
telecommunications networks and reselling wired and wireless 
telecommunications services (except satellite) to businesses and 
households. Establishments in this industry resell telecommunications 
and they do not operate transmission facilities and infrastructure. 
Mobile virtual network operators (MVNOs) are included in this industry. 
Under the SBA size standard for this industry, a business is small if 
it has 1,500 or fewer employees. U.S. Census Bureau data for 2017 show 
that 1,386 firms in this industry provided resale services during that 
year. Of that number, 1,375 firms operated with fewer than 250 
employees. Thus, for this industry under the SBA small business size 
standard, the majority of providers can be considered small entities.
    Semiconductor and Related Device Manufacturing. Semiconductor and 
Related Device Manufacturing. This industry comprises establishments 
primarily engaged in manufacturing semiconductors and related solid 
state devices. Examples of products made by these establishments are 
integrated circuits, memory chips, microprocessors, diodes, 
transistors, solar cells and other optoelectronic devices. The SBA 
small business size standard for this industry classifies entities 
having 1,250 or fewer employees as small. U.S. Census Bureau data for 
2017 show that there were 729 firms in this industry that operated for 
the entire year. Of this total, 673 firms operated with fewer than 250 
employees. Thus under the SBA size standard, the majority of firms in 
this industry can be considered small.
    Telecommunications Relay Service (TRS) Providers. 
Telecommunications

[[Page 78124]]

relay services enable individuals who are deaf, hard of hearing, deaf-
blind, or who have a speech disability to communicate by telephone in a 
manner that is functionally equivalent to using voice communication 
services. Internet-based TRS (iTRS) connects an individual with a 
hearing or a speech disability to a TRS communications assistant using 
an Internet Protocol-enabled device via the internet, rather than the 
public switched telephone network. Video Relay Service (VRS) one form 
of iTRS, enables people with hearing or speech disabilities who use 
sign language to communicate with voice telephone users over a 
broadband connection using a video communication device. Internet 
Protocol Captioned Telephone Service (IP CTS) another form of iTRS, 
permits a person with hearing loss to have a telephone conversation 
while reading captions of what the other party is saying on an 
internet-connected device. Providers must be certified by the 
Commission to provide VRS and IP CTS and to receive compensation from 
the TRS Fund for TRS provided in accordance with applicable rules.
    Neither the Commission nor the SBA have developed a small business 
size standard specifically for TRS Providers. All Other 
Telecommunications is the closest industry with an SBA small business 
size standard. Internet Service Providers (ISPs) and Voice over 
internet Protocol (VoIP) services, via client-supplied 
telecommunications connections are included in this industry. The SBA 
small business size standard for this industry classifies firms with 
annual receipts of $40 million or less as small. U.S. Census Bureau 
data for 2017 show that there were 1,079 firms in this industry that 
operated for the entire year. Of those firms, 1,039 had revenue of less 
than $25 million. Based on Commission data there are ten certified iTRS 
providers. The Commission however does not compile financial 
information for these providers. Nevertheless, based on available 
information, the Commission estimates that most providers in this 
industry are small entities.

E. Description of Projected Reporting, Recordkeeping, and Other 
Compliance Requirements for Small Entities

    The rules adopted in the Order will impose new or additional 
reporting, recordkeeping, and/or other compliance obligations on small 
entities. Some of our requirements contain written notification and 
certification requirements that will be applicable to small entities, 
and other requirements impose compliance obligations on small entities 
that may require small entities to hire professionals to implement and 
comply.
    Reporting and Recordkeeping. The Commission adopted the reporting 
and recordkeeping requirements proposed in the NG911 Notice, with minor 
adjustments. First, in each phase of the NG911 transition, the 
Commission allows OSPs and 911 Authorities the flexibility to agree to 
alternate time frames or cost allocation arrangements, but the OSPs 
must notify the Commission of the alternate arrangements, including the 
pertinent terms of that agreement, within 30 days of the agreement. We 
note that the notice of the alternative agreement must specifically 
identify which requirements from the rules are impacted, and what are 
the mutually agreed upon new requirements (e.g., compliance time 
frames, dates). In contrast, the rules proposed in the NG911 Notice 
limited OSPs and 911 Authorities to entering into mutual agreements to 
establish alternative time frames for meeting the requirements to 
deliver 911 calls and texts in the requested IP-based format. Second, 
to ensure OSPs receive valid requests from a technologically-ready 911 
Authority to initiate each phase, we require the requesting local or 
state entity to certify its technology readiness suitable to the 
appropriate phase with a formal notice that must be transmitted in 
writing to the OSPs or made available to them via a Commission public 
registry.
    Other Compliance Requirements. Several comments filed in response 
to the NG911 Notice discussed various categories of potential expenses 
to comply with NG911 transition requirements, with many asserting that 
there would be a greater burden on smaller RLECs. Our initial estimate 
of the upper bound of these costs for all 2,327 OSPs industry-wide in 
the NG911 Notice was approximately $103,000 in one-time costs and $11.6 
million in recurring annual costs for new annual IP 911 call delivery 
transport charges for the 81 of those OSPs that currently provide only 
TDM telephony. As discussed below, in this document and the Order the 
Commission adjusted our cost estimates to account for industry-
submitted data and further Commission analysis.
    Assessment of Costs of Compliance Requirements. We update our cost 
calculation for a total of 2,287 OSPs based on newer Form 477 data, and 
we estimate that OSPs will incur approximately $4.4 million in total 
one-time non-recurring costs and no more than $5.5 million in annual 
recurring costs to implement Phase 1 requirements, and additionally 
approximately $24 million in non-recurring costs and approximately $50 
million per year to implement Phase 2 requirements.
    Phase 1 Compliance Costs. The new IP transport costs due to the 
rules are non-negligible. We respond to RTCC's comment that our initial 
estimate of IP transport costs for only 8.5% of RLECs was in error by 
reassessing that wireline OSPs may incur some transport costs 
regardless of whether they already have IP switches and can convert TDM 
to IP on their own networks or not, particularly assuming SIP trunking 
is used. We recognize that some smaller OSPs--primarily RLECs--will 
incur incremental recurring cost of IP transport via SIP trunks, even 
if those RLECs already have IP switches, can convert TDM to IP on their 
own networks, and can provide broadband service using their own IP 
switching facilities. As some parties point out, these RLECs might 
incur some SIP call transport costs if they do not have settlement-free 
peering agreements and cannot hand off IP voice traffic to existing 
interconnection partners. We estimate that the total of these costs 
will be below $5.5 million per year. This estimate is based on 
assumptions that the transport cost would be $2,000 per month for the 
16 OSPs that currently only offer TDM-based voice services (i.e., they 
do not offer broadband or VoIP services) and serve fewer than 10,000 
subscribers, and 50% more (i.e., $3,000 per month) for the two OSPs 
that provide no broadband or VoIP but serve more than 10,000 
subscribers.
    The Commission concludes that most of the RLECs' and other 
commenting parties' estimates of the recurring costs of IP transport to 
NG911 Delivery Points are unduly high. Almost all of these cost 
estimates for 911 IP transport are premised on assumptions that OSPs 
will be required to transmit 911 calls over long distances across 
multiple states to faraway NG911 Delivery Points. These assumptions are 
unfounded in light of the rules, which require OSPs to transport 911 
calls only to in-state NG911 Delivery Points designated by 911 
Authorities. Given the ample evidence showing that IP transport costs 
are significantly lower than TDM transport costs, we believe that the 
rules might actually reduce the overall transport costs for OSPs. For 
example, South Carolina RFA submits data indicating that IP transport 
of 911 traffic is generally 27% cheaper than TDM call delivery, 
regardless of where the calls are delivered. iCERT points out that, to 
avoid the higher cost of transporting TDM calls, RLECs could convert 
their

[[Page 78125]]

traffic from TDM to IP format prior to transporting them. Five Area 
Telephone also points out that OSPs could significantly lower the 
overall costs of transmitting 911 calls to ESInets by taking advantage 
of third-party aggregators' services.
    We further assess small and other OSPs will incur additional non-
recurring Phase 1 material and labor costs in order to comply with the 
IP transport requirement. The Commission estimates a total of $4.4 
million in one-time material and labor costs, including approximately 
$4 million to convert TDM calls to IP format and $343,000 to configure 
the delivery to new NG911 Delivery Points. Because the majority of OSPs 
are capable of transmitting calls in IP format, we estimate that only a 
subset of OSPs that do not offer full IP-related services would need to 
incur the cost of facilities needed to convert TDM calls to IP format; 
other OSPs that already originate traffic in IP format would incur no 
up-front IP conversion costs. For the smallest entities, we 
conservatively estimate an upper bound of the one-time IP conversion 
cost to be no more than $17,600 for the voice-only OSPs with no more 
than 10,000 subscribers.
    We use Five Area Telephone's estimate of $17,600 as the upper bound 
for the up-front equipment costs for small OSPs to connect to ESInets--
an estimate that, according to Five Area Telephone, includes the costs 
of ``establishing network connectivity, procurement of private line 
circuits, configuration assistance, switching equipment configuration, 
testing, cutover, and final testing,'' equaling over $40 million if 
applied to all 2,327 carriers. The Commission believes this estimate 
substantially overstates the cost of the network equipment required to 
convert TDM calls to IP format, because it assumes a major system 
upgrade would be required, and we reject Five Area Telephone's 
assertion that the total cost would exceed $40 million because that 
erroneously assumes that all 2,327 OSPs would incur the same amount. 
Nonetheless, we apply Five Area Telephone's $17,600 one-time cost 
estimate as the basis to calculate the upper bound of our IP conversion 
cost estimate, because other commenters' estimates are even less 
credible. Most of them include the non-recurring cost of system 
upgrades that are not required by the rules; many of them rely on 
unsupported cost figures for specific OSPs without providing any basis 
for us to examine whether these costs are typical; and some include no 
cost figures at all.
    Including larger entities, we estimate that the total one-time cost 
that OSPs would incur to obtain the facilities needed to convert TDM 
calls to IP format would be approximately $4 million, including 
$334,400 for the 18 that do not offer any IP services and $3.7 million 
for the 414 that offer broadband as well as voice services. We believe 
our estimate is conservative because it does not take into account the 
many non-911 calls that these OSPs would transmit using the same 
equipment.
    The Commission also estimates that the one-time costs of 
reconfiguring and changing 911 traffic delivery points would require 
all affected OSPs to incur labor costs totaling $343,000. This is based 
on the Bureau of Labor Statistics' estimate that the average wage for 
telecommunications equipment installers and repairers is $32.26 per 
hour, as well as an estimate, based on evidence in the record, that 
OSPs serving fewer than 10,000 subscribers would need to pay for up to 
three hours of labor and OSPs serving more than 10,000 subscribers 
would need to pay 50% more in labor costs due to the potentially more 
complex tasks these entities might need to undertake to reconfigure and 
change the delivery points for their 911 traffic. We rely on RWA's 
assertion that ``the number of person-hours required will typically be 
closer to two or three,'' rather than the one hour estimated in the 
NG911 Notice, and adjust this amount upward by 50% more for OSPs 
serving more than 10,000 subscribers to account for the greater 
complexity of the task. Based on these assumptions, we arrive at the 
total one-time labor cost of $343,000 for all the OSPs to change the 
delivery points.
    Phase 2 Compliance Costs. We estimate that wireline carriers, 
interconnected VoIP providers, and other OSPs that are not CMRS 
providers (and thus not subject to the LBR Order) will incur 
approximately $24 million in one-time costs and $50 million in annual 
recurring costs to comply with 911 Authorities' Phase 2 requests to 
transmit and maintain accurate location information with 911 calls in 
IP format using LIS databases and the LVF function (or their 
equivalent). The rules allow OSPs to use ``LIS as a service'' from a 
third-party vendor as an option instead of creating their own LIS or 
equivalent databases. This LIS service may either involve native IP LIS 
or LIS equivalent database population, or a database conversion of 
OSPs' existing ALI/ANI/MSAG data to LIS formats. 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. This is a substantial cost-savings measure 
especially for smaller OSPs with TDM networks, who may not be ready to 
decommission older legacy equipment and modernize their networks for 
IP/VoIP.
    We conservatively base these figures on Five Area Telephone's 
estimates that, to comply with location-based routing-type requirements 
to insert location information into call paths, wireline and VoIP 
providers would need to incur non-recurring costs of approximately 
$10,000 and monthly recurring costs of $1,750. Extrapolating these 
statistics and increasing the costs by 50% for larger OSPs serving more 
than 10,000 subscribers, we estimate that compliance with the Phase 2 
rules would require non-CMRS OSPs to incur a total of $24 million in 
one-time costs and $50 million in annual recurring costs. The 
Commission concludes that the location information requirement does not 
result in any additional costs for CMRS providers because they will 
have already implemented such upgrades.
    We reject AT&T's cost estimate submitted in the record. AT&T 
alleges that ``requiring the introduction of a Location Information 
Server (`LIS') would be extremely expensive and inefficient'' for 
carriers with legacy TDM switching facilities and ``could cost several 
billion dollars on an industry-wide basis.'' AT&T, in its role as the 
lead NGCS and ESInet contractor in Virginia, has already provided a 
solution that allows legacy OSP wireline ALI and MSAG location data to 
be used for NG911-compliant LIS as a service, which eliminates TDM 
OSPs' needs to upgrade their networks to IP. The Commission therefore 
finds AT&T's record assertion, which could have been relevant to small 
carriers with legacy TDM switching facilities, was based on an 
assumption of an IP origination requirement, which we do not impose.
    The Commission emphasizes that these Phase 2 rules do not require 
OSPs to originate 911 calls in IP format. Our Phase 2 cost estimate 
does not include the costs of originating traffic in IP format. 
However, we nevertheless consider WTA's claims that ``obtaining the 
full benefits of NG911 service will not be possible unless 911 calls 
originate in IP format,'' and that converting networks from TDM to IP 
carries ``not only significant network and customer equipment changes 
and reconfigurations, but also substantial

[[Page 78126]]

customer service and education costs.'' Although we agree that 
converting TDM networks to IP networks can be costly, we reject the 
contention that such system upgrade costs should be attributed to the 
requirements in these rules. The transition from TDM to IP technology 
has been ongoing for over a decade as the subscriptions to voice-only 
local exchange telephone service (switched access lines) has fallen 
from nearly 141 million lines in December 2008 to 27 million in June 
2022. A linear model predicts that switched access lines will be fully 
phased out in the near future. Therefore, since we can reasonably 
expect that these system upgrades will occur organically as part of the 
natural technological evolution, regardless of whether OSPs are 
required to comply with Phase 2 requests, the upgrades cannot be 
attributed to these requirements. Instead, they should be considered 
baseline costs of operating telecommunications business. Furthermore, 
even if a handful of RLECs delayed their system upgrades for 
idiosyncratic reasons, the 6- to 12-month timeline to comply with the 
requirements for each of the two phases would be sufficient for RLECs 
to move away from the legacy systems that are beyond end of their life.
    Finally, our Phase 2 rules do not preclude small and other OSPs 
from negotiating with 911 authorities for alternative arrangements. If 
the costs of upgrading network systems are as high as some OSPs claim, 
those entities could offer 911 Authorities alternative, less costly 
arrangements, such as offering to pay the 911 Authorities to maintain 
the costly legacy conversion components for these OSPs to use in order 
to fulfill the requirements. Nonetheless, in light of the ample record 
evidence that most 911 Authorities are eager to decommission these 
legacy facilities due to the high cost of maintaining them (as well as 
the limitations on these facilities' functionality), we believe it is 
highly unlikely that any OSP would find such an arrangement to be cost-
effective, especially when compared with the cost of upgrading their 
own networks--upgrades that they almost certainly will need to 
implement within the applicable time frame for reasons that have 
nothing to do with these NG911 rules.
    OSP Implementation Timeframes. In the Order the Commission also 
adjusted the compliance timeframes for small and rural OSPs. RLECs, 
non-nationwide CMRS providers, and internet-based TRS providers are 
required to comply with a 911 Authority's valid request at each phase 
of the NG911 transition within 12 months after receiving a valid 
request or within 12 months after the effective date of the rules 
adopted in the Order, whichever is later. The Commission granted these 
OSPs a longer time to comply than nationwide CMRS providers, 
interconnected VoIP providers, and non-RLEC wireline providers who are 
required to comply within six months after receiving a valid request at 
each phase of the NG911 transition or within six months after the 
effective date of the rules adopted in the Order.
    The important life-saving public safety benefits that will result 
from the rules the Commission adopted in the Order are conservatively 
estimated at over one trillion dollars annually. The rule changes to 
implement NG911 will save lives by improving the reliability of the 911 
network and decrease outages and call failures, improving routing to 
PSAPs to ensure each 911 call goes to the most appropriate PSAP that 
can most quickly answer and respond with the most suitable emergency 
assistance, and improving the standardized format and reliability of 
caller location data delivered to PSAPs to ensure faster public safety 
response times. Accordingly, these rule changes serve the public 
interest.

F. Steps Taken To Minimize the Significant Economic Impact on Small 
Entities, and Significant Alternatives Considered

    The RFA requires an agency to provide ``a description of the steps 
the agency has taken to minimize the significant economic impact on 
small entities . . . including a statement of the factual, policy, and 
legal reasons for selecting the alternative adopted in the final rule 
and why each one of the other significant alternatives to the rule 
considered by the agency which affect the impact on small entities was 
rejected.''
    In this document and the Order the Commission describes the 
significant public safety benefits to be achieved from requiring all 
OSPs to acquire and implement NG911 technology. We also discuss that 
based on the record in this proceeding, the Commission finds it is 
technologically feasible for all OSPs to do so. While all OSPs are 
capable of complying with the NG911 transition requirements, the rules 
the Commission adopted in the Order are intended to be cost effective 
and minimally burdensome for small and other entities impacted by the 
rules. For example, the Commission did not propose, and declined to 
adopt any rules for monitoring the transition to NG911 or addressing 
compliance with the new requirements as supported by a small iTRS 
provider Hamilton Relay. Additionally, the adopted rules pertaining to 
Phase 2 SIP location and LIS costs only require OSPs to use ``LIS as a 
service'' from a third-party vendor instead of creating their own LIS 
databases. Using LIS as a service often involves simple database 
conversion of OSPs' existing ALI/ANI/MSAG data to LIS formats. As 
discussed by CSRIC, LIS as a service is envisioned as an NG911 solution 
at ``minimal expense'' to small OSPs, which absolves OSPs of most costs 
beyond monthly services and a Legacy Network Gateway (LNG), and the 
service can be provided either by a commercial vendor, or the 911 
Authority. LIS as a service is a substantial cost-savings measure 
especially for smaller OSPs, who may not be ready to decommission older 
legacy equipment and modernize their networks for NG911 end-state 
architecture. Below we discuss other steps the Commission has taken to 
minimize costs and reduce the economic impact for small entities, as 
well as some alternatives considered.
    In-State NG911 Delivery Points. In response to RLEC comments and 
concerns that they might be required to incur unreasonably high 
transport costs if 911 Authorities had unlimited discretion to 
designate interconnection points anywhere in the country, and about the 
high costs they might incur where 911 Authorities ``have delegated the 
operation of an ESInet to a third-party provider [that designates a] 
connection point far outside of state boundaries,'' the Commission 
modified the proposed default rule to require OSPs to deliver NG911 
traffic to NG911 Delivery Points designated by a 911 Authority only if 
those points are located within the 911 Authority's home state. 
Moreover, although the Commission believes the obligation to transmit 
911 calls to NG911 Delivery Points will have little, if any impact on 
RLECs' exposure to liability under state tort law, the home-state 
qualification may make it easier for RLECs to anticipate and manage 
those de minimis risks by avoiding exposing them to multiple states' 
differing tort law standards. In addition, RLECs' concerns that an 
obligation to deliver calls to faraway states would compel them to 
retain third-party long distance transmission vendors, and they could 
be held liable for violations of the Commission's 911 reliability rules 
committed by these vendors, should be addressed by the home-state 
qualification requirement. The home-state qualification should also 
reduce

[[Page 78127]]

the need for RLECs to retain third-party vendors, and make it easier 
for them to monitor the performance of both their own networks and 
those of the third-party vendors.
    No IP 911 Call Origination Requirement/LNG Gateway Solution. The 
rules decline to require IP origination of 911 calls for OSPs at Phase 
2, marking a substantial cost saving flexibility for small and other 
OSPs that still originate calls in TDM. In the Notice, the Commission 
sought comment about such a requirement, but we decline to impose it. 
Permitting these OSPs to maintain their legacy TDM facilities instead 
of moving to VoIP for NG911 Phase 2 will reduce the burdens on smaller 
entities. Specifically, our rules do not prevent OSPs from meeting the 
Phase 2 requirements by using a LIS gateway solution, which converts 
OSPs' existing legacy ALI/ANI location data into IP format for delivery 
in the SIP header code to ESInets and PSAPs. This allows the smallest 
OSPs to continue to operate legacy TDM networks and their ALI/ANI 
facilities without having to immediately convert their networks to 
VoIP.
    Time to Comply for Smaller Entities. The additional six months for 
small and rural OSPs to comply with each Phase of the NG911 transition 
is also a significant step to reduce burdens by the Commission in the 
Order. In the previous section we discuss the implementation timeframes 
for small and rural OSPs--RLECs, non-nationwide CMRS providers, and 
internet-based TRS providers--which require these providers to comply 
with a 911 Authority's valid request at each phase of the NG911 
transition within 12 months after receiving a valid request or within 
12 months after the effective date of the rules in this document and 
the Order, instead of the six month compliance timeframe for OSPs that 
do not fall into any of these classifications. The extended timeframe 
recognizes the concerns of RLEC commenters' about the challenges that 
they may face when transitioning to NG911. The Commission considered 
but declined RWA's request that non-nationwide providers have 30 months 
from a valid PSAP request to implement NG911. We also considered but 
declined to adopt an alternative sought by the Alaska Telecom Assoc. 
for, (1) ``an implementation extension or exemption for non-IP 
networks, or portions of networks'' and ``longer implementation 
timelines as well as an opportunity for waivers of timing 
requirements;'' and (2) NG911 rules that provide carriers in Alaska 
with a presumptive waiver of mandated IP-delivery deadlines, provided 
such a carrier can demonstrate that it is working in good faith with 
the PSAP to complete the request a carrier can demonstrate that it is 
working in good faith with the PSAP to complete their request, 
recommending that OSPs and 911 Authorities negotiate alternative 
agreement timelines where reasonable.
    Reporting and Recordkeeping Requirements. The Order minimizes the 
burden of reporting requirements on businesses and governmental 
jurisdictions identified as small by the SBA. First, in response to 
comments, we adopt use of a Commission-owned registry for valid 911 
authority readiness requests as the most efficient and least burdensome 
method of communication between 911 authorities and OSPs. Furthermore, 
we considered but declined to implement any additional and new data 
collections for monitoring performance and compliance with the NG911 
rules the Commission adopts. Thus, the Commission does not impose any 
added costs in addition to those discussed in the NG911 Notice. As 
discussed in this document and in section E of the Order the rules 
adopted in the Order gives small and other OSPs more flexibility than 
proposed in the NG911 Notice by the allowing OSPs and 911 Authorities 
to agree to alternate timeframes or cost allocation arrangements 
instead of those the Commission adopts but imposes notification 
requirements OSPs must make to the Commission regarding any alternate 
arrangements.
    Impact on Universal Service. Small entities could potentially incur 
an economic impact if requiring the NG911 technology transitions 
adversely affects universal service in a way that deprives smaller 
entities of cost recovery mechanisms. However, given that under the 
adopted rules states remain free to implement cost recovery mechanisms 
as they deem necessary, the Commission concludes that the rules we 
adopt will not adversely impact universal service. Moreover, some 
parties argue the rules in the NG911 Notice are contrary to universal 
service principles because RLECs will bear disproportionate costs of 
the NG911 transition. This is incorrect. To the extent RLECs' higher-
cost service areas require them to spend more than urban and suburban 
OSPs for NG911 transition costs, those costs can be recovered from 
intra-state universal service funds. South Carolina RFA notes that its 
intra-state Universal Service Fund already provides generous subsidies 
to high-cost RLECs. Further, the Kansas RLECs indicate that the Kansas 
Universal Service Fund disbursements can be increased by the Kansas 
Corporation Commission (KCC) upon petition, which the KCC takes 
approximately 8 months to address. State regulatory agencies are better 
positioned than the Commission to assess the needs of their rural 
businesses and establish appropriate universal service policies for 
intra-state call traffic (such as 911) which best serve the interests 
of their state and local populations, both now and during the NG911 
transition.

G. Report to Congress

    The Commission will send a copy of the Order, including the FRFA, 
in a report to Congress pursuant to the Congressional Review Act. In 
addition, the Commission will send a copy of the Order, including the 
FRFA, to the Chief Counsel for Advocacy of the SBA.

VI. Ordering Clauses

    Accordingly, it is ordered, pursuant to sections 1, 2, 4(i), 201, 
214, 222, 225, 251(e), 301, 303, 316, and 332 of the Communications Act 
of 1934, as amended, 47 U.S.C. 151, 152, 154(i), 201, 214, 222, 225, 
251(e), 301, 303, 316, 332; the Wireless Communications and Public 
Safety Act of 1999, Public Law 106-81, as amended, 47 U.S.C. 615 note, 
615, 615a, 615a-1, 615b; and section 106 of the Twenty-First Century 
Communications and Video Accessibility Act of 2010, Public Law 111-260, 
47 U.S.C. 615c, that the Report and Order is adopted.
    It is further ordered that the amendments to part 9 of the 
Commission's rules, as set forth in Appendix A of the Report and Order, 
are adopted, effective sixty (60) days after publication in the Federal 
Register. Compliance will not be required for paragraphs (a), (b), and 
(c) of Sec.  9.31 and paragraphs (a) and (b) of Sec.  9.34 until after 
any review by the Office of Management and Budget that the Public 
Safety and Homeland Security Bureau deems necessary. The Commission 
delegates authority to the Public Safety and Homeland Security Bureau 
to publish a document in the Federal Register announcing that 
compliance date and revising paragraph (d) of Sec.  9.31 and paragraph 
(c) of Sec.  9.34.
    It is further ordered that the Commission's Office of the 
Secretary, Reference Information Center, shall send a copy of the 
Report and Order, including the Final Regulatory Flexibility Analysis, 
to the Chief Counsel for Advocacy of the Small Business Administration.
    It is further ordered that the Office of the Managing Director, 
Performance Program Management, shall send a copy

[[Page 78128]]

of the Report and Order in a report to be sent to Congress and the 
Government Accountability Office pursuant to the Congressional Review 
Act, 5 U.S.C. 801(a)(1)(A).

List of Subjects in 47 CFR Part 9

    Communications, Communications common carriers, Communications 
equipment, internet, Radio, Reporting and recordkeeping requirements, 
Security measures, Telecommunications, Telephone.

Federal Communications Commission.
Marlene Dortch,
Secretary, Office of the Secretary.

    For the reasons discussed in the preamble, the Federal 
Communications Commission amends 47 CFR part 9 as follows:

PART 9--911 REQUIREMENTS

0
1. The authority citation for part 9 continues to read as follows:

    Authority:  47 U.S.C. 151-154, 152(a), 155(c), 157, 160, 201, 
202, 208, 210, 214, 218, 219, 222, 225, 251(e), 255, 301, 302, 303, 
307, 308, 309, 310, 316, 319, 332, 403, 405, 605, 610, 615, 615 
note, 615a, 615b, 615c, 615a-1, 616, 620, 621, 623, 623 note, 721, 
and 1471, and Section 902 of Title IX, Division FF, Pub. L. 116-260, 
134 Stat. 1182, unless otherwise noted.


0
2. Revise Sec.  9.1 to read as follows:


Sec.  9.1  Purpose.

    The purpose of this part is to set forth the 911, E911, and Next 
Generation 911 service requirements and conditions applicable to 
telecommunications carriers (subpart B); commercial mobile radio 
service (CMRS) providers (subpart C); interconnected Voice over 
internet Protocol (VoIP) providers (subpart D); internet-based 
providers of telecommunications relay services (TRS) for persons with 
disabilities (subpart E); multi-line telephone systems (MLTS) (subpart 
F); and Mobile-Satellite Service (MSS) providers (subpart G). The rules 
in this part also include requirements to help ensure the resiliency, 
redundancy, and reliability of 911 communications systems (subpart H), 
acceptable obligations and expenditures of 911 fees (subpart I), and 
Next Generation 911 obligations (subpart J).

0
3. Add subpart J, consisting of Sec. Sec.  9.27 through 9.34, to read 
as follows:

Subpart J--Next Generation 911

Sec.
9.27 Applicability, scope, and purpose.
9.28 Definitions.
9.29 Next Generation 911 transition requirements.
9.30 Next Generation 911 implementation deadlines.
9.31 Valid requests for delivery of 911 traffic in Internet 
Protocol-based formats.
9.32 Designation of NG911 Delivery Points.
9.33 Cost responsibilities.
9.34 Modification of NG911 requirements by mutual agreement.


Sec.  9.27   Applicability, scope, and purpose.

    (a) The purpose of this subpart is to set forth requirements and 
conditions in order to facilitate the transition to Next Generation 911 
(NG911), and to assist with creating an NG911 architecture that is 
secure, interoperable, and based on commonly accepted standards.
    (b) The rules in this subpart apply to ``originating service 
providers'' as defined in Sec.  9.28.
    (c) An originating service provider subject to the rules in this 
subpart shall be considered to have delivered 911 traffic to a public 
safety answering point (PSAP) if the originating service provider's 911 
traffic is delivered to NG911 Delivery Points designated by the 911 
Authority pursuant to Sec.  9.32 and the other requirements in this 
subpart are satisfied.


Sec.  9.28   Definitions.

    For purposes of this subpart, the terms in this section have the 
following meanings:
    911 Authority. 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.
    911 traffic. Transmissions 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.
    Commonly accepted standards. The technical standards followed by 
the communications industry for network, device, and Internet Protocol 
connectivity that--
    (1) Enable interoperability; and
    (2) Are--
    (i) Developed and approved by a standards development organization 
that is accredited by a United States standards body (such as the 
American National Standards Institute) or an equivalent international 
standards body in a process that--
    (A) Is open to the public, including open for participation by any 
person; and
    (B) Provides for a conflict resolution process;
    (ii) Subject to an open comment and input process before being 
finalized by the standards development organization;
    (iii) Consensus-based; and
    (iv) Made publicly available once approved.
    Covered text provider. The term ``covered text provider'' has the 
meaning given such term under Sec.  9.10(q)(1).
    Emergency Services Internet Protocol Network (ESInet). An 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.
    Functional element. A set of software features that may be combined 
with hardware interfaces and operations on those interfaces to 
accomplish a defined task.
    Location Information Server (LIS). 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.
    Location Validation Function (LVF). A 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.
    Nationwide CMRS provider. The term ``nationwide CMRS provider'' has 
the meaning given such term under Sec.  9.10(i)(1)(iv).
    Next Generation 911 (NG911). An Internet Protocol-based system 
that--
    (1) Ensures interoperability;
    (2) Is secure;
    (3) Employs commonly accepted standards;
    (4) Enables emergency communications centers to receive, process, 
and analyze all types of 911 requests for emergency assistance;
    (5) Acquires and integrates additional information useful to 
handling 911 requests for emergency assistance; and
    (6) Supports sharing information related to 911 requests for 
emergency assistance among emergency communications centers and 
emergency response providers.

[[Page 78129]]

    NG911 Delivery Point. A geographic location, facility, or 
demarcation point designated by a 911 Authority where an originating 
service provider shall transmit and deliver 911 traffic in an IP format 
to ESInets or other NG911 network facilities.
    Non-nationwide CMRS provider. The term ``non-nationwide CMRS 
provider'' has the meaning given such term under Sec.  9.10(i)(1)(v).
    Non-rural wireline provider. A wireline provider that is not a 
rural incumbent local exchange carrier (as defined in Sec.  54.5 of 
this chapter).
    Originating service providers. Providers 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.
    Rural incumbent local exchange carrier (RLEC). The term ``rural 
incumbent local exchange carrier'' or ``RLEC'' has the meaning given 
such term under Sec.  54.5 of this chapter.
    Session Initiation Protocol (SIP). A signaling protocol used for 
initiating, maintaining, modifying, and terminating communications 
sessions between Internet Protocol (IP) devices. SIP enables voice, 
messaging, video, and other communications services between two or more 
endpoints on IP networks.
    Wireline provider. A local exchange carrier (as defined in 47 
U.S.C. 153(32)) that provides service using wire communication (as 
defined in 47 U.S.C. 153(59)).


Sec.  9.29   Next Generation 911 transition requirements.

    (a) Phase 1. Upon receipt of a 911 Authority's valid request, an 
originating service provider that is subject to the rules in this 
subpart shall, by the relevant deadline specified in Sec.  9.30(a)(1) 
or (b)(1)--
    (1) Deliver all 911 traffic bound for the relevant PSAPs in the IP-
based SIP format requested by the 911 Authority;
    (2) Obtain and deliver 911 traffic to enable the ESInet and other 
NG911 network facilities to transmit all 911 traffic to the destination 
PSAP;
    (3) Deliver all such 911 traffic to NG911 Delivery Points 
designated by the 911 Authority pursuant to Sec.  9.32; and
    (4) Complete connectivity testing to confirm that the 911 Authority 
receives 911 traffic in the IP-based SIP format requested by the 911 
Authority.
    (b) Phase 2. Upon receipt of a 911 Authority's valid request, an 
originating service provider that is subject to the rules in this 
subpart shall, by the relevant deadline specified in Sec.  9.30(a)(2) 
or (b)(2)--
    (1) Comply with all Phase 1 requirements set forth in paragraph (a) 
of this section;
    (2) Deliver all 911 traffic bound for the relevant PSAPs to NG911 
Delivery Points designated by the 911 Authority pursuant to Sec.  9.32 
in the IP-based SIP format that complies with NG911 commonly accepted 
standards identified by the 911 Authority, including having location 
information embedded in the call signaling using Presence Information 
Data Format--Location Object (PIDF-LO) or the functional equivalent;
    (3) Install and put into operation all equipment, software 
applications, and other infrastructure, or acquire all services, 
necessary to use a Location Information Server (LIS) or its functional 
equivalent for the verification of its customer location information 
and records; and
    (4) Complete connectivity testing to confirm that the 911 Authority 
receives 911 traffic in the IP-based SIP format that complies with the 
identified NG911 commonly accepted standards.


Sec.  9.30   Next Generation 911 implementation deadlines.

    (a) Non-rural wireline providers, nationwide CMRS providers, 
covered text providers, and interconnected VoIP providers shall--
    (1) Comply with the Phase 1 requirements set forth in Sec.  9.29(a) 
by six months after receiving a Phase 1 valid request from a 911 
Authority, as set forth in Sec.  9.31(a); and
    (2) Comply with the Phase 2 requirements set forth in Sec.  9.29(b) 
by:
    (i) Six months after receiving a Phase 2 valid request from a 911 
Authority, as set forth in Sec.  9.31(b); or
    (ii) If the 911 Authority's Phase 2 valid request is made before 
the originating service provider is compliant with the Phase 1 
requirements or is made before the Phase 1 implementation deadline, six 
months after the earlier of:
    (A) The date when the originating service provider is compliant 
with the Phase 1 requirements set forth in Sec.  9.29(a); or
    (B) The implementation deadline set forth in paragraph (a)(1) of 
this section.
    (b) RLECs, non-nationwide CMRS providers, and internet-based TRS 
providers shall--
    (1) Comply with the Phase 1 requirements set forth in Sec.  9.29(a) 
by 12 months after receiving a Phase 1 valid request from a 911 
Authority, as set forth in Sec.  9.31(a); and
    (2) Comply with the Phase 2 requirements set forth in Sec.  9.29(b) 
by:
    (i) 12 months after receiving a Phase 2 valid request from a 911 
Authority, as set forth in Sec.  9.31(b); or
    (ii) If the 911 Authority's Phase 2 valid request is made before 
the originating service provider is compliant with the Phase 1 
requirements or is made before the Phase 1 implementation deadline, 12 
months after the earlier of:
    (A) The date when the originating service provider is compliant 
with the Phase 1 requirements set forth in Sec.  9.29(a); or
    (B) The implementation deadline set forth in paragraph (b)(1) of 
this section.


Sec.  9.31   Valid requests for delivery of 911 traffic in Internet 
Protocol-based formats.

    (a) Phase 1 valid request. A 911 Authority's request for delivery 
of 911 traffic in the manner specified in Sec.  9.29(a) is a Phase 1 
valid request if the requesting 911 Authority--
    (1) Certifies that it has installed and placed into operation all 
of the infrastructure needed to receive 911 traffic in an IP-based SIP 
format and transmit such traffic to the PSAP(s) connected to it;
    (2) Certifies that it has obtained commitments from any ESInet 
provider, Next Generation 911 Core Services provider, and/or call 
handling equipment provider needed to facilitate and complete 
connectivity testing within the compliance timeframe applicable to the 
originating service provider;
    (3) Certifies that it is authorized to submit a valid request for 
the NG911 network to receive 911 traffic in an IP-based SIP format;
    (4) Identifies the NG911 Delivery Point(s) designated pursuant to 
Sec.  9.32; and
    (5) Provides notification to the originating service provider that 
includes the information and certifications set forth in paragraphs 
(a)(1) through (4) of this section. Notification by the 911 Authority 
via a registry made available by the Commission in accordance with 
requirements established in connection therewith, or any other written 
notification reasonably acceptable to the originating service provider, 
shall constitute sufficient notification for purposes of this 
paragraph.

[[Page 78130]]

    (b) Phase 2 valid request. A 911 Authority's request for delivery 
of 911 traffic in the manner specified in Sec.  9.29(b) is a Phase 2 
valid request if the requesting 911 Authority--
    (1) Certifies that it has installed and placed into operation all 
of the infrastructure needed to receive 911 traffic in an IP-based SIP 
format that complies with NG911 commonly accepted standards and 
transmit such traffic to the PSAP(s) connected to it;
    (2) Certifies that its ESInet is connected to a fully functioning 
Next Generation 911 Core Services network that can provide access to a 
Location Validation Function and interface with a Location Information 
Server or its functional equivalent provided by the originating service 
provider;
    (3) Certifies that it has obtained commitments from any ESInet 
provider, Next Generation 911 Core Services provider, and/or call 
handling equipment provider needed to facilitate and complete 
connectivity testing within the compliance timeframe applicable to the 
originating service provider;
    (4) Certifies that it is authorized to submit a valid request for 
the NG911 network to receive 911 traffic in an IP-based SIP format that 
complies with NG911 commonly accepted standards;
    (5) Identifies the NG911 Delivery Point(s) designated pursuant to 
Sec.  9.32; and
    (6) Provides notification to the originating service provider that 
includes the information and certifications set forth in paragraphs 
(b)(1) through (5) of this section. Notification by the 911 Authority 
via a registry made available by the Commission in accordance with 
requirements established in connection therewith, or any other written 
notification reasonably acceptable to the originating service provider, 
shall constitute sufficient notification for purposes of this 
paragraph.
    (c) Originating service providers' petitions challenging 911 
Authorities' requests. Within 60 days of the receipt of a Phase 1 or 2 
request from a 911 Authority, an originating service provider may 
submit a petition to the Public Safety and Homeland Security Bureau 
asserting that the 911 Authority's request does not satisfy a condition 
set forth in paragraph (a) or (b) of this section for a Phase 1 or 
Phase 2 valid request. The Public Safety and Homeland Security Bureau 
may review the petition and determine whether to pause the 
implementation deadline for that originating service provider, affirm 
the request of the 911 Authority as valid, or take other action as 
necessary.
    (1) The petition process shall be subject to the procedural 
requirements set forth in Sec. Sec.  1.41, 1.45, and 1.47 of this 
chapter.
    (2) The petition must be in the form of an affidavit signed by a 
director or officer of the originating service provider, documenting:
    (i) The basis for the originating service provider's assertion that 
the 911 Authority's request does not satisfy one or more of the 
conditions set forth in paragraph (a) or (b) of this section for a 
Phase 1 or Phase 2 valid request.
    (ii) Each of the specific steps the originating service provider 
has taken to implement the Phase 1 requirements set forth in Sec.  
9.29(a) or the Phase 2 requirements set forth in Sec.  9.29(b).
    (iii) The basis for the originating service provider's assertion 
that it cannot make further implementation efforts until the 911 
Authority satisfies the conditions set forth in paragraph (a) or (b) of 
this section for a Phase 1 or Phase 2 valid request.
    (iv) The specific steps that remain to be completed by the 
originating service provider and, to the extent known, the 911 
Authority or other parties before the originating service provider can 
implement the Phase 1 requirements set forth in Sec.  9.29(a) or the 
Phase 2 requirements set forth in Sec.  9.29(b).
    (3) All affidavits must be correct. The originating service 
provider's director or officer who signs the affidavit has the duty to 
personally determine that the affidavit is correct. If the affidavit is 
incorrect, he or she, as well as the originating service provider, may 
be subject to enforcement action.
    (4) An originating service provider may not file an inadequate or 
incomplete petition. If an originating service provider's petition is 
inadequate and/or incomplete and the originating service provider has 
not met its obligations as set forth in Sec.  9.29(a) or (b) at the 
time of the relevant deadline, the originating service provider may be 
considered noncompliant with the applicable rules as if the petition 
had not been filed.
    (5) An originating service provider that challenges a 911 
Authority's valid request must describe all steps taken toward 
implementing the Phase 1 requirements set forth in Sec.  9.29(a) or the 
Phase 2 requirements set forth in Sec.  9.29(b) that are not dependent 
on the readiness of the 911 Authority.
    (6) The 911 Authority may file an opposition to the originating 
service provider's petition and the originating service provider may 
file a reply to the opposition in accordance with Sec.  1.45 of this 
chapter. A copy of the document (petition, opposition, or reply) must 
be served on the other party (911 Authority or originating service 
provider) at the time of the filing in accordance with Sec.  1.47 of 
this chapter.
    (d) Paragraphs (a), (b), and (c) of this section may contain 
information collection and recordkeeping requirements that require 
review by the Office of Management and Budget. Compliance with those 
paragraphs will not be required until this paragraph (d) is removed or 
contains a compliance date.


Sec.  9.32   Designation of NG911 Delivery Points.

    A 911 Authority may designate one or more NG911 Delivery Points 
where originating service providers must deliver 911 traffic to the 
ESInet pursuant to Sec.  9.29, provided that--
    (a) Each NG911 Delivery Point is located in the same State or 
territory as the PSAPs connected to the ESInet; and
    (b) The 911 Authority or the ESInet provides facilities at the 
input to the NG911 Delivery Point to receive 911 traffic in accordance 
with the applicable phase.


Sec.  9.33   Cost responsibilities.

    (a) Originating service providers are responsible for the costs of 
complying with the applicable Phase 1 and Phase 2 requirements assigned 
to them under Sec.  9.29, including the costs of--
    (1) Transmitting 911 traffic to NG911 Delivery Points;
    (2) Delivering 911 traffic in the required IP-based SIP format at 
each phase, including the cost of IP conversion using a Legacy Network 
Gateway or the functional equivalent, if necessary; and
    (3) Obtaining and delivering location and routing information using 
ALI/ANI databases, selective routers, or other means at Phase 1, and 
using LIS functionalities or other equivalent means at Phase 2.
    (b) Originating service providers are not responsible for the costs 
of furnishing, maintaining, or upgrading NG911 Delivery Points, 
ESInets, Next Generation 911 Core Services networks, or PSAPs.


Sec.  9.34   Modification of NG911 requirements by mutual agreement.

    (a) Nothing in this subpart shall prevent 911 Authorities and 
originating service providers from establishing, by mutual consent, 
terms different from the requirements set forth in Sec. Sec.  9.29 
through 9.33.
    (b) If a 911 Authority and an originating service provider enter 
into an agreement pursuant to paragraph (a) of this section, within 30 
days of the

[[Page 78131]]

date when any such agreement is executed, the originating service 
provider must notify the Commission of the agreement. The notification 
must identify with specificity each requirement in the rules that is 
impacted by the agreement and must state with specificity how the terms 
of the agreement differ from each impacted rule. The same notification 
is required if the 911 Authority and originating service provider 
amend, modify, or terminate the agreement.
    (c) Paragraphs (a) and (b) of this section may contain information 
collection and recordkeeping requirements that require review by the 
Office of Management and Budget. Compliance with those paragraphs will 
not be required until this paragraph (c) is removed or contains a 
compliance date.

[FR Doc. 2024-18603 Filed 9-23-24; 8:45 am]
BILLING CODE 6712-01-P