Implementing Kari's Law and RAY BAUM'S Act; Inquiry Concerning 911 Access, Routing, and Location in Enterprise Communications Systems; Amending the Definition of Interconnected VoIP Service, 66716-66779 [2019-20137]

Agencies

• FEDERAL COMMUNICATIONS COMMISSION

[Federal Register Volume 84, Number 234 (Thursday, December 5, 2019)]
[Rules and Regulations]
[Pages 66716-66779]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2019-20137]



[[Page 66715]]

Vol. 84

Thursday,

No. 234

December 5, 2019

Part II





Federal Communications Commission





-----------------------------------------------------------------------





47 CFR Parts 1, 9, 12, et al.





Implementing Kari's Law and RAY BAUM'S Act; Inquiry Concerning 911 
Access, Routing, and Location in Enterprise Communications Systems; 
Amending the Definition of Interconnected VoIP Service; Final Rule

Federal Register / Vol. 84 , No. 234 / Thursday, December 5, 2019 / 
Rules and Regulations

[[Page 66716]]


-----------------------------------------------------------------------

FEDERAL COMMUNICATIONS COMMISSION

47 CFR Parts 1, 9, 12, 20, 22, 25, and 64

[PS Docket Nos. 18-261, 17-239; GN Docket No. 11-117; FCC 19-76]


Implementing Kari's Law and RAY BAUM'S Act; Inquiry Concerning 
911 Access, Routing, and Location in Enterprise Communications Systems; 
Amending the Definition of Interconnected VoIP Service

AGENCY: Federal Communications Commission.

ACTION: Final rule.

-----------------------------------------------------------------------

SUMMARY: In this document, the Federal Communications Commission (the 
FCC or Commission) adopts rules for 911 calls made from multi-line 
telephone systems (MLTS), pursuant to Kari's Law, the conveyance of 
dispatchable location with 911 calls, as directed by RAY BAUM'S Act, 
and the consolidation of the Commission's 911 rules. The President 
recently signed into law two statutes designed to improve emergency 
calling: Kari's Law applies to MLTS, which are telephone systems that 
serve consumers in environments such as office buildings, campuses, and 
hotels. Kari's Law requires MLTS systems in the United States to enable 
users to dial 911 directly, without having to dial a prefix to reach an 
outside line, and to provide for notification (e.g., to a front desk or 
security office) when a 911 call is made; RAY BAUM'S Act requires the 
Commission to conduct a rulemaking proceeding to consider adopting 
rules to ensure that ``dispatchable location'' is conveyed with 911 
calls, regardless of the technological platform used, so that 911 call 
centers will receive the caller's location automatically and can 
dispatch responders more quickly. ``Dispatchable location'' is defined 
as ``the street address of the calling party, and additional 
information such as room number, floor number, or similar information 
necessary to adequately identify the location of the calling party.'' 
The Commission adopts rules to implement Kari's Law and initiates the 
rulemaking on dispatchable location required by RAY BAUM'S Act. The 
Commission also consolidates the Commission's existing 911 rules into a 
single rule part.

DATES: 
    Effective date: January 6, 2020.
    Compliance date: Compliance will not be required for Sec. Sec.  
9.8(a); 9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4); 
9.11(b)(5)(ii); (iii); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v); 
9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); and 
9.16(b)(3)(i), (ii), and (iii) until the Commission publishes a 
document in the Federal Register announcing the compliance date.

ADDRESSES: The complete text of this document is available for 
inspection and copying during normal business hours in the FCC 
Reference Information Center, Portals II, 445 12th Street SW, Room CY-
A257, Washington, DC 20554.

FOR FURTHER INFORMATION CONTACT: For further information, contact 
Brenda Boykin, Attorney-Advisor, Policy and Licensing Division, Public 
Safety and Homeland Security Bureau, (202) 418-2062 or via email at 
[email protected]; William Beckwith, Attorney-Advisor, Policy and 
Licensing Division, Public Safety and Homeland Security Bureau, (202) 
418-0134 or via email at [email protected]; Thomas Eng, 
Engineer, Policy and Licensing Division, Public Safety and Homeland 
Security Bureau, (202) 418-0019 or via email at [email protected]; Dr. 
Rasoul Safavian, Technologist, Policy and Licensing Division, Public 
Safety and Homeland Security Bureau, (202) 418-0754 or via email at 
[email protected].

SUPPLEMENTARY INFORMATION: This is a summary of the Commission's Report 
and Order, FCC 19-76, adopted on August 1, 2019 and released on August 
2, 2019. To request materials in accessible formats for people with 
disabilities (Braille, large print, electronic files, audio format), 
send an email to [email protected] or call the Consumer & Governmental 
Affairs Bureau at (202) 418-0530 (voice), (202) 418-0432 (TTY). The 
complete text of the order also is available on the Commission's 
website at https://www.fcc.gov.

Synopsis

I. Introduction

    1. In this Report and Order, we adopt measures to help ensure that 
members of the public can successfully dial 911 to request emergency 
services and that Public Safety Answering Points (PSAPs) can quickly 
and accurately locate every 911 caller, regardless of the type of 
service that is used to make the call. We act today pursuant to two 
federal statutes: Kari's Law Act of 2017, which requires implementation 
of direct 911 dialing and on-site notification capabilities in multi-
line telephone systems (MLTS), and section 506 of RAY BAUM'S Act, which 
requires the Commission to ``consider adopting rules to ensure that the 
dispatchable location is conveyed with a 9-1-1 call, regardless of the 
technological platform used and including with calls from [MLTS].''
    2. In particular, we adopt rules that implement the direct dialing 
and notification requirements of Kari's Law and clarify the law's 
application to both legacy MLTS and Internet Protocol (IP)-based 
systems, including cloud-based services, that support the 
communications needs of hotels, businesses, campuses, and other 
enterprises. And we adopt rules that will facilitate timely emergency 
response and improved location accuracy across communications 
platforms. These requirements are measured, technically feasible, and 
technologically neutral, so that providers can choose the most 
effective solutions from a range of options. In addition, our 
requirements allow sufficient time for advance planning and deployment 
of new location technology. Similar to the approach the Commission has 
taken in the wireless E911 context, we believe that ``[c]lear and 
measurable timelines and benchmarks for all stakeholders are essential 
to drive the improvements that the public reasonably expects to see in 
911 location performance.'' We also take this opportunity to 
consolidate our existing 911 rules, as well as the direct dialing and 
dispatchable location rules adopted today, into a single rule part.

II. Background

    3. Enhanced 911 (E911) was developed to provide PSAPs with the 
caller's location and a call-back number as part of each 911 call. 
Since its implementation, most E911 calls have conveyed information 
regarding the caller's location (with varying degrees of accuracy) and 
a call-back number to the PSAP. These enhancements have significantly 
improved PSAPs' ability to effectively deliver critical public safety 
and emergency response services in a timely manner. In many instances, 
E911 has proven to be a life-saving, essential emergency response tool 
for providing critical information when the caller is unable to 
verbally communicate his or her location, including when the voice call 
is dropped or discontinued and cannot be reestablished.
    4. Under the Commission's rules, consumers generally have access to 
these capabilities when they make fixed telephony, mobile, and 
interconnected VoIP calls to 911. However, to date, the Commission's 
E911 rules have not applied to MLTS. Consequently, consumers in 
environments such as office buildings, campuses, and hotels may not 
have the same access to E911 services that is provided by fixed 
telephony, mobile, and VoIP systems,

[[Page 66717]]

namely direct dialing access to 911 and the provision of the MLTS 
user's location information.
    5. MLTS include a widely embedded base of legacy private branch 
exchange (PBX), Centrex, and Key Telephone systems, IP-based systems, 
and hybrid systems. MLTS serve millions of employees, residents, and 
guests of businesses and educational facilities, including corporate 
parks, hotels, college campuses, and planned community developments. 
These systems can support anywhere from ten to thousands of telephone 
station/numbers. Emergency calls from MLTS stations generally only 
provide PSAPs the telephone or circuit number of the system's outgoing 
trunk, and not the emergency caller's individual station number. In 
some cases, the MLTS station that placed the call will not even have 
its own telephone number. As a result, PSAPs often find they are unable 
to locate an MLTS emergency call to the station from which it 
originated. The Commission in 2003 considered E911 requirements for 
MLTS but deferred to the states to address this issue, while preserving 
the option of acting should states fail to do so.
    6. At least 23 states have enacted legislation that requires 
organizations over a certain size or purchasing a new PBX/MLTS system 
to implement E911 on the system. These states have adopted varied 
requirements for MLTS providers, and only in some instances have state 
laws specifically addressed prefix dialing requirements. In the absence 
of federal or consistent state regulation, some MLTS in operation today 
do not support direct 911 dialing, may not have the capability to route 
calls to the appropriate PSAP relative to the caller's location, or may 
not provide accurate information regarding the caller's location. The 
Commission has observed that these issues have persisted, even as many 
enterprises are increasingly relying on IP-based systems, including 
cloud-based services, to support their communications needs.
    7. Given that the ongoing evolution of MLTS has not eliminated 
these shortfalls when serving 911 callers, the Commission has 
periodically sought to examine MLTS provision of 911, including the 
capabilities of MLTS to support direct 911 access, routing, callback, 
and automatic location. In September 2017, the Commission released a 
Notice of Inquiry (Enterprise Communications NOI) seeking information 
on the capabilities of enterprise communications systems to support 
direct 911 access, routing, and automatic location. The Commission 
noted that such systems may not provide consumers with the same access 
to E911 services as other wireline, wireless, and interconnected VoIP 
calls and asked whether it is still the case, as the Commission found 
in earlier proceedings, that the needs and circumstances of residential 
and business enterprise communications system users are suited to 
state-level action rather than federal regulation. The Enterprise 
Communications NOI also sought information on the state of the 
enterprise communications system industry; the costs and benefits of 
supporting E911 for enterprise communications system; the capability of 
enterprise communications system to provide accessible emergency 
communications for persons with disabilities; and options for ensuring 
that enterprise communications system keep pace with technological 
developments and consumer expectations for access to 911.
    8. Kari's Law was enacted on February 16, 2018. Kari's Law 
establishes a federal multi-tiered approach to MLTS 911 requirements. 
First, Kari's Law applies to any ``person engaged in the business of 
manufacturing, importing, selling, or leasing'' MLTS. Such persons 
``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 [MLTS], 
unless such system is pre-configured such that, when properly installed 
. . . a user may directly initiate a call to 9-1-1 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.''
    9. Second, Kari's Law applies to any ``person engaged in the 
business of installing, managing, or operating'' MLTS. Such persons 
``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 9-1-1 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.''
    10. Third, such persons ``shall, in installing, managing, or 
operating such a system for use in the United States, configure the 
system to provide a 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.''
    11. Fourth, Kari's Law expressly provides that Congress did not 
intend 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 [Act].'' 
Kari's Law directs the Commission to enforce the provisions under Title 
V of the Communications Act of 1934, as amended, ``except that section 
501 applies only to the extent that such section provides for the 
punishment of a fine.'' The effective date provision states that Kari's 
Law ``shall apply with respect 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.
    12. On March 23, 2018, shortly after Kari's Law was enacted, the 
President signed the Consolidated Appropriations Act of 2018, including 
RAY BAUM'S Act, into law. Section 506 of RAY BAUM'S Act requires the 
Commission to ``conclude a proceeding to consider adopting rules to 
ensure that the dispatchable location is conveyed with a 9-1-1 call, 
regardless of the technological platform used and including with calls 
from multi-line telephone systems'' by September 23, 2019. In 
conducting this proceeding, ``the Commission may consider information 
and conclusions from other Commission proceedings regarding the 
accuracy of the dispatchable location for a 9-1-1 call, but nothing in 
this section shall be construed to require the Commission to reconsider 
any information or conclusion from a proceeding regarding the accuracy 
of the dispatchable location for a 9-1-1 call in which the Commission 
has adopted rules or issued an order'' before the March 23, 2018 
enactment date of section 506.
    13. In September 2018, following the enactment of Kari's Law and 
RAY BAUM'S Act, the Commission proposed rules to implement Kari's Law 
and to support dispatchable location for 911 calls from MLTS and other 
communications platforms. Specifically, the NPRM proposed to implement 
Kari's Law by adopting direct dial and notification rules governing 
calls to 911 made from MLTS and clarifying the definitions associated 
with the law. As required by RAY BAUM'S Act, the Commission also 
initiated this proceeding to consider the feasibility of requiring 
dispatchable location for 911 calls from MLTS and other technological 
platforms. The

[[Page 66718]]

Commission proposed dispatchable location requirements for MLTS 911 
calls, which would apply contemporaneously with the February 16, 2020 
compliance date of Kari's Law, and proposed to add dispatchable 
location requirements to our existing 911 rules for fixed telephony 
providers, interconnected Voice over IP (VoIP) providers, and internet-
based Telecommunications Relay Services (TRS). The NPRM also considered 
the feasibility of alternative location mechanisms for MLTS and other 
services that could be used as a complement to dispatchable location or 
as a substitute when dispatchable location is not available. 
Additionally, the Commission sought comment on whether dispatchable 
location requirements should be extended to other communications 
services that are not covered by existing 911 rules but are capable of 
making a 911 call. Finally, the NPRM proposed to consolidate the 
Commission's existing 911 rules into a single rule part.

III. Discussion

A. Direct Dialing and Notification for MLTS

    14. Because Congress incorporated Kari's Law into the 
Communications Act of 1934, as amended (the Act), the Commission has 
authority to prescribe such rules and regulations as are necessary to 
carry out Kari's Law. The implementing regulations we adopt in this 
Report and Order are intended to provide additional clarity and 
specificity regarding the terms used in the statute and the obligations 
placed on covered entities.
1. Direct Dialing
    15. Kari's Law provides that any person engaged in the business of 
manufacturing, importing, selling, or leasing an MLTS may not 
manufacture or import the MLTS for use in the United States, or sell or 
lease or offer to sell or lease it in the United States, unless it is 
pre-configured so that when properly installed, a user may directly 
initiate a call to 911 from any station equipped with dialing 
facilities. In addition, any person engaged in the business of 
installing, managing, or operating an MLTS may not do so unless the 
MLTS is configured so that a user may dial 911 directly. In the NPRM, 
the Commission proposed rules that track these obligations.
    16. We adopt the rules requiring direct dialing from MLTS generally 
as proposed in the NPRM. There is broad support among all types of 
commenters (industry and public safety entities) for the proposed 
direct dialing rules, although some commenters seek clarification of 
proposed definitions and other terms. The Texas 9-1-1 Entities state 
that the proposed rules ``should generally be adopted as written.'' 
Microsoft asserts that proposed direct dialing and notification 
requirements are consistent with Kari's Law and should be reasonably 
achievable. No commenter opposes adoption of the direct dialing 
requirements.
2. Notification
    17. Kari's Law provides that any person engaged in the business of 
installing, managing, or operating an MLTS shall, in installing, 
managing, or operating such a system for use in the United States, 
configure the system to provide a 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. Consistent with this obligation, 
the Commission in the NPRM proposed rules providing that installers, 
managers, or operators must configure an MLTS to provide for 
transmission of a 911 notification if the system can be configured to 
do so without an improvement to the hardware or software of the system. 
The Commission stated that notification will potentially benefit three 
parties: (1) The 911 caller by speeding response time; (2) enterprise 
management and staff by providing needed information and reducing 
confusion and delay when emergency response teams arrive; and (3) first 
responders by reducing time spent responding to such calls.
a. Required Information and Purpose
    18. Kari's Law requires an MLTS to support notification when an end 
user makes a 911 call, but it does not specify what information must be 
provided in the notification. In the NPRM, the Commission proposed to 
define ``MLTS Notification'' as follows: ``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 screen pops 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.''
    19. The Commission tentatively concluded that for notification to 
be capable of achieving the purpose of Kari's Law, it should include 
basic information that will assist the enterprise and first responders 
in coordinating and expediting on-site response to the emergency. The 
Commission also stated its intention for notification to include only 
information that is also conveyed to the PSAP with the initial call to 
911, including the same dispatchable location information that the PSAP 
receives. Because notification is intended to help the enterprise 
assist first responders, the Commission noted, it makes sense for the 
recipient of the notification to have the same information as the PSAP 
(and, indirectly, the first responders dispatched to the scene). In 
addition, requiring the notification to convey only information that 
already exists for the 911 call would minimize the burden for 
enterprises to comply.
    20. We adopt the proposal from the NPRM with certain changes. As 
proposed, we find that the notification should include the fact that a 
911 call has been made, a valid callback number, and the same location 
information that is conveyed with the call to 911. However, we provide 
an exception for callback number and location information in 
circumstances where including this information in the notification 
would be technically infeasible. We also clarify that the callback 
number in the notification does not have to be a Direct Inward Dialing 
number to the 911 caller's extension if one is not available.
    21. Several commenters express support for the Commission's 
proposed notification requirements. APCO supports the Commission's 
proposal provided that notification does not delay the call to 
emergency responders. Verizon states that the Commission's proposed 
notification rule is straightforward and consistent with the statute's 
focus and notes that the technical details of how the capability is 
implemented will vary among enterprise customers based on their size, 
resources, and the particular network configuration involved.
    22. We agree with commenters who contend that certain minimum 
content is necessary to ensure that notification serves the purpose 
intended for it, which is to help the enterprise provide assistance to 
first responders in the event of a 911 call. For example, NASNA states 
that the Commission ``absolutely'' should establish minimum content for 
the notification and that it

[[Page 66719]]

should ``require that what is sent to PSAPs be sent also to the 
notification center.'' RedSky asserts that the notification should also 
include the date and time of the 911 call. Avaya suggests that 
notification should include ``details that may not be conveyed to the 
PSAP,'' such as ``location information that clearly establishes the 
location of the caller'' and alerts with acknowledgement and escalation 
functions.
    23. At the same time, we seek to provide enterprises sufficient 
flexibility to tailor the notification to best suit their needs. In 
this respect, we note that some commenters urge the Commission to allow 
enterprises to determine the content of notifications as they see fit. 
Panasonic, for example, states that businesses should have the 
flexibility to customize notifications to meet their needs, given their 
understanding of the physical nature of their enterprise, the technical 
capabilities of their system, and the personnel who will be involved in 
assisting with an emergency response, including on-site private 
emergency response teams in some cases.
    24. In the absence of direction in the statutory language about 
what the required notification should contain, we are also mindful of 
Congress's stated intent to ``balance the need for an onsite 
notification with the goal of not placing an undue burden on MLTS 
owners or operators.'' Reflecting this flexible approach, we define 
MLTS Notification as: ``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.''
    25. Commenters raise concerns regarding the inclusion of a callback 
number and location information in the notification. Cisco, Panasonic, 
and TIA note that Kari's Law does not specifically require a callback 
number or location information in the notification. Cisco states that 
the callback number and location information conveyed in a notification 
can vary based on the technology deployed in the enterprise, so the 
Commission should ensure that this rule provides MLTS managers 
sufficient flexibility to determine the contents of the notification. 
Several commenters note that providing a callback number that reaches 
the 911 caller's specific phone is not possible in some enterprises 
because there is no Direct Inward Dialing phone number associated with 
the MLTS endpoints. Some commenters also point out that providing the 
caller's location in the notification may not be necessary or helpful 
in the case of enterprises that are small or have an open workspace.
    26. We therefore provide an exception for callback number and 
location information in circumstances where including this information 
in the notification would not be technically feasible. We agree with 
commenters who assert that there may be MLTS solutions for which it is 
not technically feasible to include this information in the 
notification. For example, commenters point out that providing a 
callback number that reaches the 911 caller's specific phone is not 
possible in some enterprises because there is no phone number 
associated with the MLTS endpoints. Accordingly, we clarify that the 
callback number, if provided, need not be a Direct Inward Dialing 
number to the 911 caller's extension if a Direct Inward Dialing number 
is not available. This means, for example, that if the 911 call comes 
from a non-Direct Inward Dialing number, the callback number in the 
notification can be an internal extension that can be directly reached 
from inside the enterprise but not from outside it. Similarly, a hotel 
that does not provide a Direct Inward Dialing line to each guest room 
can provide the number of a central location, such as the front desk, 
in the notification. Notwithstanding that each of these MLTS 
notification examples would include callback number information in lieu 
of a Direct Inward Dialing number to the 911 caller, we reiterate that 
omission of callback number information in the notification is 
acceptable if it is technically infeasible to provide such 
information.\1\
---------------------------------------------------------------------------

    \1\ Likewise, the omission of the caller's location information 
in the MLTS notification is acceptable if it is technically 
infeasible to provide such information.
---------------------------------------------------------------------------

    27. We also adopt BRETSA's suggestion to replace the term ``screen 
pops'' from the NPRM with ``conspicuous on-screen messages,'' which we 
find to be clearer. And we reject BRETSA's suggestion that the 
Commission revise the beginning of the definition of MLTS Notification 
to read, ``[a]n MLTS feature that can send notice that a call has been 
placed to `9-1-1' from an MLTS station, to a central location at the 
facility where the system is installed or to another person.'' We 
decline to add this language because we believe the reference to the 
required content of the notification later in the definition makes 
clear that notification includes the fact that a call to 911 has been 
made.
    28. Because our requirements set a minimum, enterprises may add 
other information to the notification as useful and appropriate. This 
may include, for example, the occupancy status of a hotel room, or the 
specific location of an IP device. Enterprises are free to include such 
information in the notification as they see fit, so long as the 
notification includes the required elements. Although the additional 
information Avaya proposes for the content of the notification may be 
helpful for some enterprises, we do not believe it would be appropriate 
for all enterprises, particularly smaller businesses. We also do not 
have a sufficient record to determine whether to adopt date and time of 
the 911 call as required elements of the notification, as RedSky 
suggests, although we encourage enterprises to include this information 
at their discretion. We also encourage the development of voluntary 
best practices and employee training to prepare enterprises for 
responding to receipt of notification that a 911 call has been made. 
For instance, training could include the circumstances under which the 
notice recipient (or someone else at the enterprise) should dial the 
callback number included with the notification.
    29. Finally, BRETSA asserts that PSAPs and first responders should 
determine the notification and location information provided by the 
enterprise, with a process for state and local public safety 
authorities to waive the Commission's MLTS rules where reasonable and 
appropriate. We decline to find that state and local public safety 
agencies have authority to waive the Commission's rules, as BRETSA 
requests. Requests for such waivers should, as with other Commission 
requirements, be presented to the Commission.
b. Notification Timing
    30. Kari's Law is silent on when the notification must be provided. 
The Commission proposed to require that MLTS covered by Kari's Law be

[[Page 66720]]

configured so that notification is contemporaneous with the 911 call 
and does not delay the placement of the call to 911. Most commenters 
that address this issue support the Commission's proposal.
    31. We adopt the timing requirement as proposed but clarify that 
initiation of the notification must be contemporaneous with the call to 
911. As RedSky points out, notification can occur in many forms, 
including SMS text messages, email, screen display, and conference 
calls, and the delivery of text messages and email is not within the 
control of the MLTS provider or the MLTS user. Accordingly, RedSky asks 
the Commission to clarify that initiation of the notification must be 
contemporaneous with connection of the emergency caller to the PSAP. We 
concur. The record shows the importance of timely notification. 
According to NENA, ``[n]otification contemporaneous with the 9-1-1 call 
has significantly greater value to all parties than after-the-fact 
notification, and the majority of a notification's benefits to response 
are lost if the notification is not conveyed in real-time.''
    32. We also note Ad Hoc's concern that some enterprise owner/
operators of MLTS currently report challenges in configuring MLTS 
equipment to provide contemporaneous notification in addition to 
placing the call to 911 emergency services. As a result, Ad Hoc states, 
the Commission should condition its proposal for the timing of 
notification on what is ``technically feasible.'' We condition this 
requirement on the technical feasibility of providing contemporaneous 
notification, as Ad Hoc requests.
c. Notification Destination Points
    33. The Commission also sought comment in the NPRM on whether there 
should be any requirements relating to the location, configuration, or 
staffing of notification destination points. Kari's Law states that the 
notification may be provided either to a ``central location at the 
facility where the system is installed'' or to ``another person or 
organization regardless of location.'' The Commission noted that this 
language indicates Congress's recognition that in the enterprise 
settings where MLTS are typically used, providing someone other than 
the PSAP with notice of the call can be critical to helping first 
responders gain timely access. At the same time, the language 
``regardless of location,'' as illuminated by legislative history, 
indicates that Congress sought to provide MLTS installers, managers, 
and operators with broad flexibility in selecting destination points to 
achieve this goal. For example, the notification could be directed to 
an on-site security desk that controls access to the premises, to an 
enterprise employee who may or may not be located at the facility where 
the MLTS is installed, or to a third party that provides security or 
safety services from an off-site location. MLTS notification could also 
be configured to combine these approaches, e.g., by having 
notifications during business hours go to a central on-site location 
and off-hours notifications go to an off-site person or organization.
    34. The Commission sought comment on whether it should specify 
criteria for destination points to ensure that notifications are likely 
to be received by someone able to take appropriate action to facilitate 
or assist the 911 response. Where on-site notification to a ``central 
location'' is provided, the Commission asked whether it should specify 
that the destination point must be a location that is normally staffed 
or, alternatively, a location where on-site staff are likely to hear or 
see the notification. The Commission noted that this approach would 
afford flexibility to direct the on-site notification to a security 
guard or facilities manager, to personnel who are otherwise employed 
and can support monitoring notifications as part of existing duties, or 
to an on-site location where staff are normally present.
    35. We adopt a requirement that notifications be sent to a location 
on-site or off-site where someone is likely to hear or see the 
notification. Some commenters urge the Commission to establish criteria 
for notification destination points, while others urge the Commission 
to preserve flexibility for the enterprise. In this respect, we note 
NASNA's assertion that notification ``absolutely'' should be to a 
location that is normally staffed or where staff are likely to hear or 
see the notification and that ``[t]o do otherwise would undermine the 
purpose of the notification requirement.'' We agree with NASNA that the 
Commission should set some criteria for notification destination points 
to help ensure that they serve the purpose of Kari's Law.
    36. The requirement we adopt preserves flexibility for the 
enterprise to select an appropriate destination point. For instance, we 
recognize AHLA's suggestion that ``[h]ow an individual hotel determines 
to send a notification (via text message, a separate call or email), to 
whom the notification is sent, and where the recipient is at the time 
of receipt should be at the discretion of the hotel. For example, a 
hotel with a single on-duty employee overnight should not be required 
to send notification to a desk that may not be manned; a text message 
to the employee's mobile device might be more appropriate.'' Our 
requirement would allow a hotel such as the one described by AHLA to 
send a text message to the overnight employee's mobile device.\2\
---------------------------------------------------------------------------

    \2\ The definition of MLTS notification we adopt does not 
specify any particular form for the notification and states that 
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.''
---------------------------------------------------------------------------

    37. In addition, we do not require that the notification point be 
continuously staffed or monitored, only that it be a location where 
someone is likely to see or hear the notification. The legislative 
history of Kari's Law provides that the statute ``seeks to balance the 
need for an onsite notification with the goal of not placing an undue 
burden on MLTS owners or operators.'' Consistent with this, the 
Commission in the NPRM stated that it did not believe Congress intended 
to impose staffing or monitoring requirements that would generate 
unreasonable costs, such as the need to hire additional staff, or limit 
the flexibility of MLTS installers, managers, and operators to develop 
cost-effective notification solutions to meet their particular needs. 
Based on the record before us, we adopt a requirement with which we 
intend to strike an appropriate balance between the increased benefits 
from having notifications sent to a location where they are likely to 
be received (e.g., increased chances of assistance for first 
responders) and the increased costs that are likely to result if we 
were to adopt a less flexible approach (e.g., increased staffing 
costs).
    38. In the NPRM, the Commission also asked whether, in the case of 
off-site notification, it should require that notification be to a 
person or organization that is authorized to provide first responders 
with access to the location from which the MLTS 911 call originated. 
The Commission noted that this would allow notification to be directed 
to any offsite location, as the statute clearly allows, while 
furthering the statute's objective of facilitating access to first 
responders answering a 911 call.
    39. We agree with Ad Hoc that requiring such notification may not 
make sense in all situations, such as where the enterprise does not 
control access to the premises or where access to the premises is 
unrestricted. We nonetheless encourage enterprises using the off-site 
notification option to choose someone who can assist first responders 
in gaining access to the facility if it is

[[Page 66721]]

feasible to do. As suggested by NENA's comments, it is a best practice 
for notification to go to whomever ``has the keys'' if a campus or 
building has restricted access and to whomever has any specialized 
knowledge of the facility layout that may assist public safety in 
locating and responding to a 911 call. And we encourage the development 
of voluntary best practices and training for enterprise personnel, 
including designated notice recipients, so that they are prepared to 
assist first responders in the event of an emergency call.
d. No Exemptions to Notification Requirement
    40. In the NPRM, the Commission noted that large enterprises such 
as hotels, hospitals, and schools frequently have on-site personnel 
that control access to the premises, and notification of 911 calls to 
such personnel can improve outcomes by enabling them to assist first 
responders in accessing the premises and reaching the caller's 
location. The Commission sought comment on applying the statute's 
notification requirements to all MLTS operators, including small 
enterprises, and sought comment on whether the benefits and costs of 
notification apply differently to small businesses than large 
enterprises such as hotels, hospitals, and schools. Small businesses 
are less likely to have personnel controlling access, and first 
responders may not need the same level of assistance to reach a 911 
caller. The Commission also asked whether small enterprises using MLTS 
may find benefits to notification in addition to access and support, 
such as the ability for the enterprise to intervene when 911 is dialed 
in error and avoid sending emergency responders to a location that does 
not require a response.
    41. Commenters are divided on whether the Commission should provide 
a small business exemption for the notification requirements of Kari's 
Law. NASNA states that the benefits of notification are the same for a 
small business as for a large one and that small businesses should know 
that a 911 call was made from their MLTS so they are not surprised when 
first responders arrive and can assist if needed, including canceling 
the response if it turns out that 911 was dialed in error. Other 
commenters support a small business exemption, although their specific 
proposals for an exemption differ. RedSky, for example, argues that not 
every enterprise using an MLTS should be required to have emergency 
call notification, ``let alone staff to receive a notification,'' and 
that there are many circumstances where there is no one to consume the 
data and react. Proposed criteria for defining an exemption generally 
include limits on square footage or the number of lines used at a 
single location. In turn, RingCentral and VON urge the Commission to 
limit the notification requirement to on-site calls and not to require 
notification for 911 calls from distributed workforces, i.e., those 
spread out over a large geographic region and relying on MLTS to 
centralize communications.
    42. We decline to adopt a small business exemption because we agree 
with NASNA that small businesses should receive notice of 911 calls 
that have been made from their MLTS so that they can prepare for the 
arrival of first responders and assist if needed. We also decline to 
provide an exception to the location information requirement for 
enterprises that are small or have an open workspace, as some 
commenters suggest. We believe location information will be helpful 
even at a small business because it will confirm the caller's location 
for the notice recipient, who may be at an offsite location. In 
addition, the burden of providing this information should be minimal. 
We note that Kari's Law does not provide an exemption for small 
businesses--nor one for MLTS operators that are not always staffed. In 
addition, the requirements we adopt for notification are highly 
flexible and give small businesses significant latitude to configure 
suitable notification mechanisms without unreasonable burden or cost.
    43. We also disagree with RingCentral and VON that notification as 
a rule is unlikely to be helpful at remote or satellite locations 
served by an MLTS. Rather, we agree with BRETSA that limiting 
application of the rules to only specific types of MLTS would distort 
the market by favoring newer technologies, notwithstanding that callers 
to 911 are no less impacted by failures of MLTS using those 
technologies to provide notification (and interior location 
information) than MLTS using other technologies. Indeed, we disagree 
with arguments that whenever an MLTS is used off-site, notification is 
not useful. Although RingCentral states that it has many customers that 
provide centralized phone numbers and extensions for a workforce that 
is working from home, the road, remote offices, or a mix of these 
locations, the fact that a ``centralized location may be miles or 
states away from the emergency and have no special knowledge of the 
location where the emergency arose'' is irrelevant--Congress recognized 
that notifications have value ``regardless of location,'' and it is not 
hard to recognize that having a centralized notification system could 
aid these multi-homed workers in reaching emergency services. 
Similarly, we disagree with VON that ``a 911 call placed by a person 
working from a satellite office would trigger a notification to someone 
at the central office, who would not be able to aid first responders 
when they arrive at the satellite office or otherwise speed first 
responder response time,'' because someone at a staffed central office 
may nonetheless aid remote first responders by, for example, alerting 
other personnel at the location of the emergency. Although there may be 
corner cases in which notification is not in fact helpful, we decline 
on this record to exempt any particular category of MLTS facilities 
from the notification requirements as a matter of policy (not to 
mention that Kari's Law itself draws no such lines).
3. Definitions
a. Definition of Multi-Line Telephone System
    44. Kari's Law and RAY BAUM'S Act define the term ``multi-line 
telephone system'' by cross-referencing the definition in the Middle 
Class Tax Relief and Job Creation Act of 2012. That Act, in turn, 
defines an MLTS as:

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.

    45. In the NPRM, the Commission proposed to interpret this 
definition to include ``the full range of networked communications 
systems that serve enterprises, including circuit-switched and IP-based 
enterprise systems, as well as cloud-based IP technology and over-the-
top applications.''
    46. The Commission also proposed in the NPRM to interpret the 
definition of MLTS to include enterprise-based systems that allow 
outbound calls to 911 without providing a way for the PSAP to place a 
return call (outbound-only calling service). The Commission stated that 
it believed requiring direct dialing for any MLTS that allows the user 
to call 911, regardless of whether the system also allows the PSAP to 
make a return call, would advance the purpose of Kari's Law. In 
addition, the Commission stated, there is nothing in the language of 
the definition of MLTS

[[Page 66722]]

from the Middle Class Tax Relief and Job Creation Act of 2012 that 
excludes systems allowing only outbound calls to 911.
    47. The record is divided over the Commission's proposed definition 
of MLTS. Some commenters support the proposal, while others oppose the 
Commission's proposed interpretation. Commenters, however, generally 
support the Commission's proposed interpretation of the definition of 
MLTS to include outbound-only calling services, citing consumer 
expectations and the need for regulatory parity among services.
    48. As proposed in the NPRM, and consistent with the statutory 
definition, we interpret the definition of MLTS to include the full 
range of networked communications systems that serve enterprises, 
including circuit-switched and IP-based enterprise systems, as well as 
cloud-based IP technology and over-the-top applications. West Safety 
endorses this approach and states that the statutory definition of MLTS 
is sufficiently broad to encompass the full range of enterprise 
communications systems, including ``legacy TDM MLTS, hybrid MLTS and IP 
MLTS systems and software,'' as well as ``any and all endpoints 
supported by MLTS including mobile and smart devices, softphone 
clients, over-the-top (OTT) applications and outbound-only calling 
services.'' RedSky similarly states that the term MLTS ``should not be 
limited to any specific type of end point device'' because the 
technology is constantly evolving. We agree.
    49. TIA and VON, however, oppose the Commission's proposed 
interpretation. TIA asserts that if Congress had intended its 
definition to capture ``the full range'' of all technologies in the 
enterprise communications marketplace, including over-the-top 
applications, it could have done so in the definition. Instead, TIA 
asserts, ``the definition refers by name to numerous traditional MLTS 
technologies and points to Part 68 of the FCC's rules--regulations 
established decades ago to govern interconnection with the PSTN [public 
switched telephone network] for traditional telephony services.'' TIA 
adds that ``[t]he Commission is right to think about the modern 
enterprise communications market which has certainly expanded beyond 
traditional locally-hosted PBX systems, but it should not expand the 
scope of Kari's Law as intended by Congress.'' VON states that as 
proposed, the term could cover any business with more than one line 
using a cloud PBX and could therefore essentially turn any 
interconnected VoIP service into MLTS (or vice versa), contrary to the 
plain intent of Kari's Law. VON adds that this point becomes clearer 
when compared with RAY BAUM'S Act, which directs the Commission to 
``consider adopting rules to ensure that the dispatchable location is 
conveyed with a 9-1-1 call, regardless of the technological platform 
used and including with calls from [MLTS].'' In contrast, VON states, 
Kari's Law does not discuss other technological platforms, and as a 
result, ``the NPRM's proposed interpretation of MLTS goes farther than 
the law allows, and should be limited to those systems provided for in 
47 U.S.C. 1471.'' Cisco and Panasonic note that the statutory 
definition of MLTS does not refer to the terms ``cloud-based IP 
technology'' and ``over-the-top applications'' and state that it is not 
clear Congress envisioned such a broad interpretation of the term.
    50. We disagree with these commenters. In particular, we note that 
the statutory definition also refers to VoIP, which is a newer 
technology, and introduces the reference to VoIP with the term ``such 
as.'' The statute thus cites VoIP (and other technologies) as examples 
but not as limitations on the definition. If Congress had intended a 
more constrained view of the technologies that fall within the 
definition of MLTS, it would have stated that MLTS ``consists of'' or 
is ``limited to'' certain technologies. In addition, the statutory 
language refers broadly to a ``system comprised of common control 
units, . . . control hardware and software and adjunct systems, 
including network and premises-based systems.'' We find that this 
language broadly includes cloud-based IP technology and over-the-top 
applications. Further, there is no language in the statute specifically 
excluding cloud-based IP technology and over-the-top applications from 
the definition of MLTS.
    51. We also believe interpreting the definition of MLTS broadly is 
consistent with the intent of Kari's Law. The enterprise market has 
already seen significant migration away from traditional MLTS and 
toward IP-based and cloud-based systems, and Kari's Law applies only to 
systems that are manufactured or brought into use after February 16, 
2020. It is unlikely that Congress would seek to address the problems 
of direct dialing and notification for MLTS only with respect to 
traditional, non-IP-based MLTS technologies, which represent a 
declining share of the MLTS market. With respect to VON's assertion 
that the reference to other ``technological platform[s]'' in RAY BAUM'S 
Act shows that the definition of MLTS should be interpreted narrowly 
under Kari's Law, we disagree. We interpret the reference to 
technological platforms in RAY BAUM'S Act as a direction for the 
Commission to include other services, such as interconnected VoIP, TRS, 
and fixed telephony, in its consideration of dispatchable location 
rules. We do not interpret it as a limitation, explicit or implied, on 
the meaning of MLTS under Kari's Law.
    52. We also interpret the definition of MLTS to include outbound-
only calling systems.\3\ The statutory definition of MLTS is broad 
enough to cover outbound-only calling services and does not expressly 
exclude such services. Commenters generally support interpreting the 
definition to include outbound-only services, and no commenter 
expressly opposes this interpretation. Avaya, for example, states that 
MLTS at a minimum should include any system capable of making an 
outbound call. BRETSA asserts that 911 calls are outbound calls, and it 
is counterintuitive that they cannot be made over outbound-only calling 
systems. AT&T urges the Commission to ensure that the MLTS rules 
maintain regulatory parity between new implementations of business VoIP 
services and traditional MLTS business solutions and states that one-
way VoIP solutions should be required to support 911, as end users will 
expect their calling solutions to have this functionality and may rely 
on it in an emergency. Verizon states that applying Kari's Law 
requirements to MLTS that allow outbound-only 911 dialing is likely 
feasible, but that the scope of such requirements should focus on user 
expectations. Verizon suggests that the rules should protect users of 
outbound-only calling systems who are not employed by the enterprise or 
who are otherwise unfamiliar with the system and use it for outbound-
only dialing. On the other hand, Verizon states, if the outbound-only 
system has a defined and restricted user group that is uniformly 
familiar with and trained in the enterprise's calling practices, and 
911 is the only outbound number that users can dial, the direct dialing 
capability may be less critical. Verizon also states that requiring 
direct dialing capability for outbound-only MLTS services ``may give 
enterprises incentive to not enable any 911 dialing at all (which has 
its own public safety implications).''
---------------------------------------------------------------------------

    \3\ We clarify that our rules are not intended to prohibit 
configuring MLTS to allow outbound-only calling. Rather, we 
interpret the definition of MLTS to include outbound-only calling 
systems.

---------------------------------------------------------------------------

[[Page 66723]]

    53. We find that Congress's intent in enacting Kari's Law was to 
require direct dialing for any MLTS phone that allows the user to call 
911, regardless of whether the system also allows the PSAP to connect a 
return call directly to the 911 caller. We agree with the Texas 9-1-1 
Entities that Kari's Law and the ``utterly tragic circumstances'' 
behind its enactment demonstrate that ``it is simply unreasonable to 
expect 9-1-1 callers to know or remember when they are required to do 
something differently during a 9-1-1 call based on their particular 
device or location.'' Moreover, as BRETSA states, calling 911 is 
inherently an outbound service. As a result, it is counter-intuitive to 
expect consumers to assume that they cannot reach 911 from such 
services.
    54. We decline to adopt Verizon's suggestion that we narrow the 
requirements for outbound-only MLTS service to apply solely on the 
basis of user expectations. Rather, we believe Congress intended for 
direct 911 dialing and notification to be available for all outbound-
only MLTS services. Similarly, public safety commenters such as the 
Texas 9-1-1 Entities and BRETSA point out that 911 callers in an 
emergency should not have to slow down and analyze whether 911 is 
available from a particular device, especially when they may not know 
the particular technology involved and may not have chosen it for 
themselves. Finally, although Verizon suggests that requiring direct 
dialing capability for outbound-only MLTS services may give enterprises 
incentive to not enable any 911 dialing at all, we do not believe this 
possibility, which is speculative, outweighs the benefits of ensuring 
that direct dialing is available with any MLTS phone that allows the 
caller to reach 911.
    55. Internal systems. Cisco asks the Commission to clarify that the 
definition of MLTS excludes systems that are ``used only for internal 
employee communications and . . . are not designed to interconnect with 
the PSTN,'' such as internal messaging and data and video conference 
capabilities that are ``increasingly displacing voice communications 
for employee collaboration.'' Cisco states that ``[w]here a technology 
is specifically deployed by an enterprise to support internal 
communications (i.e., it cannot support a call outside the enterprise), 
or where a tool is designed and used for conferencing services or other 
non-point-to-point communications, there can be no reasonable 
expectation on the part of employees that such internal or conferencing 
tools would be used to summon emergency services.'' BRETSA responds 
that limiting application of the rules to specific types of MLTS would 
distort the market and that Kari's Law and RAY BAUM'S Act do not 
support such a narrow reading of the definition of MLTS. Further, 
BRETSA states that exempting internal communications systems from the 
rules ``would appear to create a loophole such as to negate the 
statutes and rules'' because an MLTS in which a user must dial a number 
to access an outside line prior to placing a call to 911 would appear 
to be an internal communications system.
    56. We agree with Cisco that Kari's Law and the rules arising out 
of RAY BAUM'S Act were not intended to apply to purely internal 
communications systems that do not rely on telephone numbers under the 
North American Numbering Plan. We clarify that a technology that is 
specifically deployed by an enterprise to support only internal 
communications and that does not connect to the public switched 
telephone network would not fall within the definition of MLTS. In 
response to BRETSA's concerns, we conclude that this will not distort 
the market or negate the statute and rules because the clarification 
applies only to systems that do not connect to the public switched 
telephone network. If an internal communications system or conferencing 
service connects to the public switched telephone network either on its 
own or through a third party and can establish calls to the public 
switched telephone network, including by dialing a prefix such as 
``9,'' then it is within the definition of MLTS under our 
interpretation.
    57. System components. Panasonic, Cisco, and TIA also urge the 
Commission to clarify that individual system components such as 
telephone sets and control software do not qualify as an MLTS. 
Panasonic states that Congress's use of the language ``system comprised 
of'' various parts, ``e.g., common control units, telephone sets, 
control software and hardware and adjunct systems,'' dictates as a 
matter of logic that such individual parts are, in isolation, not MLTS 
themselves. To hold otherwise, Panasonic states, would be to ignore the 
plain meaning of the word ``comprised,'' effectively reading it out of 
the statute. Panasonic adds that it may be uniquely situated in that 
while the company offers a ``full-blown MLTS'' and is in that case an 
MLTS manufacturer, it also sells IP phones to other parties, who bundle 
Panasonic phones with other components that make up a full MLTS. To 
address this situation, Panasonic states, the Commission should clarify 
that sellers of individual MLTS components are not subject to the 
Commission's rules for MLTS. Cisco asserts that ``[a]s a matter of 
common sense, individual system components are not even capable of 
dialing 911 or reaching the PSTN unless and until they are assembled by 
an installer.''
    58. We agree that the definition of MLTS refers to a system and 
that individual components of such a system, including telephone sets, 
control software and hardware, and adjunct systems, do not by 
themselves constitute an MLTS. Consistent with this, we clarify that 
manufacturers, importers, sellers, or lessors of individual MLTS 
components are not subject to the Commission's MLTS rules to the extent 
that they manufacture, import, sell, or lease such components without 
the other components necessary for the system to function as an MLTS. 
In the scenario described by Panasonic, the entity that bundles the 
individual components into an MLTS would be the manufacturer and 
presumably also the seller or lessor of the MLTS and would have the 
obligations that fall on those parties under the statute and our 
rules.\4\ However, we do not agree with Cisco that the test for whether 
one or more components constitute an MLTS is whether they can be used 
to dial 911 or reach the PSTN, as that would exclude all systems that 
have been manufactured but not yet installed. Such a result would 
clearly be at odds with Kari's Law, which places obligations on 
``persons engaged in the business of manufacturing, importing, selling, 
or leasing'' an MLTS that apply before installation, operation, or 
management of the system.\5\
---------------------------------------------------------------------------

    \4\ To the extent individual components need certain 
functionality or pre-configuration to comply with Kari's Law, the 
bundler should require that in its contract with the manufacturer. 
The obligation to comply with the statute and our rules, however, 
would lie with the bundler.
    \5\ Specifically, such persons may not manufacture, import, 
sell, lease, or offer to sell or lease an MLTS unless the system is 
``pre-configured'' so that when properly installed, a user may 
directly initiate a call to 911 from any station equipped with 
dialing facilities.
---------------------------------------------------------------------------

b. Definition of Pre-Configured
    59. The Commission proposed in the NPRM to define the statutory 
term ``pre-configured'' to mean:

An MLTS that comes equipped with a default configuration or setting 
that enables users to dial 911 directly as required under the 
statute and rules, 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.


[[Page 66724]]


    60. The Commission stated that this would mean an MLTS may support 
additional dialing patterns but that manufacturers (and importers, 
sellers, or lessors) must ensure that the default, ``out-of-the-box'' 
configuration allows users to reach 911 directly.
    61. Although some commenters agree with the Commission's proposed 
definition of pre-configured, others ask the Commission to clarify the 
proposed definition to acknowledge the role of the enterprise customer 
and MLTS installer in providing the MLTS with connectivity to the PSTN.
    62. We find that the revisions proposed by Cisco and Microsoft are 
consistent with the statutory language and with the definition of 
``pre-configured'' that the Commission proposed in the NPRM, and that 
they assist in providing clarity. In particular, Cisco states that MLTS 
manufacturers today can design systems that are capable of supporting 
direct 911 dialing patterns and that are shipped with software that, 
upon installation and configuration of the MLTS with PSTN connectivity, 
can enable direct 911 dialing. However, MLTS solutions of this type 
have no capability ``out of the box'' to make or complete a PSTN call, 
including an emergency call.
    63. Cisco adds that in today's market, ``MLTS manufacturers 
predominantly offer enterprise solutions over distributed systems, 
where the actual call control component of the solution need not be, 
and often is not, resident in each enterprise location where MLTS-to-
PSTN calling takes place. PSTN connectivity, including the 911 dialing 
pattern, is therefore established by the installer at the direction of 
the enterprise, based on the unique attributes of its MLTS system, at 
the time PSTN connectivity is configured.'' Cisco urges the Commission 
to clarify that the pre-configuration requirement in the context of 
distributed systems can be satisfied when a vendor includes software to 
support a direct 911 dialing pattern, which is available to the 
installer at the time the MLTS is configured for PSTN calling. 
Specifically, Cisco proposes that the Commission ``slightly'' modify 
the definition of pre-configured to read, ``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.'' Microsoft similarly states 
that many, if not most, MLTS capabilities in today's marketplace are 
not available in a ``plug and play'' version and that the Commission 
should revise the definition of pre-configured so that it ``recognizes 
the responsibilities of the customer with respect to implementation and 
provision of the service.'' Microsoft recommends that the Commission 
revise the definition to read, `` `Pre-configured' means that the MLTS 
comes equipped with a default configuration or setting that enables 
users to dial 911 directly as required under the statute and rules, so 
long as the system is installed and operated properly or, where no 
default exists, such as when customer provisioning of the system is 
required, enables the customer to configure the system to dial 911 
directly as required under the statute and rules.''
    64. We agree with these commenters that not all MLTS are ``out of 
