Rule2024-18603
Facilitating Implementation of Next Generation 911 Services (NG911); Location-Based Routing for Wireless 911 Calls
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
September 24, 2024
Effective
November 25, 2024
Issuing agencies
Federal Communications Commission
Abstract
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.
Full Text
<html>
<head>
<title>Federal Register, Volume 89 Issue 185 (Tuesday, September 24, 2024)</title>
</head>
<body><pre>
[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 [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[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 <a href="/cdn-cgi/l/email-protection#105a7f787e3e5566717e7f7676507673733e777f66"><span class="__cf_email__" data-cfemail="a0eacfc8ce8ee5d6c1cecfc6c6e0c6c3c38ec7cfd6">[email protected]</span></a>
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 <a href="https://docs.fcc.gov/public/attachments/FCC-24-78A1.pdf">https://docs.fcc.gov/public/attachments/FCC-24-78A1.pdf</a>. To request materials in accessible formats
for people with disabilities (braille, large print, electronic files,
audio format), send an email to <a href="/cdn-cgi/l/email-protection#55333636606561153336367b323a23"><span class="__cf_email__" data-cfemail="096f6a6a3c393d496f6a6a276e667f">[email protected]</span></a> 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:
<bullet> 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.
<bullet> 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), <a href="https://datatracker.ietf.org/doc/html/rfc5962">https://datatracker.ietf.org/doc/html/rfc5962</a> (RFC 5962), and A Presence-based GEOPRIV Location Object
Format (Dec. 2005), <a href="https://datatracker.ietf.org/doc/html/rfc4119">https://datatracker.ietf.org/doc/html/rfc4119</a>
(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) <a href="https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/nena-ref-005.1-2020_ng911_gu.pdf">https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/nena-ref-005.1-2020_ng911_gu.pdf</a> (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), <a href="https://www.fcc.gov/ecfs/document/1019188969473/1">https://www.fcc.gov/ecfs/document/1019188969473/1</a> (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, <a href="https://www.fcc.gov/general/9-1-1-and-e9-1-1-services">https://www.fcc.gov/general/9-1-1-and-e9-1-1-services</a> (May
15, 2024).
\12\ NENA, 9-1-1 Statistics, <a href="https://www.nena.org/page/911Statistics">https://www.nena.org/page/911Statistics</a> (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), <a href="https://www.fcc.gov/sites/default/files/15th-annual-911-fee-report-2023.pdf">https://www.fcc.gov/sites/default/files/15th-annual-911-fee-report-2023.pdf</a> (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), <a href="https://www.nyc.gov/assets/oti/downloads/pdf/reports/annual-report-next-generation-911-2022.pdf">https://www.nyc.gov/assets/oti/downloads/pdf/reports/annual-report-next-generation-911-2022.pdf</a> (listing the
primary technical benefits of NG911); see also NENA, Why NG9-1-1 at
1-2 (2009), <a href="https://cdn.ymaws.com/www.nena.org/resource/resmgr/ng9-1-1_project/whyng911.pdf">https://cdn.ymaws.com/www.nena.org/resource/resmgr/ng9-1-1_project/whyng911.pdf</a> (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), <a href="http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-296935A1.pdf">http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-296935A1.pdf</a> (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), <a href="https://transition.fcc.gov/Daily_Releases/Daily_Business/2013/db0227/DOC-319165A1.pdf">https://transition.fcc.gov/Daily_Releases/Daily_Business/2013/db0227/DOC-319165A1.pdf</a> (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, <a href="https://www.nena.org/page/911Statistics">https://www.nena.org/page/911Statistics</a> (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), <a href="https://www.911.gov/assets/2021-911-Profile-Database-Report_FINAL.pdf">https://www.911.gov/assets/2021-911-Profile-Database-Report_FINAL.pdf</a>
(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), <a href="https://www.apcointl.org/ext/pages/APCOng911Guide/APCO_NG911_Report_Final.pdf">https://www.apcointl.org/ext/pages/APCOng911Guide/APCO_NG911_Report_Final.pdf</a> (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), <a href="https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_FINALReport_012916.pdf">https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_FINALReport_012916.pdf</a> (TFOPA Final Report).
\51\ See Press Release, Verizon continues industry leadership
with additional NG911 i3 deployment (June 20, 2023), <a href="https://www.verizon.com/about/news/verizon-continues-industry-leadership-additional-ng911-i3-deployment">https://www.verizon.com/about/news/verizon-continues-industry-leadership-additional-ng911-i3-deployment</a> (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), <a href="https://www.prnewswire.com/news-releases/nga-verizon-logan-county-w-va-deploy-nations-first-end-state-nena-i3-301705551.html">https://www.prnewswire.com/news-releases/nga-verizon-logan-county-w-va-deploy-nations-first-end-state-nena-i3-301705551.html</a>
(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), <a href="https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-STA-010.3e-2021_i3_Stan.pdf">https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-STA-010.3e-2021_i3_Stan.pdf</a> (NENA i3). 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) <a href="https://www.nena.org/news/572966/NENA-Releases-New-Version-of-the-i3-Standard-for-Next-Generation-9-1-1.htm">https://www.nena.org/news/572966/NENA-Releases-New-Version-of-the-i3-Standard-for-Next-Generation-9-1-1.htm</a>. 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), <a href="https://www.nena.org/news/582667/ANSI-Approves-NENAs-i3-Standard-for-Next-Generation-9-1-1.htm">https://www.nena.org/news/582667/ANSI-Approves-NENAs-i3-Standard-for-Next-Generation-9-1-1.htm</a>.
\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), <a href="https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG1_Supplemental_Report-120216.pdf">https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG1_Supplemental_Report-120216.pdf</a> (TFOPA WG 1 Report).
\61\ FCC, Task Force on Optimal PSAP Architecture, Working Group
2 Supplemental Report (2016), <a href="https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG2_Supplemental_Report-120216.pdf">https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG2_Supplemental_Report-120216.pdf</a> (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), <a href="https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG3_Supplemental_Report-120216.pdf">https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG3_Supplemental_Report-120216.pdf</a> (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), <a href="https://www.fcc.gov/sites/default/files/csric6wg1sept18ng911report.docx">https://www.fcc.gov/sites/default/files/csric6wg1sept18ng911report.docx</a> (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), <a href="https://www.fcc.gov/document/pshsb-seeks-comment-nasna-petition-rulemaking">https://www.fcc.gov/document/pshsb-seeks-comment-nasna-petition-rulemaking</a> (Public Notice). Comments, replies, and ex
partes in this proceeding may be viewed in the Commission's
Electronic Comment Filing System (ECFS): <a href="https://www.fcc.gov/ecfs/search/search-filings/results?q=">https://www.fcc.gov/ecfs/search/search-filings/results?q=</a>(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, <a href="https://www.nena.org/page/911Statistics">https://www.nena.org/page/911Statistics</a> (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):
<a href="https://www.fcc.gov/ecfs/search/search-filings/results?q=">https://www.fcc.gov/ecfs/search/search-filings/results?q=</a>(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: <a href="https://www.fcc.gov/ecfs/search/search-filings/results?q=">https://www.fcc.gov/ecfs/search/search-filings/results?q=</a>(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), <a href="https://www.fcc.gov/document/fcc-adopts-rules-improve-wireless-911-call-routing-0">https://www.fcc.gov/document/fcc-adopts-rules-improve-wireless-911-call-routing-0</a>, 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), <a href="https://www.nyc.gov/assets/oti/downloads/pdf/reports/annual-report-next-generation-911-2022.pdf">https://www.nyc.gov/assets/oti/downloads/pdf/reports/annual-report-next-generation-911-2022.pdf</a> (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), <a href="https://cdn.ymaws.com/www.nena.org/resource/resmgr/govaffairs/Joint_Letter_Congress_1_23_2.pdf">https://cdn.ymaws.com/www.nena.org/resource/resmgr/govaffairs/Joint_Letter_Congress_1_23_2.pdf</a> (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), <a href="https://energycommerce.house.gov/posts/chair-rodgers-announces-full-committee-markup-of-19-bills">https://energycommerce.house.gov/posts/chair-rodgers-announces-full-committee-markup-of-19-bills</a> (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), <a href="https://www.congress.gov/bill/118th-congress/house-bill/1784/text">https://www.congress.gov/bill/118th-congress/house-bill/1784/text</a>; H.R. 7624, 117th Cong. sec. 159(d)(11) (2022), <a href="https://www.congress.gov/bill/117th-congress/house-bill/7624/text">https://www.congress.gov/bill/117th-congress/house-bill/7624/text</a>. 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), <a href="https://www.congress.gov/bill/118th-congress/senate-bill/2712/text?s=1&r=72">https://www.congress.gov/bill/118th-congress/senate-bill/2712/text?s=1&r=72</a>. 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), <a href="https://www.nena.org/news/572966/NENA-Releases-New-Version-of-the-i3-Standard-for-Next-Generation-9-1-1.htm">https://www.nena.org/news/572966/NENA-Releases-New-Version-of-the-i3-Standard-for-Next-Generation-9-1-1.htm</a>.
\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, <a href="https://www.nena.org/page/standards">https://www.nena.org/page/standards</a> (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), <a href="https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards-archived/nena_08-001-v1_interim_voip_.pdf">https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards-archived/nena_08-001-v1_interim_voip_.pdf</a> (``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:
<bullet> ANI = Automatic Number Identification
<bullet> ALI = Automatic Location Information
<bullet> BCF = Border Control Function
<bullet> ESInet = Emergency Services IP Network
<bullet> IMS = IP Multimedia Subsystem
<bullet> LIS = Location Information Server
<bullet> LNG = Legacy Network Gateway
<bullet> LPG = Legacy PSAP Gateway
<bullet> LSRG = Legacy Selective Router Gateway
<bullet> MSAG = Master Street Address Guide
<bullet> NG PSAP = Next Generation 911 PSAP
<bullet> NGCS = NG911 Core Services
<bullet> 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), <a href="https://kb.nena.org/wiki/SIP_">https://kb.nena.org/wiki/SIP_</a>(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:
<bullet> 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.
<bullet> 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.
<bullet> 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:
<bullet> ANI = Automatic Number Identification
<bullet> ALI = Automatic Location Information
<bullet> BCF = Border Control Function
<bullet> ECRF = Emergency Call Routing Function
<bullet> ESInet = Emergency Services IP Network
<bullet> ESRP = Emergency Services Routing Proxy
<bullet> GIS = Geographic Information System
<bullet> IMS = IP Multimedia Subsystem
<bullet> LIS = Location Information Server
<bullet> LNG = Legacy Network Gateway
<bullet> LPG = Legacy PSAP Gateway
<bullet> LVF = Location Validation Function
<bullet> MSAG = Master Street Address Guide
<bullet> NG PSAP = Next Generation 911 PSAP
<bullet> NGCS = NG911 Core Services
<bullet> 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),
<a href="https://gismaps.vdem.virginia.gov/websites/PSC/RegionalAdvisoryCommittee/Documents/20221117MSAGALIMaint.pdf">https://gismaps.vdem.virginia.gov/websites/PSC/RegionalAdvisoryCommittee/Documents/20221117MSAGALIMaint.pdf</a>
(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).
---------------------------------------------------------------------------
<bullet> Functional Element. A set of software features that may be
combined with hardware interfaces and operations on those interfaces to
accomplish a defined task.
<bullet> 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.
<bullet> 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 m
[…truncated; see source link]Indexed from Federal Register on September 24, 2024.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.