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

Federal RegisterSep 24, 2024

Ask Donna

What actually matters in this document.

Text

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 §§ 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 §§ 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

John.Evanoff@fcc.gov

or 202-418-0848.

SUPPLEMENTARY INFORMATION:

This is a summary of the Commission's Report and Order in PS Docket Nos. 21-479 and 18-64, FCC 24-78, adopted on July 18, 2024, released on July 19, 2024, and corrected via an Erratum released on September 5, 2024. The full text of this document is available for public inspection at

https://docs.fcc.gov/public/attachments/FCC-24-78A1.pdf.

To request materials in accessible formats for people with disabilities (braille, large print, electronic files, audio format), send an email to

fcc504@fcc.gov

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

to take actions to start or continue the transition to NG911 in coordination with 911 Authorities.

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.

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.

“911 Authority” means “[a] state, territorial, regional, Tribal, or local governmental entity that operates or has administrative authority over all or any aspect of a communications network for the receipt of 911 traffic at NG911 Delivery Points and for the transmission of such traffic from that point to PSAPs.”

We implement a two-phased approach to guide the transition to NG911. Each phase is initiated by a 911 Authority submitting a valid request to OSPs within the jurisdiction where the 911 Authority is located for the OSPs to comply with NG911 requirements, including:

•

Phase 1:

Upon receiving a valid Phase 1 request from a 911 Authority, an OSP must commence delivery of 911 traffic in IP-based Session Initiation Protocol (SIP) format to one or more in-state NG911 Delivery Points designated by the 911 Authority. Phase 1 will enable 911 Authorities to deploy Emergency Services IP Networks (ESInets) in a cost-effective manner by selecting convenient delivery points to receive 911 traffic; will improve 911 reliability by using an IP-based format, rather than legacy format, to deliver 911 traffic; and will establish the transmission platforms necessary for upgrading to Phase 2.

•

Phase 2:

Upon receiving a valid Phase 2 request from a 911 Authority, an OSP must commence delivery of 911 traffic to the designated in-state NG911 Delivery Point(s) in an IP-based SIP format that complies with NG911 commonly accepted standards identified by the 911 Authority, including having location information embedded in the call signaling using Presence Information Data Format—Location Object (PIDF-LO)

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.

Phase 2 will facilitate use of

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.

See

Internet Engineering Task Force (IETF), Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO) (Sept. 2010),

https://datatracker.ietf.org/doc/html/rfc5962

(RFC 5962), and A Presence-based GEOPRIV Location Object Format (Dec. 2005),

https://datatracker.ietf.org/doc/html/rfc4119

(RFC 4119).

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

In the NG911 environment, a LVF works with the LIS to validate the location of a civic address prior to a call being placed to 911.

See, e.g.,

NENA: The 9-1-1 Association (NENA), The Next Generation 9-1-1 Guide for 9-1-1 Authorities at 38 (Apr. 21, 2020)

https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/nena-ref-005.1-2020_ng911_gu.pdf

(

NENA NG911 Guide for 911 Authorities

). The functionality of the LVF within NG911 replaces the E911 master street address guide (MSAG) validation in legacy 911 environments.

Id.

In this document and the Order, we define “Location Validation Function” (LVF) as “[a] Functional Element in an NG911 Core Services (NGCS) consisting of a server where civic location information is validated against the authoritative Geographic Information System (GIS) database information. A civic address is considered valid if it can be located within the database uniquely, is suitable to provide an accurate route for an emergency call, and is adequate and specific enough to direct responders to the right location.”

Nationwide CMRS providers,

covered text providers,

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,

non-nationwide CMRS providers,

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.

The term “nationwide CMRS provider” has the meaning given such term under 47 CFR 9.10(i)(1)(iv).

The term “covered text provider” has the meaning given such term under 47 CFR 9.10(q)(1).

“Rural incumbent local exchange carrier (RLEC)” has the meaning given such term under 47 CFR 54.5.

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),

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.

Petition for Rulemaking; Alternatively, Petition for Notice of Inquiry, CC Docket No. 94-102, PS Docket Nos. 18-64, 18-261, 11-153, and 10-255 (filed Oct. 19, 2021),

https://www.fcc.gov/ecfs/document/1019188969473/1

(NASNA Petition).

II. Background

911 service is a vital part of our nation's emergency response and disaster preparedness system. Since the first 911 call was placed in 1968,

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,

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.

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.

Federal Communications Commission (FCC),

911 and E911 Services, https://www.fcc.gov/general/9-1-1-and-e9-1-1-services

(May 15, 2024).

NENA,

9-1-1 Statistics, https://www.nena.org/page/911Statistics

(last visited May 29, 2024).

FCC, Fifteenth Annual Report to Congress on State Collection and Distribution of 911 and Enhanced 911 Fees and Charges at 16, tbl.3 (2023),

https://www.fcc.gov/sites/default/files/15th-annual-911-fee-report-2023.pdf

(Fifteenth Annual 911 Fee Report).

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.

In 2000, the

Commission designated 911 as the national emergency telephone number to be used for reporting emergencies and requesting emergency assistance.

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.

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.

911 Implementation Notice, 15 FCC Rcd at 17084-85, para. 11.

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 § 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 § 64.3002 the periods for transition to 911 as the universal emergency telephone number.

Id.

The Commission subsequently renumbered §§ 64.3001 and 64.3002 as current §§ 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.

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,

as well as 911 calls originated by wireless

and interconnected VoIP

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.

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.

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.

Below is a simplified diagram that demonstrates legacy 911 architecture.

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.

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