the box,'' plug-and-play solutions and that the definition of pre-
configured should recognize the role of the enterprise and installer 
with respect to implementation and provision of service. We believe 
that the proposed revisions suggested by Cisco and Microsoft are 
fundamentally consistent with each other, and we note that no commenter 
opposes these suggested revisions. In addition, Microsoft states that 
it supports either version of the definition. Accordingly, we revise 
the definition as requested by Cisco as follows:

    `Pre-configured' means 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.

c. Definition of Configured
    65. The Commission proposed in the NPRM to define the statutory 
term ``configured'' to mean:

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

    The Commission also asked whether the difference between its 
proposed definitions of ``pre-configured'' and ``configured'' was 
sufficiently clear.
    66. NASNA, Panasonic, and West Safety support the Commission's 
proposed definition of configured. BRETSA notes that the reference to 
``notification'' in the definition should be to ``MLTS notification,'' 
because that is the term as defined in the rules. BRETSA also proposes 
line edits to specify that configuring an MLTS for direct dialing means 
configuring it for ``direct dialing of 911 without a requirement of 
first dialing or entering an additional digit, code, prefix, or post-
fix, including any trunk-access code such as the digit 9.''
    67. We adopt the definition largely as proposed. We also agree with 
BRETSA that the reference to notification should be corrected to ``MLTS 
notification.'' \6\ But we decline to adopt BRETSA's other proposed 
line edits as unnecessary. The definition already requires 
configuration so that the MLTS is fully capable when installed of 
dialing 911 directly ``as required under the statute and rules,'' which 
includes dialing without a requirement of first dialing or entering an 
additional digit, code, prefix, or post-fix, including any trunk-access 
code such as the digit 9.\7\
---------------------------------------------------------------------------

    \6\ Consistent with this, we also change a reference in section 
9.16(b)(2) of the rules from configuring an MLTS to provide ``a 
notification'' to configuring it to provide ``MLTS notification.''
    \7\ RedSky states that the titles of the definitions of pre-
configure and configure are too broad and suggests changing them to 
``Pre-configured MLTS'' and ``MLTS Configurations,'' respectively. 
We decline to make these changes because we do not believe the 
existing titles will cause confusion. In addition, our definitions 
are intended to track the language used in Kari's Law as closely as 
possible, and the statute and our implementing rules do not use the 
terms ``pre-configured MLTS'' or ``configured MLTS.''
---------------------------------------------------------------------------

    68. The revised definition of ``configured'' reads as follows:

    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.

d. Definition of Improvement to the Hardware or Software of the System
    69. Under Kari's Law, the notification requirements of the statute 
apply only if the MLTS can be configured to provide notification 
``without an improvement to the hardware or software of the system.'' 
The Commission proposed in the NPRM to define the statutory term 
``improvement to the hardware or software of the system'' to mean:

    An improvement to the hardware or software of the MLTS, 
including upgrades to the core systems of the MLTS, as well as

[[Page 66725]]

substantial upgrades to the software and any software upgrades 
requiring a significant purchase.

    70. The Commission also noted that the proposed definition is 
consistent with the legislative history of Kari's Law, which provides 
that an improvement to the hardware or software of a system is intended 
to include upgrades to the core systems of an MLTS and substantial 
upgrades to the software, particularly those requiring a significant 
purchase. The Commission asked whether there are types of routine 
hardware or software changes that should be included in or excluded 
from the definition and whether it should clarify that (1) improvements 
to the hardware of the system do not include the provision of 
additional extensions or lines, and (2) improvements to the software of 
the system do not include minor software upgrades that are easily 
achieved or made to improve the security of the system. In addition, 
the Commission asked whether upgrades requiring a significant purchase 
should be determined based on total cost alone, or whether it should 
interpret significant to be a relative determination based on the size 
of the entity making the purchase.
    71. We adopt the definition of improvement to the hardware or 
software of the system as proposed. Under this definition, enterprises 
are not required to undertake ``upgrades to the core systems of an 
MLTS,'' ``substantial upgrades to the software,'' or ``any software 
upgrades that require a significant purchase'' in order to comply with 
the notification obligation.
    72. We find that this definition is necessary to implement Kari's 
Law, which makes clear that the notification requirements of the 
statute apply only if the MLTS can be configured to provide 
notification ``without an improvement to the hardware or software of 
the system.'' The definition we adopt also is consistent with the 
legislative history of Kari's Law, which states Congress's intention to 
balance the need for notification with the goal of ``not placing an 
undue burden on MLTS owners or operators.''
    73. While NCTA supports the Commission's approach to this 
definition, others express concerns. Although RedSky objects to the 
definition on the ground that the vast majority of deployed MLTS 
systems can meet the notification requirements without any modification 
of the core systems, NCTA points out that line-based MLTS cannot be 
upgraded to offer notification without upgrades to core systems that 
would present a ``daunting technological and financial challenge.'' In 
this respect, NCTA states that MLTS are provided to commercial 
customers in a variety of configurations involving both line-based and 
trunk-based products and that it is not aware of any line-based systems 
that currently have a notification capability.
    74. We also disagree with NASNA that any improvements to an 
existing MLTS, no matter how minor, should trigger the obligation to 
comply with Kari's Law and the implementing regulations. We conclude 
that such a policy would be inconsistent with the language of Kari's 
Law, which limits application of the statute to MLTS manufactured or 
brought into use after February 16, 2020. In addition, we clarify that 
(1) improvements to the hardware of the system do not include the 
provision of additional extensions or lines, and (2) improvements to 
the software of the system do not include minor software upgrades that 
are easily achieved or made to improve the security of the system.
    75. With respect to upgrades, Panasonic requests that we further 
clarify that substantial improvements to the software of the system do 
not include software updates for addressing bug fixes, security 
vulnerabilities, or the addition of ancillary features; that 
maintenance or reconfiguration of the system to support new users or 
extensions should not be considered a substantial upgrade; and that the 
cost of the upgrade or update or the size of the enterprise should not 
be a factor. RedSky asserts that the terms ``substantial'' and 
``significant'' are subjective and ``should be quantified to ease in 
both requirement and enforcement abilities.''
    76. We believe the factors cited by Panasonic may be relevant to 
determining whether a specific upgrade is substantial, but that such 
factors, if applicable, should be evaluated in light of the total facts 
and circumstances presented in the specific case. We also decline to 
quantify the terms ``substantial'' and ``significant'' as requested by 
RedSky, as the record does not provide sufficient basis for such 
quantification at this time. We expect that as Kari's Law is 
implemented, cases will arise that will enable us to provide further 
guidance on these issues. For now, we conclude that the guidance 
provided above is sufficient and consistent with the statutory language 
and legislative history of Kari's Law.
e. Definition of Person Engaged in the Business of Manufacturing, 
Importing, Selling, or Leasing an MLTS
    77. Kari's Law applies to any ``person engaged in the business of 
manufacturing, importing, selling, or leasing'' an MLTS and provides 
that such persons may not manufacture or import an MLTS for use in the 
United States, or sell or lease or offer to sell or lease an MLTS in 
the United States, unless the system is pre-configured so that, when 
properly installed, a user may directly initiate a call to 911 from any 
station equipped with dialing facilities. In the NPRM, the Commission 
tentatively concluded that the meaning of the term ``person engaged in 
the business of manufacturing, importing, selling, or leasing'' an MLTS 
is self-evident and did not propose to modify this definition or add it 
to the rules. The Commission sought comment whether any additional 
clarification of this term is necessary for implementation or 
enforcement of Kari's Law.
    78. As proposed in the NPRM, we conclude that the meaning of the 
term ``person engaged in the business of manufacturing, importing, 
selling, or leasing an MLTS'' is self-evident and that there is no need 
to adopt a definition for it. Cisco and Panasonic agree that the 
meaning of this term is self-evident, and no commenter opposes that 
view.
f. Definition of Person Engaged in the Business of Installing an MLTS
    79. Kari's Law also places obligations on any ``person engaged in 
the business of installing, managing, or operating'' an MLTS. Such 
persons may not install, manage, or operate the MLTS for use in the 
United States unless it is configured for direct dialing of 911. In 
addition, such persons shall, in installing, managing, or operating the 
MLTS, configure it to provide notification if the system is able to be 
configured to provide notification without an improvement to the 
hardware or software of the system. In the NPRM, the Commission 
proposed to define a person engaged in the business of installing an 
MLTS as:

    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

[[Page 66726]]

enterprise change. The MLTS installer may be the MLTS manager or a 
third party acting on behalf of the manager.

    80. The Commission sought comment on this proposed definition. 
While some commenters support the proposed definition, others ask the 
Commission to clarify it.
    81. We adopt the definition of ``person engaged in the business of 
installing an MLTS'' as proposed. We decline to revise the language of 
this definition as requested by some commenters because we conclude 
that such revisions are not warranted; however, we supply guidance on 
how to apply this definition given points raised by some commenters.
    82. In this regard, RingCentral notes that although the NPRM 
defines a ``person engaged in the business of installing an MLTS'' to 
include a person who ``configures the MLTS or performs other tasks 
involved in getting the system ready to operate,'' these functions are 
often part of providing cloud-based MLTS. Accordingly, RingCentral 
states, an over-broad definition of installation risks imposing duties 
(such as configuring notification) that should rest with the MLTS 
owner/operator as the entity best positioned to make deployment 
decisions for the enterprise. According to RingCentral, the Commission 
should address this by making clear that manufacturers and sellers are 
not installers simply by virtue of providing systems; ``rather, 
manufacturers and sellers become installers only when their customers 
specifically retain them for installation by, for example, purchasing 
installation or other professional services.'' In addition, RingCentral 
states that the Commission should recognize that installers are acting 
at the direction of owners and operators and should adjust the 
responsibility for implementation of those directions accordingly.
    83. We disagree with RingCentral that responsibility for 
configuring or other tasks that fall within the definition of 
installation should automatically rest with the owner/operator in some 
circumstances, and we believe that a manufacturer of a hosted MLTS that 
configures the system is serving in that respect as an installer. 
Similarly, we note that some manufacturers provide systems with self-
installing software. In that event, the manufacturer is also performing 
some of the functions of an installer. We agree, however, with 
RingCentral that if an entity performs the functions of an installer at 
the direction of the enterprise operator or manager, then the operator 
or manager in that scenario is also serving as the installer. 
Consistent with this approach, there may be multiple parties performing 
installation functions for a single MLTS. An enterprise manager or 
operator that directs aspects of the installation may, depending on the 
degree of its involvement, be responsible for complying with the 
installer's obligations. Evidence that the manufacturer has been 
retained specifically to install the system could be relevant in 
showing that the manufacturer is at least partly responsible for the 
obligations of an installer under Kari's Law and our rules, but the 
absence of such an agreement would not necessarily mean that the 
manufacturer has not performed any installation functions.
    84. Panasonic states that the definition of a ``person engaged in 
the business of installing an MLTS'' should be limited to initial 
installation and configuration of the system or substantial 
improvement, ``lest over-long potential liability risk the exit of 
skilled installers from the market.'' We decline to limit the 
definition to initial installation and configuration of the system, as 
Panasonic requests. Panasonic presents no data to support its 
conclusion that this would lead to the exit of skilled installers from 
the market.\8\
---------------------------------------------------------------------------

    \8\ Comcast asks the Commission to make clear that in instances 
where an MLTS provider installs a system that has been pre-
configured to be capable of transmitting direct-dialed 911 calls to 
the appropriate PSAP, the installer has fulfilled its 
responsibilities under Kari's Law and the implementing rules. We 
decline to make this clarification because we believe the definition 
of a person engaged in the business of installing an MLTS is 
sufficiently clear with respect to the obligations of an installer. 
In addition, we note that the installer's obligations may extend 
beyond installing a system that has been ``pre-configured'' for 
direct dialing of 911 and may include, for example, installing a 
system capable of providing MLTS notification.
---------------------------------------------------------------------------

g. Definition of Person Engaged in the Business of Managing an MLTS; 
Person Engaged in the Business of Operating an MLTS; Role of the 
Enterprise Owner
    85. The Commission proposed to define a person engaged in the 
business of managing an MLTS as:

    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.

The Commission proposed to interpret this definition to mean that a 
user of MLTS services that does not own or lease the MLTS or exercise 
any control over it would not be deemed to be engaged in the business 
of managing the MLTS. Under this interpretation, an enterprise that 
contracts with a third party to provide a total solution for MLTS, 
including acquiring the MLTS equipment, configuring the system, 
completing calls, and providing services such as maintenance and end 
user support, would not be deemed to be engaged in the business of 
managing the MLTS unless it exercised actual control over the system. 
The Commission also proposed to define a person engaged in the business 
of operating an MLTS as ``[a] person responsible for the day-to-day 
operations of the MLTS.'' The Commission sought comment on these 
proposed definitions.
    86. In addition, the Commission sought comment on whether there are 
circumstances in which the proposed definitions of MLTS ``manager'' or 
``operator'' should extend to enterprise owners. The Commission noted 
that commenters on the Enterprise Communications NOI emphasized that 
some enterprise owners purchase, operate, and maintain their own on-
premises telephone systems with PBX equipment, while other enterprise 
owners enter contractual arrangements with third-party providers of 
network and hosted services. The Commission stated that it did not 
believe Kari's Law was intended to extend liability to enterprise 
owners that purchase MLTS services but do not exercise control over the 
manner in which such services are configured or provided. Nevertheless, 
the Commission stated, there may be instances where enterprise owners 
purchase, operate, and maintain their own MLTS systems, or where they 
exercise active control over the configuration and provision of MLTS by 
third parties. The Commission sought comment on whether in such 
instances enterprise owners should be deemed to be MLTS managers or 
operators and what indicia of active control should be considered in 
making this determination.
    87. Commenters raise a number of issues with respect to the 
proposed definitions of MLTS operator and manager. NASNA and West 
Safety generally agree with the proposed definitions, while other 
commenters seek changes to the definitions or ask the Commission to 
clarify the role of the manager, operator, and enterprise owner.
    88. We clarify the allocation of responsibility among the 
installer, operator, manager, and enterprise owner in certain respects. 
With these clarifications, we do not believe any changes are needed in 
the wording of the definitions of person engaged in the business of 
managing an MLTS and

[[Page 66727]]

person engaged in the business of operating an MLTS. Accordingly, we 
adopt these definitions as proposed.
    89. We are persuaded by the arguments of BRETSA, NASNA, and RedSky 
that even a ``passive'' enterprise owner may perform some of the 
functions of an MLTS installer, manager, or operator under our rules 
and that the owner in that event should be responsible to the extent a 
violation of the statute or rules results from that conduct. NASNA 
states that an MLTS owner ``still has an obligation to hold its third-
party service provider(s) responsible for ensuring compliance.'' RedSky 
similarly asserts that the Commission should not exclude passive owners 
from the definition, stating that ``no MLTS user can be successful in a 
vacuum. They have to provide their operational requirements to the MLTS 
provider. These requirements can and must include direction to meet 
appropriate regulatory requirements. It is incumbent on the MLTS 
provider to ensure that the provided system or service is capable of 
meeting these requirements.'' \9\ BRETSA states that the rules should 
hold MLTS customers responsible for compliance to the extent the 
customer installs, maintains, operates and/or configures the MLTS.\10\
---------------------------------------------------------------------------

    \9\ RedSky also states that the term ``operator'' is not as 
pertinent as the term and concept of provider and that the 
Commission should introduce the terms ``MLTS provider'' and ``MLTS 
user'' to capture the actual business environment. In addition, 
RedSky suggests that the Commission replace the term ``person'' 
throughout the rules with the term ``person or entity.'' We decline 
to use ``MLTS provider'' and ``MLTS user'' because those terms are 
not used in Kari's Law, and our intent is for the rules to track the 
language of the statute whenever possible. We decline to substitute 
the term ``person or entity'' for the same reason; ``person'' is the 
term used in Kari's Law. We also note that Kari's Law was codified 
as part of Chapter 5 of the Act, and that Chapter 5 defines 
``person'' to include ``an individual, partnership, association, 
joint-stock company, trust, or corporation.''
    \10\ BRETSA also states that MLTS providers with superior 
knowledge of the rules will invariably include in their sales and 
service agreements indemnification provisions that will undermine 
the deterrent effect of penalties under the rules. To address this, 
BRETSA urges the Commission to prohibit MLTS providers from 
requiring customers to indemnify them against liability for rule 
violations. We decline to prohibit providers from requiring 
customers to indemnify them because we find that any conclusions 
about the effect of such agreements on compliance with Kari's Law 
and the implementing rules would be highly speculative at this time. 
BRETSA also interprets the ``person engaged in the business of'' 
language to exclude a person that is engaged in a business unrelated 
to the provision of configuration or operation of an MLTS but that 
purchases or leases an MLTS for its use, and BRETSA proposed 
revisions to bring such persons under the rules. We decline to adopt 
these proposed revisions because we believe it is clear that Kari's 
Law and the implementing rules apply to a person engaged in a 
business unrelated to the operation of an MLTS that purchases or 
leases an MLTS for its own use.
---------------------------------------------------------------------------

    90. We agree with these commenters that an enterprise owner has an 
obligation to hold third-party service providers responsible for 
complying with Kari's Law and our rules. We clarify, however, that a 
passive owner generally should not face liability if the owner 
contracts with a responsible third party and includes compliance 
requirements in its agreement with the service provider. We decline to 
find that a hotel is not an installer, manager, or operator of MLTS 
under the rules absent ``compelling evidence to the contrary,'' as AHLA 
requests. AHLA states that hotels typically do not perform the 
functions of an installer, manager, or operator. In that event, and 
provided that the hotel contracts with responsible third parties and 
includes compliance requirements in the agreements, the hotel should 
not face potential liability under the statute or our rules.
    91. Commenters also ask the Commission to clarify the allocation of 
responsibility for complying with Kari's Law and the regulations in the 
context of hosted, cloud-based MLTS service. AT&T asserts that any new 
MLTS rules should clearly delineate the roles and responsibilities of 
the various players in the MLTS ecosystem and that any single 
stakeholder may play multiple roles in the MLTS ecosystem depending on 
how an MLTS system is configured. ``For example, when AT&T offers a 
hosted MLTS solution to a business, AT&T should be responsible for 
compliance with the requirements applicable to those engaged in the 
installing, managing, or operating MLTS. However, where AT&T offers a 
Session Initiation Protocol . . . trunking solution to provide Public 
Switched Telephone Network . . . access for call delivery and the 
customer operates and manages the PBX, the customer should have 
responsibility for compliance. In both cases, the manufacturer should 
bear responsibility for ensuring its products are compliant.''
    92. We conclude that whether a party is a manager, operator, or 
installer should be based on the party's conduct and whether it has 
performed activities that fall within the definition in our rules. 
Consistent with this, we agree with AT&T that when it offers a hosted 
MLTS solution to a business, it is responsible for compliance with the 
requirements applicable to those engaged in installing, managing, or 
operating an MLTS to the extent that its hosting service includes those 
functions. On other hand, if AT&T offers a trunking solution that 
provides public switched telephone network access with the customer 
operating and managing the PBX, we agree that the customer should have 
responsibility for compliance as an operator and/or manager.
    93. RingCentral disagrees with AT&T's suggestion that hosted PBX 
providers would be installers and managers and urges the Commission to 
clarify that manufacturers and sellers are not installers or managers 
simply by virtue of providing systems. RingCentral asserts that 
``[p]roviders of hosted cloud-based PBX may simply provide the MLTS, 
without installation or implementation of the system after 
installation. . . . The definition of `manager' could . . . 
inadvertently include a cloud-based MLTS provider, as the definition 
includes a person who is involved in `implementation of the MLTS after 
installation.''' We note that a manufacturer or seller would be deemed 
an installer or manager only to the extent that it provides 
installation or management services with respect to the system. We 
offer these as illustrative examples for guidance on how the Commission 
would apply the rule. Any determination of a particular party's 
liability will necessarily require a fact-specific, case-by-case 
inquiry. The parties' contractual arrangements may be relevant in this 
determination, but they are not determinative, and an entity that 
performs the functions of a manager in violation of a contractual 
obligation not to do so could still be deemed a ``person engaged in the 
business of managing an MLTS.''
    94. Finally, we agree with commenters on the importance of the 
enterprise owner/MLTS customer's involvement in some situations. 
Commenters assert that the MLTS customer's involvement may be necessary 
for compliance, including updating end user location information and 
selecting an appropriate destination point for the 911 notification. As 
INCOMPAS and NCTA point out, the owner/customer in such situations is 
performing some of the functions of an MLTS operator or manager. 
Specifically, INCOMPAS states that in most circumstances, the customer 
or owner serves as the true operator of the system and exercises 
considerable control over MLTS service provided by INCOMPAS members. 
Once the system is installed and configured, the enterprise customer 
controls the amount of information that flows to managers and operators 
of these systems, including location information, and decides the 
responsibilities for the parties involved. Where enterprise customers 
have assumed primary operational roles with respect to the MLTS, 
INCOMPAS urges the Commission to ``be careful not to attach liability 
for violations of the rules to

[[Page 66728]]

providers that are only engaged in technical support or network 
oversight.'' NCTA asserts that some MLTS networks--typically those that 
use a customer-managed PBX--enable a customer to program or alter the 
calling pattern of a MLTS. In those instances, NCTA urges the 
Commission to assign sole responsibility for ensuring compliance with 
Kari's Law to the customer, who would be ``engaged in the business of 
managing an MLTS,'' rather than the voice service provider or equipment 
installer. Comcast also points out that an enterprise owner may choose 
to take on additional responsibilities with respect to the MLTS.
    95. To the extent a violation of the statute or rules results from 
failure of the enterprise owner/customer to perform these tasks 
properly, the owner/customer will be responsible for that violation. 
Consistent with this approach, we agree with NCTA and Comcast that if 
the enterprise customer controls the routing of calls, the enterprise's 
voice service provider has fulfilled its responsibilities under the 
statute and regulations if it ensures that its service will not 
interfere with the customer's ability to configure the MLTS to be 
capable of transmitting direct-dialed calls to 911.
    96. AT&T, RedSky, and USTelecom urge the Commission to clarify that 
the MLTS installer, manager, or operator need only offer the central 
notification capability to the customer to be in compliance with the 
law. AT&T states that some customers may not wish to have central 
notification if, for example, they have a small facility or they do not 
have staff to support monitoring notifications at all hours, and ``the 
MLTS provider should not be responsible for compelling the customer to 
utilize a capability that the customer has judged unnecessary.'' 
USTelecom states that an enterprise customer may choose not to 
designate or maintain a central notification point. We agree with these 
commenters that a manager, operator, or installer should not be liable 
if it performs its obligations in compliance with the statute and 
rules, but the enterprise customer declines to use the services 
offered.
4. Compliance Date and Transition Provisions
    97. The effective date provision of Kari's Law states that the 
statute ``shall apply with respect 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. In the NPRM, 
the Commission proposed that the compliance date for regulations 
implementing Kari's Law would be consistent with this date. 
Accordingly, the proposed direct dialing and notification requirements 
would apply to MLTS manufactured, imported, offered for first sale or 
lease, first sold or leased, or installed after February 16, 2020. The 
Commission sought comment on this proposed compliance date as well as 
on alternatives, and stated that commenters offering alternatives 
should explain how any date other than February 16, 2020, would be 
consistent with the statutory language.
    98. The Commission also sought comment on whether to adopt 
transitional rules to inform consumers of the 911 capabilities of 
legacy MLTS that are not subject to the direct dialing and notification 
requirements of Kari's Law. The Commission noted, for example, that the 
direct 911 dialing and notification statute enacted in Texas requires 
enterprises to place a sticker adjacent to or on non-compliant MLTS 
devices providing instructions on how to call 911, and that the 
Commission's interconnected VoIP E911 rules require service providers 
to distribute stickers or labels warning subscribers that E911 service 
may be limited. The Commission sought comment on whether to require 
MLTS installers, operators, and managers to notify callers how to dial 
911 from legacy systems, as well as options for doing so, associated 
costs, and potential sources of statutory authority for such 
requirements.
    99. Some commenters support the proposed compliance date of 
February 16, 2020. Other commenters support an earlier compliance date. 
The record also is divided on whether the Commission should adopt 
transition rules, such as disclosure requirements, for legacy MLTS.
    100. We adopt a compliance date of February 16, 2020, for the 
regulations implementing Kari's Law. This is supported by commenters 
such as West Safety, which asserts that the February 16, 2020, 
compliance date will afford market participants ``sufficient advanced 
notice to make informed manufacturing, planning, and purchasing 
decisions and will give enterprises the proper level of financial and 
operational flexibility to retain their existing, grandfathered MLTS 
until end-of-life.''
    101. We decline to adopt an earlier date because we find that the 
February 16, 2020, date is consistent with the plain language of Kari's 
Law, as well as with the intent of the statute. The statute applies 
prospectively as new MLTS are brought into use after February 16, 2020, 
or as existing systems are installed or first sold or leased after that 
date. This indicates that Congress intended to balance the benefits of 
requiring direct dialing before that date against the cost to 
enterprises of having to implement these requirements with respect to 
existing, legacy equipment currently in use. Commenters who urge the 
Commission to adopt an earlier date do not address how that would be 
consistent with the statutory language of Kari's Law.
    102. With respect to transition obligations, Ad Hoc asserts that 
the Commission has no statutory authorization to adopt transitional 
rules for grandfathered MLTS equipment. Further, Ad Hoc urges the 
Commission to refrain from ``impractical mandates'' for notification to 
end users, such as stickers on equipment, also deeming them 
``ineffective.'' AT&T similarly states that the Commission should not 
require warning labels for grandfathered MLTS because many of these 
systems have been in place for years, and requiring warning labels on 
each of them would be ``incredibly disruptive to customers.'' Panasonic 
states that the Commission should not impose specific employee 
notification requirements on MLTS installers, operators, and managers 
but should instead encourage ``voluntary, industry-led initiatives'' to 
do so. TIA urges the Commission to launch a public education campaign 
aimed at educating the public on the capabilities of legacy MLTS 
equipment and, as part of this program, to take steps to ensure that 
potential MLTS users are aware of their system's capabilities. NENA and 
NASNA, on the other hand, urge the Commission to adopt disclosure 
requirements for legacy MLTS. NENA asserts that it strongly supports 
some form of conspicuous notification on any MLTS handset not in 
compliance with the end-state Kari's Law implementation rules and that 
it has enumerated model requirements for such notification in its Model 
MLTS Legislation. NASNA states that the Commission should require MLTS 
owners to place a sticker near or on non-compliant MLTS devices ``to 
avoid situations such as the one that gave rise to Kari's Law in the 
first place.''
    103. We decline to require enterprises to notify end users of the 
911 capabilities and limitations of MLTS that are not subject to the 
statute and our rules. Such a requirement falls outside the scope of 
Kari's Law and this proceeding to implement it. And even if we were 
consider adopting such a requirement under other statutory authority, 
neither the NPRM nor the record comment has addressed how the

[[Page 66729]]

benefits weigh against the costs of imposing such a requirement. 
Instead, as Panasonic suggests, we encourage enterprises to disclose 
the limitations on dialing 911 from such MLTS as part of voluntary best 
practices.
    104. AT&T and NASNA also raise the issue of what level of upgrades 
to an existing MLTS would be significant enough to constitute 
manufacture, importation, sale, lease, or installation triggering 
compliance with Kari's Law when upgrades are made after February 16, 
2020. AT&T states that upgrades unrelated to core MLTS functions in 
legacy systems should not trigger the obligation to comply with Kari's 
Law and the implementing rules. NASNA urges the Commission to ensure 
that any improvements to MLTS hardware or software that an enterprise 
makes in the future provide direct dialing and notification 
capabilities, as well as the same dispatchable location information 
that would be received by a PSAP.
    105. On the basis of the record here, we decline to specify the 
level of improvements to an existing MLTS that would trigger compliance 
with the statute and regulations. We disagree with NASNA that any 
improvements to an existing MLTS, no matter how minor, should trigger 
the obligation to comply with Kari's Law and the implementing 
regulations. We conclude that such a policy would be inconsistent with 
the plain language of Kari's Law, which limits application of the 
statute to MLTS manufactured or brought into use after February 16, 
2020, and with our decisions about upgrades in the context of the 
discussion above regarding the definition of ``improvement to the 
hardware of software of the system.'' It is also unclear what would 
constitute core MLTS functions in this context and exploring this issue 
further and more broadly could add to the resources that will be 
required to comply with the requirements of Kari's Law and our 
implementing regulations. Thus, we believe it would be difficult to 
answer this question in the abstract and more appropriate for the 
Commission to address it in response to a specific fact pattern, should 
one arise. Parties may file a request for a declaratory ruling to 
eliminate uncertainty, and the Commission can resolve any uncertainty 
in the marketplace as warranted.
5. Enforcement
    106. Kari's Law empowers the Commission to enforce the statute 
under Title V of the Act, ``except that section 501 applies only to the 
extent that such section provides for the punishment of a fine.'' The 
Commission sought comment in the NPRM on how it should enforce and 
provide oversight of the requirements of Kari's Law. The Commission 
also noted that there can be great variation in the business 
relationships between MLTS installers, operators, and managers and 
sought comment on who, or which entities, should bear responsibility 
for violations of the proposed rules. In addition, the Commission 
proposed to apply a presumption that the MLTS manager bears ultimate 
responsibility for compliance with the rules implementing Kari's Law. 
As an example, the Commission stated that if an MLTS fails to comply 
with the rules, the MLTS manager would be presumed to be responsible 
for that failure, at least in part, unless the manager can rebut that 
presumption by demonstrating compliance with its obligations under the 
statute and rules. The Commission sought comment on this proposal. The 
Commission also asked how it should apportion liability in situations 
where multiple parties may be responsible for compliance with the 
statute and proposed rules, including whether there are situations in 
which parties should be held jointly responsible.
    107. As proposed, we adopt a rule that if an MLTS fails to comply 
with the rules, the MLTS manager is presumed to be responsible for that 
failure, at least in part, unless the manager can rebut the presumption 
by demonstrating compliance with its obligations under the statute and 
rules. Most commenters that address the issue support the proposal for 
a presumption that the MLTS manager bears ultimate responsibility for 
compliance with the rules implementing Kari's Law. INCOMPAS, for 
instance, states that it supports the presumption because where 
enterprise customers have assumed primary operational roles with 
respect to the MLTS, ``the Commission needs to be careful not to attach 
liability for violations of the rules to providers that are only 
engaged in technical support or network oversight.''
    108. Verizon, on the other hand, asserts that the Commission should 
not adopt the presumption because it would not reflect the variety of 
contractual arrangements that can allocate implementation and system 
maintenance duties among installers, operators, managers, and 
enterprise customers. Instead, Verizon asserts, the Commission should 
assess compliance ``based on how the contractual arrangements allocate 
the respective responsibilities.'' We disagree that the presumption 
would be inconsistent with such multi-party contractual arrangements. 
We intend to have a case-by-case determination of who is ``engaged in 
the business of managing'' the MLTS (including by looking at the 
parties' contracts) before imposing liability. The party or parties 
that managed the MLTS would then have the burden of going forward with 
evidence to show that they met their obligations under the statute and 
rules.
    109. We decline to adopt the proposals of RedSky and Avaya for 
apportioning liability in situations where multiple parties may be 
responsible for compliance. RedSky states that if the MLTS manufacturer 
does not provide a system that can meet the requirements, it should 
bear 100% of the responsibility; if the MLTS manufacturer provides a 
system that can meet the requirements and the operator chooses not to 
offer the required services, the operator should bear 100% of the 
responsibility; and if the manufacturer and the operator offer to meet 
the required services, then the MLTS end user should bear 100% of the 
responsibility. Avaya asserts that the MLTS operator ultimately should 
be responsible for compliance and that if services are subcontracted, 
the operator must ensure that the subcontractor implements compliant 
technologies and should remain primarily responsible for compliance. Ad 
Hoc responds that the proposals of RedSky and Avaya would amount to a 
presumption that the operator is liable in certain circumstances and 
that the Commission should ``reject this premature, overzealous and 
ineffective approach to enforcement of any rules it may adopt in this 
proceeding.'' Instead, we believe a case-by-case assessment of 
liability based on the facts specific to the particular investigation 
is the most appropriate way to enforce Kari's Law and our rules.\11\
---------------------------------------------------------------------------

    \11\ The Florida Bureau of Public Safety urges the Commission to 
adopt a tiered approach to the enforcement of violations of Kari's 
law under which first time offenders would receive a warning ``with 
a strict but reasonable time frame to correct any deficiencies and 
with an appropriate penalty if the violation is not corrected.'' We 
decline to adopt this proposal because we believe it would be 
inappropriate to limit the Commission's enforcement discretion in 
this manner.
---------------------------------------------------------------------------

    110. We also decline to establish the safe harbor suggested by 
INCOMPAS. INCOMPAS asserts that if a manufacturer furnishes an MLTS 
with appropriate functionality, and an installer configures a system 
capable of direct dialing, alert notification, and sending dispatchable 
location information, then the Commission should provide a ``safe 
harbor for these parties in the service chain from liability if and 
when properly installed MLTS are not ultimately used properly.'' 
Panasonic and TIA state that

[[Page 66730]]

equipment manufacturers should not be liable for noncompliance of an 
MLTS manager with Commission rules unless the reason for the 
noncompliance is the design of the MLTS equipment. A manager, an 
operator, or an installer would not be liable if it performs its 
obligations in compliance with the statute and rules, but the 
enterprise customer declines to use the services offered. The same 
principle would apply to MLTS manufacturers, importers, sellers, and 
lessors; if the manufacturer, importer, seller, or lessor satisfies its 
obligations under the statute and rules, but the enterprise declines to 
use the system properly, then the manufacturer, importer, seller, or 
lessor should not be liable for the resulting noncompliance. 
Determinations of responsibility among multiple parties will 
necessarily be fact-specific, and we do not believe a safe harbor is 
appropriate or needed.
    111. We also decline to exclude equipment manufacturers from 
liability for the noncompliance of an MLTS manager unless the 
noncompliance results from the equipment's design, as Panasonic and TIA 
request. We find that the manufacturer's obligations and potential 
liability under Kari's Law and our rules are sufficiently clear and 
that the enforcement approach Panasonic and TIA propose is not needed. 
Further, Kari's Law and our rules do not reference the ``design'' of an 
MLTS, and we believe doing so would introduce ambiguity into the 
enforcement process.
6. Complaint Mechanisms
    112. In the NPRM, the Commission stated that it envisioned relying 
on existing Commission complaint mechanisms to facilitate the filing of 
complaints for potential violations of Kari's Law. For example, the 
Commission stated, PSAPs and the public could report problems via the 
Public Safety and Homeland Security Bureau's Public Safety Support 
Center or the Commission's Consumer Complaint Center.
    113. We conclude that our existing complaint mechanisms should be 
sufficient for addressing potential violations of Kari's Law. Several 
commenters assert that the Commission's existing mechanisms are 
sufficient for the filing of complaints for potential violations of 
Kari's Law. We also provide that persons alleging a violation of the 
rules implementing Kari's Law may file a complaint under the procedures 
set forth in part 1, subpart E of our rules.
    114. We also decline to establish procedures similar to those used 
for accessibility complaints under the Twenty-First Century 
Communications and Video Accessibility Act (CVAA) and section 255 of 
the Act. Panasonic and TIA urge the Commission to consider establishing 
a mechanism similar to that used for accessibility complaints under the 
CVAA or section 255 of the Act, including a mechanism for giving MLTS 
manufacturers, installers, operators, and managers an opportunity to 
resolve complaints informally before the Commission undertakes any 
enforcement action. Although the CVAA includes a provision directing 
the Commission to establish procedures for complaints and enforcement 
actions arising out of violation of certain accessibility requirements, 
Kari's Law does not include a corresponding provision. In addition, the 
Public Safety Support Center and Consumer Complaint Center procedures 
are flexible enough to provide an opportunity for informal resolution 
of complaints prior to enforcement should the Commission determine that 
such an opportunity would be appropriate.
    115. BRETSA urges the Commission to establish a separate mechanism 
for PSAPs to report MLTS noncompliance. We decline to do so, given that 
the Public Safety Support Center process will be sufficient for this 
purpose.
7. Preemption of State Law
    116. The preemption provision of Kari's Law states that ``[n]othing 
in this section 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 chapter.'' Commenters sought guidance, however, regarding the 
general effects of this provision on state and local law.
    117. Specifically, AT&T and BRETSA ask the Commission to clarify 
the effect of Kari's Law on state laws affecting 911 service for MLTS. 
AT&T urges the Commission to clarify how any new federal MLTS 
requirements will operate ``vis-[agrave]-vis additional, and sometimes 
conflicting, state MLTS requirements.'' AT&T, however, does not provide 
specific examples of any state requirements that appear to have the 
potential for conflicting with federal regulations implementing Kari's 
Law. BRETSA asks the Commission to find that state laws requiring 
existing MLTS systems to provide direct dialing, on-site notification, 
and interior location information are not inconsistent with Kari's Law, 
RAY BAUM'S Act, or the Commission's proposed rules. BRETSA, however, 
does not cite any such state laws, or even assert that any such laws 
exist. In addition, BRETSA asserts that federal rules implementing 
Kari's Law may establish grounds for civil claims and liability under 
state common law and statutes and urges the Commission not to limit a 
state's authority to ``determine civil liability or presumptions 
thereof, and any immunities therefrom, and any penalties for violation 
arising from violation of state MLTS 9-1-1 obligations.'' NARUC notes 
that it has adopted a resolution suggesting that any federal rules on 
MLTS direct dialing and notification ``should be written to permit 
States to impose additional requirements `presuming that such 
additional requirements do not contradict or conflict with federal 
requirements.' '' NARUC's resolution does not supply specific examples, 
however.
    118. As mentioned above, our objectives in the context of this 
