Site Feedback

Title 47

Displaying title 47, up to date as of 10/02/2026. Title 47 was last amended 10/01/2026.
New Finding Aids are now available on eCFR.gov. The Parallel Table of Authorities, Subject Index, and Agency-prepared Indexes are now online! Learn more
eCFR Content

The Code of Federal Regulations (CFR) is the official legal print publication containing the codification of the general and permanent rules published in the Federal Register by the departments and agencies of the Federal Government. The Electronic Code of Federal Regulations (eCFR) is a continuously updated online version of the CFR. It is not an official legal edition of the CFR.

Learn more about the eCFR, its status, and the editorial process.

Subpart H—Resiliency, Redundancy, Interoperability, and Reliability of 911 Communications

§ 9.19 Provision of reliable 911 service.

(a) Definitions. Terms in this section and § 9.20 have the meanings set forth in §§ 9.3 and 9.28 and as follows:

(1) Monitoring aggregation point. A point at which network monitoring data for a 911 service area is collected and routed to a network operations center (NOC) or other location for monitoring and analyzing network status and performance.

(2) Certification. An attestation by a certifying official, under penalty of perjury, that a covered 911 service provider:

(i) Has satisfied the obligations of paragraph (c) of this section and § 9.20(a);

(ii) Has adequate internal controls to bring material information regarding network architecture, operations, and maintenance to the certifying official's attention; and

(iii) Has made the certifying official aware of all material information reasonably necessary to complete the certification.

(3) Certifying official. A corporate officer of a covered 911 service provider with supervisory and budgetary authority over network operations in all relevant service areas.

(4) Covered 911 service provider.

(i) Any entity that provides covered 911 services, which are 911, E911, or NG911 services for which a failure would impede the real-time routing, delivery, or transfer of 911 traffic. Covered 911 services include:

(A) The provision of 911, E911, or NG911 capabilities such as call routing, automatic location information (ALI), automatic number identification (ANI), or the functional equivalent of those capabilities, directly to a public safety answering point (PSAP), statewide default answering point, or appropriate local emergency authority as defined in § 9.3.

(B) The operation of one or more central offices that directly serve a PSAP. For purposes of this section, a central office directly serves a PSAP if it hosts a selective router or ALI/ANI database, provides equivalent NG911 capabilities, or is the last service-provider facility through which a 911 trunk or administrative line passes before connecting to a PSAP.

(C) The provision of Next Generation Core Services (NGCS) facilities, including NGCS location facilities or NGCS routing facilities, directly by contract or tariffed service to any 911 Authority, whether via owned and operated facilities or leased or contracted facilities.

(D) The operation of an ESInet or legacy PSAP gateway (LPG).

(E) The operation of a Location Information Server (LIS) or equivalent IP 911 location database that provides service to two or more originating service providers (OSPs).

(F) The operation of a Legacy Network Gateway (LNG), a legacy selective router gateway (LSRG), or an emergency services gateway (ESGW) used for IP conversion of 911 traffic, that provides service to two or more OSPs.

(G) The operation of a major IP transport facility.

(H) The operation of an IP 911 traffic aggregation facility.

(I) The operation of interstate interconnecting ESInet facilities.

(J) For purposes of the requirement in § 4.9(h) of this chapter to notify 911 special facilities about outages that potentially affect them, only entities described in paragraphs (a)(4)(i)(A) through (D) of this section are “covered 911 service providers.”

(ii) The term “covered 911 service provider” shall not include any entity that:

(A) Constitutes a PSAP, 911 Authority, or other governmental authority to the extent that it provides 911, E911, or NG911 capabilities; or

(B) Offers the capability to originate 911 calls where another service provider delivers those calls and associated number or location information to the appropriate 911 Authority.

(5) Covered 911 circuits and paths —

