Improving the 911 System by Implementing Kari's Law and RAY BAUM'S Act, 54180-54224 [2018-21888]

Agencies

• FEDERAL COMMUNICATIONS COMMISSION

[Federal Register Volume 83, Number 208 (Friday, October 26, 2018)]
[Proposed Rules]
[Pages 54180-54224]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2018-21888]



[[Page 54179]]

Vol. 83

Friday,

No. 208

October 26, 2018

Part II





Federal Communications Commission





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





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





Improving the 911 System by Implementing Kari's Law and RAY BAUM'S Act; 
Proposed Rule

Federal Register / Vol. 83 , No. 208 / Friday, October 26, 2018 / 
Proposed Rules

[[Page 54180]]


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

FEDERAL COMMUNICATIONS COMMISSION

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

[PS Docket Nos. 18-261, 17-239; FCC 18-132]


Improving the 911 System by Implementing Kari's Law and RAY 
BAUM'S Act

AGENCY: Federal Communications Commission.

ACTION: Proposed rule.

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

SUMMARY: In this document, the Federal Communications Commission (the 
FCC or Commission) proposes 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 Commission 
also proposes consolidating the Commission's existing 911 rules into a 
single rule part.

DATES: Comments are due on or before December 10, 2018 and reply 
comments are due on or before January 9, 2019.

ADDRESSES: You may submit comments, identified by PS Docket Nos. 18-261 
and 17-239 by any of the following methods:
     Federal eRulemaking Portal: https://www.regulations.gov. 
Follow the instructions for submitting comments.
     Federal Communications Commission's Website: https://www.fcc.gov/ecfs/. Follow the instructions for submitting comments.
     Mail: Filings can be sent by hand or messenger delivery, 
by commercial overnight courier, or by first-class or overnight U.S. 
Postal Service mail (although the Commission continues to experience 
delays in receiving U.S. Postal Service mail). All filings must be 
addressed to the Commission's Secretary, Office of the Secretary, 
Federal Communications Commission.
     People with Disabilities: Contact the Commission to 
request reasonable accommodations (accessible format documents, sign 
language interpreters, CART, etc.) by email: [email protected] or phone: 
202-418-0530 or TTY: 202-418-0432.

For detailed instructions for submitting comments and additional 
information on the rulemaking process, see the SUPPLEMENTARY 
INFORMATION section of this document.

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]; Austin 
Randazzo, Attorney-Advisor, Policy and Licensing Division, Public 
Safety and Homeland Security Bureau, (202) 418-1462 or via email at 
[email protected].

SUPPLEMENTARY INFORMATION: This is a summary of the Commission's Notice 
of Proposed Rulemaking (NPRM) in PS Docket Nos. 18-261 and 17-239, FCC 
18-132, adopted and released on September 26, 2018. The full text of 
this document is available for inspection and copying during normal 
business hours in the FCC Reference Center (Room CY-A257), 445 12th 
Street SW, Washington, DC 20554. The full text may also be downloaded 
at: www.fcc.gov.

Synopis

I. Introduction

    1. In this proceeding, the Commission takes steps to advance 
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. The President recently signed into law two statutes 
directed to the improvement of 911: (1) Kari's Law Act of 2017 (Kari's 
Law), which requires implementation of direct 911 dialing and on-site 
notification capabilities in multi-line telephone systems (MLTS), and 
(2) Section 506 of RAY BAUM'S Act (RAY BAUM'S Act), which requires the 
Commission by September 23, 2019 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].''
    2. In this NPRM, we propose to implement Kari's Law by adopting 
direct dial and notification rules governing calls to 911 made from 
MLTS. As required by RAY BAUM'S Act, we also consider the feasibility 
of requiring dispatchable location for 911 calls from MLTS and other 
technological platforms that currently complete calls to 911. We 
propose establishing a dispatchable location requirement for MLTS 911 
calls, which would apply contemporaneously with the February 16, 2020 
compliance date of Kari's Law. Additionally, in keeping with the 
directive in RAY BAUM'S Act to address dispatchable location for 911 
calls ``regardless of the technological platform used,'' we propose to 
add dispatchable location requirements to our existing 911 rules for 
fixed telephony providers, interconnected Voice over internet Protocol 
(VoIP) providers, and internet-based Telecommunications Relay Services 
(TRS). We also consider 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, we consider 
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.
    3. Finally, we propose to take this opportunity to consolidate our 
existing 911 rules, as well as the direct dialing and dispatchable 
location rules proposed in this NPRM, into a single rule part. The 
Commission historically has taken a service-specific approach to 911, 
resulting in 911 requirements for different services scattered across 
different sections of the agency's rules. We believe that consolidating 
our 911 rules from these various rule sections into a single rule part 
will further the goal of recognizing that all the components of 911 
function as part of a single system and will enable 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.

II. Background

A. E911 and Multi-Line Telephone Systems

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

[[Page 54181]]

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, 
namely direct dialing access to 911 and the provision of the MLTS 
user's location information.
    6. MLTS include a widely embedded base of legacy PBX, Centrex, and 