broader rulemaking are to prescribe rules and regulations that we find 
are necessary to carry out Kari's Law, and to provide additional 
clarity and specificity regarding some of the terms used in the statute 
and the obligations placed on covered entities. We chose, in our 
discretion, to proceed incrementally, and thus did not propose to offer 
interpretations or rules going to the preemption provision of Kari's 
Law. Thus, at this time, and based on the record in this proceeding, we 
decline to provide guidance on the general effect of Kari's Law and our 
implementing regulations on individual state and local laws or on the 
``exercise of . . . authority'' of a state's or locality's 
``jurisdiction'' over ``emergency communications'' under a hypothetical 
set of facts. The record does not reflect specific examples (or even 
sufficient indication of a widespread problem) of state or local 
exercise of jurisdiction that may be inconsistent with the federal 
regulatory regime.
    119. In addition, BRETSA asserts that waiver is an essential 
element of a regulatory scheme and asks the Commission to clarify that 
state or local public safety agencies and officials have authority to 
grant waivers of the federal MLTS 911 rules ``upon finding that 
alternative deadlines and arrangements better serve the public safety 
or will avoid undue financial hardship.'' BRETSA also asserts that 
state and local public safety officials and agencies should have the 
opportunity to impose conditions on waivers, such as training 
requirements for enterprise personnel or contractors. We decline to 
find that state and local public safety authorities have authority to 
waive the Commission's MLTS rules, as BRETSA requests, or to

[[Page 66731]]

impose conditions on such waivers. Requests for such waivers should, as 
with other Commission requirements, be presented to the Commission, 
while requests for waivers of state and local requirements should be 
presented to the appropriate state or local governmental entity.
8. Equipment Authorization Rules
    120. The Commission also sought comment in the NPRM on whether to 
modify the equipment authorization rules as they apply to MLTS 
equipment manufactured after February 16, 2020. In addition, the 
Commission asked whether MLTS applications for equipment authorization 
under parts 2, 15, or 68 should constitute a representation that such 
equipment complies with MLTS 911 requirements.
    121. Commenters largely support using existing equipment 
authorization rules. While NPSTC recommends that the Commission 
implement a formal process for compliance with the provisions of Kari's 
Law as part of an equipment authorization process, other commenters 
state that a formal process would be unworkable because many MLTS 
products are software-based solutions that need to be configured and 
installed on premises. Panasonic and TIA also assert that any modified 
equipment authorization rules would apply only to hardware-based 
solutions and that this would constitute an unequal burden on such 
solutions.
    122. We decline to amend our equipment authorization procedures 
because we conclude that the existing equipment authorization 
procedures are sufficient. The MLTS marketplace represents a broad 
range of technologies that are continuing to evolve from more 
traditional, circuit-based solutions to wireless, cloud-based, and VoIP 
solutions, and we seek to ensure that our rules preserve flexibility 
and maintain technological neutrality.
9. Voluntary Best Practices
    123. The Commission in the NPRM asked commenters to identify 
voluntary best practices that can improve the effectiveness of direct 
dialing and notification for MLTS. The Commission noted, for example, 
that the Michigan State 911 Committee encourages MLTS operators to work 
directly with local public safety entities to ensure compliance and 
``strongly recommend[s] that every MLTS operator work with their local 
911 system manager/director to test the ability to dial 911 from the 
station lines associated with MLTS systems any time an MLTS has been 
installed or upgraded.'' The Commission sought comment on this and 
other recommended or potential best practices that would help 
enterprises ensure the effectiveness of direct dialing and 
notification, including best practices for training on-site emergency 
personnel and others responsible for the implementation of direct 
dialing and notification. Commenters that address this issue generally 
encourage the development of voluntary best practices for direct 
dialing and notification under Kari's Law.
    124. We encourage industry and the public safety community to work 
together to develop voluntary best practices that will help enterprises 
facilitate first responder access and minimize delays to response. NENA 
states that ``[r]ecognizing the diversity in enterprise IT staffing . . 
. means all players in the MLTS 9-1-1 space--including manufacturers, 
sellers, and 9-1-1--should contribute to education and development of 
best practices for MLTS operation.'' Cisco and BRETSA note the need for 
development of a standard testing protocol that would be employed when 
installers configure MLTS for 911, which we believe may be helpful. TIA 
states that efforts are underway to create a working group with members 
from industry and public safety to develop best practices and standards 
regarding Kari's Law requirements and the dispatchable location mandate 
under RAY BAUM'S Act. Several commenters also emphasize the need for a 
public awareness or education campaign for entities affected by the new 
rules. As noted above, we also believe it may be helpful for this 
effort to include guidance on disclosing the limitations of 911 dialing 
from legacy MLTS equipment.
    125. Some commenters make suggestions we believe are more 
appropriate for inclusion in voluntary best practices. BRETSA suggests 
that the Commission require MLTS providers to supply a copy of the 
rules to each customer. NENA asserts that although MLTS operators and 
managers are generally in the best position to maintain the unique 
registered locations of their MLTS, vendors and manufacturers ``must 
bear some responsibility to (1) encourage accurate and regular update 
of location information, and (2) provide means to alert operators and 
managers when registered location information has become out-of-date or 
hardware has been moved.'' We decline to require these practices, but 
we encourage industry and public safety entities to consider them in 
the development of best practices.
    126. We also agree with commenters about the importance of public 
outreach, and we intend to quickly develop and disseminate 
informational materials and to collaborate on outreach with our 
federal, state, and local partners, the public safety community, and 
industry.
10. Comparison of Benefits and Costs
    127. The Commission sought comment on the costs and benefits of 
satisfying its proposed direct dialing and notification rules for MLTS 
coming into service after February 16, 2020. The Commission asked 
whether there are alternative methods of meeting the requirements of 
Kari's Law that would reduce costs and/or increase benefits and whether 
there are any barriers for those wishing to replace their MLTS after 
this date that would be costly to overcome. The Commission also 
requested comment on the expected lifespan of existing MLTS that are 
not currently able to meet the requirements of the proposed rules, the 
prevalence of such systems today, and the expected prevalence of such 
systems in 2020. In addition, the Commission sought comment on the cost 
of upgrading to an MLTS that supports the requirements of the proposed 
rules. The Commission noted that ``[b]ecause most of the currently 
deployed MLTS are capable of being configured to meet the requirements 
of our rules today, without improvement to the hardware or software of 
the system, we tentatively conclude that our rules will impose no 
incremental costs to those who replace their MLTS as they come to the 
end of their useful life.'' Accordingly, the Commission sought comment 
on this tentative conclusion.
    128. Regarding notification, the Commission sought comment on its 
tentative conclusion that the costs of implementing its proposed 
requirements will not exceed the value of their benefits. The 
Commission also sought comment on any particular costs involved in 
imposing the notification requirement and alternative methods 
consistent with Kari's Law that may reduce costs and/or improve 
benefits. Further, the Commission sought comment on the costs and 
benefits associated with its proposed definitions. The Commission also 
asked for comment on the benefits and costs associated with any 
additional notification requirements the Commission might adopt, such 
as requiring operators of legacy MLTS to inform consumers of the 911 
capabilities of those systems.
    129. Some commenters support the Commission's tentative 
conclusions.

[[Page 66732]]

West Safety states that the proposed rules also appropriately balance 
the benefits and costs of implementation of direct dialing and 
notification by setting a compliance date of February 16, 2020, 
consistent with Kari's Law. West Safety asserts that ``direct access to 
9-1-1 without a dialing prefix can typically be implemented by 
appropriate configurations to MLTS of all types at little or no cost to 
the enterprise.'' West Safety also states that notification 
functionality is available natively in most MLTS equipment or can be 
supported via a third-party application. Accordingly, West Safety 
asserts, ``the cost of implementation is minimal, whereas the benefits 
of closing this regulatory gap are significant.'' Moreover, by adopting 
a prospective compliance date that applies only to MLTS offered for 
first sale after February 16, 2020, West Safety submits that ``market 
participants will be afforded sufficient advanced notice to make 
informed manufacturing, planning and purchasing decisions, and 
enterprises will have the proper level of financial and operational 
flexibility to retain their existing, grandfathered MLTS until end-of-
life.'' Regarding alternative methods of meeting the requirements of 
Kari's Law that would reduce costs and/or increase benefits, RedSky 
states that it offers a no-cost notification service when its call 
routing service is used. RedSky also states that for those wishing to 
replace their MLTS after February 16, 2020, ``[t]he cost with or 
without support to meet the requirements of the Rule should be 
equivalent.'' RedSky believes that the vast majority of existing MLTS 
can meet the requirements of the rule without significant modification.
    130. Other commenters generally agree with the Commission's 
proposals, but advocate that the Commission take a more measured 
approach towards adopting rules implementing Kari's Law than that 
suggested in the NPRM. To illustrate, Ad Hoc advises that as the 
Commission ``considers how best to implement the statutory mandates of 
Kari's Law and section 506 of RAY BAUM's Act, the Commission should 
strictly adhere to its `light touch' regulatory philosophy.'' Regarding 
notification, for example, Ad Hoc urges the Commission to avoid 
imposing detailed requirements beyond the proposed rule and to refrain 
from imposing transitional requirements on legacy MLTS.
    131. The rules we adopt today to implement the direct dialing and 
notification requirements of Kari's Law balance the needs of 
stakeholders and maximize many public safety benefits. These benefits 
include potentially preventing fatalities, injuries, or property 
damage, improving emergency response time and access to emergency 
services, reducing delays in locating 911 callers, narrowing the gap 
between MLTS 911 service capabilities relative to other communications 
services subject to 911 requirements, driving further technology 
development, and lowering the cost of 911 solutions for MLTS. The 
record developed in response to the NPRM confirms that many existing, 
installed MLTS support direct dialing to 911 and notification. Further, 
the record developed in response to the 2017 Enterprise Communications 
NOI suggests that direct dialing and notification rules will impose no 
incremental costs to those replacing their MLTS at the end of its 
useful life. Because Congress mandated compliance with its direct 
dialing and notification requirements after February 16, 2020, and 
expressly grandfathered MLTS systems in service before that date, 
Congress has already crafted a balance of costs and benefits with 
respect to compliance to which the Commission is bound. Further, when 
Congress adopted Kari's Law, it contemplated that the requirements 
would evolve with advancements in MLTS technology. The record in this 
proceeding reflects that the modern enterprise communications ecosystem 
is complex and that legacy TDM-based technology is evolving towards an 
IP-based MLTS environment.
    132. As Congress has specifically legislated to create this 
framework and identified areas in which the Commission shall enforce 
the statute, Congress has already assessed the benefits of its 
requirements. In the NPRM, the Commission observed that a Congressional 
Budget Office analysis concluded that most MLTS systems already are 
configured to meet the direct dialing and notification requirements of 
Kari's Law. In evaluating the Senate and House versions of Kari's Law, 
Cisco stated that it was not aware of any technological barriers to the 
implementation of Kari's Law as applied to MLTS. In the NPRM, the 
Commission cited eight states and some local governments that already 
have laws requiring direct dialing for 911 from MLTS. For these state 
and local jurisdictions, the Commission noted that its proposed rules 
would generally not affect the status quo and so would likely have 
little to no impact from a cost perspective. Moreover, the Commission 
observed that the existence of state-level requirements has already 
driven the manufacture of MLTS equipment that supports 911 direct 
dialing, much of which may have been marketed and sold in jurisdictions 
that do not have state or local requirements.
    133. In this analysis, we address whether our rules achieve the 
benefits of Kari's Law in a cost-effective manner. The record supports 
adopting implementing regulations of Kari's Law and the Commission's 
conclusion in the NPRM that these rules are necessary to provide 
additional clarity and specificity regarding the terms used in the 
statute and the obligations placed on covered entities. As demonstrated 
by commenters, implementing regulations can provide important guidance 
to covered entities on complying with the law and the mechanism the 
Commission will use to enforce the statute. Accordingly, our rules 
include definitions of some of the terms in Kari's Law, as well as 
other provisions to clarify the obligations of entities regulated under 
the statute. The rules we adopt today generally track the statutory 
requirements of Kari's Law, are technologically neutral, and leverage 
advances in technology to improve access to emergency services as 
envisioned by Congress. The flexibility and minimum criteria we 
establish for direct dialing and notification should offset any 
potential burdens associated with compliance with our rules. Therefore, 
we conclude that there will be no immediate costs associated with 
meeting the requirements of our rules and that the amount of 
flexibility and lead time for compliance will help to minimize future 
potential costs.
    134. The Commission also sought comment on the cost and expected 
benefit of the options proposed in the NPRM for implementing the 
notification requirement of Kari's Law, including whether to specify 
staffing requirements for the notification point. The Commission noted 
that while some state MLTS statutes include notification requirements, 
these statutes either expressly provide that the enterprise does not 
have to make a person available to receive a notification, or they are 
silent on whether the destination point must be staffed. The Commission 
stated that it did ``not believe Congress intended to impose staffing 
or monitoring requirements that would impose unreasonable costs or 
limit the flexibility of MLTS installers, managers, and operators to 
develop efficient and cost-effective notification solutions that are 
appropriate for the technology they use, such as visual alerts on 
monitors, audible alarms, text messages, and/or email.'' Rather than 
requiring staffing or monitoring, the Commission believed ``that 
allowing

[[Page 66733]]

notifications to be directed to the points where they are likely to be 
seen or heard by existing staff achieves these goals at a negligible 
cost above what an MLTS manager would already spend when purchasing an 
MLTS.''
    135. The record supports the Commission's view that Congress did 
not intend to impose burdensome staffing or monitoring requirements 
that would impose unreasonable costs or limit the flexibility of MLTS 
installers, managers, and operators to develop efficient and cost-
effective notification solutions. The record supports setting minimum 
criteria for the notification to maximize benefits but also providing 
enterprises significant flexibility to tailor notifications to meet 
their specific needs. Similarly, the record supports adopting a 
requirement that notifications be sent to a location on-site or off-
site where someone is likely to hear or see the notification, but not 
requiring that enterprise staff or monitor the notification point at 
all times. Additionally, the record suggests that the Commission's 
definition of ``improvements to the hardware or software of the 
system'' strikes the right balance to ensure that enterprises will not 
incur significant costs or core system upgrades in connection with 
providing notification, as provided under Kari's Law.
    136. Taken together, the notification requirements we adopt today 
establish the necessary conditions that will make it more likely than 
not that 911 callers using an MLTS upgraded or placed into service 
after February 16, 2020, will benefit from the notification provisions 
of Kari's Law at a negligible cost above what an MLTS manager or owner 
would already spend when purchasing or upgrading an MLTS. In sum, the 
record suggests that establishing some minimum criteria represents a 
cost-effective means to reasonably ensure that notification will be 
timely received by a person with authority to act on it while balancing 
the needs of stakeholders, maintaining technological neutrality, 
preserving flexibility for enterprises, and minimizing burdens 
associated with implementing the notification requirement of Kari's 
Law.

B. Dispatchable Location for MLTS and Other 911-Capable Communications 
Services

    137. RAY BAUM'S Act directs us to consider rules requiring the 
conveyance of dispatchable location with 911 calls ``regardless of the 
technological platform used.'' Based on this directive, we adopt 
dispatchable location requirements for MLTS and other 911-capable 
services that do not have such requirements, including fixed telephony, 
interconnected VoIP service, Telecommunications Relay Services (TRS), 
and mobile text.
1. MLTS
    138. In the NPRM, the Commission observed that when a 911 call is 
placed in an MLTS environment, the system may provide the PSAP with the 
location of a main entrance or administrative office rather than the 
location of the caller, which can lead to delays in locating the caller 
and result in injury or loss of life. By directing the Commission ``to 
consider adopting rules to ensure that the dispatchable location is 
conveyed with a 9-1-1 call . . . including with calls from multi-line 
telephone systems,'' Congress in RAY BAUM'S Act signaled its intent 
that the Commission focus on ensuring highly precise location 
information whenever feasible in connection with MLTS 911 calls.
    139. In the NPRM, the Commission proposed to proscribe the 
manufacture, import, sale, or leasing of MLTS in the United States 
unless the system is pre-configured such that, when properly installed, 
the dispatchable location of the caller will be conveyed to the PSAP 
with 911 calls. The Commission further proposed to proscribe the 
installation, management, or operation of MLTS in the United States 
unless the system is configured such that the dispatchable location of 
the caller will be conveyed to the PSAP with 911 calls. The NPRM 
proposed to apply these requirements to the same entities subject to 
Kari's Law. We adopt these proposals with certain modifications.
a. Definition of Dispatchable Location
    140. Section 506 of RAY BAUM'S Act defines ``dispatchable 
location'' as ``the street address of the calling party, and additional 
information such as room number, floor number, or similar information 
necessary to adequately identify the location of the calling party.'' 
In the NPRM, the Commission noted the substantial similarity of this 
statutory definition to the definition of ``dispatchable location'' in 
the Commission's wireless E911 location accuracy rules. The Commission 
proposed to construe the definitions as functionally identical, aside 
from the specification of the technological platform to which each 
definition applies. The Commission also sought comment on whether to 
further define ``additional information'' that may be necessary to 
``adequately identify the location of the calling party.'' Finally, the 
Commission noted that the wireless E911 definition of dispatchable 
location requires street address information to be validated, and asked 
whether validation should similarly be required for dispatchable 
location information associated with MLTS 911 calls.
    141. We adopt the definition of dispatchable location proposed in 
the NPRM, without further specifying the types of location information 
that may be required to locate callers in specific instances. We also 
require that to meet the definition of dispatchable location for MLTS 
911 calls (and for calls from other platforms discussed in succeeding 
sections below), street address information must be validated. We agree 
with commenters that the definition of dispatchable location needs to 
be both functional and flexible. As APCO states, ``[d]ispatchable 
location is well understood by public safety communications 
professionals to mean information sufficient for guiding first 
responders to the right door to kick down.'' However, what constitutes 
``sufficient'' information will vary significantly depending on the 
environment from which a 911 call originates. For calls placed from 
multi-story buildings or campus environments, first responders will 
typically require specific floor and room information, in addition to 
the street address of the building. For calls placed from many small 
businesses, on the other hand, a street address alone may provide first 
responders all the information they need to quickly locate the caller.
    142. Accordingly, the definition of dispatchable location that we 
adopt today gives participants in the MLTS marketplace flexibility in 
deciding what level of detail should be included in the location 
information provided to PSAPs for particular environments, so long as 
the level of detail is functionally sufficient to enable first 
responders to identify the location of a 911 caller in that 
environment. Given the diverse and evolving nature of the MLTS market 
and the breadth of enterprise environments at issue in this proceeding, 
we decline to expand upon the statutory definition in specifying 
instances in which ``additional information'' beyond street address 
must be made available, or in identifying specific categories of 
additional location information beyond floor level or room number.
    143. We also conclude that the definition of dispatchable location 
for MLTS 911 calls should include a requirement that street addresses 
be validated. The majority of commenters who addressed this issue 
indicate that such validation is essential to ensure that a location is 
sufficiently reliable for dispatch of first responders.

[[Page 66734]]

Commenters also state that street address validation is feasible and 
can be implemented by MLTS managers and operators without incurring 
significant costs. NENA states that MLTS managers or operators have 
``numerous methods'' for validating addresses against databases like 
the Master Street Address Guide or databases that support the Location 
Validation Function in the NG911 environment. Finally, including street 
address validation in our dispatchable location definition for MLTS and 
other services covered by this order establishes parity with the 
dispatchable location definition in our wireless E911 rules and renders 
the two definitions functionally identical.
    144. Cisco and ATIS express concern about the cost and feasibility 
of validation requirements imposed on large enterprises if validation 
beyond street address or building level is required. We emphasize that 
our adopted definition of dispatchable location--as in the case of our 
wireless rules--only references validation of street address 
information. While we encourage the development of solutions that will 
support validation of more granular location information than street 
address, including floor and room number, we agree with commenters who 
caution against imposing overly prescriptive requirements at this time 
that could inhibit the development of innovative solutions.
b. MLTS Provision of Dispatchable Location or Alternative Location 
Information
    145. In the NPRM, the Commission ``tentatively conclude[d] that it 
is feasible for 911 calls that originate from a MLTS to convey 
dispatchable location to the appropriate PSAP.'' The Commission based 
this tentative conclusion on the record in the Enterprise 
Communications NOI proceeding, in which several commenters stated that 
they already offered methods for dynamically determining and conveying 
an MLTS end user's location. The Commission also noted the potential 
availability of dispatchable location solutions that require the 
customer to identify their own location and solutions that calculate a 
location by leveraging data available from the 911 caller's device and 
the network. The Commission sought comment on this tentative conclusion 
and on the range of potential approaches to providing dispatchable 
location. The Commission also sought comment on whether a MLTS that 
handles calls initiated by remote users, e.g., off-site workers, should 
be required to convey location information about remote users.
    146. The Commission noted that there may be instances where 
location information that does not meet the definition of dispatchable 
location could still be useful to PSAPs and first responders, either as 
supplemental information to validate the dispatchable location or as an 
alternative in instances where dispatchable location information is not 
available. The Commission stated its belief that ``our rules and 
policies should not preclude--and in fact should allow and encourage--
potential alternatives to dispatchable location.'' The Commission asked 
whether other types of location information (for example, x/y/z 
coordinates) could be conveyed with a 911 call originating from an 
MLTS. Finally, the Commission proposed to require implementation of 
dispatchable location requirements for MLTS systems by February 16, 
2020, the same as the implementation date for the requirements of 
Kari's Law.
    147. Numerous commenters address the issue of MLTS dispatchable 
location, expressing a variety of viewpoints. Some commenters agree 
with the Commission's tentative conclusion that it is feasible to 
provide dispatchable location with MLTS 911 calls, and state that they 
are already capable of providing highly specific real-time location 
information for MLTS users. Other commenters, however, contend that 
while dispatchable location may be feasible for some MLTS 911 calls, it 
is not feasible in all cases, and that attempting to impose ``one-size-
fits-all'' dispatchable location requirements on all MLTS would be 
unworkable.
    148. Because the MLTS marketplace serves an enormous range of 
enterprise environments and includes systems that vary greatly in size, 
scope, and technological capability, we agree with commenters that our 
approach must take this variety into account.\12\ In this regard, the 
comments suggest that the feasibility of providing dispatchable 
location for an MLTS 911 call, and the means available to provide it, 
vary significantly depending on whether the call is from a fixed or 
non-fixed device \13\ and, in the case of non-fixed devices, whether 
the device is being used on or off the enterprise premises. Cisco 
points out that ``dispatchable location is more supportable from on-
premises fixed or `hardwired' MLTS stations (such as desk phones), more 
challenging for on-premises mobile clients (such as softphones), and 
even more difficult, if not impossible, for off-premises softphones 
using public internet or Virtual Private Network connections.'' We find 
this assessment to provide a useful framework for addressing MLTS 
location issues. Therefore, in the discussion below, we separately 
address dispatchable location requirements for MLTS 911 calls from 
fixed devices, non-fixed devices being used on-premises, and non-fixed 
devices being used off-premises.
---------------------------------------------------------------------------

    \12\ We agree with Avaya that service providers may use any 
