The purpose of this part is to set forth the 911, E911, and Next Generation 911 service requirements and conditions applicable to telecommunications carriers (subpart B); commercial mobile radio service (CMRS) providers (subpart C); interconnected Voice over internet Protocol (VoIP) providers (subpart D); internet-based providers of telecommunications relay services (TRS) for persons with disabilities (subpart E); multi-line telephone systems (MLTS) (subpart F); and Mobile-Satellite Service (MSS) providers (subpart G). The rules in this part also include requirements to help ensure the resiliency, redundancy, and reliability of 911 communications systems (subpart H), acceptable obligations and expenditures of 911 fees (subpart I), and Next Generation 911 obligations (subpart J).
資料由法律人 LawPlayer整理提供·U.S. federal law / curated by LawPlayer from GPO govinfo & eCFR
911 REQUIREMENTS
Terms with definitions including the “(RR)” designation are defined in the same way in § 2.1 of this chapter and in the Radio Regulations of the International Telecommunication Union.
911 calls. Any call initiated by an end user by dialing 911 for the purpose of accessing an emergency service provider. For wireless carriers, all 911 calls include those they are required to transmit pursuant to subpart C of this part.
Alternative location information. Location information (which may be coordinate-based) sufficient to identify the caller's civic address and approximate in-building location, including floor level, in large buildings.
Appropriate local emergency authority. An emergency answering point that has not been officially designated as a Public Safety Answering Point (PSAP), but has the capability of receiving 911 calls and either dispatching emergency services personnel or, if necessary, relaying the call to another emergency service provider. An appropriate local emergency authority may include, but is not limited to, an existing local law enforcement authority, such as the police, county sheriff, local emergency medical services provider, or fire department.
Automated dispatchable location. Automatic generation of dispatchable location.
Automatic Location Information (ALI). Information transmitted while providing E911 service that permits emergency service providers to identify the geographic location of the calling party.
Automatic Number Identification (ANI). For 911 systems, the Automatic Number Identification (ANI) identifies the calling party and may be used as the callback number.
Commercial mobile radio service (CMRS). A mobile service that is:
(1)(i) Provided for profit, i.e., with the intent of receiving compensation or monetary gain;
(ii) An interconnected service; and
(iii) Available to the public, or to such classes of eligible users as to be effectively available to a substantial portion of the public; or
(2) The functional equivalent of such a mobile service described in paragraph (1) of this definition.
(3) A variety of factors may be evaluated to make a determination whether the mobile service in question is the functional equivalent of a commercial mobile radio service, including: Consumer demand for the service to determine whether the service is closely substitutable for a commercial mobile radio service; whether changes in price for the service under examination, or for the comparable commercial mobile radio service, would prompt customers to change from one service to the other; and market research information identifying the targeted market for the service under review.
(4) Unlicensed radio frequency devices under part 15 of this chapter are excluded from this definition of Commercial mobile radio service.
Common carrier or carrier. Any common carrier engaged in interstate Communication by wire or radio as defined in section 3(h) of the Communications Act of 1934, as amended (the Act), and any common carrier engaged in intrastate communication by wire or radio, notwithstanding sections 2(b) and 221(b) of the Act.
Communications assistant (CA). A person who transliterates or interprets conversation between two or more end users of TRS.
Configured. The settings or configurations for a particular MLTS installation have been implemented so that the MLTS is fully capable when installed of dialing 911 directly and providing MLTS notification as required under the statute and rules. This does not preclude the inclusion of additional dialing patterns to reach 911. However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern.
Designated PSAP. The Public Safety Answering Point (PSAP) designated by the local or state entity that has the authority and responsibility to designate the PSAP to receive wireless 911 calls.
Device-based location information. Information regarding the location of a device used to call or text 911 generated all or in part from on-device sensors and data sources.
Dispatchable location. A location delivered to the PSAP with a 911 call that consists of the validated street address of the calling party, plus additional information such as suite, apartment or similar information necessary to adequately identify the location of the calling party, except for Commercial Mobile Radio Service providers, which shall convey the location information required by subpart C of this part.
Earth station. A station located either on the Earth's surface or within the major portion of the Earth's atmosphere intended for communication:
(1) With one or more space stations; or
(2) With one or more stations of the same kind by means of one or more reflecting satellites or other objects in space. (RR)
Emergency Call Center. A facility that subscribers of satellite commercial mobile radio services call when in need of emergency assistance by dialing “911” on their mobile earth station terminals.
Feeder link. A radio link from a fixed earth station at a given location to a space station, or vice versa, conveying information for a space radiocommunication service other than the Fixed-Satellite Service. The given location may be at a specified fixed point or at any fixed point within specified areas. (RR)
Fixed-Satellite Service (FSS). A radiocommunication service between earth stations at given positions, when one or more satellites are used; the given position may be a specified fixed point or any fixed point within specified areas; in some cases this service includes satellite-to-satellite links, which may also be operated in the inter-satellite service; the Fixed-Satellite Service may also include feeder links of other space radiocommunication services. (RR)
Handset-based location technology. A method of providing the location of wireless 911 callers that requires the use of special location-determining hardware and/or software in a portable or mobile phone. Handset-based location technology may also employ additional location-determining hardware and/or software in the CMRS network and/or another fixed infrastructure.
iTRS access technology. Any equipment, software, or other technology issued, leased, or provided by an internet-based TRS provider that can be used to make and receive an internet-based TRS call.
Improvement to the hardware or software of the system. An improvement to the hardware or software of the MLTS, including upgrades to the core systems of the MLTS, as well as substantial upgrades to the software and any software upgrades requiring a significant purchase.
Interconnected VoIP service. (1) An interconnected Voice over Internet Protocol (VoIP) service is a service that:
(i) Enables real-time, two-way voice communications;
(ii) Requires a broadband connection from the user's location;
(iii) Requires internet protocol-compatible customer premises equipment (CPE); and
(iv) Permits users generally to receive calls that originate on the public switched telephone network and to terminate calls to the public switched telephone network.
(2) Notwithstanding the foregoing, solely for purposes of compliance with the Commission's 911 obligations, an interconnected VoIP service includes a service that fulfills each of paragraphs (1)(i) through (iii) of this definition and permits users generally to terminate calls to the public switched telephone network.
Internet-based TRS (iTRS). A telecommunications relay service (TRS) in which an individual with a hearing or a speech disability connects to a TRS communications assistant using an Internet Protocol-enabled device via the internet, rather than the public switched telephone network. Except as authorized or required by the Commission, internet-based TRS does not include the use of a text telephone (TTY) or RTT over an interconnected voice over Internet Protocol service.
Internet Protocol Captioned Telephone Service (IP CTS). A telecommunications relay service that permits an individual who can speak but who has difficulty hearing over the telephone to use a telephone and an Internet Protocol-enabled device via the internet to simultaneously listen to the other party and read captions of what the other party is saying. With IP CTS, the connection carrying the captions between the relay service provider and the relay service user is via the internet, rather than the public switched telephone network.
Internet Protocol Relay Service (IP Relay). A telecommunications relay service 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.
Location-capable handsets. Portable or mobile phones that contain special location-determining hardware and/or software, which is used by a licensee to locate 911 calls.
Location-based routing. The use of information regarding the location of a device, including but not limited to device-based location information, to deliver 911 calls and real-time text communications to point(s) designated by the authorized local or state entity to receive wireless 911 voice calls and real-time text communications to 911, such as an Emergency Services internet Protocol Network (ESInet) or PSAP, or to an appropriate local emergency authority.
MLTS notification. An MLTS feature that can send notice to a central location at the facility where the system is installed or to another person or organization regardless of location. Examples of notification include conspicuous on-screen messages with audible alarms for security desk computers using a client application, text messages for smartphones, and email for administrators. Notification shall include, at a minimum, the following information:
(1) The fact that a 911 call has been made;
(2) A valid callback number; and
(3) The information about the caller's location that the MLTS conveys to the public safety answering point (PSAP) with the call to 911; provided, however, that the notification does not have to include a callback number or location information if it is technically infeasible to provide this information.
Mobile Earth Station. An earth station in the Mobile-Satellite Service intended to be used while in motion or during halts at unspecified points. (RR)
Mobile-Satellite Service (MSS). (1) A radiocommunication service:
(i) Between mobile earth stations and one or more space stations, or between space stations used by this service; or
(ii) Between mobile earth stations, by means of one or more space stations.
(2) This service may also include feeder links necessary for its operation. (RR)
Mobile service. A radio communication service carried on between mobile stations or receivers and land stations, and by mobile stations communicating among themselves, and includes:
(1) Both one-way and two-way radio communications services;
(2) A mobile service which provides a regularly interacting group of base, mobile, portable, and associated control and relay stations (whether licensed on an individual, cooperative, or multiple basis) for private one-way or two-way land mobile radio communications by eligible users over designated areas of operation; and
(3) Any service for which a license is required in a personal communications service under part 24 of this chapter.
Network-based location technology. A method of providing the location of wireless 911 callers that employs hardware and/or software in the CMRS network and/or another fixed infrastructure, and does not require the use of special location-determining hardware and/or software in the caller's portable or mobile phone.
Multi-line telephone system or MLTS. A system comprised of common control units, telephone sets, control hardware and software and adjunct systems, including network and premises based systems, such as Centrex and VoIP, as well as PBX, Hybrid, and Key Telephone Systems (as classified by the Commission under part 68 of title 47, Code of Federal Regulations), and includes systems owned or leased by governmental agencies and non-profit entities, as well as for profit businesses.
Non-English language relay service. A telecommunications relay service that allows persons with hearing or speech disabilities who use languages other than English to communicate with voice telephone users in a shared language other than English, through a CA who is fluent in that language.
On-premises. In the context of a multi-line telephone system, within the fixed property ( e.g. building(s), facilities, or campus) and under the operational control of a single administrative authority.
Person engaged in the business of installing an MLTS. A person that configures the MLTS or performs other tasks involved in getting the system ready to operate. These tasks may include, but are not limited to, establishing the dialing pattern for emergency calls, determining how calls will route to the Public Switched Telephone Network (PSTN), and determining where the MLTS will interface with the PSTN. These tasks are performed when the system is initially installed, but they may also be performed on a more or less regular basis by the MLTS operator as the communications needs of the enterprise change. The MLTS installer may be the MLTS manager or a third party acting on behalf of the manager.
Person engaged in the business of managing an MLTS. The entity that is responsible for controlling and overseeing implementation of the MLTS after installation. These responsibilities include determining how lines should be distributed (including the adding or moving of lines), assigning and reassigning telephone numbers, and ongoing network configuration.
Person engaged in the business of manufacturing, importing, selling, or leasing an MLTS. A person that manufactures, imports, sells, or leases an MLTS.
Person engaged in the business of operating an MLTS. A person responsible for the day-to-day operations of the MLTS.
Pre-configured. An MLTS that comes equipped with hardware and/or software capable of establishing a setting that enables users to directly dial 911 as soon as the system is able to initiate calls to the public switched telephone network, so long as the MLTS is installed and operated properly. This does not preclude the inclusion of additional dialing patterns to reach 911. However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern.
Private mobile radio service. A mobile service that meets neither the paragraph (1) nor paragraph (2) in the definition of commercial mobile radio service in this section. A mobile service that does not meet paragraph (1) in the definition of commercial mobile radio service in this section is presumed to be a private mobile radio service. Private mobile radio service includes the following:
(1) Not-for-profit land mobile radio and paging services that serve the licensee's internal communications needs as defined in part 90 of this chapter. Shared-use, cost-sharing, or cooperative arrangements, multiple licensed systems that use third party managers or users combining resources to meet compatible needs for specialized internal communications facilities in compliance with the safeguards of § 90.179 of this chapter are presumptively private mobile radio services;
(2) Mobile radio service offered to restricted classes of eligible users. This includes entities eligible in the Public Safety Radio Pool and Radiolocation service.
(3) 220-222 MHz land mobile service and Automatic Vehicle Monitoring systems (part 90 of this chapter) that do not offer interconnected service or that are not-for-profit; and
(4) Personal Radio Services under part 95 of this chapter (General Mobile Services, Radio Control Radio Services, and Citizens Band Radio Services); Maritime Service Stations (excluding Public Coast stations) (part 80 of this chapter); and Aviation Service Stations (part 87 of this chapter).
Pseudo Automatic Number Identification (Pseudo-ANI). A number, consisting of the same number of digits as ANI, that is not a North American Numbering Plan telephone directory number and may be used in place of an ANI to convey special meaning. The special meaning assigned to the pseudo-ANI is determined by agreements, as necessary, between the system originating the call, intermediate systems handling and routing the call, and the destination system.
Public safety answering point or PSAP. An answering point that has been designated to receive 911 calls and route them to emergency services personnel.
Public Switched Network. Any common carrier switched network, whether by wire or radio, including local exchange carriers, interexchange carriers, and mobile service providers, that uses the North American Numbering Plan in connection with the provision of switched services.
Real-Time Text (RTT). Text communications that are transmitted over Internet Protocol (IP) networks immediately as they are created, e.g., on a character-by-character basis.
Registered internet-based TRS user. An individual that has registered with a VRS, IP Relay, or IP CTS provider as described in § 64.611.
Registered Location. The most recent information obtained by a provider of interconnected VoIP service or telecommunications relay services (TRS), as applicable, that identifies the physical location of an end user.
Space station. A station located on an object which is beyond, is intended to go beyond, or has been beyond, the major portion of the Earth's atmosphere. (RR)
Speech-to-speech relay service (STS). A telecommunications relay service that allows individuals with speech disabilities to communicate with voice telephone users through the use of specially trained CAs who understand the speech patterns of persons with speech disabilities and can repeat the words spoken by that person.
Statewide default answering point. An emergency answering point designated by the State to receive 911 calls for either the entire State or those portions of the State not otherwise served by a local PSAP.
Station. A station equipped to engage in radio communication or radio transmission of energy (47 U.S.C. 153(k)).
Telecommunications relay services (TRS). Telephone transmission services that provide the ability for an individual who has a hearing or speech disability to engage in communication by wire or radio with a hearing individual in a manner that is functionally equivalent to the ability of an individual who does not have a hearing or speech disability to communicate using voice communication services by wire or radio. Such term includes services that enable two-way communication between an individual who uses a text telephone or other nonvoice terminal device and an individual who does not use such a device, speech-to-speech services, video relay services and non-English relay services. TRS supersedes the terms “dual party relay system,” “message relay services,” and “TDD Relay.”
Text telephone (TTY). A machine that employs graphic communication in the transmission of coded signals through a wire or radio communication system. TTY supersedes the term “TDD” or “telecommunications device for the deaf,” and TT.
Video relay service (VRS). A telecommunications relay service that allows people with hearing or speech disabilities who use sign language to communicate with voice telephone users through video equipment. The video link allows the CA to view and interpret the party's signed conversation and relay the conversation back and forth with a voice caller.
Wireline E911 Network. A dedicated wireline network that:
(1) Is interconnected with but largely separate from the public switched telephone network;
(2) Includes a selective router; and
(3) Is used to route emergency calls and related information to PSAPs, designated statewide default answering points, appropriate local emergency authorities or other emergency answering points.
All telecommunications carriers shall transmit all 911 calls to a PSAP, to a designated statewide default answering point, or to an appropriate local emergency authority as set forth in § 9.5.
As of December 11, 2001, except where 911 is already established as the exclusive emergency number to reach a PSAP within a given jurisdiction, telecommunications carriers shall comply with the following transition periods:
(a) Where a PSAP has been designated, telecommunications carriers shall complete all translation and routing necessary to deliver 911 calls to a PSAP no later than September 11, 2002.
(b) Where no PSAP has been designated, telecommunications carriers shall complete all translation and routing necessary to deliver 911 calls to the statewide default answering point no later than September 11, 2002.
(c) Where neither a PSAP nor a statewide default answering point has been designated, telecommunications carriers shall complete the translation and routing necessary to deliver 911 calls to an appropriate local emergency authority, within nine months of a request by the State or locality.
(d) Where no PSAP nor statewide default answering point has been designated, and no appropriate local emergency authority has been selected by an authorized state or local entity, telecommunications carriers shall identify an appropriate local emergency authority, based on the exercise of reasonable judgment, and complete all translation and routing necessary to deliver 911 calls to such appropriate local emergency authority no later than September 11, 2002.
(e) Once a PSAP is designated for an area where none had existed as of December 11, 2001, telecommunications carriers shall complete the translation and routing necessary to deliver 911 calls to that PSAP within nine months of that designation.
Upon completion of translation and routing of 911 calls to a PSAP, a statewide default answering point, to an appropriate local emergency authority, or, where no PSAP nor statewide default answering point has been designated and no appropriate local emergency authority has been selected by an authorized state or local entity, to an appropriate local emergency authority, identified by a telecommunications carrier based on the exercise of reasonable judgment, the telecommunications carrier shall provide permissive dialing between 911 and any other seven-or ten-digit emergency number or an abbreviated dialing code other than 911 that the public has previously used to reach emergency service providers until the appropriate State or local jurisdiction determines to phase out the use of such seven-or ten-digit number entirely and use 911 exclusively.
Upon termination of permissive dialing, as provided under § 9.6, telecommunications carriers shall provide a standard intercept message announcement that interrupts calls placed to the emergency service provider using either a seven-or ten-digit emergency number or an abbreviated dialing code other than 911 and informs the caller of the dialing code change.
(a) Providers of fixed telephony services shall provide automated dispatchable location with 911 calls beginning January 6, 2021.
(b) [Reserved]
Interconnection or Interconnected. Direct or indirect connection through automatic or manual means (by wire, microwave, or other technologies such as store and forward) to permit the transmission or reception of messages or signals to or from points in the public switched network.
Interconnected service. (1) A service:
(i) That is interconnected with the public switched network, or interconnected with the public switched network through an interconnected service provider, that gives subscribers the capability to communicate to or receive communication from all other users on the public switched network; or
(ii) For which a request for such interconnection is pending pursuant to section 332(c)(1)(B) of the Communications Act, 47 U.S.C. 332(c)(1)(B).
(2) A mobile service offers interconnected service even if the service allows subscribers to access the public switched network only during specified hours of the day, or if the service provides general access to points on the public switched network but also restricts access in certain limited ways. Interconnected service does not include any interface between a licensee's facilities and the public switched network exclusively for a licensee's internal control purposes.
(a) Scope of section. Except as described in paragraph (r) of this section, the following requirements of paragraphs (a) through (t) of this section are only applicable to CMRS providers, excluding mobile satellite service (MSS) operators, to the extent that they:
(1) Offer real-time, two way switched voice service that is interconnected with the public switched network; and
(2) Use an in-network switching facility that enables the provider to reuse frequencies and accomplish seamless hand-offs of subscriber calls. These requirements are applicable to entities that offer voice service to consumers by purchasing airtime or capacity at wholesale rates from CMRS licensees.
(b) Basic 911 service. CMRS providers subject to this section must transmit all wireless 911 calls without respect to their call validation process to a Public Safety Answering Point, or, where no Public Safety Answering Point has been designated, to a designated statewide default answering point or appropriate local emergency authority pursuant to § 9.4, provided that “all wireless 911 calls” is defined as “any call initiated by a wireless user dialing 911 on a phone using a compliant radio frequency protocol of the serving carrier.”
(c) Access to 911 services. CMRS providers subject to this section must be capable of transmitting 911 calls from individuals with speech or hearing disabilities through means other than mobile radio handsets, e.g., through the use of Text Telephone Devices (TTY). CMRS providers that provide voice communications over IP facilities are not required to support 911 access via TTYs if they provide 911 access via real-time text (RTT) communications, in accordance with 47 CFR part 67, except that RTT support is not required to the extent that it is not achievable for a particular manufacturer to support RTT on the provider's network.
(d) Phase I enhanced 911 services. (1) As of April 1, 1998, or within six months of a request by the designated Public Safety Answering Point as set forth in paragraph (j) of this section, whichever is later, licensees subject to this section must provide the telephone number of the originator of a 911 call and the location of the cell site or base station receiving a 911 call from any mobile handset accessing their systems to the designated Public Safety Answering Point through the use of ANI and Pseudo-ANI.
(2) When the directory number of the handset used to originate a 911 call is not available to the serving carrier, such carrier's obligations under the paragraph (d)(1) of this section extend only to delivering 911 calls and available call party information, including that prescribed in paragraph (l) of this section, to the designated Public Safety Answering Point.
Note to paragraph (d): With respect to 911 calls accessing their systems through the use of TTYs, licensees subject to this section must comply with the requirements in paragraphs (d)(1) and (2) of this section, as to calls made using a digital wireless system, as of October 1, 1998.
(e) Phase II enhanced 911 service. Licensees subject to this section must provide to the designated Public Safety Answering Point Phase II enhanced 911 service, i.e., the location of all 911 calls by longitude and latitude in conformance with Phase II accuracy requirements ( see paragraph (h) of this section).
(f) Phase-in for network-based location technologies. Licensees subject to this section who employ a network-based location technology shall provide Phase II 911 enhanced service to at least 50 percent of their coverage area or 50 percent of their population beginning October 1, 2001, or within 6 months of a PSAP request, whichever is later; and to 100 percent of their coverage area or 100 percent of their population within 18 months of such a request or by October 1, 2002, whichever is later.
(g) Phase-in for handset-based location technologies. Licensees subject to this section who employ a handset-based location technology may phase in deployment of Phase II enhanced 911 service, subject to the following requirements:
(1) Without respect to any PSAP request for deployment of Phase II 911 enhanced service, the licensee shall:
(i) Begin selling and activating location-capable handsets no later than October 1, 2001;
(ii) Ensure that at least 25 percent of all new handsets activated are location-capable no later than December 31, 2001;
(iii) Ensure that at least 50 percent of all new handsets activated are location-capable no later than June 30, 2002; and
(iv) Ensure that 100 percent of all new digital handsets activated are location-capable no later than December 31, 2002, and thereafter.
(v) By December 31, 2005, achieve 95 percent penetration of location-capable handsets among its subscribers.
(vi) Licensees that meet the enhanced 911 compliance obligations through GPS-enabled handsets and have commercial agreements with resellers will not be required to include the resellers' handset counts in their compliance percentages.
(2) Once a PSAP request is received, the licensee shall, in the area served by the PSAP, within six months or by October 1, 2001, whichever is later:
(i) Install any hardware and/or software in the CMRS network and/or other fixed infrastructure, as needed, to enable the provision of Phase II enhanced 911 service; and
(ii) Begin delivering Phase II enhanced 911 service to the PSAP.
(3) For all 911 calls from portable or mobile phones that do not contain the hardware and/or software needed to enable the licensee to provide Phase II enhanced 911 service, the licensee shall, after a PSAP request is received, support, in the area served by the PSAP, Phase I location for 911 calls or other available best practice method of providing the location of the portable or mobile phone to the PSAP.
(4) Licensees employing handset-based location technologies shall ensure that location-capable portable or mobile phones shall conform to industry interoperability standards designed to enable the location of such phones by multiple licensees.
(h) Phase II accuracy. Licensees subject to this section shall comply with the following standards for Phase II location accuracy and reliability, to be tested and measured either at the county or at the PSAP service area geographic level, based on outdoor measurements only:
(1) Network-based technologies:
(i) 100 meters for 67 percent of calls, consistent with the following benchmarks:
(A) One year from January 18, 2011, carriers shall comply with this standard in 60 percent of counties or PSAP service areas. These counties or PSAP service areas must cover at least 70 percent of the population covered by the carrier across its entire network. Compliance will be measured on a per-county or per-PSAP basis using, at the carrier's election, either:
( 1 ) Network-based accuracy data; or
( 2 ) Blended reporting as provided in paragraph (h)(1)(iv) of this section.
(B) Three years from January 18, 2011, carriers shall comply with this standard in 70 percent of counties or PSAP service areas. These counties or PSAP service areas must cover at least 80 percent of the population covered by the carrier across its entire network. Compliance will be measured on a per-county or per-PSAP basis using, at the carrier's election, either:
( 1 ) Network-based accuracy data; or
( 2 ) Blended reporting as provided in paragraph (h)(1)(iv) of this section.
(C) Five years from January 18, 2011, carriers shall comply with this standard in 100% of counties or PSAP service areas covered by the carrier. Compliance will be measured on a per-county or per-PSAP basis, using, at the carrier's election, either:
( 1 ) Network-based accuracy data;
( 2 ) Blended reporting as provided in paragraph (h)(1)(iv) of this section; or
( 3 ) Handset-based accuracy data as provided in paragraph (h)(1)(v) of this section.
(ii) 300 meters for 90 percent of calls, consistent with the following benchmarks:
(A) Three years from January 18, 2011, carriers shall comply with this standard in 60 percent of counties or PSAP service areas. These counties or PSAP service areas must cover at least 70 percent of the population covered by the carrier across its entire network. Compliance will be measured on a per-county or per-PSAP basis using, at the carrier's election, either:
( 1 ) Network-based accuracy data; or
( 2 ) Blended reporting as provided in paragraph (h)(1)(iv) of this section.
(B) Five years from January 18, 2011, carriers shall comply in 70 percent of counties or PSAP service areas. These counties or PSAP service areas must cover at least 80 percent of the population covered by the carrier across its entire network. Compliance will be measured on a per-county or per-PSAP basis using, at the carrier's election, either:
( 1 ) Network-based accuracy data; or
( 2 ) Blended reporting as provided in paragraph (h)(1)(iv) of this section.
(C) Eight years from January 18, 2011, carriers shall comply in 85 percent of counties or PSAP service areas. Compliance will be measured on a per-county or per-PSAP basis using, at the carrier's election, either:
( 1 ) Network-based accuracy data;
( 2 ) Blended reporting as provided in paragraph (h)(1)(iv) of this section; or
( 3 ) Handset-based accuracy data as provided in paragraph (h)(1)(v) of this section.
(iii) County-level or PSAP-level location accuracy standards for network-based technologies will be applicable to those counties or PSAP service areas, on an individual basis, in which a network-based carrier has deployed Phase II in at least one cell site located within a county's or PSAP service area's boundary. Compliance with the requirements of paragraphs (h)(1)(i) and (ii) of this section shall be measured and reported independently.
(iv) Accuracy data from both network-based solutions and handset-based solutions may be blended to measure compliance with the accuracy requirements of paragraphs (h)(1)(i)(A) through (C) and paragraphs (h)(1)(ii)(A) through (C) of this section. Such blending shall be based on weighting accuracy data in the ratio of assisted GPS (“A-GPS”) handsets to non-A-GPS handsets in the carrier's subscriber base. The weighting ratio shall be applied to the accuracy data from each solution and measured against the network-based accuracy requirements of paragraph (h)(1) of this section.
(v) A carrier may rely solely on handset-based accuracy data in any county or PSAP service area if at least 85 percent of its subscribers, network-wide, use A-GPS handsets, or if it offers A-GPS handsets to subscribers in that county or PSAP service area at no cost to the subscriber.
(vi) A carrier may exclude from compliance particular counties, or portions of counties, where triangulation is not technically possible, such as locations where at least three cell sites are not sufficiently visible to a handset. Carriers must file a list of the specific counties or portions of counties where they are using this exclusion within 90 days following approval from the Office of Management and Budget for the related information collection. This list must be submitted electronically into PS Docket No. 07-114, and copies must be sent to the National Emergency Number Association, the Association of Public-Safety Communications Officials-International, and the National Association of State 9-1-1 Administrators. Further, carriers must submit in the same manner any changes to their exclusion lists within thirty days of discovering such changes. This exclusion has sunset as of January 18, 2019.
(2) Handset-based technologies:
(i) Two years from January 18, 2011, 50 meters for 67 percent of calls, and 150 meters for 80 percent of calls, on a per-county or per-PSAP basis. However, a carrier may exclude up to 15 percent of counties or PSAP service areas from the 150-meter requirement based upon heavy forestation that limits handset-based technology accuracy in those counties or PSAP service areas.
(ii) Eight years from January 18, 2011, 50 meters for 67 percent of calls, and 150 meters for 90 percent of calls, on a per-county or per-PSAP basis. However, a carrier may exclude up to 15 percent of counties or PSAP service areas from the 150-meter requirement based upon heavy forestation that limits handset-based technology accuracy in those counties or PSAP service areas.
(iii) Carriers must file a list of the specific counties or PSAP service areas where they are using the exclusion for heavy forestation within 90 days following (approval from the Office of Management and Budget for the related information collection). This list must be submitted electronically into PS Docket No. 07-114, and copies must be sent to the National Emergency Number Association, the Association of Public-Safety Communications Officials-International, and the National Association of State 9-1-1 Administrators. Further, carriers must submit in the same manner any changes to their exclusion lists within thirty days of discovering such changes.
(iv) Providers of new CMRS networks that meet the definition of covered CMRS providers under paragraph (a) of this section must comply with the requirements of paragraphs (h)(2)(i) through (iii) of this section. For this purpose, a “new CMRS network” is a CMRS network that is newly deployed subsequent to the effective date of the Third Report and Order in PS Docket No. 07-114 and that is not an expansion or upgrade of an existing CMRS network.
(3) Latency (Time to First Fix): For purposes of measuring compliance with the location accuracy standards of this paragraph, a call will be deemed to satisfy the standard only if it provides the specified degree of location accuracy within a maximum latency period of 30 seconds, as measured from the time the user initiates the 911 call to the time the location fix appears at the location information center: Provided, however, that the CMRS provider may elect not to include for purposes of measuring compliance therewith any calls lasting less than 30 seconds.
(i) Indoor location accuracy for 911 and testing requirements —(1) Definitions. The terms as used in this section have the following meaning:
(i) Dispatchable location. A location delivered to the PSAP by the CMRS provider with a 911 call that consists of the street address of the calling party, plus additional information such as suite, apartment or similar information necessary to adequately identify the location of the calling party. The street address of the calling party must be validated and, to the extent possible, corroborated against other location information prior to delivery of dispatchable location information by the CMRS provider to the PSAP.
(ii) Media Access Control (MAC) Address. A location identifier of a Wi-Fi access point.
(iii) National Emergency Address Database (NEAD). A database that uses MAC address information to identify a dispatchable location for nearby wireless devices within the CMRS provider's coverage footprint.
(iv) Nationwide CMRS provider. A CMRS provider whose service extends to a majority of the population and land area of the United States.
(v) Non-nationwide CMRS provider. Any CMRS provider other than a nationwide CMRS provider.
(vi) Test cities. The six cities (San Francisco, Chicago, Atlanta, Denver/Front Range, Philadelphia, and Manhattan Borough) and surrounding geographic areas that correspond to the six geographic regions specified by the February 7, 2014 ATIS Document, “Considerations in Selecting Indoor Test Regions,” for testing of indoor location technologies.
(2) Indoor location accuracy standards. CMRS providers subject to this section shall meet the following requirements:
(i) Horizontal location. (A) Nationwide CMRS providers shall provide; dispatchable location, or; x/y location within 50 meters, for the following percentages of wireless 911 calls within the following timeframes, measured from the effective date of the adoption of this rule:
( 1 ) Within 2 years: 40 percent of all wireless 911 calls.
( 2 ) Within 3 years: 50 percent of all wireless 911 calls.
( 3 ) Within 5 years: 70 percent of all wireless 911 calls.
( 4 ) Within 6 years: 80 percent of all wireless 911 calls.
(B) Non-nationwide CMRS providers shall provide; dispatchable location or; x/y location within 50 meters, for the following percentages of wireless 911 calls within the following timeframes, measured from the effective date of the adoption of this rule:
( 1 ) Within 2 years: 40 percent of all wireless 911 calls.
( 2 ) Within 3 years: 50 percent of all wireless 911 calls.
( 3 ) Within 5 years or within six months of deploying a commercially-operating VoLTE platform in their network, whichever is later: 70 percent of all wireless 911 calls.
( 4 ) Within 6 years or within one year of deploying a commercially-operating VoLTE platform in their network, whichever is later: 80 percent of all wireless 911 calls.
(ii) Vertical location. CMRS providers shall provide vertical location information with wireless 911 calls as described in this section within the following timeframes measured from the effective date of the adoption of this rule:
(A) Within 3 years: All CMRS providers shall make uncompensated barometric data available to PSAPs with respect to any 911 call placed from any handset that has the capability to deliver barometric sensor information.
(B) Within 3 years: Nationwide CMRS providers shall develop one or more z-axis accuracy metrics validated by an independently administered and transparent test bed process as described in paragraph (i)(3)(i) of this section, and shall submit the proposed metric or metrics, supported by a report of the results of such development and testing, to the Commission for approval.
(C) By April 3, 2021: In each of the top 25 cellular market areas (CMAs), nationwide CMRS providers shall deploy either dispatchable location or z-axis technology.
(D) By April 3, 2023: In each of the top 50 CMAs, nationwide CMRS providers shall deploy either dispatchable location or z-axis technology.
(E) By April 3, 2025: Nationwide CMRS providers shall deploy on a nationwide basis either dispatchable location or z-axis technology.
(F) Non-nationwide CMRS providers that serve any of the top 25 or 50 CMAs will have an additional year to meet each of the benchmarks in paragraphs (i)(2)(ii)(C) and (D) of this section. All non-nationwide providers will have an additional year to meet the benchmark in paragraph (i)(2)(ii)(E) of this section by deploying either dispatchable location or z-axis technology throughout their network footprint.
(G) By January 6, 2022: All CMRS providers shall provide dispatchable location with wireless E911 calls if it is technically feasible for them to do so.
(H) CMRS providers that deploy z-axis technology must do so consistent with the following z-axis accuracy metric: Within 3 meters above or below (plus or minus 3 meters) the handset for 80% of wireless E911 calls made from the z-axis capable device. CMRS providers must deliver z-axis information in Height Above Ellipsoid. Where available to the CMRS provider, floor level information must be provided in addition to z-axis location information.
(I) CMRS providers that deploy z-axis technology must do so according to the following options:
( 1 ) In each area where z-axis technology is used, deploy the technology to cover 80 percent of the population or 80 percent of the buildings that exceed three stories; or
( 2 ) Deploy z-axis capable handsets enabled with z-axis technology on a nationwide basis (or throughout the CMRS provider's network footprint, as applicable).
(J) CMRS providers that deploy z-axis technology must comply with the following:
( 1 ) CMRS providers must activate all network infrastructure necessary to support z-axis location by z-axis capable devices throughout the deployment area.
( 2 ) CMRS providers may deploy z-axis technology upgrades by means of over-the-top applications as well as operating system or firmware upgrades. CMRS providers deploying z-axis technology must affirmatively push the z-axis technology to all existing z-axis capable device models on the provider's network that can receive it, and CMRS providers must continue to support the z-axis technology on these devices thereafter.
( 3 ) A CMRS provider using the handset-based deployment option must make the technology available to existing z-axis capable devices nationwide; a CMRS provider using a CMA-based deployment option must make the technology available to all z-axis capable devices in the CMA. For all new z-axis capable devices marketed to consumers, the z-axis technology must be pre-installed.
( 4 ) A CMRS provider will be deemed to have met its z-axis technology deployment obligation so long as it either pre-installs or affirmatively pushes the location technology to end users so that they receive a prompt or other notice informing them that the application or service is available and what they need to do to download and enable the technology on their phone. A CMRS provider will be deemed in compliance with its z-axis deployment obligation if it makes the technology available to the end user in this manner even if the end user declines to use the technology or subsequently disables it.
(K) CMRS providers must validate dispatchable location technologies intended for indoor location in accordance with the provisions of paragraph (i)(3)(i) of this section.
(L) In each CMA where dispatchable location is used, nationwide CMRS providers must ensure that dispatchable location is supported by a sufficient number of total dispatchable location reference points to equal 25 percent of the CMA population.
(M) A z-axis capable device is one that can measure and report vertical location without a hardware upgrade. For z-axis location solutions that rely on barometric pressure sensor information, only devices that have such sensors installed shall be considered z-axis capable. In the case of location solutions that do not require barometric pressure sensor information, both devices with and without barometric sensors shall be considered z-axis capable, provided that they are software-upgradable.
(iii) Compliance. Within 60 days after each benchmark date specified in paragraphs (i)(2)(i) and (ii) of this section, CMRS providers must certify that they are in compliance with the location accuracy requirements applicable to them as of that date. CMRS providers shall be presumed to be in compliance by certifying that they have complied with the test bed and live call data provisions described in paragraph (i)(3) of this section.
(A) All CMRS providers must certify that the indoor location technology (or technologies) used in their networks are deployed consistently with the manner in which they have been tested in the test bed. A CMRS provider must update certification whenever it introduces a new technology into its network or otherwise modifies its network, such that previous performance in the test bed would no longer be consistent with the technology's modified deployment.
(B) CMRS providers that provide quarterly reports of live call data in one or more of the six test cities specified in paragraph (i)(1)(vi) of this section must certify that their deployment of location technologies throughout their coverage area is consistent with their deployment of the same technologies in the areas that are used for live call data reporting.
(C) Non-nationwide CMRS providers that do not provide service or report quarterly live call data in any of the six test cities specified in paragraph (i)(1)(vi) of this section must certify that they have verified based on their own live call data that they are in compliance with the requirements of paragraphs (i)(2)(i)(B) and (i)(2)(ii) of this section.
(iv) Enforcement. PSAPs may seek Commission enforcement within their geographic service area of the requirements of paragraphs (i)(2)(i) and (ii) of this section, but only so long as they have implemented policies that are designed to obtain all location information made available by CMRS providers when initiating and delivering 911 calls to the PSAP. Prior to seeking Commission enforcement, a PSAP must provide the CMRS provider with [30] days written notice, and the CMRS provider shall have an opportunity to address the issue informally. If the issue has not been addressed to the PSAP's satisfaction within 90 days, the PSAP may seek enforcement relief.
(3) Indoor location accuracy testing and live call data reporting —(i) Indoor location accuracy test bed. CMRS providers must establish the test bed described in this section within 12 months of the effective date of this rule. CMRS providers must validate technologies intended for indoor location, including dispatchable location technologies and technologies that deliver horizontal and/or vertical coordinates, through an independently administered and transparent test bed process, in order for such technologies to be presumed to comply with the location accuracy requirements of this paragraph. The test bed shall meet the following minimal requirements in order for the test results to be considered valid for compliance purposes:
(A) Include testing in representative indoor environments, including dense urban, urban, suburban and rural morphologies;
(B) Test for performance attributes including location accuracy (ground truth as measured in the test bed), latency (Time to First Fix), and reliability (yield); and
(C) Each test call (or equivalent) shall be independent from prior calls and accuracy will be based on the first location delivered after the call is initiated.
(D) In complying with paragraph (i)(3)(i)(B) of this section, CMRS providers shall measure yield separately for each individual indoor location morphology (dense urban, urban, suburban, and rural) in the test bed, and based upon the specific type of location technology that the provider intends to deploy in real-world areas represented by that particular morphology. CMRS providers must base the yield percentage based on the number of test calls that deliver a location in compliance with any applicable indoor location accuracy requirements, compared to the total number of calls that successfully connect to the testing network. CMRS providers may exclude test calls that are dropped or otherwise disconnected in 10 seconds or less from calculation of the yield percentage (both the denominator and numerator).
(ii) Collection and reporting of aggregate live 911 call location data. CMRS providers providing service in any of the Test Cities or portions thereof must collect and report aggregate data on the location technologies used for live 911 calls in those areas.
(A) CMRS providers subject to this section shall identify and collect information regarding the location technology or technologies used for each 911 call in the reporting area during the calling period.
(B) CMRS providers subject to this section shall report Test City call location data on a quarterly basis to the Commission, the National Emergency Number Association, the Association of Public Safety Communications Officials, and the National Association of State 911 Administrators, with the first report due 18 months from the effective date of rules adopted in this proceeding.
(C) CMRS providers subject to this section shall also provide quarterly live call data on a more granular basis that allows evaluation of the performance of individual location technologies within different morphologies (e.g., dense urban, urban, suburban, rural). To the extent available, live call data for all CMRS providers shall delineate based on a per technology basis accumulated and so identified for:
( 1 ) Each of the ATIS ESIF morphologies;
( 2 ) On a reasonable community level basis; or
( 3 ) By census block. This more granular data will be used for evaluation and not for compliance purposes.
(D) Non-nationwide CMRS providers that operate in a single Test City need only report live 911 call data from that city or portion thereof that they cover. Non-nationwide CMRS providers that operate in more than one Test City must report live 911 call data only in half of the regions (as selected by the provider). In the event a non-nationwide CMRS provider begins coverage in a Test City it previously did not serve, it must update its certification pursuant to paragraph (i)(2)(iii)(C) of this section to reflect this change in its network and begin reporting data from the appropriate areas. All non-nationwide CMRS providers must report their Test City live call data every 6 months, beginning 18 months from the effective date of rules adopted in this proceeding.
(E) Non-nationwide CMRS providers that do not provide coverage in any of the Test Cities can satisfy the requirement of this paragraph (i)(3)(ii) by collecting and reporting data based on the largest county within its footprint. In addition, where a non-nationwide CMRS provider serves more than one of the ATIS ESIF morphologies, it must include a sufficient number of representative counties to cover each morphology.
(iii) Data retention. CMRS providers shall retain testing and live call data gathered pursuant to this section for a period of 2 years.
(4) Submission of plans and reports. The following reporting and certification obligations apply to all CMRS providers subject to this section, which may be filed electronically in PS Docket No. 07-114:
(i) Initial implementation plan. No later than 18 months from the effective date of the adoption of this rule, nationwide CMRS providers shall report to the Commission on their plans for meeting the indoor location accuracy requirements of paragraph (i)(2) of this section. Non-nationwide CMRS providers will have an additional 6 months to submit their implementation plans.
(ii) Progress reports. No later than 18 months from the effective date of the adoption of this rule), each CMRS provider shall file a progress report on implementation of indoor location accuracy requirements. Non-nationwide CMRS providers will have an additional 6 months to submit their progress reports. All CMRS providers shall provide an additional progress report no later than 36 months from the effective date of the adoption of this rule. The 36-month reports shall indicate what progress the provider has made consistent with its implementation plan, and the nationwide CMRS providers shall include an assessment of their deployment of dispatchable location solutions. For any CMRS provider participating in the development of the NEAD database, this progress report must include detail as to the implementation of the NEAD database described in paragraphs (i)(4)(iii) and (iv) of this section.
(iii) NEAD privacy and security plan. Prior to activation of the NEAD but no later than 18 months from the effective date of the adoption of this rule, the nationwide CMRS providers shall file with the Commission and request approval for a security and privacy plan for the administration and operation of the NEAD. The plan must include the identity of an administrator for the NEAD, who will serve as a point of contact for the Commission and shall be accountable for the effectiveness of the security, privacy, and resiliency measures.
(iv) Dispatchable location use certification. Prior to use of dispatchable location information to meet the Commission's 911 horizontal and indoor location accuracy requirements in paragraphs (i)(2)(i) and (ii) of this section, CMRS providers must certify that neither they nor any third party they rely on to obtain dispatchable location information will use dispatchable location information or associated data for any non-911 purpose, except with prior express consent or as otherwise required by law. The certification must state that CMRS providers and any third party they rely on to obtain dispatchable location information will implement measures sufficient to safeguard the privacy and security of dispatchable location information.
(v) Z-axis use certification. Prior to use of z-axis information to meet the Commission's 911 vertical location accuracy requirements in paragraph (i)(2)(ii) of this section, CMRS providers must certify that neither they nor any third party they rely on to obtain z-axis information will use z-axis information or associated data for any non-911 purpose, except with prior express consent or as otherwise required by law. The certification must state that CMRS providers and any third party they rely on to obtain z-axis information will implement measures sufficient to safeguard the privacy and security of z-axis location information.
(j) Confidence and uncertainty data. (1) Except as provided in paragraphs (j)(2) through (4) of this section, CMRS providers subject to this section shall provide for all wireless 911 calls, whether from outdoor or indoor locations, x- and y-axis (latitude, longitude) and z-axis (vertical) confidence and uncertainty information (C/U data) on a per-call basis upon the request of a PSAP. The data shall specify:
(i) The caller's location with a uniform confidence level of 90 percent, and;
(ii) The radius in meters from the reported position at that same confidence level. All entities responsible for transporting confidence and uncertainty between CMRS providers and PSAPs, including LECs, CLECs, owners of E911 networks, and emergency service providers, must enable the transmission of confidence and uncertainty data provided by CMRS providers to the requesting PSAP.
(2) Upon meeting the 3-year timeframe pursuant to paragraph (i)(2)(i) of this section, CMRS providers shall provide with wireless 911 calls that have a dispatchable location the C/U data for the x- and y-axis (latitude, longitude) required under paragraph (j)(1) of this section.
(3) Upon meeting the 6-year timeframe pursuant to paragraph (i)(2)(i) of this section, CMRS providers shall provide with wireless 911 calls that have a dispatchable location the C/U data for the x- and y-axis (latitude, longitude) required under paragraph (j)(1) of this section.
(4) Upon meeting the timeframes pursuant to paragraph (i)(2)(ii) of this section, CMRS providers shall provide with wireless 911 calls that have a dispatchable location the confidence and uncertainty data for z-axis (vertical) information required under paragraph (j)(1) of this section. Where available to the CMRS provider, CMRS providers shall provide with wireless 911 calls that have floor level information the confidence and uncertainty data for z-axis (vertical) information required under paragraph (j)(1) of this section.
(k) Provision of live 911 call data for PSAPs. Notwithstanding other 911 call data collection and reporting requirements in paragraph (i) of this section, CMRS providers must record information on all live 911 calls, including, but not limited to, the positioning source method used to provide a location fix associated with the call. CMRS providers must also record the confidence and uncertainty data that they provide pursuant to paragraphs (j)(1)-(4) of this section. This information must be made available to PSAPs upon request, and shall be retained for a period of two years.
(l) Reports on Phase II plans. Licensees subject to this section shall report to the Commission their plans for implementing Phase II enhanced 911 service, including the location-determination technology they plan to employ and the procedure they intend to use to verify conformance with the Phase II accuracy requirements by November 9, 2000. Licensees are required to update these plans within thirty days of the adoption of any change. These reports and updates may be filed electronically in a manner to be designated by the Commission.
(m) Conditions for enhanced 911 services —(1) Generally. The requirements set forth in paragraphs (d) through (h)(2) and in paragraph (j) of this section shall be applicable only to the extent that the administrator of the applicable designated PSAP has requested the services required under those paragraphs and such PSAP is capable of receiving and using the requested data elements and has a mechanism for recovering the PSAP's costs associated with them.
(2) Commencement of six-month period. (i) Except as provided in paragraph (m)(2)(ii) of this section, for purposes of commencing the six-month period for carrier implementation specified in paragraphs (d), (f) and (g) of this section, a PSAP will be deemed capable of receiving and using the data elements associated with the service requested, if it can demonstrate that it has:
(A) Ordered the necessary equipment and has commitments from suppliers to have it installed and operational within such six-month period; and
(B) Made a timely request to the appropriate local exchange carrier for the necessary trunking, upgrades, and other facilities.
(ii) For purposes of commencing the six-month period for carrier implementation specified in paragraphs (f) and (g) of this section, a PSAP that is Phase I-capable using a Non-Call Path Associated Signaling (NCAS) technology will be deemed capable of receiving and using the data elements associated with Phase II service if it can demonstrate that it has made a timely request to the appropriate local exchange carrier for the ALI database upgrade necessary to receive the Phase II information.
(3) Tolling of six-month period. Where a wireless carrier has served a written request for documentation on the PSAP within 15 days of receiving the PSAP's request for Phase I or Phase II enhanced 911 service, and the PSAP fails to respond to such request within 15 days of such service, the six-month period for carrier implementation specified in paragraphs (d), (f), and (g) of this section will be tolled until the PSAP provides the carrier with such documentation.
(4) Carrier certification regarding PSAP readiness issues. At the end of the six-month period for carrier implementation specified in paragraphs (d), (f), and (g) of this section, a wireless carrier that believes that the PSAP is not capable of receiving and using the data elements associated with the service requested may file a certification with the Commission. Upon filing and service of such certification, the carrier may suspend further implementation efforts, except as provided in paragraph (m)(4)(x) of this section.
(i) As a prerequisite to filing such certification, no later than 21 days prior to such filing, the wireless carrier must notify the affected PSAP, in writing, of its intent to file such certification. Any response that the carrier receives from the PSAP must be included with the carrier's certification filing.
(ii) The certification process shall be subject to the procedural requirements set forth in §§ 1.45 and 1.47 of this chapter.
(iii) The certification must be in the form of an affidavit signed by a director or officer of the carrier, documenting:
(A) The basis for the carrier's determination that the PSAP will not be ready;
(B) Each of the specific steps the carrier has taken to provide the E911 service requested;
(C) The reasons why further implementation efforts cannot be made until the PSAP becomes capable of receiving and using the data elements associated with the E911 service requested; and
(D) The specific steps that remain to be completed by the wireless carrier and, to the extent known, the PSAP or other parties before the carrier can provide the E911 service requested.
(iv) All affidavits must be correct. The carrier must ensure that its affidavit is correct, and the certifying director or officer has the duty to personally determine that the affidavit is correct.
(v) A carrier may not engage in a practice of filing inadequate or incomplete certifications for the purpose of delaying its responsibilities.
(vi) To be eligible to make a certification, the wireless carrier must have completed all necessary steps toward E911 implementation that are not dependent on PSAP readiness.
(vii) A copy of the certification must be served on the PSAP in accordance with § 1.47 of this chapter. The PSAP may challenge in writing the accuracy of the carrier's certification and shall serve a copy of such challenge on the carrier. See §§ 1.45 and 1.47 and 1.720 through 1.740 of this chapter.
(viii) If a wireless carrier's certification is facially inadequate, the six-month implementation period specified in paragraphs (d), (f), and (g) of this section will not be suspended as provided for in paragraph (m)(4) of this section.
(ix) If a wireless carrier's certification is inaccurate, the wireless carrier will be liable for noncompliance as if the certification had not been filed.
(x) A carrier that files a certification under this paragraph (m)(4) shall have 90 days from receipt of the PSAP's written notice that it is capable of receiving and using the data elements associated with the service requested to provide such service in accordance with the requirements of paragraphs (d) through (h) of this section.
(5) Modification of deadlines by agreement. Nothing in this section shall prevent Public Safety Answering Points and carriers from establishing, by mutual consent, deadlines different from those imposed for carrier and PSAP compliance in paragraphs (d), (f), and (g)(2) of this section.
(n) [Reserved]
(o) Non-service-initialized handsets. (1) Licensees subject to this section that donate a non-service-initialized handset for purposes of providing access to 911 services are required to:
(i) Program each handset with 911 plus the decimal representation of the seven least significant digits of the Electronic Serial Number, International Mobile Equipment Identifier, or any other identifier unique to that handset;
(ii) Affix to each handset a label which is designed to withstand the length of service expected for a non-service-initialized phone, and which notifies the user that the handset can only be used to dial 911, that the 911 operator will not be able to call the user back, and that the user should convey the exact location of the emergency as soon as possible; and
(iii) Institute a public education program to provide the users of such handsets with information regarding the limitations of non-service-initialized handsets.
(2) Manufacturers of 911-only handsets that are manufactured on or after May 3, 2004, are required to:
(i) Program each handset with 911 plus the decimal representation of the seven least significant digits of the Electronic Serial Number, International Mobile Equipment Identifier, or any other identifier unique to that handset;
(ii) Affix to each handset a label which is designed to withstand the length of service expected for a non-service-initialized phone, and which notifies the user that the handset can only be used to dial 911, that the 911 operator will not be able to call the user back, and that the user should convey the exact location of the emergency as soon as possible; and
(iii) Institute a public education program to provide the users of such handsets with information regarding the limitations of 911-only handsets.
(3) The following definitions apply for purposes of this paragraph.
(i) Non-service-initialized handset. A handset for which there is no valid service contract with a provider of the services enumerated in paragraph (a) of this section.
(ii) 911-only handset. A non-service-initialized handset that is manufactured with the capability of dialing 911 only and that cannot receive incoming calls.
(p) Reseller obligation. (1) Beginning December 31, 2006, resellers have an obligation, independent of the underlying licensee, to provide access to basic and enhanced 911 service to the extent that the underlying licensee of the facilities the reseller uses to provide access to the public switched network complies with § 9.10(d) through (g).
(2) Resellers have an independent obligation to ensure that all handsets or other devices offered to their customers for voice communications and sold after December 31, 2006 are capable of transmitting enhanced 911 information to the appropriate PSAP, in accordance with the accuracy requirements of § 9.10(i).
(q) Text-to-911 requirements —(1) Covered text provider. Notwithstanding any other provisions in this section, for purposes of this paragraph (q) of this section, a “covered text provider” includes all CMRS providers as well as all providers of interconnected text messaging services that enable consumers to send text messages to and receive text messages from all or substantially all text-capable U.S. telephone numbers, including through the use of applications downloaded or otherwise installed on mobile phones.
(2) Automatic bounce-back message. An automatic text message delivered to a consumer by a covered text provider in response to the consumer's attempt to send a text message to 911 when the consumer is located in an area where text-to-911 service is unavailable or the covered text provider does not support text-to-911 service generally or in the area where the consumer is located at the time.
(3) Provision of automatic bounce-back messages. No later than September 30, 2013, all covered text providers shall provide an automatic bounce-back message under the following circumstances:
(i) A consumer attempts to send a text message to a Public Safety Answering Point (PSAP) by means of the three-digit short code “911”; and
(ii) The covered text provider cannot deliver the text because the consumer is located in an area where:
(A) Text-to-911 service is unavailable; or
(B) The covered text provider does not support text-to-911 service at the time.
(4) Automatic bounce-back message exceptions. (i) A covered text provider is not required to provide an automatic bounce-back message when:
(A) Transmission of the text message is not controlled by the provider;
(B) A consumer is attempting to text 911, through a text messaging application that requires CMRS service, from a non-service initialized handset;
(C) When the text-to-911 message cannot be delivered to a PSAP due to failure in the PSAP network that has not been reported to the provider; or
(D) A consumer is attempting to text 911 through a device that is incapable of sending texts via three digit short codes, provided the software for the device cannot be upgraded over the air to allow text-to-911.
(ii) The provider of a preinstalled or downloadable interconnected text application is considered to have “control” over transmission of text messages for purposes of paragraph (q)(4)(i)(A) of this section. However, if a user or a third party modifies or manipulates the application after it is installed or downloaded so that it no longer supports bounce-back messaging, the application provider will be presumed not to have control.
(5) Automatic bounce-back message minimum requirements. The automatic bounce-back message shall, at a minimum, inform the consumer that text-to-911 service is not available and advise the consumer or texting program user to use another means to contact emergency services.
(6) Temporary suspension of text-to-911 service. Covered text providers that support text-to-911 must provide a mechanism to allow PSAPs that accept text-to-911 to request temporary suspension of text-to-911 service for any reason, including, but not limited to, network congestion, call taker overload, PSAP failure, or security breach, and to request resumption of text-to-911 service after such temporary suspension. During any period of suspension of text-to-911 service, the covered text provider must provide an automatic bounce-back message to any consumer attempting to text to 911 in the area subject to the temporary suspension.
(7) Roaming. Notwithstanding any other provisions in this section, when a consumer is roaming on a covered text provider's host network pursuant to § 20.12, the covered text provider operating the consumer's home network shall have the obligation to originate an automatic bounce-back message to such consumer when the consumer is located in an area where text-to-911 service is unavailable, or the home provider does not support text-to-911 service in that area at the time. The host provider shall not impede the consumer's 911 text message to the home provider and/or any automatic bounce-back message originated by the home provider to the consumer roaming on the host network.
(8) Software application provider. A software application provider that transmits text messages directly into the SMS network of the consumer's underlying CMRS provider satisfies the obligations of paragraph (q)(3) of this section provided it does not prevent or inhibit delivery of the CMRS provider's automatic bounce-back message to the consumer.
(9) 911 text message. A 911 text message is a message, consisting of text characters, sent to the short code “911” and intended to be delivered to a PSAP by a covered text provider, regardless of the text messaging platform used.
(10) Delivery of 911 text messages. (i) No later than December 31, 2014, all covered text providers must have the capability to route a 911 text message to a PSAP. In complying with this requirement, covered text providers must obtain location information sufficient to route text messages to the same PSAP to which a 911 voice call would be routed, unless the responsible local or state entity designates a different PSAP to receive 911 text messages and informs the covered text provider of that change. All covered text providers using device-based location information that requires consumer activation must clearly inform consumers that they must grant permission for the text messaging application to access the wireless device's location information in order to enable text-to-911. If a consumer does not permit this access, the covered text provider's text application must provide an automated bounce-back message as set forth in paragraph (q)(3) of this section.
(ii) Covered text providers must begin routing all 911 text messages to a PSAP by June 30, 2015, or within six months of the PSAP's valid request for text-to-911 service, whichever is later, unless an alternate timeframe is agreed to by both the PSAP and the covered text provider. The covered text provider must notify the Commission of the dates and terms of the alternate timeframe within 30 days of the parties' agreement.
(iii) Valid Request means that:
(A) The requesting PSAP is, and certifies that it is, technically ready to receive 911 text messages in the format requested;
(B) The appropriate local or state 911 service governing authority has specifically authorized the PSAP to accept and, by extension, the covered text provider to provide, text-to-911 service; and
(C) The requesting PSAP has provided notification to the covered text provider that it meets the foregoing requirements. Registration by the PSAP in a database made available by the Commission in accordance with requirements established in connection therewith, or any other written notification reasonably acceptable to the covered text provider, shall constitute sufficient notification for purposes of this paragraph.
(iv) The requirements set forth in paragraphs (q)(10)(i) through (iii) of this section do not apply to in-flight text messaging providers, MSS providers, or IP Relay service providers, or to 911 text messages that originate from Wi-Fi only locations or that are transmitted from devices that cannot access the CMRS network.
(v) No later than January 6, 2022, covered text providers must provide the following location information with all 911 text messages routed to a PSAP: Automated dispatchable location, if technically feasible; otherwise, either end-user manual provision of location information, or enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost.
(11) Access to SMS networks for 911 text messages. To the extent that CMRS providers offer Short Message Service (SMS), they shall allow access by any other covered text provider to the capabilities necessary for transmission of 911 text messages originating on such other covered text providers' application services. Covered text providers using the CMRS network to deliver 911 text messages must clearly inform consumers that, absent an SMS plan with the consumer's underlying CMRS provider, the covered text provider may be unable to deliver 911 text messages. CMRS providers may migrate to other technologies and need not retain SMS networks solely for other covered text providers' 911 use, but must notify the affected covered text providers not less than 90 days before the migration is to occur.
(r) Contraband Interdiction System (CIS) requirement. CIS providers regulated as private mobile radio service ( see § 9.3) must transmit all wireless 911 calls without respect to their call validation process to a Public Safety Answering Point, or, where no Public Safety Answering Point has been designated, to a designated statewide default answering point or appropriate local emergency authority pursuant to § 9.4, provided that “all wireless 911 calls” is defined as “any call initiated by a wireless user dialing 911 on a phone using a compliant radio frequency protocol of the serving carrier.” This requirement shall not apply if the Public Safety Answering Point or emergency authority informs the CIS provider that it does not wish to receive 911 calls from the CIS provider.
(s) Location-based routing requirements —(1) Wireless 911 voice calls. (i) By November 13, 2024, nationwide CMRS providers must deploy a technology that supports location-based routing for wireless 911 voice calls on their internet Protocol-based networks (4G LTE, 5G, and subsequent generations of internet Protocol-based networks) nationwide. At that time, nationwide CMRS providers must route all wireless 911 voice calls originating on their internet Protocol-based networks pursuant to the requirements of paragraph (s)(3) of this section.
(ii) By May 13, 2026, non-nationwide CMRS providers must deploy a technology that supports location-based routing for wireless 911 voice calls on their internet Protocol-based networks (4G LTE, 5G, and subsequent generations of internet Protocol-based networks). At that time, non-nationwide CMRS providers must route all wireless 911 voice calls originating on their internet Protocol-based networks pursuant to the requirements of paragraph (s)(3) of this section.
(2) Real-time text communications to 911. By May 13, 2026, CMRS providers must deploy a technology that supports location-based routing for real-time text communications to 911 originating on their internet-Protocol-based networks (4G LTE, 5G, and subsequent generations of internet Protocol-based networks). At that time, CMRS providers must route all real-time text communications to 911 originating on their internet Protocol-based networks pursuant to the requirements of paragraph (s)(3) of this section.
(3) Timeliness and accuracy threshold. (i) Notwithstanding requirements for confidence and uncertainty described in paragraph (j) of this section, CMRS providers must use location information that meets the following specifications for routing wireless 911 voice calls and real-time text communications to 911 under paragraphs (s)(1) and (2) of this section:
(A) The location information reports the horizontal location uncertainty level of the device within a radius of 165 meters at a confidence level of at least 90%; and
(B) The location information is available to the CMRS provider network at the time of routing the wireless 911 voice call or real-time text communication to 911.
(ii) When the location information does not meet either one or both of the requirements in paragraphs (s)(3)(i)(A) and (B) of this section, CMRS providers must route the wireless 911 voice call or real-time text communication to 911 based on the best available location information, which may include but is not limited to device-based location information that does not meet the requirements in paragraphs (s)(3)(i)(A) and (B), the centroid of the area served by the cell sector that first picks up the call, or other location information.
(4) Certification and reporting. Within 60 days after each benchmark specified in paragraphs (s)(1)(i) and (ii) and (s)(2) of this section, CMRS providers must comply with the following certification and reporting requirements.
(i) CMRS providers must:
(A) Certify that they are in compliance with the requirements specified in paragraphs (s)(1)(i) and (ii) and (s)(2) of this section applicable to them;
(B) Identify specific network architecture, systems, and procedures used to comply with paragraphs (s)(1)(i) and (ii) and (s)(2) of this section, including the extent to which the CMRS provider validates location information for routing purposes and the validation practices used in connection with this information; and
(C) Certify that neither they nor any third party they rely on to obtain location information or associated data used for compliance with paragraph (s)(1)(i) or (ii) or (s)(2) of this section will use such location information or associated data for any non-911 purpose, except with prior express consent or as otherwise required by law. The certification must state that the CMRS provider and any third parties it relies on to obtain location information or associated data used for compliance with paragraph (s)(1)(i) or (ii) or (s)(2) have implemented measures sufficient to safeguard the privacy and security of such location information or associated data.
(ii) CMRS providers also must:
(A) Collect and report aggregate data on the routing technologies used for all live wireless 911 voice calls in the locations specified for live 911 call location data in paragraph (i)(3)(ii) of this section for a thirty-day period which begins on the compliance date(s) specified in paragraphs (s)(1)(i) and (ii) of this section. CMRS providers must retain live wireless 911 voice call data gathered pursuant to this section for a period of 2 years. CMRS providers must collect and report the following data, expressed as both a number and percentage of the total number of live wireless 911 voice calls for which data is collected pursuant to this section:
( 1 ) Live wireless 911 voice calls routed with location-based routing using location information that meets the timeliness and accuracy thresholds defined in paragraphs (s)(3)(i)(A) and (B) of this section;
( 2 ) Live wireless 911 voice calls routed with location-based routing using location information that does not meet the timeliness or accuracy thresholds defined in paragraphs (s)(3)(i)(A) and (B) of this section; and
( 3 ) Live wireless 911 voice calls routed using tower-based routing.
(5) Modification of deadlines by agreement. Nothing in this section shall prevent PSAPs and CMRS providers from establishing, by mutual consent, deadlines different from those established for CMRS provider compliance in paragraphs (s)(1)(i) and (ii) and (s)(2) of this section. The CMRS provider must notify the Commission of the dates and terms of the alternate time frame within 30 days of the parties' agreement or June 11, 2024, whichever is later. The CMRS provider must subsequently notify the Commission of the actual date by which it comes into compliance with the location-based routing requirements in paragraph (s)(1)(i) or (ii) or (s)(2) within 30 days of that date or June 11, 2024, whichever is later. CMRS providers must file such notifications pursuant to this paragraph (s)(5) in PS Docket No. 18-64. The parties may not use this paragraph (s)(5) to delay compliance with paragraph (s)(1)(i) or (ii) or (s)(2) of this section indefinitely.
(t) Interim 911 requirements for supplemental coverage from space —(1) Supplemental coverage from space. For purposes of this paragraph (t), supplemental coverage from space (SCS) has the same meaning as in part 25, subpart A, of this chapter; SCS 911 calls are 911 calls (as defined in § 9.3) that are carried over satellite facilities pursuant to a CMRS provider's SCS arrangement; and an SCS 911 text message is a 911 text message (as defined in paragraph (q)(9) of this section) that is carried over satellite facilities pursuant to a CMRS provider's SCS arrangement.
(2) Call Transmission requirements. For purposes of delivering SCS 911 voice calls and SCS 911 text messages, CMRS providers must either:
(i) Use information regarding the location of a device, including but not limited to device-based location information, to route SCS 911 voice calls and SCS 911 text messages to an appropriate PSAP and transmit the phone number of the device used to send the SCS 911 voice call or SCS 911 text message and available location information to an appropriate PSAP; or
(ii) Use an emergency call center, at which emergency call center personnel must determine the emergency caller's phone number and location and then transfer or otherwise direct the 911 caller to an appropriate PSAP.
(3) Reporting. Each CMRS provider that utilizes SCS arrangements to expand its coverage areas for providing service to its end-user subscribers must maintain records of all SCS 911 voice calls and SCS 911 text messages received on its network and received at its emergency call center. By October 15 of each year, each CMRS provider that utilizes SCS arrangements to expand its coverage areas for providing service to its end-user subscribers must submit a report to the Commission regarding SCS 911 voice calls and 911 text messages, and its emergency call center data, current as of September 30 of that year. CMRS providers that utilize SCS arrangements to expand their coverage areas for providing service to their end-user subscribers must submit this certification in the Commission's Electronic Comment Filing System. These reports must include, at a minimum, the following:
(i) The name and address of the CMRS provider, the address of that CMRS provider's emergency call center, and the contact information of the emergency call center;
(ii) The aggregate number of SCS 911 voice calls and SCS 911 text messages received by the network of the CMRS provider that provides SCS service to its end-user subscribers during each month during the relevant reporting period;
(iii) The aggregate number of SCS 911 voice calls and SCS 911 text messages received by the emergency call center each month during the relevant reporting period;
(iv) The aggregate number of SCS 911 voice calls and SCS 911 text messages received by the emergency call center each month during the relevant reporting period that required forwarding to a PSAP and how many did not require forwarding to a PSAP;
(v) The aggregate number of SCS 911 voice calls that were routed using location information that met the timeliness and accuracy thresholds defined in paragraphs (s)(3)(i)(A) and (B) of this section;
(vi) The aggregate number of SCS 911 voice calls and SCS 911 text messages that were routed using location information that did not meet the timeliness and accuracy thresholds defined in paragraphs (s)(3)(i)(A) and (B) of this section; and
(vii) An explanation of how the SCS deployment, including network architecture, systems, and procedures, will support routing SCS 911 voice calls and SCS 911 text messages to the geographically appropriate PSAP with sufficient location information in compliance with paragraph (t)(2) of this section.
(4) Certification. CMRS providers that utilize SCS arrangements to expand their coverage areas for providing service to their end-user subscribers must certify on a one-time basis that neither they nor any third party they rely on to obtain location information or associated data used for compliance with paragraph (t)(2)(i) or (ii) of this section will use such location information or associated data for any non-911 purpose, except with prior express consent or as otherwise permitted or required by law. The certification must state that the CMRS provider and any third parties it relies on to obtain location information or associated data used for compliance with paragraph (t)(2)(i) or (ii) have implemented measures sufficient to safeguard the privacy and security of such location information or associated data. CMRS providers that utilize SCS arrangements to expand their coverage areas for providing service to their end-user subscribers must submit this one-time certification in the Commission's Electronic Comment Filing System on the due date of the first report made under paragraph (t)(3) of this section.
(5) Subscriber notification. Each CMRS provider that utilizes SCS arrangements to expand its coverage areas for providing service to its end-user subscribers shall specifically advise every subscriber, both new and existing, in writing prominently and in plain language, of the circumstances under which 911 service for all SCS 911 calls, or SCS 911 text messages may not be available via SCS or may be in some way limited by comparison to traditional enhanced 911 service.
(a) [Reserved]
(b) On or after January 6, 2021, for fixed services, and on or after January 6, 2022, for non-fixed services —(1) Scope. The following requirements of paragraphs (b)(1) through (5) of this section are only applicable to all providers of interconnected VoIP services. Further, these requirements apply only to 911 calls placed by users whose dispatchable location is in a geographic area served by a Wireline E911 Network (which, as defined in § 9.3, includes a selective router).
(2) E911 Service —(i) Interconnected VoIP service providers must, as a condition of providing service to a consumer, provide that consumer with E911 service as described in this section;
(ii) Interconnected VoIP service providers must transmit the following to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's dispatchable location and that has been designated for telecommunications carriers pursuant to § 9.4:
(A) All 911 calls, provided that “all 911 calls” is defined as “any voice communication initiated by an interconnected VoIP user dialing 911;”
(B) ANI; and
(C) The location information described in paragraph (b)(4) of this section.
(iii) All 911 calls must be routed through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network, provided that nothing in this subparagraph shall preclude routing the call first to a national emergency call center to ascertain the caller's location in the event that the interconnected VoIP service provider is unable to obtain or confirm the caller's location information; and
(iv) The location information described in paragraph (b)(4) of this section must be available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.
(3) Service level obligation. Notwithstanding the provisions in paragraph (b)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, an interconnected VoIP service provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (b)(2)(iii) of this section of an interconnected VoIP service provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's dispatchable location and that has been designated for telecommunications carriers pursuant to § 9.4.
(4) Location requirements. To meet E911 service requirements, interconnected VoIP service providers must provide location information with each 911 call as follows:
(i) Fixed interconnected VoIP services. Providers of fixed interconnected VoIP services must provide automated dispatchable location with each 911 call.
(ii) Non-fixed interconnected VoIP services. For non-fixed interconnected VoIP service (service that is capable of being used from more than one location), interconnected VoIP service providers must provide location information in accordance with paragraph (b)(4)(ii)(A) of this section, if technically feasible. Otherwise, interconnected VoIP service providers must either provide location information in accordance with paragraph (b)(4)(ii)(B) or (C), or meet paragraph (b)(4)(ii)(D) of this section.
(A) Provide automated dispatchable location, if technically feasible.
(B) Provide Registered Location information that meets the following requirements:
( 1 ) The service provider has obtained from the customer, prior to the initiation of service, the Registered Location (as defined in § 9.3) at which the service will first be used;
( 2 ) The service provider has provided end users one or more methods of updating their Registered Location, including at least one option that requires use only of the CPE necessary to access the interconnected VoIP service. Any method used must allow an end user to update the Registered Location at will and in a timely manner; and
( 3 ) The service provider must identify whether the service is being used to call 911 from a different location than the Registered Location, and if so, either:
( i ) Prompt the customer to provide a new Registered Location; or
( ii ) Update the Registered Location without requiring additional action by the customer.
(C) Provide Alternative Location Information as defined in § 9.3.
(D) Route the caller to a national emergency call center.
(5) Customer notification. (i) Each interconnected VoIP service provider shall specifically advise every subscriber, both new and existing, prominently and in plain language, of the circumstances under which E911 service may not be available through the interconnected VoIP service or may be in some way limited by comparison to traditional E911 service. Such circumstances include, but are not limited to, relocation of the end user's IP-compatible CPE, use by the end user of a non-native telephone number, broadband connection failure, loss of electrical power, and delays that may occur in making a dispatchable location available in or through the ALI database;
(ii) Each interconnected VoIP service provider shall obtain and keep a record of affirmative acknowledgement by every subscriber, both new and existing, of having received and understood the advisory described in paragraph (b)(5)(i) of this section; and
(iii) Each interconnected VoIP service provider shall either:
(A) Distribute to its existing subscribers, and to each new subscriber prior to the initiation of that subscriber's service, warning stickers or labels warning subscribers if E911 service may be limited or not available, and instructing the subscriber to place them on or near the equipment used in conjunction with the interconnected VoIP service; or
(B) Notify existing subscribers, and each new subscriber prior to the initiation of that subscriber's service, by other conspicuous means if E911 service may be limited or not available.
(a) Access. Subject to the other requirements of this part, an owner or controller of a capability that can be used for 911 or E911 service shall make that capability available to a requesting interconnected VoIP provider as set forth in paragraphs (a)(1) and (2) of this section.
(1) If the owner or controller makes the requested capability available to a CMRS provider, the owner or controller must make that capability available to the interconnected VoIP provider. An owner or controller makes a capability available to a CMRS provider if the owner or controller offers that capability to any CMRS provider.
(2) If the owner or controller does not make the requested capability available to a CMRS provider within the meaning of paragraph (a)(1) of this section, the owner or controller must make that capability available to a requesting interconnected VoIP provider only if that capability is necessary to enable the interconnected VoIP provider to provide 911 or E911 service in compliance with the Commission's rules.
(b) Rates, terms, and conditions. The rates, terms, and conditions on which a capability is provided to an interconnected VoIP provider under paragraph (a) of this section shall be reasonable. For purposes of this paragraph, it is evidence that rates, terms, and conditions are reasonable if they are:
(1) The same as the rates, terms, and conditions that are made available to CMRS providers, or
(2) In the event such capability is not made available to CMRS providers, the same rates, terms, and conditions that are made available to any telecommunications carrier or other entity for the provision of 911 or E911 service.
(c) Permissible use. An interconnected VoIP provider that obtains access to a capability pursuant to this section may use that capability only for the purpose of providing 911 or E911 service in accordance with the Commission's rules.
Any violation of this subpart E by any common carrier engaged in intrastate communication shall be subject to the same remedies, penalties, and procedures as are applicable to a violation of the Act by a common carrier engaged in interstate communication. For purposes of this subpart, all regulations and requirements applicable to common carriers shall also be applicable to providers of interconnected VoIP service as defined in § 9.3.
(a) Emergency call handling requirements for TTY-based TRS providers. TTY-based TRS providers must use a system for incoming emergency calls that, at a minimum, automatically and immediately transfers the caller to an appropriate Public Safety Answering Point (PSAP). An appropriate PSAP is either a PSAP that the caller would have reached if the caller had dialed 911 directly, or a PSAP that is capable of enabling the dispatch of emergency services to the caller in an expeditious manner.
(b) Additional emergency calling requirements applicable to internet-based TRS providers. (1) The requirements of paragraphs (b)(2)(i) and (iv) of this section shall not apply to providers of VRS and IP Relay to which § 9.14(c) and (d) apply.
(2) Each provider of internet-based TRS shall:
(i) When responsible for placing or routing voice calls to the public switched telephone network, accept and handle emergency calls and access, either directly or via a third party, a commercially available database that will allow the provider to determine an appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority that corresponds to the caller's location, and to relay the call to that entity;
(ii) Implement a system that ensures that the provider answers an incoming emergency call before other non-emergency calls ( i.e., prioritize emergency calls and move them to the top of the queue);
(iii) Provide 911 and E911 service in accordance with paragraphs (c) through (e) of this section, as applicable;
(iv) Deliver to the PSAP, designated statewide default answering point, or appropriate local emergency authority, at the outset of the outbound leg of an emergency call, at a minimum, the name of the relay user and location of the emergency, as well as the name of the relay provider, the CA's callback number, and the CA's identification number, thereby enabling the PSAP, designated statewide default answering point, or appropriate local emergency authority to re-establish contact with the CA in the event the call is disconnected;
(v) In the event one or both legs of an emergency call are disconnected ( i.e., either the call between the TRS user and the CA, or the outbound voice telephone call between the CA and the PSAP, designated statewide default answering point, or appropriate local emergency authority), immediately re-establish contact with the TRS user and/or the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority and resume handling the call; and
(vi) Ensure that information obtained as a result of this section is limited to that needed to facilitate 911 services, is made available only to emergency call handlers and emergency response or law enforcement personnel, and is used for the sole purpose of ascertaining a user's location in an emergency situation or for other emergency or law enforcement purposes.
(c) E911 Service for VRS and IP Relay before January 6, 2021, for fixed services, and before January 6, 2022, for non-fixed services —(1) Scope. The following requirements of paragraphs (c)(1) through (4) of this section are only applicable to providers of VRS or IP Relay. Further, these requirements apply only to 911 calls placed by registered users whose Registered Location is in a geographic area served by a Wireline E911 Network and is available to the provider handling the call.
(2) E911 Service. VRS or IP Relay providers must, as a condition of providing service to a user:
(i) Provide that user with E911 service as described in this section;
(ii) Request, at the beginning of each emergency call, the caller's name and location information, unless the VRS or IP Relay provider already has, or has access to, Registered Location information for the caller;
(iii) Transmit all 911 calls, as well as ANI, the caller's Registered Location, the name of the VRS or IP Relay provider, and the CA's identification number for each call, to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's Registered Location and that has been designated for telecommunications carriers pursuant to § 9.4, provided that “all 911 calls” is defined as “any communication initiated by an VRS or IP Relay user dialing 911”;
(iv) Route all 911 calls through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network, provided that nothing in this subparagraph shall preclude routing the call first to a call center to ascertain the caller's location in the event that the VRS or IP Relay provider believes the caller may not be located at the Registered Location; and
(v) Make the Registered Location, the name of the VRS or IP Relay provider, and the CA's identification number available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.
(3) Service level obligation. Notwithstanding the provisions in paragraph (c)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, a VRS or IP Relay provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (c)(2)(iv) of this section of a VRS or IP Relay provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's Registered Location and that has been designated for telecommunications carriers pursuant to § 9.4.
(4) Registered location requirement. VRS and IP Relay providers must:
(i) Obtain from each Registered internet-based TRS user, prior to the initiation of service, the physical location at which the service will first be used; and
(ii) If the VRS or IP Relay is capable of being used from more than one location, provide their registered internet-based TRS users one or more methods of updating the user's Registered Location, including at least one option that requires use only of the iTRS access technology necessary to access the VRS or IP Relay. Any method used must allow a registered internet-based TRS user to update the Registered Location at will and in a timely manner.
(d) E911 Service for VRS and IP Relay on or after January 6, 2021, for fixed services, and on or after January 6, 2022, for non-fixed services —(1) Scope. The following requirements of paragraphs (d)(1) through (4) of this section are only applicable to providers of VRS or IP Relay. Further, these requirements apply only to 911 calls placed by registered users whose dispatchable location is in a geographic area served by a Wireline E911 Network and is available to the provider handling the call.
(2) E911 Service. VRS or IP Relay providers must, as a condition of providing service to a user:
(i) Provide that user with E911 service as described in this section;
(ii) Request, at the beginning of each emergency call, the caller's name and dispatchable location, unless the VRS or IP relay provider already has, or has access to the location information described in paragraph (d)(4) of this section;
(iii) Transmit the following to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's dispatchable location and that has been designated for telecommunications carriers pursuant to § 9.4:
(A) All 911 calls, provided that “all 911 calls” is defined as “any communication initiated by an VRS or IP Relay user dialing 911;”
(B) ANI, the name of the VRS or IP Relay provider, and the CA's identification number for each call; and
(C) The location information described in paragraph (d)(4) of this section.
(iv) Route all 911 calls through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network, provided that nothing in this subparagraph shall preclude routing the call first to a call center to ascertain the caller's location in the event that the VRS or IP Relay provider is unable to obtain or confirm the caller's location information; and
(v) Make the location information described in paragraph (d)(4) of this section, the name of the VRS or IP Relay provider, and the CA's identification number available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.
(3) Service level obligation. Notwithstanding the provisions in paragraph (d)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, a VRS or IP Relay provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (d)(2)(iv) of this section of a VRS or IP Relay provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's dispatchable location and that has been designated for telecommunications carriers pursuant to § 9.4.
(4) Location requirements. To meet E911 service requirements, VRS and IP Relay providers must provide location information with each 911 call as follows:
(i) Fixed VRS and IP Relay services. Providers of fixed VRS and IP Relay services must provide automated dispatchable location with each 911 call.
(ii) Non-fixed VRS and IP Relay services. For non-fixed VRS and IP Relay services (service that is capable of being used from more than one location), VRS and IP Relay service providers must provide location information in accordance with paragraph (d)(4)(ii)(A) of this section, if technically feasible. Otherwise, VRS and IP Relay service providers must either provide location information in accordance with paragraph (d)(4)(ii)(B) or (C), or meet paragraph (d)(4)(ii)(D) of this section.
(A) Provide automated dispatchable location, if technically feasible.
(B) Provide Registered Location information that meets the following requirements:
( 1 ) The service provider has obtained from the customer, prior to the initiation of service, the Registered Location (as defined in § 9.3) at which the service will first be used;
( 2 ) The service provider has provided end users one or more methods of updating their Registered Location, including at least one option that requires use only of the internet-based TRS access technology necessary to access the VRS or IP Relay. Any method used must allow an end user to update the Registered Location at will and in a timely manner; and
( 3 ) If the VRS or IP Relay is capable of being used from more than one location, if it is not possible to automatically determine the Registered internet-based TRS user's location at the time of the initiation of an emergency call, verify the current location with the user at the beginning of an emergency call.
(C) Provide Alternative Location Information as defined in § 9.3.
(D) Route the caller to a call center.
(e) E911 Service for IP CTS on or after January 6, 2021, for fixed services, and on or after January 6, 2022, for non-fixed services —(1) Scope. The following requirements of paragraphs (e)(1) through (4) of this section are only applicable to “covered IP CTS providers,” who are providers of IP CTS to the extent that the IP CTS provider, itself or through an entity with whom the IP CTS provider contracts, places or routes voice calls to the public switched telephone network. Further, these requirements apply only to 911 calls placed by a registered user whose dispatchable location is in a geographic area served by a Wireline E911 Network and is available to the provider handling the call.
(2) E911 Service. Covered IP CTS providers must, as a condition of providing service to a user:
(i) Provide that user with E911 service as described in this section;
(ii) Transmit or provide the following to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's dispatchable location and that has been designated for telecommunications carriers pursuant to § 9.4:
(A) All 911 calls, provided that “all 911 calls” is defined as “any communication initiated by an IP CTS user dialing 911;”
(B) With the call, a telephone number that is assigned to the caller and that enables the PSAP, designated statewide default answering point, or appropriate local emergency authority to call the 911 caller back directly, while enabling the caller to receive captions on the callback; and
(C) The location information described in paragraph (e)(4) of this section.
(iii) Route all 911 calls through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network, provided that nothing in this subparagraph shall preclude routing the call first to a call center to ascertain the caller's location in the event that the covered IP CTS provider is unable to obtain or confirm the caller's location information; and
(iv) Make the location information described in paragraph (e)(4) of this section and callback number available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.
(3) Service level obligation. Notwithstanding the provisions in paragraph (e)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, a covered IP CTS provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (e)(2)(iii) of this section of a covered IP CTS provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's dispatchable location and that has been designated for telecommunications carriers pursuant to § 9.4.
(4) Location requirements. To meet E911 service requirements, covered IP CTS providers must provide location information with each 911 call as follows:
(i) Fixed IP CTS. Providers of fixed IP CTS must provide automated dispatchable location with each 911 call.
(ii) Non-fixed IP CTS. For non-fixed IP CTS (service that is capable of being used from more than one location), covered IP CTS providers must provide location information in accordance with paragraph (e)(4)(ii)(A) of this section, if technically feasible. Otherwise, covered IP CTS providers must either provide location information in accordance with paragraph (e)(4)(ii)(B) or (C), or meet paragraph (e)(4)(iii)(D) of this section.
(A) Provide automated dispatchable location, if technically feasible.
(B) Provide Registered Location information that meets the following requirements:
( 1 ) The service provider has obtained from the customer, prior to the initiation of service, the Registered Location (as defined in § 9.3) at which the service will first be used; and
( 2 ) The service provider has provided end users one or more methods of updating their Registered Location, including at least one option that requires use only of the internet-based TRS access technology necessary to access the IP CTS. Any method used must allow an end user to update the Registered Location at will and in a timely manner.
(C) Provide Alternative Location Information as defined in § 9.3.
(D) Route the caller to a call center.
The rules in this subpart F apply to:
(a) A person engaged in the business of manufacturing, importing, selling, or leasing multi-line telephone systems;
(b) A person engaged in the business of installing, managing, or operating multi-line telephone systems;
(c) Any multi-line telephone system that is manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020.
(a) Obligation of manufacturers, importers, sellers, and lessors. (1) A person engaged in the business of manufacturing, importing, selling, or leasing multi-line telephone systems may not manufacture or import for use in the United States, or sell or lease or offer to sell or lease in the United States, a multi-line telephone system, unless such system is pre-configured such that, when properly installed in accordance with paragraph (b) of this section, a user may directly initiate a call to 911 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9, regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls.
(2) A person engaged in the business of manufacturing, importing, selling, or leasing multi-line telephone systems may not manufacture or import for use in the United States, or sell or lease or offer to sell or lease in the United States, a multi-line telephone system, unless such system has the capability, after proper installation in accordance with paragraph (b) of this section, of providing the dispatchable location of the caller to the PSAP with 911 calls.
(b) Obligation of installers, managers, or operators. (1) A person engaged in the business of installing, managing, or operating multi-line telephone systems may not install, manage, or operate for use in the United States such a system, unless such system is configured such that a user may directly initiate a call to 911 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9, regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls.
(2) A person engaged in the business of installing, managing, or operating multi-line telephone systems shall, in installing, managing, or operating such a system for use in the United States, configure the system to provide MLTS notification to a central location at the facility where the system is installed or to another person or organization regardless of location, if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system. MLTS notification must meet the following requirements:
(i) MLTS notification must be initiated contemporaneously with the 911 call, provided that it is technically feasible to do so;
(ii) MLTS notification must not delay the call to 911; and
(iii) MLTS notification must be sent to a location where someone is likely to see or hear it.
(3) A person engaged in the business of installing multi-line telephone systems may not install such a system in the United States unless it is configured such that it is capable of being programmed with and conveying the dispatchable location of the caller to the PSAP with 911 calls consistent with paragraphs (i), (ii) and (iii) of this section. A person engaged in the business of managing or operating multi-line telephone systems may not manage or operate such a system in the United States unless it is configured such that the dispatchable location of the caller is conveyed to the PSAP with 911 calls consistent with paragraphs (i), (ii) and (iii) of this section.
(i) Dispatchable location requirements for on-premises fixed telephones associated with a multi-line telephone system. An on-premises fixed telephone associated with a multi-line telephone system shall provide automated dispatchable location no later than January 6, 2021;
(ii) Dispatchable location requirements for on-premises non-fixed devices associated with a multi-line telephone system. No later than January 6, 2022, an on-premises non-fixed device associated with a multi-line telephone system shall provide to the appropriate PSAP automated dispatchable location, when technically feasible; otherwise, it shall provide dispatchable location based on end user manual update, or alternative location information as defined in § 9.3.
(iii) Dispatchable location requirements for off-premises devices associated with a multi-line telephone system. No later than January 6, 2022, an off-premises device associated with a multi-line telephone system shall provide to the appropriate PSAP automatic dispatchable location, if technically feasible; otherwise, it shall provide dispatchable location based on end user manual update, or enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost.
(a) Enforcement. (1) Sections 9.16(a)(1) and (b)(1) and (2) shall be enforced under title V of the Communications Act of 1934, as amended, 47 U.S.C. 501 et seq., except that section 501 applies only to the extent that such section provides for the punishment of a fine.
(2) In the event of noncompliance with § 9.16(b), the person engaged in the business of managing the multi-line telephone system shall be presumed to be responsible for the noncompliance.
(3) Persons alleging a violation of the rules in § 9.16 may file a complaint under the procedures set forth in §§ 1.711 through 1.737 of this chapter.
(b) Compliance date. The compliance date for this subpart F is February 16, 2020, unless otherwise noted. Accordingly, the requirements in this subpart apply to a multi-line telephone system that is manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020, unless otherwise noted.
(c) Effect on State law. Nothing in § 9.16(a)(1) and (b)(1) and (2) is intended to alter the authority of State commissions or other State or local agencies with jurisdiction over emergency communications, if the exercise of such authority is not inconsistent with this subpart.
(a) Providers of Mobile-Satellite Service to end-user customers (47 CFR part 25, subparts A through D) must provide Emergency Call Center service to the extent that they offer real-time, two way switched voice service that is interconnected with the public switched network and use an in-network switching facility which enables the provider to reuse frequencies and/or accomplish seamless hand-offs of subscriber calls. Emergency Call Center personnel must determine the emergency caller's phone number and location and then transfer or otherwise redirect the call to an appropriate public safety answering point. Providers of Mobile-Satellite Services that use earth terminals that are not capable of use while in motion are exempt from providing Emergency Call Center service for such terminals.
(b) Each Mobile-Satellite Service carrier that is subject to the provisions of paragraph (a) of this section must maintain records of all 911 calls received at its emergency call center. By October 15, of each year, Mobile-Satellite Service carriers providing service in the 1.6/2.4 GHz and 2 GHz bands must submit a report to the Commission regarding their call center data, current as of September 30 of that year. By June 30, of each year, Mobile-Satellite Service carriers providing service in bands other than 1.6/2.4 GHz and 2 GHz must submit a report to the Commission regarding their call center data, current as of May 31 of that year. These reports must include, at a minimum, the following:
(1) The name and address of the carrier, the address of the carrier's emergency call center, and emergency call center contact information;
(2) The aggregate number of calls received by the call center each month during the relevant reporting period;
(3) An indication of how many calls received by the call center each month during the relevant reporting period required forwarding to a public safety answering point and how many did not require forwarding to a public safety answering point.
(a) Definitions. Terms in this section shall have the following meanings:
(1) 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.
(ii) Has adequate internal controls to bring material information regarding network architecture, operations, and maintenance to the certifying official's attention.
(iii) Has made the certifying official aware of all material information reasonably necessary to complete the certification.
(iv) The term “certification” shall include both an annual reliability certification under paragraph (c) of this section and an initial reliability certification under paragraph (d)(1) of this section, to the extent provided under paragraph (d)(1).
(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:
(A) Provides 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; and/or
(B) Operates 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.
(ii) The term “covered 911 service provider” shall not include any entity that:
(A) Constitutes a PSAP or governmental authority to the extent that it provides 911 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 PSAP.
(5) Critical 911 circuits. 911 facilities that originate at a selective router or its functional equivalent and terminate in the central office that serves the PSAP(s) to which the selective router or its functional equivalent delivers 911 calls, including all equipment in the serving central office necessary for the delivery of 911 calls to the PSAP(s). Critical 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).
(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 critical 911 circuits 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 equivalent data 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 to fail. Circuits 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.
(9) 911 service area. The metropolitan area or geographic region in which a covered 911 service provider operates a selective router or the functional equivalent to route 911 calls to the geographically appropriate PSAP.
(10) Selective router. A 911 network component that selects the appropriate destination PSAP for each 911 call based on the location of the caller.
(11) Tagging. An inventory management process whereby critical 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 circuits so long as it tracks whether critical 911 circuits are physically diverse and identifies changes that would compromise such diversity.
(b) Provision of reliable 911 service. All covered 911 service providers shall take reasonable measures to provide reliable 911 service with respect to circuit diversity, central-office backup power, and diverse network monitoring. Performance of the elements of the certification set forth in paragraphs (c)(1)(i), (c)(2)(i), and (c)(3)(i) of this section shall be deemed to satisfy the requirements of this paragraph. 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 based upon a showing in accordance with paragraph (c) of this section 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) On October 15 of each year, a certifying official of every covered 911 service provider shall submit a certification to the Commission as follows.
(1) Circuit auditing. (i) A covered 911 service provider shall certify whether it has, within the past year:
(A) Conducted diversity audits of critical 911 circuits or equivalent data paths to any PSAP served;
(B) Tagged such critical 911 circuits to reduce the probability of inadvertent loss of diversity in the period between audits; and
(C) Eliminated all single points of failure in critical 911 circuits or equivalent data paths serving each PSAP.
(ii) If a Covered 911 Service Provider does not conform with all of the elements in paragraph (c)(1)(i) of this section with respect to the 911 service provided to one or more PSAPs, it must certify with respect to each such PSAP:
(A) Whether it has taken alternative measures to mitigate the risk of critical 911 circuits that are not physically diverse or is taking steps to remediate any issues that it has identified with respect to 911 service to the PSAP, in which case it shall provide a brief explanation of such alternative measures or such remediation steps, the date by which it anticipates such remediation will be completed, and why it believes those measures are reasonably sufficient to mitigate such risk; or
(B) Whether it believes that one or more of the requirements of this paragraph are not applicable to its network, in which case it shall provide a brief explanation of why it believes any such requirement does not apply.
(2) Backup power. (i) With respect to any central office it operates that directly serves a PSAP, a covered 911 service provider shall certify whether it:
(A) Provisions backup power through fixed generators, portable generators, batteries, fuel cells, or a combination of these or other such sources to maintain full-service functionality, including network monitoring capabilities, for at least 24 hours at full office load or, if the central office hosts a selective router, at least 72 hours at full office load; provided, however, that any such portable generators shall be readily available within the time it takes the batteries to drain, notwithstanding potential demand for such generators elsewhere in the service provider's network.
(B) Tests and maintains all backup power equipment in such central offices in accordance with the manufacturer's specifications;
(C) Designs backup generators in such central offices for fully automatic operation and for ease of manual operation, when required;
(D) Designs, installs, and maintains each generator in any central office that is served by more than one backup generator as a stand-alone unit that does not depend on the operation of another generator for proper functioning.
(ii) If a covered 911 service provider does not conform with all of the elements in paragraph (c)(2)(i) of this section, it must certify with respect to each such central office:
(A) Whether it has taken alternative measures to mitigate the risk of a loss of service in that office due to a loss of power or is taking steps to remediate any issues that it has identified with respect to backup power in that office, in which case it shall provide a brief explanation of such alternative measures or such remediation steps, the date by which it anticipates such remediation will be completed, and why it believes those measures are reasonably sufficient to mitigate such risk; or
(B) Whether it believes that one or more of the requirements of this paragraph are not applicable to its network, in which case it shall provide a brief explanation of why it believes any such requirement does not apply.
(3) Network monitoring. (i) A covered 911 service provider shall certify whether it has, within the past year:
(A) Conducted diversity audits of the aggregation points that it uses to gather network monitoring data in each 911 service area;
(B) Conducted diversity audits of monitoring links between aggregation points and NOCs for each 911 service area in which it operates; and
(C) Implemented physically diverse aggregation points for network monitoring data in each 911 service area and physically diverse monitoring links from such aggregation points to at least one NOC.
(ii) If a Covered 911 Service Provider does not conform with all of the elements in paragraph (c)(3)(i) of this section, it must certify with respect to each such 911 Service Area:
(A) Whether it has taken alternative measures to mitigate the risk of network monitoring facilities that are not physically diverse or is taking steps to remediate any issues that it has identified with respect to diverse network monitoring in that 911 service area, in which case it shall provide a brief explanation of such alternative measures or such remediation steps, the date by which it anticipates such remediation will be completed, and why it believes those measures are reasonably sufficient to mitigate such risk; or
(B) Whether it believes that one or more of the requirements of this paragraph are not applicable to its network, in which case it shall provide a brief explanation of why it believes any such requirement does not apply.
(d) Other matters —(1) [Reserved]
(2) Confidential treatment. (i) The fact of filing or not filing an annual reliability certification or initial reliability certification and the responses on the face of such certification forms shall not be treated as confidential.
(ii) Information submitted with or in addition to such certifications shall be presumed confidential to the extent that it consists of descriptions and documentation of alternative measures to mitigate the risks of nonconformance with certification elements, information detailing specific corrective actions taken with respect to certification elements, or supplemental information requested by the Commission or Bureau with respect to a certification.
(3) Record retention. A covered 911 service provider shall retain records supporting the responses in a certification for two years from the date of such certification, 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 a certification hereunder shall be maintained and supplied in an electronic format.
(i) With respect to diversity audits of critical 911 circuits, such records shall include, at a minimum, audit records separately addressing each such circuit, any internal report(s) generated as a result of such audits, records of actions taken pursuant to the audit results, and records regarding any alternative measures taken to mitigate the risk of critical 911 circuits that are not physically diverse.
(ii) With respect to backup power at central offices, such records shall include, at a minimum, records regarding the nature and extent of backup power at each central office that directly serves a PSAP, testing and maintenance records for backup power equipment in each such central office, and records regarding any alternative measures taken to mitigate the risk of insufficient backup power.
(iii) With respect to network monitoring, such records shall include, at a minimum, records of diversity audits of monitoring links, any internal report(s) generated as a result of such audits, records of actions taken pursuant to the audit results, and records regarding any alternative measures taken to mitigate the risk of aggregation points and/or monitoring links that are not physically diverse.
(4) Covered 911 service providers that cease operations must notify the FCC by filing a notification under penalty of perjury no later than 60 days after the cessation of service.
The rules in this subpart apply to States or taxing jurisdictions that collect 911 fees or charges (as defined in this subpart) from commercial mobile services, IP-enabled voice services, and other emergency communications services.
For purposes of this subpart, the terms in this section have the following meanings set forth in this section. Furthermore, where the Commission uses the term “acceptable” in this subpart, it is for purposes of the Consolidated Appropriations Act, 2021, Public Law 116-260, Division FF, Title IX, section 902(c)(1)(C).
911 fee or charge. A fee or charge applicable to commercial mobile services, IP-enabled voice services, or other emergency communications services specifically designated by a State or taxing jurisdiction for the support or implementation of 911 services. A 911 fee or charge shall also include a fee or charge designated for the support of public safety, emergency services, or similar purposes if the purposes or allowable uses of such fee or charge include the support or implementation of 911 services.
Diversion. The obligation or expenditure of a 911 fee or charge for a purpose or function other than the purposes and functions designated by the Commission as acceptable pursuant to § 9.23. Diversion also includes distribution of 911 fees to a political subdivision that obligates or expends such fees for a purpose or function other than those designated as acceptable by the Commission pursuant to § 9.23.
Other emergency communications services. The provision of emergency information to a public safety answering point via wire or radio communications, and may include 911 and E911 service.
State. Any of the several States, the District of Columbia, or any territory or possession of the United States.
State or taxing jurisdiction. A State, political subdivision thereof, Indian Tribe, or village or regional corporation serving a region established pursuant to the Alaska Native Claims Settlement Act (43 U.S.C. 1601 et seq. ).
(a) Acceptable purposes and functions for the obligation or expenditure of 911 fees or charges for purposes of section 902 are limited to:
(1) Support and implementation of 911 services provided by or in the State or taxing jurisdiction imposing the fee or charge; and
(2) Operational expenses of public safety answering points within such State or taxing jurisdiction.
(b) Examples of acceptable purposes and functions include, but are not limited to, the following, provided that the State or taxing jurisdiction can adequately document that it has obligated or spent the fees or charges in question for these purposes and functions:
(1) PSAP operating costs, including lease, purchase, maintenance, replacement, and upgrade of customer premises equipment (CPE) (hardware and software), computer aided dispatch (CAD) equipment (hardware and software), and the PSAP building/facility and including NG911, cybersecurity, pre-arrival instructions, and emergency notification systems (ENS). PSAP operating costs include technological innovation that supports 911;
(2) PSAP personnel costs, including telecommunicators' salaries and training;
(3) PSAP administration, including costs for administration of 911 services and travel expenses associated with the provision of 911 services;
(4) Integrating public safety/first responder dispatch and 911 systems, including lease, purchase, maintenance, and upgrade of CAD hardware and software to support integrated 911 and public safety dispatch operations; and
(5) Providing for the interoperability of 911 systems with one another and with public safety/first responder radio systems.
(c) Examples of purposes and functions that are not acceptable for the obligation or expenditure of 911 fees or charges for purposes of section 902 include, but are not limited to, the following:
(1) Transfer of 911 fees into a State or other jurisdiction's general fund or other fund for non-911 purposes;
(2) Equipment or infrastructure for constructing or expanding non-public safety communications networks ( e.g., commercial cellular networks); and
(3) Equipment or infrastructure for law enforcement, firefighters, and other public safety/first responder entities that does not directly support providing 911 services.
(d) If a State or taxing jurisdiction collects fees or charges designated for “public safety,” “emergency services,” or similar purposes that include the support or implementation of 911 services, the obligation or expenditure of such fees or charges shall not constitute diversion provided that the State or taxing jurisdiction:
(1) Specifies the amount or percentage of such fees or charges that is dedicated to 911 services;
(2) Ensures that the 911 portion of such fees or charges is segregated and not commingled with any other funds; and
(3) Obligates or expends the 911 portion of such fees or charges for acceptable purposes and functions as defined under this section.
(a) A State or taxing jurisdiction may petition the Commission for a determination that an obligation or expenditure of 911 fees or charges for a purpose or function other than the purposes or functions designated as acceptable in § 9.23 should be treated as an acceptable purpose or function. Such a petition must meet the requirements applicable to a petition for declaratory ruling under § 1.2 of this chapter.
(b) The Commission shall grant the petition if the State or taxing jurisdiction provides sufficient documentation to demonstrate that the purpose or function:
(1) Supports public safety answering point functions or operations; or
(2) Has a direct impact on the ability of a public safety answering point to:
(i) Receive or respond to 911 calls; or
(ii) Dispatch emergency responders.
(a) If a State or taxing jurisdiction receives a grant under section 158 of the National Telecommunications and Information Administration Organization Act (47 U.S.C. 942) after December 27, 2020, such State or taxing jurisdiction shall provide the information requested by the Commission to prepare the report required under section 6(f)(2) of the Wireless Communications and Public Safety Act of 1999, as amended (47 U.S.C. 615a-1(f)(2)).
(b) Each State or taxing jurisdiction subject to paragraph (a) of this section must file the information requested by the Commission and in the form specified by the Public Safety and Homeland Security Bureau.
Notwithstanding any other provision of law, any State or taxing jurisdiction identified by the Commission in the report required under section 6(f)(2) of the Wireless Communications and Public Safety Act of 1999, as amended (47 U.S.C. 615a-1(f)(2)), as engaging in diversion of 911 fees or charges shall be ineligible to participate or send a representative to serve on any advisory committee established by the Commission.
(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.
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)).
(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.
(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.
(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.
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.
(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.
(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.
Cite this law
911 REQUIREMENTS (U.S.C.). Retrieved via LawPlayer, https://lawplayer.com/us/act/cfr-title-47-part-9
United States government works (U.S. Code, Code of Federal Regulations) are in the public domain under 17 U.S.C. § 105.
本頁資料來源：GPO govinfo / eCFR·整理提供：法律人 LawPlayer· lawplayer.com