VoIP 911 Order at 10252, para. 15.

See id.

at 10252-53, para. 17.

See id.

at 10269, paras. 40-41.

See id.

at 10250-51, para. 12.

Id.

at 10251, para. 14.

Id.

at 10252, para. 14.

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

E911 Phase I implementation.

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.

In 2002, the Commission issued an Order on Reconsideration (King County Order on Reconsideration) affirming WTB's decision.

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.

The Commission also affirmed that PSAPs were required to bear E911 Phase I costs for delivery beyond the 911 selective router.

Finally, the Commission extended this determination to apply to CMRS providers' delivery of wireless E911 Phase II information to selective routers.

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.

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

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

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

King County Order on Reconsideration, 17 FCC Rcd at 14790, 14792-93, paras. 4, 7-8.

See id.

at 14790-91, 14792-93, paras. 4, 7-8.

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.

This recognition resulted in the 2005 VoIP 911 Order, in which the Commission imposed 911 service obligations on providers of interconnected VoIP.

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

See, e.g.,

VoIP 911 Order, 20 FCC Rcd at 10247-48, paras. 4-5.

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

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”

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.

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.

The NET 911 Act extended critical 911 service-related rights, protections, and obligations to VoIP service providers,

and mandated parity for VoIP providers vis-à-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.

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

See

H.R. Rep. No. 110-442, at 6-7 (2007).

NET 911 Act, Preamble.

Id.

secs. 101, 201(a).

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.

See, e.g.,

City of New York Office of Technology & Innovation, 2022 Annual Report on Implementation of Next Generation 9-1-1 in NYC at 4 (2022),

https://www.nyc.gov/assets/oti/downloads/pdf/reports/annual-report-next-generation-911-2022.pdf

(listing the primary technical benefits of NG911);

see also

NENA, Why NG9-1-1 at 1-2 (2009),

https://cdn.ymaws.com/www.nena.org/resource/resmgr/ng9-1-1_project/whyng911.pdf

(identifying the purposes of NG911).

Congress has recognized the Commission's role in facilitating the transition to NG911. As part of the 2010 National Broadband Plan, the Commission recommended that Congress consider developing a new “legal and regulatory framework for development of NG911 and the transition from legacy 911 to NG911 networks.”

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

an IP-enabled emergency network by individuals with disabilities, where achievable and technically feasible.

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.

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.

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

FCC, Connecting America: The National Broadband Plan, Recommendation 16.14 at 326 (2010),

http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-296935A1.pdf

(last visited May 16, 2023) (National Broadband Plan).

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

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.

FCC, Legal and Regulatory Framework for Next Generation 911 Services, Section 4.1.2.2 at 28-29 (2013),

https://transition.fcc.gov/Daily_Releases/Daily_Business/2013/db0227/DOC-319165A1.pdf

(last visited May 16, 2023) (2013 NG911 Framework Report).

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.

In addition, the Commission has updated 911 outage and reliability rules, including establishing reliability requirements for covered 911 service providers.

With respect to technology, E911 Phase II is now widely implemented,

and many state and local jurisdictions have deployed ESInets and taken other transitional steps towards NG911.

Although the NG911 transition remains ongoing and there are no fully enabled NG911 systems yet operating,

the technical architecture of NG911 systems has been developed in detail and is well-established,

and one service provider—Verizon—states that it has achieved end-to-end readiness with two local jurisdictions based on the NENA i3 standard.

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.

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

NENA,

9-1-1 Statistics, https://www.nena.org/page/911Statistics

(last visited May 16, 2023).

According to the most recent National 911 Annual Report, 2,287 PSAPs reported using an ESInet across 47 states in 2021, nearly a 5% increase from the 2020 data. National 911 Program, National 911 Annual Report, 2021 Data at 8, 60, 64 (2023),

https://www.911.gov/assets/2021-911-Profile-Database-Report_FINAL.pdf

(National 911 Annual Report).

Association of Public-Safety Communications Officials-International, Inc. (APCO) Comments at 1-2 (rec. Jan. 19, 2022) (APCO Comments) (“ECCs should be able to receive, process, and share appropriate information with responders in the field and with other ECCs in a secure and fully interoperable fashion [but] no part of the country can be described as having achieved this vision of NG9-1-1 with end-to-end broadband communications for ECCs.”);

see also

APCO, APCO International's Definitive Guide to Next Generation 9-1-1 at 9 (2022),

https://www.apcointl.org/ext/pages/APCOng911Guide/APCO_NG911_Report_Final.pdf

(noting that comprehensive, end-to-end NG911 “does not yet exist anywhere in the country”).

See

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

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

(TFOPA Final Report).

See

Press Release, Verizon continues industry leadership with additional NG911 i3 deployment (June 20, 2023),

https://www.verizon.com/about/news/verizon-continues-industry-leadership-additional-ng911-i3-deployment

(discussing i3 deployment in Livingston Parish, LA); Press Release, NGA, NGA, Verizon, Logan County (W. Va.) deploy nation's first End State NENA i3 (Dec. 16, 2022),

https://www.prnewswire.com/news-releases/nga-verizon-logan-county-w-va-deploy-nations-first-end-state-nena-i3-301705551.html

(discussing i3 deployment in Logan County, WV).

2. Standards Work and Federal Advisory Committee Reports

NENA i3 Transitional and End State NG911.

The public safety community has recognized the need to evolve to NG911, and industry associations and standards bodies have worked toward defining standard architectures and protocols for NG911. For example, NENA's “i3” standard describes a system architecture for NG911 that standardizes the structure and design of the software services, databases, network elements, and interfaces needed to process multimedia emergency calls and data for NG911.

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

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