Key Telephone systems, internet Protocol (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.
    7. The National Emergency Number Association (NENA) has proposed 
model MLTS legislation for states, as well as model federal MLTS 
legislation. To date, 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.
    8. 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. 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
    9. In September 2017, the Commission released a Notice of Inquiry 
(ECS NOI) seeking information on the capabilities of enterprise 
communications systems (ECS) to support direct 911 access, routing, and 
automatic location. The Commission noted that ECS may not provide 
consumers with the same access to E911 services as non-ECS 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 ECS users are 
suited to state-level action rather than federal regulation. The ECS 
NOI also sought information on the state of the ECS industry; the costs 
and benefits of supporting E911 for ECS; the capability of ECS to 
provide accessible emergency communications for persons with 
disabilities; and options for ensuring that ECS keep pace with 
technological developments and consumer expectations for access to 911.
    10. The Commission received 19 comments and six reply comments in 
response to the ECS NOI. Commenters generally agreed that the ECS 
marketplace is diverse and complex. For example, Cisco categorized ECS 
as falling within three types: (1) On-premises hardware and software; 
(2) cloud solutions; and (3) over-the-top applications. West Safety 
categorized ECS as falling within three additional and different types: 
(1) Time-division multiplexing (TDM) ECS, which are self-contained and 
proprietary and use physical switches and wiring with localized 
infrastructure; (2) hybrid ECS, which have combined TDM and IP 
extensions and provide reduced infrastructure and interoperability; and 
(3) IP ECS, which have centralized infrastructure and servers, Session 
Initiation Protocol (SIP) capabilities with multimedia support, and 
scalability. West Safety noted that TDM-based ECS have been ``nearing 
end-of-life for a long time now'' and that the vast majority of 
enterprises have migrated, or will migrate soon, to pure IP-based ECS 
to support VoIP and Unified Communications (UC) systems, with an 
increasing trend toward cloud-based service offerings.
    11. Commenters underscored the importance of ensuring the 
accessibility of ECS for persons with disabilities, including ECS 
capability to handle text (including real time text (RTT)), data, 
video, and text telephone (TTY) calls and the availability of 
dispatchable location information to PSAPs regardless of the type of 
call being made. Commenters, however, disagreed over whether it is 
feasible for all types of ECS to support precise location of 911 
callers. In addition, commenters disagreed regarding the Commission's 
authority to establish 911 requirements for ECS. Some commenters 
asserted that the Commission lacked such authority because most 
enterprise owners and equipment manufacturers do not provide interstate 
communications, or because ECS owners and operators are not service 
providers under Title II of the Communications Act or licensees under 
Title III. Other commenters asserted that 911 calls from ECS are 
interstate in nature, and that the Commission has broad authority over 
public safety and 911, including authority over ECS operators and 
equipment and service vendors under Sections 1, 4, and 255 of the 
Communications Act, as well as the Twenty-First Century Communications 
and Video Accessibility Act of 2010 (CVAA). Finally, some commenters 
asserted that state regulation of ECS 911 service is not working and 
urged the Commission to begin a rulemaking, while others urged the 
Commission to continue to defer to the states to address ECS 911 
functionality.

B. Kari's Law and RAY BAUM'S Act

    12. Kari's Law. After the close of the ECS NOI comment/reply cycle, 
Kari's Law was enacted on February 16, 2018. Kari's Law has been added 
to the Communications Act of 1934 as amended (the Act) as section 721.
    13. 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.''
    14. 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

[[Page 54182]]

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.'' Additionally, 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.''
    15. With regard to implementation, 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.
    16. RAY BAUM'S Act. The President signed the Consolidated 
Appropriations Act of 2018, including RAY BAUM'S Act, into law on March 
23, 2018. 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.

III. Discussion

A. Direct Dialing and Notification for MLTS

    17. Kari's Law is a provision of the Communications Act of 1934, as 
amended. Accordingly, the Commission has authority to prescribe such 
rules and regulations as are necessary to carry out Kari's Law. We 
believe that adoption of implementing regulations would provide 
additional clarity and specificity regarding the terms used in the 
statute and the obligations placed on covered entities. 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 proposed 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.
1. Direct Dialing
    18. Applicability and Obligations. We propose direct dialing 
requirements for persons engaged in the business of manufacturing, 
importing, selling, or leasing MLTS, as well as persons engaged in the 
business of installing, managing, or operating MLTS, that track the 
obligations in Kari's Law. We seek comment on these proposed 
implementing regulations.
2. Notification
    19. Applicability and Obligations. Consistent with Kari's Law, we 
propose to adopt implementing regulations requiring that a person 
engaged in the business of installing, managing, or operating MLTS 
shall, in installing, managing, or operating the system, configure it 
to provide a notification that a 911 call has been placed by a caller 
on the MLTS system. The system configuration must provide for the 
notification to be transmitted 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. This notification requirement 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.
    20. Required Information and Purpose. Although Kari's Law requires 
MLTS to support notification when an MLTS user makes a 911 call, it 
does not specify what information must be provided in the notification. 
In comments on the ECS NOI, West Safety noted that on-site notification 
can be configured to include name, callback number, precise station-
level location, and links to enhanced data such as detailed floor plans 
and emergency contacts. NENA's model federal MLTS legislation provides 
for on-site notification that would automatically alert a designated 
emergency station on the premises that 911 has been dialed from the 
MLTS and would include specific location information for the station 
from which the call originated. Rules implementing a Texas statute 
similar to Kari's Law provide that the notification should include the 
telephone number or extension and location information of the handset 
from which the 911 call is made, provided that it is feasible to do so.
    21. We tentatively conclude that for notification to be capable of 
achieving the purpose of Kari's Law, it should include certain basic 
information, such as the caller's location, that will assist the 
enterprise and first responders in coordinating and expediting on-site 
response to the emergency. According to Avaya, the benefits of on-site 
notification include that it can ``allow[] internal responders to 
confirm and assist the person who has dialed 9-1-1, and provide[] 
notice that first responders are on the way so that preparations can be 
made. This includes ensuring access doors are unlocked, elevators are 
available and hallways are unobstructed.'' RedSky has stated that on-
site notification ``can save 2-3 minutes in emergency response time 
when a 9-1-1- call is made.''
    22. We propose to require that notification at a minimum include 
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 PSAP with the call to 911. Thus, 
under our dispatchable location proposal discussed in Section B.1 
below, the notification to the enterprise would include the same 
dispatchable location information that the PSAP receives. Because the 
notification will help the enterprise to assist first responders, we 
believe 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, because our proposal assumes the 
notification would only convey information that already exists for the

[[Page 54183]]

911 call, we tentatively conclude that providing the same information 
would minimize additional burdens. We seek comment on this proposed 
approach. Are there situations in which the callback or location 
information conveyed to the PSAP need not be included with an on-site 
notification? Instead of specifying the content of the notification, 
should we allow enterprises the flexibility to customize notification 
as they see fit? Is there an alternative approach that would be 
superior to the one proposed in terms of costs and benefits?
    23. Notification Timing and Destination Points. Kari's Law is 
silent on when the notification must be provided. We believe that 
timely notification is essential, because delayed notification could 
impede coordination between enterprise management or staff and first 
responders seeking access to the enterprise premises. Therefore, we 
propose to require that MLTS covered by Kari's Law be configured so 
that notification is contemporaneous with the 911 call and does not 
delay the placement of the call to 911. We seek comment on this 
proposal, as well as any alternatives.
    24. We also seek comment on whether there should be any 
requirements relating to the location, configuration, or staffing of 
notification destination points. Kari's Law provides 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.'' We believe this language 
indicates Congress's recognition that in the enterprise settings in 
which 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 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. We seek comment 
on additional options for implementing such requirements.
    25. We seek comment on whether the Commission should specify any 
criteria for destination points to ensure that notifications, whether 
on-site or off-site, 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, should we 
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? This would afford the 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 a part of existing duties, or to an on-site 
location where staff are normally present. We seek comment on this 
approach. Where notification is provided to a ``person or organization 
regardless of location,'' should we require that the person or 
organization be one that is authorized to provide first responders with 
access to the location from which the MLTS 911 call originated? 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. We seek 
comment on this approach.
    26. We also seek comment on the cost and expected benefit of the 
above-mentioned options for implementing the notification requirement 
of Kari's Law. We note 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. We do 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, we believe that allowing 
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. We seek comment on this approach. What means are available to 
reasonably ensure that notification will be timely received by a person 
with authority to act on it? For example, could alarm companies, 
security firms, or similar entities create efficiencies by providing 
911 notification monitoring for multiple customers? Are there other 
means to reduce these costs?
    27. We also seek comment on how the statute's notification 
requirements should be applied to small enterprises. 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. Do the benefits and costs of notification apply differently 
to small businesses? 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. At the same time, small enterprises 
using MLTS may find benefits to notification in addition to access and 
support. For example, on-site personnel can intervene when 911 is 
dialed in error, enabling them to contact the PSAP and avoid sending 
emergency responders to a location that does not require a response.
3. Definitions.
    28. Multi-Line Telephone System. Kari's Law and RAY BAUM'S Act 
define the term ``multi-line telephone system'' 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.''
    29. We propose 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. We further 
propose to interpret this definition to include enterprise-based 
systems that allow outbound calls to 911 without providing a way for 
the PSAP to place a return call. We believe 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, advances the 
purpose of the statute. In addition, there is nothing in the language 
of the definition of MLTS

[[Page 54184]]

from the Middle Class Tax Relief and Job Creation Act of 2012 that 
excludes systems allowing only outbound calls to 911.
    30. We seek comment on our proposed definition of the term MLTS. 
Are there other ways in which the Commission should clarify the meaning 
of MLTS, and if so, what are they? Should we define MLTS to include 
systems that allow outbound calls to 911 but not inbound calls, as 
proposed above? How common are such systems? Are 911 calls from such 
systems identified as outbound-only at the PSAP? Are outbound-only 
systems ever deployed together with systems that allow two-way calling? 
If so, how do enterprise managers address the potential for end user 
confusion over the ability to receive a return call from the PSAP over 
a particular system?
    31. Pre-configured and configured. Next, we propose to define the 
statutory terms ``pre-configured'' and ``configured'' as applied to 
MLTS direct dialing. First, we propose to define ``pre-configured'' to 
mean 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. 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. We believe this means that an MLTS may support 
additional dialing patterns, but manufacturers (and importers, sellers, 
or lessors) must ensure that the default, ``out-of-the-box'' 
configuration allows users to reach 911 directly.
    32. Second, we propose to define ``configured'' to refer to the 
settings or configurations implemented for a particular MLTS 
installation. To meet this definition, the MLTS must be fully capable 
when installed of dialing 911 directly and providing notification as 
required under the statute and rules. As with ``pre-configured,'' an 
MLTS may be configured to support additional dialing patterns, but 
manufacturers (and importers, sellers, or lessors) must ensure that 
they are in addition to the default direct dialing pattern. We seek 
comment on this proposed definition. Cisco noted in its comments on the 
ECS NOI that ``[c]onfiguring [MLTS] is an entirely different line of 
business than manufacturing [MLTS].'' Under our proposed definitions, 
is the difference between ``pre-configuring'' an MLTS and 
``configuring'' an MLTS sufficiently clear? If not, how can we clarify 
the differences?
    33. Improvement to the hardware or software of the system. Kari's 
Law provides that the notification requirements of the statute apply 
only if the system can be configured to provide notification ``without 
an improvement to the hardware or software of the system.'' We propose 
to define the term ``improvement to the hardware or software of the 
system'' to include upgrades to the core systems of an MLTS, as well as 
substantial upgrades to the software and any software upgrades 
requiring a significant purchase. We seek comment on this proposed 
definition. Are there types of routine hardware or software changes 
that should be included in or excluded from the definition? For 
example, should 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? What changes should we consider minor? Should 
upgrades requiring a significant purchase be determined based on total 
cost alone, or should we interpret significant to be a relative 
determination based on the size of the entity making the purchase?
    34. A person engaged in the business of manufacturing, importing, 
selling, or leasing an MLTS. Kari's Law prohibits the manufacture or 
importation for use in the United States, or sale or lease or offer to 
sell or lease in the United States, of non-compliant MLTS. We 
tentatively conclude that the meaning of the term ``person engaged in 
the business of manufacturing, importing, selling, or leasing an MLTS'' 
is self-evident, and we do not propose to modify or add to this 
definition in our rules. We nonetheless seek comment on whether any 
additional clarification of this term is necessary for implementation 
or enforcement of Kari's Law. For instance, should we clarify that a 
person engaged in the business of manufacturing, importing, selling, or 
leasing MLTS includes a distributor or reseller of MLTS?
    35. A person engaged in the business of installing an MLTS. We 
propose to define a person engaged in the business of installing an 
MLTS as a person who installs or 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. We note that 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. We seek 
comment on our proposed definition.
    36. A person engaged in the business of managing an MLTS. We 
propose 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. We also propose to 
interpret the 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. Thus, 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. We seek comment on this proposed definition.
    37. A person engaged in the business of operating an MLTS. We 
propose to define a person engaged in the business of operating an MLTS 
as an entity responsible for the day-to-day operations of the MLTS. As 
with our proposed definition of MLTS manager above, we also propose to 
interpret this term to mean that an MLTS user that does not own, lease, 
or exercise control over the MLTS would not be deemed to be engaged in 
the business of operating the MLTS. We seek comment on our proposed 
definition.
    38. We also seek comment on whether there are circumstances in 
which our proposed definitions of MLTS ``manager'' or ``operator'' 
should extend to enterprise owners. Commenters on the ECS NOI 
emphasized that some enterprise owners purchase, operate, and maintain 
their own on-premises telephone systems with PBX equipment, while 
others enter contractual arrangements with third-party providers of 
network and hosted services. AT&T noted that the decision whether to 
purchase and implement an MLTS solution lies with the enterprise owner

[[Page 54185]]

and that the owner ``must have a role to play in ensuring that 911 
capabilities are functioning as intended.'' As noted above, we do not 
believe that 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, 
there may be instances where enterprise owners purchase, operate, and 
maintain their own MLTS systems, or they may exercise active control 
over the configuration and provision of MLTS by third parties. In such 
instances, should enterprise owners be deemed to be MLTS managers or 
operators? What indicia of active control should be considered in 
making this determination?
4. Other Issues
    39. Compliance date. Consistent with the provisions of Kari's Law, 
we propose that the compliance date for our implementing regulations 
will be two years from the date of the law's enactment, i.e., on 
February 16, 2020. Thus, the proposed direct dialing and notification 
requirements would apply to MLTS that are manufactured, imported, 
offered for first sale or lease, first sold or leased, or installed 
after February 16, 2020. We seek comment on this proposed compliance 
date for implementing regulations, as well as on alternatives. Those 
offering alternatives should explain how any proposed date that differs 
from the one that we propose would be consistent with the statutory 
language.
    40. Transitional Issues. Kari's Law applies only with respect to 
MLTS that are manufactured, imported, offered for first sale or lease, 
first sold or leased, or installed after February 16, 2020. 
Accordingly, MLTS manufactured, imported, offered for first sale or 
lease, first sold or leased, or installed on or before that date are 
grandfathered from compliance with the statute. To what extent is 
direct dialing of 911 already available and in use in MLTS? To the 
extent that MLTS in use do not support direct dialing, what options are 
currently available to installers, managers, and operators that may be 
planning to upgrade or replace their systems? Are there any barriers 
facing (1) MLTS manufacturers, importers, sellers, and lessors, and (2) 
MLTS installers, managers, and operators, to meet the statute's direct 
dialing requirements by the compliance date? If so, what are those 
barriers and what are the potential costs of overcoming them?
    41. We also seek comment on whether we should adopt transitional 
rules to inform consumers of the 911 capabilities of grandfathered 
MLTS. For example, the state version of Kari's Law enacted in Texas 
requires enterprises to place a sticker adjacent to or on non-compliant 
MLTS devices that provides instruction in English and Spanish on how to 
call 911. Similarly, the Commission's interconnected VoIP E911 rules 
require service providers to distribute stickers or labels warning 
subscribers that E911 service may be limited. We seek comment on 
whether to require MLTS installers, operators, and managers to notify 
callers how to dial 911 from grandfathered systems, as well as options 
for doing so and their related costs. In addition, we seek comment on 
potential sources of statutory authority for such requirements.
    42. Enforcement. Under Kari's Law, the Commission is empowered to 
enforce the statute under Title V of the Communications Act, ``except 
that section 501 applies only to the extent that such section provides 
for the punishment of a fine.'' We seek comment on how the Commission 
should enforce and provide oversight of the requirements of Kari's Law. 
As a general matter, we envision following the framework set forth by 
the statute. For example, a manufacturer could face enforcement action 
for offering to sell an MLTS that is not pre-configured to support 
direct 911 dialing, and an MLTS operator could face enforcement action 
for operating the system when it was not configured so that users could 
dial 911 directly. We seek comment on the potential use of this 
enforcement approach for Kari's Law.
    43. Additionally, we seek comment on who, or which entities, should 
bear responsibility for violations of the proposed rules. Verizon 
comments that there can be great variation in the business 
relationships between MLTS installers, operators, and managers: ``In 
some cases the service provider and the system operator or vendor will 
each have a direct relationship with an enterprise customer. In other 
cases the service provider may be a subcontractor to the system 
operator, and only provide certain components of the service (such as 
MPLS circuits for transport or other trunking services), with limited 
or no say in the design or configuration of the product. Or the reverse 
may be true--i.e., the enterprise system operator is a subcontractor of 
the service provider, and the service provider maintains the direct 
contractual relationship with the customer.''
    44. We propose to apply a presumption that the MLTS manager bears 
ultimate responsibility for compliance with our proposed rules 
implementing Kari's Law. For example, if an MLTS fails to comply with 
our proposed 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 our proposed rules. We seek comment on this 
proposal. How should we apportion liability in situations where 
multiple parties may be responsible for compliance with the statute and 
our proposed rules? For example, in a case where the MLTS manager 
contracts with a third party to install and operate an MLTS, but the 
third party fails to comply with the Commission's rules, should the 
MLTS manager and third-party contractor be held jointly or individually 
responsible? What evidence or factors should we look to in apportioning 
or rebutting a presumption of liability?
    45. Complaint Mechanisms and Other Issues. We envision relying on 
existing Commission complaint mechanisms to facilitate the filing of 
complaints for potential violations of Kari's Law. For example, 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. We seek comment on this.
    46. We also seek comment on whether to modify our equipment 
authorization rules as they apply to MLTS equipment manufactured after 
February 16, 2020. Should MLTS applications for equipment authorization 
under Parts 2, 15, or 68 constitute a representation that such 
equipment complies with MLTS 911 requirements?
    47. Finally, we ask commenters to identify voluntary best practices 
that can improve the effectiveness of direct dialing and notification 
for MLTS. For example, the Michigan State 911 Committee has developed 
guidelines that call for MLTS operators to work directly with their 
local public safety entities to ensure compliance. The Michigan State 
911 Committee also ``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.'' We seek comment on this 
and other recommended or potential best practices that would help 
enterprises ensure the effectiveness of direct dialing and 
notification. Are there best practices for the training of on-site 
emergency personnel and others responsible for the implementation of 
direct dialing and notification?

[[Page 54186]]

Similarly, are there best practices for the operation of an on-site or 
offsite notification point of contact?
5. Comparison of Benefits and Costs
    48. According to a Congressional Budget Office analysis, 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 addition, eight states and some local governments already 
have laws that require direct dialing for 911 from MLTS. For these 
state and local jurisdictions, our proposed rules would generally not 
affect the status quo and so would likely have little to no impact from 
a cost perspective. Moreover, the existence of state-level requirements 
has 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. We seek comment on the 
number of MLTS systems currently deployed that do not allow direct 
dialing of 911 and/or cannot be configured to provide notification of 
911 calls to an MLTS manager.
    49. Consistent with Kari's Law, our proposed rules would apply only 
with respect to MLTS that are manufactured, imported, offered for first 
sale or lease, first sold or leased, or installed after February 16, 
2020, which means that there should be no immediate costs or stranded 
investment with respect to existing MLTS or systems that first come 
into service on or before February 16, 2020. As noted above, many 
existing, installed MLTS support direct dialing to 911 and 
notification. Therefore, we tentatively conclude that there will be no 
immediate costs or benefits associated with meeting the requirements of 
our rules. For systems coming into service after February 16, 2020, we 
seek comment on the costs and benefits of satisfying our proposed 
rules. Are there alternative methods of meeting the requirements of 
Kari's Law that would reduce costs and/or increase benefits? Will any 
barriers exist for those wishing to replace their MLTS after this date 
that would be costly to overcome? We also seek comment on the expected 
lifespan of existing MLTS that are not currently able to meet the 
requirements of our proposed rules. What is the prevalence of such 
systems today, and what will the expected prevalence of such systems be 
in 2020? We seek comment on the cost of upgrading to an MLTS that 
supports the requirements of our proposed rules. Because 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. We seek comment on this tentative 
conclusion.
    50. Specifically as to notification, we tentatively conclude that 
the costs of implementing our proposed requirements will not exceed the 
value of their benefits. As discussed above, notification can assist 
MLTS managers in large enterprises in dealing with first responders. 
Prepared with information about a 911 call, a manager will be able to 
quickly direct and assist first responders at large enterprises, rather 
than spending time trying to gather such information. Notification will 
also benefit the 911 caller and first responders by allowing quicker 
response time. This analysis is supported by RedSky's ECS NOI comments, 
which state that, in its experience, ECS customers that receive these 
types of notifications ``can save 2-3 minutes in emergency response 
time when a 911 call is made.'' We also anticipate that notification 
will provide MLTS managers with opportunities to efficiently notify the 
PSAP of accidental 911 calls, preserving first responder resources and 
allowing the MLTS manager to avoid state or municipal fines or 
penalties for accidental 911 calls. We observe that some states already 
have laws and regulations that require on-site notification for 911 
calls from MLTS. Similar to our proposed rules, the largest of these 
states defines notification to include the fact that a 911 call has 
been made, the caller's telephone number, and the caller's location. 
For these state and local jurisdictions, we anticipate that our 
proposed rules would have minimal impact. Moreover, the existence of 
state-level requirements has likely driven the manufacture of MLTS 
equipment that supports notification for 911 calls, much of which may 
have been marketed and sold in jurisdictions that do not have state or 
local requirements or to small businesses that are exempted from state 
or local requirements. We seek comment on our tentative conclusion, as 
well as particular costs involved in imposing the notification 
requirement and alternative methods consistent with Kari's Law that may 
reduce costs and/or improve benefits. We seek comment on the costs and 
benefits associated with our proposed definitions. We also seek comment 
on the benefits and costs associated with any additional notification 
requirements the Commission might adopt, such as requiring 
grandfathered MLTS to inform consumers of the 911 capabilities of those 
systems.

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

    51. 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 consider 
whether to adopt dispatchable location requirements for MLTS and other 
911-capable services. In addition to MLTS, we examine four types of 
communications services that are currently required under Commission 
rules to provide 911 service to their customers: (1) Fixed telephony, 
(2) mobile telecommunications, (3) interconnected VoIP service, and (4) 
internet-based Telecommunications Relay Services (TRS). In addition, we 
examine whether we should adopt dispatchable location rules for other 
911-capable services that are not currently subject to 911 rules.
1. MLTS
    52. Applicability and Obligations. When a 911 call is placed in an 
MLTS environment, a location may be included in the information sent to 
the PSAP, but that location may not be the location of the caller. On a 
large campus or in a hotel, for example, a 911 call may convey the 
location of the main entrance or administrative office. Such location 
imprecision can lead to delays in locating the person making the 911 
call and result in further injury or loss of life.
    53. 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. 
Moreover, the enactment of RAY BAUM'S Act only weeks after Kari's Law 
indicates that Congress recognized the importance of providing accurate 
location information to PSAPs in connection with MLTS 911 calls. 
Dispatchable location is defined in the statute 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

[[Page 54187]]

location of the calling party.'' We therefore initiate this portion of 
our proceeding with Congress's stated goal in mind.
    54. We propose 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. 
Further, we propose 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. And we propose to apply these proscriptions to 
the same entities subject to Kari's Law. We seek comment on these 
proposals.
    55. In its comments to the ECS NOI, NCTA observed that ``ECS 
involves not only the service provider and end user, but also 
manufacturers and ECS programmers. Coordination and assignment of 
responsibilities among these ECS functions must be done seamlessly to 
ensure that 911 services function properly.'' For this reason, our 
proposals for dispatchable location parallel the direct dialing and 
notification requirements of Kari's Law in that they would apply 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. We seek comment on our approach to 
addressing the division of responsibilities when deploying and 
operating MLTS. Should more granular requirements be placed on any of 
the MLTS market participants to which our proposed rules would apply? 
Are new rules necessary to ensure that communication service providers 
(such as fixed telephony, mobile carriers, and interconnected VoIP 
service providers) that complete 911 calls originating from MLTS convey 
dispatchable location, or are existing 911 rules sufficient? Similarly, 
are rules needed to ensure that manufacturers and importers of MLTS 
incorporate capabilities in their products to enable them to convey 
dispatchable location information? Do standards exist for conveying 
dispatchable location information from MLTS? If so, should MLTS be 
required to conform to these standards? How should conformance of MLTS 
to such rules and standards be demonstrated?
    56. Defining Dispatchable Location. 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.'' We note that the statutory definition of 
dispatchable location is nearly identical to the dispatchable location 
definition in the Commission's mobile E911 location accuracy rules. 
Given the substantial similarity between the two definitions, we 
propose to construe them as functionally identical, aside from the 
specification of the technological platform to which each definition 
applies. We seek comment on this proposal.
    57. The mobile E911 definition of ``dispatchable location'' further 
requires that, when delivering dispatchable location, ``[t]he 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.'' We seek comment on whether we should require similar 
validation for dispatchable location information associated with MLTS 
911 calls. Is there any reason why street address validation would be 
more difficult or costly for MLTS than for mobile E911?
    58. We also seek comment on whether our rules should further define 
``additional information'' that may be necessary in an MLTS context to 
``adequately identify the location of the calling party.'' In the 
Indoor Location Fourth Report and Order, the Commission found that the 
definition of dispatchable location applicable to mobile carriers 
``strikes the appropriate balance between specificity and 
flexibility,'' and therefore does not necessitate further specification 
of types of location information to be conveyed. We seek comment on 
applying the same approach for MLTS dispatchable location. We believe 
MLTS installers, managers, and operators will be able to identify 
situations in which street address is sufficient for first responders 
to quickly and accurately find the calling party. We also expect that 
street address would serve as a dispatchable location for the smallest 
enterprises. Nonetheless, should we specify the situations in which 
street address is not sufficient, and more granular location 
information is needed? For example, NENA's model federal MLTS 
legislation generally requires business MLTS to provide location 
information for each floor of each property served, as well as each 
7,000 square feet of workspace beyond the first. Several commenters on 
the ECS NOI supported this approach to providing dispatchable location 
for MLTS. If commenters believe we should specify when more granular 
information is needed, what should be our criteria for identifying 
those situations? When more granular information is needed, what 
elements of location, in addition to room, floor, suite, or apartment 
number, could be used to locate a 911 caller using MLTS?
    59. We agree with TIA that we ``should be careful [not] to impose 
burdensome regulations that would eliminate the robust choices enjoyed 
by enterprises of all types in today's marketplace.'' Accordingly, we 
do not propose to require implementation of specific location 
technologies or solutions but rather seek comment on functional 
requirements that would give participants in the MLTS marketplace 
flexibility to develop dispatchable location solutions. We believe that 
this approach will allow the entities affected by these proposed rules 
to implement them in a manner that is appropriate in terms of cost, 
enterprise size, site layout, and technical sophistication. We note 
that several states already place requirements on MLTS providers to 
obtain and convey location information that is more detailed than 
street address alone.
    60. Feasibility of Conveying Dispatchable Location from MLTS. We 
tentatively conclude that it is feasible for 911 calls that originate 
from MLTS to convey dispatchable location to the appropriate PSAP, as 
several commenters to the ECS NOI indicate that they are already 
offering methods for dynamically determining and conveying an MLTS end 
user's location. We seek comment on this tentative conclusion. We 
observe that potential dispatchable location solutions for MLTS include 
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.
    61. We also seek comment on whether additional dispatchable 
location solutions can be implemented for MLTS. Are there technical 
elements necessary for supporting dispatchable location that are shared 
by these solutions? Do technical elements differ across dispatchable 
location solutions, and if so, how? Are the required technical elements 
consistent across types of MLTS solutions, including on-premises 
solutions, hosted cloud solutions, and over-the-top application-based 
solutions? Are the required technical elements shared by legacy MLTS 
and IP-based MLTS, and if not, should differing requirements be placed 
on them? In its comments on the ECS NOI, West Safety observed that 
``[l]egacy-based solutions may not be able to support E9-1-1 routing 
for users

[[Page 54188]]

accessing the ECS remotely.'' We seek comment on that observation. 
Should we place differing requirements on premises-based, cloud-based, 
and over-the-top application-based solutions? Should we require MLTS to 
convey particular types of location information, such as room number or 
floor number, when it is available? If an MLTS handles calls initiated 
by remote users, e.g., off-site workers, should we require it to convey 
the remote user's location information?
    62. We seek comment on whether the technical elements necessary for 
conveying dispatchable location with a 911 call are currently available 
in MLTS that are deployed today. We observe that several MLTS offered 
today provide 911 location solutions that are capable of conveying 
dispatchable location to PSAPs. Can currently-deployed MLTS that do not 
support provision of dispatchable location be upgraded to do so? If 
they can be upgraded, what would those upgrades entail, and what would 
they cost? For support of dispatchable location, what technical 
elements must be present in MLTS-related hardware, such as handsets, 
the device on which a softphone or voice application is installed, or 
other elements of the system? Which elements can be supported with 
updates to software or applications? If some MLTS in use today are not 
capable of supporting dispatchable location, we seek comment on whether 
those systems should be exempted from a dispatchable location 
requirement. For example, should we adopt compliance date provisions 
that track the provisions of Kari's Law as discussed above? Should we 
adopt disclosure requirements for grandfathered MLTS that are not 
subject to the rules? What should such disclosure rules require?
    63. We also seek comment on the steps that an MLTS manager or 
operator must take, if any, to ensure that dispatchable location is 
conveyed to the PSAP. What is the most effective, least burdensome 
means to ensure that this happens? For example, some commenters on the 
ECS NOI suggest that managers of cloud-based MLTS are in a unique 
position to administer, maintain, and update location information for 
the enterprise. Should we adopt rules requiring MLTS managers to 
provision location information for the enterprise to the MLTS operator? 
To what extent does our legal authority under these new statutes or our 
existing authority extend to such entities? What information should be 
initially provisioned and how frequently should we require that 
information to be updated? What are the costs associated with such 
provisioning and updating? For situations in which MLTS operators are 
capable of calculating a dispatchable location by inputting one or more 
sources of device-generated location data into a location information 
server, what requirements, if any, should we place on (1) MLTS 
manufacturers and importers; (2) sellers and lessors; (3) MLTS 
installers, managers, and operators; and (4) communications service 
providers to ensure that this information or the resulting dispatchable 
location information is conveyed to the PSAP?
    64. Although RAY BAUM'S Act directs the Commission to consider 
rules to ensure that dispatchable location is conveyed with 911 calls, 
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. We therefore 
believe that our rules and policies should not preclude--and in fact 
should allow and encourage--potential alternatives to dispatchable 
location. We seek comment on this view. Could other types of location 
information (for example, x/y/z coordinates) be conveyed with a 911 
call originating from MLTS? If we adopt dispatchable location 
requirements, should we allow provision of x/y/z/coordinates or other 
approaches to conveying location information to be alternatives to 
dispatchable location? We also seek comment on the usefulness of x/y/z 
coordinates to PSAPs and first responders for responding to MLTS 911 
calls. Are they currently equipped to receive and use such information?
    65. We also seek comment on whether there are other sources of 
location information, such as the National Emergency Address Database 
(NEAD), the location database being developed by the major mobile 
carriers to provide dispatchable location for indoor mobile 911 calls, 
that could potentially assist MLTS managers and operators in 
determining the dispatchable location of MLTS end users. Could MLTS 
managers and operators leverage these other sources of location 
information? What actions, if any, should we take to facilitate use of 
the NEAD and other location information sources for MLTS managers and 
operators? With respect to the NEAD in particular, are there 
obligations that should be placed on entities that seek to access the 
NEAD? As it has been contemplated that dispatchable location 
information from third-party sources will be integrated into the NEAD, 
we seek comment on whether MLTS managers and operators are positioned 
to contribute dispatchable location reference points to the database. 
If they are capable of making such contributions, should they be 
required to do so as a condition of leveraging the NEAD? Similarly, 
should they required to contribute to the operating costs of the NEAD 
as a condition of leveraging it?
2. Fixed Telephony Providers
    66. Section 64.3001 of the Commission's rules requires all 
telecommunications carriers, including fixed telephony providers, to 
transmit all 911 calls to a PSAP, to a designated statewide default 
answering point, or to an appropriate local emergency authority. 
Section 64.3001 does not require telecommunications carriers to convey 
the location of the caller with the call, and there is no Commission 
911 location rule applicable to fixed telephony carriers. However, 
pursuant to applicable state law, fixed telephony carriers typically 
provide validated street address information in conjunction with their 
customers' 911 calls.
    67. We propose to amend our rules to require providers of fixed 
telephony services to provide dispatchable location with 911 calls. 
Fixed telephony carriers already provide validated street address 
information, which is likely sufficient in most cases, such as single 
family dwellings, to satisfy a dispatchable location requirement. 
However, dispatchable location as defined in RAY BAUM'S Act includes 
additional elements such as floor level and room number that may be 
necessary to locate the caller. We also believe that including fixed 
telephony carriers in our consideration of dispatchable location 
requirements at the federal level is consistent with the ``all 
platforms'' approach sought by Congress in the RAY BAUM'S Act, while 
omitting them could create the risk of gaps in the availability of 
location information. We seek comment on this approach.
    68. We seek comment on whether it is technically feasible for fixed 
telephony carriers to convey dispatchable location with a 911 call. In 
many instances, as noted above, fixed telephony 911 calls from single 
family homes, feasibility appears to be established because fixed 
telephony carriers already provide validated street address information 
to the PSAP and first responders do not typically require additional 
room or floor level information. We seek comment on the extent to which 
fixed telephony carriers

[[Page 54189]]

also provide other information, such as floor level and room number, 
for 911 calls from multi-story buildings and similar environments. How 
frequently do fixed telephony 911 calls convey only street addresses 
where additional information would be needed to locate the caller? What 
obstacles exist, if any, to fixed telephony carriers conveying 
dispatchable location to PSAPs? If obstacles exist, how could they be 
overcome, and at what cost? Could the NEAD, similar databases, or other 
sources of location information assist fixed telephony carriers in 
providing dispatchable location with 911 calls? What obligations, if 
any, should be placed on fixed telephony carriers that seek to access 
the NEAD? If so, what steps could the Commission take, if any, to 
facilitate the use of such databases by fixed telephony providers? Are 
there any alternatives to dispatchable location that fixed telephony 
carriers could use to provide in-building location information beyond 
street addresses, e.g., coordinate-based information?
3. Mobile Carriers
    69. The E911 location accuracy rules applicable to mobile 911 voice 
service, set forth in Section 20.18 of our rules, provide that mobile 
carriers can meet our accuracy requirements by either conveying 
dispatchable location or coordinate-based location information. Because 
we have already incorporated dispatchable location into our E911 rules 
for mobile voice service, and mobile carriers are developing 
dispatchable location solutions based on those rules, we do not 
consider further changes in this proceeding to existing dispatchable 
location requirements. We note that this is consistent with RAY BAUM'S 
Act, which states that the Commission is not required to ``reconsider 
any information or conclusion'' made in proceedings prior to the 
statute's enactment.
    70. With respect to text-to-911, our 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 location information to the PSAP 
for the purpose of locating the person sending the text. The Commission 
has previously asserted that this approach is only an interim solution, 
and that it intends to require the delivery of enhanced location 
information with texts to 911 as soon as it is technically feasible to 
do so.
    71. The Commission has previously proposed a requirement that, no 
later than two years after the effective date of the adoption of final 
rules on enhanced location for 911 texts, covered text providers must 
deliver enhanced location information (consisting of the best available 
location that covered text providers could obtain from any available 
location technology or combination of technologies, including device-
based location) with texts to 911. We seek to refresh the record on how 
enhanced location information can be generated and delivered with text 
messages to 911. Is it technologically feasible today to convey a 
dispatchable location, or other types of enhanced location information, 
to the appropriate PSAP when a text message is sent to 911? If not, 
what is the likely timeframe for covered text providers to achieve such 
capability? Is there completed, ongoing, or anticipated future 
standards work that would facilitate delivery of dispatchable location 
information by covered text providers? If it is technologically 
feasible, should we apply dispatchable location requirements to text-
to-911 consistent with requirements applied to other platforms? What 
would be the cost of such a requirement? To the extent that some text-
to-911 dispatchable location requirement would be feasible but should 
differ from that applicable to other platforms, commenters should 
explain the basis for any distinctions, what alternative(s) could work 
for text-to-911 dispatchable location, and why.
4. Interconnected VoIP Providers
    72. The Commission's rules require interconnected VoIP providers to 
transmit Automatic Number Identification (ANI) and the caller's 
Registered Location with each 911 call. Interconnected VoIP providers 
must obtain a Registered Location, which is the most recent information 
that identifies the physical location of an end user, from each 
customer prior to the initiation of service. In addition, providers 
must enable end users to update their Registered Location at will and 
in a timely manner. The Registered Location of such calls must be made 
available to the appropriate PSAP, designated statewide default 
answering point, or appropriate local emergency authority from or 
through an appropriate automatic location information database. The 
Commission has also previously sought comment on the possibility of 
interconnected VoIP services providing real-time automatic location 
information to support 911 calls from consumers that use interconnected 
VoIP services from mobile or portable devices, such as smartphones or 
laptops.
    73. The Commission adopted the Registered Location requirement in 
2005 to support the provision of location information from 911 callers 
that typically use interconnected VoIP service from a single fixed 
location, such as a residence (fixed VoIP), or that move from one fixed 
location to another (nomadic VoIP). Although RAY BAUM'S Act provides 
that the Commission is not required to reconsider E911 location rules 
adopted in prior proceedings, as discussed below, we believe that it is 
appropriate to consider revising our E911 rules for interconnected VoIP 
to require the provision of dispatchable location.
    74. Fixed VoIP. With respect to fixed VoIP, we believe it is 
feasible for 911 calls that originate from interconnected VoIP services 
to convey dispatchable location to the PSAP, in that the current 
Registered Location obligations are sufficient for this purpose. In 
this respect, we note that the Registered Location information that is 
already conveyed with such calls today typically includes street 
address information, which should be sufficient for dispatchable 
location in the case of single family homes and small buildings where 
the PSAP and first responders do not require additional room or floor 
level information. In addition, interconnected VoIP providers can also 
enable customers in multi-story buildings and similar environments to 
provide room or floor level information as part of the Registered 
Location when needed. We seek comment on this proposal.
    75. Nomadic VoIP. With respect to nomadic VoIP, we seek comment on 
whether Registered Location satisfies a dispatchable location 
requirement. In particular, we note that a Registered Location that was 
recorded when service was initiated is less likely to accurately 
identify the real-time location of an end user that moves frequently 
between home, work, and other locations. Is Registered Location a 
sufficient proxy for dispatchable location in a nomadic environment, 
where the relevant device is able to prompt the user for an updated 
location when it has been moved? We seek comment on what technical 
elements would be required in the end user's device and/or the service 
provider's network to support the provision of real-time dispatchable 
location as proposed, and the degree to which those technical elements 
are already in place. For example, as we have noted in the discussion 
of MLTS location in Section B1 above, there appear to be IP-based 
solutions currently available for providing MLTS dispatchable location 
dynamically in buildings, campuses, and similar environments. We seek

[[Page 54190]]

comment on whether these solutions could also be leveraged by 
interconnected VoIP providers when their customers call 911 from such 
environments.
    76. We note that in the Registered Location context the burden is 
on the end user to update the Registered Location whenever the end user 
moves from one location to another. We seek comment on whether nomadic 
interconnected VoIP providers have, or can develop in the near term, 
the means to provide automatic dispatchable location with 911 calls in 
lieu of conveying the customer's Registered Location. We believe 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. Therefore, we seek comment on the degree to 
which mechanisms exist for 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. How accurate is the location information acquired in these 
scenarios, and would it be sufficient to meet the proposed definition 
of dispatchable location? Are sources of reliable location information 
available to interconnected VoIP providers? Could the NEAD assist 
interconnected VoIP providers with dynamic determination of the 
location of end users? If so, what steps could the Commission take, if 
any, to facilitate the use of the NEAD by interconnected VoIP 
providers? What obligations, if any, should be placed on interconnected 
VoIP providers that seek to access the NEAD?
    77. While we prefer to encourage the development of dispatchable 
location solutions that do not require manual end user updates, we 
recognize that such solutions may not be feasible or cost-effective in 
all circumstances. For example, as part of the 911 call session, if 
real-time dispatchable location information cannot be generated 
automatically, the VoIP provider may need to send an interactive query 
to the end user to confirm the location identified by the provider, and 
to correct the location if needed. To enable interconnected VoIP 
providers to appropriately balance technical feasibility, 
functionality, customer impact, and cost, we propose to allow providers 
flexibility in implementing dispatchable location solutions, and to 
fall back to Registered Location options when dispatchable location is 
not feasible. Thus, solutions may include, but are not limited to, 
determining the customer's location dynamically, pre-populating a 
previously-supplied Registered Location based on the network attachment 
point, or requesting a new Registered Location from the customer when 
the customer initiates a new connection or attachment to the network. 
We seek comment on this approach.
    78. Finally, we seek comment on any alternative approaches that 
would achieve the same aims as the proposed rules. Are there mechanisms 
or best practices for refreshing or validating location information 
that should be encouraged or required? Are there alternatives to 
dispatchable location that interconnected VoIP providers could use to 
provide location information, e.g., coordinate-based information? We 
seek comment on whether these, or other approaches, would provide the 
greatest likelihood of conveying an accurate location to the PSAP while 
minimizing the burdens on the interconnected VoIP service provider and 
the end user.
5. Telecommunications Relay Services
    79. Section 64.604 requires Text Telephone-based (TTY-based) TRS 
providers to use a system for incoming emergency calls that, at a 
minimum, automatically and immediately transfers the caller to an 
appropriate PSAP. Section 64.605 generally requires internet-based TRS 
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 other emergency calls 
(specifically those that use a Video Relay Service (VRS) or IP Relay), 
the service provider must transmit location information to the PSAP in 
the form of a Registered Location, including for devices capable of 
being moved to a different location. The Commission modeled these 
requirements after the 911 location requirements for interconnected 
VoIP services discussed above. We observe that internet-based TRS and 
interconnected VoIP service face similar concerns regarding the ability 
to accurately locate end users that use a mobile or portable device.
    80. As in our discussion of interconnected VoIP above, although RAY 
BAUM'S Act does not require reconsideration of previously adopted E911 
location rules, we believe it is appropriate as part of the Act's 
``all-platforms'' approach to consider revising our TRS E911 rules. 
Specifically, we seek comment on whether TRS providers can develop the 
means to provide updated dispatchable location. In particular, we seek 
comment on the feasibility of using existing Registered Location 
mechanisms to provide dispatchable location for fixed and nomadic VRS 
and IP Relay users, paralleling the rules we propose above for 
interconnected VoIP service. Is Registered Location sufficient in the 
fixed TRS environment? If a mechanism exists for manual updates by the 
user when a nomadic TRS device is used, is Registered Location 
sufficient to satisfy a dispatchable location requirement? As with 
VoIP, we also seek comment on the feasibility of having TRS devices 
and/or networks support the automatic provision of real-time 
dispatchable location without requiring registration or manual location 
updates by the end user. What technical elements would be required in 
the end user's device and/or the service provider's network to support 
this capability, and to what degree are such technical elements already 
in place? To what degree are TRS providers able 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? How accurate is the location information acquired in these 
scenarios, and would it be sufficient to meet the proposed definition 
of dispatchable location?
    81. To enable TRS providers to balance technical feasibility, 
functionality, customer impact, and cost, we propose to allow TRS 
providers flexibility in implementing dispatchable location solutions, 
and to fall back to Registered Location options when real-time 
dispatchable location is not feasible. We seek comment on this 
approach. We also seek comment whether there are differences between 
internet-based TRS and interconnected VoIP that might require taking a 
different approach to TRS dispatchable location from the approach 
proposed for interconnected VoIP. As with interconnected VoIP, we seek 
comment on whether the NEAD or a similar database could assist TRS 
providers in implementing dispatchable location solutions. If so, what 
steps could the Commission take, if any, to facilitate the use of such 
databases by TRS providers? What obligations, if any, should be placed 
on TRS providers that seek to access the NEAD? Finally, we seek comment 
on any alternative approaches

[[Page 54191]]

that would achieve the same aims as our proposed rules for TRS.
6. Other 911-Capable Services
    82. We seek comment on whether we should consider adopting 911 
rules for any other communications services that are not covered by 
existing 911 rules but provide the capability for users to make a 911 
call. RAY BAUM'S Act defines a ``911 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. What 
communications services that are not covered by existing 911 rules are 
capable of making 911 calls that fall within this definition? Are there 
any services that provide one-way voice communications that are capable 
of making such a 911 call? How often do consumers use these services to 
call 911? How do these services complete calls to PSAPs? What kinds of 
information, including callback numbers and location information, is or 
could be conveyed to PSAPs with these calls? What are PSAPs' 
experiences in answering these calls? What do consumers using these 
services understand about the limitations on any 911 services provided? 
Are these 911 calls effective at conveying location information to the 
PSAP? Do any specific communication services from which these 911 calls 
originate create difficulties in locating the caller? Is there 
consistency in the way calls originating from a specific communication 
service are received and are presented to the PSAP? Would outcomes for 
911 callers be improved if we adopted 911 rules for these 
communications services that parallel existing rules, including any 
requirements for conveying dispatchable location? Would new rules that 
are specifically tailored for those communications services be more 
effective at improving outcomes?
    83. We observe that some outbound-only VoIP services partner with 
businesses that offer 911 smartphone applications that allow consumers 
to make calls to 911. Some 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. Our current rules do 
not require outbound-only VoIP services to support 911 or convey 
dispatchable location with 911 calls. However, in 2011 the Commission 
sought comment on expanding 911 obligations to providers of outbound-
only VoIP services. In that case, the Commission proposed to amend the 
definition of the subject services to include any service that: (1) 
Enables real-time, two-way voice communications; (2) requires an 
internet connection from the user's location (as opposed to a broadband 
connection); (3) requires internet protocol-compatible customer 
premises equipment; and (4) permits users to terminate calls to all or 
substantially all United States E.164 telephone numbers.
    84. Based on the concerns noted above and in light of our previous 