(i) Legacy covered 911 circuits. 911 facilities that originate at a selective router and terminate in the central office that serves the PSAP(s) to which the selective router delivers 911 calls, including all equipment in the serving central office necessary for the delivery of 911 calls to the PSAP. Legacy covered 911 circuits also include ALI and ANI facilities that originate at the ALI or ANI database and terminate in the central office that serves the PSAP(s) to which the ALI or ANI databases deliver 911 caller information, including all equipment in the serving central office necessary for the delivery of such information to the PSAP(s). In NG911 transitional architecture, circuits connected to LSRGs, ESGWs, or LPGs are also legacy covered 911 circuits.

(ii) IP covered 911 paths. Paths carrying IP communications that:

(A) Originate at an NG911 Delivery Point or equivalent ESInet point of interconnection and terminate at the last routing facility before the NG911 PSAP or the legacy PSAP gateway, including all equipment associated with a covered 911 service necessary for the delivery of 911 traffic to the PSAP, such as any trunks, circuits, or paths to and from NGCS facilities and the ESInet transmission network necessary for routing and caller location information to the PSAP(s), and any intermediate paths in the chains of delivery;

(B) Transport 911 traffic via major IP transport facilities for ultimate delivery at an NG911 Delivery Point or equivalent ESInet point of interconnection, including any intermediate paths in the chain of delivery; or

(C) Transport 911 traffic via IP 911 traffic aggregation facilities for ultimate delivery at an NG911 Delivery Point or equivalent ESInet point of interconnection, including any interconnecting paths between ESInets, and including any intermediate paths in the chain of delivery.

(6) Diversity audit. A periodic analysis of the geographic routing of network components to determine whether they are physically diverse. Diversity audits may be performed through manual or automated means, or through a review of paper or electronic records, as long as they reflect whether covered 911 circuits and paths are physically diverse.

(7) Monitoring links. Facilities that collect and transmit network monitoring data to a NOC or other location for monitoring and analyzing network status and performance.

(8) Physically diverse. Circuits or paths are physically diverse if they provide more than one physical route between end points with no common points where a single failure at that point would cause both circuits or paths to fail. Circuits or paths that share a common segment such as a fiber-optic cable or circuit board are not physically diverse even if they are logically diverse for purposes of transmitting data. IP routers, transport nodes, and node links create physical diversity if these elements are redundant, geographically distributed, load balanced, and capable of automatic failover and rerouting to redundant elements sufficient to reasonably mitigate the risks of single points of failure.

(9) Tagging. An inventory management process whereby legacy covered 911 circuits are labeled in circuit inventory databases to make it less likely that circuit rearrangements will compromise diversity. A covered 911 service provider may use any system it wishes to tag legacy covered 911 circuits so long as it tracks whether those facilities are physically diverse and identifies changes that would compromise such diversity.

(10) Geographically distributed. 911 network architecture is geographically distributed if 911 traffic can be delivered through more than one covered 911 facility in different geographic locations in different physical facilities.

(11) Load balanced. 911 network architecture is load balanced if call volume is dynamically distributed among multiple active databases or call processing facilities to accommodate changes in traffic volume.

(12) Major IP transport facility. Dedicated SIP facilities that include voice and text transport meeting or exceeding Optical Carrier 48 (OC48)/2.5 Gbps in capacity that collect and/or transmit IP 911 traffic mixed with non-911 traffic, originated from two or more OSPs and transported over interstate routes, for ultimate transport and delivery to an NG911 Delivery Point or equivalent ESInet point of interconnection. Any 911 traffic originated on the facility provider's network is not considered for purposes of determining whether a provider is serving two or more OSPs.

(13) IP 911 traffic aggregation facility. Facilities that collect and segregate IP 911 traffic from non-911 traffic for two or more OSPs, or transport such 911-only traffic for ultimate delivery to an NG911 Delivery Point or equivalent ESInet point of interconnection. Any 911 traffic originated on the facility provider's network is not considered for purposes of determining whether a provider is serving two or more OSPs.

(14) NGCS location facilities. NG911 IP facilities connected to an ESInet that enable the real-time provision of 911 caller location information to the PSAPs, including but not limited to the Emergency Call Routing Function (ECRF), the Location Validation Function (LVF), and successor technologies.