The i3 standard envisions that NG911 will reach a mature “end state”

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.

The standard

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.

NENA, NENA i3 Standard for Next Generation 9-1-1 at 2 (Oct. 7, 2021),

https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/NENA-STA-010.3e-2021_i3_Stan.pdf

(NENA i3). In July 2021, NENA released the third version of the i3 standard for NG911.

See

NENA,

NENA Releases New Version of the i3 Standard for Next Generation 9-1-1

(July 12, 2021)

https://www.nena.org/news/572966/NENA-Releases-New-Version-of-the-i3-Standard-for-Next-Generation-9-1-1.htm.

In October 2021, the NENA i3 standard was approved by the American National Standards Institute (ANSI).

See

NENA,

ANSI Approves NENA's i3 Standard for Next Generation 9-1-1

(Oct. 7, 2021),

https://www.nena.org/news/582667/ANSI-Approves-NENAs-i3-Standard-for-Next-Generation-9-1-1.htm.

NENA i3 at 2.

NENA i3 at 2 (footnote omitted).

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.

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.

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.

This environment includes IP call set-up, location determination, validation, and delivery to ESInets across the country.

In addition, the three TFOPA Working Groups issued supplemental reports in 2016 concerning (1) an “Optimal Cybersecurity Approach for PSAPs”;

(2) an “NG 9-1-1 Readiness Scorecard”;

and (3) a “Funding Sustainment Model.”

See

T911 Second Report and Order, 29 FCC Rcd at 9881, paras. 79-80 (2014).

TFOPA Final Report at 114.

Id.

at 105.

FCC, Task Force on Optimal PSAP Architecture, Working Group 1 Supplemental Report (2016),

https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG1_Supplemental_Report-120216.pdf

(TFOPA WG 1 Report).

FCC, Task Force on Optimal PSAP Architecture, Working Group 2 Supplemental Report (2016),

https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG2_Supplemental_Report-120216.pdf