proposal, we seek 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,'' defined as those 
services that enable real-time, two-way voice communications that 
require internet protocol-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. 
Is there any reason to exempt outbound-only VoIP services that allow 
911 calls from our 911 requirements simply because the service is 
incapable of receiving an incoming call from the PSTN? Does the public 
expect all VoIP services that allow the completion of 911 calls to meet 
the same minimum standards, without regard to whether the service can 
receive an incoming call? We seek comment on our proposal.
7. Additional Considerations
    85. For each of the communications service categories discussed 
above, we seek comment on common issues that are related to the 
implementation of dispatchable location requirements for 911 calls. We 
seek comment on how dispatchable location requirements for MLTS may 
interact with dispatchable location requirements for other 911-capable 
services. Are there situations in which the value of dispatchable 
location to first responders is diminished due to the availability of 
on-site notification to enterprises, or vice versa? In what situations, 
if any, should communications service providers be exempted from a 
dispatchable location requirement? Should providers be allowed or 
required to provide other types of location information, e.g., 
coordinate-based information, in addition to or as an alternative to 
satisfying a dispatchable location requirement? If communications 
services and/or certain types of providers (e.g., of a specific size, 
or with a specific number of consumers) are exempted from dispatchable 
location requirements, should we require them to provide consumer 
disclosure regarding the limitations of their 911 location 
capabilities? We also ask commenters to identify voluntary best 
practices that can improve the effectiveness of acquiring a 911 
caller's dispatchable location.
    86. As noted above, we believe MLTS installers, managers, and 