technology that delivers dispatchable location, including any 
technology that complies with NENA i3 specifications.
    \13\ For purposes of this proceeding, we define ``fixed'' MLTS 
devices as devices that connect to a single end point (e.g., a desk 
or office phone) and are not capable of being moved to another 
endpoint by the end user, although they may be capable of being 
moved to a different endpoint by a professional installer or network 
manager. ``Non-fixed'' MLTS devices are devices that the end user 
can move from one endpoint to another without assistance.
---------------------------------------------------------------------------

(i) Fixed MLTS Calls
    149. Commenters generally agree that providing dispatchable 
location of fixed devices presents the easiest use case for MLTS 
providers. Where MLTS calls originate from fixed devices such as hotel 
phones or fixed desk phones that each connect to a single access point, 
providing location information for each endpoint is not technically 
difficult or costly. In addition, our definition of dispatchable 
location gives providers substantial flexibility to determine what 
amount of information is needed to identify the dispatchable location 
of each fixed endpoint, and for many small businesses, provision of 
street address alone will be sufficient. We therefore conclude that 
providing dispatchable location for 911 calls from fixed MLTS devices 
used on-premises is readily achievable.\14\ We also conclude that 
dispatchable location from fixed MLTS devices should be provided 
automatically \15\ and that the street address associated with the 
fixed end-point should be validated.
---------------------------------------------------------------------------

    \14\ We infer that fixed MLTS use occurs solely through 
connection of fixed devices with on-premises endpoints. Commenters 
did not cite any instances of MLTS supporting fixed devices off-
premises. In the unlikely event that an MLTS were to support a fixed 
off-premises device, however, we see no reason why providing 
dispatchable location for such a device would be any less feasible 
than in the case of an on-premises device.
    \15\ In other words, the dispatchable location information 
associated with a fixed MLTS device must be conveyed to the PSAP 
when a user places a 911 call, without further intervention by the 
user at the time it places the call. As noted below, an MLTS 
operator or manager may rely on an enterprise customer to acquire, 
maintain, and keep up-to-date the location information associated 
with a fixed MLTS device.
---------------------------------------------------------------------------

    150. This requirement will take effect one year from the effective 
date of the rules adopted in this order. Although

[[Page 66735]]

the Commission proposed in the NPRM to implement dispatchable location 
requirements for MLTS on February 16, 2020, contemporaneous with the 
compliance date for the requirements of Kari's Law, most industry 
commenters oppose this proposal, arguing that it would give them only a 
few months to implement requirements and noting that RAY BAUM'S Act, 
unlike Kari's Law, does not specify an implementation date for 
requirements the Commission may adopt. We conclude that a one-year 
timeframe is more reasonable to ensure timely implementation while 
affording affected parties reasonable time to take the necessary steps 
to come into compliance.
(ii) Non-Fixed MLTS Calls
    151. Commenters express divergent views as to the feasibility of 
providing dispatchable location for on-premises MLTS 911 calls from 
non-fixed devices, e.g., softphones or mobile handsets that that are 
capable of connecting to multiple Wi-Fi access points and can move from 
one location to another within a building.\16\ Some MLTS service 
providers (e.g., RedSky, Avaya, BluIP) state that they currently offer 
enterprise services that use access point location information to 
dynamically determine and convey an MLTS end user's precise location 
within a building. Such services typically rely on storing location 
information for each access point in a database (maintained by the 
enterprise customer or the MLTS provider) that can be referenced when a 
911 call is placed from a particular access point.
---------------------------------------------------------------------------

    \16\ While such devices are capable of being moved from one 
access point to another, we note that they may be only be capable of 
conducting a communications session with one access point at a time, 
i.e., the system may not support seamless handoff of the device from 
one access point to another without interrupting the session.
---------------------------------------------------------------------------

    152. However, other commenters point out that the effectiveness of 
enterprise database approaches is dependent on a number of variables 
and could be prohibitively costly. Relying on an enterprise database to 
provide location information requires the enterprise customer to either 
develop and maintain the database or to pay a third-party vendor to 
provide database services. It also requires procedures and safeguards 
to ensure that access point location data are entered accurately and 
kept up-to-date. In addition, depending on the density and distribution 
of in-building access points, access point location information may 
provide the caller's approximate location but may not be precise enough 
to provide dispatchable location, e.g., the caller's specific room or 
office number. Commenters anticipate that over time, database location 
solutions for MLTS will become more widely available and capable of 
providing more precise location information, but they caution against 
adopting requirements that assume the near-term availability of 
database solutions to support dispatchable location across the full 
array of enterprise environments.
    153. To address these concerns, we adopt a more flexible approach 
to providing dispatchable location for MLTS 911 calls from non-fixed 
devices. MLTS providers must convey automated dispatchable location for 
such devices when technically feasible but may rely on the MLTS end 
user to provide or confirm dispatchable location information manually, 
e.g., by responding to a system prompt. Commenters generally agree that 
enabling such manual confirmation of location information by MLTS end 
users is both feasible and potentially beneficial.
    154. We recognize that relying solely on end users to provide 
manual location updates can lead to user fatigue, and that manually 
provided information may not be accurate or up-to-date. As an 
additional fallback, commenters strongly agree with the Commission's 
statement in the NPRM that our rules and policies should ``allow and 
encourage'' alternatives to dispatchable location. Microsoft states 
that commercially available location services already in use around the 
globe can be leveraged ``relatively quickly and effectively'' to 
enhance the 911 capabilities of IP-based and cloud-MLTS and 
interconnected VoIP services in ways ``far more accurate and reliable 
than a `registered location' manually entered by the end-user.'' 
According to Microsoft, location technologies that could be leveraged 
include GPS/GNSS location, device-based sensing of Wi-Fi hotspots, and 
use of commercially available crowd-sourced location data. Comtech 
states that newer MLTS hardware can incorporate GNSS signals, which 
could be used to automatically corroborate any human-provisioned 
dispatchable location information. INCOMPAS contends that ``relying on 
a `superset of location information' such as a wireless carrier's cell 
site, GPS, the Wi-Fi hotspots, and commercial location information 
gives regulated voice providers several opportunities to provide 
accurate dispatchable location data rather than relying on a static 
address.''
    155. We agree with these commenters that our rules should harness 
the potential for commercially available device-based technologies and 
coordinate-based location methods to support the provision of MLTS 911 
location information. Therefore, as proposed in the NPRM, we afford 
MLTS providers flexibility to provide alternative location information, 
including coordinate-based information, when providing dispatchable 
location is not feasible or cost-effective.\17\ We also adopt a 
technology-neutral approach, as uniformly advocated by commenters, so 
that providers have the widest latitude to choose among available 
solutions.
---------------------------------------------------------------------------

    \17\ APCO cautions that providers should not be allowed to 
``self-declare'' that dispatchable location is not technically 
feasible or cost-effective. We agree. If we receive a complaint or 
petition that a provider is not providing dispatchable location and 
the provider asserts that doing so is not technically feasible or 
cost-effective, the provider must show that its assertion has an 
objective and reasonable basis in light of the state of technology 
at the time the assertion is made.
---------------------------------------------------------------------------

    156. We recognize that where alternative location information is 
provided with an MLTS 911 call, the rules we adopt today allow the 
location fix to be less precise than a dispatchable location that 
pinpoints the caller's location down to the room, office, or apartment 
level. While we agree with APCO that a more precise location is the 
preferred outcome, we find that the record strongly supports allowing 
the provision of less precise--but still actionable--alternative 
location information as a fallback when providing more precise 
information is not technically feasible. Identifying a caller's street 
address and floor level is likely to reduce response time, even if it 
does not identify ``the door to kick down.'' Commenters also confirm 
that this level of accuracy is significantly easier and less costly to 
achieve than more precise location information in many instances. Cisco 
states that ``MLTS today typically provides the building's street 
address, and . . . systems increasingly provide floor level.'' In 
addition, while identifying a caller's room or apartment may be 
significantly more costly, as Cisco asserts, it is not difficult for an 
MLTS serving large buildings to identify the building wing or quadrant 
where the call originates. Therefore, we define ``alternative location 
information'' as location information (which may be coordinate-based) 
sufficient to identify the caller's civic address and approximate in-
building location. In large multi-story buildings, this should normally 
include floor level and approximate location on the floor (e.g., 
building quadrant). We note that this approach is similar to the 
approach the Commission took in its wireless E911

[[Page 66736]]

rules, which allow wireless carriers to provide either dispatchable 
location or x/y/z coordinate-based location information for indoor 
wireless 911 calls.
    157. These requirements will take effect two years from the 
effective date of rules adopted in this order. Although the Commission 
proposed to make dispatchable location requirements effective on 
February 16, 2020, we agree with commenters that a longer transition 
period is needed for MLTS providers to implement ``granular'' location 
requirements, particularly for non-fixed services. Cisco states that 
for ``on-premises MLTS stations,'' the Commission should consider a 
phased approach whereby the Commission would require MLTS managers to 
provide the street address of the caller's location while having the 
flexibility to provide additional information that they determine is 
sufficient for the enterprise ``following a minimum transition period 
of two years.'' Panasonic states that the Commission ``should extend 
the compliance date for 3-5 years if [validation] capability is deemed 
necessary for all MLTS systems.'' RingCentral states that the 
Commission should allow at least 18 to 24 months to develop solutions 
to meet the complex challenges posed by any new location requirements. 
VON states that the compliance date for nomadic VoIP providers should 
be at least 24 months after the effective date of our implementing 
order.
    158. We conclude that a two-year transition period is appropriate 
for implementation of these requirements. It is consistent with 
implementation timeframes recommended by many commenters. We also agree 
with Microsoft, Cisco, and other commenters that within the next two 
years, MLTS will likely be able to leverage improvements in technology 
that can refine the location process, including improvements to 
location databases and commercially available device-based technologies 
that can provide a ``superset'' of location information on a standalone 
basis or in combination with network-based tools. Finally, we note that 
the two-year deadline adopted in this order will likely fall in late 
2021, which will roughly coincide with implementation of milestones 
intended to improve in-building location of wireless 911 calls under 
the Commission's wireless location accuracy rules. This provides an 
opportunity for MLTS, as well as other services covered by this order, 
to explore opportunities with wireless carriers for developing common 
location solutions that can support in-building location regardless of 
the platform used to make the 911 call.
    159. In contrast, we conclude that MLTS providers should not be 
subject to the same location requirements for off-premises MLTS calls 
to the extent compliance is not technically feasible. When an MLTS end 
user is off-premises, the MLTS does not typically control or have 
access to location information. Remote access instead may involve 
connecting via a third-party access point that is outside the control 
of the enterprise or the MLTS operator, and for which location 
information may not be available. We agree with commenters that this 
lack of access or control makes it considerably more challenging and 
costly for an MLTS to provide location information for off-premises 
users than on-premises users. TIA states that for an end-user connected 
remotely to an enterprise via a VPN, ``ensuring accurate location data 
is difficult, if not impossible'' because a VPN user's location is 
reported as an IP address of the enterprise at end of the IP tunnel. 
Panasonic states that where an employee uses an IP-capable client off-
premises, ``there is no way to locate such callers today without 
requiring the purchase of expensive third-party services that require 
manual location entry.'' RingCentral states that ``when a user goes 
off-site and leaves the enterprise network, it may not be possible to 
locate that user or even detect that the user has moved.''
    160. In light of these factors, we conclude it is premature to 
prescribe specific standards for location of off-premises MLTS calls 
when compliance with our on-site requirements would not be technically 
feasible, and we therefore adopt a flexible approach that avoids 
imposing impossible requirements. For off-premises 911 calls, the MLTS 
operator or manager must provide (1) dispatchable location, if 
technically feasible, or, otherwise, either (2) manually-updated 
dispatchable location, or (3) 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. This requirement will take effect two 
years from the effective date of rules adopted by this order. The 
flexibility inherent in this requirement should lessen the burden and 
the amount of time it will take to comply. We recognize that as a 
practical matter, MLTS providers are unlikely to be capable of 
providing dispatchable location for most off-premises calls, and that 
``best-available'' location information may be limited in the near 
term. Nevertheless, over time this requirement will encourage 
development of improved location capabilities for off-premises MLTS 911 
calls.
c. Roles and Responsibilities of MLTS Participants
    161. The Commission proposed to apply MLTS dispatchable location 
requirements to ``the participants in the MLTS marketplace we believe 
are best positioned to ensure that all installed MLTS are capable of 
conveying an accurate location to the appropriate PSAP.'' As in the 
case of Kari's Law, the Commission proposed distinct requirements for 
MLTS manufacturers, importers, sellers, and lessors, on the one hand, 
and MLTS installers, operators, and managers on the other: The former 
group would be required to ensure that MLTS systems are ``pre-
configured'' to convey dispatchable location with 911 calls, while the 
latter group would be required to ensure that MLTS systems are 
``configured'' to convey dispatchable location with 911 calls. The 
Commission sought comment on whether more granular requirements should 
be placed on any of the MLTS market participants to which the proposed 
rules would apply and whether rules are needed to ensure that MLTS 
manufacturers and importers incorporate capabilities in their products 
to enable them to convey dispatchable location information.
    162. Commenters are generally supportive of the Commission 
clarifying the roles and responsibilities of MLTS market participants 
with respect to providing location information with 911 calls. 
Commenters also agree with the Commission's proposal that 
responsibility for dispatchable location be apportioned in the same 
manner as responsibility for the direct dialing and notification 
requirements of Kari's Law. Therefore, as proposed in the NPRM, we 
impose pre-configuration requirements on MLTS manufacturers, importers, 
sellers and lessors, and configuration requirements on MLTS installers, 
operators, and managers. In light of our adoption of flexible location 
requirements, these pre-configuration and configuration requirements 
now reference the conveyance of dispatchable location and alternative 
location information.
    163. Some commenters propose additional clarification of the 
respective roles and responsibilities of MLTS installers, operators, 
and managers in ensuring that accurate location information is provided 
with MLTS 911 calls. NTCA states that a service provider should be 
required ``to configure proper location information

[[Page 66737]]

upon installation and initiation of service only to the extent they are 
involved in configuration of handsets and systems in the first 
instance.'' RedSky states that ``the level closest to the end user has 
the most accurate device . . . location data and should be held 
responsible for the provisioning of data.'' Several commenters also 
note that MLTS operators and managers will need the assistance of 
enterprise customers to acquire, maintain, and update location 
information. Accordingly, Comcast contends, MLTS operators and managers 
should not be held responsible when a customer moves MLTS stations to 
new locations without their knowledge.
    164. We agree with commenters that additional clarification of the 
role of MLTS installers, operators, and managers is warranted. We 
therefore adopt a proposal submitted by USTelecom to add specific rules 
that delineate the respective responsibilities of MLTS installers, 
managers, and operators relative to the provision of location 
information. We also clarify that in developing and implementing 
location solutions, MLTS managers and operators are entitled to rely on 
enterprise customers to acquire, maintain, and update location 
information.
d. Location Requirements for Small Businesses
    165. The Commission sought comment on whether certain small 
business categories (e.g., of a specific size, or with a specific 
number of consumers) should be exempted from MLTS dispatchable location 
requirements. Commenters offered varying proposals for small businesses 
exemptions ranging from criteria based on square footage of enterprise; 
to allowing states and local jurisdictions to grant waivers; to 
applying requirements based on a minimum number of lines.
    166. The rules we adopt today obviate the need for small business 
exemptions or waivers of MLTS location requirements based on square 
footage or number of lines. The rules afford all MLTS a broad menu of 
options for providing location information, and the requirements are 
also scalable to the needs of small businesses: In most instances, 
provision of street address information alone will be sufficient to 
identify the dispatchable location of MLTS 911 calls originating from 
small businesses. We believe this approach minimizes burdens and 
unnecessary complexity for small businesses while also preserving 
flexibility to advance the 911 location accuracy objectives of RAY 
BAUM'S Act.
e. Legacy MLTS
    167. In the NPRM, the Commission proposed to apply location 
requirements to the same entities subject to the direct dialing and 
notification requirements of Kari's Law, which would exclude legacy 
MLTS. APCO argues that even though legacy MLTS is not subject to Kari's 
Law, legacy systems should be subject to location requirements because 
RAY BAUM'S Act does not prohibit applying such requirements to legacy 
systems, and some MLTS is capable of delivering dispatchable location 
today. Other parties support the NPRM proposal, arguing that requiring 
legacy MLTS to retrofit their systems to support dispatchable location 
would be disruptive and costly. On balance, we adopt the NPRM proposal. 
We decline to adopt APCO's request because doing so would require 
costly retrofitting of legacy MLTS--costs that would be more burdensome 
than for mass market services because legacy MLTS are specially 
configured for the particular enterprises they serve. In addition, 
applying Kari's Law and RAY BAUM'S Act to different classes of MLTS 
would create confusion and technical inconsistency, whereas applying 
the two statutes uniformly will encourage integrated 911 solutions for 
MLTS.\18\ We also disagree with APCO's suggestion that applying new 
location obligations to the existing MLTS ecosystem would be comparable 
to the Commission's approach to phased-in location accuracy for 
wireless services. In the wireless context, the increasingly precise 
location obligations adopted by the Commission were imposed on an 
industry already subject to extensive 911 obligations. In contrast, 
before Kari's Law and RAY BAUM'S Act were enacted, MLTS was not subject 
to any 911 obligations at the federal level. Adopting complex 
obligations from scratch for a legacy industry is vastly more complex 
and costly than an incremental change to an already-regulated service. 
We also believe our decision is consistent with Congressional intent to 
address MLTS 911 on a prospective basis and not to require retrofitting 
of existing MLTS.
---------------------------------------------------------------------------

    \18\ In this respect, we find that requiring retrofitting 
existing systems solely to address dispatchable location may result 
in a failure to promote more integrated technological solutions that 
could address both the direct dialing and notification provisions of 
Kari's Law and the dispatchable locations provisions of RAY BAUM'S 
Act on a holistic basis.
---------------------------------------------------------------------------

f. Liability Protection
    168. Microsoft requests that the Commission clarify that MLTS 
providers are entitled to the same liability protections afforded 
wireless carriers, iVoIP services and text-to-911 services. Microsoft 
observes that Congress has granted immunity from liability to certain 
emergency communications providers as follows:

    A wireless carrier, IP-enabled voice service provider, or other 
emergency communications provider, and their officers, directors, 
employees, vendors, and agents, shall have immunity or other 
protection from liability in a State of a scope and extent that is 
not less than the scope and extent of immunity or other protection 
from liability that any local exchange company, and its officers, 
directors, employees, vendors, or agents, have under Federal and 
State law (whether through statute, judicial decision, tariffs filed 
by such local exchange company, or otherwise) applicable in such 
State, including in connection with an act or omission involving the 
release to a PSAP, emergency medical service provider or emergency 
dispatch provider, public safety, fire service or law enforcement 
official, or hospital emergency or trauma care facility of 
subscriber information related to emergency calls, emergency 
services, or other emergency communications services.

    169. We find that this statutory liability shield extends to MLTS 
manufacturers, importers, sellers, lessors, installers, operators and 
managers. The statutory text applies its liability protections to 
``other emergency communications service providers,'' which is defined 
to include ``an entity other than a local exchange carrier, wireless 
carrier, or an IP-enabled voice service provider that is required by 
the Federal Communications Commission consistent with the Commission's 
authority under the Communications Act of 1934 [47 U.S.C. 151 et seq.] 
to provide other emergency communications services.'' In this Report 
and Order, we find that MLTS manufacturers, importers, sellers, 
lessors, installers, operators and managers are subject to our 
jurisdiction and, consistent with the requirements of Kari's Law and 
RAY BAUM'S Act, we require them to configure MLTS systems to ensure 
delivery of 911 emergency information to PSAPs. Thus, we agree with 
Microsoft that MLTS plays a ``significant role . . . in the provision 
of 911 services in the United States,'' and that ``MLTS apps will be 
engaged in the transmission of 911 information to PSAPs.'' Accordingly, 
we find that because these entities are required to provide ``emergency 
communications service,'' MLTS manufacturers, importers, sellers, 
lessors, installers, operators and managers fall within the statutory 
definition of ``other emergency communications provider.''

[[Page 66738]]

2. Fixed Telephony
    170. In the NPRM, the Commission proposed to require fixed 
telephony providers to furnish dispatchable location with 911 calls. 
The Commission noted that these providers already provide validated 
street address information with 911 calls, which should meet the 
dispatchable location requirement for single-family dwellings, and 
asked about the feasibility of also providing floor level and room 
number for calls from multi-story buildings.
    171. No commenter disagrees with our conclusion that by providing 
validated street address information with 911 calls, fixed telephony 
providers are already providing dispatchable location for single-family 
dwellings.\19\ With respect to fixed telephony calls from multi-story 
buildings, the limited comments we received on the issue support our 
view that fixed telephony providers are either already providing floor 
and room information or can readily do so at minimal cost. Panasonic 
states that ``it is feasible for 911 calls from an endpoint assigned a 
[Direct Inward Dialing] number to convey a dispatchable location; each 
[Direct Inward Dialing] number can be assigned with a dispatchable 
location in the telephony carrier's database. West Safety states that 
it is ``not aware of any technical limitations to fixed telephony 
providers conveying dispatchable location with a 9-1-1 call.'' As a 
practical matter, for apartment building residents that are fixed 
telephony customers, dispatchable location can be readily provided 
because the apartment number (which often identifies floor level as 
well) is part of the customer's billing address. To the extent that 
fixed telephony providers need to provide more than street address and 
are not already doing so, the means to add this capability are readily 
available.
---------------------------------------------------------------------------

    \19\ RedSky notes that fixed telephone providers typically have 
no control over inside wiring in single family homes, and therefore 
are unlikely to be able to identify floor level for a fixed 
telephone call originating from a single family home that is more 
than one story. However, we see no practical benefit to requiring 
floor level identification as a component of dispatchable location 
for calls from single family dwellings, nor has any public safety 
commenter suggested this is necessary.
---------------------------------------------------------------------------

    172. Based on these findings, we adopt our proposal requiring fixed 
telephony providers to deliver automated dispatchable location with 911 
calls. This requirement will take effect one year from the effective 
date of the rules adopted in this order. Although the Commission 
proposed to implement this requirement on February 16, 2020, we 
conclude that a one-year timeframe is more reasonable to ensure timely 
implementation while affording affected parties a reasonable amount of 
time to take the necessary steps to come into compliance.
    173. In an ex parte filing, IT&E requests that we exempt fixed 
telephone providers in U.S. territories from dispatchable location 
requirements, noting that one of the territories it serves has no 
street address database available and that territorial PSAPs do not 
have the capability to receive automated location information. To the 
extent that fixed telephony providers face limitations in providing 
automated dispatchable location due to factors beyond the provider's 
control, such providers may request relief under the Commission's 
waiver process.
3. Interconnected VoIP
    174. In the NPRM, the Commission proposed to revise the E911 rules 
for interconnected VoIP to require the provision of dispatchable 
location for 911 calls. The Commission stated that with respect to 
fixed VoIP, it regards the current Registered Location approach as 
sufficient to support dispatchable location. With respect to nomadic 
VoIP, the Commission sought comment on the feasibility of providing 
automatic real-time dispatchable location but also proposed to allow 
VoIP providers to fall back to using Registered Location and manual 
updates if providing automated dispatchable location is not feasible or 
cost-effective. As discussed below, we adopt dispatchable location 
requirements that distinguish between fixed and non-fixed 
interconnected VoIP services.\20\ Also, we extend this requirement to 
``outbound only'' interconnected VoIP providers as well as two-way 
interconnected VoIP providers covered by the current VoIP E911 rules.
---------------------------------------------------------------------------

    \20\ Fixed VoIP services are services that provide the 
functional equivalent of fixed telephony by means of a device that 
connects to a single access point and is not capable of being moved 
by the end user. Non-fixed VoIP services are VoIP services that 
enable the end user to connect a handset or other IP-enabled device 
to multiple access points. Such services are variously described as 
``nomadic'' or ``mobile'' VoIP, depending on the degree of 
functional mobility that the service allows the end user. We use the 
term ``non-fixed VoIP'' to refer to the full range of such services, 
except where referring to comments that specifically discuss nomadic 
or mobile VoIP. We also note that the term ``non-fixed VoIP'' does 
not extend or apply to Commercial Mobile Radio Services that are 
subject to our wireless E911 rules.
---------------------------------------------------------------------------

a. Fixed VoIP
    175. With regard to fixed interconnected VoIP, commenters generally 
agree with the Commission's tentative conclusion that Registered 
Location is already providing dispatchable location for single-family 
dwellings, and that using Registered Location to provide additional 
information for fixed VoIP serving multi-story dwellings is readily 
achievable in the near term. For example, VON states that it 
``generally agrees with the Commission's tentative assessment that 
current Registered Location obligations are sufficient to meet the 
definition of dispatchable location, and that such location information 
is already being conveyed.'' VON further suggests that fixed VoIP 
providers have incentives to provide additional location information, 
noting that ``customers now demand the ability to provide additional 
location information, including room and floor information where 
applicable, and VON members respond to these customer requirements.''
    176. We adopt our proposal to require that fixed VoIP services 
providers transmit dispatchable location with each 911 call. While 
dispatchable location may be determined by means of a customer-
generated Registered Location in the fixed VoIP context (to the extent 
a physical location conveys a street address that is validated), it 
must be provided automatically to the PSAP by the VoIP service 
provider, without additional action by the caller, at the time the 911 
call is made. As in the case of our requirements for fixed MLTS and 
fixed telephony, and for the same reasons, this requirement will take 
effect one year from the effective date of the rules adopted in this 
order.\21\
---------------------------------------------------------------------------

    \21\ INCOMPAS requests that the Commission ``extend the 
compliance deadline for fixed services and give all providers two 
years to comply with these new obligations.'' However, the record 
confirms that providing dispatchable location within a year is 
technically feasible for fixed services.
---------------------------------------------------------------------------

    177. VON, however, also argues that the existing Registered 
Location rules are sufficient to ensure the provision of dispatchable 
location, and therefore no additional requirements for fixed VoIP 
providers are necessary. We reject VON's argument that there is no need 
to apply the new dispatchable location rules to fixed VoIP providers. 
Although the rules preserve the existing option of relying on 
Registered Location to provide the caller's location, they also 
establish a new requirement for providing dispatchable location 
automatically. Our inclusion of fixed VoIP in the new rules furthers 
the RAY BAUM'S Act objective of ensuring that dispatchable location is 
provided for all 911 calls regardless of the technological platform 
used.

[[Page 66739]]

b. Non-Fixed VoIP
    178. The Commission sought comment in the NPRM on the feasibility 
of nomadic VoIP services providing automatic real-time dispatchable 
location, noting that ``automatic provision of location is preferable 
because end users under stress in emergency situations may have 
difficulty providing manual updates and the updating process may delay 
the 911 call or subsequent location and dispatch.'' The Commission 
sought comment on the capability of interconnected VoIP providers to 
dynamically determine the location of end users (1) when they are at 
home or their usual place of work, (2) when they move frequently 
between multiple locations, and (3) when they are at locations they do 
not regularly visit. The Commission also proposed to allow VoIP 
providers to fall back to using Registered Location if providing 
automated dispatchable location is not feasible or cost-effective. As a 
safeguard against sending incorrect location information, the 
Commission proposed that the VoIP provider ``identify whether the 
service is being used from a different location than the Registered 
Location, and if so, either: (1) Prompt the customer to provide a new 
Registered Location; or (2) update the Registered Location without 
requiring additional action by the customer.''
    179. As with non-fixed MLTS, we find that in the non-fixed VoIP 
environment, flexible rules and a longer time frame for providing 
accurate 911 location information are appropriate. In this respect, 
commenters generally agree on the desirability of automated validation 
of dispatchable location in the nomadic VoIP environment, but stress 
that there are challenges to providing such validation in many cases. 
RingCentral states that interconnected VoIP users ``increasingly use 
browser-based applications for calling, but browser-based 
applications--by design--do not have the capability of detecting a 
user's location unless that user opts-in to location detection.'' 
RingCentral states that similar challenges exist for users logging in 
with VPN, ``as it may not be possible to detect . . . the user's true 
location.'' Other commenters agree that the technology that would allow 
for automatic real-time dispatchable location for non-fixed VoIP users 
needs additional time to fully develop, and therefore agree with the 
Commission's proposal to allow providers to fall back to Registered 
Location options when dispatchable location is not feasible.
    180. The record further indicates that non-fixed VoIP providers 