(15) NGCS routing facilities. NG911 IP facilities connected to an ESInet that enable the real-time routing, delivery, or transfer of 911 traffic to PSAPs along with callback information and other associated data, including but not limited to the Emergency Services Routing Proxy (ESRP), the Policy Routing Function (PRF), and successor technologies.

(16) Interstate interconnecting ESInet facilities. Interstate facilities that transport IP 911 traffic from an ESInet for ultimate delivery to another ESInet, including facilities designated for intermittent, contingent, or backup exchange of IP 911 traffic between ESInets.

(17) Interoperability standards testing. Testing of covered 911 services and covered 911 circuits and paths to determine whether an NG911 interoperability solution conforms to a relevant commonly accepted standard.

(18) Interoperability conformance testing. Testing conducted between two or more NG911 covered 911 service providers in different states that validate the interoperable exchange of information.

(19) Interoperability. The technical and operational capability of NG911 systems, networks, and services to exchange 911 voice, text, data, and multimedia between jurisdictions, PSAPs, and service providers, in real time without the need for proprietary interfaces and regardless of jurisdiction, equipment, device, software, service provider, or other relevant factors.

(b) Provision of reliable 911 service. All covered 911 service providers shall take reasonable measures to provide reliable 911 service that ensures physical diversity, operational integrity, and network monitoring for their covered 911 facilities. Performance of the elements of the certification set forth in paragraphs (c)(1) through (3) of this section shall be deemed to satisfy the requirements of this paragraph (b). If a covered 911 service provider cannot certify that it has performed a given element, the Commission may determine that such provider nevertheless satisfies the requirements of this paragraph (b) based upon a showing that it is taking alternative measures with respect to that element that are reasonably sufficient to mitigate the risk of failure, or that one or more certification elements are not applicable to its network.

(c) 911 reliability benchmarks —

(1) Physical diversity. A covered 911 service provider shall certify that all IP covered 911 paths and legacy covered 911 circuits in its network are physically diverse as defined in paragraph (a)(8) of this section.

(i) For IP covered 911 paths, covered 911 service providers may satisfy this physical diversity benchmark by implementing automatic rerouting capabilities, load balancing, and geographically-distributed routing facilities, transport nodes, and node links sufficient to reasonably mitigate the risks of single points of failure. Covered 911 service providers may use dedicated diverse private facilities such as MPLS, cloud-based path redundancy, or VPN services over the public internet or equally secure industry protocols as automatically re-routed paths.

(ii) For legacy covered 911 circuits, covered 911 service providers may satisfy this physical diversity benchmark by conducting yearly diversity audits and certifying that all of the legacy covered 911 circuits in its network are tagged and are physically diverse such that no network or facility element constitutes a single point of failure.

(2) Operational integrity. A covered 911 service provider shall certify whether its central offices hosting selective routers, ALI/ANI, or functioning as the last central office serving a PSAP, or its LNG, LIS, LSRG, ESGW, LPG, or NGCS functional elements covered by paragraph (a)(4)(i) of this section in its network achieve operational integrity. Transitional elements for TDM-IP conversion, such as the LSRG or LPG, may certify to either paragraph (c)(2)(i) or (ii) of this section, in the latter case with 24 hours of backup power.

(i) LNGs, LISs, LSRGs, ESGWs, LPGs, and NGCS facilities covered by paragraph (a)(4)(i) of this section achieve operational integrity if they have the capability to ensure continuity of services via an uninterruptible and continuous power supply and automatic switchover to geographically diverse backup facilities sufficient to prevent service disruption.

(ii) For central offices hosting selective routers, ALI/ANI, or functioning as the last central office serving a PSAP, covered 911 service providers satisfy this operational integrity benchmark by implementing backup power facilities for covered legacy 911 central office facilities for at least 24 hours at full office load if the central office directly serves a PSAP, or, for at least 72 hours at full office load if the central office hosts a selective router, including all equipment design, proper installation, necessary testing, and equipment maintenance to ensure the automatic and independent function of backup power facilities.