operators will be able to identify situations in which street address 
is sufficient for first responders to quickly and accurately find the 
calling party. We also expect that street address will suffice as a 
dispatchable location for the smallest enterprises. Accordingly, we do 
not propose size-based exceptions to the dispatchable location 
requirement. We seek comment on this approach.
8. Compliance Dates
    87. For all communications platforms that are to be covered by the 
dispatchable location requirements proposed in this NPRM, we propose to 
require compliance on the same date as our proposed implementation of 
Kari's Law, i.e., February 16, 2020. We tentatively conclude a uniform 
compliance date will promote efficiency by enabling MLTS manufacturers 
to implement dispatchable location upgrades on the same timeline as any 
upgrades needed to comply with the direct dial and notification 
requirements of Kari's Law. In addition, we tentatively conclude that 
applying the same compliance date to dispatchable location requirements 
across all platforms will encourage the development of common 
dispatchable location solutions that can support multiple platforms. We 
seek comment on this approach, as well as alternatives. With respect to 
MLTS, is it reasonable to anticipate that by the February 16, 2020 
compliance date for Kari's Law, newly manufactured MLTS will be capable 
of conveying dispatchable location with 911 calls? Are there 
dispatchable location solutions that can be widely and inexpensively 
implemented into MLTS being manufactured today? Do technical standards 
currently exist that would be appropriate for governing conveyance of 
dispatchable location from MLTS, or do such standards need to be 
developed? If the latter, how much time is needed to develop those 
standards, and who should develop them?
    88. We also seek comment on our proposal to apply the same February 
2020 compliance date for our proposed dispatchable location 
requirements for fixed telephony, interconnected VoIP, and TRS. We also 
seek comment on alternatives. Is there any reason to establish a 
compliance date or dates for these services that is either earlier or 
later than the proposed compliance date

[[Page 54192]]

for implementation of Kari's Law? Should compliance for different 
service types be phased as a way to require greater accuracy over time 
or to provide additional time to small businesses to come into 
compliance? Will PSAPs be capable of receiving dispatchable location by 
February 16, 2020, or are there additional steps that either some or 
all PSAPs must take to achieve this capability? Are existing class of 
service definitions sufficient to support PSAP receipt of dispatchable 
location or must new ones be developed? Are there standards-based 
approaches that could be taken to improve the technological 
capabilities of emergency calling (particularly as it expands beyond 
PSTN calls) while also improving the economics of enabling effective 
emergency calling? Should international roaming scenarios be taken into 
consideration? Are other countries/regions of the world developing 
emergency calling standards that have addressed location accuracy, 
routing to the appropriate PSAP, and provision of dispatchable location 
in the context of interconnected VoIP and other new technologies?
9. Comparison of Benefits and Costs
    89. We seek comment on whether providing dispatchable location for 
911 calls from MLTS and other communications services would improve 
emergency response and the health and safety of the public, and whether 
this benefit would exceed the cost of providing it. Commenters to the 
ECS NOI argued that the life-saving benefits of adopting E911 
requirements for MLTS are apparent. For example, NASNA asserted that 
just as E911 for landline, wireless, and VoIP has resulted in 
improvements in the speed at which emergency responders are able to 
reach the caller, so would E911 for ECS. NASNA stated, ``The magnitude 
of this benefit would be analogous to the well-studied, documented and 
proven benefits of E911 in general.''
    90. The scale of any potential benefits depends on the magnitude of 
the problem we are facing. Currently, how common are 911 calls from 
MLTS and other communications platforms that fail to convey any 
location information or that convey location information that is too 
imprecise or inaccurate to assist PSAPs and first responders in timely 
locating the caller? What is the expected lifespan of such systems? Is 
there any reason to expect that this situation will improve by 2020? If 
so, by how much? What cost differential will our proposed rules impose 
on MLTS and other systems purchased beginning in 2020? How many 
systems, at what additional cost, will be impacted? We seek comment on 
the 2013 decision attached to the California Public Utilities 
Commission (CPUC) comments on the ECS NOI, which found that potentially 
70 percent of California's PBX MLTS systems were not at the time 
provisioned to display accurate caller location information to any PSAP 
and that only ``350 of AT&T California's customers with PBX phone 
stations in 2007 had provisioned [PS/ALI] location information records 
in AT&T California's [E911] database.'' To what extent do these 
findings accurately reflect caller location information provided by 
MLTS? Could the results of these findings be extrapolated more broadly 
(e.g., outside of California)? How often are those calls routed to the 
wrong PSAPs due to poor or nonexistent location information?
    91. We also seek comment on the length and impact of delays in 
emergency response due to a lack of location information. RedSky 
asserts that ``[p]lacing a detailed, accurate location record in the 
hands of emergency responders can save 3-5 minutes in response time 
particularly in complex environments.'' Is 3-5 minutes a reasonable 
estimate of the improvement in response time? What are the consequences 
of those delays for a person needing emergency response? Can those 
consequences be quantified? Are there data on the speed of emergency 
response for calls that convey alternatives to dispatchable location, 
such as x/y/z coordinates? Are there other benefits that have accrued 
or could accrue in those systems and services that convey dispatchable 
location to PSAPs and first responders, such as reduced time spent on 
re-routing calls or arriving at the correct location? Are there any 
MLTS or other communications services (e.g., very small facilities) 
that would not benefit from conveying dispatchable location, or for 
whom the benefit would not exceed the cost?
    92. We seek comment on 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 this NPRM. We anticipate 
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, we 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, we 
estimate that approximately 75% of 911 calls come from mobile phones, 
which already are required to convey a dispatchable location. However, 
we believe the remaining 25% of calls to which our proposed rules would 
apply will realize benefits. Because three times as many calls come 
from mobile phones as from non-mobile sources, we estimate that our 
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, we 
expect that our dispatchable location rules will save considerably 
fewer lives. Even if we were to assume our proposed rules would save 
only one twentieth of the lives that we projected would be saved by the 
mobile location rules, the proposed rules would save 506 lives 
annually. We rely 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, we estimate that the 506 lives saved by the 
proposed rules multiplied by the VSL establishes a benefit floor of 
$4.9 billion. We seek comment on whether our estimate is reasonable. 
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, increased confidence in the 911 system and emergency 
responders? How can we assign a dollar figure to evaluate the magnitude 
of these and other benefits? We seek estimates of the time-saving value 
of dispatchable location and data demonstrating the value of a 
reduction in emergency response time.
    93. We observe that 911 location solutions that are capable of 
conveying dispatchable location to PSAPs are already offered by several 
MLTS market participants. Further, several states already place 
requirements on MLTS providers to obtain and convey location 
information that is more detailed than street address alone, and we 
therefore conclude that MLTS manufacturers are

[[Page 54193]]

producing and widely selling equipment that is capable of complying 
with our proposed rules. Are there any cases in which currently-
available equipment will not be suitable? In addition, 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, we believe 
that the implementation costs of our proposed dispatchable location 
rules to these entities would be negligible in most respects. We also 
believe that our approach of granting flexibility in satisfying our 
proposed rules minimizes the potential cost of compliance. We seek 
comment on these observations and tentative conclusions.
    94. We tentatively find that three aspects of our proposed rules 
may lead to additional implementation costs: (1) Implementation of the 
proposed dispatchable location requirement by MLTS managers; (2) 
implementation of the proposed requirement for interconnected VoIP, 
VRS, and IP Relay providers to identify when a customer uses the 
service from a new location and update the customer's location 
information; and (3) the proposed requirement for outbound-only VoIP 
service providers or other 911 VoIP service providers to comply with 
the Part 9 rules. First, we seek comment on any additional costs that 
our proposed rules may impose on MLTS managers. In comments responsive 
to the ECS NOI, for example, RedSky stated that it can provision its 
E911 system service for as little as a $2,500.00 one-time service 
installation fee and $100 per month. The service gives the ECS access 
to over 5,500 PSAPs in the U.S. and all regional ALI (Automatic 
Location Information) databases, as well as providing 911 call 
notifications to enterprise security personnel. West Safety stated that 
the 2010 MLTS workshop report of the California PUC concluded that 
third-party ECS 911 solutions ``are going down in cost and are 
available for under $5,000'' with ``[s]mall business solutions as low 
as $1,250 for a one-time implementation fee and $65 to $100 per month 
in recurring fees.'' However, because our proposed dispatchable 
location rules would only apply to those MLTS managers that install 
MLTS after February 16, 2020, at which time all MLTS must be 
dispatchable location-capable, we tentatively find that the only costs 
for which our rules would be responsible are marginal differences in 
MLTS price that are attributable to manufacturer efforts to comply with 
the rules. Because many MLTS manufacturers are producing and widely 
selling equipment that is capable of complying with our proposed rules, 
we anticipate that price increases will be minimal.
    95. We seek comment on how our rules may affect the price of MLTS, 
especially recurring costs. We anticipate that the most significant 
costs would be for initial and recurring costs of provisioning location 
information to MLTS operators, but tentatively find that the cost of 
such provisioning will be significantly less than the benefits that 
arise from adopting the rule. Nearly 80% of businesses in the United 
States have fewer than ten employees. While we acknowledge that 
enterprises with few employees do not always have those employees work 
in close proximity to one another, we anticipate that a street address 
would likely satisfy the definition of dispatchable location for most 
of those businesses and would be available to the MLTS operator at no 
cost to the MLTS manager.
    96. We expect larger companies to face some initial location 
provisioning costs. Because many MLTS manufacturers are producing and 
widely selling equipment that is capable of complying with our proposed 
rules, we tentatively find that the primary cost to MLTS managers is 
the cost of provisioning the location information in the MLTS. To 
estimate the cost to these enterprises, we seek to estimate the number 
of employees at the affected enterprises, determine the number of lines 
and the amount of time needed annually to provision dispatchable 
location for those lines, and finally determine the total cost for 
workers paid at an hourly wage to complete the task. We tentatively 
estimate the number of affected telephone lines in larger (>10) 
enterprises from Small Business Administration data, which indicates 
that there are approximately 109 million employees at larger firms. We 
initially estimate there are 1.1 employees per installed line, 
resulting in approximately 99.1 million lines. At an incremental effort 
of 1 minute per line and a $30 per hour labor rate, this results in a 
maximum one-time cost of approximately $49.6 million. Significantly, 
this cost assumes firms will need to create an employee phonebook 
database that duplicates that used in general enterprise systems, such 
as Microsoft Outlook. We expect that such duplication will be 
unnecessary for many enterprises. We also expect that within a few 
years, this setup cost will become minimal because manufacturers of 
MLTS and general enterprise systems will increasingly connect their 
systems, setting up a single phonebook database and making duplication 
unnecessary. We seek comment on our proposed methodology and estimates, 
including on the existing and future availability to connect general 
enterprise systems to MLTS.
    97. Larger businesses that use MLTS are likely to initially face 
recurring costs to maintain a separate location database. To estimate 
the cost to these enterprises, we seek to estimate the number of lines 
at the affected enterprises, determine the number of provisioning 
changes and the amount of time needed annually to make those changes 
for those lines, and finally determine the total cost for workers paid 
at an hourly wage to complete the task. We tentatively estimate that 
entering the dispatchable address for a move, add, or change to an MLTS 
endpoint will take 1 minute of a manager's time. An industry rule-of-
thumb is that 5% of endpoints will require a change of provisioning 
(moves, adds, or changes) in a year. With 99.1 million total 
incremental lines subject to this rule, 5% of this figure is 
approximately 5 million changes per year. At 1 minute per modification 
and $30 per hour labor rate, this results in a maximum annual cost of 
$2.5 million to keep the location databases up to date. As noted above, 
we expect this incremental cost will become minimal over time as 
manufacturers of MLTS and general enterprise systems start connecting 
their systems. At that point, enterprise information technology staff 
will only need to provision a single line when an employee moves. In 
addition, as noted above, several states already place requirements on 
MLTS providers to obtain and convey location information that is more 
detailed than street address alone. For those states, the incremental 
cost of our rules is potentially zero. We seek comment on these 
estimates, including on the existing and future availability to connect 
general enterprise systems to MLTS.
    98. RedSky discusses the costs for providing E911 for both legacy 
and IP-based ECS, stating that ``IP-based systems have a cost advantage 
over legacy systems because of their ability to use [Emergency Response 
Location] ERLs and [Emergency Location Information Numbers] ELINs and 
segment their networks into logical subnets or zones.'' We seek comment 
on whether our proposed rules will hasten the ongoing transition to IP-
based