(TFOPA WG 2 Report). Regarding readiness, TFOPA WG 2, for example, observed that the NG911 transition process followed a “maturity continuum” ranging from a “legacy state” through “foundational, transitional, and intermediate” stages, on the way to a goal of full “end state” NG911 relative to PSAPs. TFOPA WG 2 Report at 12-14. Specifically, the WG 2 Report defined “Jurisdictional End State” (noting that a jurisdiction could be a Local, Regional, State or Tribal Authority and could be intrastate or interstate) as “the state in which PSAPs are served by i3 standards-based systems and/or elements, from ingress through multimedia `call' handling. Originating Service Providers are providing SIP interfaces and location information during call set-up time. Within the jurisdiction, ESInets are interconnected providing interoperability which is supported by established agreements, policies and procedures. Systems in the End State are NG9-1-1 Compliant.” TFOPA WG 2 Report at 13. Based on anecdotal information, including based on ESInet and NG911 early adopter case studies, TFOPA WG 2 noted that a “phased” implementation model offers the greatest opportunity for success, as opposed to a one-step implementation. TFOPA WG 2 Report at 12, 76-88.

FCC, Task Force on Optimal PSAP Architecture, Working Group 3 Supplemental Report (2016),

https://transition.fcc.gov/pshs/911/TFOPA/TFOPA_WG3_Supplemental_Report-120216.pdf

(TFOPA WG 3 Report). TFOPA WG 3 discusses among other things, 911 network and call routing, including providing historical context regarding the relationship between 911 networks and 911 jurisdictions relative to selective routing, and the role of FCC rules and state policies relative to originating service provider cost responsibilities. TFOPA WG 3 Report at 19-20.

Communications Security, Reliability, and Interoperability Council (CSRIC) VI and Small Carrier NG911 Considerations.

In 2017, the Commission directed CSRIC VI to recommend measures to improve both legacy 911 and NG911 systems, including recommending ways in which the Commission can further the NG911 transition, enhance the reliability and effectiveness of NG911, and assist small originating service providers as they transition to providing NG911 service.

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.

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.

The Transition Report is organized into three major sections, dealing with the scope and nature of the report;

analysis, findings and recommendations;

and a small carrier readiness checklist

structured around service provider support for migration to NG911. The report's recommendations relating to small carriers address: (1) transition timelines;

(2) the regulatory environment;

(3) NG911 funding;

(4) interconnection options;

and (5) delivering caller location to the NG911 ESInet.

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.

CSRIC VI Working Group 1,

Transition Path to NG9-1-1 Final Report—Small Carrier NG9-1-1 Transition Considerations,

secs. 1.1, 3.1 (Sept. 2018),

https://www.fcc.gov/sites/default/files/csric6wg1sept18ng911report.docx

(CSRIC NG911 Transition Report). The FCC charged CSRIC VI with defining the long term network requirements for transmitting emergency services information to emergency services organizations and personnel that is beyond communications between PSAPs, and between the public and PSAPs.

Id.

sec. 1.1. CSRIC VI Working Group 1 was charged to specifically look at service provider support for public safety transition to NG911.

Id.

sec. 1.1.

Id.

sec. 3.

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.

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.

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.

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.

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.

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

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

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.

CSRIC suggested that the Commission update its

King County

decision in order to resolve ongoing uncertainty about cost responsibilities in the NG911 environment.

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

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

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.

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.

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.

Id.

sec. 5.1.5.

Id.

sec. 5.2.1.

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.

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

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.

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.

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.

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.

NASNA Petition at 1.

Id.

at 2, 4-5.

Id.

at 2-3, 5-7.

Id.

at 3, 7-8.

Public Safety and Homeland Security Bureau Seeks Comment on Petition for Rulemaking Filed by the National Association of State 911 Administrators,

CC Docket No. 94-102 and PS Docket Nos. 21-479, 18-261, 18-64, 11-153, and 10-255, Public Notice, 36 FCC Rcd 17805 (PSHSB 2021),

https://www.fcc.gov/document/pshsb-seeks-comment-nasna-petition-rulemaking

(Public Notice). Comments, replies, and ex partes in this proceeding may be viewed in the Commission's Electronic Comment Filing System (ECFS):

https://www.fcc.gov/ecfs/search/search-filings/results?q=(proceedings.name:(%2221-479%22)).

Wireless Location-Based Routing.

In December 2022, the Commission issued the Location-Based Routing Notice proposing to require CMRS and covered text providers to implement location-based routing for 911 calls and texts nationwide.

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.

In addition, the Commission proposed to establish time frames for CMRS and covered text providers to deliver IP-based 911 traffic.

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.

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.

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

Id.

at 15185, 15202, paras. 4, 46.

Id.

at 15203, para. 50.

Id.

at 15204, para. 52.

NENA,

9-1-1 Statistics, https://www.nena.org/page/911Statistics

(last visited May 30, 2024).

NG911 Notice Proposed Framework.

In June 2023, the Commission issued the NG911 Notice seeking to establish a framework that would expedite the nation's transition to NG911 by proposing comprehensive requirements that would apply to wireline, CMRS, interconnected VoIP, and internet-based TRS providers.

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.

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.

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.

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

Id.

at 6205-06, para. 2.

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.

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.

In addition, the Commission sought to align the NG911 transition rules for wireline,

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.

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

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.

NG911 Notice, 38 FCC Rcd at 6206, para. 3.

Id.

(citing NASNA Petition at 6).

Public Safety and Homeland Security Bureau Announces Comment and Reply Comment Dates for the Notice of Proposed Rulemaking on Facilitating Implementation of Next Generation 911 Services (NG911),

PS Docket No. 21-479, Public Notice, DA 23-596, 2023 WL 4503161 (PSHSB July 10, 2023). A list of entities that filed comments, replies, and ex partes may be found in Appendix C of the Order. Comments, replies, and ex partes in this proceeding may be viewed in the Commission's Electronic Comment Filing System (ECFS):

https://www.fcc.gov/ecfs/search/search-filings/results?q=(proceedings.name:(%2221-479%22)).

We note that there are also comments, replies, and ex partes filed in response to the LBR Notice pertaining to issues that we address in this proceeding. Those filings can be viewed in the location-based routing docket (PS Docket No. 18-64) in the Commission's ECFS:

https://www.fcc.gov/ecfs/search/search-filings/results?q=(proceedings.name:(%2218-64*%22)).

LBR Order.

In 2024, we issued the LBR Order requiring all CMRS providers to implement location-based routing nationwide for wireless calls and real-time text (RTT) communications to 911 call centers.

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.

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.

Location-Based Routing for Wireless 911 Calls,

PS Docket No. 18-64, Report and Order, FCC 24-4, 2024 WL 356874 (Jan. 26, 2024),

https://www.fcc.gov/document/fcc-adopts-rules-improve-wireless-911-call-routing-0,

89 FR 18488 (Mar. 13, 2024) (LBR Order).

See

LBR Order at *2, para. 3.

100

Id.

at *2, *24, *32, *37, *38, paras. 3, 66, 92, 110, 113.

III. Discussion

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

A. The Need for Rules To Facilitate the NG911 Transition

In the NG911 Notice and LBR Notice, the Commission proposed to expedite the nationwide transition to NG911 by adopting certain requirements that would apply to wireline, CMRS, covered text, interconnected VoIP, covered text providers, and internet-based TRS providers.

101

Together, our proposals were intended not only to expedite this vital transition, but also to help ensure that the nation's 911 system functions effectively and utilizes advanced capabilities.

102

In addition, the proposed rules in the NG911 Notice responded to the petition from NASNA, the organization that represents state 911 administrators, urging the Commission to adopt rules to facilitate the transition to NG911.

103

101

NG911 Notice, 38 FCC Rcd at 6205-06, paras. 1-2; LBR Notice, 37 FCC Rcd at 15201, para. 46.

102

NG911 Notice, 38 FCC Rcd at 6206, para. 3; LBR Notice, 37 FCC Rcd at 15202, para. 48.

103

NG911 Notice, 38 FCC Rcd at 6206, para. 3; NASNA Petition.

As the Commission noted in the NG911 Notice, to achieve the transition to NG911, state and local 911 authorities must implement IP-based technologies and applications that will provide all of the functions of the legacy E911 system as well as new capabilities.

104

NG911 relies on IP-based architecture to provide an expanded array of emergency communications services that encompasses both the core functionalities of legacy E911 and additional functionalities that take advantage of the enhanced capabilities of IP-based devices and networks.

105

The transition to NG911 involves fundamental changes in the technology that 911 Authorities use to receive and process 911 traffic, and it requires equally fundamental changes in the way OSPs deliver 911 traffic to PSAPs.

106

The benefits that result from the transition to NG911 include improvements to 911 network reliability and resilience,

107

improvements to interoperability between PSAPs, and location information that is available to PSAPs more quickly. As the Commission observed in the NG911 Notice, in its end state, NG911 will also support the transmission of text, photos, video, and data.

108

104

NG911 Notice, 38 FCC Rcd at 6212, para. 15.

105

Id.; Framework for Next Generation 911 Deployment,

PS Docket No. 10-255, Notice of Inquiry, 25 FCC Rcd 17869, 17877, para. 18 (2010), 76 FR 2297 (Jan. 13, 2011) (NG911 NOI).

106

See

NG911 Notice, 38 FCC Rcd at 6212-13, para. 16.

107

Letter from Lauren Kravetz, Vice President, Government Affairs, Intrado Life & Safety, Inc. (Intrado), to Marlene Dortch, Secretary, FCC, PS Docket No. 21-479, at 1 (filed Mar. 26, 2024) (Intrado Mar. 26, 2024

Ex Parte

); Industry Council for Emergency Response Technologies, Inc. (iCERT) NG911 Notice Comments at 1 (rec. Aug. 9, 2023) (iCERT NG911 Notice Comments).

108

NG911 Notice, 38 FCC Rcd at 6209, para. 10 (citing City of New York Office of Technology & Innovation, 2022 Annual Report on Implementation of Next Generation 9-1-1 in NYC at 4 (2022),

https://www.nyc.gov/assets/oti/downloads/pdf/reports/annual-report-next-generation-911-2022.pdf

(listing the primary technical benefits of NG911)).

Most states have already made significant commitments to implementing NG911.

109

Thirty-seven states and jurisdictions reported to the FCC in 2023 that they had ESInets operating in 2022.

110

Despite investments in these new capabilities, however, some states report experiencing delays in OSPs connecting to their ESInets.

111

Disputes with OSPs include issues of both cost allocation and the points to which the OSPs will deliver 911 traffic.

112

In addition, some commenters contend that some OSPs have financial incentives to delay transitioning from legacy 911 to NG911, resulting in protracted disputes and mounting costs for 911 Authorities, and

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

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

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

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

interoperability of NG911 systems, NENA argues that any definition of NG911 should reference “an i3-centric architecture.”

143

Colorado PUC agrees that the Commission should consider including language regarding “i3 standard compatibility” in the NG911 definition, stating that “[t]he vast majority, if not all” implementations of NG911 technology across the country have the goal of deploying i3-based NG911 systems.

144

In contrast, APCO opposes incorporating i3 or any other specific NG911 standard into the Commission's rules, noting that there are alternative potential standards, that the telecommunications ecosystem and technology continue to evolve, and that Emergency Communications Centers (ECCs) should have flexibility to pursue their preferred approaches with a “technology-neutral approach” that ensures “ECCs can continually benefit from ongoing innovation.”

145

APCO urges that the Commission must avoid rules or assumptions that might “lock ECCs into a particular approach to implementing NG9-1-1” and should not adopt rules “that bake in specific architectures for NG9-1-1.” APCO states that this is why the public safety community's “comprehensive definition of NG9-1-1 [

i.e.,

the definition in H.R. 3565, H.R. 1784, and H.R. 7624] references the use of `commonly accepted standards' rather than identify[ing] a particular standard for NG9-1-1.”