continue to rely heavily on Registered Location, but that alternative 
approaches are increasingly available that could support automatic 
location in some instances. For example, NENA states that the emergence 
of software-based VoIP applications on mobile phones has made automatic 
location updates more technically and economically feasible. RedSky 
states that ``the technology exists'' to provide dispatchable location 
for nomadic users through device-based location methods. Microsoft 
states that commercially available location services can improve 
interconnected VoIP location in ways ``far more accurate and reliable 
than a `registered location' manually entered by the end-user[.]'' The 
ability of non-fixed VoIP providers to provide automated real-time 
dispatchable location is highly dependent on whether granular location 
information is available for the access point from which the 911 call 
is placed, and whether the VoIP provider has access to that 
information. In some environments, particularly when end users are away 
from their home or regular workplace, this information is either 
unavailable or the development of information sources that could be 
leveraged by VoIP providers to provide dispatchable location (e.g., 
databases with access point location information) is in early stages. 
Therefore, we adopt rules that require automatic provision of 
dispatchable location when technically feasible, but also allow non-
fixed VoIP providers to fall back on manual updating of Registered 
Location information by end users as a backstop approach.\22\
---------------------------------------------------------------------------

    \22\ We note that AT&T points out that automatic location 
solutions could raise network security concerns because some 
proposed solutions, which would have limited applicability, would 
involve scanning of the Data Link Layer (Layer 2) of IP networks, 
which would violate cybersecurity protocols and expose cyber 
vulnerabilities. AT&T states that solutions based on scanning 
networks may require customer disclosure of sensitive data, which 
they may be unwilling to give vendors because doing so would present 
a cybersecurity risk. In light of AT&T's concerns, providers may 
fall back on manual registered location if automatic solutions raise 
security concerns.
---------------------------------------------------------------------------

    181. We also conclude that it is important to encourage development 
of alternative approaches, based on the full range of device-based and 
other available location technologies, that place less burden on the 
end user than manual updates, and that can often provide more accurate, 
timely, and reliable location information for VoIP users that move 
frequently between multiple locations or are at locations they do not 
regularly visit. Such information may not always be precise enough to 
identify the caller's dispatchable location, but it can significantly 
reduce the potential for error or delay that otherwise occurs when a 
VoIP provider relies solely on Registered Location and uncertainty 
arises about whether the VoIP user is actually calling from that 
location. Commenters generally support giving interconnected VoIP 
providers the flexibility to provide alternative location information, 
including x/y/z coordinates, as a supplement or alternative to 
dispatchable location. Therefore, we give non-fixed VoIP providers 
flexibility to provide alternative location information, including 
coordinate-based information, from all available sources when providing 
dispatchable location is not technically feasible. This will provide 
flexibility for non-fixed VoIP providers to convey an accurate location 
to the PSAP while minimizing the burdens on the interconnected VoIP 
service provider and the end user.
    182. We recognize that where a non-fixed VoIP provider provides 
alternative location information, the location fix may be less precise 
than a location that pinpoints the caller's location down to the room, 
office, or apartment level. We find that the record strongly supports 
allowing less precise--but still actionable--alternative location 
information as a fallback approach when providing dispatchable location 
is not technically feasible. Therefore, as an alternative to automated 
dispatchable location or end users' manual updating of Registered 
Location information, we allow non-fixed VoIP providers to provide 
alternative 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.\23\ We 
also clarify that as a last resort, a VoIP provider may route a 911 
call to a national emergency call center for the operator to ask the 
caller about his or her location, so long as the provider has made a 
good-faith effort to obtain location data from all available 
alternative location sources. We also conclude that the two-year 
transition period established by this order is appropriate for 
implementation of these requirements, as it is consistent

[[Page 66740]]

with implementation timeframes recommended by a number of industry 
commenters, provides time for development and deployment of 
improvements in technology that can refine the nomadic VoIP location 
process, including improvements to location databases and commercially 
available device-based technologies, and coincides with implementation 
of milestones intended to improve in-building location of wireless 911 
calls under the Commission's wireless location accuracy rules.
---------------------------------------------------------------------------

    \23\ We agree that the MLTS and interconnected VoIP location 
rules do not overlap, and that providers should be subject to only 
one set of requirements for any particular service they provide. If 
a service meets the definition of interconnected VoIP service in 
section 9.3 of our newly adopted rules, it will be subject to the 
interconnected VoIP location rules and not the MLTS location rules.
---------------------------------------------------------------------------

c. Outbound-Only Interconnected VoIP
    183. Consistent with Congress's approach of establishing regulatory 
parity across technological platforms and enabling the completion of 
outgoing 911 calls and messages from people in emergency situations, we 
adopt 911 location requirements for outbound-only interconnected VoIP 
providers. The requirements we adopt today are flexible and 
technologically neutral from a compliance standpoint and serve a vital 
public safety interest. We amend the definition of ``Interconnected 
VoIP Service'' used for 911 purposes to include outbound-only 
interconnected VoIP services that generally permit users to initiate 
calls that terminate to the PSTN. We thus require outbound-only 
interconnected VoIP providers to comply with our 911 obligations, 
including the requirement to notify subscribers of any limitations to 
E911 service. However, we modify the notification requirement to 
clarify that it may be satisfied through stickers or warning labels, or 
other conspicuous means, provided that the notification is prominently 
displayed or highlighted in a manner that makes it likely to be seen by 
the customer.\24\ Similar to our discussion of nomadic VoIP service 
above, we require outbound-only interconnected VoIP service providers, 
which are now encompassed by our amended language in the Sec.  9.3 
definition of ``Interconnected VoIP Service,'' to provide (1) 
dispatchable location if feasible, or, otherwise, either (2) manual 
updating of Registered Location information; or (3) alternative 
location information sufficient to identify the caller's civic address, 
floor level, and approximate floor location in large buildings. We 
require outbound-only interconnected VoIP providers to comply with the 
911 requirements we adopt today two years after the effective date of 
the rules.
---------------------------------------------------------------------------

    \24\ In this regard, inclusion of the notification in the fine 
print of an online customer agreement would not be sufficient.
---------------------------------------------------------------------------

    184. RAY BAUM'S Act directs the Commission to ``conclude a 
proceeding to consider adopting rules to ensure that the dispatchable 
location is conveyed with a 9-1-1 call, regardless of the technological 
platform used.'' RAY BAUM'S Act also states that, ``[i]n conducting the 
proceeding . . . the Commission may consider information and 
conclusions from other Commission proceedings regarding the accuracy of 
the dispatchable location for a 9-1-1 call . . . .'' RAY BAUM'S Act 
defines a ``9-1-1 call'' as a voice call that is placed, or a message 
that is sent by other means of communication, to a PSAP for the purpose 
of requesting emergency services.
    185. Consistent with RAY BAUM'S expansive approach, which 
recognized the Commission's existing 911 authority, the Commission 
broadly sought comment on what communications services not covered by 
existing 911 rules but that are capable of making 911 calls may fall 
within this definition. In the NPRM, the Commission asked whether (1) 
outcomes for 911 callers would be improved if it adopted 911 rules for 
these communications services that parallel existing rules, including 
any requirements for conveying dispatchable location and (2) new rules 
that are specifically tailored for those communications services would 
be more effective at improving outcomes. Specifically, the Commission 
observed that some outbound-only VoIP services partner with businesses 
that offer 911 smartphone applications that allow consumers to make 
calls to 911 and that 911 stakeholders have expressed concerns that 
calls received from these services may route to the incorrect PSAP, 
result in fraudulent calls, lack critical location information 
capabilities, and place the 911 caller at risk. The Commission noted 
that the current rules do not require outbound-only VoIP services to 
support 911 or convey dispatchable location with 911 calls, but it 
recounted that in 2011 the Commission sought comment on expanding 911 
obligations to providers of outbound-only interconnected VoIP services.
    186. The Commission has broad authority over interconnected VoIP 
services and 911. The RAY BAUM'S Act provided the Commission the 
flexibility to consider whether and how to apply dispatchable location 
requirements to services that provide the capability for users to make 
a 911 call, which includes outbound-only interconnected VoIP. We 
believe that the expansive scope of the legislative directive provides 
legal authority for the Commission to adopt regulations that will 
ensure dispatchable location data are conveyed with 911 calls with any 
voice service that satisfies the definition of ``9-1-1 call,'' 
including outbound-only interconnected VoIP service. It also leaves 
room to amend the definition of ``Interconnected VoIP Service'' at 
Sec.  9.3 pursuant to the NET 911 Improvement Act and the CVAA.
    187. We find that, from a 911 perspective, outbound-only 
interconnected VoIP services are functionally equivalent to landlines 
and other interconnected devices that connect to the PSTN and are 911-
capable, and thus, we should require outbound-only interconnected VoIP 
service providers to comply with 911 obligations. As noted by West 
Safety, ``[f]rom a caller's perspective, interconnected outbound-only 
VoIP service is, for the most part, similar to traditional telephone 
service, and its users reasonably expect it to function the same.'' To 
illustrate further, Microsoft's Skype voice application facilitates 
internet-based calls yet also provides users the ability to call any 
landline or mobile device. Failing to require support for 911 services 
by outbound-only calling services that are able to place PSTN calls to 
any other North American Numbering Plan telephone number treats 
similarly-situated services differently and enables and rewards 
regulatory arbitrage. Moreover, treating these services inconsistently 
or 911 purposes is likely to breed consumer confusion, particularly 
when a caller is seeking help in a time of crisis.
    188. Some commenters submit that the essential basis of Commission 
regulation of outbound-only VoIP services is whether those services 
would substitute for traditional telephone service. However, as 
discussed above, our 911 rules already apply to interconnected VoIP (as 
currently defined to refer to both inbound and outbound 
interconnection), and the Commission proposed extending those 
obligations to outbound-only interconnected VoIP more than eight years 
ago. To use Skype to call regular phones, consumers pay by purchasing 
credits, subscribe to Skype for unlimited calls, or buy a Skype phone 
number. Additionally, Skype emergency calling is enabled in certain 
countries, platforms, and versions of Skype software. Moreover, our 
current approach enables providers to avoid basic public interest 
obligations by offering purportedly separate ``outbound-only'' and 
``inbound-only'' calling services, even though these services combined 
are functionally

[[Page 66741]]

equivalent to traditional calling services and, in a regulatory sleight 
of hand, avoid basic public interest obligations. We decline to 
maintain this regulatory loophole to the benefit of one segment or 
market participants over another, and to the detriment of consumers.
    189. Some commenters support expanding 911 obligations to outbound-
only VoIP services on the grounds that consumers increasingly rely on a 
variety of interchangeable communications services to place 911 calls 
and expect those services to connect them to first responders. Others, 
however, argue that consumer expectations regarding outbound-only VoIP 
do not warrant imposing any obligations.
    190. As an initial matter, we decline to make consumer expectations 
the touchstone for determining what types of services should be subject 
to 911 obligations. In this context, the relevant RAY BAUM'S Act 
provisions do not refer to consumer expectations; rather, they define 
``9-1-1- call'' broadly, in relevant part, as ``a voice call that is 
placed, or a message that is sent by other means of communication, to a 
public safety answering point . . . for the purpose of requesting 
emergency services.'' The statutory focus, therefore, is on enabling 
the user to reach emergency services to request assistance, 
``regardless of the technological platform,'' not on whether the 
service bears similarity to a traditional two-way phone call or whether 
consumers perceive it as such. Our decision to subject outbound-only 
VoIP service to 911 obligations is most consistent with Congress's 
focus on ensuring that all messages from a person to emergency services 
are received, regardless of the technology employed. A focus on 
consumer expectations, by contrast, would frustrate the statute by 
disadvantaging those people who were unaware that a particular device 
or technology was incapable of dialing 911--precisely the tragic 
circumstance that led to the adoption of Kari's Law.
    191. In any event, we find that consumer expectations generally 
support our decision today. We find that consumer expectations on this 
issue have significantly changed since 2011. In this respect, we give 
significant weight to the fact that the increasing variety of 
interchangeable voice services on the market has changed the public's 
expectations about access to 911, and our rules today reflect those 
expectations. We are persuaded by BRETSA's comments that the fact that 
Microsoft has enabled emergency calling with Skype in some European 
countries and Australia demonstrates that 911 calling can be provided 
in the United States. BRETSA also asserts that it is more important for 
callers to be able to reach 911 in an emergency than that a PSAP can 
reconnect a dropped call, and we agree.
    192. The commenters who assert that consumers do not expect to 
reach 911 from outbound-only systems present little data that support 
their position. In particular, Microsoft, VON, and INCOMPAS oppose the 
Commission's proposed expansion of 911 obligations to outbound-only 
VoIP calling applications, arguing that users of one-way calling 
capabilities do not expect to reach emergency services on these tools 
and do not use them for emergency calling. Microsoft adds that it 
voluntarily deployed emergency calling on its one-way, outbound-only 
calling feature Skype to Phone (formerly SkypeOut) in four foreign 
countries (Australia, Denmark, Finland, and the United Kingdom) and 
that only 1,788 emergency calls were made in those four countries in 
the most recent 23-month period. According to Microsoft, ``[t]he low 
emergency call volumes are evidence that consumers do not expect to 
have the capability to make emergency calls through Skype desktop and 
tablet applications and, when this capability is provided to them, they 
tend not to use it.'' Microsoft also states that many emergency calls 
placed from this calling feature lasted less than one minute, 
``strongly suggesting accidental or nefarious calls to emergency 
services since valid emergency calls tend to last longer than a 
minute.'' Commenters argue that consumers do not expect to use 
outbound-only VoIP services to place emergency calls, in part because 
some expected features of 911 calling, specifically PSAP callback, are 
not readily available. Thus, according to Microsoft and INCOMPAS, the 
Commission would be creating consumer expectations for 911 services 
where certain features that customers have come to expect with 
emergency calling are technically not feasible. Microsoft and INCOMPAS 
also contend that expanding 911 rules to outbound-only VoIP will 
increase nuisance or accidental calls to emergency services, which is 
not in the public interest.\25\
---------------------------------------------------------------------------

    \25\ Microsoft analogizes its argument to the Commission's 1996 
decision to extend emergency calling requirements to non-service-
initialized (NSI) phones, which similarly lacked callback 
capabilities, by requiring carriers to forward to PSAPs 
automatically all 911 calls from wireless mobile handsets which 
transmit a code identification, without requiring user validation or 
any similar procedure. Although the Commission has acknowledged that 
fraudulent 911 calls from NSI devices impose a substantial burden on 
PSAPs, we disagree with Microsoft that this is a result of the lack 
of the callback feature.
---------------------------------------------------------------------------

    193. We find these arguments unpersuasive. First, it is 
unsurprising that some consumers may not presently expect outbound-only 
calling services to support 911 dialing and location services, as they 
have not been obligated to do so. In this respect, though, we disagree 
with the view that the Commission should refrain from acting for fear 
of ``creating'' expectations regarding the availability of 911 
services; to the contrary, the Commission should act where it finds a 
need to support public safety. Second, the data presented prompt us to 
draw the opposite inference on calls to emergency services from 
SkypeOut in four foreign countries than that asserted by Microsoft. 
Rather than indicating that 911 connectivity was not expected in these 
instances, we find the existence of these calls is instead evidence 
that at least some users expected--and needed--to call for help via 
SkypeOut. We may further infer that as use of these services becomes 
more widespread, the expectations carried with these services will 
align with traditional voice services. That domestic expectations have 
also evolved with the technology is reflected in the congressional 
emphasis that the Commission should consider whether dispatchable 
location obligations apply ``regardless of the technological 
platform.'' Furthermore, concerns about overly broad regulation are 
misplaced because we apply the change in a limited way--solely to 911 
obligations on outbound-only interconnected VoIP service providers. 
Finally, the possibility that there may be nuisance or inadvertent 
calls to 911 from outbound-only services is not a sufficient reason to 
exclude such services from the 911 obligations applicable to 
interconnected VoIP service providers, thereby providing no access to 
911 for callers with legitimate emergency needs to use these services. 
While we recognize that accidental or nuisance calls can strain already 
limited PSAP resources, there has been no demonstration that these 
calls would overwhelm PSAP capabilities.\26\
---------------------------------------------------------------------------

    \26\ Microsoft speculates that relying on end users to manually 
update their location information could create an additional risk 
that applications like Skype could be downloaded easily by a 
nefarious actor who could then ``input a false location, and then a 
make a 911 call for the purpose of dispatching public safety 
resources to a particular location under false pretenses.'' We find 
this argument implausible. For one, interconnected VoIP providers 
are already required to require their end users to register a 
location for 911 calls, and yet the record presents no evidence that 
this is a problem today. Given that distinguishing feature between 
such services and outbound-only interconnected VoIP services is 
solely the lack of a callback feature--which is unrelated to the 
problem Microsoft alleges--we see no reason to think improper 
location information will suddenly become a problem should Microsoft 
be required to allow its SkypeOut users call emergency services 
effectively. More broadly, nefarious actors can give false 
information to a PSAP via any technological platform--and there is 
nothing distinctive about outbound-only interconnected VoIP services 
that would lead us to believe including them would have a material 
impact. What is more, we do not mandate registered locations to be 
collected but instead empower providers to use other technologies to 
facilitate dispatchable location or alternative location information 
for such 911 calls--and of course we expect providers like Microsoft 
to take into account the risks to public safety it has flagged when 
choosing how to comply with our rules. Finally, to the extent that 
Registered Location still presents any ``additional risk,'' as 
Microsoft posits, that risk is outweighed by the need for people to 
be able call 911 and for emergency responders to find them.

---------------------------------------------------------------------------

[[Page 66742]]

    194. Several commenters support expanding 911 dispatchable location 
requirements to outbound-only VoIP services, and state that technically 
feasible solutions exist for such service providers to provide that 
data. Comtech states ``it is imperative that any location requirements 
adopted for 911-capable services take into consideration the current 
state of technology and its rapid rate of change.'' Verizon indicates 
that, like nomadic VoIP, the Commission should clarify that nomadic 
outbound services could use either dispatchable locations or registered 
locations because the same concerns raised in the context of nomadic 
VoIP services apply.
    195. We find that it is technically feasible to require outbound-
only interconnected VoIP service providers to convey the dispatchable 
or alternate location requirements we adopt today. The location 
requirements for outbound-only interconnected VoIP service providers 
allow for flexible, technologically neutral compliance. Although the 
NPRM sought comment on such communications services that are not 
covered by existing 911 rules yet are capable of making a 911 call and 
their ability to convey location information to the PSAP, no commenters 
submit that it is not possible for outbound-only interconnected VoIP 
providers to convey such location information. With the additional 
compliance time provided below, we anticipate that such a capability 
can be readily applied within the United States.
    196. 911 VoIP Service. The Commission sought comment on expanding 
the scope of those IP-based services subject to our 911 rules to 
include not only interconnected VoIP but to also include ``911 VoIP 
Services,'' which was proposed to include those services that enable 
real-time, two-way voice communications that require IP-compatible 
customer premises equipment and permit users generally to initiate a 
911 call, even if the service does not permit users generally to 
receive calls that originate on the PSTN, thus encompassing those 
services that are considered ``outbound only VoIP.'' The Commission 
further stated its intent to retain the existing definition of 
``Interconnected VoIP Service'' to avoid inadvertent impact on the term 
as used by various non-911 statutory provisions. By proposing a new 
``911 VoIP Service'' category for use in the Commission's 911 rules, 
the Commission sought to avert unintended consequences.
    197. We conclude that the best approach to achieve what the public 
interest demands is to amend the definition of ``Interconnected VoIP 
Service'' to expand those services subject to our 911 rules, rather 
than to adopt a separate ``911 VoIP Service'' definition. In this 
respect, we find that the definition of ``911 VoIP Service'' proposed 
in the NPRM mirrors the existing definition of ``Interconnected VoIP 
Service,'' with the exception that the fourth element of the proposed 
definition does not reference calling numbers or interconnection to the 
PSTN and is limited to 911 calls. Amending the definition of 
``Interconnected VoIP Service'' to include outbound-only VoIP services 
solely for purposes of extending our 911 obligations is consistent with 
our intent to apply only this set of obligations to such services, but 
in a manner that responds to record comments and avoids the unintended 
consequences to other uses of the term. For example, some commenters 
express concerns with the proposed definition of ``911 VoIP Service'' 
and the applicability of our 911 requirements, including dispatchable 
location, to those services. Verizon states that the Commission's 
proposal to apply the interconnected VoIP 911 rules, including the 
registered location choice, to newly defined outbound-only ``911 VoIP 
Services'' may be overbroad. Verizon asserts that it is unclear that 
outbound-only VoIP meets the New and Emerging Technologies (NET) 911 
Improvement Act standard of ``widely accepted and fungible substitutes 
for telephony'' if there are no other connections to the public 
switched telephone network. According to Verizon, the proposed rule 
also is unclear because it would require that calling party number 
information be provided on all 911 VoIP services, which could enable 
callback for a service that supports both outbound and inbound calling, 
but ``would not help for outbound-only services.''
    198. Accordingly, we decline to adopt the defined term ``911 VoIP 
Service'' and instead add an additional category of services that 
constitute interconnected VoIP for the purposes of 911 obligations to 
expand the scope of services to those that are generally capable of 
allowing users to initiate calls that terminate to the public switched 
telephone network, including calls to 911.\27\ We expand the definition 
of ``Interconnected VoIP Service'' in Sec.  9.3 of the Commission's 
rules to mean a service that permits users generally to terminate calls 
to the public switched telephone network.\28\
---------------------------------------------------------------------------

    \27\ We acknowledge that some voice applications may provide 
users with both interconnected and non-interconnected VoIP services 
and emphasize that applicability of our 911 requirements to 
interconnected VoIP service providers hinges on whether the service 
satisfies all prongs of the definition, including interconnection to 
the PSTN.
    \28\ We note that the definition we adopt today tracks more 
closely to the existing definition of ``Interconnected VoIP 
Service'' as it is currently defined to refer to both inbound and 
outbound interconnection than the definition proposed in the 2011 
NPRM, which permitted users to terminate calls to all or 
substantially all United States E.164 telephone numbers. As we 
describe above, this is in-line with our intended approach to 
minimize disruption to the current definition of ``Interconnected 
VoIP Service'' in section 9.3 of the Commission's rules.
---------------------------------------------------------------------------

    199. We concur with BRETSA's concerns that outbound-calling voice 
applications or service providers could configure their services for 
the specific purpose of avoiding 911 compliance. As a result, the 
definition of ``Interconnected VoIP Service'' extends 911 calling 
requirements to interconnected, outbound-only VoIP services that 
generally permit users to terminate calls to the public switched 
telephone network. We further clarify that the revisions we adopt today 
preserve the application of the original definition of ``Interconnected 
VoIP Service'' to other parts of the Commission's rules while expanding 
those services to which the Commission's 911 rules apply. Thus, the 
non-911 statutory provisions and rules that reference the current 
definition of ``Interconnected VoIP Service'' in Sec.  9.3 of the 
Commission's rules are not disturbed.\29\ Consistent with the directive 
of RAY BAUM'S Act, and as supported by the record, we find that 
expansion of the location requirements to interconnected VoIP service, 
which includes outbound-only interconnected VoIP service, enacts 911 
rules that are flexible and technologically neutral from a

[[Page 66743]]

compliance standpoint while limiting regulatory disruption.
---------------------------------------------------------------------------

    \29\ We further clarify that outbound-only interconnected VoIP 
services, which are now encompassed within the section 9.3 
definition of ``Interconnected VoIP Service,'' are still considered 
non-interconnected VoIP services for the purposes of section 716 of 
the Communications Act of 1934, and therefore remain subject to part 
14 of the Commission's rules.
---------------------------------------------------------------------------

    200. Some commenters also argue that expanding 911 requirements to 
``911 VoIP Services'' exceeds the scope of the Commission's statutory 
authority under the NET 911 Improvement Act. Microsoft states that the 
Commission has not proposed a sufficient basis of statutory authority 
to impose emergency calling obligations on outbound-only voice 
applications, and contends that the NET 911 Improvement Act provided 
the Commission authority to establish emergency calling requirements 
for IP-enabled voice services, which were defined to be synonymous with 
``Interconnected VoIP Service.'' However, Microsoft asserts that the 
NPRM ``does not propose to expand or modify the definition of 
`interconnected VoIP service' to include outbound-only calling apps. 
Nor does it propose an independent basis for imposing these 
requirements on applications that currently satisfy the statutory 
definition of `non-interconnected VoIP.' '' As a result, Microsoft 
claims that the Commission's proposal would ``involve an extraordinary 
expansion of the scope of the FCC's regulatory authority and would 
exceed the limits of reasonable statutory interpretation.''
    201. We disagree that expanding 911 requirements to the underlying 
services that would have met our proposed definition of ``911 VoIP 
Services'' exceeds the scope of the Commission's authority under the 
NET 911 Improvement Act, particularly when coupled with the directive 
of RAY BAUM'S Act.\30\ In this respect, by amending the definition of 
interconnected VoIP we meet both the letter and spirit of both laws, 
which provides the Commission discretion and flexibility to address new 
technologies. We find that Congress, in directing the Commission to 
consider all technological platforms, intended the Commission to 
consider 911 obligations for these technologies. Moreover, the NET 911 
Improvement Act provides that ``[i]t shall be the duty of each IP-
enabled voice service provider to provide 9-1-1 and enhanced 9-1-1 
service to its subscribers in accordance with the requirements of the 
Federal Communications Commission, as in effect on the date of 
enactment of the [NET 911 Improvement Act] . . . and as such 
requirements may be modified by the Commission from time to time.'' 
Pursuant to subsequent legislation, the Commission also retains ample 
authority to amend the definition of interconnected VoIP. As a result, 
we find that the Commission has direct statutory authority to modify 
the definition of ``Interconnected VoIP Service'' to include outbound-
only interconnected VoIP, and today we modify that definition.
---------------------------------------------------------------------------

    \30\ To the extent commenters argued that the Commission lacks 
statutory authority to create a ``911 VoIP Services'' definition 
that includes non-interconnected VoIP, we conclude that the issue is 
moot as we are not addressing those services at this time.
---------------------------------------------------------------------------

    202. Although in the NPRM the Commission stated its intention to 
avoid disturbing the existing definition of interconnected VoIP since 
it is referenced by various non-911 statutory provisions and rules, we 
find that our approach to amending the definition of ``Interconnected 
VoIP Service'' in Sec.  9.3 of the Commission's rules satisfies our 
proposed intent and responds to concerns raised by commenters. 
Specifically, to implement RAY BAUM'S Act, the Commission led with a 
proposal to adopt the definition of ``911 VoIP Services'' and also 
sought comment on extending 911 requirements, including location 
obligations, to outbound-only VoIP services under the definition of 
``911 VoIP Services.'' We note that entities which provide one-way, 
interconnected VoIP service have been on notice since 2011, and even as 
early as 2005, that the Commission was considering expanding the scope 
of its 911 rules to include their communications services. The NPRM was 
informed by, and cited to, these earlier rulemaking efforts, including 
the outstanding proposals from 2011, and RAY BAUM'S Act left the 
Commission discretion to consider these earlier efforts. The rule we 
adopt today reflects consideration of proposals raised in earlier 
Notices of Proposed Rulemaking and in the NPRM to extend dispatchable 
location obligations to one-way VoIP calls, the purpose of the NPRM to 
dispatch our RAY BAUM'S Act mandate to consider all technological 
platforms, and record comment received in response. In light of the 
comments received, we have not amended our definition of interconnected 
VoIP, except as it affects 911 service obligations for outbound-only 
interconnected VoIP service.
    203. Furthermore, as stated above, commenters express concern about 
our statutory authority to expand our 911 rules to services beyond 
interconnected VoIP services, and in response we act upon their 
suggestion that an amendment of the definition of ``Interconnected VoIP 
Service'' would accomplish the Commission's intended objective, 
particularly where we limit the definition change solely to impose 911 
obligations. Moreover, the similarities in the proposed language of the 
definition of ``911 VoIP Services'' largely tracks the language of 
``Interconnected VoIP Service,'' and as such, regardless of the label 
used, the service to which our rules were to be applied is sufficiently 
apparent.
    204. We amend the definition of ``Interconnected VoIP Service'' to 
include outbound-only interconnected VoIP services. The expansive scope 
of the legislative directive coupled with our discretion to amend the 
definition of ``Interconnected VoIP Service'' provides sufficient legal 
authority for the Commission to extend 911 regulations, including rules 
to convey dispatchable location with 911 calls, to outbound-only 
interconnected VoIP services. Doing so in this fashion also avoids 
loopholes for evading regulatory obligations that protect the health 
and safety of the American people, which commenters have pointed out to 
be a risk of attaching such obligations only to those who choose to 
provide ``911 VoIP Services.'' We believe that this approach is 
consistent with our objective to promote safety of life and property 
through communications.
    205. Compliance Deadline. In the NPRM, the Commission proposed to 
require compliance for dispatchable location requirements on the same 
date as the proposed implementation for Kari's Law, i.e., February 16, 
2020. The Commission further tentatively concluded that applying the 
same compliance date across all platforms will promote efficiency and 
encourage development of common dispatchable location solutions. No 
commenters addressed compliance deadlines for outbound-only 
interconnected VoIP service providers, but some commenters objected to 
the proposed February 16, 2020 date as premature for imposition of 
dispatchable location requirements for any service.
    206. We adopt a two-year period for compliance for outbound-only 
interconnected VoIP service. Due to the similar nomadic or mobile 
functionality of the services, we find that similar implementation 
considerations for nomadic VoIP providers are applicable to outbound-
only interconnected VoIP providers and warrant additional time for 
compliance. Furthermore, adopting a two-year compliance period for 
outbound-only interconnected VoIP service providers will result in a 
compliance date in the same time frame as the implementation deadline 
for wireless E911 location requirements, which will promote regulatory 
parity and encourage the development of common location solutions 
across all platforms.

[[Page 66744]]

4. Telecommunications Relay Services (TRS)
    207. In the NPRM, the Commission observed that TRS providers are 
required to deliver emergency calls to an appropriate PSAP and to 
provide the location of the emergency. For some of these services, the 
service provider is required to ask callers for their location 
information at the beginning of the emergency call. For emergency calls 
made through a Video Relay Service (VRS) or IP Relay (collectively, 
``internet-based TRS''), the service provider must transmit location 
information to the PSAP in the form of a Registered Location under 
rules modelled on the Commission's interconnected VoIP 911 rules. In 
the NPRM, the Commission observed that ``internet-based TRS and 
interconnected VoIP face similar concerns regarding the ability to 
accurately locate end users that use a mobile or portable device.'' The 
Commission therefore proposed dispatchable location requirements for 
internet-based TRS paralleling the requirements it proposed for VoIP, 
i.e., allowing internet-based TRS providers flexibility to implement 
automated dispatchable location and to fall back to Registered Location 
options when real-time dispatchable location is not feasible. The 
Commission asked whether there are differences between internet-based 
TRS and interconnected VoIP that might require taking a different 
approach to TRS dispatchable location, and sought comment on 
alternative approaches.
    208. We adopt flexible rules for internet-based TRS that largely 
parallel our rules for fixed and nomadic VoIP. In this respect, TRS 
commenters express many of the same views as VoIP commenters on the 
feasibility of providing automatic real-time dispatchable location. 
Sorenson and CaptionCall state that ``the technology for automatically 
locating mobile users is advancing rapidly and the technology for 
locating nomadic VoIP subscribers is improving, though it is still not 
reliable in every instance.'' Nevertheless, ``[i]f solutions are not 
technically feasible for over-the-top VoIP services, whether mobile or 
nomadic, they will not be technically feasible for internet-based TRS 
providers involved in call routing.'' Sorenson also states that in 
certain situations, internet-based TRS providers lack the capability to 
automatically detect whether a videophone or device has changed 
location, in which case the only remaining option is to prompt users to 
confirm or update their locations. Sorenson and other commenters 
therefore support the Commission's proposal that internet-based TRS 
providers should have the option to fall back to Registered Location 
when dispatchable location is not feasible.
    209. TRS commenters also support being given flexibility to provide 
alternative location information when more precise location information 
is not available. Sorenson and CaptionCall state that ``x,y,z needs to 
be a permissible alternative to dispatchable location, and may be 
necessary as location solutions evolve technologically.'' Sorenson 
states that when its ability to use device-based location is fully 
implemented and operational ``the customer's device will automatically 
determine an x, y (and, where available, z) location estimate,'' 
provided the consumer has consented to allowing the VRS application to 
access location information from the device. In an ex parte filing, 
Sorenson and CaptionCall propose to require internet-based TRS 
providers to provide dispatchable location when it is available but to 
permit automatic geolocation when the dispatchable location is 
unavailable. If neither a dispatchable location nor geolocation 
information is available, their proposal would allow the provider to 
provide the Registered Location. Sorenson and CaptionCall also propose 
to specify in the rules that an internet-based TRS provider can use a 
back-up call center when the provider is not confident that it can 
otherwise reliably identify the caller's location.
    210. We find that in the internet-based TRS environment, flexible 
rules and a longer time frame for providing accurate 911 location 
information are appropriate. The record indicates that internet-based 
TRS providers continue to rely heavily on Registered Location, but that 
alternative approaches are increasingly available that could support 
automated dispatchable location in some instances.
    211. For 911 calls from fixed internet-based TRS,\31\ beginning one 
year from the effective date of the rules, we require internet-based 
TRS providers to provide automated, validated dispatchable location for 
each call. For 911 calls from non-fixed internet-based TRS,\32\ 
beginning two years from the effective date of the rules, we require 
internet-based TRS providers to provide with each 911 call (1) 
automated dispatchable location, if technically feasible, or, 
otherwise, either (2) manual updating of Registered Location, or (3) 
alternative 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 when the 
first two are not technically feasible.
---------------------------------------------------------------------------

    \31\ We define TRS fixed services to include hardware-based TRS 
and videophone equipment that are professionally installed and 
cannot be moved by the customer without professional assistance.
    \32\ We define TRS nomadic and mobile services to include TRS 
facilities that use software-based endpoints.
---------------------------------------------------------------------------

    212. TRS commenters also identify a distinction between IP 
captioned telephone services (IP CTS), and relay services such as VRS 
and IP Relay. Commenters state that call set-up and routing for most IP 
CTS calls are handled by the user's underlying voice provider rather 
than the TRS provider. In case of a 911 call, the IP CTS Communications 
Assistant provides captioning but is not able to speak directly with 
the parties or generate location information, much less provide it to 
the PSAP. Sorenson and CaptionCall jointly suggest that the Commission 
should separate the dispatchable location requirements for VRS from the 
requirements for IP CTS, ``allow[ing] each service to be treated in an 
appropriate manner.'' Further, with respect to IP CTS, Sorenson and 
CaptionCall state that the ability of web/wireless IP CTS applications 
to provide information other than Registered Location is dependent upon 
the capabilities of underlying nomadic or mobile VoIP providers. To 
afford IP CTS providers time to implement these capabilities, they 
propose that the Commission set the implementation date for IP CTS one 
year after the implementation date for nomadic or mobile VoIP.
    213. We clarify that these requirements do not apply to TTY-based 
TRS providers, or to internet-based TRS providers who completely rely 
on their customers' underlying voice service providers to handle 
emergency call set-up, routing, and provision of location information. 
In such cases, it is not necessary to impose requirements on the TRS 
provider because the underlying service provider is subject to the 
relevant 911 requirements, including location requirements, in 
connection with the call. Next, we are dismissing Sorenson and Caption 
Call's request to set the implementation date for IP CTS one year after 
the implementation date for non-fixed VoIP because the location rules 
we adopt herein provide sufficient flexibility including fall back to 
Registered Location, and they only apply to IP CTS providers that 
handle call set-up and routing.

[[Page 66745]]

    214. We also clarify that the rules do not require TRS providers to 
automatically detect when a device is being used at a different 
location from the Registered Location to the extent doing so is not 
technically feasible. The record indicates that such detection is not 
technically feasible for some internet-based TRS providers. In such 
cases, the requirement can be met by a manual prompt to the user asking 
for confirmation whether the user is at the Registered Location or a 
different location.
    215. We agree with commenters regarding routing of calls to 
Emergency Calling Relay Centers as a last resort in the occasional case 
where neither a prompt for a manual update nor any alternative 
technology confirms the validity of the caller's location or otherwise 
provides actionable dispatchable location information. In those 
isolated cases, we will allow internet-based TRS providers to route the 
call to an Emergency Calling Relay Center, so long as the provider has 
made a good-faith effort to obtain location data from all available 
alternative location sources.
    216. Finally, we find that our TRS location rule amendments herein 
do not conflict with the IP CTS emergency calling requirement rule 
proposals in, or prejudge the outcome of, the IP CTS Reform Further 
Notice. The Commission did not propose any changes to location 
requirements in the IP CTS emergency call handling rules. We crafted 
our new TRS location rules so that they will harmonize with the 
proposed IP CTS emergency call handling rules in the event the latter 
are adopted, as well as with the existing TRS rules in the event that 
the proposed IP CTS emergency call handling rule amendments are not 
adopted. Further, the Commission noted that ``issues regarding location 
determination by IP CTS providers, as well as other TRS providers, will 
be addressed in that docket,'' which refers to the instant docket.
5. Mobile Text
    217. In the NPRM, the Commission noted that our current Text-to-911 
rules require mobile carriers and other covered text providers to 
obtain location information sufficient to route text messages to the 
appropriate PSAP, but text providers are not required to convey 
additional location information to the PSAP. The Commission stated that 
this approach has always been viewed as an interim solution, and noted 
the prior pending proposal in the Text-to-911 docket to require covered 
text providers to deliver enhanced location information (consisting of 
the best available location information that covered text providers can 
obtain from any available location technology or combination of 
technologies, including device-based location). In the NPRM, the 
Commission sought to refresh the record on text-to-911 location and 
asked whether to apply dispatchable location requirements to text-to-
911, if it is technically feasible, consistent with requirements 
applied to other platforms.
    218. The record indicates that the location technology options 
available to covered text providers have significantly expanded since 
the Commission adopted its text-to-911 rules five years ago. For 
example, commenters point to recent improvements in technology that 
have the potential to provide location information for an increasing 
percentage of 911 texts. First, wireless carriers note that they are 
starting to transition mobile wireless text services from SMS to more 
robust IP-enabled platforms, such as real-time text, which can support 
provision of location information with 911 texts using some of the same 
location methodologies that are used to support IP-based voice 
services. Second, Comtech and West Safety note the potential to use the 
device-based location capabilities of mobile handsets (e.g., Google's 
Emergency Location Service in Android devices) to generate location 
information, which can then be sent via text to the PSAP.
    219. However, the transition away from SMS texting is far from 
complete, and the technologies being used to support text-to-911 
location, while promising, have not yet been demonstrated to be capable 
of consistently supporting either dispatchable location or enhanced 
location accuracy comparable to the level of accuracy required for 
wireless voice services. In this respect, wireless carriers commenting 
on this issue caution against requiring them to implement dispatchable 
location capabilities in SMS-based text-to-911, which would require 
major retrofitting of legacy SMS networks that were not designed to 
support the provision of location information. Commenters express 
uncertainty about (1) when text-to-911 will fully migrate from SMS-
based texting to newer technologies, and (2) how soon device-based 
location for 911 texts will be universally available. Comtech states 
that ``some of the technological challenges that must be overcome to 
improve location information for text-to-911, when compared to wireless 
voice 911 location information, include: (1) The current configuration 
of mobile handsets, (2) the types of location technologies and 
protocols supported by mobile handsets, and (3) the availability of 
real-time location platforms across each individual carrier.'' 
Consequently, while some commenters support establishing enhanced 
location requirements for text-to-911, others argue that such 
requirements are premature.
    220. We therefore conclude that it would be premature to adopt 
dispatchable location requirements for text-to-911 comparable to the 
requirements applicable to other services covered by this order. 
Instead, we adopt a flexible approach to text-to-911 location 
requirements. We require covered text providers, within two years of 
the effective date of these rules, to provide (1) dispatchable 
location, if technically feasible, or, otherwise, either (2) end-user 
manual provision of dispatchable location, or (3) enhanced location 
information, which may be coordinate-based, consisting of the best 
available location that can be obtained from any available existing 
technology or combination of technologies at reasonable cost. We 
clarify that the latter requirement does not require covered text 
providers to retrofit SMS-based text networks or to upgrade legacy 
mobile handsets that are only SMS-capable. We recognize that as a 
practical matter, covered text providers are unlikely to be capable of 
providing dispatchable location for most 911 texts, and that the 
quality of ``best-available'' location information provided with 911 
texts may vary. Nevertheless, we believe that over time this 
requirement will encourage development of improved location 
capabilities for text-to-911, while accounting for technical 
feasibility issues raised in the current record.
6. Comparison of Benefits and Costs
    221. In order to quantify the magnitude of the benefits to the 
public when dispatchable location is conveyed with a 911 call from MLTS 
and other communications services identified in the NPRM, the 
Commission anticipated that the increase in location accuracy that 
results from the use of dispatchable location will reduce the arrival 
time of ambulances for some 911 callers at least as much as was 
accomplished by the mobile location rules adopted in the Indoor 
Location Fourth Report and Order. In that Report and Order, the 
Commission found that the location accuracy improvements adopted for 
mobile 911 calls had the potential to save approximately 10,120 lives 
annually for an annual benefit of approximately $92 billion. Based on 
available 911 call volume data in the

[[Page 66746]]

Commission's Ninth Annual Report and 911 Fees, the Commission estimated 
that approximately 75% of 911 calls come from mobile phones, which 
already are required to convey a dispatchable location. However, the 
Commission believed the remaining 25% of calls to which its proposed 
rules would apply will realize benefits. Because three times as many 
calls come from mobile phones as from non-mobile sources, the 
Commission estimated that the proposed rules have the potential to save 
a maximum of one third of the 10,120 lives that were projected to be 
saved annually by the mobile location rules adopted in the Indoor 
Location Fourth Report and Order, or 3,373 lives annually. However, 
because some providers already convey location information that is 
equivalent to dispatchable location, the Commission expected that the 
dispatchable location rules will save considerably fewer lives.
    222. In the NPRM, the Commission assumed that the proposed rules 
would save 506 lives annually, or only one twentieth of the lives that 
it projected would be saved by the mobile location rules. The 
Commission relied on the U.S. Department of Transportation's estimate 
that the ``Value of a Statistical Life'' (VSL), defined as ``the 
additional cost that individuals would be willing to bear for 
improvements in safety (that is, reductions in risks) that, in the 
aggregate, reduce the expected number of fatalities by one,'' is $9.6 
million. In doing so, the Commission estimated that the 506 lives saved 
by the proposed rules multiplied by the VSL establishes a benefit floor 
of $4.9 billion. The Commission sought comment on the reasonableness of 
its estimate, what other benefits can be expected to accrue, such as 
(but not limited to) reduced complications from medical issues, reduced 
damage to property, increased likelihood of forestalling crime and 
apprehending suspects, and increased confidence in the 911 system and 
emergency responders.
    223. No commenter disagreed with the Commission's analysis of the 
benefits that the public should expect from the implementation of 
improved location accuracy requirements for MLTS and other services. 
Additionally, public safety commenters support improvements to location 
accuracy for calls to 911 from MLTS and other services, provided that 
dispatchable location information is validated. The Texas 9-1-1 
Entities submit that ``as legacy TDM landline continues to transition 
to IP as the dominant market solution, 9-1-1 calls are becoming 
increasingly less distinguishable based solely on technological 
platform.'' ``While consistency alone warrants that the definition of 
`dispatchable location' be the same across the Commission's 9-1-1 rules 
regardless of technological platform (e.g., CMRS, fixed telephone/
legacy landline, MLTS),'' the Texas 9-1-1 Entities argue, ``this is 
particularly important as technological platforms morph and evolve 
(e.g., fixed wireless, mobile VoIP, Wi-Fi calling) and no longer fit 
neatly into traditionally defined and differentiated categories.'' The 
Texas 9-1-1 Entities and MESB illustrate that validation is 
particularly necessary in an evolving IP environment, which appears 
vulnerable to 911 calls being misrouted across state lines and placing 
increased burdens on resource-limited PSAPs to re-route 911 calls to 
the appropriate jurisdiction.
    224. Additionally, of the total reported calls to 911 in 2017, 