[[Page 54194]]

MLTS, and whether this transition will reduce the costs to MLTS 
managers over time, including the costs of provisioning location 
information to MLTS operators. If so, by how much? We seek additional 
cost data relative to provisioning dispatchable location from MLTS and 
other communications services identified in this NPRM.
    99. Second, we seek comment on the costs of implementing our 
proposed requirement that interconnected VoIP, VRS, and IP Relay 
services identify when a customer uses the service from a new location 
and update the customer's location information. To estimate the cost to 
these service providers, we seek to estimate the amount of time 
required to develop and test the necessary software number and 
determine the total cost for workers paid at hourly wages to complete 
the task. We tentatively estimate a maximum initial cost of $8,280,000 
industry-wide. We tentatively assume that eight months will be a 
sufficient time period for developing and testing and deploying the 
software modifications required for updating customer location 
information, as this would enable service providers to begin to comply 
with our proposed rules after their final adoption and finish before 
the February 16, 2020 compliance date. We estimate that six of the 
eight months will be devoted to software development and deployment, 
and two of the eight months will be devoted to testing and debugging. 
We estimate that the maximum cost of developing any software update 
necessary to comply with the rules we propose today for each 
interconnected VoIP-related entity, VRS provider, and IP Relay provider 
would be $92,000, the cost of compensating one full-time software 
engineer for six months of labor. We estimate that the cost of testing 
these modifications (including integration testing, unit testing, and 
failure testing), which requires as many as 12 software engineers 
working for two months, will be $368,000 for each interconnected VoIP-
related entity, VRS provider, and IP Relay provider. Thus, we estimate 
that the total cost of software modifications for each interconnected 
VoIP-related entity, VRS provider, and IP Relay provider will be 
$460,000. We estimate that this requirement will be implemented by 12 
interconnected VoIP-related entities and 6 VRS providers and IP Relay 
providers. Therefore, the total cost to the industry will be $8,280,000 
(18 organizations times $460,000 per organization).
    100. We further observe that some VoIP-based MLTS will not need to 
implement this functionality, as they are already capable of obtaining 
the customer's dispatchable location at the time a 911 call is 
initiated without requiring additional customer action. We seek comment 
on the extent to which interconnected VoIP, VRS, and IP Relay services 
already are able to identify when a customer uses the service from a 
new location and update the customer's location information. We seek 
comment on all of the assumptions upon which these cost estimates are 
based and on any recurring costs that interconnected VoIP, VRS, and IP 
Relay and service providers would incur in complying with our proposed 
rules.
    101. Third, we seek comment on the prospective costs to outbound-
only VoIP service providers or other 911 VoIP service providers for 
complying with the proposed Part 9 rules, including the proposed 
dispatchable location rules. We specifically seek comment on how the 
costs of compliance for these providers may differ from the costs to 
interconnected VoIP providers that the rules already cover, including 
increased costs that arise from unique technical obstacles and 
decreased costs that arise from technical solutions for complying with 
our rules being well-established and widely available.
    102. We seek comment on any additional costs and benefits that 
arise from our proposed rules that we have not considered. For example, 
how would dispatchable location requirements for MLTS and other 
communications services affect PSAPs? How would such requirements 
affect customers of those services?

C. Consolidating the Commission's 911 Rules

    103. Historically, the Commission has taken a service-by-service 
approach to establishing 911 obligations. As a result, our 911 rules 
are today scattered throughout different parts of Title 47. For 
example, our interconnected VoIP 911 rules are in Part 9, our 911 
reliability rules are in Part 12, our mobile E911 rules are in Part 20, 
our emergency call center requirements for Mobile-Satellite Service 
(MSS) are in Part 25, and our telecommunications carrier obligations 
and emergency calling requirements for TRS providers are in Part 64. We 
believe that this siloed approach to the organization of our 911 rules 
does not adequately reflect that all of the individual services that 
enable 911 calls are functional parts of a single system. Moreover, we 
expect that the 911 system will become increasingly integrated as 
technology evolves and stakeholders migrate from legacy 911 to NG911.
    104. Our initiation of this proceeding to develop 911 rules for 
MLTS and dispatchable location requirements for all 911-capable 
platforms provides us with a unique opportunity to simplify and 
streamline our 911 rules in the process. Therefore, in addition to 
proposing adoption of MLTS and dispatchable location rules as discussed 
above, we propose to consolidate all of our existing 911 rules in a 
single rule part, i.e., Part 9, to the extent practicable. We also 
propose to simplify and streamline the rules in some instances and to 
eliminate corresponding duplicative rules in other rule parts. We 
believe the proposed 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.
    105. As noted in Appendix A and described for reference in a chart 
in Appendix C of the NPRM, we propose to designate Part 9, which 
currently contains our interconnected VoIP 911 rules, as the rule part 
that would contain the consolidated 911 rules, and we propose to 
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 propose to consolidate our 911 rules as follows:
     Move relevant definitions for all services to Subpart A of 
Part 9;
     Move telecommunications carrier obligations (Sections 
64.3001 et seq.) to Subpart B of Part 9;
     Move CMRS obligations (Section 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 
(Sections 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 
(Section 25.284) to Subpart G of Part 9; and
     Move 911 resiliency, redundancy, and reliability 
requirements (Part 12) to Subpart H of Part 9.
    106. Aside from the proposed MLTS and dispatchable location rules 
discussed in preceding sections, our proposed rule revisions would 
mainly entail consolidating our existing 911 rules without making 
substantive changes, but there are some exceptions. Specifically, 
consolidating the rules will

[[Page 54195]]

entail making certain conforming and technical changes. For example, in 
instances where there are minor differences in the definitions of 
common 911-related terms in different rule parts, we propose to 
harmonize these definitions for purposes of providing a uniform 
definition in Part 9. In addition, we propose to remove a few obsolete 
911 rules, e.g., rules referencing one-time information collections 
that have been completed, rather than recodify them in Part 9. We also 
seek comment on whether we should move Section 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. Further, we propose to 
update cross-references in other rule parts as needed, and to correct 
erroneous internal cross-references that appear in our existing rules.
    107. We explain these proposed changes in greater detail in 
Appendix C of the NPRM, which contains conversion tables that track the 
proposed disposition of each rule in the consolidation process. We have 
prepared a separate table for each current rule part that would be 
affected by the proposed rule consolidation. The table identifies the 
existing rule section, the section in Part 9 where it would be located 
after the consolidation, and whether the rule would also be removed 
from its current location. In addition, to help interested parties 
quickly identify the source of each rule in proposed Part 9, Appendix C 
of the NPRM also contains a conversion table that lists the proposed 
Part 9 rules in numerical order and lists the current rule or rules 
from which each proposed new rule is derived.
    108. We do not include some 911-related rules in our consolidation 
proposal, where such rules either do not relate to core 911 obligations 
or 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. For example, Part 4 of our rules 
contains rules relating to network outage reporting, including some 
rules that specifically address outages affecting 911 facilities. 
Because the Part 4 rules constitute an integrated whole, we do not 
propose to transfer or consolidate the 911-specific rules currently 
contained in Part 4.
    109. Finally, we invite commenters to identify any additional rules 
that they recommend for consolidation in Part 9, as well as any rules 
that should be updated in light of our proposal.

IV. Procedural Matters

    110. Ex Parte Presentations. The proceeding shall be treated as a 
``permit-but-disclose'' proceeding in accordance with the Commission's 
ex parte rules. Persons making ex parte presentations must file a copy 
of any written presentation or a memorandum summarizing any oral 
presentation within two business days after the presentation (unless a 
different deadline applicable to the Sunshine period applies). Persons 
making oral ex parte presentations are reminded that memoranda 
summarizing the presentation must (1) list all persons attending or 
otherwise participating in the meeting at which the ex parte 
presentation was made, and (2) summarize all data presented and 
arguments made during the presentation. If the presentation consisted 
in whole or in part of the presentation of data or arguments already 
reflected in the presenter's written comments, memoranda or other 
filings in the proceeding, the presenter may provide citations to such 
data or arguments in his or her prior comments, memoranda, or other 
filings (specifying the relevant page and/or paragraph numbers where 
such data or arguments can be found) in lieu of summarizing them in the 
memorandum. Documents shown or given to Commission staff during ex 
parte meetings are deemed to be written ex parte presentations and must 
be filed consistent with rule 1.1206(b). In proceedings governed by 
rule 1.49(f) or for which the Commission has made available a method of 
electronic filing, written ex parte presentations and memoranda 
summarizing oral ex parte presentations, and all attachments thereto, 
must be filed through the electronic comment filing system available 
for that proceeding, and must be filed in their native format (e.g., 
.doc, .xml, .ppt, searchable .pdf). Participants in this proceeding 
should familiarize themselves with the Commission's ex parte rules.
    111. Comment Filing Procedures. Pursuant to Sec. Sec.  1.415 and 
1.419 of the Commission's rules, 47 CFR 1.415, 1.419, interested 
parties may file comments and reply comments on or before the dates 
indicated on the first page of this document. Comments and reply 
comments may be filed using the Commission's Electronic Comment Filing 
System (ECFS). See Electronic Filing of Documents in Rulemaking 
Proceedings, 63 FR 24121 (1998).
     Electronic Filers: Comments may be filed electronically 
using the internet by accessing the ECFS: https://apps.fcc.gov/ecfs/.
     Paper Filers: Parties who choose to file by paper must 
file an original and one copy of each filing. If more than one docket 
or rulemaking number appears in the caption of this proceeding, filers 
must submit two additional copies for each additional docket or 
rulemaking number.
    Filings can be sent by hand or messenger delivery, by commercial 
overnight courier, or by first-class or overnight U.S. Postal Service 
mail. All filings must be addressed to the Commission's Secretary, 
Office of the Secretary, Federal Communications Commission.
     All hand-delivered or messenger-delivered paper filings 
for the Commission's Secretary must be delivered to FCC Headquarters at 
445 12th St. SW, Room TW-A325, Washington, DC 20554. The filing hours 
are 8:00 a.m. to 7:00 p.m. All hand deliveries must be held together 
with rubber bands or fasteners. Any envelopes and boxes must be 
disposed of before entering the building.
     Commercial overnight mail (other than U.S. Postal Service 
Express Mail and Priority Mail) must be sent to 9050 Junction Drive, 
Annapolis Junction, MD 20701.
     U.S. Postal Service first-class, Express, and Priority 
mail must be addressed to 445 12th Street SW, Washington DC 20554.
    112. People with Disabilities: 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).
    113. Regulatory Flexibility Analysis. As required by the Regulatory 
Flexibility Act of 1980, see 5 U.S.C. 603, the Commission has prepared 
an Initial Regulatory Flexibility Analysis (IRFA) of the possible 
significant economic impact on small entities of the policies and rules 
addressed in this document. The IRFA is set forth in Appendix B of the 
NPRM. Written public comments are requested on the IRFA. These comments 
must be filed in accordance with the same filing deadlines as comments 
filed in response to this NPRM as set forth herein, and they should 
have a separate and distinct heading designating them as responses to 
the IRFA. The Commission's Consumer and Governmental Affairs Bureau, 
Reference Information Center, will send a copy of the NPRM, including 
this IRFA, to the Chief Counsel for Advocacy of the Small Business 
Administration (SBA).

[[Page 54196]]

    114. Initial Paperwork Reduction Act Analysis. This NPRM may 
contain proposed new and modified information collection requirements. 
The Commission, as part of its continuing effort to reduce paperwork 
burdens, invites the general public and the Office of Management and 
Budget (OMB) to comment on the information collection requirements 
contained in this document, as required by the Paperwork Reduction Act 
of 1995 (PRA). In addition, pursuant to the Small Business Paperwork 
Relief Act of 2002, Public Law 107-198, see 44 U.S.C. 3506(c)(4), we 
seek specific comment on how we might ``further reduce the information 
collection burden for small business concerns with fewer than 25 
employees.''

V. Initial Regulatory Flexibility Act

    115. As required by the Regulatory Flexibility Act of 1980, as 
amended (RFA), the Commission has prepared this Initial Regulatory 
Flexibility Analysis (IRFA) of the possible significant economic impact 
on a substantial number of small entities by the policies and rules 
proposed in the NPRM. Written public comments are requested on this 
IRFA. Comments must be identified as responses to the IRFA and must be 
filed by the deadlines for comments provided in paragraph 113 of the 
NPRM. The Commission will send a copy of the NPRM, including this IRFA, 
to the Chief Counsel for Advocacy of the Small Business Administration 
(SBA). In addition, the NPRM and IRFA (or summaries thereof) will be 
published in the Federal Register.

A. Need for, and Objectives of, the Proposed Rules

    116. In this proceeding, the Commission takes steps to advance 
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. The President recently signed into law two statutes 
directed to the improvement of 911: (1) Kari's Law Act of 2017 (Kari's 
Law), which requires implementation of direct 911 dialing and on-site 
notification capabilities in multi-line telephone systems (MLTS), and 
(2) Section 506 of RAY BAUM'S Act (RAY BAUM'S Act), which requires the 
Commission, within 18 months after March 23, 2018, the date of the 
legislation's enactment, 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].''
    117. The NPRM proposes to implement Kari's Law by adopting direct 
dial and on-site notification rules governing calls to 911 made from 
MLTS. As required by RAY BAUM'S Act, the Commission also considers the 
feasibility of requiring dispatchable location for 911 calls from MLTS 
and other technological platforms that currently complete calls to 911. 
The NPRM proposes establishing a dispatchable location requirement for 
MLTS 911 calls, which would apply contemporaneously with the February 
16, 2020 compliance date of Kari's Law. Additionally, in keeping with 
the directive in RAY BAUM'S Act to address dispatchable location for 
911 calls ``regardless of the technological platform used,'' the NPRM 
proposes to add dispatchable location requirements to the Commission's 
existing 911 rules for fixed telephony providers, interconnected Voice 
over internet Protocol (VoIP) providers, and Telecommunications Relay 
Services (TRS). The NPRM also considers 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 NPRM 
considers whether dispatchable location rules should be extended to 
other communications services that are not covered by existing 911 
rules but are capable of making a 911 call.
    118. Finally, the NPRM proposes to take this opportunity to 
consolidate the Commission's existing 911 rules, as well as the direct 
dialing and dispatchable location rules proposed in this 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. We believe that consolidating our 911 rules from these 
various rule sections into a single rule part will further the goal of 
recognizing that all the components of 911 function as part of a single 
system and will enable 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. Legal Basis

    119. The proposed action is authorized under 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.

C. Description and Estimate of the Number of Small Entities To Which 
the Proposed Rules Will Apply

    120. 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 proposed rules, if adopted. 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 which: (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.
    121. 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.

[[Page 54197]]

    122. 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.
    123. 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 IRFA, we group entities operating, 
installing, and managing MLTS in the Small Business, Small Organization 
and Small Government Jurisdiction description contained in paragraph 15 
infra.
    124. 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 42 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.
    125. 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 
this size standard the majority of firms in this industry can be 
considered small.
    126. 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.
    127. 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-1000 or 
more employees. Thus, the Commission estimates that the majority of 
Information Technology Value Added Resellers in this industry can be 
considered small.
    128. 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.
    129. 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.
    130. Next, the type of small entity described as a ``small 
organization'' is generally ``any not-for-profit enterprise

[[Page 54198]]

which is independently owned and operated and is not dominant in its 
field.'' Nationwide, as of Aug 2016, there were approximately 356,494 
small organizations based on registration and tax data filed by 
nonprofits with the Internal Revenue Service (IRS).
    131. 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 indicates 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 shows that the majority of these governments 
have populations of less than 50,000. Based on this data we estimate 
that at least 49,316 local government jurisdictions fall in the 
category of ``small governmental jurisdictions.''
    132. 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.
    133. 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, 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.
    134. 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 data, 3,117 
firms operated the 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.
    135. 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 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 this 
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 that may be affected by the adopted rules.
    136. 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 that may be affected are 
small entities.
    137. 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.

[[Page 54199]]

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.
    138. 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 1,000 
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.
    139. 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. Thus, 
using available data, we estimate that the majority of wireless firms 
can be considered small.
    140. 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.
    141. 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), and the appropriate 
size standard for this category under the 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 
fewer than 1,000 employees and 12 firms has 1,000 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.

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

    142. The NPRM proposes rules and seeks comment on rule changes that 