146

Mission Critical Partners also advocates for a “technology-neutral definition” of NG911 “to reduce any ambiguity by providers or 911 authorities regarding compliance with the proposed NG911 rulemaking.”

147

143

Id. See also

NENA, NENA Releases New Version of the i3 Standard for Next Generation 9-1-1 (July 12, 2021),

https://www.nena.org/news/572966/NENA-Releases-New-Version-of-the-i3-Standard-for-Next-Generation-9-1-1.htm.

144

Colorado Public Utilities Commission (Colorado PUC) NG911 Notice Comments at 10 (rec. Aug. 9, 2023) (Colorado PUC NG911 Notice Comments).

145

Letter from Jeffrey S. Cohen, Chief Counsel, Mark S. Reddish, Senior Counsel, and Alison P. Venable, Government Relations Counsel, APCO International, to Marlene H. Dortch, Secretary, FCC, PS Docket No. 21-479, at 2 (filed Oct. 31, 2023) (APCO Oct. 31, 2023

Ex Parte

); APCO NG911 Notice Reply at 2 & n.5; APCO NG911 Notice Comments at 1-2.

146

APCO NG911 Notice Reply at 2;

see also

APCO Oct. 31, 2023

Ex Parte

at 2 (noting “the public safety community's legislative efforts to require the use of `commonly accepted standards' rather than a particular method for achieving the capabilities envisioned” for NG911); APCO NG911 Notice Comments at 1-3 (“The public safety community has coalesced around a comprehensive vision for NG9-1-1 based on a technology-neutral approach that fosters a competitive marketplace and is pursuing significant federal funding legislation that has received broad bipartisan support on Capitol Hill.”).

147

Mission Critical Partners NG911 Notice Coments at 10;

accord

Intrado Mar. 26

Ex Parte

