[Federal Register Volume 83, Number 208 (Friday, October 26, 2018)]
[Proposed Rules]
[Pages 54180-54224]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2018-21888]
[[Page 54179]]
Vol. 83
Friday,
No. 208
October 26, 2018
Part II
Federal Communications Commission
-----------------------------------------------------------------------
47 CFR Parts 9, 12, 20, et al.
Improving the 911 System by Implementing Kari's Law and RAY BAUM'S Act;
Proposed Rule
Federal Register / Vol. 83 , No. 208 / Friday, October 26, 2018 /
Proposed Rules
[[Page 54180]]
-----------------------------------------------------------------------
FEDERAL COMMUNICATIONS COMMISSION
47 CFR Parts 9, 12, 20, 25, and 64
[PS Docket Nos. 18-261, 17-239; FCC 18-132]
Improving the 911 System by Implementing Kari's Law and RAY
BAUM'S Act
AGENCY: Federal Communications Commission.
ACTION: Proposed rule.
-----------------------------------------------------------------------
SUMMARY: In this document, the Federal Communications Commission (the
FCC or Commission) proposes rules for 911 calls made from multi-line
telephone systems (MLTS), pursuant to Kari's Law, the conveyance of
dispatchable location with 911 calls, as directed by RAY BAUM'S Act,
and the consolidation of the Commission's 911 rules. The Commission
also proposes consolidating the Commission's existing 911 rules into a
single rule part.
DATES: Comments are due on or before December 10, 2018 and reply
comments are due on or before January 9, 2019.
ADDRESSES: You may submit comments, identified by PS Docket Nos. 18-261
and 17-239 by any of the following methods:
Federal eRulemaking Portal: http://www.regulations.gov.
Follow the instructions for submitting comments.
Federal Communications Commission's Website: http://www.fcc.gov/ecfs/. Follow the instructions for submitting comments.
Mail: Filings can be sent by hand or messenger delivery,
by commercial overnight courier, or by first-class or overnight U.S.
Postal Service mail (although the Commission continues to experience
delays in receiving U.S. Postal Service mail). All filings must be
addressed to the Commission's Secretary, Office of the Secretary,
Federal Communications Commission.
People with Disabilities: Contact the Commission to
request reasonable accommodations (accessible format documents, sign
language interpreters, CART, etc.) by email: [email protected] or phone:
202-418-0530 or TTY: 202-418-0432.
For detailed instructions for submitting comments and additional
information on the rulemaking process, see the SUPPLEMENTARY
INFORMATION section of this document.
FOR FURTHER INFORMATION CONTACT: Brenda Boykin, Attorney-Advisor,
Policy and Licensing Division, Public Safety and Homeland Security
Bureau, (202) 418-2062 or via email at [email protected]; Austin
Randazzo, Attorney-Advisor, Policy and Licensing Division, Public
Safety and Homeland Security Bureau, (202) 418-1462 or via email at
[email protected].
SUPPLEMENTARY INFORMATION: This is a summary of the Commission's Notice
of Proposed Rulemaking (NPRM) in PS Docket Nos. 18-261 and 17-239, FCC
18-132, adopted and released on September 26, 2018. The full text of
this document is available for inspection and copying during normal
business hours in the FCC Reference Center (Room CY-A257), 445 12th
Street SW, Washington, DC 20554. The full text may also be downloaded
at: www.fcc.gov.
Synopis
I. Introduction
1. In this proceeding, the Commission takes steps to advance
Congressional and Commission objectives to ensure that members of the
public can successfully dial 911 to request emergency services and that
Public Safety Answering Points (PSAPs) can quickly and accurately
locate every 911 caller, regardless of the type of service that is used
to make the call. The President recently signed into law two statutes
directed to the improvement of 911: (1) Kari's Law Act of 2017 (Kari's
Law), which requires implementation of direct 911 dialing and on-site
notification capabilities in multi-line telephone systems (MLTS), and
(2) Section 506 of RAY BAUM'S Act (RAY BAUM'S Act), which requires the
Commission by September 23, 2019 to ``conclude a proceeding to consider
adopting rules to ensure that the dispatchable location is conveyed
with a 9-1-1 call, regardless of the technological platform used and
including with calls from [MLTS].''
2. In this NPRM, we propose to implement Kari's Law by adopting
direct dial and notification rules governing calls to 911 made from
MLTS. As required by RAY BAUM'S Act, we also consider the feasibility
of requiring dispatchable location for 911 calls from MLTS and other
technological platforms that currently complete calls to 911. We
propose establishing a dispatchable location requirement for MLTS 911
calls, which would apply contemporaneously with the February 16, 2020
compliance date of Kari's Law. Additionally, in keeping with the
directive in RAY BAUM'S Act to address dispatchable location for 911
calls ``regardless of the technological platform used,'' we propose to
add dispatchable location requirements to our existing 911 rules for
fixed telephony providers, interconnected Voice over internet Protocol
(VoIP) providers, and internet-based Telecommunications Relay Services
(TRS). We also consider the feasibility of alternative location
mechanisms for MLTS and other services that could be used as a
complement to dispatchable location or as a substitute when
dispatchable location is not available. Additionally, we consider
whether dispatchable location requirements should be extended to other
communications services that are not covered by existing 911 rules but
are capable of making a 911 call.
3. Finally, we propose to take this opportunity to consolidate our
existing 911 rules, as well as the direct dialing and dispatchable
location rules proposed in this NPRM, into a single rule part. The
Commission historically has taken a service-specific approach to 911,
resulting in 911 requirements for different services scattered across
different sections of the agency's rules. We believe that consolidating
our 911 rules from these various rule sections into a single rule part
will further the goal of recognizing that all the components of 911
function as part of a single system and will enable service providers,
emergency management officials, and other stakeholders to refer to a
single part of the Commission's rules to more easily ascertain all 911
requirements.
II. Background
A. E911 and Multi-Line Telephone Systems
4. Enhanced 911 (E911) was developed to provide PSAPs with the
caller's location and a call-back number as part of each 911 call.
Since its implementation, most E911 calls have conveyed information
regarding the caller's location (with varying degrees of accuracy) and
a call-back number to the PSAP. These enhancements have significantly
improved PSAPs' ability to effectively deliver critical public safety
and emergency response services in a timely manner. In many instances,
E911 has proven to be a life-saving, essential emergency response tool
for providing critical information when the caller is unable to
verbally communicate his or her location, including when the voice call
is dropped or discontinued and cannot be reestablished.
5. Under the Commission's rules, consumers generally have access to
these capabilities when they make fixed telephony, mobile, and
interconnected VoIP calls to 911. However, to date, the Commission's
E911 rules have not
[[Page 54181]]
applied to MLTS. Consequently, consumers in environments such as office
buildings, campuses, and hotels may not have the same access to E911
services that is provided by fixed telephony, mobile, and VoIP systems,
namely direct dialing access to 911 and the provision of the MLTS
user's location information.
6. MLTS include a widely embedded base of legacy PBX, Centrex, and
Key Telephone systems, internet Protocol (IP)-based systems, and hybrid
systems. MLTS serve millions of employees, residents, and guests of
businesses and educational facilities, including corporate parks,
hotels, college campuses, and planned community developments. These
systems can support anywhere from ten to thousands of telephone
station/numbers. Emergency calls from MLTS stations generally only
provide PSAPs the telephone or circuit number of the system's outgoing
trunk, and not the emergency caller's individual station number. In
some cases, the MLTS station that placed the call will not even have
its own telephone number. As a result, PSAPs often find they are unable
to locate an MLTS emergency call to the station from which it
originated. The Commission in 2003 considered E911 requirements for
MLTS but deferred to the states to address this issue, while preserving
the option of acting should states fail to do so.
7. The National Emergency Number Association (NENA) has proposed
model MLTS legislation for states, as well as model federal MLTS
legislation. To date, 23 states have enacted legislation that requires
organizations over a certain size or purchasing a new PBX/MLTS system
to implement E911 on the system. These states have adopted varied
requirements for MLTS providers, and only in some instances have state
laws specifically addressed prefix dialing requirements.
8. In the absence of federal or consistent state regulation, some
MLTS in operation today do not support direct 911 dialing, may not have
the capability to route calls to the appropriate PSAP relative to the
caller's location, or may not provide accurate information regarding
the caller's location. The Commission has observed that these issues
have persisted, even as many enterprises are increasingly relying on
IP-based systems, including cloud-based services, to support their
communications needs. Given that the ongoing evolution of MLTS has not
eliminated these shortfalls when serving 911 callers, the Commission
has periodically sought to examine MLTS provision of 911, including the
capabilities of MLTS to support direct 911 access, routing, callback,
and automatic location
9. In September 2017, the Commission released a Notice of Inquiry
(ECS NOI) seeking information on the capabilities of enterprise
communications systems (ECS) to support direct 911 access, routing, and
automatic location. The Commission noted that ECS may not provide
consumers with the same access to E911 services as non-ECS wireline,
wireless, and interconnected VoIP calls and asked whether it is still
the case, as the Commission found in earlier proceedings, that the
needs and circumstances of residential and business ECS users are
suited to state-level action rather than federal regulation. The ECS
NOI also sought information on the state of the ECS industry; the costs
and benefits of supporting E911 for ECS; the capability of ECS to
provide accessible emergency communications for persons with
disabilities; and options for ensuring that ECS keep pace with
technological developments and consumer expectations for access to 911.
10. The Commission received 19 comments and six reply comments in
response to the ECS NOI. Commenters generally agreed that the ECS
marketplace is diverse and complex. For example, Cisco categorized ECS
as falling within three types: (1) On-premises hardware and software;
(2) cloud solutions; and (3) over-the-top applications. West Safety
categorized ECS as falling within three additional and different types:
(1) Time-division multiplexing (TDM) ECS, which are self-contained and
proprietary and use physical switches and wiring with localized
infrastructure; (2) hybrid ECS, which have combined TDM and IP
extensions and provide reduced infrastructure and interoperability; and
(3) IP ECS, which have centralized infrastructure and servers, Session
Initiation Protocol (SIP) capabilities with multimedia support, and
scalability. West Safety noted that TDM-based ECS have been ``nearing
end-of-life for a long time now'' and that the vast majority of
enterprises have migrated, or will migrate soon, to pure IP-based ECS
to support VoIP and Unified Communications (UC) systems, with an
increasing trend toward cloud-based service offerings.
11. Commenters underscored the importance of ensuring the
accessibility of ECS for persons with disabilities, including ECS
capability to handle text (including real time text (RTT)), data,
video, and text telephone (TTY) calls and the availability of
dispatchable location information to PSAPs regardless of the type of
call being made. Commenters, however, disagreed over whether it is
feasible for all types of ECS to support precise location of 911
callers. In addition, commenters disagreed regarding the Commission's
authority to establish 911 requirements for ECS. Some commenters
asserted that the Commission lacked such authority because most
enterprise owners and equipment manufacturers do not provide interstate
communications, or because ECS owners and operators are not service
providers under Title II of the Communications Act or licensees under
Title III. Other commenters asserted that 911 calls from ECS are
interstate in nature, and that the Commission has broad authority over
public safety and 911, including authority over ECS operators and
equipment and service vendors under Sections 1, 4, and 255 of the
Communications Act, as well as the Twenty-First Century Communications
and Video Accessibility Act of 2010 (CVAA). Finally, some commenters
asserted that state regulation of ECS 911 service is not working and
urged the Commission to begin a rulemaking, while others urged the
Commission to continue to defer to the states to address ECS 911
functionality.
B. Kari's Law and RAY BAUM'S Act
12. Kari's Law. After the close of the ECS NOI comment/reply cycle,
Kari's Law was enacted on February 16, 2018. Kari's Law has been added
to the Communications Act of 1934 as amended (the Act) as section 721.
13. Kari's Law establishes a federal multi-tiered approach to MLTS
911 requirements. First, Kari's Law applies to any ``person engaged in
the business of manufacturing, importing, selling, or leasing'' MLTS.
Such persons ``may not manufacture or import for use in the United
States, or sell or lease or offer to sell or lease in the United
States, a [MLTS], unless such system is pre-configured such that, when
properly installed . . . a user may directly initiate a call to 9-1-1
from any station equipped with dialing facilities, without dialing any
additional digit, code, prefix, or post-fix, including any trunk-access
code such as the digit `9', regardless of whether the user is required
to dial such a digit, code, prefix, or post-fix for other calls.''
14. Second, Kari's Law applies to any ``person engaged in the
business of installing, managing, or operating'' MLTS. Such persons
``may not install, manage, or operate for use in the United States such
a system, unless such system is configured such that a user
[[Page 54182]]
may directly initiate a call to 9-1-1 from any station equipped with
dialing facilities, without dialing any additional digit, code, prefix,
or post-fix, including any trunk-access code such as the digit `9',
regardless of whether the user is required to dial such a digit, code,
prefix, or post-fix for other calls.'' Additionally, such persons
``shall, in installing, managing, or operating such a system for use in
the United States, configure the system to provide a notification to a
central location at the facility where the system is installed or to
another person or organization regardless of location, if the system is
able to be configured to provide the notification without an
improvement to the hardware or software of the system.''
15. With regard to implementation, Kari's Law expressly provides
that Congress did not intend to ``alter the authority of State
commissions or other State or local agencies with jurisdiction over
emergency communications, if the exercise of such authority is not
inconsistent with this Act.'' Kari's Law directs the Commission to
enforce the provisions under Title V of the Communications Act of 1934,
as amended, ``except that section 501 applies only to the extent that
such section provides for the punishment of a fine.'' The effective
date provision states that Kari's Law ``shall apply with respect to a
multi-line telephone system that is manufactured, imported, offered for
first sale or lease, first sold or leased, or installed after''
February 16, 2020.
16. RAY BAUM'S Act. The President signed the Consolidated
Appropriations Act of 2018, including RAY BAUM'S Act, into law on March
23, 2018. Section 506 of RAY BAUM'S Act requires the Commission to
``conclude a proceeding to consider adopting rules to ensure that the
dispatchable location is conveyed with a 9-1-1 call, regardless of the
technological platform used and including with calls from multi-line
telephone systems'' by September 23, 2019. In conducting this
proceeding, ``the Commission may consider information and conclusions
from other Commission proceedings regarding the accuracy of the
dispatchable location for a 9-1-1 call, but nothing in this section
shall be construed to require the Commission to reconsider any
information or conclusion from a proceeding regarding the accuracy of
the dispatchable location for a 9-1-1 call in which the Commission has
adopted rules or issued an order'' before the March 23, 2018 enactment
date of Section 506.
III. Discussion
A. Direct Dialing and Notification for MLTS
17. Kari's Law is a provision of the Communications Act of 1934, as
amended. Accordingly, the Commission has authority to prescribe such
rules and regulations as are necessary to carry out Kari's Law. We
believe that adoption of implementing regulations would provide
additional clarity and specificity regarding the terms used in the
statute and the obligations placed on covered entities. Implementing
regulations can provide important guidance to covered entities on
complying with the law and the mechanism the Commission will use to
enforce the statute. Accordingly, our proposed rules include
definitions of some of the terms in Kari's Law, as well as other
provisions to clarify the obligations of entities regulated under the
statute.
1. Direct Dialing
18. Applicability and Obligations. We propose direct dialing
requirements for persons engaged in the business of manufacturing,
importing, selling, or leasing MLTS, as well as persons engaged in the
business of installing, managing, or operating MLTS, that track the
obligations in Kari's Law. We seek comment on these proposed
implementing regulations.
2. Notification
19. Applicability and Obligations. Consistent with Kari's Law, we
propose to adopt implementing regulations requiring that a person
engaged in the business of installing, managing, or operating MLTS
shall, in installing, managing, or operating the system, configure it
to provide a notification that a 911 call has been placed by a caller
on the MLTS system. The system configuration must provide for the
notification to be transmitted to a central location at the facility
where the system is installed or to another person or organization
regardless of location, if the system is able to be configured to
provide the notification without an improvement to the hardware or
software of the system. This notification requirement will potentially
benefit three parties: (1) The 911 caller by speeding response time;
(2) enterprise management and staff by providing needed information and
reducing confusion and delay when emergency response teams arrive; and
(3) first responders by reducing time spent responding to such calls.
20. Required Information and Purpose. Although Kari's Law requires
MLTS to support notification when an MLTS user makes a 911 call, it
does not specify what information must be provided in the notification.
In comments on the ECS NOI, West Safety noted that on-site notification
can be configured to include name, callback number, precise station-
level location, and links to enhanced data such as detailed floor plans
and emergency contacts. NENA's model federal MLTS legislation provides
for on-site notification that would automatically alert a designated
emergency station on the premises that 911 has been dialed from the
MLTS and would include specific location information for the station
from which the call originated. Rules implementing a Texas statute
similar to Kari's Law provide that the notification should include the
telephone number or extension and location information of the handset
from which the 911 call is made, provided that it is feasible to do so.
21. We tentatively conclude that for notification to be capable of
achieving the purpose of Kari's Law, it should include certain basic
information, such as the caller's location, that will assist the
enterprise and first responders in coordinating and expediting on-site
response to the emergency. According to Avaya, the benefits of on-site
notification include that it can ``allow[] internal responders to
confirm and assist the person who has dialed 9-1-1, and provide[]
notice that first responders are on the way so that preparations can be
made. This includes ensuring access doors are unlocked, elevators are
available and hallways are unobstructed.'' RedSky has stated that on-
site notification ``can save 2-3 minutes in emergency response time
when a 9-1-1- call is made.''
22. We propose to require that notification at a minimum include
the following information: (1) The fact that a 911 call has been made,
(2) a valid callback number, and (3) the information about the caller's
location that the MLTS conveys to the PSAP with the call to 911. Thus,
under our dispatchable location proposal discussed in Section B.1
below, the notification to the enterprise would include the same
dispatchable location information that the PSAP receives. Because the
notification will help the enterprise to assist first responders, we
believe it makes sense for the recipient of the notification to have
the same information as the PSAP (and, indirectly, the first responders
dispatched to the scene). In addition, because our proposal assumes the
notification would only convey information that already exists for the
[[Page 54183]]
911 call, we tentatively conclude that providing the same information
would minimize additional burdens. We seek comment on this proposed
approach. Are there situations in which the callback or location
information conveyed to the PSAP need not be included with an on-site
notification? Instead of specifying the content of the notification,
should we allow enterprises the flexibility to customize notification
as they see fit? Is there an alternative approach that would be
superior to the one proposed in terms of costs and benefits?
23. Notification Timing and Destination Points. Kari's Law is
silent on when the notification must be provided. We believe that
timely notification is essential, because delayed notification could
impede coordination between enterprise management or staff and first
responders seeking access to the enterprise premises. Therefore, we
propose to require that MLTS covered by Kari's Law be configured so
that notification is contemporaneous with the 911 call and does not
delay the placement of the call to 911. We seek comment on this
proposal, as well as any alternatives.
24. We also seek comment on whether there should be any
requirements relating to the location, configuration, or staffing of
notification destination points. Kari's Law provides that the
notification may be provided either to a ``central location at the
facility where the system is installed'' or to ``another person or
organization regardless of location.'' We believe this language
indicates Congress's recognition that in the enterprise settings in
which MLTS are typically used, providing someone other than the PSAP
with notice of the call can be critical to helping first responders
gain timely access. At the same time, the language indicates that
Congress sought to provide MLTS installers, managers, and operators
with broad flexibility in selecting destination points to achieve this
goal. For example, the notification could be directed to an on-site
security desk that controls access to the premises, to an enterprise
employee who may or may not be located at the facility where the MLTS
is installed, or to a third party that provides security or safety
services from an off-site location. MLTS notification could also be
configured to combine these approaches, e.g., by having notifications
during business hours go to a central on-site location and off-hours
notifications go to an off-site person or organization. We seek comment
on additional options for implementing such requirements.
25. We seek comment on whether the Commission should specify any
criteria for destination points to ensure that notifications, whether
on-site or off-site, are likely to be received by someone able to take
appropriate action to facilitate or assist the 911 response. Where on-
site notification to a ``central location'' is provided, should we
specify that the destination point must be a location that is normally
staffed or, alternatively, a location where on-site staff are likely to
hear or see the notification? This would afford the flexibility to
direct the on-site notification to a security guard or facilities
manager, to personnel who are otherwise employed and can support
monitoring notifications as a part of existing duties, or to an on-site
location where staff are normally present. We seek comment on this
approach. Where notification is provided to a ``person or organization
regardless of location,'' should we require that the person or
organization be one that is authorized to provide first responders with
access to the location from which the MLTS 911 call originated? This
would allow notification to be directed to any offsite location, as the
statute clearly allows, while furthering the statute's objective of
facilitating access to first responders answering a 911 call. We seek
comment on this approach.
26. We also seek comment on the cost and expected benefit of the
above-mentioned options for implementing the notification requirement
of Kari's Law. We note that while some state MLTS statutes include
notification requirements, these statutes either expressly provide that
the enterprise does not have to make a person available to receive a
notification, or they are silent on whether the destination point must
be staffed. We do not believe Congress intended to impose staffing or
monitoring requirements that would impose unreasonable costs or limit
the flexibility of MLTS installers, managers, and operators to develop
efficient and cost-effective notification solutions that are
appropriate for the technology they use, such as visual alerts on
monitors, audible alarms, text messages, and/or email. Rather than
requiring staffing or monitoring, we believe that allowing
notifications to be directed to the points where they are likely to be
seen or heard by existing staff achieves these goals at a negligible
cost above what an MLTS manager would already spend when purchasing an
MLTS. We seek comment on this approach. What means are available to
reasonably ensure that notification will be timely received by a person
with authority to act on it? For example, could alarm companies,
security firms, or similar entities create efficiencies by providing
911 notification monitoring for multiple customers? Are there other
means to reduce these costs?
27. We also seek comment on how the statute's notification
requirements should be applied to small enterprises. Large enterprises
such as hotels, hospitals, and schools frequently have on-site
personnel that control access to the premises, and notification of 911
calls to such personnel can improve outcomes by enabling them to assist
first responders in accessing the premises and reaching the caller's
location. Do the benefits and costs of notification apply differently
to small businesses? Small businesses are less likely to have personnel
controlling access, and first responders may not need the same level of
assistance to reach a 911 caller. At the same time, small enterprises
using MLTS may find benefits to notification in addition to access and
support. For example, on-site personnel can intervene when 911 is
dialed in error, enabling them to contact the PSAP and avoid sending
emergency responders to a location that does not require a response.
3. Definitions.
28. Multi-Line Telephone System. Kari's Law and RAY BAUM'S Act
define the term ``multi-line telephone system'' as ``a system comprised
of common control units, telephone sets, control hardware and software
and adjunct systems, including network and premises based systems, such
as Centrex and VoIP, as well as PBX, Hybrid, and Key Telephone Systems
(as classified by the Commission under part 68 of title 47, Code of
Federal Regulations), and includes systems owned or leased by
governmental agencies and non-profit entities, as well as for profit
businesses.''
29. We propose to interpret this definition to include the full
range of networked communications systems that serve enterprises,
including circuit-switched and IP-based enterprise systems, as well as
cloud-based IP technology and over-the-top applications. We further
propose to interpret this definition to include enterprise-based
systems that allow outbound calls to 911 without providing a way for
the PSAP to place a return call. We believe requiring direct dialing
for any MLTS that allows the user to call 911, regardless of whether
the system also allows the PSAP to make a return call, advances the
purpose of the statute. In addition, there is nothing in the language
of the definition of MLTS
[[Page 54184]]
from the Middle Class Tax Relief and Job Creation Act of 2012 that
excludes systems allowing only outbound calls to 911.
30. We seek comment on our proposed definition of the term MLTS.
Are there other ways in which the Commission should clarify the meaning
of MLTS, and if so, what are they? Should we define MLTS to include
systems that allow outbound calls to 911 but not inbound calls, as
proposed above? How common are such systems? Are 911 calls from such
systems identified as outbound-only at the PSAP? Are outbound-only
systems ever deployed together with systems that allow two-way calling?
If so, how do enterprise managers address the potential for end user
confusion over the ability to receive a return call from the PSAP over
a particular system?
31. Pre-configured and configured. Next, we propose to define the
statutory terms ``pre-configured'' and ``configured'' as applied to
MLTS direct dialing. First, we propose to define ``pre-configured'' to
mean that the MLTS comes equipped with a default configuration or
setting that enables users to dial 911 directly as required under the
statute and rules, so long as the system is installed and operated
properly. This does not preclude the inclusion of additional dialing
patterns to reach 911. However, if the system is configured with these
additional dialing patterns, they must be in addition to the default
direct dialing pattern. We believe this means that an MLTS may support
additional dialing patterns, but manufacturers (and importers, sellers,
or lessors) must ensure that the default, ``out-of-the-box''
configuration allows users to reach 911 directly.
32. Second, we propose to define ``configured'' to refer to the
settings or configurations implemented for a particular MLTS
installation. To meet this definition, the MLTS must be fully capable
when installed of dialing 911 directly and providing notification as
required under the statute and rules. As with ``pre-configured,'' an
MLTS may be configured to support additional dialing patterns, but
manufacturers (and importers, sellers, or lessors) must ensure that
they are in addition to the default direct dialing pattern. We seek
comment on this proposed definition. Cisco noted in its comments on the
ECS NOI that ``[c]onfiguring [MLTS] is an entirely different line of
business than manufacturing [MLTS].'' Under our proposed definitions,
is the difference between ``pre-configuring'' an MLTS and
``configuring'' an MLTS sufficiently clear? If not, how can we clarify
the differences?
33. Improvement to the hardware or software of the system. Kari's
Law provides that the notification requirements of the statute apply
only if the system can be configured to provide notification ``without
an improvement to the hardware or software of the system.'' We propose
to define the term ``improvement to the hardware or software of the
system'' to include upgrades to the core systems of an MLTS, as well as
substantial upgrades to the software and any software upgrades
requiring a significant purchase. We seek comment on this proposed
definition. Are there types of routine hardware or software changes
that should be included in or excluded from the definition? For
example, should we clarify that (1) improvements to the hardware of the
system do not include the provision of additional extensions or lines,
and (2) improvements to the software of the system do not include minor
software upgrades that are easily achieved or made to improve the
security of the system? What changes should we consider minor? Should
upgrades requiring a significant purchase be determined based on total
cost alone, or should we interpret significant to be a relative
determination based on the size of the entity making the purchase?
34. A person engaged in the business of manufacturing, importing,
selling, or leasing an MLTS. Kari's Law prohibits the manufacture or
importation for use in the United States, or sale or lease or offer to
sell or lease in the United States, of non-compliant MLTS. We
tentatively conclude that the meaning of the term ``person engaged in
the business of manufacturing, importing, selling, or leasing an MLTS''
is self-evident, and we do not propose to modify or add to this
definition in our rules. We nonetheless seek comment on whether any
additional clarification of this term is necessary for implementation
or enforcement of Kari's Law. For instance, should we clarify that a
person engaged in the business of manufacturing, importing, selling, or
leasing MLTS includes a distributor or reseller of MLTS?
35. A person engaged in the business of installing an MLTS. We
propose to define a person engaged in the business of installing an
MLTS as a person who installs or configures the MLTS or performs other
tasks involved in getting the system ready to operate. These tasks may
include, but are not limited to, establishing the dialing pattern for
emergency calls, determining how calls will route to the Public
Switched Telephone Network (PSTN), and determining where the MLTS will
interface with the PSTN. We note that these tasks are performed when
the system is initially installed, but they may also be performed on a
more or less regular basis by the MLTS operator as the communications
needs of the enterprise change. The MLTS installer may be the MLTS
manager or a third party acting on behalf of the manager. We seek
comment on our proposed definition.
36. A person engaged in the business of managing an MLTS. We
propose to define a person engaged in the business of managing an MLTS
as the entity that is responsible for controlling and overseeing
implementation of the MLTS after installation. These responsibilities
include determining how lines should be distributed (including the
adding or moving of lines), assigning and reassigning telephone
numbers, and ongoing network configuration. We also propose to
interpret the definition to mean that a user of MLTS services that does
not own or lease the MLTS or exercise any control over it would not be
deemed to be engaged in the business of managing the MLTS. Thus, an
enterprise that contracts with a third party to provide a total
solution for MLTS, including acquiring the MLTS equipment, configuring
the system, completing calls, and providing services such as
maintenance and end user support, would not be deemed to be engaged in
the business of managing the MLTS unless it exercised actual control
over the system. We seek comment on this proposed definition.
37. A person engaged in the business of operating an MLTS. We
propose to define a person engaged in the business of operating an MLTS
as an entity responsible for the day-to-day operations of the MLTS. As
with our proposed definition of MLTS manager above, we also propose to
interpret this term to mean that an MLTS user that does not own, lease,
or exercise control over the MLTS would not be deemed to be engaged in
the business of operating the MLTS. We seek comment on our proposed
definition.
38. We also seek comment on whether there are circumstances in
which our proposed definitions of MLTS ``manager'' or ``operator''
should extend to enterprise owners. Commenters on the ECS NOI
emphasized that some enterprise owners purchase, operate, and maintain
their own on-premises telephone systems with PBX equipment, while
others enter contractual arrangements with third-party providers of
network and hosted services. AT&T noted that the decision whether to
purchase and implement an MLTS solution lies with the enterprise owner
[[Page 54185]]
and that the owner ``must have a role to play in ensuring that 911
capabilities are functioning as intended.'' As noted above, we do not
believe that Kari's Law was intended to extend liability to enterprise
owners that purchase MLTS services but do not exercise control over the
manner in which such services are configured or provided. Nevertheless,
there may be instances where enterprise owners purchase, operate, and
maintain their own MLTS systems, or they may exercise active control
over the configuration and provision of MLTS by third parties. In such
instances, should enterprise owners be deemed to be MLTS managers or
operators? What indicia of active control should be considered in
making this determination?
4. Other Issues
39. Compliance date. Consistent with the provisions of Kari's Law,
we propose that the compliance date for our implementing regulations
will be two years from the date of the law's enactment, i.e., on
February 16, 2020. Thus, the proposed direct dialing and notification
requirements would apply to MLTS that are manufactured, imported,
offered for first sale or lease, first sold or leased, or installed
after February 16, 2020. We seek comment on this proposed compliance
date for implementing regulations, as well as on alternatives. Those
offering alternatives should explain how any proposed date that differs
from the one that we propose would be consistent with the statutory
language.
40. Transitional Issues. Kari's Law applies only with respect to
MLTS that are manufactured, imported, offered for first sale or lease,
first sold or leased, or installed after February 16, 2020.
Accordingly, MLTS manufactured, imported, offered for first sale or
lease, first sold or leased, or installed on or before that date are
grandfathered from compliance with the statute. To what extent is
direct dialing of 911 already available and in use in MLTS? To the
extent that MLTS in use do not support direct dialing, what options are
currently available to installers, managers, and operators that may be
planning to upgrade or replace their systems? Are there any barriers
facing (1) MLTS manufacturers, importers, sellers, and lessors, and (2)
MLTS installers, managers, and operators, to meet the statute's direct
dialing requirements by the compliance date? If so, what are those
barriers and what are the potential costs of overcoming them?
41. We also seek comment on whether we should adopt transitional
rules to inform consumers of the 911 capabilities of grandfathered
MLTS. For example, the state version of Kari's Law enacted in Texas
requires enterprises to place a sticker adjacent to or on non-compliant
MLTS devices that provides instruction in English and Spanish on how to
call 911. Similarly, the Commission's interconnected VoIP E911 rules
require service providers to distribute stickers or labels warning
subscribers that E911 service may be limited. We seek comment on
whether to require MLTS installers, operators, and managers to notify
callers how to dial 911 from grandfathered systems, as well as options
for doing so and their related costs. In addition, we seek comment on
potential sources of statutory authority for such requirements.
42. Enforcement. Under Kari's Law, the Commission is empowered to
enforce the statute under Title V of the Communications Act, ``except
that section 501 applies only to the extent that such section provides
for the punishment of a fine.'' We seek comment on how the Commission
should enforce and provide oversight of the requirements of Kari's Law.
As a general matter, we envision following the framework set forth by
the statute. For example, a manufacturer could face enforcement action
for offering to sell an MLTS that is not pre-configured to support
direct 911 dialing, and an MLTS operator could face enforcement action
for operating the system when it was not configured so that users could
dial 911 directly. We seek comment on the potential use of this
enforcement approach for Kari's Law.
43. Additionally, we seek comment on who, or which entities, should
bear responsibility for violations of the proposed rules. Verizon
comments that there can be great variation in the business
relationships between MLTS installers, operators, and managers: ``In
some cases the service provider and the system operator or vendor will
each have a direct relationship with an enterprise customer. In other
cases the service provider may be a subcontractor to the system
operator, and only provide certain components of the service (such as
MPLS circuits for transport or other trunking services), with limited
or no say in the design or configuration of the product. Or the reverse
may be true--i.e., the enterprise system operator is a subcontractor of
the service provider, and the service provider maintains the direct
contractual relationship with the customer.''
44. We propose to apply a presumption that the MLTS manager bears
ultimate responsibility for compliance with our proposed rules
implementing Kari's Law. For example, if an MLTS fails to comply with
our proposed rules, the MLTS manager would be presumed to be
responsible for that failure, at least in part, unless the manager can
rebut that presumption by demonstrating compliance with its obligations
under the statute and our proposed rules. We seek comment on this
proposal. How should we apportion liability in situations where
multiple parties may be responsible for compliance with the statute and
our proposed rules? For example, in a case where the MLTS manager
contracts with a third party to install and operate an MLTS, but the
third party fails to comply with the Commission's rules, should the
MLTS manager and third-party contractor be held jointly or individually
responsible? What evidence or factors should we look to in apportioning
or rebutting a presumption of liability?
45. Complaint Mechanisms and Other Issues. We envision relying on
existing Commission complaint mechanisms to facilitate the filing of
complaints for potential violations of Kari's Law. For example, PSAPs
and the public could report problems via the Public Safety and Homeland
Security Bureau's Public Safety Support Center or the Commission's
Consumer Complaint Center. We seek comment on this.
46. We also seek comment on whether to modify our equipment
authorization rules as they apply to MLTS equipment manufactured after
February 16, 2020. Should MLTS applications for equipment authorization
under Parts 2, 15, or 68 constitute a representation that such
equipment complies with MLTS 911 requirements?
47. Finally, we ask commenters to identify voluntary best practices
that can improve the effectiveness of direct dialing and notification
for MLTS. For example, the Michigan State 911 Committee has developed
guidelines that call for MLTS operators to work directly with their
local public safety entities to ensure compliance. The Michigan State
911 Committee also ``strongly recommend[s] that every MLTS operator
work with their local 911 system manager/director to test the ability
to dial 911 from the station lines associated with MLTS systems any
time an MLTS has been installed or upgraded.'' We seek comment on this
and other recommended or potential best practices that would help
enterprises ensure the effectiveness of direct dialing and
notification. Are there best practices for the training of on-site
emergency personnel and others responsible for the implementation of
direct dialing and notification?
[[Page 54186]]
Similarly, are there best practices for the operation of an on-site or
offsite notification point of contact?
5. Comparison of Benefits and Costs
48. According to a Congressional Budget Office analysis, most MLTS
systems already are configured to meet the direct dialing and
notification requirements of Kari's Law. In evaluating the Senate and
House versions of Kari's Law, Cisco stated that it was not aware of any
technological barriers to the implementation of Kari's Law as applied
to MLTS. In addition, eight states and some local governments already
have laws that require direct dialing for 911 from MLTS. For these
state and local jurisdictions, our proposed rules would generally not
affect the status quo and so would likely have little to no impact from
a cost perspective. Moreover, the existence of state-level requirements
has driven the manufacture of MLTS equipment that supports 911 direct
dialing, much of which may have been marketed and sold in jurisdictions
that do not have state or local requirements. We seek comment on the
number of MLTS systems currently deployed that do not allow direct
dialing of 911 and/or cannot be configured to provide notification of
911 calls to an MLTS manager.
49. Consistent with Kari's Law, our proposed rules would apply only
with respect to MLTS that are manufactured, imported, offered for first
sale or lease, first sold or leased, or installed after February 16,
2020, which means that there should be no immediate costs or stranded
investment with respect to existing MLTS or systems that first come
into service on or before February 16, 2020. As noted above, many
existing, installed MLTS support direct dialing to 911 and
notification. Therefore, we tentatively conclude that there will be no
immediate costs or benefits associated with meeting the requirements of
our rules. For systems coming into service after February 16, 2020, we
seek comment on the costs and benefits of satisfying our proposed
rules. Are there alternative methods of meeting the requirements of
Kari's Law that would reduce costs and/or increase benefits? Will any
barriers exist for those wishing to replace their MLTS after this date
that would be costly to overcome? We also seek comment on the expected
lifespan of existing MLTS that are not currently able to meet the
requirements of our proposed rules. What is the prevalence of such
systems today, and what will the expected prevalence of such systems be
in 2020? We seek comment on the cost of upgrading to an MLTS that
supports the requirements of our proposed rules. Because most of the
currently deployed MLTS are capable of being configured to meet the
requirements of our rules today, without improvement to the hardware or
software of the system, we tentatively conclude that our rules will
impose no incremental costs to those who replace their MLTS as they
come to the end of their useful life. We seek comment on this tentative
conclusion.
50. Specifically as to notification, we tentatively conclude that
the costs of implementing our proposed requirements will not exceed the
value of their benefits. As discussed above, notification can assist
MLTS managers in large enterprises in dealing with first responders.
Prepared with information about a 911 call, a manager will be able to
quickly direct and assist first responders at large enterprises, rather
than spending time trying to gather such information. Notification will
also benefit the 911 caller and first responders by allowing quicker
response time. This analysis is supported by RedSky's ECS NOI comments,
which state that, in its experience, ECS customers that receive these
types of notifications ``can save 2-3 minutes in emergency response
time when a 911 call is made.'' We also anticipate that notification
will provide MLTS managers with opportunities to efficiently notify the
PSAP of accidental 911 calls, preserving first responder resources and
allowing the MLTS manager to avoid state or municipal fines or
penalties for accidental 911 calls. We observe that some states already
have laws and regulations that require on-site notification for 911
calls from MLTS. Similar to our proposed rules, the largest of these
states defines notification to include the fact that a 911 call has
been made, the caller's telephone number, and the caller's location.
For these state and local jurisdictions, we anticipate that our
proposed rules would have minimal impact. Moreover, the existence of
state-level requirements has likely driven the manufacture of MLTS
equipment that supports notification for 911 calls, much of which may
have been marketed and sold in jurisdictions that do not have state or
local requirements or to small businesses that are exempted from state
or local requirements. We seek comment on our tentative conclusion, as
well as particular costs involved in imposing the notification
requirement and alternative methods consistent with Kari's Law that may
reduce costs and/or improve benefits. We seek comment on the costs and
benefits associated with our proposed definitions. We also seek comment
on the benefits and costs associated with any additional notification
requirements the Commission might adopt, such as requiring
grandfathered MLTS to inform consumers of the 911 capabilities of those
systems.
B. Dispatchable Location for MLTS and Other 911-Capable Communications
Services
51. RAY BAUM'S Act directs us to consider rules requiring the
conveyance of dispatchable location with 911 calls ``regardless of the
technological platform used.'' Based on this directive, we consider
whether to adopt dispatchable location requirements for MLTS and other
911-capable services. In addition to MLTS, we examine four types of
communications services that are currently required under Commission
rules to provide 911 service to their customers: (1) Fixed telephony,
(2) mobile telecommunications, (3) interconnected VoIP service, and (4)
internet-based Telecommunications Relay Services (TRS). In addition, we
examine whether we should adopt dispatchable location rules for other
911-capable services that are not currently subject to 911 rules.
1. MLTS
52. Applicability and Obligations. When a 911 call is placed in an
MLTS environment, a location may be included in the information sent to
the PSAP, but that location may not be the location of the caller. On a
large campus or in a hotel, for example, a 911 call may convey the
location of the main entrance or administrative office. Such location
imprecision can lead to delays in locating the person making the 911
call and result in further injury or loss of life.
53. By directing the Commission ``to consider adopting rules to
ensure that the dispatchable location is conveyed with a 9-1-1 call . .
. including with calls from multi-line telephone systems,'' Congress in
RAY BAUM'S Act signaled its intent that the Commission focus on
ensuring highly precise location information whenever feasible.
Moreover, the enactment of RAY BAUM'S Act only weeks after Kari's Law
indicates that Congress recognized the importance of providing accurate
location information to PSAPs in connection with MLTS 911 calls.
Dispatchable location is defined in the statute as ``the street address
of the calling party, and additional information such as room number,
floor number, or similar information necessary to adequately identify
the
[[Page 54187]]
location of the calling party.'' We therefore initiate this portion of
our proceeding with Congress's stated goal in mind.
54. We propose to proscribe the manufacture, import, sale, or
leasing of MLTS in the United States unless the system is pre-
configured such that, when properly installed, the dispatchable
location of the caller will be conveyed to the PSAP with 911 calls.
Further, we propose to proscribe the installation, management, or
operation of MLTS in the United States unless the system is configured
such that the dispatchable location of the caller will be conveyed to
the PSAP with 911 calls. And we propose to apply these proscriptions to
the same entities subject to Kari's Law. We seek comment on these
proposals.
55. In its comments to the ECS NOI, NCTA observed that ``ECS
involves not only the service provider and end user, but also
manufacturers and ECS programmers. Coordination and assignment of
responsibilities among these ECS functions must be done seamlessly to
ensure that 911 services function properly.'' For this reason, our
proposals for dispatchable location parallel the direct dialing and
notification requirements of Kari's Law in that they would apply to the
participants in the MLTS marketplace we believe are best positioned to
ensure that all installed MLTS are capable of conveying an accurate
location to the appropriate PSAP. We seek comment on our approach to
addressing the division of responsibilities when deploying and
operating MLTS. Should more granular requirements be placed on any of
the MLTS market participants to which our proposed rules would apply?
Are new rules necessary to ensure that communication service providers
(such as fixed telephony, mobile carriers, and interconnected VoIP
service providers) that complete 911 calls originating from MLTS convey
dispatchable location, or are existing 911 rules sufficient? Similarly,
are rules needed to ensure that manufacturers and importers of MLTS
incorporate capabilities in their products to enable them to convey
dispatchable location information? Do standards exist for conveying
dispatchable location information from MLTS? If so, should MLTS be
required to conform to these standards? How should conformance of MLTS
to such rules and standards be demonstrated?
56. Defining Dispatchable Location. RAY BAUM'S Act defines
``dispatchable location'' as ``the street address of the calling party,
and additional information such as room number, floor number, or
similar information necessary to adequately identify the location of
the calling party.'' We note that the statutory definition of
dispatchable location is nearly identical to the dispatchable location
definition in the Commission's mobile E911 location accuracy rules.
Given the substantial similarity between the two definitions, we
propose to construe them as functionally identical, aside from the
specification of the technological platform to which each definition
applies. We seek comment on this proposal.
57. The mobile E911 definition of ``dispatchable location'' further
requires that, when delivering dispatchable location, ``[t]he street
address of the calling party must be validated and, to the extent
possible, corroborated against other location information prior to
delivery of dispatchable location information by the CMRS provider to
the PSAP.'' We seek comment on whether we should require similar
validation for dispatchable location information associated with MLTS
911 calls. Is there any reason why street address validation would be
more difficult or costly for MLTS than for mobile E911?
58. We also seek comment on whether our rules should further define
``additional information'' that may be necessary in an MLTS context to
``adequately identify the location of the calling party.'' In the
Indoor Location Fourth Report and Order, the Commission found that the
definition of dispatchable location applicable to mobile carriers
``strikes the appropriate balance between specificity and
flexibility,'' and therefore does not necessitate further specification
of types of location information to be conveyed. We seek comment on
applying the same approach for MLTS dispatchable location. We believe
MLTS installers, managers, and operators will be able to identify
situations in which street address is sufficient for first responders
to quickly and accurately find the calling party. We also expect that
street address would serve as a dispatchable location for the smallest
enterprises. Nonetheless, should we specify the situations in which
street address is not sufficient, and more granular location
information is needed? For example, NENA's model federal MLTS
legislation generally requires business MLTS to provide location
information for each floor of each property served, as well as each
7,000 square feet of workspace beyond the first. Several commenters on
the ECS NOI supported this approach to providing dispatchable location
for MLTS. If commenters believe we should specify when more granular
information is needed, what should be our criteria for identifying
those situations? When more granular information is needed, what
elements of location, in addition to room, floor, suite, or apartment
number, could be used to locate a 911 caller using MLTS?
59. We agree with TIA that we ``should be careful [not] to impose
burdensome regulations that would eliminate the robust choices enjoyed
by enterprises of all types in today's marketplace.'' Accordingly, we
do not propose to require implementation of specific location
technologies or solutions but rather seek comment on functional
requirements that would give participants in the MLTS marketplace
flexibility to develop dispatchable location solutions. We believe that
this approach will allow the entities affected by these proposed rules
to implement them in a manner that is appropriate in terms of cost,
enterprise size, site layout, and technical sophistication. We note
that several states already place requirements on MLTS providers to
obtain and convey location information that is more detailed than
street address alone.
60. Feasibility of Conveying Dispatchable Location from MLTS. We
tentatively conclude that it is feasible for 911 calls that originate
from MLTS to convey dispatchable location to the appropriate PSAP, as
several commenters to the ECS NOI indicate that they are already
offering methods for dynamically determining and conveying an MLTS end
user's location. We seek comment on this tentative conclusion. We
observe that potential dispatchable location solutions for MLTS include
solutions that require the customer to identify their own location and
solutions that calculate a location by leveraging data available from
the 911 caller's device and the network.
61. We also seek comment on whether additional dispatchable
location solutions can be implemented for MLTS. Are there technical
elements necessary for supporting dispatchable location that are shared
by these solutions? Do technical elements differ across dispatchable
location solutions, and if so, how? Are the required technical elements
consistent across types of MLTS solutions, including on-premises
solutions, hosted cloud solutions, and over-the-top application-based
solutions? Are the required technical elements shared by legacy MLTS
and IP-based MLTS, and if not, should differing requirements be placed
on them? In its comments on the ECS NOI, West Safety observed that
``[l]egacy-based solutions may not be able to support E9-1-1 routing
for users
[[Page 54188]]
accessing the ECS remotely.'' We seek comment on that observation.
Should we place differing requirements on premises-based, cloud-based,
and over-the-top application-based solutions? Should we require MLTS to
convey particular types of location information, such as room number or
floor number, when it is available? If an MLTS handles calls initiated
by remote users, e.g., off-site workers, should we require it to convey
the remote user's location information?
62. We seek comment on whether the technical elements necessary for
conveying dispatchable location with a 911 call are currently available
in MLTS that are deployed today. We observe that several MLTS offered
today provide 911 location solutions that are capable of conveying
dispatchable location to PSAPs. Can currently-deployed MLTS that do not
support provision of dispatchable location be upgraded to do so? If
they can be upgraded, what would those upgrades entail, and what would
they cost? For support of dispatchable location, what technical
elements must be present in MLTS-related hardware, such as handsets,
the device on which a softphone or voice application is installed, or
other elements of the system? Which elements can be supported with
updates to software or applications? If some MLTS in use today are not
capable of supporting dispatchable location, we seek comment on whether
those systems should be exempted from a dispatchable location
requirement. For example, should we adopt compliance date provisions
that track the provisions of Kari's Law as discussed above? Should we
adopt disclosure requirements for grandfathered MLTS that are not
subject to the rules? What should such disclosure rules require?
63. We also seek comment on the steps that an MLTS manager or
operator must take, if any, to ensure that dispatchable location is
conveyed to the PSAP. What is the most effective, least burdensome
means to ensure that this happens? For example, some commenters on the
ECS NOI suggest that managers of cloud-based MLTS are in a unique
position to administer, maintain, and update location information for
the enterprise. Should we adopt rules requiring MLTS managers to
provision location information for the enterprise to the MLTS operator?
To what extent does our legal authority under these new statutes or our
existing authority extend to such entities? What information should be
initially provisioned and how frequently should we require that
information to be updated? What are the costs associated with such
provisioning and updating? For situations in which MLTS operators are
capable of calculating a dispatchable location by inputting one or more
sources of device-generated location data into a location information
server, what requirements, if any, should we place on (1) MLTS
manufacturers and importers; (2) sellers and lessors; (3) MLTS
installers, managers, and operators; and (4) communications service
providers to ensure that this information or the resulting dispatchable
location information is conveyed to the PSAP?
64. Although RAY BAUM'S Act directs the Commission to consider
rules to ensure that dispatchable location is conveyed with 911 calls,
there may be instances where location information that does not meet
the definition of dispatchable location could still be useful to PSAPs
and first responders, either as supplemental information to validate
the dispatchable location or as an alternative in instances where
dispatchable location information is not available. We therefore
believe that our rules and policies should not preclude--and in fact
should allow and encourage--potential alternatives to dispatchable
location. We seek comment on this view. Could other types of location
information (for example, x/y/z coordinates) be conveyed with a 911
call originating from MLTS? If we adopt dispatchable location
requirements, should we allow provision of x/y/z/coordinates or other
approaches to conveying location information to be alternatives to
dispatchable location? We also seek comment on the usefulness of x/y/z
coordinates to PSAPs and first responders for responding to MLTS 911
calls. Are they currently equipped to receive and use such information?
65. We also seek comment on whether there are other sources of
location information, such as the National Emergency Address Database
(NEAD), the location database being developed by the major mobile
carriers to provide dispatchable location for indoor mobile 911 calls,
that could potentially assist MLTS managers and operators in
determining the dispatchable location of MLTS end users. Could MLTS
managers and operators leverage these other sources of location
information? What actions, if any, should we take to facilitate use of
the NEAD and other location information sources for MLTS managers and
operators? With respect to the NEAD in particular, are there
obligations that should be placed on entities that seek to access the
NEAD? As it has been contemplated that dispatchable location
information from third-party sources will be integrated into the NEAD,
we seek comment on whether MLTS managers and operators are positioned
to contribute dispatchable location reference points to the database.
If they are capable of making such contributions, should they be
required to do so as a condition of leveraging the NEAD? Similarly,
should they required to contribute to the operating costs of the NEAD
as a condition of leveraging it?
2. Fixed Telephony Providers
66. Section 64.3001 of the Commission's rules requires all
telecommunications carriers, including fixed telephony providers, to
transmit all 911 calls to a PSAP, to a designated statewide default
answering point, or to an appropriate local emergency authority.
Section 64.3001 does not require telecommunications carriers to convey
the location of the caller with the call, and there is no Commission
911 location rule applicable to fixed telephony carriers. However,
pursuant to applicable state law, fixed telephony carriers typically
provide validated street address information in conjunction with their
customers' 911 calls.
67. We propose to amend our rules to require providers of fixed
telephony services to provide dispatchable location with 911 calls.
Fixed telephony carriers already provide validated street address
information, which is likely sufficient in most cases, such as single
family dwellings, to satisfy a dispatchable location requirement.
However, dispatchable location as defined in RAY BAUM'S Act includes
additional elements such as floor level and room number that may be
necessary to locate the caller. We also believe that including fixed
telephony carriers in our consideration of dispatchable location
requirements at the federal level is consistent with the ``all
platforms'' approach sought by Congress in the RAY BAUM'S Act, while
omitting them could create the risk of gaps in the availability of
location information. We seek comment on this approach.
68. We seek comment on whether it is technically feasible for fixed
telephony carriers to convey dispatchable location with a 911 call. In
many instances, as noted above, fixed telephony 911 calls from single
family homes, feasibility appears to be established because fixed
telephony carriers already provide validated street address information
to the PSAP and first responders do not typically require additional
room or floor level information. We seek comment on the extent to which
fixed telephony carriers
[[Page 54189]]
also provide other information, such as floor level and room number,
for 911 calls from multi-story buildings and similar environments. How
frequently do fixed telephony 911 calls convey only street addresses
where additional information would be needed to locate the caller? What
obstacles exist, if any, to fixed telephony carriers conveying
dispatchable location to PSAPs? If obstacles exist, how could they be
overcome, and at what cost? Could the NEAD, similar databases, or other
sources of location information assist fixed telephony carriers in
providing dispatchable location with 911 calls? What obligations, if
any, should be placed on fixed telephony carriers that seek to access
the NEAD? If so, what steps could the Commission take, if any, to
facilitate the use of such databases by fixed telephony providers? Are
there any alternatives to dispatchable location that fixed telephony
carriers could use to provide in-building location information beyond
street addresses, e.g., coordinate-based information?
3. Mobile Carriers
69. The E911 location accuracy rules applicable to mobile 911 voice
service, set forth in Section 20.18 of our rules, provide that mobile
carriers can meet our accuracy requirements by either conveying
dispatchable location or coordinate-based location information. Because
we have already incorporated dispatchable location into our E911 rules
for mobile voice service, and mobile carriers are developing
dispatchable location solutions based on those rules, we do not
consider further changes in this proceeding to existing dispatchable
location requirements. We note that this is consistent with RAY BAUM'S
Act, which states that the Commission is not required to ``reconsider
any information or conclusion'' made in proceedings prior to the
statute's enactment.
70. With respect to text-to-911, our rules require mobile carriers
and other covered text providers to obtain location information
sufficient to route text messages to the appropriate PSAP, but text
providers are not required to convey location information to the PSAP
for the purpose of locating the person sending the text. The Commission
has previously asserted that this approach is only an interim solution,
and that it intends to require the delivery of enhanced location
information with texts to 911 as soon as it is technically feasible to
do so.
71. The Commission has previously proposed a requirement that, no
later than two years after the effective date of the adoption of final
rules on enhanced location for 911 texts, covered text providers must
deliver enhanced location information (consisting of the best available
location that covered text providers could obtain from any available
location technology or combination of technologies, including device-
based location) with texts to 911. We seek to refresh the record on how
enhanced location information can be generated and delivered with text
messages to 911. Is it technologically feasible today to convey a
dispatchable location, or other types of enhanced location information,
to the appropriate PSAP when a text message is sent to 911? If not,
what is the likely timeframe for covered text providers to achieve such
capability? Is there completed, ongoing, or anticipated future
standards work that would facilitate delivery of dispatchable location
information by covered text providers? If it is technologically
feasible, should we apply dispatchable location requirements to text-
to-911 consistent with requirements applied to other platforms? What
would be the cost of such a requirement? To the extent that some text-
to-911 dispatchable location requirement would be feasible but should
differ from that applicable to other platforms, commenters should
explain the basis for any distinctions, what alternative(s) could work
for text-to-911 dispatchable location, and why.
4. Interconnected VoIP Providers
72. The Commission's rules require interconnected VoIP providers to
transmit Automatic Number Identification (ANI) and the caller's
Registered Location with each 911 call. Interconnected VoIP providers
must obtain a Registered Location, which is the most recent information
that identifies the physical location of an end user, from each
customer prior to the initiation of service. In addition, providers
must enable end users to update their Registered Location at will and
in a timely manner. The Registered Location of such calls must be made
available to the appropriate PSAP, designated statewide default
answering point, or appropriate local emergency authority from or
through an appropriate automatic location information database. The
Commission has also previously sought comment on the possibility of
interconnected VoIP services providing real-time automatic location
information to support 911 calls from consumers that use interconnected
VoIP services from mobile or portable devices, such as smartphones or
laptops.
73. The Commission adopted the Registered Location requirement in
2005 to support the provision of location information from 911 callers
that typically use interconnected VoIP service from a single fixed
location, such as a residence (fixed VoIP), or that move from one fixed
location to another (nomadic VoIP). Although RAY BAUM'S Act provides
that the Commission is not required to reconsider E911 location rules
adopted in prior proceedings, as discussed below, we believe that it is
appropriate to consider revising our E911 rules for interconnected VoIP
to require the provision of dispatchable location.
74. Fixed VoIP. With respect to fixed VoIP, we believe it is
feasible for 911 calls that originate from interconnected VoIP services
to convey dispatchable location to the PSAP, in that the current
Registered Location obligations are sufficient for this purpose. In
this respect, we note that the Registered Location information that is
already conveyed with such calls today typically includes street
address information, which should be sufficient for dispatchable
location in the case of single family homes and small buildings where
the PSAP and first responders do not require additional room or floor
level information. In addition, interconnected VoIP providers can also
enable customers in multi-story buildings and similar environments to
provide room or floor level information as part of the Registered
Location when needed. We seek comment on this proposal.
75. Nomadic VoIP. With respect to nomadic VoIP, we seek comment on
whether Registered Location satisfies a dispatchable location
requirement. In particular, we note that a Registered Location that was
recorded when service was initiated is less likely to accurately
identify the real-time location of an end user that moves frequently
between home, work, and other locations. Is Registered Location a
sufficient proxy for dispatchable location in a nomadic environment,
where the relevant device is able to prompt the user for an updated
location when it has been moved? We seek comment on what technical
elements would be required in the end user's device and/or the service
provider's network to support the provision of real-time dispatchable
location as proposed, and the degree to which those technical elements
are already in place. For example, as we have noted in the discussion
of MLTS location in Section B1 above, there appear to be IP-based
solutions currently available for providing MLTS dispatchable location
dynamically in buildings, campuses, and similar environments. We seek
[[Page 54190]]
comment on whether these solutions could also be leveraged by
interconnected VoIP providers when their customers call 911 from such
environments.
76. We note that in the Registered Location context the burden is
on the end user to update the Registered Location whenever the end user
moves from one location to another. We seek comment on whether nomadic
interconnected VoIP providers have, or can develop in the near term,
the means to provide automatic dispatchable location with 911 calls in
lieu of conveying the customer's Registered Location. We believe that
automatic provision of location is preferable because end users under
stress in emergency situations may have difficulty providing manual
updates and the updating process may delay the 911 call or subsequent
location and dispatch. Therefore, we seek comment on the degree to
which mechanisms exist for interconnected VoIP providers to dynamically
determine the location of end users (1) when they are at home or their
usual place of work, (2) when they move frequently between multiple
locations, and (3) when they are at locations they do not regularly
visit. How accurate is the location information acquired in these
scenarios, and would it be sufficient to meet the proposed definition
of dispatchable location? Are sources of reliable location information
available to interconnected VoIP providers? Could the NEAD assist
interconnected VoIP providers with dynamic determination of the
location of end users? If so, what steps could the Commission take, if
any, to facilitate the use of the NEAD by interconnected VoIP
providers? What obligations, if any, should be placed on interconnected
VoIP providers that seek to access the NEAD?
77. While we prefer to encourage the development of dispatchable
location solutions that do not require manual end user updates, we
recognize that such solutions may not be feasible or cost-effective in
all circumstances. For example, as part of the 911 call session, if
real-time dispatchable location information cannot be generated
automatically, the VoIP provider may need to send an interactive query
to the end user to confirm the location identified by the provider, and
to correct the location if needed. To enable interconnected VoIP
providers to appropriately balance technical feasibility,
functionality, customer impact, and cost, we propose to allow providers
flexibility in implementing dispatchable location solutions, and to
fall back to Registered Location options when dispatchable location is
not feasible. Thus, solutions may include, but are not limited to,
determining the customer's location dynamically, pre-populating a
previously-supplied Registered Location based on the network attachment
point, or requesting a new Registered Location from the customer when
the customer initiates a new connection or attachment to the network.
We seek comment on this approach.
78. Finally, we seek comment on any alternative approaches that
would achieve the same aims as the proposed rules. Are there mechanisms
or best practices for refreshing or validating location information
that should be encouraged or required? Are there alternatives to
dispatchable location that interconnected VoIP providers could use to
provide location information, e.g., coordinate-based information? We
seek comment on whether these, or other approaches, would provide the
greatest likelihood of conveying an accurate location to the PSAP while
minimizing the burdens on the interconnected VoIP service provider and
the end user.
5. Telecommunications Relay Services
79. Section 64.604 requires Text Telephone-based (TTY-based) TRS
providers to use a system for incoming emergency calls that, at a
minimum, automatically and immediately transfers the caller to an
appropriate PSAP. Section 64.605 generally requires internet-based TRS
to deliver emergency calls to an appropriate PSAP and to provide the
location of the emergency. For some of these services, the service
provider is required to ask callers for their location information at
the beginning of the emergency call. For other emergency calls
(specifically those that use a Video Relay Service (VRS) or IP Relay),
the service provider must transmit location information to the PSAP in
the form of a Registered Location, including for devices capable of
being moved to a different location. The Commission modeled these
requirements after the 911 location requirements for interconnected
VoIP services discussed above. We observe that internet-based TRS and
interconnected VoIP service face similar concerns regarding the ability
to accurately locate end users that use a mobile or portable device.
80. As in our discussion of interconnected VoIP above, although RAY
BAUM'S Act does not require reconsideration of previously adopted E911
location rules, we believe it is appropriate as part of the Act's
``all-platforms'' approach to consider revising our TRS E911 rules.
Specifically, we seek comment on whether TRS providers can develop the
means to provide updated dispatchable location. In particular, we seek
comment on the feasibility of using existing Registered Location
mechanisms to provide dispatchable location for fixed and nomadic VRS
and IP Relay users, paralleling the rules we propose above for
interconnected VoIP service. Is Registered Location sufficient in the
fixed TRS environment? If a mechanism exists for manual updates by the
user when a nomadic TRS device is used, is Registered Location
sufficient to satisfy a dispatchable location requirement? As with
VoIP, we also seek comment on the feasibility of having TRS devices
and/or networks support the automatic provision of real-time
dispatchable location without requiring registration or manual location
updates by the end user. What technical elements would be required in
the end user's device and/or the service provider's network to support
this capability, and to what degree are such technical elements already
in place? To what degree are TRS providers able to dynamically
determine the location of end users (1) when they are at home or their
usual place of work, (2) when they move frequently between multiple
locations, and (3) when they are at locations they do not regularly
visit? How accurate is the location information acquired in these
scenarios, and would it be sufficient to meet the proposed definition
of dispatchable location?
81. To enable TRS providers to balance technical feasibility,
functionality, customer impact, and cost, we propose to allow TRS
providers flexibility in implementing dispatchable location solutions,
and to fall back to Registered Location options when real-time
dispatchable location is not feasible. We seek comment on this
approach. We also seek comment whether there are differences between
internet-based TRS and interconnected VoIP that might require taking a
different approach to TRS dispatchable location from the approach
proposed for interconnected VoIP. As with interconnected VoIP, we seek
comment on whether the NEAD or a similar database could assist TRS
providers in implementing dispatchable location solutions. If so, what
steps could the Commission take, if any, to facilitate the use of such
databases by TRS providers? What obligations, if any, should be placed
on TRS providers that seek to access the NEAD? Finally, we seek comment
on any alternative approaches
[[Page 54191]]
that would achieve the same aims as our proposed rules for TRS.
6. Other 911-Capable Services
82. We seek comment on whether we should consider adopting 911
rules for any other communications services that are not covered by
existing 911 rules but provide the capability for users to make a 911
call. RAY BAUM'S Act defines a ``911 call'' as a voice call that is
placed, or a message that is sent by other means of communication, to a
PSAP for the purpose of requesting emergency services. What
communications services that are not covered by existing 911 rules are
capable of making 911 calls that fall within this definition? Are there
any services that provide one-way voice communications that are capable
of making such a 911 call? How often do consumers use these services to
call 911? How do these services complete calls to PSAPs? What kinds of
information, including callback numbers and location information, is or
could be conveyed to PSAPs with these calls? What are PSAPs'
experiences in answering these calls? What do consumers using these
services understand about the limitations on any 911 services provided?
Are these 911 calls effective at conveying location information to the
PSAP? Do any specific communication services from which these 911 calls
originate create difficulties in locating the caller? Is there
consistency in the way calls originating from a specific communication
service are received and are presented to the PSAP? Would outcomes for
911 callers be improved if we adopted 911 rules for these
communications services that parallel existing rules, including any
requirements for conveying dispatchable location? Would new rules that
are specifically tailored for those communications services be more
effective at improving outcomes?
83. We observe that some outbound-only VoIP services partner with
businesses that offer 911 smartphone applications that allow consumers
to make calls to 911. Some 911 stakeholders have expressed concerns
that calls received from these services may route to the incorrect
PSAP, result in fraudulent calls, lack critical location information
capabilities, and place the 911 caller at risk. Our current rules do
not require outbound-only VoIP services to support 911 or convey
dispatchable location with 911 calls. However, in 2011 the Commission
sought comment on expanding 911 obligations to providers of outbound-
only VoIP services. In that case, the Commission proposed to amend the
definition of the subject services to include any service that: (1)
Enables real-time, two-way voice communications; (2) requires an
internet connection from the user's location (as opposed to a broadband
connection); (3) requires internet protocol-compatible customer
premises equipment; and (4) permits users to terminate calls to all or
substantially all United States E.164 telephone numbers.
84. Based on the concerns noted above and in light of our previous
proposal, we seek comment on expanding the scope of those IP-based
services subject to our 911 rules to include not only interconnected
VoIP, but to also include ``911 VoIP Services,'' defined as those
services that enable real-time, two-way voice communications that
require internet protocol-compatible customer premises equipment and
permit users generally to initiate a 911 call, even if the service does
not permit users generally to receive calls that originate on the PSTN.
Is there any reason to exempt outbound-only VoIP services that allow
911 calls from our 911 requirements simply because the service is
incapable of receiving an incoming call from the PSTN? Does the public
expect all VoIP services that allow the completion of 911 calls to meet
the same minimum standards, without regard to whether the service can
receive an incoming call? We seek comment on our proposal.
7. Additional Considerations
85. For each of the communications service categories discussed
above, we seek comment on common issues that are related to the
implementation of dispatchable location requirements for 911 calls. We
seek comment on how dispatchable location requirements for MLTS may
interact with dispatchable location requirements for other 911-capable
services. Are there situations in which the value of dispatchable
location to first responders is diminished due to the availability of
on-site notification to enterprises, or vice versa? In what situations,
if any, should communications service providers be exempted from a
dispatchable location requirement? Should providers be allowed or
required to provide other types of location information, e.g.,
coordinate-based information, in addition to or as an alternative to
satisfying a dispatchable location requirement? If communications
services and/or certain types of providers (e.g., of a specific size,
or with a specific number of consumers) are exempted from dispatchable
location requirements, should we require them to provide consumer
disclosure regarding the limitations of their 911 location
capabilities? We also ask commenters to identify voluntary best
practices that can improve the effectiveness of acquiring a 911
caller's dispatchable location.
86. As noted above, we believe MLTS installers, managers, and
operators will be able to identify situations in which street address
is sufficient for first responders to quickly and accurately find the
calling party. We also expect that street address will suffice as a
dispatchable location for the smallest enterprises. Accordingly, we do
not propose size-based exceptions to the dispatchable location
requirement. We seek comment on this approach.
8. Compliance Dates
87. For all communications platforms that are to be covered by the
dispatchable location requirements proposed in this NPRM, we propose to
require compliance on the same date as our proposed implementation of
Kari's Law, i.e., February 16, 2020. We tentatively conclude a uniform
compliance date will promote efficiency by enabling MLTS manufacturers
to implement dispatchable location upgrades on the same timeline as any
upgrades needed to comply with the direct dial and notification
requirements of Kari's Law. In addition, we tentatively conclude that
applying the same compliance date to dispatchable location requirements
across all platforms will encourage the development of common
dispatchable location solutions that can support multiple platforms. We
seek comment on this approach, as well as alternatives. With respect to
MLTS, is it reasonable to anticipate that by the February 16, 2020
compliance date for Kari's Law, newly manufactured MLTS will be capable
of conveying dispatchable location with 911 calls? Are there
dispatchable location solutions that can be widely and inexpensively
implemented into MLTS being manufactured today? Do technical standards
currently exist that would be appropriate for governing conveyance of
dispatchable location from MLTS, or do such standards need to be
developed? If the latter, how much time is needed to develop those
standards, and who should develop them?
88. We also seek comment on our proposal to apply the same February
2020 compliance date for our proposed dispatchable location
requirements for fixed telephony, interconnected VoIP, and TRS. We also
seek comment on alternatives. Is there any reason to establish a
compliance date or dates for these services that is either earlier or
later than the proposed compliance date
[[Page 54192]]
for implementation of Kari's Law? Should compliance for different
service types be phased as a way to require greater accuracy over time
or to provide additional time to small businesses to come into
compliance? Will PSAPs be capable of receiving dispatchable location by
February 16, 2020, or are there additional steps that either some or
all PSAPs must take to achieve this capability? Are existing class of
service definitions sufficient to support PSAP receipt of dispatchable
location or must new ones be developed? Are there standards-based
approaches that could be taken to improve the technological
capabilities of emergency calling (particularly as it expands beyond
PSTN calls) while also improving the economics of enabling effective
emergency calling? Should international roaming scenarios be taken into
consideration? Are other countries/regions of the world developing
emergency calling standards that have addressed location accuracy,
routing to the appropriate PSAP, and provision of dispatchable location
in the context of interconnected VoIP and other new technologies?
9. Comparison of Benefits and Costs
89. We seek comment on whether providing dispatchable location for
911 calls from MLTS and other communications services would improve
emergency response and the health and safety of the public, and whether
this benefit would exceed the cost of providing it. Commenters to the
ECS NOI argued that the life-saving benefits of adopting E911
requirements for MLTS are apparent. For example, NASNA asserted that
just as E911 for landline, wireless, and VoIP has resulted in
improvements in the speed at which emergency responders are able to
reach the caller, so would E911 for ECS. NASNA stated, ``The magnitude
of this benefit would be analogous to the well-studied, documented and
proven benefits of E911 in general.''
90. The scale of any potential benefits depends on the magnitude of
the problem we are facing. Currently, how common are 911 calls from
MLTS and other communications platforms that fail to convey any
location information or that convey location information that is too
imprecise or inaccurate to assist PSAPs and first responders in timely
locating the caller? What is the expected lifespan of such systems? Is
there any reason to expect that this situation will improve by 2020? If
so, by how much? What cost differential will our proposed rules impose
on MLTS and other systems purchased beginning in 2020? How many
systems, at what additional cost, will be impacted? We seek comment on
the 2013 decision attached to the California Public Utilities
Commission (CPUC) comments on the ECS NOI, which found that potentially
70 percent of California's PBX MLTS systems were not at the time
provisioned to display accurate caller location information to any PSAP
and that only ``350 of AT&T California's customers with PBX phone
stations in 2007 had provisioned [PS/ALI] location information records
in AT&T California's [E911] database.'' To what extent do these
findings accurately reflect caller location information provided by
MLTS? Could the results of these findings be extrapolated more broadly
(e.g., outside of California)? How often are those calls routed to the
wrong PSAPs due to poor or nonexistent location information?
91. We also seek comment on the length and impact of delays in
emergency response due to a lack of location information. RedSky
asserts that ``[p]lacing a detailed, accurate location record in the
hands of emergency responders can save 3-5 minutes in response time
particularly in complex environments.'' Is 3-5 minutes a reasonable
estimate of the improvement in response time? What are the consequences
of those delays for a person needing emergency response? Can those
consequences be quantified? Are there data on the speed of emergency
response for calls that convey alternatives to dispatchable location,
such as x/y/z coordinates? Are there other benefits that have accrued
or could accrue in those systems and services that convey dispatchable
location to PSAPs and first responders, such as reduced time spent on
re-routing calls or arriving at the correct location? Are there any
MLTS or other communications services (e.g., very small facilities)
that would not benefit from conveying dispatchable location, or for
whom the benefit would not exceed the cost?
92. We seek comment on the magnitude of the benefits to the public
when dispatchable location is conveyed with a 911 call from MLTS and
other communications services identified in this NPRM. We anticipate
that the increase in location accuracy that results from the use of
dispatchable location will reduce the arrival time of ambulances for
some 911 callers at least as much as was accomplished by the mobile
location rules adopted in the Indoor Location Fourth Report and Order.
In that Report and Order, we found that the location accuracy
improvements adopted for mobile 911 calls had the potential to save
approximately 10,120 lives annually for an annual benefit of
approximately $92 billion? Based on available 911 call volume data, we
estimate that approximately 75% of 911 calls come from mobile phones,
which already are required to convey a dispatchable location. However,
we believe the remaining 25% of calls to which our proposed rules would
apply will realize benefits. Because three times as many calls come
from mobile phones as from non-mobile sources, we estimate that our
proposed rules have the potential to save a maximum of one third of the
10,120 lives that were projected to be saved annually by the mobile
location rules adopted in the Indoor Location Fourth Report and Order,
or 3,373 lives annually. However, because some providers already convey
location information that is equivalent to dispatchable location, we
expect that our dispatchable location rules will save considerably
fewer lives. Even if we were to assume our proposed rules would save
only one twentieth of the lives that we projected would be saved by the
mobile location rules, the proposed rules would save 506 lives
annually. We rely on the U.S. Department of Transportation's estimate
that the ``Value of a Statistical Life'' (VSL), defined as ``the
additional cost that individuals would be willing to bear for
improvements in safety (that is, reductions in risks) that, in the
aggregate, reduce the expected number of fatalities by one,'' is $9.6
million. In doing so, we estimate that the 506 lives saved by the
proposed rules multiplied by the VSL establishes a benefit floor of
$4.9 billion. We seek comment on whether our estimate is reasonable.
What other benefits can be expected to accrue, such as (but not limited
to) reduced complications from medical issues, reduced damage to
property, increased likelihood of forestalling crime and apprehending
suspects, increased confidence in the 911 system and emergency
responders? How can we assign a dollar figure to evaluate the magnitude
of these and other benefits? We seek estimates of the time-saving value
of dispatchable location and data demonstrating the value of a
reduction in emergency response time.
93. We observe that 911 location solutions that are capable of
conveying dispatchable location to PSAPs are already offered by several
MLTS market participants. Further, several states already place
requirements on MLTS providers to obtain and convey location
information that is more detailed than street address alone, and we
therefore conclude that MLTS manufacturers are
[[Page 54193]]
producing and widely selling equipment that is capable of complying
with our proposed rules. Are there any cases in which currently-
available equipment will not be suitable? In addition, to comply with
current rules, interconnected VoIP service providers and internet-based
TRS providers today obtain customers' Registered Location, which we
believe would likely be sufficient to satisfy our proposed dispatchable
location requirements in many circumstances. Because these dispatchable
location-capable solutions and equipment are already being widely
offered by MLTS manufacturers, installers, and operators, we believe
that the implementation costs of our proposed dispatchable location
rules to these entities would be negligible in most respects. We also
believe that our approach of granting flexibility in satisfying our
proposed rules minimizes the potential cost of compliance. We seek
comment on these observations and tentative conclusions.
94. We tentatively find that three aspects of our proposed rules
may lead to additional implementation costs: (1) Implementation of the
proposed dispatchable location requirement by MLTS managers; (2)
implementation of the proposed requirement for interconnected VoIP,
VRS, and IP Relay providers to identify when a customer uses the
service from a new location and update the customer's location
information; and (3) the proposed requirement for outbound-only VoIP
service providers or other 911 VoIP service providers to comply with
the Part 9 rules. First, we seek comment on any additional costs that
our proposed rules may impose on MLTS managers. In comments responsive
to the ECS NOI, for example, RedSky stated that it can provision its
E911 system service for as little as a $2,500.00 one-time service
installation fee and $100 per month. The service gives the ECS access
to over 5,500 PSAPs in the U.S. and all regional ALI (Automatic
Location Information) databases, as well as providing 911 call
notifications to enterprise security personnel. West Safety stated that
the 2010 MLTS workshop report of the California PUC concluded that
third-party ECS 911 solutions ``are going down in cost and are
available for under $5,000'' with ``[s]mall business solutions as low
as $1,250 for a one-time implementation fee and $65 to $100 per month
in recurring fees.'' However, because our proposed dispatchable
location rules would only apply to those MLTS managers that install
MLTS after February 16, 2020, at which time all MLTS must be
dispatchable location-capable, we tentatively find that the only costs
for which our rules would be responsible are marginal differences in
MLTS price that are attributable to manufacturer efforts to comply with
the rules. Because many MLTS manufacturers are producing and widely
selling equipment that is capable of complying with our proposed rules,
we anticipate that price increases will be minimal.
95. We seek comment on how our rules may affect the price of MLTS,
especially recurring costs. We anticipate that the most significant
costs would be for initial and recurring costs of provisioning location
information to MLTS operators, but tentatively find that the cost of
such provisioning will be significantly less than the benefits that
arise from adopting the rule. Nearly 80% of businesses in the United
States have fewer than ten employees. While we acknowledge that
enterprises with few employees do not always have those employees work
in close proximity to one another, we anticipate that a street address
would likely satisfy the definition of dispatchable location for most
of those businesses and would be available to the MLTS operator at no
cost to the MLTS manager.
96. We expect larger companies to face some initial location
provisioning costs. Because many MLTS manufacturers are producing and
widely selling equipment that is capable of complying with our proposed
rules, we tentatively find that the primary cost to MLTS managers is
the cost of provisioning the location information in the MLTS. To
estimate the cost to these enterprises, we seek to estimate the number
of employees at the affected enterprises, determine the number of lines
and the amount of time needed annually to provision dispatchable
location for those lines, and finally determine the total cost for
workers paid at an hourly wage to complete the task. We tentatively
estimate the number of affected telephone lines in larger (>10)
enterprises from Small Business Administration data, which indicates
that there are approximately 109 million employees at larger firms. We
initially estimate there are 1.1 employees per installed line,
resulting in approximately 99.1 million lines. At an incremental effort
of 1 minute per line and a $30 per hour labor rate, this results in a
maximum one-time cost of approximately $49.6 million. Significantly,
this cost assumes firms will need to create an employee phonebook
database that duplicates that used in general enterprise systems, such
as Microsoft Outlook. We expect that such duplication will be
unnecessary for many enterprises. We also expect that within a few
years, this setup cost will become minimal because manufacturers of
MLTS and general enterprise systems will increasingly connect their
systems, setting up a single phonebook database and making duplication
unnecessary. We seek comment on our proposed methodology and estimates,
including on the existing and future availability to connect general
enterprise systems to MLTS.
97. Larger businesses that use MLTS are likely to initially face
recurring costs to maintain a separate location database. To estimate
the cost to these enterprises, we seek to estimate the number of lines
at the affected enterprises, determine the number of provisioning
changes and the amount of time needed annually to make those changes
for those lines, and finally determine the total cost for workers paid
at an hourly wage to complete the task. We tentatively estimate that
entering the dispatchable address for a move, add, or change to an MLTS
endpoint will take 1 minute of a manager's time. An industry rule-of-
thumb is that 5% of endpoints will require a change of provisioning
(moves, adds, or changes) in a year. With 99.1 million total
incremental lines subject to this rule, 5% of this figure is
approximately 5 million changes per year. At 1 minute per modification
and $30 per hour labor rate, this results in a maximum annual cost of
$2.5 million to keep the location databases up to date. As noted above,
we expect this incremental cost will become minimal over time as
manufacturers of MLTS and general enterprise systems start connecting
their systems. At that point, enterprise information technology staff
will only need to provision a single line when an employee moves. In
addition, as noted above, several states already place requirements on
MLTS providers to obtain and convey location information that is more
detailed than street address alone. For those states, the incremental
cost of our rules is potentially zero. We seek comment on these
estimates, including on the existing and future availability to connect
general enterprise systems to MLTS.
98. RedSky discusses the costs for providing E911 for both legacy
and IP-based ECS, stating that ``IP-based systems have a cost advantage
over legacy systems because of their ability to use [Emergency Response
Location] ERLs and [Emergency Location Information Numbers] ELINs and
segment their networks into logical subnets or zones.'' We seek comment
on whether our proposed rules will hasten the ongoing transition to IP-
based
[[Page 54194]]
MLTS, and whether this transition will reduce the costs to MLTS
managers over time, including the costs of provisioning location
information to MLTS operators. If so, by how much? We seek additional
cost data relative to provisioning dispatchable location from MLTS and
other communications services identified in this NPRM.
99. Second, we seek comment on the costs of implementing our
proposed requirement that interconnected VoIP, VRS, and IP Relay
services identify when a customer uses the service from a new location
and update the customer's location information. To estimate the cost to
these service providers, we seek to estimate the amount of time
required to develop and test the necessary software number and
determine the total cost for workers paid at hourly wages to complete
the task. We tentatively estimate a maximum initial cost of $8,280,000
industry-wide. We tentatively assume that eight months will be a
sufficient time period for developing and testing and deploying the
software modifications required for updating customer location
information, as this would enable service providers to begin to comply
with our proposed rules after their final adoption and finish before
the February 16, 2020 compliance date. We estimate that six of the
eight months will be devoted to software development and deployment,
and two of the eight months will be devoted to testing and debugging.
We estimate that the maximum cost of developing any software update
necessary to comply with the rules we propose today for each
interconnected VoIP-related entity, VRS provider, and IP Relay provider
would be $92,000, the cost of compensating one full-time software
engineer for six months of labor. We estimate that the cost of testing
these modifications (including integration testing, unit testing, and
failure testing), which requires as many as 12 software engineers
working for two months, will be $368,000 for each interconnected VoIP-
related entity, VRS provider, and IP Relay provider. Thus, we estimate
that the total cost of software modifications for each interconnected
VoIP-related entity, VRS provider, and IP Relay provider will be
$460,000. We estimate that this requirement will be implemented by 12
interconnected VoIP-related entities and 6 VRS providers and IP Relay
providers. Therefore, the total cost to the industry will be $8,280,000
(18 organizations times $460,000 per organization).
100. We further observe that some VoIP-based MLTS will not need to
implement this functionality, as they are already capable of obtaining
the customer's dispatchable location at the time a 911 call is
initiated without requiring additional customer action. We seek comment
on the extent to which interconnected VoIP, VRS, and IP Relay services
already are able to identify when a customer uses the service from a
new location and update the customer's location information. We seek
comment on all of the assumptions upon which these cost estimates are
based and on any recurring costs that interconnected VoIP, VRS, and IP
Relay and service providers would incur in complying with our proposed
rules.
101. Third, we seek comment on the prospective costs to outbound-
only VoIP service providers or other 911 VoIP service providers for
complying with the proposed Part 9 rules, including the proposed
dispatchable location rules. We specifically seek comment on how the
costs of compliance for these providers may differ from the costs to
interconnected VoIP providers that the rules already cover, including
increased costs that arise from unique technical obstacles and
decreased costs that arise from technical solutions for complying with
our rules being well-established and widely available.
102. We seek comment on any additional costs and benefits that
arise from our proposed rules that we have not considered. For example,
how would dispatchable location requirements for MLTS and other
communications services affect PSAPs? How would such requirements
affect customers of those services?
C. Consolidating the Commission's 911 Rules
103. Historically, the Commission has taken a service-by-service
approach to establishing 911 obligations. As a result, our 911 rules
are today scattered throughout different parts of Title 47. For
example, our interconnected VoIP 911 rules are in Part 9, our 911
reliability rules are in Part 12, our mobile E911 rules are in Part 20,
our emergency call center requirements for Mobile-Satellite Service
(MSS) are in Part 25, and our telecommunications carrier obligations
and emergency calling requirements for TRS providers are in Part 64. We
believe that this siloed approach to the organization of our 911 rules
does not adequately reflect that all of the individual services that
enable 911 calls are functional parts of a single system. Moreover, we
expect that the 911 system will become increasingly integrated as
technology evolves and stakeholders migrate from legacy 911 to NG911.
104. Our initiation of this proceeding to develop 911 rules for
MLTS and dispatchable location requirements for all 911-capable
platforms provides us with a unique opportunity to simplify and
streamline our 911 rules in the process. Therefore, in addition to
proposing adoption of MLTS and dispatchable location rules as discussed
above, we propose to consolidate all of our existing 911 rules in a
single rule part, i.e., Part 9, to the extent practicable. We also
propose to simplify and streamline the rules in some instances and to
eliminate corresponding duplicative rules in other rule parts. We
believe the proposed rule consolidation will help to minimize the
burden on small entities subject to the Commission's 911 rules by
making it easier to identify and comply with all 911 requirements.
105. As noted in Appendix A and described for reference in a chart
in Appendix C of the NPRM, we propose to designate Part 9, which
currently contains our interconnected VoIP 911 rules, as the rule part
that would contain the consolidated 911 rules, and we propose to
transfer and consolidate our existing 911 rules from Parts 12, 20, 25,
and 64 to Part 9. The revised Part 9 will continue to differentiate
between platforms where needed, but it will also enable service
providers, PSAPs, and other stakeholders to refer to a single part of
the Commission's rules to ascertain all 911 requirements. Specifically,
we propose to consolidate our 911 rules as follows:
Move relevant definitions for all services to Subpart A of
Part 9;
Move telecommunications carrier obligations (Sections
64.3001 et seq.) to Subpart B of Part 9;
Move CMRS obligations (Section 20.18) to Subpart C of Part
9;
Move interconnected VoIP obligations (current Part 9) to
Subpart D of Part 9;
Move emergency calling requirements for TRS providers
(Sections 64.604(a)(4) and 64.605) to Subpart E of Part 9;
Place proposed MLTS rules in Subpart F of Part 9;
Move emergency call center requirements for MSS providers
(Section 25.284) to Subpart G of Part 9; and
Move 911 resiliency, redundancy, and reliability
requirements (Part 12) to Subpart H of Part 9.
106. Aside from the proposed MLTS and dispatchable location rules
discussed in preceding sections, our proposed rule revisions would
mainly entail consolidating our existing 911 rules without making
substantive changes, but there are some exceptions. Specifically,
consolidating the rules will
[[Page 54195]]
entail making certain conforming and technical changes. For example, in
instances where there are minor differences in the definitions of
common 911-related terms in different rule parts, we propose to
harmonize these definitions for purposes of providing a uniform
definition in Part 9. In addition, we propose to remove a few obsolete
911 rules, e.g., rules referencing one-time information collections
that have been completed, rather than recodify them in Part 9. We also
seek comment on whether we should move Section 22.921 of the rules,
which addresses 911 call processing procedures for analog telephones in
the Cellular Radiotelephone Service, into Part 9 or whether that rule
has become obsolete and should be removed. Further, we propose to
update cross-references in other rule parts as needed, and to correct
erroneous internal cross-references that appear in our existing rules.
107. We explain these proposed changes in greater detail in
Appendix C of the NPRM, which contains conversion tables that track the
proposed disposition of each rule in the consolidation process. We have
prepared a separate table for each current rule part that would be
affected by the proposed rule consolidation. The table identifies the
existing rule section, the section in Part 9 where it would be located
after the consolidation, and whether the rule would also be removed
from its current location. In addition, to help interested parties
quickly identify the source of each rule in proposed Part 9, Appendix C
of the NPRM also contains a conversion table that lists the proposed
Part 9 rules in numerical order and lists the current rule or rules
from which each proposed new rule is derived.
108. We do not include some 911-related rules in our consolidation
proposal, where such rules either do not relate to core 911 obligations
or are integrated with non-911-related rules in such a way that
removing the 911-related rules and transferring them to Part 9 would be
cumbersome and counterproductive. For example, Part 4 of our rules
contains rules relating to network outage reporting, including some
rules that specifically address outages affecting 911 facilities.
Because the Part 4 rules constitute an integrated whole, we do not
propose to transfer or consolidate the 911-specific rules currently
contained in Part 4.
109. Finally, we invite commenters to identify any additional rules
that they recommend for consolidation in Part 9, as well as any rules
that should be updated in light of our proposal.
IV. Procedural Matters
110. Ex Parte Presentations. The proceeding shall be treated as a
``permit-but-disclose'' proceeding in accordance with the Commission's
ex parte rules. Persons making ex parte presentations must file a copy
of any written presentation or a memorandum summarizing any oral
presentation within two business days after the presentation (unless a
different deadline applicable to the Sunshine period applies). Persons
making oral ex parte presentations are reminded that memoranda
summarizing the presentation must (1) list all persons attending or
otherwise participating in the meeting at which the ex parte
presentation was made, and (2) summarize all data presented and
arguments made during the presentation. If the presentation consisted
in whole or in part of the presentation of data or arguments already
reflected in the presenter's written comments, memoranda or other
filings in the proceeding, the presenter may provide citations to such
data or arguments in his or her prior comments, memoranda, or other
filings (specifying the relevant page and/or paragraph numbers where
such data or arguments can be found) in lieu of summarizing them in the
memorandum. Documents shown or given to Commission staff during ex
parte meetings are deemed to be written ex parte presentations and must
be filed consistent with rule 1.1206(b). In proceedings governed by
rule 1.49(f) or for which the Commission has made available a method of
electronic filing, written ex parte presentations and memoranda
summarizing oral ex parte presentations, and all attachments thereto,
must be filed through the electronic comment filing system available
for that proceeding, and must be filed in their native format (e.g.,
.doc, .xml, .ppt, searchable .pdf). Participants in this proceeding
should familiarize themselves with the Commission's ex parte rules.
111. Comment Filing Procedures. Pursuant to Sec. Sec. 1.415 and
1.419 of the Commission's rules, 47 CFR 1.415, 1.419, interested
parties may file comments and reply comments on or before the dates
indicated on the first page of this document. Comments and reply
comments may be filed using the Commission's Electronic Comment Filing
System (ECFS). See Electronic Filing of Documents in Rulemaking
Proceedings, 63 FR 24121 (1998).
Electronic Filers: Comments may be filed electronically
using the internet by accessing the ECFS: http://apps.fcc.gov/ecfs/.
Paper Filers: Parties who choose to file by paper must
file an original and one copy of each filing. If more than one docket
or rulemaking number appears in the caption of this proceeding, filers
must submit two additional copies for each additional docket or
rulemaking number.
Filings can be sent by hand or messenger delivery, by commercial
overnight courier, or by first-class or overnight U.S. Postal Service
mail. All filings must be addressed to the Commission's Secretary,
Office of the Secretary, Federal Communications Commission.
All hand-delivered or messenger-delivered paper filings
for the Commission's Secretary must be delivered to FCC Headquarters at
445 12th St. SW, Room TW-A325, Washington, DC 20554. The filing hours
are 8:00 a.m. to 7:00 p.m. All hand deliveries must be held together
with rubber bands or fasteners. Any envelopes and boxes must be
disposed of before entering the building.
Commercial overnight mail (other than U.S. Postal Service
Express Mail and Priority Mail) must be sent to 9050 Junction Drive,
Annapolis Junction, MD 20701.
U.S. Postal Service first-class, Express, and Priority
mail must be addressed to 445 12th Street SW, Washington DC 20554.
112. People with Disabilities: To request materials in accessible
formats for people with disabilities (braille, large print, electronic
files, audio format), send an email to [email protected] or call the
Consumer & Governmental Affairs Bureau at 202-418-0530 (voice), 202-
418-0432 (tty).
113. Regulatory Flexibility Analysis. As required by the Regulatory
Flexibility Act of 1980, see 5 U.S.C. 603, the Commission has prepared
an Initial Regulatory Flexibility Analysis (IRFA) of the possible
significant economic impact on small entities of the policies and rules
addressed in this document. The IRFA is set forth in Appendix B of the
NPRM. Written public comments are requested on the IRFA. These comments
must be filed in accordance with the same filing deadlines as comments
filed in response to this NPRM as set forth herein, and they should
have a separate and distinct heading designating them as responses to
the IRFA. The Commission's Consumer and Governmental Affairs Bureau,
Reference Information Center, will send a copy of the NPRM, including
this IRFA, to the Chief Counsel for Advocacy of the Small Business
Administration (SBA).
[[Page 54196]]
114. Initial Paperwork Reduction Act Analysis. This NPRM may
contain proposed new and modified information collection requirements.
The Commission, as part of its continuing effort to reduce paperwork
burdens, invites the general public and the Office of Management and
Budget (OMB) to comment on the information collection requirements
contained in this document, as required by the Paperwork Reduction Act
of 1995 (PRA). In addition, pursuant to the Small Business Paperwork
Relief Act of 2002, Public Law 107-198, see 44 U.S.C. 3506(c)(4), we
seek specific comment on how we might ``further reduce the information
collection burden for small business concerns with fewer than 25
employees.''
V. Initial Regulatory Flexibility Act
115. As required by the Regulatory Flexibility Act of 1980, as
amended (RFA), the Commission has prepared this Initial Regulatory
Flexibility Analysis (IRFA) of the possible significant economic impact
on a substantial number of small entities by the policies and rules
proposed in the NPRM. Written public comments are requested on this
IRFA. Comments must be identified as responses to the IRFA and must be
filed by the deadlines for comments provided in paragraph 113 of the
NPRM. The Commission will send a copy of the NPRM, including this IRFA,
to the Chief Counsel for Advocacy of the Small Business Administration
(SBA). In addition, the NPRM and IRFA (or summaries thereof) will be
published in the Federal Register.
A. Need for, and Objectives of, the Proposed Rules
116. In this proceeding, the Commission takes steps to advance
Congressional and Commission objectives to ensure that members of the
public can successfully dial 911 to request emergency services and that
Public Safety Answering Points (PSAPs) can quickly and accurately
locate every 911 caller, regardless of the type of service that is used
to make the call. The President recently signed into law two statutes
directed to the improvement of 911: (1) Kari's Law Act of 2017 (Kari's
Law), which requires implementation of direct 911 dialing and on-site
notification capabilities in multi-line telephone systems (MLTS), and
(2) Section 506 of RAY BAUM'S Act (RAY BAUM'S Act), which requires the
Commission, within 18 months after March 23, 2018, the date of the
legislation's enactment, to ``conclude a proceeding to consider
adopting rules to ensure that the dispatchable location is conveyed
with a 9-1-1 call, regardless of the technological platform used and
including with calls from [MLTS].''
117. The NPRM proposes to implement Kari's Law by adopting direct
dial and on-site notification rules governing calls to 911 made from
MLTS. As required by RAY BAUM'S Act, the Commission also considers the
feasibility of requiring dispatchable location for 911 calls from MLTS
and other technological platforms that currently complete calls to 911.
The NPRM proposes establishing a dispatchable location requirement for
MLTS 911 calls, which would apply contemporaneously with the February
16, 2020 compliance date of Kari's Law. Additionally, in keeping with
the directive in RAY BAUM'S Act to address dispatchable location for
911 calls ``regardless of the technological platform used,'' the NPRM
proposes to add dispatchable location requirements to the Commission's
existing 911 rules for fixed telephony providers, interconnected Voice
over internet Protocol (VoIP) providers, and Telecommunications Relay
Services (TRS). The NPRM also considers the feasibility of alternative
location mechanisms for MLTS and other services that could be used as a
complement to dispatchable location or as a substitute when
dispatchable location is not available. Additionally, the NPRM
considers whether dispatchable location rules should be extended to
other communications services that are not covered by existing 911
rules but are capable of making a 911 call.
118. Finally, the NPRM proposes to take this opportunity to
consolidate the Commission's existing 911 rules, as well as the direct
dialing and dispatchable location rules proposed in this NPRM, into a
single rule part. The Commission historically has taken a service-
specific approach to 911, with the result that 911 requirements for
different services are scattered across different sections of the
agency's rules. We believe that consolidating our 911 rules from these
various rule sections into a single rule part will further the goal of
recognizing that all the components of 911 function as part of a single
system and will enable service providers, emergency management
officials, and other stakeholders to refer to a single part of the
Commission's rules to more easily ascertain all 911 requirements.
B. Legal Basis
119. The proposed action is authorized under sections 1, 4(i),
4(j), 4(o), 201(b), 251(e), 301, 303(b), 303(r), 307, 309, and 316, of
the Communications Act of 1934, as amended, 47 U.S.C. 151, 154(i),
154(j), 154(o), 201(b), 251(e), 301, 303(b), 303(r), 307, 309, 316, and
pursuant to Kari's Law Act of 2017, Public Law 115-127, 47 U.S.C. 623
and 623 note, Section 506 of the Repack Airwaves Yielding Better Access
for Users of Modern Services Act of 2018 (RAY BAUM'S Act), Public Law
115-141, 47 U.S.C. 615 note, Section 106 of the Twenty-First Century
Communications and Video Accessibility Act of 2010, Public Law 111-260,
47 U.S.C. 615c, Section 101 of the New and Emerging Technologies 911
Improvement Act of 2008, Public Law 110-283, 47 U.S.C. 615a-1, Middle
Class Tax Relief and Job Creation Act of 2012, Public Law 112-96, 47
U.S.C. 1471, and the Wireless Communications and Public Safety Act of
1999, Public Law 106-81, 47 U.S.C. 615 note, 615, 615a, 615b.
C. Description and Estimate of the Number of Small Entities To Which
the Proposed Rules Will Apply
120. The RFA directs agencies to provide a description of and,
where feasible, an estimate of the number of small entities that may be
affected by the proposed rules, if adopted. The RFA generally defines
the term ``small entity'' as having the same meaning as the terms
``small business,'' ``small organization,'' and ``small governmental
jurisdiction.'' In addition, the term ``small business'' has the same
meaning as the term ``small business concern'' under the Small Business
Act. A small business concern is one which: (1) Is independently owned
and operated; (2) is not dominant in its field of operation; and (3)
satisfies any additional criteria established by the SBA.
121. Multi-Line Telephone System Manufacturers, Importers, Sellers
or Lessors. Neither the Commission nor the SBA has developed a specific
small business size standard for MLTS manufacturers, importers, sellers
or lessors. The closest applicable SBA category for entities
manufacturing MLTS equipment used to provide wire telephone and data
communications equipment, interconnected VoIP, non-interconnected VoIP,
is Telephone Apparatus Manufacturing. The SBA size standard for
Telephone Apparatus Manufacturing consists of all such companies having
1,250 or fewer employees. U.S. Census Bureau data for 2012 show that
there were 266 establishments that operated that year. Of this total,
262 operated with fewer than 1,000 employees. Thus, under this size
standard, the majority of firms in this industry can be considered
small.
[[Page 54197]]
122. Telephone Apparatus Manufacturing. This industry comprises
establishments primarily engaged in manufacturing wire telephone and
data communications equipment. These products may be stand-alone or
board-level components of a larger system. Examples of products made by
these establishments are central office switching equipment, cordless
and wire telephones (except cellular), PBX equipment, telephone
answering machines, LAN modems, multi-user modems, and other data
communications equipment, such as bridges, routers, and gateways. The
SBA has developed a small business size standard for Telephone
Apparatus Manufacturing, which consists of all such companies having
1,250 or fewer employees. U.S. Census Bureau data for 2012 show that
there were 266 establishments that operated that year. Of this total,
262 operated with fewer than 1,000 employees. Thus, under this size
standard, the majority of firms in this industry can be considered
small.
123. Multi-Line Telephone System Operators, Installers and
Managers. Neither the Commission nor the SBA has developed a specific
small business size standard for MLTS operators, installers and
managers. MLTS Operators, Installers and Managers cut across numerous
industry segments and encompass all types of businesses and
organization including for-profit, not-for-profit and government
agencies. Thus for purposes of this IRFA, we group entities operating,
installing, and managing MLTS in the Small Business, Small Organization
and Small Government Jurisdiction description contained in paragraph 15
infra.
124. All Other Telecommunications. The ``All Other
Telecommunications'' category is comprised of establishments primarily
engaged in providing specialized telecommunications services, such as
satellite tracking, communications telemetry, and radar station
operation. This industry also includes establishments primarily engaged
in providing satellite terminal stations and associated facilities
connected with one or more terrestrial systems and capable of
transmitting telecommunications to, and receiving telecommunications
from, satellite systems. Establishments providing internet services or
voice over internet protocol (VoIP) services via client-supplied
telecommunications connections are also included in this industry. The
SBA has developed a small business size standard for All Other
Telecommunications, which consists of all such firms with annual
receipts of $ 32.5 million or less. For this category, U.S. Census
Bureau data for 2012 show that there were 1,442 firms that operated for
the entire year. Of those firms, a total of 1,400 had annual receipts
less than $25 million and 42 firms had annual receipts of $25 million
to $49,999,999. Thus, the Commission estimates that the majority of
``All Other Telecommunications'' firms potentially affected by our
action can be considered small.
125. Computer Facilities Management Services. This industry
comprises establishments primarily engaged in providing on-site
management and operation of clients' computer systems and/or data
processing facilities. Establishments providing computer systems or
data processing facilities support services are included in this
industry. The SBA has developed a small business size standard for
Computer Facilities Management Services which consists of all such
firms with annual receipts of $27.5 million or less. U.S. Census Bureau
data for 2012 indicate that 4,828 firms operated the entire year. Of
this total, 4,743 had annual receipts less than $25 million and 38
firms had annual receipts of $25 million to $49,999,999. Thus, under
this size standard the majority of firms in this industry can be
considered small.
126. Other Computer Related Services (Except Information Technology
Value Added Resellers). This industry comprises establishments
primarily engaged in providing computer related services (except custom
programming, systems integration design, and facilities management
services). Establishments providing computer disaster recovery services
or software installation services are included in this industry. The
SBA has developed a small business size standard for Other Computer
Related Services, which consists of all such firms with annual receipts
of $27.5 million or less. For this category, U.S. Census Bureau data
for 2012 indicate that 6,354 firms operated the entire year. Of this
total, 6,266 had annual receipts less than $25 million and 42 firms had
annual receipts of $25 million to $49,999,999. Thus, the Commission
estimates that the majority of Other Computer Related Services firms in
this industry can be considered small.
127. Information Technology Value Added Resellers. Information
Technology Value Added Resellers provide a total solution to
information technology acquisitions by providing multi-vendor hardware
and software along with significant value added services. Significant
value added services consist of, but are not limited to, configuration
consulting and design, systems integration, installation of multi-
vendor computer equipment, customization of hardware or software,
training, product technical support, maintenance, and end user support.
The SBA has developed a small business size standard for Information
Technology Value Added Resellers which consists of all such companies
having 150 or fewer employees. For this category, U.S. Census Bureau
data for 2012 indicate that 6,354 firms operated the entire year. Of
this total, 6, 241 had less than 100 employees and 113 had 100-1000 or
more employees. Thus, the Commission estimates that the majority of
Information Technology Value Added Resellers in this industry can be
considered small.
128. Data Processing, Hosting, and Related Services. This industry
comprises establishments primarily engaged in providing infrastructure
for hosting or data processing services. These establishments may
provide specialized hosting activities, such as Web hosting, streaming
services, or application hosting (except software publishing), or they
may provide general time-share mainframe facilities to clients. Data
processing establishments provide complete processing and specialized
reports from data supplied by clients or provide automated data
processing and data entry services. The SBA has developed a small
business size standard for Data Processing, Hosting, and Related
Services which consists of all such firms with annual receipts of $32.5
million or less. U.S. Census Bureau data for 2012 indicate that 8,252
firms operated the entire year. Of this total, 7,730 had annual
receipts less than $25 million and 228 firms had annual receipts of $25
million to $49,999,999. Thus, under this size standard the majority of
firms in this industry are small businesses.
129. Small Businesses, Small Organizations, Small Governmental
Jurisdictions. Our actions, over time, may affect small entities that
are not easily categorized at present. We therefore describe here, at
the outset, three comprehensive small entity size standards that could
be directly affected herein. First, while there are industry specific
size standards for small businesses that are used in the regulatory
flexibility analysis, according to data from the SBA's Office of
Advocacy, in general a small business is an independent business having
fewer than 500 employees. These types of small businesses represent
99.9% of all businesses in the United States which translates to 28.8
million businesses.
130. Next, the type of small entity described as a ``small
organization'' is generally ``any not-for-profit enterprise
[[Page 54198]]
which is independently owned and operated and is not dominant in its
field.'' Nationwide, as of Aug 2016, there were approximately 356,494
small organizations based on registration and tax data filed by
nonprofits with the Internal Revenue Service (IRS).
131. Finally, the small entity described as a ``small governmental
jurisdiction'' is defined generally as ``governments of cities,
counties, towns, townships, villages, school districts, or special
districts, with a population of less than fifty thousand.'' U.S. Census
Bureau data from the 2012 Census of Governments indicates that there
were 90,056 local governmental jurisdictions consisting of general
purpose governments and special purpose governments in the United
States. Of this number there were 37,132 General purpose governments
(county, municipal, and town or township) with populations of less than
50,000 and 12,184 Special purpose governments (independent school
districts and special districts) with populations of less than 50,000.
The 2012 U.S. Census Bureau data for most types of governments in the
local government category shows that the majority of these governments
have populations of less than 50,000. Based on this data we estimate
that at least 49,316 local government jurisdictions fall in the
category of ``small governmental jurisdictions.''
132. Wired Telecommunications Carriers. The U.S. Census Bureau
defines this industry as ``establishments primarily engaged in
operating and/or providing access to transmission facilities and
infrastructure that they own and/or lease for the transmission of
voice, data, text, sound, and video using wired communications
networks. Transmission facilities may be based on a single technology
or a combination of technologies. Establishments in this industry use
the wired telecommunications network facilities that they operate to
provide a variety of services, such as wired telephony services,
including VoIP services, wired (cable) audio and video programming
distribution, and wired broadband internet services. By exception,
establishments providing satellite television distribution services
using facilities and infrastructure that they operate are included in
this industry.'' The SBA has developed a small business size standard
for Wired Telecommunications Carriers, which consists of all such
companies having 1,500 or fewer employees. U.S. Census Bureau data for
2012 show that there were 3,117 firms that operated that year. Of this
total, 3,083 operated with fewer than 1,000 employees. Thus, under this
size standard, the majority of firms in this industry can be considered
small.
133. Local Exchange Carriers (LECs). Neither the Commission nor the
SBA has developed a size standard for small businesses specifically
applicable to local exchange services. The closest applicable NAICS
Code category is for Wired Telecommunications Carriers. Under the
applicable SBA size standard, such a business is small if it has 1,500
or fewer employees. U.S. Census Bureau data for 2012 show that there
were 3,117 firms that operated for the entire year. Of this total,
3,083 operated with fewer than 1,000 employees. Thus under this
category and the associated size standard, the Commission estimates
that the majority of local exchange carriers are small entities.
134. Incumbent Local Exchange Carriers (Incumbent LECs). Neither
the Commission nor the SBA has developed a small business size standard
specifically for incumbent local exchange services. The closest
applicable NAICS Code category is Wired Telecommunications Carriers.
Under the applicable SBA size standard, such a business is small if it
has 1,500 or fewer employees. According to U.S. Census data, 3,117
firms operated the year. Of this total, 3,083 operated with fewer than
1,000 employees. Consequently, the Commission estimates that most
providers of incumbent local exchange service are small businesses that
may be affected by the rules and policies adopted. According to
Commission data, one thousand three hundred and seven (1,307) Incumbent
Local Exchange Carriers reported that they were incumbent local
exchange service providers. Of this total, an estimated 1,006 have
1,500 or fewer employees. Thus using the SBA's size standard the
majority of incumbent LECs can be considered small entities.
135. Competitive Local Exchange Carriers (Competitive LECs),
Competitive Access Providers (CAPs), Shared-Tenant Service Providers,
and Other Local Service Providers. Neither the Commission nor the SBA
has developed a small business size standard specifically for these
service providers. The appropriate NAICS Code category is Wired
Telecommunications Carriers. Under that size standard, such a business
is small if it has 1,500 or fewer employees. U.S. Census Bureau data
for 2012 indicate that 3,117 firms operated during that year. Of that
number, 3,083 operated with fewer than 1,000 employees. Based on this
data, the Commission concludes that the majority of Competitive LECs,
CAPs, Shared-Tenant Service Providers, and Other Local Service
Providers are small entities. According to Commission data, 1,442
carriers reported that they were engaged in the provision of either
competitive local exchange services or competitive access provider
services. Of these 1,442 carriers, an estimated 1,256 have 1,500 or
fewer employees. In addition, 17 carriers have reported that they are
Shared-Tenant Service Providers, and all 17 are estimated to have 1,500
or fewer employees. In addition, 72 carriers have reported that they
are Other Local Service Providers. Of this total, 70 have 1,500 or
fewer employees. Consequently, the Commission estimates that most
providers of competitive local exchange service, competitive access
providers, Shared-Tenant Service Providers, and Other Local Service
Providers are small entities that may be affected by the adopted rules.
136. Interexchange Carriers (IXCs). Neither the Commission nor the
SBA has developed a definition for Interexchange Carriers. The closest
NAICS Code category is Wired Telecommunications Carriers. The
applicable size standard under SBA rules is that such a business is
small if it has 1,500 or fewer employees. U.S. Census Bureau data for
2012 indicate that 3,117 firms operated for the entire year. Of that
number, 3,083 operated with fewer than 1,000 employees. According to
internally developed Commission data, 359 companies reported that their
primary telecommunications service activity was the provision of
interexchange services. Of this total, an estimated 317 have 1,500 or
fewer employees. Consequently, the Commission estimates that the
majority of interexchange service providers that may be affected are
small entities.
137. Local Resellers. The SBA has developed a small business size
standard for Telecommunications Resellers which includes Local
Resellers. The Telecommunications Resellers industry comprises
establishments engaged in purchasing access and network capacity from
owners and operators of telecommunications networks and reselling wired
and wireless telecommunications services (except satellite) to
businesses and households. Establishments in this industry resell
telecommunications; they do not operate transmission facilities and
infrastructure. Mobile virtual network operators (MVNOs) are included
in this industry. Under the SBA's size standard, such a business is
small if it has 1,500 or fewer employees. U.S.
[[Page 54199]]
Census Bureau data for 2012 show that 1,341 firms provided resale
services for the entire year. Of that number, all operated with fewer
than 1,000 employees. Thus, under this category and the associated
small business size standard, the majority of these resellers can be
considered small entities. According to Commission data, 213 carriers
have reported that they are engaged in the provision of local resale
services. Of these, an estimated 211 have 1,500 or fewer employees.
Consequently, the Commission estimates that the majority of Local
Resellers are small entities.
138. Wireless Telecommunications Carriers (except Satellite). This
industry comprises establishments engaged in operating and maintaining
switching and transmission facilities to provide communications via the
airwaves. Establishments in this industry have spectrum licenses and
provide services using that spectrum, such as cellular services, paging
services, wireless internet access, and wireless video services. The
appropriate size standard under SBA rules is that such a business is
small if it has 1,500 or fewer employees. For this industry, U.S.
Census Bureau data for 2012 show that there were 967 firms that
operated for the entire year. Of this total, 955 firms had had
employment of 999 or fewer employees and 12 had employment of 1,000
employees or more. Thus under this category and the associated size
standard, the Commission estimates that the majority of wireless
telecommunications carriers (except satellite) are small entities.
139. The Commission's own data--available in its Universal
Licensing System--indicate that, as of August 31, 2018 there are 265
Cellular licensees that will be affected by our proposed actions. The
Commission does not know how many of these licensees are small, as the
Commission does not collect that information for these types of
entities. Similarly, according to internally developed Commission data,
413 carriers reported that they were engaged in the provision of
wireless telephony, including cellular service, Personal Communications
Service (PCS), and Specialized Mobile Radio (SMR) Telephony services.
Of this total, an estimated 261 have 1,500 or fewer employees. Thus,
using available data, we estimate that the majority of wireless firms
can be considered small.
140. Wireless Communications Services. This service can be used for
fixed, mobile, radiolocation, and digital audio broadcasting satellite
uses. The Commission defined ``small business'' for the wireless
communications services (WCS) auction as an entity with average gross
revenues of $40 million for each of the three preceding years, and a
``very small business'' as an entity with average gross revenues of $15
million for each of the three preceding years. The SBA has approved
these small business size standards. In the Commission's auction for
geographic area licenses in the WCS there were seven winning bidders
that qualified as ``very small business'' entities, and one that
qualified as a ``small business'' entity.
141. Wireless Telephony. Wireless telephony includes cellular,
personal communications services, and specialized mobile radio
telephony carriers. The closest applicable SBA category is Wireless
Telecommunications Carriers (except Satellite), and the appropriate
size standard for this category under the SBA rules is that such a
business is small if it has 1,500 or fewer employees. For this
industry, U.S. Census Bureau data for 2012 show that there were 967
firms that operated for the entire year. Of this total, 955 firms had
fewer than 1,000 employees and 12 firms has 1,000 employees or more.
Thus under this category and the associated size standard, the
Commission estimates that a majority of these entities can be
considered small. According to Commission data, 413 carriers reported
that they were engaged in wireless telephony. Of these, an estimated
261 have 1,500 or fewer employees and 152 have more than 1,500
employees. Therefore, more than half of these entities can be
considered small.
D. Description of Projected Reporting, Recordkeeping, and Other
Compliance Requirements for Small Entities
142. The NPRM proposes rules and seeks comment on rule changes that
will affect the reporting, recordkeeping and/or other compliance
requirements of small businesses and entities of all sizes that are
engaged in the business of manufacturing, importing, selling,
installing, managing or operating MLTS that are manufactured, imported,
offered for first sale or lease, first sold or leased, or installed
after February 16, 2020. The NPRM also proposes rules that will affect
small businesses and entities of all sizes that are engaged in the
business of offering fixed telephony service, wireless
telecommunications, interconnected VoIP service, and TRS. The proposed
changes are being implemented as a result of Congressional mandates in
Kari's Law and RAY BAUM'S Act that require the Commission to address
the inability of callers to directly dial 911 from MLTS and a lack of
accurate and critical location information necessary for a PSAP to
dispatch emergency services to those in need because of the
communications system used in making a 911 call. The specific proposals
in the NPRM are described below.
1. Direct Dialing and Notification for MLTS
143. To implement and enforce Kari's Law, the NPRM proposes rules
that interpret the law's direct dialing and notification requirements
for MLTS. First, the NPRM proposes that a person engaged in the
business of manufacturing, importing, selling, or leasing multi-line
telephone systems may not manufacture or import for use in the United
States, or sell or lease or offer to sell or lease in the United
States, a multi-line telephone system, unless such system is pre-
configured such that, when properly installed in accordance with the
rules, a user may directly initiate a call to 911 from any station
equipped with dialing facilities, without dialing any additional digit,
code, prefix, or post-fix, including any trunk-access code such as the
digit 9, regardless of whether the user is required to dial such a
digit, code, prefix, or post-fix for other calls.
144. Second, the NPRM proposes that a person engaged in the
business of installing, managing, or operating multi-line telephone
systems may not install, manage, or operate for use in the United
States such a system, unless such system is configured such that a user
may directly initiate a call to 911 from any station equipped with
dialing facilities, without dialing any additional digit, code, prefix,
or post-fix, including any trunk-access code such as the digit 9,
regardless of whether the user is required to dial such a digit, code,
prefix, or post-fix for other calls. The NPRM also seeks comment on
whether any additional elements should be included in the proposed
regulations to facilitate compliance and enforcement.
145. Third, the NPRM proposes that a person engaged in the business
of installing, managing, or operating multi-line telephone systems
shall, in installing, managing, or operating such a system for use in
the United States, configure the system to provide notification to a
central location at the facility where the system is installed or to
another person or organization regardless of location, if the system is
able to be configured to provide the notification without an
improvement to the hardware or software of the system. The NPRM also
proposes to require that notification at a minimum (1) the fact that a
911 call has been made, (2) a valid
[[Page 54200]]
callback number, and (3) the information about the caller's location
that the MLTS conveys to the public safety answering point (PSAP) with
the call to 911. The notification must be contemporaneous with the 911
call and must not delay the placement of the call to 911. The NPRM also
seeks comment on whether to require that a person be available on-site
or off-site to receive the notification. The NPRM asks whether small
businesses should be exempt from certain aspects of the notification
requirement.
146. Fourth, Kari's Law applies only with respect to MLTS that are
manufactured, imported, offered for first sale or lease, first sold or
leased, or installed after February 16, 2020. Accordingly, the NPRM
notes that MLTS manufactured, imported, offered for first sale or
lease, first sold or leased, or installed on or before that date are
grandfathered from compliance with the statute, and it seeks comment on
whether the Commission should adopt transitional rules to inform
consumers of the 911 capabilities of grandfathered MLTS.
147. The NPRM also proposes and seeks comment on definitions for
the following terms contained in the proposed regulations: (1) Multi-
line telephone system, (2) Pre-configured and configured, (3)
Improvement to the hardware or software of the system, (4) A person
engaged in the business of managing an MLTS, (5) A person engaged in
the business of operating an MLTS, and (6) A person engaged in the
business of installing an MLTS, (7) notification, and (8) MLTS
notification. The proposed definitions are described below.
148. Multi-line telephone system. The NPRM proposes to define MLTS
consistent with Kari's Law and RAY BAUM'S Act which define MLTS as ``a
system comprised of common control units, telephone sets, control
hardware and software and adjunct systems, including network and
premises based systems, such as Centrex and VoIP, as well as PBX,
Hybrid, and Key Telephone Systems (as classified by the Commission
under part 68 of title 47, Code of Federal Regulations), and includes
systems owned or leased by governmental agencies and non-profit
entities, as well as for profit businesses.'' The NPRM proposes to
interpret this definition to include the full range of networked
communications systems that serve enterprises, including circuit-
switched and IP-based enterprise systems, as well as cloud-based IP
technology and over-the-top applications. We further interpret this
definition to include systems that allow outbound calls to 911 without
providing a way for the PSAP to place a return call.
149. Pre-configured and configured. The NPRM proposes to define
``pre-configured'' to mean that the MLTS is equipped with a default
configuration or setting that enables users to dial 911 directly as
required under the statute and rules, so long as the MLTS is installed
and operated properly. However, if the system is configured with these
additional dialing patterns, they must be in addition to the default
direct dialing pattern. The NPRM proposes to include similar clarifying
language in the definition of ``pre-configure.'' The NPRM also proposes
to define ``configured'' to mean that the MLTS must be fully capable
when installed of dialing 911 directly and providing notification as
required under the statute and rules.
150. Improvement to the hardware or software of the system. Kari's
Law provides that the notification requirements of the statute apply
only if the system can be configured to provide notification without an
improvement to the hardware or software of the system. The NPRM
proposes to define the term ``improvement to the hardware or software
of the system'' to include upgrades to the core systems of an MLTS, as
well as substantial upgrades to the software and any software upgrades
requiring a significant purchase.
151. A person engaged in the business of managing an MLTS. The NPRM
proposes to define a person engaged in the business of managing an MLTS
as the entity that is responsible for controlling and overseeing
implementation of the MLTS after installation. These responsibilities
include determining how lines should be distributed (including the
adding or moving of lines), assigning and reassigning telephone
numbers, and ongoing network configuration.
152. A person engaged in the business of operating an MLTS. The
NPRM proposes to define a person engaged in the business of operating
an MLTS as an entity responsible for the day-to-day operations of the
MLTS. The NPRM's proposed definition would specify that the MLTS
operator may be the MLTS manager, or it may be a third-party acting on
behalf of the manager. For example, an MLTS owner may contract with a
third party to provide a total solution for MLTS, including acquiring
the MLTS equipment, configuring the system, and providing services such
as training, technical support, maintenance, and end user support.
153. A person engaged in the business of installing an MLTS. The
NPRM proposes to define a person engaged in the business of installing
an MLTS as a person who installs or configures the MLTS or performs
other tasks involved in getting the system ready to operate. These
tasks may include, but are not limited to, establishing the dialing
pattern for emergency calls, determining how calls will route to the
PSTN, and determining where the MLTS will interface with the PSTN. The
MLTS installer may be the MLTS manager or a third-party acting on
behalf of the manager.
154. MLTS Notification. The NPRM proposes to define MLTS
notification as an MLTS feature that can send notice to a central
location at the facility where the system is installed or to another
person or organization regardless of location. Examples of notification
include screen pops with audible alarms for security desk computers
using a client application, text messages for smartphones, and email
for administrators.
155. The NPRM observes that according to a Congressional Budget
Office analysis, most MLTS systems already are configured to meet the
direct dialing requirements of Kari's Law. In evaluating the Senate and
House versions of Kari's Law, Cisco stated that it was not aware of any
technological barriers to the implementation of Kari's Law as applied
to MLTS. In addition, eight states and one local government already
have laws that require direct dialing for 911 from MLTS. The NPRM also
tentatively finds that there should be no immediate costs or stranded
investment with respect to existing MLTS or systems that first come
into service on or before February 16, 2020. Therefore, the Commission
tentatively concludes that there will be no immediate costs or benefits
associated with meeting the requirements of its rules. For systems
coming into service after February 16, 2020, the NPRM seeks comment on
the costs and benefits of satisfying its proposed rules. The NPRM also
seeks comment on the expected lifespan of existing MLTS that are not
currently able to meet the requirements of our proposed rules and the
costs of upgrading to an MLTS that meets the requirements. The
Commission seeks comment on its tentative conclusion that its rules
will impose no incremental costs to those who replace their MLTS as
they come to the end of their useful life.
[[Page 54201]]
2. Dispatchable Location for Other 911-Capable Communications Services
156. To facilitate the provisioning of dispatchable location by
other communications services as contemplated by RAY BAUM'S Act, the
NPRM generally proposes to amend existing location requirements with
dispatchable location requirements. In addition to MLTS, the NPRM
examines four types of communications services that are currently
required under Commission rules to provide 911 service to their
customers: (1) Fixed telephony, (2) mobile telecommunications, (3)
interconnected VoIP service, and (4) Telecommunications Relay Services
(TRS). In addition, we examine whether we should adopt dispatchable
location rules for other 911-capable services that are not currently
subject to 911 rules.
157. The NPRM proposes to proscribe the manufacture, import, sale,
or leasing of MLTS unless the system is pre-configured such that, when
properly installed, the dispatchable location of the caller is conveyed
to the PSAP with 911 calls. Further, the NPRM proposes to proscribe the
installation, management, or operation of MLTS in the United States
unless the system is configured such that the dispatchable location of
the caller is conveyed to the PSAP with 911 calls. The NPRM does not
propose specific location technologies or solutions but, rather, seeks
comment on implementing general dispatchable location requirements that
would give participants in the MLTS marketplace flexibility. This
approach will allow the entities affected by the proposed rules to
implement them in a manner that is appropriate for them in terms of
cost, enterprise size, site layout, and technical sophistication. The
NPRM seeks comment on whether the dispatchable location requirement for
MLTS should apply to the same entities subject to the MLTS direct
dialing and notification requirements. Finally, the NPRM seeks comment
on the technical feasibility of 911 calls that originate from MLTS to
convey dispatchable location to the appropriate PSAP as well as
alternatives for conveying dispatchable location such as the use of x/
y/z coordinates to be conveyed with 911 calls originating from MLTS.
The NPRM also seeks comment on alternative compliance timeframes for
dispatchable location requirements for MLTS.
158. The NPRM proposes to define ``dispatchable location'' as ``the
street address of the calling party, and additional information such as
room number, floor number, or similar information necessary to
adequately identify the location of the calling party.'' Given the
substantial similarity between the statutory definition and the
definition of dispatchable location in the FCC's wireless E911 rules,
the NPRM proposes to construe them as functionally identical, aside
from the specification of the technological platform to which each
definition applies. The NPRM also seeks comment on whether to require
validation for dispatchable location information associated with MLTS
911 calls. The NPRM also seeks comment on whether to define
``additional information'' that may be necessary in an MLTS context to
``adequately identify the location of the calling party.'' The NPRM
also seeks comment on whether the National Emergency Address Database
(NEAD), the location database being developed by the major mobile
carriers to provide dispatchable location for indoor mobile 911 calls,
could potentially assist MLTS managers and operators in determining the
dispatchable location of MLTS end users
159. The NPRM proposes to amend the rules to require fixed
telephony providers to provide dispatchable location with 911 calls.
Although fixed telephony providers already provide validated street
address information, dispatchable location includes additional elements
such as floor level and room number that may be necessary to locate the
caller. The NPRM also seeks comment on whether the NEAD or similar
database could assist fixed telephony carriers in providing
dispatchable location with 911 calls. The NPRM seeks comment on whether
there any alternatives to dispatchable location that fixed telephony
could use to provide in-building location information beyond street
addresses, e.g., coordinate-based information.
160. The NPRM proposes to amend the Commission's rules to require
interconnected VoIP providers to develop the means to provide updated
dispatchable location with 911 calls in lieu of conveying the
customer's Registered Location. Regarding Fixed VoIP, the NPRM observes
that it is feasible for 911 calls that originate from interconnected
VoIP services to convey dispatchable location to the PSAP. In a Nomadic
VoIP context, the NPRM seeks comment on whether Registered Location
represents sufficient proxy for dispatchable location in a nomadic
environment, where the relevant device is able to prompt the user for
an updated location when it has been moved. The NPRM also seeks to
encourage having interconnected VoIP devices and/or networks support
the automatic provision of real-time dispatchable location without
requiring a manual location update by the end user.
161. The NPRM proposes to amend the Commission's rules to require
TRS providers to develop the means to provide updated dispatchable
location, paralleling the rules the NPRM proposes for interconnected
VoIP service. The NPRM seeks comment on the feasibility of using
existing Registered Location mechanisms to provide dispatchable
location for fixed and nomadic TRS users. The NPRM also seeks comment
on the feasibility of having TRS devices and/or networks support the
dynamic provision of real-time dispatchable location without requiring
registration or manual location updates by the end user.
162. The NPRM seeks comment on whether providing dispatchable
location for 911 calls from MLTS and other communications services
would improve emergency response and the health and safety of the
public, and whether this benefit would exceed the cost of providing it.
The NPRM seeks comment on the magnitude of the benefits to the public
when dispatchable location is conveyed with a 911 call from MLTS and
other communications services identified in this NPRM. The NPRM
anticipates that the increase in location accuracy that results from
the use of dispatchable location will reduce the arrival time of
ambulances for some 911 callers at least as much as was accomplished by
the mobile location rules adopted in the Indoor Location Fourth Report
and Order.
163. The NPRM tentatively concludes that the benefits of adopting
proposed dispatchable location rules for MLTS, fixed telephony
providers, interconnected VoIP service providers, and TRS providers
will outweigh the costs. The NPRM observes that 911 location solutions
that are capable of conveying dispatchable location to PSAPs are
already offered by several MLTS market participants. Further, several
states already place requirements on MLTS providers to obtain and
convey location information that is more detailed than street address
alone, and we therefore conclude that MLTS manufacturers are producing
and widely selling equipment that are capable of complying with our
proposed rules. In addition, we observe that interconnected VoIP
service providers and internet-based TRS providers today obtain
customers' Registered Location, which would satisfy our proposed
dispatchable location requirements. Because these dispatchable
location-
[[Page 54202]]
capable solutions and equipment are already widely available, the
implementation costs of our proposed dispatchable rules to MLTS
manufacturers, installers, and operators would be negligible in most
respects. The NPRM also proposes to provide flexibility in how to
satisfy the proposed dispatchable location requirements and should
minimize the potential cost of compliance.
164. The NPRM identifies several aspects of the proposed rules that
may lead to additional implementation costs. To assist the Commission
in identifying and quantifying the additional costs that may impact
small as well large entities, the Commission requests cost information
from the parties. First, the NPRM seeks comment on any additional costs
that our proposed rules may impose on MLTS managers. Second, the NPRM
seeks comment on the costs of implementing our proposed requirement
that interconnected VoIP and TRS services identify when a customer uses
the service from a new location and update the customer's location
information. Third, the NPRM seeks comment on the costs to outbound-
only VoIP service providers of complying with the Part 9 rules,
including the proposed dispatchable location rules. Finally, the NPRM
seeks comment on any additional costs that arise from our proposed
rules that we have not considered.
E. Steps Taken To Minimize the Significant Economic Impact on Small
Entities, and Significant Alternatives Considered
165. The RFA requires an agency to describe any significant
alternatives that it has considered in reaching its proposed approach,
which may include the following four alternatives (among others): (1)
The establishment of differing compliance or reporting requirements or
timetables that take into account the resources available to small
entities; (2) the clarification, consolidation, or simplification of
compliance or reporting requirements under the rule for small entities;
(3) the use of performance, rather than design, standards; and (4) an
exemption from coverage of the rule, or any part thereof, for small
entities.
166. To assist the Commission's evaluation of the economic impact
on small entities as a result of actions that have been proposed in
this NPRM and to better explore options and alternatives, the
Commission seeks comment from the parties. With respect to direct
dialing and notification under Kari's Law, the NPRM seeks comment on
alternatives to reduce the burden and minimize the costs of compliance
on small entities. The NPRM observes that notification can be
particularly important in large buildings such as hotels, hospitals,
and schools, where on-site personnel are uniquely suited to provide
information about the building and its occupants. The NPRM asks whether
commenters agree that notification is more important for larger
enterprises and, if so, whether small businesses should be exempt from
certain aspects of the notification requirement, such as a requirement
to staff the notification point. The NPRM also seeks comment on what
entities should fall within an exception for small businesses. The NPRM
asks whether the criterion should be the size of the business or the
number of stations in the MLTS. In addition, the NPRM asks whether
instead of specifying the content of the notification, the Commission
should allow enterprises the flexibility to customize it as they see
fit.
167. Regarding dispatchable location, the NPRM asks whether some
MLTS in use today are not capable of supporting dispatchable location
and whether such systems should be exempted from a dispatchable
location requirement. The NPRM invites commenters to offer alternatives
to reduce the cost burdens on MLTS entities and other communications
services, including whether to allow the entity to pick the location
methodology that works best. As mentioned above, giving participants in
the MLTS marketplace the flexibility to choose how to implement the
proposed rules will mitigate their cost of compliance. The NPRM also
asks what steps an MLTS manager must take, if any, to ensure that
dispatchable location is conveyed to the PSAP, what are the most
effective, least burdensome means to ensure that these steps are taken.
168. The NPRM asks whether there are situations in which
communications service providers should be exempted from a dispatchable
location requirement. In addition, the NPRM asks whether there are any
MLTS or other communications services (e.g., very small facilities)
that would not benefit from conveying dispatchable location, or for
whom the benefit would not exceed the cost. The NPRM also asks whether
any communications services that are exempted from dispatchable
location requirements should be required to provide consumer disclosure
regarding the limitations of their 911 location capabilities. In
addition, the NPRM asks whether dispatchable location requirements for
different service types should become effective in phases to require
greater accuracy over time or to provide additional time to small
businesses to come into compliance.
169. The NPRM also proposes to consolidate all of the existing 911
rules into a single rule part, i.e., Part 9, to the extent practicable.
As part of this consolidation, the Commission proposes to simplify and
streamline the rules in some instances and to eliminate corresponding
duplicative rules in other rule parts. In addition, the NPRM invites
commenters to identify additional 911 service rules that should be
consolidated under Part 9. We believe the proposed rule consolidation
will help to minimize the burden on small entities subject to the
Commission's 911 rules because it will simplify and streamline the
rules, making it easier for small entities to identify and comply with
all 911 requirements.
F. Federal Rules that May Duplicate, Overlap, or Conflict with the
Proposed Rules
170. None.
G. Paperwork Reduction Act
171. This document may contain proposed new or modified information
collection requirements. The Commission, as part of its continuing
effort to reduce paperwork burdens, invites the general public and the
Office of Management and Budget (OMB) to comment on the information
collection requirements contained in this document, as required by the
Paperwork Reduction Act of 1995, Public Law 104-13. In addition,
pursuant to the Small Business Paperwork Relief Act of 2002, Public Law
107-198, see 44 U.S.C. 3506(c)(4), we seek specific comment on how we
might further reduce the information collection burden for small
business concerns with fewer than 25 employees.''
VI. Conversion Tables
Appendix C
[[Page 54203]]
Conversion Table A
------------------------------------------------------------------------
Proposed Rule Source Rule(s) Comment(s)
------------------------------------------------------------------------
Subpart A--Purpose and
Definitions
Sec. 9.1 Purpose........
Sec. 9.2 Reserved.......
Sec. 9.3 Definitions........ 47 CFR 9.3, 20.3, Certain definitions
25.103, from source rules
64.601(a), and added to Sec. 9.3;
64.3000. some definitions
revised; some
definitions new.
Subpart B--Telecommunications ................. Part 64, subpart AA
Carriers. (Universal Emergency
Telephone Number) is
removed and
reserved.
Sec. 9.4 Obligation to 47 CFR 64.3001... Source rule moved to
transmit 911 calls. Sec. 9.4 and
subpart AA removed
and reserved in Part
64.
Sec. 9.5 Transition to 47 CFR 64.3002... Source rule moved to
911 as the universal Sec. 9.5 and
emergency telephone subpart AA removed
number. and reserved in Part
64.
Sec. 9.6 Obligation for 47 CFR 64.3003... Source rule moved to
providing a permissive Sec. 9.6 and
dialing period. subpart AA removed
and reserved in Part
64.
Sec. 9.7 Obligation for 47 CFR 64.3004... Source rule moved to
providing an intercept Sec. 9.7 and
message. subpart AA removed
and reserved in Part
64.
Sec. 9.8 Obligation to ................. New provision.
convey dispatchable
location.
Subpart C--Commercial Mobile
Radio Service
Sec. 9.9 Definitions.... 47 CFR 20.3...... Certain definitions
from source rule
added to Sec. 9.9.
Sec. 9.10 911 Service 47 CFR 20.18..... Source rule moved to
Requirements. Sec. 9.10 and
removed and reserved
in Part 20.
Subpart D--Interconnected
Voice over Internet Protocol
Services and 911 VoIP
Services
Sec. 9.11 E911 Service.. 47 CFR 9.5....... Source rule moved to
Sec. 9.11 and
revised except for
Sec. 9.5(f), which
is omitted.
Sec. 9.12 Access to 911 47 CFR 9.7....... Source rule moved to
and E911 service Sec. 9.12 and
capabilities. revised.
Subpart E--Telecommunications
Relay Services for Persons
With Disabilities
Sec. 9.13 Jurisdiction.. 47 CFR 64.601(b) Source rules added to
and 64.602. Sec. 9.13.
Sec. 9.14 Emergency 47 CFR Source rules moved to
Calling Requirements. 64.604(a)(4) and Sec. 9.14 and
64.605. revised; Sec.
64.605 removed and
reserved in Part 64.
Subpart F--Multi Line ................. New provision.
Telephone Systems.
Sec. 9.15 Applicability.
Sec. 9.16 General
obligations--direct 911
dialing, notification and
dispatchable location.
Sec. 9.17 Enforcement,
compliance date, State
law.
Subpart G--Mobile-Satellite
Service
Sec. 9.18 Emergency Call 47 CFR 25.284.... Source rule moved to
Center Service. Sec. 9.18 and
removed and reserved
in Part 25.
Subpart H--Resiliency, ................. Part 12 is
redundancy and reliability of consolidated under
911 communications. Part 9, Subpart H
and is removed and
reserved.
Sec. 9.19 Reliability of 47 CFR 12.4...... Source rule moved to
covered 911 service Sec. 9.19 and
providers. removed and reserved
in Part 12.
Sec. 9.20 Backup power 47 CFR 12.5...... Source rule moved to
obligations. Sec. 9.20 and
removed and reserved
in Part 12.
------------------------------------------------------------------------
Conversion Table B
Part 9--Interconnected Voice Over Internet Protocol Services, Proposed
Rule Changes
------------------------------------------------------------------------
Current rule No. Subject Proposed changes
------------------------------------------------------------------------
9.1........................... Purposes......... Revised.
9.3........................... Definitions...... Definition of
``Registered
Location'' moved to
9.3 and revised.
All other
definitions remain in
9.3:
ANI.
Appropriate local
emergency authority.
Automatic Location
Information (ALI).
CMRS.
Interconnected VoIP
service.
[[Page 54204]]
PSAP.
Pseudo Automatic
Number Identification
(Pseudo-ANI).
Statewide default
answering point.
Wireline E911
Network.
9.5........................... E911 Service..... Moved to 9.11 and
revised, except for
9.5(f), which is a
one-time information
collection that has
been completed.
Propose to remove
the obligation in
9.5(f).
9.7........................... Access to 911 and Moved to 9.12 and
E911 service revised.
capabilities.
------------------------------------------------------------------------
Part 12--Resiliency, Redundancy and Reliability of Communications,
Proposed Rule Changes
------------------------------------------------------------------------
Current rule No. Subject Proposed changes
------------------------------------------------------------------------
12.1.......................... Purpose.......... Removed.
12.3.......................... 911 and E911 Removed (one-time
analyses and reporting
reports. requirement has been
completed).
12.4.......................... Reliability of Moved to 9.19;
covered 911 corrected internal
service cross-references.
providers.
12.5.......................... Backup power Moved to 9.20;
obligations. corrected internal
cross-references.
------------------------------------------------------------------------
Part 20--Commercial Mobile Services, Proposed Rule Changes
------------------------------------------------------------------------
Current rule No. Subject Proposed changes
------------------------------------------------------------------------
20.2.......................... Other applicable Section 20.2
rule parts. specifies other FCC
rule parts
applicable to
licensees in the
commercial mobile
radio services.
Revised 20.2 by
adding a reference
to compliance with
the 911 requirements
in part 9 of this
chapter.
20.3.......................... Definitions...... Definitions of the
following terms
added to 9.3 and
removed from 20.3:
Appropriate local
emergency authority.
Automatic Number
Identification (ANI)
(The version in 9.3
is revised slightly
to harmonize it with
the definition of ANI
from 64.601).
Designated PSAP.
Handset-based
location technology.
Location-capable
handsets.
Network-based
Location Technology.
Pseudo Automatic
Number Identification
(Pseudo-ANI).
Public safety
answering point
(PSAP) (The version
in 9.3 is revised
slightly for clarity
by adding the word
``answering'' before
``point'').
Statewide default
answering point.
Definitions of the
following terms added
to 9.3 (but not
removed from 20.3).
Commercial mobile
radio service
(acronym CMRS added
to definition for
clarity).
Mobile Service.
Public Switched
Network.
Private Mobile
Radio Service.
Definitions of the
following terms added
to 9.9 (but not
removed from 20.3).
Interconnection or
Interconnected.
Interconnected
Service.
20.18......................... 911 Service...... Moved to 9.10;
corrected internal
cross-references.
Corrected certain
internal references
to paragraph (j),
which was previously
redesignated as
paragraph (m).
Corrected certain
internal references
to paragraph (n),
which was previously
redesignated as
paragraph (q).
------------------------------------------------------------------------
Part 25--Satellite Communications, Proposed Rule Changes
------------------------------------------------------------------------
Current rule No. Subject Proposed changes
------------------------------------------------------------------------
25.103........................ Definitions...... Definitions of the
following terms
added to 9.3 (but
not removed from
25.103):
Earth station.
Feeder link.
Fixed-Satellite
Service (FSS).
Mobile Earth
Station.
[[Page 54205]]
Mobile-Satellite
Service (MSS).
Space station.
Definition of the
following term added
to 9.3 and removed
from 25.103:
Emergency Call
Center.
25.109........................ Cross-reference.. Added new (e) to
25.109 stating that
``Mobile-Satellite
Service providers
must comply with the
emergency call
center service
requirements under
47 CFR part 9.''
25.284........................ Emergency Call Moved to 9.18;
Center Service. section 25.284
removed and
reserved.
------------------------------------------------------------------------
Part 64--Miscellaneous Rules Relating to Common Carriers, Proposed Rule
Changes
------------------------------------------------------------------------
Current rule No. Subject Proposed changes
------------------------------------------------------------------------
64.601........................ Definitions and 64.601(b), which
provisions of states that ``For
general purposes of this
applicability. subpart, all
regulations and
requirements
applicable to common
carriers shall also
be applicable to
providers of
interconnected VoIP
service,'' is added
to 9.13, with
reference to the
definition of
interconnected VoIP
in 9.3.
64.601(a), which
lists several terms
and defines them by
cross-referencing
other rule sections,
is revised to
include references
to definitions in
9.3.
Definition of ANI
added to 9.3 but not
removed from 64.601.
Definition of
Registered Location
added to 9.3 and
revised.
Definition of Real-
Time Text (RTT) is
added to 9.3 and
revised to include
definition from 67.1
(rather than cross-
reference to 67.1).
Definition of the
following terms
added to 9.3 (but
not removed from
64.601):
Common carrier or
carrier
Communications
assistant (CA)
Internet-based TRS
(iTRS)
IP Relay access
technology
iTRS access
technology
Internet-based TRS
(iTRS)
Internet Protocol
Relay Service (IP
Relay)
Non-English
language relay
service
Speech-to-speech
relay service
Telecommunications
relay services (TRS)
Text telephone
(TTY)
Video relay service
(VRS)
VRS access
technology
64.602........................ Jurisdiction..... 64.602, which states
that ``Any violation
of this subpart F by
any common carrier
engaged in
intrastate
communication shall
be subject to the
same remedies,
penalties, and
procedures as are
applicable to a
violation of the Act
by a common carrier
engaged in
interstate
communication,'' is
added to 9.13 (with
reference to subpart
E of part 9).
64.603........................ Provision of Section 64.603(a)
services. requires common
carriers providing
telephone voice
transmission
services to provide
telecommunications
relay services in
compliance with the
regulations
prescribed in
subpart F of part
64. Revised
64.603(a) so that it
also refers to
compliance with the
emergency calling
requirements
prescribed in part
9, subpart E of this
chapter.
64.604(a)(4).................. Emergency call Moved to 9.14(a);
handling Section 64.604(a)(4)
requirements for and (d) revised to
TTY-based TRS contain cross-
providers. reference to
9.14(a).
64.605........................ Emergency calling Moved to 9.14(b) and
requirements. (c); section 64.605
removed and
reserved.
64.3000....................... Definitions...... Moved to 9.3 and
removed from Part 64
as subpart AA.
(Universal Emergency
Telephone Number) is
removed and
reserved.
Definition of the
following terms
added to 9.3 (and
removed from Part 64
as subpart AA is
removed and
reserved):
911 calls.
Appropriate local
emergency authority.
Public safety
answering point
(PSAP) (The version
in 9.3 is revised
slightly for
consistency with the
version from 20.3 and
for clarity;
``facility'' changed
to ``answering
point.'').
Statewide default
answering point.
64.3001....................... Obligation to Moved to 9.4 and
transmit 911 removed from Part 64
calls. as subpart AA
(Universal Emergency
Telephone Number) is
removed and
reserved.
64.3002....................... Transition to 911 Moved to 9.5 and
as the universal removed from Part 64
emergency as subpart AA
telephone number. (Universal Emergency
Telephone Number) is
removed and
reserved.
[[Page 54206]]
64.3003....................... Obligation for Moved to 9.6 and
providing a removed from Part 64
permissive as subpart AA
dialing period. (Universal Emergency
Telephone Number) is
removed and
reserved.
64.3004....................... Obligation for Moved to 9.7 and
providing an removed from Part 64
intercept as subpart AA
message. (Universal Emergency
Telephone Number) is
removed and
reserved.
------------------------------------------------------------------------
VII. Ordering Clauses
172. Accordingly, it is ordered, pursuant to sections 1, 4(i),
4(j), 4(o), 201(b), 251(e), 301, 303(b), 303(r), 307, 309, and 316 of
the Communications Act of 1934, as amended, 47 U.S.C. 151, 154(i),
154(j), 154(o), 201(b), 251(e), 301, 303(b), 303(r), 307, 309, 316 and
pursuant to Kari's Law Act of 2017, Public Law 115-127, 47 U.S.C. 623
and 623 note, Section 506 of the Repack Airwaves Yielding Better Access
for Users of Modern Services Act of 2018 (RAY BAUM'S Act), Public Law
115-141, 47 U.S.C. 615 note, Section 106 of the Twenty-First Century
Communications and Video Accessibility Act of 2010, Public Law 111-260,
47 U.S.C. 615c, Section 101 of the New and Emerging Technologies 911
Improvement Act of 2008, Public Law 110-283, 47 U.S.C. 615a-1, Middle
Class Tax Relief and Job Creation Act of 2012, Public Law 112-96, 47
U.S.C. 1471, and the Wireless Communications and Public Safety Act of
1999, Public Law 106-81, 47 U.S.C. 615 note, 615, 615a, 615b, that this
Notice of Proposed Rulemaking is hereby adopted.
173. It is further ordered that the Commission's Consumer and
Governmental Affairs Bureau, Reference Information Center, shall send a
copy of this Notice of Proposed Rulemaking, including the Initial
Regulatory Flexibility Analysis, to the Chief Counsel for Advocacy of
the Small Business Administration.
List of Subjects in 47 CFR Parts 9, 12, 20, 25, 64
Communications, Communications common carriers, Communications
equipment, Reporting and recordkeeping requirements, Security measures,
Satellites, Securities, Telecommunications, Telephone.
Federal Communications Commission.
Marlene Dortch,
Secretary, Office of the Secretary.
Proposed Rules
For the reasons discussed in the preamble, the Federal
Communications Commission proposes to amend 47 CFR parts 9, 12, 20, 25,
and 64 as follows:
0
1. Part 9 is revised to read as follows:
PART 9--911 REQUIREMENTS
Sec.
Subpart A--Purpose and Definitions
9.1 Purpose
9.2 Reserved
9.3 Definitions
Subpart B--Telecommunications Carriers
9.4 Obligation to transmit 911 calls
9.5 Transition to 911 as the universal emergency telephone number
9.6 Obligation for providing a permissive dialing period
9.7 Obligation for providing an intercept message
9.8 Obligation to convey dispatchable location
Subpart C--Commercial Mobile Radio Service
9.9 Definitions
9.10 911 Service Requirements
Subpart D--Interconnected Voice over internet Protocol Services and 911
VoIP Services
9.11 E911 Service
9.12 Access to 911 and E911 service capabilities
Subpart E--Telecommunications Relay Services for Persons With
Disabilities
9.13 Jurisdiction
9.14 Emergency Calling Requirements
Subpart F--Multi Line Telephone Systems
9.15 Applicability
9.16 General obligations--direct 911 dialing, notification and
dispatchable location
9.17 Enforcement, compliance date, State law
Subpart G--Mobile-Satellite Service
9.18 Emergency Call Center
Subpart H--Resiliency, redundancy and reliability of 911 communications
9.19 Reliability of covered 911 service providers
9.20 Backup power obligations
Authority: 47 U.S.C. 151-154, 152(a), 155(c), 157, 160, 201,
202, 208, 210, 214, 218, 219, 222, 225, 251(e), 255, 301, 302, 303,
307, 308, 309, 310, 316, 319, 332, 403, 405, 605, 610, 615, 615
note, 615a, 615b, 615c, 615a-1, 616, 620, 621, 623, 623 note, 721,
and 1471, unless otherwise noted.
Sec. 9.1 Purpose
The purpose of this part is to set forth the 911 and E911 service
requirements and conditions applicable to telecommunications carriers
(subpart B); commercial mobile radio service (CMRS) providers (subpart
C); interconnected Voice over internet Protocol (VoIP) providers
(subpart D); providers of telecommunications relay services (TRS) for
persons with disabilities (subpart E); multi-line telephone systems
(MLTS) (subpart F); and Mobile-Satellite Service (MSS) providers
(subpart G). The rules in this part also include requirements to help
ensure the resiliency, redundancy, and reliability of communications
systems, particularly 911 and E911 networks and/or systems (subpart H).
Sec. 9.2 [ Reserved]
Sec. 9.3 Definitions.
Terms with definitions including the ``(RR)'' designation are
defined in the same way in Sec. 2.1 of this chapter and in the Radio
Regulations of the International Telecommunication Union.
911 calls. Any call initiated by an end user by dialing 911 for the
purpose of accessing an emergency service provider. For wireless
carriers, all 911 calls include those they are required to transmit
pursuant to subpart C of this part.
911 VoIP Service. A 911 VoIP service is a service that:
(1) Enables real-time, two-way voice communications;
(2) Requires a broadband connection from the user's location;
(3) Requires internet protocol-compatible customer premises
equipment (CPE); and
(4) Permits users generally to initiate a 911 call.
Appropriate local emergency authority. An emergency answering point
that has not been officially designated as a Public Safety Answering
Point (PSAP), but has the capability of receiving 911 calls and either
dispatching emergency services personnel or, if necessary, relaying the
call to another emergency service provider. An appropriate local
emergency authority may include, but is not limited to, an existing
local law enforcement authority, such as the police, county sheriff,
local emergency medical services provider, or fire department.
[[Page 54207]]
Automatic Location Information (ALI). Information transmitted while
providing E911 service that permits emergency service providers to
identify the geographic location of the calling party.
Automatic Number Identification (ANI). For 911 systems, the
Automatic Number Identification (ANI) identifies the calling party and
may be used as the callback number.
Commercial mobile radio service (CMRS). A mobile service that is:
(1)(i) Provided for profit, i.e., with the intent of receiving
compensation or monetary gain;
(ii) An interconnected service; and
(iii) Available to the public, or to such classes of eligible users
as to be effectively available to a substantial portion of the public;
or
(2) The functional equivalent of such a mobile service described in
paragraph (1) of this definition.
(3) A variety of factors may be evaluated to make a determination
whether the mobile service in question is the functional equivalent of
a commercial mobile radio service, including: Consumer demand for the
service to determine whether the service is closely substitutable for a
commercial mobile radio service; whether changes in price for the
service under examination, or for the comparable commercial mobile
radio service, would prompt customers to change from one service to the
other; and market research information identifying the targeted market
for the service under review.
(4) Unlicensed radio frequency devices under part 15 of this
chapter are excluded from this definition of Commercial mobile radio
service.
Common carrier or carrier. Any common carrier engaged in interstate
Communication by wire or radio as defined in section 3(h) of the
Communications Act of 1934, as amended (the Act), and any common
carrier engaged in intrastate communication by wire or radio,
notwithstanding sections 2(b) and 221(b) of the Act.
Communications assistant (CA). A person who transliterates or
interprets conversation between two or more end users of TRS. CA
supersedes the term ``TDD operator.''
Configured. The settings or configurations for a particular MLTS
installation have been implemented so that the MLTS is fully capable
when installed of dialing 911 directly and providing notification as
required under the statute and rules. This does not preclude the
inclusion of additional dialing patterns to reach 911. However, if the
system is configured with these additional dialing patterns, they must
be in addition to the default direct dialing pattern.
Designated PSAP. The Public Safety Answering Point (PSAP)
designated by the local or state entity that has the authority and
responsibility to designate the PSAP to receive wireless 911 calls.
Dispatchable location. A location delivered to the PSAP with a 911
call that consists of the street address of the calling party, plus
additional information such as suite, apartment or similar information
necessary to adequately identify the location of the calling party.
Earth station. A station located either on the Earth's surface or
within the major portion of the Earth's atmosphere intended for
communication:
(1) With one or more space stations; or
(2) With one or more stations of the same kind by means of one or
more reflecting satellites or other objects in space. (RR)
Emergency Call Center. A facility that subscribers of satellite
commercial mobile radio services call when in need of emergency
assistance by dialing ``911'' on their mobile earth station terminals.
Feeder link. A radio link from a fixed earth station at a given
location to a space station, or vice versa, conveying information for a
space radiocommunication service other than the Fixed-Satellite
Service. The given location may be at a specified fixed point or at any
fixed point within specified areas. (RR)
Fixed-Satellite Service (FSS). A radiocommunication service between
earth stations at given positions, when one or more satellites are
used; the given position may be a specified fixed point or any fixed
point within specified areas; in some cases this service includes
satellite-to-satellite links, which may also be operated in the inter-
satellite service; the Fixed-Satellite Service may also include feeder
links of other space radiocommunication services. (RR)
Handset-based location technology. A method of providing the
location of wireless 911 callers that requires the use of special
location-determining hardware and/or software in a portable or mobile
phone. Handset-based location technology may also employ additional
location-determining hardware and/or software in the CMRS network and/
or another fixed infrastructure.
IP Relay access technology. Any equipment, software, or other
technology issued, leased, or provided by an internet-based TRS
provider that can be used to make and receive an IP Relay call.
iTRS access technology. Any equipment, software, or other
technology issued, leased, or provided by an internet-based TRS
provider that can be used to make and receive an internet-based TRS
call.
Improvement to the hardware or software of the system. An
improvement to the hardware or software of the MLTS, including upgrades
to the core systems of the MLTS, as well as substantial upgrades to the
software and any software upgrades requiring a significant purchase.
Interconnected VoIP service. An interconnected Voice over internet
protocol (VoIP) service is a service that:
(1) Enables real-time, two-way voice communications;
(2) Requires a broadband connection from the user's location;
(3) Requires internet protocol-compatible customer premises
equipment (CPE); and
(4) Permits users generally to receive calls that originate on the
public switched telephone network and to terminate calls to the public
switched telephone network.
Internet-based TRS (iTRS). A telecommunications relay service (TRS)
in which an individual with a hearing or a speech disability connects
to a TRS communications assistant using an internet Protocol-enabled
device via the internet, rather than the public switched telephone
network. Except as authorized or required by the Commission, internet-
based TRS does not include the use of a text telephone (TTY) or RTT
over an interconnected voice over internet Protocol service.
Internet Protocol Relay Service (IP Relay). A telecommunications
relay service that permits an individual with a hearing or a speech
disability to communicate in text using an internet Protocol-enabled
device via the internet, rather than using a text telephone (TTY) and
the public switched telephone network.
Location-capable handsets. Portable or mobile phones that contain
special location-determining hardware and/or software, which is used by
a licensee to locate 911 calls.
MLTS Notification. An MLTS feature that can send notice to a
central location at the facility where the system is installed or to
another person or organization regardless of location. Examples of
notification include screen pops with audible alarms for security desk
computers using a client application, text messages for smartphones,
and email for administrators. Notification shall
[[Page 54208]]
include, at a minimum, the following information:
(1) The fact that a 911 call has been made,
(2) A valid callback number, and
(3) The information about the caller's location that the MLTS
conveys to the public safety answering point (PSAP) with the call to
911.
Mobile Earth Station. An earth station in the Mobile-Satellite
Service intended to be used while in motion or during halts at
unspecified points. (RR)
Mobile-Satellite Service (MSS). (1) A radiocommunication service:
(i) Between mobile earth stations and one or more space stations,
or between space stations used by this service; or
(ii) Between mobile earth stations, by means of one or more space
stations.
(2) This service may also include feeder links necessary for its
operation. (RR)
Mobile Service. A radio communication service carried on between
mobile stations or receivers and land stations, and by mobile stations
communicating among themselves, and includes:
(1) Both one-way and two-way radio communications services;
(2) A mobile service which provides a regularly interacting group
of base, mobile, portable, and associated control and relay stations
(whether licensed on an individual, cooperative, or multiple basis) for
private one-way or two-way land mobile radio communications by eligible
users over designated areas of operation; and
(3) Any service for which a license is required in a personal
communications service under part 24 of this chapter.
Network-based Location Technology. A method of providing the
location of wireless 911 callers that employs hardware and/or software
in the CMRS network and/or another fixed infrastructure, and does not
require the use of special location-determining hardware and/or
software in the caller's portable or mobile phone.
Multi-line telephone system or MLTS. A system comprised of common
control units, telephone sets, control hardware and software and
adjunct systems, including network and premises based systems, such as
Centrex and VoIP, as well as PBX, Hybrid, and Key Telephone Systems (as
classified by the Commission under part 68 of title 47, Code of Federal
Regulations), and includes systems owned or leased by governmental
agencies and non-profit entities, as well as for profit businesses.
Non-English language relay service. A telecommunications relay
service that allows persons with hearing or speech disabilities who use
languages other than English to communicate with voice telephone users
in a shared language other than English, through a CA who is fluent in
that language.
Person engaged in the business of installing an MLTS. A person that
configures the MLTS or performs other tasks involved in getting the
system ready to operate. These tasks may include, but are not limited
to, establishing the dialing pattern for emergency calls, determining
how calls will route to the Public Switched Telephone Network (PSTN),
and determining where the MLTS will interface with the PSTN. These
tasks are performed when the system is initially installed, but they
may also be performed on a more or less regular basis by the MLTS
operator as the communications needs of the enterprise change. The MLTS
installer may be the MLTS manager or a third party acting on behalf of
the manager.
Person engaged in the business of managing an MLTS. The entity that
is responsible for controlling and overseeing implementation of the
MLTS after installation. These responsibilities include determining how
lines should be distributed (including the adding or moving of lines),
assigning and reassigning telephone numbers, and ongoing network
configuration.
Person engaged in the business of manufacturing, importing,
selling, or leasing an MLTS. A person that manufactures, imports,
sells, or leases an MLTS.
Person engaged in the business of operating an MLTS. A person
responsible for the day-to-day operations of the MLTS.
Pre-configured. An MLTS that comes equipped with a default
configuration or setting that enables users to dial 911 directly as
required under the statute and rules, so long as the MLTS is installed
and operated properly. This does not preclude the inclusion of
additional dialing patterns to reach 911. However, if the system is
configured with these additional dialing patterns, they must be in
addition to the default direct dialing pattern.
Private Mobile Radio Service. A mobile service that meets neither
paragraph (1) nor (2) of the definition of commercial mobile radio
service in this section. A mobile service that does not meet the
paragraph (1) definition of commercial mobile radio service in this
section is presumed to be a private mobile radio service. Private
mobile radio service includes the following:
(1) Not-for-profit land mobile radio and paging services that serve
the licensee's internal communications needs as defined in part 90 of
this chapter. Shared-use, cost-sharing, or cooperative arrangements,
multiple licensed systems that use third party managers or users
combining resources to meet compatible needs for specialized internal
communications facilities in compliance with the safeguards of Sec.
90.179 of this chapter are presumptively private mobile radio services;
(2) Mobile radio service offered to restricted classes of eligible
users. This includes entities eligible in the Public Safety Radio Pool
and Radiolocation service.
(3) 220-222 MHz land mobile service and Automatic Vehicle
Monitoring systems (part 90 of this chapter) that do not offer
interconnected service or that are not-for-profit; and
(4) Personal Radio Services under part 95 of this chapter (General
Mobile Services, Radio Control Radio Services, and Citizens Band Radio
Services); Maritime Service Stations (excluding Public Coast stations)
(part 80 of this chapter); and Aviation Service Stations (part 87 of
this chapter).
Pseudo Automatic Number Identification (Pseudo-ANI). A number,
consisting of the same number of digits as ANI, that is not a North
American Numbering Plan telephone directory number and may be used in
place of an ANI to convey special meaning. The special meaning assigned
to the pseudo-ANI is determined by agreements, as necessary, between
the system originating the call, intermediate systems handling and
routing the call, and the destination system.
Public safety answering point or PSAP. An answering point that has
been designated to receive 911 calls and route them to emergency
services personnel.
Public Switched Network. Any common carrier switched network,
whether by wire or radio, including local exchange carriers,
interexchange carriers, and mobile service providers, that uses the
North American Numbering Plan in connection with the provision of
switched services.
Real-Time Text (RTT). Text communications that are transmitted over
internet Protocol (IP) networks immediately as they are created, e.g.,
on a character-by-character basis.
Registered internet-based TRS user. An individual that has
registered with a VRS or IP Relay provider as described in Sec.
64.611.
Registered Location. Before February 16, 2020: The most recent
information obtained by a provider of interconnected VoIP service or
telecommunications relay services (TRS), as applicable, that identifies
the physical location of an end user. On or
[[Page 54209]]
after February 16, 2020: The most recent information obtained by a
provider of interconnected VoIP service, 911 VoIP service, or
telecommunications relay services (TRS), as applicable, that identifies
the dispatchable location of an end user.
Space station. A station located on an object which is beyond, is
intended to go beyond, or has been beyond, the major portion of the
Earth's atmosphere. (RR)
Speech-to-speech relay service (STS). A telecommunications relay
service that allows individuals with speech disabilities to communicate
with voice telephone users through the use of specially trained CAs who
understand the speech patterns of persons with speech disabilities and
can repeat the words spoken by that person.
Statewide default answering point. An emergency answering point
designated by the State to receive 911 calls for either the entire
State or those portions of the State not otherwise served by a local
PSAP.
Station. A station equipped to engage in radio communication or
radio transmission of energy (47 U.S.C. 153(k)).
Telecommunications relay services (TRS). Telephone transmission
services that provide the ability for an individual who has a hearing
or speech disability to engage in communication by wire or radio with a
hearing individual in a manner that is functionally equivalent to the
ability of an individual who does not have a hearing or speech
disability to communicate using voice communication services by wire or
radio. Such term includes services that enable two-way communication
between an individual who uses a text telephone or other nonvoice
terminal device and an individual who does not use such a device,
speech-to-speech services, video relay services and non-English relay
services. TRS supersedes the terms ``dual party relay system,''
``message relay services,'' and ``TDD Relay.''
Text telephone (TTY). A machine that employs graphic communication
in the transmission of coded signals through a wire or radio
communication system. TTY supersedes the term ``TDD'' or
``telecommunications device for the deaf,'' and TT.
Video relay service (VRS). A telecommunications relay service that
allows people with hearing or speech disabilities who use sign language
to communicate with voice telephone users through video equipment. The
video link allows the CA to view and interpret the party's signed
conversation and relay the conversation back and forth with a voice
caller.
VRS access technology. Any equipment, software, or other technology
issued, leased, or provided by an internet-based TRS provider that can
be used to make and receive a VRS call.
Wireline E911 Network. A dedicated wireline network that:
(1) Is interconnected with but largely separate from the public
switched telephone network;
(2) Includes a selective router; and
(3) Is used to route emergency calls and related information to
PSAPs, designated statewide default answering points, appropriate local
emergency authorities or other emergency answering points.
Subpart B--Telecommunications Carriers
Sec. 9.4 Obligation to transmit 911 calls.
All telecommunications carriers shall transmit all 911 calls to a
PSAP, to a designated statewide default answering point, or to an
appropriate local emergency authority as set forth in Sec. 9.5.
Sec. 9.5 Transition to 911 as the universal emergency telephone
number.
As of December 11, 2001, except where 911 is already established as
the exclusive emergency number to reach a PSAP within a given
jurisdiction, telecommunications carriers shall comply with the
following transition periods:
(a) Where a PSAP has been designated, telecommunications carriers
shall complete all translation and routing necessary to deliver 911
calls to a PSAP no later than September 11, 2002.
(b) Where no PSAP has been designated, telecommunications carriers
shall complete all translation and routing necessary to deliver 911
calls to the statewide default answering point no later than September
11, 2002.
(c) Where neither a PSAP nor a statewide default answering point
has been designated, telecommunications carriers shall complete the
translation and routing necessary to deliver 911 calls to an
appropriate local emergency authority, within nine months of a request
by the State or locality.
(d) Where no PSAP nor statewide default answering point has been
designated, and no appropriate local emergency authority has been
selected by an authorized state or local entity, telecommunications
carriers shall identify an appropriate local emergency authority, based
on the exercise of reasonable judgment, and complete all translation
and routing necessary to deliver 911 calls to such appropriate local
emergency authority no later than September 11, 2002.
(e) Once a PSAP is designated for an area where none had existed as
of December 11, 2001, telecommunications carriers shall complete the
translation and routing necessary to deliver 911 calls to that PSAP
within nine months of that designation.
Sec. 9.6 Obligation for providing a permissive dialing period.
Upon completion of translation and routing of 911 calls to a PSAP,
a statewide default answering point, to an appropriate local emergency
authority, or, where no PSAP nor statewide default answering point has
been designated and no appropriate local emergency authority has been
selected by an authorized state or local entity, to an appropriate
local emergency authority, identified by a telecommunications carrier
based on the exercise of reasonable judgment, the telecommunications
carrier shall provide permissive dialing between 911 and any other
seven-or ten-digit emergency number or an abbreviated dialing code
other than 911 that the public has previously used to reach emergency
service providers until the appropriate State or local jurisdiction
determines to phase out the use of such seven-or ten-digit number
entirely and use 911 exclusively.
Sec. 9.7 Obligation for providing an intercept message.
Upon termination of permissive dialing, as provided under Sec.
9.6, telecommunications carriers shall provide a standard intercept
message announcement that interrupts calls placed to the emergency
service provider using either a seven-or ten-digit emergency number or
an abbreviated dialing code other than 911 and informs the caller of
the dialing code change.
Sec. 9.8 Obligation to convey dispatchable location.
All telecommunications carriers shall convey the dispatchable
location of the caller to the PSAP with 911 calls, except for wireless
carriers, which shall convey the location information required by
subpart C of this part.
Subpart C--Commercial Mobile Radio Service
Sec. 9.9 Definitions.
Interconnection or Interconnected. Direct or indirect connection
through automatic or manual means (by wire, microwave, or other
technologies such
[[Page 54210]]
as store and forward) to permit the transmission or reception of
messages or signals to or from points in the public switched network.
Interconnected Service. A service:
(1) That is interconnected with the public switched network, or
interconnected with the public switched network through an
interconnected service provider, that gives subscribers the capability
to communicate to or receive communication from all other users on the
public switched network; or
(2) For which a request for such interconnection is pending
pursuant to section 332(c)(1)(B) of the Communications Act, 47 U.S.C.
332(c)(1)(B). A mobile service offers interconnected service even if
the service allows subscribers to access the public switched network
only during specified hours of the day, or if the service provides
general access to points on the public switched network but also
restricts access in certain limited ways. Interconnected service does
not include any interface between a licensee's facilities and the
public switched network exclusively for a licensee's internal control
purposes.
Sec. 9.10 911 Service.
(a) Scope of section. Except as described in paragraph (r) of this
section, the following requirements are only applicable to CMRS
providers, excluding mobile satellite service (MSS) operators, to the
extent that they:
(1) Offer real-time, two way switched voice service that is
interconnected with the public switched network; and
(2) Use an in-network switching facility that enables the provider
to reuse frequencies and accomplish seamless hand-offs of subscriber
calls. These requirements are applicable to entities that offer voice
service to consumers by purchasing airtime or capacity at wholesale
rates from CMRS licensees.
(b) Basic 911 Service. CMRS providers subject to this section must
transmit all wireless 911 calls without respect to their call
validation process to a Public Safety Answering Point, or, where no
Public Safety Answering Point has been designated, to a designated
statewide default answering point or appropriate local emergency
authority pursuant to Sec. 9.4 of this chapter, provided that ``all
wireless 911 calls'' is defined as ``any call initiated by a wireless
user dialing 911 on a phone using a compliant radio frequency protocol
of the serving carrier.''
(c) Access to 911 services. CMRS providers subject to this section
must be capable of transmitting 911 calls from individuals with speech
or hearing disabilities through means other than mobile radio handsets,
e.g., through the use of Text Telephone Devices (TTY). CMRS providers
that provide voice communications over IP facilities are not required
to support 911 access via TTYs if they provide 911 access via real-time
text (RTT) communications, in accordance with 47 CFR part 67, except
that RTT support is not required to the extent that it is not
achievable for a particular manufacturer to support RTT on the
provider's network.
(d) Phase I enhanced 911 services. (1) As of April 1, 1998, or
within six months of a request by the designated Public Safety
Answering Point as set forth in paragraph (j) of this section,
whichever is later, licensees subject to this section must provide the
telephone number of the originator of a 911 call and the location of
the cell site or base station receiving a 911 call from any mobile
handset accessing their systems to the designated Public Safety
Answering Point through the use of ANI and Pseudo-ANI.
(2) When the directory number of the handset used to originate a
911 call is not available to the serving carrier, such carrier's
obligations under paragraph (d)(1) of this section extend only to
delivering 911 calls and available call party information, including
that prescribed in paragraph (l) of this section, to the designated
Public Safety Answering Point.
Note to paragraph (d): With respect to 911 calls accessing their
systems through the use of TTYs, licensees subject to this section
must comply with the requirements in paragraphs (d)(1) and (d)(2) of
this section, as to calls made using a digital wireless system, as
of October 1, 1998.
(e) Phase II enhanced 911 service. Licensees subject to this
section must provide to the designated Public Safety Answering Point
Phase II enhanced 911 service, i.e., the location of all 911 calls by
longitude and latitude in conformance with Phase II accuracy
requirements (see paragraph (h) of this section).
(f) Phase-in for network-based location technologies. Licensees
subject to this section who employ a network-based location technology
shall provide Phase II 911 enhanced service to at least 50 percent of
their coverage area or 50 percent of their population beginning October
1, 2001, or within 6 months of a PSAP request, whichever is later; and
to 100 percent of their coverage area or 100 percent of their
population within 18 months of such a request or by October 1, 2002,
whichever is later.
(g) Phase-in for handset-based location technologies. Licensees
subject to this section who employ a handset-based location technology
may phase in deployment of Phase II enhanced 911 service, subject to
the following requirements:
(1) Without respect to any PSAP request for deployment of Phase II
911 enhanced service, the licensee shall:
(i) Begin selling and activating location-capable handsets no later
than October 1, 2001;
(ii) Ensure that at least 25 percent of all new handsets activated
are location-capable no later than December 31, 2001;
(iii) Ensure that at least 50 percent of all new handsets activated
are location-capable no later than June 30, 2002; and
(iv) Ensure that 100 percent of all new digital handsets activated
are location-capable no later than December 31, 2002, and thereafter.
(v) By December 31, 2005, achieve 95 percent penetration of
location-capable handsets among its subscribers.
(vi) Licensees that meet the enhanced 911 compliance obligations
through GPS-enabled handsets and have commercial agreements with
resellers will not be required to include the resellers' handset counts
in their compliance percentages.
(2) Once a PSAP request is received, the licensee shall, in the
area served by the PSAP, within six months or by October 1, 2001,
whichever is later:
(i) Install any hardware and/or software in the CMRS network and/or
other fixed infrastructure, as needed, to enable the provision of Phase
II enhanced 911 service; and
(ii) Begin delivering Phase II enhanced 911 service to the PSAP.
(3) For all 911 calls from portable or mobile phones that do not
contain the hardware and/or software needed to enable the licensee to
provide Phase II enhanced 911 service, the licensee shall, after a PSAP
request is received, support, in the area served by the PSAP, Phase I
location for 911 calls or other available best practice method of
providing the location of the portable or mobile phone to the PSAP.
(4) Licensees employing handset-based location technologies shall
ensure that location-capable portable or mobile phones shall conform to
industry interoperability standards designed to enable the location of
such phones by multiple licensees.
(h) Phase II accuracy. Licensees subject to this section shall
comply with the following standards for Phase II location accuracy and
reliability, to be tested and measured either at the county or at the
PSAP service area geographic level, based on outdoor measurements only:
[[Page 54211]]
(1) Network-based technologies: (i) 100 meters for 67 percent of
calls, consistent with the following benchmarks:
(A) One year from January 18, 2011, carriers shall comply with this
standard in 60 percent of counties or PSAP service areas. These
counties or PSAP service areas must cover at least 70 percent of the
population covered by the carrier across its entire network. Compliance
will be measured on a per-county or per-PSAP basis using, at the
carrier's election, either
(1) Network-based accuracy data, or
(2) Blended reporting as provided in paragraph (h)(1)(iv) of this
section.
(B) Three years from January 18, 2011, carriers shall comply with
this standard in 70 percent of counties or PSAP service areas. These
counties or PSAP service areas must cover at least 80 percent of the
population covered by the carrier across its entire network. Compliance
will be measured on a per-county or per-PSAP basis using, at the
carrier's election, either
(1) Network-based accuracy data, or
(2) Blended reporting as provided in paragraph (h)(1)(iv) of this
section.
(C) Five years from January 18, 2011, carriers shall comply with
this standard in 100% of counties or PSAP service areas covered by the
carrier. Compliance will be measured on a per-county or per-PSAP basis,
using, at the carrier's election, either
(1) Network-based accuracy data,
(2) Blended reporting as provided in paragraph (h)(1)(iv) of this
section, or
(3) Handset-based accuracy data as provided in paragraph (h)(1)(v)
of this section.
(ii) 300 meters for 90 percent of calls, consistent with the
following benchmarks:
(A) Three years from January 18, 2011, carriers shall comply with
this standard in 60 percent of counties or PSAP service areas. These
counties or PSAP service areas must cover at least 70 percent of the
population covered by the carrier across its entire network. Compliance
will be measured on a per-county or per-PSAP basis using, at the
carrier's election, either
(1) Network-based accuracy data, or
(2) Blended reporting as provided in paragraph (h)(1)(iv) of this
section.
(B) Five years from January 18, 2011, carriers shall comply in 70
percent of counties or PSAP service areas. These counties or PSAP
service areas must cover at least 80 percent of the population covered
by the carrier across its entire network. Compliance will be measured
on a per-county or per-PSAP basis using, at the carrier's election,
either
(1) Network-based accuracy data, or
(2) Blended reporting as provided in paragraph (h)(1)(iv) of this
section.
(C) Eight years from January 18, 2011, carriers shall comply in 85
percent of counties or PSAP service areas. Compliance will be measured
on a per-county or per-PSAP basis using, at the carrier's election,
either
(1) Network-based accuracy data,
(2) Blended reporting as provided in paragraph (h)(1)(iv) of this
section, or
(3) Handset-based accuracy data as provided in paragraph (h)(1)(v)
of this section.
(iii) County-level or PSAP-level location accuracy standards for
network-based technologies will be applicable to those counties or PSAP
service areas, on an individual basis, in which a network-based carrier
has deployed Phase II in at least one cell site located within a
county's or PSAP service area's boundary. Compliance with the
requirements of paragraph (h)(1)(i) and paragraph (h)(1)(ii) of this
section shall be measured and reported independently.
(iv) Accuracy data from both network-based solutions and handset-
based solutions may be blended to measure compliance with the accuracy
requirements of paragraph (h)(1)(i)(A) through (C) and paragraph
(h)(1)(ii)(A) through (C) of this section. Such blending shall be based
on weighting accuracy data in the ratio of assisted GPS (``A-GPS'')
handsets to non-A-GPS handsets in the carrier's subscriber base. The
weighting ratio shall be applied to the accuracy data from each
solution and measured against the network-based accuracy requirements
of paragraph (h)(1) of this section.
(v) A carrier may rely solely on handset-based accuracy data in any
county or PSAP service area if at least 85 percent of its subscribers,
network-wide, use A-GPS handsets, or if it offers A-GPS handsets to
subscribers in that county or PSAP service area at no cost to the
subscriber.
(vi) A carrier may exclude from compliance particular counties, or
portions of counties, where triangulation is not technically possible,
such as locations where at least three cell sites are not sufficiently
visible to a handset. Carriers must file a list of the specific
counties or portions of counties where they are using this exclusion
within 90 days following approval from the Office of Management and
Budget for the related information collection. This list must be
submitted electronically into PS Docket No. 07-114, and copies must be
sent to the National Emergency Number Association, the Association of
Public-Safety Communications Officials-International, and the National
Association of State 9-1-1 Administrators. Further, carriers must
submit in the same manner any changes to their exclusion lists within
thirty days of discovering such changes. This exclusion will sunset on
[8 years after effective date].
(2) Handset-based technologies: (i) Two years from January 18,
2011, 50 meters for 67 percent of calls, and 150 meters for 80 percent
of calls, on a per-county or per-PSAP basis. However, a carrier may
exclude up to 15 percent of counties or PSAP service areas from the 150
meter requirement based upon heavy forestation that limits handset-
based technology accuracy in those counties or PSAP service areas.
(ii) Eight years from January 18, 2011, 50 meters for 67 percent of
calls, and 150 meters for 90 percent of calls, on a per-county or per-
PSAP basis. However, a carrier may exclude up to 15 percent of counties
or PSAP service areas from the 150 meter requirement based upon heavy
forestation that limits handset-based technology accuracy in those
counties or PSAP service areas.
(iii) Carriers must file a list of the specific counties or PSAP
service areas where they are using the exclusion for heavy forestation
within 90 days following approval from the Office of Management and
Budget for the related information collection. This list must be
submitted electronically into PS Docket No. 07-114, and copies must be
sent to the National Emergency Number Association, the Association of
Public-Safety Communications Officials-International, and the National
Association of State 9-1-1 Administrators. Further, carriers must
submit in the same manner any changes to their exclusion lists within
thirty days of discovering such changes.
(iv) Providers of new CMRS networks that meet the definition of
covered CMRS providers under paragraph (a) of this section must comply
with the requirements of paragraphs (h)(2)(i) through (iii) of this
section. For this purpose, a ``new CMRS network'' is a CMRS network
that is newly deployed subsequent to the effective date of the Third
Report and Order in PS Docket No. 07-114 and that is not an expansion
or upgrade of an existing CMRS network.
(3) Latency (Time to First Fix). For purposes of measuring
compliance with the location accuracy standards of this paragraph, a
call will be deemed to satisfy the standard only if it provides the
specified degree of location accuracy within a maximum latency period
of 30 seconds, as measured from the time the
[[Page 54212]]
user initiates the 911 call to the time the location fix appears at the
location information center: Provided, however, that the CMRS provider
may elect not to include for purposes of measuring compliance therewith
any calls lasting less than 30 seconds.
(i) Indoor location accuracy for 911 and testing requirements--(1)
Definitions: The terms as used in this section have the following
meaning:
(i) Dispatchable location: A location delivered to the PSAP by the
CMRS provider with a 911 call that consists of the street address of
the calling party, plus additional information such as suite, apartment
or similar information necessary to adequately identify the location of
the calling party. The street address of the calling party must be
validated and, to the extent possible, corroborated against other
location information prior to delivery of dispatchable location
information by the CMRS provider to the PSAP.
(ii) Media Access Control (MAC) Address. A location identifier of a
Wi-Fi access point.
(iii) National Emergency Address Database (NEAD). A database that
uses MAC address information to identify a dispatchable location for
nearby wireless devices within the CMRS provider's coverage footprint.
(iv) Nationwide CMRS provider: A CMRS provider whose service
extends to a majority of the population and land area of the United
States.
(v) Non-nationwide CMRS provider: Any CMRS provider other than a
nationwide CMRS provider.
(vi) Test Cities. The six cities (San Francisco, Chicago, Atlanta,
Denver/Front Range, Philadelphia, and Manhattan Borough) and
surrounding geographic areas that correspond to the six geographic
regions specified by the February 7, 2014 ATIS Document,
``Considerations in Selecting Indoor Test Regions,'' for testing of
indoor location technologies.
(2) Indoor location accuracy standards: CMRS providers subject to
this section shall meet the following requirements:
(i) Horizontal location. (A) Nationwide CMRS providers shall
provide; dispatchable location, or; x/y location within 50 meters, for
the following percentages of wireless 911 calls within the following
timeframes, measured from the effective date of the adoption of this
rule:
(1) Within 2 years: 40 percent of all wireless 911 calls.
(2) Within 3 years: 50 percent of all wireless 911 calls.
(3) Within 5 years: 70 percent of all wireless 911 calls.
(4) Within 6 years: 80 percent of all wireless 911 calls.
(B) Non-nationwide CMRS providers shall provide; dispatchable
location or; x/y location within 50 meters, for the following
percentages of wireless 911 calls within the following timeframes,
measured from the effective date of the adoption of this rule:
(1) Within 2 years: 40 percent of all wireless 911 calls.
(2) Within 3 years: 50 percent of all wireless 911 calls.
(3) Within 5 years or within six months of deploying a
commercially-operating VoLTE platform in their network, whichever is
later: 70 percent of all wireless 911 calls.
(4) Within 6 years or within one year of deploying a commercially-
operating VoLTE platform in their network, whichever is later: 80
percent of all wireless 911 calls.
(ii) Vertical location. CMRS providers shall provide vertical
location information with wireless 911 calls as described in this
section within the following timeframes measured from the effective
date of the adoption of this rule:
(A) Within 3 years: All CMRS providers shall make uncompensated
barometric data available to PSAPs with respect to any 911 call placed
from any handset that has the capability to deliver barometric sensor
information.
(B) Within 3 years: Nationwide CMRS providers shall develop one or
more z-axis accuracy metrics validated by an independently administered
and transparent test bed process as described in paragraph (i)(3)(i) of
this section, and shall submit the proposed metric or metrics,
supported by a report of the results of such development and testing,
to the Commission for approval.
(C) Within 6 years: In each of the top 25 CMAs, nationwide CMRS
providers shall deploy either;) dispatchable location, or ; z-axis
technology in compliance with any z-axis accuracy metric that has been
approved by the Commission,
(1) In each CMA where dispatchable location is used: Nationwide
CMRS providers must ensure that the NEAD is populated with a sufficient
number of total dispatchable location reference points to equal 25
percent of the CMA population.
(2) In each CMA where z-axis technology is used: Nationwide CMRS
providers must deploy z-axis technology to cover 80 percent of the CMA
population.
(D) Within 8 years: In each of the top 50 CMAs, nationwide CMRS
providers shall deploy either
(1) Dispatchable location or;
(2) Such z-axis technology in compliance with any z-axis accuracy
metric that has been approved by the Commission.
(E) Non-nationwide CMRS providers that serve any of the top 25 or
50 CMAs will have an additional year to meet each of the benchmarks in
paragraphs (i)(2)(ii)(C) and (D) of this section.
(iii) Compliance. Within 60 days after each benchmark date
specified in paragraphs (i)(2)(i) and (ii) of this section, CMRS
providers must certify that they are in compliance with the location
accuracy requirements applicable to them as of that date. CMRS
providers shall be presumed to be in compliance by certifying that they
have complied with the test bed and live call data provisions described
in paragraph (i)(3) of this section.
(A) All CMRS providers must certify that the indoor location
technology (or technologies) used in their networks are deployed
consistently with the manner in which they have been tested in the test
bed. A CMRS provider must update certification whenever it introduces a
new technology into its network or otherwise modifies its network, such
that previous performance in the test bed would no longer be consistent
with the technology's modified deployment.
(B) CMRS providers that provide quarterly reports of live call data
in one or more of the six test cities specified in paragraph (i)(1)(vi)
of this section must certify that their deployment of location
technologies throughout their coverage area is consistent with their
deployment of the same technologies in the areas that are used for live
call data reporting.
(C) Non-nationwide CMRS providers that do not provide service or
report quarterly live call data in any of the six test cities specified
in paragraph (i)(1)(vi) of this section must certify that they have
verified based on their own live call data that they are in compliance
with the requirements of paragraphs (i)(2)(i)(B) and (ii) of this
section.
(iv) Enforcement. PSAPs may seek Commission enforcement within
their geographic service area of the requirements of paragraphs
(i)(2)(i) and (ii) of this section, but only so long as they have
implemented policies that are designed to obtain all location
information made available by CMRS providers when initiating and
delivering 911 calls to the PSAP. Prior to seeking Commission
enforcement, a PSAP must provide the CMRS provider with [30] days
written notice, and the CMRS provider shall have an opportunity to
address the issue informally. If the issue has not been addressed to
the PSAP's
[[Page 54213]]
satisfaction within 90 days, the PSAP may seek enforcement relief.
(3) Indoor location accuracy testing and live call data reporting--
(i) Indoor location accuracy test bed. CMRS providers must establish
the test bed described in this section within 12 months of the
effective date of this rule. CMRS providers must validate technologies
intended for indoor location, including dispatchable location
technologies and technologies that deliver horizontal and/or vertical
coordinates, through an independently administered and transparent test
bed process, in order for such technologies to be presumed to comply
with the location accuracy requirements of this paragraph. The test bed
shall meet the following minimal requirements in order for the test
results to be considered valid for compliance purposes:
(A) Include testing in representative indoor environments,
including dense urban, urban, suburban and rural morphologies;
(B) Test for performance attributes including location accuracy
(ground truth as measured in the test bed), latency (Time to First
Fix), and reliability (yield); and
(C) Each test call (or equivalent) shall be independent from prior
calls and accuracy will be based on the first location delivered after
the call is initiated.
(D) In complying with paragraph (i)(3)(i)(B) of this section, CMRS
providers shall measure yield separately for each individual indoor
location morphology (dense urban, urban, suburban, and rural) in the
test bed, and based upon the specific type of location technology that
the provider intends to deploy in real-world areas represented by that
particular morphology. CMRS providers must base the yield percentage
based on the number of test calls that deliver a location in compliance
with any applicable indoor location accuracy requirements, compared to
the total number of calls that successfully connect to the testing
network. CMRS providers may exclude test calls that are dropped or
otherwise disconnected in 10 seconds or less from calculation of the
yield percentage (both the denominator and numerator).
(ii) Collection and reporting of aggregate live 911 call location
data. CMRS providers providing service in any of the Test Cities or
portions thereof must collect and report aggregate data on the location
technologies used for live 911 calls in those areas.
(A) CMRS providers subject to this section shall identify and
collect information regarding the location technology or technologies
used for each 911 call in the reporting area during the calling period.
(B) CMRS providers subject to this section shall report Test City
call location data on a quarterly basis to the Commission, the National
Emergency Number Association, the Association of Public Safety
Communications Officials, and the National Association of State 911
Administrators, with the first report due 18 months from the effective
date of rules adopted in this proceeding.
(C) CMRS providers subject to this section shall also provide
quarterly live call data on a more granular basis that allows
evaluation of the performance of individual location technologies
within different morphologies (e.g., dense urban, urban, suburban,
rural). To the extent available, live call data for all CMRS providers
shall delineate based on a per technology basis accumulated and so
identified for:
(1) Each of the ATIS ESIF morphologies;
(2) On a reasonable community level basis; or
(3) By census block. This more granular data will be used for
evaluation and not for compliance purposes.
(D) Non-nationwide CMRS providers that operate in a single Test
City need only report live 911 call data from that city or portion
thereof that they cover. Non-nationwide CMRS providers that operate in
more than one Test City must report live 911 call data only in half of
the regions (as selected by the provider). In the event a non-
nationwide CMRS provider begins coverage in a Test City it previously
did not serve, it must update its certification pursuant to paragraph
(i)(2)(iii)(C) of this section to reflect this change in its network
and begin reporting data from the appropriate areas. All non-nationwide
CMRS providers must report their Test City live call data every 6
months, beginning 18 months from the effective date of rules adopted in
this proceeding.
(E) Non-nationwide CMRS providers that do not provide coverage in
any of the Test Cities can satisfy the requirement of paragraph
(i)(3)(ii) of this section by collecting and reporting data based on
the largest county within its footprint. In addition, where a non-
nationwide CMRS provider serves more than one of the ATIS ESIF
morphologies, it must include a sufficient number of representative
counties to cover each morphology.
(iii) Data retention. CMRS providers shall retain testing and live
call data gathered pursuant to this section for a period of 2 years.
(4) Submission of plans and reports. The following reporting and
certification obligations apply to all CMRS providers subject to this
section, which may be filed electronically in PS Docket No. 07-114:
(i) Initial implementation plan. No later than 18 months from the
effective date of the adoption of this rule, nationwide CMRS providers
shall report to the Commission on their plans for meeting the indoor
location accuracy requirements of paragraph (i)(2) of this section.
Non-nationwide CMRS providers will have an additional 6 months to
submit their implementation plans.
(ii) Progress reports. No later than 18 months from the effective
date of the adoption of this rule, each CMRS provider shall file a
progress report on implementation of indoor location accuracy
requirements. Non-nationwide CMRS providers will have an additional 6
months to submit their progress reports. All CMRS providers shall
provide an additional progress report no later than 36 months from the
effective date of the adoption of this rule. The 36-month reports shall
indicate what progress the provider has made consistent with its
implementation plan, and the nationwide CMRS providers shall include an
assessment of their deployment of dispatchable location solutions. For
any CMRS provider participating in the development of the NEAD
database, this progress report must include detail as to the
implementation of the NEAD database described in paragraphs (i)(4)(iii)
and (iv) of this section.
(iii) NEAD privacy and security plan. Prior to activation of the
NEAD but no later than 18 months from the effective date of the
adoption of this rule, the nationwide CMRS providers shall file with
the Commission and request approval for a security and privacy plan for
the administration and operation of the NEAD. The plan must include the
identity of an administrator for the NEAD, who will serve as a point of
contact for the Commission and shall be accountable for the
effectiveness of the security, privacy, and resiliency measures.
(iv) NEAD use certification. Prior to use of the NEAD or any
information contained therein to meet such requirements, CMRS providers
must certify that they will not use the NEAD or associated data for any
non-911 purpose, except as otherwise required by law.
(j) Confidence and uncertainty data. (1) Except as provided in
paragraphs (j)(2)-(3) of this section, CMRS providers subject to this
section shall provide for all wireless 911 calls, whether from outdoor
or indoor
[[Page 54214]]
locations, x- and y-axis (latitude, longitude) confidence and
uncertainty information (C/U data) on a per-call basis upon the request
of a PSAP. The data shall specify
(i) The caller's location with a uniform confidence level of 90
percent, and;
(ii) The radius in meters from the reported position at that same
confidence level. All entities responsible for transporting confidence
and uncertainty between CMRS providers and PSAPs, including LECs,
CLECs, owners of E911 networks, and emergency service providers, must
enable the transmission of confidence and uncertainty data provided by
CMRS providers to the requesting PSAP.
(2) Upon meeting the 3-year timeframe pursuant to paragraph
(i)(2)(i) of this section, CMRS providers shall provide with wireless
911 calls that have a dispatchable location the C/U data for the x- and
y-axis (latitude, longitude) required under paragraph (j)(1) of this
section.
(3) Upon meeting the 6-year timeframe pursuant to paragraph
(i)(2)(i) of this section, CMRS providers shall provide with wireless
911 calls that have a dispatchable location the C/U data for the x- and
y-axis (latitude, longitude) required under paragraph (j)(1) of this
section.
(k) Provision of live 911 call data for PSAPs. Notwithstanding
other 911 call data collection and reporting requirements in paragraph
(i) of this section, CMRS providers must record information on all live
911 calls, including, but not limited to, the positioning source method
used to provide a location fix associated with the call. CMRS providers
must also record the confidence and uncertainty data that they provide
pursuant to paragraphs (j)(1) through (3) of this section. This
information must be made available to PSAPs upon request, and shall be
retained for a period of two years.
(l) Reports on Phase II plans. Licensees subject to this section
shall report to the Commission their plans for implementing Phase II
enhanced 911 service, including the location-determination technology
they plan to employ and the procedure they intend to use to verify
conformance with the Phase II accuracy requirements by November 9,
2000. Licensees are required to update these plans within thirty days
of the adoption of any change. These reports and updates may be filed
electronically in a manner to be designated by the Commission.
(m) Conditions for enhanced 911 services--(1) Generally. The
requirements set forth in paragraphs (d) through (h)(2) and in
paragraph (j) of this section shall be applicable only to the extent
that the administrator of the applicable designated PSAP has requested
the services required under those paragraphs and such PSAP is capable
of receiving and using the requested data elements and has a mechanism
for recovering the PSAP's costs associated with them.
(2) Commencement of six-month period. (i) Except as provided in
paragraph (ii) of this section, for purposes of commencing the six-
month period for carrier implementation specified in paragraphs (d),
(f) and (g) of this section, a PSAP will be deemed capable of receiving
and using the data elements associated with the service requested, if
it can demonstrate that it has:
(A) Ordered the necessary equipment and has commitments from
suppliers to have it installed and operational within such six-month
period; and
(B) Made a timely request to the appropriate local exchange carrier
for the necessary trunking, upgrades, and other facilities.
(ii) For purposes of commencing the six-month period for carrier
implementation specified in paragraphs (f) and (g) of this section, a
PSAP that is Phase I-capable using a Non-Call Path Associated Signaling
(NCAS) technology will be deemed capable of receiving and using the
data elements associated with Phase II service if it can demonstrate
that it has made a timely request to the appropriate local exchange
carrier for the ALI database upgrade necessary to receive the Phase II
information.
(3) Tolling of six-month period. Where a wireless carrier has
served a written request for documentation on the PSAP within 15 days
of receiving the PSAP's request for Phase I or Phase II enhanced 911
service, and the PSAP fails to respond to such request within 15 days
of such service, the six-month period for carrier implementation
specified in paragraphs (d), (f), and (g) of this section will be
tolled until the PSAP provides the carrier with such documentation.
(4) Carrier certification regarding PSAP readiness issues. At the
end of the six-month period for carrier implementation specified in
paragraphs (d), (f), and (g) of this section, a wireless carrier that
believes that the PSAP is not capable of receiving and using the data
elements associated with the service requested may file a certification
with the Commission. Upon filing and service of such certification, the
carrier may suspend further implementation efforts, except as provided
in paragraph (m)(4)(x) of this section.
(i) As a prerequisite to filing such certification, no later than
21 days prior to such filing, the wireless carrier must notify the
affected PSAP, in writing, of its intent to file such certification.
Any response that the carrier receives from the PSAP must be included
with the carrier's certification filing.
(ii) The certification process shall be subject to the procedural
requirements set forth in sections 1.45 and 1.47 of this chapter.
(iii) The certification must be in the form of an affidavit signed
by a director or officer of the carrier, documenting:
(A) The basis for the carrier's determination that the PSAP will
not be ready;
(B) Each of the specific steps the carrier has taken to provide the
E911 service requested;
(C) The reasons why further implementation efforts cannot be made
until the PSAP becomes capable of receiving and using the data elements
associated with the E911 service requested; and
(D) The specific steps that remain to be completed by the wireless
carrier and, to the extent known, the PSAP or other parties before the
carrier can provide the E911 service requested.
(iv) All affidavits must be correct. The carrier must ensure that
its affidavit is correct, and the certifying director or officer has
the duty to personally determine that the affidavit is correct.
(v) A carrier may not engage in a practice of filing inadequate or
incomplete certifications for the purpose of delaying its
responsibilities.
(vi) To be eligible to make a certification, the wireless carrier
must have completed all necessary steps toward E911 implementation that
are not dependent on PSAP readiness.
(vii) A copy of the certification must be served on the PSAP in
accordance with Sec. 1.47 of this chapter. The PSAP may challenge in
writing the accuracy of the carrier's certification and shall serve a
copy of such challenge on the carrier. See Sec. Sec. 1.45 and 1.47 and
Sec. Sec. 1.720 through 1.740 of this chapter.
(viii) If a wireless carrier's certification is facially
inadequate, the six-month implementation period specified in paragraphs
(d), (f) and (g) of this section will not be suspended as provided for
in paragraph (m)(4) of this section.
(ix) If a wireless carrier's certification is inaccurate, the
wireless carrier will be liable for noncompliance as if the
certification had not been filed.
(x) A carrier that files a certification under paragraph (m)(4) of
this section
[[Page 54215]]
shall have 90 days from receipt of the PSAP's written notice that it is
capable of receiving and using the data elements associated with the
service requested to provide such service in accordance with the
requirements of paragraphs (d) through (h) of this section.
(5) Modification of deadlines by agreement. Nothing in this section
shall prevent Public Safety Answering Points and carriers from
establishing, by mutual consent, deadlines different from those imposed
for carrier and PSAP compliance in paragraphs (d), (f), and (g)(2) of
this section.
(n) Dispatch service. A service provider covered by this section
who offers dispatch service to customers may meet the requirements of
this section with respect to customers who use dispatch service either
by complying with the requirements set forth in paragraphs (b) through
(e) of this section, or by routing the customer's emergency calls
through a dispatcher. If the service provider chooses the latter
alternative, it must make every reasonable effort to explicitly notify
its current and potential dispatch customers and their users that they
are not able to directly reach a PSAP by calling 911 and that, in the
event of an emergency, the dispatcher should be contacted.
(o) Non-service-initialized handsets. (1) Licensees subject to this
section that donate a non-service-initialized handset for purposes of
providing access to 911 services are required to:
(i) Program each handset with 911 plus the decimal representation
of the seven least significant digits of the Electronic Serial Number,
International Mobile Equipment Identifier, or any other identifier
unique to that handset;
(ii) Affix to each handset a label which is designed to withstand
the length of service expected for a non-service-initialized phone, and
which notifies the user that the handset can only be used to dial 911,
that the 911 operator will not be able to call the user back, and that
the user should convey the exact location of the emergency as soon as
possible; and
(iii) Institute a public education program to provide the users of
such handsets with information regarding the limitations of non-
service-initialized handsets.
(2) Manufacturers of 911-only handsets that are manufactured on or
after May 3, 2004, are required to:
(i) Program each handset with 911 plus the decimal representation
of the seven least significant digits of the Electronic Serial Number,
International Mobile Equipment Identifier, or any other identifier
unique to that handset;
(ii) Affix to each handset a label which is designed to withstand
the length of service expected for a non-service-initialized phone, and
which notifies the user that the handset can only be used to dial 911,
that the 911 operator will not be able to call the user back, and that
the user should convey the exact location of the emergency as soon as
possible; and
(iii) Institute a public education program to provide the users of
such handsets with information regarding the limitations of 911-only
handsets.
(3) Definitions. The following definitions apply for purposes of
this paragraph.
(i) Non-service-initialized handset. A handset for which there is
no valid service contract with a provider of the services enumerated in
paragraph (a) of this section.
(ii) 911-only handset. A non-service-initialized handset that is
manufactured with the capability of dialing 911 only and that cannot
receive incoming calls.
(p) Reseller obligation. (1) Beginning December 31, 2006, resellers
have an obligation, independent of the underlying licensee, to provide
access to basic and enhanced 911 service to the extent that the
underlying licensee of the facilities the reseller uses to provide
access to the public switched network complies with sections 9.10(d)-
(g).
(2) Resellers have an independent obligation to ensure that all
handsets or other devices offered to their customers for voice
communications and sold after December 31, 2006 are capable of
transmitting enhanced 911 information to the appropriate PSAP, in
accordance with the accuracy requirements of section 9.10(i).
(q) Text-to-911 Requirements--(1) Covered Text Provider:
Notwithstanding any other provisions in this section, for purposes of
this paragraph (q) of this section, a ``covered text provider''
includes all CMRS providers as well as all providers of interconnected
text messaging services that enable consumers to send text messages to
and receive text messages from all or substantially all text-capable
U.S. telephone numbers, including through the use of applications
downloaded or otherwise installed on mobile phones.
(2) Automatic Bounce-back Message: An automatic text message
delivered to a consumer by a covered text provider in response to the
consumer's attempt to send a text message to 911 when the consumer is
located in an area where text-to-911 service is unavailable or the
covered text provider does not support text-to-911 service generally or
in the area where the consumer is located at the time.
(3) No later than September 30, 2013, all covered text providers
shall provide an automatic bounce-back message under the following
circumstances:
(i) A consumer attempts to send a text message to a Public Safety
Answering Point (PSAP) by means of the three-digit short code ``911'';
and
(ii) The covered text provider cannot deliver the text because the
consumer is located in an area where:
(A) Text-to-911 service is unavailable; or
(B) The covered text provider does not support text-to-911 service
at the time.
(4)(i) A covered text provider is not required to provide an
automatic bounce-back message when:
(A) Transmission of the text message is not controlled by the
provider;
(B) A consumer is attempting to text 911, through a text messaging
application that requires CMRS service, from a non-service initialized
handset;
(C) When the text-to-911 message cannot be delivered to a PSAP due
to failure in the PSAP network that has not been reported to the
provider; or
(D) A consumer is attempting to text 911 through a device that is
incapable of sending texts via three digit short codes, provided the
software for the device cannot be upgraded over the air to allow text-
to-911.
(ii) The provider of a preinstalled or downloadable interconnected
text application is considered to have ``control'' over transmission of
text messages for purposes of paragraph (q)(4)(i)(A) of this section.
However, if a user or a third party modifies or manipulates the
application after it is installed or downloaded so that it no longer
supports bounce-back messaging, the application provider will be
presumed not to have control.
(5) The automatic bounce-back message shall, at a minimum, inform
the consumer that text-to-911 service is not available and advise the
consumer or texting program user to use another means to contact
emergency services.
(6) Covered text providers that support text-to-911 must provide a
mechanism to allow PSAPs that accept text-to-911 to request temporary
suspension of text-to-911 service for any reason, including, but not
limited to, network congestion, call taker overload, PSAP failure, or
security breach, and to request resumption of text-to-911 service after
such temporary suspension. During any period of suspension of text-to-
911 service, the covered text provider must provide an automatic
bounce-back message to any consumer attempting to text to 911 in the
area subject to the temporary suspension.
[[Page 54216]]
(7) Notwithstanding any other provisions in this section, when a
consumer is roaming on a covered text provider's host network pursuant
to Sec. 20.12, the covered text provider operating the consumer's home
network shall have the obligation to originate an automatic bounce-back
message to such consumer when the consumer is located in an area where
text-to-911 service is unavailable, or the home provider does not
support text-to-911 service in that area at the time. The host provider
shall not impede the consumer's 911 text message to the home provider
and/or any automatic bounce-back message originated by the home
provider to the consumer roaming on the host network.
(8) A software application provider that transmits text messages
directly into the SMS network of the consumer's underlying CMRS
provider satisfies the obligations of paragraph (q)(3) of this section
provided it does not prevent or inhibit delivery of the CMRS provider's
automatic bounce-back message to the consumer.
(9) 911 text message. A 911 text message is a message, consisting
of text characters, sent to the short code ``911'' and intended to be
delivered to a PSAP by a covered text provider, regardless of the text
messaging platform used.
(10) Delivery of 911 text messages. (i) No later than December 31,
2014, all covered text providers must have the capability to route a
911 text message to a PSAP. In complying with this requirement, covered
text providers must obtain location information sufficient to route
text messages to the same PSAP to which a 911 voice call would be
routed, unless the responsible local or state entity designates a
different PSAP to receive 911 text messages and informs the covered
text provider of that change. All covered text providers using device-
based location information that requires consumer activation must
clearly inform consumers that they must grant permission for the text
messaging application to access the wireless device's location
information in order to enable text-to-911. If a consumer does not
permit this access, the covered text provider's text application must
provide an automated bounce-back message as set forth in paragraph
(q)(3) of this section.
(ii) Covered text providers must begin routing all 911 text
messages to a PSAP by June 30, 2015, or within six months of the PSAP's
valid request for text-to-911 service, whichever is later, unless an
alternate timeframe is agreed to by both the PSAP and the covered text
provider. The covered text provider must notify the Commission of the
dates and terms of the alternate timeframe within 30 days of the
parties' agreement.
(iii) Valid Request means that:
(A) The requesting PSAP is, and certifies that it is, technically
ready to receive 911 text messages in the format requested;
(B) The appropriate local or state 911 service governing authority
has specifically authorized the PSAP to accept and, by extension, the
covered text provider to provide, text-to-911 service; and
(C) The requesting PSAP has provided notification to the covered
text provider that it meets the foregoing requirements. Registration by
the PSAP in a database made available by the Commission in accordance
with requirements established in connection therewith, or any other
written notification reasonably acceptable to the covered text
provider, shall constitute sufficient notification for purposes of this
paragraph.
(iv) The requirements set forth in paragraphs (q)(10)(i) through
(iii) of this section do not apply to in-flight text messaging
providers, MSS providers, or IP Relay service providers, or to 911 text
messages that originate from Wi-Fi only locations or that are
transmitted from devices that cannot access the CMRS network.
(11) Access to SMS networks for 911 text messages. To the extent
that CMRS providers offer Short Message Service (SMS), they shall allow
access by any other covered text provider to the capabilities necessary
for transmission of 911 text messages originating on such other covered
text providers' application services. Covered text providers using the
CMRS network to deliver 911 text messages must clearly inform consumers
that, absent an SMS plan with the consumer's underlying CMRS provider,
the covered text provider may be unable to deliver 911 text messages.
CMRS providers may migrate to other technologies and need not retain
SMS networks solely for other covered text providers' 911 use, but must
notify the affected covered text providers not less than 90 days before
the migration is to occur.
(r) Contraband Interdiction System (CIS) requirement. CIS providers
regulated as private mobile radio service (see Sec. 9.3) must transmit
all wireless 911 calls without respect to their call validation process
to a Public Safety Answering Point, or, where no Public Safety
Answering Point has been designated, to a designated statewide default
answering point or appropriate local emergency authority pursuant to
Sec. 9.4 of this chapter, provided that ``all wireless 911 calls'' is
defined as ``any call initiated by a wireless user dialing 911 on a
phone using a compliant radio frequency protocol of the serving
carrier.'' This requirement shall not apply if the Public Safety
Answering Point or emergency authority informs the CIS provider that it
does not wish to receive 911 calls from the CIS provider.
Subpart D--Interconnected Voice Over Internet Protocol Services and
911 VoIP Services
Sec. 9.11 E911 Service.
(a) Before February 16, 2020. (1) Scope of Section. The following
requirements are only applicable to providers of interconnected VoIP
services. Further, the following requirements apply only to 911 calls
placed by users whose Registered Location is in a geographic area
served by a Wireline E911 Network (which, as defined in Sec. 9.3,
includes a selective router).
(2) E911 Service. As of November 28, 2005:
(i) Interconnected VoIP service providers must, as a condition of
providing service to a consumer, provide that consumer with E911
service as described in this section;
(ii) Interconnected VoIP service providers must transmit all 911
calls, as well as ANI and the caller's Registered Location for each
call, to the PSAP, designated statewide default answering point, or
appropriate local emergency authority that serves the caller's
Registered Location and that has been designated for telecommunications
carriers pursuant to Sec. 9.4 of this chapter, provided that ``all 911
calls'' is defined as ``any voice communication initiated by an
interconnected VoIP user dialing 911;''
(iii) All 911 calls must be routed through the use of ANI and, if
necessary, pseudo-ANI, via the dedicated Wireline E911 Network; and
(iv) The Registered Location must be available to the appropriate
PSAP, designated statewide default answering point, or appropriate
local emergency authority from or through the appropriate automatic
location information (ALI) database.
(3) Service Level Obligation. Notwithstanding the provisions in
paragraph (a)(2) of this section, if a PSAP, designated statewide
default answering point, or appropriate local emergency authority is
not capable of receiving and processing either ANI or location
information, an interconnected VoIP service provider need not provide
such ANI or location information; however, nothing in this paragraph
[[Page 54217]]
affects the obligation under paragraph (a)(2)(iii) of this section of
an interconnected VoIP service provider to transmit via the Wireline
E911 Network all 911 calls to the PSAP, designated statewide default
answering point, or appropriate local emergency authority that serves
the caller's Registered Location and that has been designated for
telecommunications carriers pursuant to Sec. 9.4 of this chapter.
(4) Registered Location Requirement. As of November 28, 2005,
interconnected VoIP service providers must:
(i) Obtain from each customer, prior to the initiation of service,
the physical location at which the service will first be used; and
(ii) Provide their end users one or more methods of updating their
Registered Location, including at least one option that requires use
only of the CPE necessary to access the interconnected VoIP service.
Any method used must allow an end user to update the Registered
Location at will and in a timely manner.
(5) Customer Notification. Each interconnected VoIP service
provider shall:
(i) Specifically advise every subscriber, both new and existing,
prominently and in plain language, of the circumstances under which
E911 service may not be available through the interconnected VoIP
service or may be in some way limited by comparison to traditional E911
service. Such circumstances include, but are not limited to, relocation
of the end user's IP-compatible CPE, use by the end user of a non-
native telephone number, broadband connection failure, loss of
electrical power, and delays that may occur in making a Registered
Location available in or through the ALI database;
(ii) Obtain and keep a record of affirmative acknowledgement by
every subscriber, both new and existing, of having received and
understood the advisory described in paragraph (a)(5)(i) of this
section; and
(iii) Distribute to its existing subscribers warning stickers or
other appropriate labels warning subscribers if E911 service may be
limited or not available and instructing the subscriber to place them
on or near the equipment used in conjunction with the interconnected
VoIP service. Each interconnected VoIP provider shall distribute such
warning stickers or other appropriate labels to each new subscriber
prior to the initiation of that subscriber's service.
(b) On or after February 16, 2020. (1) Scope of Section. The
following requirements are only applicable to providers of
interconnected VoIP services and 911 VoIP services. Further, the
following requirements apply only to 911 calls placed by users whose
dispatchable location is in a geographic area served by a Wireline E911
Network (which, as defined in Sec. 9.3, includes a selective router).
(2) E911 Service. (i) Interconnected VoIP service providers and 911
VoIP service providers must, as a condition of providing service to a
consumer, provide that consumer with E911 service as described in this
section;
(ii) Interconnected VoIP service providers and 911 VoIP service
providers must transmit all 911 calls, as well as ANI and the caller's
dispatchable location for each call, to the PSAP, designated statewide
default answering point, or appropriate local emergency authority that
serves the caller's dispatchable location and that has been designated
for telecommunications carriers pursuant to Sec. 9.4 of this chapter,
provided that ``all 911 calls'' is defined as ``any voice communication
initiated by an interconnected VoIP user dialing 911;''
(iii) All 911 calls must be routed through the use of ANI and, if
necessary, pseudo-ANI, via the dedicated Wireline E911 Network; and
(iv) The dispatchable location must be available to the appropriate
PSAP, designated statewide default answering point, or appropriate
local emergency authority from or through the appropriate automatic
location information (ALI) database.
(3) Service Level Obligation. Notwithstanding the provisions in
paragraph (b)(2) of this section, if a PSAP, designated statewide
default answering point, or appropriate local emergency authority is
not capable of receiving and processing either ANI or location
information, an interconnected VoIP service provider need not provide
such ANI or location information; however, nothing in this paragraph
affects the obligation under paragraph (b)(2)(iii) of this section of
an interconnected VoIP service provider to transmit via the Wireline
E911 Network all 911 calls to the PSAP, designated statewide default
answering point, or appropriate local emergency authority that serves
the caller's dispatchable location and that has been designated for
telecommunications carriers pursuant to Sec. 9.4 of this chapter.
(4) Dispatchable Location Requirement. Interconnected VoIP service
providers and 911 VoIP service providers must comply with either
subparagraph (4)(i) or (4)(ii) below.
(i)(A) Obtain from each customer, prior to the initiation of
service, the Registered Location at which the service will first be
used;
(B) Provide their end users one or more methods of updating their
Registered Location, including at least one option that requires use
only of the CPE necessary to access the interconnected VoIP service or
911 VoIP service. Any method used must allow an end user to update the
Registered Location at will and in a timely manner; and
(C) For interconnected VoIP service or 911 VoIP service that is
capable of being used from more than one location, identify whether the
service is being used from a different location than the Registered
Location, and if so, either:
(1) Prompt the customer to provide a new Registered Location; or
(2) Update the Registered Location without requiring additional
action by the customer.
(ii) Obtain the customer's dispatchable location at the time the
customer initiates a 911 call without requiring additional action by
the customer.
(5) Customer Notification. Each interconnected VoIP service
provider and 911 service provider shall:
(i) Specifically advise every subscriber, both new and existing,
prominently and in plain language, of the circumstances under which
E911 service may not be available through the interconnected VoIP
service (or 911 VoIP service) or may be in some way limited by
comparison to traditional E911 service. Such circumstances include, but
are not limited to, relocation of the end user's IP-compatible CPE, use
by the end user of a non-native telephone number, broadband connection
failure, loss of electrical power, and delays that may occur in making
a dispatchable location available in or through the ALI database;
(ii) Obtain and keep a record of affirmative acknowledgement by
every subscriber, both new and existing, of having received and
understood the advisory described in paragraph (b)(5)(i) of this
section; and
(iii) Distribute to its existing subscribers warning stickers or
other appropriate labels warning subscribers if E911 service may be
limited or not available and instructing the subscriber to place them
on or near the equipment used in conjunction with the interconnected
VoIP service or 911 VoIP service. Each interconnected VoIP provider or
911 VoIP service provider shall distribute such warning stickers or
other appropriate labels to each new subscriber prior to the initiation
of that subscriber's service.
[[Page 54218]]
Sec. 9.12 Access to 911 and E911 service capabilities.
(a) Access. Subject to the other requirements of this part, an
owner or controller of a capability that can be used for 911 or E911
service shall make that capability available to a requesting
interconnected VoIP provider or 911 VoIP service provider as set forth
in paragraphs (a)(1) and (a)(2) of this section.
(1) If the owner or controller makes the requested capability
available to a CMRS provider, the owner or controller must make that
capability available to the interconnected VoIP provider or 911 VoIP
service provider. An owner or controller makes a capability available
to a CMRS provider if the owner or controller offers that capability to
any CMRS provider.
(2) If the owner or controller does not make the requested
capability available to a CMRS provider within the meaning of paragraph
(a)(1) of this section, the owner or controller must make that
capability available to a requesting interconnected VoIP provider or
911 VoIP service provider only if that capability is necessary to
enable the interconnected VoIP provider or 911 VoIP service provider to
provide 911 or E911 service in compliance with the Commission's rules.
(b) Rates, terms, and conditions. The rates, terms, and conditions
on which a capability is provided to an interconnected VoIP provider or
911 VoIP service provider under paragraph (a) of this section shall be
reasonable. For purposes of this paragraph, it is evidence that rates,
terms, and conditions are reasonable if they are:
(1) The same as the rates, terms, and conditions that are made
available to CMRS providers, or
(2) In the event such capability is not made available to CMRS
providers, the same rates, terms, and conditions that are made
available to any telecommunications carrier or other entity for the
provision of 911 or E911 service.
(c) Permissible use. An interconnected VoIP provider or 911 VoIP
service provider that obtains access to a capability pursuant to this
section may use that capability only for the purpose of providing 911
or E911 service in accordance with the Commission's rules.
Subpart E--Telecommunications Relay Services for Persons With
Disabilities
Sec. 9.13 Jurisdiction.
Any violation of this subpart E by any common carrier engaged in
intrastate communication shall be subject to the same remedies,
penalties, and procedures as are applicable to a violation of the Act
by a common carrier engaged in interstate communication. For purposes
of this subpart, all regulations and requirements applicable to common
carriers shall also be applicable to providers of interconnected VoIP
service as defined in Sec. 9.2.
Sec. 9.14 Emergency calling requirements.
(a) Emergency call handling requirements for TTY-based TRS
providers. (1) Before February 16, 2020. TTY-based TRS providers must
use a system for incoming emergency calls that, at a minimum,
automatically and immediately transfers the caller to an appropriate
Public Safety Answering Point (PSAP). An appropriate PSAP is either a
PSAP that the caller would have reached if he had dialed 911 directly,
or a PSAP that is capable of enabling the dispatch of emergency
services to the caller in an expeditious manner.
(2) On or after February 16, 2020. TTY-based TRS providers must use
a system for incoming emergency calls that, at a minimum, automatically
and immediately transfers the caller to an appropriate Public Safety
Answering Point (PSAP) and transmits the caller's dispatchable location
to the PSAP. An appropriate PSAP is either a PSAP that the caller would
have reached if he had dialed 911 directly, or a PSAP that is capable
of enabling the dispatch of emergency services to the caller in an
expeditious manner.
(b) Additional emergency calling requirements applicable to
internet-based TRS providers. (1) As of December 31, 2008, the
requirements of paragraphs (b)(2)(i) and (b)(2)(v) of this section
shall not apply to providers of VRS and IP Relay to which Sec. Sec.
9.14(c) and 9.14(d) apply.
(2) Each provider of internet-based TRS shall:
(i) Accept and handle emergency calls and access, either directly
or via a third party, a commercially available database that will allow
the provider to determine an appropriate PSAP, designated statewide
default answering point, or appropriate local emergency authority that
corresponds to the caller's location, and to relay the call to that
entity;
(ii) Implement a system that ensures that the provider answers an
incoming emergency call before other non-emergency calls (i.e.,
prioritize emergency calls and move them to the top of the queue);
(iii) Before February 16, 2020. Request, at the beginning of each
emergency call, the caller's name and location information, unless the
internet-based TRS provider already has, or has access to, a Registered
Location for the caller;
(iv) On or after February 16, 2020. Request, at the beginning of
each emergency call, the caller's name and dispatchable location,
unless the internet-based TRS provider already has, or has access to, a
dispatchable location for the caller;
(v) Deliver to the PSAP, designated statewide default answering
point, or appropriate local emergency authority, at the outset of the
outbound leg of an emergency call, at a minimum, the name of the relay
user and location of the emergency, as well as the name of the relay
provider, the CA's callback number, and the CA's identification number,
thereby enabling the PSAP, designated statewide default answering
point, or appropriate local emergency authority to re-establish contact
with the CA in the event the call is disconnected;
(vi) In the event one or both legs of an emergency call are
disconnected (i.e., either the call between the TRS user and the CA, or
the outbound voice telephone call between the CA and the PSAP,
designated statewide default answering point, or appropriate local
emergency authority), immediately re-establish contact with the TRS
user and/or the appropriate PSAP, designated statewide default
answering point, or appropriate local emergency authority and resume
handling the call; and
(vii) Ensure that information obtained as a result of this section
is limited to that needed to facilitate 911 services, is made available
only to emergency call handlers and emergency response or law
enforcement personnel, and is used for the sole purpose of ascertaining
a user's location in an emergency situation or for other emergency or
law enforcement purposes.
(c) E911 Service for VRS and IP Relay before February 16, 2020. (1)
Scope. The following requirements are only applicable to providers of
VRS or IP Relay. Further, the following requirements apply only to 911
calls placed by registered users whose Registered Location is in a
geographic area served by a Wireline E911 Network and is available to
the provider handling the call.
(2) E911 Service. (i) VRS or IP Relay providers must, as a
condition of providing service to a user, provide that user with E911
service as described in this section;
(ii) VRS or IP Relay providers must transmit all 911 calls, as well
as ANI, the caller's Registered Location, the name of the VRS or IP
Relay provider, and the CA's identification number for
[[Page 54219]]
each call, to the PSAP, designated statewide default answering point,
or appropriate local emergency authority that serves the caller's
Registered Location and that has been designated for telecommunications
carriers pursuant to Sec. 9.4 of this chapter, provided that ``all 911
calls'' is defined as ``any communication initiated by an VRS or IP
Relay user dialing 911'';
(iii) All 911 calls must be routed through the use of ANI and, if
necessary, pseudo-ANI, via the dedicated Wireline E911 Network; and
(iv) The Registered Location, the name of the VRS or IP Relay
provider, and the CA's identification number must be available to the
appropriate PSAP, designated statewide default answering point, or
appropriate local emergency authority from or through the appropriate
automatic location information (ALI) database.
(3) Service level obligation. Notwithstanding the provisions in
paragraph (c)(2) of this section, if a PSAP, designated statewide
default answering point, or appropriate local emergency authority is
not capable of receiving and processing either ANI or location
information, a VRS or IP Relay provider need not provide such ANI or
location information; however, nothing in this paragraph affects the
obligation under paragraph (c)(2)(iii) of this section of a VRS or IP
Relay provider to transmit via the Wireline E911 Network all 911 calls
to the PSAP, designated statewide default answering point, or
appropriate local emergency authority that serves the caller's
Registered Location and that has been designated for telecommunications
carriers pursuant to Sec. 64.3001 of this chapter.
(4) Registered location requirement. As of December 31, 2008, VRS
and IP Relay providers must:
(i) Obtain from each Registered internet-based TRS User, prior to
the initiation of service, the physical location at which the service
will first be used; and
(ii) If the VRS or IP Relay is capable of being used from more than
one location, provide their registered internet-based TRS users one or
more methods of updating their Registered Location, including at least
one option that requires use only of the iTRS access technology
necessary to access the VRS or IP Relay. Any method used must allow a
registered internet-based TRS user to update the Registered Location at
will and in a timely manner.
(d) E911 Service for VRS and IP Relay on or after February 16,
2020. (1) Scope. The following requirements are only applicable to
providers of VRS or IP Relay. Further, the following requirements apply
only to 911 calls placed by registered users whose dispatchable
location is in a geographic area served by a Wireline E911 Network and
is available to the provider handling the call.
(2) E911 Service. (i) VRS or IP Relay providers must, as a
condition of providing service to a user, provide that user with E911
service as described in this section;
(ii) VRS or IP Relay providers must transmit all 911 calls, as well
as ANI, the caller's dispatchable location, the name of the VRS or IP
Relay provider, and the CA's identification number for each call, to
the PSAP, designated statewide default answering point, or appropriate
local emergency authority that serves the caller's dispatchable
location and that has been designated for telecommunications carriers
pursuant to Sec. 9.4 of this chapter, provided that ``all 911 calls''
is defined as ``any communication initiated by an VRS or IP Relay user
dialing 911'';
(iii) All 911 calls must be routed through the use of ANI and, if
necessary, pseudo-ANI, via the dedicated Wireline E911 Network; and
(iv) The dispatchable location, the name of the VRS or IP Relay
provider, and the CA's identification number must be available to the
appropriate PSAP, designated statewide default answering point, or
appropriate local emergency authority from or through the appropriate
automatic location information (ALI) database.
(3) Service level obligation. Notwithstanding the provisions in
paragraph (d)(2) of this section, if a PSAP, designated statewide
default answering point, or appropriate local emergency authority is
not capable of receiving and processing either ANI or location
information, a VRS or IP Relay provider need not provide such ANI or
location information; however, nothing in this paragraph affects the
obligation under paragraph (d)(2)(iii) of this section of a VRS or IP
Relay provider to transmit via the Wireline E911 Network all 911 calls
to the PSAP, designated statewide default answering point, or
appropriate local emergency authority that serves the caller's
dispatchable location and that has been designated for
telecommunications carriers pursuant to Sec. 9.4 of this chapter.
(4) Dispatchable location requirement. VRS and IP Relay providers
must comply with either paragraphs (4)(i) or (4)(ii) of this section.
(i)(A) Obtain from each Registered internet-based TRS User, prior
to the initiation of service, the Registered Location at which the
service will first be used; and
(B) If the VRS or IP Relay is capable of being used from more than
one location, provide their registered internet-based TRS users one or
more methods of updating their Registered Location, including at least
one option that requires use only of the internet-based TRS access
technology necessary to access the VRS or IP Relay. Any method used
must allow a registered internet-based TRS user to update the
Registered Location at will and in a timely manner; and
(C) If the VRS or IP Relay is capable of being used from more than
one location, identify whether the service is being used from a
different location than the Registered Location, and if so, either:
(1) Prompt the Registered internet-based TRS User to provide a new
Registered Location; or
(2) Update the Registered Location without requiring additional
action by the Registered internet-based TRS User.
(ii) Obtain the Registered internet-based TRS User's dispatchable
location at the time they initiate a 911 call without requiring
additional action by the Registered internet-based TRS User.
Subpart F--Multi-Line Telephone Systems
Sec. 9.15 Applicability.
The rules in this subpart F apply to:
(a) A person engaged in the business of manufacturing, importing,
selling, or leasing multi-line telephone systems;
(b) A person engaged in the business of installing, managing, or
operating multi-line telephone systems;
(c) Any multi-line telephone system that is manufactured, imported,
offered for first sale or lease, first sold or leased, or installed
after February 16, 2020.
Sec. 9.16 General Obligations--direct 911 dialing, notification and
dispatchable location.
(a) Obligation of manufacturers, importers, sellers and lessors.
(1) A person engaged in the business of manufacturing, importing,
selling, or leasing multi-line telephone systems may not manufacture or
import for use in the United States, or sell or lease or offer to sell
or lease in the United States, a multi-line telephone system, unless
such system is pre-configured such that, when properly installed in
accordance with paragraph (b) of this section, a user may directly
initiate a call to 911 from any station equipped with dialing
facilities, without dialing any additional digit, code, prefix, or
post-fix, including any trunk-access code such as the digit 9,
regardless of whether the user is required to dial such a digit, code,
prefix, or post-fix for other calls.
[[Page 54220]]
(2) A person engaged in the business of manufacturing, importing,
selling, or leasing multi-line telephone systems may not manufacture or
import for use in the United States, or sell or lease or offer to sell
or lease in the United States, a multi-line telephone system, unless
such system is pre-configured such that, when properly installed in
accordance with subsection (b), the dispatchable location of the caller
is conveyed to the PSAP with 911 calls.
(b) Obligation of installers, operators and managers. (1) A person
engaged in the business of installing, managing, or operating multi-
line telephone systems may not install, manage, or operate for use in
the United States such a system, unless such system is configured such
that a user may directly initiate a call to 911 from any station
equipped with dialing facilities, without dialing any additional digit,
code, prefix, or post-fix, including any trunk-access code such as the
digit 9, regardless of whether the user is required to dial such a
digit, code, prefix, or post-fix for other calls.
(2) A person engaged in the business of installing, managing, or
operating multi-line telephone systems shall, in installing, managing,
or operating such a system for use in the United States, configure the
system to provide a notification to a central location at the facility
where the system is installed or to another person or organization
regardless of location, if the system is able to be configured to
provide the notification without an improvement to the hardware or
software of the system. The MLTS notification must be contemporaneous
with the 911 call and must not delay the call to 9-1-1.
(3) A person engaged in the business of installing, managing, or
operating multi-line telephone systems may not install, manage, or
operate such a system in the United States unless it is configured such
that the dispatchable location of the caller is conveyed to the PSAP
with 911 calls.
Sec. 9.17 Enforcement, Compliance date, State law.
(a) Enforcement. Sections 9.16(a)(1) and 9.16(b)(1) and (2) of this
subpart shall be enforced under title V of the Communications Act of
1934, as amended, 5 U.S.C. 501 et seq., except that section 501 applies
only to the extent that such section provides for the punishment of a
fine.
(b) Compliance date. The compliance date for this subpart F is
February 16, 2020. Accordingly, the requirements in this subpart apply
to MLTS that are manufactured, imported, offered for first sale or
lease, first sold or leased, or installed after February 16, 2020.
(c) Effect on State law. Nothing in this subpart is intended to
alter the authority of State commissions or other State or local
agencies with jurisdiction over emergency communications, if the
exercise of such authority is not inconsistent with this subpart.
Subpart G--Mobile-Satellite Service
Sec. 9.18 Emergency Call Center Service.
(a) Providers of Mobile-Satellite Service to end-user customers
(part 25, subparts A-D) must provide Emergency Call Center service to
the extent that they offer real-time, two way switched voice service
that is interconnected with the public switched network and use an in-
network switching facility which enables the provider to reuse
frequencies and/or accomplish seamless hand-offs of subscriber calls.
Emergency Call Center personnel must determine the emergency caller's
phone number and location and then transfer or otherwise redirect the
call to an appropriate public safety answering point. Providers of
Mobile-Satellite Services that use earth terminals that are not capable
of use while in motion are exempt from providing Emergency Call Center
service for such terminals.
(b) Each Mobile-Satellite Service carrier that is subject to the
provisions of paragraph (a) of this section must maintain records of
all 911 calls received at its emergency call center. By October 15, of
each year, Mobile-Satellite Service carriers providing service in the
1.6/2.4 GHz and 2 GHz bands must submit a report to the Commission
regarding their call center data, current as of September 30 of that
year. By June 30, of each year, Mobile-Satellite Service carriers
providing service in bands other than 1.6/2.4 GHz and 2 GHz must submit
a report to the Commission regarding their call center data, current as
of May 31 of that year. These reports must include, at a minimum, the
following:
(1) The name and address of the carrier, the address of the
carrier's emergency call center, and emergency call center contact
information;
(2) The aggregate number of calls received by the call center each
month during the relevant reporting period;
(3) An indication of how many calls received by the call center
each month during the relevant reporting period required forwarding to
a public safety answering point and how many did not require forwarding
to a public safety answering point.
Subpart H--Resiliency, redundancy and reliability of 911
communications
Sec. 9.19 Reliability of covered 911 service providers.
(a) Definitions. Terms in this section shall have the following
meanings:
(1) Aggregation point. A point at which network monitoring data for
a 911 service area is collected and routed to a network operations
center (NOC) or other location for monitoring and analyzing network
status and performance.
(2) Certification. An attestation by a certifying official, under
penalty of perjury, that a covered 911 service provider:
(i) Has satisfied the obligations of paragraph (c) of this section.
(ii) Has adequate internal controls to bring material information
regarding network architecture, operations, and maintenance to the
certifying official's attention.
(iii) Has made the certifying official aware of all material
information reasonably necessary to complete the certification.
(iv) The term ``certification'' shall include both an annual
reliability certification under paragraph (c) of this section and an
initial reliability certification under paragraph (d)(1) of this
section, to the extent provided under paragraph (d)(1) of this section.
(3) Certifying official. A corporate officer of a covered 911
service provider with supervisory and budgetary authority over network
operations in all relevant service areas.
(4) Covered 911 service provider.
(i) Any entity that:
(A) Provides 911, E911, or NG911 capabilities such as call routing,
automatic location information (ALI), automatic number identification
(ANI), or the functional equivalent of those capabilities, directly to
a public safety answering point (PSAP), statewide default answering
point, or appropriate local emergency authority as defined in Sec. 9.3
of this chapter; and/or
(B) Operates one or more central offices that directly serve a
PSAP. For purposes of this section, a central office directly serves a
PSAP if it hosts a selective router or ALI/ANI database, provides
equivalent NG911 capabilities, or is the last service-provider facility
through which a 911 trunk or administrative line passes before
connecting to a PSAP.
(ii) The term ``covered 911 service provider'' shall not include
any entity that:
(A) Constitutes a PSAP or governmental authority to the extent that
it provides 911 capabilities; or
[[Page 54221]]
(B) Offers the capability to originate 911 calls where another
service provider delivers those calls and associated number or location
information to the appropriate PSAP.
(5) Critical 911 circuits. 911 facilities that originate at a
selective router or its functional equivalent and terminate in the
central office that serves the PSAP(s) to which the selective router or
its functional equivalent delivers 911 calls, including all equipment
in the serving central office necessary for the delivery of 911 calls
to the PSAP(s). Critical 911 circuits also include ALI and ANI
facilities that originate at the ALI or ANI database and terminate in
the central office that serves the PSAP(s) to which the ALI or ANI
databases deliver 911 caller information, including all equipment in
the serving central office necessary for the delivery of such
information to the PSAP(s).
(6) Diversity audit. A periodic analysis of the geographic routing
of network components to determine whether they are physically diverse.
Diversity audits may be performed through manual or automated means, or
through a review of paper or electronic records, as long as they
reflect whether critical 911 circuits are physically diverse.
(7) Monitoring links. Facilities that collect and transmit network
monitoring data to a NOC or other location for monitoring and analyzing
network status and performance.
(8) Physically diverse. Circuits or equivalent data paths are
Physically Diverse if they provide more than one physical route between
end points with no common points where a single failure at that point
would cause both circuits to fail. Circuits that share a common segment
such as a fiber-optic cable or circuit board are not Physically diverse
even if they are logically diverse for purposes of transmitting data.
(9) 911 service area. The metropolitan area or geographic region in
which a covered 911 service provider operates a selective router or the
functional equivalent to route 911 calls to the geographically
appropriate PSAP.
(10) Selective router. A 911 network component that selects the
appropriate destination PSAP for each 911 call based on the location of
the caller.
(11) Tagging. An inventory management process whereby critical 911
circuits are labeled in circuit inventory databases to make it less
likely that circuit rearrangements will compromise diversity. A covered
911 service provider may use any system it wishes to tag circuits so
long as it tracks whether critical 911 circuits are physically diverse
and identifies changes that would compromise such diversity.
(b) Provision of reliable 911 service. All covered 911 service
providers shall take reasonable measures to provide reliable 911
service with respect to circuit diversity, central-office backup power,
and diverse network monitoring. Performance of the elements of the
certification set forth in paragraphs (c)(1)(i), (c)(2)(i), and
(c)(3)(i) of this section shall be deemed to satisfy the requirements
of this paragraph. If a covered 911 service provider cannot certify
that it has performed a given element, the Commission may determine
that such provider nevertheless satisfies the requirements of this
paragraph based upon a showing in accordance with paragraph (c) of this
section that it is taking alternative measures with respect to that
element that are reasonably sufficient to mitigate the risk of failure,
or that one or more certification elements are not applicable to its
network.
(c) Annual reliability certification. One year after the initial
reliability certification described in paragraph (d)(1) of this section
and every year thereafter, a certifying official of every covered 911
service provider shall submit a certification to the Commission as
follows.
(1) Circuit auditing. (i) A covered 911 service provider shall
certify whether it has, within the past year:
(A) Conducted diversity audits of critical 911 circuits or
equivalent data paths to any PSAP served;
(B) Tagged such critical 911 circuits to reduce the probability of
inadvertent loss of diversity in the period between audits; and
(C) Eliminated all single points of failure in critical 911
circuits or equivalent data paths serving each PSAP.
(ii) If a Covered 911 Service Provider does not conform with all of
the elements in paragraph (c)(1)(i) of this section with respect to the
911 service provided to one or more PSAPs, it must certify with respect
to each such PSAP:
(A) Whether it has taken alternative measures to mitigate the risk
of critical 911 circuits that are not physically diverse or is taking
steps to remediate any issues that it has identified with respect to
911 service to the PSAP, in which case it shall provide a brief
explanation of such alternative measures or such remediation steps, the
date by which it anticipates such remediation will be completed, and
why it believes those measures are reasonably sufficient to mitigate
such risk; or
(B) Whether it believes that one or more of the requirements of
this paragraph are not applicable to its network, in which case it
shall provide a brief explanation of why it believes any such
requirement does not apply.
(2) Backup power. (i) With respect to any central office it
operates that directly serves a PSAP, a covered 911 service provider
shall certify whether it:
(A) Provisions backup power through fixed generators, portable
generators, batteries, fuel cells, or a combination of these or other
such sources to maintain full-service functionality, including network
monitoring capabilities, for at least 24 hours at full office load or,
if the central office hosts a selective router, at least 72 hours at
full office load; provided, however, that any such portable generators
shall be readily available within the time it takes the batteries to
drain, notwithstanding potential demand for such generators elsewhere
in the service provider's network.
(B) Tests and maintains all backup power equipment in such central
offices in accordance with the manufacturer's specifications;
(C) Designs backup generators in such central offices for fully
automatic operation and for ease of manual operation, when required;
(D) Designs, installs, and maintains each generator in any central
office that is served by more than one backup generator as a stand-
alone unit that does not depend on the operation of another generator
for proper functioning.
(ii) If a covered 911 service provider does not conform with all of
the elements in paragraph (c)(2)(i) of this section, it must certify
with respect to each such central office:
(A) Whether it has taken alternative measures to mitigate the risk
of a loss of service in that office due to a loss of power or is taking
steps to remediate any issues that it has identified with respect to
backup power in that office, in which case it shall provide a brief
explanation of such alternative measures or such remediation steps, the
date by which it anticipates such remediation will be completed, and
why it believes those measures are reasonably sufficient to mitigate
such risk; or
(B) Whether it believes that one or more of the requirements of
this paragraph are not applicable to its network, in which case it
shall provide a brief explanation of why it believes any such
requirement does not apply.
(3) Network monitoring. (i) A covered 911 service provider shall
certify whether it has, within the past year:
[[Page 54222]]
(A) Conducted diversity audits of the aggregation points that it
uses to gather network monitoring data in each 911 service area;
(B) Conducted diversity audits of monitoring links between
aggregation points and NOCs for each 911 service area in which it
operates; and
(C) Implemented physically diverse aggregation points for network
monitoring data in each 911 service area and physically diverse
monitoring links from such aggregation points to at least one NOC.
(ii) If a Covered 911 Service Provider does not conform with all of
the elements in paragraph (c)(3)(i) of this section, it must certify
with respect to each such 911 Service Area:
(A) Whether it has taken alternative measures to mitigate the risk
of network monitoring facilities that are not physically diverse or is
taking steps to remediate any issues that it has identified with
respect to diverse network monitoring in that 911 service area, in
which case it shall provide a brief explanation of such alternative
measures or such remediation steps, the date by which it anticipates
such remediation will be completed, and why it believes those measures
are reasonably sufficient to mitigate such risk; or
(B) Whether it believes that one or more of the requirements of
this paragraph are not applicable to its network, in which case it
shall provide a brief explanation of why it believes any such
requirement does not apply.
(d) Other matters. --(1) Initial reliability certification. One
year after October 15, 2014, a certifying official of every covered 911
service provider shall certify to the Commission that it has made
substantial progress toward meeting the standards of the annual
reliability certification described in paragraph (c) of this section.
Substantial progress in each element of the certification shall be
defined as compliance with standards of the full certification in at
least 50 percent of the covered 911 service provider's critical 911
circuits, central offices that directly serve PSAPs, and independently
monitored 911 service areas.
(2) Confidential treatment. (i) The fact of filing or not filing an
annual reliability certification or initial reliability certification
and the responses on the face of such certification forms shall not be
treated as confidential.
(ii) Information submitted with or in addition to such
certifications shall be presumed confidential to the extent that it
consists of descriptions and documentation of alternative measures to
mitigate the risks of nonconformance with certification elements,
information detailing specific corrective actions taken with respect to
certification elements, or supplemental information requested by the
Commission or Bureau with respect to a certification.
(2) Record retention. A covered 911 service provider shall retain
records supporting the responses in a certification for two years from
the date of such certification, and shall make such records available
to the Commission upon request. To the extent that a covered 911
service provider maintains records in electronic format, records
supporting a certification hereunder shall be maintained and supplied
in an electronic format.
(i) With respect to diversity audits of critical 911 circuits, such
records shall include, at a minimum, audit records separately
addressing each such circuit, any internal report(s) generated as a
result of such audits, records of actions taken pursuant to the audit
results, and records regarding any alternative measures taken to
mitigate the risk of critical 911 circuits that are not physically
diverse.
(ii) With respect to backup power at central offices, such records
shall include, at a minimum, records regarding the nature and extent of
backup power at each central office that directly serves a PSAP,
testing and maintenance records for backup power equipment in each such
central office, and records regarding any alternative measures taken to
mitigate the risk of insufficient backup power.
(iii) With respect to network monitoring, such records shall
include, at a minimum, records of diversity audits of monitoring links,
any internal report(s) generated as a result of such audits, records of
actions taken pursuant to the audit results, and records regarding any
alternative measures taken to mitigate the risk of aggregation points
and/or monitoring links that are not physically diverse.
Sec. 9.20 Backup power obligations
(a) Covered service. For purposes of this section, a Covered
Service is any facilities-based, fixed voice service offered as
residential service, including fixed applications of wireless service
offered as a residential service, that is not line powered.
(b) Obligations of providers of a Covered Service to offer backup
power. Providers of a Covered Service shall, at the point of sale for a
Covered Service, offer subscribers the option to purchase backup power
for the Covered Service as follows:
(1) Eight hours. Providers shall offer for sale at least one option
with a minimum of eight hours of standby backup power.
(2) Twenty-four hours. By February 13, 2019, providers of a Covered
Service shall offer for sale also at least one option that provides a
minimum of twenty-four hours of standby backup power.
(3) At the provider's discretion, the options in paragraphs (b)(1)
and (2) of this section may be either:
(i) A complete solution including battery or other power source; or
(ii) Installation by the provider of a component that accepts or
enables the use of a battery or other backup power source that the
subscriber obtains separately. If the provider does not offer a
complete solution, the provider shall install a compatible battery or
other power source if the subscriber makes it available at the time of
installation and so requests. After service has been initiated, the
provider may, but is not required to, offer to sell any such options
directly to subscribers.
(c) Backup power required. The backup power offered for purchase
under paragraph (b) of this section must include power for all
provider-furnished equipment and devices installed and operated on the
customer premises that must remain powered in order for the service to
provide 911 access.
(d) Subscriber disclosure. (1) The provider of a Covered Service
shall disclose to each new subscriber at the point of sale and to all
subscribers to a Covered Service annually thereafter:
(i) Capability of the service to accept backup power, and if so,
the availability of at least one backup power solution available
directly from the provider, or after the initiation of service,
available from either the provider or a third party. After the
obligation to offer for purchase a solution for twenty-four hours of
standby backup power becomes effective, providers must disclose this
information also for the twenty-four-hour solution;
(ii) Service limitations with and without backup power;
(iii) Purchase and replacement information, including cost;
(iv) Expected backup power duration;
(v) Proper usage and storage conditions, including the impact on
duration of failing to adhere to proper usage and storage;
(vi) Subscriber backup power self-testing and -monitoring
instructions; and
(vii) Backup power warranty details, if any.
(2) Disclosure reasonably calculated to reach each subscriber. A
provider of
[[Page 54223]]
a Covered Service shall make disclosures required by this rule in a
manner reasonably calculated to reach individual subscribers, with due
consideration for subscriber preferences. Information posted on a
provider's public website and/or within a subscriber portal accessed by
logging through the provider's website are not sufficient to comply
with these requirements.
(3) The disclosures required under this paragraph are in addition
to, but may be combined with, any disclosures required under Sec.
9.11(e) of this chapter.
(e) Obligation with respect to existing subscribers. Providers are
not obligated to offer for sale backup power options to or retrofit
equipment for those who are subscribers as of the effective date listed
in paragraph (f) of this section for the obligations in paragraph
(b)(1) of this section, but shall provide such subscribers with the
annual disclosures required by paragraph (d) of this section.
(f) Effective dates of obligations. (1) Except as noted in
paragraphs (b)(2) and (f)(2) of this section, the obligations under
paragraph (b) of this section are effective February 16, 2016, and the
obligations under paragraph (d) of this section are effective 120 days
after the Commission announces approval from the Office of Management
and Budget.
(2) For a provider of a Covered Service that (together with any
entities under common control with such provider) has fewer than
100,000 domestic retail subscriber lines, the obligations in paragraph
(b)(1) of this section are effective August 11, 2016, the obligations
in paragraph (b)(2) of this section are effective as prescribed
therein, and the obligations under paragraph (d) of this section are
effective 300 days after the Commission announces approval from the
Office of Management and Budget.
(g) Sunset date. The requirements of this section shall no longer
be in effect as of September 1, 2025.
PART 12--[REMOVED AND RESERVED]
0
2. Under the authority of 47 U.S.C. 151, 154(i), 154 (j), 154 (o),
155(c), 201(b), 214(d), 218, 219, 251(e)(3), 301, 303(b), 303(g),
303(j), 303(r), 307, 309(a), 316, 332, 403, 405, 615a-1, 615c,
621(b)(3), and 621(d)), 47 CFR chapter I is amended by removing and
reserving part 12.
PART 20--COMMERCIAL MOBILE SERVICES
0
3. The authority citation for part 20 continues to read as follows:
Authority: 47 U.S.C. 151, 152(a) 154(i), 157, 160, 201, 214,
222, 251(e), 301, 302, 303, 303(b), 303(r), 307, 307(a), 309,
309(j)(3), 316, 316(a), 332, 610, 615, 615a, 615b, 615c, unless
otherwise noted.
0
4. Section 20.2 is amended by adding paragraph (c) to read as follows:
Sec. 20.2 Other applicable rule parts.
* * * * *
(c) Part 9. This part contains 911 and E911 requirements applicable
to telecommunications carriers and commercial mobile radio service
(CMRS) providers.
Sec. 20.3 [Amended]
0
5. Section 20.3 is amended by removing the definitions of ``Appropriate
local emergency authority,'' ``Automatic Number Identification (ANI),''
``Designated PSAP,'' ``Handset-based location technology,'' ``Location-
capable handsets,'' ``Network-based Location Technology,'' ``Pseudo
Automatic Number Identification (Pseudo-ANI),'' ``Public safety
answering point (PSAP),'' and ``Statewide default answering point.''
Sec. 20.18 [Removed and Reserved]
0
6. Remove and reserve Sec. 20.18.
PART 25--SATELLITE COMMUNICATIONS
0
7. The authority citation for part 25 continues to read as follows:
Authority: 47 U.S.C. 154, 301, 302, 303, 307, 309, 310, 319,
332, 605, and 721, unless otherwise noted.
Sec. 25.103 [Amended]
0
8. Section 25.103 is amended by removing the definition of ``Emergency
Call Center.''
0
9. Section 25.109 is amended by adding paragraph (e) to read as
follows:
Sec. 25.109 Cross-reference
* * * * *
(e) Mobile-Satellite Service providers must comply with the
emergency call center service requirements under 47 CFR part 9.
Sec. 25.284 [Removed and Reserved]
0
10. Remove and reserve Sec. 25.284.
PART 64--MISCELLANEOUS RULES RELATING TO COMMON CARRIERS
0
11. The authority citation for part 64 continues to read as follows:
Authority: 47 U.S.C. 154, 201, 202, 217, 218, 220, 222, 225,
226, 227, 228, 251(a), 251(e), 254(k), 262, 403(b)(2)(B), (c), 616,
620, 1401-1473, unless otherwise noted.
0
12. Section 64.601 is amended by revising paragraph (a) to read as
follows:
Sec. 64.601 Definitions and provisions of general applicability
(a) For purposes of this subpart, the terms Public Safety Answering
Point (PSAP), statewide default answering point, and appropriate local
emergency authority are defined in 47 CFR 9.3; the term affiliate is
defined in 47 CFR 52.12(a)(1)(i), and the terms majority and debt are
defined in 47 CFR 52.12(a)(1)(ii).
* * * * *
0
13. Section 64.603 is amended by revising paragraph (a) to read as
follows:
Sec. 64.603 Provision of services
(a) Each common carrier providing telephone voice transmission
services shall provide, in compliance with the regulations prescribed
herein and the emergency calling requirements in part 9, subpart E of
this chapter, throughout the area in which it offers services,
telecommunications relay services, individually, through designees,
through a competitively selected vendor, or in concert with other
carriers. Interstate Spanish language relay service shall be provided.
Speech-to-speech relay service also shall be provided, except that
speech-to-speech relay service need not be provided by IP Relay
providers, VRS providers, captioned telephone relay service providers,
and IP CTS providers. In addition, each common carrier providing
telephone voice transmission services shall provide access via the 711
dialing code to all relay services as a toll free call. CMRS providers
subject to this 711 access requirement are not required to provide 711
dialing code access to TTY users if they provide 711 dialing code
access via real-time text communications, in accordance with 47 CFR
part 67.
* * * * *
0
14. Section 64.604 is amended by revising paragraphs (a)(4) and (d) to
read as follows:
Sec. 64.604 Mandatory minimum standards.
(a) * * *
(4) Emergency call handling requirements for TTY-based TRS
providers. TTY-based TRS providers are subject to the emergency call
handling requirements in Sec. 9.14(a).
* * * * *
(d) Other standards. The applicable requirements of Sec. Sec.
9.14, 64.611, 64.615, 64.617, 64.621, 64.631, 64.632, 64.5105, 64.5107,
64.5108, 64.5109, and 64.5110 of this part are to be considered
mandatory minimum standards.
Sec. 64.605 [Removed and Reserved]
0
15. Remove and reserve Sec. 64.605.
[[Page 54224]]
Subpart AA [Removed and reserved]
0
16. Remove and reserve Subpart AA, consisting of Sec. Sec. 64.3000
through 64.3004.
[FR Doc. 2018-21888 Filed 10-25-18; 8:45 am]
BILLING CODE 6712-01-P