will affect the reporting, recordkeeping and/or other compliance 
requirements of small businesses and entities of all sizes that are 
engaged in the business of manufacturing, importing, selling, 
installing, managing or operating MLTS that are manufactured, imported, 
offered for first sale or lease, first sold or leased, or installed 
after February 16, 2020. The NPRM also proposes rules that will affect 
small businesses and entities of all sizes that are engaged in the 
business of offering fixed telephony service, wireless 
telecommunications, interconnected VoIP service, and TRS. The proposed 
changes are being implemented as a result of Congressional mandates in 
Kari's Law and RAY BAUM'S Act that require the Commission to 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. The specific proposals 
in the NPRM are described below.
1. Direct Dialing and Notification for MLTS
    143. To implement and enforce Kari's Law, the NPRM proposes rules 
that interpret the law's direct dialing and notification requirements 
for MLTS. First, the NPRM proposes that 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 the 
rules, 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.
    144. Second, the NPRM proposes that 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. The NPRM also seeks comment on 
whether any additional elements should be included in the proposed 
regulations to facilitate compliance and enforcement.
    145. Third, the NPRM proposes that 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 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. The NPRM also 
proposes to require that notification at a minimum (1) the fact that a 
911 call has been made, (2) a valid

[[Page 54200]]

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. The notification must be contemporaneous with the 911 
call and must not delay the placement of the call to 911. The NPRM also 
seeks comment on whether to require that a person be available on-site 
or off-site to receive the notification. The NPRM asks whether small 
businesses should be exempt from certain aspects of the notification 
requirement.
    146. Fourth, Kari's Law applies only with respect to MLTS that are 
manufactured, imported, offered for first sale or lease, first sold or 
leased, or installed after February 16, 2020. Accordingly, the NPRM 
notes that MLTS manufactured, imported, offered for first sale or 
lease, first sold or leased, or installed on or before that date are 
grandfathered from compliance with the statute, and it seeks comment on 
whether the Commission should adopt transitional rules to inform 
consumers of the 911 capabilities of grandfathered MLTS.
    147. The NPRM also proposes and seeks comment on definitions for 
the following terms contained in the proposed regulations: (1) Multi-
line telephone system, (2) Pre-configured and configured, (3) 
Improvement to the hardware or software of the system, (4) A person 
engaged in the business of managing an MLTS, (5) A person engaged in 
the business of operating an MLTS, and (6) A person engaged in the 
business of installing an MLTS, (7) notification, and (8) MLTS 
notification. The proposed definitions are described below.
    148. Multi-line telephone system. The NPRM proposes to define MLTS 
consistent with Kari's Law and RAY BAUM'S Act which define 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.'' The NPRM proposes 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. We further interpret this 
definition to include systems that allow outbound calls to 911 without 
providing a way for the PSAP to place a return call.
    149. Pre-configured and configured. The NPRM proposes to define 
``pre-configured'' to mean that the MLTS is 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. However, if the system is configured with these 
additional dialing patterns, they must be in addition to the default 
direct dialing pattern. The NPRM proposes to include similar clarifying 
language in the definition of ``pre-configure.'' The NPRM also proposes 
to define ``configured'' to mean that the MLTS must be fully capable 
when installed of dialing 911 directly and providing notification as 
required under the statute and rules.
    150. Improvement to the hardware or software of the system. Kari's 
Law provides that the notification requirements of the statute apply 
only if the system can be configured to provide notification without an 
improvement to the hardware or software of the system. The NPRM 
proposes to define the term ``improvement to the hardware or software 
of the system'' to include upgrades to the core systems of an MLTS, as 
well as substantial upgrades to the software and any software upgrades 
requiring a significant purchase.
    151. A person engaged in the business of managing an MLTS. The NPRM 
proposes 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.
    152. A person engaged in the business of operating an MLTS. The 
NPRM proposes to define a person engaged in the business of operating 
an MLTS as an entity responsible for the day-to-day operations of the 
MLTS. The NPRM's proposed definition would specify that the MLTS 
operator may be the MLTS manager, or it may be a third-party acting on 
behalf of the manager. For example, an MLTS owner may contract with a 
third party to provide a total solution for MLTS, including acquiring 
the MLTS equipment, configuring the system, and providing services such 
as training, technical support, maintenance, and end user support.
    153. A person engaged in the business of installing an MLTS. The 
NPRM proposes to define a person engaged in the business of installing 
an MLTS as a person who installs or 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 
PSTN, and determining where the MLTS will interface with the PSTN. The 
MLTS installer may be the MLTS manager or a third-party acting on 
behalf of the manager.
    154. MLTS Notification. The NPRM proposes to 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 screen pops with audible alarms for security desk computers 
using a client application, text messages for smartphones, and email 
for administrators.
    155. The NPRM observes that according to a Congressional Budget 
Office analysis, most MLTS systems already are configured to meet the 
direct dialing 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 addition, eight states and one local government already 
have laws that require direct dialing for 911 from MLTS. The NPRM also 
tentatively finds that there should be no immediate costs or stranded 
investment with respect to existing MLTS or systems that first come 
into service on or before February 16, 2020. Therefore, the Commission 
tentatively concludes that there will be no immediate costs or benefits 
associated with meeting the requirements of its rules. For systems 
coming into service after February 16, 2020, the NPRM seeks comment on 
the costs and benefits of satisfying its proposed rules. The NPRM also 
seeks comment on the expected lifespan of existing MLTS that are not 
currently able to meet the requirements of our proposed rules and the 
costs of upgrading to an MLTS that meets the requirements. The 
Commission seeks comment on its tentative conclusion that its rules 
will impose no incremental costs to those who replace their MLTS as 
they come to the end of their useful life.

[[Page 54201]]

2. Dispatchable Location for Other 911-Capable Communications Services
    156. To facilitate the provisioning of dispatchable location by 
other communications services as contemplated by RAY BAUM'S Act, the 
NPRM generally proposes to amend existing location requirements with 
dispatchable location requirements. In addition to MLTS, the NPRM 
examines four types of communications services that are currently 
required under Commission rules to provide 911 service to their 
customers: (1) Fixed telephony, (2) mobile telecommunications, (3) 
interconnected VoIP service, and (4) Telecommunications Relay Services 
(TRS). In addition, we examine whether we should adopt dispatchable 
location rules for other 911-capable services that are not currently 
subject to 911 rules.
    157. The NPRM proposes to proscribe the manufacture, import, sale, 
or leasing of MLTS unless the system is pre-configured such that, when 
properly installed, the dispatchable location of the caller is conveyed 
to the PSAP with 911 calls. Further, the NPRM proposes 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 is conveyed to the PSAP with 911 calls. The NPRM does not 
propose specific location technologies or solutions but, rather, seeks 
comment on implementing general dispatchable location requirements that 
would give participants in the MLTS marketplace flexibility. This 
approach will allow the entities affected by the proposed rules to 
implement them in a manner that is appropriate for them in terms of 
cost, enterprise size, site layout, and technical sophistication. The 
NPRM seeks comment on whether the dispatchable location requirement for 
MLTS should apply to the same entities subject to the MLTS direct 
dialing and notification requirements. Finally, the NPRM seeks comment 
on the technical feasibility of 911 calls that originate from MLTS to 
convey dispatchable location to the appropriate PSAP as well as 
alternatives for conveying dispatchable location such as the use of x/
y/z coordinates to be conveyed with 911 calls originating from MLTS. 
The NPRM also seeks comment on alternative compliance timeframes for 
dispatchable location requirements for MLTS.
    158. The NPRM proposes to define ``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.'' Given the 
substantial similarity between the statutory definition and the 
definition of dispatchable location in the FCC's wireless E911 rules, 
the NPRM proposes to construe them as functionally identical, aside 
from the specification of the technological platform to which each 
definition applies. The NPRM also seeks comment on whether to require 
validation for dispatchable location information associated with MLTS 
911 calls. The NPRM also seeks comment on whether to define 
``additional information'' that may be necessary in an MLTS context to 
``adequately identify the location of the calling party.'' The NPRM 
also seeks comment on whether the National Emergency Address Database 
(NEAD), the location database being developed by the major mobile 
carriers to provide dispatchable location for indoor mobile 911 calls, 
could potentially assist MLTS managers and operators in determining the 
dispatchable location of MLTS end users
    159. The NPRM proposes to amend the rules to require fixed 
telephony providers to provide dispatchable location with 911 calls. 
Although fixed telephony providers already provide validated street 
address information, dispatchable location includes additional elements 
such as floor level and room number that may be necessary to locate the 
caller. The NPRM also seeks comment on whether the NEAD or similar 
database could assist fixed telephony carriers in providing 
dispatchable location with 911 calls. The NPRM seeks comment on whether 
there any alternatives to dispatchable location that fixed telephony 
could use to provide in-building location information beyond street 
addresses, e.g., coordinate-based information.
    160. The NPRM proposes to amend the Commission's rules to require 
interconnected VoIP providers to develop the means to provide updated 
dispatchable location with 911 calls in lieu of conveying the 
customer's Registered Location. Regarding Fixed VoIP, the NPRM observes 
that it is feasible for 911 calls that originate from interconnected 
VoIP services to convey dispatchable location to the PSAP. In a Nomadic 
VoIP context, the NPRM seeks comment on whether Registered Location 
represents sufficient proxy for dispatchable location in a nomadic 
environment, where the relevant device is able to prompt the user for 
an updated location when it has been moved. The NPRM also seeks to 
encourage having interconnected VoIP devices and/or networks support 
the automatic provision of real-time dispatchable location without 
requiring a manual location update by the end user.
    161. The NPRM proposes to amend the Commission's rules to require 
TRS providers to develop the means to provide updated dispatchable 
location, paralleling the rules the NPRM proposes for interconnected 
VoIP service. The NPRM seeks comment on the feasibility of using 
existing Registered Location mechanisms to provide dispatchable 
location for fixed and nomadic TRS users. The NPRM also seeks comment 
on the feasibility of having TRS devices and/or networks support the 
dynamic provision of real-time dispatchable location without requiring 
registration or manual location updates by the end user.
    162. The NPRM seeks comment on whether providing dispatchable 
location for 911 calls from MLTS and other communications services 
would improve emergency response and the health and safety of the 
public, and whether this benefit would exceed the cost of providing it. 
The NPRM seeks comment on 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 this NPRM. The NPRM 
anticipates 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.
    163. The NPRM tentatively concludes that the benefits of adopting 
proposed dispatchable location rules for MLTS, fixed telephony 
providers, interconnected VoIP service providers, and TRS providers 
will outweigh the costs. The NPRM observes that 911 location solutions 
that are capable of conveying dispatchable location to PSAPs are 
already offered by several MLTS market participants. Further, several 
states already place requirements on MLTS providers to obtain and 
convey location information that is more detailed than street address 
alone, and we therefore conclude that MLTS manufacturers are producing 
and widely selling equipment that are capable of complying with our 
proposed rules. In addition, we observe that interconnected VoIP 
service providers and internet-based TRS providers today obtain 
customers' Registered Location, which would satisfy our proposed 
dispatchable location requirements. Because these dispatchable 
location-

[[Page 54202]]

capable solutions and equipment are already widely available, the 
implementation costs of our proposed dispatchable rules to MLTS 
manufacturers, installers, and operators would be negligible in most 
respects. The NPRM also proposes to provide flexibility in how to 
satisfy the proposed dispatchable location requirements and should 
minimize the potential cost of compliance.
    164. The NPRM identifies several aspects of the proposed rules that 
may lead to additional implementation costs. To assist the Commission 
in identifying and quantifying the additional costs that may impact 
small as well large entities, the Commission requests cost information 
from the parties. First, the NPRM seeks comment on any additional costs 
that our proposed rules may impose on MLTS managers. Second, the NPRM 
seeks comment on the costs of implementing our proposed requirement 
that interconnected VoIP and TRS services identify when a customer uses 
the service from a new location and update the customer's location 
information. Third, the NPRM seeks comment on the costs to outbound-
only VoIP service providers of complying with the Part 9 rules, 
including the proposed dispatchable location rules. Finally, the NPRM 
seeks comment on any additional costs that arise from our proposed 
rules that we have not considered.

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

    165. The RFA requires an agency to describe any significant 
alternatives that it has considered in reaching its proposed 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.
    166. To assist the Commission's evaluation of the economic impact 
on small entities as a result of actions that have been proposed in 
this NPRM and to better explore options and alternatives, the 
Commission seeks comment from the parties. With respect to direct 
dialing and notification under Kari's Law, the NPRM seeks comment on 
alternatives to reduce the burden and minimize the costs of compliance 
on small entities. The NPRM observes that notification can be 
particularly important in large buildings such as hotels, hospitals, 
and schools, where on-site personnel are uniquely suited to provide 
information about the building and its occupants. The NPRM asks whether 
commenters agree that notification is more important for larger 
enterprises and, if so, whether small businesses should be exempt from 
certain aspects of the notification requirement, such as a requirement 
to staff the notification point. The NPRM also seeks comment on what 
entities should fall within an exception for small businesses. The NPRM 
asks whether the criterion should be the size of the business or the 
number of stations in the MLTS. In addition, the NPRM asks whether 
instead of specifying the content of the notification, the Commission 
should allow enterprises the flexibility to customize it as they see 
fit.
    167. Regarding dispatchable location, the NPRM asks whether some 
MLTS in use today are not capable of supporting dispatchable location 
and whether such systems should be exempted from a dispatchable 
location requirement. The NPRM invites commenters to offer alternatives 
to reduce the cost burdens on MLTS entities and other communications 
services, including whether to allow the entity to pick the location 
methodology that works best. As mentioned above, giving participants in 
the MLTS marketplace the flexibility to choose how to implement the 
proposed rules will mitigate their cost of compliance. The NPRM also 
asks what steps an MLTS manager must take, if any, to ensure that 
dispatchable location is conveyed to the PSAP, what are the most 
effective, least burdensome means to ensure that these steps are taken.
    168. The NPRM asks whether there are situations in which 
communications service providers should be exempted from a dispatchable 
location requirement. In addition, the NPRM asks whether there are any 
MLTS or other communications services (e.g., very small facilities) 
that would not benefit from conveying dispatchable location, or for 
whom the benefit would not exceed the cost. The NPRM also asks whether 
any communications services that are exempted from dispatchable 
location requirements should be required to provide consumer disclosure 
regarding the limitations of their 911 location capabilities. In 
addition, the NPRM asks whether dispatchable location requirements for 
different service types should become effective in phases to require 
greater accuracy over time or to provide additional time to small 
businesses to come into compliance.
    169. The NPRM also proposes to consolidate all of the existing 911 
rules into a single rule part, i.e., Part 9, to the extent practicable. 
As part of this consolidation, the Commission proposes to simplify and 
streamline the rules in some instances and to eliminate corresponding 
duplicative rules in other rule parts. In addition, the NPRM invites 
commenters to identify additional 911 service rules that should be 
consolidated under Part 9. We believe the proposed rule consolidation 
will help to minimize the burden on small entities subject to the 
Commission's 911 rules because it will simplify and streamline the 
rules, making it easier for small entities to identify and comply with 
all 911 requirements.

F. Federal Rules that May Duplicate, Overlap, or Conflict with the 
Proposed Rules

    170. None.

G. Paperwork Reduction Act

    171. This document may contain proposed new or modified information 
collection requirements. The Commission, as part of its continuing 
effort to reduce paperwork burdens, invites the general public and the 
Office of Management and Budget (OMB) to comment on the information 
collection requirements contained in this document, as required by the 
Paperwork Reduction Act of 1995, Public Law 104-13. In addition, 
pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 
107-198, see 44 U.S.C. 3506(c)(4), we seek specific comment on how we 
might further reduce the information collection burden for small 
business concerns with fewer than 25 employees.''

VI. Conversion Tables

Appendix C

[[Page 54203]]



                           Conversion Table A
------------------------------------------------------------------------
         Proposed 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 to    .................  New provision.
     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
                                                    removed and reserved
                                                    in Part 20.
Subpart D--Interconnected
 Voice over Internet Protocol
 Services and 911 VoIP
 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.
    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 9--Interconnected Voice Over Internet Protocol Services, Proposed
                              Rule Changes
------------------------------------------------------------------------
       Current rule No.              Subject          Proposed changes
------------------------------------------------------------------------
9.1...........................  Purposes.........  Revised.
9.3...........................  Definitions......  Definition of
                                                    ``Registered
                                                    Location'' moved to
                                                    9.3 and revised.
                                                     All other
                                                   definitions remain in
                                                   9.3:
                                                     ANI.
                                                     Appropriate local
                                                   emergency authority.
                                                     Automatic Location
                                                   Information (ALI).
                                                     CMRS.
                                                     Interconnected VoIP
                                                   service.