155,231,318 calls came from wireless phones, representing approximately 
70% of the total reported call volume. In addition, the ratio of 
wireless calls to total reported call volume remained steady even 
though there was a 135% increase in VoIP calls from 2016 and a 378% 
increase in the number of calls reported as ``Other'' from 2016 (VoIP 
calls reported in 2017 increased to 7,666,958 from 5,661,055 in 2016 
and the number of calls reported as ``Other'' increased to 8,907,760 
from 2,353,291 in 2016). While the Bureau believes that the 70% figure 
likely understated the percentage of wireless 911 calls because a 
number of states reported total 911 calls but did not break out all 
service categories separately, it is also likely that the Tenth Annual 
Fee Report underestimated the increase in VoIP and ``Other'' calls 
given that half of reporting jurisdictions did not report call volume 
for those categories. Thus, the record suggests that the problem of 
inaccurate location information or no location information being 
conveyed with a 911 call from MLTS and other 911 services is common and 
will continue to grow and potentially undermine public confidence in 
location accuracy of such calls absent a requirement for validated 
location information.
    225. In the NPRM, the Commission proposed a dispatchable location 
implementation schedule across all technological platforms that tracked 
the February 16, 2020, compliance date for Kari's Law. The Commission 
sought comment on the costs of the proposed rules in the NPRM. The 
Commission observed that ``911 location solutions that are capable of 
conveying dispatchable location to PSAPs are already offered by several 
MLTS market participants.'' Further, the Commission noted that 
``several states already place requirements on MLTS providers to obtain 
and convey location information that is more detailed than street 
address alone, [footnote omitted] and we therefore conclude that MLTS 
manufacturers are producing and widely selling equipment that is 
capable of complying with our proposed rules.'' The Commission asked 
commenters to address whether there are any cases ``in which currently-
available equipment will not be suitable.'' In addition, the Commission 
observed that ``to comply with current rules, interconnected VoIP 
service providers and internet-based TRS providers today obtain 
customers' Registered Location, which we believe would likely be 
sufficient to satisfy our proposed dispatchable location requirements 
in many circumstances.'' Because these dispatchable location-capable 
solutions and equipment are already being widely offered by MLTS 
manufacturers, installers, and operators, the Commission stated its 
belief ``that the implementation costs of our proposed dispatchable 
location rules to these entities would be negligible in most 
respects.'' The Commission also expressed its belief ``that our 
approach of granting flexibility in satisfying our proposed rules 
minimizes the potential cost of compliance.'' Accordingly, the 
Commission sought comment on these observations and tentative 
conclusions.
    226. As the Commission emphasized in the NPRM, we do not mandate 
any particular technology or model for implementing the 911 location 
rules we adopt today and apply these requirements on a technologically 
neutral basis. Moreover, service providers can leverage existing 
location technology solutions to mitigate costs. Further, we adopt a 
phased-in approach that allows service providers additional time beyond 
the February 16, 2020, proposal in the NPRM to come into compliance 
with our rules. Additionally, we have tailored the compliance deadlines 
to each particular service. Further, we apply our rules on a 
prospective basis, thus minimizing cost on legacy systems and small 
businesses. We find that applying our rules to these legacy systems 
would be too costly because there is such a great variety of systems 
that location technology solutions would have to be tailored for each 
enterprise. That said, the record demonstrates that delivering 
dispatchable location is technically feasible today for many services 
at a cost that is less than the $4.9 billion minimum benefit floor. 
Consistent with our approach in the Wireless Indoor Accuracy Fourth 
Report and Order, this means that MLTS and other service

[[Page 66747]]

providers subject to our 911 location rules need only choose the 
methods necessary to close the gap between already-deployed 
capabilities and the Commission's requirements, ``rather than starting 
from scratch.'' So, although the cost of meeting our 911 location rules 
has not yet been determined to a dollar amount, the rules we adopt 
today provide MLTS and service providers a clear reference point from 
which to factor in compliance costs incrementally. We provide the 
following analysis of comments addressing compliance costs.
    227. Compliance Costs. In the NPRM, the Commission estimated that 
the annual cost to MLTS operators to provide location information as 
proposed would be less than $49.6 million, and that such costs are 
likely to decline within a few years as databases and other sources of 
location information become increasingly centralized. The Commission 
also estimated a $460,000 per-provider cost for 18 providers of 
Interconnected VoIP, VRS, and IP Relay services to implement software 
upgrades that would detect when an end user's location has changed and 
to identify the new location. The Commission also sought comment on 
implementation costs for outbound-only VoIP providers. No commenter 
objected to the costs estimated in the NPRM. One commenter, however, 
suggested that the Commission over-estimated the costs associated with 
building a ``white pages like directory'' or database and software 
development costs.
    228. Industry commenters recognize that accurate location 
information can be critical in ensuring a timely emergency response, 
including for vulnerable populations such as TRS users. Commenters 
suggest that providers of fixed MLTS, fixed telephony, and 
interconnected VoIP already provide dispatchable location, while some 
are concerned that applying dispatchable requirements to nomadic or 
remote, off-site MLTS could undermine incentives to use innovative 
solutions. The record reflects that industry has incentives to continue 
to improve 911 location capabilities and desires flexibility to adopt 
911 solutions. However, industry commenters generally warn against 
applying rigid, overly-granular, ``one-size fits all'' dispatchable 
location mandates by February 16, 2020, that could be unduly burdensome 
on evolving technologies. For example, Sorenson and CaptionCall note 
that ``the technology for automatically locating mobile users is 
advancing rapidly and the technology for locating nomadic VoIP 
subscribers is improving, though it is still not reliable in every 
instance.'' Microsoft suggests that prematurely applying such 
requirements would be unachievable and ``runs the risk of preventing 
the use of readily available location technologies that can vastly 
improve the current location capabilities of MLTS and iVoIP, 
particularly nomadic MLTS and iVoIP services.'' Ad Hoc advises that 
``the Commission should not impose obligations on MLTS owners or 
operators to transmit any type of information that their MLTS equipment 
is not technically capable of transmitting or that would require 
assumption of any unreasonable costs to upgrade.'' Cisco expresses 
concerned that ``[a] dispatchable location requirement would also 
amount to a de facto mandate for enterprise customers to purchase 
third-party solutions that may be cost-prohibitive or ineffective.''
    229. Cost Mitigation. Notwithstanding the lack of cost data, 
commenters suggest measures to mitigate potential costs and complexity 
of compliance, including enshrining the principles of technological 
neutrality, flexibility and maintaining service specific 911 rules. The 
requirements we adopt today are measured, technically feasible, and 
technologically neutral, so that service providers can choose the most 
effective solutions from a range of options. In addition, our 
requirements allow sufficient time for advance planning and deployment 
of new location technology, beyond the February 16, 2020 compliance 
date proposed in the NPRM.
    230. The record demonstrates that the scale of the potential 
benefits will increase over time given the magnitude of the problem we 
are facing, industry's incentives to improve 911 location accuracy, and 
the fact that the requirements that we adopt today will render the 
conveyance of dispatchable location an even more effective emergency 
response tool as technology improves and becomes more widely available.
    231. Outbound-only Interconnected VoIP. In the NPRM, the Commission 
acknowledged potential technical challenges for outbound-only 
interconnected VoIP services to automatically send a caller's 
dispatchable location to a local PSAP during a 911 emergency. 
Commenters submitted estimates for the costs of such a mechanism. 
Precision Broadband, for example, noted in its ex parte its service of 
mapping a consumer broadband IP address to a dispatchable location, and 
projected ``an expenditure of between $200 million and $275 million per 
year for the Fixed Broadband 911 system at full nationwide 
deployment.'' We obtained a similar estimate for full nationwide 
coverage through alternative means. We also note this is an upper bound 
but an extremely unlikely scenario as many outbound-only interconnected 
VoIP services already have provision for delivering their location. 
According to a 2016 study conducted by the Pew Research Center, 90% of 
smartphone users have location services enabled, meaning that these 
users can already be located automatically without the aid of a third-
party technology like the one proposed by Precision Broadband. We also 
believe that this statistic would apply to other devices with location 
service capabilities not just the smartphone. Moreover, this Pew 
statistic suggests there would be a similar willingness of consumers to 
enter the dispatchable location into applications. Thus, the costs 
imposed by this rule are for those consumers who neither have location 
services available nor enter an address. Because the $275 million 
figure presumes there are no location services available today, we 
conclude that the total cost would be $27.5 million (10% of $275 
million). We believe it is a reasonable expectation that of the 506 
lives saved, at least 25 lives (i.e., only 5% because, as explained 
above and in the NPRM, about 95% of interconnected devices already have 
location ability) will be from this part of the rule. Indeed, just 
three lives saved per year would fully cover the expected cost. 
Furthermore, there are a variety of flexible options to provide 911 
caller location information depending on the service, such as x-y-z 
coordinates or manually updated Registered Location, adding support for 
our finding that costs are likely to be on the lower end as we describe 
here. We therefore find the benefits exceed the estimated costs 
imposed.
    232. We also require outbound-only interconnected VoIP service 
providers to comply with the customer notification requirements of our 
rules. We require outbound-only interconnected VoIP service providers 
to comply with the 911 requirements we adopt today two years after the 
effective date of the rules. Regarding general 911 requirements that we 
extend to outbound-only interconnected VoIP, we envision that the costs 
for consumer notification and record-keeping would also be comparable 
to the information collection costs applicable to other interconnected 
VoIP service providers under the Commission's rules. In sum, the record 
indicates that the costs for outbound-only interconnected service

[[Page 66748]]

providers to comply with our 911 rules, including dispatchable 
location, will not differ from the costs to interconnected VoIP 
providers that our well-established rules already cover and for which 
we have previously found to have the benefits outweigh the costs.

C. Consolidating the Commission's 911 Rules

    233. In the NPRM, the Commission proposed to consolidate all the 
existing 911 rules into a single rule part. The Commission also 
proposed to simplify and streamline the rules in some instances and to 
eliminate corresponding duplicative rules in other rule parts. The 
Commission explained that rule consolidation will help to minimize the 
burden on small entities subject to the Commission's 911 rules by 
making it easier to identify and comply with all 911 requirements.
    234. The majority of commenters who addressed the issue support the 
proposed 911 rule consolidation. iCERT states that it does not object 
to a non-substantive rule reorganization, and TIA supports removal of 
rules that are obsolete. Hamilton provided the sole comment expressing 
opposition, arguing that relay service rules ``are integrated with non-
911 related rules in such a way that removing the 911-related rules and 
transferring them to part 9 would be cumbersome and counterproductive.
    235. We consolidate the existing 911 rules as proposed. To address 
Hamilton's concerns, we find that we can transfer and amend the relay 
service emergency calling rules without adversely affecting the 
integrity of the remaining non-911 relay service rules. The revised 
part 9 differentiates between platforms and services where needed, but 
it also enables service providers, PSAPs, and other stakeholders to 
refer to a single part of the Commission's rules to ascertain all 911 
requirements.
    236. As noted in Appendix A and described for reference in 
conversion tables in Appendix B, we designate part 9, which currently 
contains our interconnected VoIP rules, as the rule part that contains 
the consolidated 911 rules, and we transfer and consolidate our 
existing 911 rules from parts 12, 20, 25, and 64 to part 9. The revised 
part 9 will continue to differentiate between platforms where needed, 
but it will also enable service providers, PSAPs, and other 
stakeholders to refer to a single part of the Commission's rules to 
ascertain all 911 requirements. Specifically, we consolidate our 911 
rules as follows:
     Move relevant definitions for all services to subpart A of 
part 9;
     Move telecommunications carrier obligations (Sec.  64.3001 
et seq.) to subpart B of part 9;
     Move CMRS obligations (Sec.  20.18) to subpart C of part 
9;
     Move interconnected VoIP obligations (current part 9) to 
subpart D of part 9;
     Move emergency calling requirements for TRS providers 
(Sec. Sec.  64.604(a)(4) and 64.605) to subpart E of part 9;
     Place proposed MLTS rules in subpart F of part 9;
     Move emergency call center requirements for MSS providers 
(Sec.  25.284) to subpart G of part 9; and
     Move 911 resiliency, redundancy, and reliability 
requirements (part 12) to subpart H of part 9.
    In addition, as proposed in the NPRM, we remove Sec.  12.3, an 
obsolete 911 rule that references a one-time information collection 
that has been completed, rather than recodify it in part 9. The 
Commission also sought comment on whether to move Sec.  22.921 of the 
rules, which addresses 911 call processing procedures for analog 
telephones in the Cellular Radiotelephone Service, into part 9 or 
whether that rule has become obsolete and should be removed. As 
proposed in the NPRM, we remove Sec.  22.921 as obsolete.
    237. In proposing to consolidate the 911 rules, the Commission also 
invited commenters to identify any other rules that should be 
consolidated or updated. No commenters suggest additional rules for 
consolidation, but some commenters suggest substantive rule changes. 
Several of these suggestions concern 911 call routing issues. 
Specifically, BRETSA suggests that the Commission should require MLTS 
to be configured to route a 911 call to the PSAP serving the caller's 
location to cover cases where a different PSAP serves the enterprise's 
main office or location of the core MLTS equipment. MESB argues that 
federal intervention and enforcement mechanisms are needed to ensure 
accurate routing of 911 calls to the correct PSAP and accurate callback 
number delivery to the PSAP, noting that state MLTS statutes have not 
been successful in ensuring MLTS compliance with these requirements. 
BRETSA also suggests that the Commission propose a ``forward-looking'' 
location rule that would require all devices (e.g., all types of 
computers, tablets, and phones) used for voice, text, or video 
communications to incorporate GPS chipsets and other location 
technologies such as Wi-Fi, so that the devices are location-aware and 
are able to route 911 calls to the appropriate PSAP. RedSky suggests 
that the Commission should give telecommunications carriers the ability 
to transmit a 911 call through a third party such as an incumbent local 
exchange carrier, a VoIP Provisioning Center (VPC), its agent, or 
directly to an Emergency Services IP Network (ESINet) or its agent, 
rather than have to transmit a 911 call directly to a PSAP. In a 
similar vein, Texas 9-1-1 Entities request that the Commission allow 
911 calls to be routed through third-party call centers when 
dispatchable location, geographic coordinates, or registered location 
are not available. But MESB states that MLTS and VoIP 911 calls should 
not be allowed to routinely route to national call centers rather than 
the local serving PSAPs. BRETSA similarly states that Regional or 
national call centers are not a permissible alternative to proper 
configuration of an MLTS.
    238. Commenters suggest several other miscellaneous rule changes. 
