[Federal Register Volume 84, Number 234 (Thursday, December 5, 2019)]
[Rules and Regulations]
[Pages 66716-66779]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2019-20137]
[[Page 66715]]
Vol. 84
Thursday,
No. 234
December 5, 2019
Part II
Federal Communications Commission
-----------------------------------------------------------------------
47 CFR Parts 1, 9, 12, et al.
Implementing Kari's Law and RAY BAUM'S Act; Inquiry Concerning 911
Access, Routing, and Location in Enterprise Communications Systems;
Amending the Definition of Interconnected VoIP Service; Final Rule
Federal Register / Vol. 84 , No. 234 / Thursday, December 5, 2019 /
Rules and Regulations
[[Page 66716]]
-----------------------------------------------------------------------
FEDERAL COMMUNICATIONS COMMISSION
47 CFR Parts 1, 9, 12, 20, 22, 25, and 64
[PS Docket Nos. 18-261, 17-239; GN Docket No. 11-117; FCC 19-76]
Implementing Kari's Law and RAY BAUM'S Act; Inquiry Concerning
911 Access, Routing, and Location in Enterprise Communications Systems;
Amending the Definition of Interconnected VoIP Service
AGENCY: Federal Communications Commission.
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: In this document, the Federal Communications Commission (the
FCC or Commission) adopts rules for 911 calls made from multi-line
telephone systems (MLTS), pursuant to Kari's Law, the conveyance of
dispatchable location with 911 calls, as directed by RAY BAUM'S Act,
and the consolidation of the Commission's 911 rules. The President
recently signed into law two statutes designed to improve emergency
calling: Kari's Law applies to MLTS, which are telephone systems that
serve consumers in environments such as office buildings, campuses, and
hotels. Kari's Law requires MLTS systems in the United States to enable
users to dial 911 directly, without having to dial a prefix to reach an
outside line, and to provide for notification (e.g., to a front desk or
security office) when a 911 call is made; RAY BAUM'S Act requires the
Commission to conduct a rulemaking proceeding to consider adopting
rules to ensure that ``dispatchable location'' is conveyed with 911
calls, regardless of the technological platform used, so that 911 call
centers will receive the caller's location automatically and can
dispatch responders more quickly. ``Dispatchable location'' is defined
as ``the street address of the calling party, and additional
information such as room number, floor number, or similar information
necessary to adequately identify the location of the calling party.''
The Commission adopts rules to implement Kari's Law and initiates the
rulemaking on dispatchable location required by RAY BAUM'S Act. The
Commission also consolidates the Commission's existing 911 rules into a
single rule part.
DATES:
Effective date: January 6, 2020.
Compliance date: Compliance will not be required for Sec. Sec.
9.8(a); 9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4);
9.11(b)(5)(ii); (iii); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v);
9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); and
9.16(b)(3)(i), (ii), and (iii) until the Commission publishes a
document in the Federal Register announcing the compliance date.
ADDRESSES: The complete text of this document is available for
inspection and copying during normal business hours in the FCC
Reference Information Center, Portals II, 445 12th Street SW, Room CY-
A257, Washington, DC 20554.
FOR FURTHER INFORMATION CONTACT: For further information, contact
Brenda Boykin, Attorney-Advisor, Policy and Licensing Division, Public
Safety and Homeland Security Bureau, (202) 418-2062 or via email at
[email protected]; William Beckwith, Attorney-Advisor, Policy and
Licensing Division, Public Safety and Homeland Security Bureau, (202)
418-0134 or via email at [email protected]; Thomas Eng,
Engineer, Policy and Licensing Division, Public Safety and Homeland
Security Bureau, (202) 418-0019 or via email at [email protected]; Dr.
Rasoul Safavian, Technologist, Policy and Licensing Division, Public
Safety and Homeland Security Bureau, (202) 418-0754 or via email at
[email protected].
SUPPLEMENTARY INFORMATION: This is a summary of the Commission's Report
and Order, FCC 19-76, adopted on August 1, 2019 and released on August
2, 2019. To request materials in accessible formats for people with
disabilities (Braille, large print, electronic files, audio format),
send an email to [email protected] or call the Consumer & Governmental
Affairs Bureau at (202) 418-0530 (voice), (202) 418-0432 (TTY). The
complete text of the order also is available on the Commission's
website at http://www.fcc.gov.
Synopsis
I. Introduction
1. In this Report and Order, we adopt measures to help ensure that
members of the public can successfully dial 911 to request emergency
services and that Public Safety Answering Points (PSAPs) can quickly
and accurately locate every 911 caller, regardless of the type of
service that is used to make the call. We act today pursuant to two
federal statutes: Kari's Law Act of 2017, which requires implementation
of direct 911 dialing and on-site notification capabilities in multi-
line telephone systems (MLTS), and section 506 of RAY BAUM'S Act, which
requires the Commission to ``consider adopting rules to ensure that the
dispatchable location is conveyed with a 9-1-1 call, regardless of the
technological platform used and including with calls from [MLTS].''
2. In particular, we adopt rules that implement the direct dialing
and notification requirements of Kari's Law and clarify the law's
application to both legacy MLTS and Internet Protocol (IP)-based
systems, including cloud-based services, that support the
communications needs of hotels, businesses, campuses, and other
enterprises. And we adopt rules that will facilitate timely emergency
response and improved location accuracy across communications
platforms. These requirements are measured, technically feasible, and
technologically neutral, so that providers can choose the most
effective solutions from a range of options. In addition, our
requirements allow sufficient time for advance planning and deployment
of new location technology. Similar to the approach the Commission has
taken in the wireless E911 context, we believe that ``[c]lear and
measurable timelines and benchmarks for all stakeholders are essential
to drive the improvements that the public reasonably expects to see in
911 location performance.'' We also take this opportunity to
consolidate our existing 911 rules, as well as the direct dialing and
dispatchable location rules adopted today, into a single rule part.
II. Background
3. Enhanced 911 (E911) was developed to provide PSAPs with the
caller's location and a call-back number as part of each 911 call.
Since its implementation, most E911 calls have conveyed information
regarding the caller's location (with varying degrees of accuracy) and
a call-back number to the PSAP. These enhancements have significantly
improved PSAPs' ability to effectively deliver critical public safety
and emergency response services in a timely manner. In many instances,
E911 has proven to be a life-saving, essential emergency response tool
for providing critical information when the caller is unable to
verbally communicate his or her location, including when the voice call
is dropped or discontinued and cannot be reestablished.
4. Under the Commission's rules, consumers generally have access to
these capabilities when they make fixed telephony, mobile, and
interconnected VoIP calls to 911. However, to date, the Commission's
E911 rules have not applied to MLTS. Consequently, consumers in
environments such as office buildings, campuses, and hotels may not
have the same access to E911 services that is provided by fixed
telephony, mobile, and VoIP systems,
[[Page 66717]]
namely direct dialing access to 911 and the provision of the MLTS
user's location information.
5. MLTS include a widely embedded base of legacy private branch
exchange (PBX), Centrex, and Key Telephone systems, IP-based systems,
and hybrid systems. MLTS serve millions of employees, residents, and
guests of businesses and educational facilities, including corporate
parks, hotels, college campuses, and planned community developments.
These systems can support anywhere from ten to thousands of telephone
station/numbers. Emergency calls from MLTS stations generally only
provide PSAPs the telephone or circuit number of the system's outgoing
trunk, and not the emergency caller's individual station number. In
some cases, the MLTS station that placed the call will not even have
its own telephone number. As a result, PSAPs often find they are unable
to locate an MLTS emergency call to the station from which it
originated. The Commission in 2003 considered E911 requirements for
MLTS but deferred to the states to address this issue, while preserving
the option of acting should states fail to do so.
6. At least 23 states have enacted legislation that requires
organizations over a certain size or purchasing a new PBX/MLTS system
to implement E911 on the system. These states have adopted varied
requirements for MLTS providers, and only in some instances have state
laws specifically addressed prefix dialing requirements. In the absence
of federal or consistent state regulation, some MLTS in operation today
do not support direct 911 dialing, may not have the capability to route
calls to the appropriate PSAP relative to the caller's location, or may
not provide accurate information regarding the caller's location. The
Commission has observed that these issues have persisted, even as many
enterprises are increasingly relying on IP-based systems, including
cloud-based services, to support their communications needs.
7. Given that the ongoing evolution of MLTS has not eliminated
these shortfalls when serving 911 callers, the Commission has
periodically sought to examine MLTS provision of 911, including the
capabilities of MLTS to support direct 911 access, routing, callback,
and automatic location. In September 2017, the Commission released a
Notice of Inquiry (Enterprise Communications NOI) seeking information
on the capabilities of enterprise communications systems to support
direct 911 access, routing, and automatic location. The Commission
noted that such systems may not provide consumers with the same access
to E911 services as other wireline, wireless, and interconnected VoIP
calls and asked whether it is still the case, as the Commission found
in earlier proceedings, that the needs and circumstances of residential
and business enterprise communications system users are suited to
state-level action rather than federal regulation. The Enterprise
Communications NOI also sought information on the state of the
enterprise communications system industry; the costs and benefits of
supporting E911 for enterprise communications system; the capability of
enterprise communications system to provide accessible emergency
communications for persons with disabilities; and options for ensuring
that enterprise communications system keep pace with technological
developments and consumer expectations for access to 911.
8. Kari's Law was enacted on February 16, 2018. Kari's Law
establishes a federal multi-tiered approach to MLTS 911 requirements.
First, Kari's Law applies to any ``person engaged in the business of
manufacturing, importing, selling, or leasing'' MLTS. Such persons
``may not manufacture or import for use in the United States, or sell
or lease or offer to sell or lease in the United States, a [MLTS],
unless such system is pre-configured such that, when properly installed
. . . a user may directly initiate a call to 9-1-1 from any station
equipped with dialing facilities, without dialing any additional digit,
code, prefix, or post-fix, including any trunk-access code such as the
digit `9', regardless of whether the user is required to dial such a
digit, code, prefix, or post-fix for other calls.''
9. Second, Kari's Law applies to any ``person engaged in the
business of installing, managing, or operating'' MLTS. Such persons
``may not install, manage, or operate for use in the United States such
a system, unless such system is configured such that a user may
directly initiate a call to 9-1-1 from any station equipped with
dialing facilities, without dialing any additional digit, code, prefix,
or post-fix, including any trunk-access code such as the digit `9',
regardless of whether the user is required to dial such a digit, code,
prefix, or post-fix for other calls.''
10. Third, such persons ``shall, in installing, managing, or
operating such a system for use in the United States, configure the
system to provide a notification to a central location at the facility
where the system is installed or to another person or organization
regardless of location, if the system is able to be configured to
provide the notification without an improvement to the hardware or
software of the system.''
11. Fourth, Kari's Law expressly provides that Congress did not
intend to ``alter the authority of State commissions or other State or
local agencies with jurisdiction over emergency communications, if the
exercise of such authority is not inconsistent with this [Act].''
Kari's Law directs the Commission to enforce the provisions under Title
V of the Communications Act of 1934, as amended, ``except that section
501 applies only to the extent that such section provides for the
punishment of a fine.'' The effective date provision states that Kari's
Law ``shall apply with respect to a multi-line telephone system that is
manufactured, imported, offered for first sale or lease, first sold or
leased, or installed after'' February 16, 2020.
12. On March 23, 2018, shortly after Kari's Law was enacted, the
President signed the Consolidated Appropriations Act of 2018, including
RAY BAUM'S Act, into law. Section 506 of RAY BAUM'S Act requires the
Commission to ``conclude a proceeding to consider adopting rules to
ensure that the dispatchable location is conveyed with a 9-1-1 call,
regardless of the technological platform used and including with calls
from multi-line telephone systems'' by September 23, 2019. In
conducting this proceeding, ``the Commission may consider information
and conclusions from other Commission proceedings regarding the
accuracy of the dispatchable location for a 9-1-1 call, but nothing in
this section shall be construed to require the Commission to reconsider
any information or conclusion from a proceeding regarding the accuracy
of the dispatchable location for a 9-1-1 call in which the Commission
has adopted rules or issued an order'' before the March 23, 2018
enactment date of section 506.
13. In September 2018, following the enactment of Kari's Law and
RAY BAUM'S Act, the Commission proposed rules to implement Kari's Law
and to support dispatchable location for 911 calls from MLTS and other
communications platforms. Specifically, the NPRM proposed to implement
Kari's Law by adopting direct dial and notification rules governing
calls to 911 made from MLTS and clarifying the definitions associated
with the law. As required by RAY BAUM'S Act, the Commission also
initiated this proceeding to consider the feasibility of requiring
dispatchable location for 911 calls from MLTS and other technological
platforms. The
[[Page 66718]]
Commission proposed dispatchable location requirements for MLTS 911
calls, which would apply contemporaneously with the February 16, 2020
compliance date of Kari's Law, and proposed to add dispatchable
location requirements to our existing 911 rules for fixed telephony
providers, interconnected Voice over IP (VoIP) providers, and internet-
based Telecommunications Relay Services (TRS). The NPRM also considered
the feasibility of alternative location mechanisms for MLTS and other
services that could be used as a complement to dispatchable location or
as a substitute when dispatchable location is not available.
Additionally, the Commission sought comment on whether dispatchable
location requirements should be extended to other communications
services that are not covered by existing 911 rules but are capable of
making a 911 call. Finally, the NPRM proposed to consolidate the
Commission's existing 911 rules into a single rule part.
III. Discussion
A. Direct Dialing and Notification for MLTS
14. Because Congress incorporated Kari's Law into the
Communications Act of 1934, as amended (the Act), the Commission has
authority to prescribe such rules and regulations as are necessary to
carry out Kari's Law. The implementing regulations we adopt in this
Report and Order are intended to provide additional clarity and
specificity regarding the terms used in the statute and the obligations
placed on covered entities.
1. Direct Dialing
15. Kari's Law provides that any person engaged in the business of
manufacturing, importing, selling, or leasing an MLTS may not
manufacture or import the MLTS for use in the United States, or sell or
lease or offer to sell or lease it in the United States, unless it is
pre-configured so that when properly installed, a user may directly
initiate a call to 911 from any station equipped with dialing
facilities. In addition, any person engaged in the business of
installing, managing, or operating an MLTS may not do so unless the
MLTS is configured so that a user may dial 911 directly. In the NPRM,
the Commission proposed rules that track these obligations.
16. We adopt the rules requiring direct dialing from MLTS generally
as proposed in the NPRM. There is broad support among all types of
commenters (industry and public safety entities) for the proposed
direct dialing rules, although some commenters seek clarification of
proposed definitions and other terms. The Texas 9-1-1 Entities state
that the proposed rules ``should generally be adopted as written.''
Microsoft asserts that proposed direct dialing and notification
requirements are consistent with Kari's Law and should be reasonably
achievable. No commenter opposes adoption of the direct dialing
requirements.
2. Notification
17. Kari's Law provides that any person engaged in the business of
installing, managing, or operating an MLTS shall, in installing,
managing, or operating such a system for use in the United States,
configure the system to provide a notification to a central location at
the facility where the system is installed or to another person or
organization regardless of location, if the system is able to be
configured to provide the notification without an improvement to the
hardware or software of the system. Consistent with this obligation,
the Commission in the NPRM proposed rules providing that installers,
managers, or operators must configure an MLTS to provide for
transmission of a 911 notification if the system can be configured to
do so without an improvement to the hardware or software of the system.
The Commission stated that notification will potentially benefit three
parties: (1) The 911 caller by speeding response time; (2) enterprise
management and staff by providing needed information and reducing
confusion and delay when emergency response teams arrive; and (3) first
responders by reducing time spent responding to such calls.
a. Required Information and Purpose
18. Kari's Law requires an MLTS to support notification when an end
user makes a 911 call, but it does not specify what information must be
provided in the notification. In the NPRM, the Commission proposed to
define ``MLTS Notification'' as follows: ``An MLTS feature that can
send notice to a central location at the facility where the system is
installed or to another person or organization regardless of location.
Examples of notification include screen pops with audible alarms for
security desk computers using a client application, text messages for
smartphones, and email for administrators. Notification shall include,
at a minimum, the following information: (1) The fact that a 911 call
has been made, (2) a valid callback number, and (3) the information
about the caller's location that the MLTS conveys to the public safety
answering point (PSAP) with the call to 911.''
19. The Commission tentatively concluded that for notification to
be capable of achieving the purpose of Kari's Law, it should include
basic information that will assist the enterprise and first responders
in coordinating and expediting on-site response to the emergency. The
Commission also stated its intention for notification to include only
information that is also conveyed to the PSAP with the initial call to
911, including the same dispatchable location information that the PSAP
receives. Because notification is intended to help the enterprise
assist first responders, the Commission noted, it makes sense for the
recipient of the notification to have the same information as the PSAP
(and, indirectly, the first responders dispatched to the scene). In
addition, requiring the notification to convey only information that
already exists for the 911 call would minimize the burden for
enterprises to comply.
20. We adopt the proposal from the NPRM with certain changes. As
proposed, we find that the notification should include the fact that a
911 call has been made, a valid callback number, and the same location
information that is conveyed with the call to 911. However, we provide
an exception for callback number and location information in
circumstances where including this information in the notification
would be technically infeasible. We also clarify that the callback
number in the notification does not have to be a Direct Inward Dialing
number to the 911 caller's extension if one is not available.
21. Several commenters express support for the Commission's
proposed notification requirements. APCO supports the Commission's
proposal provided that notification does not delay the call to
emergency responders. Verizon states that the Commission's proposed
notification rule is straightforward and consistent with the statute's
focus and notes that the technical details of how the capability is
implemented will vary among enterprise customers based on their size,
resources, and the particular network configuration involved.
22. We agree with commenters who contend that certain minimum
content is necessary to ensure that notification serves the purpose
intended for it, which is to help the enterprise provide assistance to
first responders in the event of a 911 call. For example, NASNA states
that the Commission ``absolutely'' should establish minimum content for
the notification and that it
[[Page 66719]]
should ``require that what is sent to PSAPs be sent also to the
notification center.'' RedSky asserts that the notification should also
include the date and time of the 911 call. Avaya suggests that
notification should include ``details that may not be conveyed to the
PSAP,'' such as ``location information that clearly establishes the
location of the caller'' and alerts with acknowledgement and escalation
functions.
23. At the same time, we seek to provide enterprises sufficient
flexibility to tailor the notification to best suit their needs. In
this respect, we note that some commenters urge the Commission to allow
enterprises to determine the content of notifications as they see fit.
Panasonic, for example, states that businesses should have the
flexibility to customize notifications to meet their needs, given their
understanding of the physical nature of their enterprise, the technical
capabilities of their system, and the personnel who will be involved in
assisting with an emergency response, including on-site private
emergency response teams in some cases.
24. In the absence of direction in the statutory language about
what the required notification should contain, we are also mindful of
Congress's stated intent to ``balance the need for an onsite
notification with the goal of not placing an undue burden on MLTS
owners or operators.'' Reflecting this flexible approach, we define
MLTS Notification as: ``An MLTS feature that can send notice to a
central location at the facility where the system is installed or to
another person or organization regardless of location. Examples of
notification include conspicuous on-screen messages with audible alarms
for security desk computers using a client application, text messages
for smartphones, and email for administrators. Notification shall
include, at a minimum, the following information: (1) The fact that a
911 call has been made, (2) a valid callback number, and (3) the
information about the caller's location that the MLTS conveys to the
public safety answering point (PSAP) with the call to 911; provided,
however, that the notification does not have to include a callback
number or location information if it is technically infeasible to
provide this information.''
25. Commenters raise concerns regarding the inclusion of a callback
number and location information in the notification. Cisco, Panasonic,
and TIA note that Kari's Law does not specifically require a callback
number or location information in the notification. Cisco states that
the callback number and location information conveyed in a notification
can vary based on the technology deployed in the enterprise, so the
Commission should ensure that this rule provides MLTS managers
sufficient flexibility to determine the contents of the notification.
Several commenters note that providing a callback number that reaches
the 911 caller's specific phone is not possible in some enterprises
because there is no Direct Inward Dialing phone number associated with
the MLTS endpoints. Some commenters also point out that providing the
caller's location in the notification may not be necessary or helpful
in the case of enterprises that are small or have an open workspace.
26. We therefore provide an exception for callback number and
location information in circumstances where including this information
in the notification would not be technically feasible. We agree with
commenters who assert that there may be MLTS solutions for which it is
not technically feasible to include this information in the
notification. For example, commenters point out that providing a
callback number that reaches the 911 caller's specific phone is not
possible in some enterprises because there is no phone number
associated with the MLTS endpoints. Accordingly, we clarify that the
callback number, if provided, need not be a Direct Inward Dialing
number to the 911 caller's extension if a Direct Inward Dialing number
is not available. This means, for example, that if the 911 call comes
from a non-Direct Inward Dialing number, the callback number in the
notification can be an internal extension that can be directly reached
from inside the enterprise but not from outside it. Similarly, a hotel
that does not provide a Direct Inward Dialing line to each guest room
can provide the number of a central location, such as the front desk,
in the notification. Notwithstanding that each of these MLTS
notification examples would include callback number information in lieu
of a Direct Inward Dialing number to the 911 caller, we reiterate that
omission of callback number information in the notification is
acceptable if it is technically infeasible to provide such
information.\1\
---------------------------------------------------------------------------
\1\ Likewise, the omission of the caller's location information
in the MLTS notification is acceptable if it is technically
infeasible to provide such information.
---------------------------------------------------------------------------
27. We also adopt BRETSA's suggestion to replace the term ``screen
pops'' from the NPRM with ``conspicuous on-screen messages,'' which we
find to be clearer. And we reject BRETSA's suggestion that the
Commission revise the beginning of the definition of MLTS Notification
to read, ``[a]n MLTS feature that can send notice that a call has been
placed to `9-1-1' from an MLTS station, to a central location at the
facility where the system is installed or to another person.'' We
decline to add this language because we believe the reference to the
required content of the notification later in the definition makes
clear that notification includes the fact that a call to 911 has been
made.
28. Because our requirements set a minimum, enterprises may add
other information to the notification as useful and appropriate. This
may include, for example, the occupancy status of a hotel room, or the
specific location of an IP device. Enterprises are free to include such
information in the notification as they see fit, so long as the
notification includes the required elements. Although the additional
information Avaya proposes for the content of the notification may be
helpful for some enterprises, we do not believe it would be appropriate
for all enterprises, particularly smaller businesses. We also do not
have a sufficient record to determine whether to adopt date and time of
the 911 call as required elements of the notification, as RedSky
suggests, although we encourage enterprises to include this information
at their discretion. We also encourage the development of voluntary
best practices and employee training to prepare enterprises for
responding to receipt of notification that a 911 call has been made.
For instance, training could include the circumstances under which the
notice recipient (or someone else at the enterprise) should dial the
callback number included with the notification.
29. Finally, BRETSA asserts that PSAPs and first responders should
determine the notification and location information provided by the
enterprise, with a process for state and local public safety
authorities to waive the Commission's MLTS rules where reasonable and
appropriate. We decline to find that state and local public safety
agencies have authority to waive the Commission's rules, as BRETSA
requests. Requests for such waivers should, as with other Commission
requirements, be presented to the Commission.
b. Notification Timing
30. Kari's Law is silent on when the notification must be provided.
The Commission proposed to require that MLTS covered by Kari's Law be
[[Page 66720]]
configured so that notification is contemporaneous with the 911 call
and does not delay the placement of the call to 911. Most commenters
that address this issue support the Commission's proposal.
31. We adopt the timing requirement as proposed but clarify that
initiation of the notification must be contemporaneous with the call to
911. As RedSky points out, notification can occur in many forms,
including SMS text messages, email, screen display, and conference
calls, and the delivery of text messages and email is not within the
control of the MLTS provider or the MLTS user. Accordingly, RedSky asks
the Commission to clarify that initiation of the notification must be
contemporaneous with connection of the emergency caller to the PSAP. We
concur. The record shows the importance of timely notification.
According to NENA, ``[n]otification contemporaneous with the 9-1-1 call
has significantly greater value to all parties than after-the-fact
notification, and the majority of a notification's benefits to response
are lost if the notification is not conveyed in real-time.''
32. We also note Ad Hoc's concern that some enterprise owner/
operators of MLTS currently report challenges in configuring MLTS
equipment to provide contemporaneous notification in addition to
placing the call to 911 emergency services. As a result, Ad Hoc states,
the Commission should condition its proposal for the timing of
notification on what is ``technically feasible.'' We condition this
requirement on the technical feasibility of providing contemporaneous
notification, as Ad Hoc requests.
c. Notification Destination Points
33. The Commission also sought comment in the NPRM on whether there
should be any requirements relating to the location, configuration, or
staffing of notification destination points. Kari's Law states that the
notification may be provided either to a ``central location at the
facility where the system is installed'' or to ``another person or
organization regardless of location.'' The Commission noted that this
language indicates Congress's recognition that in the enterprise
settings where MLTS are typically used, providing someone other than
the PSAP with notice of the call can be critical to helping first
responders gain timely access. At the same time, the language
``regardless of location,'' as illuminated by legislative history,
indicates that Congress sought to provide MLTS installers, managers,
and operators with broad flexibility in selecting destination points to
achieve this goal. For example, the notification could be directed to
an on-site security desk that controls access to the premises, to an
enterprise employee who may or may not be located at the facility where
the MLTS is installed, or to a third party that provides security or
safety services from an off-site location. MLTS notification could also
be configured to combine these approaches, e.g., by having
notifications during business hours go to a central on-site location
and off-hours notifications go to an off-site person or organization.
34. The Commission sought comment on whether it should specify
criteria for destination points to ensure that notifications are likely
to be received by someone able to take appropriate action to facilitate
or assist the 911 response. Where on-site notification to a ``central
location'' is provided, the Commission asked whether it should specify
that the destination point must be a location that is normally staffed
or, alternatively, a location where on-site staff are likely to hear or
see the notification. The Commission noted that this approach would
afford flexibility to direct the on-site notification to a security
guard or facilities manager, to personnel who are otherwise employed
and can support monitoring notifications as part of existing duties, or
to an on-site location where staff are normally present.
35. We adopt a requirement that notifications be sent to a location
on-site or off-site where someone is likely to hear or see the
notification. Some commenters urge the Commission to establish criteria
for notification destination points, while others urge the Commission
to preserve flexibility for the enterprise. In this respect, we note
NASNA's assertion that notification ``absolutely'' should be to a
location that is normally staffed or where staff are likely to hear or
see the notification and that ``[t]o do otherwise would undermine the
purpose of the notification requirement.'' We agree with NASNA that the
Commission should set some criteria for notification destination points
to help ensure that they serve the purpose of Kari's Law.
36. The requirement we adopt preserves flexibility for the
enterprise to select an appropriate destination point. For instance, we
recognize AHLA's suggestion that ``[h]ow an individual hotel determines
to send a notification (via text message, a separate call or email), to
whom the notification is sent, and where the recipient is at the time
of receipt should be at the discretion of the hotel. For example, a
hotel with a single on-duty employee overnight should not be required
to send notification to a desk that may not be manned; a text message
to the employee's mobile device might be more appropriate.'' Our
requirement would allow a hotel such as the one described by AHLA to
send a text message to the overnight employee's mobile device.\2\
---------------------------------------------------------------------------
\2\ The definition of MLTS notification we adopt does not
specify any particular form for the notification and states that
examples of notification include ``conspicuous on-screen messages
with audible alarms for security desk computers using a client
application, text messages for smartphones, and email for
administrators.''
---------------------------------------------------------------------------
37. In addition, we do not require that the notification point be
continuously staffed or monitored, only that it be a location where
someone is likely to see or hear the notification. The legislative
history of Kari's Law provides that the statute ``seeks to balance the
need for an onsite notification with the goal of not placing an undue
burden on MLTS owners or operators.'' Consistent with this, the
Commission in the NPRM stated that it did not believe Congress intended
to impose staffing or monitoring requirements that would generate
unreasonable costs, such as the need to hire additional staff, or limit
the flexibility of MLTS installers, managers, and operators to develop
cost-effective notification solutions to meet their particular needs.
Based on the record before us, we adopt a requirement with which we
intend to strike an appropriate balance between the increased benefits
from having notifications sent to a location where they are likely to
be received (e.g., increased chances of assistance for first
responders) and the increased costs that are likely to result if we
were to adopt a less flexible approach (e.g., increased staffing
costs).
38. In the NPRM, the Commission also asked whether, in the case of
off-site notification, it should require that notification be to a
person or organization that is authorized to provide first responders
with access to the location from which the MLTS 911 call originated.
The Commission noted that this would allow notification to be directed
to any offsite location, as the statute clearly allows, while
furthering the statute's objective of facilitating access to first
responders answering a 911 call.
39. We agree with Ad Hoc that requiring such notification may not
make sense in all situations, such as where the enterprise does not
control access to the premises or where access to the premises is
unrestricted. We nonetheless encourage enterprises using the off-site
notification option to choose someone who can assist first responders
in gaining access to the facility if it is
[[Page 66721]]
feasible to do. As suggested by NENA's comments, it is a best practice
for notification to go to whomever ``has the keys'' if a campus or
building has restricted access and to whomever has any specialized
knowledge of the facility layout that may assist public safety in
locating and responding to a 911 call. And we encourage the development
of voluntary best practices and training for enterprise personnel,
including designated notice recipients, so that they are prepared to
assist first responders in the event of an emergency call.
d. No Exemptions to Notification Requirement
40. In the NPRM, the Commission noted that large enterprises such
as hotels, hospitals, and schools frequently have on-site personnel
that control access to the premises, and notification of 911 calls to
such personnel can improve outcomes by enabling them to assist first
responders in accessing the premises and reaching the caller's
location. The Commission sought comment on applying the statute's
notification requirements to all MLTS operators, including small
enterprises, and sought comment on whether the benefits and costs of
notification apply differently to small businesses than large
enterprises such as hotels, hospitals, and schools. Small businesses
are less likely to have personnel controlling access, and first
responders may not need the same level of assistance to reach a 911
caller. The Commission also asked whether small enterprises using MLTS
may find benefits to notification in addition to access and support,
such as the ability for the enterprise to intervene when 911 is dialed
in error and avoid sending emergency responders to a location that does
not require a response.
41. Commenters are divided on whether the Commission should provide
a small business exemption for the notification requirements of Kari's
Law. NASNA states that the benefits of notification are the same for a
small business as for a large one and that small businesses should know
that a 911 call was made from their MLTS so they are not surprised when
first responders arrive and can assist if needed, including canceling
the response if it turns out that 911 was dialed in error. Other
commenters support a small business exemption, although their specific
proposals for an exemption differ. RedSky, for example, argues that not
every enterprise using an MLTS should be required to have emergency
call notification, ``let alone staff to receive a notification,'' and
that there are many circumstances where there is no one to consume the
data and react. Proposed criteria for defining an exemption generally
include limits on square footage or the number of lines used at a
single location. In turn, RingCentral and VON urge the Commission to
limit the notification requirement to on-site calls and not to require
notification for 911 calls from distributed workforces, i.e., those
spread out over a large geographic region and relying on MLTS to
centralize communications.
42. We decline to adopt a small business exemption because we agree
with NASNA that small businesses should receive notice of 911 calls
that have been made from their MLTS so that they can prepare for the
arrival of first responders and assist if needed. We also decline to
provide an exception to the location information requirement for
enterprises that are small or have an open workspace, as some
commenters suggest. We believe location information will be helpful
even at a small business because it will confirm the caller's location
for the notice recipient, who may be at an offsite location. In
addition, the burden of providing this information should be minimal.
We note that Kari's Law does not provide an exemption for small
businesses--nor one for MLTS operators that are not always staffed. In
addition, the requirements we adopt for notification are highly
flexible and give small businesses significant latitude to configure
suitable notification mechanisms without unreasonable burden or cost.
43. We also disagree with RingCentral and VON that notification as
a rule is unlikely to be helpful at remote or satellite locations
served by an MLTS. Rather, we agree with BRETSA that limiting
application of the rules to only specific types of MLTS would distort
the market by favoring newer technologies, notwithstanding that callers
to 911 are no less impacted by failures of MLTS using those
technologies to provide notification (and interior location
information) than MLTS using other technologies. Indeed, we disagree
with arguments that whenever an MLTS is used off-site, notification is
not useful. Although RingCentral states that it has many customers that
provide centralized phone numbers and extensions for a workforce that
is working from home, the road, remote offices, or a mix of these
locations, the fact that a ``centralized location may be miles or
states away from the emergency and have no special knowledge of the
location where the emergency arose'' is irrelevant--Congress recognized
that notifications have value ``regardless of location,'' and it is not
hard to recognize that having a centralized notification system could
aid these multi-homed workers in reaching emergency services.
Similarly, we disagree with VON that ``a 911 call placed by a person
working from a satellite office would trigger a notification to someone
at the central office, who would not be able to aid first responders
when they arrive at the satellite office or otherwise speed first
responder response time,'' because someone at a staffed central office
may nonetheless aid remote first responders by, for example, alerting
other personnel at the location of the emergency. Although there may be
corner cases in which notification is not in fact helpful, we decline
on this record to exempt any particular category of MLTS facilities
from the notification requirements as a matter of policy (not to
mention that Kari's Law itself draws no such lines).
3. Definitions
a. Definition of Multi-Line Telephone System
44. Kari's Law and RAY BAUM'S Act define the term ``multi-line
telephone system'' by cross-referencing the definition in the Middle
Class Tax Relief and Job Creation Act of 2012. That Act, in turn,
defines an MLTS as:
A system comprised of common control units, telephone sets, control
hardware and software and adjunct systems, including network and
premises based systems, such as Centrex and VoIP, as well as PBX,
Hybrid, and Key Telephone Systems (as classified by the Commission
under part 68 of title 47, Code of Federal Regulations), and
includes systems owned or leased by governmental agencies and non-
profit entities, as well as for profit businesses.
45. In the NPRM, the Commission proposed to interpret this
definition to include ``the full range of networked communications
systems that serve enterprises, including circuit-switched and IP-based
enterprise systems, as well as cloud-based IP technology and over-the-
top applications.''
46. The Commission also proposed in the NPRM to interpret the
definition of MLTS to include enterprise-based systems that allow
outbound calls to 911 without providing a way for the PSAP to place a
return call (outbound-only calling service). The Commission stated that
it believed requiring direct dialing for any MLTS that allows the user
to call 911, regardless of whether the system also allows the PSAP to
make a return call, would advance the purpose of Kari's Law. In
addition, the Commission stated, there is nothing in the language of
the definition of MLTS
[[Page 66722]]
from the Middle Class Tax Relief and Job Creation Act of 2012 that
excludes systems allowing only outbound calls to 911.
47. The record is divided over the Commission's proposed definition
of MLTS. Some commenters support the proposal, while others oppose the
Commission's proposed interpretation. Commenters, however, generally
support the Commission's proposed interpretation of the definition of
MLTS to include outbound-only calling services, citing consumer
expectations and the need for regulatory parity among services.
48. As proposed in the NPRM, and consistent with the statutory
definition, we interpret the definition of MLTS to include the full
range of networked communications systems that serve enterprises,
including circuit-switched and IP-based enterprise systems, as well as
cloud-based IP technology and over-the-top applications. West Safety
endorses this approach and states that the statutory definition of MLTS
is sufficiently broad to encompass the full range of enterprise
communications systems, including ``legacy TDM MLTS, hybrid MLTS and IP
MLTS systems and software,'' as well as ``any and all endpoints
supported by MLTS including mobile and smart devices, softphone
clients, over-the-top (OTT) applications and outbound-only calling
services.'' RedSky similarly states that the term MLTS ``should not be
limited to any specific type of end point device'' because the
technology is constantly evolving. We agree.
49. TIA and VON, however, oppose the Commission's proposed
interpretation. TIA asserts that if Congress had intended its
definition to capture ``the full range'' of all technologies in the
enterprise communications marketplace, including over-the-top
applications, it could have done so in the definition. Instead, TIA
asserts, ``the definition refers by name to numerous traditional MLTS
technologies and points to Part 68 of the FCC's rules--regulations
established decades ago to govern interconnection with the PSTN [public
switched telephone network] for traditional telephony services.'' TIA
adds that ``[t]he Commission is right to think about the modern
enterprise communications market which has certainly expanded beyond
traditional locally-hosted PBX systems, but it should not expand the
scope of Kari's Law as intended by Congress.'' VON states that as
proposed, the term could cover any business with more than one line
using a cloud PBX and could therefore essentially turn any
interconnected VoIP service into MLTS (or vice versa), contrary to the
plain intent of Kari's Law. VON adds that this point becomes clearer
when compared with RAY BAUM'S Act, which directs the Commission to
``consider adopting rules to ensure that the dispatchable location is
conveyed with a 9-1-1 call, regardless of the technological platform
used and including with calls from [MLTS].'' In contrast, VON states,
Kari's Law does not discuss other technological platforms, and as a
result, ``the NPRM's proposed interpretation of MLTS goes farther than
the law allows, and should be limited to those systems provided for in
47 U.S.C. 1471.'' Cisco and Panasonic note that the statutory
definition of MLTS does not refer to the terms ``cloud-based IP
technology'' and ``over-the-top applications'' and state that it is not
clear Congress envisioned such a broad interpretation of the term.
50. We disagree with these commenters. In particular, we note that
the statutory definition also refers to VoIP, which is a newer
technology, and introduces the reference to VoIP with the term ``such
as.'' The statute thus cites VoIP (and other technologies) as examples
but not as limitations on the definition. If Congress had intended a
more constrained view of the technologies that fall within the
definition of MLTS, it would have stated that MLTS ``consists of'' or
is ``limited to'' certain technologies. In addition, the statutory
language refers broadly to a ``system comprised of common control
units, . . . control hardware and software and adjunct systems,
including network and premises-based systems.'' We find that this
language broadly includes cloud-based IP technology and over-the-top
applications. Further, there is no language in the statute specifically
excluding cloud-based IP technology and over-the-top applications from
the definition of MLTS.
51. We also believe interpreting the definition of MLTS broadly is
consistent with the intent of Kari's Law. The enterprise market has
already seen significant migration away from traditional MLTS and
toward IP-based and cloud-based systems, and Kari's Law applies only to
systems that are manufactured or brought into use after February 16,
2020. It is unlikely that Congress would seek to address the problems
of direct dialing and notification for MLTS only with respect to
traditional, non-IP-based MLTS technologies, which represent a
declining share of the MLTS market. With respect to VON's assertion
that the reference to other ``technological platform[s]'' in RAY BAUM'S
Act shows that the definition of MLTS should be interpreted narrowly
under Kari's Law, we disagree. We interpret the reference to
technological platforms in RAY BAUM'S Act as a direction for the
Commission to include other services, such as interconnected VoIP, TRS,
and fixed telephony, in its consideration of dispatchable location
rules. We do not interpret it as a limitation, explicit or implied, on
the meaning of MLTS under Kari's Law.
52. We also interpret the definition of MLTS to include outbound-
only calling systems.\3\ The statutory definition of MLTS is broad
enough to cover outbound-only calling services and does not expressly
exclude such services. Commenters generally support interpreting the
definition to include outbound-only services, and no commenter
expressly opposes this interpretation. Avaya, for example, states that
MLTS at a minimum should include any system capable of making an
outbound call. BRETSA asserts that 911 calls are outbound calls, and it
is counterintuitive that they cannot be made over outbound-only calling
systems. AT&T urges the Commission to ensure that the MLTS rules
maintain regulatory parity between new implementations of business VoIP
services and traditional MLTS business solutions and states that one-
way VoIP solutions should be required to support 911, as end users will
expect their calling solutions to have this functionality and may rely
on it in an emergency. Verizon states that applying Kari's Law
requirements to MLTS that allow outbound-only 911 dialing is likely
feasible, but that the scope of such requirements should focus on user
expectations. Verizon suggests that the rules should protect users of
outbound-only calling systems who are not employed by the enterprise or
who are otherwise unfamiliar with the system and use it for outbound-
only dialing. On the other hand, Verizon states, if the outbound-only
system has a defined and restricted user group that is uniformly
familiar with and trained in the enterprise's calling practices, and
911 is the only outbound number that users can dial, the direct dialing
capability may be less critical. Verizon also states that requiring
direct dialing capability for outbound-only MLTS services ``may give
enterprises incentive to not enable any 911 dialing at all (which has
its own public safety implications).''
---------------------------------------------------------------------------
\3\ We clarify that our rules are not intended to prohibit
configuring MLTS to allow outbound-only calling. Rather, we
interpret the definition of MLTS to include outbound-only calling
systems.
---------------------------------------------------------------------------
[[Page 66723]]
53. We find that Congress's intent in enacting Kari's Law was to
require direct dialing for any MLTS phone that allows the user to call
911, regardless of whether the system also allows the PSAP to connect a
return call directly to the 911 caller. We agree with the Texas 9-1-1
Entities that Kari's Law and the ``utterly tragic circumstances''
behind its enactment demonstrate that ``it is simply unreasonable to
expect 9-1-1 callers to know or remember when they are required to do
something differently during a 9-1-1 call based on their particular
device or location.'' Moreover, as BRETSA states, calling 911 is
inherently an outbound service. As a result, it is counter-intuitive to
expect consumers to assume that they cannot reach 911 from such
services.
54. We decline to adopt Verizon's suggestion that we narrow the
requirements for outbound-only MLTS service to apply solely on the
basis of user expectations. Rather, we believe Congress intended for
direct 911 dialing and notification to be available for all outbound-
only MLTS services. Similarly, public safety commenters such as the
Texas 9-1-1 Entities and BRETSA point out that 911 callers in an
emergency should not have to slow down and analyze whether 911 is
available from a particular device, especially when they may not know
the particular technology involved and may not have chosen it for
themselves. Finally, although Verizon suggests that requiring direct
dialing capability for outbound-only MLTS services may give enterprises
incentive to not enable any 911 dialing at all, we do not believe this
possibility, which is speculative, outweighs the benefits of ensuring
that direct dialing is available with any MLTS phone that allows the
caller to reach 911.
55. Internal systems. Cisco asks the Commission to clarify that the
definition of MLTS excludes systems that are ``used only for internal
employee communications and . . . are not designed to interconnect with
the PSTN,'' such as internal messaging and data and video conference
capabilities that are ``increasingly displacing voice communications
for employee collaboration.'' Cisco states that ``[w]here a technology
is specifically deployed by an enterprise to support internal
communications (i.e., it cannot support a call outside the enterprise),
or where a tool is designed and used for conferencing services or other
non-point-to-point communications, there can be no reasonable
expectation on the part of employees that such internal or conferencing
tools would be used to summon emergency services.'' BRETSA responds
that limiting application of the rules to specific types of MLTS would
distort the market and that Kari's Law and RAY BAUM'S Act do not
support such a narrow reading of the definition of MLTS. Further,
BRETSA states that exempting internal communications systems from the
rules ``would appear to create a loophole such as to negate the
statutes and rules'' because an MLTS in which a user must dial a number
to access an outside line prior to placing a call to 911 would appear
to be an internal communications system.
56. We agree with Cisco that Kari's Law and the rules arising out
of RAY BAUM'S Act were not intended to apply to purely internal
communications systems that do not rely on telephone numbers under the
North American Numbering Plan. We clarify that a technology that is
specifically deployed by an enterprise to support only internal
communications and that does not connect to the public switched
telephone network would not fall within the definition of MLTS. In
response to BRETSA's concerns, we conclude that this will not distort
the market or negate the statute and rules because the clarification
applies only to systems that do not connect to the public switched
telephone network. If an internal communications system or conferencing
service connects to the public switched telephone network either on its
own or through a third party and can establish calls to the public
switched telephone network, including by dialing a prefix such as
``9,'' then it is within the definition of MLTS under our
interpretation.
57. System components. Panasonic, Cisco, and TIA also urge the
Commission to clarify that individual system components such as
telephone sets and control software do not qualify as an MLTS.
Panasonic states that Congress's use of the language ``system comprised
of'' various parts, ``e.g., common control units, telephone sets,
control software and hardware and adjunct systems,'' dictates as a
matter of logic that such individual parts are, in isolation, not MLTS
themselves. To hold otherwise, Panasonic states, would be to ignore the
plain meaning of the word ``comprised,'' effectively reading it out of
the statute. Panasonic adds that it may be uniquely situated in that
while the company offers a ``full-blown MLTS'' and is in that case an
MLTS manufacturer, it also sells IP phones to other parties, who bundle
Panasonic phones with other components that make up a full MLTS. To
address this situation, Panasonic states, the Commission should clarify
that sellers of individual MLTS components are not subject to the
Commission's rules for MLTS. Cisco asserts that ``[a]s a matter of
common sense, individual system components are not even capable of
dialing 911 or reaching the PSTN unless and until they are assembled by
an installer.''
58. We agree that the definition of MLTS refers to a system and
that individual components of such a system, including telephone sets,
control software and hardware, and adjunct systems, do not by
themselves constitute an MLTS. Consistent with this, we clarify that
manufacturers, importers, sellers, or lessors of individual MLTS
components are not subject to the Commission's MLTS rules to the extent
that they manufacture, import, sell, or lease such components without
the other components necessary for the system to function as an MLTS.
In the scenario described by Panasonic, the entity that bundles the
individual components into an MLTS would be the manufacturer and
presumably also the seller or lessor of the MLTS and would have the
obligations that fall on those parties under the statute and our
rules.\4\ However, we do not agree with Cisco that the test for whether
one or more components constitute an MLTS is whether they can be used
to dial 911 or reach the PSTN, as that would exclude all systems that
have been manufactured but not yet installed. Such a result would
clearly be at odds with Kari's Law, which places obligations on
``persons engaged in the business of manufacturing, importing, selling,
or leasing'' an MLTS that apply before installation, operation, or
management of the system.\5\
---------------------------------------------------------------------------
\4\ To the extent individual components need certain
functionality or pre-configuration to comply with Kari's Law, the
bundler should require that in its contract with the manufacturer.
The obligation to comply with the statute and our rules, however,
would lie with the bundler.
\5\ Specifically, such persons may not manufacture, import,
sell, lease, or offer to sell or lease an MLTS unless the system is
``pre-configured'' so that when properly installed, a user may
directly initiate a call to 911 from any station equipped with
dialing facilities.
---------------------------------------------------------------------------
b. Definition of Pre-Configured
59. The Commission proposed in the NPRM to define the statutory
term ``pre-configured'' to mean:
An MLTS that comes equipped with a default configuration or setting
that enables users to dial 911 directly as required under the
statute and rules, so long as the MLTS is installed and operated
properly. This does not preclude the inclusion of additional dialing
patterns to reach 911. However, if the system is configured with
these additional dialing patterns, they must be in addition to the
default direct dialing pattern.
[[Page 66724]]
60. The Commission stated that this would mean an MLTS may support
additional dialing patterns but that manufacturers (and importers,
sellers, or lessors) must ensure that the default, ``out-of-the-box''
configuration allows users to reach 911 directly.
61. Although some commenters agree with the Commission's proposed
definition of pre-configured, others ask the Commission to clarify the
proposed definition to acknowledge the role of the enterprise customer
and MLTS installer in providing the MLTS with connectivity to the PSTN.
62. We find that the revisions proposed by Cisco and Microsoft are
consistent with the statutory language and with the definition of
``pre-configured'' that the Commission proposed in the NPRM, and that
they assist in providing clarity. In particular, Cisco states that MLTS
manufacturers today can design systems that are capable of supporting
direct 911 dialing patterns and that are shipped with software that,
upon installation and configuration of the MLTS with PSTN connectivity,
can enable direct 911 dialing. However, MLTS solutions of this type
have no capability ``out of the box'' to make or complete a PSTN call,
including an emergency call.
63. Cisco adds that in today's market, ``MLTS manufacturers
predominantly offer enterprise solutions over distributed systems,
where the actual call control component of the solution need not be,
and often is not, resident in each enterprise location where MLTS-to-
PSTN calling takes place. PSTN connectivity, including the 911 dialing
pattern, is therefore established by the installer at the direction of
the enterprise, based on the unique attributes of its MLTS system, at
the time PSTN connectivity is configured.'' Cisco urges the Commission
to clarify that the pre-configuration requirement in the context of
distributed systems can be satisfied when a vendor includes software to
support a direct 911 dialing pattern, which is available to the
installer at the time the MLTS is configured for PSTN calling.
Specifically, Cisco proposes that the Commission ``slightly'' modify
the definition of pre-configured to read, ``An MLTS that comes equipped
with hardware and/or software capable of establishing a setting that
enables users to directly dial 911 as soon as the system is able to
initiate calls to the public switched telephone network, so long as the
MLTS is installed and operated properly.'' Microsoft similarly states
that many, if not most, MLTS capabilities in today's marketplace are
not available in a ``plug and play'' version and that the Commission
should revise the definition of pre-configured so that it ``recognizes
the responsibilities of the customer with respect to implementation and
provision of the service.'' Microsoft recommends that the Commission
revise the definition to read, `` `Pre-configured' means that the MLTS
comes equipped with a default configuration or setting that enables
users to dial 911 directly as required under the statute and rules, so
long as the system is installed and operated properly or, where no
default exists, such as when customer provisioning of the system is
required, enables the customer to configure the system to dial 911
directly as required under the statute and rules.''
64. We agree with these commenters that not all MLTS are ``out of
the box,'' plug-and-play solutions and that the definition of pre-
configured should recognize the role of the enterprise and installer
with respect to implementation and provision of service. We believe
that the proposed revisions suggested by Cisco and Microsoft are
fundamentally consistent with each other, and we note that no commenter
opposes these suggested revisions. In addition, Microsoft states that
it supports either version of the definition. Accordingly, we revise
the definition as requested by Cisco as follows:
`Pre-configured' means an MLTS that comes equipped with hardware
and/or software capable of establishing a setting that enables users
to directly dial 911 as soon as the system is able to initiate calls
to the public switched telephone network, so long as the MLTS is
installed and operated properly. This does not preclude the
inclusion of additional dialing patterns to reach 911. However, if
the system is configured with these additional dialing patterns,
they must be in addition to the default direct dialing pattern.
c. Definition of Configured
65. The Commission proposed in the NPRM to define the statutory
term ``configured'' to mean:
The settings or configurations for a particular MLTS
installation have been implemented so that the MLTS is fully capable
when installed of dialing 911 directly and providing notification as
required under the statute and rules. This does not preclude the
inclusion of additional dialing patterns to reach 911. However, if
the system is configured with these additional dialing patterns,
they must be in addition to the default direct dialing pattern.
The Commission also asked whether the difference between its
proposed definitions of ``pre-configured'' and ``configured'' was
sufficiently clear.
66. NASNA, Panasonic, and West Safety support the Commission's
proposed definition of configured. BRETSA notes that the reference to
``notification'' in the definition should be to ``MLTS notification,''
because that is the term as defined in the rules. BRETSA also proposes
line edits to specify that configuring an MLTS for direct dialing means
configuring it for ``direct dialing of 911 without a requirement of
first dialing or entering an additional digit, code, prefix, or post-
fix, including any trunk-access code such as the digit 9.''
67. We adopt the definition largely as proposed. We also agree with
BRETSA that the reference to notification should be corrected to ``MLTS
notification.'' \6\ But we decline to adopt BRETSA's other proposed
line edits as unnecessary. The definition already requires
configuration so that the MLTS is fully capable when installed of
dialing 911 directly ``as required under the statute and rules,'' which
includes dialing without a requirement of first dialing or entering an
additional digit, code, prefix, or post-fix, including any trunk-access
code such as the digit 9.\7\
---------------------------------------------------------------------------
\6\ Consistent with this, we also change a reference in section
9.16(b)(2) of the rules from configuring an MLTS to provide ``a
notification'' to configuring it to provide ``MLTS notification.''
\7\ RedSky states that the titles of the definitions of pre-
configure and configure are too broad and suggests changing them to
``Pre-configured MLTS'' and ``MLTS Configurations,'' respectively.
We decline to make these changes because we do not believe the
existing titles will cause confusion. In addition, our definitions
are intended to track the language used in Kari's Law as closely as
possible, and the statute and our implementing rules do not use the
terms ``pre-configured MLTS'' or ``configured MLTS.''
---------------------------------------------------------------------------
68. The revised definition of ``configured'' reads as follows:
The settings or configurations for a particular MLTS
installation have been implemented so that the MLTS is fully capable
when installed of dialing 911 directly and providing MLTS
notification, as required under the statute and rules. This does not
preclude the inclusion of additional dialing patterns to reach 911.
However, if the system is configured with these additional dialing
patterns, they must be in addition to the default direct dialing
pattern.
d. Definition of Improvement to the Hardware or Software of the System
69. Under Kari's Law, the notification requirements of the statute
apply only if the MLTS can be configured to provide notification
``without an improvement to the hardware or software of the system.''
The Commission proposed in the NPRM to define the statutory term
``improvement to the hardware or software of the system'' to mean:
An improvement to the hardware or software of the MLTS,
including upgrades to the core systems of the MLTS, as well as
[[Page 66725]]
substantial upgrades to the software and any software upgrades
requiring a significant purchase.
70. The Commission also noted that the proposed definition is
consistent with the legislative history of Kari's Law, which provides
that an improvement to the hardware or software of a system is intended
to include upgrades to the core systems of an MLTS and substantial
upgrades to the software, particularly those requiring a significant
purchase. The Commission asked whether there are types of routine
hardware or software changes that should be included in or excluded
from the definition and whether it should clarify that (1) improvements
to the hardware of the system do not include the provision of
additional extensions or lines, and (2) improvements to the software of
the system do not include minor software upgrades that are easily
achieved or made to improve the security of the system. In addition,
the Commission asked whether upgrades requiring a significant purchase
should be determined based on total cost alone, or whether it should
interpret significant to be a relative determination based on the size
of the entity making the purchase.
71. We adopt the definition of improvement to the hardware or
software of the system as proposed. Under this definition, enterprises
are not required to undertake ``upgrades to the core systems of an
MLTS,'' ``substantial upgrades to the software,'' or ``any software
upgrades that require a significant purchase'' in order to comply with
the notification obligation.
72. We find that this definition is necessary to implement Kari's
Law, which makes clear that the notification requirements of the
statute apply only if the MLTS can be configured to provide
notification ``without an improvement to the hardware or software of
the system.'' The definition we adopt also is consistent with the
legislative history of Kari's Law, which states Congress's intention to
balance the need for notification with the goal of ``not placing an
undue burden on MLTS owners or operators.''
73. While NCTA supports the Commission's approach to this
definition, others express concerns. Although RedSky objects to the
definition on the ground that the vast majority of deployed MLTS
systems can meet the notification requirements without any modification
of the core systems, NCTA points out that line-based MLTS cannot be
upgraded to offer notification without upgrades to core systems that
would present a ``daunting technological and financial challenge.'' In
this respect, NCTA states that MLTS are provided to commercial
customers in a variety of configurations involving both line-based and
trunk-based products and that it is not aware of any line-based systems
that currently have a notification capability.
74. We also disagree with NASNA that any improvements to an
existing MLTS, no matter how minor, should trigger the obligation to
comply with Kari's Law and the implementing regulations. We conclude
that such a policy would be inconsistent with the language of Kari's
Law, which limits application of the statute to MLTS manufactured or
brought into use after February 16, 2020. In addition, we clarify that
(1) improvements to the hardware of the system do not include the
provision of additional extensions or lines, and (2) improvements to
the software of the system do not include minor software upgrades that
are easily achieved or made to improve the security of the system.
75. With respect to upgrades, Panasonic requests that we further
clarify that substantial improvements to the software of the system do
not include software updates for addressing bug fixes, security
vulnerabilities, or the addition of ancillary features; that
maintenance or reconfiguration of the system to support new users or
extensions should not be considered a substantial upgrade; and that the
cost of the upgrade or update or the size of the enterprise should not
be a factor. RedSky asserts that the terms ``substantial'' and
``significant'' are subjective and ``should be quantified to ease in
both requirement and enforcement abilities.''
76. We believe the factors cited by Panasonic may be relevant to
determining whether a specific upgrade is substantial, but that such
factors, if applicable, should be evaluated in light of the total facts
and circumstances presented in the specific case. We also decline to
quantify the terms ``substantial'' and ``significant'' as requested by
RedSky, as the record does not provide sufficient basis for such
quantification at this time. We expect that as Kari's Law is
implemented, cases will arise that will enable us to provide further
guidance on these issues. For now, we conclude that the guidance
provided above is sufficient and consistent with the statutory language
and legislative history of Kari's Law.
e. Definition of Person Engaged in the Business of Manufacturing,
Importing, Selling, or Leasing an MLTS
77. Kari's Law applies to any ``person engaged in the business of
manufacturing, importing, selling, or leasing'' an MLTS and provides
that such persons may not manufacture or import an MLTS for use in the
United States, or sell or lease or offer to sell or lease an MLTS in
the United States, unless the system is pre-configured so that, when
properly installed, a user may directly initiate a call to 911 from any
station equipped with dialing facilities. In the NPRM, the Commission
tentatively concluded that the meaning of the term ``person engaged in
the business of manufacturing, importing, selling, or leasing'' an MLTS
is self-evident and did not propose to modify this definition or add it
to the rules. The Commission sought comment whether any additional
clarification of this term is necessary for implementation or
enforcement of Kari's Law.
78. As proposed in the NPRM, we conclude that the meaning of the
term ``person engaged in the business of manufacturing, importing,
selling, or leasing an MLTS'' is self-evident and that there is no need
to adopt a definition for it. Cisco and Panasonic agree that the
meaning of this term is self-evident, and no commenter opposes that
view.
f. Definition of Person Engaged in the Business of Installing an MLTS
79. Kari's Law also places obligations on any ``person engaged in
the business of installing, managing, or operating'' an MLTS. Such
persons may not install, manage, or operate the MLTS for use in the
United States unless it is configured for direct dialing of 911. In
addition, such persons shall, in installing, managing, or operating the
MLTS, configure it to provide notification if the system is able to be
configured to provide notification without an improvement to the
hardware or software of the system. In the NPRM, the Commission
proposed to define a person engaged in the business of installing an
MLTS as:
A person that configures the MLTS or performs other tasks
involved in getting the system ready to operate. These tasks may
include, but are not limited to, establishing the dialing pattern
for emergency calls, determining how calls will route to the Public
Switched Telephone Network (PSTN), and determining where the MLTS
will interface with the PSTN. These tasks are performed when the
system is initially installed, but they may also be performed on a
more or less regular basis by the MLTS operator as the
communications needs of the
[[Page 66726]]
enterprise change. The MLTS installer may be the MLTS manager or a
third party acting on behalf of the manager.
80. The Commission sought comment on this proposed definition.
While some commenters support the proposed definition, others ask the
Commission to clarify it.
81. We adopt the definition of ``person engaged in the business of
installing an MLTS'' as proposed. We decline to revise the language of
this definition as requested by some commenters because we conclude
that such revisions are not warranted; however, we supply guidance on
how to apply this definition given points raised by some commenters.
82. In this regard, RingCentral notes that although the NPRM
defines a ``person engaged in the business of installing an MLTS'' to
include a person who ``configures the MLTS or performs other tasks
involved in getting the system ready to operate,'' these functions are
often part of providing cloud-based MLTS. Accordingly, RingCentral
states, an over-broad definition of installation risks imposing duties
(such as configuring notification) that should rest with the MLTS
owner/operator as the entity best positioned to make deployment
decisions for the enterprise. According to RingCentral, the Commission
should address this by making clear that manufacturers and sellers are
not installers simply by virtue of providing systems; ``rather,
manufacturers and sellers become installers only when their customers
specifically retain them for installation by, for example, purchasing
installation or other professional services.'' In addition, RingCentral
states that the Commission should recognize that installers are acting
at the direction of owners and operators and should adjust the
responsibility for implementation of those directions accordingly.
83. We disagree with RingCentral that responsibility for
configuring or other tasks that fall within the definition of
installation should automatically rest with the owner/operator in some
circumstances, and we believe that a manufacturer of a hosted MLTS that
configures the system is serving in that respect as an installer.
Similarly, we note that some manufacturers provide systems with self-
installing software. In that event, the manufacturer is also performing
some of the functions of an installer. We agree, however, with
RingCentral that if an entity performs the functions of an installer at
the direction of the enterprise operator or manager, then the operator
or manager in that scenario is also serving as the installer.
Consistent with this approach, there may be multiple parties performing
installation functions for a single MLTS. An enterprise manager or
operator that directs aspects of the installation may, depending on the
degree of its involvement, be responsible for complying with the
installer's obligations. Evidence that the manufacturer has been
retained specifically to install the system could be relevant in
showing that the manufacturer is at least partly responsible for the
obligations of an installer under Kari's Law and our rules, but the
absence of such an agreement would not necessarily mean that the
manufacturer has not performed any installation functions.
84. Panasonic states that the definition of a ``person engaged in
the business of installing an MLTS'' should be limited to initial
installation and configuration of the system or substantial
improvement, ``lest over-long potential liability risk the exit of
skilled installers from the market.'' We decline to limit the
definition to initial installation and configuration of the system, as
Panasonic requests. Panasonic presents no data to support its
conclusion that this would lead to the exit of skilled installers from
the market.\8\
---------------------------------------------------------------------------
\8\ Comcast asks the Commission to make clear that in instances
where an MLTS provider installs a system that has been pre-
configured to be capable of transmitting direct-dialed 911 calls to
the appropriate PSAP, the installer has fulfilled its
responsibilities under Kari's Law and the implementing rules. We
decline to make this clarification because we believe the definition
of a person engaged in the business of installing an MLTS is
sufficiently clear with respect to the obligations of an installer.
In addition, we note that the installer's obligations may extend
beyond installing a system that has been ``pre-configured'' for
direct dialing of 911 and may include, for example, installing a
system capable of providing MLTS notification.
---------------------------------------------------------------------------
g. Definition of Person Engaged in the Business of Managing an MLTS;
Person Engaged in the Business of Operating an MLTS; Role of the
Enterprise Owner
85. The Commission proposed to define a person engaged in the
business of managing an MLTS as:
The entity that is responsible for controlling and overseeing
implementation of the MLTS after installation. These
responsibilities include determining how lines should be distributed
(including the adding or moving of lines), assigning and reassigning
telephone numbers, and ongoing network configuration.
The Commission proposed to interpret this definition to mean that a
user of MLTS services that does not own or lease the MLTS or exercise
any control over it would not be deemed to be engaged in the business
of managing the MLTS. Under this interpretation, an enterprise that
contracts with a third party to provide a total solution for MLTS,
including acquiring the MLTS equipment, configuring the system,
completing calls, and providing services such as maintenance and end
user support, would not be deemed to be engaged in the business of
managing the MLTS unless it exercised actual control over the system.
The Commission also proposed to define a person engaged in the business
of operating an MLTS as ``[a] person responsible for the day-to-day
operations of the MLTS.'' The Commission sought comment on these
proposed definitions.
86. In addition, the Commission sought comment on whether there are
circumstances in which the proposed definitions of MLTS ``manager'' or
``operator'' should extend to enterprise owners. The Commission noted
that commenters on the Enterprise Communications NOI emphasized that
some enterprise owners purchase, operate, and maintain their own on-
premises telephone systems with PBX equipment, while other enterprise
owners enter contractual arrangements with third-party providers of
network and hosted services. The Commission stated that it did not
believe Kari's Law was intended to extend liability to enterprise
owners that purchase MLTS services but do not exercise control over the
manner in which such services are configured or provided. Nevertheless,
the Commission stated, there may be instances where enterprise owners
purchase, operate, and maintain their own MLTS systems, or where they
exercise active control over the configuration and provision of MLTS by
third parties. The Commission sought comment on whether in such
instances enterprise owners should be deemed to be MLTS managers or
operators and what indicia of active control should be considered in
making this determination.
87. Commenters raise a number of issues with respect to the
proposed definitions of MLTS operator and manager. NASNA and West
Safety generally agree with the proposed definitions, while other
commenters seek changes to the definitions or ask the Commission to
clarify the role of the manager, operator, and enterprise owner.
88. We clarify the allocation of responsibility among the
installer, operator, manager, and enterprise owner in certain respects.
With these clarifications, we do not believe any changes are needed in
the wording of the definitions of person engaged in the business of
managing an MLTS and
[[Page 66727]]
person engaged in the business of operating an MLTS. Accordingly, we
adopt these definitions as proposed.
89. We are persuaded by the arguments of BRETSA, NASNA, and RedSky
that even a ``passive'' enterprise owner may perform some of the
functions of an MLTS installer, manager, or operator under our rules
and that the owner in that event should be responsible to the extent a
violation of the statute or rules results from that conduct. NASNA
states that an MLTS owner ``still has an obligation to hold its third-
party service provider(s) responsible for ensuring compliance.'' RedSky
similarly asserts that the Commission should not exclude passive owners
from the definition, stating that ``no MLTS user can be successful in a
vacuum. They have to provide their operational requirements to the MLTS
provider. These requirements can and must include direction to meet
appropriate regulatory requirements. It is incumbent on the MLTS
provider to ensure that the provided system or service is capable of
meeting these requirements.'' \9\ BRETSA states that the rules should
hold MLTS customers responsible for compliance to the extent the
customer installs, maintains, operates and/or configures the MLTS.\10\
---------------------------------------------------------------------------
\9\ RedSky also states that the term ``operator'' is not as
pertinent as the term and concept of provider and that the
Commission should introduce the terms ``MLTS provider'' and ``MLTS
user'' to capture the actual business environment. In addition,
RedSky suggests that the Commission replace the term ``person''
throughout the rules with the term ``person or entity.'' We decline
to use ``MLTS provider'' and ``MLTS user'' because those terms are
not used in Kari's Law, and our intent is for the rules to track the
language of the statute whenever possible. We decline to substitute
the term ``person or entity'' for the same reason; ``person'' is the
term used in Kari's Law. We also note that Kari's Law was codified
as part of Chapter 5 of the Act, and that Chapter 5 defines
``person'' to include ``an individual, partnership, association,
joint-stock company, trust, or corporation.''
\10\ BRETSA also states that MLTS providers with superior
knowledge of the rules will invariably include in their sales and
service agreements indemnification provisions that will undermine
the deterrent effect of penalties under the rules. To address this,
BRETSA urges the Commission to prohibit MLTS providers from
requiring customers to indemnify them against liability for rule
violations. We decline to prohibit providers from requiring
customers to indemnify them because we find that any conclusions
about the effect of such agreements on compliance with Kari's Law
and the implementing rules would be highly speculative at this time.
BRETSA also interprets the ``person engaged in the business of''
language to exclude a person that is engaged in a business unrelated
to the provision of configuration or operation of an MLTS but that
purchases or leases an MLTS for its use, and BRETSA proposed
revisions to bring such persons under the rules. We decline to adopt
these proposed revisions because we believe it is clear that Kari's
Law and the implementing rules apply to a person engaged in a
business unrelated to the operation of an MLTS that purchases or
leases an MLTS for its own use.
---------------------------------------------------------------------------
90. We agree with these commenters that an enterprise owner has an
obligation to hold third-party service providers responsible for
complying with Kari's Law and our rules. We clarify, however, that a
passive owner generally should not face liability if the owner
contracts with a responsible third party and includes compliance
requirements in its agreement with the service provider. We decline to
find that a hotel is not an installer, manager, or operator of MLTS
under the rules absent ``compelling evidence to the contrary,'' as AHLA
requests. AHLA states that hotels typically do not perform the
functions of an installer, manager, or operator. In that event, and
provided that the hotel contracts with responsible third parties and
includes compliance requirements in the agreements, the hotel should
not face potential liability under the statute or our rules.
91. Commenters also ask the Commission to clarify the allocation of
responsibility for complying with Kari's Law and the regulations in the
context of hosted, cloud-based MLTS service. AT&T asserts that any new
MLTS rules should clearly delineate the roles and responsibilities of
the various players in the MLTS ecosystem and that any single
stakeholder may play multiple roles in the MLTS ecosystem depending on
how an MLTS system is configured. ``For example, when AT&T offers a
hosted MLTS solution to a business, AT&T should be responsible for
compliance with the requirements applicable to those engaged in the
installing, managing, or operating MLTS. However, where AT&T offers a
Session Initiation Protocol . . . trunking solution to provide Public
Switched Telephone Network . . . access for call delivery and the
customer operates and manages the PBX, the customer should have
responsibility for compliance. In both cases, the manufacturer should
bear responsibility for ensuring its products are compliant.''
92. We conclude that whether a party is a manager, operator, or
installer should be based on the party's conduct and whether it has
performed activities that fall within the definition in our rules.
Consistent with this, we agree with AT&T that when it offers a hosted
MLTS solution to a business, it is responsible for compliance with the
requirements applicable to those engaged in installing, managing, or
operating an MLTS to the extent that its hosting service includes those
functions. On other hand, if AT&T offers a trunking solution that
provides public switched telephone network access with the customer
operating and managing the PBX, we agree that the customer should have
responsibility for compliance as an operator and/or manager.
93. RingCentral disagrees with AT&T's suggestion that hosted PBX
providers would be installers and managers and urges the Commission to
clarify that manufacturers and sellers are not installers or managers
simply by virtue of providing systems. RingCentral asserts that
``[p]roviders of hosted cloud-based PBX may simply provide the MLTS,
without installation or implementation of the system after
installation. . . . The definition of `manager' could . . .
inadvertently include a cloud-based MLTS provider, as the definition
includes a person who is involved in `implementation of the MLTS after
installation.''' We note that a manufacturer or seller would be deemed
an installer or manager only to the extent that it provides
installation or management services with respect to the system. We
offer these as illustrative examples for guidance on how the Commission
would apply the rule. Any determination of a particular party's
liability will necessarily require a fact-specific, case-by-case
inquiry. The parties' contractual arrangements may be relevant in this
determination, but they are not determinative, and an entity that
performs the functions of a manager in violation of a contractual
obligation not to do so could still be deemed a ``person engaged in the
business of managing an MLTS.''
94. Finally, we agree with commenters on the importance of the
enterprise owner/MLTS customer's involvement in some situations.
Commenters assert that the MLTS customer's involvement may be necessary
for compliance, including updating end user location information and
selecting an appropriate destination point for the 911 notification. As
INCOMPAS and NCTA point out, the owner/customer in such situations is
performing some of the functions of an MLTS operator or manager.
Specifically, INCOMPAS states that in most circumstances, the customer
or owner serves as the true operator of the system and exercises
considerable control over MLTS service provided by INCOMPAS members.
Once the system is installed and configured, the enterprise customer
controls the amount of information that flows to managers and operators
of these systems, including location information, and decides the
responsibilities for the parties involved. Where enterprise customers
have assumed primary operational roles with respect to the MLTS,
INCOMPAS urges the Commission to ``be careful not to attach liability
for violations of the rules to
[[Page 66728]]
providers that are only engaged in technical support or network
oversight.'' NCTA asserts that some MLTS networks--typically those that
use a customer-managed PBX--enable a customer to program or alter the
calling pattern of a MLTS. In those instances, NCTA urges the
Commission to assign sole responsibility for ensuring compliance with
Kari's Law to the customer, who would be ``engaged in the business of
managing an MLTS,'' rather than the voice service provider or equipment
installer. Comcast also points out that an enterprise owner may choose
to take on additional responsibilities with respect to the MLTS.
95. To the extent a violation of the statute or rules results from
failure of the enterprise owner/customer to perform these tasks
properly, the owner/customer will be responsible for that violation.
Consistent with this approach, we agree with NCTA and Comcast that if
the enterprise customer controls the routing of calls, the enterprise's
voice service provider has fulfilled its responsibilities under the
statute and regulations if it ensures that its service will not
interfere with the customer's ability to configure the MLTS to be
capable of transmitting direct-dialed calls to 911.
96. AT&T, RedSky, and USTelecom urge the Commission to clarify that
the MLTS installer, manager, or operator need only offer the central
notification capability to the customer to be in compliance with the
law. AT&T states that some customers may not wish to have central
notification if, for example, they have a small facility or they do not
have staff to support monitoring notifications at all hours, and ``the
MLTS provider should not be responsible for compelling the customer to
utilize a capability that the customer has judged unnecessary.''
USTelecom states that an enterprise customer may choose not to
designate or maintain a central notification point. We agree with these
commenters that a manager, operator, or installer should not be liable
if it performs its obligations in compliance with the statute and
rules, but the enterprise customer declines to use the services
offered.
4. Compliance Date and Transition Provisions
97. The effective date provision of Kari's Law states that the
statute ``shall apply with respect to a multi-line telephone system
that is manufactured, imported, offered for first sale or lease, first
sold or leased, or installed after'' February 16, 2020. In the NPRM,
the Commission proposed that the compliance date for regulations
implementing Kari's Law would be consistent with this date.
Accordingly, the proposed direct dialing and notification requirements
would apply to MLTS manufactured, imported, offered for first sale or
lease, first sold or leased, or installed after February 16, 2020. The
Commission sought comment on this proposed compliance date as well as
on alternatives, and stated that commenters offering alternatives
should explain how any date other than February 16, 2020, would be
consistent with the statutory language.
98. The Commission also sought comment on whether to adopt
transitional rules to inform consumers of the 911 capabilities of
legacy MLTS that are not subject to the direct dialing and notification
requirements of Kari's Law. The Commission noted, for example, that the
direct 911 dialing and notification statute enacted in Texas requires
enterprises to place a sticker adjacent to or on non-compliant MLTS
devices providing instructions on how to call 911, and that the
Commission's interconnected VoIP E911 rules require service providers
to distribute stickers or labels warning subscribers that E911 service
may be limited. The Commission sought comment on whether to require
MLTS installers, operators, and managers to notify callers how to dial
911 from legacy systems, as well as options for doing so, associated
costs, and potential sources of statutory authority for such
requirements.
99. Some commenters support the proposed compliance date of
February 16, 2020. Other commenters support an earlier compliance date.
The record also is divided on whether the Commission should adopt
transition rules, such as disclosure requirements, for legacy MLTS.
100. We adopt a compliance date of February 16, 2020, for the
regulations implementing Kari's Law. This is supported by commenters
such as West Safety, which asserts that the February 16, 2020,
compliance date will afford market participants ``sufficient advanced
notice to make informed manufacturing, planning, and purchasing
decisions and will give enterprises the proper level of financial and
operational flexibility to retain their existing, grandfathered MLTS
until end-of-life.''
101. We decline to adopt an earlier date because we find that the
February 16, 2020, date is consistent with the plain language of Kari's
Law, as well as with the intent of the statute. The statute applies
prospectively as new MLTS are brought into use after February 16, 2020,
or as existing systems are installed or first sold or leased after that
date. This indicates that Congress intended to balance the benefits of
requiring direct dialing before that date against the cost to
enterprises of having to implement these requirements with respect to
existing, legacy equipment currently in use. Commenters who urge the
Commission to adopt an earlier date do not address how that would be
consistent with the statutory language of Kari's Law.
102. With respect to transition obligations, Ad Hoc asserts that
the Commission has no statutory authorization to adopt transitional
rules for grandfathered MLTS equipment. Further, Ad Hoc urges the
Commission to refrain from ``impractical mandates'' for notification to
end users, such as stickers on equipment, also deeming them
``ineffective.'' AT&T similarly states that the Commission should not
require warning labels for grandfathered MLTS because many of these
systems have been in place for years, and requiring warning labels on
each of them would be ``incredibly disruptive to customers.'' Panasonic
states that the Commission should not impose specific employee
notification requirements on MLTS installers, operators, and managers
but should instead encourage ``voluntary, industry-led initiatives'' to
do so. TIA urges the Commission to launch a public education campaign
aimed at educating the public on the capabilities of legacy MLTS
equipment and, as part of this program, to take steps to ensure that
potential MLTS users are aware of their system's capabilities. NENA and
NASNA, on the other hand, urge the Commission to adopt disclosure
requirements for legacy MLTS. NENA asserts that it strongly supports
some form of conspicuous notification on any MLTS handset not in
compliance with the end-state Kari's Law implementation rules and that
it has enumerated model requirements for such notification in its Model
MLTS Legislation. NASNA states that the Commission should require MLTS
owners to place a sticker near or on non-compliant MLTS devices ``to
avoid situations such as the one that gave rise to Kari's Law in the
first place.''
103. We decline to require enterprises to notify end users of the
911 capabilities and limitations of MLTS that are not subject to the
statute and our rules. Such a requirement falls outside the scope of
Kari's Law and this proceeding to implement it. And even if we were
consider adopting such a requirement under other statutory authority,
neither the NPRM nor the record comment has addressed how the
[[Page 66729]]
benefits weigh against the costs of imposing such a requirement.
Instead, as Panasonic suggests, we encourage enterprises to disclose
the limitations on dialing 911 from such MLTS as part of voluntary best
practices.
104. AT&T and NASNA also raise the issue of what level of upgrades
to an existing MLTS would be significant enough to constitute
manufacture, importation, sale, lease, or installation triggering
compliance with Kari's Law when upgrades are made after February 16,
2020. AT&T states that upgrades unrelated to core MLTS functions in
legacy systems should not trigger the obligation to comply with Kari's
Law and the implementing rules. NASNA urges the Commission to ensure
that any improvements to MLTS hardware or software that an enterprise
makes in the future provide direct dialing and notification
capabilities, as well as the same dispatchable location information
that would be received by a PSAP.
105. On the basis of the record here, we decline to specify the
level of improvements to an existing MLTS that would trigger compliance
with the statute and regulations. We disagree with NASNA that any
improvements to an existing MLTS, no matter how minor, should trigger
the obligation to comply with Kari's Law and the implementing
regulations. We conclude that such a policy would be inconsistent with
the plain language of Kari's Law, which limits application of the
statute to MLTS manufactured or brought into use after February 16,
2020, and with our decisions about upgrades in the context of the
discussion above regarding the definition of ``improvement to the
hardware of software of the system.'' It is also unclear what would
constitute core MLTS functions in this context and exploring this issue
further and more broadly could add to the resources that will be
required to comply with the requirements of Kari's Law and our
implementing regulations. Thus, we believe it would be difficult to
answer this question in the abstract and more appropriate for the
Commission to address it in response to a specific fact pattern, should
one arise. Parties may file a request for a declaratory ruling to
eliminate uncertainty, and the Commission can resolve any uncertainty
in the marketplace as warranted.
5. Enforcement
106. Kari's Law empowers the Commission to enforce the statute
under Title V of the Act, ``except that section 501 applies only to the
extent that such section provides for the punishment of a fine.'' The
Commission sought comment in the NPRM on how it should enforce and
provide oversight of the requirements of Kari's Law. The Commission
also noted that there can be great variation in the business
relationships between MLTS installers, operators, and managers and
sought comment on who, or which entities, should bear responsibility
for violations of the proposed rules. In addition, the Commission
proposed to apply a presumption that the MLTS manager bears ultimate
responsibility for compliance with the rules implementing Kari's Law.
As an example, the Commission stated that if an MLTS fails to comply
with the rules, the MLTS manager would be presumed to be responsible
for that failure, at least in part, unless the manager can rebut that
presumption by demonstrating compliance with its obligations under the
statute and rules. The Commission sought comment on this proposal. The
Commission also asked how it should apportion liability in situations
where multiple parties may be responsible for compliance with the
statute and proposed rules, including whether there are situations in
which parties should be held jointly responsible.
107. As proposed, we adopt a rule that if an MLTS fails to comply
with the rules, the MLTS manager is presumed to be responsible for that
failure, at least in part, unless the manager can rebut the presumption
by demonstrating compliance with its obligations under the statute and
rules. Most commenters that address the issue support the proposal for
a presumption that the MLTS manager bears ultimate responsibility for
compliance with the rules implementing Kari's Law. INCOMPAS, for
instance, states that it supports the presumption because where
enterprise customers have assumed primary operational roles with
respect to the MLTS, ``the Commission needs to be careful not to attach
liability for violations of the rules to providers that are only
engaged in technical support or network oversight.''
108. Verizon, on the other hand, asserts that the Commission should
not adopt the presumption because it would not reflect the variety of
contractual arrangements that can allocate implementation and system
maintenance duties among installers, operators, managers, and
enterprise customers. Instead, Verizon asserts, the Commission should
assess compliance ``based on how the contractual arrangements allocate
the respective responsibilities.'' We disagree that the presumption
would be inconsistent with such multi-party contractual arrangements.
We intend to have a case-by-case determination of who is ``engaged in
the business of managing'' the MLTS (including by looking at the
parties' contracts) before imposing liability. The party or parties
that managed the MLTS would then have the burden of going forward with
evidence to show that they met their obligations under the statute and
rules.
109. We decline to adopt the proposals of RedSky and Avaya for
apportioning liability in situations where multiple parties may be
responsible for compliance. RedSky states that if the MLTS manufacturer
does not provide a system that can meet the requirements, it should
bear 100% of the responsibility; if the MLTS manufacturer provides a
system that can meet the requirements and the operator chooses not to
offer the required services, the operator should bear 100% of the
responsibility; and if the manufacturer and the operator offer to meet
the required services, then the MLTS end user should bear 100% of the
responsibility. Avaya asserts that the MLTS operator ultimately should
be responsible for compliance and that if services are subcontracted,
the operator must ensure that the subcontractor implements compliant
technologies and should remain primarily responsible for compliance. Ad
Hoc responds that the proposals of RedSky and Avaya would amount to a
presumption that the operator is liable in certain circumstances and
that the Commission should ``reject this premature, overzealous and
ineffective approach to enforcement of any rules it may adopt in this
proceeding.'' Instead, we believe a case-by-case assessment of
liability based on the facts specific to the particular investigation
is the most appropriate way to enforce Kari's Law and our rules.\11\
---------------------------------------------------------------------------
\11\ The Florida Bureau of Public Safety urges the Commission to
adopt a tiered approach to the enforcement of violations of Kari's
law under which first time offenders would receive a warning ``with
a strict but reasonable time frame to correct any deficiencies and
with an appropriate penalty if the violation is not corrected.'' We
decline to adopt this proposal because we believe it would be
inappropriate to limit the Commission's enforcement discretion in
this manner.
---------------------------------------------------------------------------
110. We also decline to establish the safe harbor suggested by
INCOMPAS. INCOMPAS asserts that if a manufacturer furnishes an MLTS
with appropriate functionality, and an installer configures a system
capable of direct dialing, alert notification, and sending dispatchable
location information, then the Commission should provide a ``safe
harbor for these parties in the service chain from liability if and
when properly installed MLTS are not ultimately used properly.''
Panasonic and TIA state that
[[Page 66730]]
equipment manufacturers should not be liable for noncompliance of an
MLTS manager with Commission rules unless the reason for the
noncompliance is the design of the MLTS equipment. A manager, an
operator, or an installer would not be liable if it performs its
obligations in compliance with the statute and rules, but the
enterprise customer declines to use the services offered. The same
principle would apply to MLTS manufacturers, importers, sellers, and
lessors; if the manufacturer, importer, seller, or lessor satisfies its
obligations under the statute and rules, but the enterprise declines to
use the system properly, then the manufacturer, importer, seller, or
lessor should not be liable for the resulting noncompliance.
Determinations of responsibility among multiple parties will
necessarily be fact-specific, and we do not believe a safe harbor is
appropriate or needed.
111. We also decline to exclude equipment manufacturers from
liability for the noncompliance of an MLTS manager unless the
noncompliance results from the equipment's design, as Panasonic and TIA
request. We find that the manufacturer's obligations and potential
liability under Kari's Law and our rules are sufficiently clear and
that the enforcement approach Panasonic and TIA propose is not needed.
Further, Kari's Law and our rules do not reference the ``design'' of an
MLTS, and we believe doing so would introduce ambiguity into the
enforcement process.
6. Complaint Mechanisms
112. In the NPRM, the Commission stated that it envisioned relying
on existing Commission complaint mechanisms to facilitate the filing of
complaints for potential violations of Kari's Law. For example, the
Commission stated, PSAPs and the public could report problems via the
Public Safety and Homeland Security Bureau's Public Safety Support
Center or the Commission's Consumer Complaint Center.
113. We conclude that our existing complaint mechanisms should be
sufficient for addressing potential violations of Kari's Law. Several
commenters assert that the Commission's existing mechanisms are
sufficient for the filing of complaints for potential violations of
Kari's Law. We also provide that persons alleging a violation of the
rules implementing Kari's Law may file a complaint under the procedures
set forth in part 1, subpart E of our rules.
114. We also decline to establish procedures similar to those used
for accessibility complaints under the Twenty-First Century
Communications and Video Accessibility Act (CVAA) and section 255 of
the Act. Panasonic and TIA urge the Commission to consider establishing
a mechanism similar to that used for accessibility complaints under the
CVAA or section 255 of the Act, including a mechanism for giving MLTS
manufacturers, installers, operators, and managers an opportunity to
resolve complaints informally before the Commission undertakes any
enforcement action. Although the CVAA includes a provision directing
the Commission to establish procedures for complaints and enforcement
actions arising out of violation of certain accessibility requirements,
Kari's Law does not include a corresponding provision. In addition, the
Public Safety Support Center and Consumer Complaint Center procedures
are flexible enough to provide an opportunity for informal resolution
of complaints prior to enforcement should the Commission determine that
such an opportunity would be appropriate.
115. BRETSA urges the Commission to establish a separate mechanism
for PSAPs to report MLTS noncompliance. We decline to do so, given that
the Public Safety Support Center process will be sufficient for this
purpose.
7. Preemption of State Law
116. The preemption provision of Kari's Law states that ``[n]othing
in this section is intended to alter the authority of State commissions
or other State or local agencies with jurisdiction over emergency
communications, if the exercise of such authority is not inconsistent
with this chapter.'' Commenters sought guidance, however, regarding the
general effects of this provision on state and local law.
117. Specifically, AT&T and BRETSA ask the Commission to clarify
the effect of Kari's Law on state laws affecting 911 service for MLTS.
AT&T urges the Commission to clarify how any new federal MLTS
requirements will operate ``vis-[agrave]-vis additional, and sometimes
conflicting, state MLTS requirements.'' AT&T, however, does not provide
specific examples of any state requirements that appear to have the
potential for conflicting with federal regulations implementing Kari's
Law. BRETSA asks the Commission to find that state laws requiring
existing MLTS systems to provide direct dialing, on-site notification,
and interior location information are not inconsistent with Kari's Law,
RAY BAUM'S Act, or the Commission's proposed rules. BRETSA, however,
does not cite any such state laws, or even assert that any such laws
exist. In addition, BRETSA asserts that federal rules implementing
Kari's Law may establish grounds for civil claims and liability under
state common law and statutes and urges the Commission not to limit a
state's authority to ``determine civil liability or presumptions
thereof, and any immunities therefrom, and any penalties for violation
arising from violation of state MLTS 9-1-1 obligations.'' NARUC notes
that it has adopted a resolution suggesting that any federal rules on
MLTS direct dialing and notification ``should be written to permit
States to impose additional requirements `presuming that such
additional requirements do not contradict or conflict with federal
requirements.' '' NARUC's resolution does not supply specific examples,
however.
118. As mentioned above, our objectives in the context of this
broader rulemaking are to prescribe rules and regulations that we find
are necessary to carry out Kari's Law, and to provide additional
clarity and specificity regarding some of the terms used in the statute
and the obligations placed on covered entities. We chose, in our
discretion, to proceed incrementally, and thus did not propose to offer
interpretations or rules going to the preemption provision of Kari's
Law. Thus, at this time, and based on the record in this proceeding, we
decline to provide guidance on the general effect of Kari's Law and our
implementing regulations on individual state and local laws or on the
``exercise of . . . authority'' of a state's or locality's
``jurisdiction'' over ``emergency communications'' under a hypothetical
set of facts. The record does not reflect specific examples (or even
sufficient indication of a widespread problem) of state or local
exercise of jurisdiction that may be inconsistent with the federal
regulatory regime.
119. In addition, BRETSA asserts that waiver is an essential
element of a regulatory scheme and asks the Commission to clarify that
state or local public safety agencies and officials have authority to
grant waivers of the federal MLTS 911 rules ``upon finding that
alternative deadlines and arrangements better serve the public safety
or will avoid undue financial hardship.'' BRETSA also asserts that
state and local public safety officials and agencies should have the
opportunity to impose conditions on waivers, such as training
requirements for enterprise personnel or contractors. We decline to
find that state and local public safety authorities have authority to
waive the Commission's MLTS rules, as BRETSA requests, or to
[[Page 66731]]
impose conditions on such waivers. Requests for such waivers should, as
with other Commission requirements, be presented to the Commission,
while requests for waivers of state and local requirements should be
presented to the appropriate state or local governmental entity.
8. Equipment Authorization Rules
120. The Commission also sought comment in the NPRM on whether to
modify the equipment authorization rules as they apply to MLTS
equipment manufactured after February 16, 2020. In addition, the
Commission asked whether MLTS applications for equipment authorization
under parts 2, 15, or 68 should constitute a representation that such
equipment complies with MLTS 911 requirements.
121. Commenters largely support using existing equipment
authorization rules. While NPSTC recommends that the Commission
implement a formal process for compliance with the provisions of Kari's
Law as part of an equipment authorization process, other commenters
state that a formal process would be unworkable because many MLTS
products are software-based solutions that need to be configured and
installed on premises. Panasonic and TIA also assert that any modified
equipment authorization rules would apply only to hardware-based
solutions and that this would constitute an unequal burden on such
solutions.
122. We decline to amend our equipment authorization procedures
because we conclude that the existing equipment authorization
procedures are sufficient. The MLTS marketplace represents a broad
range of technologies that are continuing to evolve from more
traditional, circuit-based solutions to wireless, cloud-based, and VoIP
solutions, and we seek to ensure that our rules preserve flexibility
and maintain technological neutrality.
9. Voluntary Best Practices
123. The Commission in the NPRM asked commenters to identify
voluntary best practices that can improve the effectiveness of direct
dialing and notification for MLTS. The Commission noted, for example,
that the Michigan State 911 Committee encourages MLTS operators to work
directly with local public safety entities to ensure compliance and
``strongly recommend[s] that every MLTS operator work with their local
911 system manager/director to test the ability to dial 911 from the
station lines associated with MLTS systems any time an MLTS has been
installed or upgraded.'' The Commission sought comment on this and
other recommended or potential best practices that would help
enterprises ensure the effectiveness of direct dialing and
notification, including best practices for training on-site emergency
personnel and others responsible for the implementation of direct
dialing and notification. Commenters that address this issue generally
encourage the development of voluntary best practices for direct
dialing and notification under Kari's Law.
124. We encourage industry and the public safety community to work
together to develop voluntary best practices that will help enterprises
facilitate first responder access and minimize delays to response. NENA
states that ``[r]ecognizing the diversity in enterprise IT staffing . .
. means all players in the MLTS 9-1-1 space--including manufacturers,
sellers, and 9-1-1--should contribute to education and development of
best practices for MLTS operation.'' Cisco and BRETSA note the need for
development of a standard testing protocol that would be employed when
installers configure MLTS for 911, which we believe may be helpful. TIA
states that efforts are underway to create a working group with members
from industry and public safety to develop best practices and standards
regarding Kari's Law requirements and the dispatchable location mandate
under RAY BAUM'S Act. Several commenters also emphasize the need for a
public awareness or education campaign for entities affected by the new
rules. As noted above, we also believe it may be helpful for this
effort to include guidance on disclosing the limitations of 911 dialing
from legacy MLTS equipment.
125. Some commenters make suggestions we believe are more
appropriate for inclusion in voluntary best practices. BRETSA suggests
that the Commission require MLTS providers to supply a copy of the
rules to each customer. NENA asserts that although MLTS operators and
managers are generally in the best position to maintain the unique
registered locations of their MLTS, vendors and manufacturers ``must
bear some responsibility to (1) encourage accurate and regular update
of location information, and (2) provide means to alert operators and
managers when registered location information has become out-of-date or
hardware has been moved.'' We decline to require these practices, but
we encourage industry and public safety entities to consider them in
the development of best practices.
126. We also agree with commenters about the importance of public
outreach, and we intend to quickly develop and disseminate
informational materials and to collaborate on outreach with our
federal, state, and local partners, the public safety community, and
industry.
10. Comparison of Benefits and Costs
127. The Commission sought comment on the costs and benefits of
satisfying its proposed direct dialing and notification rules for MLTS
coming into service after February 16, 2020. The Commission asked
whether there are alternative methods of meeting the requirements of
Kari's Law that would reduce costs and/or increase benefits and whether
there are any barriers for those wishing to replace their MLTS after
this date that would be costly to overcome. The Commission also
requested comment on the expected lifespan of existing MLTS that are
not currently able to meet the requirements of the proposed rules, the
prevalence of such systems today, and the expected prevalence of such
systems in 2020. In addition, the Commission sought comment on the cost
of upgrading to an MLTS that supports the requirements of the proposed
rules. The Commission noted that ``[b]ecause most of the currently
deployed MLTS are capable of being configured to meet the requirements
of our rules today, without improvement to the hardware or software of
the system, we tentatively conclude that our rules will impose no
incremental costs to those who replace their MLTS as they come to the
end of their useful life.'' Accordingly, the Commission sought comment
on this tentative conclusion.
128. Regarding notification, the Commission sought comment on its
tentative conclusion that the costs of implementing its proposed
requirements will not exceed the value of their benefits. The
Commission also sought comment on any particular costs involved in
imposing the notification requirement and alternative methods
consistent with Kari's Law that may reduce costs and/or improve
benefits. Further, the Commission sought comment on the costs and
benefits associated with its proposed definitions. The Commission also
asked for comment on the benefits and costs associated with any
additional notification requirements the Commission might adopt, such
as requiring operators of legacy MLTS to inform consumers of the 911
capabilities of those systems.
129. Some commenters support the Commission's tentative
conclusions.
[[Page 66732]]
West Safety states that the proposed rules also appropriately balance
the benefits and costs of implementation of direct dialing and
notification by setting a compliance date of February 16, 2020,
consistent with Kari's Law. West Safety asserts that ``direct access to
9-1-1 without a dialing prefix can typically be implemented by
appropriate configurations to MLTS of all types at little or no cost to
the enterprise.'' West Safety also states that notification
functionality is available natively in most MLTS equipment or can be
supported via a third-party application. Accordingly, West Safety
asserts, ``the cost of implementation is minimal, whereas the benefits
of closing this regulatory gap are significant.'' Moreover, by adopting
a prospective compliance date that applies only to MLTS offered for
first sale after February 16, 2020, West Safety submits that ``market
participants will be afforded sufficient advanced notice to make
informed manufacturing, planning and purchasing decisions, and
enterprises will have the proper level of financial and operational
flexibility to retain their existing, grandfathered MLTS until end-of-
life.'' Regarding alternative methods of meeting the requirements of
Kari's Law that would reduce costs and/or increase benefits, RedSky
states that it offers a no-cost notification service when its call
routing service is used. RedSky also states that for those wishing to
replace their MLTS after February 16, 2020, ``[t]he cost with or
without support to meet the requirements of the Rule should be
equivalent.'' RedSky believes that the vast majority of existing MLTS
can meet the requirements of the rule without significant modification.
130. Other commenters generally agree with the Commission's
proposals, but advocate that the Commission take a more measured
approach towards adopting rules implementing Kari's Law than that
suggested in the NPRM. To illustrate, Ad Hoc advises that as the
Commission ``considers how best to implement the statutory mandates of
Kari's Law and section 506 of RAY BAUM's Act, the Commission should
strictly adhere to its `light touch' regulatory philosophy.'' Regarding
notification, for example, Ad Hoc urges the Commission to avoid
imposing detailed requirements beyond the proposed rule and to refrain
from imposing transitional requirements on legacy MLTS.
131. The rules we adopt today to implement the direct dialing and
notification requirements of Kari's Law balance the needs of
stakeholders and maximize many public safety benefits. These benefits
include potentially preventing fatalities, injuries, or property
damage, improving emergency response time and access to emergency
services, reducing delays in locating 911 callers, narrowing the gap
between MLTS 911 service capabilities relative to other communications
services subject to 911 requirements, driving further technology
development, and lowering the cost of 911 solutions for MLTS. The
record developed in response to the NPRM confirms that many existing,
installed MLTS support direct dialing to 911 and notification. Further,
the record developed in response to the 2017 Enterprise Communications
NOI suggests that direct dialing and notification rules will impose no
incremental costs to those replacing their MLTS at the end of its
useful life. Because Congress mandated compliance with its direct
dialing and notification requirements after February 16, 2020, and
expressly grandfathered MLTS systems in service before that date,
Congress has already crafted a balance of costs and benefits with
respect to compliance to which the Commission is bound. Further, when
Congress adopted Kari's Law, it contemplated that the requirements
would evolve with advancements in MLTS technology. The record in this
proceeding reflects that the modern enterprise communications ecosystem
is complex and that legacy TDM-based technology is evolving towards an
IP-based MLTS environment.
132. As Congress has specifically legislated to create this
framework and identified areas in which the Commission shall enforce
the statute, Congress has already assessed the benefits of its
requirements. In the NPRM, the Commission observed that a Congressional
Budget Office analysis concluded that most MLTS systems already are
configured to meet the direct dialing and notification requirements of
Kari's Law. In evaluating the Senate and House versions of Kari's Law,
Cisco stated that it was not aware of any technological barriers to the
implementation of Kari's Law as applied to MLTS. In the NPRM, the
Commission cited eight states and some local governments that already
have laws requiring direct dialing for 911 from MLTS. For these state
and local jurisdictions, the Commission noted that its proposed rules
would generally not affect the status quo and so would likely have
little to no impact from a cost perspective. Moreover, the Commission
observed that the existence of state-level requirements has already
driven the manufacture of MLTS equipment that supports 911 direct
dialing, much of which may have been marketed and sold in jurisdictions
that do not have state or local requirements.
133. In this analysis, we address whether our rules achieve the
benefits of Kari's Law in a cost-effective manner. The record supports
adopting implementing regulations of Kari's Law and the Commission's
conclusion in the NPRM that these rules are necessary to provide
additional clarity and specificity regarding the terms used in the
statute and the obligations placed on covered entities. As demonstrated
by commenters, implementing regulations can provide important guidance
to covered entities on complying with the law and the mechanism the
Commission will use to enforce the statute. Accordingly, our rules
include definitions of some of the terms in Kari's Law, as well as
other provisions to clarify the obligations of entities regulated under
the statute. The rules we adopt today generally track the statutory
requirements of Kari's Law, are technologically neutral, and leverage
advances in technology to improve access to emergency services as
envisioned by Congress. The flexibility and minimum criteria we
establish for direct dialing and notification should offset any
potential burdens associated with compliance with our rules. Therefore,
we conclude that there will be no immediate costs associated with
meeting the requirements of our rules and that the amount of
flexibility and lead time for compliance will help to minimize future
potential costs.
134. The Commission also sought comment on the cost and expected
benefit of the options proposed in the NPRM for implementing the
notification requirement of Kari's Law, including whether to specify
staffing requirements for the notification point. The Commission noted
that while some state MLTS statutes include notification requirements,
these statutes either expressly provide that the enterprise does not
have to make a person available to receive a notification, or they are
silent on whether the destination point must be staffed. The Commission
stated that it did ``not believe Congress intended to impose staffing
or monitoring requirements that would impose unreasonable costs or
limit the flexibility of MLTS installers, managers, and operators to
develop efficient and cost-effective notification solutions that are
appropriate for the technology they use, such as visual alerts on
monitors, audible alarms, text messages, and/or email.'' Rather than
requiring staffing or monitoring, the Commission believed ``that
allowing
[[Page 66733]]
notifications to be directed to the points where they are likely to be
seen or heard by existing staff achieves these goals at a negligible
cost above what an MLTS manager would already spend when purchasing an
MLTS.''
135. The record supports the Commission's view that Congress did
not intend to impose burdensome staffing or monitoring requirements
that would impose unreasonable costs or limit the flexibility of MLTS
installers, managers, and operators to develop efficient and cost-
effective notification solutions. The record supports setting minimum
criteria for the notification to maximize benefits but also providing
enterprises significant flexibility to tailor notifications to meet
their specific needs. Similarly, the record supports adopting a
requirement that notifications be sent to a location on-site or off-
site where someone is likely to hear or see the notification, but not
requiring that enterprise staff or monitor the notification point at
all times. Additionally, the record suggests that the Commission's
definition of ``improvements to the hardware or software of the
system'' strikes the right balance to ensure that enterprises will not
incur significant costs or core system upgrades in connection with
providing notification, as provided under Kari's Law.
136. Taken together, the notification requirements we adopt today
establish the necessary conditions that will make it more likely than
not that 911 callers using an MLTS upgraded or placed into service
after February 16, 2020, will benefit from the notification provisions
of Kari's Law at a negligible cost above what an MLTS manager or owner
would already spend when purchasing or upgrading an MLTS. In sum, the
record suggests that establishing some minimum criteria represents a
cost-effective means to reasonably ensure that notification will be
timely received by a person with authority to act on it while balancing
the needs of stakeholders, maintaining technological neutrality,
preserving flexibility for enterprises, and minimizing burdens
associated with implementing the notification requirement of Kari's
Law.
B. Dispatchable Location for MLTS and Other 911-Capable Communications
Services
137. RAY BAUM'S Act directs us to consider rules requiring the
conveyance of dispatchable location with 911 calls ``regardless of the
technological platform used.'' Based on this directive, we adopt
dispatchable location requirements for MLTS and other 911-capable
services that do not have such requirements, including fixed telephony,
interconnected VoIP service, Telecommunications Relay Services (TRS),
and mobile text.
1. MLTS
138. In the NPRM, the Commission observed that when a 911 call is
placed in an MLTS environment, the system may provide the PSAP with the
location of a main entrance or administrative office rather than the
location of the caller, which can lead to delays in locating the caller
and result in injury or loss of life. By directing the Commission ``to
consider adopting rules to ensure that the dispatchable location is
conveyed with a 9-1-1 call . . . including with calls from multi-line
telephone systems,'' Congress in RAY BAUM'S Act signaled its intent
that the Commission focus on ensuring highly precise location
information whenever feasible in connection with MLTS 911 calls.
139. In the NPRM, the Commission proposed to proscribe the
manufacture, import, sale, or leasing of MLTS in the United States
unless the system is pre-configured such that, when properly installed,
the dispatchable location of the caller will be conveyed to the PSAP
with 911 calls. The Commission further proposed to proscribe the
installation, management, or operation of MLTS in the United States
unless the system is configured such that the dispatchable location of
the caller will be conveyed to the PSAP with 911 calls. The NPRM
proposed to apply these requirements to the same entities subject to
Kari's Law. We adopt these proposals with certain modifications.
a. Definition of Dispatchable Location
140. Section 506 of RAY BAUM'S Act defines ``dispatchable
location'' as ``the street address of the calling party, and additional
information such as room number, floor number, or similar information
necessary to adequately identify the location of the calling party.''
In the NPRM, the Commission noted the substantial similarity of this
statutory definition to the definition of ``dispatchable location'' in
the Commission's wireless E911 location accuracy rules. The Commission
proposed to construe the definitions as functionally identical, aside
from the specification of the technological platform to which each
definition applies. The Commission also sought comment on whether to
further define ``additional information'' that may be necessary to
``adequately identify the location of the calling party.'' Finally, the
Commission noted that the wireless E911 definition of dispatchable
location requires street address information to be validated, and asked
whether validation should similarly be required for dispatchable
location information associated with MLTS 911 calls.
141. We adopt the definition of dispatchable location proposed in
the NPRM, without further specifying the types of location information
that may be required to locate callers in specific instances. We also
require that to meet the definition of dispatchable location for MLTS
911 calls (and for calls from other platforms discussed in succeeding
sections below), street address information must be validated. We agree
with commenters that the definition of dispatchable location needs to
be both functional and flexible. As APCO states, ``[d]ispatchable
location is well understood by public safety communications
professionals to mean information sufficient for guiding first
responders to the right door to kick down.'' However, what constitutes
``sufficient'' information will vary significantly depending on the
environment from which a 911 call originates. For calls placed from
multi-story buildings or campus environments, first responders will
typically require specific floor and room information, in addition to
the street address of the building. For calls placed from many small
businesses, on the other hand, a street address alone may provide first
responders all the information they need to quickly locate the caller.
142. Accordingly, the definition of dispatchable location that we
adopt today gives participants in the MLTS marketplace flexibility in
deciding what level of detail should be included in the location
information provided to PSAPs for particular environments, so long as
the level of detail is functionally sufficient to enable first
responders to identify the location of a 911 caller in that
environment. Given the diverse and evolving nature of the MLTS market
and the breadth of enterprise environments at issue in this proceeding,
we decline to expand upon the statutory definition in specifying
instances in which ``additional information'' beyond street address
must be made available, or in identifying specific categories of
additional location information beyond floor level or room number.
143. We also conclude that the definition of dispatchable location
for MLTS 911 calls should include a requirement that street addresses
be validated. The majority of commenters who addressed this issue
indicate that such validation is essential to ensure that a location is
sufficiently reliable for dispatch of first responders.
[[Page 66734]]
Commenters also state that street address validation is feasible and
can be implemented by MLTS managers and operators without incurring
significant costs. NENA states that MLTS managers or operators have
``numerous methods'' for validating addresses against databases like
the Master Street Address Guide or databases that support the Location
Validation Function in the NG911 environment. Finally, including street
address validation in our dispatchable location definition for MLTS and
other services covered by this order establishes parity with the
dispatchable location definition in our wireless E911 rules and renders
the two definitions functionally identical.
144. Cisco and ATIS express concern about the cost and feasibility
of validation requirements imposed on large enterprises if validation
beyond street address or building level is required. We emphasize that
our adopted definition of dispatchable location--as in the case of our
wireless rules--only references validation of street address
information. While we encourage the development of solutions that will
support validation of more granular location information than street
address, including floor and room number, we agree with commenters who
caution against imposing overly prescriptive requirements at this time
that could inhibit the development of innovative solutions.
b. MLTS Provision of Dispatchable Location or Alternative Location
Information
145. In the NPRM, the Commission ``tentatively conclude[d] that it
is feasible for 911 calls that originate from a MLTS to convey
dispatchable location to the appropriate PSAP.'' The Commission based
this tentative conclusion on the record in the Enterprise
Communications NOI proceeding, in which several commenters stated that
they already offered methods for dynamically determining and conveying
an MLTS end user's location. The Commission also noted the potential
availability of dispatchable location solutions that require the
customer to identify their own location and solutions that calculate a
location by leveraging data available from the 911 caller's device and
the network. The Commission sought comment on this tentative conclusion
and on the range of potential approaches to providing dispatchable
location. The Commission also sought comment on whether a MLTS that
handles calls initiated by remote users, e.g., off-site workers, should
be required to convey location information about remote users.
146. The Commission noted that there may be instances where
location information that does not meet the definition of dispatchable
location could still be useful to PSAPs and first responders, either as
supplemental information to validate the dispatchable location or as an
alternative in instances where dispatchable location information is not
available. The Commission stated its belief that ``our rules and
policies should not preclude--and in fact should allow and encourage--
potential alternatives to dispatchable location.'' The Commission asked
whether other types of location information (for example, x/y/z
coordinates) could be conveyed with a 911 call originating from an
MLTS. Finally, the Commission proposed to require implementation of
dispatchable location requirements for MLTS systems by February 16,
2020, the same as the implementation date for the requirements of
Kari's Law.
147. Numerous commenters address the issue of MLTS dispatchable
location, expressing a variety of viewpoints. Some commenters agree
with the Commission's tentative conclusion that it is feasible to
provide dispatchable location with MLTS 911 calls, and state that they
are already capable of providing highly specific real-time location
information for MLTS users. Other commenters, however, contend that
while dispatchable location may be feasible for some MLTS 911 calls, it
is not feasible in all cases, and that attempting to impose ``one-size-
fits-all'' dispatchable location requirements on all MLTS would be
unworkable.
148. Because the MLTS marketplace serves an enormous range of
enterprise environments and includes systems that vary greatly in size,
scope, and technological capability, we agree with commenters that our
approach must take this variety into account.\12\ In this regard, the
comments suggest that the feasibility of providing dispatchable
location for an MLTS 911 call, and the means available to provide it,
vary significantly depending on whether the call is from a fixed or
non-fixed device \13\ and, in the case of non-fixed devices, whether
the device is being used on or off the enterprise premises. Cisco
points out that ``dispatchable location is more supportable from on-
premises fixed or `hardwired' MLTS stations (such as desk phones), more
challenging for on-premises mobile clients (such as softphones), and
even more difficult, if not impossible, for off-premises softphones
using public internet or Virtual Private Network connections.'' We find
this assessment to provide a useful framework for addressing MLTS
location issues. Therefore, in the discussion below, we separately
address dispatchable location requirements for MLTS 911 calls from
fixed devices, non-fixed devices being used on-premises, and non-fixed
devices being used off-premises.
---------------------------------------------------------------------------
\12\ We agree with Avaya that service providers may use any
technology that delivers dispatchable location, including any
technology that complies with NENA i3 specifications.
\13\ For purposes of this proceeding, we define ``fixed'' MLTS
devices as devices that connect to a single end point (e.g., a desk
or office phone) and are not capable of being moved to another
endpoint by the end user, although they may be capable of being
moved to a different endpoint by a professional installer or network
manager. ``Non-fixed'' MLTS devices are devices that the end user
can move from one endpoint to another without assistance.
---------------------------------------------------------------------------
(i) Fixed MLTS Calls
149. Commenters generally agree that providing dispatchable
location of fixed devices presents the easiest use case for MLTS
providers. Where MLTS calls originate from fixed devices such as hotel
phones or fixed desk phones that each connect to a single access point,
providing location information for each endpoint is not technically
difficult or costly. In addition, our definition of dispatchable
location gives providers substantial flexibility to determine what
amount of information is needed to identify the dispatchable location
of each fixed endpoint, and for many small businesses, provision of
street address alone will be sufficient. We therefore conclude that
providing dispatchable location for 911 calls from fixed MLTS devices
used on-premises is readily achievable.\14\ We also conclude that
dispatchable location from fixed MLTS devices should be provided
automatically \15\ and that the street address associated with the
fixed end-point should be validated.
---------------------------------------------------------------------------
\14\ We infer that fixed MLTS use occurs solely through
connection of fixed devices with on-premises endpoints. Commenters
did not cite any instances of MLTS supporting fixed devices off-
premises. In the unlikely event that an MLTS were to support a fixed
off-premises device, however, we see no reason why providing
dispatchable location for such a device would be any less feasible
than in the case of an on-premises device.
\15\ In other words, the dispatchable location information
associated with a fixed MLTS device must be conveyed to the PSAP
when a user places a 911 call, without further intervention by the
user at the time it places the call. As noted below, an MLTS
operator or manager may rely on an enterprise customer to acquire,
maintain, and keep up-to-date the location information associated
with a fixed MLTS device.
---------------------------------------------------------------------------
150. This requirement will take effect one year from the effective
date of the rules adopted in this order. Although
[[Page 66735]]
the Commission proposed in the NPRM to implement dispatchable location
requirements for MLTS on February 16, 2020, contemporaneous with the
compliance date for the requirements of Kari's Law, most industry
commenters oppose this proposal, arguing that it would give them only a
few months to implement requirements and noting that RAY BAUM'S Act,
unlike Kari's Law, does not specify an implementation date for
requirements the Commission may adopt. We conclude that a one-year
timeframe is more reasonable to ensure timely implementation while
affording affected parties reasonable time to take the necessary steps
to come into compliance.
(ii) Non-Fixed MLTS Calls
151. Commenters express divergent views as to the feasibility of
providing dispatchable location for on-premises MLTS 911 calls from
non-fixed devices, e.g., softphones or mobile handsets that that are
capable of connecting to multiple Wi-Fi access points and can move from
one location to another within a building.\16\ Some MLTS service
providers (e.g., RedSky, Avaya, BluIP) state that they currently offer
enterprise services that use access point location information to
dynamically determine and convey an MLTS end user's precise location
within a building. Such services typically rely on storing location
information for each access point in a database (maintained by the
enterprise customer or the MLTS provider) that can be referenced when a
911 call is placed from a particular access point.
---------------------------------------------------------------------------
\16\ While such devices are capable of being moved from one
access point to another, we note that they may be only be capable of
conducting a communications session with one access point at a time,
i.e., the system may not support seamless handoff of the device from
one access point to another without interrupting the session.
---------------------------------------------------------------------------
152. However, other commenters point out that the effectiveness of
enterprise database approaches is dependent on a number of variables
and could be prohibitively costly. Relying on an enterprise database to
provide location information requires the enterprise customer to either
develop and maintain the database or to pay a third-party vendor to
provide database services. It also requires procedures and safeguards
to ensure that access point location data are entered accurately and
kept up-to-date. In addition, depending on the density and distribution
of in-building access points, access point location information may
provide the caller's approximate location but may not be precise enough
to provide dispatchable location, e.g., the caller's specific room or
office number. Commenters anticipate that over time, database location
solutions for MLTS will become more widely available and capable of
providing more precise location information, but they caution against
adopting requirements that assume the near-term availability of
database solutions to support dispatchable location across the full
array of enterprise environments.
153. To address these concerns, we adopt a more flexible approach
to providing dispatchable location for MLTS 911 calls from non-fixed
devices. MLTS providers must convey automated dispatchable location for
such devices when technically feasible but may rely on the MLTS end
user to provide or confirm dispatchable location information manually,
e.g., by responding to a system prompt. Commenters generally agree that
enabling such manual confirmation of location information by MLTS end
users is both feasible and potentially beneficial.
154. We recognize that relying solely on end users to provide
manual location updates can lead to user fatigue, and that manually
provided information may not be accurate or up-to-date. As an
additional fallback, commenters strongly agree with the Commission's
statement in the NPRM that our rules and policies should ``allow and
encourage'' alternatives to dispatchable location. Microsoft states
that commercially available location services already in use around the
globe can be leveraged ``relatively quickly and effectively'' to
enhance the 911 capabilities of IP-based and cloud-MLTS and
interconnected VoIP services in ways ``far more accurate and reliable
than a `registered location' manually entered by the end-user.''
According to Microsoft, location technologies that could be leveraged
include GPS/GNSS location, device-based sensing of Wi-Fi hotspots, and
use of commercially available crowd-sourced location data. Comtech
states that newer MLTS hardware can incorporate GNSS signals, which
could be used to automatically corroborate any human-provisioned
dispatchable location information. INCOMPAS contends that ``relying on
a `superset of location information' such as a wireless carrier's cell
site, GPS, the Wi-Fi hotspots, and commercial location information
gives regulated voice providers several opportunities to provide
accurate dispatchable location data rather than relying on a static
address.''
155. We agree with these commenters that our rules should harness
the potential for commercially available device-based technologies and
coordinate-based location methods to support the provision of MLTS 911
location information. Therefore, as proposed in the NPRM, we afford
MLTS providers flexibility to provide alternative location information,
including coordinate-based information, when providing dispatchable
location is not feasible or cost-effective.\17\ We also adopt a
technology-neutral approach, as uniformly advocated by commenters, so
that providers have the widest latitude to choose among available
solutions.
---------------------------------------------------------------------------
\17\ APCO cautions that providers should not be allowed to
``self-declare'' that dispatchable location is not technically
feasible or cost-effective. We agree. If we receive a complaint or
petition that a provider is not providing dispatchable location and
the provider asserts that doing so is not technically feasible or
cost-effective, the provider must show that its assertion has an
objective and reasonable basis in light of the state of technology
at the time the assertion is made.
---------------------------------------------------------------------------
156. We recognize that where alternative location information is
provided with an MLTS 911 call, the rules we adopt today allow the
location fix to be less precise than a dispatchable location that
pinpoints the caller's location down to the room, office, or apartment
level. While we agree with APCO that a more precise location is the
preferred outcome, we find that the record strongly supports allowing
the provision of less precise--but still actionable--alternative
location information as a fallback when providing more precise
information is not technically feasible. Identifying a caller's street
address and floor level is likely to reduce response time, even if it
does not identify ``the door to kick down.'' Commenters also confirm
that this level of accuracy is significantly easier and less costly to
achieve than more precise location information in many instances. Cisco
states that ``MLTS today typically provides the building's street
address, and . . . systems increasingly provide floor level.'' In
addition, while identifying a caller's room or apartment may be
significantly more costly, as Cisco asserts, it is not difficult for an
MLTS serving large buildings to identify the building wing or quadrant
where the call originates. Therefore, we define ``alternative location
information'' as location information (which may be coordinate-based)
sufficient to identify the caller's civic address and approximate in-
building location. In large multi-story buildings, this should normally
include floor level and approximate location on the floor (e.g.,
building quadrant). We note that this approach is similar to the
approach the Commission took in its wireless E911
[[Page 66736]]
rules, which allow wireless carriers to provide either dispatchable
location or x/y/z coordinate-based location information for indoor
wireless 911 calls.
157. These requirements will take effect two years from the
effective date of rules adopted in this order. Although the Commission
proposed to make dispatchable location requirements effective on
February 16, 2020, we agree with commenters that a longer transition
period is needed for MLTS providers to implement ``granular'' location
requirements, particularly for non-fixed services. Cisco states that
for ``on-premises MLTS stations,'' the Commission should consider a
phased approach whereby the Commission would require MLTS managers to
provide the street address of the caller's location while having the
flexibility to provide additional information that they determine is
sufficient for the enterprise ``following a minimum transition period
of two years.'' Panasonic states that the Commission ``should extend
the compliance date for 3-5 years if [validation] capability is deemed
necessary for all MLTS systems.'' RingCentral states that the
Commission should allow at least 18 to 24 months to develop solutions
to meet the complex challenges posed by any new location requirements.
VON states that the compliance date for nomadic VoIP providers should
be at least 24 months after the effective date of our implementing
order.
158. We conclude that a two-year transition period is appropriate
for implementation of these requirements. It is consistent with
implementation timeframes recommended by many commenters. We also agree
with Microsoft, Cisco, and other commenters that within the next two
years, MLTS will likely be able to leverage improvements in technology
that can refine the location process, including improvements to
location databases and commercially available device-based technologies
that can provide a ``superset'' of location information on a standalone
basis or in combination with network-based tools. Finally, we note that
the two-year deadline adopted in this order will likely fall in late
2021, which will roughly coincide with implementation of milestones
intended to improve in-building location of wireless 911 calls under
the Commission's wireless location accuracy rules. This provides an
opportunity for MLTS, as well as other services covered by this order,
to explore opportunities with wireless carriers for developing common
location solutions that can support in-building location regardless of
the platform used to make the 911 call.
159. In contrast, we conclude that MLTS providers should not be
subject to the same location requirements for off-premises MLTS calls
to the extent compliance is not technically feasible. When an MLTS end
user is off-premises, the MLTS does not typically control or have
access to location information. Remote access instead may involve
connecting via a third-party access point that is outside the control
of the enterprise or the MLTS operator, and for which location
information may not be available. We agree with commenters that this
lack of access or control makes it considerably more challenging and
costly for an MLTS to provide location information for off-premises
users than on-premises users. TIA states that for an end-user connected
remotely to an enterprise via a VPN, ``ensuring accurate location data
is difficult, if not impossible'' because a VPN user's location is
reported as an IP address of the enterprise at end of the IP tunnel.
Panasonic states that where an employee uses an IP-capable client off-
premises, ``there is no way to locate such callers today without
requiring the purchase of expensive third-party services that require
manual location entry.'' RingCentral states that ``when a user goes
off-site and leaves the enterprise network, it may not be possible to
locate that user or even detect that the user has moved.''
160. In light of these factors, we conclude it is premature to
prescribe specific standards for location of off-premises MLTS calls
when compliance with our on-site requirements would not be technically
feasible, and we therefore adopt a flexible approach that avoids
imposing impossible requirements. For off-premises 911 calls, the MLTS
operator or manager must provide (1) dispatchable location, if
technically feasible, or, otherwise, either (2) manually-updated
dispatchable location, or (3) enhanced location information, which may
be coordinate-based, consisting of the best available location that can
be obtained from any available technology or combination of
technologies at reasonable cost. This requirement will take effect two
years from the effective date of rules adopted by this order. The
flexibility inherent in this requirement should lessen the burden and
the amount of time it will take to comply. We recognize that as a
practical matter, MLTS providers are unlikely to be capable of
providing dispatchable location for most off-premises calls, and that
``best-available'' location information may be limited in the near
term. Nevertheless, over time this requirement will encourage
development of improved location capabilities for off-premises MLTS 911
calls.
c. Roles and Responsibilities of MLTS Participants
161. The Commission proposed to apply MLTS dispatchable location
requirements to ``the participants in the MLTS marketplace we believe
are best positioned to ensure that all installed MLTS are capable of
conveying an accurate location to the appropriate PSAP.'' As in the
case of Kari's Law, the Commission proposed distinct requirements for
MLTS manufacturers, importers, sellers, and lessors, on the one hand,
and MLTS installers, operators, and managers on the other: The former
group would be required to ensure that MLTS systems are ``pre-
configured'' to convey dispatchable location with 911 calls, while the
latter group would be required to ensure that MLTS systems are
``configured'' to convey dispatchable location with 911 calls. The
Commission sought comment on whether more granular requirements should
be placed on any of the MLTS market participants to which the proposed
rules would apply and whether rules are needed to ensure that MLTS
manufacturers and importers incorporate capabilities in their products
to enable them to convey dispatchable location information.
162. Commenters are generally supportive of the Commission
clarifying the roles and responsibilities of MLTS market participants
with respect to providing location information with 911 calls.
Commenters also agree with the Commission's proposal that
responsibility for dispatchable location be apportioned in the same
manner as responsibility for the direct dialing and notification
requirements of Kari's Law. Therefore, as proposed in the NPRM, we
impose pre-configuration requirements on MLTS manufacturers, importers,
sellers and lessors, and configuration requirements on MLTS installers,
operators, and managers. In light of our adoption of flexible location
requirements, these pre-configuration and configuration requirements
now reference the conveyance of dispatchable location and alternative
location information.
163. Some commenters propose additional clarification of the
respective roles and responsibilities of MLTS installers, operators,
and managers in ensuring that accurate location information is provided
with MLTS 911 calls. NTCA states that a service provider should be
required ``to configure proper location information
[[Page 66737]]
upon installation and initiation of service only to the extent they are
involved in configuration of handsets and systems in the first
instance.'' RedSky states that ``the level closest to the end user has
the most accurate device . . . location data and should be held
responsible for the provisioning of data.'' Several commenters also
note that MLTS operators and managers will need the assistance of
enterprise customers to acquire, maintain, and update location
information. Accordingly, Comcast contends, MLTS operators and managers
should not be held responsible when a customer moves MLTS stations to
new locations without their knowledge.
164. We agree with commenters that additional clarification of the
role of MLTS installers, operators, and managers is warranted. We
therefore adopt a proposal submitted by USTelecom to add specific rules
that delineate the respective responsibilities of MLTS installers,
managers, and operators relative to the provision of location
information. We also clarify that in developing and implementing
location solutions, MLTS managers and operators are entitled to rely on
enterprise customers to acquire, maintain, and update location
information.
d. Location Requirements for Small Businesses
165. The Commission sought comment on whether certain small
business categories (e.g., of a specific size, or with a specific
number of consumers) should be exempted from MLTS dispatchable location
requirements. Commenters offered varying proposals for small businesses
exemptions ranging from criteria based on square footage of enterprise;
to allowing states and local jurisdictions to grant waivers; to
applying requirements based on a minimum number of lines.
166. The rules we adopt today obviate the need for small business
exemptions or waivers of MLTS location requirements based on square
footage or number of lines. The rules afford all MLTS a broad menu of
options for providing location information, and the requirements are
also scalable to the needs of small businesses: In most instances,
provision of street address information alone will be sufficient to
identify the dispatchable location of MLTS 911 calls originating from
small businesses. We believe this approach minimizes burdens and
unnecessary complexity for small businesses while also preserving
flexibility to advance the 911 location accuracy objectives of RAY
BAUM'S Act.
e. Legacy MLTS
167. In the NPRM, the Commission proposed to apply location
requirements to the same entities subject to the direct dialing and
notification requirements of Kari's Law, which would exclude legacy
MLTS. APCO argues that even though legacy MLTS is not subject to Kari's
Law, legacy systems should be subject to location requirements because
RAY BAUM'S Act does not prohibit applying such requirements to legacy
systems, and some MLTS is capable of delivering dispatchable location
today. Other parties support the NPRM proposal, arguing that requiring
legacy MLTS to retrofit their systems to support dispatchable location
would be disruptive and costly. On balance, we adopt the NPRM proposal.
We decline to adopt APCO's request because doing so would require
costly retrofitting of legacy MLTS--costs that would be more burdensome
than for mass market services because legacy MLTS are specially
configured for the particular enterprises they serve. In addition,
applying Kari's Law and RAY BAUM'S Act to different classes of MLTS
would create confusion and technical inconsistency, whereas applying
the two statutes uniformly will encourage integrated 911 solutions for
MLTS.\18\ We also disagree with APCO's suggestion that applying new
location obligations to the existing MLTS ecosystem would be comparable
to the Commission's approach to phased-in location accuracy for
wireless services. In the wireless context, the increasingly precise
location obligations adopted by the Commission were imposed on an
industry already subject to extensive 911 obligations. In contrast,
before Kari's Law and RAY BAUM'S Act were enacted, MLTS was not subject
to any 911 obligations at the federal level. Adopting complex
obligations from scratch for a legacy industry is vastly more complex
and costly than an incremental change to an already-regulated service.
We also believe our decision is consistent with Congressional intent to
address MLTS 911 on a prospective basis and not to require retrofitting
of existing MLTS.
---------------------------------------------------------------------------
\18\ In this respect, we find that requiring retrofitting
existing systems solely to address dispatchable location may result
in a failure to promote more integrated technological solutions that
could address both the direct dialing and notification provisions of
Kari's Law and the dispatchable locations provisions of RAY BAUM'S
Act on a holistic basis.
---------------------------------------------------------------------------
f. Liability Protection
168. Microsoft requests that the Commission clarify that MLTS
providers are entitled to the same liability protections afforded
wireless carriers, iVoIP services and text-to-911 services. Microsoft
observes that Congress has granted immunity from liability to certain
emergency communications providers as follows:
A wireless carrier, IP-enabled voice service provider, or other
emergency communications provider, and their officers, directors,
employees, vendors, and agents, shall have immunity or other
protection from liability in a State of a scope and extent that is
not less than the scope and extent of immunity or other protection
from liability that any local exchange company, and its officers,
directors, employees, vendors, or agents, have under Federal and
State law (whether through statute, judicial decision, tariffs filed
by such local exchange company, or otherwise) applicable in such
State, including in connection with an act or omission involving the
release to a PSAP, emergency medical service provider or emergency
dispatch provider, public safety, fire service or law enforcement
official, or hospital emergency or trauma care facility of
subscriber information related to emergency calls, emergency
services, or other emergency communications services.
169. We find that this statutory liability shield extends to MLTS
manufacturers, importers, sellers, lessors, installers, operators and
managers. The statutory text applies its liability protections to
``other emergency communications service providers,'' which is defined
to include ``an entity other than a local exchange carrier, wireless
carrier, or an IP-enabled voice service provider that is required by
the Federal Communications Commission consistent with the Commission's
authority under the Communications Act of 1934 [47 U.S.C. 151 et seq.]
to provide other emergency communications services.'' In this Report
and Order, we find that MLTS manufacturers, importers, sellers,
lessors, installers, operators and managers are subject to our
jurisdiction and, consistent with the requirements of Kari's Law and
RAY BAUM'S Act, we require them to configure MLTS systems to ensure
delivery of 911 emergency information to PSAPs. Thus, we agree with
Microsoft that MLTS plays a ``significant role . . . in the provision
of 911 services in the United States,'' and that ``MLTS apps will be
engaged in the transmission of 911 information to PSAPs.'' Accordingly,
we find that because these entities are required to provide ``emergency
communications service,'' MLTS manufacturers, importers, sellers,
lessors, installers, operators and managers fall within the statutory
definition of ``other emergency communications provider.''
[[Page 66738]]
2. Fixed Telephony
170. In the NPRM, the Commission proposed to require fixed
telephony providers to furnish dispatchable location with 911 calls.
The Commission noted that these providers already provide validated
street address information with 911 calls, which should meet the
dispatchable location requirement for single-family dwellings, and
asked about the feasibility of also providing floor level and room
number for calls from multi-story buildings.
171. No commenter disagrees with our conclusion that by providing
validated street address information with 911 calls, fixed telephony
providers are already providing dispatchable location for single-family
dwellings.\19\ With respect to fixed telephony calls from multi-story
buildings, the limited comments we received on the issue support our
view that fixed telephony providers are either already providing floor
and room information or can readily do so at minimal cost. Panasonic
states that ``it is feasible for 911 calls from an endpoint assigned a
[Direct Inward Dialing] number to convey a dispatchable location; each
[Direct Inward Dialing] number can be assigned with a dispatchable
location in the telephony carrier's database. West Safety states that
it is ``not aware of any technical limitations to fixed telephony
providers conveying dispatchable location with a 9-1-1 call.'' As a
practical matter, for apartment building residents that are fixed
telephony customers, dispatchable location can be readily provided
because the apartment number (which often identifies floor level as
well) is part of the customer's billing address. To the extent that
fixed telephony providers need to provide more than street address and
are not already doing so, the means to add this capability are readily
available.
---------------------------------------------------------------------------
\19\ RedSky notes that fixed telephone providers typically have
no control over inside wiring in single family homes, and therefore
are unlikely to be able to identify floor level for a fixed
telephone call originating from a single family home that is more
than one story. However, we see no practical benefit to requiring
floor level identification as a component of dispatchable location
for calls from single family dwellings, nor has any public safety
commenter suggested this is necessary.
---------------------------------------------------------------------------
172. Based on these findings, we adopt our proposal requiring fixed
telephony providers to deliver automated dispatchable location with 911
calls. This requirement will take effect one year from the effective
date of the rules adopted in this order. Although the Commission
proposed to implement this requirement on February 16, 2020, we
conclude that a one-year timeframe is more reasonable to ensure timely
implementation while affording affected parties a reasonable amount of
time to take the necessary steps to come into compliance.
173. In an ex parte filing, IT&E requests that we exempt fixed
telephone providers in U.S. territories from dispatchable location
requirements, noting that one of the territories it serves has no
street address database available and that territorial PSAPs do not
have the capability to receive automated location information. To the
extent that fixed telephony providers face limitations in providing
automated dispatchable location due to factors beyond the provider's
control, such providers may request relief under the Commission's
waiver process.
3. Interconnected VoIP
174. In the NPRM, the Commission proposed to revise the E911 rules
for interconnected VoIP to require the provision of dispatchable
location for 911 calls. The Commission stated that with respect to
fixed VoIP, it regards the current Registered Location approach as
sufficient to support dispatchable location. With respect to nomadic
VoIP, the Commission sought comment on the feasibility of providing
automatic real-time dispatchable location but also proposed to allow
VoIP providers to fall back to using Registered Location and manual
updates if providing automated dispatchable location is not feasible or
cost-effective. As discussed below, we adopt dispatchable location
requirements that distinguish between fixed and non-fixed
interconnected VoIP services.\20\ Also, we extend this requirement to
``outbound only'' interconnected VoIP providers as well as two-way
interconnected VoIP providers covered by the current VoIP E911 rules.
---------------------------------------------------------------------------
\20\ Fixed VoIP services are services that provide the
functional equivalent of fixed telephony by means of a device that
connects to a single access point and is not capable of being moved
by the end user. Non-fixed VoIP services are VoIP services that
enable the end user to connect a handset or other IP-enabled device
to multiple access points. Such services are variously described as
``nomadic'' or ``mobile'' VoIP, depending on the degree of
functional mobility that the service allows the end user. We use the
term ``non-fixed VoIP'' to refer to the full range of such services,
except where referring to comments that specifically discuss nomadic
or mobile VoIP. We also note that the term ``non-fixed VoIP'' does
not extend or apply to Commercial Mobile Radio Services that are
subject to our wireless E911 rules.
---------------------------------------------------------------------------
a. Fixed VoIP
175. With regard to fixed interconnected VoIP, commenters generally
agree with the Commission's tentative conclusion that Registered
Location is already providing dispatchable location for single-family
dwellings, and that using Registered Location to provide additional
information for fixed VoIP serving multi-story dwellings is readily
achievable in the near term. For example, VON states that it
``generally agrees with the Commission's tentative assessment that
current Registered Location obligations are sufficient to meet the
definition of dispatchable location, and that such location information
is already being conveyed.'' VON further suggests that fixed VoIP
providers have incentives to provide additional location information,
noting that ``customers now demand the ability to provide additional
location information, including room and floor information where
applicable, and VON members respond to these customer requirements.''
176. We adopt our proposal to require that fixed VoIP services
providers transmit dispatchable location with each 911 call. While
dispatchable location may be determined by means of a customer-
generated Registered Location in the fixed VoIP context (to the extent
a physical location conveys a street address that is validated), it
must be provided automatically to the PSAP by the VoIP service
provider, without additional action by the caller, at the time the 911
call is made. As in the case of our requirements for fixed MLTS and
fixed telephony, and for the same reasons, this requirement will take
effect one year from the effective date of the rules adopted in this
order.\21\
---------------------------------------------------------------------------
\21\ INCOMPAS requests that the Commission ``extend the
compliance deadline for fixed services and give all providers two
years to comply with these new obligations.'' However, the record
confirms that providing dispatchable location within a year is
technically feasible for fixed services.
---------------------------------------------------------------------------
177. VON, however, also argues that the existing Registered
Location rules are sufficient to ensure the provision of dispatchable
location, and therefore no additional requirements for fixed VoIP
providers are necessary. We reject VON's argument that there is no need
to apply the new dispatchable location rules to fixed VoIP providers.
Although the rules preserve the existing option of relying on
Registered Location to provide the caller's location, they also
establish a new requirement for providing dispatchable location
automatically. Our inclusion of fixed VoIP in the new rules furthers
the RAY BAUM'S Act objective of ensuring that dispatchable location is
provided for all 911 calls regardless of the technological platform
used.
[[Page 66739]]
b. Non-Fixed VoIP
178. The Commission sought comment in the NPRM on the feasibility
of nomadic VoIP services providing automatic real-time dispatchable
location, noting that ``automatic provision of location is preferable
because end users under stress in emergency situations may have
difficulty providing manual updates and the updating process may delay
the 911 call or subsequent location and dispatch.'' The Commission
sought comment on the capability of interconnected VoIP providers to
dynamically determine the location of end users (1) when they are at
home or their usual place of work, (2) when they move frequently
between multiple locations, and (3) when they are at locations they do
not regularly visit. The Commission also proposed to allow VoIP
providers to fall back to using Registered Location if providing
automated dispatchable location is not feasible or cost-effective. As a
safeguard against sending incorrect location information, the
Commission proposed that the VoIP provider ``identify whether the
service is being used from a different location than the Registered
Location, and if so, either: (1) Prompt the customer to provide a new
Registered Location; or (2) update the Registered Location without
requiring additional action by the customer.''
179. As with non-fixed MLTS, we find that in the non-fixed VoIP
environment, flexible rules and a longer time frame for providing
accurate 911 location information are appropriate. In this respect,
commenters generally agree on the desirability of automated validation
of dispatchable location in the nomadic VoIP environment, but stress
that there are challenges to providing such validation in many cases.
RingCentral states that interconnected VoIP users ``increasingly use
browser-based applications for calling, but browser-based
applications--by design--do not have the capability of detecting a
user's location unless that user opts-in to location detection.''
RingCentral states that similar challenges exist for users logging in
with VPN, ``as it may not be possible to detect . . . the user's true
location.'' Other commenters agree that the technology that would allow
for automatic real-time dispatchable location for non-fixed VoIP users
needs additional time to fully develop, and therefore agree with the
Commission's proposal to allow providers to fall back to Registered
Location options when dispatchable location is not feasible.
180. The record further indicates that non-fixed VoIP providers
continue to rely heavily on Registered Location, but that alternative
approaches are increasingly available that could support automatic
location in some instances. For example, NENA states that the emergence
of software-based VoIP applications on mobile phones has made automatic
location updates more technically and economically feasible. RedSky
states that ``the technology exists'' to provide dispatchable location
for nomadic users through device-based location methods. Microsoft
states that commercially available location services can improve
interconnected VoIP location in ways ``far more accurate and reliable
than a `registered location' manually entered by the end-user[.]'' The
ability of non-fixed VoIP providers to provide automated real-time
dispatchable location is highly dependent on whether granular location
information is available for the access point from which the 911 call
is placed, and whether the VoIP provider has access to that
information. In some environments, particularly when end users are away
from their home or regular workplace, this information is either
unavailable or the development of information sources that could be
leveraged by VoIP providers to provide dispatchable location (e.g.,
databases with access point location information) is in early stages.
Therefore, we adopt rules that require automatic provision of
dispatchable location when technically feasible, but also allow non-
fixed VoIP providers to fall back on manual updating of Registered
Location information by end users as a backstop approach.\22\
---------------------------------------------------------------------------
\22\ We note that AT&T points out that automatic location
solutions could raise network security concerns because some
proposed solutions, which would have limited applicability, would
involve scanning of the Data Link Layer (Layer 2) of IP networks,
which would violate cybersecurity protocols and expose cyber
vulnerabilities. AT&T states that solutions based on scanning
networks may require customer disclosure of sensitive data, which
they may be unwilling to give vendors because doing so would present
a cybersecurity risk. In light of AT&T's concerns, providers may
fall back on manual registered location if automatic solutions raise
security concerns.
---------------------------------------------------------------------------
181. We also conclude that it is important to encourage development
of alternative approaches, based on the full range of device-based and
other available location technologies, that place less burden on the
end user than manual updates, and that can often provide more accurate,
timely, and reliable location information for VoIP users that move
frequently between multiple locations or are at locations they do not
regularly visit. Such information may not always be precise enough to
identify the caller's dispatchable location, but it can significantly
reduce the potential for error or delay that otherwise occurs when a
VoIP provider relies solely on Registered Location and uncertainty
arises about whether the VoIP user is actually calling from that
location. Commenters generally support giving interconnected VoIP
providers the flexibility to provide alternative location information,
including x/y/z coordinates, as a supplement or alternative to
dispatchable location. Therefore, we give non-fixed VoIP providers
flexibility to provide alternative location information, including
coordinate-based information, from all available sources when providing
dispatchable location is not technically feasible. This will provide
flexibility for non-fixed VoIP providers to convey an accurate location
to the PSAP while minimizing the burdens on the interconnected VoIP
service provider and the end user.
182. We recognize that where a non-fixed VoIP provider provides
alternative location information, the location fix may be less precise
than a location that pinpoints the caller's location down to the room,
office, or apartment level. We find that the record strongly supports
allowing less precise--but still actionable--alternative location
information as a fallback approach when providing dispatchable location
is not technically feasible. Therefore, as an alternative to automated
dispatchable location or end users' manual updating of Registered
Location information, we allow non-fixed VoIP providers to provide
alternative location information, which may be coordinate-based,
sufficient to identify the caller's civic address and approximate in-
building location, including floor level, in large buildings.\23\ We
also clarify that as a last resort, a VoIP provider may route a 911
call to a national emergency call center for the operator to ask the
caller about his or her location, so long as the provider has made a
good-faith effort to obtain location data from all available
alternative location sources. We also conclude that the two-year
transition period established by this order is appropriate for
implementation of these requirements, as it is consistent
[[Page 66740]]
with implementation timeframes recommended by a number of industry
commenters, provides time for development and deployment of
improvements in technology that can refine the nomadic VoIP location
process, including improvements to location databases and commercially
available device-based technologies, and coincides with implementation
of milestones intended to improve in-building location of wireless 911
calls under the Commission's wireless location accuracy rules.
---------------------------------------------------------------------------
\23\ We agree that the MLTS and interconnected VoIP location
rules do not overlap, and that providers should be subject to only
one set of requirements for any particular service they provide. If
a service meets the definition of interconnected VoIP service in
section 9.3 of our newly adopted rules, it will be subject to the
interconnected VoIP location rules and not the MLTS location rules.
---------------------------------------------------------------------------
c. Outbound-Only Interconnected VoIP
183. Consistent with Congress's approach of establishing regulatory
parity across technological platforms and enabling the completion of
outgoing 911 calls and messages from people in emergency situations, we
adopt 911 location requirements for outbound-only interconnected VoIP
providers. The requirements we adopt today are flexible and
technologically neutral from a compliance standpoint and serve a vital
public safety interest. We amend the definition of ``Interconnected
VoIP Service'' used for 911 purposes to include outbound-only
interconnected VoIP services that generally permit users to initiate
calls that terminate to the PSTN. We thus require outbound-only
interconnected VoIP providers to comply with our 911 obligations,
including the requirement to notify subscribers of any limitations to
E911 service. However, we modify the notification requirement to
clarify that it may be satisfied through stickers or warning labels, or
other conspicuous means, provided that the notification is prominently
displayed or highlighted in a manner that makes it likely to be seen by
the customer.\24\ Similar to our discussion of nomadic VoIP service
above, we require outbound-only interconnected VoIP service providers,
which are now encompassed by our amended language in the Sec. 9.3
definition of ``Interconnected VoIP Service,'' to provide (1)
dispatchable location if feasible, or, otherwise, either (2) manual
updating of Registered Location information; or (3) alternative
location information sufficient to identify the caller's civic address,
floor level, and approximate floor location in large buildings. We
require outbound-only interconnected VoIP providers to comply with the
911 requirements we adopt today two years after the effective date of
the rules.
---------------------------------------------------------------------------
\24\ In this regard, inclusion of the notification in the fine
print of an online customer agreement would not be sufficient.
---------------------------------------------------------------------------
184. RAY BAUM'S Act directs the Commission to ``conclude a
proceeding to consider adopting rules to ensure that the dispatchable
location is conveyed with a 9-1-1 call, regardless of the technological
platform used.'' RAY BAUM'S Act also states that, ``[i]n conducting the
proceeding . . . the Commission may consider information and
conclusions from other Commission proceedings regarding the accuracy of
the dispatchable location for a 9-1-1 call . . . .'' RAY BAUM'S Act
defines a ``9-1-1 call'' as a voice call that is placed, or a message
that is sent by other means of communication, to a PSAP for the purpose
of requesting emergency services.
185. Consistent with RAY BAUM'S expansive approach, which
recognized the Commission's existing 911 authority, the Commission
broadly sought comment on what communications services not covered by
existing 911 rules but that are capable of making 911 calls may fall
within this definition. In the NPRM, the Commission asked whether (1)
outcomes for 911 callers would be improved if it adopted 911 rules for
these communications services that parallel existing rules, including
any requirements for conveying dispatchable location and (2) new rules
that are specifically tailored for those communications services would
be more effective at improving outcomes. Specifically, the Commission
observed that some outbound-only VoIP services partner with businesses
that offer 911 smartphone applications that allow consumers to make
calls to 911 and that 911 stakeholders have expressed concerns that
calls received from these services may route to the incorrect PSAP,
result in fraudulent calls, lack critical location information
capabilities, and place the 911 caller at risk. The Commission noted
that the current rules do not require outbound-only VoIP services to
support 911 or convey dispatchable location with 911 calls, but it
recounted that in 2011 the Commission sought comment on expanding 911
obligations to providers of outbound-only interconnected VoIP services.
186. The Commission has broad authority over interconnected VoIP
services and 911. The RAY BAUM'S Act provided the Commission the
flexibility to consider whether and how to apply dispatchable location
requirements to services that provide the capability for users to make
a 911 call, which includes outbound-only interconnected VoIP. We
believe that the expansive scope of the legislative directive provides
legal authority for the Commission to adopt regulations that will
ensure dispatchable location data are conveyed with 911 calls with any
voice service that satisfies the definition of ``9-1-1 call,''
including outbound-only interconnected VoIP service. It also leaves
room to amend the definition of ``Interconnected VoIP Service'' at
Sec. 9.3 pursuant to the NET 911 Improvement Act and the CVAA.
187. We find that, from a 911 perspective, outbound-only
interconnected VoIP services are functionally equivalent to landlines
and other interconnected devices that connect to the PSTN and are 911-
capable, and thus, we should require outbound-only interconnected VoIP
service providers to comply with 911 obligations. As noted by West
Safety, ``[f]rom a caller's perspective, interconnected outbound-only
VoIP service is, for the most part, similar to traditional telephone
service, and its users reasonably expect it to function the same.'' To
illustrate further, Microsoft's Skype voice application facilitates
internet-based calls yet also provides users the ability to call any
landline or mobile device. Failing to require support for 911 services
by outbound-only calling services that are able to place PSTN calls to
any other North American Numbering Plan telephone number treats
similarly-situated services differently and enables and rewards
regulatory arbitrage. Moreover, treating these services inconsistently
or 911 purposes is likely to breed consumer confusion, particularly
when a caller is seeking help in a time of crisis.
188. Some commenters submit that the essential basis of Commission
regulation of outbound-only VoIP services is whether those services
would substitute for traditional telephone service. However, as
discussed above, our 911 rules already apply to interconnected VoIP (as
currently defined to refer to both inbound and outbound
interconnection), and the Commission proposed extending those
obligations to outbound-only interconnected VoIP more than eight years
ago. To use Skype to call regular phones, consumers pay by purchasing
credits, subscribe to Skype for unlimited calls, or buy a Skype phone
number. Additionally, Skype emergency calling is enabled in certain
countries, platforms, and versions of Skype software. Moreover, our
current approach enables providers to avoid basic public interest
obligations by offering purportedly separate ``outbound-only'' and
``inbound-only'' calling services, even though these services combined
are functionally
[[Page 66741]]
equivalent to traditional calling services and, in a regulatory sleight
of hand, avoid basic public interest obligations. We decline to
maintain this regulatory loophole to the benefit of one segment or
market participants over another, and to the detriment of consumers.
189. Some commenters support expanding 911 obligations to outbound-
only VoIP services on the grounds that consumers increasingly rely on a
variety of interchangeable communications services to place 911 calls
and expect those services to connect them to first responders. Others,
however, argue that consumer expectations regarding outbound-only VoIP
do not warrant imposing any obligations.
190. As an initial matter, we decline to make consumer expectations
the touchstone for determining what types of services should be subject
to 911 obligations. In this context, the relevant RAY BAUM'S Act
provisions do not refer to consumer expectations; rather, they define
``9-1-1- call'' broadly, in relevant part, as ``a voice call that is
placed, or a message that is sent by other means of communication, to a
public safety answering point . . . for the purpose of requesting
emergency services.'' The statutory focus, therefore, is on enabling
the user to reach emergency services to request assistance,
``regardless of the technological platform,'' not on whether the
service bears similarity to a traditional two-way phone call or whether
consumers perceive it as such. Our decision to subject outbound-only
VoIP service to 911 obligations is most consistent with Congress's
focus on ensuring that all messages from a person to emergency services
are received, regardless of the technology employed. A focus on
consumer expectations, by contrast, would frustrate the statute by
disadvantaging those people who were unaware that a particular device
or technology was incapable of dialing 911--precisely the tragic
circumstance that led to the adoption of Kari's Law.
191. In any event, we find that consumer expectations generally
support our decision today. We find that consumer expectations on this
issue have significantly changed since 2011. In this respect, we give
significant weight to the fact that the increasing variety of
interchangeable voice services on the market has changed the public's
expectations about access to 911, and our rules today reflect those
expectations. We are persuaded by BRETSA's comments that the fact that
Microsoft has enabled emergency calling with Skype in some European
countries and Australia demonstrates that 911 calling can be provided
in the United States. BRETSA also asserts that it is more important for
callers to be able to reach 911 in an emergency than that a PSAP can
reconnect a dropped call, and we agree.
192. The commenters who assert that consumers do not expect to
reach 911 from outbound-only systems present little data that support
their position. In particular, Microsoft, VON, and INCOMPAS oppose the
Commission's proposed expansion of 911 obligations to outbound-only
VoIP calling applications, arguing that users of one-way calling
capabilities do not expect to reach emergency services on these tools
and do not use them for emergency calling. Microsoft adds that it
voluntarily deployed emergency calling on its one-way, outbound-only
calling feature Skype to Phone (formerly SkypeOut) in four foreign
countries (Australia, Denmark, Finland, and the United Kingdom) and
that only 1,788 emergency calls were made in those four countries in
the most recent 23-month period. According to Microsoft, ``[t]he low
emergency call volumes are evidence that consumers do not expect to
have the capability to make emergency calls through Skype desktop and
tablet applications and, when this capability is provided to them, they
tend not to use it.'' Microsoft also states that many emergency calls
placed from this calling feature lasted less than one minute,
``strongly suggesting accidental or nefarious calls to emergency
services since valid emergency calls tend to last longer than a
minute.'' Commenters argue that consumers do not expect to use
outbound-only VoIP services to place emergency calls, in part because
some expected features of 911 calling, specifically PSAP callback, are
not readily available. Thus, according to Microsoft and INCOMPAS, the
Commission would be creating consumer expectations for 911 services
where certain features that customers have come to expect with
emergency calling are technically not feasible. Microsoft and INCOMPAS
also contend that expanding 911 rules to outbound-only VoIP will
increase nuisance or accidental calls to emergency services, which is
not in the public interest.\25\
---------------------------------------------------------------------------
\25\ Microsoft analogizes its argument to the Commission's 1996
decision to extend emergency calling requirements to non-service-
initialized (NSI) phones, which similarly lacked callback
capabilities, by requiring carriers to forward to PSAPs
automatically all 911 calls from wireless mobile handsets which
transmit a code identification, without requiring user validation or
any similar procedure. Although the Commission has acknowledged that
fraudulent 911 calls from NSI devices impose a substantial burden on
PSAPs, we disagree with Microsoft that this is a result of the lack
of the callback feature.
---------------------------------------------------------------------------
193. We find these arguments unpersuasive. First, it is
unsurprising that some consumers may not presently expect outbound-only
calling services to support 911 dialing and location services, as they
have not been obligated to do so. In this respect, though, we disagree
with the view that the Commission should refrain from acting for fear
of ``creating'' expectations regarding the availability of 911
services; to the contrary, the Commission should act where it finds a
need to support public safety. Second, the data presented prompt us to
draw the opposite inference on calls to emergency services from
SkypeOut in four foreign countries than that asserted by Microsoft.
Rather than indicating that 911 connectivity was not expected in these
instances, we find the existence of these calls is instead evidence
that at least some users expected--and needed--to call for help via
SkypeOut. We may further infer that as use of these services becomes
more widespread, the expectations carried with these services will
align with traditional voice services. That domestic expectations have
also evolved with the technology is reflected in the congressional
emphasis that the Commission should consider whether dispatchable
location obligations apply ``regardless of the technological
platform.'' Furthermore, concerns about overly broad regulation are
misplaced because we apply the change in a limited way--solely to 911
obligations on outbound-only interconnected VoIP service providers.
Finally, the possibility that there may be nuisance or inadvertent
calls to 911 from outbound-only services is not a sufficient reason to
exclude such services from the 911 obligations applicable to
interconnected VoIP service providers, thereby providing no access to
911 for callers with legitimate emergency needs to use these services.
While we recognize that accidental or nuisance calls can strain already
limited PSAP resources, there has been no demonstration that these
calls would overwhelm PSAP capabilities.\26\
---------------------------------------------------------------------------
\26\ Microsoft speculates that relying on end users to manually
update their location information could create an additional risk
that applications like Skype could be downloaded easily by a
nefarious actor who could then ``input a false location, and then a
make a 911 call for the purpose of dispatching public safety
resources to a particular location under false pretenses.'' We find
this argument implausible. For one, interconnected VoIP providers
are already required to require their end users to register a
location for 911 calls, and yet the record presents no evidence that
this is a problem today. Given that distinguishing feature between
such services and outbound-only interconnected VoIP services is
solely the lack of a callback feature--which is unrelated to the
problem Microsoft alleges--we see no reason to think improper
location information will suddenly become a problem should Microsoft
be required to allow its SkypeOut users call emergency services
effectively. More broadly, nefarious actors can give false
information to a PSAP via any technological platform--and there is
nothing distinctive about outbound-only interconnected VoIP services
that would lead us to believe including them would have a material
impact. What is more, we do not mandate registered locations to be
collected but instead empower providers to use other technologies to
facilitate dispatchable location or alternative location information
for such 911 calls--and of course we expect providers like Microsoft
to take into account the risks to public safety it has flagged when
choosing how to comply with our rules. Finally, to the extent that
Registered Location still presents any ``additional risk,'' as
Microsoft posits, that risk is outweighed by the need for people to
be able call 911 and for emergency responders to find them.
---------------------------------------------------------------------------
[[Page 66742]]
194. Several commenters support expanding 911 dispatchable location
requirements to outbound-only VoIP services, and state that technically
feasible solutions exist for such service providers to provide that
data. Comtech states ``it is imperative that any location requirements
adopted for 911-capable services take into consideration the current
state of technology and its rapid rate of change.'' Verizon indicates
that, like nomadic VoIP, the Commission should clarify that nomadic
outbound services could use either dispatchable locations or registered
locations because the same concerns raised in the context of nomadic
VoIP services apply.
195. We find that it is technically feasible to require outbound-
only interconnected VoIP service providers to convey the dispatchable
or alternate location requirements we adopt today. The location
requirements for outbound-only interconnected VoIP service providers
allow for flexible, technologically neutral compliance. Although the
NPRM sought comment on such communications services that are not
covered by existing 911 rules yet are capable of making a 911 call and
their ability to convey location information to the PSAP, no commenters
submit that it is not possible for outbound-only interconnected VoIP
providers to convey such location information. With the additional
compliance time provided below, we anticipate that such a capability
can be readily applied within the United States.
196. 911 VoIP Service. The Commission sought comment on expanding
the scope of those IP-based services subject to our 911 rules to
include not only interconnected VoIP but to also include ``911 VoIP
Services,'' which was proposed to include those services that enable
real-time, two-way voice communications that require IP-compatible
customer premises equipment and permit users generally to initiate a
911 call, even if the service does not permit users generally to
receive calls that originate on the PSTN, thus encompassing those
services that are considered ``outbound only VoIP.'' The Commission
further stated its intent to retain the existing definition of
``Interconnected VoIP Service'' to avoid inadvertent impact on the term
as used by various non-911 statutory provisions. By proposing a new
``911 VoIP Service'' category for use in the Commission's 911 rules,
the Commission sought to avert unintended consequences.
197. We conclude that the best approach to achieve what the public
interest demands is to amend the definition of ``Interconnected VoIP
Service'' to expand those services subject to our 911 rules, rather
than to adopt a separate ``911 VoIP Service'' definition. In this
respect, we find that the definition of ``911 VoIP Service'' proposed
in the NPRM mirrors the existing definition of ``Interconnected VoIP
Service,'' with the exception that the fourth element of the proposed
definition does not reference calling numbers or interconnection to the
PSTN and is limited to 911 calls. Amending the definition of
``Interconnected VoIP Service'' to include outbound-only VoIP services
solely for purposes of extending our 911 obligations is consistent with
our intent to apply only this set of obligations to such services, but
in a manner that responds to record comments and avoids the unintended
consequences to other uses of the term. For example, some commenters
express concerns with the proposed definition of ``911 VoIP Service''
and the applicability of our 911 requirements, including dispatchable
location, to those services. Verizon states that the Commission's
proposal to apply the interconnected VoIP 911 rules, including the
registered location choice, to newly defined outbound-only ``911 VoIP
Services'' may be overbroad. Verizon asserts that it is unclear that
outbound-only VoIP meets the New and Emerging Technologies (NET) 911
Improvement Act standard of ``widely accepted and fungible substitutes
for telephony'' if there are no other connections to the public
switched telephone network. According to Verizon, the proposed rule
also is unclear because it would require that calling party number
information be provided on all 911 VoIP services, which could enable
callback for a service that supports both outbound and inbound calling,
but ``would not help for outbound-only services.''
198. Accordingly, we decline to adopt the defined term ``911 VoIP
Service'' and instead add an additional category of services that
constitute interconnected VoIP for the purposes of 911 obligations to
expand the scope of services to those that are generally capable of
allowing users to initiate calls that terminate to the public switched
telephone network, including calls to 911.\27\ We expand the definition
of ``Interconnected VoIP Service'' in Sec. 9.3 of the Commission's
rules to mean a service that permits users generally to terminate calls
to the public switched telephone network.\28\
---------------------------------------------------------------------------
\27\ We acknowledge that some voice applications may provide
users with both interconnected and non-interconnected VoIP services
and emphasize that applicability of our 911 requirements to
interconnected VoIP service providers hinges on whether the service
satisfies all prongs of the definition, including interconnection to
the PSTN.
\28\ We note that the definition we adopt today tracks more
closely to the existing definition of ``Interconnected VoIP
Service'' as it is currently defined to refer to both inbound and
outbound interconnection than the definition proposed in the 2011
NPRM, which permitted users to terminate calls to all or
substantially all United States E.164 telephone numbers. As we
describe above, this is in-line with our intended approach to
minimize disruption to the current definition of ``Interconnected
VoIP Service'' in section 9.3 of the Commission's rules.
---------------------------------------------------------------------------
199. We concur with BRETSA's concerns that outbound-calling voice
applications or service providers could configure their services for
the specific purpose of avoiding 911 compliance. As a result, the
definition of ``Interconnected VoIP Service'' extends 911 calling
requirements to interconnected, outbound-only VoIP services that
generally permit users to terminate calls to the public switched
telephone network. We further clarify that the revisions we adopt today
preserve the application of the original definition of ``Interconnected
VoIP Service'' to other parts of the Commission's rules while expanding
those services to which the Commission's 911 rules apply. Thus, the
non-911 statutory provisions and rules that reference the current
definition of ``Interconnected VoIP Service'' in Sec. 9.3 of the
Commission's rules are not disturbed.\29\ Consistent with the directive
of RAY BAUM'S Act, and as supported by the record, we find that
expansion of the location requirements to interconnected VoIP service,
which includes outbound-only interconnected VoIP service, enacts 911
rules that are flexible and technologically neutral from a
[[Page 66743]]
compliance standpoint while limiting regulatory disruption.
---------------------------------------------------------------------------
\29\ We further clarify that outbound-only interconnected VoIP
services, which are now encompassed within the section 9.3
definition of ``Interconnected VoIP Service,'' are still considered
non-interconnected VoIP services for the purposes of section 716 of
the Communications Act of 1934, and therefore remain subject to part
14 of the Commission's rules.
---------------------------------------------------------------------------
200. Some commenters also argue that expanding 911 requirements to
``911 VoIP Services'' exceeds the scope of the Commission's statutory
authority under the NET 911 Improvement Act. Microsoft states that the
Commission has not proposed a sufficient basis of statutory authority
to impose emergency calling obligations on outbound-only voice
applications, and contends that the NET 911 Improvement Act provided
the Commission authority to establish emergency calling requirements
for IP-enabled voice services, which were defined to be synonymous with
``Interconnected VoIP Service.'' However, Microsoft asserts that the
NPRM ``does not propose to expand or modify the definition of
`interconnected VoIP service' to include outbound-only calling apps.
Nor does it propose an independent basis for imposing these
requirements on applications that currently satisfy the statutory
definition of `non-interconnected VoIP.' '' As a result, Microsoft
claims that the Commission's proposal would ``involve an extraordinary
expansion of the scope of the FCC's regulatory authority and would
exceed the limits of reasonable statutory interpretation.''
201. We disagree that expanding 911 requirements to the underlying
services that would have met our proposed definition of ``911 VoIP
Services'' exceeds the scope of the Commission's authority under the
NET 911 Improvement Act, particularly when coupled with the directive
of RAY BAUM'S Act.\30\ In this respect, by amending the definition of
interconnected VoIP we meet both the letter and spirit of both laws,
which provides the Commission discretion and flexibility to address new
technologies. We find that Congress, in directing the Commission to
consider all technological platforms, intended the Commission to
consider 911 obligations for these technologies. Moreover, the NET 911
Improvement Act provides that ``[i]t shall be the duty of each IP-
enabled voice service provider to provide 9-1-1 and enhanced 9-1-1
service to its subscribers in accordance with the requirements of the
Federal Communications Commission, as in effect on the date of
enactment of the [NET 911 Improvement Act] . . . and as such
requirements may be modified by the Commission from time to time.''
Pursuant to subsequent legislation, the Commission also retains ample
authority to amend the definition of interconnected VoIP. As a result,
we find that the Commission has direct statutory authority to modify
the definition of ``Interconnected VoIP Service'' to include outbound-
only interconnected VoIP, and today we modify that definition.
---------------------------------------------------------------------------
\30\ To the extent commenters argued that the Commission lacks
statutory authority to create a ``911 VoIP Services'' definition
that includes non-interconnected VoIP, we conclude that the issue is
moot as we are not addressing those services at this time.
---------------------------------------------------------------------------
202. Although in the NPRM the Commission stated its intention to
avoid disturbing the existing definition of interconnected VoIP since
it is referenced by various non-911 statutory provisions and rules, we
find that our approach to amending the definition of ``Interconnected
VoIP Service'' in Sec. 9.3 of the Commission's rules satisfies our
proposed intent and responds to concerns raised by commenters.
Specifically, to implement RAY BAUM'S Act, the Commission led with a
proposal to adopt the definition of ``911 VoIP Services'' and also
sought comment on extending 911 requirements, including location
obligations, to outbound-only VoIP services under the definition of
``911 VoIP Services.'' We note that entities which provide one-way,
interconnected VoIP service have been on notice since 2011, and even as
early as 2005, that the Commission was considering expanding the scope
of its 911 rules to include their communications services. The NPRM was
informed by, and cited to, these earlier rulemaking efforts, including
the outstanding proposals from 2011, and RAY BAUM'S Act left the
Commission discretion to consider these earlier efforts. The rule we
adopt today reflects consideration of proposals raised in earlier
Notices of Proposed Rulemaking and in the NPRM to extend dispatchable
location obligations to one-way VoIP calls, the purpose of the NPRM to
dispatch our RAY BAUM'S Act mandate to consider all technological
platforms, and record comment received in response. In light of the
comments received, we have not amended our definition of interconnected
VoIP, except as it affects 911 service obligations for outbound-only
interconnected VoIP service.
203. Furthermore, as stated above, commenters express concern about
our statutory authority to expand our 911 rules to services beyond
interconnected VoIP services, and in response we act upon their
suggestion that an amendment of the definition of ``Interconnected VoIP
Service'' would accomplish the Commission's intended objective,
particularly where we limit the definition change solely to impose 911
obligations. Moreover, the similarities in the proposed language of the
definition of ``911 VoIP Services'' largely tracks the language of
``Interconnected VoIP Service,'' and as such, regardless of the label
used, the service to which our rules were to be applied is sufficiently
apparent.
204. We amend the definition of ``Interconnected VoIP Service'' to
include outbound-only interconnected VoIP services. The expansive scope
of the legislative directive coupled with our discretion to amend the
definition of ``Interconnected VoIP Service'' provides sufficient legal
authority for the Commission to extend 911 regulations, including rules
to convey dispatchable location with 911 calls, to outbound-only
interconnected VoIP services. Doing so in this fashion also avoids
loopholes for evading regulatory obligations that protect the health
and safety of the American people, which commenters have pointed out to
be a risk of attaching such obligations only to those who choose to
provide ``911 VoIP Services.'' We believe that this approach is
consistent with our objective to promote safety of life and property
through communications.
205. Compliance Deadline. In the NPRM, the Commission proposed to
require compliance for dispatchable location requirements on the same
date as the proposed implementation for Kari's Law, i.e., February 16,
2020. The Commission further tentatively concluded that applying the
same compliance date across all platforms will promote efficiency and
encourage development of common dispatchable location solutions. No
commenters addressed compliance deadlines for outbound-only
interconnected VoIP service providers, but some commenters objected to
the proposed February 16, 2020 date as premature for imposition of
dispatchable location requirements for any service.
206. We adopt a two-year period for compliance for outbound-only
interconnected VoIP service. Due to the similar nomadic or mobile
functionality of the services, we find that similar implementation
considerations for nomadic VoIP providers are applicable to outbound-
only interconnected VoIP providers and warrant additional time for
compliance. Furthermore, adopting a two-year compliance period for
outbound-only interconnected VoIP service providers will result in a
compliance date in the same time frame as the implementation deadline
for wireless E911 location requirements, which will promote regulatory
parity and encourage the development of common location solutions
across all platforms.
[[Page 66744]]
4. Telecommunications Relay Services (TRS)
207. In the NPRM, the Commission observed that TRS providers are
required to deliver emergency calls to an appropriate PSAP and to
provide the location of the emergency. For some of these services, the
service provider is required to ask callers for their location
information at the beginning of the emergency call. For emergency calls
made through a Video Relay Service (VRS) or IP Relay (collectively,
``internet-based TRS''), the service provider must transmit location
information to the PSAP in the form of a Registered Location under
rules modelled on the Commission's interconnected VoIP 911 rules. In
the NPRM, the Commission observed that ``internet-based TRS and
interconnected VoIP face similar concerns regarding the ability to
accurately locate end users that use a mobile or portable device.'' The
Commission therefore proposed dispatchable location requirements for
internet-based TRS paralleling the requirements it proposed for VoIP,
i.e., allowing internet-based TRS providers flexibility to implement
automated dispatchable location and to fall back to Registered Location
options when real-time dispatchable location is not feasible. The
Commission asked whether there are differences between internet-based
TRS and interconnected VoIP that might require taking a different
approach to TRS dispatchable location, and sought comment on
alternative approaches.
208. We adopt flexible rules for internet-based TRS that largely
parallel our rules for fixed and nomadic VoIP. In this respect, TRS
commenters express many of the same views as VoIP commenters on the
feasibility of providing automatic real-time dispatchable location.
Sorenson and CaptionCall state that ``the technology for automatically
locating mobile users is advancing rapidly and the technology for
locating nomadic VoIP subscribers is improving, though it is still not
reliable in every instance.'' Nevertheless, ``[i]f solutions are not
technically feasible for over-the-top VoIP services, whether mobile or
nomadic, they will not be technically feasible for internet-based TRS
providers involved in call routing.'' Sorenson also states that in
certain situations, internet-based TRS providers lack the capability to
automatically detect whether a videophone or device has changed
location, in which case the only remaining option is to prompt users to
confirm or update their locations. Sorenson and other commenters
therefore support the Commission's proposal that internet-based TRS
providers should have the option to fall back to Registered Location
when dispatchable location is not feasible.
209. TRS commenters also support being given flexibility to provide
alternative location information when more precise location information
is not available. Sorenson and CaptionCall state that ``x,y,z needs to
be a permissible alternative to dispatchable location, and may be
necessary as location solutions evolve technologically.'' Sorenson
states that when its ability to use device-based location is fully
implemented and operational ``the customer's device will automatically
determine an x, y (and, where available, z) location estimate,''
provided the consumer has consented to allowing the VRS application to
access location information from the device. In an ex parte filing,
Sorenson and CaptionCall propose to require internet-based TRS
providers to provide dispatchable location when it is available but to
permit automatic geolocation when the dispatchable location is
unavailable. If neither a dispatchable location nor geolocation
information is available, their proposal would allow the provider to
provide the Registered Location. Sorenson and CaptionCall also propose
to specify in the rules that an internet-based TRS provider can use a
back-up call center when the provider is not confident that it can
otherwise reliably identify the caller's location.
210. We find that in the internet-based TRS environment, flexible
rules and a longer time frame for providing accurate 911 location
information are appropriate. The record indicates that internet-based
TRS providers continue to rely heavily on Registered Location, but that
alternative approaches are increasingly available that could support
automated dispatchable location in some instances.
211. For 911 calls from fixed internet-based TRS,\31\ beginning one
year from the effective date of the rules, we require internet-based
TRS providers to provide automated, validated dispatchable location for
each call. For 911 calls from non-fixed internet-based TRS,\32\
beginning two years from the effective date of the rules, we require
internet-based TRS providers to provide with each 911 call (1)
automated dispatchable location, if technically feasible, or,
otherwise, either (2) manual updating of Registered Location, or (3)
alternative location information, which may be coordinate-based,
sufficient to identify the caller's civic address and approximate in-
building location, including floor level, in large buildings when the
first two are not technically feasible.
---------------------------------------------------------------------------
\31\ We define TRS fixed services to include hardware-based TRS
and videophone equipment that are professionally installed and
cannot be moved by the customer without professional assistance.
\32\ We define TRS nomadic and mobile services to include TRS
facilities that use software-based endpoints.
---------------------------------------------------------------------------
212. TRS commenters also identify a distinction between IP
captioned telephone services (IP CTS), and relay services such as VRS
and IP Relay. Commenters state that call set-up and routing for most IP
CTS calls are handled by the user's underlying voice provider rather
than the TRS provider. In case of a 911 call, the IP CTS Communications
Assistant provides captioning but is not able to speak directly with
the parties or generate location information, much less provide it to
the PSAP. Sorenson and CaptionCall jointly suggest that the Commission
should separate the dispatchable location requirements for VRS from the
requirements for IP CTS, ``allow[ing] each service to be treated in an
appropriate manner.'' Further, with respect to IP CTS, Sorenson and
CaptionCall state that the ability of web/wireless IP CTS applications
to provide information other than Registered Location is dependent upon
the capabilities of underlying nomadic or mobile VoIP providers. To
afford IP CTS providers time to implement these capabilities, they
propose that the Commission set the implementation date for IP CTS one
year after the implementation date for nomadic or mobile VoIP.
213. We clarify that these requirements do not apply to TTY-based
TRS providers, or to internet-based TRS providers who completely rely
on their customers' underlying voice service providers to handle
emergency call set-up, routing, and provision of location information.
In such cases, it is not necessary to impose requirements on the TRS
provider because the underlying service provider is subject to the
relevant 911 requirements, including location requirements, in
connection with the call. Next, we are dismissing Sorenson and Caption
Call's request to set the implementation date for IP CTS one year after
the implementation date for non-fixed VoIP because the location rules
we adopt herein provide sufficient flexibility including fall back to
Registered Location, and they only apply to IP CTS providers that
handle call set-up and routing.
[[Page 66745]]
214. We also clarify that the rules do not require TRS providers to
automatically detect when a device is being used at a different
location from the Registered Location to the extent doing so is not
technically feasible. The record indicates that such detection is not
technically feasible for some internet-based TRS providers. In such
cases, the requirement can be met by a manual prompt to the user asking
for confirmation whether the user is at the Registered Location or a
different location.
215. We agree with commenters regarding routing of calls to
Emergency Calling Relay Centers as a last resort in the occasional case
where neither a prompt for a manual update nor any alternative
technology confirms the validity of the caller's location or otherwise
provides actionable dispatchable location information. In those
isolated cases, we will allow internet-based TRS providers to route the
call to an Emergency Calling Relay Center, so long as the provider has
made a good-faith effort to obtain location data from all available
alternative location sources.
216. Finally, we find that our TRS location rule amendments herein
do not conflict with the IP CTS emergency calling requirement rule
proposals in, or prejudge the outcome of, the IP CTS Reform Further
Notice. The Commission did not propose any changes to location
requirements in the IP CTS emergency call handling rules. We crafted
our new TRS location rules so that they will harmonize with the
proposed IP CTS emergency call handling rules in the event the latter
are adopted, as well as with the existing TRS rules in the event that
the proposed IP CTS emergency call handling rule amendments are not
adopted. Further, the Commission noted that ``issues regarding location
determination by IP CTS providers, as well as other TRS providers, will
be addressed in that docket,'' which refers to the instant docket.
5. Mobile Text
217. In the NPRM, the Commission noted that our current Text-to-911
rules require mobile carriers and other covered text providers to
obtain location information sufficient to route text messages to the
appropriate PSAP, but text providers are not required to convey
additional location information to the PSAP. The Commission stated that
this approach has always been viewed as an interim solution, and noted
the prior pending proposal in the Text-to-911 docket to require covered
text providers to deliver enhanced location information (consisting of
the best available location information that covered text providers can
obtain from any available location technology or combination of
technologies, including device-based location). In the NPRM, the
Commission sought to refresh the record on text-to-911 location and
asked whether to apply dispatchable location requirements to text-to-
911, if it is technically feasible, consistent with requirements
applied to other platforms.
218. The record indicates that the location technology options
available to covered text providers have significantly expanded since
the Commission adopted its text-to-911 rules five years ago. For
example, commenters point to recent improvements in technology that
have the potential to provide location information for an increasing
percentage of 911 texts. First, wireless carriers note that they are
starting to transition mobile wireless text services from SMS to more
robust IP-enabled platforms, such as real-time text, which can support
provision of location information with 911 texts using some of the same
location methodologies that are used to support IP-based voice
services. Second, Comtech and West Safety note the potential to use the
device-based location capabilities of mobile handsets (e.g., Google's
Emergency Location Service in Android devices) to generate location
information, which can then be sent via text to the PSAP.
219. However, the transition away from SMS texting is far from
complete, and the technologies being used to support text-to-911
location, while promising, have not yet been demonstrated to be capable
of consistently supporting either dispatchable location or enhanced
location accuracy comparable to the level of accuracy required for
wireless voice services. In this respect, wireless carriers commenting
on this issue caution against requiring them to implement dispatchable
location capabilities in SMS-based text-to-911, which would require
major retrofitting of legacy SMS networks that were not designed to
support the provision of location information. Commenters express
uncertainty about (1) when text-to-911 will fully migrate from SMS-
based texting to newer technologies, and (2) how soon device-based
location for 911 texts will be universally available. Comtech states
that ``some of the technological challenges that must be overcome to
improve location information for text-to-911, when compared to wireless
voice 911 location information, include: (1) The current configuration
of mobile handsets, (2) the types of location technologies and
protocols supported by mobile handsets, and (3) the availability of
real-time location platforms across each individual carrier.''
Consequently, while some commenters support establishing enhanced
location requirements for text-to-911, others argue that such
requirements are premature.
220. We therefore conclude that it would be premature to adopt
dispatchable location requirements for text-to-911 comparable to the
requirements applicable to other services covered by this order.
Instead, we adopt a flexible approach to text-to-911 location
requirements. We require covered text providers, within two years of
the effective date of these rules, to provide (1) dispatchable
location, if technically feasible, or, otherwise, either (2) end-user
manual provision of dispatchable location, or (3) enhanced location
information, which may be coordinate-based, consisting of the best
available location that can be obtained from any available existing
technology or combination of technologies at reasonable cost. We
clarify that the latter requirement does not require covered text
providers to retrofit SMS-based text networks or to upgrade legacy
mobile handsets that are only SMS-capable. We recognize that as a
practical matter, covered text providers are unlikely to be capable of
providing dispatchable location for most 911 texts, and that the
quality of ``best-available'' location information provided with 911
texts may vary. Nevertheless, we believe that over time this
requirement will encourage development of improved location
capabilities for text-to-911, while accounting for technical
feasibility issues raised in the current record.
6. Comparison of Benefits and Costs
221. In order to quantify the magnitude of the benefits to the
public when dispatchable location is conveyed with a 911 call from MLTS
and other communications services identified in the NPRM, the
Commission anticipated that the increase in location accuracy that
results from the use of dispatchable location will reduce the arrival
time of ambulances for some 911 callers at least as much as was
accomplished by the mobile location rules adopted in the Indoor
Location Fourth Report and Order. In that Report and Order, the
Commission found that the location accuracy improvements adopted for
mobile 911 calls had the potential to save approximately 10,120 lives
annually for an annual benefit of approximately $92 billion. Based on
available 911 call volume data in the
[[Page 66746]]
Commission's Ninth Annual Report and 911 Fees, the Commission estimated
that approximately 75% of 911 calls come from mobile phones, which
already are required to convey a dispatchable location. However, the
Commission believed the remaining 25% of calls to which its proposed
rules would apply will realize benefits. Because three times as many
calls come from mobile phones as from non-mobile sources, the
Commission estimated that the proposed rules have the potential to save
a maximum of one third of the 10,120 lives that were projected to be
saved annually by the mobile location rules adopted in the Indoor
Location Fourth Report and Order, or 3,373 lives annually. However,
because some providers already convey location information that is
equivalent to dispatchable location, the Commission expected that the
dispatchable location rules will save considerably fewer lives.
222. In the NPRM, the Commission assumed that the proposed rules
would save 506 lives annually, or only one twentieth of the lives that
it projected would be saved by the mobile location rules. The
Commission relied on the U.S. Department of Transportation's estimate
that the ``Value of a Statistical Life'' (VSL), defined as ``the
additional cost that individuals would be willing to bear for
improvements in safety (that is, reductions in risks) that, in the
aggregate, reduce the expected number of fatalities by one,'' is $9.6
million. In doing so, the Commission estimated that the 506 lives saved
by the proposed rules multiplied by the VSL establishes a benefit floor
of $4.9 billion. The Commission sought comment on the reasonableness of
its estimate, what other benefits can be expected to accrue, such as
(but not limited to) reduced complications from medical issues, reduced
damage to property, increased likelihood of forestalling crime and
apprehending suspects, and increased confidence in the 911 system and
emergency responders.
223. No commenter disagreed with the Commission's analysis of the
benefits that the public should expect from the implementation of
improved location accuracy requirements for MLTS and other services.
Additionally, public safety commenters support improvements to location
accuracy for calls to 911 from MLTS and other services, provided that
dispatchable location information is validated. The Texas 9-1-1
Entities submit that ``as legacy TDM landline continues to transition
to IP as the dominant market solution, 9-1-1 calls are becoming
increasingly less distinguishable based solely on technological
platform.'' ``While consistency alone warrants that the definition of
`dispatchable location' be the same across the Commission's 9-1-1 rules
regardless of technological platform (e.g., CMRS, fixed telephone/
legacy landline, MLTS),'' the Texas 9-1-1 Entities argue, ``this is
particularly important as technological platforms morph and evolve
(e.g., fixed wireless, mobile VoIP, Wi-Fi calling) and no longer fit
neatly into traditionally defined and differentiated categories.'' The
Texas 9-1-1 Entities and MESB illustrate that validation is
particularly necessary in an evolving IP environment, which appears
vulnerable to 911 calls being misrouted across state lines and placing
increased burdens on resource-limited PSAPs to re-route 911 calls to
the appropriate jurisdiction.
224. Additionally, of the total reported calls to 911 in 2017,
155,231,318 calls came from wireless phones, representing approximately
70% of the total reported call volume. In addition, the ratio of
wireless calls to total reported call volume remained steady even
though there was a 135% increase in VoIP calls from 2016 and a 378%
increase in the number of calls reported as ``Other'' from 2016 (VoIP
calls reported in 2017 increased to 7,666,958 from 5,661,055 in 2016
and the number of calls reported as ``Other'' increased to 8,907,760
from 2,353,291 in 2016). While the Bureau believes that the 70% figure
likely understated the percentage of wireless 911 calls because a
number of states reported total 911 calls but did not break out all
service categories separately, it is also likely that the Tenth Annual
Fee Report underestimated the increase in VoIP and ``Other'' calls
given that half of reporting jurisdictions did not report call volume
for those categories. Thus, the record suggests that the problem of
inaccurate location information or no location information being
conveyed with a 911 call from MLTS and other 911 services is common and
will continue to grow and potentially undermine public confidence in
location accuracy of such calls absent a requirement for validated
location information.
225. In the NPRM, the Commission proposed a dispatchable location
implementation schedule across all technological platforms that tracked
the February 16, 2020, compliance date for Kari's Law. The Commission
sought comment on the costs of the proposed rules in the NPRM. The
Commission observed that ``911 location solutions that are capable of
conveying dispatchable location to PSAPs are already offered by several
MLTS market participants.'' Further, the Commission noted that
``several states already place requirements on MLTS providers to obtain
and convey location information that is more detailed than street
address alone, [footnote omitted] and we therefore conclude that MLTS
manufacturers are producing and widely selling equipment that is
capable of complying with our proposed rules.'' The Commission asked
commenters to address whether there are any cases ``in which currently-
available equipment will not be suitable.'' In addition, the Commission
observed that ``to comply with current rules, interconnected VoIP
service providers and internet-based TRS providers today obtain
customers' Registered Location, which we believe would likely be
sufficient to satisfy our proposed dispatchable location requirements
in many circumstances.'' Because these dispatchable location-capable
solutions and equipment are already being widely offered by MLTS
manufacturers, installers, and operators, the Commission stated its
belief ``that the implementation costs of our proposed dispatchable
location rules to these entities would be negligible in most
respects.'' The Commission also expressed its belief ``that our
approach of granting flexibility in satisfying our proposed rules
minimizes the potential cost of compliance.'' Accordingly, the
Commission sought comment on these observations and tentative
conclusions.
226. As the Commission emphasized in the NPRM, we do not mandate
any particular technology or model for implementing the 911 location
rules we adopt today and apply these requirements on a technologically
neutral basis. Moreover, service providers can leverage existing
location technology solutions to mitigate costs. Further, we adopt a
phased-in approach that allows service providers additional time beyond
the February 16, 2020, proposal in the NPRM to come into compliance
with our rules. Additionally, we have tailored the compliance deadlines
to each particular service. Further, we apply our rules on a
prospective basis, thus minimizing cost on legacy systems and small
businesses. We find that applying our rules to these legacy systems
would be too costly because there is such a great variety of systems
that location technology solutions would have to be tailored for each
enterprise. That said, the record demonstrates that delivering
dispatchable location is technically feasible today for many services
at a cost that is less than the $4.9 billion minimum benefit floor.
Consistent with our approach in the Wireless Indoor Accuracy Fourth
Report and Order, this means that MLTS and other service
[[Page 66747]]
providers subject to our 911 location rules need only choose the
methods necessary to close the gap between already-deployed
capabilities and the Commission's requirements, ``rather than starting
from scratch.'' So, although the cost of meeting our 911 location rules
has not yet been determined to a dollar amount, the rules we adopt
today provide MLTS and service providers a clear reference point from
which to factor in compliance costs incrementally. We provide the
following analysis of comments addressing compliance costs.
227. Compliance Costs. In the NPRM, the Commission estimated that
the annual cost to MLTS operators to provide location information as
proposed would be less than $49.6 million, and that such costs are
likely to decline within a few years as databases and other sources of
location information become increasingly centralized. The Commission
also estimated a $460,000 per-provider cost for 18 providers of
Interconnected VoIP, VRS, and IP Relay services to implement software
upgrades that would detect when an end user's location has changed and
to identify the new location. The Commission also sought comment on
implementation costs for outbound-only VoIP providers. No commenter
objected to the costs estimated in the NPRM. One commenter, however,
suggested that the Commission over-estimated the costs associated with
building a ``white pages like directory'' or database and software
development costs.
228. Industry commenters recognize that accurate location
information can be critical in ensuring a timely emergency response,
including for vulnerable populations such as TRS users. Commenters
suggest that providers of fixed MLTS, fixed telephony, and
interconnected VoIP already provide dispatchable location, while some
are concerned that applying dispatchable requirements to nomadic or
remote, off-site MLTS could undermine incentives to use innovative
solutions. The record reflects that industry has incentives to continue
to improve 911 location capabilities and desires flexibility to adopt
911 solutions. However, industry commenters generally warn against
applying rigid, overly-granular, ``one-size fits all'' dispatchable
location mandates by February 16, 2020, that could be unduly burdensome
on evolving technologies. For example, Sorenson and CaptionCall note
that ``the technology for automatically locating mobile users is
advancing rapidly and the technology for locating nomadic VoIP
subscribers is improving, though it is still not reliable in every
instance.'' Microsoft suggests that prematurely applying such
requirements would be unachievable and ``runs the risk of preventing
the use of readily available location technologies that can vastly
improve the current location capabilities of MLTS and iVoIP,
particularly nomadic MLTS and iVoIP services.'' Ad Hoc advises that
``the Commission should not impose obligations on MLTS owners or
operators to transmit any type of information that their MLTS equipment
is not technically capable of transmitting or that would require
assumption of any unreasonable costs to upgrade.'' Cisco expresses
concerned that ``[a] dispatchable location requirement would also
amount to a de facto mandate for enterprise customers to purchase
third-party solutions that may be cost-prohibitive or ineffective.''
229. Cost Mitigation. Notwithstanding the lack of cost data,
commenters suggest measures to mitigate potential costs and complexity
of compliance, including enshrining the principles of technological
neutrality, flexibility and maintaining service specific 911 rules. The
requirements we adopt today are measured, technically feasible, and
technologically neutral, so that service providers can choose the most
effective solutions from a range of options. In addition, our
requirements allow sufficient time for advance planning and deployment
of new location technology, beyond the February 16, 2020 compliance
date proposed in the NPRM.
230. The record demonstrates that the scale of the potential
benefits will increase over time given the magnitude of the problem we
are facing, industry's incentives to improve 911 location accuracy, and
the fact that the requirements that we adopt today will render the
conveyance of dispatchable location an even more effective emergency
response tool as technology improves and becomes more widely available.
231. Outbound-only Interconnected VoIP. In the NPRM, the Commission
acknowledged potential technical challenges for outbound-only
interconnected VoIP services to automatically send a caller's
dispatchable location to a local PSAP during a 911 emergency.
Commenters submitted estimates for the costs of such a mechanism.
Precision Broadband, for example, noted in its ex parte its service of
mapping a consumer broadband IP address to a dispatchable location, and
projected ``an expenditure of between $200 million and $275 million per
year for the Fixed Broadband 911 system at full nationwide
deployment.'' We obtained a similar estimate for full nationwide
coverage through alternative means. We also note this is an upper bound
but an extremely unlikely scenario as many outbound-only interconnected
VoIP services already have provision for delivering their location.
According to a 2016 study conducted by the Pew Research Center, 90% of
smartphone users have location services enabled, meaning that these
users can already be located automatically without the aid of a third-
party technology like the one proposed by Precision Broadband. We also
believe that this statistic would apply to other devices with location
service capabilities not just the smartphone. Moreover, this Pew
statistic suggests there would be a similar willingness of consumers to
enter the dispatchable location into applications. Thus, the costs
imposed by this rule are for those consumers who neither have location
services available nor enter an address. Because the $275 million
figure presumes there are no location services available today, we
conclude that the total cost would be $27.5 million (10% of $275
million). We believe it is a reasonable expectation that of the 506
lives saved, at least 25 lives (i.e., only 5% because, as explained
above and in the NPRM, about 95% of interconnected devices already have
location ability) will be from this part of the rule. Indeed, just
three lives saved per year would fully cover the expected cost.
Furthermore, there are a variety of flexible options to provide 911
caller location information depending on the service, such as x-y-z
coordinates or manually updated Registered Location, adding support for
our finding that costs are likely to be on the lower end as we describe
here. We therefore find the benefits exceed the estimated costs
imposed.
232. We also require outbound-only interconnected VoIP service
providers to comply with the customer notification requirements of our
rules. We require outbound-only interconnected VoIP service providers
to comply with the 911 requirements we adopt today two years after the
effective date of the rules. Regarding general 911 requirements that we
extend to outbound-only interconnected VoIP, we envision that the costs
for consumer notification and record-keeping would also be comparable
to the information collection costs applicable to other interconnected
VoIP service providers under the Commission's rules. In sum, the record
indicates that the costs for outbound-only interconnected service
[[Page 66748]]
providers to comply with our 911 rules, including dispatchable
location, will not differ from the costs to interconnected VoIP
providers that our well-established rules already cover and for which
we have previously found to have the benefits outweigh the costs.
C. Consolidating the Commission's 911 Rules
233. In the NPRM, the Commission proposed to consolidate all the
existing 911 rules into a single rule part. The Commission also
proposed to simplify and streamline the rules in some instances and to
eliminate corresponding duplicative rules in other rule parts. The
Commission explained that rule consolidation will help to minimize the
burden on small entities subject to the Commission's 911 rules by
making it easier to identify and comply with all 911 requirements.
234. The majority of commenters who addressed the issue support the
proposed 911 rule consolidation. iCERT states that it does not object
to a non-substantive rule reorganization, and TIA supports removal of
rules that are obsolete. Hamilton provided the sole comment expressing
opposition, arguing that relay service rules ``are integrated with non-
911 related rules in such a way that removing the 911-related rules and
transferring them to part 9 would be cumbersome and counterproductive.
235. We consolidate the existing 911 rules as proposed. To address
Hamilton's concerns, we find that we can transfer and amend the relay
service emergency calling rules without adversely affecting the
integrity of the remaining non-911 relay service rules. The revised
part 9 differentiates between platforms and services where needed, but
it also enables service providers, PSAPs, and other stakeholders to
refer to a single part of the Commission's rules to ascertain all 911
requirements.
236. As noted in Appendix A and described for reference in
conversion tables in Appendix B, we designate part 9, which currently
contains our interconnected VoIP rules, as the rule part that contains
the consolidated 911 rules, and we transfer and consolidate our
existing 911 rules from parts 12, 20, 25, and 64 to part 9. The revised
part 9 will continue to differentiate between platforms where needed,
but it will also enable service providers, PSAPs, and other
stakeholders to refer to a single part of the Commission's rules to
ascertain all 911 requirements. Specifically, we consolidate our 911
rules as follows:
Move relevant definitions for all services to subpart A of
part 9;
Move telecommunications carrier obligations (Sec. 64.3001
et seq.) to subpart B of part 9;
Move CMRS obligations (Sec. 20.18) to subpart C of part
9;
Move interconnected VoIP obligations (current part 9) to
subpart D of part 9;
Move emergency calling requirements for TRS providers
(Sec. Sec. 64.604(a)(4) and 64.605) to subpart E of part 9;
Place proposed MLTS rules in subpart F of part 9;
Move emergency call center requirements for MSS providers
(Sec. 25.284) to subpart G of part 9; and
Move 911 resiliency, redundancy, and reliability
requirements (part 12) to subpart H of part 9.
In addition, as proposed in the NPRM, we remove Sec. 12.3, an
obsolete 911 rule that references a one-time information collection
that has been completed, rather than recodify it in part 9. The
Commission also sought comment on whether to move Sec. 22.921 of the
rules, which addresses 911 call processing procedures for analog
telephones in the Cellular Radiotelephone Service, into part 9 or
whether that rule has become obsolete and should be removed. As
proposed in the NPRM, we remove Sec. 22.921 as obsolete.
237. In proposing to consolidate the 911 rules, the Commission also
invited commenters to identify any other rules that should be
consolidated or updated. No commenters suggest additional rules for
consolidation, but some commenters suggest substantive rule changes.
Several of these suggestions concern 911 call routing issues.
Specifically, BRETSA suggests that the Commission should require MLTS
to be configured to route a 911 call to the PSAP serving the caller's
location to cover cases where a different PSAP serves the enterprise's
main office or location of the core MLTS equipment. MESB argues that
federal intervention and enforcement mechanisms are needed to ensure
accurate routing of 911 calls to the correct PSAP and accurate callback
number delivery to the PSAP, noting that state MLTS statutes have not
been successful in ensuring MLTS compliance with these requirements.
BRETSA also suggests that the Commission propose a ``forward-looking''
location rule that would require all devices (e.g., all types of
computers, tablets, and phones) used for voice, text, or video
communications to incorporate GPS chipsets and other location
technologies such as Wi-Fi, so that the devices are location-aware and
are able to route 911 calls to the appropriate PSAP. RedSky suggests
that the Commission should give telecommunications carriers the ability
to transmit a 911 call through a third party such as an incumbent local
exchange carrier, a VoIP Provisioning Center (VPC), its agent, or
directly to an Emergency Services IP Network (ESINet) or its agent,
rather than have to transmit a 911 call directly to a PSAP. In a
similar vein, Texas 9-1-1 Entities request that the Commission allow
911 calls to be routed through third-party call centers when
dispatchable location, geographic coordinates, or registered location
are not available. But MESB states that MLTS and VoIP 911 calls should
not be allowed to routinely route to national call centers rather than
the local serving PSAPs. BRETSA similarly states that Regional or
national call centers are not a permissible alternative to proper
configuration of an MLTS.
238. Commenters suggest several other miscellaneous rule changes.
Specifically, APCO suggests that the Commission should monitor
consumers' use of new technological platforms for communications, and
that the Commission consider further expanding the scope of the 911
rules to take into account such platforms and prevent subtle technology
distinctions from impacting communications with 911. Ad Hoc states that
the Commission should modify Sec. 9.11(b)(5)(iii), which requires
interconnected VoIP service providers to distribute stickers or other
appropriate labels warning subscribers if E911 service may be limited
or not available, to ``permit carriers to discharge their
`notification/warning label' obligations differently for enterprise
customers.'' BRETSA suggests an inquiry into 911 fees related to
digital broadband facilities connected to an MLTS. RedSky suggests that
the Commission should revisit consent decrees that an individual
carrier or service provider may have entered into with the FCC or other
body because such decrees ``serve to un-level the playing field.''
Next, RedSky, BRETSA, and APCO suggest modifying several terms in Sec.
9.3 definitions. RedSky and BRETSA also suggest amendments to several
definitions. Additionally, RedSky notes that several 911-related terms
are missing from the part 9 terms and definitions, and Texas 9-1-1
Entities proposes adding a term and definition. Finally, RedSky
suggests retitling some rule section headings.
239. While many of the suggestions described above may be worth
pursuing separately, we decline to address them in this proceeding. The
Commission stated that aside from the new MLTS and dispatchable
location rules and deleting obsolete rules, the rule
[[Page 66749]]
revisions in this proceeding would simply entail consolidating our
existing 911 rules without making substantive changes. Limited
exceptions would include certain conforming and technical changes, such
as harmonizing definitions of 911-related terms. We find that the
commenters' suggestions go well beyond the scope of issues the
Commission intended to address in this proceeding. We retain the
discretion to address elsewhere, and parties have the option to file
petitions for rulemaking or raise such issues in other appropriate
proceedings.
240. We do make ministerial conforming changes to certain other
rules in light of our decision to consolidate the existing 911 rules
into part 9. First, we found that part 1 contains several references to
Sec. 20.18, which is being moved to part 9 as the new Sec. 9.10.
Accordingly, we update those references to Sec. 9.10. Next, we found
that four rules have references to part 20 governing CMRS. Since part
20 will no longer cover CMRS 911 obligations after the relocation of
Sec. 20.18 to Sec. 9.10, we are adding a reference to part 9 to each
of the four rules to clarify the location of CMRS 911 rules. Since
these changes are ministerial in nature and facilitate the part 9 rule
consolidation, for which the Commission has already provided notice and
allowed for comment, we find for good cause that notice and comment are
unnecessary. Finally, we harmonize the Sec. 9.3 definition of
``Registered internet-based TRS user'' to conform with the recently
updated definition in part 64 of the Commission's rules. Because the
Commission's proposed Sec. 9.3 definition of ``Registered internet-
based TRS user'' is sourced from Sec. 64.601(a), and because the
Commission changed the definition in Sec. 64.601(a) in a proper
rulemaking proceeding, we find for good cause that notice and comment
to adopt the same definition change for part 9 are unnecessary.
IV. Procedural Matters
241. Final Regulatory Flexibility Analysis. As required by the
Regulatory Flexibility Act of 1980, as amended (RFA), the Commission
has prepared a Final Regulatory Flexibility Analysis (FRFA) relating to
this Report and Order. The FRFA is set forth in Appendix C.
242. Paperwork Reduction Act Analysis. The requirements in
Sec. Sec. 9.8(a) and 9.16(b)(3)(i), (ii) and (iii) constitute new
information collections subject to the Paperwork Reduction Act of 1995
(PRA), and the requirements in Sec. Sec. 9.8(a); 9.10(q)(10)(v);
9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4); 9.11(b)(5)(ii); (iii);
9.14(d)(2)(ii); (iii); 9.14(d)(2)(v); 9.14(d)(4); 9.14(e)(2)(ii);
9.14(e)(2)(iv); 9.14(e)(4); 9.16(b)(3)(i); (ii); and (iii) constitute
modified information collections. They will be submitted to the Office
of Management and Budget (OMB) for review under section 3507(d) of the
PRA. OMB, the general public, and other Federal agencies will be
invited to comment on the new information collection requirements
contained in this proceeding. This document will be submitted to OMB
for review under section 3507(d) of the PRA. In addition, we note that,
pursuant to the Small Business Paperwork Relief Act of 2002, we
previously sought, but did not receive, specific comment on how the
Commission might further reduce the information collection burden for
small business concerns with fewer than 25 employees. We describe
impacts that might affect small businesses, which includes more
businesses with fewer than 25 employees, in the Final Regulatory
Flexibility Analysis in Appendix C.
243. Congressional Review Act. The Commission has determined that
these rules are non-major under the Congressional Review Act, 5 U.S.C.
804(2). The Commission will send a copy of this Report and Order to
Congress and the Government Accountability Office pursuant to 5 U.S.C.
801(a)(1)(A).
244. Further Information. For further information, contact Brenda
Boykin, Attorney-Advisor, Policy and Licensing Division, Public Safety
and Homeland Security Bureau, (202) 418-2062 or via email at
[email protected]; William Beckwith, Attorney-Advisor, Policy and
Licensing Division, Public Safety and Homeland Security Bureau, (202)
418-0134 or via email at [email protected]; Thomas Eng,
Engineer, Policy and Licensing Division, Public Safety and Homeland
Security Bureau, (202) 418-0019 or via email at [email protected]; Dr.
Rasoul Safavian, Technologist, Policy and Licensing Division, Public
Safety and Homeland Security Bureau, (202) 418-0754 or via email at
[email protected].
V. Final Regulatory Flexibility Analysis
245. As required by the Regulatory Flexibility Act of 1980, as
amended (RFA), an Initial Regulatory Flexibility Analysis (IRFAs) was
incorporated in the Notice of Proposed Rulemaking adopted in September
2018 (NPRM). The Commission sought written public comment on the
proposals in the NPRM including comment on the IRFA. The Comments
received are discussed below. This Final Regulatory Flexibility
Analysis (FRFA) conforms to the RFA.
A. Need for, and Objectives of, the Report and Order
246. In the Report and Order, the Commission advances Congressional
and Commission objectives to ensure that members of the public can
successfully dial 911 to request emergency services and that Public
Safety Answering Points (PSAPs) can quickly and accurately locate every
911 caller, regardless of the type of service that is used to make the
call. In 2018, the President signed into law Kari's Law Act of 2017
(Kari's Law), which requires implementation of direct 911 dialing and
on-site notification capabilities in a multi-line telephone system
(MLTS), and Section 506 of RAY BAUM'S Act (RAY BAUM'S Act), which
requires the Commission, within 18 months after the date of the
legislation's enactment (March 23, 2018), to ``conclude a proceeding to
consider adopting rules to ensure that the dispatchable location is
conveyed with a 9-1-1 call, regardless of the technological platform
used and including with calls from [MLTS].''
247. The Report and Order implements Kari's Law by adopting direct
dial and on-site notification rules governing calls to 911 made from a
MLTS. The Commission takes the following actions:
Adopts 911 direct dialing requirements as proposed in the
NPRM, subject to clarification of some definitions and terms, including
the term pre-configured.
adopts a requirement that notification be sent to a
location where someone is likely to hear or see it, but we do not
require the location to be continuously staffed or monitored.
requires the notification to include the fact that a 911
call has been made, a valid callback number, and the same location
information that is conveyed with the call to 911. However, we provide
an exception for callback number and location information in
circumstances where including this information in the notification
would be technologically infeasible. We also require that initiation of
the notification be contemporaneous with the call to 911, provided that
it is technologically feasible to do so.
requires an MLTS to be configured to provide notification
for any caller on the system, including callers at satellite or branch
locations.
adopts the statutory definition of MLTS cited in Kari's
Law and RAY BAUM'S Act. In addition, we interpret this definition to
cover the full range of networked communications systems
[[Page 66750]]
that serve enterprises, including IP-based and cloud-based systems. We
also interpret the definition to include outbound-only MLTS systems
that allow users to make 911 calls but do not enable PSAPs to place a
return call directly to the 911 caller.
establishes February 16, 2020 as the compliance date for
regulations implementing Kari's Law.
adopts a presumption that if an MLTS fails to comply with
the rules, the MLTS manager is responsible unless the manager can rebut
the presumption by demonstrating compliance with its obligations under
the statute and rules.
declines to adopt disclosure requirements for legacy MLTS
that are not subject to the requirements of Kari's Law and instead
encourage enterprises to disclose the limitations on dialing 911 from
legacy MLTS as part of voluntary best practices.
248. As required by RAY BAUM'S Act, the Commission considered the
feasibility of requiring dispatchable location for 911 calls from MLTS
and other technological platforms that currently complete calls to 911,
and established a dispatchable location requirement for MLTS 911 calls.
In keeping with the directive in RAY BAUM'S Act to address dispatchable
location for 911 calls ``regardless of the technological platform
used,'' the Report and Order adds dispatchable location requirements to
the Commission's existing 911 rules for fixed telephony providers,
interconnected Voice over Internet Protocol (VoIP), Telecommunications
Relay Services (TRS), Video Relay Services (VRS), and mobile text.
Finally, consistent with RAY BAUM'S Act, we do not make any changes to
the Commission's existing rules for CMRS providers to provide
dispatchable location.
249. More specifically, consistent with RAY BAUM'S Act the
Commission adopts the following definition of dispatchable location and
alternative location information:
Dispatchable Location. A location delivered to the PSAP
with a 911 call that consists of the validated street address of the
calling party, plus additional information such as suite, apartment or
similar information necessary to adequately identify the location of
the calling party, except for Commercial Mobile Radio Service
providers, which shall convey the location information required by our
existing rules.
250. For MLTS systems subject to Kari's Law, we separately address
dispatchable location requirements for MLTS 911 calls from (1) fixed
devices and non-fixed devices being used on-premises, and (2) non-fixed
devices being used off-premises. Accordingly, the Commission adopts the
following dispatchable location rules:
[cir] MLTS 911 calls from fixed devices: One year after the
effective date of the rules, MLTS must provide automated dispatchable
location with each 911 call.
[cir] MLTS 911 calls from non-fixed devices:
[cir] On-premises MLTS 911 calls from non-fixed devices: Two years
after the effective date of the rules, MLTS must provide (1) automated
dispatchable location, if technically feasible, or, otherwise, either
(2) end-user manually-updated dispatchable location, or (3) alternative
location information, which may be coordinate-based, sufficient to
identify the caller's civic address and approximate in-building
location, including floor level, in large buildings.
[cir] Off-premises MLTS 911 calls from off-premises devices: Two
years after the effective date of the rules, MLTS must provide (1)
automated dispatchable location, if technically feasible, or, if
otherwise, either (2) end-user manually-updated dispatchable location,
or (3) enhanced location information, which may be coordinate-based,
consisting of the best available location that can be obtained from any
available technology or combination of technologies at reasonable cost.
251. For other services currently subject to 911 requirements
(Fixed Telephony, Interconnected Voice over Internet Protocol (VoIP),
Telecommunications Relay Service (TRS) and mobile text, the Commission
adopts the following requirements:
[cir] Fixed Telephony: One year after the effective date of the
rules, service providers must deliver automated dispatchable location
with each 911 call.
[cir] Interconnected VoIP:
[cir] Fixed interconnected VoIP: One year after the effective date
of the rules, service providers must deliver automated dispatchable
location with each 911 call or Registered Location. Dispatchable
location may be provided by means of a customer-generated Registered
Location, under the same terms and conditions specified in our current
VoIP 911 rules, or by automatic provision of dispatchable location by
the VoIP service provider, without additional action by the caller, at
the time the 911 call is made.
[cir] Non-fixed interconnected VoIP: Two years after the effective
date of the rules, service providers must provide (1) automated
dispatchable location, if technically feasible, or, otherwise, either
(2) manual updating of Registered Location information, or (3)
alternative location information, which may be coordinate-based,
sufficient to identify the caller's civic address and approximate in-
building location, including floor level, in large buildings. If the
provider is unable to obtain or confirm the caller's location, the
provider may route the call to a national emergency call center.
[cir] Outbound-only interconnected VoIP: For purposes of compliance
with our 911 rules, we amend the definition of ``Interconnected VoIP
Service'' in Sec. 9.3 of the Commission's rules to include ``outbound-
only'' interconnected VoIP services that permit users generally to
terminate calls to the public switched telephone network and extend the
Interconnected VoIP location requirements described above to such
providers.
Telecommunications Relay Services
[cir] Fixed TRS: One year after the effective date of the rules,
service providers must deliver automated dispatchable location with
each 911 call.
[cir] Non-fixed TRS: Two years after the effective date of the
rules, service providers must provide (1) automated dispatchable
location, if technically feasible, or, otherwise, either (2) manual
updating of Registered Location information, or (3) alternative
location information sufficient to identify the caller's civic address
and approximate in-building location, including floor level, in large
buildings. If the provider is unable to obtain or confirm the caller's
location, the provider may route the call to a national emergency call
center.
Mobile Text: Two years after the effective date of the
rules, covered text providers must provide (1) automated dispatchable
location, if technically feasible, or, otherwise, either (2) end-user
manually provisioned location information, or (3) enhanced location
information consisting of the best available location that can be
obtained from any available technology or combination of technologies
at reasonable cost.
252. Lastly, as the Commission proposed in the NPRM, the Report and
Order consolidates the Commission's existing 911 rules, and the direct
dialing and dispatchable location rules proposed in the NPRM, into a
single rule part. The Commission historically has taken a service-
specific approach to 911, with the result that 911 requirements for
different services are scattered across different sections of the
agency's rules. Consolidating our 911 rules from these various rule
sections
[[Page 66751]]
into a single rule part furthers the goal of recognizing that all the
components of 911 function as part of a single system and enables
service providers, emergency management officials, and other
stakeholders to refer to a single part of the Commission's rules to
more easily ascertain all 911 requirements.
B. Summary of Significant Issues Raised by Public Comments in Response
to the IRFA
253. There were no comments that specifically addressed the
proposed rules and policies presented in the IRFA.
C. Response to Comments by the Chief Counsel for Advocacy of the Small
Business Administration
254. Pursuant to the Small Business Jobs Act of 2010, which amended
the RFA, the Commission is required to respond to any comments filed by
the Chief Counsel for Advocacy of the Small Business Administration
(SBA), and to provide a detailed statement of any change made to the
proposed rules as a result of those comments.
255. The Chief Counsel did not file any comments in response to the
proposed rules in this proceeding.
D. Description and Estimate of the Number of Small Entities to Which
the Rules Will Apply
256. The RFA directs agencies to provide a description of, and
where feasible, an estimate of the number of small entities that may be
affected by the rule changes. The RFA generally defines the term
``small entity'' as having the same meaning as the terms ``small
business,'' ``small organization,'' and ``small governmental
jurisdiction.'' In addition, the term ``small business'' has the same
meaning as the term ``small business concern'' under the Small Business
Act. A ``small business concern'' is one that: (1) Is independently
owned and operated; (2) is not dominant in its field of operation; and
(3) satisfies any additional criteria established by the SBA.
257. Multi-Line Telephone System Manufacturers, Importers, Sellers
or Lessors. Neither the Commission nor the SBA has developed a specific
small business size standard for MLTS manufacturers, importers, sellers
or lessors. The closest applicable SBA category for entities
manufacturing MLTS equipment used to provide wire telephone and data
communications equipment, interconnected VoIP, non-interconnected VoIP,
is Telephone Apparatus Manufacturing. The SBA size standard for
Telephone Apparatus Manufacturing consists of all such companies having
1,250 or fewer employees. U.S. Census Bureau data for 2012 show that
there were 266 establishments that operated that year. Of this total,
262 operated with fewer than 1,000 employees. Thus, under this size
standard, the majority of firms in this industry can be considered
small.
258. Telephone Apparatus Manufacturing. This industry comprises
establishments primarily engaged in manufacturing wire telephone and
data communications equipment. These products may be stand-alone or
board-level components of a larger system. Examples of products made by
these establishments are central office switching equipment, cordless
and wire telephones (except cellular), PBX equipment, telephone
answering machines, LAN modems, multi-user modems, and other data
communications equipment, such as bridges, routers, and gateways. The
SBA has developed a small business size standard for Telephone
Apparatus Manufacturing, which consists of all such companies having
1,250 or fewer employees. U.S. Census Bureau data for 2012 show that
there were 266 establishments that operated that year. Of this total,
262 operated with fewer than 1,000 employees. Thus, under this size
standard, the majority of firms in this industry can be considered
small.
259. Multi-Line Telephone System Operators, Installers and
Managers. Neither the Commission nor the SBA has developed a specific
small business size standard for MLTS operators, installers and
managers. MLTS Operators, Installers and Managers cut across numerous
industry segments and encompass all types of businesses and
organization including for-profit, not-for-profit and government
agencies. Thus, for purposes of this FRFA, we group entities operating,
installing, and managing MLTS in the Small Businesses, Small
Organizations and Small Government Jurisdictions description contained
in paragraph 21 infra.
260. All Other Telecommunications. The ``All Other
Telecommunications'' category is comprised of establishments primarily
engaged in providing specialized telecommunications services, such as
satellite tracking, communications telemetry, and radar station
operation. This industry also includes establishments primarily engaged
in providing satellite terminal stations and associated facilities
connected with one or more terrestrial systems and capable of
transmitting telecommunications to, and receiving telecommunications
from, satellite systems. Establishments providing internet services or
voice over internet protocol (VoIP) services via client-supplied
telecommunications connections are also included in this industry. The
SBA has developed a small business size standard for All Other
Telecommunications, which consists of all such firms with annual
receipts of $32.5 million or less. For this category, U.S. Census
Bureau data for 2012 show that there were 1,442 firms that operated for
the entire year. Of those firms, a total of 1,400 had annual receipts
less than $25 million and 15 firms had annual receipts of $25 million
to $49,999,999. Thus, the Commission estimates that the majority of
``All Other Telecommunications'' firms potentially affected by our
action can be considered small.
261. Computer Facilities Management Services. This industry
comprises establishments primarily engaged in providing on-site
management and operation of clients' computer systems and/or data
processing facilities. Establishments providing computer systems or
data processing facilities support services are included in this
industry. The SBA has developed a small business size standard for
Computer Facilities Management Services which consists of all such
firms with annual receipts of $27.5 million or less. U.S. Census Bureau
data for 2012 indicate that 4,828 firms operated the entire year. Of
this total, 4,743 had annual receipts less than $25 million and 38
firms had annual receipts of $25 million to $49,999,999. Thus, under
the SBA size standard the majority of firms in this industry can be
considered small.
262. Other Computer Related Services (Except Information Technology
Value Added Resellers). This industry comprises establishments
primarily engaged in providing computer related services (except custom
programming, systems integration design, and facilities management
services). Establishments providing computer disaster recovery services
or software installation services are included in this industry. The
SBA has developed a small business size standard for Other Computer
Related Services, which consists of all such firms with annual receipts
of $27.5 million or less. For this category, U.S. Census Bureau data
for 2012 indicate that 6,354 firms operated the entire year. Of this
total, 6,266 had annual receipts less than $25 million and 42 firms had
annual receipts of $25 million to $49,999,999. Thus, the Commission
estimates that the majority of Other Computer Related Services firms in
this industry can be considered small.
[[Page 66752]]
263. Information Technology Value Added Resellers. Information
Technology Value Added Resellers provide a total solution to
information technology acquisitions by providing multi-vendor hardware
and software along with significant value added services. Significant
value added services consist of, but are not limited to, configuration
consulting and design, systems integration, installation of multi-
vendor computer equipment, customization of hardware or software,
training, product technical support, maintenance, and end user support.
The SBA has developed a small business size standard for Information
Technology Value Added Resellers which consists of all such companies
having 150 or fewer employees. For this category, U.S. Census Bureau
data for 2012 indicate that 6,354 firms operated the entire year. Of
this total, 6,241 had less than 100 employees and 113 had 100-1,000 or
more employees. Thus, the Commission estimates that the majority of
Information Technology Value Added Resellers in this industry can be
considered small.
264. Data Processing, Hosting, and Related Services. This industry
comprises establishments primarily engaged in providing infrastructure
for hosting or data processing services. These establishments may
provide specialized hosting activities, such as Web hosting, streaming
services, or application hosting (except software publishing), or they
may provide general time-share mainframe facilities to clients. Data
processing establishments provide complete processing and specialized
reports from data supplied by clients or provide automated data
processing and data entry services. The SBA has developed a small
business size standard for Data Processing, Hosting, and Related
Services which consists of all such firms with annual receipts of $32.5
million or less. U.S. Census Bureau data for 2012 indicate that 8,252
firms operated the entire year. Of this total, 7,730 had annual
receipts less than $25 million and 228 firms had annual receipts of $25
million to $49,999,999. Thus, under this size standard the majority of
firms in this industry are small businesses.
265. Small Businesses, Small Organizations, Small Governmental
Jurisdictions. Our actions, over time, may affect small entities that
are not easily categorized at present. We therefore describe here, at
the outset, three comprehensive small entity size standards that could
be directly affected herein. First, while there are industry specific
size standards for small businesses that are used in the regulatory
flexibility analysis, according to data from the SBA's Office of
Advocacy, in general a small business is an independent business having
fewer than 500 employees. These types of small businesses represent
99.9% of all businesses in the United States which translates to 28.8
million businesses.
266. Next, the type of small entity described as a ``small
organization'' is generally ``any not-for-profit enterprise which is
independently owned and operated and is not dominant in its field.''
Nationwide, as of August 2016, there were approximately 356,494 small
organizations based on registration and tax data filed by nonprofits
with the Internal Revenue Service (IRS).
267. Finally, the small entity described as a ``small governmental
jurisdiction'' is defined generally as ``governments of cities,
counties, towns, townships, villages, school districts, or special
districts, with a population of less than fifty thousand.'' U.S. Census
Bureau data from the 2012 Census of Governments indicate that there
were 90,056 local governmental jurisdictions consisting of general
purpose governments and special purpose governments in the United
States. Of this number there were 37, 132 General purpose governments
(county, municipal and town or township) with populations of less than
50,000 and 12,184 Special purpose governments (independent school
districts and special districts) with populations of less than 50,000.
The 2012 U.S. Census Bureau data for most types of governments in the
local government category show that the majority of these governments
have populations of less than 50,000. Based on these data we estimate
that at least 49,316 local government jurisdictions fall in the
category of ``small governmental jurisdictions.''
268. Wired Telecommunications Carriers. The U.S. Census Bureau
defines this industry as ``establishments primarily engaged in
operating and/or providing access to transmission facilities and
infrastructure that they own and/or lease for the transmission of
voice, data, text, sound, and video using wired communications
networks. Transmission facilities may be based on a single technology
or a combination of technologies. Establishments in this industry use
the wired telecommunications network facilities that they operate to
provide a variety of services, such as wired telephony services,
including VoIP services, wired (cable) audio and video programming
distribution, and wired broadband internet services. By exception,
establishments providing satellite television distribution services
using facilities and infrastructure that they operate are included in
this industry.'' The SBA has developed a small business size standard
for Wired Telecommunications Carriers, which consists of all such
companies having 1,500 or fewer employees. U.S. Census Bureau data for
2012 show that there were 3,117 firms that operated that year. Of this
total, 3,083 operated with fewer than 1,000 employees. Thus, under this
size standard, the majority of firms in this industry can be considered
small.
269. Local Exchange Carriers (LECs). Neither the Commission nor the
SBA has developed a size standard for small businesses specifically
applicable to local exchange services. The closest applicable NAICS
Code category is for Wired Telecommunications Carriers. Under the
applicable SBA size standard size standard, such a business is small if
it has 1,500 or fewer employees. U.S. Census Bureau data for 2012 show
that there were 3,117 firms that operated for the entire year. Of this
total, 3,083 operated with fewer than 1,000 employees. Thus, under this
category and the associated size standard, the Commission estimates
that the majority of local exchange carriers are small entities.
270. Incumbent Local Exchange Carriers (Incumbent LECs). Neither
the Commission nor the SBA has developed a small business size standard
specifically for incumbent local exchange services. The closest
applicable NAICS Code category is Wired Telecommunications Carriers.
Under the applicable SBA size standard, such a business is small if it
has 1,500 or fewer employees. According to U.S. Census Bureau data,
3,117 firms operated the entire year. Of this total, 3,083 operated
with fewer than 1,000 employees. Consequently, the Commission estimates
that most providers of incumbent local exchange service are small
businesses that may be affected by the rules and policies adopted.
According to Commission data, one thousand three hundred and seven
(1,307) Incumbent Local Exchange Carriers reported that they were
incumbent local exchange service providers. Of this total, an estimated
1,006 have 1,500 or fewer employees. Thus, using the SBA's size
standard the majority of incumbent LECs can be considered small
entities.
271. Competitive Local Exchange Carriers (Competitive LECs),
Competitive Access Providers (CAPs), Shared-Tenant Service Providers,
and Other Local Service Providers. Neither the Commission nor the SBA
has developed a small business size
[[Page 66753]]
standard specifically for these service providers. The appropriate
NAICS Code category is Wired Telecommunications Carriers. Under that
size standard, such a business is small if it has 1,500 or fewer
employees. U.S. Census Bureau data for 2012 indicate that 3,117 firms
operated during that year. Of that number, 3,083 operated with fewer
than 1,000 employees. Based on these data, the Commission concludes
that the majority of Competitive LECs, CAPs, Shared-Tenant Service
Providers, and Other Local Service Providers are small entities.
According to Commission data, 1,442 carriers reported that they were
engaged in the provision of either competitive local exchange services
or competitive access provider services. Of these 1,442 carriers, an
estimated 1,256 have 1,500 or fewer employees. In addition, 17 carriers
have reported that they are Shared-Tenant Service Providers, and all 17
are estimated to have 1,500 or fewer employees. In addition, 72
carriers have reported that they are Other Local Service Providers. Of
this total, 70 have 1,500 or fewer employees. Consequently, the
Commission estimates that most providers of competitive local exchange
service, competitive access providers, Shared-Tenant Service Providers,
and Other Local Service Providers are small entities.
272. Interexchange Carriers (IXCs). Neither the Commission nor the
SBA has developed a definition for Interexchange Carriers. The closest
NAICS Code category is Wired Telecommunications Carriers. The
applicable size standard under SBA rules is that such a business is
small if it has 1,500 or fewer employees. U.S. Census Bureau data for
2012 indicate that 3,117 firms operated for the entire year. Of that
number, 3,083 operated with fewer than 1,000 employees. According to
internally developed Commission data, 359 companies reported that their
primary telecommunications service activity was the provision of
interexchange services. Of this total, an estimated 317 have 1,500 or
fewer employees. Consequently, the Commission estimates that the
majority of interexchange service providers are small entities.
273. Local Resellers. The SBA has developed a small business size
standard for Telecommunications Resellers which includes Local
Resellers. The Telecommunications Resellers industry comprises
establishments engaged in purchasing access and network capacity from
owners and operators of telecommunications networks and reselling wired
and wireless telecommunications services (except satellite) to
businesses and households. Establishments in this industry resell
telecommunications; they do not operate transmission facilities and
infrastructure. Mobile virtual network operators (MVNOs) are included
in this industry. Under the SBA's size standard, such a business is
small if it has 1,500 or fewer employees. U.S. Census Bureau data for
2012 show that 1,341 firms provided resale services for the entire
year. Of that number, all operated with fewer than 1,000 employees.
Thus, under this category and the associated small business size
standard, the majority of these resellers can be considered small
entities. According to Commission data, 213 carriers have reported that
they are engaged in the provision of local resale services. Of these,
an estimated 211 have 1,500 or fewer employees. Consequently, the
Commission estimates that the majority of Local Resellers are small
entities.
274. Wireless Telecommunications Carriers (except Satellite). This
industry comprises establishments engaged in operating and maintaining
switching and transmission facilities to provide communications via the
airwaves. Establishments in this industry have spectrum licenses and
provide services using that spectrum, such as cellular services, paging
services, wireless internet access, and wireless video services. The
appropriate size standard under SBA rules is that such a business is
small if it has 1,500 or fewer employees. For this industry, U.S.
Census Bureau data for 2012 show that there were 967 firms that
operated for the entire year. Of this total, 955 firms had had
employment of 999 or fewer employees and 12 had employment of 1000
employees or more. Thus, under this category and the associated size
standard, the Commission estimates that the majority of wireless
telecommunications carriers (except satellite) are small entities.
275. The Commission's own data--available in its Universal
Licensing System--indicate that, as of August 31, 2018 there are 265
Cellular licensees that will be affected by our proposed actions. The
Commission does not know how many of these licensees are small, as the
Commission does not collect that information for these types of
entities. Similarly, according to internally developed Commission data,
413 carriers reported that they were engaged in the provision of
wireless telephony, including cellular service, Personal Communications
Service (PCS), and Specialized Mobile Radio (SMR) Telephony services.
Of this total, an estimated 261 have 1,500 or fewer employees, and 152
have more than 1,500 employees. Thus, using available data, we estimate
that the majority of wireless firms can be considered small.
276. Wireless Communications Services. This service can be used for
fixed, mobile, radiolocation, and digital audio broadcasting satellite
uses. The Commission defined ``small business'' for the wireless
communications services (WCS) auction as an entity with average gross
revenues of $40 million for each of the three preceding years, and a
``very small business'' as an entity with average gross revenues of $15
million for each of the three preceding years. The SBA has approved
these small business size standards. In the Commission's auction for
geographic area licenses in the WCS there were seven winning bidders
that qualified as ``very small business'' entities, and one that
qualified as a ``small business'' entity.
277. Wireless Telephony. Wireless telephony includes cellular,
personal communications services, and specialized mobile radio
telephony carriers. The closest applicable SBA category is Wireless
Telecommunications Carriers (except Satellite). Under the SBA small
business size standard a business is small if it has 1,500 or fewer
employees. For this industry, U.S. Census Bureau data for 2012 show
that there were 967 firms that operated for the entire year. Of this
total, 955 firms had fewer than 1,000 employees and 12 firms has 1000
employees or more. Thus under this category and the associated size
standard, the Commission estimates that a majority of these entities
can be considered small. According to Commission data, 413 carriers
reported that they were engaged in wireless telephony. Of these, an
estimated 261 have 1,500 or fewer employees and 152 have more than
1,500 employees. Therefore, more than half of these entities can be
considered small.
E. Description of Projected Reporting, Recordkeeping, and Other
Compliance Requirements for Small Entities
278. The Report and Order enacts rules that will affect the
reporting, recordkeeping, and/or other compliance requirements of small
businesses and enterprises of all sizes that are engaged in the
business of manufacturing, importing, selling, leasing, installing,
managing, or operating MLTS, provided that the MLTS is manufactured,
imported, offered for first sale or lease, first sold or leased, or
installed after February 16, 2020. The Report and
[[Page 66754]]
Order will also affect small businesses and enterprises that are
engaged in the business of offering fixed telephony service, wireless
telecommunications, interconnected VoIP service, and TRS. The
Commission adopted these changes to implement Kari's Law and RAY BAUM'S
Act, which collectively address the inability of callers to directly
dial 911 from MLTS and a lack of accurate and critical location
information necessary for a PSAP to dispatch emergency services to
those in need because of the communications system used in making a 911
call.
279. The rules and compliance requirements the Commission adopted
to implement the direct dialing and notification requirements of Kari's
Law sought to balance the needs of stakeholders and maximize the public
safety benefits. These benefits include potentially preventing
fatalities, injuries, or property damage, improving emergency response
time and access to emergency services, reducing delays in locating 911
callers, narrowing the gap between MLTS 911 service capabilities
relative to other communications services subject to 911 requirements,
and driving further technology development. The Commission also sought
to achieve the benefits of Kari's Law in a cost-effective manner. As a
result, the rules adopted generally track the statutory requirements of
Kari's Law, are technologically neutral, and leverage advances in
technology to improve access to emergency services as envisioned by
Congress.
280. The adopted rules provide small businesses and other
enterprises impacted by these requirements wide flexibility and adopt
minimum criteria in direct dialing and notification requirements which
should offset any potential burdens associated with compliance with our
rules.
281. Consistent with Kari's Law, the Commission establishes
February 16, 2020, as the compliance date for regulations implementing
Kari's Law. It declines to adopt disclosure requirements for legacy
MLTS but, instead, encourages industry to consider disclosure and
education as part of voluntary best practices. The Commission also
adopts a presumption that if an MLTS fails to comply with the rules,
the MLTS manager is responsible unless the manager can rebut the
presumption by demonstrating compliance with its obligations under the
statute and rules.
282. Similar to its approach to implement the requirements of
Kari's Law, the Commission sought to craft dispatchable location rules
that leverage existing market-driven advances in technology to improve
location accuracy, and that provide small businesses and others
significant flexibility, are technology neutral, encourage innovation
and allow a wide array of options to for compliance while minimizing
the compliance burden and cost. Given the lack of cost data submitted
in the record for meeting our 911 location rules or MLTS direct dialing
and notification requirements, and in light of our flexible and
technologically neutral approach to compliance, we do not believe
compliance with these requirements will impose a significant economic
burden for small businesses.
283. Similarly, we do not believe that the new or modified
information collection requirements in Sec. Sec. 9.8(a);
9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4);
9.11(b)(5)(ii); (iii); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v);
9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); 9.16(b)(3)(i);
(ii); and (iii), will be unduly burdensome on small businesses. Rather
than unduly burden small entities, applying the new and modified
information collections will promote 911 service and emergency
response, which should benefit small governmental jurisdictions, small
businesses, small equipment manufacturers, and small business
associations by giving them greater confidence in 911 location
accuracy. Moreover, the rules we adopt in the Report and Order provide
regulatory flexibility to all entities, including small businesses, and
encourage service providers to leverage technology to the extent
possible to reduce the burden of the information collections adopted in
the Report and Order. Additionally, the Report and Order establishes a
one- to two-year period from the effective date of the rules before
requiring compliance with the revised rules. We provide the following
analysis:
284. For compliance with the Commission's 911 requirements,
interconnected VoIP service providers must collect and disclose certain
information to third parties. OMB approved the information collection
for Sec. 9.5 (redesignated Sec. 9.11) under OMB Control No. 3060-
1085. This collection applies to interconnected VoIP providers
obtaining and updating registered location from their customers and
placing that information into ALI databases. This collection also
applies to interconnected VoIP providers' customer notification
obligations. The Commission modifies the definition of interconnected
VoIP, thus potentially increasing the number of respondents subject to
these existing information collections. The Commission also changes the
wording of Sec. 9.11's registered location requirements to facilitate
the provision of automated dispatchable location, registered location,
or alternative location information for 911 calls. Thus, we anticipate
the burden and cost levels of these requirements would be comparable to
the existing Registered Location and customer notification
requirements, which OMB approved.
285. TRS service providers must collect and disclose certain
information to third parties for compliance with the Commission's 911
rules. OMB approved the information collection for Sec. 64.604
(redesignated as Sec. 9.14) under OMB Control No. 3060-1089. This
collection applies to TRS service providers transmitting location
information to the PSAP, making location information available to the
appropriate PSAP through the ALI database, and obtaining location
information from the user. The Commission makes changes to the wording
of Sec. 9.14's registered location requirements to facilitate the
provision of automated dispatchable location, registered location, or
alternative location information for 911 calls. Thus, we anticipate the
burden and cost levels of these requirements would be comparable to the
existing location requirements, which OMB approved.
286. Covered text providers must notify consumers that they must
grant permission to covered text providers to access the device's
location information to enable the delivery and routing of text
messages to PSAPs (i.e. Text-to-911) under Sec. 20.18 (redesignated as
9.10). OMB renewed the information collection under OMB Control No.
3060-1204, ICR Reference No: 201802-3060-012. In this Report and Order,
the Commission makes changes to the wording of Sec. 9.10's text-to-911
requirements to facilitate the provision of dispatchable location or
best available location information along with 911 text messages. Thus,
we anticipate the burden and cost levels of these requirements will
require covered text providers to update customer notification at a
cost that would be comparable to the existing text-to-911 requirements,
which OMB approved.
287. Finally, new Sec. 9.8 requires providers of fixed telephony
services to provide automated dispatchable location with 911 calls
beginning one year after the effective date of this rule. Additionally,
new Sec. 9.16(b)(3)(i), (iii) and (iii) specifies dispatchable
location requirements for on-premises fixed telephones; on premises
non-fixed devices; and off-premises devices associated with a multi-
line telephone system. The Report and Order reflects
[[Page 66755]]
that the costs to implement these requirements would be minimal. For
purposes of estimating projected costs to small businesses, we find
that the costs would be comparable to the costs CMRS service providers
incur in delivering uncompensated barometric pressure data, which OMB
approved under OMB Control No. 3060-1210, ICR Reference No: 201801-
3060-010. Current rule Sec. 20.18 (redesignated as Sec. 9.10)
requires that CMRS providers shall deliver uncompensated barometric
pressure data from any device capable of delivering such data to PSAPs.
The Commission stated that the furnishing of this information to PSAPs
is necessary to ensure that PSAPs are receiving all location
information possible to be used for dispatch.
F. Steps Taken To Minimize the Significant Economic Impact on Small
Entities, and Significant Alternatives Considered
288. The RFA requires an agency to describe any significant,
specifically small business alternatives, that it has considered in
reaching its approach, which may include the following four
alternatives (among others): (1) The establishment of differing
compliance or reporting requirements or timetables that take into
account the resources available to small entities; (2) the
clarification, consolidation, or simplification of compliance or
reporting requirements under the rule for small entities; (3) the use
of performance, rather than design, standards; and (4) an exemption
from coverage of the rule, or any part thereof, for small entities. To
minimize any significant impact on small businesses, the Commission
establishes a longer timetable for compliance timetable than that
proposed in the NPRM relative to dispatchable location requirements.
The Report and Order clarifies that the rules are flexible and
technologically neutral so that small businesses may choose from a
broad array of options to comply with the Commission's rules. We
provide the following analysis of our rules.
289. Direct Dialing and Notification Requirements for a Multi-Line
Telephone System. The Commission takes a number of steps in the Report
and Order to provide flexibility and reduce costs for small businesses
and other enterprises. As a preliminary matter, Kari's Law provides
that the central notification requirements of the statute apply only if
the MLTS can be configured to provide notification ``without an
improvement to the hardware or software of the system.'' The
legislative history of Kari's Law notes that this provision is intended
to ``balance the need for an onsite notification with the goal of not
placing an undue burden on MLTS owners or operators.'' The Commission
adopts rules to implement and clarify this provision.
290. The Commission requires the notification to include the fact
that a 911 call has been made, a valid callback number, and the same
location information that is conveyed with the call to 911. However,
the Commission also provides an exception for callback number and
location information in circumstances where including this information
in the notification would be technologically infeasible. In addition,
the Commission requires that initiation of the notification be
contemporaneous with the call to 911, conditioned on whether it is
technologically feasible to do so. The Commission also requires that
notifications be sent to a location where someone is likely to hear or
see the notification but does not require the location to be
continuously staffed or monitored. The absence of a continuous staffing
or monitoring requirement minimizes a potentially significant cost for
small businesses. The Report and Order also clarifies that an MLTS must
be configured to provide notification for any caller on the system,
including callers at satellite or branch locations. These requirements
are highly flexible and give enterprises, including small businesses,
significant latitude to configure suitable notification mechanisms
without unreasonable burden or cost.
291. Consistent with Kari's Law, the Commission establishes
February 16, 2020, as the compliance date for the regulations
implementing the statute. The Commission also affords all entities
flexibility, including small businesses, to come into compliance with
the notification requirements of Kari's Law. This should give
enterprises, including small businesses, sufficient advance notice to
make informed manufacturing, planning, and purchasing decisions. In
addition, because the statute and regulations apply to MLTS that are
manufactured, imported, offered for first sale or lease, first sold or
leased, or installed after February 16, 2020, enterprises have the
flexibility to retain an existing MLTS until the end of its useful life
should they choose to do so. The Commission declines to adopt
disclosure requirements for existing MLTS and, instead, encourages
industry to consider disclosure and education as part of voluntary best
practices. This avoids ``one-size-fits-all'' disclosure requirements
and allows enterprises the flexibility to disclose the limitations of
calling 911 from legacy MLTS in a way that makes sense for their
particular business.
292. Dispatchable Location. In the Report and Order, the Commission
adopts rules to implement the dispatchable location requirements that
are measured, technologically neutral and include a phased-in
compliance timetable in order to minimize implementation costs, and
leverage technological advances. The Commission's measured approach
seeks to minimize costs and burdens for small businesses and other
enterprises where possible, while providing these MLTS and
communications service providers significant flexibility to comply with
the rules adopted. For example, small businesses can take advantage of
the option for MLTS and other communication service providers subject
to 911 requirements that are unable to provide a dispatchable location
consistent with the rules adopted in the Report and Order, to elect to
provide alternative location information, and incur minimal to no
implementation costs as a result. Moreover, the Commission's decision
not to mandate any particular technology or model for implementing the
911 location rules gives small businesses the ability choose a
compliance approach that best fits their economic circumstances.
Because delivering dispatchable location is already technically
feasible for many services today, MLTS and other service providers
subject to our 911 location rules need only choose the methods
necessary to close the gap between already-deployed capabilities and
the Commission's requirements, ``rather than starting from scratch''
which should prove less costly for small businesses. Similarly, the
Commission's decision to implement a phased-in approach for compliance
and to tailor compliance deadlines to particular technologies rather
than adopting a hard and fast, ``one size fits all'' approach takes
into account the needs of small businesses for flexibility and a longer
compliance timeframe. Additionally, by apply the adopted rules on a
prospective basis, the Commission will minimize costs for small
businesses and legacy MLTS systems.
293. Finally, the Commission considered adopting a small business
exemption for our dispatchable location requirements but declined to
adopt such an exemption because the flexible rules afford small
businesses a broad menu of options for compliance that we believe are
scalable in ways to make them cost-effective for small businesses.
Further, the proposed criteria for small business
[[Page 66756]]
exemptions would have undermined the purpose of the dispatchable
location rules, i.e., to improve location accuracy, while offering no
countervailing reduction in compliance costs. Rather than an exemption
that relies on proposed criteria that would have little or no practical
effect on small businesses, we believe the flexible and scalable rules
that we adopt will minimize burdens on small businesses while advancing
Congress's location accuracy goals.
294. Rule Consolidation. The Report and Order also consolidates
various 911 rules into a single rule part, i.e., part 9, to the extent
practicable. As part of this consolidation, the Commission simplifies
and streamlines the rules in some instances and eliminates
corresponding duplicative rules in other rule parts. We believe the
rule consolidation helps to minimize the burden on small entities
subject to the Commission's 911 rules because it simplifies and
streamlines the rules, making it easier for small entities to identify
and understand what's required to comply with all 911 requirements.
295. Report to Congress. The Commission will send a copy of the
Report and Order, including this FRFA, in a report to Congress pursuant
to the Congressional Review Act. In addition, the Commission will send
a copy of the Report and Order, including this FRFA, to the Chief
Counsel for Advocacy of the SBA. A copy of the Report and Order, and
FRFA (or summaries thereof) will also be published in the Federal
Register.
VI. Conversion Tables
Conversion Table A
------------------------------------------------------------------------
Final rule Source rule(s) Comment(s)
------------------------------------------------------------------------
Subpart A--Purpose and
Definitions
Sec. 9.1 Purpose........ ................. .....................
Sec. 9.2 Reserved....... ................. .....................
Sec. 9.3 Definitions.... 47 CFR 9.3, 20.3, Certain definitions
25.103, from source rules
64.601(a), and added to Sec. 9.3;
64.3000. some definitions
revised; some
definitions new.
Subpart B--Telecommunications ................. Part 64, subpart AA
Carriers. (Universal Emergency
Telephone Number) is
removed and
reserved.
Sec. 9.4 Obligation to 47 CFR 64.3001... Source rule moved to
transmit 911 calls. Sec. 9.4 and
subpart AA removed
and reserved in part
64.
Sec. 9.5 Transition to 47 CFR 64.3002... Source rule moved to
911 as the universal Sec. 9.5 and
emergency telephone subpart AA removed
number. and reserved in part
64.
Sec. 9.6 Obligation for 47 CFR 64.3003... Source rule moved to
providing a permissive Sec. 9.6 and
dialing period. subpart AA removed
and reserved in part
64.
Sec. 9.7 Obligation for 47 CFR 64.3004... Source rule moved to
providing an intercept Sec. 9.7 and
message. subpart AA removed
and reserved in part
64.
Sec. 9.8 Obligation of ................. New provision.
fixed telephony providers
to convey dispatchable
location.
Subpart C--Commercial Mobile
Radio Service
Sec. 9.9 Definitions.... 47 CFR 20.3...... Certain definitions
from source rule
added to Sec. 9.9.
Sec. 9.10 911 Service 47 CFR 20.18..... Source rule moved to
Requirements. Sec. 9.10 and
revised to add
paragraph
(q)(10)(v); and
removed and reserved
in Part 20.
Subpart D--Interconnected
Voice over Internet Protocol
Services
Sec. 9.11 E911 Service.. 47 CFR 9.5....... Source rule moved to
Sec. 9.11 and
revised except for
Sec. 9.5(f), which
is omitted.
Sec. 9.12 Access to 911 47 CFR 9.7....... Source rule moved to
and E911 service Sec. 9.12 and
capabilities. revised.
Subpart E--Telecommunications
Relay Services for Persons
With Disabilities
Sec. 9.13 Jurisdiction.. 47 CFR 64.601(b) Source rules added to
and 64.602. Sec. 9.13.
Sec. 9.14 Emergency 47 CFR Source rules moved to
Calling Requirements. 64.604(a)(4) and Sec. 9.14 and
64.605. revised; Sec.
64.605 removed and
reserved in part 64.
Subpart F--Multi Line ................. New provision.
Telephone Systems.
Sec. 9.15 Applicability.
Sec. 9.16 General
obligations--direct 911
dialing, notification and
dispatchable location.
Sec. 9.17 Enforcement,
compliance date, State
law.
Subpart G--Mobile-Satellite
Service
Sec. 9.18 Emergency Call 47 CFR 25.284.... Source rule moved to
Center Service. Sec. 9.18 and
removed and reserved
in part 25.
Subpart H--Resiliency, ................. Part 12 is
redundancy and reliability of consolidated under
911 communications. part 9, subpart H
and is removed and
reserved.
Sec. 9.19 Reliability of 47 CFR 12.4...... Source rule moved to
covered 911 service Sec. 9.19 and
providers. removed and reserved
in part 12.
[[Page 66757]]
Sec. 9.20 Backup power 47 CFR 12.5...... Source rule moved to
obligations. Sec. 9.20 and
removed and reserved
in part 12.
------------------------------------------------------------------------
Conversion Table B
Part 1--Practice and Procedure, Final Rule Changes
------------------------------------------------------------------------
Current rule No. Subject Final Changes
------------------------------------------------------------------------
1.9020........................ Spectrum manager Updated cross-
leasing references.
arrangements.
1.9030........................ Long-term de Updated cross-
facto transfer references.
leasing
arrangements.
1.9035........................ Short-term de Updated cross-
facto transfer references.
leasing
arrangements.
1.9049........................ Special Updated cross-
provisions references.
relating to
spectrum leasing
arrangements
involving the
ancillary
terrestrial
component of
Mobile Satellite
Services.
------------------------------------------------------------------------
Part 9--Interconnected Voice Over Internet Protocol Services, Final Rule
Changes
------------------------------------------------------------------------
Current rule No. Subject Final changes
------------------------------------------------------------------------
9.1........................... Purposes......... Revised.
9.3........................... Definitions...... Definition of
``Registered
Location'' moved to
Sec. 9.3 and
revised.
All other definitions
remain in Sec.
9.3:
ANI
Appropriate local
emergency authority.
Automatic Location
Information (ALI).
CMRS.
Interconnected VoIP
service.
PSAP.
Pseudo Automatic
Number Identification
(Pseudo-ANI).
Statewide default
answering point.
Wireline E911
Network.
9.5........................... E911 Service..... Moved to Sec. 9.11
and revised, except
for Sec. 9.5(f),
which is a one-time
information
collection that has
been completed.
Removed the
obligation in Sec.
9.5(f).
9.7........................... Access to 911 and Moved to Sec. 9.12
E911 service and revised.
capabilities.
------------------------------------------------------------------------
Part 12--Resiliency, Redundancy and Reliability of Communications, Final
Rule Changes
------------------------------------------------------------------------
Current rule No. Subject Final changes
------------------------------------------------------------------------
12.1.......................... Purpose.......... Removed.
12.3.......................... 911 and E911 Removed (one-time
analyses and reporting
reports. requirement has been
completed).
12.4.......................... Reliability of Moved to Sec. 9.19;
covered 911 corrected internal
service cross-references.
providers.
12.5.......................... Backup power Moved to Sec. 9.20;
obligations. corrected internal
cross-references.
------------------------------------------------------------------------
Part 20--Commercial Mobile Services, Final Rule Changes
------------------------------------------------------------------------
Current rule No. Subject Final changes
------------------------------------------------------------------------
20.2.......................... Other applicable Section 20.2
rule parts. specifies other FCC
rule parts
applicable to
licensees in the
commercial mobile
radio services.
Revised Sec. 20.2
by adding a
reference to
compliance with the
911 requirements in
part 9 of this
chapter.
20.3.......................... Definitions...... Definitions of the
following terms
added to Sec. 9.3
and removed from
Sec. 20.3:
Appropriate local
emergency authority.
Automatic Number
Identification (ANI)
(The version in 9.3
is revised slightly
to harmonize it with
the definition of ANI
from Sec. 64.601.)
Designated PSAP.
Handset-based
location technology.
Location-capable
handsets.
Network-based
Location Technology.
Pseudo Automatic
Number Identification
(Pseudo-ANI).
Public safety
answering point
(PSAP) (The version
in Sec. 9.3 is
revised slightly for
clarity by adding the
word ``answering''
before ``point.'').
[[Page 66758]]
Statewide default
answering point.
Definitions of the
following terms
added to Sec. 9.3
(but not removed
from Sec. 20.3)
Commercial mobile
radio service
(acronym CMRS added
to definition for
clarity).
Mobile Service.
Public Switched
Network.
Private Mobile
Radio Service.
Definitions of the
following terms
added to Sec. 9.9
(but not removed
from Sec. 20.3):
Interconnection or
Interconnected.
Interconnected
Service.
20.18......................... 911 Service...... Moved to Sec. 9.10;
corrected internal
cross-references.
Corrected certain
internal references
to paragraph (j),
which was previously
redesignated as
paragraph (m).
Corrected certain
internal references
to paragraph (n),
which was previously
redesignated as
paragraph (q).
Added new paragraph
(q)(10)(v).
------------------------------------------------------------------------
Part 22--Public Mobile Services, Final Rule Changes
------------------------------------------------------------------------
Current rule No. Subject Final changes
------------------------------------------------------------------------
22.921........................ 911 call Removed and reserved.
processing
procedures; 911-
only calling
mode.
------------------------------------------------------------------------
Part 25--Satellite Communications, Final Rule Changes
------------------------------------------------------------------------
Current rule No. Subject Final changes
------------------------------------------------------------------------
25.103........................ Definitions...... Definitions of the
following terms
added to Sec. 9.3
(but not removed
from Sec. 25.103):
Earth station.
Feeder link.
Fixed-Satellite
Service (FSS).
Mobile Earth
Station.
Mobile-Satellite
Service (MSS).
Space station.
Definition of the
following term added
to Sec. 9.3 and
removed from Sec.
25.103:
Emergency Call
Center.
25.284........................ Emergency Call Moved to Sec. 9.18;
Center Service. Sec. 25.284
removed and
reserved.
------------------------------------------------------------------------
Part 64--Miscellaneous Rules Relating to Common Carriers, Final Rule
Changes
------------------------------------------------------------------------
Current rule No. Subject Final changes
------------------------------------------------------------------------
64.601........................ Definitions and Section 64.601(b),
provisions of which states that
general ``For purposes of
applicability. this subpart, all
regulations and
requirements
applicable to common
carriers shall also
be applicable to
providers of
interconnected VoIP
service,'' is added
to Sec. 9.13, with
reference to the
definition of
interconnected VoIP
in Sec. 9.3.
Section 64.601(a),
which lists several
terms and defines
them by cross-
referencing other
rule sections, is
revised to remove
the terms ``Public
Safety Answering
Point (PSAP),''
``statewide default
answering point,''
and ``appropriate
local emergency
authority.''
Definition of ANI
added to Sec. 9.3
but not removed from
Sec. 64.601.
Definition of
Registered Location
added to Sec. 9.3
and revised.
Definition of Real-
Time Text (RTT) is
added to Sec. 9.3
and revised to
include definition
from 67.1 (rather
than cross-reference
to Sec. 67.1).
Definition of the
following terms
added to Sec. 9.3
(but not removed
from Sec. 64.601):
Common carrier or
carrier.
Communications
assistant (CA).
Internet-based TRS
(iTRS).
iTRS access
technology.
Internet-based TRS
(iTRS).
Internet Protocol
Captioned Telephone
Service (IP CTS).
[[Page 66759]]
Internet Protocol
Relay Service (IP
Relay).
Non-English
language relay
service.
Speech-to-speech
relay service.
Telecommunications
relay services (TRS).
Text telephone
(TTY).
Video relay service
(VRS).
64.602........................ Jurisdiction..... Section 64.602, which
states that ``Any
violation of this
subpart F by any
common carrier
engaged in
intrastate
communication shall
be subject to the
same remedies,
penalties, and
procedures as are
applicable to a
violation of the Act
by a common carrier
engaged in
interstate
communication,'' is
added to Sec. 9.13
(with reference to
subpart E of part
9).
64.603........................ Provision of Section 64.603(a)
services. requires common
carriers providing
telephone voice
transmission
services to provide
telecommunications
relay services in
compliance with the
regulations
prescribed in
subpart F of part
64. Revised Sec.
64.603(a) so that it
also refers to
compliance with the
emergency calling
requirements
prescribed in part
9, subpart E of this
chapter.
64.604(a)(4).................. Emergency call Moved to Sec.
handling 9.14(a); Sec.
requirements for 64.604(a)(4) removed
TTY-based TRS and reserved; and
providers. Sec. 64.604(d)
revised to update
cross-reference from
Sec. 64.605 to
Sec. 9.14.
64.605........................ Emergency calling Moved to Sec.
requirements. 9.14(b) and (c);
Sec. 64.605
removed and
reserved.
64.3000....................... Definitions...... Moved to Sec. 9.3
and removed from
part 64 as subpart
AA (Universal
Emergency Telephone
Number) is removed
and reserved.
Definition of the
following terms
added to Sec. 9.3
(and removed from
Part 64 as subpart
AA is removed and
reserved):
911 calls.
Appropriate local
emergency authority.
Public safety
answering point
(PSAP) (The version
in Sec. 9.3 is
revised slightly for
consistency with the
version from Sec.
20.3 and for clarity;
``facility'' changed
to ``answering
point.'').
Statewide default
answering point.
64.3001....................... Obligation to Moved to Sec. 9.4
transmit 911 and removed from
calls. part 64 as subpart
AA (Universal
Emergency Telephone
Number) is removed
and reserved.
64.3002....................... Transition to 911 Moved to Sec. 9.5
as the universal and removed from
emergency part 64 as subpart
telephone number. AA (Universal
Emergency Telephone
Number) is removed
and reserved.
64.3003....................... Obligation for Moved to Sec. 9.6
providing a and removed from
permissive part 64 as subpart
dialing period. AA (Universal
Emergency Telephone
Number) is removed
and reserved.
64.3004....................... Obligation for Moved to Sec. 9.7
providing an and removed from
intercept part 64 as subpart
message. AA (Universal
Emergency Telephone
Number) is removed
and reserved.
------------------------------------------------------------------------
VII. Ordering Clauses
296. Accordingly, it is ordered, pursuant to sections 1, 4(i),
4(j), 4(o), 201(b), 251(e), 301, 303(b), 303(r), 307, 309, and 316 of
the Communications Act of 1934, as amended, 47 U.S.C. 151, 154(i),
154(j), 154(o), 201(b), 251(e), 301, 303(b), 303(r), 307, 309, 316 and
pursuant to Kari's Law Act of 2017, Public Law 115-127, 47 U.S.C. 623
and 623 note, section 506 of the Repack Airwaves Yielding Better Access
for Users of Modern Services Act of 2018 (RAY BAUM'S Act), Public Law
115-141, 47 U.S.C. 615 note, Section 106 of the Twenty-First Century
Communications and Video Accessibility Act of 2010, Public Law 111-260,
47 U.S.C. 615c, section 101 of the New and Emerging Technologies 911
Improvement Act of 2008, Public Law 110-283, 47 U.S.C. 615a-1, Middle
Class Tax Relief and Job Creation Act of 2012, Public Law 112-96, 47
U.S.C. 1471, and the Wireless Communications and Public Safety Act of
1999, Public Law 106-81, 47 U.S.C. 615 note, 615, 615a, 615b, that this
Report and Order is adopted.
297. It is further ordered that the amendments of the Commission's
rules as set forth in Appendix A are adopted, effective thirty days
from the date of publication in the Federal Register. Sections 9.8(a);
9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4);
9.11(b)(5)(ii); (iii); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v);
9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); 9.16(b)(3)(i);
(ii); and (iii), contain new or modified information collection
requirements that require review by the OMB under the PRA. The
Commission directs the Public Safety and Homeland Security Bureau
(Bureau) to announce the effective date of those information
collections in a document published in the Federal Register after the
Commission receives OMB approval, and directs the Bureau to cause
Sec. Sec. 9.8(b); 9.10(s); 9.11(c); 9.14(f); 9.16(c), to be revised
accordingly.
298. It is further ordered that the Commission SHALL SEND a copy of
the Report and Order in a report to be sent to Congress and the
Government Accountability Office pursuant to the Congressional Review
Act, 5 U.S.C. 801(a)(1)(A).
299. It is further ordered that the Commission's Consumer and
Governmental Affairs Bureau, Reference Information Center, shall send a
copy of the Report and Order, including the Final Regulatory
Flexibility Analysis, to the Chief Counsel for Advocacy of the Small
Business Administration.
List of Subjects in 47 CFR Parts 1, 9, 12, 20, 25, and 64
Communications, Communications common carriers, Communications
Equipment, Reporting and recordkeeping requirements, Security measures,
Satellites, Telecommunications, Telephone.
[[Page 66760]]
Federal Communications Commission.
Katura Jackson,
Federal Register Liaison Officer.
Final Rules
For the reasons discussed in the preamble, the Federal
Communications Commission amends 47 parts 1, 9, 12, 20, 25, and 64 as
follows:
PART 1--PRACTICE AND PROCEDURE
0
1. The authority citation for part 1 continues to read as follows:
Authority: 47 U.S.C. chs. 2, 5, 9, 13; 28 U.S.C. 2461 note,
unless otherwise noted.
0
2. Section 1.9020 is amended by revising paragraph (d)(8) to read as
follows:
Sec. 1.9020 Spectrum manager leasing arrangements.
* * * * *
(d) * * *
(8) E911 requirements. If E911 obligations apply to the licensee
(see Sec. 9.10 of this chapter), the licensee retains the obligations
with respect to leased spectrum. However, if the spectrum lessee is a
Contraband Interdiction System (CIS) provider, as defined in Sec.
1.9003, then the CIS provider is responsible for compliance with Sec.
9.10(r) regarding E911 transmission obligations.
* * * * *
0
3. Section 1.9030 is amended by revising paragraph (d)(8) to read as
follows:
Sec. 1.9030 Long-term de facto transfer leasing arrangements.
* * * * *
(d) * * *
(8) E911 requirements. To the extent the licensee is required to
meet E911 obligations (see Sec. 9.10 of this chapter), the spectrum
lessee is required to meet those obligations with respect to the
spectrum leased under the spectrum leasing arrangement insofar as the
spectrum lessee's operations are encompassed within the E911
obligations. If the spectrum lessee is a Contraband Interdiction System
(CIS) provider, as defined in Sec. 1.9003, then the CIS provider is
responsible for compliance with Sec. 9.10(r) regarding E911
transmission obligations.
* * * * *
0
4. Section 1.9035 is amended by revising paragraph (d)(4) to read as
follows:
Sec. 1.9035 Short-term de facto transfer leasing arrangements.
* * * * *
(d) * * *
(4) E911 requirements. If E911 obligations apply to the licensee
(see Sec. 9.10 of this chapter), the licensee retains the obligations
with respect to leased spectrum. A spectrum lessee entering into a
short-term de facto transfer leasing arrangement is not separately
required to comply with any such obligations in relation to the leased
spectrum. However, if the spectrum lessee is a Contraband Interdiction
System (CIS) provider, as defined in Sec. 1.9003, then the CIS
provider is responsible for compliance with Sec. 9.10(r) regarding
E911 transmission obligations.
* * * * *
0
5. Section 1.9049 is amended by revising paragraph (c) to read as
follows:
Sec. 1.9049 Special provisions relating to spectrum leasing
arrangements involving the ancillary terrestrial component of Mobile
Satellite Services.
* * * * *
(c) For purposes of Sec. 1.9020(d)(8), the Mobile Satellite
Service licensee's obligation, if any, concerning the E911 requirements
in Sec. 9.10 of this chapter, will, with respect to an ATC, be
specified in the licensing document for the ATC.
* * * * *
0
6. Revise part 9 to read as follows:
PART 9--911 REQUIREMENTS
Subpart A--Purpose and Definitions
Sec.
9.1 Purpose.
9.2 [Reserved]
9.3 Definitions.
Subpart B--Telecommunications Carriers
9.4 Obligation to transmit 911 calls.
9.5 Transition to 911 as the universal emergency telephone number.
9.6 Obligation for providing a permissive dialing period.
9.7 Obligation for providing an intercept message.
9.8 Obligation of fixed telephony providers to convey dispatchable
location.
Subpart C--Commercial Mobile Radio Service
9.9 Definitions.
9.10 911 Service.
Subpart D--Interconnected Voice over Internet Protocol Services
9.11 E911 Service.
9.12 Access to 911 and E911 service capabilities.
Subpart E--Telecommunications Relay Services for Persons With
Disabilities
9.13 Jurisdiction.
9.14 Emergency calling requirements.
Subpart F--Multi-Line Telephone Systems
9.15 Applicability.
9.16 General obligations--direct 911 dialing, notification, and
dispatchable location.
9.17 Enforcement, compliance date, State law.
Subpart G--Mobile-Satellite Service
9.18 Emergency Call Center service.
Subpart H--Resiliency, Redundancy, and Reliability of 911
Communications
9.19 Reliability of covered 911 service providers.
9.20 Backup power obligations.
Authority: 47 U.S.C. 151-154, 152(a), 155(c), 157, 160, 201,
202, 208, 210, 214, 218, 219, 222, 225, 251(e), 255, 301, 302, 303,
307, 308, 309, 310, 316, 319, 332, 403, 405, 605, 610, 615, 615
note, 615a, 615b, 615c, 615a-1, 616, 620, 621, 623, 623 note, 721,
and 1471, unless otherwise noted.
Subpart A--Purpose and Definitions
Sec. 9.1 Purpose.
The purpose of this part is to set forth the 911 and E911 service
requirements and conditions applicable to telecommunications carriers
(subpart B); commercial mobile radio service (CMRS) providers (subpart
C); interconnected Voice over Internet Protocol (VoIP) providers
(subpart D); providers of telecommunications relay services (TRS) for
persons with disabilities (subpart E); multi-line telephone systems
(MLTS) (subpart F); and Mobile-Satellite Service (MSS) providers
(subpart G). The rules in this part also include requirements to help
ensure the resiliency, redundancy, and reliability of communications
systems, particularly 911 and E911 networks and/or systems (subpart H).
Sec. 9.2 [Reserved]
Sec. 9.3 Definitions.
Terms with definitions including the ``(RR)'' designation are
defined in the same way in Sec. 2.1 of this chapter and in the Radio
Regulations of the International Telecommunication Union.
911 calls. Any call initiated by an end user by dialing 911 for the
purpose of accessing an emergency service provider. For wireless
carriers, all 911 calls include those they are required to transmit
pursuant to subpart C of this part.
Alternative location information. Location information (which may
be coordinate-based) sufficient to identify the caller's civic address
and approximate in-building location, including floor level, in large
buildings.
Appropriate local emergency authority. An emergency answering point
that has not been officially designated as a Public Safety Answering
Point (PSAP), but has the capability of
[[Page 66761]]
receiving 911 calls and either dispatching emergency services personnel
or, if necessary, relaying the call to another emergency service
provider. An appropriate local emergency authority may include, but is
not limited to, an existing local law enforcement authority, such as
the police, county sheriff, local emergency medical services provider,
or fire department.
Automated dispatchable location. Automatic generation of
dispatchable location.
Automatic Location Information (ALI). Information transmitted while
providing E911 service that permits emergency service providers to
identify the geographic location of the calling party.
Automatic Number Identification (ANI). For 911 systems, the
Automatic Number Identification (ANI) identifies the calling party and
may be used as the callback number.
Commercial mobile radio service (CMRS). A mobile service that is:
(1)(i) Provided for profit, i.e., with the intent of receiving
compensation or monetary gain;
(ii) An interconnected service; and
(iii) Available to the public, or to such classes of eligible users
as to be effectively available to a substantial portion of the public;
or
(2) The functional equivalent of such a mobile service described in
paragraph (1) of this definition.
(3) A variety of factors may be evaluated to make a determination
whether the mobile service in question is the functional equivalent of
a commercial mobile radio service, including: Consumer demand for the
service to determine whether the service is closely substitutable for a
commercial mobile radio service; whether changes in price for the
service under examination, or for the comparable commercial mobile
radio service, would prompt customers to change from one service to the
other; and market research information identifying the targeted market
for the service under review.
(4) Unlicensed radio frequency devices under part 15 of this
chapter are excluded from this definition of Commercial mobile radio
service.
Common carrier or carrier. Any common carrier engaged in interstate
Communication by wire or radio as defined in section 3(h) of the
Communications Act of 1934, as amended (the Act), and any common
carrier engaged in intrastate communication by wire or radio,
notwithstanding sections 2(b) and 221(b) of the Act. Communications
assistant (CA). A person who transliterates or interprets conversation
between two or more end users of TRS.
Configured. The settings or configurations for a particular MLTS
installation have been implemented so that the MLTS is fully capable
when installed of dialing 911 directly and providing MLTS notification
as required under the statute and rules. This does not preclude the
inclusion of additional dialing patterns to reach 911. However, if the
system is configured with these additional dialing patterns, they must
be in addition to the default direct dialing pattern.
Designated PSAP. The Public Safety Answering Point (PSAP)
designated by the local or state entity that has the authority and
responsibility to designate the PSAP to receive wireless 911 calls.
Dispatchable location. A location delivered to the PSAP with a 911
call that consists of the validated street address of the calling
party, plus additional information such as suite, apartment or similar
information necessary to adequately identify the location of the
calling party, except for Commercial Mobile Radio Service providers,
which shall convey the location information required by subpart C of
this part.
Earth station. A station located either on the Earth's surface or
within the major portion of the Earth's atmosphere intended for
communication:
(1) With one or more space stations; or
(2) With one or more stations of the same kind by means of one or
more reflecting satellites or other objects in space. (RR)
Emergency Call Center. A facility that subscribers of satellite
commercial mobile radio services call when in need of emergency
assistance by dialing ``911'' on their mobile earth station terminals.
Feeder link. A radio link from a fixed earth station at a given
location to a space station, or vice versa, conveying information for a
space radiocommunication service other than the Fixed-Satellite
Service. The given location may be at a specified fixed point or at any
fixed point within specified areas. (RR)
Fixed-Satellite Service (FSS). A radiocommunication service between
earth stations at given positions, when one or more satellites are
used; the given position may be a specified fixed point or any fixed
point within specified areas; in some cases this service includes
satellite-to-satellite links, which may also be operated in the inter-
satellite service; the Fixed-Satellite Service may also include feeder
links of other space radiocommunication services. (RR)
Handset-based location technology. A method of providing the
location of wireless 911 callers that requires the use of special
location-determining hardware and/or software in a portable or mobile
phone. Handset-based location technology may also employ additional
location-determining hardware and/or software in the CMRS network and/
or another fixed infrastructure.
iTRS access technology. Any equipment, software, or other
technology issued, leased, or provided by an internet-based TRS
provider that can be used to make and receive an internet-based TRS
call.
Improvement to the hardware or software of the system. An
improvement to the hardware or software of the MLTS, including upgrades
to the core systems of the MLTS, as well as substantial upgrades to the
software and any software upgrades requiring a significant purchase.
Interconnected VoIP service. (1) An interconnected Voice over
Internet Protocol (VoIP) service is a service that:
(i) Enables real-time, two-way voice communications;
(ii) Requires a broadband connection from the user's location;
(iii) Requires internet protocol-compatible customer premises
equipment (CPE); and
(iv) Permits users generally to receive calls that originate on the
public switched telephone network and to terminate calls to the public
switched telephone network.
(2) Notwithstanding the foregoing, solely for purposes of
compliance with the Commission's 911 obligations, an interconnected
VoIP service includes a service that fulfills each of paragraphs (1)(i)
through (iii) of this definition and permits users generally to
terminate calls to the public switched telephone network.
Internet-based TRS (iTRS). A telecommunications relay service (TRS)
in which an individual with a hearing or a speech disability connects
to a TRS communications assistant using an Internet Protocol-enabled
device via the internet, rather than the public switched telephone
network. Except as authorized or required by the Commission, internet-
based TRS does not include the use of a text telephone (TTY) or RTT
over an interconnected voice over Internet Protocol service.
Internet Protocol Captioned Telephone Service (IP CTS). A
telecommunications relay service that permits an individual who can
speak but who has difficulty hearing over the
[[Page 66762]]
telephone to use a telephone and an Internet Protocol-enabled device
via the internet to simultaneously listen to the other party and read
captions of what the other party is saying. With IP CTS, the connection
carrying the captions between the relay service provider and the relay
service user is via the internet, rather than the public switched
telephone network.
Internet Protocol Relay Service (IP Relay). A telecommunications
relay service that permits an individual with a hearing or a speech
disability to communicate in text using an Internet Protocol-enabled
device via the internet, rather than using a text telephone (TTY) and
the public switched telephone network.
Location-capable handsets. Portable or mobile phones that contain
special location-determining hardware and/or software, which is used by
a licensee to locate 911 calls.
MLTS notification. An MLTS feature that can send notice to a
central location at the facility where the system is installed or to
another person or organization regardless of location. Examples of
notification include conspicuous on-screen messages with audible alarms
for security desk computers using a client application, text messages
for smartphones, and email for administrators. Notification shall
include, at a minimum, the following information:
(1) The fact that a 911 call has been made;
(2) A valid callback number; and
(3) The information about the caller's location that the MLTS
conveys to the public safety answering point (PSAP) with the call to
911; provided, however, that the notification does not have to include
a callback number or location information if it is technically
infeasible to provide this information.
Mobile Earth Station. An earth station in the Mobile-Satellite
Service intended to be used while in motion or during halts at
unspecified points. (RR)
Mobile-Satellite Service (MSS). (1) A radiocommunication service:
(i) Between mobile earth stations and one or more space stations,
or between space stations used by this service; or
(ii) Between mobile earth stations, by means of one or more space
stations.
(2) This service may also include feeder links necessary for its
operation. (RR)
Mobile service. A radio communication service carried on between
mobile stations or receivers and land stations, and by mobile stations
communicating among themselves, and includes:
(1) Both one-way and two-way radio communications services;
(2) A mobile service which provides a regularly interacting group
of base, mobile, portable, and associated control and relay stations
(whether licensed on an individual, cooperative, or multiple basis) for
private one-way or two-way land mobile radio communications by eligible
users over designated areas of operation; and
(3) Any service for which a license is required in a personal
communications service under part 24 of this chapter.
Network-based location technology. A method of providing the
location of wireless 911 callers that employs hardware and/or software
in the CMRS network and/or another fixed infrastructure, and does not
require the use of special location-determining hardware and/or
software in the caller's portable or mobile phone.
Multi-line telephone system or MLTS. A system comprised of common
control units, telephone sets, control hardware and software and
adjunct systems, including network and premises based systems, such as
Centrex and VoIP, as well as PBX, Hybrid, and Key Telephone Systems (as
classified by the Commission under part 68 of title 47, Code of Federal
Regulations), and includes systems owned or leased by governmental
agencies and non-profit entities, as well as for profit businesses.
Non-English language relay service. A telecommunications relay
service that allows persons with hearing or speech disabilities who use
languages other than English to communicate with voice telephone users
in a shared language other than English, through a CA who is fluent in
that language.
On-premises. In the context of a multi-line telephone system,
within the fixed property (e.g. building(s), facilities, or campus) and
under the operational control of a single administrative authority.
Person engaged in the business of installing an MLTS. A person that
configures the MLTS or performs other tasks involved in getting the
system ready to operate. These tasks may include, but are not limited
to, establishing the dialing pattern for emergency calls, determining
how calls will route to the Public Switched Telephone Network (PSTN),
and determining where the MLTS will interface with the PSTN. These
tasks are performed when the system is initially installed, but they
may also be performed on a more or less regular basis by the MLTS
operator as the communications needs of the enterprise change. The MLTS
installer may be the MLTS manager or a third party acting on behalf of
the manager.
Person engaged in the business of managing an MLTS. The entity that
is responsible for controlling and overseeing implementation of the
MLTS after installation. These responsibilities include determining how
lines should be distributed (including the adding or moving of lines),
assigning and reassigning telephone numbers, and ongoing network
configuration.
Person engaged in the business of manufacturing, importing,
selling, or leasing an MLTS. A person that manufactures, imports,
sells, or leases an MLTS.
Person engaged in the business of operating an MLTS. A person
responsible for the day-to-day operations of the MLTS.
Pre-configured. An MLTS that comes equipped with hardware and/or
software capable of establishing a setting that enables users to
directly dial 911 as soon as the system is able to initiate calls to
the public switched telephone network, so long as the MLTS is installed
and operated properly. This does not preclude the inclusion of
additional dialing patterns to reach 911. However, if the system is
configured with these additional dialing patterns, they must be in
addition to the default direct dialing pattern.
Private mobile radio service. A mobile service that meets neither
the paragraph (1) nor paragraph (2) in the definition of commercial
mobile radio service in this section. A mobile service that does not
meet paragraph (1) in the definition of commercial mobile radio service
in this section is presumed to be a private mobile radio service.
Private mobile radio service includes the following:
(1) Not-for-profit land mobile radio and paging services that serve
the licensee's internal communications needs as defined in part 90 of
this chapter. Shared-use, cost-sharing, or cooperative arrangements,
multiple licensed systems that use third party managers or users
combining resources to meet compatible needs for specialized internal
communications facilities in compliance with the safeguards of Sec.
90.179 of this chapter are presumptively private mobile radio services;
(2) Mobile radio service offered to restricted classes of eligible
users. This includes entities eligible in the Public Safety Radio Pool
and Radiolocation service.
(3) 220-222 MHz land mobile service and Automatic Vehicle
Monitoring systems (part 90 of this chapter) that do not offer
interconnected service or that are not-for-profit; and
[[Page 66763]]
(4) Personal Radio Services under part 95 of this chapter (General
Mobile Services, Radio Control Radio Services, and Citizens Band Radio
Services); Maritime Service Stations (excluding Public Coast stations)
(part 80 of this chapter); and Aviation Service Stations (part 87 of
this chapter).
Pseudo Automatic Number Identification (Pseudo-ANI). A number,
consisting of the same number of digits as ANI, that is not a North
American Numbering Plan telephone directory number and may be used in
place of an ANI to convey special meaning. The special meaning assigned
to the pseudo-ANI is determined by agreements, as necessary, between
the system originating the call, intermediate systems handling and
routing the call, and the destination system.
Public safety answering point or PSAP. An answering point that has
been designated to receive 911 calls and route them to emergency
services personnel.
Public Switched Network. Any common carrier switched network,
whether by wire or radio, including local exchange carriers,
interexchange carriers, and mobile service providers, that uses the
North American Numbering Plan in connection with the provision of
switched services.
Real-Time Text (RTT). Text communications that are transmitted over
Internet Protocol (IP) networks immediately as they are created, e.g.,
on a character-by-character basis.
Registered internet-based TRS user. An individual that has
registered with a VRS, IP Relay, or IP CTS provider as described in
Sec. 64.611.
Registered Location. The most recent information obtained by a
provider of interconnected VoIP service or telecommunications relay
services (TRS), as applicable, that identifies the physical location of
an end user.
Space station. A station located on an object which is beyond, is
intended to go beyond, or has been beyond, the major portion of the
Earth's atmosphere. (RR)
Speech-to-speech relay service (STS). A telecommunications relay
service that allows individuals with speech disabilities to communicate
with voice telephone users through the use of specially trained CAs who
understand the speech patterns of persons with speech disabilities and
can repeat the words spoken by that person.
Statewide default answering point. An emergency answering point
designated by the State to receive 911 calls for either the entire
State or those portions of the State not otherwise served by a local
PSAP.
Station. A station equipped to engage in radio communication or
radio transmission of energy (47 U.S.C. 153(k)).
Telecommunications relay services (TRS). Telephone transmission
services that provide the ability for an individual who has a hearing
or speech disability to engage in communication by wire or radio with a
hearing individual in a manner that is functionally equivalent to the
ability of an individual who does not have a hearing or speech
disability to communicate using voice communication services by wire or
radio. Such term includes services that enable two-way communication
between an individual who uses a text telephone or other nonvoice
terminal device and an individual who does not use such a device,
speech-to-speech services, video relay services and non-English relay
services. TRS supersedes the terms ``dual party relay system,''
``message relay services,'' and ``TDD Relay.''
Text telephone (TTY). A machine that employs graphic communication
in the transmission of coded signals through a wire or radio
communication system. TTY supersedes the term ``TDD'' or
``telecommunications device for the deaf,'' and TT.
Video relay service (VRS). A telecommunications relay service that
allows people with hearing or speech disabilities who use sign language
to communicate with voice telephone users through video equipment. The
video link allows the CA to view and interpret the party's signed
conversation and relay the conversation back and forth with a voice
caller.
Wireline E911 Network. A dedicated wireline network that:
(1) Is interconnected with but largely separate from the public
switched telephone network;
(2) Includes a selective router; and
(3) Is used to route emergency calls and related information to
PSAPs, designated statewide default answering points, appropriate local
emergency authorities or other emergency answering points.
Subpart B--Telecommunications Carriers
Sec. 9.4 Obligation to transmit 911 calls.
All telecommunications carriers shall transmit all 911 calls to a
PSAP, to a designated statewide default answering point, or to an
appropriate local emergency authority as set forth in Sec. 9.5.
Sec. 9.5 Transition to 911 as the universal emergency telephone
number.
As of December 11, 2001, except where 911 is already established as
the exclusive emergency number to reach a PSAP within a given
jurisdiction, telecommunications carriers shall comply with the
following transition periods:
(a) Where a PSAP has been designated, telecommunications carriers
shall complete all translation and routing necessary to deliver 911
calls to a PSAP no later than September 11, 2002.
(b) Where no PSAP has been designated, telecommunications carriers
shall complete all translation and routing necessary to deliver 911
calls to the statewide default answering point no later than September
11, 2002.
(c) Where neither a PSAP nor a statewide default answering point
has been designated, telecommunications carriers shall complete the
translation and routing necessary to deliver 911 calls to an
appropriate local emergency authority, within nine months of a request
by the State or locality.
(d) Where no PSAP nor statewide default answering point has been
designated, and no appropriate local emergency authority has been
selected by an authorized state or local entity, telecommunications
carriers shall identify an appropriate local emergency authority, based
on the exercise of reasonable judgment, and complete all translation
and routing necessary to deliver 911 calls to such appropriate local
emergency authority no later than September 11, 2002.
(e) Once a PSAP is designated for an area where none had existed as
of December 11, 2001, telecommunications carriers shall complete the
translation and routing necessary to deliver 911 calls to that PSAP
within nine months of that designation.
Sec. 9.6 Obligation for providing a permissive dialing period.
Upon completion of translation and routing of 911 calls to a PSAP,
a statewide default answering point, to an appropriate local emergency
authority, or, where no PSAP nor statewide default answering point has
been designated and no appropriate local emergency authority has been
selected by an authorized state or local entity, to an appropriate
local emergency authority, identified by a telecommunications carrier
based on the exercise of reasonable judgment, the telecommunications
carrier shall provide permissive dialing between 911 and any other
seven-or ten-digit emergency number or an abbreviated dialing code
other than 911 that the public has previously used to reach emergency
service providers until the appropriate State or local jurisdiction
[[Page 66764]]
determines to phase out the use of such seven-or ten-digit number
entirely and use 911 exclusively.
Sec. 9.7 Obligation for providing an intercept message.
Upon termination of permissive dialing, as provided under Sec.
9.6, telecommunications carriers shall provide a standard intercept
message announcement that interrupts calls placed to the emergency
service provider using either a seven-or ten-digit emergency number or
an abbreviated dialing code other than 911 and informs the caller of
the dialing code change.
Sec. 9.8 Obligation of fixed telephony providers to convey
dispatchable location.
(a) Providers of fixed telephony services shall provide automated
dispatchable location with 911 calls beginning January 6, 2021.
(b) Paragraph (a) of this section contains information-collection
and recordkeeping requirements. Compliance will not be required until
after approval by the Office of Management and Budget. The Commission
will publish a document in the Federal Register announcing that
compliance date and revising this paragraph accordingly.
Subpart C--Commercial Mobile Radio Service
Sec. 9.9 Definitions.
Interconnection or Interconnected. Direct or indirect connection
through automatic or manual means (by wire, microwave, or other
technologies such as store and forward) to permit the transmission or
reception of messages or signals to or from points in the public
switched network.
Interconnected service. (1) A service:
(i) That is interconnected with the public switched network, or
interconnected with the public switched network through an
interconnected service provider, that gives subscribers the capability
to communicate to or receive communication from all other users on the
public switched network; or
(ii) For which a request for such interconnection is pending
pursuant to section 332(c)(1)(B) of the Communications Act, 47 U.S.C.
332(c)(1)(B).
(2) A mobile service offers interconnected service even if the
service allows subscribers to access the public switched network only
during specified hours of the day, or if the service provides general
access to points on the public switched network but also restricts
access in certain limited ways. Interconnected service does not include
any interface between a licensee's facilities and the public switched
network exclusively for a licensee's internal control purposes.
Sec. 9.10 911 Service.
(a) Scope of section. Except as described in paragraph (r) of this
section, the following requirements of paragraphs (a) through (q) of
this section are only applicable to CMRS providers, excluding mobile
satellite service (MSS) operators, to the extent that they:
(1) Offer real-time, two way switched voice service that is
interconnected with the public switched network; and
(2) Use an in-network switching facility that enables the provider
to reuse frequencies and accomplish seamless hand-offs of subscriber
calls. These requirements are applicable to entities that offer voice
service to consumers by purchasing airtime or capacity at wholesale
rates from CMRS licensees.
(b) Basic 911 service. CMRS providers subject to this section must
transmit all wireless 911 calls without respect to their call
validation process to a Public Safety Answering Point, or, where no
Public Safety Answering Point has been designated, to a designated
statewide default answering point or appropriate local emergency
authority pursuant to Sec. 9.4, provided that ``all wireless 911
calls'' is defined as ``any call initiated by a wireless user dialing
911 on a phone using a compliant radio frequency protocol of the
serving carrier.''
(c) Access to 911 services. CMRS providers subject to this section
must be capable of transmitting 911 calls from individuals with speech
or hearing disabilities through means other than mobile radio handsets,
e.g., through the use of Text Telephone Devices (TTY). CMRS providers
that provide voice communications over IP facilities are not required
to support 911 access via TTYs if they provide 911 access via real-time
text (RTT) communications, in accordance with 47 CFR part 67, except
that RTT support is not required to the extent that it is not
achievable for a particular manufacturer to support RTT on the
provider's network.
(d) Phase I enhanced 911 services. (1) As of April 1, 1998, or
within six months of a request by the designated Public Safety
Answering Point as set forth in paragraph (j) of this section,
whichever is later, licensees subject to this section must provide the
telephone number of the originator of a 911 call and the location of
the cell site or base station receiving a 911 call from any mobile
handset accessing their systems to the designated Public Safety
Answering Point through the use of ANI and Pseudo-ANI.
(2) When the directory number of the handset used to originate a
911 call is not available to the serving carrier, such carrier's
obligations under the paragraph (d)(1) of this section extend only to
delivering 911 calls and available call party information, including
that prescribed in paragraph (l) of this section, to the designated
Public Safety Answering Point.
Note to paragraph (d): With respect to 911 calls accessing their
systems through the use of TTYs, licensees subject to this section must
comply with the requirements in paragraphs (d)(1) and (2) of this
section, as to calls made using a digital wireless system, as of
October 1, 1998.
(e) Phase II enhanced 911 service. Licensees subject to this
section must provide to the designated Public Safety Answering Point
Phase II enhanced 911 service, i.e., the location of all 911 calls by
longitude and latitude in conformance with Phase II accuracy
requirements (see paragraph (h) of this section).
(f) Phase-in for network-based location technologies. Licensees
subject to this section who employ a network-based location technology
shall provide Phase II 911 enhanced service to at least 50 percent of
their coverage area or 50 percent of their population beginning October
1, 2001, or within 6 months of a PSAP request, whichever is later; and
to 100 percent of their coverage area or 100 percent of their
population within 18 months of such a request or by October 1, 2002,
whichever is later.
(g) Phase-in for handset-based location technologies. Licensees
subject to this section who employ a handset-based location technology
may phase in deployment of Phase II enhanced 911 service, subject to
the following requirements:
(1) Without respect to any PSAP request for deployment of Phase II
911 enhanced service, the licensee shall:
(i) Begin selling and activating location-capable handsets no later
than October 1, 2001;
(ii) Ensure that at least 25 percent of all new handsets activated
are location-capable no later than December 31, 2001;
(iii) Ensure that at least 50 percent of all new handsets activated
are location-capable no later than June 30, 2002; and
(iv) Ensure that 100 percent of all new digital handsets activated
are location-capable no later than December 31, 2002, and thereafter.
[[Page 66765]]
(v) By December 31, 2005, achieve 95 percent penetration of
location-capable handsets among its subscribers.
(vi) Licensees that meet the enhanced 911 compliance obligations
through GPS-enabled handsets and have commercial agreements with
resellers will not be required to include the resellers' handset counts
in their compliance percentages.
(2) Once a PSAP request is received, the licensee shall, in the
area served by the PSAP, within six months or by October 1, 2001,
whichever is later:
(i) Install any hardware and/or software in the CMRS network and/or
other fixed infrastructure, as needed, to enable the provision of Phase
II enhanced 911 service; and
(ii) Begin delivering Phase II enhanced 911 service to the PSAP.
(3) For all 911 calls from portable or mobile phones that do not
contain the hardware and/or software needed to enable the licensee to
provide Phase II enhanced 911 service, the licensee shall, after a PSAP
request is received, support, in the area served by the PSAP, Phase I
location for 911 calls or other available best practice method of
providing the location of the portable or mobile phone to the PSAP.
(4) Licensees employing handset-based location technologies shall
ensure that location-capable portable or mobile phones shall conform to
industry interoperability standards designed to enable the location of
such phones by multiple licensees.
(h) Phase II accuracy. Licensees subject to this section shall
comply with the following standards for Phase II location accuracy and
reliability, to be tested and measured either at the county or at the
PSAP service area geographic level, based on outdoor measurements only:
(1) Network-based technologies:
(i) 100 meters for 67 percent of calls, consistent with the
following benchmarks:
(A) One year from January 18, 2011, carriers shall comply with this
standard in 60 percent of counties or PSAP service areas. These
counties or PSAP service areas must cover at least 70 percent of the
population covered by the carrier across its entire network. Compliance
will be measured on a per-county or per-PSAP basis using, at the
carrier's election, either:
(1) Network-based accuracy data; or
(2) Blended reporting as provided in paragraph (h)(1)(iv) of this
section.
(B) Three years from January 18, 2011, carriers shall comply with
this standard in 70 percent of counties or PSAP service areas. These
counties or PSAP service areas must cover at least 80 percent of the
population covered by the carrier across its entire network. Compliance
will be measured on a per-county or per-PSAP basis using, at the
carrier's election, either:
(1) Network-based accuracy data; or
(2) Blended reporting as provided in paragraph (h)(1)(iv) of this
section.
(C) Five years from January 18, 2011, carriers shall comply with
this standard in 100% of counties or PSAP service areas covered by the
carrier. Compliance will be measured on a per-county or per-PSAP basis,
using, at the carrier's election, either:
(1) Network-based accuracy data;
(2) Blended reporting as provided in paragraph (h)(1)(iv) of this
section; or
(3) Handset-based accuracy data as provided in paragraph (h)(1)(v)
of this section.
(ii) 300 meters for 90 percent of calls, consistent with the
following benchmarks:
(A) Three years from January 18, 2011, carriers shall comply with
this standard in 60 percent of counties or PSAP service areas. These
counties or PSAP service areas must cover at least 70 percent of the
population covered by the carrier across its entire network. Compliance
will be measured on a per-county or per-PSAP basis using, at the
carrier's election, either:
(1) Network-based accuracy data; or
(2) Blended reporting as provided in paragraph (h)(1)(iv) of this
section.
(B) Five years from January 18, 2011, carriers shall comply in 70
percent of counties or PSAP service areas. These counties or PSAP
service areas must cover at least 80 percent of the population covered
by the carrier across its entire network. Compliance will be measured
on a per-county or per-PSAP basis using, at the carrier's election,
either:
(1) Network-based accuracy data; or
(2) Blended reporting as provided in paragraph (h)(1)(iv) of this
section.
(C) Eight years from January 18, 2011, carriers shall comply in 85
percent of counties or PSAP service areas. Compliance will be measured
on a per-county or per-PSAP basis using, at the carrier's election,
either:
(1) Network-based accuracy data;
(2) Blended reporting as provided in paragraph (h)(1)(iv) of this
section; or
(3) Handset-based accuracy data as provided in paragraph (h)(1)(v)
of this section.
(iii) County-level or PSAP-level location accuracy standards for
network-based technologies will be applicable to those counties or PSAP
service areas, on an individual basis, in which a network-based carrier
has deployed Phase II in at least one cell site located within a
county's or PSAP service area's boundary. Compliance with the
requirements of paragraphs (h)(1)(i) and (ii) of this section shall be
measured and reported independently.
(iv) Accuracy data from both network-based solutions and handset-
based solutions may be blended to measure compliance with the accuracy
requirements of paragraphs (h)(1)(i)(A) through (C) and paragraphs
(h)(1)(ii)(A) through (C) of this section. Such blending shall be based
on weighting accuracy data in the ratio of assisted GPS (``A-GPS'')
handsets to non-A-GPS handsets in the carrier's subscriber base. The
weighting ratio shall be applied to the accuracy data from each
solution and measured against the network-based accuracy requirements
of paragraph (h)(1) of this section.
(v) A carrier may rely solely on handset-based accuracy data in any
county or PSAP service area if at least 85 percent of its subscribers,
network-wide, use A-GPS handsets, or if it offers A-GPS handsets to
subscribers in that county or PSAP service area at no cost to the
subscriber.
(vi) A carrier may exclude from compliance particular counties, or
portions of counties, where triangulation is not technically possible,
such as locations where at least three cell sites are not sufficiently
visible to a handset. Carriers must file a list of the specific
counties or portions of counties where they are using this exclusion
within 90 days following approval from the Office of Management and
Budget for the related information collection. This list must be
submitted electronically into PS Docket No. 07-114, and copies must be
sent to the National Emergency Number Association, the Association of
Public-Safety Communications Officials-International, and the National
Association of State 9-1-1 Administrators. Further, carriers must
submit in the same manner any changes to their exclusion lists within
thirty days of discovering such changes. This exclusion has sunset as
of January 18, 2019.
(2) Handset-based technologies:
(i) Two years from January 18, 2011, 50 meters for 67 percent of
calls, and 150 meters for 80 percent of calls, on a per-county or per-
PSAP basis. However, a carrier may exclude up to 15 percent of counties
or PSAP service areas from the 150-meter requirement based upon heavy
forestation that limits handset-based technology accuracy in those
counties or PSAP service areas.
(ii) Eight years from January 18, 2011, 50 meters for 67 percent of
calls, and 150 meters for 90 percent of calls, on a
[[Page 66766]]
per-county or per-PSAP basis. However, a carrier may exclude up to 15
percent of counties or PSAP service areas from the 150-meter
requirement based upon heavy forestation that limits handset-based
technology accuracy in those counties or PSAP service areas.
(iii) Carriers must file a list of the specific counties or PSAP
service areas where they are using the exclusion for heavy forestation
within 90 days following (approval from the Office of Management and
Budget for the related information collection). This list must be
submitted electronically into PS Docket No. 07-114, and copies must be
sent to the National Emergency Number Association, the Association of
Public-Safety Communications Officials-International, and the National
Association of State 9-1-1 Administrators. Further, carriers must
submit in the same manner any changes to their exclusion lists within
thirty days of discovering such changes.
(iv) Providers of new CMRS networks that meet the definition of
covered CMRS providers under paragraph (a) of this section must comply
with the requirements of paragraphs (h)(2)(i) through (iii) of this
section. For this purpose, a ``new CMRS network'' is a CMRS network
that is newly deployed subsequent to the effective date of the Third
Report and Order in PS Docket No. 07-114 and that is not an expansion
or upgrade of an existing CMRS network.
(3) Latency (Time to First Fix): For purposes of measuring
compliance with the location accuracy standards of this paragraph, a
call will be deemed to satisfy the standard only if it provides the
specified degree of location accuracy within a maximum latency period
of 30 seconds, as measured from the time the user initiates the 911
call to the time the location fix appears at the location information
center: Provided, however, that the CMRS provider may elect not to
include for purposes of measuring compliance therewith any calls
lasting less than 30 seconds.
(i) Indoor location accuracy for 911 and testing requirements--(1)
Definitions. The terms as used in this section have the following
meaning:
(i) Dispatchable location. A location delivered to the PSAP by the
CMRS provider with a 911 call that consists of the street address of
the calling party, plus additional information such as suite, apartment
or similar information necessary to adequately identify the location of
the calling party. The street address of the calling party must be
validated and, to the extent possible, corroborated against other
location information prior to delivery of dispatchable location
information by the CMRS provider to the PSAP.
(ii) Media Access Control (MAC) Address. A location identifier of a
Wi-Fi access point.
(iii) National Emergency Address Database (NEAD). A database that
uses MAC address information to identify a dispatchable location for
nearby wireless devices within the CMRS provider's coverage footprint.
(iv) Nationwide CMRS provider. A CMRS provider whose service
extends to a majority of the population and land area of the United
States.
(v) Non-nationwide CMRS provider. Any CMRS provider other than a
nationwide CMRS provider.
(vi) Test cities. The six cities (San Francisco, Chicago, Atlanta,
Denver/Front Range, Philadelphia, and Manhattan Borough) and
surrounding geographic areas that correspond to the six geographic
regions specified by the February 7, 2014 ATIS Document,
``Considerations in Selecting Indoor Test Regions,'' for testing of
indoor location technologies.
(2) Indoor location accuracy standards. CMRS providers subject to
this section shall meet the following requirements:
(i) Horizontal location. (A) Nationwide CMRS providers shall
provide; dispatchable location, or; x/y location within 50 meters, for
the following percentages of wireless 911 calls within the following
timeframes, measured from the effective date of the adoption of this
rule:
(1) Within 2 years: 40 percent of all wireless 911 calls.
(2) Within 3 years: 50 percent of all wireless 911 calls.
(3) Within 5 years: 70 percent of all wireless 911 calls.
(4) Within 6 years: 80 percent of all wireless 911 calls.
(B) Non-nationwide CMRS providers shall provide; dispatchable
location or; x/y location within 50 meters, for the following
percentages of wireless 911 calls within the following timeframes,
measured from the effective date of the adoption of this rule:
(1) Within 2 years: 40 percent of all wireless 911 calls.
(2) Within 3 years: 50 percent of all wireless 911 calls.
(3) Within 5 years or within six months of deploying a
commercially-operating VoLTE platform in their network, whichever is
later: 70 percent of all wireless 911 calls.
(4) Within 6 years or within one year of deploying a commercially-
operating VoLTE platform in their network, whichever is later: 80
percent of all wireless 911 calls.
(ii) Vertical location. CMRS providers shall provide vertical
location information with wireless 911 calls as described in this
section within the following timeframes measured from the effective
date of the adoption of this rule:
(A) Within 3 years: All CMRS providers shall make uncompensated
barometric data available to PSAPs with respect to any 911 call placed
from any handset that has the capability to deliver barometric sensor
information.
(B) Within 3 years: Nationwide CMRS providers shall develop one or
more z-axis accuracy metrics validated by an independently administered
and transparent test bed process as described in paragraph (i)(3)(i) of
this section, and shall submit the proposed metric or metrics,
supported by a report of the results of such development and testing,
to the Commission for approval.
(C) Within 6 years: In each of the top 25 CMAs, nationwide CMRS
providers shall deploy either;) dispatchable location, or; z-axis
technology in compliance with any z-axis accuracy metric that has been
approved by the Commission,
(1) In each CMA where dispatchable location is used: nationwide
CMRS providers must ensure that the NEAD is populated with a sufficient
number of total dispatchable location reference points to equal 25
percent of the CMA population.
(2) In each CMA where z-axis technology is used: nationwide CMRS
providers must deploy z-axis technology to cover 80 percent of the CMA
population.
(D) Within 8 years: In each of the top 50 CMAs, nationwide CMRS
providers shall deploy either
(1) Dispatchable location or;
(2) Such z-axis technology in compliance with any z-axis accuracy
metric that has been approved by the Commission.
(E) Non-nationwide CMRS providers that serve any of the top 25 or
50 CMAs will have an additional year to meet each of the benchmarks in
paragraphs (i)(2)(ii)(C) and (D) of this section.
(iii) Compliance. Within 60 days after each benchmark date
specified in paragraphs (i)(2)(i) and (ii) of this section, CMRS
providers must certify that they are in compliance with the location
accuracy requirements applicable to them as of that date. CMRS
providers shall be presumed to be in compliance by certifying that they
have complied with the test bed and live call data provisions described
in paragraph (i)(3) of this section.
(A) All CMRS providers must certify that the indoor location
technology (or
[[Page 66767]]
technologies) used in their networks are deployed consistently with the
manner in which they have been tested in the test bed. A CMRS provider
must update certification whenever it introduces a new technology into
its network or otherwise modifies its network, such that previous
performance in the test bed would no longer be consistent with the
technology's modified deployment.
(B) CMRS providers that provide quarterly reports of live call data
in one or more of the six test cities specified in paragraph (i)(1)(vi)
of this section must certify that their deployment of location
technologies throughout their coverage area is consistent with their
deployment of the same technologies in the areas that are used for live
call data reporting.
(C) Non-nationwide CMRS providers that do not provide service or
report quarterly live call data in any of the six test cities specified
in paragraph (i)(1)(vi) of this section must certify that they have
verified based on their own live call data that they are in compliance
with the requirements of paragraphs (i)(2)(i)(B) and (i)(2)(ii) of this
section.
(iv) Enforcement. PSAPs may seek Commission enforcement within
their geographic service area of the requirements of paragraphs
(i)(2)(i) and (ii) of this section, but only so long as they have
implemented policies that are designed to obtain all location
information made available by CMRS providers when initiating and
delivering 911 calls to the PSAP. Prior to seeking Commission
enforcement, a PSAP must provide the CMRS provider with [30] days
written notice, and the CMRS provider shall have an opportunity to
address the issue informally. If the issue has not been addressed to
the PSAP's satisfaction within 90 days, the PSAP may seek enforcement
relief.
(3) Indoor location accuracy testing and live call data reporting--
(i) Indoor location accuracy test bed. CMRS providers must establish
the test bed described in this section within 12 months of the
effective date of this rule. CMRS providers must validate technologies
intended for indoor location, including dispatchable location
technologies and technologies that deliver horizontal and/or vertical
coordinates, through an independently administered and transparent test
bed process, in order for such technologies to be presumed to comply
with the location accuracy requirements of this paragraph. The test bed
shall meet the following minimal requirements in order for the test
results to be considered valid for compliance purposes:
(A) Include testing in representative indoor environments,
including dense urban, urban, suburban and rural morphologies;
(B) Test for performance attributes including location accuracy
(ground truth as measured in the test bed), latency (Time to First
Fix), and reliability (yield); and
(C) Each test call (or equivalent) shall be independent from prior
calls and accuracy will be based on the first location delivered after
the call is initiated.
(D) In complying with paragraph (i)(3)(i)(B) of this section, CMRS
providers shall measure yield separately for each individual indoor
location morphology (dense urban, urban, suburban, and rural) in the
test bed, and based upon the specific type of location technology that
the provider intends to deploy in real-world areas represented by that
particular morphology. CMRS providers must base the yield percentage
based on the number of test calls that deliver a location in compliance
with any applicable indoor location accuracy requirements, compared to
the total number of calls that successfully connect to the testing
network. CMRS providers may exclude test calls that are dropped or
otherwise disconnected in 10 seconds or less from calculation of the
yield percentage (both the denominator and numerator).
(ii) Collection and reporting of aggregate live 911 call location
data. CMRS providers providing service in any of the Test Cities or
portions thereof must collect and report aggregate data on the location
technologies used for live 911 calls in those areas.
(A) CMRS providers subject to this section shall identify and
collect information regarding the location technology or technologies
used for each 911 call in the reporting area during the calling period.
(B) CMRS providers subject to this section shall report Test City
call location data on a quarterly basis to the Commission, the National
Emergency Number Association, the Association of Public Safety
Communications Officials, and the National Association of State 911
Administrators, with the first report due 18 months from the effective
date of rules adopted in this proceeding.
(C) CMRS providers subject to this section shall also provide
quarterly live call data on a more granular basis that allows
evaluation of the performance of individual location technologies
within different morphologies (e.g., dense urban, urban, suburban,
rural). To the extent available, live call data for all CMRS providers
shall delineate based on a per technology basis accumulated and so
identified for:
(1) Each of the ATIS ESIF morphologies;
(2) On a reasonable community level basis; or
(3) By census block. This more granular data will be used for
evaluation and not for compliance purposes.
(D) Non-nationwide CMRS providers that operate in a single Test
City need only report live 911 call data from that city or portion
thereof that they cover. Non-nationwide CMRS providers that operate in
more than one Test City must report live 911 call data only in half of
the regions (as selected by the provider). In the event a non-
nationwide CMRS provider begins coverage in a Test City it previously
did not serve, it must update its certification pursuant to paragraph
(i)(2)(iii)(C) of this section to reflect this change in its network
and begin reporting data from the appropriate areas. All non-nationwide
CMRS providers must report their Test City live call data every 6
months, beginning 18 months from the effective date of rules adopted in
this proceeding.
(E) Non-nationwide CMRS providers that do not provide coverage in
any of the Test Cities can satisfy the requirement of this paragraph
(i)(3)(ii) by collecting and reporting data based on the largest county
within its footprint. In addition, where a non-nationwide CMRS provider
serves more than one of the ATIS ESIF morphologies, it must include a
sufficient number of representative counties to cover each morphology.
(iii) Data retention. CMRS providers shall retain testing and live
call data gathered pursuant to this section for a period of 2 years.
(4) Submission of plans and reports. The following reporting and
certification obligations apply to all CMRS providers subject to this
section, which may be filed electronically in PS Docket No. 07-114:
(i) Initial implementation plan. No later than 18 months from the
effective date of the adoption of this rule, nationwide CMRS providers
shall report to the Commission on their plans for meeting the indoor
location accuracy requirements of paragraph (i)(2) of this section.
Non-nationwide CMRS providers will have an additional 6 months to
submit their implementation plans.
(ii) Progress reports. No later than 18 months from the effective
date of the adoption of this rule), each CMRS provider shall file a
progress report on implementation of indoor location accuracy
requirements. Non-nationwide CMRS providers will have an additional
[[Page 66768]]
6 months to submit their progress reports. All CMRS providers shall
provide an additional progress report no later than 36 months from the
effective date of the adoption of this rule. The 36-month reports shall
indicate what progress the provider has made consistent with its
implementation plan, and the nationwide CMRS providers shall include an
assessment of their deployment of dispatchable location solutions. For
any CMRS provider participating in the development of the NEAD
database, this progress report must include detail as to the
implementation of the NEAD database described in paragraphs (i)(4)(iii)
and (iv) of this section.
(iii) NEAD privacy and security plan. Prior to activation of the
NEAD but no later than 18 months from the effective date of the
adoption of this rule, the nationwide CMRS providers shall file with
the Commission and request approval for a security and privacy plan for
the administration and operation of the NEAD. The plan must include the
identity of an administrator for the NEAD, who will serve as a point of
contact for the Commission and shall be accountable for the
effectiveness of the security, privacy, and resiliency measures.
(iv) NEAD use certification. Prior to use of the NEAD or any
information contained therein to meet such requirements, CMRS providers
must certify that they will not use the NEAD or associated data for any
non-911 purpose, except as otherwise required by law.
(j) Confidence and uncertainty data. (1) Except as provided in
paragraphs (j)(2) and (3) of this section, CMRS providers subject to
this section shall provide for all wireless 911 calls, whether from
outdoor or indoor locations, x- and y-axis (latitude, longitude)
confidence and uncertainty information (C/U data) on a per-call basis
upon the request of a PSAP. The data shall specify:
(i) The caller's location with a uniform confidence level of 90
percent, and;
(ii) The radius in meters from the reported position at that same
confidence level. All entities responsible for transporting confidence
and uncertainty between CMRS providers and PSAPs, including LECs,
CLECs, owners of E911 networks, and emergency service providers, must
enable the transmission of confidence and uncertainty data provided by
CMRS providers to the requesting PSAP.
(2) Upon meeting the 3-year timeframe pursuant to paragraph
(i)(2)(i) of this section, CMRS providers shall provide with wireless
911 calls that have a dispatchable location the C/U data for the x- and
y-axis (latitude, longitude) required under paragraph (j)(1) of this
section.
(3) Upon meeting the 6-year timeframe pursuant to paragraph
(i)(2)(i) of this section, CMRS providers shall provide with wireless
911 calls that have a dispatchable location the C/U data for the x- and
y-axis (latitude, longitude) required under paragraph (j)(1) of this
section.
(k) Provision of live 911 call data for PSAPs. Notwithstanding
other 911 call data collection and reporting requirements in paragraph
(i) of this section, CMRS providers must record information on all live
911 calls, including, but not limited to, the positioning source method
used to provide a location fix associated with the call. CMRS providers
must also record the confidence and uncertainty data that they provide
pursuant to paragraphs (j)(1) through (3) of this section. This
information must be made available to PSAPs upon request, and shall be
retained for a period of two years.
(l) Reports on Phase II plans. Licensees subject to this section
shall report to the Commission their plans for implementing Phase II
enhanced 911 service, including the location-determination technology
they plan to employ and the procedure they intend to use to verify
conformance with the Phase II accuracy requirements by November 9,
2000. Licensees are required to update these plans within thirty days
of the adoption of any change. These reports and updates may be filed
electronically in a manner to be designated by the Commission.
(m) Conditions for enhanced 911 services--(1) Generally. The
requirements set forth in paragraphs (d) through (h)(2) and in
paragraph (j) of this section shall be applicable only to the extent
that the administrator of the applicable designated PSAP has requested
the services required under those paragraphs and such PSAP is capable
of receiving and using the requested data elements and has a mechanism
for recovering the PSAP's costs associated with them.
(2) Commencement of six-month period. (i) Except as provided in
paragraph (m)(2)(ii) of this section, for purposes of commencing the
six-month period for carrier implementation specified in paragraphs
(d), (f) and (g) of this section, a PSAP will be deemed capable of
receiving and using the data elements associated with the service
requested, if it can demonstrate that it has:
(A) Ordered the necessary equipment and has commitments from
suppliers to have it installed and operational within such six-month
period; and
(B) Made a timely request to the appropriate local exchange carrier
for the necessary trunking, upgrades, and other facilities.
(ii) For purposes of commencing the six-month period for carrier
implementation specified in paragraphs (f) and (g) of this section, a
PSAP that is Phase I-capable using a Non-Call Path Associated Signaling
(NCAS) technology will be deemed capable of receiving and using the
data elements associated with Phase II service if it can demonstrate
that it has made a timely request to the appropriate local exchange
carrier for the ALI database upgrade necessary to receive the Phase II
information.
(3) Tolling of six-month period. Where a wireless carrier has
served a written request for documentation on the PSAP within 15 days
of receiving the PSAP's request for Phase I or Phase II enhanced 911
service, and the PSAP fails to respond to such request within 15 days
of such service, the six-month period for carrier implementation
specified in paragraphs (d), (f), and (g) of this section will be
tolled until the PSAP provides the carrier with such documentation.
(4) Carrier certification regarding PSAP readiness issues. At the
end of the six-month period for carrier implementation specified in
paragraphs (d), (f), and (g) of this section, a wireless carrier that
believes that the PSAP is not capable of receiving and using the data
elements associated with the service requested may file a certification
with the Commission. Upon filing and service of such certification, the
carrier may suspend further implementation efforts, except as provided
in paragraph (m)(4)(x) of this section.
(i) As a prerequisite to filing such certification, no later than
21 days prior to such filing, the wireless carrier must notify the
affected PSAP, in writing, of its intent to file such certification.
Any response that the carrier receives from the PSAP must be included
with the carrier's certification filing.
(ii) The certification process shall be subject to the procedural
requirements set forth in Sec. Sec. 1.45 and 1.47 of this chapter.
(iii) The certification must be in the form of an affidavit signed
by a director or officer of the carrier, documenting:
(A) The basis for the carrier's determination that the PSAP will
not be ready;
(B) Each of the specific steps the carrier has taken to provide the
E911 service requested;
[[Page 66769]]
(C) The reasons why further implementation efforts cannot be made
until the PSAP becomes capable of receiving and using the data elements
associated with the E911 service requested; and
(D) The specific steps that remain to be completed by the wireless
carrier and, to the extent known, the PSAP or other parties before the
carrier can provide the E911 service requested.
(iv) All affidavits must be correct. The carrier must ensure that
its affidavit is correct, and the certifying director or officer has
the duty to personally determine that the affidavit is correct.
(v) A carrier may not engage in a practice of filing inadequate or
incomplete certifications for the purpose of delaying its
responsibilities.
(vi) To be eligible to make a certification, the wireless carrier
must have completed all necessary steps toward E911 implementation that
are not dependent on PSAP readiness.
(vii) A copy of the certification must be served on the PSAP in
accordance with Sec. 1.47 of this chapter. The PSAP may challenge in
writing the accuracy of the carrier's certification and shall serve a
copy of such challenge on the carrier. See Sec. Sec. 1.45 and 1.47 and
1.720 through 1.740 of this chapter.
(viii) If a wireless carrier's certification is facially
inadequate, the six-month implementation period specified in paragraphs
(d), (f), and (g) of this section will not be suspended as provided for
in paragraph (m)(4) of this section.
(ix) If a wireless carrier's certification is inaccurate, the
wireless carrier will be liable for noncompliance as if the
certification had not been filed.
(x) A carrier that files a certification under this paragraph
(m)(4) shall have 90 days from receipt of the PSAP's written notice
that it is capable of receiving and using the data elements associated
with the service requested to provide such service in accordance with
the requirements of paragraphs (d) through (h) of this section.
(5) Modification of deadlines by agreement. Nothing in this section
shall prevent Public Safety Answering Points and carriers from
establishing, by mutual consent, deadlines different from those imposed
for carrier and PSAP compliance in paragraphs (d), (f), and (g)(2) of
this section.
(n) Dispatch service. A service provider covered by this section
who offers dispatch service to customers may meet the requirements of
this section with respect to customers who use dispatch service either
by complying with the requirements set forth in paragraphs (b) through
(e) of this section, or by routing the customer's emergency calls
through a dispatcher. If the service provider chooses the latter
alternative, it must make every reasonable effort to explicitly notify
its current and potential dispatch customers and their users that they
are not able to directly reach a PSAP by calling 911 and that, in the
event of an emergency, the dispatcher should be contacted.
(o) Non-service-initialized handsets. (1) Licensees subject to this
section that donate a non-service-initialized handset for purposes of
providing access to 911 services are required to:
(i) Program each handset with 911 plus the decimal representation
of the seven least significant digits of the Electronic Serial Number,
International Mobile Equipment Identifier, or any other identifier
unique to that handset;
(ii) Affix to each handset a label which is designed to withstand
the length of service expected for a non-service-initialized phone, and
which notifies the user that the handset can only be used to dial 911,
that the 911 operator will not be able to call the user back, and that
the user should convey the exact location of the emergency as soon as
possible; and
(iii) Institute a public education program to provide the users of
such handsets with information regarding the limitations of non-
service-initialized handsets.
(2) Manufacturers of 911-only handsets that are manufactured on or
after May 3, 2004, are required to:
(i) Program each handset with 911 plus the decimal representation
of the seven least significant digits of the Electronic Serial Number,
International Mobile Equipment Identifier, or any other identifier
unique to that handset;
(ii) Affix to each handset a label which is designed to withstand
the length of service expected for a non-service-initialized phone, and
which notifies the user that the handset can only be used to dial 911,
that the 911 operator will not be able to call the user back, and that
the user should convey the exact location of the emergency as soon as
possible; and
(iii) Institute a public education program to provide the users of
such handsets with information regarding the limitations of 911-only
handsets.
(3) The following definitions apply for purposes of this paragraph.
(i) Non-service-initialized handset. A handset for which there is
no valid service contract with a provider of the services enumerated in
paragraph (a) of this section.
(ii) 911-only handset. A non-service-initialized handset that is
manufactured with the capability of dialing 911 only and that cannot
receive incoming calls.
(p) Reseller obligation. (1) Beginning December 31, 2006, resellers
have an obligation, independent of the underlying licensee, to provide
access to basic and enhanced 911 service to the extent that the
underlying licensee of the facilities the reseller uses to provide
access to the public switched network complies with Sec. 9.10(d)
through (g).
(2) Resellers have an independent obligation to ensure that all
handsets or other devices offered to their customers for voice
communications and sold after December 31, 2006 are capable of
transmitting enhanced 911 information to the appropriate PSAP, in
accordance with the accuracy requirements of Sec. 9.10(i).
(q) Text-to-911 requirements--(1) Covered text provider.
Notwithstanding any other provisions in this section, for purposes of
this paragraph (q) of this section, a ``covered text provider''
includes all CMRS providers as well as all providers of interconnected
text messaging services that enable consumers to send text messages to
and receive text messages from all or substantially all text-capable
U.S. telephone numbers, including through the use of applications
downloaded or otherwise installed on mobile phones.
(2) Automatic bounce-back message. An automatic text message
delivered to a consumer by a covered text provider in response to the
consumer's attempt to send a text message to 911 when the consumer is
located in an area where text-to-911 service is unavailable or the
covered text provider does not support text-to-911 service generally or
in the area where the consumer is located at the time.
(3) Provision of automatic bounce-back messages. No later than
September 30, 2013, all covered text providers shall provide an
automatic bounce-back message under the following circumstances:
(i) A consumer attempts to send a text message to a Public Safety
Answering Point (PSAP) by means of the three-digit short code ``911'';
and
(ii) The covered text provider cannot deliver the text because the
consumer is located in an area where:
(A) Text-to-911 service is unavailable; or
(B) The covered text provider does not support text-to-911 service
at the time.
(4) Automatic bounce-back message exceptions. (i) A covered text
provider is not required to provide an automatic bounce-back message
when:
(A) Transmission of the text message is not controlled by the
provider;
[[Page 66770]]
(B) A consumer is attempting to text 911, through a text messaging
application that requires CMRS service, from a non-service initialized
handset;
(C) When the text-to-911 message cannot be delivered to a PSAP due
to failure in the PSAP network that has not been reported to the
provider; or
(D) A consumer is attempting to text 911 through a device that is
incapable of sending texts via three digit short codes, provided the
software for the device cannot be upgraded over the air to allow text-
to-911.
(ii) The provider of a preinstalled or downloadable interconnected
text application is considered to have ``control'' over transmission of
text messages for purposes of paragraph (q)(4)(i)(A) of this section.
However, if a user or a third party modifies or manipulates the
application after it is installed or downloaded so that it no longer
supports bounce-back messaging, the application provider will be
presumed not to have control.
(5) Automatic bounce-back message minimum requirements. The
automatic bounce-back message shall, at a minimum, inform the consumer
that text-to-911 service is not available and advise the consumer or
texting program user to use another means to contact emergency
services.
(6) Temporary suspension of text-to-911 service. Covered text
providers that support text-to-911 must provide a mechanism to allow
PSAPs that accept text-to-911 to request temporary suspension of text-
to-911 service for any reason, including, but not limited to, network
congestion, call taker overload, PSAP failure, or security breach, and
to request resumption of text-to-911 service after such temporary
suspension. During any period of suspension of text-to-911 service, the
covered text provider must provide an automatic bounce-back message to
any consumer attempting to text to 911 in the area subject to the
temporary suspension.
(7) Roaming. Notwithstanding any other provisions in this section,
when a consumer is roaming on a covered text provider's host network
pursuant to Sec. 20.12, the covered text provider operating the
consumer's home network shall have the obligation to originate an
automatic bounce-back message to such consumer when the consumer is
located in an area where text-to-911 service is unavailable, or the
home provider does not support text-to-911 service in that area at the
time. The host provider shall not impede the consumer's 911 text
message to the home provider and/or any automatic bounce-back message
originated by the home provider to the consumer roaming on the host
network.
(8) Software application provider. A software application provider
that transmits text messages directly into the SMS network of the
consumer's underlying CMRS provider satisfies the obligations of
paragraph (q)(3) of this section provided it does not prevent or
inhibit delivery of the CMRS provider's automatic bounce-back message
to the consumer.
(9) 911 text message. A 911 text message is a message, consisting
of text characters, sent to the short code ``911'' and intended to be
delivered to a PSAP by a covered text provider, regardless of the text
messaging platform used.
(10) Delivery of 911 text messages. (i) No later than December 31,
2014, all covered text providers must have the capability to route a
911 text message to a PSAP. In complying with this requirement, covered
text providers must obtain location information sufficient to route
text messages to the same PSAP to which a 911 voice call would be
routed, unless the responsible local or state entity designates a
different PSAP to receive 911 text messages and informs the covered
text provider of that change. All covered text providers using device-
based location information that requires consumer activation must
clearly inform consumers that they must grant permission for the text
messaging application to access the wireless device's location
information in order to enable text-to-911. If a consumer does not
permit this access, the covered text provider's text application must
provide an automated bounce-back message as set forth in paragraph
(q)(3) of this section.
(ii) Covered text providers must begin routing all 911 text
messages to a PSAP by June 30, 2015, or within six months of the PSAP's
valid request for text-to-911 service, whichever is later, unless an
alternate timeframe is agreed to by both the PSAP and the covered text
provider. The covered text provider must notify the Commission of the
dates and terms of the alternate timeframe within 30 days of the
parties' agreement.
(iii) Valid Request means that:
(A) The requesting PSAP is, and certifies that it is, technically
ready to receive 911 text messages in the format requested;
(B) The appropriate local or state 911 service governing authority
has specifically authorized the PSAP to accept and, by extension, the
covered text provider to provide, text-to-911 service; and
(C) The requesting PSAP has provided notification to the covered
text provider that it meets the foregoing requirements. Registration by
the PSAP in a database made available by the Commission in accordance
with requirements established in connection therewith, or any other
written notification reasonably acceptable to the covered text
provider, shall constitute sufficient notification for purposes of this
paragraph.
(iv) The requirements set forth in paragraphs (q)(10)(i) through
(iii) of this section do not apply to in-flight text messaging
providers, MSS providers, or IP Relay service providers, or to 911 text
messages that originate from Wi-Fi only locations or that are
transmitted from devices that cannot access the CMRS network.
(v) No later than January 6, 2022, covered text providers must
provide the following location information with all 911 text messages
routed to a PSAP: Automated dispatchable location, if technically
feasible; otherwise, either end-user manual provision of location
information, or enhanced location information, which may be coordinate-
based, consisting of the best available location that can be obtained
from any available technology or combination of technologies at
reasonable cost.
(11) Access to SMS networks for 911 text messages. To the extent
that CMRS providers offer Short Message Service (SMS), they shall allow
access by any other covered text provider to the capabilities necessary
for transmission of 911 text messages originating on such other covered
text providers' application services. Covered text providers using the
CMRS network to deliver 911 text messages must clearly inform consumers
that, absent an SMS plan with the consumer's underlying CMRS provider,
the covered text provider may be unable to deliver 911 text messages.
CMRS providers may migrate to other technologies and need not retain
SMS networks solely for other covered text providers' 911 use, but must
notify the affected covered text providers not less than 90 days before
the migration is to occur.
(r) Contraband Interdiction System (CIS) requirement. CIS providers
regulated as private mobile radio service (see Sec. 9.3) must transmit
all wireless 911 calls without respect to their call validation process
to a Public Safety Answering Point, or, where no Public Safety
Answering Point has been designated, to a designated statewide default
answering point or appropriate local emergency authority pursuant to
Sec. 9.4, provided that ``all wireless 911 calls'' is defined as ``any
call initiated by a wireless user dialing 911 on a phone using a
compliant radio
[[Page 66771]]
frequency protocol of the serving carrier.'' This requirement shall not
apply if the Public Safety Answering Point or emergency authority
informs the CIS provider that it does not wish to receive 911 calls
from the CIS provider.
(s) Compliance date. Paragraph (q)(10)(v) of this section contains
information-collection and recordkeeping requirements. Compliance will
not be required until after approval by the Office of Management and
Budget. The Commission will publish a document in the Federal Register
announcing that compliance date and revising this paragraph
accordingly.
Subpart D--Interconnected Voice over Internet Protocol Services
Sec. 9.11 E911 Service.
(a) Before January 6, 2021, for fixed services and before January
6, 2022, for non-fixed services.--(1) Scope. The following requirements
of paragraphs (a)(1) through (5) of this section are only applicable to
providers of interconnected VoIP services, except those interconnected
VoIP services that fulfill each paragraphs (1)(i) through (iii) of the
definition of interconnected VoIP service in Sec. 9.3, and also permit
users generally to terminate calls to the public switched telephone
network. Further, the following requirements apply only to 911 calls
placed by users whose Registered Location is in a geographic area
served by a Wireline E911 Network (which, as defined in Sec. 9.3,
includes a selective router).
(2) E911 Service. As of November 28, 2005:
(i) Interconnected VoIP service providers must, as a condition of
providing service to a consumer, provide that consumer with E911
service as described in this section;
(ii) Interconnected VoIP service providers must transmit all 911
calls, as well as ANI and the caller's Registered Location for each
call, to the PSAP, designated statewide default answering point, or
appropriate local emergency authority that serves the caller's
Registered Location and that has been designated for telecommunications
carriers pursuant to Sec. 9.4, provided that ``all 911 calls'' is
defined as ``any voice communication initiated by an interconnected
VoIP user dialing 911;''
(iii) All 911 calls must be routed through the use of ANI and, if
necessary, pseudo-ANI, via the dedicated Wireline E911 Network; and
(iv) The Registered Location must be available to the appropriate
PSAP, designated statewide default answering point, or appropriate
local emergency authority from or through the appropriate automatic
location information (ALI) database.
(3) Service Level Obligation. Notwithstanding the provisions in
paragraph (a)(2) of this section, if a PSAP, designated statewide
default answering point, or appropriate local emergency authority is
not capable of receiving and processing either ANI or location
information, an interconnected VoIP service provider need not provide
such ANI or location information; however, nothing in this paragraph
affects the obligation under paragraph (a)(2)(iii) of this section of
an interconnected VoIP service provider to transmit via the Wireline
E911 Network all 911 calls to the PSAP, designated statewide default
answering point, or appropriate local emergency authority that serves
the caller's Registered Location and that has been designated for
telecommunications carriers pursuant to Sec. 9.4.
(4) Registered Location requirement. As of November 28, 2005,
interconnected VoIP service providers must:
(i) Obtain from each customer, prior to the initiation of service,
the physical location at which the service will first be used; and
(ii) Provide their end users one or more methods of updating their
Registered Location, including at least one option that requires use
only of the CPE necessary to access the interconnected VoIP service.
Any method used must allow an end user to update the Registered
Location at will and in a timely manner.
(5) Customer notification. Each interconnected VoIP service
provider shall:
(i) Specifically advise every subscriber, both new and existing,
prominently and in plain language, of the circumstances under which
E911 service may not be available through the interconnected VoIP
service or may be in some way limited by comparison to traditional E911
service. Such circumstances include, but are not limited to, relocation
of the end user's IP-compatible CPE, use by the end user of a non-
native telephone number, broadband connection failure, loss of
electrical power, and delays that may occur in making a Registered
Location available in or through the ALI database;
(ii) Obtain and keep a record of affirmative acknowledgement by
every subscriber, both new and existing, of having received and
understood the advisory described in paragraph (a)(5)(i) of this
section; and
(iii) Either--
(A) Distribute to its existing subscribers, and to each new
subscriber prior to the initiation of that subscriber's service,
warning stickers or other appropriate labels warning subscribers if
E911 service may be limited or not available and instructing the
subscriber to place them on or near the equipment used in conjunction
with the interconnected VoIP service; or
(B) Notify existing subscribers, and each new subscriber prior to
the initiation of that subscriber's service, by other conspicuous means
if E911 service may be limited or not available.
(b) On or after January 6, 2021, for fixed services, and on or
after January 6, 2022, for non-fixed services--(1) Scope. The following
requirements of paragraphs (b)(1) through (5) of this section are only
applicable to all providers of interconnected VoIP services. Further,
these requirements apply only to 911 calls placed by users whose
dispatchable location is in a geographic area served by a Wireline E911
Network (which, as defined in Sec. 9.3, includes a selective router).
(2) E911 Service--(i) Interconnected VoIP service providers must,
as a condition of providing service to a consumer, provide that
consumer with E911 service as described in this section;
(ii) Interconnected VoIP service providers must transmit the
following to the PSAP, designated statewide default answering point, or
appropriate local emergency authority that serves the caller's
dispatchable location and that has been designated for
telecommunications carriers pursuant to Sec. 9.4:
(A) All 911 calls, provided that ``all 911 calls'' is defined as
``any voice communication initiated by an interconnected VoIP user
dialing 911;''
(B) ANI; and
(C) The location information described in paragraph (b)(4) of this
section.
(iii) All 911 calls must be routed through the use of ANI and, if
necessary, pseudo-ANI, via the dedicated Wireline E911 Network,
provided that nothing in this subparagraph shall preclude routing the
call first to a national emergency call center to ascertain the
caller's location in the event that the interconnected VoIP service
provider is unable to obtain or confirm the caller's location
information; and
(iv) The location information described in paragraph (b)(4) of this
section must be available to the appropriate PSAP, designated statewide
default answering point, or appropriate local emergency authority from
or
[[Page 66772]]
through the appropriate automatic location information (ALI) database.
(3) Service level obligation. Notwithstanding the provisions in
paragraph (b)(2) of this section, if a PSAP, designated statewide
default answering point, or appropriate local emergency authority is
not capable of receiving and processing either ANI or location
information, an interconnected VoIP service provider need not provide
such ANI or location information; however, nothing in this paragraph
affects the obligation under paragraph (b)(2)(iii) of this section of
an interconnected VoIP service provider to transmit via the Wireline
E911 Network all 911 calls to the PSAP, designated statewide default
answering point, or appropriate local emergency authority that serves
the caller's dispatchable location and that has been designated for
telecommunications carriers pursuant to Sec. 9.4.
(4) Location requirements. To meet E911 service requirements,
interconnected VoIP service providers must provide location information
with each 911 call as follows:
(i) Fixed interconnected VoIP services. Providers of fixed
interconnected VoIP services must provide automated dispatchable
location with each 911 call.
(ii) Non-fixed interconnected VoIP services. For non-fixed
interconnected VoIP service (service that is capable of being used from
more than one location), interconnected VoIP service providers must
provide location information in accordance with paragraph (b)(4)(ii)(A)
of this section, if technically feasible. Otherwise, interconnected
VoIP service providers must either provide location information in
accordance with paragraph (b)(4)(ii)(B) or (C), or meet paragraph
(b)(4)(ii)(D) of this section.
(A) Provide automated dispatchable location, if technically
feasible.
(B) Provide Registered Location information that meets the
following requirements:
(1) The service provider has obtained from the customer, prior to
the initiation of service, the Registered Location (as defined in Sec.
9.3) at which the service will first be used;
(2) The service provider has provided end users one or more methods
of updating their Registered Location, including at least one option
that requires use only of the CPE necessary to access the
interconnected VoIP service. Any method used must allow an end user to
update the Registered Location at will and in a timely manner; and
(3) The service provider must identify whether the service is being
used to call 911 from a different location than the Registered
Location, and if so, either:
(i) Prompt the customer to provide a new Registered Location; or
(ii) Update the Registered Location without requiring additional
action by the customer.
(C) Provide Alternative Location Information as defined in Sec.
9.3.
(D) Route the caller to a national emergency call center.
(5) Customer notification. (i) Each interconnected VoIP service
provider shall specifically advise every subscriber, both new and
existing, prominently and in plain language, of the circumstances under
which E911 service may not be available through the interconnected VoIP
service or may be in some way limited by comparison to traditional E911
service. Such circumstances include, but are not limited to, relocation
of the end user's IP-compatible CPE, use by the end user of a non-
native telephone number, broadband connection failure, loss of
electrical power, and delays that may occur in making a dispatchable
location available in or through the ALI database;
(ii) Each interconnected VoIP service provider shall obtain and
keep a record of affirmative acknowledgement by every subscriber, both
new and existing, of having received and understood the advisory
described in paragraph (b)(5)(i) of this section; and
(iii) Each interconnected VoIP service provider shall either:
(A) Distribute to its existing subscribers, and to each new
subscriber prior to the initiation of that subscriber's service,
warning stickers or labels warning subscribers if E911 service may be
limited or not available, and instructing the subscriber to place them
on or near the equipment used in conjunction with the interconnected
VoIP service; or
(B) Notify existing subscribers, and each new subscriber prior to
the initiation of that subscriber's service, by other conspicuous means
if E911 service may be limited or not available.
(c) Paragraphs (b)(2)(ii) and (iv), (b)(4), and (b)(5)(ii) and
(iii) of this section contain information-collection and recordkeeping
requirements. Compliance will not be required until after approval by
the Office of Management and Budget. The Commission will publish a
document in the Federal Register announcing that compliance date and
revising this paragraph accordingly.
Sec. 9.12 Access to 911 and E911 service capabilities.
(a) Access. Subject to the other requirements of this part, an
owner or controller of a capability that can be used for 911 or E911
service shall make that capability available to a requesting
interconnected VoIP provider as set forth in paragraphs (a)(1) and (2)
of this section.
(1) If the owner or controller makes the requested capability
available to a CMRS provider, the owner or controller must make that
capability available to the interconnected VoIP provider. An owner or
controller makes a capability available to a CMRS provider if the owner
or controller offers that capability to any CMRS provider.
(2) If the owner or controller does not make the requested
capability available to a CMRS provider within the meaning of paragraph
(a)(1) of this section, the owner or controller must make that
capability available to a requesting interconnected VoIP provider only
if that capability is necessary to enable the interconnected VoIP
provider to provide 911 or E911 service in compliance with the
Commission's rules.
(b) Rates, terms, and conditions. The rates, terms, and conditions
on which a capability is provided to an interconnected VoIP provider
under paragraph (a) of this section shall be reasonable. For purposes
of this paragraph, it is evidence that rates, terms, and conditions are
reasonable if they are:
(1) The same as the rates, terms, and conditions that are made
available to CMRS providers, or
(2) In the event such capability is not made available to CMRS
providers, the same rates, terms, and conditions that are made
available to any telecommunications carrier or other entity for the
provision of 911 or E911 service.
(c) Permissible use. An interconnected VoIP provider that obtains
access to a capability pursuant to this section may use that capability
only for the purpose of providing 911 or E911 service in accordance
with the Commission's rules.
Subpart E--Telecommunications Relay Services for Persons with
Disabilities
Sec. 9.13 Jurisdiction.
Any violation of this subpart E by any common carrier engaged in
intrastate communication shall be subject to the same remedies,
penalties, and procedures as are applicable to a violation of the Act
by a common carrier engaged in interstate communication. For purposes
of this subpart, all
[[Page 66773]]
regulations and requirements applicable to common carriers shall also
be applicable to providers of interconnected VoIP service as defined in
Sec. 9.3.
Sec. 9.14 Emergency calling requirements.
(a) Emergency call handling requirements for TTY-based TRS
providers. TTY-based TRS providers must use a system for incoming
emergency calls that, at a minimum, automatically and immediately
transfers the caller to an appropriate Public Safety Answering Point
(PSAP). An appropriate PSAP is either a PSAP that the caller would have
reached if the caller had dialed 911 directly, or a PSAP that is
capable of enabling the dispatch of emergency services to the caller in
an expeditious manner.
(b) Additional emergency calling requirements applicable to
internet-based TRS providers. (1) The requirements of paragraphs
(b)(2)(i) and (iv) of this section shall not apply to providers of VRS
and IP Relay to which Sec. 9.14(c) and (d) apply.
(2) Each provider of internet-based TRS shall:
(i) When responsible for placing or routing voice calls to the
public switched telephone network, accept and handle emergency calls
and access, either directly or via a third party, a commercially
available database that will allow the provider to determine an
appropriate PSAP, designated statewide default answering point, or
appropriate local emergency authority that corresponds to the caller's
location, and to relay the call to that entity;
(ii) Implement a system that ensures that the provider answers an
incoming emergency call before other non-emergency calls (i.e.,
prioritize emergency calls and move them to the top of the queue);
(iii) Provide 911 and E911 service in accordance with paragraphs
(c) through (e) of this section, as applicable;
(iv) Deliver to the PSAP, designated statewide default answering
point, or appropriate local emergency authority, at the outset of the
outbound leg of an emergency call, at a minimum, the name of the relay
user and location of the emergency, as well as the name of the relay
provider, the CA's callback number, and the CA's identification number,
thereby enabling the PSAP, designated statewide default answering
point, or appropriate local emergency authority to re-establish contact
with the CA in the event the call is disconnected;
(v) In the event one or both legs of an emergency call are
disconnected (i.e., either the call between the TRS user and the CA, or
the outbound voice telephone call between the CA and the PSAP,
designated statewide default answering point, or appropriate local
emergency authority), immediately re-establish contact with the TRS
user and/or the appropriate PSAP, designated statewide default
answering point, or appropriate local emergency authority and resume
handling the call; and
(vi) Ensure that information obtained as a result of this section
is limited to that needed to facilitate 911 services, is made available
only to emergency call handlers and emergency response or law
enforcement personnel, and is used for the sole purpose of ascertaining
a user's location in an emergency situation or for other emergency or
law enforcement purposes.
(c) E911 Service for VRS and IP Relay before January 6, 2021, for
fixed services, and before January 6, 2022, for non-fixed services--(1)
Scope. The following requirements of paragraphs (c)(1) through (4) of
this section are only applicable to providers of VRS or IP Relay.
Further, these requirements apply only to 911 calls placed by
registered users whose Registered Location is in a geographic area
served by a Wireline E911 Network and is available to the provider
handling the call.
(2) E911 Service. VRS or IP Relay providers must, as a condition of
providing service to a user:
(i) Provide that user with E911 service as described in this
section;
(ii) Request, at the beginning of each emergency call, the caller's
name and location information, unless the VRS or IP Relay provider
already has, or has access to, Registered Location information for the
caller;
(iii) Transmit all 911 calls, as well as ANI, the caller's
Registered Location, the name of the VRS or IP Relay provider, and the
CA's identification number for each call, to the PSAP, designated
statewide default answering point, or appropriate local emergency
authority that serves the caller's Registered Location and that has
been designated for telecommunications carriers pursuant to Sec. 9.4,
provided that ``all 911 calls'' is defined as ``any communication
initiated by an VRS or IP Relay user dialing 911'';
(iv) Route all 911 calls through the use of ANI and, if necessary,
pseudo-ANI, via the dedicated Wireline E911 Network, provided that
nothing in this subparagraph shall preclude routing the call first to a
call center to ascertain the caller's location in the event that the
VRS or IP Relay provider believes the caller may not be located at the
Registered Location; and
(v) Make the Registered Location, the name of the VRS or IP Relay
provider, and the CA's identification number available to the
appropriate PSAP, designated statewide default answering point, or
appropriate local emergency authority from or through the appropriate
automatic location information (ALI) database.
(3) Service level obligation. Notwithstanding the provisions in
paragraph (c)(2) of this section, if a PSAP, designated statewide
default answering point, or appropriate local emergency authority is
not capable of receiving and processing either ANI or location
information, a VRS or IP Relay provider need not provide such ANI or
location information; however, nothing in this paragraph affects the
obligation under paragraph (c)(2)(iv) of this section of a VRS or IP
Relay provider to transmit via the Wireline E911 Network all 911 calls
to the PSAP, designated statewide default answering point, or
appropriate local emergency authority that serves the caller's
Registered Location and that has been designated for telecommunications
carriers pursuant to Sec. 9.4.
(4) Registered location requirement. VRS and IP Relay providers
must:
(i) Obtain from each Registered internet-based TRS user, prior to
the initiation of service, the physical location at which the service
will first be used; and
(ii) If the VRS or IP Relay is capable of being used from more than
one location, provide their registered internet-based TRS users one or
more methods of updating the user's Registered Location, including at
least one option that requires use only of the iTRS access technology
necessary to access the VRS or IP Relay. Any method used must allow a
registered internet-based TRS user to update the Registered Location at
will and in a timely manner.
(d) E911 Service for VRS and IP Relay on or after January 6, 2021,
for fixed services, and on or after January 6, 2022, for non-fixed
services--(1) Scope. The following requirements of paragraphs (d)(1)
through (4) of this section are only applicable to providers of VRS or
IP Relay. Further, these requirements apply only to 911 calls placed by
registered users whose dispatchable location is in a geographic area
served by a Wireline E911 Network and is available to the provider
handling the call.
(2) E911 Service. VRS or IP Relay providers must, as a condition of
providing service to a user:
(i) Provide that user with E911 service as described in this
section;
[[Page 66774]]
(ii) Request, at the beginning of each emergency call, the caller's
name and dispatchable location, unless the VRS or IP relay provider
already has, or has access to the location information described in
paragraph (d)(4) of this section;
(iii) Transmit the following to the PSAP, designated statewide
default answering point, or appropriate local emergency authority that
serves the caller's dispatchable location and that has been designated
for telecommunications carriers pursuant to Sec. 9.4:
(A) All 911 calls, provided that ``all 911 calls'' is defined as
``any communication initiated by an VRS or IP Relay user dialing 911;''
(B) ANI, the name of the VRS or IP Relay provider, and the CA's
identification number for each call; and
(C) The location information described in paragraph (d)(4) of this
section.
(iv) Route all 911 calls through the use of ANI and, if necessary,
pseudo-ANI, via the dedicated Wireline E911 Network, provided that
nothing in this subparagraph shall preclude routing the call first to a
call center to ascertain the caller's location in the event that the
VRS or IP Relay provider is unable to obtain or confirm the caller's
location information; and
(v) Make the location information described in paragraph (d)(4) of
this section, the name of the VRS or IP Relay provider, and the CA's
identification number available to the appropriate PSAP, designated
statewide default answering point, or appropriate local emergency
authority from or through the appropriate automatic location
information (ALI) database.
(3) Service level obligation. Notwithstanding the provisions in
paragraph (d)(2) of this section, if a PSAP, designated statewide
default answering point, or appropriate local emergency authority is
not capable of receiving and processing either ANI or location
information, a VRS or IP Relay provider need not provide such ANI or
location information; however, nothing in this paragraph affects the
obligation under paragraph (d)(2)(iv) of this section of a VRS or IP
Relay provider to transmit via the Wireline E911 Network all 911 calls
to the PSAP, designated statewide default answering point, or
appropriate local emergency authority that serves the caller's
dispatchable location and that has been designated for
telecommunications carriers pursuant to Sec. 9.4.
(4) Location requirements. To meet E911 service requirements, VRS
and IP Relay providers must provide location information with each 911
call as follows:
(i) Fixed VRS and IP Relay services. Providers of fixed VRS and IP
Relay services must provide automated dispatchable location with each
911 call.
(ii) Non-fixed VRS and IP Relay services. For non-fixed VRS and IP
Relay services (service that is capable of being used from more than
one location), VRS and IP Relay service providers must provide location
information in accordance with paragraph (d)(4)(ii)(A) of this section,
if technically feasible. Otherwise, VRS and IP Relay service providers
must either provide location information in accordance with paragraph
(d)(4)(ii)(B) or (C), or meet paragraph (d)(4)(ii)(D) of this section.
(A) Provide automated dispatchable location, if technically
feasible.
(B) Provide Registered Location information that meets the
following requirements:
(1) The service provider has obtained from the customer, prior to
the initiation of service, the Registered Location (as defined in Sec.
9.3) at which the service will first be used;
(2) The service provider has provided end users one or more methods
of updating their Registered Location, including at least one option
that requires use only of the internet-based TRS access technology
necessary to access the VRS or IP Relay. Any method used must allow an
end user to update the Registered Location at will and in a timely
manner; and
(3) If the VRS or IP Relay is capable of being used from more than
one location, if it is not possible to automatically determine the
Registered internet-based TRS user's location at the time of the
initiation of an emergency call, verify the current location with the
user at the beginning of an emergency call.
(C) Provide Alternative Location Information as defined in Sec.
9.3.
(D) Route the caller to a call center.
(e) E911 Service for IP CTS on or after January 6, 2021, for fixed
services, and on or after January 6, 2022, for non-fixed services--(1)
Scope. The following requirements of paragraphs (e)(1) through (4) of
this section are only applicable to ``covered IP CTS providers,'' who
are providers of IP CTS to the extent that the IP CTS provider, itself
or through an entity with whom the IP CTS provider contracts, places or
routes voice calls to the public switched telephone network. Further,
these requirements apply only to 911 calls placed by a registered user
whose dispatchable location is in a geographic area served by a
Wireline E911 Network and is available to the provider handling the
call.
(2) E911 Service. Covered IP CTS providers must, as a condition of
providing service to a user:
(i) Provide that user with E911 service as described in this
section;
(ii) Transmit or provide the following to the PSAP, designated
statewide default answering point, or appropriate local emergency
authority that serves the caller's dispatchable location and that has
been designated for telecommunications carriers pursuant to Sec. 9.4:
(A) All 911 calls, provided that ``all 911 calls'' is defined as
``any communication initiated by an IP CTS user dialing 911;''
(B) With the call, a telephone number that is assigned to the
caller and that enables the PSAP, designated statewide default
answering point, or appropriate local emergency authority to call the
911 caller back directly, while enabling the caller to receive captions
on the callback; and
(C) The location information described in paragraph (e)(4) of this
section.
(iii) Route all 911 calls through the use of ANI and, if necessary,
pseudo-ANI, via the dedicated Wireline E911 Network, provided that
nothing in this subparagraph shall preclude routing the call first to a
call center to ascertain the caller's location in the event that the
covered IP CTS provider is unable to obtain or confirm the caller's
location information; and
(iv) Make the location information described in paragraph (e)(4) of
this section and callback number available to the appropriate PSAP,
designated statewide default answering point, or appropriate local
emergency authority from or through the appropriate automatic location
information (ALI) database.
(3) Service level obligation. Notwithstanding the provisions in
paragraph (e)(2) of this section, if a PSAP, designated statewide
default answering point, or appropriate local emergency authority is
not capable of receiving and processing either ANI or location
information, a covered IP CTS provider need not provide such ANI or
location information; however, nothing in this paragraph affects the
obligation under paragraph (e)(2)(iii) of this section of a covered IP
CTS provider to transmit via the Wireline E911 Network all 911 calls to
the PSAP, designated statewide default answering point, or appropriate
local emergency authority that serves the caller's dispatchable
location and that has been designated for
[[Page 66775]]
telecommunications carriers pursuant to Sec. 9.4.
(4) Location requirements. To meet E911 service requirements,
covered IP CTS providers must provide location information with each
911 call as follows:
(i) Fixed IP CTS. Providers of fixed IP CTS must provide automated
dispatchable location with each 911 call.
(ii) Non-fixed IP CTS. For non-fixed IP CTS (service that is
capable of being used from more than one location), covered IP CTS
providers must provide location information in accordance with
paragraph (e)(4)(ii)(A) of this section, if technically feasible.
Otherwise, covered IP CTS providers must either provide location
information in accordance with paragraph (e)(4)(ii)(B) or (C), or meet
paragraph (e)(4)(iii)(D) of this section.
(A) Provide automated dispatchable location, if technically
feasible.
(B) Provide Registered Location information that meets the
following requirements:
(1) The service provider has obtained from the customer, prior to
the initiation of service, the Registered Location (as defined in Sec.
9.3) at which the service will first be used; and
(2) The service provider has provided end users one or more methods
of updating their Registered Location, including at least one option
that requires use only of the internet-based TRS access technology
necessary to access the IP CTS. Any method used must allow an end user
to update the Registered Location at will and in a timely manner.
(C) Provide Alternative Location Information as defined in Sec.
9.3.
(D) Route the caller to a call center.
(f) Paragraphs (d)(2)(ii), (iii), and (v), (d)(4), (e)(2)(ii) and
(iv), and (e)(4) of this section contain information-collection and
recordkeeping requirements. Compliance will not be required until after
approval by the Office of Management and Budget. The Commission will
publish a document in the Federal Register announcing that compliance
date and revising this paragraph accordingly.
Subpart F--Multi-Line Telephone Systems
Sec. 9.15 Applicability.
The rules in this subpart F apply to:
(a) A person engaged in the business of manufacturing, importing,
selling, or leasing multi-line telephone systems;
(b) A person engaged in the business of installing, managing, or
operating multi-line telephone systems;
(c) Any multi-line telephone system that is manufactured, imported,
offered for first sale or lease, first sold or leased, or installed
after February 16, 2020.
Sec. 9.16 General obligations--direct 911 dialing, notification, and
dispatchable location.
(a) Obligation of manufacturers, importers, sellers, and lessors.
(1) A person engaged in the business of manufacturing, importing,
selling, or leasing multi-line telephone systems may not manufacture or
import for use in the United States, or sell or lease or offer to sell
or lease in the United States, a multi-line telephone system, unless
such system is pre-configured such that, when properly installed in
accordance with paragraph (b) of this section, a user may directly
initiate a call to 911 from any station equipped with dialing
facilities, without dialing any additional digit, code, prefix, or
post-fix, including any trunk-access code such as the digit 9,
regardless of whether the user is required to dial such a digit, code,
prefix, or post-fix for other calls.
(2) A person engaged in the business of manufacturing, importing,
selling, or leasing multi-line telephone systems may not manufacture or
import for use in the United States, or sell or lease or offer to sell
or lease in the United States, a multi-line telephone system, unless
such system has the capability, after proper installation in accordance
with paragraph (b) of this section, of providing the dispatchable
location of the caller to the PSAP with 911 calls.
(b) Obligation of installers, managers, or operators. (1) A person
engaged in the business of installing, managing, or operating multi-
line telephone systems may not install, manage, or operate for use in
the United States such a system, unless such system is configured such
that a user may directly initiate a call to 911 from any station
equipped with dialing facilities, without dialing any additional digit,
code, prefix, or post-fix, including any trunk-access code such as the
digit 9, regardless of whether the user is required to dial such a
digit, code, prefix, or post-fix for other calls.
(2) A person engaged in the business of installing, managing, or
operating multi-line telephone systems shall, in installing, managing,
or operating such a system for use in the United States, configure the
system to provide MLTS notification to a central location at the
facility where the system is installed or to another person or
organization regardless of location, if the system is able to be
configured to provide the notification without an improvement to the
hardware or software of the system. MLTS notification must meet the
following requirements:
(i) MLTS notification must be initiated contemporaneously with the
911 call, provided that it is technically feasible to do so;
(ii) MLTS notification must not delay the call to 911; and
(iii) MLTS notification must be sent to a location where someone is
likely to see or hear it.
(3) A person engaged in the business of installing multi-line
telephone systems may not install such a system in the United States
unless it is configured such that it is capable of being programmed
with and conveying the dispatchable location of the caller to the PSAP
with 911 calls consistent with paragraphs (i), (ii) and (iii) of this
section. A person engaged in the business of managing or operating
multi-line telephone systems may not manage or operate such a system in
the United States unless it is configured such that the dispatchable
location of the caller is conveyed to the PSAP with 911 calls
consistent with paragraphs (i), (ii) and (iii) of this section.
(i) Dispatchable location requirements for on-premises fixed
telephones associated with a multi-line telephone system. An on-
premises fixed telephone associated with a multi-line telephone system
shall provide automated dispatchable location no later than January 6,
2021;
(ii) Dispatchable location requirements for on-premises non-fixed
devices associated with a multi-line telephone system. No later than
January 6, 2022, an on-premises non-fixed device associated with a
multi-line telephone system shall provide to the appropriate PSAP
automated dispatchable location, when technically feasible; otherwise,
it shall provide dispatchable location based on end user manual update,
or alternative location information as defined in Sec. 9.3.
(iii) Dispatchable location requirements for off-premises devices
associated with a multi-line telephone system. No later than January 6,
2022, an off-premises device associated with a multi-line telephone
system shall provide to the appropriate PSAP automatic dispatchable
location, if technically feasible; otherwise, it shall provide
dispatchable location based on end user manual update, or enhanced
location information, which may be coordinate-based, consisting of the
best available location that can be obtained from any available
technology or combination of technologies at reasonable cost.
(c) Compliance date. Paragraphs (b)(3)(i) through (iii) of this
section contain information-collection and recordkeeping requirements.
[[Page 66776]]
Compliance will not be required until after approval by the Office of
Management and Budget. The Commission will publish a document in the
Federal Register announcing that compliance date and revising this
paragraph accordingly.
Sec. 9.17 Enforcement, compliance date, State law.
(a) Enforcement. (1) Sections 9.16(a)(1) and (b)(1) and (2) shall
be enforced under title V of the Communications Act of 1934, as
amended, 5 U.S.C. 501 et seq., except that section 501 applies only to
the extent that such section provides for the punishment of a fine.
(2) In the event of noncompliance with Sec. 9.16(b), the person
engaged in the business of managing the multi-line telephone system
shall be presumed to be responsible for the noncompliance.
(3) Persons alleging a violation of the rules in Sec. 9.16 may
file a complaint under the procedures set forth in Sec. Sec. 1.711
through 1.737 of this chapter.
(b) Compliance date. The compliance date for this subpart F is
February 16, 2020, unless otherwise noted. Accordingly, the
requirements in this subpart apply to a multi-line telephone system
that is manufactured, imported, offered for first sale or lease, first
sold or leased, or installed after February 16, 2020, unless otherwise
noted.
(c) Effect on State law. Nothing in Sec. 9.16(a)(1) and (b)(1) and
(2) is intended to alter the authority of State commissions or other
State or local agencies with jurisdiction over emergency
communications, if the exercise of such authority is not inconsistent
with this subpart.
Subpart G--Mobile-Satellite Service
Sec. 9.18 Emergency Call Center service.
(a) Providers of Mobile-Satellite Service to end-user customers (47
CFR part 25, subparts A through D) must provide Emergency Call Center
service to the extent that they offer real-time, two way switched voice
service that is interconnected with the public switched network and use
an in-network switching facility which enables the provider to reuse
frequencies and/or accomplish seamless hand-offs of subscriber calls.
Emergency Call Center personnel must determine the emergency caller's
phone number and location and then transfer or otherwise redirect the
call to an appropriate public safety answering point. Providers of
Mobile-Satellite Services that use earth terminals that are not capable
of use while in motion are exempt from providing Emergency Call Center
service for such terminals.
(b) Each Mobile-Satellite Service carrier that is subject to the
provisions of paragraph (a) of this section must maintain records of
all 911 calls received at its emergency call center. By October 15, of
each year, Mobile-Satellite Service carriers providing service in the
1.6/2.4 GHz and 2 GHz bands must submit a report to the Commission
regarding their call center data, current as of September 30 of that
year. By June 30, of each year, Mobile-Satellite Service carriers
providing service in bands other than 1.6/2.4 GHz and 2 GHz must submit
a report to the Commission regarding their call center data, current as
of May 31 of that year. These reports must include, at a minimum, the
following:
(1) The name and address of the carrier, the address of the
carrier's emergency call center, and emergency call center contact
information;
(2) The aggregate number of calls received by the call center each
month during the relevant reporting period;
(3) An indication of how many calls received by the call center
each month during the relevant reporting period required forwarding to
a public safety answering point and how many did not require forwarding
to a public safety answering point.
Subpart H--Resiliency, Redundancy, and Reliability of 911
Communications
Sec. 9.19 Reliability of covered 911 service providers.
(a) Definitions. Terms in this section shall have the following
meanings:
(1) Aggregation point. A point at which network monitoring data for
a 911 service area is collected and routed to a network operations
center (NOC) or other location for monitoring and analyzing network
status and performance.
(2) Certification. An attestation by a certifying official, under
penalty of perjury, that a covered 911 service provider:
(i) Has satisfied the obligations of paragraph (c) of this section.
(ii) Has adequate internal controls to bring material information
regarding network architecture, operations, and maintenance to the
certifying official's attention.
(iii) Has made the certifying official aware of all material
information reasonably necessary to complete the certification.
(iv) The term ``certification'' shall include both an annual
reliability certification under paragraph (c) of this section and an
initial reliability certification under paragraph (d)(1) of this
section, to the extent provided under paragraph (d)(1).
(3) Certifying official. A corporate officer of a covered 911
service provider with supervisory and budgetary authority over network
operations in all relevant service areas.
(4) Covered 911 service provider. (i) Any entity that:
(A) Provides 911, E911, or NG911 capabilities such as call routing,
automatic location information (ALI), automatic number identification
(ANI), or the functional equivalent of those capabilities, directly to
a public safety answering point (PSAP), statewide default answering
point, or appropriate local emergency authority as defined in Sec.
9.3; and/or
(B) Operates one or more central offices that directly serve a
PSAP. For purposes of this section, a central office directly serves a
PSAP if it hosts a selective router or ALI/ANI database, provides
equivalent NG911 capabilities, or is the last service-provider facility
through which a 911 trunk or administrative line passes before
connecting to a PSAP.
(ii) The term ``covered 911 service provider'' shall not include
any entity that:
(A) Constitutes a PSAP or governmental authority to the extent that
it provides 911 capabilities; or
(B) Offers the capability to originate 911 calls where another
service provider delivers those calls and associated number or location
information to the appropriate PSAP.
(5) Critical 911 circuits. 911 facilities that originate at a
selective router or its functional equivalent and terminate in the
central office that serves the PSAP(s) to which the selective router or
its functional equivalent delivers 911 calls, including all equipment
in the serving central office necessary for the delivery of 911 calls
to the PSAP(s). Critical 911 circuits also include ALI and ANI
facilities that originate at the ALI or ANI database and terminate in
the central office that serves the PSAP(s) to which the ALI or ANI
databases deliver 911 caller information, including all equipment in
the serving central office necessary for the delivery of such
information to the PSAP(s).
(6) Diversity audit. A periodic analysis of the geographic routing
of network components to determine whether they are physically diverse.
Diversity audits may be performed through manual or automated means, or
through a review of paper or electronic records, as long as they
reflect whether critical 911 circuits are physically diverse.
(7) Monitoring links. Facilities that collect and transmit network
monitoring data to a NOC or other location for
[[Page 66777]]
monitoring and analyzing network status and performance.
(8) Physically diverse. Circuits or equivalent data paths are
Physically Diverse if they provide more than one physical route between
end points with no common points where a single failure at that point
would cause both circuits to fail. Circuits that share a common segment
such as a fiber-optic cable or circuit board are not Physically diverse
even if they are logically diverse for purposes of transmitting data.
(9) 911 service area. The metropolitan area or geographic region in
which a covered 911 service provider operates a selective router or the
functional equivalent to route 911 calls to the geographically
appropriate PSAP.
(10) Selective router. A 911 network component that selects the
appropriate destination PSAP for each 911 call based on the location of
the caller.
(11) Tagging. An inventory management process whereby critical 911
circuits are labeled in circuit inventory databases to make it less
likely that circuit rearrangements will compromise diversity. A covered
911 service provider may use any system it wishes to tag circuits so
long as it tracks whether critical 911 circuits are physically diverse
and identifies changes that would compromise such diversity.
(b) Provision of reliable 911 service. All covered 911 service
providers shall take reasonable measures to provide reliable 911
service with respect to circuit diversity, central-office backup power,
and diverse network monitoring. Performance of the elements of the
certification set forth in paragraphs (c)(1)(i), (c)(2)(i), and
(c)(3)(i) of this section shall be deemed to satisfy the requirements
of this paragraph. If a covered 911 service provider cannot certify
that it has performed a given element, the Commission may determine
that such provider nevertheless satisfies the requirements of this
paragraph based upon a showing in accordance with paragraph (c) of this
section that it is taking alternative measures with respect to that
element that are reasonably sufficient to mitigate the risk of failure,
or that one or more certification elements are not applicable to its
network.
(c) Annual reliability certification. One year after the initial
reliability certification described in paragraph (d)(1) of this section
and every year thereafter, a certifying official of every covered 911
service provider shall submit a certification to the Commission as
follows.
(1) Circuit auditing. (i) A covered 911 service provider shall
certify whether it has, within the past year:
(A) Conducted diversity audits of critical 911 circuits or
equivalent data paths to any PSAP served;
(B) Tagged such critical 911 circuits to reduce the probability of
inadvertent loss of diversity in the period between audits; and
(C) Eliminated all single points of failure in critical 911
circuits or equivalent data paths serving each PSAP.
(ii) If a Covered 911 Service Provider does not conform with all of
the elements in paragraph (c)(1)(i) of this section with respect to the
911 service provided to one or more PSAPs, it must certify with respect
to each such PSAP:
(A) Whether it has taken alternative measures to mitigate the risk
of critical 911 circuits that are not physically diverse or is taking
steps to remediate any issues that it has identified with respect to
911 service to the PSAP, in which case it shall provide a brief
explanation of such alternative measures or such remediation steps, the
date by which it anticipates such remediation will be completed, and
why it believes those measures are reasonably sufficient to mitigate
such risk; or
(B) Whether it believes that one or more of the requirements of
this paragraph are not applicable to its network, in which case it
shall provide a brief explanation of why it believes any such
requirement does not apply.
(2) Backup power. (i) With respect to any central office it
operates that directly serves a PSAP, a covered 911 service provider
shall certify whether it:
(A) Provisions backup power through fixed generators, portable
generators, batteries, fuel cells, or a combination of these or other
such sources to maintain full-service functionality, including network
monitoring capabilities, for at least 24 hours at full office load or,
if the central office hosts a selective router, at least 72 hours at
full office load; provided, however, that any such portable generators
shall be readily available within the time it takes the batteries to
drain, notwithstanding potential demand for such generators elsewhere
in the service provider's network.
(B) Tests and maintains all backup power equipment in such central
offices in accordance with the manufacturer's specifications;
(C) Designs backup generators in such central offices for fully
automatic operation and for ease of manual operation, when required;
(D) Designs, installs, and maintains each generator in any central
office that is served by more than one backup generator as a stand-
alone unit that does not depend on the operation of another generator
for proper functioning.
(ii) If a covered 911 service provider does not conform with all of
the elements in paragraph (c)(2)(i) of this section, it must certify
with respect to each such central office:
(A) Whether it has taken alternative measures to mitigate the risk
of a loss of service in that office due to a loss of power or is taking
steps to remediate any issues that it has identified with respect to
backup power in that office, in which case it shall provide a brief
explanation of such alternative measures or such remediation steps, the
date by which it anticipates such remediation will be completed, and
why it believes those measures are reasonably sufficient to mitigate
such risk; or
(B) Whether it believes that one or more of the requirements of
this paragraph are not applicable to its network, in which case it
shall provide a brief explanation of why it believes any such
requirement does not apply.
(3) Network monitoring. (i) A covered 911 service provider shall
certify whether it has, within the past year:
(A) Conducted diversity audits of the aggregation points that it
uses to gather network monitoring data in each 911 service area;
(B) Conducted diversity audits of monitoring links between
aggregation points and NOCs for each 911 service area in which it
operates; and
(C) Implemented physically diverse aggregation points for network
monitoring data in each 911 service area and physically diverse
monitoring links from such aggregation points to at least one NOC.
(ii) If a Covered 911 Service Provider does not conform with all of
the elements in paragraph (c)(3)(i) of this section, it must certify
with respect to each such 911 Service Area:
(A) Whether it has taken alternative measures to mitigate the risk
of network monitoring facilities that are not physically diverse or is
taking steps to remediate any issues that it has identified with
respect to diverse network monitoring in that 911 service area, in
which case it shall provide a brief explanation of such alternative
measures or such remediation steps, the date by which it anticipates
such remediation will be completed, and why it believes those measures
are reasonably sufficient to mitigate such risk; or
[[Page 66778]]
(B) Whether it believes that one or more of the requirements of
this paragraph are not applicable to its network, in which case it
shall provide a brief explanation of why it believes any such
requirement does not apply.
(d) Other matters--(1) Initial reliability certification. One year
after October 15, 2014, a certifying official of every covered 911
service provider shall certify to the Commission that it has made
substantial progress toward meeting the standards of the annual
reliability certification described in paragraph (c) of this section.
Substantial progress in each element of the certification shall be
defined as compliance with standards of the full certification in at
least 50 percent of the covered 911 service provider's critical 911
circuits, central offices that directly serve PSAPs, and independently
monitored 911 service areas.
(2) Confidential treatment. (i) The fact of filing or not filing an
annual reliability certification or initial reliability certification
and the responses on the face of such certification forms shall not be
treated as confidential.
(ii) Information submitted with or in addition to such
certifications shall be presumed confidential to the extent that it
consists of descriptions and documentation of alternative measures to
mitigate the risks of nonconformance with certification elements,
information detailing specific corrective actions taken with respect to
certification elements, or supplemental information requested by the
Commission or Bureau with respect to a certification.
(3) Record retention. A covered 911 service provider shall retain
records supporting the responses in a certification for two years from
the date of such certification, and shall make such records available
to the Commission upon request. To the extent that a covered 911
service provider maintains records in electronic format, records
supporting a certification hereunder shall be maintained and supplied
in an electronic format.
(i) With respect to diversity audits of critical 911 circuits, such
records shall include, at a minimum, audit records separately
addressing each such circuit, any internal report(s) generated as a
result of such audits, records of actions taken pursuant to the audit
results, and records regarding any alternative measures taken to
mitigate the risk of critical 911 circuits that are not physically
diverse.
(ii) With respect to backup power at central offices, such records
shall include, at a minimum, records regarding the nature and extent of
backup power at each central office that directly serves a PSAP,
testing and maintenance records for backup power equipment in each such
central office, and records regarding any alternative measures taken to
mitigate the risk of insufficient backup power.
(iii) With respect to network monitoring, such records shall
include, at a minimum, records of diversity audits of monitoring links,
any internal report(s) generated as a result of such audits, records of
actions taken pursuant to the audit results, and records regarding any
alternative measures taken to mitigate the risk of aggregation points
and/or monitoring links that are not physically diverse.
Sec. 9.20 Backup power obligations.
(a) Covered service. For purposes of this section, a Covered
Service is any facilities-based, fixed voice service offered as
residential service, including fixed applications of wireless service
offered as a residential service, that is not line powered.
(b) Obligations of providers of a Covered Service to offer backup
power. Providers of a Covered Service shall, at the point of sale for a
Covered Service, offer subscribers the option to purchase backup power
for the Covered Service as follows:
(1) Eight hours. Providers shall offer for sale at least one option
with a minimum of eight hours of standby backup power.
(2) Twenty-four hours. By February 13, 2019, providers of a Covered
Service shall offer for sale also at least one option that provides a
minimum of twenty-four hours of standby backup power.
(3) Options. At the provider's discretion, the options in
paragraphs (b)(1) and (2) of this section may be either:
(i) A complete solution including battery or other power source; or
(ii) Installation by the provider of a component that accepts or
enables the use of a battery or other backup power source that the
subscriber obtains separately. If the provider does not offer a
complete solution, the provider shall install a compatible battery or
other power source if the subscriber makes it available at the time of
installation and so requests. After service has been initiated, the
provider may, but is not required to, offer to sell any such options
directly to subscribers.
(c) Backup power required. The backup power offered for purchase
under paragraph (b) of this section must include power for all
provider-furnished equipment and devices installed and operated on the
customer premises that must remain powered in order for the service to
provide 911 access.
(d) Subscriber disclosure. (1) The provider of a Covered Service
shall disclose to each new subscriber at the point of sale and to all
subscribers to a Covered Service annually thereafter:
(i) Capability of the service to accept backup power, and if so,
the availability of at least one backup power solution available
directly from the provider, or after the initiation of service,
available from either the provider or a third party. After the
obligation to offer for purchase a solution for twenty-four hours of
standby backup power becomes effective, providers must disclose this
information also for the twenty-four-hour solution;
(ii) Service limitations with and without backup power;
(iii) Purchase and replacement information, including cost;
(iv) Expected backup power duration;
(v) Proper usage and storage conditions, including the impact on
duration of failing to adhere to proper usage and storage;
(vi) Subscriber backup power self-testing and -monitoring
instructions; and
(vii) Backup power warranty details, if any.
(2) Disclosure reasonably calculated to reach each subscriber. A
provider of a Covered Service shall make disclosures required by this
rule in a manner reasonably calculated to reach individual subscribers,
with due consideration for subscriber preferences. Information posted
on a provider's public website and/or within a subscriber portal
accessed by logging through the provider's website are not sufficient
to comply with these requirements.
(3) The disclosures required under this paragraph are in addition
to, but may be combined with, any disclosures required under Sec.
9.11(a)(5) and (b)(5).
(e) Obligation with respect to existing subscribers. Providers are
not obligated to offer for sale backup power options to or retrofit
equipment for those who are subscribers as of the effective date listed
in paragraph (f) of this section for the obligations in paragraph
(b)(1) of this section, but shall provide such subscribers with the
annual disclosures required by paragraph (d) of this section.
(f) Dates of obligations. (1) Except as noted in paragraphs (b)(2)
and (f)(2) of this section, the obligations under paragraph (b) of this
section are in effect February 16, 2016, and the obligations under
paragraph (d) of this section are in effect August 5, 2016.
[[Page 66779]]
(2) For a provider of a Covered Service that (together with any
entities under common control with such provider) has fewer than
100,000 domestic retail subscriber lines, the obligations in paragraph
(b)(1) of this section are in effect August 11, 2016, the obligations
in paragraph (b)(2) of this section are in effect as prescribed
therein, and the obligations under paragraph (d) of this section are in
effect February 1, 2017.
(g) Sunset date. The requirements of this section shall no longer
be in effect as of September 1, 2025.
PART 12--[REMOVED AND RESERVED]
0
7. Under the authority of 47 U.S.C. 154(i), part 12 is removed.
PART 20--COMMERCIAL MOBILE SERVICES
0
8. The authority citation for part 20 continues to read as follows:
Authority: 47 U.S.C. 151, 152(a), 154(i), 157, 160, 201, 214,
222, 251(e), 301, 302, 303, 303(b), 303(r), 307, 307(a), 309,
309(j)(3), 316, 316(a), 332, 610, 615, 615a, 615b, 615c, unless
otherwise noted.
0
9. Section 20.2 is amended by adding paragraph (c) to read as follows:
Sec. 20.2 Other applicable rule parts.
* * * * *
(c) Part 9. This part contains 911 and E911 requirements applicable
to telecommunications carriers and commercial mobile radio service
(CMRS) providers.
Sec. 20.3 [Amended]
0
10. Section 20.3 is amended by removing the definitions of
``Appropriate local emergency authority,'' ``Automatic Number
Identification (ANI),'' ``Designated PSAP,'' ``Handset-based location
technology,'' ``Location-capable handsets,'' ``Network-based Location
Technology,'' ``Pseudo Automatic Number Identification (Pseudo-ANI),''
``Public safety answering point (PSAP),'' and ``Statewide default
answering point''.
Sec. 20.18 [Removed and Reserved]
0
11. Section 20.18 is removed and reserved.
PART 22--PUBLIC MOBILE SERVICES
0
12. The authority citation for part 22 continues to read as follows:
Authority: 47 U.S.C. 154, 222, 303, 309, and 332.
Sec. 22.921 [Removed and Reserved]
0
13. Section 22.921 is removed and reserved.
PART 25--SATELLITE COMMUNICATIONS
0
14. The authority citation for part 25 continues to read as follows:
Authority: 47 U.S.C. 154, 301, 302, 303, 307, 309, 310, 319,
332, 605, and 721, unless otherwise noted.
Sec. 25.103 [Amended]
0
15. Section 25.103 is amended by removing the definition of ``Emergency
Call Center''.
Sec. 25.284 [Removed and Reserved]
0
16. Section 25.284 is removed and reserved.
PART 64--MISCELLANEOUS RULES RELATING TO COMMON CARRIERS
0
17. The authority citation for part 64 continues to read as follows:
Authority: 47 U.S.C. 154, 201, 202, 217, 218, 220, 222, 225,
226, 227, 228, 251(a), 251(e), 254(k), 262, 403(b)(2)(B), (c), 616,
620, 1401-1473, unless otherwise noted.
0
18. Section 64.601 is amended by revising paragraph (a) to read as
follows:
Sec. 64.601 Definitions and provisions of general applicability.
(a) For purposes of this subpart, the term affiliate is defined in
47 CFR 52.12(a)(1)(i), and the terms majority and debt are defined in
47 CFR 52.12(a)(1)(ii).
* * * * *
0
19. Section 64.603 is amended by revising paragraph (a) to read as
follows:
Sec. 64.603 Provision of services.
(a) Each common carrier providing telephone voice transmission
services shall provide, in compliance with the regulations prescribed
herein and the emergency calling requirements in part 9, subpart E of
this chapter, throughout the area in which it offers services,
telecommunications relay services, individually, through designees,
through a competitively selected vendor, or in concert with other
carriers. Interstate Spanish language relay service shall be provided.
Speech-to-speech relay service also shall be provided, except that
speech-to-speech relay service need not be provided by IP Relay
providers, VRS providers, captioned telephone relay service providers,
and IP CTS providers. In addition, each common carrier providing
telephone voice transmission services shall provide access via the 711
dialing code to all relay services as a toll free call. CMRS providers
subject to this 711 access requirement are not required to provide 711
dialing code access to TTY users if they provide 711 dialing code
access via real-time text communications, in accordance with 47 CFR
part 67.
* * * * *
0
20. Section 64.604 is amended by removing and reserving paragraph
(a)(4) and revising paragraph (d).
The revision reads as follows:
Sec. 64.604 Mandatory minimum standards.
* * * * *
(d) Other standards. The applicable requirements of Sec. 9.14 of
this chapter and Sec. Sec. 64.611, 64.615, 64.617, 64.621, 64.631,
64.632, 64.5105, 64.5107, 64.5108, 64.5109, and 64.5110 of this part
are to be considered mandatory minimum standards.
Sec. 64.605 [Removed and Reserved]
0
21. Section 64.605 is removed and reserved.
Subpart AA--[Removed and Reserved]
0
22. Subpart AA, consisting of Sec. Sec. 64.3000 through 64.3004, is
removed and reserved.
[FR Doc. 2019-20137 Filed 11-27-19; 8:45 am]
BILLING CODE 6712-01-P