at 4-5 (Intrado “typically respond[s] to RFPs by proposing the use of a `mutually agreed industry standard,' with the intention to base the deployment on a foundation of i3 methodology tailored to the circumstances.”).

We find that adopting a definition of NG911 will facilitate compliance with the NG911 rules, as it will help promote clarity and certainty about the Commission's NG911 requirements. Accordingly, we adopt the definition of NG911 used in the Spectrum Auction Reauthorization Act of 2023 (H.R. 3565), a definition that is supported by multiple stakeholders in the public safety community and that has been used in several recent pieces of proposed Federal legislation. Although not all commenters to this proceeding support this specific definition, we believe that it comes closest to reflecting a broad consensus as to the essential elements that should be included in a definition of NG911. In particular, the definition will advance our goal of a technology-neutral approach to implementation of NG911, and it contains the important requirements that an NG911 system ensure interoperability, be secure, and employ commonly accepted standards.

We decline to reference any specific standard or set of standards as part of the codified definition of NG911. Although NENA and Colorado PUC advocate for including a reference to the i3 standard in the rules, we conclude that the better approach is to adopt a technology-neutral definition that avoids referencing any specific standard. As discussed below, we believe commenters' concerns that NG911 development be standards-based are fully addressed by including “commonly accepted standards” as an element of our NG911 definition.

148

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

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

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

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

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 § 9.10(a); covered text providers, as defined in § 9.10(q)(1); interconnected Voice over Internet Protocol (VoIP) providers, including all entities subject to subpart D of this part; and internet-based Telecommunications Relay Service (TRS) providers that are directly involved with routing 911 traffic, pursuant to subpart E of this part.

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

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

the i3 standard, with the former being a prerequisite for the latter.” MSCI suggests that the Commission consider “a two-step approach to NG911 deployment. The first step would involve a requirement that an OSP deliver 911 calls in IP format [upon request of a 911 Authority] . . . . The second step would involve a requirement that an OSP deliver 911 calls consistent with NENA i3 standard . . . .” The rules are very similar to Intrado's and MSCI's recommendations.

NASNA proposed a three-phase approach in which the initial phase would be triggered when the 911 Authority has an ESInet that is ready to receive 911 calls from the OSPs via an LNG. Colorado PUC similarly contemplates a phase in which 911 Authorities would maintain an LNG. We conclude that incorporating this initial phase into our rules is unnecessary and potentially counterproductive, as it merely describes the earliest transitional stage in which 911 Authorities continue to maintain LNGs to accommodate OSPs that have not transitioned to IP. We agree with MSCI that including this “legacy phase” could “prolong the migration.”

205

Instead, Phase 1 and Phase 2 in our rules correspond to the second and third phases proposed by NASNA, which call for OSPs to first support basic SIP and then support SIP that complies with NG911 commonly accepted standards.

205

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

We prefer the two-phase approach to the single-phase approach proposed in the LBR Notice and NG911 Notice because a single-phase approach is less capable of encompassing the sequencing of steps that both 911 Authorities and OSPs must take during the NG911 transition. As discussed by several commenters, a phased regulatory approach aligns with the typical multi-phased implementation of NG911. In addition, we find it unnecessary to seek further comment on whether to adopt a phased approach, given that the Commission sought comment on NASNA's phased recommendation in the NG911 Notice and has gathered an adequate record for decision.

206

We additionally conclude that, in light of the extensive record in this proceeding, an industry task force is not needed to further study these NG911 rules. We also find that a two-phased approach will not needlessly slow the transition to NG911, as argued by APCO, as the phased approach we adopt will ensure that OSPs and 911 Authorities take the necessary steps at each phase of the transition to NG911.

206

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

We affirm the Commission's reasoning in the LBR Notice and NG911 Notice that IP delivery requirements will advance the transition to NG911 by alleviating the burden on 911 Authorities to maintain transitional gateways and helping 911 Authorities realize the public safety benefits of NG911 networks. We agree with iCERT's assertion that the need to accommodate TDM-based 911 calls creates added costs for state and local 911 authorities, and that the adoption of IP delivery requirements will reduce the cost burdens of maintaining and operating legacy 911 infrastructure. We also agree with Intrado's assertion that establishing direct OSP connectivity via SIP to ESInets “will materially reduce the number of 911 outages through improved network reliability and availability.”

207

We agree with Comtech that maintaining both legacy and IP-based systems for the delivery of 911 traffic involves significant costs and creates increased vulnerability and risk of 911 outages. NENA also states that it is prohibitively expensive to maintain TDM and IP networks for 911 simultaneously.

207

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

Ex Parte

In addition, we affirm the principle of parity in NG911 requirements for OSPs at Phases 1 and 2, though as discussed in this document and section III.C.3 of the Order, differences among types of OSPs regarding their current NG911 transition progress and capabilities merit adjustment of compliance timelines for some classes of OSPs. NENA, iCERT, NASNA, Maine PUC, Colorado PUC, Mission Critical Partners, and the Ad Hoc NG911 Service Providers Coalition support parity among different types of OSPs. Several commenters indicate that the Commission should decline to extend IP delivery requirements to wireline and VoIP providers as these services deliver location information to 911 Authorities differently than CMRS providers.

208

We note that interconnected VoIP providers already use a LIS functional element to transmit location information to 911 Authorities, subject to the NENA i2 standard,

209

and we therefore find arguments that interconnected VoIP providers cannot provide location information to NG911 networks via a LIS to be unsupported. The record also confirms that it is technically feasible for wireline providers to use a LIS to transmit location information to 911 Authorities, even when they do not originate calls in IP. We also note that nothing under these rules changes the existing obligations that all OSPs have to determine the location of the 911 caller under the OSP-specific rules in part 9.

208

South Carolina RLECs NG911 Notice Reply at 13 (rec. Sept. 8, 2023) (South Carolina RLECs NG911 Notice Reply) (stating that it is premature to extend IP delivery requirements to fixed wireline carriers, and that such rules should not be applied to wireline and VoIP because this would be expensive and unnecessary due to differences in how fixed and mobile 911 location data is delivered); Home Telephone ILEC LLC (Home Telephone) NG911 Notice Comments at 15-16 (rec. Aug. 9, 2023) (Home Telephone NG911 Notice Comments) (stating that the Commission should not require wireline providers to deliver location data in IP format, as RLECs lack that capability); USTelecom NG911 Notice Comments at 3 (rec. Aug. 9, 2023) (USTelecom NG911 Notice Comments) (stating that it is technically infeasible for some wireline carriers to include location information in IP call headers, requiring continued reliance on ALI databases); Five Area Telephone Cooperative, Inc. and Mid-Plains Rural Telephone Cooperative, Inc. (Five Area Telephone) NG911 Notice Comments at 5 (rec. Aug. 9, 2023) (Five Area Telephone NG911 Notice Comments) (arguing that wireline and VoIP carriers cannot provide the same automated location data as CMRS); NTCA-The Rural Broadband Association (NTCA) NG911 Notice Comments at 16-17 (rec. Aug. 9, 2023) (NTCA NG911 Notice Comments) (arguing that wireline providers should be allowed to continue to rely on ALI for location information and should not have to provide the location information proposed in the LBR proceeding for CMRS and covered text providers).

209

NENA, Interim VoIP Architecture for Enhanced 9-1-1 Services (i2) at page 58 (Dec. 6, 2005),

https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards-archived/nena_08-001-v1_interim_voip_.pdf

(“The i2 solution proposes a Location Information Server (LIS) be the source for distributing location information within an access network.”).

b. Phase 1

(i) Requirement

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

The diagram below demonstrates the main high-level functions covered at Phase 1. This diagram is not meant to

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.

ER24SE24.002

The above diagram uses the following acronyms:

• ANI = Automatic Number Identification

• ALI = Automatic Location Information

• BCF = Border Control Function

• ESInet = Emergency Services IP Network

• IMS = IP Multimedia Subsystem

• LIS = Location Information Server

• LNG = Legacy Network Gateway

• LPG = Legacy PSAP Gateway

• LSRG = Legacy Selective Router Gateway

• MSAG = Master Street Address Guide

• NG PSAP = Next Generation 911 PSAP

• NGCS = NG911 Core Services

• TDM = Time Division Multiplex

Implementing Phase 1 will help reduce costs and improve 911 reliability by moving 911 traffic from legacy to IP transmission facilities, and will establish the foundation necessary for subsequent implementation of Phase 2. MSCI and iCERT argue, and we agree, that delivery in IP is a critical first step before compliance with NG911 commonly accepted standards.

210

Intrado asserts that IP delivery will “materially reduce the number of 911 outages through improved network reliability.” Mission Critical Partners, iCERT, Comtech, and the State of Minnesota Department of Public Safety-Emergency Communication Networks (Minnesota DPS-ECN) indicate that relieving 911 Authorities of the burden of supporting TDM traffic from OSPs will materially reduce costs to those 911 Authorities.

210

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

Ex Parte,

Attach. at 4; iCERT Dec. 13, 2023 Office of Commissioner Carr

Ex Parte,

Attach. at 4; iCERT Dec. 13, 2023 Office of Commissioner Starks

Ex Parte,

Attach. at 4.

To the extent that OSPs originate 911 traffic in TDM, we find that they should be responsible in Phase 1 for translating such traffic to SIP when delivering it to the designated NG911 Delivery Point. We disagree with Verizon's argument that requiring each individual TDM-based OSP to provide an LNG “imposes unnecessary costs on OSPs” and that “LNG capabilities should thus presumptively remain the PSAP/NG911 provider's responsibility.”

211

As most OSPs already transmit traffic via SIP, it is unreasonable to require 911 Authorities to maintain LNGs for the small number of OSPs that continue to originate and transmit their traffic in TDM. In addition, we find that it is not unreasonably costly for OSPs that originate and transmit traffic in TDM to maintain an LNG or contract with a third party to translate 911 traffic. We find that it should be the responsibility of the OSP to translate 911 traffic from legacy formats and deliver 911 traffic in the SIP format requested by the 911 Authority. However, nothing in our rules prevents a 911 Authority from continuing to host an LNG for OSPs to use, either through an alternative agreement with an OSP or by choosing not to use the valid request mechanism in our rules. This possibility was noted by CSRIC, which observed that a 911 Authority's ESInet provider “can provide the LNG as a service and

accommodate small carriers coming on board with minimal expense to the smaller carrier.”

212

211

Verizon NG911 Notice Reply at 5 (rec. Sept. 8, 2023) (Verizon NG911 Notice Reply).

212

CSRIC NG911 Transition Report, sec. 5.1.1.2.2.3.

Connectivity Testing.

As part of Phase 1, we require OSPs to conduct connectivity testing to confirm that the 911 Authority receives 911 traffic in the IP-based SIP format requested by the 911 Authority. Such testing will help to ensure that the connection from the OSP to the 911 Authority is implemented correctly and meets the requirements of the 911 Authority. The Commission sought comment on testing related to NG911 delivery in the LBR Notice and NG911 Notice.

213

Several commenters emphasize the importance of connectivity testing as part of the process of initiating delivery of 911 traffic to ESInets.

214

Commenters also note that connectivity testing will require cooperation, coordination, and collaboration among multiple parties, including OSPs, NG911 vendors, and 911 Authorities.

215

Because the ability of OSPs to complete testing within the required time period depends on such cooperation, we condition the testing requirement on 911 Authorities securing commitments from their NG911 vendors to ensure that such vendors are available to complete connectivity testing by the compliance deadline applicable to the OSP.

213

LBR Notice, 37 FCC Rcd at 15208, para. 64; NG911 Notice, 38 FCC Rcd at 6228, para. 47.

214

See, e.g.,

T-Mobile LBR Notice Comments at 12 (rec. Feb. 16, 2023) (“Carriers cannot unilaterally deliver traffic in IP—they must first ensure that PSAPs are ready to receive it, which is verified through comprehensive testing.”) (T-Mobile LBR Notice Comments); Verizon LBR Notice Reply at 4 (rec. Mar. 20, 2023) (“[M]any of the technical and operational details will inevitably need to be addressed as part of the [NG911] implementation process”) (Verizon LBR Notice Reply); CCA NG911 Notice Comments at 7-8 (noting that it is important for OSPs to “meaningfully collaborate” with 911 Authorities on IP traffic delivery by ensuring that sufficient testing occurs to minimize real world issues when IP traffic is exchanged and NG911 is implemented).

215

CCA NG911 Notice Comments at 7-8 (“It is important for OSPs to meaningfully collaborate with 911 authorities on IP traffic delivery and NG911 to ensure readiness, account for any unique local circumstances or complexities, and ensure that sufficient planning and testing occurs to minimize real world issues when IP traffic is exchanged and NG911 is implemented.”); BRETSA NG911 Notice Reply at i (“The ESInet or NGCS provider is also the party which can confirm that the PSAPs are IP-ready, and which must cooperate in provisioning and testing IP call delivery.”); T-Mobile LBR Notice Comments at 12.

(ii) Definitions

To facilitate compliance with our rules for Phase 1 delivery, we adopt definitions for “911 traffic,” “NG911 Delivery Point,” and “Session Initiation Protocol (SIP).” Adopting functional definitions of these terms will provide guidance to OSPs in complying with our cost allocation and IP-delivery rules and will assist both OSPs and 911 Authorities by providing baseline definitions of important technical terms relevant to their needs. We define the term “911 traffic” as a convenient descriptor of the transmissions regulated under these rules. We similarly define the term “NG911 Delivery Point” as a convenient descriptor of the point to which an OSP's 911 traffic is delivered. While several commenters called for definitions of the terms “IP-capable,” “IP-based,” and “NG911-capable,”

216

the term “SIP” is a standard technical term used in NG911 reference materials.

217

“SIP” was also used by several other commenters in the record.

218

We believe that referencing “SIP” to describe IP delivery and 911 Authority readiness at Phases 1 and 2 and defining that term will provide clarity regarding the Commission's NG911 rules, as it is a technically more precise term than “IP-based format” and similar terms.

216

Comtech NG911 Notice Comments at 7; CTIA LBR Notice Reply at 2, 9-10; NENA LBR Notice Reply at 4-5; Southern Communications Services, Inc. d/b/a Southern Linc (Southern Linc) LBR Notice Reply at 8-9 (rec. Mar. 20, 2023).

217

See, e.g.,

NENA i3 at 3; NENA, NENA Knowledge Base (May 17, 2024),

https://kb.nena.org/wiki/SIP_(Session_Initiation_Protocol).

218

See, e.g.,

USTelecom NG911 Notice Reply at 4 (discussing the NG911 Notice's “proposal to require OSPs to provide location data with the SIP message”); T-Mobile NG911 Notice Comments at 4 (“SIP connectivity is a foundational building block for NG911.”); Intrado NG911 Notice Reply at 3 (rec. Sept. 8, 2023) (Intrado NG911 Notice Reply) (explaining its proposal that the first stage of PSAP readiness would be that a 911 Authority is “ready to certify that it can receive IP-formatted (

i.e.,

SIP) traffic at the designated IP POI”). Regarding IP Service Delivery, NASNA urged the Commission to assist with the transition to NG911 by, among other things, amending the Commission's rules to “specifically address NG911, including the standardized requirements associated with NG911 (

e.g.,

Session Initiation Protocol [SIP] format and provide location information attached to the SIP header of the call using Presence Information Data Format Location Object [PIDF-LO]).” NG911 Notice, 38 FCC Rcd at 6214-15, para. 20 (citing NASNA Petition at 4-5).

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

•

911 traffic.

Transmissions consisting of all 911 calls (as defined in §§ 9.3, 9.11(b)(2)(ii)(A), 9.14(d)(2)(iii)(A), and 9.14 (e)(2)(ii)(A)) and/or 911 text messages (as defined in § 9.10(q)(9)), as well information about calling parties' locations and originating telephone numbers and routing information transmitted with the calls and/or text messages.

•

NG911 Delivery Point.

A geographic location, facility, or demarcation point designated by a 911 Authority where an originating service provider shall transmit and deliver 911 traffic in an IP format to ESInets or other NG911 network facilities.

•

Session Initiation Protocol (SIP).

A signaling protocol used for initiating, maintaining, modifying, and terminating communications sessions between internet Protocol (IP) devices. SIP enables voice, messaging, video, and other communications services between two or more endpoints on IP networks.

c. Phase 2

(i) Requirement

Upon receipt of a 911 Authority's valid Phase 2 request, OSPs must deliver all 911 traffic bound for the relevant PSAPs to NG911 Delivery Points designated by the 911 Authority in an IP-based SIP format that complies with NG911 commonly accepted standards identified by the 911 Authority, including having location information embedded in the call signaling using Presence Information Data Format—Location Object (PIDF-LO)

219

or its functional equivalent. OSPs must also either (1) install and put into operation all equipment, software applications, and other infrastructure necessary to use a LIS or its functional equivalent for the verification of their customer location information and records, or (2) acquire services that can be used for the same purpose. In addition, OSPs must complete connectivity testing to confirm that the 911 Authority receives 911 traffic in the IP-based SIP f

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

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