(3) Network monitoring. A covered 911 service provider shall certify whether it uses physically diverse monitoring to detect outages and disruptions in its covered facilities.

(i) Using geographically distributed automatic disruption detection and alarm systems to monitor IP covered facilities, including the IP routers, transport nodes, and node links used to make covered 911 circuits and paths physically diverse, constitutes physically diverse monitoring.

(ii) For non-IP covered facilities, maintaining and annually auditing physically diverse monitoring aggregation points, monitoring links, and NOCs constitutes physically diverse monitoring.

(d) Compliance date. For covered 911 service providers described at paragraphs (a)(4)(i)(E) through (I) of this section, compliance with the reliability requirement at paragraph (b) of this section will not be required until 18 months from the date of issuance of a Public Notice announcing a compliance date for those paragraphs. For all covered 911 service providers, compliance with the benchmarks at paragraphs (c)(1)(i), (c)(2)(i), and (c)(3)(i) of this section will not be required until 18 months from the date of issuance of a Public Notice announcing a compliance date for those paragraphs.

[84 FR 66760, Dec. 5, 2019, as amended at 88 FR 9765, Feb. 15, 2023; 91 FR 1403, Jan. 14, 2026; 91 FR 42841, July 10, 2026]

§ 9.20 911 Reliability certifications; interoperability reporting; cessation notifications.

(a) 911 reliability filings —

(1) Attestation.

(i) Within six months of a Public Notice announcing a compliance date for this paragraph (a)(1) and filing guidelines, any covered 911 service provider that has not previously filed a reliability certification shall submit to the Commission an attestation identifying itself as a covered 911 service provider. Attestations will not be deemed confidential.

(ii) Any new covered 911 service provider that begins service for the first time after the date in paragraph (a)(1)(i) of this section shall submit an attestation when it begins service.

(2) Certification —

(i) Initial certification. Within 18 months of a Public Notice announcing a compliance date for this paragraph (a)(2) and filing guidelines, a certifying official of each covered 911 service provider shall submit a certification to the Commission that addresses the elements of reliability listed in § 9.19(c)(1) through (3).

(ii) Updates covering material changes. A covered 911 service provider must exercise reasonable judgement in determining whether there is a material change to its ownership structure, networks, facilities, operations, or reliability practices that renders its previous certification no longer accurate and file an updated certification within 90 days of discovery of such a material change, unless:

(A) The cause of the change is remedied within the applicable update period;

(B) The change reflects incremental conformance with the reliability elements in § 9.19(c)(1) through (3), rather than reliance on alternative measures, for less than 50 percent of its covered 911 services, circuits, and paths; or

(C) The change to a covered 911 service provider's ownership structure is pro forma in nature.

(iii) Non-conforming facilities and services. If a covered 911 service provider does not conform with the elements of reliability listed in § 9.19(c)(1) through (3), it must include in its certification with respect to each of its non-conforming covered 911 circuits or paths and covered 911 services whether:

(A) The covered 911 service provider has taken alternative measures to mitigate the risks of lack of physical diversity, operational integrity, or network monitoring; or

(B) The physical diversity, operational integrity, or network monitoring benchmark is not applicable to the covered 911 service provider.

(iv) Covered 911 service providers are required to answer additional questions about covered 911 circuits and paths and covered 911 services as directed by the Public Safety and Homeland Security Bureau.

(b) 911 interoperability reports.

(1) Each NGCS and ESInet covered 911 service provider defined in § 9.19(a)(4)(i)(C) or (D) shall submit a one-time report to the Commission describing its specific actions and plans to enable NG911 interoperability consistent with § 9.19(a)(19) within 18 months of a Public Notice announcing a compliance date for this paragraph and filing guidelines.

