Collapse to view only § 9.27 - Applicability, scope, and purpose.
- § 9.27 - Applicability, scope, and purpose.
- § 9.28 - Definitions.
- § 9.29 - Next Generation 911 transition requirements.
- § 9.30 - Next Generation 911 implementation deadlines.
- § 9.31 - Valid requests for delivery of 911 traffic in Internet Protocol-based formats.
- § 9.32 - Designation of NG911 Delivery Points.
- § 9.33 - Cost responsibilities.
- § 9.34 - Modification of NG911 requirements by mutual agreement.
§ 9.27 - Applicability, scope, and purpose.
(a) The purpose of this subpart is to set forth requirements and conditions in order to facilitate the transition to Next Generation 911 (NG911), and to assist with creating an NG911 architecture that is secure, interoperable, and based on commonly accepted standards.
(b) The rules in this subpart apply to “originating service providers” as defined in § 9.28.
(c) An originating service provider subject to the rules in this subpart shall be considered to have delivered 911 traffic to a public safety answering point (PSAP) if the originating service provider's 911 traffic is delivered to NG911 Delivery Points designated by the 911 Authority pursuant to § 9.32 and the other requirements in this subpart are satisfied.
§ 9.28 - Definitions.
For purposes of this subpart, the terms in this section have the following meanings:
911 Authority. A State, territorial, regional, Tribal, or local governmental entity that operates or has administrative authority over all or any aspect of a communications network for the receipt of 911 traffic at NG911 Delivery Points and for the transmission of such traffic from that point to PSAPs.
911 traffic. Transmissions consisting of all 911 calls (as defined in §§ 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 as information about calling parties' locations and originating telephone numbers and routing information transmitted with the calls and/or text messages.
Commonly accepted standards. The technical standards followed by the communications industry for network, device, and Internet Protocol connectivity that—
(1) Enable interoperability; and
(2) Are—
(i) Developed and approved by a standards development organization that is accredited by a United States standards body (such as the American National Standards Institute) or an equivalent international standards body in a process that—
(A) Is open to the public, including open for participation by any person; and
(B) Provides for a conflict resolution process;
(ii) Subject to an open comment and input process before being finalized by the standards development organization;
(iii) Consensus-based; and
(iv) Made publicly available once approved.
Covered text provider. The term “covered text provider” has the meaning given such term under § 9.10(q)(1).
Emergency Services Internet Protocol Network (ESInet). An Internet Protocol (IP)-based network that is managed or operated by a 911 Authority or its agents or vendors and that is used for emergency services communications, including Next Generation 911.
Functional element. A set of software features that may be combined with hardware interfaces and operations on those interfaces to accomplish a defined task.
Location Information Server (LIS). A functional element that provides locations of endpoints. A LIS can provide Location-by-Reference or Location-by-Value, and, if the latter, in geodetic or civic forms. A LIS can be queried by an endpoint for its own location, or by another entity for the location of an endpoint.
Location Validation Function (LVF). A functional element in NG911 Core Services (NGCS) consisting of a server where civic location information is validated against the authoritative Geographic Information System (GIS) database information. A civic address is considered valid if it can be located within the database uniquely, is suitable to provide an accurate route for an emergency call, and is adequate and specific enough to direct responders to the right location.
Nationwide CMRS provider. The term “nationwide CMRS provider” has the meaning given such term under § 9.10(i)(1)(iv).
Next Generation 911 (NG911). An Internet Protocol-based system that—
(1) Ensures interoperability;
(2) Is secure;
(3) Employs commonly accepted standards;
(4) Enables emergency communications centers to receive, process, and analyze all types of 911 requests for emergency assistance;
(5) Acquires and integrates additional information useful to handling 911 requests for emergency assistance; and
(6) Supports sharing information related to 911 requests for emergency assistance among emergency communications centers and emergency response providers.
NG911 Delivery Point. A geographic location, facility, or demarcation point designated by a 911 Authority where an originating service provider shall transmit and deliver 911 traffic in an IP format to ESInets or other NG911 network facilities.
Non-nationwide CMRS provider. The term “non-nationwide CMRS provider” has the meaning given such term under § 9.10(i)(1)(v).
Non-rural wireline provider. A wireline provider that is not a rural incumbent local exchange carrier (as defined in § 54.5 of this chapter).
Originating service providers. Providers that originate 911 traffic, specifically wireline providers; commercial mobile radio service (CMRS) providers, excluding mobile satellite service (MSS) operators to the same extent as set forth in § 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.
Rural incumbent local exchange carrier (RLEC). The term “rural incumbent local exchange carrier” or “RLEC” has the meaning given such term under § 54.5 of this chapter.
Session Initiation Protocol (SIP). A signaling protocol used for initiating, maintaining, modifying, and terminating communications sessions between Internet Protocol (IP) devices. SIP enables voice, messaging, video, and other communications services between two or more endpoints on IP networks.
Wireline provider. A local exchange carrier (as defined in 47 U.S.C. 153(32)) that provides service using wire communication (as defined in 47 U.S.C. 153(59)).
§ 9.29 - Next Generation 911 transition requirements.
(a) Phase 1. Upon receipt of a 911 Authority's valid request, an originating service provider that is subject to the rules in this subpart shall, by the relevant deadline specified in § 9.30(a)(1) or (b)(1)—
(1) Deliver all 911 traffic bound for the relevant PSAPs in the IP-based SIP format requested by the 911 Authority;
(2) Obtain and deliver 911 traffic to enable the ESInet and other NG911 network facilities to transmit all 911 traffic to the destination PSAP;
(3) Deliver all such 911 traffic to NG911 Delivery Points designated by the 911 Authority pursuant to § 9.32; and
(4) Complete connectivity testing to confirm that the 911 Authority receives 911 traffic in the IP-based SIP format requested by the 911 Authority.
(b) Phase 2. Upon receipt of a 911 Authority's valid request, an originating service provider that is subject to the rules in this subpart shall, by the relevant deadline specified in § 9.30(a)(2) or (b)(2)—
(1) Comply with all Phase 1 requirements set forth in paragraph (a) of this section;
(2) Deliver all 911 traffic bound for the relevant PSAPs to NG911 Delivery Points designated by the 911 Authority pursuant to § 9.32 in the IP-based SIP format that complies with NG911 commonly accepted standards identified by the 911 Authority, including having location information embedded in the call signaling using Presence Information Data Format—Location Object (PIDF-LO) or the functional equivalent;
(3) Install and put into operation all equipment, software applications, and other infrastructure, or acquire all services, necessary to use a Location Information Server (LIS) or its functional equivalent for the verification of its customer location information and records; and
(4) Complete connectivity testing to confirm that the 911 Authority receives 911 traffic in the IP-based SIP format that complies with the identified NG911 commonly accepted standards.
§ 9.30 - Next Generation 911 implementation deadlines.
(a) Non-rural wireline providers, nationwide CMRS providers, covered text providers, and interconnected VoIP providers shall—
(1) Comply with the Phase 1 requirements set forth in § 9.29(a) by six months after receiving a Phase 1 valid request from a 911 Authority, as set forth in § 9.31(a); and
(2) Comply with the Phase 2 requirements set forth in § 9.29(b) by:
(i) Six months after receiving a Phase 2 valid request from a 911 Authority, as set forth in § 9.31(b); or
(ii) If the 911 Authority's Phase 2 valid request is made before the originating service provider is compliant with the Phase 1 requirements or is made before the Phase 1 implementation deadline, six months after the earlier of:
(A) The date when the originating service provider is compliant with the Phase 1 requirements set forth in § 9.29(a); or
(B) The implementation deadline set forth in paragraph (a)(1) of this section.
(b) RLECs, non-nationwide CMRS providers, and internet-based TRS providers shall—
(1) Comply with the Phase 1 requirements set forth in § 9.29(a) by 12 months after receiving a Phase 1 valid request from a 911 Authority, as set forth in § 9.31(a); and
(2) Comply with the Phase 2 requirements set forth in § 9.29(b) by:
(i) 12 months after receiving a Phase 2 valid request from a 911 Authority, as set forth in § 9.31(b); or
(ii) If the 911 Authority's Phase 2 valid request is made before the originating service provider is compliant with the Phase 1 requirements or is made before the Phase 1 implementation deadline, 12 months after the earlier of:
(A) The date when the originating service provider is compliant with the Phase 1 requirements set forth in § 9.29(a); or
(B) The implementation deadline set forth in paragraph (b)(1) of this section.
§ 9.31 - Valid requests for delivery of 911 traffic in Internet Protocol-based formats.
(a) Phase 1 valid request. A 911 Authority's request for delivery of 911 traffic in the manner specified in § 9.29(a) is a Phase 1 valid request if the requesting 911 Authority—
(1) Certifies that it has installed and placed into operation all of the infrastructure needed to receive 911 traffic in an IP-based SIP format and transmit such traffic to the PSAP(s) connected to it;
(2) Certifies that it has obtained commitments from any ESInet provider, Next Generation 911 Core Services provider, and/or call handling equipment provider needed to facilitate and complete connectivity testing within the compliance timeframe applicable to the originating service provider;
(3) Certifies that it is authorized to submit a valid request for the NG911 network to receive 911 traffic in an IP-based SIP format;
(4) Identifies the NG911 Delivery Point(s) designated pursuant to § 9.32; and
(5) Provides notification to the originating service provider that includes the information and certifications set forth in paragraphs (a)(1) through (4) of this section. Notification by the 911 Authority via a registry made available by the Commission in accordance with requirements established in connection therewith, or any other written notification reasonably acceptable to the originating service provider, shall constitute sufficient notification for purposes of this paragraph.
(b) Phase 2 valid request. A 911 Authority's request for delivery of 911 traffic in the manner specified in § 9.29(b) is a Phase 2 valid request if the requesting 911 Authority—
(1) Certifies that it has installed and placed into operation all of the infrastructure needed to receive 911 traffic in an IP-based SIP format that complies with NG911 commonly accepted standards and transmit such traffic to the PSAP(s) connected to it;
(2) Certifies that its ESInet is connected to a fully functioning Next Generation 911 Core Services network that can provide access to a Location Validation Function and interface with a Location Information Server or its functional equivalent provided by the originating service provider;
(3) Certifies that it has obtained commitments from any ESInet provider, Next Generation 911 Core Services provider, and/or call handling equipment provider needed to facilitate and complete connectivity testing within the compliance timeframe applicable to the originating service provider;
(4) Certifies that it is authorized to submit a valid request for the NG911 network to receive 911 traffic in an IP-based SIP format that complies with NG911 commonly accepted standards;
(5) Identifies the NG911 Delivery Point(s) designated pursuant to § 9.32; and
(6) Provides notification to the originating service provider that includes the information and certifications set forth in paragraphs (b)(1) through (5) of this section. Notification by the 911 Authority via a registry made available by the Commission in accordance with requirements established in connection therewith, or any other written notification reasonably acceptable to the originating service provider, shall constitute sufficient notification for purposes of this paragraph.
(c) Originating service providers' petitions challenging 911 Authorities' requests. Within 60 days of the receipt of a Phase 1 or 2 request from a 911 Authority, an originating service provider may submit a petition to the Public Safety and Homeland Security Bureau asserting that the 911 Authority's request does not satisfy a condition set forth in paragraph (a) or (b) of this section for a Phase 1 or Phase 2 valid request. The Public Safety and Homeland Security Bureau may review the petition and determine whether to pause the implementation deadline for that originating service provider, affirm the request of the 911 Authority as valid, or take other action as necessary.
(1) The petition process shall be subject to the procedural requirements set forth in §§ 1.41, 1.45, and 1.47 of this chapter.
(2) The petition must be in the form of an affidavit signed by a director or officer of the originating service provider, documenting:
(i) The basis for the originating service provider's assertion that the 911 Authority's request does not satisfy one or more of the conditions set forth in paragraph (a) or (b) of this section for a Phase 1 or Phase 2 valid request.
(ii) Each of the specific steps the originating service provider has taken to implement the Phase 1 requirements set forth in § 9.29(a) or the Phase 2 requirements set forth in § 9.29(b).
(iii) The basis for the originating service provider's assertion that it cannot make further implementation efforts until the 911 Authority satisfies the conditions set forth in paragraph (a) or (b) of this section for a Phase 1 or Phase 2 valid request.
(iv) The specific steps that remain to be completed by the originating service provider and, to the extent known, the 911 Authority or other parties before the originating service provider can implement the Phase 1 requirements set forth in § 9.29(a) or the Phase 2 requirements set forth in § 9.29(b).
(3) All affidavits must be correct. The originating service provider's director or officer who signs the affidavit has the duty to personally determine that the affidavit is correct. If the affidavit is incorrect, he or she, as well as the originating service provider, may be subject to enforcement action.
(4) An originating service provider may not file an inadequate or incomplete petition. If an originating service provider's petition is inadequate and/or incomplete and the originating service provider has not met its obligations as set forth in § 9.29(a) or (b) at the time of the relevant deadline, the originating service provider may be considered noncompliant with the applicable rules as if the petition had not been filed.
(5) An originating service provider that challenges a 911 Authority's valid request must describe all steps taken toward implementing the Phase 1 requirements set forth in § 9.29(a) or the Phase 2 requirements set forth in § 9.29(b) that are not dependent on the readiness of the 911 Authority.
(6) The 911 Authority may file an opposition to the originating service provider's petition and the originating service provider may file a reply to the opposition in accordance with § 1.45 of this chapter. A copy of the document (petition, opposition, or reply) must be served on the other party (911 Authority or originating service provider) at the time of the filing in accordance with § 1.47 of this chapter.
(d) Paragraphs (a), (b), and (c) of this section may contain information collection and recordkeeping requirements that require review by the Office of Management and Budget. Compliance with those paragraphs will not be required until this paragraph (d) is removed or contains a compliance date.
§ 9.32 - Designation of NG911 Delivery Points.
A 911 Authority may designate one or more NG911 Delivery Points where originating service providers must deliver 911 traffic to the ESInet pursuant to § 9.29, provided that—
(a) Each NG911 Delivery Point is located in the same State or territory as the PSAPs connected to the ESInet; and
(b) The 911 Authority or the ESInet provides facilities at the input to the NG911 Delivery Point to receive 911 traffic in accordance with the applicable phase.
§ 9.33 - Cost responsibilities.
(a) Originating service providers are responsible for the costs of complying with the applicable Phase 1 and Phase 2 requirements assigned to them under § 9.29, including the costs of—
(1) Transmitting 911 traffic to NG911 Delivery Points;
(2) Delivering 911 traffic in the required IP-based SIP format at each phase, including the cost of IP conversion using a Legacy Network Gateway or the functional equivalent, if necessary; and
(3) Obtaining and delivering location and routing information using ALI/ANI databases, selective routers, or other means at Phase 1, and using LIS functionalities or other equivalent means at Phase 2.
(b) Originating service providers are not responsible for the costs of furnishing, maintaining, or upgrading NG911 Delivery Points, ESInets, Next Generation 911 Core Services networks, or PSAPs.
§ 9.34 - Modification of NG911 requirements by mutual agreement.
(a) Nothing in this subpart shall prevent 911 Authorities and originating service providers from establishing, by mutual consent, terms different from the requirements set forth in §§ 9.29 through 9.33.
(b) If a 911 Authority and an originating service provider enter into an agreement pursuant to paragraph (a) of this section, within 30 days of the date when any such agreement is executed, the originating service provider must notify the Commission of the agreement. The notification must identify with specificity each requirement in the rules that is impacted by the agreement and must state with specificity how the terms of the agreement differ from each impacted rule. The same notification is required if the 911 Authority and originating service provider amend, modify, or terminate the agreement.
(c) Paragraphs (a) and (b) of this section may contain information collection and recordkeeping requirements that require review by the Office of Management and Budget. Compliance with those paragraphs will not be required until this paragraph (c) is removed or contains a compliance date.