[[Page 54204]]

 
                                                     PSAP.
                                                     Pseudo Automatic
                                                   Number Identification
                                                   (Pseudo-ANI).
                                                     Statewide default
                                                   answering point.
                                                     Wireline E911
                                                   Network.
9.5...........................  E911 Service.....  Moved to 9.11 and
                                                    revised, except for
                                                    9.5(f), which is a
                                                    one-time information
                                                    collection that has
                                                    been completed.
                                                    Propose to remove
                                                    the obligation in
                                                    9.5(f).
9.7...........................  Access to 911 and  Moved to 9.12 and
                                 E911 service       revised.
                                 capabilities.
------------------------------------------------------------------------


   Part 12--Resiliency, Redundancy and Reliability of Communications,
                          Proposed Rule Changes
------------------------------------------------------------------------
       Current rule No.              Subject          Proposed 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 9.19;
                                 covered 911        corrected internal
                                 service            cross-references.
                                 providers.
12.5..........................  Backup power       Moved to 9.20;
                                 obligations.       corrected internal
                                                    cross-references.
------------------------------------------------------------------------


       Part 20--Commercial Mobile Services, Proposed Rule Changes
------------------------------------------------------------------------
       Current rule No.              Subject          Proposed 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 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 9.3 and
                                                    removed from 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 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 9.3 is revised
                                                   slightly for clarity
                                                   by adding the word
                                                   ``answering'' before
                                                   ``point'').
                                                     Statewide default
                                                   answering point.
                                                     Definitions of the
                                                   following terms added
                                                   to 9.3 (but not
                                                   removed from 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 9.9 (but not
                                                   removed from 20.3).
                                                     Interconnection or
                                                   Interconnected.
                                                     Interconnected
                                                   Service.
20.18.........................  911 Service......  Moved to 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).
------------------------------------------------------------------------


        Part 25--Satellite Communications, Proposed Rule Changes
------------------------------------------------------------------------
       Current rule No.              Subject          Proposed changes
------------------------------------------------------------------------
25.103........................  Definitions......  Definitions of the
                                                    following terms
                                                    added to 9.3 (but
                                                    not removed from
                                                    25.103):
                                                     Earth station.
                                                     Feeder link.
                                                     Fixed-Satellite
                                                   Service (FSS).
                                                     Mobile Earth
                                                   Station.

[[Page 54205]]

 
                                                     Mobile-Satellite
                                                   Service (MSS).
                                                     Space station.
                                                   Definition of the
                                                    following term added
                                                    to 9.3 and removed
                                                    from 25.103:
                                                     Emergency Call
                                                   Center.
25.109........................  Cross-reference..  Added new (e) to
                                                    25.109 stating that
                                                    ``Mobile-Satellite
                                                    Service providers
                                                    must comply with the
                                                    emergency call
                                                    center service
                                                    requirements under
                                                    47 CFR part 9.''
25.284........................  Emergency Call     Moved to 9.18;
                                 Center Service.    section 25.284
                                                    removed and
                                                    reserved.
------------------------------------------------------------------------


 Part 64--Miscellaneous Rules Relating to Common Carriers, Proposed Rule
                                 Changes
------------------------------------------------------------------------
       Current rule No.              Subject          Proposed changes
------------------------------------------------------------------------
64.601........................  Definitions and    64.601(b), which
                                 provisions of      states that ``For
                                 general            purposes of this
                                 applicability.     subpart, all
                                                    regulations and
                                                    requirements
                                                    applicable to common
                                                    carriers shall also
                                                    be applicable to
                                                    providers of
                                                    interconnected VoIP
                                                    service,'' is added
                                                    to 9.13, with
                                                    reference to the
                                                    definition of
                                                    interconnected VoIP
                                                    in 9.3.
                                                   64.601(a), which
                                                    lists several terms
                                                    and defines them by
                                                    cross-referencing
                                                    other rule sections,
                                                    is revised to
                                                    include references
                                                    to definitions in
                                                    9.3.
                                                   Definition of ANI
                                                    added to 9.3 but not
                                                    removed from 64.601.
                                                   Definition of
                                                    Registered Location
                                                    added to 9.3 and
                                                    revised.
                                                   Definition of Real-
                                                    Time Text (RTT) is
                                                    added to 9.3 and
                                                    revised to include
                                                    definition from 67.1
                                                    (rather than cross-
                                                    reference to 67.1).
                                                   Definition of the
                                                    following terms
                                                    added to 9.3 (but
                                                    not removed from
                                                    64.601):
                                                     Common carrier or
                                                   carrier
                                                     Communications
                                                   assistant (CA)
                                                     Internet-based TRS
                                                   (iTRS)
                                                     IP Relay access
                                                   technology
                                                     iTRS access
                                                   technology
                                                     Internet-based TRS
                                                   (iTRS)
                                                     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)
                                                     VRS access
                                                   technology
64.602........................  Jurisdiction.....  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 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
                                                    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 9.14(a);
                                 handling           Section 64.604(a)(4)
                                 requirements for   and (d) revised to
                                 TTY-based TRS      contain cross-
                                 providers.         reference to
                                                    9.14(a).
64.605........................  Emergency calling  Moved to 9.14(b) and
                                 requirements.      (c); section 64.605
                                                    removed and
                                                    reserved.
64.3000.......................  Definitions......  Moved to 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 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 9.3 is revised
                                                   slightly for
                                                   consistency with the
                                                   version from 20.3 and
                                                   for clarity;
                                                   ``facility'' changed
                                                   to ``answering
                                                   point.'').
                                                     Statewide default
                                                   answering point.
64.3001.......................  Obligation to      Moved to 9.4 and
                                 transmit 911       removed from Part 64
                                 calls.             as subpart AA
                                                    (Universal Emergency
                                                    Telephone Number) is
                                                    removed and
                                                    reserved.
64.3002.......................  Transition to 911  Moved to 9.5 and
                                 as the universal   removed from Part 64
                                 emergency          as subpart AA
                                 telephone number.  (Universal Emergency
                                                    Telephone Number) is
                                                    removed and
                                                    reserved.

[[Page 54206]]

 
64.3003.......................  Obligation for     Moved to 9.6 and
                                 providing a        removed from Part 64
                                 permissive         as subpart AA
                                 dialing period.    (Universal Emergency
                                                    Telephone Number) is
                                                    removed and
                                                    reserved.
64.3004.......................  Obligation for     Moved to 9.7 and
                                 providing an       removed from Part 64
                                 intercept          as subpart AA
                                 message.           (Universal Emergency
                                                    Telephone Number) is
                                                    removed and
                                                    reserved.
------------------------------------------------------------------------

VII. Ordering Clauses

    172. 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 
Notice of Proposed Rulemaking is hereby adopted.
    173. It is further ordered that the Commission's Consumer and 
Governmental Affairs Bureau, Reference Information Center, shall send a 
copy of this Notice of Proposed Rulemaking, including the Initial 
Regulatory Flexibility Analysis, to the Chief Counsel for Advocacy of 
the Small Business Administration.

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

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

Federal Communications Commission.
Marlene Dortch,
Secretary, Office of the Secretary.

Proposed Rules

    For the reasons discussed in the preamble, the Federal 
Communications Commission proposes to amend 47 CFR parts 9, 12, 20, 25, 
and 64 as follows:

0
1. Part 9 is revised to read as follows:

PART 9--911 REQUIREMENTS

Sec.
Subpart A--Purpose and Definitions
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 to convey dispatchable location
Subpart C--Commercial Mobile Radio Service
9.9 Definitions
9.10 911 Service Requirements
Subpart D--Interconnected Voice over internet Protocol Services and 911 
VoIP 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
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.


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.
    911 VoIP Service. A 911 VoIP service is a service that:
    (1) Enables real-time, two-way voice communications;
    (2) Requires a broadband connection from the user's location;
    (3) Requires internet protocol-compatible customer premises 
equipment (CPE); and
    (4) Permits users generally to initiate a 911 call.
    Appropriate local emergency authority. An emergency answering point 
that has not been officially designated as a Public Safety Answering 
Point (PSAP), but has the capability of receiving 911 calls and either 
dispatching emergency services personnel or, if necessary, relaying the 
call to another emergency service provider. An appropriate local 
emergency authority may include, but is not limited to, an existing 
local law enforcement authority, such as the police, county sheriff, 
local emergency medical services provider, or fire department.

[[Page 54207]]

    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. CA 
supersedes the term ``TDD operator.''
    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 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 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.
    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.
    IP Relay 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 IP Relay call.
    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. An interconnected Voice over internet 
protocol (VoIP) service is a service that:
    (1) Enables real-time, two-way voice communications;
    (2) Requires a broadband connection from the user's location;
    (3) Requires internet protocol-compatible customer premises 
equipment (CPE); and
    (4) Permits users generally to receive calls that originate on the 
public switched telephone network and 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 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 screen pops with audible alarms for security desk 
computers using a client application, text messages for smartphones, 
and email for administrators. Notification shall

[[Page 54208]]

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.
    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.
    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 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.
    Private Mobile Radio Service. A mobile service that meets neither 
paragraph (1) nor (2) of the definition of commercial mobile radio 
service in this section. A mobile service that does not meet the 
paragraph (1) 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
    (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 or IP Relay provider as described in Sec.  
64.611.
    Registered Location. Before February 16, 2020: 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. On or

[[Page 54209]]

after February 16, 2020: The most recent information obtained by a 
provider of interconnected VoIP service, 911 VoIP service, or 
telecommunications relay services (TRS), as applicable, that identifies 
the dispatchable 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.
    VRS 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 a VRS call.
    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 
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 to convey dispatchable location.

    All telecommunications carriers shall convey the dispatchable 
location of the caller to the PSAP with 911 calls, except for wireless 
carriers, which shall convey the location information required by 
subpart C of this part.

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

[[Page 54210]]

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. A service:
    (1) 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
    (2) 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). 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 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 of this chapter, 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 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 (d)(2) of 
this section, as to calls made using a digital wireless system, as 
of October 1, 1998.

    (e) Phase II enhanced 911 service. Licensees subject to this 
section must provide to the designated Public Safety Answering Point 
Phase II enhanced 911 service, i.e., the location of all 911 calls by 
longitude and latitude in conformance with Phase II accuracy 
requirements (see paragraph (h) of this section).
    (f) Phase-in for network-based location technologies. Licensees 
subject to this section who employ a network-based location technology 
shall provide Phase II 911 enhanced service to at least 50 percent of 
their coverage area or 50 percent of their population beginning October 
1, 2001, or within 6 months of a PSAP request, whichever is later; and 
to 100 percent of their coverage area or 100 percent of their 
population within 18 months of such a request or by October 1, 2002, 
whichever is later.
    (g) Phase-in for handset-based location technologies. Licensees 
subject to this section who employ a handset-based location technology 
may phase in deployment of Phase II enhanced 911 service, subject to 
the following requirements:
    (1) Without respect to any PSAP request for deployment of Phase II 
911 enhanced service, the licensee shall:
    (i) Begin selling and activating location-capable handsets no later 
than October 1, 2001;
    (ii) Ensure that at least 25 percent of all new handsets activated 
are location-capable no later than December 31, 2001;
    (iii) Ensure that at least 50 percent of all new handsets activated 
are location-capable no later than June 30, 2002; and
    (iv) Ensure that 100 percent of all new digital handsets activated 
are location-capable no later than December 31, 2002, and thereafter.
    (v) By December 31, 2005, achieve 95 percent penetration of 
location-capable handsets among its subscribers.
    (vi) Licensees that meet the enhanced 911 compliance obligations 
through GPS-enabled handsets and have commercial agreements with 
resellers will not be required to include the resellers' handset counts 
in their compliance percentages.
    (2) Once a PSAP request is received, the licensee shall, in the 
area served by the PSAP, within six months or by October 1, 2001, 
whichever is later:
    (i) Install any hardware and/or software in the CMRS network and/or 
other fixed infrastructure, as needed, to enable the provision of Phase 
II enhanced 911 service; and
    (ii) Begin delivering Phase II enhanced 911 service to the PSAP.
    (3) For all 911 calls from portable or mobile phones that do not 
contain the hardware and/or software needed to enable the licensee to 
provide Phase II enhanced 911 service, the licensee shall, after a PSAP 
request is received, support, in the area served by the PSAP, Phase I 
location for 911 calls or other available best practice method of 
providing the location of the portable or mobile phone to the PSAP.
    (4) Licensees employing handset-based location technologies shall 
ensure that location-capable portable or mobile phones shall conform to 
industry interoperability standards designed to enable the location of 
such phones by multiple licensees.
    (h) Phase II accuracy. Licensees subject to this section shall 
comply with the following standards for Phase II location accuracy and 
reliability, to be tested and measured either at the county or at the 
PSAP service area geographic level, based on outdoor measurements only:

[[Page 54211]]

    (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 paragraph (h)(1)(i) and paragraph (h)(1)(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 paragraph (h)(1)(i)(A) through (C) and paragraph 
(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 will sunset on 
[8 years after effective date].
    (2) Handset-based technologies: (i) Two years from January 18, 
2011, 50 meters for 67 percent of calls, and 150 meters for 80 percent 
of calls, on a per-county or per-PSAP basis. However, a carrier may 
exclude up to 15 percent of counties or PSAP service areas from the 150 
meter requirement based upon heavy forestation that limits handset-
based technology accuracy in those counties or PSAP service areas.
    (ii) Eight years from January 18, 2011, 50 meters for 67 percent of 
calls, and 150 meters for 90 percent of calls, on a per-county or per-
PSAP basis. However, a carrier may exclude up to 15 percent of counties 
or PSAP service areas from the 150 meter requirement based upon heavy 
forestation that limits handset-based technology accuracy in those 
counties or PSAP service areas.
    (iii) Carriers must file a list of the specific counties or PSAP 
service areas where they are using the exclusion for heavy forestation 
within 90 days following approval from the Office of Management and 
Budget for the related information collection. This list must be 
submitted electronically into PS Docket No. 07-114, and copies must be 
sent to the National Emergency Number Association, the Association of 
Public-Safety Communications Officials-International, and the National 
Association of State 9-1-1 Administrators. Further, carriers must 
submit in the same manner any changes to their exclusion lists within 
thirty days of discovering such changes.
    (iv) Providers of new CMRS networks that meet the definition of 
covered CMRS providers under paragraph (a) of this section must comply 
with the requirements of paragraphs (h)(2)(i) through (iii) of this 
section. For this purpose, a ``new CMRS network'' is a CMRS network 
that is newly deployed subsequent to the effective date of the Third 
Report and Order in PS Docket No. 07-114 and that is not an expansion 
or upgrade of an existing CMRS network.
    (3) Latency (Time to First Fix). For purposes of measuring 
compliance with the location accuracy standards of this paragraph, a 
call will be deemed to satisfy the standard only if it provides the 
specified degree of location accuracy within a maximum latency period 
of 30 seconds, as measured from the time the

[[Page 54212]]

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

[[Page 54213]]

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 paragraph 
(i)(3)(ii) of this section by collecting and reporting data based on 
the largest county within its footprint. In addition, where a non-
nationwide CMRS provider serves more than one of the ATIS ESIF 
morphologies, it must include a sufficient number of representative 
counties to cover each morphology.
    (iii) Data retention. CMRS providers shall retain testing and live 
call data gathered pursuant to this section for a period of 2 years.
    (4) Submission of plans and reports. The following reporting and 
certification obligations apply to all CMRS providers subject to this 
section, which may be filed electronically in PS Docket No. 07-114:
    (i) Initial implementation plan. No later than 18 months from the 
effective date of the adoption of this rule, nationwide CMRS providers 
shall report to the Commission on their plans for meeting the indoor 
location accuracy requirements of paragraph (i)(2) of this section. 
Non-nationwide CMRS providers will have an additional 6 months to 
submit their implementation plans.
    (ii) Progress reports. No later than 18 months from the effective 
date of the adoption of this rule, each CMRS provider shall file a 
progress report on implementation of indoor location accuracy 
requirements. Non-nationwide CMRS providers will have an additional 6 
months to submit their progress reports. All CMRS providers shall 
provide an additional progress report no later than 36 months from the 
effective date of the adoption of this rule. The 36-month reports shall 
indicate what progress the provider has made consistent with its 
implementation plan, and the nationwide CMRS providers shall include an 
assessment of their deployment of dispatchable location solutions. For 
any CMRS provider participating in the development of the NEAD 
database, this progress report must include detail as to the 
implementation of the NEAD database described in paragraphs (i)(4)(iii) 
and (iv) of this section.
    (iii) NEAD privacy and security plan. Prior to activation of the 
NEAD but no later than 18 months from the effective date of the 
adoption of this rule, the nationwide CMRS providers shall file with 
the Commission and request approval for a security and privacy plan for 
the administration and operation of the NEAD. The plan must include the 
identity of an administrator for the NEAD, who will serve as a point of 
contact for the Commission and shall be accountable for the 
effectiveness of the security, privacy, and resiliency measures.
    (iv) 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)-(3) of this section, CMRS providers subject to this 
section shall provide for all wireless 911 calls, whether from outdoor 
or indoor

[[Page 54214]]

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 (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 sections 1.45 and 1.47 of this chapter.
    (iii) The certification must be in the form of an affidavit signed 
by a director or officer of the carrier, documenting:
    (A) The basis for the carrier's determination that the PSAP will 
not be ready;
    (B) Each of the specific steps the carrier has taken to provide the 
E911 service requested;
    (C) The reasons why further implementation efforts cannot be made 
until the PSAP becomes capable of receiving and using the data elements 
associated with the E911 service requested; and
    (D) The specific steps that remain to be completed by the wireless 
carrier and, to the extent known, the PSAP or other parties before the 
carrier can provide the E911 service requested.
    (iv) All affidavits must be correct. The carrier must ensure that 
its affidavit is correct, and the certifying director or officer has 
the duty to personally determine that the affidavit is correct.
    (v) A carrier may not engage in a practice of filing inadequate or 
incomplete certifications for the purpose of delaying its 
responsibilities.
    (vi) To be eligible to make a certification, the wireless carrier 
must have completed all necessary steps toward E911 implementation that 
are not dependent on PSAP readiness.
    (vii) A copy of the certification must be served on the PSAP in 
accordance with 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 
Sec. Sec.  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 paragraph (m)(4) of 
this section

[[Page 54215]]

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) Definitions. 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 sections 9.10(d)-
(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 section 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) 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)(i) A covered text provider is not required to provide an 
automatic bounce-back message when:
    (A) Transmission of the text message is not controlled by the 
provider;
    (B) A consumer is attempting to text 911, through a text messaging 
application that requires CMRS service, from a non-service initialized 
handset;
    (C) When the text-to-911 message cannot be delivered to a PSAP due 
to failure in the PSAP network that has not been reported to the 
provider; or
    (D) A consumer is attempting to text 911 through a device that is 
incapable of sending texts via three digit short codes, provided the 
software for the device cannot be upgraded over the air to allow text-
to-911.
    (ii) The provider of a preinstalled or downloadable interconnected 
text application is considered to have ``control'' over transmission of 
text messages for purposes of paragraph (q)(4)(i)(A) of this section. 
However, if a user or a third party modifies or manipulates the 
application after it is installed or downloaded so that it no longer 
supports bounce-back messaging, the application provider will be 
presumed not to have control.
    (5) 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) 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.