(2) NGCS and ESInet covered 911 service providers defined in § 9.19(a)(4)(i)(C) or (D) are required to answer additional questions about covered 911 circuits and paths and covered 911 services as directed by the Public Safety and Homeland Security Bureau.

(c) Confidential treatment of certifications and reports.

(1) The fact of filing or not filing 911 reliability certifications and 911 interoperability reports shall not be treated as confidential.

(2) Information submitted with such certifications and reports shall be presumed confidential to the extent that it consists of non-public descriptions of networks or facilities, compliance plans, or additional information requested by the Bureau with respect to a certification.

(d) 911 Authority access to certifications and reports.

(1) Following the compliance date for initial certifications and reports, a statewide, territorial, or tribal 911 Authority may request that covered 911 service providers produce copies of their 911 reliability certifications and interoperability reports to the extent they pertain to covered 911 services or covered 911 circuits and paths located within or providing services to the 911 Authority's jurisdiction.

(2) Covered 911 service providers must provide the requested certifications or reports within 14 days of a request. Covered 911 service providers may omit or redact information relating to portions of their networks or facilities that are not located within and do not provide service to the requesting 911 Authority's jurisdiction. Covered 911 service providers may condition the granting of such requests on the 911 Authority's execution of a confidentiality agreement under terms not more restrictive than those set forth in § 4.2 of this chapter and in related guidance, instructions, and forms published by the Commission.

(3) To the extent the Public Safety and Homeland Security Bureau provides statewide, territorial, or tribal 911 Authorities with, or grants them access to, 911 reliability certifications and interoperability reports, it shall do so in accordance with relevant confidentiality terms and conditions pursuant to which it provides access to NORS data under § 4.2 of this chapter and related guidance, instructions, and forms published by the Commission.

(e) Record retention. A covered 911 service provider shall retain records supporting its responses in 911 reliability certifications and interoperability reports for two years from the date of filing, and shall make such records available to the Commission upon request. To the extent that a covered 911 service provider maintains records in electronic format, records supporting such a certification or report shall be maintained and supplied in an electronic format. Such records shall include, at a minimum, any audit records, internal reports concerning reliability and interoperability compliance, records of action to achieve reliability and interoperability compliance, and testing and maintenance of reliability and interoperability measures and technology.

(f) Covered service cessation notices. Covered 911 service providers that cease covered operations under § 9.19 must notify the Commission by filing a notification under penalty of perjury no later than 60 days after the cessation of service.

(g) Remedial action orders and procedures. When acting pursuant to authority delegated under § 0.392(j) of this chapter to order remedial actions, the Chief of the Public Safety and Homeland Security Bureau (Bureau Chief) will carry out restricted non-public proceedings with parties regulated under this subpart as follows:

(1) Notice. If certifications or other information available to the Commission indicate that a covered 911 service provider may not be taking reasonable measures to provide reliable 911 service, the Bureau Chief may issue and electronically serve upon the covered 911 service provider a notice that describes any apparent deficiencies and proposes remedial actions. The notice may include requests for relevant documents and information.

(2) Response. A covered 911 service provider may submit a written response to a notice within 30 days of service of such notice and shall provide any requested documents and information by such date. Service shall be made as directed by the Bureau.

(3) Order. At any time after the 30th day following service of a notice, the Bureau Chief may issue and serve upon the covered 911 service provider an order setting forth its findings as to such deficiencies and specifying the actions that the covered 911 service provider is required to take to mitigate the deficiencies. The order may specify deadlines by which the covered 911 service provider must complete the required actions and may identify information that the provider must submit to demonstrate its compliance with the order.

(4) Notice to 911 Authorities. The covered 911 service provider shall deliver a copy of the order promptly to the 911 Authority for each jurisdiction in which its actions have been found deficient or in which it has been directed to take remediating actions.

(h) Compliance date. This section may contain information collection and recordkeeping requirements that require review by the Office of Management and Budget. Compliance with new information collection and recordkeeping requirements will not be required until this paragraph (h) is removed or contains a compliance date.

[91 FR 42841, July 10, 2026]