Specifically, APCO suggests that the Commission should monitor 
consumers' use of new technological platforms for communications, and 
that the Commission consider further expanding the scope of the 911 
rules to take into account such platforms and prevent subtle technology 
distinctions from impacting communications with 911. Ad Hoc states that 
the Commission should modify Sec.  9.11(b)(5)(iii), which requires 
interconnected VoIP service providers to distribute stickers or other 
appropriate labels warning subscribers if E911 service may be limited 
or not available, to ``permit carriers to discharge their 
`notification/warning label' obligations differently for enterprise 
customers.'' BRETSA suggests an inquiry into 911 fees related to 
digital broadband facilities connected to an MLTS. RedSky suggests that 
the Commission should revisit consent decrees that an individual 
carrier or service provider may have entered into with the FCC or other 
body because such decrees ``serve to un-level the playing field.'' 
Next, RedSky, BRETSA, and APCO suggest modifying several terms in Sec.  
9.3 definitions. RedSky and BRETSA also suggest amendments to several 
definitions. Additionally, RedSky notes that several 911-related terms 
are missing from the part 9 terms and definitions, and Texas 9-1-1 
Entities proposes adding a term and definition. Finally, RedSky 
suggests retitling some rule section headings.
    239. While many of the suggestions described above may be worth 
pursuing separately, we decline to address them in this proceeding. The 
Commission stated that aside from the new MLTS and dispatchable 
location rules and deleting obsolete rules, the rule

[[Page 66749]]

revisions in this proceeding would simply entail consolidating our 
existing 911 rules without making substantive changes. Limited 
exceptions would include certain conforming and technical changes, such 
as harmonizing definitions of 911-related terms. We find that the 
commenters' suggestions go well beyond the scope of issues the 
Commission intended to address in this proceeding. We retain the 
discretion to address elsewhere, and parties have the option to file 
petitions for rulemaking or raise such issues in other appropriate 
proceedings.
    240. We do make ministerial conforming changes to certain other 
rules in light of our decision to consolidate the existing 911 rules 
into part 9. First, we found that part 1 contains several references to 
Sec.  20.18, which is being moved to part 9 as the new Sec.  9.10. 
Accordingly, we update those references to Sec.  9.10. Next, we found 
that four rules have references to part 20 governing CMRS. Since part 
20 will no longer cover CMRS 911 obligations after the relocation of 
Sec.  20.18 to Sec.  9.10, we are adding a reference to part 9 to each 
of the four rules to clarify the location of CMRS 911 rules. Since 
these changes are ministerial in nature and facilitate the part 9 rule 
consolidation, for which the Commission has already provided notice and 
allowed for comment, we find for good cause that notice and comment are 
unnecessary. Finally, we harmonize the Sec.  9.3 definition of 
``Registered internet-based TRS user'' to conform with the recently 
updated definition in part 64 of the Commission's rules. Because the 
Commission's proposed Sec.  9.3 definition of ``Registered internet-
based TRS user'' is sourced from Sec.  64.601(a), and because the 
Commission changed the definition in Sec.  64.601(a) in a proper 
rulemaking proceeding, we find for good cause that notice and comment 
to adopt the same definition change for part 9 are unnecessary.

IV. Procedural Matters

    241. Final Regulatory Flexibility Analysis. As required by the 
Regulatory Flexibility Act of 1980, as amended (RFA), the Commission 
has prepared a Final Regulatory Flexibility Analysis (FRFA) relating to 
this Report and Order. The FRFA is set forth in Appendix C.
    242. Paperwork Reduction Act Analysis. The requirements in 
Sec. Sec.  9.8(a) and 9.16(b)(3)(i), (ii) and (iii) constitute new 
information collections subject to the Paperwork Reduction Act of 1995 
(PRA), and the requirements in Sec. Sec.  9.8(a); 9.10(q)(10)(v); 
9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4); 9.11(b)(5)(ii); (iii); 
9.14(d)(2)(ii); (iii); 9.14(d)(2)(v); 9.14(d)(4); 9.14(e)(2)(ii); 
9.14(e)(2)(iv); 9.14(e)(4); 9.16(b)(3)(i); (ii); and (iii) constitute 
modified information collections. They will be submitted to the Office 
of Management and Budget (OMB) for review under section 3507(d) of the 
PRA. OMB, the general public, and other Federal agencies will be 
invited to comment on the new information collection requirements 
contained in this proceeding. This document will be submitted to OMB 
for review under section 3507(d) of the PRA. In addition, we note that, 
pursuant to the Small Business Paperwork Relief Act of 2002, we 
previously sought, but did not receive, specific comment on how the 
Commission might further reduce the information collection burden for 
small business concerns with fewer than 25 employees. We describe 
impacts that might affect small businesses, which includes more 
businesses with fewer than 25 employees, in the Final Regulatory 
Flexibility Analysis in Appendix C.
    243. Congressional Review Act. The Commission has determined that 
these rules are non-major under the Congressional Review Act, 5 U.S.C. 
804(2). The Commission will send a copy of this Report and Order to 
Congress and the Government Accountability Office pursuant to 5 U.S.C. 
801(a)(1)(A).
    244. Further Information. For further information, contact Brenda 
Boykin, Attorney-Advisor, Policy and Licensing Division, Public Safety 
and Homeland Security Bureau, (202) 418-2062 or via email at 
[email protected]; William Beckwith, Attorney-Advisor, Policy and 
Licensing Division, Public Safety and Homeland Security Bureau, (202) 
418-0134 or via email at [email protected]; Thomas Eng, 
Engineer, Policy and Licensing Division, Public Safety and Homeland 
Security Bureau, (202) 418-0019 or via email at [email protected]; Dr. 
Rasoul Safavian, Technologist, Policy and Licensing Division, Public 
Safety and Homeland Security Bureau, (202) 418-0754 or via email at 
[email protected].

V. Final Regulatory Flexibility Analysis

    245. As required by the Regulatory Flexibility Act of 1980, as 
amended (RFA), an Initial Regulatory Flexibility Analysis (IRFAs) was 
incorporated in the Notice of Proposed Rulemaking adopted in September 
2018 (NPRM). The Commission sought written public comment on the 
proposals in the NPRM including comment on the IRFA. The Comments 
received are discussed below. This Final Regulatory Flexibility 
Analysis (FRFA) conforms to the RFA.

A. Need for, and Objectives of, the Report and Order

    246. In the Report and Order, the Commission advances Congressional 
and Commission objectives to ensure that members of the public can 
successfully dial 911 to request emergency services and that Public 
Safety Answering Points (PSAPs) can quickly and accurately locate every 
911 caller, regardless of the type of service that is used to make the 
call. In 2018, the President signed into law Kari's Law Act of 2017 
(Kari's Law), which requires implementation of direct 911 dialing and 
on-site notification capabilities in a multi-line telephone system 
(MLTS), and Section 506 of RAY BAUM'S Act (RAY BAUM'S Act), which 
requires the Commission, within 18 months after the date of the 
legislation's enactment (March 23, 2018), to ``conclude a proceeding to 
consider adopting rules to ensure that the dispatchable location is 
conveyed with a 9-1-1 call, regardless of the technological platform 
used and including with calls from [MLTS].''
    247. The Report and Order implements Kari's Law by adopting direct 
dial and on-site notification rules governing calls to 911 made from a 
MLTS. The Commission takes the following actions:
     Adopts 911 direct dialing requirements as proposed in the 
NPRM, subject to clarification of some definitions and terms, including 
the term pre-configured.
     adopts a requirement that notification be sent to a 
location where someone is likely to hear or see it, but we do not 
require the location to be continuously staffed or monitored.
     requires the notification to include the fact that a 911 
call has been made, a valid callback number, and the same location 
information that is conveyed with the call to 911. However, we provide 
an exception for callback number and location information in 
circumstances where including this information in the notification 
would be technologically infeasible. We also require that initiation of 
the notification be contemporaneous with the call to 911, provided that 
it is technologically feasible to do so.
     requires an MLTS to be configured to provide notification 
for any caller on the system, including callers at satellite or branch 
locations.
     adopts the statutory definition of MLTS cited in Kari's 
Law and RAY BAUM'S Act. In addition, we interpret this definition to 
cover the full range of networked communications systems

[[Page 66750]]

that serve enterprises, including IP-based and cloud-based systems. We 
also interpret the definition to include outbound-only MLTS systems 
that allow users to make 911 calls but do not enable PSAPs to place a 
return call directly to the 911 caller.
     establishes February 16, 2020 as the compliance date for 
regulations implementing Kari's Law.
     adopts a presumption that if an MLTS fails to comply with 
the rules, the MLTS manager is responsible unless the manager can rebut 
the presumption by demonstrating compliance with its obligations under 
the statute and rules.
     declines to adopt disclosure requirements for legacy MLTS 
that are not subject to the requirements of Kari's Law and instead 
encourage enterprises to disclose the limitations on dialing 911 from 
legacy MLTS as part of voluntary best practices.
    248. As required by RAY BAUM'S Act, the Commission considered the 
feasibility of requiring dispatchable location for 911 calls from MLTS 
and other technological platforms that currently complete calls to 911, 
and established a dispatchable location requirement for MLTS 911 calls. 
In keeping with the directive in RAY BAUM'S Act to address dispatchable 
location for 911 calls ``regardless of the technological platform 
used,'' the Report and Order adds dispatchable location requirements to 
the Commission's existing 911 rules for fixed telephony providers, 
interconnected Voice over Internet Protocol (VoIP), Telecommunications 
Relay Services (TRS), Video Relay Services (VRS), and mobile text. 
Finally, consistent with RAY BAUM'S Act, we do not make any changes to 
the Commission's existing rules for CMRS providers to provide 
dispatchable location.
    249. More specifically, consistent with RAY BAUM'S Act the 
Commission adopts the following definition of dispatchable location and 
alternative location information:
     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 our 
existing rules.
    250. For MLTS systems subject to Kari's Law, we separately address 
dispatchable location requirements for MLTS 911 calls from (1) fixed 
devices and non-fixed devices being used on-premises, and (2) non-fixed 
devices being used off-premises. Accordingly, the Commission adopts the 
following dispatchable location rules:
    [cir] MLTS 911 calls from fixed devices: One year after the 
effective date of the rules, MLTS must provide automated dispatchable 
location with each 911 call.
    [cir] MLTS 911 calls from non-fixed devices:
    [cir] On-premises MLTS 911 calls from non-fixed devices: Two years 
after the effective date of the rules, MLTS must provide (1) automated 
dispatchable location, if technically feasible, or, otherwise, either 
(2) end-user manually-updated dispatchable location, or (3) alternative 
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.
    [cir] Off-premises MLTS 911 calls from off-premises devices: Two 
years after the effective date of the rules, MLTS must provide (1) 
automated dispatchable location, if technically feasible, or, if 
otherwise, either (2) end-user manually-updated dispatchable location, 
or (3) 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.
    251. For other services currently subject to 911 requirements 
(Fixed Telephony, Interconnected Voice over Internet Protocol (VoIP), 
Telecommunications Relay Service (TRS) and mobile text, the Commission 
adopts the following requirements:
    [cir] Fixed Telephony: One year after the effective date of the 
rules, service providers must deliver automated dispatchable location 
with each 911 call.
    [cir] Interconnected VoIP:
    [cir] Fixed interconnected VoIP: One year after the effective date 
of the rules, service providers must deliver automated dispatchable 
location with each 911 call or Registered Location. Dispatchable 
location may be provided by means of a customer-generated Registered 
Location, under the same terms and conditions specified in our current 
VoIP 911 rules, or by automatic provision of dispatchable location by 
the VoIP service provider, without additional action by the caller, at 
the time the 911 call is made.
    [cir] Non-fixed interconnected VoIP: Two years after the effective 
date of the rules, service providers must provide (1) automated 
dispatchable location, if technically feasible, or, otherwise, either 
(2) manual updating of Registered Location information, or (3) 
alternative 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. If the 
provider is unable to obtain or confirm the caller's location, the 
provider may route the call to a national emergency call center.
    [cir] Outbound-only interconnected VoIP: For purposes of compliance 
with our 911 rules, we amend the definition of ``Interconnected VoIP 
Service'' in Sec.  9.3 of the Commission's rules to include ``outbound-
only'' interconnected VoIP services that permit users generally to 
terminate calls to the public switched telephone network and extend the 
Interconnected VoIP location requirements described above to such 
providers.
     Telecommunications Relay Services
    [cir] Fixed TRS: One year after the effective date of the rules, 
service providers must deliver automated dispatchable location with 
each 911 call.
    [cir] Non-fixed TRS: Two years after the effective date of the 
rules, service providers must provide (1) automated dispatchable 
location, if technically feasible, or, otherwise, either (2) manual 
updating of Registered Location information, or (3) alternative 
location information sufficient to identify the caller's civic address 
and approximate in-building location, including floor level, in large 
buildings. If the provider is unable to obtain or confirm the caller's 
location, the provider may route the call to a national emergency call 
center.
     Mobile Text: Two years after the effective date of the 
rules, covered text providers must provide (1) automated dispatchable 
location, if technically feasible, or, otherwise, either (2) end-user 
manually provisioned location information, or (3) enhanced location 
information consisting of the best available location that can be 
obtained from any available technology or combination of technologies 
at reasonable cost.
    252. Lastly, as the Commission proposed in the NPRM, the Report and 
Order consolidates the Commission's existing 911 rules, and the direct 
dialing and dispatchable location rules proposed in the NPRM, into a 
single rule part. The Commission historically has taken a service-
specific approach to 911, with the result that 911 requirements for 
different services are scattered across different sections of the 
agency's rules. Consolidating our 911 rules from these various rule 
sections

[[Page 66751]]

into a single rule part furthers the goal of recognizing that all the 
components of 911 function as part of a single system and enables 
service providers, emergency management officials, and other 
stakeholders to refer to a single part of the Commission's rules to 
more easily ascertain all 911 requirements.

B. Summary of Significant Issues Raised by Public Comments in Response 
to the IRFA

    253. There were no comments that specifically addressed the 
proposed rules and policies presented in the IRFA.

C. Response to Comments by the Chief Counsel for Advocacy of the Small 
Business Administration

    254. Pursuant to the Small Business Jobs Act of 2010, which amended 
the RFA, the Commission is required to respond to any comments filed by 
the Chief Counsel for Advocacy of the Small Business Administration 
(SBA), and to provide a detailed statement of any change made to the 
proposed rules as a result of those comments.
    255. The Chief Counsel did not file any comments in response to the 
proposed rules in this proceeding.

D. Description and Estimate of the Number of Small Entities to Which 
the Rules Will Apply

    256. The RFA directs agencies to provide a description of, and 
where feasible, an estimate of the number of small entities that may be 
affected by the rule changes. The RFA generally defines the term 
``small entity'' as having the same meaning as the terms ``small 
business,'' ``small organization,'' and ``small governmental 
jurisdiction.'' In addition, the term ``small business'' has the same 
meaning as the term ``small business concern'' under the Small Business 
Act. A ``small business concern'' is one that: (1) Is independently 
owned and operated; (2) is not dominant in its field of operation; and 
(3) satisfies any additional criteria established by the SBA.
    257. Multi-Line Telephone System Manufacturers, Importers, Sellers 
or Lessors. Neither the Commission nor the SBA has developed a specific 
small business size standard for MLTS manufacturers, importers, sellers 
or lessors. The closest applicable SBA category for entities 
manufacturing MLTS equipment used to provide wire telephone and data 
communications equipment, interconnected VoIP, non-interconnected VoIP, 
is Telephone Apparatus Manufacturing. The SBA size standard for 
Telephone Apparatus Manufacturing consists of all such companies having 
1,250 or fewer employees. U.S. Census Bureau data for 2012 show that 
there were 266 establishments that operated that year. Of this total, 
262 operated with fewer than 1,000 employees. Thus, under this size 
standard, the majority of firms in this industry can be considered 
small.
    258. Telephone Apparatus Manufacturing. This industry comprises 
establishments primarily engaged in manufacturing wire telephone and 
data communications equipment. These products may be stand-alone or 
board-level components of a larger system. Examples of products made by 
these establishments are central office switching equipment, cordless 
and wire telephones (except cellular), PBX equipment, telephone 
answering machines, LAN modems, multi-user modems, and other data 
communications equipment, such as bridges, routers, and gateways. The 
SBA has developed a small business size standard for Telephone 
Apparatus Manufacturing, which consists of all such companies having 
1,250 or fewer employees. U.S. Census Bureau data for 2012 show that 
there were 266 establishments that operated that year. Of this total, 
262 operated with fewer than 1,000 employees. Thus, under this size 
standard, the majority of firms in this industry can be considered 
small.
    259. Multi-Line Telephone System Operators, Installers and 
Managers. Neither the Commission nor the SBA has developed a specific 
small business size standard for MLTS operators, installers and 
managers. MLTS Operators, Installers and Managers cut across numerous 
industry segments and encompass all types of businesses and 
organization including for-profit, not-for-profit and government 
agencies. Thus, for purposes of this FRFA, we group entities operating, 
installing, and managing MLTS in the Small Businesses, Small 
Organizations and Small Government Jurisdictions description contained 
in paragraph 21 infra.
    260. All Other Telecommunications. The ``All Other 
Telecommunications'' category is comprised of establishments primarily 
engaged in providing specialized telecommunications services, such as 
satellite tracking, communications telemetry, and radar station 
operation. This industry also includes establishments primarily engaged 
in providing satellite terminal stations and associated facilities 
connected with one or more terrestrial systems and capable of 
transmitting telecommunications to, and receiving telecommunications 
from, satellite systems. Establishments providing internet services or 
voice over internet protocol (VoIP) services via client-supplied 
telecommunications connections are also included in this industry. The 
SBA has developed a small business size standard for All Other 
Telecommunications, which consists of all such firms with annual 
receipts of $32.5 million or less. For this category, U.S. Census 
Bureau data for 2012 show that there were 1,442 firms that operated for 
the entire year. Of those firms, a total of 1,400 had annual receipts 
less than $25 million and 15 firms had annual receipts of $25 million 
to $49,999,999. Thus, the Commission estimates that the majority of 
``All Other Telecommunications'' firms potentially affected by our 
action can be considered small.
    261. Computer Facilities Management Services. This industry 
comprises establishments primarily engaged in providing on-site 
management and operation of clients' computer systems and/or data 
processing facilities. Establishments providing computer systems or 
data processing facilities support services are included in this 
industry. The SBA has developed a small business size standard for 
Computer Facilities Management Services which consists of all such 
firms with annual receipts of $27.5 million or less. U.S. Census Bureau 
data for 2012 indicate that 4,828 firms operated the entire year. Of 
this total, 4,743 had annual receipts less than $25 million and 38 
firms had annual receipts of $25 million to $49,999,999. Thus, under 
the SBA size standard the majority of firms in this industry can be 
considered small.
    262. Other Computer Related Services (Except Information Technology 
Value Added Resellers). This industry comprises establishments 
primarily engaged in providing computer related services (except custom 
programming, systems integration design, and facilities management 
services). Establishments providing computer disaster recovery services 
or software installation services are included in this industry. The 
SBA has developed a small business size standard for Other Computer 
Related Services, which consists of all such firms with annual receipts 
of $27.5 million or less. For this category, U.S. Census Bureau data 
for 2012 indicate that 6,354 firms operated the entire year. Of this 
total, 6,266 had annual receipts less than $25 million and 42 firms had 
annual receipts of $25 million to $49,999,999. Thus, the Commission 
estimates that the majority of Other Computer Related Services firms in 
this industry can be considered small.

[[Page 66752]]

    263. Information Technology Value Added Resellers. Information 
Technology Value Added Resellers provide a total solution to 
information technology acquisitions by providing multi-vendor hardware 
and software along with significant value added services. Significant 
value added services consist of, but are not limited to, configuration 
consulting and design, systems integration, installation of multi-
vendor computer equipment, customization of hardware or software, 
training, product technical support, maintenance, and end user support. 
The SBA has developed a small business size standard for Information 
Technology Value Added Resellers which consists of all such companies 
having 150 or fewer employees. For this category, U.S. Census Bureau 
data for 2012 indicate that 6,354 firms operated the entire year. Of 
this total, 6,241 had less than 100 employees and 113 had 100-1,000 or 
more employees. Thus, the Commission estimates that the majority of 
Information Technology Value Added Resellers in this industry can be 
considered small.
    264. Data Processing, Hosting, and Related Services. This industry 
comprises establishments primarily engaged in providing infrastructure 
for hosting or data processing services. These establishments may 
provide specialized hosting activities, such as Web hosting, streaming 
services, or application hosting (except software publishing), or they 
may provide general time-share mainframe facilities to clients. Data 
processing establishments provide complete processing and specialized 
reports from data supplied by clients or provide automated data 
processing and data entry services. The SBA has developed a small 
business size standard for Data Processing, Hosting, and Related 
Services which consists of all such firms with annual receipts of $32.5 
million or less. U.S. Census Bureau data for 2012 indicate that 8,252 
firms operated the entire year. Of this total, 7,730 had annual 
receipts less than $25 million and 228 firms had annual receipts of $25 
million to $49,999,999. Thus, under this size standard the majority of 
firms in this industry are small businesses.
    265. Small Businesses, Small Organizations, Small Governmental 
Jurisdictions. Our actions, over time, may affect small entities that 
are not easily categorized at present. We therefore describe here, at 
the outset, three comprehensive small entity size standards that could 
be directly affected herein. First, while there are industry specific 
size standards for small businesses that are used in the regulatory 
flexibility analysis, according to data from the SBA's Office of 
Advocacy, in general a small business is an independent business having 
fewer than 500 employees. These types of small businesses represent 
99.9% of all businesses in the United States which translates to 28.8 
million businesses.
    266. Next, the type of small entity described as a ``small 
organization'' is generally ``any not-for-profit enterprise which is 
independently owned and operated and is not dominant in its field.'' 
Nationwide, as of August 2016, there were approximately 356,494 small 
organizations based on registration and tax data filed by nonprofits 
with the Internal Revenue Service (IRS).
    267. Finally, the small entity described as a ``small governmental 
jurisdiction'' is defined generally as ``governments of cities, 
counties, towns, townships, villages, school districts, or special 
districts, with a population of less than fifty thousand.'' U.S. Census 
Bureau data from the 2012 Census of Governments indicate that there 
were 90,056 local governmental jurisdictions consisting of general 
purpose governments and special purpose governments in the United 
States. Of this number there were 37, 132 General purpose governments 
(county, municipal and town or township) with populations of less than 
50,000 and 12,184 Special purpose governments (independent school 
districts and special districts) with populations of less than 50,000. 
The 2012 U.S. Census Bureau data for most types of governments in the 
local government category show that the majority of these governments 
have populations of less than 50,000. Based on these data we estimate 
that at least 49,316 local government jurisdictions fall in the 
category of ``small governmental jurisdictions.''
    268. Wired Telecommunications Carriers. The U.S. Census Bureau 
defines this industry as ``establishments primarily engaged in 
operating and/or providing access to transmission facilities and 
infrastructure that they own and/or lease for the transmission of 
voice, data, text, sound, and video using wired communications 
networks. Transmission facilities may be based on a single technology 
or a combination of technologies. Establishments in this industry use 
the wired telecommunications network facilities that they operate to 
provide a variety of services, such as wired telephony services, 
including VoIP services, wired (cable) audio and video programming 
distribution, and wired broadband internet services. By exception, 
establishments providing satellite television distribution services 
using facilities and infrastructure that they operate are included in 
this industry.'' The SBA has developed a small business size standard 
for Wired Telecommunications Carriers, which consists of all such 
companies having 1,500 or fewer employees. U.S. Census Bureau data for 
2012 show that there were 3,117 firms that operated that year. Of this 
total, 3,083 operated with fewer than 1,000 employees. Thus, under this 
size standard, the majority of firms in this industry can be considered 
small.
    269. Local Exchange Carriers (LECs). Neither the Commission nor the 
SBA has developed a size standard for small businesses specifically 
applicable to local exchange services. The closest applicable NAICS 
Code category is for Wired Telecommunications Carriers. Under the 
applicable SBA size standard size standard, such a business is small if 
it has 1,500 or fewer employees. U.S. Census Bureau data for 2012 show 
that there were 3,117 firms that operated for the entire year. Of this 
total, 3,083 operated with fewer than 1,000 employees. Thus, under this 
category and the associated size standard, the Commission estimates 
that the majority of local exchange carriers are small entities.
    270. Incumbent Local Exchange Carriers (Incumbent LECs). Neither 
the Commission nor the SBA has developed a small business size standard 
specifically for incumbent local exchange services. The closest 
applicable NAICS Code category is Wired Telecommunications Carriers. 
Under the applicable SBA size standard, such a business is small if it 
has 1,500 or fewer employees. According to U.S. Census Bureau data, 
3,117 firms operated the entire year. Of this total, 3,083 operated 
with fewer than 1,000 employees. Consequently, the Commission estimates 
that most providers of incumbent local exchange service are small 
businesses that may be affected by the rules and policies adopted. 
According to Commission data, one thousand three hundred and seven 
(1,307) Incumbent Local Exchange Carriers reported that they were 
incumbent local exchange service providers. Of this total, an estimated 
1,006 have 1,500 or fewer employees. Thus, using the SBA's size 
standard the majority of incumbent LECs can be considered small 
entities.
    271. Competitive Local Exchange Carriers (Competitive LECs), 
Competitive Access Providers (CAPs), Shared-Tenant Service Providers, 
and Other Local Service Providers. Neither the Commission nor the SBA 
has developed a small business size

[[Page 66753]]

standard specifically for these service providers. The appropriate 
NAICS Code category is Wired Telecommunications Carriers. Under that 
size standard, such a business is small if it has 1,500 or fewer 
employees. U.S. Census Bureau data for 2012 indicate that 3,117 firms 
operated during that year. Of that number, 3,083 operated with fewer 
than 1,000 employees. Based on these data, the Commission concludes 
that the majority of Competitive LECs, CAPs, Shared-Tenant Service 
Providers, and Other Local Service Providers are small entities. 
According to Commission data, 1,442 carriers reported that they were 
engaged in the provision of either competitive local exchange services 
or competitive access provider services. Of these 1,442 carriers, an 
estimated 1,256 have 1,500 or fewer employees. In addition, 17 carriers 
have reported that they are Shared-Tenant Service Providers, and all 17 
are estimated to have 1,500 or fewer employees. In addition, 72 
carriers have reported that they are Other Local Service Providers. Of 
this total, 70 have 1,500 or fewer employees. Consequently, the 
Commission estimates that most providers of competitive local exchange 
service, competitive access providers, Shared-Tenant Service Providers, 
and Other Local Service Providers are small entities.
    272. Interexchange Carriers (IXCs). Neither the Commission nor the 
SBA has developed a definition for Interexchange Carriers. The closest 
NAICS Code category is Wired Telecommunications Carriers. The 
applicable size standard under SBA rules is that such a business is 
small if it has 1,500 or fewer employees. U.S. Census Bureau data for 
2012 indicate that 3,117 firms operated for the entire year. Of that 
number, 3,083 operated with fewer than 1,000 employees. According to 
internally developed Commission data, 359 companies reported that their 
primary telecommunications service activity was the provision of 
interexchange services. Of this total, an estimated 317 have 1,500 or 
fewer employees. Consequently, the Commission estimates that the 
majority of interexchange service providers are small entities.
    273. Local Resellers. The SBA has developed a small business size 
standard for Telecommunications Resellers which includes Local 
Resellers. The Telecommunications Resellers industry comprises 
establishments engaged in purchasing access and network capacity from 
owners and operators of telecommunications networks and reselling wired 
and wireless telecommunications services (except satellite) to 
businesses and households. Establishments in this industry resell 
telecommunications; they do not operate transmission facilities and 
infrastructure. Mobile virtual network operators (MVNOs) are included 
in this industry. Under the SBA's size standard, such a business is 
small if it has 1,500 or fewer employees. U.S. Census Bureau data for 
2012 show that 1,341 firms provided resale services for the entire 
year. Of that number, all operated with fewer than 1,000 employees. 
Thus, under this category and the associated small business size 
standard, the majority of these resellers can be considered small 
entities. According to Commission data, 213 carriers have reported that 
they are engaged in the provision of local resale services. Of these, 
an estimated 211 have 1,500 or fewer employees. Consequently, the 
Commission estimates that the majority of Local Resellers are small 
entities.
    274. Wireless Telecommunications Carriers (except Satellite). This 
industry comprises establishments engaged in operating and maintaining 
switching and transmission facilities to provide communications via the 
airwaves. Establishments in this industry have spectrum licenses and 
provide services using that spectrum, such as cellular services, paging 
services, wireless internet access, and wireless video services. The 
appropriate size standard under SBA rules is that such a business is 
small if it has 1,500 or fewer employees. For this industry, U.S. 
Census Bureau data for 2012 show that there were 967 firms that 
operated for the entire year. Of this total, 955 firms had had 
employment of 999 or fewer employees and 12 had employment of 1000 
employees or more. Thus, under this category and the associated size 
standard, the Commission estimates that the majority of wireless 
telecommunications carriers (except satellite) are small entities.
    275. The Commission's own data--available in its Universal 
Licensing System--indicate that, as of August 31, 2018 there are 265 
Cellular licensees that will be affected by our proposed actions. The 
Commission does not know how many of these licensees are small, as the 
Commission does not collect that information for these types of 
entities. Similarly, according to internally developed Commission data, 
413 carriers reported that they were engaged in the provision of 
wireless telephony, including cellular service, Personal Communications 
Service (PCS), and Specialized Mobile Radio (SMR) Telephony services. 
Of this total, an estimated 261 have 1,500 or fewer employees, and 152 
have more than 1,500 employees. Thus, using available data, we estimate 
that the majority of wireless firms can be considered small.
    276. Wireless Communications Services. This service can be used for 
fixed, mobile, radiolocation, and digital audio broadcasting satellite 
uses. The Commission defined ``small business'' for the wireless 
communications services (WCS) auction as an entity with average gross 
revenues of $40 million for each of the three preceding years, and a 
``very small business'' as an entity with average gross revenues of $15 
million for each of the three preceding years. The SBA has approved 
these small business size standards. In the Commission's auction for 
geographic area licenses in the WCS there were seven winning bidders 
that qualified as ``very small business'' entities, and one that 
qualified as a ``small business'' entity.
    277. Wireless Telephony. Wireless telephony includes cellular, 
personal communications services, and specialized mobile radio 
telephony carriers. The closest applicable SBA category is Wireless 
Telecommunications Carriers (except Satellite). Under the SBA small 
business size standard a business is small if it has 1,500 or fewer 
employees. For this industry, U.S. Census Bureau data for 2012 show 
that there were 967 firms that operated for the entire year. Of this 
total, 955 firms had fewer than 1,000 employees and 12 firms has 1000 
employees or more. Thus under this category and the associated size 
standard, the Commission estimates that a majority of these entities 
can be considered small. According to Commission data, 413 carriers 
reported that they were engaged in wireless telephony. Of these, an 
estimated 261 have 1,500 or fewer employees and 152 have more than 
1,500 employees. Therefore, more than half of these entities can be 
considered small.

E. Description of Projected Reporting, Recordkeeping, and Other 
Compliance Requirements for Small Entities

    278. The Report and Order enacts rules that will affect the 
reporting, recordkeeping, and/or other compliance requirements of small 
businesses and enterprises of all sizes that are engaged in the 
business of manufacturing, importing, selling, leasing, installing, 
managing, or operating MLTS, provided that the MLTS is manufactured, 
imported, offered for first sale or lease, first sold or leased, or 
installed after February 16, 2020. The Report and

[[Page 66754]]

Order will also affect small businesses and enterprises that are 
engaged in the business of offering fixed telephony service, wireless 
telecommunications, interconnected VoIP service, and TRS. The 
Commission adopted these changes to implement Kari's Law and RAY BAUM'S 
Act, which collectively address the inability of callers to directly 
dial 911 from MLTS and a lack of accurate and critical location 
information necessary for a PSAP to dispatch emergency services to 
those in need because of the communications system used in making a 911 
call.
    279. The rules and compliance requirements the Commission adopted 
to implement the direct dialing and notification requirements of Kari's 
Law sought to balance the needs of stakeholders and maximize the public 
safety benefits. These benefits include potentially preventing 
fatalities, injuries, or property damage, improving emergency response 
time and access to emergency services, reducing delays in locating 911 
callers, narrowing the gap between MLTS 911 service capabilities 
relative to other communications services subject to 911 requirements, 
and driving further technology development. The Commission also sought 
to achieve the benefits of Kari's Law in a cost-effective manner. As a 
result, the rules adopted generally track the statutory requirements of 
Kari's Law, are technologically neutral, and leverage advances in 
technology to improve access to emergency services as envisioned by 
Congress.
    280. The adopted rules provide small businesses and other 
enterprises impacted by these requirements wide flexibility and adopt 
minimum criteria in direct dialing and notification requirements which 
should offset any potential burdens associated with compliance with our 
rules.
    281. Consistent with Kari's Law, the Commission establishes 
February 16, 2020, as the compliance date for regulations implementing 
Kari's Law. It declines to adopt disclosure requirements for legacy 
MLTS but, instead, encourages industry to consider disclosure and 
education as part of voluntary best practices. The Commission also 
adopts a presumption that if an MLTS fails to comply with the rules, 
the MLTS manager is responsible unless the manager can rebut the 
presumption by demonstrating compliance with its obligations under the 
statute and rules.
    282. Similar to its approach to implement the requirements of 
Kari's Law, the Commission sought to craft dispatchable location rules 
that leverage existing market-driven advances in technology to improve 
location accuracy, and that provide small businesses and others 
significant flexibility, are technology neutral, encourage innovation 
and allow a wide array of options to for compliance while minimizing 
the compliance burden and cost. Given the lack of cost data submitted 
in the record for meeting our 911 location rules or MLTS direct dialing 
and notification requirements, and in light of our flexible and 
technologically neutral approach to compliance, we do not believe 
compliance with these requirements will impose a significant economic 
burden for small businesses.
    283. Similarly, we do not believe that the new or modified 
information collection requirements in Sec. Sec.  9.8(a); 
9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4); 
9.11(b)(5)(ii); (iii); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v); 
9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); 9.16(b)(3)(i); 
(ii); and (iii), will be unduly burdensome on small businesses. Rather 
than unduly burden small entities, applying the new and modified 
information collections will promote 911 service and emergency 
response, which should benefit small governmental jurisdictions, small 
businesses, small equipment manufacturers, and small business 
associations by giving them greater confidence in 911 location 
accuracy. Moreover, the rules we adopt in the Report and Order provide 
regulatory flexibility to all entities, including small businesses, and 
encourage service providers to leverage technology to the extent 
possible to reduce the burden of the information collections adopted in 
the Report and Order. Additionally, the Report and Order establishes a 
one- to two-year period from the effective date of the rules before 
requiring compliance with the revised rules. We provide the following 
analysis:
    284. For compliance with the Commission's 911 requirements, 
interconnected VoIP service providers must collect and disclose certain 
information to third parties. OMB approved the information collection 
for Sec.  9.5 (redesignated Sec.  9.11) under OMB Control No. 3060-
1085. This collection applies to interconnected VoIP providers 
obtaining and updating registered location from their customers and 
placing that information into ALI databases. This collection also 
applies to interconnected VoIP providers' customer notification 
obligations. The Commission modifies the definition of interconnected 
VoIP, thus potentially increasing the number of respondents subject to 
these existing information collections. The Commission also changes the 
wording of Sec.  9.11's registered location requirements to facilitate 
the provision of automated dispatchable location, registered location, 
or alternative location information for 911 calls. Thus, we anticipate 
the burden and cost levels of these requirements would be comparable to 
the existing Registered Location and customer notification 
requirements, which OMB approved.
    285. TRS service providers must collect and disclose certain 
information to third parties for compliance with the Commission's 911 
rules. OMB approved the information collection for Sec.  64.604 
(redesignated as Sec.  9.14) under OMB Control No. 3060-1089. This 
collection applies to TRS service providers transmitting location 
information to the PSAP, making location information available to the 
appropriate PSAP through the ALI database, and obtaining location 
information from the user. The Commission makes changes to the wording 
of Sec.  9.14's registered location requirements to facilitate the 
provision of automated dispatchable location, registered location, or 
alternative location information for 911 calls. Thus, we anticipate the 
burden and cost levels of these requirements would be comparable to the 
existing location requirements, which OMB approved.
    286. Covered text providers must notify consumers that they must 
grant permission to covered text providers to access the device's 
location information to enable the delivery and routing of text 
messages to PSAPs (i.e. Text-to-911) under Sec.  20.18 (redesignated as 
9.10). OMB renewed the information collection under OMB Control No. 
3060-1204, ICR Reference No: 201802-3060-012. In this Report and Order, 
the Commission makes changes to the wording of Sec.  9.10's text-to-911 
requirements to facilitate the provision of dispatchable location or 
best available location information along with 911 text messages. Thus, 
we anticipate the burden and cost levels of these requirements will 
require covered text providers to update customer notification at a 
cost that would be comparable to the existing text-to-911 requirements, 
which OMB approved.
    287. Finally, new Sec.  9.8 requires providers of fixed telephony 
services to provide automated dispatchable location with 911 calls 
beginning one year after the effective date of this rule. Additionally, 
new Sec.  9.16(b)(3)(i), (iii) and (iii) specifies dispatchable 
location requirements for on-premises fixed telephones; on premises 
non-fixed devices; and off-premises devices associated with a multi-
line telephone system. The Report and Order reflects

[[Page 66755]]

that the costs to implement these requirements would be minimal. For 
purposes of estimating projected costs to small businesses, we find 
that the costs would be comparable to the costs CMRS service providers 
incur in delivering uncompensated barometric pressure data, which OMB 
approved under OMB Control No. 3060-1210, ICR Reference No: 201801-
3060-010. Current rule Sec.  20.18 (redesignated as Sec.  9.10) 
requires that CMRS providers shall deliver uncompensated barometric 
pressure data from any device capable of delivering such data to PSAPs. 
The Commission stated that the furnishing of this information to PSAPs 
is necessary to ensure that PSAPs are receiving all location 
information possible to be used for dispatch.

F. Steps Taken To Minimize the Significant Economic Impact on Small 
Entities, and Significant Alternatives Considered

    288. The RFA requires an agency to describe any significant, 
specifically small business alternatives, that it has considered in 
reaching its approach, which may include the following four 
alternatives (among others): (1) The establishment of differing 
compliance or reporting requirements or timetables that take into 
account the resources available to small entities; (2) the 
clarification, consolidation, or simplification of compliance or 
reporting requirements under the rule for small entities; (3) the use 
of performance, rather than design, standards; and (4) an exemption 
from coverage of the rule, or any part thereof, for small entities. To 
minimize any significant impact on small businesses, the Commission 
establishes a longer timetable for compliance timetable than that 
proposed in the NPRM relative to dispatchable location requirements. 
The Report and Order clarifies that the rules are flexible and 
technologically neutral so that small businesses may choose from a 
broad array of options to comply with the Commission's rules. We 
provide the following analysis of our rules.
    289. Direct Dialing and Notification Requirements for a Multi-Line 
Telephone System. The Commission takes a number of steps in the Report 
and Order to provide flexibility and reduce costs for small businesses 
and other enterprises. As a preliminary matter, Kari's Law provides 
that the central notification requirements of the statute apply only if 
the MLTS can be configured to provide notification ``without an 
improvement to the hardware or software of the system.'' The 
legislative history of Kari's Law notes that this provision is intended 
to ``balance the need for an onsite notification with the goal of not 
placing an undue burden on MLTS owners or operators.'' The Commission 
adopts rules to implement and clarify this provision.
    290. The Commission requires the notification to include the fact 
that a 911 call has been made, a valid callback number, and the same 
location information that is conveyed with the call to 911. However, 
the Commission also provides an exception for callback number and 
location information in circumstances where including this information 
in the notification would be technologically infeasible. In addition, 
the Commission requires that initiation of the notification be 
contemporaneous with the call to 911, conditioned on whether it is 
technologically feasible to do so. The Commission also requires that 
notifications be sent to a location where someone is likely to hear or 
see the notification but does not require the location to be 
continuously staffed or monitored. The absence of a continuous staffing 
or monitoring requirement minimizes a potentially significant cost for 
small businesses. The Report and Order also clarifies that an MLTS must 
be configured to provide notification for any caller on the system, 
including callers at satellite or branch locations. These requirements 
are highly flexible and give enterprises, including small businesses, 
significant latitude to configure suitable notification mechanisms 
without unreasonable burden or cost.
    291. Consistent with Kari's Law, the Commission establishes 
February 16, 2020, as the compliance date for the regulations 
implementing the statute. The Commission also affords all entities 
flexibility, including small businesses, to come into compliance with 
the notification requirements of Kari's Law. This should give 
enterprises, including small businesses, sufficient advance notice to 
make informed manufacturing, planning, and purchasing decisions. In 
addition, because the statute and regulations apply to MLTS that are 
manufactured, imported, offered for first sale or lease, first sold or 
leased, or installed after February 16, 2020, enterprises have the 
flexibility to retain an existing MLTS until the end of its useful life 
should they choose to do so. The Commission declines to adopt 
disclosure requirements for existing MLTS and, instead, encourages 
industry to consider disclosure and education as part of voluntary best 
practices. This avoids ``one-size-fits-all'' disclosure requirements 
and allows enterprises the flexibility to disclose the limitations of 
calling 911 from legacy MLTS in a way that makes sense for their 
particular business.
    292. Dispatchable Location. In the Report and Order, the Commission 
adopts rules to implement the dispatchable location requirements that 
are measured, technologically neutral and include a phased-in 
compliance timetable in order to minimize implementation costs, and 
leverage technological advances. The Commission's measured approach 
seeks to minimize costs and burdens for small businesses and other 
enterprises where possible, while providing these MLTS and 
communications service providers significant flexibility to comply with 
the rules adopted. For example, small businesses can take advantage of 
the option for MLTS and other communication service providers subject 
to 911 requirements that are unable to provide a dispatchable location 
consistent with the rules adopted in the Report and Order, to elect to 
provide alternative location information, and incur minimal to no 
implementation costs as a result. Moreover, the Commission's decision 
not to mandate any particular technology or model for implementing the 
911 location rules gives small businesses the ability choose a 
compliance approach that best fits their economic circumstances. 
Because delivering dispatchable location is already technically 
feasible for many services today, MLTS and other service providers 
subject to our 911 location rules need only choose the methods 
necessary to close the gap between already-deployed capabilities and 
the Commission's requirements, ``rather than starting from scratch'' 
which should prove less costly for small businesses. Similarly, the 
Commission's decision to implement a phased-in approach for compliance 
and to tailor compliance deadlines to particular technologies rather 
than adopting a hard and fast, ``one size fits all'' approach takes 
into account the needs of small businesses for flexibility and a longer 
compliance timeframe. Additionally, by apply the adopted rules on a 
prospective basis, the Commission will minimize costs for small 
businesses and legacy MLTS systems.
    293. Finally, the Commission considered adopting a small business 
exemption for our dispatchable location requirements but declined to 
adopt such an exemption because the flexible rules afford small 
businesses a broad menu of options for compliance that we believe are 
scalable in ways to make them cost-effective for small businesses. 
Further, the proposed criteria for small business

[[Page 66756]]

exemptions would have undermined the purpose of the dispatchable 
location rules, i.e., to improve location accuracy, while offering no 
countervailing reduction in compliance costs. Rather than an exemption 
that relies on proposed criteria that would have little or no practical 
effect on small businesses, we believe the flexible and scalable rules 
that we adopt will minimize burdens on small businesses while advancing 
Congress's location accuracy goals.
    294. Rule Consolidation. The Report and Order also consolidates 
various 911 rules into a single rule part, i.e., part 9, to the extent 
practicable. As part of this consolidation, the Commission simplifies 
and streamlines the rules in some instances and eliminates 
corresponding duplicative rules in other rule parts. We believe the 
rule consolidation helps to minimize the burden on small entities 
subject to the Commission's 911 rules because it simplifies and 
streamlines the rules, making it easier for small entities to identify 
and understand what's required to comply with all 911 requirements.
    295. Report to Congress. The Commission will send a copy of the 
Report and Order, including this FRFA, in a report to Congress pursuant 
to the Congressional Review Act. In addition, the Commission will send 
a copy of the Report and Order, including this FRFA, to the Chief 
Counsel for Advocacy of the SBA. A copy of the Report and Order, and 
FRFA (or summaries thereof) will also be published in the Federal 
Register.

VI. Conversion Tables

                           Conversion Table A
------------------------------------------------------------------------
          Final rule              Source rule(s)         Comment(s)
------------------------------------------------------------------------
Subpart A--Purpose and
 Definitions
    Sec.   9.1 Purpose........  .................  .....................
    Sec.   9.2 Reserved.......  .................  .....................
    Sec.   9.3 Definitions....  47 CFR 9.3, 20.3,  Certain definitions
                                 25.103,            from source rules
                                 64.601(a), and     added to Sec.   9.3;
                                 64.3000.           some definitions
                                                    revised; some
                                                    definitions new.
Subpart B--Telecommunications   .................  Part 64, subpart AA
 Carriers.                                          (Universal Emergency
                                                    Telephone Number) is
                                                    removed and
                                                    reserved.
    Sec.   9.4 Obligation to    47 CFR 64.3001...  Source rule moved to
     transmit 911 calls.                            Sec.   9.4 and
                                                    subpart AA removed
                                                    and reserved in part
                                                    64.
    Sec.   9.5 Transition to    47 CFR 64.3002...  Source rule moved to
     911 as the universal                           Sec.   9.5 and
     emergency telephone                            subpart AA removed
     number.                                        and reserved in part
                                                    64.
    Sec.   9.6 Obligation for   47 CFR 64.3003...  Source rule moved to
     providing a permissive                         Sec.   9.6 and
     dialing period.                                subpart AA removed
                                                    and reserved in part
                                                    64.
    Sec.   9.7 Obligation for   47 CFR 64.3004...  Source rule moved to
     providing an intercept                         Sec.   9.7 and
     message.                                       subpart AA removed
                                                    and reserved in part
                                                    64.
    Sec.   9.8 Obligation of    .................  New provision.
     fixed telephony providers
     to convey dispatchable
     location.
Subpart C--Commercial Mobile
 Radio Service
    Sec.   9.9 Definitions....  47 CFR 20.3......  Certain definitions
                                                    from source rule
                                                    added to Sec.   9.9.
    Sec.   9.10 911 Service     47 CFR 20.18.....  Source rule moved to
     Requirements.                                  Sec.   9.10 and
                                                    revised to add
                                                    paragraph
                                                    (q)(10)(v); and
                                                    removed and reserved
                                                    in Part 20.
Subpart D--Interconnected
 Voice over Internet Protocol
 Services
    Sec.   9.11 E911 Service..  47 CFR 9.5.......  Source rule moved to
                                                    Sec.   9.11 and
                                                    revised except for
                                                    Sec.   9.5(f), which
                                                    is omitted.
    Sec.   9.12 Access to 911   47 CFR 9.7.......  Source rule moved to
     and E911 service                               Sec.   9.12 and
     capabilities.                                  revised.
Subpart E--Telecommunications
 Relay Services for Persons
 With Disabilities
    Sec.   9.13 Jurisdiction..  47 CFR 64.601(b)   Source rules added to
                                 and 64.602.        Sec.   9.13.
    Sec.   9.14 Emergency       47 CFR             Source rules moved to
     Calling Requirements.       64.604(a)(4) and   Sec.   9.14 and
                                 64.605.            revised; Sec.
                                                    64.605 removed and
                                                    reserved in part 64.
Subpart F--Multi Line           .................  New provision.
 Telephone Systems.
    Sec.   9.15 Applicability.
    Sec.   9.16 General
     obligations--direct 911
     dialing, notification and
     dispatchable location.
    Sec.   9.17 Enforcement,
     compliance date, State
     law.
Subpart G--Mobile-Satellite
 Service
    Sec.   9.18 Emergency Call  47 CFR 25.284....  Source rule moved to
     Center Service.                                Sec.   9.18 and
                                                    removed and reserved
                                                    in part 25.
Subpart H--Resiliency,          .................  Part 12 is
 redundancy and reliability of                      consolidated under
 911 communications.                                part 9, subpart H
                                                    and is removed and
                                                    reserved.
    Sec.   9.19 Reliability of  47 CFR 12.4......  Source rule moved to
     covered 911 service                            Sec.   9.19 and
     providers.                                     removed and reserved
                                                    in part 12.

[[Page 66757]]

 
    Sec.   9.20 Backup power    47 CFR 12.5......  Source rule moved to
     obligations.                                   Sec.   9.20 and
                                                    removed and reserved
                                                    in part 12.
------------------------------------------------------------------------

Conversion Table B

           Part 1--Practice and Procedure, Final Rule Changes
------------------------------------------------------------------------
       Current rule No.              Subject           Final Changes
------------------------------------------------------------------------
1.9020........................  Spectrum manager   Updated cross-
                                 leasing            references.
                                 arrangements.
1.9030........................  Long-term de       Updated cross-
                                 facto transfer     references.
                                 leasing
                                 arrangements.
1.9035........................  Short-term de      Updated cross-
                                 facto transfer     references.
                                 leasing
                                 arrangements.
1.9049........................  Special            Updated cross-
                                 provisions         references.
                                 relating to
                                 spectrum leasing
                                 arrangements
                                 involving the
                                 ancillary
                                 terrestrial
                                 component of
                                 Mobile Satellite
                                 Services.
------------------------------------------------------------------------


Part 9--Interconnected Voice Over Internet Protocol Services, Final Rule
                                 Changes
------------------------------------------------------------------------
       Current rule No.              Subject           Final changes
------------------------------------------------------------------------
9.1...........................  Purposes.........  Revised.
9.3...........................  Definitions......  Definition of
                                                    ``Registered
                                                    Location'' moved to
                                                    Sec.   9.3 and
                                                    revised.
                                                   All other definitions
                                                    remain in Sec.
                                                    9.3:
                                                     ANI
                                                     Appropriate local
                                                   emergency authority.
                                                     Automatic Location
                                                   Information (ALI).
                                                     CMRS.
                                                     Interconnected VoIP
                                                   service.
                                                     PSAP.
                                                     Pseudo Automatic
                                                   Number Identification
                                                   (Pseudo-ANI).
                                                     Statewide default
                                                   answering point.
                                                     Wireline E911
                                                   Network.
9.5...........................  E911 Service.....  Moved to Sec.   9.11
                                                    and revised, except
                                                    for Sec.   9.5(f),
                                                    which is a one-time
                                                    information
                                                    collection that has
                                                    been completed.
                                                    Removed the
                                                    obligation in Sec.
                                                    9.5(f).
9.7...........................  Access to 911 and  Moved to Sec.   9.12
                                 E911 service       and revised.
                                 capabilities.
------------------------------------------------------------------------


Part 12--Resiliency, Redundancy and Reliability of Communications, Final
                              Rule Changes
------------------------------------------------------------------------
       Current rule No.              Subject           Final changes
------------------------------------------------------------------------
12.1..........................  Purpose..........  Removed.
12.3..........................  911 and E911       Removed (one-time
                                 analyses and       reporting
                                 reports.           requirement has been
                                                    completed).
12.4..........................  Reliability of     Moved to Sec.   9.19;
                                 covered 911        corrected internal
                                 service            cross-references.
                                 providers.
12.5..........................  Backup power       Moved to Sec.   9.20;
                                 obligations.       corrected internal
                                                    cross-references.
------------------------------------------------------------------------


         Part 20--Commercial Mobile Services, Final Rule Changes
------------------------------------------------------------------------
       Current rule No.              Subject           Final changes
------------------------------------------------------------------------
20.2..........................  Other applicable   Section 20.2
                                 rule parts.        specifies other FCC
                                                    rule parts
                                                    applicable to
                                                    licensees in the
                                                    commercial mobile
                                                    radio services.
                                                    Revised Sec.   20.2
                                                    by adding a
                                                    reference to
                                                    compliance with the
                                                    911 requirements in
                                                    part 9 of this
                                                    chapter.
20.3..........................  Definitions......  Definitions of the
                                                    following terms
                                                    added to Sec.   9.3
                                                    and removed from
                                                    Sec.   20.3:
                                                     Appropriate local
                                                   emergency authority.
                                                     Automatic Number
                                                   Identification (ANI)
                                                   (The version in 9.3
                                                   is revised slightly
                                                   to harmonize it with
                                                   the definition of ANI
                                                   from Sec.   64.601.)
                                                     Designated PSAP.
                                                     Handset-based
                                                   location technology.
                                                     Location-capable
                                                   handsets.
                                                     Network-based
                                                   Location Technology.
                                                     Pseudo Automatic
                                                   Number Identification
                                                   (Pseudo-ANI).
                                                     Public safety
                                                   answering point
                                                   (PSAP) (The version
                                                   in Sec.   9.3 is
                                                   revised slightly for
                                                   clarity by adding the
                                                   word ``answering''
                                                   before ``point.'').

[[Page 66758]]

 
                                                     Statewide default
                                                   answering point.
 
                                                   Definitions of the
                                                    following terms
                                                    added to Sec.   9.3
                                                    (but not removed
                                                    from Sec.   20.3)
                                                     Commercial mobile
                                                   radio service
                                                   (acronym CMRS added
                                                   to definition for
                                                   clarity).
                                                     Mobile Service.
                                                     Public Switched
                                                   Network.
                                                     Private Mobile
                                                   Radio Service.
 
                                                   Definitions of the
                                                    following terms
                                                    added to Sec.   9.9
                                                    (but not removed
                                                    from Sec.   20.3):
                                                     Interconnection or
                                                   Interconnected.
                                                     Interconnected
                                                   Service.
20.18.........................  911 Service......  Moved to Sec.   9.10;
                                                    corrected internal
                                                    cross-references.
                                                   Corrected certain
                                                    internal references
                                                    to paragraph (j),
                                                    which was previously
                                                    redesignated as
                                                    paragraph (m).
                                                   Corrected certain
                                                    internal references
                                                    to paragraph (n),
                                                    which was previously
                                                    redesignated as
                                                    paragraph (q).
                                                   Added new paragraph
                                                    (q)(10)(v).
------------------------------------------------------------------------


           Part 22--Public Mobile Services, Final Rule Changes
------------------------------------------------------------------------
       Current rule No.              Subject           Final changes
------------------------------------------------------------------------
22.921........................  911 call           Removed and reserved.
                                 processing
                                 procedures; 911-
                                 only calling
                                 mode.
------------------------------------------------------------------------


          Part 25--Satellite Communications, Final Rule Changes
------------------------------------------------------------------------
       Current rule No.              Subject           Final changes
------------------------------------------------------------------------
25.103........................  Definitions......  Definitions of the
                                                    following terms
                                                    added to Sec.   9.3
                                                    (but not removed
                                                    from Sec.   25.103):
                                                     Earth station.
                                                     Feeder link.
                                                     Fixed-Satellite
                                                   Service (FSS).
                                                     Mobile Earth
                                                   Station.
                                                     Mobile-Satellite
                                                   Service (MSS).
                                                     Space station.
 
                                                   Definition of the
                                                    following term added
                                                    to Sec.   9.3 and
                                                    removed from Sec.
                                                    25.103:
                                                     Emergency Call
                                                   Center.
25.284........................  Emergency Call     Moved to Sec.   9.18;
                                 Center Service.    Sec.   25.284
                                                    removed and
                                                    reserved.
------------------------------------------------------------------------


  Part 64--Miscellaneous Rules Relating to Common Carriers, Final Rule
                                 Changes
------------------------------------------------------------------------
       Current rule No.              Subject           Final changes
------------------------------------------------------------------------
64.601........................  Definitions and    Section 64.601(b),
                                 provisions of      which states that
                                 general            ``For purposes of
                                 applicability.     this subpart, all
                                                    regulations and
                                                    requirements
                                                    applicable to common
                                                    carriers shall also
                                                    be applicable to
                                                    providers of
                                                    interconnected VoIP
                                                    service,'' is added
                                                    to Sec.   9.13, with
                                                    reference to the
                                                    definition of
                                                    interconnected VoIP
                                                    in Sec.   9.3.
                                                   Section 64.601(a),
                                                    which lists several
                                                    terms and defines
                                                    them by cross-
                                                    referencing other
                                                    rule sections, is
                                                    revised to remove
                                                    the terms ``Public
                                                    Safety Answering
                                                    Point (PSAP),''
                                                    ``statewide default
                                                    answering point,''
                                                    and ``appropriate
                                                    local emergency
                                                    authority.''
                                                   Definition of ANI
                                                    added to Sec.   9.3
                                                    but not removed from
                                                    Sec.   64.601.
                                                   Definition of
                                                    Registered Location
                                                    added to Sec.   9.3
                                                    and revised.
                                                   Definition of Real-
                                                    Time Text (RTT) is
                                                    added to Sec.   9.3
                                                    and revised to
                                                    include definition
                                                    from 67.1 (rather
                                                    than cross-reference
                                                    to Sec.   67.1).
 
                                                   Definition of the
                                                    following terms
                                                    added to Sec.   9.3
                                                    (but not removed
                                                    from Sec.   64.601):
                                                     Common carrier or
                                                   carrier.
                                                     Communications
                                                   assistant (CA).
                                                     Internet-based TRS
                                                   (iTRS).
                                                     iTRS access
                                                   technology.
                                                     Internet-based TRS
                                                   (iTRS).
                                                     Internet Protocol
                                                   Captioned Telephone
                                                   Service (IP CTS).

[[Page 66759]]

 
                                                     Internet Protocol
                                                   Relay Service (IP
                                                   Relay).
                                                     Non-English
                                                   language relay
                                                   service.
                                                     Speech-to-speech
                                                   relay service.
                                                     Telecommunications
                                                   relay services (TRS).
                                                     Text telephone
                                                   (TTY).
                                                     Video relay service
                                                   (VRS).
64.602........................  Jurisdiction.....  Section 64.602, which
                                                    states that ``Any
                                                    violation of this
                                                    subpart F 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,'' is
                                                    added to Sec.   9.13
                                                    (with reference to
                                                    subpart E of part
                                                    9).
64.603........................  Provision of       Section 64.603(a)
                                 services.          requires common
                                                    carriers providing
                                                    telephone voice
                                                    transmission
                                                    services to provide
                                                    telecommunications
                                                    relay services in
                                                    compliance with the
                                                    regulations
                                                    prescribed in
                                                    subpart F of part
                                                    64. Revised Sec.
                                                    64.603(a) so that it
                                                    also refers to
                                                    compliance with the
                                                    emergency calling
                                                    requirements
                                                    prescribed in part
                                                    9, subpart E of this
                                                    chapter.
64.604(a)(4)..................  Emergency call     Moved to Sec.
                                 handling           9.14(a); Sec.
                                 requirements for   64.604(a)(4) removed
                                 TTY-based TRS      and reserved; and
                                 providers.         Sec.   64.604(d)
                                                    revised to update
                                                    cross-reference from
                                                    Sec.   64.605 to
                                                    Sec.   9.14.
64.605........................  Emergency calling  Moved to Sec.
                                 requirements.      9.14(b) and (c);
                                                    Sec.   64.605
                                                    removed and
                                                    reserved.
64.3000.......................  Definitions......  Moved to Sec.   9.3
                                                    and removed from
                                                    part 64 as subpart
                                                    AA (Universal
                                                    Emergency Telephone
                                                    Number) is removed
                                                    and reserved.
 
                                                   Definition of the
                                                    following terms
                                                    added to Sec.   9.3
                                                    (and removed from
                                                    Part 64 as subpart
                                                    AA is removed and
                                                    reserved):
                                                     911 calls.
                                                     Appropriate local
                                                   emergency authority.
                                                     Public safety
                                                   answering point
                                                   (PSAP) (The version
                                                   in Sec.   9.3 is
                                                   revised slightly for
                                                   consistency with the
                                                   version from Sec.
                                                   20.3 and for clarity;
                                                   ``facility'' changed
                                                   to ``answering
                                                   point.'').
                                                     Statewide default
                                                   answering point.
64.3001.......................  Obligation to      Moved to Sec.   9.4
                                 transmit 911       and removed from
                                 calls.             part 64 as subpart
                                                    AA (Universal
                                                    Emergency Telephone
                                                    Number) is removed
                                                    and reserved.
64.3002.......................  Transition to 911  Moved to Sec.   9.5
                                 as the universal   and removed from
                                 emergency          part 64 as subpart
                                 telephone number.  AA (Universal
                                                    Emergency Telephone
                                                    Number) is removed
                                                    and reserved.
64.3003.......................  Obligation for     Moved to Sec.   9.6
                                 providing a        and removed from
                                 permissive         part 64 as subpart
                                 dialing period.    AA (Universal
                                                    Emergency Telephone
                                                    Number) is removed
                                                    and reserved.
64.3004.......................  Obligation for     Moved to Sec.   9.7
                                 providing an       and removed from
                                 intercept          part 64 as subpart
                                 message.           AA (Universal
                                                    Emergency Telephone
                                                    Number) is removed
                                                    and reserved.
------------------------------------------------------------------------

VII. Ordering Clauses

    296. Accordingly, it is ordered, pursuant to sections 1, 4(i), 
4(j), 4(o), 201(b), 251(e), 301, 303(b), 303(r), 307, 309, and 316 of 
the Communications Act of 1934, as amended, 47 U.S.C. 151, 154(i), 
154(j), 154(o), 201(b), 251(e), 301, 303(b), 303(r), 307, 309, 316 and 
pursuant to Kari's Law Act of 2017, Public Law 115-127, 47 U.S.C. 623 
and 623 note, section 506 of the Repack Airwaves Yielding Better Access 
for Users of Modern Services Act of 2018 (RAY BAUM'S Act), Public Law 
115-141, 47 U.S.C. 615 note, Section 106 of the Twenty-First Century 
Communications and Video Accessibility Act of 2010, Public Law 111-260, 
47 U.S.C. 615c, section 101 of the New and Emerging Technologies 911 
Improvement Act of 2008, Public Law 110-283, 47 U.S.C. 615a-1, Middle 
Class Tax Relief and Job Creation Act of 2012, Public Law 112-96, 47 
U.S.C. 1471, and the Wireless Communications and Public Safety Act of 
1999, Public Law 106-81, 47 U.S.C. 615 note, 615, 615a, 615b, that this 
Report and Order is adopted.
    297. It is further ordered that the amendments of the Commission's 
rules as set forth in Appendix A are adopted, effective thirty days 
from the date of publication in the Federal Register. Sections 9.8(a); 
9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4); 
9.11(b)(5)(ii); (iii); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v); 
9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); 9.16(b)(3)(i); 
(ii); and (iii), contain new or modified information collection 
requirements that require review by the OMB under the PRA. The 
Commission directs the Public Safety and Homeland Security Bureau 
(Bureau) to announce the effective date of those information 
collections in a document published in the Federal Register after the 
Commission receives OMB approval, and directs the Bureau to cause 
Sec. Sec.  9.8(b); 9.10(s); 9.11(c); 9.14(f); 9.16(c), to be revised 
accordingly.
    298. It is further ordered that the Commission SHALL SEND a copy of 
the Report and Order in a report to be sent to Congress and the 
Government Accountability Office pursuant to the Congressional Review 
Act, 5 U.S.C. 801(a)(1)(A).
    299. It is further ordered that the Commission's Consumer and 
Governmental Affairs Bureau, Reference Information Center, shall send a 
copy of the Report and Order, including the Final Regulatory 
Flexibility Analysis, to the Chief Counsel for Advocacy of the Small 
Business Administration.

List of Subjects in 47 CFR Parts 1, 9, 12, 20, 25, and 64

    Communications, Communications common carriers, Communications 
Equipment, Reporting and recordkeeping requirements, Security measures, 
Satellites, Telecommunications, Telephone.


[[Page 66760]]


Federal Communications Commission.
Katura Jackson,
Federal Register Liaison Officer.

Final Rules

    For the reasons discussed in the preamble, the Federal 
Communications Commission amends 47 parts 1, 9, 12, 20, 25, and 64 as 
follows:

PART 1--PRACTICE AND PROCEDURE

0
1. The authority citation for part 1 continues to read as follows:

    Authority:  47 U.S.C. chs. 2, 5, 9, 13; 28 U.S.C. 2461 note, 
unless otherwise noted.


0
2. Section 1.9020 is amended by revising paragraph (d)(8) to read as 
follows:


Sec.  1.9020   Spectrum manager leasing arrangements.

* * * * *
    (d) * * *
    (8) E911 requirements. If E911 obligations apply to the licensee 
(see Sec.  9.10 of this chapter), the licensee retains the obligations 
with respect to leased spectrum. However, if the spectrum lessee is a 
Contraband Interdiction System (CIS) provider, as defined in Sec.  
1.9003, then the CIS provider is responsible for compliance with Sec.  
9.10(r) regarding E911 transmission obligations.
* * * * *

0
3. Section 1.9030 is amended by revising paragraph (d)(8) to read as 
follows:


Sec.  1.9030   Long-term de facto transfer leasing arrangements.

* * * * *
    (d) * * *
    (8) E911 requirements. To the extent the licensee is required to 
meet E911 obligations (see Sec.  9.10 of this chapter), the spectrum 
lessee is required to meet those obligations with respect to the 
spectrum leased under the spectrum leasing arrangement insofar as the 
spectrum lessee's operations are encompassed within the E911 
obligations. If the spectrum lessee is a Contraband Interdiction System 
(CIS) provider, as defined in Sec.  1.9003, then the CIS provider is 
responsible for compliance with Sec.  9.10(r) regarding E911 
transmission obligations.
* * * * *

0
4. Section 1.9035 is amended by revising paragraph (d)(4) to read as 
follows:


Sec.  1.9035   Short-term de facto transfer leasing arrangements.

* * * * *
    (d) * * *
    (4) E911 requirements. If E911 obligations apply to the licensee 
(see Sec.  9.10 of this chapter), the licensee retains the obligations 
with respect to leased spectrum. A spectrum lessee entering into a 
short-term de facto transfer leasing arrangement is not separately 
required to comply with any such obligations in relation to the leased 
spectrum. However, if the spectrum lessee is a Contraband Interdiction 
System (CIS) provider, as defined in Sec.  1.9003, then the CIS 
provider is responsible for compliance with Sec.  9.10(r) regarding 
E911 transmission obligations.
* * * * *

0
5. Section 1.9049 is amended by revising paragraph (c) to read as 
follows:


Sec.  1.9049   Special provisions relating to spectrum leasing 
arrangements involving the ancillary terrestrial component of Mobile 
Satellite Services.

* * * * *
    (c) For purposes of Sec.  1.9020(d)(8), the Mobile Satellite 
Service licensee's obligation, if any, concerning the E911 requirements 
in Sec.  9.10 of this chapter, will, with respect to an ATC, be 
specified in the licensing document for the ATC.
* * * * *

0
6. Revise part 9 to read as follows:

PART 9--911 REQUIREMENTS

Subpart A--Purpose and Definitions
Sec.
9.1 Purpose.
9.2 [Reserved]
9.3 Definitions.
Subpart B--Telecommunications Carriers
9.4 Obligation to transmit 911 calls.
9.5 Transition to 911 as the universal emergency telephone number.
9.6 Obligation for providing a permissive dialing period.
9.7 Obligation for providing an intercept message.
9.8 Obligation of fixed telephony providers to convey dispatchable 
location.
Subpart C--Commercial Mobile Radio Service
9.9 Definitions.
9.10 911 Service.
Subpart D--Interconnected Voice over Internet Protocol Services
9.11 E911 Service.
9.12 Access to 911 and E911 service capabilities.
Subpart E--Telecommunications Relay Services for Persons With 
Disabilities
9.13 Jurisdiction.
9.14 Emergency calling requirements.
Subpart F--Multi-Line Telephone Systems
9.15 Applicability.
9.16 General obligations--direct 911 dialing, notification, and 
dispatchable location.
9.17 Enforcement, compliance date, State law.
Subpart G--Mobile-Satellite Service
9.18 Emergency Call Center service.
Subpart H--Resiliency, Redundancy, and Reliability of 911 
Communications
9.19 Reliability of covered 911 service providers.
9.20 Backup power obligations.

    Authority:  47 U.S.C. 151-154, 152(a), 155(c), 157, 160, 201, 
202, 208, 210, 214, 218, 219, 222, 225, 251(e), 255, 301, 302, 303, 
307, 308, 309, 310, 316, 319, 332, 403, 405, 605, 610, 615, 615 
note, 615a, 615b, 615c, 615a-1, 616, 620, 621, 623, 623 note, 721, 
and 1471, unless otherwise noted.

Subpart A--Purpose and Definitions


Sec.  9.1   Purpose.

    The purpose of this part is to set forth the 911 and E911 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); 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 communications 
systems, particularly 911 and E911 networks and/or systems (subpart H).


Sec.  9.2   [Reserved]


Sec.  9.3   Definitions.

    Terms with definitions including the ``(RR)'' designation are 
defined in the same way in Sec.  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

[[Page 66761]]

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

[[Page 66762]]

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

[[Page 66763]]

    (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 
Sec.  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.

Subpart B--Telecommunications Carriers


Sec.  9.4   Obligation to transmit 911 calls.

    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 Sec.  9.5.


Sec.  9.5  Transition to 911 as the universal emergency telephone 
number.

    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.


Sec.  9.6  Obligation for providing a permissive dialing period.

    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

[[Page 66764]]

determines to phase out the use of such seven-or ten-digit number 
entirely and use 911 exclusively.


Sec.  9.7  Obligation for providing an intercept message.

    Upon termination of permissive dialing, as provided under Sec.  
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.


Sec.  9.8  Obligation of fixed telephony providers to convey 
dispatchable location.

    (a) Providers of fixed telephony services shall provide automated 
dispatchable location with 911 calls beginning January 6, 2021.
    (b) Paragraph (a) of this section contains information-collection 
and recordkeeping requirements. Compliance will not be required until 
after approval by the Office of Management and Budget. The Commission 
will publish a document in the Federal Register announcing that 
compliance date and revising this paragraph accordingly.

Subpart C--Commercial Mobile Radio Service


Sec.  9.9  Definitions.

    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.


Sec.  9.10  911 Service.

    (a) Scope of section. Except as described in paragraph (r) of this 
section, the following requirements of paragraphs (a) through (q) 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 Sec.  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.

[[Page 66765]]

    (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

[[Page 66766]]

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) Within 6 years: In each of the top 25 CMAs, nationwide CMRS 
providers shall deploy either;) dispatchable location, or; z-axis 
technology in compliance with any z-axis accuracy metric that has been 
approved by the Commission,
    (1) In each CMA where dispatchable location is used: nationwide 
CMRS providers must ensure that the NEAD is populated with a sufficient 
number of total dispatchable location reference points to equal 25 
percent of the CMA population.
    (2) In each CMA where z-axis technology is used: nationwide CMRS 
providers must deploy z-axis technology to cover 80 percent of the CMA 
population.
    (D) Within 8 years: In each of the top 50 CMAs, nationwide CMRS 
providers shall deploy either
    (1) Dispatchable location or;
    (2) Such z-axis technology in compliance with any z-axis accuracy 
metric that has been approved by the Commission.
    (E) 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.
    (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

[[Page 66767]]

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

[[Page 66768]]

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) NEAD use certification. Prior to use of the NEAD or any 
information contained therein to meet such requirements, CMRS providers 
must certify that they will not use the NEAD or associated data for any 
non-911 purpose, except as otherwise required by law.
    (j) Confidence and uncertainty data. (1) Except as provided in 
paragraphs (j)(2) and (3) 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) 
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.
    (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) through (3) 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 Sec. Sec.  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;

[[Page 66769]]

    (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 Sec.  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 Sec. Sec.  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) Dispatch service. A service provider covered by this section 
who offers dispatch service to customers may meet the requirements of 
this section with respect to customers who use dispatch service either 
by complying with the requirements set forth in paragraphs (b) through 
(e) of this section, or by routing the customer's emergency calls 
through a dispatcher. If the service provider chooses the latter 
alternative, it must make every reasonable effort to explicitly notify 
its current and potential dispatch customers and their users that they 
are not able to directly reach a PSAP by calling 911 and that, in the 
event of an emergency, the dispatcher should be contacted.
    (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 Sec.  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 Sec.  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;

[[Page 66770]]

    (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 Sec.  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 Sec.  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 
Sec.  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

[[Page 66771]]

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) Compliance date. Paragraph (q)(10)(v) of this section contains 
information-collection and recordkeeping requirements. Compliance will 
not be required until after approval by the Office of Management and 
Budget. The Commission will publish a document in the Federal Register 
announcing that compliance date and revising this paragraph 
accordingly.

Subpart D--Interconnected Voice over Internet Protocol Services


Sec.  9.11  E911 Service.

    (a) Before January 6, 2021, for fixed services and before January 
6, 2022, for non-fixed services.--(1) Scope. The following requirements 
of paragraphs (a)(1) through (5) of this section are only applicable to 
providers of interconnected VoIP services, except those interconnected 
VoIP services that fulfill each paragraphs (1)(i) through (iii) of the 
definition of interconnected VoIP service in Sec.  9.3, and also permit 
users generally to terminate calls to the public switched telephone 
network. Further, the following requirements apply only to 911 calls 
placed by users whose Registered Location is in a geographic area 
served by a Wireline E911 Network (which, as defined in Sec.  9.3, 
includes a selective router).
    (2) E911 Service. As of November 28, 2005:
    (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 all 911 
calls, as well as ANI and the caller's Registered Location 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 Sec.  9.4, provided that ``all 911 calls'' is 
defined as ``any voice communication initiated by an interconnected 
VoIP user dialing 911;''
    (iii) All 911 calls must be routed through the use of ANI and, if 
necessary, pseudo-ANI, via the dedicated Wireline E911 Network; and
    (iv) The Registered Location 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 (a)(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 (a)(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 Registered Location and that has been designated for 
telecommunications carriers pursuant to Sec.  9.4.
    (4) Registered Location requirement. As of November 28, 2005, 
interconnected VoIP service providers must:
    (i) Obtain from each customer, prior to the initiation of service, 
the physical location at which the service will first be used; and
    (ii) Provide their 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.
    (5) Customer notification. Each interconnected VoIP service 
provider shall:
    (i) 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 Registered 
Location available in or through the ALI database;
    (ii) 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 (a)(5)(i) of this 
section; and
    (iii) Either--
    (A) Distribute to its existing subscribers, and to each new 
subscriber prior to the initiation of that subscriber's service, 
warning stickers or other appropriate 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.
    (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 Sec.  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 Sec.  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

[[Page 66772]]

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 Sec.  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 Sec.  
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 Sec.  
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.
    (c) Paragraphs (b)(2)(ii) and (iv), (b)(4), and (b)(5)(ii) and 
(iii) of this section contain information-collection and recordkeeping 
requirements. Compliance will not be required until after approval by 
the Office of Management and Budget. The Commission will publish a 
document in the Federal Register announcing that compliance date and 
revising this paragraph accordingly.


Sec.  9.12   Access to 911 and E911 service capabilities.

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

Subpart E--Telecommunications Relay Services for Persons with 
Disabilities


Sec.  9.13   Jurisdiction.

    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

[[Page 66773]]

regulations and requirements applicable to common carriers shall also 
be applicable to providers of interconnected VoIP service as defined in 
Sec.  9.3.


Sec.  9.14   Emergency calling requirements.

    (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 Sec.  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 Sec.  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 Sec.  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;

[[Page 66774]]

    (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 Sec.  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 Sec.  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 Sec.  
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 Sec.  
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 Sec.  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

[[Page 66775]]

telecommunications carriers pursuant to Sec.  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 Sec.  
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 Sec.  
9.3.
    (D) Route the caller to a call center.
    (f) Paragraphs (d)(2)(ii), (iii), and (v), (d)(4), (e)(2)(ii) and 
(iv), and (e)(4) of this section contain information-collection and 
recordkeeping requirements. Compliance will not be required until after 
approval by the Office of Management and Budget. The Commission will 
publish a document in the Federal Register announcing that compliance 
date and revising this paragraph accordingly.

Subpart F--Multi-Line Telephone Systems


Sec.  9.15   Applicability.

    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.


Sec.  9.16   General obligations--direct 911 dialing, notification, and 
dispatchable location.

    (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 Sec.  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.
    (c) Compliance date. Paragraphs (b)(3)(i) through (iii) of this 
section contain information-collection and recordkeeping requirements.

[[Page 66776]]

Compliance will not be required until after approval by the Office of 
Management and Budget. The Commission will publish a document in the 
Federal Register announcing that compliance date and revising this 
paragraph accordingly.


Sec.  9.17  Enforcement, compliance date, State law.

    (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, 5 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 Sec.  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 Sec.  9.16 may 
file a complaint under the procedures set forth in Sec. Sec.  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 Sec.  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.

Subpart G--Mobile-Satellite Service


Sec.  9.18   Emergency Call Center service.

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

Subpart H--Resiliency, Redundancy, and Reliability of 911 
Communications


Sec.  9.19   Reliability of covered 911 service providers.

    (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 Sec.  
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

[[Page 66777]]

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) Annual reliability certification. One year after the initial 
reliability certification described in paragraph (d)(1) of this section 
and every year thereafter, 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

[[Page 66778]]

    (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) Initial reliability certification. One year 
after October 15, 2014, a certifying official of every covered 911 
service provider shall certify to the Commission that it has made 
substantial progress toward meeting the standards of the annual 
reliability certification described in paragraph (c) of this section. 
Substantial progress in each element of the certification shall be 
defined as compliance with standards of the full certification in at 
least 50 percent of the covered 911 service provider's critical 911 
circuits, central offices that directly serve PSAPs, and independently 
monitored 911 service areas.
    (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.


Sec.  9.20  Backup power obligations.

    (a) Covered service. For purposes of this section, a Covered 
Service is any facilities-based, fixed voice service offered as 
residential service, including fixed applications of wireless service 
offered as a residential service, that is not line powered.
    (b) Obligations of providers of a Covered Service to offer backup 
power. Providers of a Covered Service shall, at the point of sale for a 
Covered Service, offer subscribers the option to purchase backup power 
for the Covered Service as follows:
    (1) Eight hours. Providers shall offer for sale at least one option 
with a minimum of eight hours of standby backup power.
    (2) Twenty-four hours. By February 13, 2019, providers of a Covered 
Service shall offer for sale also at least one option that provides a 
minimum of twenty-four hours of standby backup power.
    (3) Options. At the provider's discretion, the options in 
paragraphs (b)(1) and (2) of this section may be either:
    (i) A complete solution including battery or other power source; or
    (ii) Installation by the provider of a component that accepts or 
enables the use of a battery or other backup power source that the 
subscriber obtains separately. If the provider does not offer a 
complete solution, the provider shall install a compatible battery or 
other power source if the subscriber makes it available at the time of 
installation and so requests. After service has been initiated, the 
provider may, but is not required to, offer to sell any such options 
directly to subscribers.
    (c) Backup power required. The backup power offered for purchase 
under paragraph (b) of this section must include power for all 
provider-furnished equipment and devices installed and operated on the 
customer premises that must remain powered in order for the service to 
provide 911 access.
    (d) Subscriber disclosure. (1) The provider of a Covered Service 
shall disclose to each new subscriber at the point of sale and to all 
subscribers to a Covered Service annually thereafter:
    (i) Capability of the service to accept backup power, and if so, 
the availability of at least one backup power solution available 
directly from the provider, or after the initiation of service, 
available from either the provider or a third party. After the 
obligation to offer for purchase a solution for twenty-four hours of 
standby backup power becomes effective, providers must disclose this 
information also for the twenty-four-hour solution;
    (ii) Service limitations with and without backup power;
    (iii) Purchase and replacement information, including cost;
    (iv) Expected backup power duration;
    (v) Proper usage and storage conditions, including the impact on 
duration of failing to adhere to proper usage and storage;
    (vi) Subscriber backup power self-testing and -monitoring 
instructions; and
    (vii) Backup power warranty details, if any.
    (2) Disclosure reasonably calculated to reach each subscriber. A 
provider of a Covered Service shall make disclosures required by this 
rule in a manner reasonably calculated to reach individual subscribers, 
with due consideration for subscriber preferences. Information posted 
on a provider's public website and/or within a subscriber portal 
accessed by logging through the provider's website are not sufficient 
to comply with these requirements.
    (3) The disclosures required under this paragraph are in addition 
to, but may be combined with, any disclosures required under Sec.  
9.11(a)(5) and (b)(5).
    (e) Obligation with respect to existing subscribers. Providers are 
not obligated to offer for sale backup power options to or retrofit 
equipment for those who are subscribers as of the effective date listed 
in paragraph (f) of this section for the obligations in paragraph 
(b)(1) of this section, but shall provide such subscribers with the 
annual disclosures required by paragraph (d) of this section.
    (f) Dates of obligations. (1) Except as noted in paragraphs (b)(2) 
and (f)(2) of this section, the obligations under paragraph (b) of this 
section are in effect February 16, 2016, and the obligations under 
paragraph (d) of this section are in effect August 5, 2016.

[[Page 66779]]

    (2) For a provider of a Covered Service that (together with any 
entities under common control with such provider) has fewer than 
100,000 domestic retail subscriber lines, the obligations in paragraph 
(b)(1) of this section are in effect August 11, 2016, the obligations 
in paragraph (b)(2) of this section are in effect as prescribed 
therein, and the obligations under paragraph (d) of this section are in 
effect February 1, 2017.
    (g) Sunset date. The requirements of this section shall no longer 
be in effect as of September 1, 2025.

PART 12--[REMOVED AND RESERVED]

0
7. Under the authority of 47 U.S.C. 154(i), part 12 is removed.

PART 20--COMMERCIAL MOBILE SERVICES

0
8. The authority citation for part 20 continues to read as follows:

    Authority: 47 U.S.C. 151, 152(a), 154(i), 157, 160, 201, 214, 
222, 251(e), 301, 302, 303, 303(b), 303(r), 307, 307(a), 309, 
309(j)(3), 316, 316(a), 332, 610, 615, 615a, 615b, 615c, unless 
otherwise noted.

0
9. Section 20.2 is amended by adding paragraph (c) to read as follows:


Sec.  20.2  Other applicable rule parts.

* * * * *
    (c) Part 9. This part contains 911 and E911 requirements applicable 
to telecommunications carriers and commercial mobile radio service 
(CMRS) providers.


Sec.  20.3  [Amended]

0
10. Section 20.3 is amended by removing the definitions of 
``Appropriate local emergency authority,'' ``Automatic Number 
Identification (ANI),'' ``Designated PSAP,'' ``Handset-based location 
technology,'' ``Location-capable handsets,'' ``Network-based Location 
Technology,'' ``Pseudo Automatic Number Identification (Pseudo-ANI),'' 
``Public safety answering point (PSAP),'' and ``Statewide default 
answering point''.


Sec.  20.18  [Removed and Reserved]

0
11. Section 20.18 is removed and reserved.

PART 22--PUBLIC MOBILE SERVICES

0
12. The authority citation for part 22 continues to read as follows:

    Authority: 47 U.S.C. 154, 222, 303, 309, and 332.


Sec.  22.921  [Removed and Reserved]

0
13. Section 22.921 is removed and reserved.

PART 25--SATELLITE COMMUNICATIONS

0
14. The authority citation for part 25 continues to read as follows:

    Authority:  47 U.S.C. 154, 301, 302, 303, 307, 309, 310, 319, 
332, 605, and 721, unless otherwise noted.


Sec.  25.103  [Amended]

0
15. Section 25.103 is amended by removing the definition of ``Emergency 
Call Center''.


Sec.  25.284  [Removed and Reserved]

0
16. Section 25.284 is removed and reserved.

PART 64--MISCELLANEOUS RULES RELATING TO COMMON CARRIERS

0
17. The authority citation for part 64 continues to read as follows:

    Authority: 47 U.S.C. 154, 201, 202, 217, 218, 220, 222, 225, 
226, 227, 228, 251(a), 251(e), 254(k), 262, 403(b)(2)(B), (c), 616, 
620, 1401-1473, unless otherwise noted.

0
18. Section 64.601 is amended by revising paragraph (a) to read as 
follows:


Sec.  64.601  Definitions and provisions of general applicability.

    (a) For purposes of this subpart, the term affiliate is defined in 
47 CFR 52.12(a)(1)(i), and the terms majority and debt are defined in 
47 CFR 52.12(a)(1)(ii).
* * * * *

0
19. Section 64.603 is amended by revising paragraph (a) to read as 
follows:


Sec.  64.603  Provision of services.

    (a) Each common carrier providing telephone voice transmission 
services shall provide, in compliance with the regulations prescribed 
herein and the emergency calling requirements in part 9, subpart E of 
this chapter, throughout the area in which it offers services, 
telecommunications relay services, individually, through designees, 
through a competitively selected vendor, or in concert with other 
carriers. Interstate Spanish language relay service shall be provided. 
Speech-to-speech relay service also shall be provided, except that 
speech-to-speech relay service need not be provided by IP Relay 
providers, VRS providers, captioned telephone relay service providers, 
and IP CTS providers. In addition, each common carrier providing 
telephone voice transmission services shall provide access via the 711 
dialing code to all relay services as a toll free call. CMRS providers 
subject to this 711 access requirement are not required to provide 711 
dialing code access to TTY users if they provide 711 dialing code 
access via real-time text communications, in accordance with 47 CFR 
part 67.
* * * * *

0
20. Section 64.604 is amended by removing and reserving paragraph 
(a)(4) and revising paragraph (d).
    The revision reads as follows:


Sec.  64.604  Mandatory minimum standards.

* * * * *
    (d) Other standards. The applicable requirements of Sec.  9.14 of 
this chapter and Sec. Sec.  64.611, 64.615, 64.617, 64.621, 64.631, 
64.632, 64.5105, 64.5107, 64.5108, 64.5109, and 64.5110 of this part 
are to be considered mandatory minimum standards.


Sec.  64.605  [Removed and Reserved]

0
21. Section 64.605 is removed and reserved.

Subpart AA--[Removed and Reserved]

0
22. Subpart AA, consisting of Sec. Sec.  64.3000 through 64.3004, is 
removed and reserved.

[FR Doc. 2019-20137 Filed 11-27-19; 8:45 am]
BILLING CODE 6712-01-P