[[Page 54216]]

    (7) 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) 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.
    (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 of this chapter, provided that ``all wireless 911 calls'' is 
defined as ``any call initiated by a wireless user dialing 911 on a 
phone using a compliant radio frequency protocol of the serving 
carrier.'' This requirement shall not apply if the Public Safety 
Answering Point or emergency authority informs the CIS provider that it 
does not wish to receive 911 calls from the CIS provider.

Subpart D--Interconnected Voice Over Internet Protocol Services and 
911 VoIP Services


Sec.  9.11   E911 Service.

    (a) Before February 16, 2020. (1) Scope of Section. The following 
requirements are only applicable to providers of interconnected VoIP 
services. 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 of this chapter, 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

[[Page 54217]]

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 of this chapter.
    (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) Distribute to its existing subscribers 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. Each interconnected VoIP provider shall distribute such 
warning stickers or other appropriate labels to each new subscriber 
prior to the initiation of that subscriber's service.
    (b) On or after February 16, 2020. (1) Scope of Section. The 
following requirements are only applicable to providers of 
interconnected VoIP services and 911 VoIP services. Further, the 
following 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 and 911 
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 and 911 VoIP service 
providers must transmit all 911 calls, as well as ANI and the caller's 
dispatchable location for each call, 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 of this chapter, 
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 dispatchable 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 (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 of this chapter.
    (4) Dispatchable Location Requirement. Interconnected VoIP service 
providers and 911 VoIP service providers must comply with either 
subparagraph (4)(i) or (4)(ii) below.
    (i)(A) Obtain from each customer, prior to the initiation of 
service, the Registered Location at which the service will first be 
used;
    (B) 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 or 
911 VoIP service. Any method used must allow an end user to update the 
Registered Location at will and in a timely manner; and
    (C) For interconnected VoIP service or 911 VoIP service that is 
capable of being used from more than one location, 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.
    (ii) Obtain the customer's dispatchable location at the time the 
customer initiates a 911 call without requiring additional action by 
the customer.
    (5) Customer Notification. Each interconnected VoIP service 
provider and 911 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 911 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) 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) Distribute to its existing subscribers 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 911 VoIP service. Each interconnected VoIP provider or 
911 VoIP service provider shall distribute such warning stickers or 
other appropriate labels to each new subscriber prior to the initiation 
of that subscriber's service.

[[Page 54218]]

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 or 911 VoIP service provider as set forth 
in paragraphs (a)(1) and (a)(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 or 911 VoIP 
service 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 or 
911 VoIP service provider only if that capability is necessary to 
enable the interconnected VoIP provider or 911 VoIP service 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 or 
911 VoIP service 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 or 911 VoIP 
service 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 regulations and requirements applicable to common 
carriers shall also be applicable to providers of interconnected VoIP 
service as defined in Sec.  9.2.


Sec.  9.14  Emergency calling requirements.

    (a) Emergency call handling requirements for TTY-based TRS 
providers. (1) Before February 16, 2020. 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 he had dialed 911 directly, 
or a PSAP that is capable of enabling the dispatch of emergency 
services to the caller in an expeditious manner.
    (2) On or after February 16, 2020. 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) and transmits the caller's dispatchable location 
to the PSAP. An appropriate PSAP is either a PSAP that the caller would 
have reached if he 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) As of December 31, 2008, the 
requirements of paragraphs (b)(2)(i) and (b)(2)(v) of this section 
shall not apply to providers of VRS and IP Relay to which Sec. Sec.  
9.14(c) and 9.14(d) apply.
    (2) Each provider of internet-based TRS shall:
    (i) 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) Before February 16, 2020. Request, at the beginning of each 
emergency call, the caller's name and location information, unless the 
internet-based TRS provider already has, or has access to, a Registered 
Location for the caller;
    (iv) On or after February 16, 2020. Request, at the beginning of 
each emergency call, the caller's name and dispatchable location, 
unless the internet-based TRS provider already has, or has access to, a 
dispatchable location for the caller;
    (v) 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;
    (vi) 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
    (vii) 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 February 16, 2020. (1) 
Scope. The following requirements are only applicable to providers of 
VRS or IP Relay. Further, the following 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. (i) VRS or IP Relay providers must, as a 
condition of providing service to a user, provide that user with E911 
service as described in this section;
    (ii) VRS or IP Relay providers must 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

[[Page 54219]]

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 of this chapter, provided that ``all 911 
calls'' is defined as ``any communication initiated by an VRS or IP 
Relay 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, the name of the VRS or IP Relay 
provider, and the CA's identification number 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 (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)(iii) 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.  64.3001 of this chapter.
    (4) Registered location requirement. As of December 31, 2008, 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 their 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 February 16, 
2020. (1) Scope. The following requirements are only applicable to 
providers of VRS or IP Relay. Further, the following 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. (i) VRS or IP Relay providers must, as a 
condition of providing service to a user, provide that user with E911 
service as described in this section;
    (ii) VRS or IP Relay providers must transmit all 911 calls, as well 
as ANI, the caller's dispatchable 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 dispatchable 
location and that has been designated for telecommunications carriers 
pursuant to Sec.  9.4 of this chapter, provided that ``all 911 calls'' 
is defined as ``any communication initiated by an VRS or IP Relay 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 dispatchable location, the name of the VRS or IP Relay 
provider, and the CA's identification number 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 (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)(iii) 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 of this chapter.
    (4) Dispatchable location requirement. VRS and IP Relay providers 
must comply with either paragraphs (4)(i) or (4)(ii) of this section.
    (i)(A) Obtain from each Registered internet-based TRS User, prior 
to the initiation of service, the Registered Location at which the 
service will first be used; and
    (B) 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 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 a registered internet-based TRS user to update the 
Registered Location at will and in a timely manner; and
    (C) If the VRS or IP Relay is capable of being used from more than 
one location, identify whether the service is being used from a 
different location than the Registered Location, and if so, either:
    (1) Prompt the Registered internet-based TRS User to provide a new 
Registered Location; or
    (2) Update the Registered Location without requiring additional 
action by the Registered internet-based TRS User.
    (ii) Obtain the Registered internet-based TRS User's dispatchable 
location at the time they initiate a 911 call without requiring 
additional action by the Registered internet-based TRS User.

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.

[[Page 54220]]

    (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 is pre-configured such that, when properly installed in 
accordance with subsection (b), the dispatchable location of the caller 
is conveyed to the PSAP with 911 calls.
    (b) Obligation of installers, operators and managers. (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 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. The MLTS notification must be contemporaneous 
with the 911 call and must not delay the call to 9-1-1.
    (3) A person engaged in the business of installing, managing, or 
operating multi-line telephone systems may not install, 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.


Sec.  9.17  Enforcement, Compliance date, State law.

    (a) Enforcement. Sections 9.16(a)(1) and 9.16(b)(1) and (2) of this 
subpart 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.
    (b) Compliance date. The compliance date for this subpart F is 
February 16, 2020. Accordingly, the requirements in this subpart apply 
to MLTS that are manufactured, imported, offered for first sale or 
lease, first sold or leased, or installed after February 16, 2020.
    (c) Effect on State law. Nothing in this subpart 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 
(part 25, subparts A-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) of this section.
    (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 
of this chapter; 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

[[Page 54221]]

    (B) Offers the capability to originate 911 calls where another 
service provider delivers those calls and associated number or location 
information to the appropriate PSAP.
    (5) Critical 911 circuits. 911 facilities that originate at a 
selective router or its functional equivalent and terminate in the 
central office that serves the PSAP(s) to which the selective router or 
its functional equivalent delivers 911 calls, including all equipment 
in the serving central office necessary for the delivery of 911 calls 
to the PSAP(s). Critical 911 circuits also include ALI and ANI 
facilities that originate at the ALI or ANI database and terminate in 
the central office that serves the PSAP(s) to which the ALI or ANI 
databases deliver 911 caller information, including all equipment in 
the serving central office necessary for the delivery of such 
information to the PSAP(s).
    (6) Diversity audit. A periodic analysis of the geographic routing 
of network components to determine whether they are physically diverse. 
Diversity audits may be performed through manual or automated means, or 
through a review of paper or electronic records, as long as they 
reflect whether critical 911 circuits are physically diverse.
    (7) Monitoring links. Facilities that collect and transmit network 
monitoring data to a NOC or other location for monitoring and analyzing 
network status and performance.
    (8) Physically diverse. Circuits or equivalent data paths are 
Physically Diverse if they provide more than one physical route between 
end points with no common points where a single failure at that point 
would cause both circuits to fail. Circuits that share a common segment 
such as a fiber-optic cable or circuit board are not Physically diverse 
even if they are logically diverse for purposes of transmitting data.
    (9) 911 service area. The metropolitan area or geographic region in 
which a covered 911 service provider operates a selective router or the 
functional equivalent to route 911 calls to the geographically 
appropriate PSAP.
    (10) Selective router. A 911 network component that selects the 
appropriate destination PSAP for each 911 call based on the location of 
the caller.
    (11) Tagging. An inventory management process whereby critical 911 
circuits are labeled in circuit inventory databases to make it less 
likely that circuit rearrangements will compromise diversity. A covered 
911 service provider may use any system it wishes to tag circuits so 
long as it tracks whether critical 911 circuits are physically diverse 
and identifies changes that would compromise such diversity.
    (b) Provision of reliable 911 service. All covered 911 service 
providers shall take reasonable measures to provide reliable 911 
service with respect to circuit diversity, central-office backup power, 
and diverse network monitoring. Performance of the elements of the 
certification set forth in paragraphs (c)(1)(i), (c)(2)(i), and 
(c)(3)(i) of this section shall be deemed to satisfy the requirements 
of this paragraph. If a covered 911 service provider cannot certify 
that it has performed a given element, the Commission may determine 
that such provider nevertheless satisfies the requirements of this 
paragraph based upon a showing in accordance with paragraph (c) of this 
section that it is taking alternative measures with respect to that 
element that are reasonably sufficient to mitigate the risk of failure, 
or that one or more certification elements are not applicable to its 
network.
    (c) 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:

[[Page 54222]]

    (A) Conducted diversity audits of the aggregation points that it 
uses to gather network monitoring data in each 911 service area;
    (B) Conducted diversity audits of monitoring links between 
aggregation points and NOCs for each 911 service area in which it 
operates; and
    (C) Implemented physically diverse aggregation points for network 
monitoring data in each 911 service area and physically diverse 
monitoring links from such aggregation points to at least one NOC.
    (ii) If a Covered 911 Service Provider does not conform with all of 
the elements in paragraph (c)(3)(i) of this section, it must certify 
with respect to each such 911 Service Area:
    (A) Whether it has taken alternative measures to mitigate the risk 
of network monitoring facilities that are not physically diverse or is 
taking steps to remediate any issues that it has identified with 
respect to diverse network monitoring in that 911 service area, in 
which case it shall provide a brief explanation of such alternative 
measures or such remediation steps, the date by which it anticipates 
such remediation will be completed, and why it believes those measures 
are reasonably sufficient to mitigate such risk; or
    (B) Whether it believes that one or more of the requirements of 
this paragraph are not applicable to its network, in which case it 
shall provide a brief explanation of why it believes any such 
requirement does not apply.
    (d) Other matters. --(1) 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.
    (2) 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) 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

[[Page 54223]]

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(e) of this chapter.
    (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) Effective 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 effective February 16, 2016, and the 
obligations under paragraph (d) of this section are effective 120 days 
after the Commission announces approval from the Office of Management 
and Budget.
    (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 effective August 11, 2016, the obligations 
in paragraph (b)(2) of this section are effective as prescribed 
therein, and the obligations under paragraph (d) of this section are 
effective 300 days after the Commission announces approval from the 
Office of Management and Budget.
    (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
2. Under the authority of 47 U.S.C. 151, 154(i), 154 (j), 154 (o), 
155(c), 201(b), 214(d), 218, 219, 251(e)(3), 301, 303(b), 303(g), 
303(j), 303(r), 307, 309(a), 316, 332, 403, 405, 615a-1, 615c, 
621(b)(3), and 621(d)), 47 CFR chapter I is amended by removing and 
reserving part 12.

PART 20--COMMERCIAL MOBILE SERVICES

0
3. 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
4. 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
5. 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
6. Remove and reserve Sec.  20.18.

PART 25--SATELLITE COMMUNICATIONS

0
7. 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
8. Section 25.103 is amended by removing the definition of ``Emergency 
Call Center.''
0
9. Section 25.109 is amended by adding paragraph (e) to read as 
follows:


Sec.  25.109   Cross-reference

* * * * *
    (e) Mobile-Satellite Service providers must comply with the 
emergency call center service requirements under 47 CFR part 9.


Sec.  25.284   [Removed and Reserved]

0
10. Remove and reserve Sec.  25.284.

PART 64--MISCELLANEOUS RULES RELATING TO COMMON CARRIERS

0
11. 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
12. 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 terms Public Safety Answering 
Point (PSAP), statewide default answering point, and appropriate local 
emergency authority are defined in 47 CFR 9.3; 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
13. 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
14. Section 64.604 is amended by revising paragraphs (a)(4) and (d) to 
read as follows:


Sec.  64.604   Mandatory minimum standards.

    (a) * * *
    (4) Emergency call handling requirements for TTY-based TRS 
providers. TTY-based TRS providers are subject to the emergency call 
handling requirements in Sec.  9.14(a).
* * * * *
    (d) Other standards. The applicable requirements of Sec. Sec.  
9.14, 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
15. Remove and reserve Sec.  64.605.

[[Page 54224]]

Subpart AA [Removed and reserved]

0
16. Remove and reserve Subpart AA, consisting of Sec. Sec.  64.3000 
through 64.3004.

[FR Doc. 2018-21888 Filed 10-25-18; 8:45 am]
 BILLING CODE 6712-01-P