Federal Communications Commission	FCC 19-76


Before the
FEDERAL COMMUNICATIONS COMMISSION
WASHINGTON, D.C. 20554


In the Matter of

Implementing Kari’s Law and Section 506 of RAY BAUM’S Act 

Inquiry Concerning 911 Access, Routing, and Location in Enterprise Communications Systems

Amending the Definition of Interconnected VoIP Service in Section 9.3 of the Commission’s Rules
)
)
)
)
)
)
)
)
)
)


PS Docket No. 18-261


PS Docket No. 17-239


GN Docket No. 11-117

REPORT AND ORDER

Adopted: August 1, 2019	Released: August 2, 2019

By the Commission: Chairman Pai and Commissioners O’Rielly and Carr issuing separate statements; Commissioners Rosenworcel and Starks approving in part, dissenting in part, and issuing separate statements.

TABLE OF CONTENTS
Heading	Paragraph #
I.	INTRODUCTION	1
II.	BACKGROUND	3
III.	DISCUSSION	14
A.	Direct Dialing and Notification for MLTS	14
1.	Direct Dialing	15
2.	Notification	17
3.	Definitions	44
4.	Compliance Date and Transition Provisions	97
5.	Enforcement	106
6.	Complaint Mechanisms	112
7.	Preemption of State Law	116
8.	Equipment Authorization Rules	120
9.	Voluntary Best Practices	123
10.	Comparison of Benefits and Costs	127
B.	Dispatchable Location for MLTS and Other 911-Capable Communications Services	137
1.	MLTS	138
2.	Fixed Telephony	170
3.	Interconnected VoIP	174
4.	Telecommunications Relay Services (TRS)	207
5.	Mobile Text	217
6.	Comparison of Benefits and Costs	221
C.	Consolidating the Commission’s 911 Rules	233
IV.	PROCEDURAL MATTERS	241
V.	ORDERING CLAUSES	245
APPENDIX A – Final Rules
APPENDIX B – Conversion Tables
APPENDIX C – Final Regulatory Flexibility Analysis 
APPENDIX D – List of Commenting Parties


I. INTRODUCTION 
1. In this Report and Order, we adopt measures to help ensure that members of the public can successfully dial 911 to request emergency services and that Public Safety Answering Points (PSAPs) can quickly and accurately locate every 911 caller, regardless of the type of service that is used to make the call.  We act today pursuant to two federal statutes: Kari’s Law Act of 2017, which requires implementation of direct 911 dialing and on-site notification capabilities in multi-line telephone systems (MLTS), Kari’s Law Act of 2017, Pub. L. No. 115-127, 132 Stat. 326 (2018) (codified at 47 U.S.C. § 623) (Kari’s Law).  Kari’s Law is named in honor of Kari Hunt, who was attacked and killed by her estranged husband in a motel room in Marshall, Texas in 2013.  Ms. Hunt’s 9-year-old daughter tried to call 911 for help four times from the motel room phone, as she had been taught to do.  The call never went through because she did not know that the hotel’s phone system required dialing “9” for an outbound line before dialing 911.  See FCC, Chairman Pai Statement on Passage of Kari’s Law (Feb. 6, 2018), https://apps.fcc.gov/edocs_public/attachmatch/DOC-349050A1.pdf.
 and Section 506 of RAY BAUM’S Act, which requires the Commission to “consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call, regardless of the technological platform used and including with calls from [MLTS].” Section 506 of the Repack Airwaves Yielding Better Access for Users of Modern Services Act of 2018 (RAY BAUM’S Act), Pub. L. No. 115-141, 132 Stat. 348, 1095 (codified at 47 U.S.C. § 615 note).

2. In particular, we adopt rules that implement the direct dialing and notification requirements of Kari’s Law and clarify the law’s application to both legacy MLTS and Internet Protocol (IP)-based systems, including cloud-based services, that support the communications needs of hotels, businesses, campuses, and other enterprises.  And we adopt rules that will facilitate timely emergency response and improved location accuracy across communications platforms.  These requirements are measured, technically feasible, and technologically neutral, so that providers can choose the most effective solutions from a range of options.  In addition, our requirements allow sufficient time for advance planning and deployment of new location technology.  Similar to the approach the Commission has taken in the wireless E911 context, we believe that “[c]lear and measurable timelines and benchmarks for all stakeholders are essential to drive the improvements that the public reasonably expects to see in 911 location performance.” Wireless E911 Location Accuracy Requirements, Fourth Report and Order, 30 FCC Rcd 1259, 1260, para. 4 (2015) (Indoor Location Accuracy Report and Order).  Consistent with RAY BAUM’S Act and the Notice, we do not modify the existing dispatchable location requirements applicable to Commercial Mobile Radio Service (CMRS) providers.  See Implementing Kari’s Law and Section 506 of RAY BAUM’S Act, Inquiry Concerning 911 Access, Routing, and Location in Enterprise Communications Systems, PS Docket Nos. 18-261 and 17-239, Notice of Proposed Rulemaking, 33 FCC Rcd 8984, 9007, para. 69 (2018) (Notice).   
  We also take this opportunity to consolidate our existing 911 rules, as well as the direct dialing and dispatchable location rules adopted today, into a single rule part.
II. BACKGROUND
3. Enhanced 911 (E911) was developed to provide PSAPs with the caller’s location and a call-back number as part of each 911 call. See Wireless Communications and Public Safety Act of 1999, Pub. L. No. 106-81, 113 Stat. 1286 (codified at 47 U.S.C. § 615a) (1999) (Wireless 911 Act).  The Wireless 911 Act defined “enhanced 9-1-1 service” as “the delivery of 9-1-1 calls with automatic number identification and automatic location identification, or successor or equivalent information features over the wireline E911 network (as defined in section 9.3 of the Federal Communications Commission’s regulations (47 C.F.R. 9.3) as of July 23, 2008) and equivalent or successor networks and technologies.”  See 47 U.S.C. § 615b(10).
  Since its implementation, most E911 calls have conveyed information regarding the caller’s location (with varying degrees of accuracy) and a call-back number to the PSAP.  These enhancements have significantly improved PSAPs’ ability to effectively deliver critical public safety and emergency response services in a timely manner.  In many instances, E911 has proven to be a life-saving, essential emergency response tool for providing critical information when the caller is unable to verbally communicate his or her location, including when the voice call is dropped or discontinued and cannot be reestablished.  
4. Under the Commission’s rules, consumers generally have access to these capabilities when they make fixed telephony, mobile, and interconnected VoIP calls to 911. See Framework for Next Generation 911 Deployment, Notice of Inquiry, 25 FCC Rcd 17869, 17875, para. 13 (2010) (NG911 Deployment NOI).   
  However, to date, the Commission’s E911 rules have not applied to MLTS.  Consequently, consumers in environments such as office buildings, campuses, and hotels may not have the same access to E911 services that is provided by fixed telephony, mobile, and VoIP systems, namely direct dialing access to 911 and the provision of the MLTS user’s location information. In 1994, for example, the Commission sought comment on amending its Part 68 rules to ensure the compatibility of PBX and other dispersed multi-line telephone systems with E911 services.  Revision of the Commission’s Rules to Ensure Compatibility With Enhanced 911 Emergency Calling Systems, Notice of Proposed Rulemaking, 9 FCC Rcd 6170, 6174, paras. 20-21 (1994).  The Commission ultimately deferred to states as to a decision on whether to require MLTS compliance with its enhanced 911 rules.  See Revision of the Commission’s Rules to Ensure Compatibility with Enhanced 911 Emergency Calling Systems, Report and Order and Second Further Notice of Proposed Rulemaking, 18 FCC Rcd 25340, 25363, paras. 53-54 (2003) (E911 Scope Order).

5. MLTS include a widely embedded base of legacy private branch exchange (PBX), Centrex, and Key Telephone systems, IP-based systems, and hybrid systems.  MLTS serve millions of employees, residents, and guests of businesses and educational facilities, including corporate parks, hotels, college campuses, and planned community developments. See Inquiry Concerning 911 Access, Routing, and Location in Enterprise Communications Systems, Notice of Inquiry, 32 FCC Rcd 7923, 7924-25, paras. 4-5 (2017) (Enterprise Communications NOI); see also West Safety Enterprise Communications NOI Comments at 8 (citing Frost & Sullivan, North American Hosted IP Telephony and UCaaS Market - Cloud Communications Solutions Evolve to Align with an API Economy at 4, 52 (Nov. 2016)).  
  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. See E911 Scope Order, 18 FCC Rcd at 25363, paras. 53-54.  The Commission expressed concern that lack of effective implementation of E911 capabilities for MLTS could be an unacceptable gap in the emergency call system.  However, the Commission declined to adopt federal rules requiring MLTS operators to implement E911, finding that state and local governments were in a better position to devise rules to ensure that E911 is effectively deployed over MLTS in their jurisdictions.  Id. at 25361, 25366, paras. 50, 62.

6. At least 23 states have enacted legislation that requires organizations over a certain size or purchasing a new PBX/MLTS system to implement E911 on the system. See Enterprise Communications NOI, 32 FCC Rcd at 7941, Appendix B; see also West Safety Enterprise Communications NOI Comments at 5 (stating that there are currently 23 states with MLTS-related laws).
  These states have adopted varied requirements for MLTS providers, and only in some instances have state laws specifically addressed prefix dialing requirements. See, e.g., 9-1-1 Enable, State-by-State E911 Legislation Summary, http://files.meetup.com/3299882/State-E911-Legislation-Summary.pdf (last visited July 10, 2019); West Corporation, MLTS E911 Regulations By State, https://www.west.com/legal-privacy/e911-regulations/#State_E911_Legislation (last visited July 10, 2019). 
  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. See Enterprise Communications NOI, 32 FCC Rcd at 7923-24, paras. 2-3.

7. Given that the ongoing evolution of MLTS has not eliminated these shortfalls when serving 911 callers, the Commission has periodically sought to examine MLTS provision of 911, including the capabilities of MLTS to support direct 911 access, routing, callback, and automatic location. For example, in 2012, pursuant to Section 6504(b) of the NG9-1-1 Advancement Act, the Public Safety and Homeland Security Bureau released a Public Notice seeking comment on (1) the feasibility of mechanisms for MLTS to “provide a sufficiently precise indication of a 911 caller’s location,” and (2) NENA’s model MLTS legislation.  Public Safety and Homeland Security Bureau Seeks Comment on Multi-Line Telephone Systems Pursuant to Next Generation 911 Advancement Act of 2012, Public Notice, 27 FCC Rcd 5329, 5329-32 (PSHSB 2012).
  In September 2017, the Commission released a Notice of Inquiry (Enterprise Communications NOI) seeking information on the capabilities of enterprise communications systems to support direct 911 access, routing, and automatic location. Enterprise Communications NOI, 32 FCC Rcd at 7924, para. 3.  In the Enterprise Communications NOI, the Commission noted that it had previously used the term “MLTS” to refer to various types of multi-line systems, but stated that in the Enterprise Communications NOI it would use the term enterprise communications systems to refer to the full range of networked communications systems that serve enterprises, including circuit-switched and IP-based systems.  See id. at 7924, n.2.  Both Kari’s Law and Section 506 of RAY BAUM’S Act use the term “MLTS” and define it to include IP-based as well as circuit-switched systems, making the statutory definition of MLTS essentially synonymous with the Commission’s definition of enterprise communications system.  Therefore, for purposes of consistency with the statutory language, in this Report and Order we use the term MLTS instead of enterprise communications system to refer to the full range of systems that serve enterprises, whether circuit- or IP-based, unless the context requires otherwise.   
  The Commission noted that such systems may not provide consumers with the same access to E911 services as other wireline, wireless, and interconnected VoIP calls and asked whether it is still the case, as the Commission found in earlier proceedings, that the needs and circumstances of residential and business enterprise communications system users are suited to state-level action rather than federal regulation. See Enterprise Communications NOI, 32 FCC Rcd at 7934, para. 38.
  The Enterprise Communications NOI also sought information on the state of the enterprise communications system industry; the costs and benefits of supporting E911 for enterprise communications system; the capability of enterprise communications system to provide accessible emergency communications for persons with disabilities; and options for ensuring that enterprise communications system keep pace with technological developments and consumer expectations for access to 911. See id. at 7929-36, paras. 17-43.

8. Kari’s Law was enacted on February 16, 2018. The President signed Kari’s Law into law on February 16, 2018, which was the 50th anniversary of the first 911 call in the United States.  See 47 U.S.C. § 623 and 623 note.  
  Kari’s Law establishes a federal multi-tiered approach to MLTS 911 requirements. The House of Representatives debated H.R. 582, the bill that was enacted as Kari’s Law Act of 2017, on Jan. 23, 2017.  The Congressional Record for that day includes a statement of the background and need for the legislation, as well as a section-by-section analysis of the bill.  See 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017). 
  First, Kari’s Law applies to any “person engaged in the business of manufacturing, importing, selling, or leasing” MLTS. 47 U.S.C. § 623(a).
  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.” Id.

9. Second, Kari’s Law applies to any “person engaged in the business of installing, managing, or operating” MLTS. Id. § 623(b).
  Such persons “may not install, manage, or operate for use in the United States such a system, unless such system is configured such that a user may directly initiate a call to 9-1-1 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit ‘9’, regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls.” Id.

10. Third, such persons “shall, in installing, managing, or operating such a system for use in the United States, configure the system to provide a notification to a central location at the facility where the system is installed or to another person or organization regardless of location, if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system.” Id. § 623(c).

11. Fourth, Kari’s Law expressly provides that Congress did not intend to “alter the authority of State commissions or other State or local agencies with jurisdiction over emergency communications, if the exercise of such authority is not inconsistent with this [Act].” Id. § 623(d).
  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.” Id. § 623(e).
  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. Id. § 623 note.
 
12. On March 23, 2018, shortly after Kari’s Law was enacted, the President signed the Consolidated Appropriations Act of 2018, including RAY BAUM’S Act, into law.  Section 506 of RAY BAUM’S Act requires the Commission to “conclude a proceeding to consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call, regardless of the technological platform used and including with calls from multi-line telephone systems” by September 23, 2019. See RAY BAUM’S Act, § 506(a).  
  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. See id. § 506(b).

13. In September 2018, following the enactment of Kari’s Law and RAY BAUM’S Act, the Commission proposed rules to implement Kari’s Law and to support dispatchable location for 911 calls from MLTS and other communications platforms. Notice, 33 FCC Rcd 8984 (2018).  The Commission received 34 comments from the following commenters:  ADT LLC d/b/a ADT Security Services (ADT); Alliance for Telecommunications Industry Solutions (ATIS); Association of Public-Safety Communications Officials-International, Inc. (APCO); AT&T Services, Inc. (AT&T); Ad Hoc Telecommunications Users Committee (Ad Hoc); American Cable Association (ACA); American Hotel and Lodging Association (AHLA); Avaya, Inc. (Avaya); Bandwidth Inc. (Bandwidth); BluIP, Inc. (BluIP); Boulder Regional Emergency Telephone Service Authority (BRETSA); Cisco Systems, Inc. (Cisco); Comtech Telecommunications Corp. (Comtech); Dave Moore; DECT Forum; Hamilton Relay, Inc. (Hamilton Relay); Metropolitan Emergency Services Board (a joint powers board of nine counties and the City of Minneapolis, MN) (MESB); Microsoft Corporation (Microsoft); National Association of State 911 Administrators (NASNA); National Public Safety Telecommunications Council (NPSTC); NCTA – The Internet & Television Association (NCTA); NENA: The 9-1-1 Association (NENA); NTCA – The Rural Broadband Association (NTCA); Panasonic Corporation of North America (Panasonic); RedSky Technologies Inc. (RedSky);  RingCentral, Inc. (RingCentral); Sorenson Communications, LLC (Sorenson); State of Florida Department of Management Services, Division of Telecommunications, Bureau of Public Safety (Florida Bureau of Public Safety); Telecommunications Industry Association (TIA); Texas 9-1-1 Alliance, the Texas Commission on State Emergency Communications, and the Municipal Emergency Communication Districts Association (Texas 9-1-1 Entities); USTelecom – The Broadband Association (USTelecom); Verizon; Voice on the Net Coalition (VON); West Safety Services, Inc. (West Safety).  The Commission also received 15 reply comments from the following commenters: Ad Hoc; ACA; BRETSA; Cisco; ClearCaptions, LLC (ClearCaptions); Comcast Corporation (Comcast); Comtech; INCOMPAS; Industry Council for Emergency Response Technologies (iCERT); RedSky; RingCentral; Sorenson and CaptionCall, LLC (CaptionCall); T-Mobile USA, Inc. (T-Mobile); TIA and DECT Forum; West Safety.  After the close of comments, ACA changed its name to ACA Connects. 
  Specifically, the Notice proposed to implement Kari’s Law by adopting direct dial and notification rules governing calls to 911 made from MLTS and clarifying the definitions associated with the law.  As required by RAY BAUM’S Act, the Commission also initiated this proceeding to consider the feasibility of requiring dispatchable location for 911 calls from MLTS and other technological platforms.  The Commission proposed dispatchable location requirements for MLTS 911 calls, which would apply contemporaneously with the February 16, 2020 compliance date of Kari’s Law, and proposed to add dispatchable location requirements to our existing 911 rules for fixed telephony providers, interconnected Voice over IP (VoIP) providers, and Internet-based Telecommunications Relay Services (TRS).  The Notice also considered the feasibility of alternative location mechanisms for MLTS and other services that could be used as a complement to dispatchable location or as a substitute when dispatchable location is not available.  Additionally, the Commission sought comment on whether dispatchable location requirements should be extended to other communications services that are not covered by existing 911 rules but are capable of making a 911 call.  Finally, the Notice proposed to consolidate the Commission’s existing 911 rules into a single rule part.  
III. DISCUSSION
A. Direct Dialing and Notification for MLTS
14. Because Congress incorporated Kari’s Law into the Communications Act of 1934, as amended (the Act), Notice, 33 FCC Rcd at 8991, para. 17.  
 the Commission has authority to prescribe such rules and regulations as are necessary to carry out Kari’s Law. See 47 U.S.C. § 201(b) (“The Commission may prescribe such rules and regulations as may be necessary in the public interest to carry out the provisions of this [Act].”); id. § 303(r) (stating that the Commission may “[m]ake such rules and regulations and prescribe such restrictions and conditions, not inconsistent with law, as may be necessary to carry out the provisions of this [Act]”); see also AT&T Corp. v. Iowa Utils. Bd., 525 U.S. 366, 383-85 (1999) (upholding the Commission’s rulemaking authority under section 201(b) of the Act). 
  The implementing regulations we adopt in this Report and Order are intended to provide additional clarity and specificity regarding the terms used in the statute and the obligations placed on covered entities.
1. Direct Dialing  
15. Kari’s Law provides that any person engaged in the business of manufacturing, importing, selling, or leasing an MLTS may not manufacture or import the MLTS for use in the United States, or sell or lease or offer to sell or lease it in the United States, unless it is pre-configured so that when properly installed, a user may directly initiate a call to 911 from any station equipped with dialing facilities. 47 U.S.C. § 623(a).
  In addition, any person engaged in the business of installing, managing, or operating an MLTS may not do so unless the MLTS is configured so that a user may dial 911 directly. 47 U.S.C. § 623(b).
  In the Notice, the Commission proposed rules that track these obligations. See Notice, 33 FCC Rcd at 8991, para. 18; see also id. at 9050, Appendix A, proposed rule § 9.16(a)(1), (b)(1) (proposed direct dialing obligations). 

16. We adopt the rules requiring direct dialing from MLTS generally as proposed in the Notice. See infra Appendix A, final rule § 9.16(a)(1), (b)(1).
  There is broad support among all types of commenters (industry and public safety entities) for the proposed direct dialing rules, although some commenters seek clarification of proposed definitions and other terms. See Ad Hoc Comments at 4-5; AHLA Comments at 3; APCO Comments at 2; Cisco Comments at 3; MESB Comments at 3, 8; Microsoft Comments at 7; Dave Moore Comments at 1; NASNA Comments at 1; NPSTC Comments at 4; RedSky Comments at 1; Verizon Comments at 2; West Safety Comments at 1; BRETSA Reply at iii (supporting the proposed rules generally, subject to state and local authority to approve broad and narrow exceptions); TIA and DECT Forum Reply at 14; see also Letter from James Bradford Ramsay, NARUC General Counsel, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261 et seq., at 2 (filed Sept. 18, 2018) (NARUC Ex Parte) (noting that NARUC has adopted a resolution supporting federal and state actions to require enterprise communications systems manufacturers, installers, and operators to design and configure systems to allow direct dialing of 911 and to support on-site notification). 
  The Texas 9-1-1 Entities state that the proposed rules “should generally be adopted as written.” Texas 9-1-1 Entities Comments at 6.
  Microsoft asserts that proposed direct dialing and notification requirements are consistent with Kari’s Law and should be reasonably achievable. Microsoft Comments at 7.
  No commenter opposes adoption of the direct dialing requirements.
2. Notification
17. Kari’s Law provides that any person engaged in the business of installing, managing, or operating an MLTS shall, in installing, managing, or operating such a system for use in the United States, configure the system to provide a notification to a central location at the facility where the system is installed or to another person or organization regardless of location, if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system. 47 U.S.C. § 623(c).
  Consistent with this obligation, the Commission in the Notice proposed rules providing that installers, managers, or operators must configure an MLTS to provide for transmission of a 911 notification if the system can be configured to do so without an improvement to the hardware or software of the system. See Notice, 33 FCC Rcd at 8991, para. 19, 9050, Appendix A, proposed rule § 9.16(b)(2); see also 47 U.S.C. § 623(c).  Although this section of Kari’s Law is titled “On-Site Notification,” the statute specifies that notice can be provided to an on-site location or to another person or organization “regardless of location.”  The section-by-section analysis of H.R. 582, which became Kari’s Law, notes that the statute “requires the system to designate a central point of contact, but allows the MLTS owner or operator some flexibility in determining the most appropriate contact, whether in the building or otherwise.”  See Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017).
  The Commission stated that notification will potentially benefit three parties:  (1) the 911 caller by speeding response time; (2) enterprise management and staff by providing needed information and reducing confusion and delay when emergency response teams arrive; and (3) first responders by reducing time spent responding to such calls. Notice, 33 FCC Rcd at 8991, para. 19.

a. Required Information and Purpose  
18. Kari’s Law requires an MLTS to support notification when an end user makes a 911 call, but it does not specify what information must be provided in the notification.  In the Notice, the Commission proposed to define “MLTS Notification” as follows: “An MLTS feature that can send notice to a central location at the facility where the system is installed or to another person or organization regardless of location.  Examples of notification include screen pops with audible alarms for security desk computers using a client application, text messages for smartphones, and email for administrators.  Notification shall include, at a minimum, the following information: (1) the fact that a 911 call has been made, (2) a valid callback number, and (3) the information about the caller’s location that the MLTS conveys to the public safety answering point (PSAP) with the call to 911.” Id. at 8992, para. 22, 9028, 9050-51, Appendix A, proposed rules §§ 9.16(b)(2), 9.3 (definition of MLTS Notification).

19. The Commission tentatively concluded that for notification to be capable of achieving the purpose of Kari’s Law, it should include basic information that will assist the enterprise and first responders in coordinating and expediting on-site response to the emergency. Id. at 8992, para. 21.
  The Commission also stated its intention for notification to include only information that is also conveyed to the PSAP with the initial call to 911, including the same dispatchable location information that the PSAP receives. Id. at 8992-93, para. 22.
  Because notification is intended to help the enterprise assist first responders, the Commission noted, it makes sense for the recipient of the notification to have the same information as the PSAP (and, indirectly, the first responders dispatched to the scene). Id. at 8993, para. 22.
  In addition, requiring the notification to convey only information that already exists for the 911 call would minimize the burden for enterprises to comply. Id. 

20. We adopt the proposal from the Notice with certain changes.  As proposed, we find that the notification should include the fact that a 911 call has been made, a valid callback number, and the same location information that is conveyed with the call to 911.  However, we provide an exception for callback number and location information in circumstances where including this information in the notification would be technically infeasible.  We also clarify that the callback number in the notification does not have to be a Direct Inward Dialing number to the 911 caller’s extension if one is not available.
21. Several commenters express support for the Commission’s proposed notification requirements. See APCO Comments at 1; BRETSA Comments at 1-2; Microsoft Comments at 7; NASNA Comments at 1; NPSTC Comments at 6; Texas 9-1-1 Entities Comments at 1, 6; Verizon Comments at 2; West Safety Comments at 3; NARUC Ex Parte at 2.
  APCO supports the Commission’s proposal provided that notification does not delay the call to emergency responders. APCO Comments at 2.
  Verizon states that the Commission’s proposed notification rule is straightforward and consistent with the statute’s focus and notes that the technical details of how the capability is implemented will vary among enterprise customers based on their size, resources, and the particular network configuration involved. Verizon Comments at 2-3.

22. We agree with commenters who contend that certain minimum content is necessary to ensure that notification serves the purpose intended for it, which is to help the enterprise provide assistance to first responders in the event of a 911 call. See APCO Comments at 2; NASNA Comments at 1-2; West Safety Comments at 4-5.  
  For example, NASNA states that the Commission “absolutely” should establish minimum content for the notification and that it should “require that what is sent to PSAPs be sent also to the notification center.” NASNA Comments at 2; see also West Safety Comments at 4 (“Requiring this minimal level of content in the notification aligns with the purpose of Kari’s Law and ensures enterprises will be fully equipped to assist 9-1-1 MLTS callers and first responders.”); NPSTC Comments at 6 (stating that requiring the recipient of the notification to have the same information as the PSAP would be “beneficial to public safety and the general public using 911”). 
  RedSky asserts that the notification should also include the date and time of the 911 call. RedSky Comments at 2.
  Avaya suggests that notification should include “details that may not be conveyed to the PSAP,” such as “location information that clearly establishes the location of the caller” and alerts with acknowledgement and escalation functions. Avaya Comments at 4.  
  
23. At the same time, we seek to provide enterprises sufficient flexibility to tailor the notification to best suit their needs.  In this respect, we note that some commenters urge the Commission to allow enterprises to determine the content of notifications as they see fit. Ad Hoc Comments at i, 5-6; Cisco Comments at 13-14; Panasonic Comments at 13-17; TIA Comments at 11-12; Comcast Reply at 2-3; TIA and DECT Forum Reply at 6-7.
  Panasonic, for example, states that businesses should have the flexibility to customize notifications to meet their needs, given their understanding of the physical nature of their enterprise, the technical capabilities of their system, and the personnel who will be involved in assisting with an emergency response, including on-site private emergency response teams in some cases. Panasonic Comments at 14; see also Ad Hoc Comments at 3 (urging the Commission not to adopt “heavy-handed, ‘one size fits all’ regulations that interfere with MLTS operators’ discretion to design and implement the most effective safety policies for their companies’ workforces”).
  
24. In the absence of direction in the statutory language about what the required notification should contain, we are also mindful of Congress’s stated intent to “balance the need for an onsite notification with the goal of not placing an undue burden on MLTS owners or operators.” Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017).
  Reflecting this flexible approach, we define MLTS Notification as: “An MLTS feature that can send notice to a central location at the facility where the system is installed or to another person or organization regardless of location.  Examples of notification include conspicuous on-screen messages with audible alarms for security desk computers using a client application, text messages for smartphones, and email for administrators.  Notification shall include, at a minimum, the following information: (1) the fact that a 911 call has been made, (2) a valid callback number, and (3) the information about the caller’s location that the MLTS conveys to the public safety answering point (PSAP) with the call to 911; provided, however, that the notification does not have to include a callback number or location information if it is technically infeasible to provide this information.” See infra Appendix A, final rule § 9.3 (definition of MLTS Notification).

25. Commenters raise concerns regarding the inclusion of a callback number and location information in the notification. AHLA Comments at 3-4; Cisco Comments at 13-14; Cisco Reply at 6-7; Panasonic Comments at 16-17; TIA Comments at 11-12; TIA and DECT Forum Reply at 7.
  Cisco, Panasonic, and TIA note that Kari’s Law does not specifically require a callback number or location information in the notification. Cisco Comments at 14; Panasonic Comments at 16; TIA Comments at 11.  TIA asserts that “Kari’s Law requires a notification that a 911 call has been placed, and no more.”  Id.
  Cisco states that the callback number and location information conveyed in a notification can vary based on the technology deployed in the enterprise, so the Commission should ensure that this rule provides MLTS managers sufficient flexibility to determine the contents of the notification. Cisco Comments at 13-14; see also TIA Comments at 11 (urging the Commission to provide enterprises flexibility to determine the form and content of notifications without “overly prescriptive requirements concerning a callback number or location”). 
  Several commenters note that providing a callback number that reaches the 911 caller’s specific phone is not possible in some enterprises because there is no Direct Inward Dialing phone number associated with the MLTS endpoints. AHLA Comments at 3-4; Cisco Comments at 13-14; Panasonic Comments at 16-17; TIA Comments at 11-12; Cisco Reply at 7; TIA and DECT Forum Reply at 7.  TIA notes, for example, that “[p]roviding a callback number to a specific station is difficult—even impossible—in certain situations, such as enterprise calling platforms that are not supported by Direct Inward Dialing . . . numbers.”  TIA Comments at 11.  Similarly, AHLA states that providing a callback number to the specific phone that dialed 911 may not always be possible in the context of hotels, and BluIP states that some hotels as a matter of policy may not wish to enable direct outside calling to rooms.  AHLA Comments at 3; BluIP Comments at 6.
  Some commenters also point out that providing the caller’s location in the notification may not be necessary or helpful in the case of enterprises that are small or have an open workspace. See AT&T Comments at 4 (stating that notification “would serve little purpose in an office where all employees sit in a single small room”); NCTA Comments at 4 (stating that “[a] person working in an office with a four-line system does not require an automated notification to know that a 911 call has been placed by a colleague and the source of the emergency”); Panasonic Comments at 14 (stating that flexibility in customizing the notification is particularly important for small businesses, which “are more likely to be able to assist emergency responders with locating a caller than a large enterprise”); RedSky Comments at 4 (stating that the benefits of notification would be reduced at “a garden center which is open to the public and has good visibility to all areas of the facility”); VON Comments at 11 (stating that at a small business, the staff “would be aware of the call and the location of the caller”).  

26. We therefore provide an exception for callback number and location information in circumstances where including this information in the notification would not be technically feasible.  We agree with commenters who assert that there may be MLTS solutions for which it is not technically feasible to include this information in the notification.  For example, commenters point out that providing a callback number that reaches the 911 caller’s specific phone is not possible in some enterprises because there is no phone number associated with the MLTS endpoints.  Accordingly, we clarify that the callback number, if provided, need not be a Direct Inward Dialing number to the 911 caller’s extension if a Direct Inward Dialing number is not available.  This means, for example, that if the 911 call comes from a non-Direct Inward Dialing number, the callback number in the notification can be an internal extension that can be directly reached from inside the enterprise but not from outside it. See Cisco Comments at 14.
  Similarly, a hotel that does not provide a Direct Inward Dialing line to each guest room can provide the number of a central location, such as the front desk, in the notification. See AHLA Comments at 7. 
  Notwithstanding that each of these MLTS notification examples would include callback number information in lieu of a Direct Inward Dialing number to the 911 caller, we reiterate that omission of callback number information in the notification is acceptable if it is technically infeasible to provide such information. Likewise, the omission of the caller’s location information in the MLTS notification is acceptable if it is technically infeasible to provide such information.  TIA and DECT Forum state that “specifics that must be included in a notification, such as . . . a street address, . . . will not be practicable in all scenarios.”  TIA and DECT Forum Reply at 7.  TIA and DECT Forum state that, for example, “wireless off-premises VoIP solutions can create an issue where a caller’s location information may match a central office, rather than the remote location where the employee is actually working.”  Id.
 
27. We also adopt BRETSA’s suggestion to replace the term “screen pops” from the Notice with “conspicuous on-screen messages,” which we find to be clearer.  And we reject BRETSA’s suggestion that the Commission revise the beginning of the definition of MLTS Notification to read, “[a]n MLTS feature that can send notice that a call has been placed to ‘9-1-1’ from an MLTS station, to a central location at the facility where the system is installed or to another person.” BRETSA Comments at 8 (emphasis in original to show suggested additions).  
  We decline to add this language because we believe the reference to the required content of the notification later in the definition makes clear that notification includes the fact that a call to 911 has been made.
28. Because our requirements set a minimum, enterprises may add other information to the notification as useful and appropriate.  This may include, for example, the occupancy status of a hotel room, or the specific location of an IP device. See, e.g., Avaya Comments at 2-3; BluIP Comments at 4; 
  Enterprises are free to include such information in the notification as they see fit, so long as the notification includes the required elements.  Although the additional information Avaya proposes for the content of the notification may be helpful for some enterprises, we do not believe it would be appropriate for all enterprises, particularly smaller businesses.  We also do not have a sufficient record to determine whether to adopt date and time of the 911 call as required elements of the notification, as RedSky suggests, RedSky Comments at 2.
 although we encourage enterprises to include this information at their discretion.  We also encourage the development of voluntary best practices and employee training to prepare enterprises for responding to receipt of notification that a 911 call has been made. We note that it may not be advisable for the recipient of the notification to dial the callback number in some situations, such as when the PSAP may be trying to reconnect to the 911 caller after a dropped call.
  For instance, training could include the circumstances under which the notice recipient (or someone else at the enterprise) should dial the callback number included with the notification. Calls to 911 may include voice, text (including real-time text), data, video, and text telephone.  Therefore, best practices should include dialing any callback number using the same method the caller used to contact 911.  For instance, if the caller used text-based communications such as Real-Time Text to call 911, a text-based method should be used to contact the caller.

29. Finally, BRETSA asserts that PSAPs and first responders should determine the notification and location information provided by the enterprise, with a process for state and local public safety authorities to waive the Commission’s MLTS rules where reasonable and appropriate. BRETSA Reply at 14-17.
  We decline to find that state and local public safety agencies have authority to waive the Commission’s rules, as BRETSA requests.  Requests for such waivers should, as with other Commission requirements, be presented to the Commission.  
b. Notification Timing  
30. Kari’s Law is silent on when the notification must be provided.  The Commission proposed to require that MLTS covered by Kari’s Law be configured so that notification is contemporaneous with the 911 call and does not delay the placement of the call to 911. Notice, 33 FCC Rcd at 8993, para. 23, 9050, Appendix A, proposed rule § 9.16(b)(2).
  Most commenters that address this issue support the Commission’s proposal. See Avaya Comments at 4; NASNA Comments at 2; NENA Comments at 2; Panasonic Comments at 14; West Safety Comments at 4-5. 
  
31. We adopt the timing requirement as proposed but clarify that initiation of the notification must be contemporaneous with the call to 911. See infra Appendix A, final rule § 9.16(b)(2)(i).
  As RedSky points out, notification can occur in many forms, including SMS text messages, email, screen display, and conference calls, and the delivery of text messages and email is not within the control of the MLTS provider or the MLTS user. RedSky Comments at 3.
  Accordingly, RedSky asks the Commission to clarify that initiation of the notification must be contemporaneous with connection of the emergency caller to the PSAP. Id.
  We concur.  The record shows the importance of timely notification.  According to NENA, “[n]otification contemporaneous with the 9-1-1 call has significantly greater value to all parties than after-the-fact notification, and the majority of a notification’s benefits to response are lost if the notification is not conveyed in real-time.” NENA Comments at 2.
  
32. We also note Ad Hoc’s concern that some enterprise owner/operators of MLTS currently report challenges in configuring MLTS equipment to provide contemporaneous notification in addition to placing the call to 911 emergency services. Ad Hoc Reply at 4. 
  As a result, Ad Hoc states, the Commission should condition its proposal for the timing of notification on what is “technically feasible.” Ad Hoc Comments at 6; Ad Hoc Reply at 4.
  We condition this requirement on the technical feasibility of providing contemporaneous notification, as Ad Hoc requests. See infra Appendix A, final rule § 9.16(b)(2)(i).
  
c. Notification Destination Points   
33. The Commission also sought comment in the Notice on whether there should be any requirements relating to the location, configuration, or staffing of notification destination points. Notice, 33 FCC Rcd at 8993, para. 24.
  Kari’s Law states that the notification may be provided either to a “central location at the facility where the system is installed” or to “another person or organization regardless of location.” 47 U.S.C. § 623(c).
  The Commission noted that this language indicates Congress’s recognition that in the enterprise settings where MLTS are typically used, providing someone other than the PSAP with notice of the call can be critical to helping first responders gain timely access. Id.
  At the same time, the language “regardless of location,” as illuminated by legislative history, indicates that Congress sought to provide MLTS installers, managers, and operators with broad flexibility in selecting destination points to achieve this goal. The legislative history of Kari’s Law also states that the notification provision of the statute “requires the system to designate a central point of contact, but allows the MLTS owner or operator some flexibility in determining the most appropriate contact, whether in the building or otherwise.”  Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017). 
  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. Notice, 33 FCC Rcd at 8993, para. 24.

34. The Commission sought comment on whether it should specify criteria for destination points to ensure that notifications are likely to be received by someone able to take appropriate action to facilitate or assist the 911 response. Id. at 8993, para. 25.
  Where on-site notification to a “central location” is provided, the Commission asked whether it should specify that the destination point must be a location that is normally staffed or, alternatively, a location where on-site staff are likely to hear or see the notification.  The Commission noted that this approach would afford flexibility to direct the on-site notification to a security guard or facilities manager, to personnel who are otherwise employed and can support monitoring notifications as part of existing duties, or to an on-site location where staff are normally present. Id.
  
35. We adopt a requirement that notifications be sent to a location on-site or off-site where someone is likely to hear or see the notification. See infra Appendix A, final rule § 9.16(b)(2)(i).
  Some commenters urge the Commission to establish criteria for notification destination points, See NASNA Comments at 2; BRETSA Reply at 17.
 while others urge the Commission to preserve flexibility for the enterprise. See Ad Hoc Comments at 7-8; AHLA Comments at 7-8; BluIP Comments at 4; Panasonic Comments at 13-14; Verizon Comments at 2-3.  
  In this respect, we note NASNA’s assertion that notification “absolutely” should be to a location that is normally staffed or where staff are likely to hear or see the notification and that “[t]o do otherwise would undermine the purpose of the notification requirement.”  NASNA Comments at 2.
  We agree with NASNA that the Commission should set some criteria for notification destination points to help ensure that they serve the purpose of Kari’s Law.  
36. The requirement we adopt preserves flexibility for the enterprise to select an appropriate destination point.  For instance, we recognize AHLA’s suggestion that “[h]ow an individual hotel determines to send a notification (via text message, a separate call or email), to whom the notification is sent, and where the recipient is at the time of receipt should be at the discretion of the hotel.  For example, a hotel with a single on-duty employee overnight should not be required to send notification to a desk that may not be manned; a text message to the employee’s mobile device might be more appropriate.” AHLA Comments at 7-8.  AHLA also urges the Commission to bear in mind that “not every hotel is a ‘large enterprise’ with multiple on-site personnel at all hours” and states that the Commission should “afford flexibility to hotels consistent with their operational reality.”  Id. at 8.
  Our requirement would allow a hotel such as the one described by AHLA to send a text message to the overnight employee’s mobile device. The definition of MLTS notification we adopt does not specify any particular form for the notification and states that examples of notification include “conspicuous on-screen messages with audible alarms for security desk computers using a client application, text messages for smartphones, and email for administrators.”  See infra Appendix A, final rule § 9.3 (definition of MLTS notification).    
 
37. In addition, we do not require that the notification point be continuously staffed or monitored, only that it be a location where someone is likely to see or hear the notification.  The legislative history of Kari’s Law provides that the statute “seeks to balance the need for an onsite notification with the goal of not placing an undue burden on MLTS owners or operators.” Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017).
  Consistent with this, the Commission in the Notice stated that it did not believe Congress intended to impose staffing or monitoring requirements that would generate unreasonable costs, such as the need to hire additional staff, or limit the flexibility of MLTS installers, managers, and operators to develop cost-effective notification solutions to meet their particular needs. Notice, 33 FCC Rcd at 8994, para. 26.
  Based on the record before us, we adopt a requirement with which we intend to strike an appropriate balance between the increased benefits from having notifications sent to a location where they are likely to be received (e.g., increased chances of assistance for first responders) and the increased costs that are likely to result if we were to adopt a less flexible approach (e.g., increased staffing costs).
38. In the Notice, the Commission also asked whether, in the case of off-site notification, it should require that notification be to a person or organization that is authorized to provide first responders with access to the location from which the MLTS 911 call originated. Id. at 8993, para. 25.
  The Commission noted that this would allow notification to be directed to any offsite location, as the statute clearly allows, while furthering the statute’s objective of facilitating access to first responders answering a 911 call. Id.
  
39. We agree with Ad Hoc that requiring such notification may not make sense in all situations, such as where the enterprise does not control access to the premises or where access to the premises is unrestricted. Ad Hoc Reply at 6.  Because we decline to make this requirement mandatory, we find it unnecessary to reach Ad Hoc’s argument that the Commission lacks legal authority or expertise to adopt it.  Ad Hoc Comments at 7-8.  
  We nonetheless encourage enterprises using the off-site notification option to choose someone who can assist first responders in gaining access to the facility if it is feasible to do.  As suggested by NENA’s comments, it is a best practice for notification to go to whomever “has the keys” if a campus or building has restricted access and to whomever has any specialized knowledge of the facility layout that may assist public safety in locating and responding to a 911 call. NENA Comments at 3.  NASNA states that an off-site notice recipient should be authorized to provide first responders with access to the caller’s location and that “[t]o do otherwise would negate the purpose of the notification requirement, which is to get help to the caller.  If the person receiving the notification lacks authority to facilitate the response, the net effect would be as though no notification had been provided at all.”  NASNA Comments at 2.
  And we encourage the development of voluntary best practices and training for enterprise personnel, including designated notice recipients, so that they are prepared to assist first responders in the event of an emergency call.
d. No Exemptions to Notification Requirement
40. In the Notice, the Commission noted that large enterprises such as hotels, hospitals, and schools frequently have on-site personnel that control access to the premises, and notification of 911 calls to such personnel can improve outcomes by enabling them to assist first responders in accessing the premises and reaching the caller’s location. See Notice, 33 FCC Rcd at 8994, para. 27.
  The Commission sought comment on applying the statute’s notification requirements to all MLTS operators, including small enterprises, and sought comment on whether the benefits and costs of notification apply differently to small businesses than large enterprises such as hotels, hospitals, and schools. See id.
  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. See id.; see also Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017) (stating that notification “can be particularly important in large buildings like hotels, hospitals, and schools, where on-site personnel are uniquely suited to provide information about the building and its occupants”).
  The Commission also asked whether small enterprises using MLTS may find benefits to notification in addition to access and support, such as the ability for the enterprise to intervene when 911 is dialed in error and avoid sending emergency responders to a location that does not require a response. See Notice, 33 FCC Rcd at 8994, para. 27.

41. Commenters are divided on whether the Commission should provide a small business exemption for the notification requirements of Kari’s Law.  NASNA states that the benefits of notification are the same for a small business as for a large one and that small businesses should know that a 911 call was made from their MLTS so they are not surprised when first responders arrive and can assist if needed, including canceling the response if it turns out that 911 was dialed in error. NASNA Comments at 2.
  Other commenters support a small business exemption, although their specific proposals for an exemption differ. See AT&T Comments at 4-5; NCTA Comments at 5; Panasonic Comments at 14; RingCentral Comments at 8; VON Comments at 11-12; Comcast Reply at 3.
  RedSky, for example, argues that not every enterprise using an MLTS should be required to have emergency call notification, “let alone staff to receive a notification,” and that there are many circumstances where there is no one to consume the data and react. RedSky Comments at 3.  RedSky cites as an example a college with no public safety department that occupies 50 buildings and states that “[f]orcing the college to install and maintain a display in each building that provides the same data the PSAP already has is unnecessary.”  Id.  But see BRETSA Reply at 17 (stating that dormitories will typically have resident advisors or equivalent student representatives, and other buildings will have administrative personnel to whom notifications can be provided).
  Proposed criteria for defining an exemption generally include limits on square footage or the number of lines used at a single location. See, e.g., AT&T Comments at 5 (asserting that businesses under 40,000 square feet should be exempt from the notification rules and should only be required to provide a street address as the dispatchable location); RingCentral Comments at 8 (urging the Commission to clarify that the notification and dispatchable location rules apply only to MLTS deployed at single locations that have 50 or more lines, where the MLTS owner controls the network); VON Comments at 11-12 (stating that notification should not be required for MLTS with under 50 lines located on one floor in a contiguous workspace of less than 40,000 square feet); Comcast Reply at 3 (stating that businesses under 40,000 square feet should be exempt from the notification requirement, and the Commission should clarify that the definition of MLTS is limited to systems with 10 or more lines); see also NCTA Comments at 5 (stating that the Commission should exclude very small systems from the definition of MLTS, and it should exclude systems with fewer than ten lines from the notification obligation and consider adopting a business size exemption); Panasonic Comments at 14 (stating that the Commission is “right to seek to minimize the burden of notification requirements for small business”); VON Comments at 12 n.53; Letter from Glenn S. Richards, Counsel for VON, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, at 2 (filed May 24, 2019) (VON Ex Parte) (stating that “[t]he Commission should adopt exemptions from proposed notification requirements for small businesses and business with distributed workforces”).
  In turn, RingCentral and VON urge the Commission to limit the notification requirement to on-site calls and not to require notification for 911 calls from distributed workforces, i.e., those spread out over a large geographic region and relying on MLTS to centralize communications. See RingCentral Comments at 3-4; VON Comments at 12 n.53; VON Ex Parte at 2. 
  
42. We decline to adopt a small business exemption because we agree with NASNA that small businesses should receive notice of 911 calls that have been made from their MLTS so that they can prepare for the arrival of first responders and assist if needed.  We also decline to provide an exception to the location information requirement for enterprises that are small or have an open workspace, as some commenters suggest. See, e.g., NCTA Comments at 4, VON Comments at 11-12. 
  We believe location information will be helpful even at a small business because it will confirm the caller’s location for the notice recipient, who may be at an offsite location.  In addition, the burden of providing this information should be minimal.  We note that Kari’s Law does not provide an exemption for small businesses—nor one for MLTS operators that are not always staffed.  In addition, the requirements we adopt for notification are highly flexible and give small businesses significant latitude to configure suitable notification mechanisms without unreasonable burden or cost.
43. We also disagree with RingCentral and VON that notification as a rule is unlikely to be helpful at remote or satellite locations served by an MLTS.  Rather, we agree with BRETSA that limiting application of the rules to only specific types of MLTS would distort the market by favoring newer technologies, notwithstanding that callers to 911 are no less impacted by failures of MLTS using those technologies to provide notification (and interior location information) than MLTS using other technologies. BRETSA Reply at 13.
  Indeed, we disagree with arguments that whenever an MLTS is used off-site, notification is not useful.  Although RingCentral states that it has many customers that provide centralized phone numbers and extensions for a workforce that is working from home, the road, remote offices, or a mix of these locations, RingCentral Comments at 4.
 the fact that a “centralized location may be miles or states away from the emergency and have no special knowledge of the location where the emergency arose” RingCentral Comments at 4; see also Comcast Reply at 6 (stating that the notification requirement should extend only to 911 calls placed from a telephone at the location where the MLTS facilities have been installed, and any notification capability for users that are located off-site should be determined by the MLTS customer).
 is irrelevant—Congress recognized that notifications have value “regardless of location,” and it is not hard to recognize that having a centralized notification system could aid these multi-homed workers in reaching emergency services.  Similarly, we disagree with VON that “a 911 call placed by a person working from a satellite office would trigger a notification to someone at the central office, who would not be able to aid first responders when they arrive at the satellite office or otherwise speed first responder response time,” VON Comments at 12 n.53.
 because someone at a staffed central office may nonetheless aid remote first responders by, for example, alerting other personnel at the location of the emergency.  Although there may be corner cases in which notification is not in fact helpful, we decline on this record to exempt any particular category of MLTS facilities from the notification requirements as a matter of policy (not to mention that Kari’s Law itself draws no such lines).
3. Definitions
a. Definition of Multi-line Telephone System
44. Kari’s Law and RAY BAUM’S Act define the term “multi-line telephone system” by cross-referencing the definition in the Middle Class Tax Relief and Job Creation Act of 2012. See 47 U.S.C. § 623(f); RAY BAUM’S Act, § 506(a).
  That Act, in turn, defines an MLTS as:
a system comprised of common control units, telephone sets, control hardware and software and adjunct systems, including network and premises based systems, such as Centrex and VoIP, as well as PBX, Hybrid, and Key Telephone Systems (as classified by the Commission under part 68 of title 47, Code of Federal Regulations), and includes systems owned or leased by governmental agencies and non-profit entities, as well as for profit businesses. 47 U.S.C. § 1471(2). 

45. In the Notice, the Commission proposed to interpret this definition to include “the full range of networked communications systems that serve enterprises, including circuit-switched and IP-based enterprise systems, as well as cloud-based IP technology and over-the-top applications.” Notice, 33 FCC Rcd at 8994, para. 29. 

46. The Commission also proposed in the Notice to interpret the definition of MLTS to include enterprise-based systems that allow outbound calls to 911 without providing a way for the PSAP to place a return call (outbound-only calling service). Id.
  The Commission stated that it believed requiring direct dialing for any MLTS that allows the user to call 911, regardless of whether the system also allows the PSAP to make a return call, would advance the purpose of Kari’s Law. Id. at 8994-95, para. 29.
  In addition, the Commission stated, there is nothing in the language of the definition of MLTS from the Middle Class Tax Relief and Job Creation Act of 2012 that excludes systems allowing only outbound calls to 911. Id. at 8995, para. 29.

47. The record is divided over the Commission’s proposed definition of MLTS.  Some commenters support the proposal, See AT&T Comments at 6; Avaya Comments at 6; Florida Bureau of Public Safety Comments at 1; NASNA Comments at 2; RedSky Comments at 5-6; West Safety Comments at 5; BRETSA Reply at 12-13.
 while others oppose the Commission’s proposed interpretation. See TIA Comments at 8; VON Comments at 10-11; VON Ex Parte at 2.
  Commenters, however, generally support the Commission’s proposed interpretation of the definition of MLTS to include outbound-only calling services, citing consumer expectations and the need for regulatory parity among services. AT&T Comments at 6; Avaya Comments at 6; RedSky Comments at 6; West Safety Comments at 5; BRETSA Reply at iii, 24; see also APCO Comments at 8 (stating that for communications platforms that may appear functionally identical to consumers, the Commission should ensure consistency in capabilities such as location information conveyed with the call and ability to access 911).  

48. As proposed in the Notice, and consistent with the statutory definition, we interpret the definition of MLTS to include the full range of networked communications systems that serve enterprises, including circuit-switched and IP-based enterprise systems, as well as cloud-based IP technology and over-the-top applications.  West Safety endorses this approach and states that the statutory definition of MLTS is sufficiently broad to encompass the full range of enterprise communications systems, including “legacy TDM MLTS, hybrid MLTS and IP MLTS systems and software,” as well as “any and all endpoints supported by MLTS including mobile and smart devices, softphone clients, over-the-top (OTT) applications and outbound-only calling services.” West Safety Comments at 5.
  RedSky similarly states that the term MLTS “should not be limited to any specific type of end point device” because the technology is constantly evolving. RedSky Comments at 5-6.  RedSky adds that its customers use a mix of physical devices, including telephones and multi-media devices, as well as soft phones that can be deployed and function without a telephone set.  RedSky Comments at 39-40.
  We agree. 
49. TIA and VON, however, oppose the Commission’s proposed interpretation. See TIA Comments at 8; VON Comments at 10-11; VON Ex Parte at 2.
  TIA asserts that if Congress had intended its definition to capture “the full range” of all technologies in the enterprise communications marketplace, including over-the-top applications, it could have done so in the definition. TIA Comments at 8.
  Instead, TIA asserts, “the definition refers by name to numerous traditional MLTS technologies and points to Part 68 of the FCC’s rules—regulations established decades ago to govern interconnection with the PSTN [public switched telephone network] for traditional telephony services.” Id. 
  TIA adds that “[t]he Commission is right to think about the modern enterprise communications market which has certainly expanded beyond traditional locally-hosted PBX systems, but it should not expand the scope of Kari’s Law as intended by Congress.” Id.  TIA also states that the Notice’s proposed definition is not consistent with the Commission’s historic understanding of MLTS as describing a physical network that allowed businesses the opportunity to use multiple lines on-site within an enterprise.  Id.  TIA states that in the Enterprise Communications NOI, the Commission noted that MLTS “historically denoted systems that use circuit-switched telephone technology to support enterprise voice communications” and may “not capture the full array of existing and emerging IP-based enterprise systems, including cloud-based systems.”  As a result of that understanding, “the Commission determined it was necessary to propose a new definition of enterprise communications system . . . to capture ‘the full range of networked communications systems that serve enterprises.’  Thus, just over a year ago, the Commission understood that the term MLTS did not capture all forms of enterprise communications.  This does not square with the proposed interpretation in the NPRM and nothing about Kari’s Law or RAY BAUM’S Act addresses the definitional deficiency.”  Id. at 8-9.  We disagree that the Commission’s use of the term “enterprise communications system” in the Enterprise Communications NOI constituted agency precedent on the meaning of the term MLTS under 47 U.S.C. § 1471.  Even if it were precedent on this point, however, we disagree with TIA’s limited view of the definition of MLTS.  Specifically, the Commission explained in the Enterprise Communications NOI that it was introducing the term enterprise communications system to underscore its intention for the Enterprise Communications NOI to address new and emerging MLTS technologies, as well as older forms of MLTS.  See Enterprise Communications NOI, 32 FCC Rcd at 7924 n.2.  The Commission also used the term throughout the Enterprise Communications NOI, including in its summary of the statute that added section 1471(2) to the Act.  This shows that the Commission, for purposes of that proceeding, viewed the terms “enterprise communications system” and “all MLTS” (regardless of the age or type of technology) as synonymous.  See id. at 7926-28, paras. 8-13 (summarizing “Previous Commission Proceedings Related to E911 Service for [enterprise communications systems]”).  As intervening legislation and the initiation of this proceeding prompted the Commission to observe:
Both Kari’s Law and Section 506 of RAY BAUM’S Act use the term “MLTS” and define it to include IP-based as well as circuit-switched systems, making the statutory definition of MLTS essentially synonymous with the Commission’s definition of [enterprise communications systems].  Therefore, for purposes of consistency with the statutory language, in this Notice we use the term MLTS instead of [enterprise communications systems] to refer to the full range of systems that serve enterprises, whether circuit- or IP-based, unless the context requires otherwise.
Notice, 33 FCC Rcd at 8987 n.15. 
  VON states that as proposed, the term could cover any business with more than one line using a cloud PBX and could therefore essentially turn any interconnected VoIP service into MLTS (or vice versa), contrary to the plain intent of Kari’s Law. VON Comments at 10.  
  VON adds that this point becomes clearer when compared with RAY BAUM’S Act, which directs the Commission to “consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call, regardless of the technological platform used and including with calls from [MLTS].”  In contrast, VON states, Kari’s Law does not discuss other technological platforms, and as a result, “the NPRM’s proposed interpretation of MLTS goes farther than the law allows, and should be limited to those systems provided for in 47 U.S.C. 1471.” Id. at 10-11; see also VON Ex Parte at 2 (stating that the Commission “should adopt the definition of Multiline Telephone Systems in the legislation; not the more expansive definition proposed in the Notice of Proposed Rulemaking”).
  Cisco and Panasonic note that the statutory definition of MLTS does not refer to the terms “cloud-based IP technology” and “over-the-top applications” and state that it is not clear Congress envisioned such a broad interpretation of the term. Cisco Comments at 8; Panasonic Comments at 10.  Cisco also notes that the statutory definition includes a reference to “premises based systems” but does not refer to “off-premises” systems.  Cisco Comments at 8. 

50. We disagree with these commenters.  In particular, we note that the statutory definition also refers to VoIP, which is a newer technology, and introduces the reference to VoIP with the term “such as.”  The statute thus cites VoIP (and other technologies) as examples but not as limitations on the definition.  If Congress had intended a more constrained view of the technologies that fall within the definition of MLTS, it would have stated that MLTS “consists of” or is “limited to” certain technologies.  In addition, the statutory language refers broadly to a “system comprised of common control units, . . . control hardware and software and adjunct systems, including network and premises-based systems.” 47 U.S.C. § 1471(2).
  We find that this language broadly includes cloud-based IP technology and over-the-top applications.  Further, there is no language in the statute specifically excluding cloud-based IP technology and over-the-top applications from the definition of MLTS.
51. We also believe interpreting the definition of MLTS broadly is consistent with the intent of Kari’s Law.  The enterprise market has already seen significant migration away from traditional MLTS and toward IP-based and cloud-based systems, See TIA Comments at 4 (stating that in addition to legacy, on-premises PBX, Centrex, and Key Telephone Systems, MLTS systems are now increasingly hosted in the cloud, web-based, and IP-enabled); TIA and DECT Forum Reply at 11 (stating that in the MLTS marketplace, newer technologies similar to VoIP or cloud-based technologies are growing in availability and popularity over traditional wireline options); see also Notice, 33 FCC Rcd at 8987, para. 8 (noting that enterprises are increasingly relying on IP-based systems, including cloud-based services, to support their communications needs).   
 and Kari’s Law applies only to systems that are manufactured or brought into use after February 16, 2020.  It is unlikely that Congress would seek to address the problems of direct dialing and notification for MLTS only with respect to traditional, non-IP-based MLTS technologies, which represent a declining share of the MLTS market. See also 163 Cong. Rec. H590 (daily ed. Jan. 23, 2017) (statement of Rep. Sheila Jackson Lee) (“The goal of H.R. 582 is to ensure that all emergency calls regardless of the source are routed properly to emergency services.”).
  With respect to VON’s assertion that the reference to other “technological platform[s]” in RAY BAUM’S Act shows that the definition of MLTS should be interpreted narrowly under Kari’s Law, we disagree.  We interpret the reference to technological platforms in RAY BAUM’S Act as a direction for the Commission to include other services, such as interconnected VoIP, TRS, and fixed telephony, in its consideration of dispatchable location rules.  We do not interpret it as a limitation, explicit or implied, on the meaning of MLTS under Kari’s Law.
52. We also interpret the definition of MLTS to include outbound-only calling systems. The Texas 9-1-1 Entities state that “based on questions that we continue to receive regarding the state law version of Kari’s Law in Texas, if it is the Commission’s intent to preclude MLTS from being configured to not allow outbound calls (including calls to 9-1-1) as opposed to requiring MLTS that allow outbound dialing to have direct access to 9-1-1, then the FCC may want to clarify that concept.”  Texas 9-1-1 Entities Comments at 6.  We clarify that our rules are not intended to prohibit configuring MLTS to allow outbound-only calling.  Rather, we interpret the definition of MLTS to include outbound-only calling systems.
  The statutory definition of MLTS is broad enough to cover outbound-only calling services and does not expressly exclude such services.  Commenters generally support interpreting the definition to include outbound-only services, AT&T Comments at 6; Avaya Comments at 6; RedSky Comments at 6; West Safety Comments at 5; BRETSA Reply at iii, 24; see also APCO Comments at 8 (stating that the Commission should “ensur[e] consistency in capabilities such as the location information conveyed with the call, as well as the ability to access 9-1-1 from communications platforms that for consumers may appear functionally identical”).
 and no commenter expressly opposes this interpretation. Microsoft and INCOMPAS assert that the Commission should not expand its 911 rules to cover outbound-only calling applications.  See Microsoft Comments at ii, 17-22; INCOMPAS Reply at 2, 10-11.  We do not interpret these comments to apply to the question of outbound-only MLTS services under Kari’s Law.  
  Avaya, for example, states that MLTS at a minimum should include any system capable of making an outbound call. Avaya Comments at 6; see also West Safety Comments at 5 (asserting that the statutory definition of MLTS is broad enough to encompass outbound-only calling services).
  BRETSA asserts that 911 calls are outbound calls, and it is counterintuitive that they cannot be made over outbound-only calling systems. BRETSA Reply at iii, 24.
  AT&T urges the Commission to ensure that the MLTS rules maintain regulatory parity between new implementations of business VoIP services and traditional MLTS business solutions and states that one-way VoIP solutions should be required to support 911, as end users will expect their calling solutions to have this functionality and may rely on it in an emergency. AT&T Comments at 6.
  Verizon states that applying Kari’s Law requirements to MLTS that allow outbound-only 911 dialing is likely feasible, but that the scope of such requirements should focus on user expectations. Verizon Comments at 3.
  Verizon suggests that the rules should protect users of outbound-only calling systems who are not employed by the enterprise or who are otherwise unfamiliar with the system and use it for outbound-only dialing. Id.
  On the other hand, Verizon states, if the outbound-only system has a defined and restricted user group that is uniformly familiar with and trained in the enterprise’s calling practices, and 911 is the only outbound number that users can dial, the direct dialing capability may be less critical. Id. at 3-4.
  Verizon also states that requiring direct dialing capability for outbound-only MLTS services “may give enterprises incentive to not enable any 911 dialing at all (which has its own public safety implications).” Id. at 4.

53. We find that Congress’s intent in enacting Kari’s Law was to require direct dialing for any MLTS phone that allows the user to call 911, regardless of whether the system also allows the PSAP to connect a return call directly to the 911 caller.  We agree with the Texas 9-1-1 Entities that Kari’s Law and the “utterly tragic circumstances” behind its enactment demonstrate that “it is simply unreasonable to expect 9-1-1 callers to know or remember when they are required to do something differently during a 9-1-1 call based on their particular device or location.” Texas 9-1-1 Entities Comments at 4.
  Moreover, as BRETSA states, calling 911 is inherently an outbound service. BRETSA Reply at iii, 24.
  As a result, it is counter-intuitive to expect consumers to assume that they cannot reach 911 from such services. Indeed, the requirement in our text-to-911 rules for covered text providers to send a bounce-back message informing the user when text-to-911 service is not available is based on a similar conclusion that consumers in an emergency cannot be expected to know the limits of various devices and services that they may use to try to reach 911.  See 47 CFR § 20.18(q)(3); Facilitating the Deployment of Text-to-911 and Other Next Generation 911 Applications; Framework for Next Generation 911 Deployment, PS Dockets Nos. 11-153 and 10-255, Report and Order, 28 FCC Rcd 7556, 7562, para. 15 (2013) (stating that as IP-based text applications proliferate beyond Short Message Service and Multimedia Messaging Services, “consumers are likely to assume that they should be as capable of reaching 911 as any other telephone number”).

54. We decline to adopt Verizon’s suggestion that we narrow the requirements for outbound-only MLTS service to apply solely on the basis of user expectations.  Rather, we believe Congress intended for direct 911 dialing and notification to be available for all outbound-only MLTS services.  Similarly, public safety commenters such as the Texas 9-1-1 Entities and BRETSA point out that 911 callers in an emergency should not have to slow down and analyze whether 911 is available from a particular device, especially when they may not know the particular technology involved and may not have chosen it for themselves.  Finally, although Verizon suggests that requiring direct dialing capability for outbound-only MLTS services may give enterprises incentive to not enable any 911 dialing at all, we do not believe this possibility, which is speculative, outweighs the benefits of ensuring that direct dialing is available with any MLTS phone that allows the caller to reach 911. See also BRETSA Reply at 25 (stating that excluding outbound-only calling services from 911 regulation might cause voice application and service providers to configure their services to permit outbound-only calling for the specific purpose of avoiding the complications and expense of 911).
   
55. Internal systems.  Cisco asks the Commission to clarify that the definition of MLTS excludes systems that are “used only for internal employee communications and . . . are not designed to interconnect with the PSTN,” such as internal messaging and data and video conference capabilities that are “increasingly displacing voice communications for employee collaboration.” Cisco Comments at 9.
  Cisco states that “[w]here a technology is specifically deployed by an enterprise to support internal communications (i.e., it cannot support a call outside the enterprise), or where a tool is designed and used for conferencing services or other non-point-to-point communications, there can be no reasonable expectation on the part of employees that such internal or conferencing tools would be used to summon emergency services.” Id.
  BRETSA responds that limiting application of the rules to specific types of MLTS would distort the market and that Kari’s Law and RAY BAUM’S Act do not support such a narrow reading of the definition of MLTS. BRETSA Reply at 13-14.
  Further, BRETSA states that exempting internal communications systems from the rules “would appear to create a loophole such as to negate the statutes and rules” because an MLTS in which a user must dial a number to access an outside line prior to placing a call to 911 would appear to be an internal communications system. Id. at 14.
  
56. We agree with Cisco that Kari’s Law and the rules arising out of RAY BAUM’S Act were not intended to apply to purely internal communications systems that do not rely on telephone numbers under the North American Numbering Plan.  We clarify that a technology that is specifically deployed by an enterprise to support only internal communications and that does not connect to the public switched telephone network would not fall within the definition of MLTS.  In response to BRETSA’s concerns, we conclude that this will not distort the market or negate the statute and rules because the clarification applies only to systems that do not connect to the public switched telephone network.  If an internal communications system or conferencing service connects to the public switched telephone network either on its own or through a third party and can establish calls to the public switched telephone network, including by dialing a prefix such as “9,” then it is within the definition of MLTS under our interpretation. See Verizon Comments at 2 (stating that the scope of the draft rules is “appropriately” targeted at systems interconnected to the PSTN and that this is consistent with the Commission’s traditional approach to consumers’ and businesses’ 911 dialing expectations and preserves flexibility in developing new purely private, internal enterprise systems).

57. System components.  Panasonic, Cisco, and TIA also urge the Commission to clarify that individual system components such as telephone sets and control software do not qualify as an MLTS. Panasonic Comments at 10; TIA Comments at 9; Cisco Reply at 5. 
  Panasonic states that Congress’s use of the language “system comprised of” various parts, “e.g., common control units, telephone sets, control software and hardware and adjunct systems,” dictates as a matter of logic that such individual parts are, in isolation, not MLTS themselves. Panasonic Comments at 10.
  To hold otherwise, Panasonic states, would be to ignore the plain meaning of the word “comprised,” effectively reading it out of the statute. Id.
  Panasonic adds that it may be uniquely situated in that while the company offers a “full-blown MLTS” and is in that case an MLTS manufacturer, it also sells IP phones to other parties, who bundle Panasonic phones with other components that make up a full MLTS. Id.
  To address this situation, Panasonic states, the Commission should clarify that sellers of individual MLTS components are not subject to the Commission’s rules for MLTS. Id.
  Cisco asserts that “[a]s a matter of common sense, individual system components are not even capable of dialing 911 or reaching the PSTN unless and until they are assembled by an installer.” Cisco Reply at 5; see also TIA Comments at 9 (stating that when a company is merely providing a component of an MLTS, it cannot be subject to a rule that clearly only applies to entities that manufacture and sell the entire system that makes up an MLTS).
  
58. We agree that the definition of MLTS refers to a system and that individual components of such a system, including telephone sets, control software and hardware, and adjunct systems, do not by themselves constitute an MLTS.  Consistent with this, we clarify that manufacturers, importers, sellers, or lessors of individual MLTS components are not subject to the Commission’s MLTS rules to the extent that they manufacture, import, sell, or lease such components without the other components necessary for the system to function as an MLTS.  In the scenario described by Panasonic, the entity that bundles the individual components into an MLTS would be the manufacturer and presumably also the seller or lessor of the MLTS and would have the obligations that fall on those parties under the statute and our rules. To the extent individual components need certain functionality or pre-configuration to comply with Kari’s Law, the bundler should require that in its contract with the manufacturer.  The obligation to comply with the statute and our rules, however, would lie with the bundler.
  However, we do not agree with Cisco that the test for whether one or more components constitute an MLTS is whether they can be used to dial 911 or reach the PSTN, as that would exclude all systems that have been manufactured but not yet installed.  Such a result would clearly be at odds with Kari’s Law, which places obligations on “persons engaged in the business of manufacturing, importing, selling, or leasing” an MLTS that apply before installation, operation, or management of the system. Specifically, such persons may not manufacture, import, sell, lease, or offer to sell or lease an MLTS unless the system is “pre-configured” so that when properly installed, a user may directly initiate a call to 911 from any station equipped with dialing facilities.  47 U.S.C. § 623(a).
  
b. Definition of Pre-configured 
59. The Commission proposed in the Notice to define the statutory term “pre-configured” to mean:
An MLTS that comes equipped with a default configuration or setting that enables users to dial 911 directly as required under the statute and rules, so long as the MLTS is installed and operated properly.  This does not preclude the inclusion of additional dialing patterns to reach 911.  However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern. Notice, 33 FCC Rcd at 8995, para. 31; see also id. at 9029, Appendix A, proposed rule § 9.3 (proposed definition of pre-configured).  The Commission noted that the Section-by-Section analysis of H.R. 582 states that the law would require MLTS to be “pre-configured with the default dialing pattern described in this section,” see Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017), and that a default configuration commonly refers to the preexisting, “out of the box” settings of a user-configurable software application, computer program, or device.  See Notice, 33 FCC Rcd at 8995, n.59.

60. The Commission stated that this would mean an MLTS may support additional dialing patterns but that manufacturers (and importers, sellers, or lessors) must ensure that the default, “out-of-the-box” configuration allows users to reach 911 directly. Id. at 8995, para. 31; see also Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017) (stating that the law would not preclude the inclusion of additional optional dialing patterns to reach 911, such as 9-911, but that “if the system is configured with these additional dialing patterns, they must be in addition to the default pattern”).

61. Although some commenters agree with the Commission’s proposed definition of pre-configured, See NASNA Comments at 2; West Safety Comments at 5.
 others ask the Commission to clarify the proposed definition to acknowledge the role of the enterprise customer and MLTS installer in providing the MLTS with connectivity to the PSTN. See Cisco Comments at 10-12; Microsoft Comments at 6; Panasonic Comments at 11-12; TIA Comments at i, 10; INCOMPAS Reply at 7-8; RingCentral Reply at 11-12; TIA and DECT Forum Reply at 5-6.

62. We find that the revisions proposed by Cisco and Microsoft are consistent with the statutory language and with the definition of “pre-configured” that the Commission proposed in the Notice, and that they assist in providing clarity.  In particular, Cisco states that MLTS manufacturers today can design systems that are capable of supporting direct 911 dialing patterns and that are shipped with software that, upon installation and configuration of the MLTS with PSTN connectivity, can enable direct 911 dialing. Cisco Comments at 10.
  However, MLTS solutions of this type have no capability “out of the box” to make or complete a PSTN call, including an emergency call. Id.
  
63. Cisco adds that in today’s market, “MLTS manufacturers predominantly offer enterprise solutions over distributed systems, where the actual call control component of the solution need not be, and often is not, resident in each enterprise location where MLTS-to-PSTN calling takes place.  PSTN connectivity, including the 911 dialing pattern, is therefore established by the installer at the direction of the enterprise, based on the unique attributes of its MLTS system, at the time PSTN connectivity is configured.” Id.  Cisco also states that “[a]s is the case with direct dialing, distributed MLTS are not preconfigured to provide dispatchable location; rather, the initial configuration of dispatchable location (and the maintenance of that configuration over time) can only effectively be the responsibility of the MLTS installer and operator, not the manufacturer.”  Cisco Reply at 5; see also Letter from John T. Scott, III, Counsel for Cisco, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, at 1 (filed May 22, 2019) (Cisco May 22 Ex Parte) (stating that the MLTS software Cisco produces and markets to enterprises is capable of being configured at time of installation with a default direct 911 dial setting but cannot be pre-configured as the Commission proposed to define that term in the Notice); Panasonic Comments at 12 (stating that some MLTS per se require further steps by the installer, which are likely as directed by the manager of the MLTS, before any dial-out, including to 911, is possible and that the definition or interpretation of pre-configured should “reflect this reality”).
  Cisco urges the Commission to clarify that the pre-configuration requirement in the context of distributed systems can be satisfied when a vendor includes software to support a direct 911 dialing pattern, which is available to the installer at the time the MLTS is configured for PSTN calling. Cisco Comments at 12. 
  Specifically, Cisco proposes that the Commission “slightly” modify the definition of pre-configured to read, “An MLTS that comes equipped with hardware and/or software capable of establishing a setting that enables users to directly dial 911 as soon as the system is able to initiate calls to the public switched telephone network, so long as the MLTS is installed and operated properly.” Id.
  Microsoft similarly states that many, if not most, MLTS capabilities in today’s marketplace are not available in a “plug and play” version and that the Commission should revise the definition of pre-configured so that it “recognizes the responsibilities of the customer with respect to implementation and provision of the service.” Microsoft Comments at 6.
  Microsoft recommends that the Commission revise the definition to read, “‘Pre-configured’ means that the MLTS comes equipped with a default configuration or setting that enables users to dial 911 directly as required under the statute and rules, so long as the system is installed and operated properly or, where no default exists, such as when customer provisioning of the system is required, enables the customer to configure the system to dial 911 directly as required under the statute and rules.” Id.; see also INCOMPAS Reply at 8 (supporting Microsoft’s proposed revision).

64. We agree with these commenters that not all MLTS are “out of the box,” plug-and-play solutions and that the definition of pre-configured should recognize the role of the enterprise and installer with respect to implementation and provision of service.  We believe that the proposed revisions suggested by Cisco and Microsoft are fundamentally consistent with each other, and we note that no commenter opposes these suggested revisions.  In addition, Microsoft states that it supports either version of the definition. See Letter from Paula Boyd, Senior Director, Government and Regulatory Affairs, Microsoft Corporation, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, at 5 (filed June 26, 2019) (Microsoft June 26 Ex Parte).
  Accordingly, we revise the definition as requested by Cisco as follows:
‘Pre-configured’ means an MLTS that comes equipped with hardware and/or software capable of establishing a setting that enables users to directly dial 911 as soon as the system is able to initiate calls to the public switched telephone network, so long as the MLTS is installed and operated properly.  This does not preclude the inclusion of additional dialing patterns to reach 911.  However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern. See infra Appendix A, final rule § 9.3 (definition of pre-configured).  

c. Definition of Configured
65. The Commission proposed in the Notice to define the statutory term “configured” to mean:
The settings or configurations for a particular MLTS installation have been implemented so that the MLTS is fully capable when installed of dialing 911 directly and providing notification as required under the statute and rules.  This does not preclude the inclusion of additional dialing patterns to reach 911.  However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern. Notice, 33 FCC Rcd at 8995, para. 32; see also Notice, 33 FCC Rcd at 9026, Appendix A, proposed rule § 9.3 (proposed definition of configured). 

The Commission also asked whether the difference between its proposed definitions of “pre-configured” and “configured” was sufficiently clear. Notice, 33 FCC Rcd at 8995, para. 32.

66. NASNA, Panasonic, and West Safety support the Commission’s proposed definition of configured. See NASNA Comments at 2; Panasonic Comments at 12; West Safety Comments at 5.
  BRETSA notes that the reference to “notification” in the definition should be to “MLTS notification,” because that is the term as defined in the rules. See BRETSA Comments at 7.
  BRETSA also proposes line edits to specify that configuring an MLTS for direct dialing means configuring it for “direct dialing of 911 without a requirement of first dialing or entering an additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9.” Id.
  
67. We adopt the definition largely as proposed.  We also agree with BRETSA that the reference to notification should be corrected to “MLTS notification.” Consistent with this, we also change a reference in section 9.16(b)(2) of the rules from configuring an MLTS to provide “a notification” to configuring it to provide “MLTS notification.”  See infra Appendix A, final rule § 9.16(b)(2). 
  But we decline to adopt BRETSA’s other proposed line edits as unnecessary.  The definition already requires configuration so that the MLTS is fully capable when installed of dialing 911 directly “as required under the statute and rules,” which includes dialing without a requirement of first dialing or entering an additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9. RedSky states that the titles of the definitions of pre-configure and configure are too broad and suggests changing them to “Pre-configured MLTS” and “MLTS Configurations,” respectively.  See RedSky Comments at 39, 40.  We decline to make these changes because we do not believe the existing titles will cause confusion.  In addition, our definitions are intended to track the language used in Kari’s Law as closely as possible, and the statute and our implementing rules do not use the terms “pre-configured MLTS” or “configured MLTS.”

68. The revised definition of “configured” reads as follows:
The settings or configurations for a particular MLTS installation have been implemented so that the MLTS is fully capable when installed of dialing 911 directly and providing MLTS notification, as required under the statute and rules.  This does not preclude the inclusion of additional dialing patterns to reach 911.  However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern. See infra Appendix A, final rule § 9.3 (definition of configured). 

d. Definition of Improvement to the Hardware or Software of the System
69. Under Kari’s Law, the notification requirements of the statute apply only if the MLTS can be configured to provide notification “without an improvement to the hardware or software of the system.” Notice, 33 FCC Rcd at 8995-96, para. 33 (citing 47 U.S.C. § 623(c)). 
  The Commission proposed in the Notice to define the statutory term “improvement to the hardware or software of the system” to mean:
An improvement to the hardware or software of the MLTS, including upgrades to the core systems of the MLTS, as well as substantial upgrades to the software and any software upgrades requiring a significant purchase. Id.; see also id. at 9027, Appendix A, proposed rule § 9.3 (proposed definition of improvement to the hardware or software of the system). 

70. The Commission also noted that the proposed definition is consistent with the legislative history of Kari’s Law, which provides that an improvement to the hardware or software of a system is intended to include upgrades to the core systems of an MLTS and substantial upgrades to the software, particularly those requiring a significant purchase. Notice, 33 FCC Rcd at 8996, n.64 (citing Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017)).  The Commission also noted that the legislative history of Kari’s Law provides that an improvement to the hardware of a system is not intended to include “the addition of additional extensions or lines” and that “[m]inor software upgrades that are easily achieved or are made to improve the security of the system would not be considered an ‘improvement’ for the purposes of this section.”  In addition, the legislative history provides that the statute “seeks to balance the need for an onsite notification with the goal of not placing an undue burden on MLTS owners or operators.”  Id. at nn.65, 66.
  The Commission asked whether there are types of routine hardware or software changes that should be included in or excluded from the definition and whether it should clarify that (1) improvements to the hardware of the system do not include the provision of additional extensions or lines, and (2) improvements to the software of the system do not include minor software upgrades that are easily achieved or made to improve the security of the system. Id. at 8996, para. 33.
  In addition, the Commission asked whether upgrades requiring a significant purchase should be determined based on total cost alone, or whether it should interpret significant to be a relative determination based on the size of the entity making the purchase.Id.

71. We adopt the definition of improvement to the hardware or software of the system as proposed. See infra Appendix A, final rule § 9.3 (definition of improvement to the hardware or software of the system).
  Under this definition, enterprises are not required to undertake “upgrades to the core systems of an MLTS,” “substantial upgrades to the software,” or “any software upgrades that require a significant purchase” in order to comply with the notification obligation.  
72. We find that this definition is necessary to implement Kari’s Law, which makes clear that the notification requirements of the statute apply only if the MLTS can be configured to provide notification “without an improvement to the hardware or software of the system.” 47 U.S.C. § 623(c). 
  The definition we adopt also is consistent with the legislative history of Kari’s Law, which states Congress’s intention to balance the need for notification with the goal of “not placing an undue burden on MLTS owners or operators.” See Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017).

73. While NCTA supports the Commission’s approach to this definition, NCTA Comments at 3. 
 others express concerns. See Panasonic Comments at 14-15; RedSky Comments at 7.
  Although RedSky objects to the definition on the ground that the vast majority of deployed MLTS systems can meet the notification requirements without any modification of the core systems, NCTA points out that line-based MLTS cannot be upgraded to offer notification without upgrades to core systems that would present a “daunting technological and financial challenge.” See NCTA Comments at 4; RedSky Comments at 7.  RedSky also asserts that the only type of improvements that should be considered minor are “programming configurations.”  RedSky Comments at 7.  
  In this respect, NCTA states that MLTS are provided to commercial customers in a variety of configurations involving both line-based and trunk-based products and that it is not aware of any line-based systems that currently have a notification capability. NCTA Comments at 3. 

74. We also disagree with NASNA that any improvements to an existing MLTS, no matter how minor, should trigger the obligation to comply with Kari’s Law and the implementing regulations. NASNA Comments at 2 (stating that “any improvements to MLTS hardware or software that an enterprise makes in the future must provide direct dialing and notification capabilities, and the same dispatchable location information that would be received by a PSAP”) (emphasis added).  
  We conclude that such a policy would be inconsistent with the language of Kari’s Law, which limits application of the statute to MLTS manufactured or brought into use after February 16, 2020.  In addition, we clarify that (1) improvements to the hardware of the system do not include the provision of additional extensions or lines, and (2) improvements to the software of the system do not include minor software upgrades that are easily achieved or made to improve the security of the system. Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017).
 
75. With respect to upgrades, Panasonic requests that we further clarify that substantial improvements to the software of the system do not include software updates for addressing bug fixes, security vulnerabilities, or the addition of ancillary features; that maintenance or reconfiguration of the system to support new users or extensions should not be considered a substantial upgrade; and that the cost of the upgrade or update or the size of the enterprise should not be a factor. Panasonic Comments at 14-15.
  RedSky asserts that the terms “substantial” and “significant” are subjective and “should be quantified to ease in both requirement and enforcement abilities.” RedSky Comments at 39.
  
76. We believe the factors cited by Panasonic may be relevant to determining whether a specific upgrade is substantial, but that such factors, if applicable, should be evaluated in light of the total facts and circumstances presented in the specific case.  We also decline to quantify the terms “substantial” and “significant” as requested by RedSky, as the record does not provide sufficient basis for such quantification at this time.  We expect that as Kari’s Law is implemented, cases will arise that will enable us to provide further guidance on these issues.  For now, we conclude that the guidance provided above is sufficient and consistent with the statutory language and legislative history of Kari’s Law.    
e. Definition of Person Engaged in the Business of Manufacturing, Importing, Selling, or Leasing an MLTS
77. Kari’s Law applies to any “person engaged in the business of manufacturing, importing, selling, or leasing” an MLTS and provides that such persons may not manufacture or import an MLTS for use in the United States, or sell or lease or offer to sell or lease an MLTS in the United States, unless the system is pre-configured so that, when properly installed, a user may directly initiate a call to 911 from any station equipped with dialing facilities. 47 U.S.C. § 623(a).
  In the Notice, the Commission tentatively concluded that the meaning of the term “person engaged in the business of manufacturing, importing, selling, or leasing” an MLTS is self-evident and did not propose to modify this definition or add it to the rules. Notice, 33 FCC Rcd at 8996, para. 34.
  The Commission sought comment whether any additional clarification of this term is necessary for implementation or enforcement of Kari’s Law. Id.

78. As proposed in the Notice, we conclude that the meaning of the term “person engaged in the business of manufacturing, importing, selling, or leasing an MLTS” is self-evident and that there is no need to adopt a definition for it.  Cisco and Panasonic agree that the meaning of this term is self-evident, and no commenter opposes that view. See Cisco Comments at 13; Panasonic Comments at 13; see also West Safety Comments at 5 (endorsing the Commission’s proposed definitions of “the various roles of MLTS marketplace participants”). 

f. Definition of Person Engaged in the Business of Installing an MLTS
79. Kari’s Law also places obligations on any “person engaged in the business of installing, managing, or operating” an MLTS. 47 U.S.C. § 623(b).
  Such persons may not install, manage, or operate the MLTS for use in the United States unless it is configured for direct dialing of 911. Id.
  In addition, such persons shall, in installing, managing, or operating the MLTS, configure it to provide notification if the system is able to be configured to provide notification without an improvement to the hardware or software of the system. Id. at § 623(c).
  In the Notice, the Commission proposed to define a person engaged in the business of installing an MLTS as:
A person that configures the MLTS or performs other tasks involved in getting the system ready to operate.  These tasks may include, but are not limited to, establishing the dialing pattern for emergency calls, determining how calls will route to the Public Switched Telephone Network (PSTN), and determining where the MLTS will interface with the PSTN.  These tasks are performed when the system is initially installed, but they may also be performed on a more or less regular basis by the MLTS operator as the communications needs of the enterprise change.  The MLTS installer may be the MLTS manager or a third party acting on behalf of the manager. Notice, 33 FCC Rcd at 8996, para. 35; see also id. at 9029, Appendix A, proposed rule § 9.3 (proposed definition of “person engaged in the business of installing an MLTS”).

80. The Commission sought comment on this proposed definition. Id. at 8996-97, para. 35.
  While some commenters support the proposed definition, See NPSTC Comments at 4; West Safety Comments at 6.
 others ask the Commission to clarify it. See RingCentral Comments at 9-10; Panasonic Comments at 9; Cisco Reply at 5; Comcast Reply at 5.
  
81. We adopt the definition of “person engaged in the business of installing an MLTS” as proposed. See infra Appendix A, final rule § 9.3 (definition of “person engaged in the business of installing an MLTS”).
  We decline to revise the language of this definition as requested by some commenters because we conclude that such revisions are not warranted; however, we supply guidance on how to apply this definition given points raised by some commenters.  
82. In this regard, RingCentral notes that although the Notice defines a “person engaged in the business of installing an MLTS” to include a person who “configures the MLTS or performs other tasks involved in getting the system ready to operate,” these functions are often part of providing cloud-based MLTS. RingCentral Comments at 9.
  Accordingly, RingCentral states, an over-broad definition of installation risks imposing duties (such as configuring notification) that should rest with the MLTS owner/operator as the entity best positioned to make deployment decisions for the enterprise. Id.
  According to RingCentral, the Commission should address this by making clear that manufacturers and sellers are not installers simply by virtue of providing systems; “rather, manufacturers and sellers become installers only when their customers specifically retain them for installation by, for example, purchasing installation or other professional services.” Id.
  In addition, RingCentral states that the Commission should recognize that installers are acting at the direction of owners and operators and should adjust the responsibility for implementation of those directions accordingly. Id.; see also Cisco Reply at 5 (supporting RingCentral’s position).
  
83. We disagree with RingCentral that responsibility for configuring or other tasks that fall within the definition of installation should automatically rest with the owner/operator in some circumstances, and we believe that a manufacturer of a hosted MLTS that configures the system is serving in that respect as an installer.  Similarly, we note that some manufacturers provide systems with self-installing software.  In that event, the manufacturer is also performing some of the functions of an installer.  We agree, however, with RingCentral that if an entity performs the functions of an installer at the direction of the enterprise operator or manager, then the operator or manager in that scenario is also serving as the installer.  Consistent with this approach, there may be multiple parties performing installation functions for a single MLTS.  An enterprise manager or operator that directs aspects of the installation may, depending on the degree of its involvement, be responsible for complying with the installer’s obligations.  Evidence that the manufacturer has been retained specifically to install the system could be relevant in showing that the manufacturer is at least partly responsible for the obligations of an installer under Kari’s Law and our rules, but the absence of such an agreement would not necessarily mean that the manufacturer has not performed any installation functions.  
84. Panasonic states that the definition of a “person engaged in the business of installing an MLTS” should be limited to initial installation and configuration of the system or substantial improvement, “lest over-long potential liability risk the exit of skilled installers from the market.” Panasonic Comments at 13.
  We decline to limit the definition to initial installation and configuration of the system, as Panasonic requests.  Panasonic presents no data to support its conclusion that this would lead to the exit of skilled installers from the market. Comcast asks the Commission to make clear that in instances where an MLTS provider installs a system that has been pre-configured to be capable of transmitting direct-dialed 911 calls to the appropriate PSAP, the installer has fulfilled its responsibilities under Kari’s Law and the implementing rules.  Comcast Reply at 5.  We decline to make this clarification because we believe the definition of a person engaged in the business of installing an MLTS is sufficiently clear with respect to the obligations of an installer.  In addition, we note that the installer’s obligations may extend beyond installing a system that has been “pre-configured” for direct dialing of 911 and may include, for example, installing a system capable of providing MLTS notification.

g. Definition of Person Engaged in the Business of Managing an MLTS; Person Engaged in the Business of Operating an MLTS; Role of the Enterprise Owner
85. The Commission proposed to define a person engaged in the business of managing an MLTS as:
The entity that is responsible for controlling and overseeing implementation of the MLTS after installation.  These responsibilities include determining how lines should be distributed (including the adding or moving of lines), assigning and reassigning telephone numbers, and ongoing network configuration. Notice, 33 FCC Rcd at 8996, para. 36; see also id. at 9029, Appendix A, proposed rule § 9.3 (proposed definition of “person engaged in the business of managing an MLTS”).

The Commission proposed to interpret this definition to mean that a user of MLTS services that does not own or lease the MLTS or exercise any control over it would not be deemed to be engaged in the business of managing the MLTS. Id. at 8997, para. 36.
  Under this interpretation, an enterprise that contracts with a third party to provide a total solution for MLTS, including acquiring the MLTS equipment, configuring the system, completing calls, and providing services such as maintenance and end user support, would not be deemed to be engaged in the business of managing the MLTS unless it exercised actual control over the system.Id.
  The Commission also proposed to define a person engaged in the business of operating an MLTS as “[a] person responsible for the day-to-day operations of the MLTS.” Id. para. 37; see also Id. at 9029, Appendix A, proposed rule § 9.3 (proposed definition of “person engaged in the business of operating an MLTS”).
  The Commission sought comment on these proposed definitions. Id. at 8996-97, paras. 36-37.

86. In addition, the Commission sought comment on whether there are circumstances in which the proposed definitions of MLTS “manager” or “operator” should extend to enterprise owners. Id. at 8997, para. 38.
  The Commission noted that commenters on the Enterprise Communications NOI emphasized that some enterprise owners purchase, operate, and maintain their own on-premises telephone systems with PBX equipment, while other enterprise owners enter contractual arrangements with third-party providers of network and hosted services. Id. (citing West Safety Enterprise Communications NOI Comments at 7).
  The Commission stated that it did not believe Kari’s Law was intended to extend liability to enterprise owners that purchase MLTS services but do not exercise control over the manner in which such services are configured or provided.Id.
  Nevertheless, the Commission stated, there may be instances where enterprise owners purchase, operate, and maintain their own MLTS systems, or where they exercise active control over the configuration and provision of MLTS by third parties. Id.
  The Commission sought comment on whether in such instances enterprise owners should be deemed to be MLTS managers or operators and what indicia of active control should be considered in making this determination. Id.

87. Commenters raise a number of issues with respect to the proposed definitions of MLTS operator and manager.  NASNA and West Safety generally agree with the proposed definitions, NASNA Comments at 3; West Safety Comments at 6.
 while other commenters seek changes to the definitions or ask the Commission to clarify the role of the manager, operator, and enterprise owner. See AHLA Comments at 4, 10-11; AT&T Comments at 6, 7-8; BRETSA Comments at 5; NASNA Comments at 3; NCTA Comments at 2; Panasonic Comments at 18; RedSky Comments at 9; USTelecom Comments at 3; Comcast Reply at 4-5; INCOMPAS Reply at 3-6; RingCentral Reply at 10-11. 

88. We clarify the allocation of responsibility among the installer, operator, manager, and enterprise owner in certain respects.  With these clarifications, we do not believe any changes are needed in the wording of the definitions of person engaged in the business of managing an MLTS and person engaged in the business of operating an MLTS.  Accordingly, we adopt these definitions as proposed.  See infra Appendix A, final rule § 9.3 (definition of “person engaged in the business of managing an MLTS, definition of person engaged in the business of operating an MLTS”). 

89. We are persuaded by the arguments of BRETSA, NASNA, and RedSky that even a “passive” enterprise owner may perform some of the functions of an MLTS installer, manager, or operator under our rules and that the owner in that event should be responsible to the extent a violation of the statute or rules results from that conduct. See BRETSA Comments at 5; NASNA Comments at 3; RedSky Comments at 9.
  NASNA states that an MLTS owner “still has an obligation to hold its third-party service provider(s) responsible for ensuring compliance.” NASNA Comments at 3.
  RedSky similarly asserts that the Commission should not exclude passive owners from the definition, stating that “no MLTS user can be successful in a vacuum.  They have to provide their operational requirements to the MLTS provider.  These requirements can and must include direction to meet appropriate regulatory requirements.  It is incumbent on the MLTS provider to ensure that the provided system or service is capable of meeting these requirements.” RedSky Comments at 9.  RedSky also states that the term “operator” is not as pertinent as the term and concept of provider and that the Commission should introduce the terms “MLTS provider” and “MLTS user” to capture the actual business environment.  Id.  In addition, RedSky suggests that the Commission replace the term “person” throughout the rules with the term “person or entity.”  Id. at 8.  We decline to use “MLTS provider” and “MLTS user” because those terms are not used in Kari’s Law, and our intent is for the rules to track the language of the statute whenever possible.  We decline to substitute the term “person or entity” for the same reason; “person” is the term used in Kari’s Law.  We also note that Kari’s Law was codified as part of Chapter 5 of the Act, and that Chapter 5 defines “person” to include “an individual, partnership, association, joint-stock company, trust, or corporation.”  47 U.S.C. § 153(39).
  BRETSA states that the rules should hold MLTS customers responsible for compliance to the extent the customer installs, maintains, operates and/or configures the MLTS. BRETSA Comments at 5.  BRETSA also states that MLTS providers with superior knowledge of the rules will invariably include in their sales and service agreements indemnification provisions that will undermine the deterrent effect of penalties under the rules.  To address this, BRETSA urges the Commission to prohibit MLTS providers from requiring customers to indemnify them against liability for rule violations.  Id.  We decline to prohibit providers from requiring customers to indemnify them because we find that any conclusions about the effect of such agreements on compliance with Kari’s Law and the implementing rules would be highly speculative at this time.  BRETSA also interprets the “person engaged in the business of” language to exclude a person that is engaged in a business unrelated to the provision of configuration or operation of an MLTS but that purchases or leases an MLTS for its use, and BRETSA proposed revisions to bring such persons under the rules.  See BRETSA Comments at 5, 9.  We decline to adopt these proposed revisions because we believe it is clear that Kari’s Law and the implementing rules apply to a person engaged in a business unrelated to the operation of an MLTS that purchases or leases an MLTS for its own use.  See Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017) (stating that “[n]ew Section 721(b) requires that any person who installs, operates, or manages a MLTS only do so if the system is configured such that a user may directly initiate a call to 9-1-1 without any additional digit or prefix”) (emphasis added).

90. We agree with these commenters that an enterprise owner has an obligation to hold third-party service providers responsible for complying with Kari’s Law and our rules.  We clarify, however, that a passive owner generally should not face liability if the owner contracts with a responsible third party and includes compliance requirements in its agreement with the service provider.  We decline to find that a hotel is not an installer, manager, or operator of MLTS under the rules absent “compelling evidence to the contrary,” as AHLA requests. AHLA Comments at 4; see also West Safety Comments at 6 (agreeing with the Commission’s proposal to interpret the definitions of MLTS manager and operator to exclude users that do not own, lease, or exercise any control over the MLTS and stating that regulating the activities and purchase decisions of passive enterprise owners is inconsistent with the intent of Kari’s Law).
  AHLA states that hotels typically do not perform the functions of an installer, manager, or operator. See AHLA Comments at 11 (stating that AHLA members of any size generally contract with third-party vendors to acquire equipment, configure the system, complete calls, and provide maintenance and support). 
  In that event, and provided that the hotel contracts with responsible third parties and includes compliance requirements in the agreements, the hotel should not face potential liability under the statute or our rules. 
91. Commenters also ask the Commission to clarify the allocation of responsibility for complying with Kari’s Law and the regulations in the context of hosted, cloud-based MLTS service. See AT&T Comments at 6; RingCentral Reply at 10-11.
  AT&T asserts that any new MLTS rules should clearly delineate the roles and responsibilities of the various players in the MLTS ecosystem and that any single stakeholder may play multiple roles in the MLTS ecosystem depending on how an MLTS system is configured. AT&T Comments at 6.
  “For example, when AT&T offers a hosted MLTS solution to a business, AT&T should be responsible for compliance with the requirements applicable to those engaged in the installing, managing, or operating MLTS.  However, where AT&T offers a Session Initiation Protocol . . . trunking solution to provide Public Switched Telephone Network . . . access for call delivery and the customer operates and manages the PBX, the customer should have responsibility for compliance.  In both cases, the manufacturer should bear responsibility for ensuring its products are compliant.” Id.

92. We conclude that whether a party is a manager, operator, or installer should be based on the party’s conduct and whether it has performed activities that fall within the definition in our rules.  Consistent with this, we agree with AT&T that when it offers a hosted MLTS solution to a business, it is responsible for compliance with the requirements applicable to those engaged in installing, managing, or operating an MLTS to the extent that its hosting service includes those functions.  On other hand, if AT&T offers a trunking solution that provides public switched telephone network access with the customer operating and managing the PBX, we agree that the customer should have responsibility for compliance as an operator and/or manager.  
93. RingCentral disagrees with AT&T’s suggestion that hosted PBX providers would be installers and managers and urges the Commission to clarify that manufacturers and sellers are not installers or managers simply by virtue of providing systems. RingCentral Reply at 10-11.
  RingCentral asserts that “[p]roviders of hosted cloud-based PBX may simply provide the MLTS, without installation or implementation of the system after installation. . . .  The definition of ‘manager’ could . . . inadvertently include a cloud-based MLTS provider, as the definition includes a person who is involved in ‘implementation of the MLTS after installation.’”Id.
  We note that a manufacturer or seller would be deemed an installer or manager only to the extent that it provides installation or management services with respect to the system.  We offer these as illustrative examples for guidance on how the Commission would apply the rule.  Any determination of a particular party’s liability will necessarily require a fact-specific, case-by-case inquiry.  The parties’ contractual arrangements may be relevant in this determination, but they are not determinative, and an entity that performs the functions of a manager in violation of a contractual obligation not to do so could still be deemed a “person engaged in the business of managing an MLTS.”
94. Finally, we agree with commenters on the importance of the enterprise owner/MLTS customer’s involvement in some situations.  Commenters assert that the MLTS customer’s involvement may be necessary for compliance, including updating end user location information See ACA Comments at 4; AT&T Comments at 6; INCOMPAS Reply at 4-5; NCTA Reply at 5; NTCA Comments at 2; RingCentral Reply at 9.  AT&T notes that customers may “unilaterally move telephone stations [after installation] . . . which may require updating the dispatchable location.”  AT&T Comments at 8.  NTCA states that the accuracy of dispatchable location information as discussed in the Notice often depends on an MLTS end-user customer “continually and proactively updating the data at issue, such as the location of handsets and/or individual users within buildings or multiple buildings as the case may be.”  NTCA Comments at 2.  NTCA adds that “by contrast, service providers—after initial installation or configuration of the MLTS—lack visibility into any individual user’s location to accurately, and on a timely basis, update handset location or other relevant data.”  Id.; see also Letter from Brian Hurley, Vice President of Regulatory Affairs, ACA Connects, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, at 2 n.6 (filed April 22, 2019) (ACA Connects April 22 Ex Parte) (noting that ACA interprets the proposed rules to mean that a provider which follows the requirements for installing, operating, or managing an MLTS should be deemed to have met its obligation under the rule to “configure” the MLTS to provide dispatchable location “notwithstanding any failure of the customer to supply accurate location information or to keep the information current”).
 and selecting an appropriate destination point for the 911 notification. See Verizon Comments at 3 (stating that covered MLTS entities will need to rely on the representations of the enterprise customer regarding any appropriate destination point for the notification, “as the customer is ultimately responsible for matters such as office design, staffing levels, and employee training and duties”); NCTA Reply at 5 (stating that end user customers should specify the location where the notification is to be sent, rather than imposing that burden on the MLTS provider); RingCentral Reply at 9 (stating that “the customer is in the best position to determine the location for the notification requirement, and whether there is any value to notification at all”).
  As INCOMPAS and NCTA point out, the owner/customer in such situations is performing some of the functions of an MLTS operator or manager.  Specifically, INCOMPAS states that in most circumstances, the customer or owner serves as the true operator of the system and exercises considerable control over MLTS service provided by INCOMPAS members. INCOMPAS Reply at 4.
  Once the system is installed and configured, the enterprise customer controls the amount of information that flows to managers and operators of these systems, including location information, and decides the responsibilities for the parties involved. Id.
  Where enterprise customers have assumed primary operational roles with respect to the MLTS, INCOMPAS urges the Commission to “be careful not to attach liability for violations of the rules to providers that are only engaged in technical support or network oversight.” Id. at 5.
  NCTA asserts that some MLTS networks—typically those that use a customer-managed PBX—enable a customer to program or alter the calling pattern of a MLTS. NCTA Comments at 2.
  In those instances, NCTA urges the Commission to assign sole responsibility for ensuring compliance with Kari’s Law to the customer, who would be “engaged in the business of managing an MLTS,” rather than the voice service provider or equipment installer.Id.
  Comcast also points out that an enterprise owner may choose to take on additional responsibilities with respect to the MLTS. Comcast states that enterprise customers may control the routing of calls and urges the Commission to “state clearly” that in such a situation the enterprise’s voice service provider has fulfilled its responsibilities under the statute and regulations if it ensures that its service will not interfere with the customer’s ability to configure the MLTS to be capable of transmitting direct-dialed 911 calls.  Comcast Reply at 5.  Comcast states that for example, “if the customer separately purchases a PBX and trunking service to interconnect to the PSTN, the trunk service provider’s obligation should be satisfied if the trunking service does not prohibit 911 direct dialing.”  Id. at 5 n.11.

95. To the extent a violation of the statute or rules results from failure of the enterprise owner/customer to perform these tasks properly, the owner/customer will be responsible for that violation.  Consistent with this approach, we agree with NCTA and Comcast that if the enterprise customer controls the routing of calls, the enterprise’s voice service provider has fulfilled its responsibilities under the statute and regulations if it ensures that its service will not interfere with the customer’s ability to configure the MLTS to be capable of transmitting direct-dialed calls to 911.  
96. AT&T, RedSky, and USTelecom urge the Commission to clarify that the MLTS installer, manager, or operator need only offer the central notification capability to the customer to be in compliance with the law. AT&T Comments at 7-8; RedSky Comments at 11; USTelecom Comments at 4; RedSky Reply at 9-10.
  AT&T states that some customers may not wish to have central notification if, for example, they have a small facility or they do not have staff to support monitoring notifications at all hours, and “the MLTS provider should not be responsible for compelling the customer to utilize a capability that the customer has judged unnecessary.” AT&T Comments at 7-8. 
  USTelecom states that an enterprise customer may choose not to designate or maintain a central notification point. USTelecom Comments at 4.
  We agree with these commenters that a manager, operator, or installer should not be liable if it performs its obligations in compliance with the statute and rules, but the enterprise customer declines to use the services offered.
4. Compliance Date and Transition Provisions
97. The effective date provision of Kari’s Law states that the statute “shall apply with respect to a multi-line telephone system that is manufactured, imported, offered for first sale or lease, first sold or leased, or installed after” February 16, 2020. 47 U.S.C. § 623 note.
  In the Notice, the Commission proposed that the compliance date for regulations implementing Kari’s Law would be consistent with this date. Notice, 33 FCC Rcd at 8997, para. 39.
  Accordingly, the proposed direct dialing and notification requirements would apply to MLTS manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020.Id.
  The Commission sought comment on this proposed compliance date as well as on alternatives, and stated that commenters offering alternatives should explain how any date other than February 16, 2020, would be consistent with the statutory language.Id.

98. The Commission also sought comment on whether to adopt transitional rules to inform consumers of the 911 capabilities of legacy MLTS that are not subject to the direct dialing and notification requirements of Kari’s Law. Id. at 8998, para. 41.
  The Commission noted, for example, that the direct 911 dialing and notification statute enacted in Texas requires enterprises to place a sticker adjacent to or on non-compliant MLTS devices providing instructions on how to call 911, Id. (citing Tex. Health & Safety Code Ann. § 771A.001(e)(2)(C); 1 Tex. Admin. Code § 251.16(c), (d)(7)).  The Commission also noted that Utah’s version of Kari’s Law requires the enterprise to post a notice near each non-compliant telephone stating that the phone may not be used to directly access 911 services by dialing 911, indicating how an individual may access 911 through the telephone, and providing the street address and other location information for the telephone.  Id. at 8998 n.74 (citing Utah Code Ann. § 69-5-205(2)).
 and that the Commission’s interconnected VoIP E911 rules require service providers to distribute stickers or labels warning subscribers that E911 service may be limited. Id. at 8998, para. 41 (citing 47 CFR § 9.5(e)(3)).
  The Commission sought comment on whether to require MLTS installers, operators, and managers to notify callers how to dial 911 from legacy systems, as well as options for doing so, associated costs, and potential sources of statutory authority for such requirements. Id.

99. Some commenters support the proposed compliance date of February 16, 2020. See AHLA Comments at 4; Verizon Comments at 2; West Safety Comments at 4; Ad Hoc Reply at 6-7; Cisco Reply at 6.
  Other commenters support an earlier compliance date. See APCO Comments at 2-3; BluIP Comments at 6-7; Florida Bureau of Public Safety Comments at 1; RedSky Comments at 10; BRETSA Reply at 7; RedSky Reply at 10.  
  The record also is divided on whether the Commission should adopt transition rules, such as disclosure requirements, for legacy MLTS.
100. We adopt a compliance date of February 16, 2020, for the regulations implementing Kari’s Law.  This is supported by commenters such as West Safety, which asserts that the February 16, 2020, compliance date will afford market participants “sufficient advanced notice to make informed manufacturing, planning, and purchasing decisions and will give enterprises the proper level of financial and operational flexibility to retain their existing, grandfathered MLTS until end-of-life.” West Safety Comments at 4.  Ad Hoc further asserts that the Commission has no authority or mandate to impose requirements on operators of legacy MLTS equipment and that any such requirement would “impose huge implementation costs on large and small businesses.”  Ad Hoc Reply at 6-7.  
  
101. We decline to adopt an earlier date because we find that the February 16, 2020, date is consistent with the plain language of Kari’s Law, as well as with the intent of the statute.  The statute applies prospectively as new MLTS are brought into use after February 16, 2020, or as existing systems are installed or first sold or leased after that date.  This indicates that Congress intended to balance the benefits of requiring direct dialing before that date against the cost to enterprises of having to implement these requirements with respect to existing, legacy equipment currently in use.  Commenters who urge the Commission to adopt an earlier date do not address how that would be consistent with the statutory language of Kari’s Law. See, e.g., APCO Comments at 2-3; BluIP Comments at 6-7; Florida Bureau of Public Safety Comments at 1; RedSky Comments at 10; BRETSA Reply at 7, 13.
  
102. With respect to transition obligations, Ad Hoc asserts that the Commission has no statutory authorization to adopt transitional rules for grandfathered MLTS equipment. Ad Hoc Comments at 10.
  Further, Ad Hoc urges the Commission to refrain from “impractical mandates” for notification to end users, such as stickers on equipment, also deeming them “ineffective.” Id. at 10, 11 (“Many of the phones at issue in the enterprise market are soft phone clients that reside on laptops or wireless smartphones, making stickers impracticable.”); see also AT&T Comments at 7 (stating that stickers are ineffective); Ad Hoc Reply at 6-8.
  AT&T similarly states that the Commission should not require warning labels for grandfathered MLTS because many of these systems have been in place for years, and requiring warning labels on each of them would be “incredibly disruptive to customers.” AT&T Comments at 7.
  Panasonic states that the Commission should not impose specific employee notification requirements on MLTS installers, operators, and managers but should instead encourage “voluntary, industry-led initiatives” to do so. Panasonic Comments at 18.  
  TIA urges the Commission to launch a public education campaign aimed at educating the public on the capabilities of legacy MLTS equipment and, as part of this program, to take steps to ensure that potential MLTS users are aware of their system’s capabilities. TIA Comments at 12.
  NENA and NASNA, on the other hand, urge the Commission to adopt disclosure requirements for legacy MLTS. See NASNA Comments at 3; NENA Comments at 4.
  NENA asserts that it strongly supports some form of conspicuous notification on any MLTS handset not in compliance with the end-state Kari’s Law implementation rules and that it has enumerated model requirements for such notification in its Model MLTS Legislation. NENA Comments at 4, citing NENA Model MLTS Legislation § 6(a)(2)(A)-(C), https://c.ymcdn.com/sites/www.nena.org/resource/collection/C3D071C2-FACD-41CB-A09C-354888272EF8/MLTS_2015.pdf. 
  NASNA states that the Commission should require MLTS owners to place a sticker near or on non-compliant MLTS devices “to avoid situations such as the one that gave rise to Kari’s Law in the first place.” NASNA Comments at 3.  Verizon notes that the sticker/label rule for interconnected VoIP services was designed with end user retail consumers in mind and that “[o]perators and managers of enterprise systems, however, have a different relationship with an end user employee than, say, a hotel does with a guest.  Alternative notification methods that are reasonably targeted to the user(s) in question, such as device or monitor displays or priority employer-employee communications, should be permitted as well.”  Verizon Comments at 4.
 
103. We decline to require enterprises to notify end users of the 911 capabilities and limitations of MLTS that are not subject to the statute and our rules.  Such a requirement falls outside the scope of Kari’s Law and this proceeding to implement it.  And even if we were consider adopting such a requirement under other statutory authority, neither the Notice nor the record comment has addressed how the benefits weigh against the costs of imposing such a requirement. As we are not adopting this requirement, we find it unnecessary to address arguments that we lack legal authority to support doing so.
  Instead, as Panasonic suggests, we encourage enterprises to disclose the limitations on dialing 911 from such MLTS as part of voluntary best practices.  
104. AT&T and NASNA also raise the issue of what level of upgrades to an existing MLTS would be significant enough to constitute manufacture, importation, sale, lease, or installation triggering compliance with Kari’s Law when upgrades are made after February 16, 2020.  AT&T states that upgrades unrelated to core MLTS functions in legacy systems should not trigger the obligation to comply with Kari’s Law and the implementing rules. See AT&T Comments at 3.  AT&T states that in the disability access context, the Commission classified “substantial upgrades” as “those changing the nature of the product or service, on the rationale that such upgrades would give the provider a natural opportunity to consider implementing the new requirements.”  Id. at 3-4 (citing Implementation of Sections 716 and 717 of the Communications Act of 1934, as Enacted by the Twenty-First Century Communications and Video Accessibility Act of 2010; Amendments to the Commission’s Rules Implementing Sections 255 and 251(a)(2) of the Communications Act of 1934, as Enacted by the Telecommunications Act of 1966; Accessible Mobile Phone Options for People who are Blind, Deaf-Blind, or Have Low Vision, CG Docket Nos. 10-213, 10-145, WT Docket No. 96-198, Report and Order and Further Notice of Proposed Rulemaking, 26 FCC Rcd 14557, paras. 122-23 (2011)).  According to AT&T, the same logic should apply in this context for the concept of “substantial upgrades.”  AT&T Comments at 3.
  NASNA urges the Commission to ensure that any improvements to MLTS hardware or software that an enterprise makes in the future provide direct dialing and notification capabilities, as well as the same dispatchable location information that would be received by a PSAP. NASNA Comments at 2.

105. On the basis of the record here, we decline to specify the level of improvements to an existing MLTS that would trigger compliance with the statute and regulations.  We disagree with NASNA that any improvements to an existing MLTS, no matter how minor, should trigger the obligation to comply with Kari’s Law and the implementing regulations.  We conclude that such a policy would be inconsistent with the plain language of Kari’s Law, which limits application of the statute to MLTS manufactured or brought into use after February 16, 2020, and with our decisions about upgrades in the context of the discussion above regarding the definition of “improvement to the hardware of software of the system.” We find the same to be true of AT&T’s suggestions regarding application of the concept of “substantial upgrades” to this context.  See supra Section III.A.3.d.
  It is also unclear what would constitute core MLTS functions in this context and exploring this issue further and more broadly could add to the resources that will be required to comply with the requirements of Kari’s Law and our implementing regulations.  Thus, we believe it would be difficult to answer this question in the abstract and more appropriate for the Commission to address it in response to a specific fact pattern, should one arise.  Parties may file a request for a declaratory ruling to eliminate uncertainty, and the Commission can resolve any uncertainty in the marketplace as warranted.  
5. Enforcement
106. Kari’s Law empowers the Commission to enforce the statute under Title V of the Act, “except that section 501 applies only to the extent that such section provides for the punishment of a fine.” See 47 U.S.C. § 623(e).  Section 501 provides for enforcement via fines and, under some circumstances, imprisonment.  See 47 U.S.C. § 501.  Kari’s Law thus precludes enforcement via imprisonment.
  The Commission sought comment in the Notice on how it should enforce and provide oversight of the requirements of Kari’s Law. Notice, 33 FCC Rcd at 8998, para. 42.
  The Commission also noted that there can be great variation in the business relationships between MLTS installers, operators, and managers and sought comment on who, or which entities, should bear responsibility for violations of the proposed rules. Id. at 8998, para. 43.  
  In addition, the Commission proposed to apply a presumption that the MLTS manager bears ultimate responsibility for compliance with the rules implementing Kari's Law. Id. at 8998-99, para. 44.
  As an example, the Commission stated that if an MLTS fails to comply with the rules, the MLTS manager would be presumed to be responsible for that failure, at least in part, unless the manager can rebut that presumption by demonstrating compliance with its obligations under the statute and rules. Id.
  The Commission sought comment on this proposal. Id.
  The Commission also asked how it should apportion liability in situations where multiple parties may be responsible for compliance with the statute and proposed rules, including whether there are situations in which parties should be held jointly responsible. Id.

107. As proposed, we adopt a rule that if an MLTS fails to comply with the rules, the MLTS manager is presumed to be responsible for that failure, at least in part, unless the manager can rebut the presumption by demonstrating compliance with its obligations under the statute and rules. See infra Appendix A, final rule § 9.17(a)(2).
  Most commenters that address the issue support the proposal for a presumption that the MLTS manager bears ultimate responsibility for compliance with the rules implementing Kari's Law. See NCTA Comments at 2; NPSTC Comments at 4; INCOMPAS Reply at 4-5; NCTA Reply at 2. 
  INCOMPAS, for instance, states that it supports the presumption because where enterprise customers have assumed primary operational roles with respect to the MLTS, “the Commission needs to be careful not to attach liability for violations of the rules to providers that are only engaged in technical support or network oversight.” INCOMPAS Reply at 5.
  
108. Verizon, on the other hand, asserts that the Commission should not adopt the presumption because it would not reflect the variety of contractual arrangements that can allocate implementation and system maintenance duties among installers, operators, managers, and enterprise customers. Verizon Comments at 4-5.
  Instead, Verizon asserts, the Commission should assess compliance “based on how the contractual arrangements allocate the respective responsibilities.” Id. at 5.
  We disagree that the presumption would be inconsistent with such multi-party contractual arrangements.  We intend to have a case-by-case determination of who is “engaged in the business of managing” the MLTS (including by looking at the parties’ contracts) before imposing liability.  The party or parties that managed the MLTS would then have the burden of going forward with evidence to show that they met their obligations under the statute and rules.
109. We decline to adopt the proposals of RedSky and Avaya for apportioning liability in situations where multiple parties may be responsible for compliance.  RedSky states that if the MLTS manufacturer does not provide a system that can meet the requirements, it should bear 100% of the responsibility; if the MLTS manufacturer provides a system that can meet the requirements and the operator chooses not to offer the required services, the operator should bear 100% of the responsibility; and if the manufacturer and the operator offer to meet the required services, then the MLTS end user should bear 100% of the responsibility. RedSky Comments at 12.
  Avaya asserts that the MLTS operator ultimately should be responsible for compliance and that if services are subcontracted, the operator must ensure that the subcontractor implements compliant technologies and should remain primarily responsible for compliance. Avaya Comments at 6.
  Ad Hoc responds that the proposals of RedSky and Avaya would amount to a presumption that the operator is liable in certain circumstances and that the Commission should “reject this premature, overzealous and ineffective approach to enforcement of any rules it may adopt in this proceeding.” Ad Hoc Reply at 12.
  Instead, we believe a case-by-case assessment of liability based on the facts specific to the particular investigation is the most appropriate way to enforce Kari’s Law and our rules. The Florida Bureau of Public Safety urges the Commission to adopt a tiered approach to the enforcement of violations of Kari’s law under which first time offenders would receive a warning “with a strict but reasonable time frame to correct any deficiencies and with an appropriate penalty if the violation is not corrected.”  Florida Bureau of Public Safety Comments at 1.  We decline to adopt this proposal because we believe it would be inappropriate to limit the Commission’s enforcement discretion in this manner.
  
110. We also decline to establish the safe harbor suggested by INCOMPAS.  INCOMPAS asserts that if a manufacturer furnishes an MLTS with appropriate functionality, and an installer configures a system capable of direct dialing, alert notification, and sending dispatchable location information, then the Commission should provide a “safe harbor for these parties in the service chain from liability if and when properly installed MLTS are not ultimately used properly.” INCOMPAS Reply at 6.
  Panasonic and TIA state that equipment manufacturers should not be liable for noncompliance of an MLTS manager with Commission rules unless the reason for the noncompliance is the design of the MLTS equipment. Panasonic Comments at 18; TIA Comments at 13.
  A manager, an operator, or an installer would not be liable if it performs its obligations in compliance with the statute and rules, but the enterprise customer declines to use the services offered.  The same principle would apply to MLTS manufacturers, importers, sellers, and lessors; if the manufacturer, importer, seller, or lessor satisfies its obligations under the statute and rules, but the enterprise declines to use the system properly, then the manufacturer, importer, seller, or lessor should not be liable for the resulting noncompliance.  Determinations of responsibility among multiple parties will necessarily be fact-specific, and we do not believe a safe harbor is appropriate or needed.  
111. We also decline to exclude equipment manufacturers from liability for the noncompliance of an MLTS manager unless the noncompliance results from the equipment’s design, as Panasonic and TIA request.  We find that the manufacturer’s obligations and potential liability under Kari’s Law and our rules are sufficiently clear and that the enforcement approach Panasonic and TIA propose is not needed.  Further, Kari’s Law and our rules do not reference the “design” of an MLTS, and we believe doing so would introduce ambiguity into the enforcement process.
6. Complaint Mechanisms
112. In the Notice, the Commission stated that it envisioned relying on existing Commission complaint mechanisms to facilitate the filing of complaints for potential violations of Kari’s Law. Notice, 33 FCC Rcd at 8999, para. 45.
  For example, the Commission stated, PSAPs and the public could report problems via the Public Safety and Homeland Security Bureau’s Public Safety Support Center or the Commission’s Consumer Complaint Center. Id.  The Public Safety Support Center is a web-based portal that enables PSAPs and other public safety entities to request support or information from the Public Safety and Homeland Security Bureau and to notify it of problems or issues impacting the provision of emergency services.  See Public Safety and Homeland Security Bureau Announces Opening of Public Safety Support Center, DA 15-1089, Public Notice, 30 FCC Rcd 10639 (2015); Federal Communications Commission, Public Safety Support Center, https://www.fcc.gov/general/public-safety-support-center (last visited July 16, 2019).  The Consumer Complaint Center handles consumer inquiries and complaints, including consumer complaints about access to 911 emergency services.   Federal Communications Commission, Consumer Complaint Center, https://consumercomplaints.fcc.gov/hc/en-us (last visited July 18, 2019).

113. We conclude that our existing complaint mechanisms should be sufficient for addressing potential violations of Kari’s Law.  Several commenters assert that the Commission’s existing mechanisms are sufficient for the filing of complaints for potential violations of Kari’s Law. NASNA Comments at 3; Panasonic Comments at 19; RedSky Comments at 12 (“Assuming appropriate staffing to investigate and response to these submissions, we agree that the existing mechanisms are appropriate.”); TIA Comments at 13.
  We also provide that persons alleging a violation of the rules implementing Kari’s Law may file a complaint under the procedures set forth in part 1, subpart E of our rules. See infra Appendix A, final rule § 9.17(a)(3) (stating that persons alleging a violation of section 9.16 may file a complaint under the procedures set forth in sections 1.711-1.737 of the rules); 47 CFR §§ 1.771-1.737. 
  
114. We also decline to establish procedures similar to those used for accessibility complaints under the Twenty-First Century Communications and Video Accessibility Act (CVAA) and Section 255 of the Act.  Panasonic and TIA urge the Commission to consider establishing a mechanism similar to that used for accessibility complaints under the CVAA or Section 255 of the Act, including a mechanism for giving MLTS manufacturers, installers, operators, and managers an opportunity to resolve complaints informally before the Commission undertakes any enforcement action. Panasonic Comments at 19; TIA Comments at 13. 
  Although the CVAA includes a provision directing the Commission to establish procedures for complaints and enforcement actions arising out of violation of certain accessibility requirements, Section 717 of the Communications Act, as amended by the CVAA, directs the Commission to “establish regulations that facilitate the filing of formal and informal complaints that allege a violation of section 255, 617, or 619 of this title” and to “establish procedures for enforcement actions by the Commission with respect to such violations.”  Twenty-First Century Communications and Video Accessibility Act of 2010, Pub. L. No. 111-265, 124 Stat. 2795 (codified as amended at 47 U.S.C. § 618(a)); see also 47 CFR §§ 14.30-14.38 (recordkeeping, consumer dispute assistance, and enforcement rules adopted pursuant to section 618(a)).
 Kari’s Law does not include a corresponding provision.  In addition, the Public Safety Support Center and Consumer Complaint Center procedures are flexible enough to provide an opportunity for informal resolution of complaints prior to enforcement should the Commission determine that such an opportunity would be appropriate.  
115. BRETSA urges the Commission to establish a separate mechanism for PSAPs to report MLTS noncompliance. See BRETSA Reply at 19.
  We decline to do so, given that the Public Safety Support Center process will be sufficient for this purpose. 
7. Preemption of State Law
116. The preemption provision of Kari’s Law states that “[n]othing in this section is intended to alter the authority of State commissions or other State or local agencies with jurisdiction over emergency communications, if the exercise of such authority is not inconsistent with this chapter.” 47 U.S.C. § 623(d) (“Effect on State Law”); see also Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017) (stating that the preemption language of Kari’s Law “clarifies that this legislation does not alter the authority of state or local agencies with jurisdiction over emergency communications, as long as that authority isn’t exercised in a manner inconsistent with this legislation”).  
  Commenters sought guidance, however, regarding the general effects of this provision on state and local law.
117. Specifically, AT&T and BRETSA ask the Commission to clarify the effect of Kari’s Law on state laws affecting 911 service for MLTS. See AT&T Comments at 5 n.14; BRETSA Reply at 17-18. 
  AT&T urges the Commission to clarify how any new federal MLTS requirements will operate “vis-à-vis additional, and sometimes conflicting, state MLTS requirements.” AT&T Comments at 5 n.14.
  AT&T, however, does not provide specific examples of any state requirements that appear to have the potential for conflicting with federal regulations implementing Kari’s Law.  BRETSA asks the Commission to find that state laws requiring existing MLTS systems to provide direct dialing, on-site notification, and interior location information are not inconsistent with Kari’s Law, RAY BAUM’S Act, or the Commission’s proposed rules. BRETSA Reply at 17-18.
  BRETSA, however, does not cite any such state laws, or even assert that any such laws exist.  In addition, BRETSA asserts that federal rules implementing Kari’s Law may establish grounds for civil claims and liability under state common law and statutes and urges the Commission not to limit a state’s authority to “determine civil liability or presumptions thereof, and any immunities therefrom, and any penalties for violation arising from violation of state MLTS 9-1-1 obligations.” BRETSA Comments at 3; see also id. at 10 (proposing a rule stating that “[c]ivil liability for violations of these rules, or immunity therefrom, shall be determined pursuant to state common or statutory law”).
  NARUC notes that it has adopted a resolution suggesting that any federal rules on MLTS direct dialing and notification “should be written to permit States to impose additional requirements ‘presuming that such additional requirements do not contradict or conflict with federal requirements.’” NARUC Ex Parte at 2.
  NARUC’s resolution does not supply specific examples, however.
118. As mentioned above, our objectives in the context of this broader rulemaking are to prescribe rules and regulations that we find are necessary to carry out Kari’s Law, and to provide additional clarity and specificity regarding some of the terms used in the statute and the obligations placed on covered entities.  We chose, in our discretion, to proceed incrementally, and thus did not propose to offer interpretations or rules going to the preemption provision of Kari’s Law.  Thus, at this time, and based on the record in this proceeding, we decline to provide guidance on the general effect of Kari’s Law and our implementing regulations on individual state and local laws or on the “exercise of . . . authority” of a state’s or locality’s “jurisdiction” over “emergency communications” See 47 U.S.C. § 623(d).
 under a hypothetical set of facts.  The record does not reflect specific examples (or even sufficient indication of a widespread problem) of state or local exercise of jurisdiction that may be inconsistent with the federal regulatory regime. Cf. Alascom v. FCC, 727 F.2d 1212, 1219 (D.C. Cir. 1984) (holding that the issue of the Commission’s authority to preempt inconsistent state regulations “is not a purely legal one” and that “underlying questions of fact pervade the determination of the scope of the Commission’s statutory jurisdiction”).

119. In addition, BRETSA asserts that waiver is an essential element of a regulatory scheme and asks the Commission to clarify that state or local public safety agencies and officials have authority to grant waivers of the federal MLTS 911 rules “upon finding that alternative deadlines and arrangements better serve the public safety or will avoid undue financial hardship.” BRETSA Reply at 18 (stating that waivers should be based on “local facts including, for example, the nature of the facility served by the MLTS, qualifications of enterprise personnel, location of fire stations in relation to the facility, specialized requirements for addressing incidents at the facility which First Responders are not trained and equipped to address but private responders engaged by the enterprise are trained and equipped to address”); see also BRETSA Comments at 3-5 (asserting that state and local authorities must have authority to grant waivers and exceptions to the Commission’s MLTS 911 rules).
  BRETSA also asserts that state and local public safety officials and agencies should have the opportunity to impose conditions on waivers, such as training requirements for enterprise personnel or contractors. BRETSA Reply at 18.  But see Avaya Comments at 6 (“Waivers should not be encouraged, because many systems that may not be compliant can be upgraded at minimal expense.”).
  We decline to find that state and local public safety authorities have authority to waive the Commission’s MLTS rules, as BRETSA requests, or to impose conditions on such waivers.  Requests for such waivers should, as with other Commission requirements, be presented to the Commission, while requests for waivers of state and local requirements should be presented to the appropriate state or local governmental entity.
8. Equipment Authorization Rules
120. The Commission also sought comment in the Notice on whether to modify the equipment authorization rules as they apply to MLTS equipment manufactured after February 16, 2020. Notice, 33 FCC Rcd at 8999, para. 46.
  In addition, the Commission asked whether MLTS applications for equipment authorization under Parts 2, 15, or 68 should constitute a representation that such equipment complies with MLTS 911 requirements. Id. (citing 47 CFR part 2, subpart J (Equipment Authorization Procedures); 47 CFR part 15 (Radio Frequency Devices); 47 CFR part 68 (Connection of Terminal Equipment to the Telephone Network)).

121. Commenters largely support using existing equipment authorization rules.  While NPSTC recommends that the Commission implement a formal process for compliance with the provisions of Kari’s Law as part of an equipment authorization process, NPSTC Comments at 5.  RedSky also asserts that MLTS applications for equipment authorization under Parts 2, 15, or 68 should constitute a representation that such equipment complies with the MLTS 911 requirements.  RedSky Comments at 12. 
 other commenters state that a formal process would be unworkable because many MLTS products are software-based solutions that need to be configured and installed on premises. TIA Comments at 14; Cisco Reply at 14. 
  Panasonic and TIA also assert that any modified equipment authorization rules would apply only to hardware-based solutions and that this would constitute an unequal burden on such solutions. Panasonic Comments at 19; TIA Comments at 14. 

122. We decline to amend our equipment authorization procedures because we conclude that the existing equipment authorization procedures are sufficient.  The MLTS marketplace represents a broad range of technologies that are continuing to evolve from more traditional, circuit-based solutions to wireless, cloud-based, and VoIP solutions, and we seek to ensure that our rules preserve flexibility and maintain technological neutrality.  
9. Voluntary Best Practices
123. The Commission in the Notice asked commenters to identify voluntary best practices that can improve the effectiveness of direct dialing and notification for MLTS. Notice, 33 FCC Rcd at 8999, para. 47.
  The Commission noted, for example, that the Michigan State 911 Committee encourages MLTS operators to work directly with local public safety entities to ensure compliance and “strongly recommend[s] that every MLTS operator work with their local 911 system manager/director to test the ability to dial 911 from the station lines associated with MLTS systems any time an MLTS has been installed or upgraded.” Id. (citing Michigan State 911 Committee, Guidelines for Multi-Line Telephone Systems at 5 (July 2018), https://www.michigan.gov/documents/msp/FINAL_MLTS_Guidelines_503991_7.pdf).
  The Commission sought comment on this and other recommended or potential best practices that would help enterprises ensure the effectiveness of direct dialing and notification, including best practices for training on-site emergency personnel and others responsible for the implementation of direct dialing and notification. Notice, 33 FCC Rcd at 8999, para. 47. 
  Commenters that address this issue generally encourage the development of voluntary best practices for direct dialing and notification under Kari’s Law. 
124. We encourage industry and the public safety community to work together to develop voluntary best practices that will help enterprises facilitate first responder access and minimize delays to response.  NENA states that “[r]ecognizing the diversity in enterprise IT staffing . . . means all players in the MLTS 9-1-1 space—including manufacturers, sellers, and 9-1-1—should contribute to education and development of best practices for MLTS operation.” NENA Comments at 5.
  Cisco and BRETSA note the need for development of a standard testing protocol that would be employed when installers configure MLTS for 911, Cisco Comments at 15; BRETSA Reply at 29-30.
 which we believe may be helpful.  TIA states that efforts are underway to create a working group with members from industry and public safety to develop best practices and standards regarding Kari’s Law requirements and the dispatchable location mandate under RAY BAUM’S Act. See Letter from Colin Black Andrews, Policy Counsel, Government Affairs, TIA, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, at 1-2 (filed March 25, 2019) (TIA and DECT Forum Ex Parte).  
  Several commenters also emphasize the need for a public awareness or education campaign for entities affected by the new rules. NPSTC Comments at 5; Panasonic Comments at 18; RedSky Comments at 13; TIA Comments at 12; Cisco Reply at 13.
  As noted above, we also believe it may be helpful for this effort to include guidance on disclosing the limitations of 911 dialing from legacy MLTS equipment. See, e.g., Cisco Reply at 13 (suggesting that enterprise managers notify employees how to reach emergency services, which could occur during the onboarding process for new employees and on an annual basis for existing employees).
  
125. Some commenters make suggestions we believe are more appropriate for inclusion in voluntary best practices.  BRETSA suggests that the Commission require MLTS providers to supply a copy of the rules to each customer. BRETSA Comments at 5.
  NENA asserts that although MLTS operators and managers are generally in the best position to maintain the unique registered locations of their MLTS, vendors and manufacturers “must bear some responsibility to (1) encourage accurate and regular update of location information, and (2) provide means to alert operators and managers when registered location information has become out-of-date or hardware has been moved.” NENA Comments at 7.
  We decline to require these practices, but we encourage industry and public safety entities to consider them in the development of best practices.
126. We also agree with commenters about the importance of public outreach, and we intend to quickly develop and disseminate informational materials and to collaborate on outreach with our federal, state, and local partners, the public safety community, and industry. See, e.g., Letter from Mary Brown, Senior Director, Governmental Affairs, Cisco Systems, Inc., to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, at 1 (filed July 24, 2019);  Letter from Mary Brown, Senior Director, Governmental Affairs, Cisco Systems, Inc., to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239 at 1 (filed July 26, 2019).

10. Comparison of Benefits and Costs
127. The Commission sought comment on the costs and benefits of satisfying its proposed direct dialing and notification rules for MLTS coming into service after February 16, 2020. Notice, 33 FCC Rcd at 9000, para. 49.  In the Notice, the Commission sought comment on whether most MLTS systems currently deployed do not allow direct dialing of 911 and/or cannot be configured to provide notification of 911 calls to an MLTS manager.  Id. at 9000, para. 48.
  The Commission asked whether there are alternative methods of meeting the requirements of Kari’s Law that would reduce costs and/or increase benefits and whether there are any barriers for those wishing to replace their MLTS after this date that would be costly to overcome. Id. at 9000, para. 49.
  The Commission also requested comment on the expected lifespan of existing MLTS that are not currently able to meet the requirements of the proposed rules, the prevalence of such systems today, and the expected prevalence of such systems in 2020. Id.
  In addition, the Commission sought comment on the cost of upgrading to an MLTS that supports the requirements of the proposed rules. Id.
  The Commission noted that “[b]ecause most of the currently deployed MLTS are capable of being configured to meet the requirements of our rules today, without improvement to the hardware or software of the system, we tentatively conclude that our rules will impose no incremental costs to those who replace their MLTS as they come to the end of their useful life.” Id.
  Accordingly, the Commission sought comment on this tentative conclusion. Id.  
 
128. Regarding notification, the Commission sought comment on its tentative conclusion that the costs of implementing its proposed requirements will not exceed the value of their benefits. Id. at 9001, para. 50.
  The Commission also sought comment on any particular costs involved in imposing the notification requirement and alternative methods consistent with Kari’s Law that may reduce costs and/or improve benefits. Id. 
  Further, the Commission sought comment on the costs and benefits associated with its proposed definitions.  Id.  For example, the Commission sought comment on the costs and benefits associated with a requirement to convey the caller’s location with the on-site notification or a requirement to staff the notification point.  Id. at 9001 n.91.
  The Commission also asked for comment on the benefits and costs associated with any additional notification requirements the Commission might adopt, such as requiring operators of legacy MLTS to inform consumers of the 911 capabilities of those systems. Id.

129. Some commenters support the Commission’s tentative conclusions. See, e.g., ADT Comments at 4 (“As reflected in the Notice, most MLTS sold and installed today have this notification capability.”); RedSky Comments at 14; West Safety Comments at 3-4.
  West Safety states that the proposed rules also appropriately balance the benefits and costs of implementation of direct dialing and notification by setting a compliance date of February 16, 2020, consistent with Kari’s Law. West Safety Comments at 3.
  West Safety asserts that “direct access to 9-1-1 without a dialing prefix can typically be implemented by appropriate configurations to MLTS of all types at little or no cost to the enterprise.” Id.; see West Safety Enterprise Communications NOI Comments at 10.
  West Safety also states that notification functionality is available natively in most MLTS equipment or can be supported via a third-party application. West Safety Comments at 3.
  Accordingly, West Safety asserts, “the cost of implementation is minimal, whereas the benefits of closing this regulatory gap are significant.” Id. at 4; see West Safety Enterprise Communications NOI Comments at 26-28.
  Moreover, by adopting a prospective compliance date that applies only to MLTS offered for first sale after February 16, 2020, West Safety submits that “market participants will be afforded sufficient advanced notice to make informed manufacturing, planning and purchasing decisions, and enterprises will have the proper level of financial and operational flexibility to retain their existing, grandfathered MLTS until end-of-life.” West Safety Comments at 4.
  Regarding alternative methods of meeting the requirements of Kari’s Law that would reduce costs and/or increase benefits, RedSky states that it offers a no-cost notification service when its call routing service is used. RedSky Comments at 14.
  RedSky also states that for those wishing to replace their MLTS after February 16, 2020, “[t]he cost with or without support to meet the requirements of the Rule should be equivalent.” Id.
  RedSky believes that the vast majority of existing MLTS can meet the requirements of the rule without significant modification. Id.

130. Other commenters generally agree with the Commission’s proposals, but advocate that the Commission take a more measured approach towards adopting rules implementing Kari’s Law than that suggested in the Notice. Ad Hoc Comments at 4 (supporting the Commission’s proposed rules in the Notice, Appendix A, proposed rule § 9.16(a) and § 9.16(b)(1)-(2), to implement the statutory mandate of Kari’s Law).
  To illustrate, Ad Hoc advises that as the Commission “considers how best to implement the statutory mandates of Kari’s Law and Section 506 of RAY BAUM’s Act, the Commission should strictly adhere to its ‘light touch’ regulatory philosophy.” Id. at 3.
  Regarding notification, for example, Ad Hoc urges the Commission to avoid imposing detailed requirements beyond the proposed rule Id. at 5 (urging the Commission to adopt the rule as proposed and avoid adding more specific or detailed requirements for the content required in the internal notification, either as part of the rule or in any subsequent order adopting the rule). 
 and to refrain from imposing transitional requirements on legacy MLTS. Id. at 10-11.
    
131. The rules we adopt today to implement the direct dialing and notification requirements of Kari’s Law balance the needs of stakeholders and maximize many public safety benefits.  These benefits include potentially preventing fatalities, injuries, or property damage, improving emergency response time and access to emergency services, reducing delays in locating 911 callers, narrowing the gap between MLTS 911 service capabilities relative to other communications services subject to 911 requirements, driving further technology development, and lowering the cost of 911 solutions for MLTS. See NASNA Comments at 1 (noting that the notification “will benefit the caller, the MLTS enterprise management and staff, first responders”); see also Notice, 33 FCC Rcd at 9001, para. 50 (stating that notification can assist MLTS managers in large enterprises in dealing with first responders, facilitate a manager quickly directing and assisting first responders at large enterprises, rather than spending time trying to gather such information, and benefit the 911 caller and first responders by allowing quicker response time).
  The record developed in response to the Notice confirms that many existing, installed MLTS support direct dialing to 911 and notification.  Further, the record developed in response to the 2017 Enterprise Communications NOI suggests that direct dialing and notification rules will impose no incremental costs to those replacing their MLTS at the end of its useful life. For example, in response to the Enterprise Communications NOI, West Safety stated that “[e]nterprises are migrating rapidly to on-premises and hosted Internet Protocol (IP)-based [enterprise communications system] for VoIP and Unified Communications (UC) platforms to reduce voice and network costs and consolidate or eliminate internal infrastructure.”  West Safety Enterprise Communications NOI Comments at 3.  According to West Safety, “[a]ll of these IP-based [enterprise communications systems] and equipment are capable of supporting E9-1-1 with little or no additional cost, and reasonable upgrades and services are available to bring legacy, TDM-based [enterprise communications system] into E911 compliance.  Id.  West Safety added that “[t]he cost of E911 solutions for IP-based [enterprise communications systems] is nominal and E9-1-1 functionality can now be seamlessly integrated across a wide range of VoIP and UC platforms with minimal user effort and automated E9-1-1 location updates.”  Id.  Further, West Safety stated that “[a]part from the potential burden to be imposed on the shrinking (and one-day nonexistent) marketplace for legacy [enterprise communications systems], which can be addressed through a generous implementation schedule tied to the pace of migration to IP, cost and burden should no longer be valid reasons for delaying Commission action.”  Id.  
  Because Congress mandated compliance with its direct dialing and notification requirements after February 16, 2020, and expressly grandfathered MLTS systems in service before that date, Congress has already crafted a balance of costs and benefits with respect to compliance to which the Commission is bound. Consistent with Kari’s Law and the Commission’s proposal in the Notice, our final rules 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.  Notice, 33 FCC Rcd at 9000, para. 49.
  Further, when Congress adopted Kari’s Law, it contemplated that the requirements would evolve with advancements in MLTS technology.  The record in this proceeding reflects that the modern enterprise communications ecosystem is complex and that legacy TDM-based technology is evolving towards an IP-based MLTS environment. 
132. As Congress has specifically legislated to create this framework and identified areas in which the Commission shall enforce the statute, Congress has already assessed the benefits of its requirements.  In the Notice, the Commission observed that a Congressional Budget Office analysis concluded that most MLTS systems already are configured to meet the direct dialing and notification requirements of Kari’s Law. Id. para. 48 (citing Congressional Budget Office (CBO), Cost Estimate, S. 123, Kari’s Law Act of 2017 (2017), https://www.cbo.gov/publication/52424). 
  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. Id. (citing Cisco Enterprise Communications NOI Comments at 6).  The Commission noted that West Safety adds that “[d]irect access to 9-1-1 without a dialing prefix can typically be implemented by appropriate configurations to [enterprise communications systems] of all types at little or no cost to the enterprise”).  Id. at n.85.
  In the Notice, the Commission cited eight states and some local governments that already have laws requiring direct dialing for 911 from MLTS. See 50 Il. Comp. Stat. 750/15.8(a); Me. Rev. Stat. Ann. title 25, § 2934-A; Md. Code Ann., Public Safety § 1-314; Okla. Stat. Ann. title 63, § 2855.1.A; 35 Pa. Cons. Stat. § 5311.22; Tenn. Code Ann. § 7-86-403(a); Tex. Health & Safety Code Ann. § 771A.001(c); Utah Code Ann. § 69-5-205; see also, e.g., N.Y.C. Admin. Code § 10-176.b.  We are aware that some states and localities have requirements that are similar to the ones we are adopting here today.  We are not aware, however, of state or local requirements that would conflict with this federal regime.  As noted above, we will address questions regarding any such conflicts if they are presented to us with sufficient specificity to assist our review.
  For these state and local jurisdictions, the Commission noted that its proposed rules would generally not affect the status quo and so would likely have little to no impact from a cost perspective. Notice, 33 FCC Rcd at 9000, para. 48.
  Moreover, the Commission observed that the existence of state-level requirements has already driven the manufacture of MLTS equipment that supports 911 direct dialing, much of which may have been marketed and sold in jurisdictions that do not have state or local requirements. Id.

133. In this analysis, we address whether our rules achieve the benefits of Kari’s Law in a cost-effective manner.  The record supports adopting implementing regulations of Kari’s Law and the Commission’s conclusion in the Notice that these rules are necessary to provide additional clarity and specificity regarding the terms used in the statute and the obligations placed on covered entities. Id. at 8991, para. 17.  
  As demonstrated by commenters, implementing regulations can provide important guidance to covered entities on complying with the law and the mechanism the Commission will use to enforce the statute. See, e.g., TIA Comments at 6 (stating that “[r]ules requiring direct dialing and on-site notification of 911 calls from MLTS are clearly required by Kari’s Law”); West Safety Comments at 3 (agreeing with the Commission’s conclusion that “rules are necessary to provide additional clarity and specificity for effective implementation”).  
  Accordingly, our rules include definitions of some of the terms in Kari’s Law, as well as other provisions to clarify the obligations of entities regulated under the statute.  The rules we adopt today generally track the statutory requirements of Kari’s Law, are technologically neutral, and leverage advances in technology to improve access to emergency services as envisioned by Congress.  The flexibility and minimum criteria we establish for direct dialing and notification should offset any potential burdens associated with compliance with our rules.  Therefore, we conclude that there will be no immediate costs associated with meeting the requirements of our rules and that the amount of flexibility and lead time for compliance will help to minimize future potential costs.   
134. The Commission also sought comment on the cost and expected benefit of the options proposed in the Notice for implementing the notification requirement of Kari’s Law, including whether to specify staffing requirements for the notification point. Notice, 33 FCC Rcd at 8994, para. 26.
  The Commission noted that while some state MLTS statutes include notification requirements, these statutes either expressly provide that the enterprise does not have to make a person available to receive a notification, Id. (citing Tex. Health & Safety Code Ann. § 771A.001(d); Okla. Stat. Ann. title 63, § 2855.1.B; Tenn. Code Ann. § 7-86-403(a)(2)).
 or they are silent on whether the destination point must be staffed. Id. (citing 35 Pa. Cons. Stat. §§ 5311.19, 5302); see also N.Y.C. Admin. Code § 10-176.d.
  The Commission stated that it did “not believe Congress intended to impose staffing or monitoring requirements that would impose unreasonable costs or limit the flexibility of MLTS installers, managers, and operators to develop efficient and cost-effective notification solutions that are appropriate for the technology they use, such as visual alerts on monitors, audible alarms, text messages, and/or email.” Notice, 33 FCC Rcd at 8994, para. 26.
  Rather than requiring staffing or monitoring, the Commission believed “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.” Id.  The Commission asked “[w]hat 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?”  See id.  

135. The record supports the Commission’s view that Congress did not intend to impose burdensome staffing or monitoring requirements that would impose unreasonable costs or limit the flexibility of MLTS installers, managers, and operators to develop efficient and cost-effective notification solutions. See Ad Hoc Comments at 8 (stating that “[t]he Commission is correct in noting that nothing suggests Congress intended to impose staffing or monitoring requirements that would impose unreasonable costs—or, any costs, for that matter—or limit the flexibility of MLTS operators to develop cost-effective and efficient notification solutions”); ADT Comments at 4-5 (supporting “the Commission’s suggestion that the notification obligation may be met in whole or in part by configuring MLTS to send notifications to offsite third parties that provide ‘security or safety services’ to the enterprise”); AHLA Comments at 8 (agreeing with the Commission’s statement that “[w]e 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”). 
  The record supports setting minimum criteria for the notification to maximize benefits See, e.g., NENA Comments at 2 (agreeing with the Commission’s assessment that timely notification is essential; “[n]otification contemporaneous with the 9-1-1 call has significantly greater value to all parties than after-the-fact notification, and the majority of a notification’s benefits to response are lost if the notification is not conveyed in real-time”); West Safety Comments at 4-5 (agreeing with the Commission’s proposal that notification be delivered contemporaneous with the 911 call, “as this concurrent timeline is critical to realizing the full benefits of internal responders working together with first responders to gain timely access and direction to the emergency”).
 but also providing enterprises significant flexibility to tailor notifications to meet their specific needs. See, e.g., Ad Hoc Comments at 7, 9 (stating that the Commission “should not now prescribe specific location, configuration, or staffing requirements for destination points” and that “mandated requirements for notification endpoints will ultimately fail to provide effective and achievable standards at a reasonable cost”); Panasonic Comments at 14 (asserting that “the Commission should emphasize flexibility for a given enterprise to determine the content, form, and destination of the notification”).  
  Similarly, the record supports adopting a requirement that notifications be sent to a location on-site or off-site where someone is likely to hear or see the notification, but not requiring that enterprise staff or monitor the notification point at all times. See, e.g., ADT Comments at 5 (stating that small or midsize companies “could cost-effectively utilize alarm or security companies. . . to receive an off-site notification”); Avaya Comments at 5 (stating that Avaya has had discussions with companies looking to add security or alarm services to their suite of products and that in one case, “an alarm company considered consolidating onsite services where it maintained a 24 x 7 presence to ‘cover’ access to other facilities in close proximity on a per call out basis”).
  Additionally, the record suggests that the Commission’s definition of “improvements to the hardware or software of the system” strikes the right balance to ensure that enterprises will not incur significant costs or core system upgrades in connection with providing notification, as provided under Kari’s Law.
136. Taken together, the notification requirements we adopt today establish the necessary conditions that will make it more likely than not that 911 callers using an MLTS upgraded or placed into service after February 16, 2020, will benefit from the notification provisions of Kari’s Law at a negligible cost above what an MLTS manager or owner would already spend when purchasing or upgrading an MLTS. For example, “West Safety supports the Commission’s proposal that the MLTS notification include the same dispatchable location information that the PSAP receives in addition to a valid callback number and an indication that a 9-1-1 call has been made.  Requiring this minimal level of content in the notification aligns with the purpose of Kari’s Law and ensures enterprises will be fully equipped to assist 9-1-1 MLTS callers and first responders.”  West Safety Comments at 4.  West Safety adds that “[a]ny potential burden from this content requirement will be offset by the Commission’s proposal to not require conveyance of the notification to a specific on-site destination point, nor to require specific staffing or monitoring obligations at the enterprise.  Accounting for the proliferation of low-cost systems for remote security and monitoring offered by third-party vendors capable of ensuring these MLTS 9-1-1 notifications will be delivered to points where they will be seen or heard by existing staff, the implementation cost of the proposed rule is minor.”  West Safety Comments at 5.  
  In sum, the record suggests that establishing some minimum criteria represents a cost-effective means to reasonably ensure that notification will be timely received by a person with authority to act on it while balancing the needs of stakeholders, maintaining technological neutrality, preserving flexibility for enterprises, and minimizing burdens associated with implementing the notification requirement of Kari’s Law. 
B. Dispatchable Location for MLTS and Other 911-Capable Communications Services
137. RAY BAUM’S Act directs us to consider rules requiring the conveyance of dispatchable location with 911 calls “regardless of the technological platform used.”  RAY BAUM’S Act, § 506(a).
  Based on this directive, we adopt dispatchable location requirements for MLTS and other 911-capable services that do not have such requirements, including fixed telephony, interconnected VoIP service, Telecommunications Relay Services (TRS), and mobile text.
1. MLTS
138. In the Notice, the Commission observed that when a 911 call is placed in an MLTS environment, the system may provide the PSAP with the location of a main entrance or administrative office rather than the location of the caller, which can lead to delays in locating the caller and result in injury or loss of life. Notice, 33 FCC Rcd at 9001, para. 52.
  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,” See RAY BAUM’S Act, § 506(a) (emphasis added).
 Congress in RAY BAUM’S Act signaled its intent that the Commission focus on ensuring highly precise location information whenever feasible in connection with MLTS 911 calls.
139. In the Notice, the Commission proposed to proscribe the manufacture, import, sale, or leasing of MLTS in the United States unless the system is pre-configured such that, when properly installed, the dispatchable location of the caller will be conveyed to the PSAP with 911 calls. Notice, 33 FCC Rcd at 9002, para 54.
  The Commission further proposed to proscribe the installation, management, or operation of MLTS in the United States unless the system is configured such that the dispatchable location of the caller will be conveyed to the PSAP with 911 calls.  The Notice proposed to apply these requirements to the same entities subject to Kari’s Law. Id.
  We adopt these proposals with certain modifications.  
a. Definition of Dispatchable Location
140. Section 506 of RAY BAUM’S Act defines “dispatchable location” as “the street address of the calling party, and additional information such as room number, floor number, or similar information necessary to adequately identify the location of the calling party.” RAY BAUM’S Act, § 506(a).
  In the Notice, the Commission noted the substantial similarity of this statutory definition to the definition of “dispatchable location” in the Commission’s wireless E911 location accuracy rules. Notice, 33 FCC Rcd at 9002, para. 56.
  The Commission proposed to construe the definitions as functionally identical, aside from the specification of the technological platform to which each definition applies. Id. 
  The Commission also sought comment on whether to further define “additional information” that may be necessary to “adequately identify the location of the calling party.” Id. at 9003, para. 58. 
  Finally, the Commission noted that the wireless E911 definition of dispatchable location requires street address information to be validated, The definition of wireless “dispatchable location” requires that “[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.”  47 CFR § 20.18(i)(1)(i).
 and asked whether validation should similarly be required for dispatchable location information associated with MLTS 911 calls. Notice, 33 FCC Rcd at 9002, para. 57.

141. We adopt the definition of dispatchable location proposed in the Notice, without further specifying the types of location information that may be required to locate callers in specific instances.  We also require that to meet the definition of dispatchable location for MLTS 911 calls (and for calls from other platforms discussed in succeeding sections below), street address information must be validated.  We agree with commenters that the definition of dispatchable location needs to be both functional and flexible. See Cisco Comments at 19; Comtech Comments at 6; Ad Hoc Reply at 9; TIA and DECT Forum Reply at 9-10.
  As APCO states, “[d]ispatchable location is well understood by public safety communications professionals to mean information sufficient for guiding first responders to the right door to kick down.” APCO Comments at 3.  
  However, what constitutes “sufficient” information will vary significantly depending on the environment from which a 911 call originates.  For calls placed from multi-story buildings or campus environments, first responders will typically require specific floor and room information, in addition to the street address of the building.  For calls placed from many small businesses, on the other hand, a street address alone may provide first responders all the information they need to quickly locate the caller. NASNA Comments at 4 (“[T]he Commission correctly states that street address would be adequate for small enterprises.”); NCTA Comments at 6 (asserting that for a small business, “the dispatchable location for any caller often is only the street address, with no need to specify a more granular location”); ACA Reply at 2-3 (“For fixed MLTS used by small enterprises, which doubtlessly comprise a substantial share of all MLTS, a registered street address should adequately identify the location of [a 911 caller] anywhere on the premises.”) (internal quotations omitted).
  
142. Accordingly, the definition of dispatchable location that we adopt today gives participants in the MLTS marketplace flexibility in deciding what level of detail should be included in the location information provided to PSAPs for particular environments, See Ad Hoc Comments 11 (“The Commission should permit MLTS operators to transmit the level of location detail they determine is technically feasible and most appropriate for the safety of their workplaces and employees.”).
 so long as the level of detail is functionally sufficient to enable first responders to identify the location of a 911 caller in that environment. See, e.g., APCO Comments at 6 (stating APCO’s support for the Commission’s proposals “to construe the definitions of dispatchable location in the wireless rules and in RAY BAUM’S Act as functionally identical . . .  [and to] require validation of dispatchable location information associated with MLTS similar to wireless calls”); Bandwidth Comments at 6 (“Bandwidth supports the Commission’s proposed interpretation of the Ray Baum Act definition of ‘dispatchable location.’”); Texas 911 Entities Comments at 5 (stating that the proposed rule definition of ‘dispatchable location’ should be amended to require that the location be “validated and, to the extent possible, corroborated against other location information prior to delivery of dispatchable location to the PSAP”); West Safety Comments at 10 ( “Validation is the one critical piece missing from the proposed definition of dispatchable location.”); BRETSA Reply at 10 (stating that where MLTS serve separate buildings or facilities in areas served by the same PSAP, it is essential that the correct address of the building in which the caller is located, rather than the building where the MLTS core CPE is located be included in the ALI data for the 911 call).  
  Given the diverse and evolving nature of the MLTS market and the breadth of enterprise environments at issue in this proceeding, we decline to expand upon the statutory definition in specifying instances in which “additional information” beyond street address must be made available, See, e.g., ACA Comments at 4 (stating that to promote the provision of location information more granular than street address, “service providers should inform their customers that they can supply more information than just street addresses” and “[w]here the customer provides more granular information—either for the first time or as an update—the provider should be expected to report the information promptly”); AHLA Comments at 4 (asserting that the Commission should not require dispatchable location information to include a hotel guestroom number because it will not be technologically possible in all cases and, at most, the Commission should consider establishing a “baseline requirement” that a building’s street address be included with every 911 call while encouraging enterprises to provide more granular location information where “technically feasible and commercially reasonable”); Comtech Comments at 6 (urging the Commission to “carefully draft any location requirements for MLTS such that MLTS operators have flexibility to determine whether additional location information is necessary in any particular MLTS environment” because “[t]he importance of using some level of supplemental location information to validate dispatchable location information depends on the size of the building, or the size of suites or units in a building, coupled with the amount of detail already included in the civic address”); Panasonic Comments at 3, 20 (“[A]t this time, dispatchable location requirements should be limited to those systems used on-premises and the granularity of required location information should be limited to a street address of the building”); ACA Reply at 2-3 (asserting that ACA members often collect and report dispatchable information more granular than street addresses from the customer and should comply with the RAY BAUM’S dispatchable location standard); NCTA Reply at 6 (stating that small businesses with only a few telephone lines are differently situated than large businesses and do not require more granular location than a street address); TIA and DECT Forum Reply at 7 (“In keeping with congressional intent, the Commission should refrain from mandating granular specifics . . . such as a call back number and a street address as this will not be practicable in all scenarios”).  
 or in identifying specific categories of additional location information beyond floor level or room number. See, e.g., Ad Hoc Comments at 11 (stating that the Commission’s proposed definition of dispatchable location “should not be expanded any further by the Commission”); NCTA Comments at 6 (stating that the Commission should not mandate the use of “some vendor solutions … to provide dynamic dispatchable location information from MLTS” as they “have not been adequately vetted to ensure that they will work effectively in all situations, nor is there any analysis of whether these vendor solutions would be economically viable to deploy”); Ad Hoc Reply at 11 (asserting that the Commission should not impose either “overly detailed requirements or impossible-to-meet timetables with regard to the transmission of dispatchable location”).
  
143. We also conclude that the definition of dispatchable location for MLTS 911 calls should include a requirement that street addresses be validated.  The majority of commenters who addressed this issue indicate that such validation is essential to ensure that a location is sufficiently reliable for dispatch of first responders. See, e.g., APCO Comments at 6; MESB Comments at 6 (“Validation of dispatchable locations from MLTS/PBX and [enterprise communications] systems to authoritative data must be required (i.e., Master Street Address Guide (MSAG) and/or geospatial datasets, such as road centerline and address points, supplied by official local government/public safety authoritative sources).”); Texas 9-1-1 Entities Comments at 10 (indicating that the definition of dispatchable location should require the validation of a street address of the calling party and, to the extent possible, for it to be corroborated against other location information prior to delivery of dispatchable location information to the PSAP); West Safety Comments at 10 (“Validation is the one critical piece missing from the proposed definition of dispatchable location.”).
  Commenters also state that street address validation is feasible and can be implemented by MLTS managers and operators without incurring significant costs. Avaya Comments at 8, n.6 (“Avaya agrees with the Commission that physical street addresses must be validated, and confirms that there is no significant cost to doing so.”); Verizon Comments at 8-9 (stating that validation methods and “an appropriate uncertainty standard” for registered location, developed with public safety input, may provide a PSAP with actionable information that meets the dispatchable location definition, including a detached home address validated by x/y coordinates or another accurate location method).
  NENA states that MLTS managers or operators have “numerous methods” for validating addresses against databases like the Master Street Address Guide or databases that support the Location Validation Function in the NG911 environment. NENA Comments at 6.  
  Finally, including street address validation in our dispatchable location definition for MLTS and other services covered by this order establishes parity with the dispatchable location definition in our wireless E911 rules and renders the two definitions functionally identical.  
144. Cisco and ATIS express concern about the cost and feasibility of validation requirements imposed on large enterprises if validation beyond street address or building level is required. ATIS Comments at 3 (“Deploying equipment to validate and maintain the accuracy of dispatchable locations for MLTS on large commercial campuses would be cost prohibitive to enterprise owner/operators. . . . [and] when other location data is available, integrating this information into existing source(s) to identify the most accurate data will create additional complexities potentially on PSAPs, operators, and/or the enterprise.”); Cisco Reply at 11 (“[T]here is no basis for the Commission to impose [a validation] requirement because: (1) location validation is not currently available on a cost-effective basis on large commercial campuses; and (2) local NG911 systems will need to be established before location validation below the building level can occur on a widespread basis.”).  
  We emphasize that our adopted definition of dispatchable location—as in the case of our wireless rules—only references validation of street address information.  While we encourage the development of solutions that will support validation of more granular location information than street address, including floor and room number, we agree with commenters who caution against imposing overly prescriptive requirements at this time that could inhibit the development of innovative solutions.  
b. MLTS Provision of Dispatchable Location or Alternative Location Information
145. In the Notice, the Commission “tentatively conclude[d] that it is feasible for 911 calls that originate from a MLTS to convey dispatchable location to the appropriate PSAP.” Notice, 33 FCC Rcd at 9004, para. 60. 
  The Commission based this tentative conclusion on the record in the Enterprise Communications NOI proceeding, in which several commenters stated that they already offered methods for dynamically determining and conveying an MLTS end user’s location. Id. 
  The Commission also noted the potential availability of dispatchable location solutions that require the customer to identify their own location and solutions that calculate a location by leveraging data available from the 911 caller’s device and the network. Id.
  The Commission sought comment on this tentative conclusion and on the range of potential approaches to providing dispatchable location. Id. at 9004-05 paras. 60-63.
  The Commission also sought comment on whether a MLTS that handles calls initiated by remote users, e.g., off-site workers, should be required to convey location information about remote users. Id. at 9004, para 61.

146. The Commission noted that there may be instances where location information that does not meet the definition of dispatchable location could still be useful to PSAPs and first responders, either as supplemental information to validate the dispatchable location or as an alternative in instances where dispatchable location information is not available. Id. at 9005, para. 64.
  The Commission stated its belief that “our rules and policies should not preclude—and in fact should allow and encourage—potential alternatives to dispatchable location.” Id.
  The Commission asked whether other types of location information (for example, x/y/z coordinates) could be conveyed with a 911 call originating from an MLTS. Id.
  Finally, the Commission proposed to require implementation of dispatchable location requirements for MLTS systems by February 16, 2020, the same as the implementation date for the requirements of Kari’s Law.
147. Numerous commenters address the issue of MLTS dispatchable location, expressing a variety of viewpoints.  Some commenters agree with the Commission’s tentative conclusion that it is feasible to provide dispatchable location with MLTS 911 calls, and state that they are already capable of providing highly specific real-time location information for MLTS users. Cf.; BluIP Comments at 5 (stating that its cloud-based, hosted “PBX” solution for the hospitality industry “is presently capable of providing the 911 caller’s specific location information, such as room number, tower and floor, to on-site personnel[,] and this information can also be conveyed to PSAP operators, even where the hotel has not replaced its legacy PBX phone system”); RedSky Comments at 20 (stating that RedSky’s and others offer MLTS service that “accepts a 9-1-1 call and correlates the incoming [Direct Inward Dialing number] to a dispatchable location that is passed on to the PSAP”).  See generally Avaya Comments at 2-4 (describing how Avaya can use standard network protocols and discovery techniques in numerous contexts to track the location of any IP telephone device on its network, ingest MLTS database information from TDM devices that cannot be located natively, provide routing guidance and updates to the MLTS once a device has been discovered, and provide an on-site notification to an enterprise).  
  Other commenters, however, contend that while dispatchable location may be feasible for some MLTS 911 calls, it is not feasible in all cases, and that attempting to impose “one-size-fits-all” dispatchable location requirements on all MLTS would be unworkable. See DECT Forum Comments at 3 (“Over the top (‘OTT’) VoIP, Virtual Private Network (‘VPN’), and cloud or hosted technologies may not have technical capabilities analogous to the ‘traditional’ multiline telephone services of the past, rendering a ‘one size fits all’ approach to emergency calling requirements impracticable”); see also Ad Hoc Comments at 4 (“Rather than attempt to prescribe ‘one size fits all,’ top-down mandates for MLTS E911 deployments, the Commission should grant enterprise owner/operators the flexibility to develop individualized solutions that take into account their wide variety of workplace scenarios and network technologies . . ..”). 
  
148. Because the MLTS marketplace serves an enormous range of enterprise environments and includes systems that vary greatly in size, scope, and technological capability, we agree with commenters that our approach must take this variety into account. We agree with Avaya that service providers may use any technology that delivers dispatchable location, including any technology that complies with NENA i3 specifications.  See Letter from Michael P. Donahue, Counsel for Avaya, Inc., to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, at 1 (filed July 22, 2019).
  In this regard, the comments suggest that the feasibility of providing dispatchable location for an MLTS 911 call, and the means available to provide it, vary significantly depending on whether the call is from a fixed or non-fixed device For purposes of this proceeding, we define “fixed” MLTS devices as devices that connect to a single end point (e.g., a desk or office phone) and are not capable of being moved to another endpoint by the end user, although they may be capable of being moved to a different endpoint by a professional installer or network manager.  “Non-fixed” MLTS devices are devices that the end user can move from one endpoint to another without assistance.  
 and, in the case of non-fixed devices, whether the device is being used on or off the enterprise premises.  Cisco points out that “dispatchable location is more supportable from on-premises fixed or ‘hardwired’ MLTS stations (such as desk phones), more challenging for on-premises mobile clients (such as softphones), and even more difficult, if not impossible, for off-premises softphones using public Internet or Virtual Private Network connections.” Cisco Reply Comments at 12. 
  We find this assessment to provide a useful framework for addressing MLTS location issues.  Therefore, in the discussion below, we separately address dispatchable location requirements for MLTS 911 calls from fixed devices, non-fixed devices being used on-premises, and non-fixed devices being used off-premises.   
(i) Fixed MLTS Calls 
149. Commenters generally agree that providing dispatchable location of fixed devices presents the easiest use case for MLTS providers. Cf. Cisco Comments at 17 (stating that generating dispatchable locations for desk phones that typically do not move is “relatively straightforward”); Panasonic Comments at 19-20 (“[T]he Commission should limit any dispatchable location requirement at this time on a baseline rule for hard-wired fixed telephony endpoints assigned to a physical on-premises location.”); RingCentral Comments at 6 (“[T]he Commission should make clear that dispatchable location requirements only apply to on-site MLTS.”).
  Where MLTS calls originate from fixed devices such as hotel phones or fixed desk phones that each connect to a single access point, providing location information for each endpoint is not technically difficult or costly.  In addition, our definition of dispatchable location gives providers substantial flexibility to determine what amount of information is needed to identify the dispatchable location of each fixed endpoint, and for many small businesses, provision of street address alone will be sufficient.  We therefore conclude that providing dispatchable location for 911 calls from fixed MLTS devices used on-premises is readily achievable. We infer that fixed MLTS use occurs solely through connection of fixed devices with on-premises endpoints.  Commenters did not cite any instances of MLTS supporting fixed devices off-premises.  In the unlikely event that an MLTS were to support a fixed off-premises device, however, we see no reason why providing dispatchable location for such a device would be any less feasible than in the case of an on-premises device.    
  We also conclude that dispatchable location from fixed MLTS devices should be provided automatically In other words, the dispatchable location information associated with a fixed MLTS device must be conveyed to the PSAP when a user places a 911 call, without further intervention by the user at the time it places the call.  As noted below, an MLTS operator or manager may rely on an enterprise customer to acquire, maintain, and keep up-to-date the location information associated with a fixed MLTS device.  See infra para. 164; see also Letter from Brian Hurley, Vice President of Regulatory Affairs, ACA Connects, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, at 1-2 (filed July 25, 2019).
 and that the street address associated with the fixed end-point should be validated. Cisco Comments at 17 (stating that generating dispatchable locations for desk phones that typically do not move is “relatively straightforward” and noting that the location of the device can be a “hard configuration” established by the enterprise’s chosen vendor); NASNA Comments at 4 (“Street address validation should not be more difficult or costly for MLTS than for any other fixed telephony service in most instances, although we acknowledge that it may be incrementally costlier in complex MLTS environments.”).

150. This requirement will take effect one year from the effective date of the rules adopted in this order.  Although the Commission proposed in the Notice to implement dispatchable location requirements for MLTS on February 16, 2020, contemporaneous with the compliance date for the requirements of Kari’s Law, Notice, 33 FCC Rcd at 9012, para 87. 
 most industry commenters oppose this proposal, arguing that it would give them only a few months to implement requirements and noting that RAY BAUM’S Act, unlike Kari’s Law, does not specify an implementation date for requirements the Commission may adopt. Cisco May 22 Ex Parte at 2.  See generally TIA Comments at 14 (“Nor does the RAY BAUM’S Act mandate immediate action with regards to dispatchable location contemporaneous to the implementation of Kari’s Law.”).
  We conclude that a one-year timeframe is more reasonable to ensure timely implementation while affording affected parties reasonable time to take the necessary steps to come into compliance.
(ii) Non-Fixed MLTS Calls
151. Commenters express divergent views as to the feasibility of providing dispatchable location for on-premises MLTS 911 calls from non-fixed devices, e.g., softphones or mobile handsets that that are capable of connecting to multiple Wi-Fi access points and can move from one location to another within a building. While such devices are capable of being moved from one access point to another, we note that they may be only be capable of conducting a communications session with one access point at a time, i.e., the system may not support seamless handoff of the device from one access point to another without interrupting the session.  
  Some MLTS service providers (e.g., RedSky, Avaya, BluIP) state that they currently offer enterprise services that use access point location information to dynamically determine and convey an MLTS end user’s precise location within a building. Avaya Comments at 3-4 (Avaya uses “standard network protocols and discovery techniques to track the location of any IP telephone device on the network, ingests MLTS database information from devices that cannot be located natively, provides routing guidance and updates to the MLTS once a device has been discovered, and provides an on-site notification and situational awareness to local onsite staff”); BluIP Comments at 5 (stating that its cloud-based, hosted “PBX” solution for the hospitality industry “is presently capable of providing the 911 caller’s specific location information, such as room number, tower and floor, to on-site personnel[,] and this information can also be conveyed to PSAP operators, even where the hotel has not replaced its legacy PBX phone system”); RedSky Comments at 20 (stating that RedSky and others offer MLTS service that “accepts a 9-1-1 call and correlates the incoming [Direct Inward Dialing number] to a dispatchable location that is passed on to the PSAP”); see also Avaya Letter from Michael P. Donahue, Counsel for Avaya, Inc., to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, at 1 (filed July 22, 2019) (urging the Commission to “ensure that any technology that provides data that is compliant with NENA i3 specifications is an acceptable means for conveying dispatchable location and other location detail as part of a transition to NG 911.”).  
  Such services typically rely on storing location information for each access point in a database (maintained by the enterprise customer or the MLTS provider) that can be referenced when a 911 call is placed from a particular access point. See generally RedSky, Protecting the Mobile Workforce, https://www.redskye911.com/mobility (last visited July 10, 2019) (RedSky’s “WiFi E911 for Mobile Networks” service “[s]tores a location database of all access points.”).
  
152. However, other commenters point out that the effectiveness of enterprise database approaches is dependent on a number of variables and could be prohibitively costly. USTelecom Comments at 1 (“[T]he Commission should allow MLTS customers to decide whether they want to upload dispatchable location data or to pay someone, like an installer or a third-party vendor, to do so.  Mandating that installers upload location data and holding them liable—even in instances when a customer uploads the dispatchable location data—would unnecessarily increase MLTS costs and stifle consumer offerings and innovation in the market.”). 
  Relying on an enterprise database to provide location information requires the enterprise customer to either develop and maintain the database or to pay a third-party vendor to provide database services. Id.
  It also requires procedures and safeguards to ensure that access point location data are entered accurately and kept up-to-date. See, e.g., NENA Comments at 7 ( “[V]endors and manufacturers must bear some responsibility to (1) encourage accurate and regular update of location information, and (2) provide means to alert operators and managers when registered location information has become out-of-date or hardware has been moved.”); ACA Reply at 2 (stating that ACA’s “members collect location information from MLTS customers at the time of installation; ensure the information is reported to the appropriate 911 database; instruct customers how to update their location information; and ensure that any updates are reported promptly”).
  In addition, depending on the density and distribution of in-building access points, access point location information may provide the caller’s approximate location but may not be precise enough to provide dispatchable location, e.g., the caller’s specific room or office number. Panasonic Comments at 24 (“[I]t is costly to map and maintain the location of access points for an enterprise’s individual use (and even when mapped, any location beyond street address may not be accurate when relied on by certain wireless systems).”).
  Commenters anticipate that over time, database location solutions for MLTS will become more widely available and capable of providing more precise location information, but they caution against adopting requirements that assume the near-term availability of database solutions to support dispatchable location across the full array of enterprise environments. The Commission sought comment on whether the National Emergency Address Database (NEAD), the location database being developed by the nationwide wireless carriers to provide dispatchable location for indoor wireless 911 calls, could potentially assist MLTS managers and operators in determining the dispatchable location of MLTS end users.  Notice, 33 FCC Rcd at 9006, para. 65.  Commenters generally express skepticism that the NEAD has any near-term utility for MLTS location.  See, e.g., AT&T Comments at 10 (stating that while the NEAD may be useful for providing dispatchable location for some MLTS devices in the future, it is premature to rely on the NEAD for dispatchable location because the NEAD relies on the capability to detect Wi-Fi and Bluetooth access points, a capability that most of the MLTS end user devices lack); Cisco Reply at 12 (“[T]he record confirms that Wi-Fi access point location offers tremendous promise as a source of dispatchable location information in the future, but … the [NEAD] is not an effective solution at this time.”); Comtech Comments at 5 (“[A]lthough … it may be possible to extend the use of the NEAD to MLTS operators and users, many onerous changes would be required to enable such use of the NEAD, including changes to the NEAD standards, architecture, and infrastructure.”); RedSky Comments at 22 (“In terms of an MLTS operator provisioning location data into the NEAD, there are many challenges to be overcome including credentialing, authorization, address validation, upkeep, the ability to delete a location and cost/benefit.”).
 
153. To address these concerns, we adopt a more flexible approach to providing dispatchable location for MLTS 911 calls from non-fixed devices.  MLTS providers must convey automated dispatchable location for such devices when technically feasible but may rely on the MLTS end user to provide or confirm dispatchable location information manually, e.g., by responding to a system prompt.  Commenters generally agree that enabling such manual confirmation of location information by MLTS end users is both feasible and potentially beneficial. See, e.g., AT&T Comments at 9 (stating that the most reliable way to locate end-users is by their confirmation of their dispatchable locations when using the device and the Commission should, therefore, not require the use of automatic location solutions for end-user devices); West Safety Comments at 14 (suggesting that a “nomadic VoIP provider could use an internal or vendor solution to detect when a location may have changed and either pre-populate the location based on network history or prompt the end user to do so manually”).  
  
154. We recognize that relying solely on end users to provide manual location updates can lead to user fatigue, See, e.g., Cisco Comments at 18 (stating that there is a trade-off between location prompting and end-user fatigue); Panasonic Comments at 21 (asserting that “requiring a manual location entry every time the device is used will likely result in pop-up overload, the effect of which will be users ignoring location update prompts”); TIA Comments at 18 (stating that the more granular the information required in manual updates, the more difficult it will be to obtain accurate information from users); VON Comments at 5 (suggesting that users do not always update their information even when prompted to do so, particularly if they are using a device that regularly moves with them).
 and that manually provided information may not be accurate or up-to-date. See, e.g., Bandwidth Comments at 4 (stating that 911 rules that only envision manual location updates to address information when users change location are inadequate for an increasingly mobile environment); MESB Comments at 6 (stating that because users do not maintain their 911 location after the initial implementation, automatic detection and supply of user locations should be required).  
  As an additional fallback, commenters strongly agree with the Commission’s statement in the Notice that our rules and policies should “allow and encourage” alternatives to dispatchable location. Notice, 33 FCC Rcd at 9005, para. 64.
  Microsoft states that commercially available location services already in use around the globe can be leveraged “relatively quickly and effectively” to enhance the 911 capabilities of IP-based and cloud-MLTS and interconnected VoIP services in ways “far more accurate and reliable than a ‘registered location’ manually entered by the end-user.” Microsoft Comments at i-ii.
  According to Microsoft, location technologies that could be leveraged include GPS/GNSS location, device-based sensing of Wi-Fi hotspots, and use of commercially available crowd-sourced location data. Id. at 11-12.  
  Comtech states that newer MLTS hardware can incorporate GNSS signals, which could be used to automatically corroborate any human-provisioned dispatchable location information. ComTech Reply at 3.
  INCOMPAS contends that “relying on a ‘superset of location information’ such as a wireless carrier’s cell site, GPS, the Wi-Fi hotspots, and commercial location information gives regulated voice providers several opportunities to provide accurate dispatchable location data rather than relying on a static address.” INCOMPAS Reply at 9-10 (citing Bandwidth Comments at 5).   
  
155. We agree with these commenters that our rules should harness the potential for commercially available device-based technologies and coordinate-based location methods to support the provision of MLTS 911 location information.  Therefore, as proposed in the Notice, we afford MLTS providers flexibility to provide alternative location information, including coordinate-based information, when providing dispatchable location is not feasible or cost-effective. APCO cautions that providers should not be allowed to “self-declare” that dispatchable location is not technically feasible or cost-effective.  Letter from Jeffrey S. Cohen, Chief Counsel, Mark Reddish, Senior Counsel, APCO, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 07-114, 18-261, 17-239, 11-60, ET Docket No. 18-295, GN Docket Nos. 17-183, 11-117, at 2 (filed July 26, 2019) (APCO July 26 Ex Parte) at 2.  We agree.  If we receive a complaint or petition that a provider is not providing dispatchable location and the provider asserts that doing so is not technically feasible or cost-effective, the provider must show that its assertion has an objective and reasonable basis in light of the state of technology at the time the assertion is made.
  We also adopt a technology-neutral approach, as uniformly advocated by commenters, so that providers have the widest latitude to choose among available solutions. ATIS Comments at 3 (“ATIS . . . supports the Commission’s proposal to allow the industry to use alternatives to dispatchable location, noting that such flexibility facilitates innovation and interoperability.”).
   
156. We recognize that where alternative location information is provided with an MLTS 911 call, the rules we adopt today allow the location fix to be less precise than a dispatchable location that pinpoints the caller’s location down to the room, office, or apartment level.  While we agree with APCO that a more precise location is the preferred outcome, APCO Comments at 5 (stating that “dispatchable location is much preferred over x/y/z coordinates”).  
 we find that the record strongly supports allowing the provision of less precise—but still actionable—alternative location information as a fallback when providing more precise information is not technically feasible. ATIS Comments at 3 (asserting that “x/y/z coordinates may be beneficial as a supplement or alternative to dispatchable location in certain contexts”); Bandwidth Comments at 6 (“Because an IP end-point can be a soft agent that resides on a mobile device, like a smart-phone, a laptop or tablet (which could be completely outside the expected building environment), more accurate and dynamic end-user location information could be presented in the form of latitude-longitude information or ‘X/Y coordinates’ instead of, or in addition to, a civic address and floor number.”); RedSky Comments at 21 (“[T]here are many examples where latitude and longitude are not only useful, but the only location information available.”); Texas 9-1-1 Entities Comments at 10 (stating that to the extent technically feasible, dispatchable location should be the general approach used indoors, but without restricting the use of x, y coordinates (and z-axis, as applicable) when such coordinates provide more accurate caller location information or when using dispatchable location is not possible); Comtech Reply at 2 (“[I]n situations where a dispatchable location cannot provide sufficiently granular information, it may be necessary to utilize sources of location information (such as x/y/z coordinates) that are not tied to a named place, address, building, or structure.”); INCOMPAS Reply at 8 (stating that voice providers and technology companies should be allowed to use the best available location sources when providing life-saving information to PSAPs and emergency officials). 
  Identifying a caller’s street address and floor level is likely to reduce response time, even if it does not identify “the door to kick down.” APCO Comments at 6 (“If the Commission permits x/y/z coordinates as a backstop to dispatchable location for MLTS or other technological platforms, the information must be actionable, with the vertical component delivered as a specific floor number.”).
  Commenters also confirm that this level of accuracy is significantly easier and less costly to achieve than more precise location information in many instances.  Cisco states that “MLTS today typically provides the building’s street address, and . . .systems increasingly provide floor level.” Cisco May 22 Ex Parte at 2. 
  In addition, while identifying a caller’s room or apartment may be significantly more costly, as Cisco asserts, it is not difficult for an MLTS serving large buildings to identify the building wing or quadrant where the call originates. Id.  See, e.g., Avaya Comments at 2-3.  
  Therefore, we define “alternative location information” as location information (which may be coordinate-based) sufficient to identify the caller’s civic address and approximate in-building location.  In large multi-story buildings, this should normally include floor level and approximate location on the floor (e.g., building quadrant).  We note that this approach is similar to the approach the Commission took in its wireless E911 rules, which allow wireless carriers to provide either dispatchable location or x/y/z coordinate-based location information for indoor wireless 911 calls.
157. These requirements will take effect two years from the effective date of rules adopted in this order.  Although the Commission proposed to make dispatchable location requirements effective on February 16, 2020, we agree with commenters that a longer transition period is needed for MLTS providers to implement “granular” location requirements, particularly for non-fixed services. Verizon Comments at 9-10; see also TIA Comments at i (suggesting that the Commission should allow public safety representatives, the information and communications technology industry, and building owners/managers to continue working on establishing standards and best practices for how MLTS can deliver location information in an effective and accurate manner); VON Comments at 8.  
  Cisco states that for “on-premises MLTS stations,” the Commission should consider a phased approach whereby the Commission would require MLTS managers to provide the street address of the caller’s location while having the flexibility to provide additional information that they determine is sufficient for the enterprise “following a minimum transition period of two years.” Cisco Comments at i, 4; see also id. at 22-23.  
  Panasonic states that the Commission “should extend the compliance date for 3-5 years if [validation] capability is deemed necessary for all MLTS systems.” Panasonic Comments at 25.  
  RingCentral states that the Commission should allow at least 18 to 24 months to develop solutions to meet the complex challenges posed by any new location requirements. RingCentral Comments at 12.  
  VON states that the compliance date for nomadic VoIP providers should be at least 24 months after the effective date of our implementing order. VON Comments at 8.
  
158. We conclude that a two-year transition period is appropriate for implementation of these requirements.  It is consistent with implementation timeframes recommended by many commenters. See supra para. 157.
  We also agree with Microsoft, Cisco, and other commenters that within the next two years, MLTS will likely be able to leverage improvements in technology that can refine the location process, including improvements to location databases and commercially available device-based technologies that can provide a “superset” of location information on a standalone basis or in combination with network-based tools. Microsoft Comments at 10; Cisco Comments at 1; RingCentral Comments at 12; VON Comments at 8.
  Finally, we note that the two-year deadline adopted in this order will likely fall in late 2021, which will roughly coincide with implementation of milestones intended to improve in-building location of wireless 911 calls under the Commission’s wireless location accuracy rules. Under our wireless E911 location rules, wireless carriers must provide dispatchable location or meet horizontal accuracy standards for 80% of wireless 911 calls by April 2021.  47 CFR § 20.18(i)(2)(i)(A).  In addition, wireless carriers must meet vertical accuracy standards in the top 25 Cellular Market Areas (CMAs) by April 2021.  Id. § 20.18(i)(2)(ii)(C).
  This provides an opportunity for MLTS, as well as other services covered by this order, to explore opportunities with wireless carriers for developing common location solutions that can support in-building location regardless of the platform used to make the 911 call.     
159. In contrast, we conclude that MLTS providers should not be subject to the same location requirements for off-premises MLTS calls to the extent compliance is not technically feasible.  When an MLTS end user is off-premises, the MLTS does not typically control or have access to location information.  Remote access instead may involve connecting via a third-party access point that is outside the control of the enterprise or the MLTS operator, and for which location information may not be available.  We agree with commenters that this lack of access or control makes it considerably more challenging and costly for an MLTS to provide location information for off-premises users than on-premises users.  TIA states that for an end-user connected remotely to an enterprise via a VPN, “ensuring accurate location data is difficult, if not impossible” because a VPN user’s location is reported as an IP address of the enterprise at end of the IP tunnel. TIA Comments at 18-19.  
  Panasonic states that where an employee uses an IP-capable client off-premises, “there is no way to locate such callers today without requiring the purchase of expensive third-party services that require manual location entry.” Panasonic Comments at 21-22.  
  RingCentral states that “when a user goes off-site and leaves the enterprise network, it may not be possible to locate that user or even detect that the user has moved.” RingCentral Comments at 5.  

160. In light of these factors, we conclude it is premature to prescribe specific standards for location of off-premises MLTS calls when compliance with our on-site requirements would not be technically feasible, and we therefore adopt a flexible approach that avoids imposing impossible requirements.  For off-premises 911 calls, the MLTS operator or manager must provide (1) dispatchable location, if technically feasible, or, otherwise, either 2) manually-updated dispatchable location, or (3) enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost.  This requirement will take effect two years from the effective date of rules adopted by this order.  The flexibility inherent in this requirement should lessen the burden and the amount of time it will take to comply.  We recognize that as a practical matter, MLTS providers are unlikely to be capable of providing dispatchable location for most off-premises calls, and that “best-available” location information may be limited in the near term.  Nevertheless, over time this requirement will encourage development of improved location capabilities for off-premises MLTS 911 calls.  
c. Roles and Responsibilities of MLTS Participants 
161. The Commission proposed to apply MLTS dispatchable location requirements to “the participants in the MLTS marketplace we believe are best positioned to ensure that all installed MLTS are capable of conveying an accurate location to the appropriate PSAP.” Notice, 33 FCC Rcd at 9002, para. 55.
  As in the case of Kari’s Law, the Commission proposed distinct requirements for MLTS manufacturers, importers, sellers, and lessors, on the one hand, and MLTS installers, operators, and managers on the other:  the former group would be required to ensure that MLTS systems are “pre-configured” to convey dispatchable location with 911 calls, Id. para. 54; see also id. at 9050, Appendix A, proposed rule § 9.16(a)(2). 
 while the latter group would be required to ensure that MLTS systems are “configured” to convey dispatchable location with 911 calls. Id. at 9050, Appendix A, proposed rule § 9.16(b)(3).
  The Commission sought comment on whether more granular requirements should be placed on any of the MLTS market participants to which the proposed rules would apply and whether rules are needed to ensure that MLTS manufacturers and importers incorporate capabilities in their products to enable them to convey dispatchable location information. Notice, 33 FCC Rcd at 9002, para. 55.
  
162. Commenters are generally supportive of the Commission clarifying the roles and responsibilities of MLTS market participants with respect to providing location information with 911 calls. TIA and DECT Forum urge the Commission to “clearly identify[] the roles and responsibilities of MLTS stakeholders for each requirement that the Commission imposes, including what compliance will be required from manufacturers versus building owners and managers and how compliance will be evaluated.”  TIA and DECT Forum Reply at 4-5  (citing Ad Hoc Comments at 7; VON Comments at 12-13 [sic, at 10-11]).  
  Commenters also agree with the Commission’s proposal that responsibility for dispatchable location be apportioned in the same manner as responsibility for the direct dialing and notification requirements of Kari’s Law. AHLA Comments at 11 (stating that the Commission “should adopt its conclusion . . . that dispatchable location rules apply ‘to the participants in the MLTS marketplace [who] are best positioned to ensure that all installed MLTS are capable of conveying an accurate location to the appropriate PSAP,’ i.e., to the same market participants responsible for compliance under Kari’s Law” (citing Notice at 9002, para. 55)).
  Therefore, as proposed in the Notice, we impose pre-configuration requirements on MLTS manufacturers, importers, sellers and lessors, and configuration requirements on MLTS installers, operators, and managers.  In light of our adoption of flexible location requirements, these pre-configuration and configuration requirements now reference the conveyance of dispatchable location and alternative location information.   
163. Some commenters propose additional clarification of the respective roles and responsibilities of MLTS installers, operators, and managers in ensuring that accurate location information is provided with MLTS 911 calls.  NTCA states that a service provider should be required “to configure proper location information upon installation and initiation of service only to the extent they are involved in configuration of handsets and systems in the first instance.” NTCA Comments at 3.  
  RedSky states that “the level closest to the end user has the most accurate device . . . location data and should be held responsible for the provisioning of data.” RedSky Comments at 21.
  Several commenters also note that MLTS operators and managers will need the assistance of enterprise customers to acquire, maintain, and update location information. AT&T Comments at 8; NTCA Comments at 2 (“[T]he accuracy of ‘dispatchable location information’ . . . often depends on a MLTS end-user customer continually and proactively updating the data at issue, such as the location of handsets and/or individual users within buildings or multiple buildings,” while “[b]y contrast, service providers—after initial installation or configuration of MLTS—lack visibility into any individual user’s location to accurately, and on a timely basis, update handset location or other relevant data.”); Comcast Reply at 6-7.
  Accordingly, Comcast contends, MLTS operators and managers should not be held responsible when a customer moves MLTS stations to new locations without their knowledge. Comcast Reply at 6-7.
   
164. We agree with commenters that additional clarification of the role of MLTS installers, operators, and managers is warranted.  We therefore adopt a proposal submitted by USTelecom to add specific rules that delineate the respective responsibilities of MLTS installers, managers, and operators relative to the provision of location information. USTelecom Comments at 3; see also INCOMPAS Reply at 4-5 (endorsing USTelecom’s proposal). 
  We also clarify that in developing and implementing location solutions, MLTS managers and operators are entitled to rely on enterprise customers to acquire, maintain, and update location information.
d. Location Requirements for Small Businesses
165. The Commission sought comment on whether certain small business categories (e.g., of a specific size, or with a specific number of consumers) should be exempted from MLTS dispatchable location requirements. Notice, 33 FCC Rcd at 9012, para. 85.
  Commenters offered varying proposals for small businesses exemptions ranging from criteria based on square footage of enterprise; AT&T notes that some states have adopted size-based cutoffs for small businesses in their MLTS 911 requirements, and recommends that the Commission follow the approach of Maine and Illinois, which “require a single dispatchable location—i.e., a street address—for individual buildings with a workspace of less than 40,000 square feet.”  AT&T Comments at 5.  But see RedSky Comments at 18 (stating that rather than relying on square footage in a rule, “language can state the dispatchable address must ensure the ability to locate the 911 caller in an efficient manner[,]” which would “allow[] both the MLTS user and the [a]uthority [h]aving [j]urisdiction to cooperate applying a common sense approach”). 
 to allowing states and local jurisdictions to grant waivers; BRETSA states that “State and local authority to grant waivers and exceptions to the Rules, subject to appropriate conditions, is the most pragmatic way of addressing the myriad situations in which strict application of the Rules would be contrary to the public safety and public interest.”  BRETSA Comments at 5.  
 to applying requirements based on a minimum number of lines. Letter from Brita Sandberg, Counsel to RingCentral, Inc., to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, at 2 (filed Dec. 7, 2018) (stating that notice and dispatchable location requirements should only apply to MLTS sites with more than 50 lines where the MLTS owner controls the network). 
 
166. The rules we adopt today obviate the need for small business exemptions or waivers of MLTS location requirements based on square footage or number of lines.  The rules afford all MLTS a broad menu of options for providing location information, and the requirements are also scalable to the needs of small businesses:  in most instances, provision of street address information alone will be sufficient to identify the dispatchable location of MLTS 911 calls originating from small businesses.  We believe this approach minimizes burdens and unnecessary complexity for small businesses while also preserving flexibility to advance the 911 location accuracy objectives of RAY BAUM’S Act.    
e. Legacy MLTS 
167. In the Notice, the Commission proposed to apply location requirements to the same entities subject to the direct dialing and notification requirements of Kari’s Law, which would exclude legacy MLTS. Notice, 33 FCC Rcd at 9005, para. 62.
  APCO argues that even though legacy MLTS is not subject to Kari’s Law, legacy systems should be subject to location requirements because RAY BAUM’S Act does not prohibit applying such requirements to legacy systems, and some MLTS is capable of delivering dispatchable location today. APCO July 26 Ex Parte at 1-2.  See also BluIP Comments at 6-7 (stating that the Commission should “consider requiring enterprises, or at least enterprises above a certain size, to modify their existing systems to come into compliance on or after February 2020 unless doing so would be overly burdensome.”); BRETSA Reply at 13 (stating that the relevant portions of the proposed rules should apply to all MLTS currently in service as of the date of the Commission’s Order adopting the rules and subsequently installed); RedSky Comments at 29 (stating that there are dispatchable location solutions that can be widely and inexpensively implemented into MLTS being manufactured today).
  Other parties support the Notice proposal, arguing that requiring legacy MLTS to retrofit their systems to support dispatchable location would be disruptive and costly. AT&T Comments at 3 (“[T]he Commission should grandfather MLTS equipment installed before February 16, 2020 for RAY BAUM’S ACT as it did for Kari’s Law”);  Panasonic Comments at 22 (stating that “any dispatchable location requirements should only apply to systems manufactured after the compliance date”); West Safety Comments at 8 (“grandfathering relief alleviates the burden on enterprises from having to replace or upgrade legacy TDM MLTS systems”).
  On balance, we adopt the Notice proposal.  We decline to adopt APCO’s request because doing so would require costly retrofitting of legacy MLTS – costs that would be more burdensome than for mass market services because legacy MLTS are specially configured for the particular enterprises they serve.  In addition,  applying Kari’s Law and RAY BAUM’S Act to different classes of MLTS would create confusion and technical inconsistency, whereas applying the two statutes uniformly In this regard, we observe that both Kari’s Law and the RAY BAUM’S Act were adopted within months of each other and uniformly apply to MLTS as defined in 47 U.S.C. § 1471.  See RAY BAUM’S Act § 506(a); 47 U.S.C. § 623(f).  We do not interpret Congress to have applied such disparate regulatory regimes to MLTS, and the record about compliance costs adds support for such an interpretation.
 will encourage integrated 911 solutions for MLTS. In this respect, we find that requiring retrofitting existing systems solely to address dispatchable location may result in a failure to promote more integrated technological solutions that could address both the direct dialing and notification provisions of Kari’s Law and the dispatchable locations provisions of RAY BAUM’S Act on a holistic basis.  
  We also disagree with APCO’s suggestion that applying new location obligations to the existing MLTS ecosystem would be comparable to the Commission’s approach to phased-in location accuracy for wireless services. APCO July 26 Ex Parte at 1-2.
  In the wireless context, the increasingly precise location obligations adopted by the Commission were imposed on an industry already subject to extensive 911 obligations.  In contrast, before Kari’s Law and RAY BAUM’S Act were enacted, MLTS was not subject to any 911 obligations at the federal level.  Adopting complex obligations from scratch for a legacy industry is vastly more complex and costly than an incremental change to an already-regulated service.  We also believe our decision is consistent with Congressional intent to address MLTS 911 on a prospective basis and not to require retrofitting of existing MLTS.  
f. Liability Protection
168. Microsoft requests that the Commission clarify that MLTS providers are entitled to the same liability protections afforded wireless carriers, iVoIP services and text-to-911 services. Microsoft June 26 Ex Parte at 3 (urging the Commission to “clarify that 47 U.S.C. 615a’s ‘other emergency communications provider’ includes MLTS Manufacturers, Importers, Sellers, Lessors, Installers, Operators and Managers.”).
  Microsoft observes that Congress has granted immunity from liability to certain emergency communications providers as follows: 
A wireless carrier, IP-enabled voice service provider, or other emergency communications provider, and their officers, directors, employees, vendors, and agents, shall have immunity or other protection from liability in a State of a scope and extent that is not less than the scope and extent of immunity or other protection from liability that any local exchange company, and its officers, directors, employees, vendors, or agents, have under Federal and State law (whether through statute, judicial decision, tariffs filed by such local exchange company, or otherwise) applicable in such State, including in connection with an act or omission involving the release to a PSAP, emergency medical service provider or emergency dispatch provider, public safety, fire service or law enforcement official, or hospital emergency or trauma care facility of subscriber information related to emergency calls, emergency services, or other emergency communications services. Id. Wireless Communications Act, Pub. L. No. 106-81, 113 Stat. 1286 at § 4 (codified at 47 U.S.C. § 615a); NET 911 Improvement Act of 2008, Pub. L. 110–283, 122 Stat 2620 at § 201(a) (amending 47 U.S.C. § 615a).  In 2012, Congress also extended the liability protection under 47 U.S.C. § 615a to wireless carriers, public safety answering points, and users of wireless 9-1-1 service with respect to the release of subscriber information related to emergency calls or emergency services, the use or provision of 9-1-1, E9-1-1, or NG9-1-1 services, and other matters related to 9-1-1, E9-1-1, or NG9-1-1 services.  See Next Generation 9-1-1 Advancement Act of 2012, Pub. L. No. 112-96, 126 Stat. 156 at § 6506 (codified at 47 U.S.C. § 1472).

169. We find that this statutory liability shield extends to MLTS manufacturers, importers, sellers, lessors, installers, operators and managers.  The statutory text applies its liability protections to “other emergency communications service providers,” which is defined to include “an entity other than a local exchange carrier, wireless carrier, or an IP-enabled voice service provider that is required by the Federal Communications Commission consistent with the Commission’s authority under the Communications Act of 1934 [47 U.S.C. 151 et seq.] to provide other emergency communications services.” 47 U.S.C. § 615b(9)(A).
  In this Report and Order, we find that MLTS manufacturers, importers, sellers, lessors, installers, operators and managers are subject to our jurisdiction and, consistent with the requirements of Kari’s Law and RAY BAUM’S Act, we require them to configure MLTS systems to ensure delivery of 911 emergency information to PSAPs.  Thus, we agree with Microsoft that MLTS plays a “significant role . . . in the provision of 911 services in the United States,” and that “MLTS apps will be engaged in the transmission of 911 information to PSAPs.” Microsoft June 26 Ex Parte at 3.
  Accordingly, we find that because these entities are required to provide “emergency communications service,” 47 U.S.C. § 615b(8).
 MLTS manufacturers, importers, sellers, lessors, installers, operators and managers fall within the statutory definition of “other emergency communications provider.” Id. § 615a; see also Facilitating the Deployment of Text-to-911 and Other Next Generation 911 Applications; Framework for Next Generation 911 Deployment, PS Docket Nos. 11-153 and 10-255, Second Report and Order and Third Further Notice of Proposed Rulemaking, 29 FCC Rcd. 9846, 9876, para. 65 (2014) (Text-to-911 Order) (finding that covered text providers subject to our text-to-911 requirements fall within the scope of “other emergency communications service providers”).

2. Fixed Telephony
170. In the Notice, the Commission proposed to require fixed telephony providers to furnish dispatchable location with 911 calls. Notice, 33 FCC Rcd at 9006-07, para. 67.
  The Commission noted that these providers already provide validated street address information with 911 calls, which should meet the dispatchable location requirement for single-family dwellings, and asked about the feasibility of also providing floor level and room number for calls from multi-story buildings. Id.

171. No commenter disagrees with our conclusion that by providing validated street address information with 911 calls, fixed telephony providers are already providing dispatchable location for single-family dwellings. RedSky notes that fixed telephone providers typically have no control over inside wiring in single family homes, and therefore are unlikely to be able to identify floor level for a fixed telephone call originating from a single family home that is more than one story.  RedSky Comments at 23.  However, we see no practical benefit to requiring floor level identification as a component of dispatchable location for calls from single family dwellings, nor has any public safety commenter suggested this is necessary.     
  With respect to fixed telephony calls from multi-story buildings, the limited comments we received on the issue support our view that fixed telephony providers are either already providing floor and room information or can readily do so at minimal cost.  Panasonic states that “it is feasible for 911 calls from an endpoint assigned a [Direct Inward Dialing] number to convey a dispatchable location; each [Direct Inward Dialing] number can be assigned with a dispatchable location in the telephony carrier’s database. Panasonic Comments at 23.
  West Safety states that it is “not aware of any technical limitations to fixed telephony providers conveying dispatchable location with a 9-1-1 call.” West Safety Comments at 11; see also TIA Comments at 17-18 (stating that traditional fixed-location devices can be programmed to associate an address with the device).
  As a practical matter, for apartment building residents that are fixed telephony customers, dispatchable location can be readily provided because the apartment number (which often identifies floor level as well) is part of the customer’s billing address.  To the extent that fixed telephony providers need to provide more than street address and are not already doing so, the means to add this capability are readily available. See Cisco Comments at 17 (suggesting that the location of a fixed-location phone can be established by the telecommunications service provider via a private switch automatic location identification (PS ALI) or managed by a third-party provider that provides a dynamic ALI capability). 
  
172. Based on these findings, we adopt our proposal requiring fixed telephony providers to deliver automated dispatchable location with 911 calls.  This requirement will take effect one year from the effective date of the rules adopted in this order.  Although the Commission proposed to implement this requirement on February 16, 2020, we conclude that a one-year timeframe is more reasonable to ensure timely implementation while affording affected parties a reasonable amount of time to take the necessary steps to come into compliance.  
173. In an ex parte filing, IT&E requests that we exempt fixed telephone providers in U.S. territories from dispatchable location requirements, noting that one of the territories it serves has no street address database available IT&E Ex Parte at 1-2 (stating that on certain islands in the Commonwealth of Northern Mariana Islands street names are not used and there is no street address database).
 and that territorial PSAPs do not have the capability to receive automated location information. Id.  (stating that PSAPs in Guam and the Northern Mariana Islands cannot receive automatic location information). 
  To the extent that fixed telephony providers face limitations in providing automated dispatchable location due to factors beyond the provider’s control, such providers may request relief under the Commission’s waiver process. See 47 CFR § 1.925.

3. Interconnected VoIP
174. In the Notice, the Commission proposed to revise the E911 rules for interconnected VoIP to require the provision of dispatchable location for 911 calls. Notice, 33 FCC Rcd at 9008, para. 73.
  The Commission stated that with respect to fixed VoIP, it regards the current Registered Location Under the existing VoIP E911 rules, Registered Location is “[t]he most recent information obtained by an interconnected VoIP service provider that identifies the physical location of an end user.”  47 CFR § 9.3.  
 approach as sufficient to support dispatchable location. Notice, 33 FCC Rcd at 9008-09, para. 74.  
  With respect to nomadic VoIP, the Commission sought comment on the feasibility of providing automatic real-time dispatchable location but also proposed to allow VoIP providers to fall back to using Registered Location and manual updates if providing automated dispatchable location is not feasible or cost-effective. Id. at 9009-10, para. 75-78.
  As discussed below, we adopt dispatchable location requirements that distinguish between fixed and non-fixed interconnected VoIP services. Fixed VoIP services are services that provide the functional equivalent of fixed telephony by means of a device that connects to a single access point and is not capable of being moved by the end user.  Non-fixed VoIP services are VoIP services that enable the end user to connect a handset or other IP-enabled device to multiple access points.  Such services are variously described as “nomadic” or “mobile” VoIP, depending on the degree of functional mobility that the service allows the end user.  We use the term “non-fixed VoIP” to refer to the full range of such services, except where referring to comments that specifically discuss nomadic or mobile VoIP.  We also note that the term “non-fixed VoIP” does not extend or apply to Commercial Mobile Radio Services that are subject to our wireless E911 rules.  
  Also, we extend this requirement to “outbound only” interconnected VoIP providers as well as two-way interconnected VoIP providers covered by the current VoIP E911 rules. See infra Section c.

a. Fixed VoIP
175. With regard to fixed interconnected VoIP, commenters generally agree with the Commission’s tentative conclusion that Registered Location is already providing dispatchable location for single-family dwellings, and that using Registered Location to provide additional information for fixed VoIP serving multi-story dwellings is readily achievable in the near term. See, e.g., Comtech Comments at 9 (Comtech “agrees with the FCC that a Registered Location, in most cases, provides sufficient dispatchable location information for fixed interconnected VoIP users”); RedSky Comments at 23 (concurring with the Commission’s proposal to require fixed VoIP to provide dispatchable location consisting of Registered Location information including room or floor level information when needed).  
  For example, VON states that it “generally agrees with the Commission’s tentative assessment that current Registered Location obligations are sufficient to meet the definition of dispatchable location, and that such location information is already being conveyed.” VON Comments at 4 (citing Notice, 33 FCC Rcd at 9008-09, para. 74).  
  VON further suggests that fixed VoIP providers have incentives to provide additional location information, noting that “customers now demand the ability to provide additional location information, including room and floor information where applicable, and VON members respond to these customer requirements.” Id. at 4-5.  
  
176. We adopt our proposal to require that fixed VoIP services providers transmit dispatchable location with each 911 call.  While dispatchable location may be determined by means of a customer-generated Registered Location in the fixed VoIP context (to the extent a physical location conveys a street address that is validated), it must be provided automatically to the PSAP by the VoIP service provider, without additional action by the caller, at the time the 911 call is made. See infra Appendix A, final rule § 9.11(b)(4)(i).
  As in the case of our requirements for fixed MLTS and fixed telephony, and for the same reasons, See supra paras. 150, 172.
 this requirement will take effect one year from the effective date of the rules adopted in this order. INCOMPAS requests that the Commission “extend the compliance deadline for fixed services and give all providers two years to comply with these new obligations.”  Letter from Christopher L. Shipley, Attorney & Policy Advisor, INCOMPAS, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, GN Docket No. 11-117, at 2 (filed July 26, 2019) (INCOMPAS Ex Parte).  However, the record confirms that providing dispatchable location within a year is technically feasible for fixed services.  See RedSky Comments at 29 (“[B]ased on the current capabilities within fixed telephony, interconnected VoIP, and call initiation into a TRS, that there is no reason to delay the implementation of the final rule requiring compliance in February, 2020.”).  Cf. VON Comments at 4 (stating that “fixed VoIP providers generally make available dispatchable location information”).  
  
177. VON, however, also argues that the existing Registered Location rules are sufficient to ensure the provision of dispatchable location, and therefore no additional requirements for fixed VoIP providers are necessary. VON Comments at 4-5.  
  We reject VON’s argument that there is no need to apply the new dispatchable location rules to fixed VoIP providers.  Although the rules preserve the existing option of relying on Registered Location to provide the caller’s location, they also establish a new requirement for providing dispatchable location automatically.  Our inclusion of fixed VoIP in the new rules furthers the RAY BAUM’S Act objective of ensuring that dispatchable location is provided for all 911 calls regardless of the technological platform used. 
b. Non-Fixed VoIP
178. The Commission sought comment in the Notice on the feasibility of nomadic VoIP services providing automatic real-time dispatchable location, noting that “automatic provision of location is preferable because end users under stress in emergency situations may have difficulty providing manual updates and the updating process may delay the 911 call or subsequent location and dispatch.” Notice, 33 FCC Rcd at 9009, para. 76.
  The Commission sought comment on the capability of interconnected VoIP providers to dynamically determine the location of end users (1) when they are at home or their usual place of work, (2) when they move frequently between multiple locations, and (3) when they are at locations they do not regularly visit. Id.
  The Commission also proposed to allow VoIP providers to fall back to using Registered Location if providing automated dispatchable location is not feasible or cost-effective. Id. at 9009-10, para. 77.
  As a safeguard against sending incorrect location information, the Commission proposed that the VoIP provider “identify whether the service is being used from a different location than the Registered Location, and if so, either: (1) prompt the customer to provide a new Registered Location; or (2) update the Registered Location without requiring additional action by the customer.” Id. at 9045, Appendix A (Proposed Rules), § 9.11(b)(4)(ii).

179. As with non-fixed MLTS, we find that in the non-fixed VoIP environment, flexible rules and a longer time frame for providing accurate 911 location information are appropriate.  In this respect, commenters generally agree on the desirability of automated validation of dispatchable location in the nomadic VoIP environment, but stress that there are challenges to providing such validation in many cases. See, e.g., TIA and DECT Forum Reply at 9 (arguing that “the difficulty of identifying a dispatchable location increases when dealing with nomadic, wireless solutions as opposed to traditional circuit-based fixed-location equipment.”).  
  RingCentral states that interconnected VoIP users “increasingly use browser-based applications for calling, but browser-based applications—by design—do not have the capability of detecting a user’s location unless that user opts-in to location detection.” See Letter from Brita Strandberg, Counsel to RingCentral, Inc., to Marlene H. Dortch, Secretary, FCC, PS Docket No. 18-261 at 2 (filed Dec. 20, 2018).
  RingCentral states that similar challenges exist for users logging in with VPN, “as it may not be possible to detect . . . the user’s true location.” Id.
  Other commenters agree that the technology that would allow for automatic real-time dispatchable location for non-fixed VoIP users needs additional time to fully develop, and therefore agree with the Commission’s proposal to allow providers to fall back to Registered Location options when dispatchable location is not feasible. See Comtech Comments at 10-11 (also urging the Commission to encourage the development of standards); NCTA Comments at 7-8; RedSky Comments at 23-25; RingCentral Comments at 10-11; VON Comments at 6-8; VON Comments at 6-8; West Safety Comments at 13-14; Sorenson and CaptionCall Reply at 3-4. In an ex parte filing, Apple requests that the Commission modify the language relating to updating of Registered Location to clarify that the VoIP service provider’s obligation to identify whether the service is being used from a different location than the Registered Location only applies when the user is making a 911 call.  Letter from Paul Margie, Harris Wiltshire and Grannis, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, GN Docket No. 11-117 (filed July 26, 2019).  We agree with this clarification and amend our rules accordingly. See infra Appendix A, final rule § 9.11(b)(4)(ii)(B)(3).  
 
180. The record further indicates that non-fixed VoIP providers continue to rely heavily on Registered Location, but that alternative approaches are increasingly available that could support automatic location in some instances.  For example, NENA states that the emergence of software-based VoIP applications on mobile phones has made automatic location updates more technically and economically feasible. NENA Comments at 8.
  RedSky states that “the technology exists” to provide dispatchable location for nomadic users through device-based location methods. RedSky Reply at 9 (“In devices that support GPS, the location is based on existing technologies that allow the end user to add floor, room, or area to a civic address as envisioned in the Ray Baum Act.  For those devices that that do not have access to GPS, there are existing Internet based technologies to determine the location of the device i.e. Google Maps.”).  
  Microsoft states that commercially available location services can improve interconnected VoIP location in ways “far more accurate and reliable than a ‘registered location’ manually entered by the end-user[.]” Microsoft Comments at i-ii.
  The ability of non-fixed VoIP providers to provide automated real-time dispatchable location is highly dependent on whether granular location information is available for the access point from which the 911 call is placed, and whether the VoIP provider has access to that information.  In some environments, particularly when end users are away from their home or regular workplace, this information is either unavailable or the development of information sources that could be leveraged by VoIP providers to provide dispatchable location (e.g., databases with access point location information) is in early stages.  Therefore, we adopt rules that require automatic provision of dispatchable location when technically feasible, but also allow non-fixed VoIP providers to fall back on manual updating of Registered Location information by end users as a backstop approach. We note that AT&T points out that automatic location solutions could raise network security concerns because some proposed solutions, which would have limited applicability, would involve scanning of the Data Link Layer (Layer 2) of IP networks, which would violate cybersecurity protocols and expose cyber vulnerabilities.  AT&T Comments at 9.  AT&T states that solutions based on scanning networks may require customer disclosure of sensitive data, which they may be unwilling to give vendors because doing so would present a cybersecurity risk.  Id.  In light of AT&T’s concerns, providers may fall back on manual registered location if automatic solutions raise security concerns.  

181. We also conclude that it is important to encourage development of alternative approaches, based on the full range of device-based and other available location technologies, that place less burden on the end user than manual updates, and that can often provide more accurate, timely, and reliable location information for VoIP users that move frequently between multiple locations or are at locations they do not regularly visit.  Such information may not always be precise enough to identify the caller’s dispatchable location, but it can significantly reduce the potential for error or delay that otherwise occurs when a VoIP provider relies solely on Registered Location and uncertainty arises about whether the VoIP user is actually calling from that location.  Commenters generally support giving interconnected VoIP providers the flexibility to provide alternative location information, including x/y/z coordinates, as a supplement or alternative to dispatchable location. See, e.g., ATIS Comments at 3 (stating that “x/y/z coordinates may be beneficial as a supplement or alternative to dispatchable location in certain contexts.”); Bandwidth Comments at 6 (“Because an IP end-point can be a soft agent that resides on a mobile device, like a smart-phone, a laptop or tablet (which could be completely outside the expected building environment), more accurate and dynamic end-user location information could be presented in the form of latitude-longitude information or ‘X/Y coordinates’ instead of, or in addition to, a civic address and floor number.”); NCTA Comments at 7 (stating that “the Commission should adopt its proposal to ‘allow providers flexibility in implementing dispatchable location solutions, and to fall back to Registered Location options when dispatchable location is not feasible’”).
  Therefore, we give non-fixed VoIP providers flexibility to provide alternative location information, including coordinate-based information, from all available sources when providing dispatchable location is not technically feasible.  This will provide flexibility for non-fixed VoIP providers to convey an accurate location to the PSAP while minimizing the burdens on the interconnected VoIP service provider and the end user.  
182. We recognize that where a non-fixed VoIP provider provides alternative location information, the location fix may be less precise than a location that pinpoints the caller’s location down to the room, office, or apartment level.  We find that the record strongly supports allowing less precise—but still actionable—alternative location information as a fallback approach when providing dispatchable location is not technically feasible.  Therefore, as an alternative to automated dispatchable location or end users’ manual updating of Registered Location information, we allow non-fixed VoIP providers to provide alternative location information, which may be coordinate-based, sufficient to identify the caller’s civic address and approximate in-building location, including floor level, In the interconnected VoIP context, Microsoft requests that the Commission define alternative location information as “[l]ocation information (which may be coordinate-based) sufficient to identify the civic address and approximate in-building location, which may include floor level, in large buildings.”  Letter from Paula Boyd, Senior Director, Government and Regulatory Affairs, Microsoft Corporation, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, at 2 (filed July 26, 2019) (Microsoft July 26 Ex Parte).  Similarly, INCOMPAS requests the addition of an option for non-fixed interconnected VoIP service providers to provide enhanced location information if providing alternative location information is not technically feasible.  Letter from Christopher L. Shipley, Attorney & Policy Advisor, INCOMPAS, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, GN Docket No. 11-117, at 2 (filed July 26, 2019) (INCOMPAS July 26 Ex Parte).  However, as described in this paragraph, we implement a backstop to allow a VoIP provider to route a 911 call to a national emergency call center in certain cases.  We believe this backstop provides additional flexibility for VoIP providers and thus obviates the need to adopt INCOMPAS or Microsoft’s proposals.
 in large buildings. RingCentral requests that the Commission “consider clarifying that 911 calls from a particular device or end-user terminal can only be subject to one set of location requirements,” i.e., that providers should not be subject to both the MLTS and VoIP rules for the same service.  Letter from Brita Sandberg, Counsel to RingCentral, Inc., to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, GN Docket No. 11-117, at 2 (filed July 25, 2019) (RingCentral July 25, 2019 Ex Parte).  We agree that the MLTS and interconnected VoIP location rules do not overlap, and that providers should be subject to only one set of requirements for any particular service they provide.  If a service meets the definition of interconnected VoIP service in section 9.3 of our newly adopted rules, it will be subject to the interconnected VoIP location rules and not the MLTS location rules.
  We also clarify that as a last resort, a VoIP provider may route a 911 call to a national emergency call center for the operator to ask the caller about his or her location, so long as the provider has made a good-faith effort to obtain location data from all available alternative location sources. RingCentral July 25, 2019 Ex Parte at 1.  
  We also conclude that the two-year transition period established by this order is appropriate for implementation of these requirements, as it is consistent with implementation timeframes recommended by a number of industry commenters, See, e.g., RingCentral Comments at 12 (stating that the Commission should allow at least 18 to 24 months to develop solutions to meet the complex challenges posed by any new location requirements); VON Comments at 8 (stating that if the Commission adopts new location requirements for nomadic VoIP providers, the compliance date should be at least 24 months after the effective date of our implementing order).  
 provides time for development and deployment of improvements in technology that can refine the nomadic VoIP location process, including improvements to location databases and commercially available device-based technologies, Microsoft Comments at 8-15.
 and coincides with implementation of milestones intended to improve in-building location of wireless 911 calls under the Commission’s wireless location accuracy rules. See supra para. 158.

c. Outbound-Only Interconnected VoIP
183. Consistent with Congress’s approach of establishing regulatory parity across technological platforms and enabling the completion of outgoing 911 calls and messages from people in emergency situations, we adopt 911 location requirements for outbound-only interconnected VoIP providers.  The requirements we adopt today are flexible and technologically neutral from a compliance standpoint and serve a vital public safety interest.  We amend the definition of “Interconnected VoIP Service” used for 911 purposes to include outbound-only interconnected VoIP services that generally permit users to initiate calls that terminate to the PSTN.  We thus require outbound-only interconnected VoIP providers to comply with our 911 obligations, including the requirement to notify subscribers of any limitations to E911 service.  However, we modify the notification requirement to clarify that it may be satisfied through stickers or warning labels, or other conspicuous means, provided that the notification is prominently displayed or highlighted in a manner that makes it likely to be seen by the customer. See infra Appendix A, final rule § 9.11(b)(5)(iii).  In this regard, inclusion of the notification in the fine print of an online customer agreement would not be sufficient.  Pursuant to section 3507(d) of the Paperwork Reduction Act, the information collection contained in Appendix A, final rule section 9.11(b)(5)(i) & (ii) as it applies to outbound-only interconnected VoIP service providers is subject to review by the Office of Management and Budget.  44 U.S.C. § 3507(d); Paperwork Reduction Act of 1995, Pub. L. No. 104-13, 109 Stat 163 (1995) (codified at 44 U.S.C. §§ 3501-3520); see infra Appendix A, final rule § 9.11(b)(5)(i) & (ii).  Thus, we will be revising the information collection contained in 3060-1085 to extend the customer notification requirements contained in Appendix A, final rule section 9.11(b)(5)(ii) & (iii) to outbound-only interconnected VoIP providers.  See infra para. 246. 
  Similar to our discussion of nomadic VoIP service above, See supra Section b.
 we require outbound-only interconnected VoIP service providers, which are now encompassed by our amended language in the section 9.3 definition of “Interconnected VoIP Service,” to provide (1) dispatchable location if feasible, or, otherwise, either (2) manual updating of Registered Location information; or (3) alternative location information sufficient to identify the caller’s civic address, floor level, and approximate floor location in large buildings.  We require outbound-only interconnected VoIP providers to comply with the 911 requirements we adopt today two years after the effective date of the rules. This is consistent with the compliance deadlines adopted for nomadic VoIP services.  See supra Section b.  No commenters addressed compliance dates for outbound-only interconnected VoIP service providers.  INCOMPAS and Microsoft request that the Commission clarify in our rules that outbound-only interconnected VoIP services have two years to comply with the 911 requirements that we adopt in this order and are not subject to the pre-existing VoIP 911 rules that have been recodified in final rule § 9.11(a).  See Letter from Paula Boyd, Senior Director, Government and Regulatory Affairs, Microsoft Corporation, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, at 5 (filed July 26, 2019); INCOMPAS Ex Parte at 2.  We agree and have clarified our rules accordingly.  See infra Appendix A, final rule § 9.11(a).
  
184. RAY BAUM’S Act directs the Commission to “conclude a proceeding to consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call, regardless of the technological platform used.” See RAY BAUM’S Act, § 506(a) (emphasis added).  Subsection (c) defines “9-1-1 call” as “a voice call that is placed, or a message that is sent by other means of communication, to a public safety answering point (as defined in section 222 of the Communications Act of 1934 (47 U.S.C. 222)) for the purpose of requesting emergency services.”  See id. § 506(c)(1). 
  RAY BAUM’S Act also states that, “[i]n conducting the proceeding . . . the Commission may consider information and conclusions from other Commission proceedings regarding the accuracy of the dispatchable location for a 9-1-1 call . . . .” See id., § 506(b).
  RAY BAUM’S Act defines a “9-1-1 call” as a voice call that is placed, or a message that is sent by other means of communication, to a PSAP for the purpose of requesting emergency services. Id. § 506(c)(1).

185. Consistent with RAY BAUM’S expansive approach, which recognized the Commission’s existing 911 authority, the Commission broadly sought comment on what communications services not covered by existing 911 rules but that are capable of making 911 calls may fall within this definition. Notice, 33 FCC Rcd at 9011, para. 82.  RAY BAUM’S Act, § 506(c)(1).
  In the Notice, the Commission asked whether (1) outcomes for 911 callers would be improved if it adopted 911 rules for these communications services that parallel existing rules, including any requirements for conveying dispatchable location and (2) new rules that are specifically tailored for those communications services would be more effective at improving outcomes. Notice, 33 FCC Rcd at 9011, para. 82.  
  Specifically, the Commission observed that some outbound-only VoIP services partner with businesses that offer 911 smartphone applications that allow consumers to make calls to 911 and that 911 stakeholders have expressed concerns that calls received from these services may route to the incorrect PSAP, result in fraudulent calls, lack critical location information capabilities, and place the 911 caller at risk. Id., para. 83 (citing Letter from Evelyn Bailey, Executive Director, National Association of State 911 Administrators, to Tom Wheeler, Chairman, FCC at 2 (Oct. 18, 2016) (on file in RM-11780)).   
  The Commission noted that the current rules do not require outbound-only VoIP services to support 911 or convey dispatchable location with 911 calls, but it recounted that in 2011 the Commission sought comment on expanding 911 obligations to providers of outbound-only interconnected VoIP services. Notice, 33 FCC Rcd at 9011, para. 83; see also Amending the Definition of Interconnected VoIP Service in Section 9.3 of the Commission’s Rules; Wireless E911 Location Accuracy Requirements; E911 Requirements for IP-Enabled Service Providers, Notice of Proposed Rulemaking, Third Report and Order, and Second Further Notice of Proposed Rulemaking, 26 FCC Rcd 10074, 10092-94, 10107-08, paras. 48-58, 100-101 (2011) (VoIP E911 Notice). The issue remained pending before the Commission.  In the most recent comment-seeking effort, the Commission proposed in the Notice to adopt a definition of “911 VoIP Service” 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.”  Notice, 33 FCC Rcd at 9012, para. 84.  In this regard, we reject Microsoft’s assertion that the Notice provides an insufficient basis for expanding or modifying the definition of “Interconnected VoIP Service” to include outbound-only interconnected VoIP service.  Microsoft Comments at 21-22.
  
186. The Commission has broad authority over interconnected VoIP services and 911. 47 U.S.C. § 615a-1; New and Emerging Technologies 911 Improvement Act of 2008, Pub. L. No. 110-283, 122 Stat. 2620 (2008).
  The RAY BAUM’S Act provided the Commission the flexibility to consider whether and how to apply dispatchable location requirements to services that provide the capability for users to make a 911 call, which includes outbound-only interconnected VoIP.  We believe that the expansive scope of the legislative directive provides legal authority for the Commission to adopt regulations that will ensure dispatchable location data are conveyed with 911 calls with any voice service that satisfies the definition of “9-1-1 call,” including outbound-only interconnected VoIP service. To the extent an outbound-only interconnected VoIP service is used to enable text rather than voice communications with 911, we note that there would be no analog for text-to-911 for this service.  See infra Appendix A, final rule § 9.10(q).
  It also leaves room to amend the definition of “Interconnected VoIP Service” at section 9.3 pursuant to the NET 911 Improvement Act and the CVAA. See infra, note 571.

187. We find that, from a 911 perspective, outbound-only interconnected VoIP services are functionally equivalent to landlines and other interconnected devices that connect to the PSTN and are 911-capable, and thus, we should require outbound-only interconnected VoIP service providers to comply with 911 obligations.  As noted by West Safety, “[f]rom a caller’s perspective, interconnected outbound-only VoIP service is, for the most part, similar to traditional telephone service, and its users reasonably expect it to function the same.” West Safety Comments at 14.
  To illustrate further, Microsoft’s Skype voice application facilitates Internet-based calls yet also provides users the ability to call any landline or mobile device. See Microsoft Comments at 2-5 (overview of Microsoft’s various IP-based calling services through its Skype software); see also How Do I Make a Call in Skype?, https://support.skype.com/en/faq/FA10613/how-do-i-make-a-call-in-skype (last visited July 11, 2019). 
  Failing to require support for 911 services by outbound-only calling services that are able to place PSTN calls to any other North American Numbering Plan telephone number treats similarly-situated services differently and enables and rewards regulatory arbitrage.  Moreover, treating these services inconsistently or 911 purposes is likely to breed consumer confusion, particularly when a caller is seeking help in a time of crisis.  
188. Some commenters submit that the essential basis of Commission regulation of outbound-only VoIP services is whether those services would substitute for traditional telephone service. Verizon Comments at 9; see also INCOMPAS Reply at 11 (noting that “data provided for the record shows that consumers are still choosing traditional fixed and mobile voice services to make their emergency calls”). 
  However, as discussed above, our 911 rules already apply to interconnected VoIP (as currently defined to refer to both inbound and outbound interconnection), and the Commission proposed extending those obligations to outbound-only interconnected VoIP more than eight years ago. See supra Section 3 (discussing dispatchable location requirements for interconnected VoIP service); VoIP E911 Notice, 26 FCC Rcd at 10089-94, paras. 40-58.
  To use Skype to call regular phones, consumers pay by purchasing credits, subscribe to Skype for unlimited calls, or buy a Skype phone number. See How Do I Make a Call in Skype?, https://support.skype.com/en/faq/FA10613/how-do-i-make-a-call-in-skype (last visited July 11, 2019).
  Additionally, Skype emergency calling is enabled in certain countries, platforms, and versions of Skype software. See Skype Emergency Calling, https://www.skype.com/en/legal/emergency-calling/ (last visited July 11, 2019) (noting that Skype Emergency Calling is enabled on: Skype for Windows 10, Skype for Windows, Skype for Mac, Skype for Linux: available in Australia, Denmark, Finland, and UK; home phone adapters: available in UK).
  Moreover, our current approach enables providers to avoid basic public interest obligations by offering purportedly separate “outbound-only” and “inbound-only” calling services, even though these services combined are functionally equivalent to traditional calling services and, in a regulatory sleight of hand, avoid basic public interest obligations.  We decline to maintain this regulatory loophole to the benefit of one segment or market participants over another, and to the detriment of consumers.
189. Some commenters support expanding 911 obligations to outbound-only VoIP services on the grounds that consumers increasingly rely on a variety of interchangeable communications services to place 911 calls and expect those services to connect them to first responders. See Comtech Comments at 11-12 (“Imposing FCC requirements on such 911-capable VoIP services also represents a necessary step toward ensuring the availability of emergency services in devices and commercial communications offerings that consumers are increasingly relying on in their daily lives.”); NENA Comments at 8 (supporting the Commission’s proposal to expand 911 service rules to include “911 VoIP Services” because VoIP-enabled “smart speakers” are evolving in users’ minds as the “new home phone”); BRETSA Reply at 19 (“Desktop computers, laptops, tablets, cell phones, and other devices are increasingly used for voice and video personal communications using native functionality or over-the-top applications, and it is foreseeable that this trend will continue.”). 
  Others, however, argue that consumer expectations regarding outbound-only VoIP do not warrant imposing any obligations. Microsoft Comments at ii, 17-22; VON Comments at 8; INCOMPAS Reply at 2, 10-11; see also VON Comments at 8 (stating that outbound-only VoIP consumers do not expect 911 functionality); Microsoft Comments at 20 (noting it is unlikely for an emergency caller to have access to an outbound-only calling application and an Internet connection without a mobile phone or fixed line telephone because fixed and mobile penetration in the U.S. is high); INCOMPAS Reply at 10-11 (stating that consumers do not expect to use outbound-only VoIP services to reach first responders, with data provided by Microsoft’s SkypeOut service indicating that consumers are still choosing traditional fixed and mobile voice services to make emergency calls).  

190. As an initial matter, we decline to make consumer expectations the touchstone for determining what types of services should be subject to 911 obligations.  In this context, the relevant RAY BAUM’S Act provisions do not refer to consumer expectations; rather, they define “9-1-1- call” broadly, in relevant part, as “a voice call that is placed, or a message that is sent by other means of communication, to a public safety answering point . . . for the purpose of requesting emergency services.” RAY BAUM’S Act, § 506(c)(1) (emphases added).
  The statutory focus, therefore, is on enabling the user to reach emergency services to request assistance, “regardless of the technological platform,” Id. at § 506(a).
 not on whether the service bears similarity to a traditional two-way phone call or whether consumers perceive it as such.  Our decision to subject outbound-only VoIP service to 911 obligations is most consistent with Congress’s focus on ensuring that all messages from a person to emergency services are received, regardless of the technology employed.  A focus on consumer expectations, by contrast, would frustrate the statute by disadvantaging those people who were unaware that a particular device or technology was incapable of dialing 911—precisely the tragic circumstance that led to the adoption of Kari’s Law.  
191. In any event, we find that consumer expectations generally support our decision today.  We find that consumer expectations on this issue have significantly changed since 2011. For example, Precision Broadband submits that “[c]onsumers have a desire (and growing expectation) to use non-phone, broadband connected devices to contact 911.”  Letter from Charles H. Simon, Jr., Founder and Chief Executive Officer, Precision Broadband, LLC, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 07-114, 18-261, 18-64, at 1 (filed June 27, 2019) (Precision June 27 Ex Parte).  Precision notes that in a recent study that it commissioned focusing on consumer perceptions of 911 and alternative access technologies, “[o]f the 250 people surveyed, 63% said they would like to be able to contact 911 using one or more devices through their home broadband connection.”  Id.  Precision asserts that this was further validated in the recent “‘Smart Audio Report’ where 55% of consumers ‘expressed interest in having a feature that would allow their smart speaker to call 911 if multiple smoke alarms went off in the home.’”  Id.  See National Public Radio, The Smart Audio Report (2019), https://www.nationalpublicmedia.com/smart-audio-report/latest-report/ (last visited July 11, 2019).
  In this respect, we give significant weight to the fact that the increasing variety of interchangeable voice services on the market has changed the public’s expectations about access to 911, and our rules today reflect those expectations. See supra note 531; see also West Safety Comments at 14 (arguing that from the caller’s perspective, outbound-only interconnected VoIP service is similar to traditional telephone service, and users reasonably expect it to function the same).
  We are persuaded by BRETSA’s comments that the fact that Microsoft has enabled emergency calling with Skype in some European countries and Australia demonstrates that 911 calling can be provided in the United States. BRETSA Reply at iii-iv, 25.
  BRETSA also asserts that it is more important for callers to be able to reach 911 in an emergency than that a PSAP can reconnect a dropped call, Id. at 24-25;  Additionally, in 2011, some commenters articulated their belief that outbound-only interconnected VoIP providers have solutions to support PSAP callback or other means of reconnection if a call to 911 is disconnected.  NENA Comments at 6 (GN Docket No. 11-117, PS Docket No, 07-114, WC Docket No. 05-196) (stating its belief that callback methods already in use by outbound-only VoIP providers such as Skype Caller ID could permit such providers to supply callback information to PSAPs using, for example, permissibly manipulated Caller ID information); TeleCommunications Systems, Inc. (TCS) Comments at 5 (GN Docket No. 11-117, PS Docket No, 07-114, WC Docket No. 05-196) (stating if an outbound-only interconnected VoIP service provider has initiated a callback mechanism, also referred to as an “‘online number’ for non-emergency purposes to support callback capability from a PSTN phone,” the service provider should have no significant cost or technical barrier to allowing the PSAP or 911 call center to reconnect with the caller if the 911 call is inadvertently dropped).
 and we agree.  
192. The commenters who assert that consumers do not expect to reach 911 from outbound-only systems present little data that support their position.  In particular, Microsoft, VON, and INCOMPAS oppose the Commission’s proposed expansion of 911 obligations to outbound-only VoIP calling applications, arguing that users of one-way calling capabilities do not expect to reach emergency services on these tools and do not use them for emergency calling. See Microsoft Comments at 20 (stating that it is unlikely for an emergency caller to have access to an outbound-only calling application and an Internet connection without a mobile phone or fixed line telephone because fixed and mobile penetration in the U.S. is high); VON Comments at 8 (stating that outbound-only VoIP consumers “do not expect 911 functionality”); INCOMPAS Reply at 10-11 (consumers do not expect to use outbound-only VoIP services to reach first responders, with data provided by Microsoft’s SkypeOut service indicating that consumers are still choosing traditional fixed and mobile voice services to make emergency calls).  
  Microsoft adds that it voluntarily deployed emergency calling on its one-way, outbound-only calling feature Skype to Phone (formerly SkypeOut) in four foreign countries (Australia, Denmark, Finland, and the United Kingdom) and that only 1,788 emergency calls were made in those four countries in the most recent 23-month period. Microsoft Comments at ii, 18.  In its comments, Microsoft refers to its outbound-only VoIP service where emergency calling has been enabled as SkypeOut.  Id.
  According to Microsoft, “[t]he low emergency call volumes are evidence that consumers do not expect to have the capability to make emergency calls through Skype desktop and tablet applications and, when this capability is provided to them, they tend not to use it.” Id. at 18.
  Microsoft also states that many emergency calls placed from this calling feature lasted less than one minute, “strongly suggesting accidental or nefarious calls to emergency services since valid emergency calls tend to last longer than a minute.” Id. at 18-19.  As a result, Microsoft states, more of the emergency calls from this calling feature were erroneous than were valid.  Id. at 19.  We also note that while Microsoft states that 1,788 calls were placed to 911 during the defined period, 2,000 calls lasted less than one minute.  We are unable to reconcile these numbers as they appear inconsistent.  See also Microsoft June 26 Ex Parte at 4 (stating that in Microsoft’s experience in the four countries where emergency calling is enabled today, emergency calls that last less than one minute outnumber legitimate calls (i.e. those lasting more than one minute) almost 2-to-1).  
  Commenters argue that consumers do not expect to use outbound-only VoIP services to place emergency calls, in part because some expected features of 911 calling, specifically PSAP callback, are not readily available. Microsoft Comments at 19 (“Outbound-only calling applications, by definition, do not enable the user to receive calls back from the PSAP in the same manner that two-way calling services do” and that “if an emergency call from an outbound-only application were to disconnect, the emergency call operator may have no way to re-establish a connection with the user.”); INCOMPAS Reply at 10-11 (asserting consumers using two-way, regulated voice service expect to receive a call-back from a PSAP in the event their emergency calls are disconnected and because outbound-only VoIP service cannot provide that capability, it is less likely that consumers would choose this service to make an emergency call).  But see RedSky Comments at 27 (stating that “any device capable of initiating a 9-1-1 call should be subject to the Rules for dispatchable location” and PSAP callback functionality “should be addressed.”).
  Thus, according to Microsoft and INCOMPAS, the Commission would be creating consumer expectations for 911 services where certain features that customers have come to expect with emergency calling are technically not feasible. See Microsoft Comments at 19-20 (stating that the Commission “should not create consumer expectations where none exist, particularly for applications that, for technical reasons, do not match the features of other readily available options for emergency calling,” such as callback); INCOMPAS Reply at 10-11 (“Outbound-only VoIP service, by definition, cannot provide that [call-back] capability making it less likely that consumers would choose this service to make an emergency call.”).  
  Microsoft and INCOMPAS also contend that expanding 911 rules to outbound-only VoIP will increase nuisance or accidental calls to emergency services, which is not in the public interest. Microsoft Comments at 20 (stating that given emergency call patterns on SkypeOut, in countries where such functionality is enabled, “requiring emergency calling on outbound-only calling applications would not materially benefit the safety of the average user, but could interfere with public safety objectives more broadly by increasing the accidental call burden on emergency call centers”); INCOMPAS Reply at 11 (arguing that, based on data provided by Microsoft, calls from outbound-only interconnected calling applications can overwhelmingly consist of accidental or nefarious calls, which can disrupt PSAP operations and threaten the public interest by diverting valuable resources away from genuine emergency calls).  Microsoft analogizes its argument to the Commission’s 1996 decision to extend emergency calling requirements to non-service-initialized (NSI) phones, which similarly lacked callback capabilities, by requiring carriers to forward to PSAPs automatically all 911 calls from wireless mobile handsets which transmit a code identification, without requiring user validation or any similar procedure.  Revision of the Commission’s Rules to Ensure Compatibility with Enhanced 911 Emergency Calling Systems, Report and Order and Further Notice of Proposed Rulemaking, 11 FCC Rcd 18676, 18692, para. 29 (1997).  Although the Commission has acknowledged that fraudulent 911 calls from NSI devices impose a substantial burden on PSAPs, we disagree with Microsoft that this is a result of the lack of the callback feature.  911 Call-Forwarding Requirements for Non-Service-Initialized Phones, Notice of Proposed Rulemaking, 30 FCC Rcd 3449, 3455, para. 12 (2015).
  
193. We find these arguments unpersuasive.  First, it is unsurprising that some consumers may not presently expect outbound-only calling services to support 911 dialing and location services, as they have not been obligated to do so.  In this respect, though, we disagree with the view that the Commission should refrain from acting for fear of “creating” expectations regarding the availability of 911 services; to the contrary, the Commission should act where it finds a need to support public safety.  Second, the data presented prompt us to draw the opposite inference on calls to emergency services from SkypeOut in four foreign countries than that asserted by Microsoft.  Rather than indicating that 911 connectivity was not expected in these instances, we find the existence of these calls is instead evidence that at least some users expected—and needed—to call for help via SkypeOut.  We may further infer that as use of these services becomes more widespread, the expectations carried with these services will align with traditional voice services.  That domestic expectations have also evolved with the technology is reflected in the congressional emphasis that the Commission should consider whether dispatchable location obligations apply “regardless of the technological platform.” RAY BAUM’S Act, § 506(a).
  Furthermore, concerns about overly broad regulation are misplaced because we apply the change in a limited way—solely to 911 obligations on outbound-only interconnected VoIP service providers.  Finally, the possibility that there may be nuisance or inadvertent calls to 911 from outbound-only services is not a sufficient reason to exclude such services from the 911 obligations applicable to interconnected VoIP service providers, thereby providing no access to 911 for callers with legitimate emergency needs to use these services.  While we recognize that accidental or nuisance calls can strain already limited PSAP resources, there has been no demonstration that these calls would overwhelm PSAP capabilities. Microsoft speculates that relying on end users to manually update their location information could create an additional risk that applications like Skype could be downloaded easily by a nefarious actor who could then “input a false location, and then a make a 911 call for the purpose of dispatching public safety resources to a particular location under false pretenses.”  Microsoft July 26 Ex Parte at 3-4.  We find this argument implausible.  For one, interconnected VoIP providers are already required to require their end users to register a location for 911 calls, and yet the record presents no evidence that this is a problem today.  Given that distinguishing feature between such services and outbound-only interconnected VoIP services is solely the lack of a callback feature—which is unrelated to the problem Microsoft alleges—we see no reason to think improper location information will suddenly become a problem should Microsoft be required to allow its SkypeOut users call emergency services effectively.  More broadly, nefarious actors can give false information to a PSAP via any technological platform—and there is nothing distinctive about outbound-only interconnected VoIP services that would lead us to believe including them would have a material impact.  What is more, we do not mandate registered locations to be collected but instead empower providers to use other technologies to facilitate dispatchable location or alternative location information for such 911 calls—and of course we expect providers like Microsoft to take into account the risks to public safety it has flagged when choosing how to comply with our rules.  Finally, to the extent that Registered Location still presents any “additional risk,” as Microsoft posits, that risk is outweighed by the need for people to be able call 911 and for emergency responders to find them. 
  
194. Several commenters support expanding 911 dispatchable location requirements to outbound-only VoIP services, See Comtech Comments at 11-12 (supporting expanding use of dispatchable location requirements for other 911-capable services, including those services capable of initiating 911 calls that are not covered by existing 911 regulations such as outbound-only VoIP services); RedSky Comments at 26-27 (arguing that any device capable that is location aware or supported by a network that is aware of the device’s location and capable of initiating a 911 call should be subject to dispatchable location rules); West Safety Comments at 15 (supporting extending 911 rules to outbound-only interconnected VoIP services through the Commission’s proposed definition of “911 VoIP Service”).
 and state that technically feasible solutions exist for such service providers to provide that data. See West Safety Comments at 13-14 (stating that several low-cost internal or vendor solutions to provide dispatchable location data currently available for nomadic interconnected VoIP service, such as a hybrid approach using existing device location or network history, are also available to 911 VoIP services like outbound-only interconnected VoIP); BRETSA Reply at 25 (stating that there “would not appear to be any technical reason outbound-only services cannot provide 9-1-1 calling, since Microsoft provides 9-1-1 calling with Skype in several countries”).
  Comtech states “it is imperative that any location requirements adopted for 911-capable services take into consideration the current state of technology and its rapid rate of change.” Comtech Comments at 12.
  Verizon indicates that, like nomadic VoIP, the Commission should clarify that nomadic outbound services could use either dispatchable locations or registered locations because the same concerns raised in the context of nomadic VoIP services apply. Verizon Comments at 9; see supra Section b for discussion of nomadic VoIP.
   
195. We find that it is technically feasible to require outbound-only interconnected VoIP service providers to convey the dispatchable or alternate location requirements we adopt today. See, e.g., Letter from Charles H. Simon, Jr., Founder and Chief Executive Officer, Precision Broadband LLC, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 07-114 and 18-261, at 1 (filed May 30, 2019) (“Precision Broadband’s system leverages the fixed broadband networks of facilities-based Internet Service Providers to provide the same real-time, accurate, dispatchable address location, including floor and unit, as is provided today with E911 landline telephone service for CMRS and non-CMRS device 911 calls.”).
  The location requirements for outbound-only interconnected VoIP service providers allow for flexible, technologically neutral compliance.  Although the Notice sought comment on such communications services that are not covered by existing 911 rules yet are capable of making a 911 call and their ability to convey location information to the PSAP, no commenters submit that it is not possible for outbound-only interconnected VoIP providers to convey such location information. Verizon notes that its concerns regarding the impact of the proposed rules on nomadic VoIP also apply to nomadic outbound-only services as well.  Verizon Comments at 9.  We address those concerns in Section b supra.  See also, e.g., BRETSA Reply at 25. 
  With the additional compliance time provided below, we anticipate that such a capability can be readily applied within the United States. See supra Section b (discussing technical considerations and compliance requirements for nomadic VoIP services).

196. 911 VoIP Service.  The Commission sought comment on expanding the scope of those IP-based services subject to our 911 rules to include not only interconnected VoIP but to also include “911 VoIP Services,” which was proposed to include those services that enable real-time, two-way voice communications that require IP-compatible customer premises equipment and permit users generally to initiate a 911 call, even if the service does not permit users generally to receive calls that originate on the PSTN, thus encompassing those services that are considered “outbound only VoIP.” Notice, 33 FCC Rcd at 9012, para. 84.  
  The Commission further stated its intent to retain the existing definition of “Interconnected VoIP Service” to avoid inadvertent impact on the term as used by various non-911 statutory provisions.  By proposing a new “911 VoIP Service” category for use in the Commission’s 911 rules, the Commission sought to avert unintended consequences. Id. at 9012 n.135 (citing 47 U.S.C. § 153(25), 47 CFR §§ 54.5, 63.60(e), (g), 63.71(f)(2)(ii)(A), 64.601(a)(15), 64.1600(i), 64.2003(o), 64.2005(c)(3)).  

197. We conclude that the best approach to achieve what the public interest demands is to amend the definition of “Interconnected VoIP Service” to expand those services subject to our 911 rules, rather than to adopt a separate “911 VoIP Service” definition.  In this respect, we find that the definition of “911 VoIP Service” proposed in the Notice mirrors the existing definition of “Interconnected VoIP Service,” with the exception that the fourth element of the proposed definition does not reference calling numbers or interconnection to the PSTN and is limited to 911 calls. Notice, 33 FCC Rcd at 9012, para. 84.  
  Amending the definition of “Interconnected VoIP Service” to include outbound-only VoIP services solely for purposes of extending our 911 obligations is consistent with our intent to apply only this set of obligations to such services, but in a manner that responds to record comments and avoids the unintended consequences to other uses of the term.  For example, some commenters express concerns with the proposed definition of “911 VoIP Service” and the applicability of our 911 requirements, including dispatchable location, to those services. RedSky Comments at 39; Verizon Comments at 9.
  Verizon states that the Commission’s proposal to apply the interconnected VoIP 911 rules, including the registered location choice, to newly defined outbound-only “911 VoIP Services” may be overbroad. Verizon Comments at 9; see also RedSky Comments at 26 (stating that it would be counterintuitive for the Commission to create rules that counter state laws that do not allow automated dialers or alarm systems to initiate a 911 call).
  Verizon asserts that it is unclear that outbound-only VoIP meets the New and Emerging Technologies (NET) 911 Improvement Act standard of “widely accepted and fungible substitutes for telephony” if there are no other connections to the public switched telephone network. Verizon Comments at 9.  Cf. RedSky Comments at 39 (noting that a system’s ability to reach 911 is reliant upon its ability to connect to the PSTN and asserting that the Commission’s definition of “911 VoIP Service” must insure that if a system can reach the PSTN, it must adhere to all subsequent 911 obligations).
  According to Verizon, the proposed rule also is unclear because it would require that calling party number information be provided on all 911 VoIP services, which could enable callback for a service that supports both outbound and inbound calling, but “would not help for outbound-only services.” Verizon Comments at 9.  
  
198. Accordingly, we decline to adopt the defined term “911 VoIP Service” and instead add an additional category of services that constitute interconnected VoIP for the purposes of 911 obligations to expand the scope of services to those that are generally capable of allowing users to initiate calls that terminate to the public switched telephone network, including calls to 911. See id.  We acknowledge that some voice applications may provide users with both interconnected and non-interconnected VoIP services and emphasize that applicability of our 911 requirements to interconnected VoIP service providers hinges on whether the service satisfies all prongs of the definition, including interconnection to the PSTN.  
  We expand the definition of “Interconnected VoIP Service” in section 9.3 of the Commission’s rules to mean a service that permits users generally to terminate calls to the public switched telephone network. We note that the definition we adopt today tracks more closely to the existing definition of “Interconnected VoIP Service” as it is currently defined to refer to both inbound and outbound interconnection than the definition proposed in the 2011 NPRM, which permitted users to terminate calls to all or substantially all United States E.164 telephone numbers.  VoIP E911 Notice, 26 FCC Rcd at 10093, para. 51.  As we describe above, this is in-line with our intended approach to minimize disruption to the current definition of “Interconnected VoIP Service” in section 9.3 of the Commission’s rules. 

199. We concur with BRETSA’s concerns that outbound-calling voice applications or service providers could configure their services for the specific purpose of avoiding 911 compliance. BRETSA Reply at 25 (noting that voice application or service providers might configure their outbound-calling service for the specific purpose of avoiding the complications and expense of 911 compliance).
  As a result, the definition of “Interconnected VoIP Service” extends 911 calling requirements to interconnected, outbound-only VoIP services that generally permit users to terminate calls to the public switched telephone network.  We further clarify that the revisions we adopt today preserve the application of the original definition of “Interconnected VoIP Service” to other parts of the Commission’s rules while expanding those services to which the Commission’s 911 rules apply.  Thus, the non-911 statutory provisions and rules that reference the current definition of “Interconnected VoIP Service” in section 9.3 of the Commission’s rules are not disturbed. See, e.g., 47 CFR parts 6, 14, 51, 52, 54, 63, 64.  We further clarify that outbound-only interconnected VoIP services, which are now encompassed within the section 9.3 definition of “Interconnected VoIP Service,” are still considered non-interconnected VoIP services for the purposes of section 716 of the Communications Act of 1934, and therefore remain subject to part 14 of the Commission’s rules.  See 47 U.S.C. §§ 153(36), 617(f); 47 CFR part 14; Implementation of Sections 716 and 717 of the Communications Act of 1934, as Enacted by the Twenty-First Century Communications and Video Accessibility Act of 2010; Amendments to the Commission’s Rules Implementing Sections 255 and 251(a)(2) of the Communications Act of 1934, as Enacted by the Telecommunications Act of 1966; Accessible Mobile Phone Options for People who are Blind, Deaf-Blind, or Have Low Vision, CG Docket No. 10-213, WT Docket No. 96-198, CG Docket No. 10-145, Report and Order and Further Notice of Proposed Rulemaking, 26 FCC Rcd 14557, 14564, 14570-72, paras. 13, 34-36 (2011).
  Consistent with the directive of RAY BAUM’S Act, and as supported by the record, we find that expansion of the location requirements to interconnected VoIP service, which includes outbound-only interconnected VoIP service, enacts 911 rules that are flexible and technologically neutral from a compliance standpoint while limiting regulatory disruption.  
200. Some commenters also argue that expanding 911 requirements to “911 VoIP Services” exceeds the scope of the Commission’s statutory authority under the NET 911 Improvement Act. Microsoft Comments at 21; Verizon Comments at 9.
  Microsoft states that the Commission has not proposed a sufficient basis of statutory authority to impose emergency calling obligations on outbound-only voice applications, and contends that the NET 911 Improvement Act provided the Commission authority to establish emergency calling requirements for IP-enabled voice services, which were defined to be synonymous with “Interconnected VoIP Service.” Microsoft Comments at 21, note 32 (citing 47 U.S.C. § 615b(8) (“IP-enabled service has the meaning given the term ‘interconnected VoIP service’ by § 9.3 of the Federal Communications Commission’s regulations.”)).  Microsoft notes that the Notice proposed to adopt the new term “911 VoIP Services” for use in the 911 rules but to retain the existing definition of interconnected VoIP service “since that definition is referenced by various non-911 statutory provisions and rules.”  See id. at note 33 (citing Notice, 33 FCC Rcd at 9012 n.135).
  However, Microsoft asserts that the Notice “does not propose to expand or modify the definition of ‘interconnected VoIP service’ to include outbound-only calling apps.  Nor does it propose an independent basis for imposing these requirements on applications that currently satisfy the statutory definition of ‘non-interconnected VoIP.’” Microsoft Comments at 21-22 (footnotes omitted) (citing 47 U.S.C. § 153(36) (“The term non-interconnected VoIP service means a service that enables real-time voice communications that originate from or terminate to the user’s location using Internet protocol or any successor protocol; and requires Internet protocol compatible customer premises equipment; and does not include any service that is an interconnected VoIP service.”)).  As noted above, we reject Microsoft’s notice argument.  See supra note 521.  
  As a result, Microsoft claims that the Commission’s proposal would “involve an extraordinary expansion of the scope of the FCC’s regulatory authority and would exceed the limits of reasonable statutory interpretation.” Microsoft Comments at 21.
  
201. We disagree that expanding 911 requirements to the underlying services that would have met our proposed definition of “911 VoIP Services” exceeds the scope of the Commission’s authority under the NET 911 Improvement Act, particularly when coupled with the directive of RAY BAUM’S Act. To the extent commenters argued that the Commission lacks statutory authority to create a “911 VoIP Services” definition that includes non-interconnected VoIP, we conclude that the issue is moot as we are not addressing those services at this time.  See, e.g., Microsoft Comments at 21-22 (stating that the Notice does not provide adequate legal basis for expanding the scope of its 911 obligations to a new category of providers); INCOMPAS Reply at 10 (stating that any decision to extend 911 obligations to other communications services should be based on customer expectations and whether application of rules to new services would be in the public interest); Cisco Comments at 8 (stating that the Commission should “tread cautiously” when considering imposing dispatchable location requirement on “off-premises” systems, cloud-based IP technology, or over-the-top applications that may be beyond the reach of what Congress envisioned).
  In this respect, by amending the definition of interconnected VoIP we meet both the letter and spirit of both laws, which provides the Commission discretion and flexibility to address new technologies.  We find that Congress, in directing the Commission to consider all technological platforms, intended the Commission to consider 911 obligations for these technologies.  Moreover, the NET 911 Improvement Act provides that “[i]t shall be the duty of each IP-enabled voice service provider to provide 9-1-1 and enhanced 9-1-1 service to its subscribers in accordance with the requirements of the Federal Communications Commission, as in effect on the date of enactment of the [NET 911 Improvement Act] . . . and as such requirements may be modified by the Commission from time to time.” NET 911 Improvement Act of 2008, Pub. L. 110–283, 122 Stat 2620 at § 101(3) (codified at 47 U.S.C. § 615b(8) (2008)).  The NET 911 Improvement Act stated the duty of each IP-enabled voice service, a term synonymous with “Interconnected VoIP Service” as defined by section 9.3 of the Commission’s rules, to provide 911 service in accordance with requirements of the Commission in effect on the date of the NET 911 Improvement Act’s enactment.  Id.  Furthermore, the NET 911 Improvement Act directed the Commission to adopt regulations establishing parity for IP-enabled voice services with commercial mobile services under the Commission’s 911 rules.  Id. at § 101(2) (codified at 47 U.S.C. § 615a-1(c) (2008)).
  Pursuant to subsequent legislation, the Commission also retains ample authority to amend the definition of interconnected VoIP. The CVAA defines “advanced communications services” to include “Interconnected VoIP Service” as defined in section 9.3 of our rules “as such section may be amended from time to time,” as well as “non-interconnected VoIP” service,” which is service other than interconnected VoIP service “that . . . enables real-time voice communications that originate from or terminate to the user’s location using Internet protocol or any successor protocol; and . . . requires Internet protocol compatible customer premises equipment.”  Twenty-First Century Communications and Video Accessibility Act of 2010, Pub. L. No. 111-260, §§ 101, 102, 103(a), 103(b), 104(a), 105, 106, 202, 203(a), 203(b), 203(c). 124 Stat. 2751, et seq.  (amending sections 3, 225, 303, 330, 710, and 713 of the Communications Act, and adding sections 615c and 715-19 (codified at 47 U.S.C. §§ 153, 225, 303, 330, 610, 613, 615c, 616-20)).  The 2010 revisions to the Truth in Caller ID Act define “IP-enabled voice service” to have “the meaning given that term by section 9.3 of the Commission’s regulations (47 C.F.R. 9.3), as those regulations may be amended by the Commission from time to time.”  Truth in Caller ID Act of 2009, Pub. L. No. 111-331, 124 Stat. 3572 (2010) (codified at 47 U.S.C. § 227(e)(8)(C) (2010)).  The Commission subsequently interpreted Congress to have referred to the definition of “Interconnected VoIP Service” in section 9.3.  See Rules and Regulations Implementing the Truth in Caller ID Act of 2009, WC Docket. No. 11-39, Report and Order, 26 FCC Rcd 10074, 10106, para. 96 (2011) .  We observe that, in RAY BAUM’S Act, Congress amended the Truth-in-Caller-ID Act to change the scope of covered communications from any “telecommunications service or IP-enabled voice service” to a “voice service or a text message sent using a text messaging service,” and in so doing, dropped the reference to section 9.3’s definition of “Interconnected VoIP Service” for purposes of those requirements.  See RAY BAUM’S Act, § 503(a)(1) (codified at 47 U.S.C. § 227(e)(1) (2011)); see also Implementing Section 503 of RAY BAUM’S Act, Rules and Regulation Implementing the Truth in Caller ID Act of 2009, WC Docket Nos. 18-335 and 11-39, Notice of Proposed Rulemaking, 34 FCC Rcd 738 (2019).  Congress left intact, however, the reliance on section 9.3’s definition of “Interconnected VoIP Service” for purposes of any 911 obligations, including, but not limited to, the dispatchable location obligations added elsewhere in the RAY BAUM’S Act.  Congress thus continued to leave to the Commission’s discretion whether to revise that definition for purposes of 911 requirements, as we do here.  
  As a result, we find that the Commission has direct statutory authority to modify the definition of “Interconnected VoIP Service” to include outbound-only interconnected VoIP, See, e.g., 47 U.S.C. § 153(25), 47 CFR §§ 54.5, 63.60(e), (g), 63.71(f)(2)(ii)(A), 64.601(a)(15), 64.1600(i), 64.2003(o), 64.2005(c)(3).  
 and today we modify that definition.    
202. Although in the Notice the Commission stated its intention to avoid disturbing the existing definition of interconnected VoIP since it is referenced by various non-911 statutory provisions and rules, we find that our approach to amending the definition of “Interconnected VoIP Service” in section 9.3 of the Commission’s rules satisfies our proposed intent and responds to concerns raised by commenters.  Specifically, to implement RAY BAUM’S Act, the Commission led with a proposal to adopt the definition of “911 VoIP Services” and also sought comment on extending 911 requirements, including location obligations, to outbound-only VoIP services under the definition of “911 VoIP Services.”  We note that entities which provide one-way, interconnected VoIP service have been on notice since 2011, and even as early as 2005, that the Commission was considering expanding the scope of its 911 rules to include their communications services. See IP-Enabled Services; E911 Requirements for IP-Enabled Service Providers, WC Docket Nos. 04-36, 05-196, First Report and Order and Notice of Proposed Rulemaking, 20 FCC Rcd 10245, 10277, para. 58 (2005) (seeking further comment on whether to extend E911 obligations to providers of other VoIP services that are not covered by the interconnected VoIP service E911 rules as adopted in the Report and Order); Amending the Definition of Interconnected VoIP Service in Section 9.3 of the Commission's Rules; VoIP E911 Notice, 26 FCC Rcd at 10108, para. 101 (seeking comment on whether, if the Commission decides to amend the definition of interconnected VoIP in section 9.3 of the Commission’s rules, the Commission should amend it for 911 purposes only).  Commenters to the 2011 proposal generally supported the Commission’s broad legal authority to impose 911 requirements on entities to advance and promote reliable E911 service throughout the country.  See, e.g., Letter from H. Russell Frisby, Jr., Counsel to TCS, to Sean Lev, General Counsel, FCC, GN Docket No. 11-117, at 12 (filed Aug. 15, 2013); Letter from H. Russell Frisby, Jr., Counsel to TCS, to Marlene H. Dortch, Secretary, FCC, GN Docket No. 11-117, WC Docket No. 05-196, PS Docket No. 11-153, PS Docket No. 10-255, at 3-4 (filed Nov. 21, 2014); see also Letter from Dean R. Brenner, Senior Vice President, Government Affairs, Qualcomm, to Sean Lev, General Counsel, FCC, GN Docket 11-117, WC Docket 05-196, PS Docket 11-153, PS Docket 10-255, at 4-5 (filed Sept. 13, 2013) (while the expansion of E911 requirements to interconnected VoIP providers involved the Commission’s regulation of wire or radio communications, which arguably falls within the Commission’s general jurisdiction grant, any such regulations must be consistent with the Congressional purpose under the NET 911 Improvement Act of providing VoIP providers with a right to access the 911 infrastructure).  
  The Notice was informed by, and cited to, these earlier rulemaking efforts, including the outstanding proposals from 2011, and RAY BAUM’S Act left the Commission discretion to consider these earlier efforts.  The rule we adopt today reflects consideration of proposals raised in earlier Notices of Proposed Rulemaking and in the Notice to extend dispatchable location obligations to one-way VoIP calls, the purpose of the Notice to dispatch our RAY BAUM’S Act mandate to consider all technological platforms, and record comment received in response.  In light of the comments received, we have not amended our definition of interconnected VoIP, except as it affects 911 service obligations for outbound-only interconnected VoIP service.  
203. Furthermore, as stated above, commenters express concern about our statutory authority to expand our 911 rules to services beyond interconnected VoIP services, and in response we act upon their suggestion that an amendment of the definition of “Interconnected VoIP Service” would accomplish the Commission’s intended objective, particularly where we limit the definition change solely to impose 911 obligations.  Moreover, the similarities in the proposed language of the definition of “911 VoIP Services” largely tracks the language of “Interconnected VoIP Service,” and as such, regardless of the label used, the service to which our rules were to be applied is sufficiently apparent.
204. We amend the definition of “Interconnected VoIP Service” to include outbound-only interconnected VoIP services.  The expansive scope of the legislative directive coupled with our discretion to amend the definition of “Interconnected VoIP Service” provides sufficient legal authority for the Commission to extend 911 regulations, including rules to convey dispatchable location with 911 calls, to outbound-only interconnected VoIP services.  Doing so in this fashion also avoids loopholes for evading regulatory obligations that protect the health and safety of the American people, which commenters have pointed out to be a risk of attaching such obligations only to those who choose to provide “911 VoIP Services.” See, e.g., BRETSA Reply at 25 (stating concerns that voice application or service providers may configure their outbound-calling service for the specific purpose of avoiding the complications and expense of 911 compliance).
  We believe that this approach is consistent with our objective to promote safety of life and property through communications. 47 U.S.C. § 151.
  
205. Compliance Deadline.  In the Notice, the Commission proposed to require compliance for dispatchable location requirements on the same date as the proposed implementation for Kari’s Law, i.e., February 16, 2020. Notice, 33 FCC Rcd at 9012-13, paras. 87-88.
  The Commission further tentatively concluded that applying the same compliance date across all platforms will promote efficiency and encourage development of common dispatchable location solutions. Id. at para. 87.
  No commenters addressed compliance deadlines for outbound-only interconnected VoIP service providers, but some commenters objected to the proposed February 16, 2020 date as premature for imposition of dispatchable location requirements for any service. See supra Sections a-b. 
    
206. We adopt a two-year period for compliance for outbound-only interconnected VoIP service.  Due to the similar nomadic or mobile functionality of the services, we find that similar implementation considerations for nomadic VoIP providers are applicable to outbound-only interconnected VoIP providers and warrant additional time for compliance. See, e.g., Microsoft Comments at 4 (describing its outbound-only Skype to Phone application as designed to be nomadic); Verizon Comments at 9 (describing concerns regarding the impact of dispatchable location requirements on nomadic VoIP providers applying to nomadic outbound-only services as well).
  Furthermore, adopting a two-year compliance period for outbound-only interconnected VoIP service providers will result in a compliance date in the same time frame as the implementation deadline for wireless E911 location requirements, which will promote regulatory parity and encourage the development of common location solutions across all platforms.
4. Telecommunications Relay Services (TRS)
207. In the Notice, the Commission observed that TRS providers are required to deliver emergency calls to an appropriate PSAP and to provide the location of the emergency. Notice, 33 FCC Rcd at 9010, para. 79 (citing 47 CFR § 64.605).
  For some of these services, the service provider is required to ask callers for their location information at the beginning of the emergency call. See 47 CFR § 64.605(a)(2)(iii).
  For emergency calls made through a Video Relay Service (VRS) or IP Relay (collectively, “Internet-based TRS”), the service provider must transmit location information to the PSAP in the form of a Registered Location under rules modelled on the Commission’s interconnected VoIP 911 rules. See 47 CFR § 64.605(b)(2)(ii).
  In the Notice, the Commission observed that “Internet-based TRS and interconnected VoIP face similar concerns regarding the ability to accurately locate end users that use a mobile or portable device.” Notice, 33 FCC Rcd at 9010, para 79.  
  The Commission therefore proposed dispatchable location requirements for Internet-based TRS paralleling the requirements it proposed for VoIP, i.e., allowing Internet-based TRS providers flexibility to implement automated dispatchable location and to fall back to Registered Location options when real-time dispatchable location is not feasible. Id. at 9010-11, para. 81.
  The Commission asked whether there are differences between Internet-based TRS and interconnected VoIP that might require taking a different approach to TRS dispatchable location, and sought comment on alternative approaches. Id.
 
208. We adopt flexible rules for Internet-based TRS that largely parallel our rules for fixed and nomadic VoIP.  In this respect, TRS commenters express many of the same views as VoIP commenters on the feasibility of providing automatic real-time dispatchable location.  Sorenson and CaptionCall state that “the technology for automatically locating mobile users is advancing rapidly and the technology for locating nomadic VoIP subscribers is improving, though it is still not reliable in every instance.” Sorenson and CaptionCall Reply at 5 (citing West Comments at 11-14, VON Comments at 7-8).
  Nevertheless, “[i]f solutions are not technically feasible for over-the-top VoIP services, whether mobile or nomadic, they will not be technically feasible for Internet-based TRS providers involved in call routing.” Sorenson and CaptionCall Reply at 4.
  Sorenson also states that in certain situations, Internet-based TRS providers lack the capability to automatically detect whether a videophone or device has changed location, in which case the only remaining option is to prompt users to confirm or update their locations. Sorenson Comments at 4-5, 8-9.
  Sorenson and other commenters therefore support the Commission’s proposal that Internet-based TRS providers should have the option to fall back to Registered Location when dispatchable location is not feasible. Id. at 7; Hamilton Comments at 6; ClearCaptions Reply at 3; Sorenson and CaptionCall Reply at 4; Sorenson is nonetheless concerned that the draft dispatchable location language in the proposed rule “is inconsistent” with the fallback proposal in paragraph 81 of the Notice.  Sorenson Comments at 8.  Sorenson and CaptionCall also state that it is not clear whether the proposed rules would allow providers to send calls to an Emergency Call Relay Center as a back-up when the previously collected Registered Location is deemed unreliable and alternative location information is not available.  Letter from John T. Nakahata, Counsel to Sorenson Communications, LLC, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 17-239, 18-261, at 5 (filed Mar. 25, 2019) (Sorenson and CaptionCall Mar. 25 Ex Parte).
   
209. TRS commenters also support being given flexibility to provide alternative location information when more precise location information is not available. Sorenson and CaptionCall Reply at 3 (citing Microsoft Comments at 10-12).
  Sorenson and CaptionCall state that “x,y,z needs to be a permissible alternative to dispatchable location, and may be necessary as location solutions evolve technologically.” Id. at 5 (citing ATIS Comments at 3).
  Sorenson states that when its ability to use device-based location is fully implemented and operational “the customer’s device will automatically determine an x, y (and, where available, z) location estimate,” provided the consumer has consented to allowing the VRS application to access location information from the device. Sorenson Comments at 6.
  In an ex parte filing, Sorenson and CaptionCall propose to require Internet-based TRS providers to provide dispatchable location when it is available but to permit automatic geolocation when the dispatchable location is unavailable.  If neither a dispatchable location nor geolocation information is available, their proposal would allow the provider to provide the Registered Location. Letter from John T. Nakahata, Counsel to Sorenson Communications, LLC and CaptionCall, LLC, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 17-239, 18-261, and CG Docket No. 13-24, at 2 (filed May. 24, 2019) (Sorenson and CaptionCall May 24 Ex Parte).
  Sorenson and CaptionCall also propose to specify in the rules that an Internet-based TRS provider can use a back-up call center when the provider is not confident that it can otherwise reliably identify the caller’s location. Id.
 
210. We find that in the Internet-based TRS environment, flexible rules and a longer time frame for providing accurate 911 location information are appropriate.  The record indicates that Internet-based TRS providers continue to rely heavily on Registered Location, but that alternative approaches are increasingly available that could support automated dispatchable location in some instances.
211. For 911 calls from fixed Internet-based TRS, We define TRS fixed services to include hardware-based TRS and videophone equipment that are professionally installed and cannot be moved by the customer without professional assistance. 
 beginning one year from the effective date of the rules, we require Internet-based TRS providers to provide automated, validated dispatchable location for each call.  For 911 calls from non-fixed Internet-based TRS, We define TRS nomadic and mobile services to include TRS facilities that use software-based endpoints.    
 beginning two years from the effective date of the rules, we require Internet-based TRS providers to provide with each 911 call (1) automated dispatchable location, if technically feasible, or, otherwise, either (2) manual updating of Registered Location, or (3) alternative location information, which may be coordinate-based, sufficient to identify the caller’s civic address and approximate in-building location, including floor level, in large buildings when the first two are not technically feasible.   
212. TRS commenters also identify a distinction between IP captioned telephone services (IP CTS), and relay services such as VRS and IP Relay.  Commenters state that call set-up and routing for most IP CTS calls are handled by the user’s underlying voice provider rather than the TRS provider. Hamilton Comments at 4; Sorenson and CaptionCall Reply at 2; Sorenson and CaptionCall Mar. 25 Ex Parte at 4.
  In case of a 911 call, the IP CTS Communications Assistant provides captioning but is not able to speak directly with the parties or generate location information, much less provide it to the PSAP. Hamilton Comments at 4, 6; Sorenson and CaptionCall Mar. 25 Ex Parte at 4.
  Sorenson and CaptionCall jointly suggest that the Commission should separate the dispatchable location requirements for VRS from the requirements for IP CTS, “allow[ing] each service to be treated in an appropriate manner.” Sorenson and CaptionCall May 24, 2019 Ex Parte at 1.
  Further, with respect to IP CTS, Sorenson and CaptionCall state that the ability of web/wireless IP CTS applications to provide information other than Registered Location is dependent upon the capabilities of underlying nomadic or mobile VoIP providers. Id. at 2.
  To afford IP CTS providers time to implement these capabilities, they propose that the Commission set the implementation date for IP CTS one year after the implementation date for nomadic or mobile VoIP. Id.; see also Letter from John T. Nakahata, Counsel to Sorenson Communications, LLC and CaptionCall, LLC, to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 17-239, 18-261, at 3 (filed June 27, 2019) (Sorenson and CaptionCall June 27 Ex Parte) (“The VoIP service provider may not finalize and fully deploy stable, provider Application Programming Interfaces (‘APIs’) that support 911 location delivery until close to the VoIP implementation deadline.  Any mobile device communications app publisher, such as CaptionCall, will then require some time to finalize its software that connects to and relies on the underlying VoIP provider’s API and, if necessary, to a 911 service provider (e.g. West).  Once that device software is developed, it and the full system still need to be tested to ensure there are no problems within the mobile IP CTS application or the manufacturers’ various devices on which the software may run.  Pre-launch product performance verification usually takes about 6 months.  Together, finalizing software and subsequent verification testing add up to one year.”).
  
213. We clarify that these requirements do not apply to TTY-based TRS providers, See Letter from David A. O’Connor, Danielle Thumann, Counsel for Hamilton Relay, Inc., to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 18-261, 17-239, GN Docket No. 11-117 (filed July 25, 2019).
 or to Internet-based TRS providers who completely rely on their customers’ underlying voice service providers to handle emergency call set-up, routing, and provision of location information. See Hamilton Comments at 4; Sorenson and CaptionCall Mar. 25 Ex Parte at 4.
  In such cases, it is not necessary to impose requirements on the TRS provider because the underlying service provider is subject to the relevant 911 requirements, including location requirements, in connection with the call.  Next, we are dismissing Sorenson and Caption Call’s request to set the implementation date for IP CTS one year after the implementation date for non-fixed VoIP because the location rules we adopt herein provide sufficient flexibility including fall back to Registered Location, and they only apply to IP CTS providers that handle call set-up and routing.
214. We also clarify that the rules do not require TRS providers to automatically detect when a device is being used at a different location from the Registered Location to the extent doing so is not technically feasible.  The record indicates that such detection is not technically feasible for some Internet-based TRS providers. See Sorenson Comments at 4-5, 8-9.
  In such cases, the requirement can be met by a manual prompt to the user asking for confirmation whether the user is at the Registered Location or a different location.  
215. We agree with commenters regarding routing of calls to Emergency Calling Relay Centers as a last resort in the occasional case where neither a prompt for a manual update nor any alternative technology confirms the validity of the caller’s location or otherwise provides actionable dispatchable location information.  In those isolated cases, we will allow Internet-based TRS providers to route the call to an Emergency Calling Relay Center, so long as the provider has made a good-faith effort to obtain location data from all available alternative location sources.  
216. Finally, we find that our TRS location rule amendments herein do not conflict with the IP CTS emergency calling requirement rule proposals in, or prejudge the outcome of, the IP CTS Reform Further Notice.  The Commission did not propose any changes to location requirements in the IP CTS emergency call handling rules. See Misuse of Internet Protocol (IP) Captioned Telephone Service; Telecommunications Relay Services and Speech-to-Speech Services for Individuals with Hearing and Speech Disabilities, CG Docket Nos. 13-24, 03-123, Report and Order, Further Notice of Proposed Rulemaking, and Order, 34 FCC Rcd 691, 725 Appendix E, proposed rule § 64.605(a)(3) (2019) (IP CTS Reform Further Notice).
  We crafted our new TRS location rules so that they will harmonize with the proposed IP CTS emergency call handling rules in the event the latter are adopted, as well as with the existing TRS rules in the event that the proposed IP CTS emergency call handling rule amendments are not adopted.  Further, the Commission noted that “issues regarding location determination by IP CTS providers, as well as other TRS providers, will be addressed in that docket,” which refers to the instant docket. Id. at 709 n.110.
  
5. Mobile Text
217. In the Notice, the Commission noted that our current Text-to-911 rules require mobile carriers and other covered text providers to obtain location information sufficient to route text messages to the appropriate PSAP, but text providers are not required to convey additional location information to the PSAP. Notice, 33 FCC Rcd at 9007, para 70 (citing TTY to Real-Time Text Technology; Petition for Rulemaking to Update the Commission’s Rules for Access to Support the Transition from TTY to Real-Time Text Technology, and Petition for Waiver of Rules Requiring Support of TTY Technology, Report and Order and Further Notice of Proposed Rulemaking, 31 FCC Rcd 13568, 13595, para. 50 (2016)).  
  The Commission stated that this approach has always been viewed as an interim solution, and noted the prior pending proposal in the Text-to-911 docket to require covered text providers to deliver enhanced location information (consisting of the best available location information that covered text providers can obtain from any available location technology or combination of technologies, including device-based location). Notice, 33 FCC Rcd at 9007, para 70 (citing Facilitating the Deployment of Text-to-911 and Other Next Generation 911 Applications; Framework for Next Generation 911 Deployment, Second Report and Order and Third Further Notice of Proposed Rulemaking, 29 FCC Rcd 9846, 9875, para. 61 (2014) (Text-to-911 Order)).
  In the Notice, the Commission sought to refresh the record on text-to-911 location and asked whether to apply dispatchable location requirements to text-to-911, if it is technically feasible, consistent with requirements applied to other platforms. Notice, 33 FCC Rcd at 9008, para. 71.
  
218. The record indicates that the location technology options available to covered text providers have significantly expanded since the Commission adopted its text-to-911 rules five years ago.  For example, commenters point to recent improvements in technology that have the potential to provide location information for an increasing percentage of 911 texts.  First, wireless carriers note that they are starting to transition mobile wireless text services from SMS to more robust IP-enabled platforms, such as real-time text, which can support provision of location information with 911 texts using some of the same location methodologies that are used to support IP-based voice services. AT&T Comments at 11 (stating that because real-time text includes a voice component, it can access specific caller location updates—and deliver it to the PSAP); Verizon Comments at 7 (“The transition to IP-enabled LTE networks, and global text telephony (GTT) (i.e. real-time text. . . ) solutions, that leverage VoLTE’s E911 capabilities, will most effectively improve location accuracy for text-based communications to PSAPs.”).
  Second, Comtech and West Safety note the potential to use the device-based location capabilities of mobile handsets (e.g., Google’s Emergency Location Service in Android devices) to generate location information, which can then be sent via text to the PSAP. Comtech Comments at 6-7; West Safety Comments at 12.
 
219. However, the transition away from SMS texting is far from complete, and the technologies being used to support text-to-911 location, while promising, have not yet been demonstrated to be capable of consistently supporting either dispatchable location or enhanced location accuracy comparable to the level of accuracy required for wireless voice services.  In this respect, wireless carriers commenting on this issue caution against requiring them to implement dispatchable location capabilities in SMS-based text-to-911, which would require major retrofitting of legacy SMS networks that were not designed to support the provision of location information. AT&T Comments at 11; T-Mobile Reply at 4; see Verizon Comments at 7.    
  Commenters express uncertainty about (1) when text-to-911 will fully migrate from SMS-based texting to newer technologies, and (2) how soon device-based location for 911 texts will be universally available. Comtech Comments at 7.
  Comtech states that “some of the technological challenges that must be overcome to improve location information for text-to-911, when compared to wireless voice 911 location information, include: (1) the current configuration of mobile handsets, (2) the types of location technologies and protocols supported by mobile handsets, and (3) the availability of real-time location platforms across each individual carrier.” Id. 
  Consequently, while some commenters support establishing enhanced location requirements for text-to-911, APCO Comments at 4 (“Requiring dispatchable location information with all text-based methods would be appropriate, either under the current wireless location accuracy benchmarks or a separate deadline for MLTS and other platforms.”); Comtech Comments at 8 (stating that despite financial and technological challenges, the Commission should “consider adopting enhanced location information requirements for covered text providers”).
 others argue that such requirements are premature. AT&T Comments at 11; T-Mobile Reply at 4.
  
220. We therefore conclude that it would be premature to adopt dispatchable location requirements for text-to-911 comparable to the requirements applicable to other services covered by this order.  Instead, we adopt a flexible approach to text-to-911 location requirements.  We require covered text providers, within two years of the effective date of these rules, to provide (1) dispatchable location, if technically feasible, or, otherwise, either (2) end-user manual provision of dispatchable location, or (3) enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available existing technology or combination of technologies at reasonable cost.  We clarify that the latter requirement does not require covered text providers to retrofit SMS-based text networks or to upgrade legacy mobile handsets that are only SMS-capable.  We recognize that as a practical matter, covered text providers are unlikely to be capable of providing dispatchable location for most 911 texts, and that the quality of “best-available” location information provided with 911 texts may vary.  Nevertheless, we believe that over time this requirement will encourage development of improved location capabilities for text-to-911, while accounting for technical feasibility issues raised in the current record.
6. Comparison of Benefits and Costs
221. In order to quantify the magnitude of the benefits to the public when dispatchable location is conveyed with a 911 call from MLTS and other communications services identified in the Notice, the Commission anticipated that the increase in location accuracy that results from the use of dispatchable location will reduce the arrival time of ambulances for some 911 callers at least as much as was accomplished by the mobile location rules adopted in the Indoor Location Fourth Report and Order. Notice, 33 FCC Rcd at 9014, para. 92.
  In that Report and Order, the Commission found that the location accuracy improvements adopted for mobile 911 calls had the potential to save approximately 10,120 lives annually for an annual benefit of approximately $92 billion. Id. at 9014-15, para. 92 (citing Indoor Location Fourth Report and Order, 30 FCC Rcd at 1320, para. 166).
  Based on available 911 call volume data in the Commission’s Ninth Annual Report and 911 Fees, the Commission estimated that approximately 75% of 911 calls come from mobile phones, which already are required to convey a dispatchable location. Notice, 33 FCC Rcd 9015, para. 92.  The Commission’s Ninth Annual Report on 911 Fees reported data showing that approximately 70 percent of total 911 calls in 2016 came from mobile phones.  The report noted that this likely understates the percentage of mobile 911 calls because some states reported total 911 calls but did not break out service categories separately.  FCC, Ninth Annual Report to Congress on State Collection and Distribution of 911 and Enhanced 911 Fees and Charges for the Period January 1, 2016 to December 31, 2016 at 10 (2017), https://www.fcc.gov/files/9thannual911feereportpdf (Ninth Annual 911 Fee Report).  The 2017 National 911 Progress Report found that in 2016, approximately 80 percent of consumers used cellular phones to make 911 calls, while about 16 percent used wireline phones.  National Highway Traffic Safety Administration (NHTSA), 2017 National 911 Progress Report at 2 (2017), https://www.911.gov/pdf/National-911-Program-Profile-Database-Progress-Report-2017.pdf.  The California Office of Emergency Services reported that in California, the percentage of 911 calls from mobile devices increased from 75 percent in 2014 to 79 percent in 2017.  California Office of Emergency Services, State of California Official E9-1-1 Call Statistics (2018), https://www.caloes.ca.gov/PublicSafetyCommunicationsSite/Documents/2018OfficialCallTotalswithNGandText.pdf. 
  However, the Commission believed the remaining 25% of calls to which its proposed rules would apply will realize benefits. Notice, 33 FCC Rcd at 9015, para. 92.
  Because three times as many calls come from mobile phones as from non-mobile sources, the Commission estimated that the proposed rules have the potential to save a maximum of one third of the 10,120 lives that were projected to be saved annually by the mobile location rules adopted in the Indoor Location Fourth Report and Order, or 3,373 lives annually. Id.
  However, because some providers already convey location information that is equivalent to dispatchable location, the Commission expected that the dispatchable location rules will save considerably fewer lives. Id.
  
222. In the Notice, the Commission assumed that the proposed rules would save 506 lives annually, or only one twentieth of the lives that it projected would be saved by the mobile location rules. Id.
  The Commission relied on the U.S. Department of Transportation’s estimate that the “Value of a Statistical Life” (VSL), defined as “the additional cost that individuals would be willing to bear for improvements in safety (that is, reductions in risks) that, in the aggregate, reduce the expected number of fatalities by one,” is $9.6 million. U.S. Department of Transportation, Guidance on Treatment of the Economic Value of a Statistical Life (VSL) in U.S. Department of Transportation Analyses at 1 (Aug. 8, 2016), https://www.transportation.gov/sites/dot.gov/files/docs/2016%20Revised%20Value%20of%20a%20Statistical%20Life%20Guidance.pdf.  We note that the value of a statistical life is not a measure of the value of a human life.  Rather, it is “an estimate for how much people are willing to pay to reduce their risk of death.  Alternatively, the VSL can be thought of as how much people are willing to pay for safety.”  See Strata, The Value of a Statistical Life: Economics and Politics (March 2017), https://www.strata.org/vsl/.
  In doing so, the Commission estimated that the 506 lives saved by the proposed rules multiplied by the VSL establishes a benefit floor of $4.9 billion. Notice, 33 FCC Rcd at 9015, para. 92.
  The Commission sought comment on the reasonableness of its estimate, what other benefits can be expected to accrue, such as (but not limited to) reduced complications from medical issues, reduced damage to property, increased likelihood of forestalling crime and apprehending suspects, and increased confidence in the 911 system and emergency responders. RedSky Comments at 30 (stating that “[t]he scale of benefits is incalculable” and that “[i]t is not possible, all actuarial tables aside, to determine the value of a life saved or lost because the first responder could not locate the person in need.”).  RedSky states that the benefits far exceed the simple saving of a life.  Id. at 32 (citing NPRM, para. 92).  RedSky identifies several additional benefits: “increases in person safety due to a reduction in first responder time to arrive, reduction in property damage due to reduction in time for a first responder to arrive at a fire, and the [reduction in] physical damage to a person when an emergency medical responder arrives sooner.”  Id.  RedSky states that it “is not prepared to estimate in dollars, the values of these benefits.”  Id.

223. No commenter disagreed with the Commission’s analysis of the benefits that the public should expect from the implementation of improved location accuracy requirements for MLTS and other services.  Additionally, public safety commenters support improvements to location accuracy for calls to 911 from MLTS and other services, provided that dispatchable location information is validated. See, e.g., APCO Comments at 6; MESB Comments at 6; NASNA Comments at 4; NENA Comments at 6; Texas 9-1-1 Entities Comments at 2-4. 
  The Texas 9-1-1 Entities submit that “as legacy TDM landline continues to transition to IP as the dominant market solution, 9-1-1 calls are becoming increasingly less distinguishable based solely on technological platform.” Texas 9-1-1 Entities Comments at 3.
  “While consistency alone warrants that the definition of ‘dispatchable location’ be the same across the Commission’s 9-1-1 rules regardless of technological platform (e.g., CMRS, fixed telephone/legacy landline, MLTS),” the Texas 9-1-1 Entities argue, “this is particularly important as technological platforms morph and evolve (e.g., fixed wireless, mobile VoIP, Wi-Fi calling) and no longer fit neatly into traditionally defined and differentiated categories.” Id. at 5.
  The Texas 9-1-1 Entities and MESB illustrate that validation is particularly necessary in an evolving IP environment, which appears vulnerable to 911 calls being misrouted across state lines and placing increased burdens on resource-limited PSAPs to re-route 911 calls to the appropriate jurisdiction. Id. at 5; MESB Comments at 5.  
  
224. Additionally, of the total reported calls to 911 in 2017, 155,231,318 calls came from wireless phones, representing approximately 70% of the total reported call volume. FCC, Tenth Annual Report to Congress on State Collection and Distribution of 911 and Enhanced 911 Fees and Charges for the Period January 1, 2017 to December 31, 2017 at 10 (2018), https://www.fcc.gov/files/10thannual911feereporttocongresspdf (Tenth Annual 911 Fee Report).
  In addition, the ratio of wireless calls to total reported call volume remained steady even though there was a 135% increase in VoIP calls from 2016 and a 378% increase in the number of calls reported as “Other” from 2016 (VoIP calls reported in 2017 increased to 7,666,958 from 5,661,055 in 2016 and the number of calls reported as “Other” increased to 8,907,760 from 2,353,291 in 2016). Id. at 10-11.
  While the Bureau believes that the 70% figure likely understated the percentage of wireless 911 calls because a number of states reported total 911 calls but did not break out all service categories separately, it is also likely that the Tenth Annual Fee Report underestimated the increase in VoIP and “Other” calls given that half of reporting jurisdictions did not report call volume for those categories. Id. at 10-13.
  Thus, the record suggests that the problem of inaccurate location information or no location information being conveyed with a 911 call from MLTS and other 911 services is common and will continue to grow and potentially undermine public confidence in location accuracy of such calls absent a requirement for validated location information.
225. In the Notice, the Commission proposed a dispatchable location implementation schedule across all technological platforms that tracked the February 16, 2020, compliance date for Kari’s Law.  The Commission sought comment on the costs of the proposed rules in the Notice. See, e.g., Notice, 33 FCC Rcd at 9002, para. 57 (seeking comment on whether there is “any reason why street address validation would be more difficult or costly for MLTS than for mobile E911?”); id. at 9004, para. 62 (asking whether currently-deployed MLTS that do not support provision of dispatchable location can be upgraded to do so, and, “[i]f they can be upgraded, what would those upgrades entail, and what would they cost?”); id. at 9005, para. 63 (seeking comment on whether to adopt rules requiring MLTS managers to provision location information for the enterprise to the MLTS operator, and, if so, what information should be initially provisioned and how frequently should the Commission require that information to be updated, and what are the costs associated with such provisioning and updating); id. at 9006, para. 65 (asking whether MLTS operators and managers should be required to contribute to the operating costs of the NEAD as a condition of leveraging it.); id. at 9007, para. 68 (seeking comment on what obstacles exist, if any, to fixed telephony carriers conveying dispatchable location to PSAPs, and, if obstacles exist, how could they be overcome, and at what cost.); id. at 9008, para. 71 (seeking comment on if it is technically feasible, should the Commission apply dispatchable location requirements to text-to-911 consistent with requirements applied to other platforms, and what would be the cost of such a requirement); id. at 9009, para. 77 (stating that to enable interconnected VoIP providers to appropriately balance technical feasibility, functionality, customer impact, and cost, the Commission proposed to allow providers flexibility in implementing dispatchable location solutions, and to fall back to Registered Location options when dispatchable location is not feasible.); id. at 9011, para. 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.”).
  The Commission observed that “911 location solutions that are capable of conveying dispatchable location to PSAPs are already offered by several MLTS market participants.” Notice, 33 FCC Rcd at 9015, para. 93 (citing Letter from Greg Rogers, Bandwidth, Inc., to Marlene H. Dortch, Secretary, FCC, PS Docket No. 17-239, Attach. at 8-10 (filed May 4, 2018) (stating that Bandwidth’s MLTS solution is capable of conveying the current location of the subscriber sent at 911 call time); Letter from Mary L. Brown, Senior Director, Government Affairs, Cisco Systems, Inc., to Marlene H. Dortch, Secretary, FCC, PS Docket No. 17-239, at 1 (filed May 7, 2018) (stating that the Cisco Emergency Responder solution is capable of dynamically updating location, with capability for making building, floor, and cube or room number available); Letter from Mary A. Boyd, ENP, VP, Regulatory and Government Affairs, West Safety Services, Inc., to Marlene H. Dortch, Secretary, FCC, PS Docket No. 17-239, Attach. at 2-10 (filed May 15, 2018) (explaining how West Safety offers services that include 911 for MLTS solutions that convey dispatchable location, including services that automatically discover the caller’s location)).
  Further, the Commission noted that “several states already place requirements on MLTS providers to obtain and convey location information that is more detailed than street address alone, [footnote omitted] and we therefore conclude that MLTS manufacturers are producing and widely selling equipment that is capable of complying with our proposed rules.” Id. at 9016, para. 93.  
  The Commission asked commenters to address whether there are any cases “in which currently-available equipment will not be suitable.” Id.
  In addition, the Commission observed that “to comply with current rules, interconnected VoIP service providers and Internet-based TRS providers today obtain customers’ Registered Location, which we believe would likely be sufficient to satisfy our proposed dispatchable location requirements in many circumstances.” Id.
  Because these dispatchable location-capable solutions and equipment are already being widely offered by MLTS manufacturers, installers, and operators, the Commission stated its belief “that the implementation costs of our proposed dispatchable location rules to these entities would be negligible in most respects.” Id.
  The Commission also expressed its belief “that our approach of granting flexibility in satisfying our proposed rules minimizes the potential cost of compliance.” Id.
  Accordingly, the Commission sought comment on these observations and tentative conclusions.
226. As the Commission emphasized in the Notice, we do not mandate any particular technology or model for implementing the 911 location rules we adopt today and apply these requirements on a technologically neutral basis.  Moreover, service providers can leverage existing location technology solutions to mitigate costs.  Further, we adopt a phased-in approach that allows service providers additional time beyond the February 16, 2020, proposal in the Notice to come into compliance with our rules.  Additionally, we have tailored the compliance deadlines to each particular service.  Further, we apply our rules on a prospective basis, thus minimizing cost on legacy systems and small businesses.  We find that applying our rules to these legacy systems would be too costly because there is such a great variety of systems that location technology solutions would have to be tailored for each enterprise. That said, the record demonstrates that delivering dispatchable location is technically feasible today for many services at a cost that is less than the $4.9 billion minimum benefit floor.  Consistent with our approach in the Wireless Indoor Accuracy Fourth Report and Order, this means that MLTS and other service providers subject to our 911 location rules need only choose the methods necessary to close the gap between already-deployed capabilities and the Commission’s requirements, “rather than starting from scratch.” Indoor Location Accuracy Report and Order, 30 FCC Rcd at 1322, para. 169.
  So, although the cost of meeting our 911 location rules has not yet been determined to a dollar amount, the rules we adopt today provide MLTS and service providers a clear reference point from which to factor in compliance costs incrementally. Id.
  We provide the following analysis of comments addressing compliance costs.
227. Compliance Costs.  In the Notice, the Commission estimated that the annual cost to MLTS operators to provide location information as proposed would be less than $49.6 million, and that such costs are likely to decline within a few years as databases and other sources of location information become increasingly centralized.  The Commission also estimated a $460,000 per-provider cost for 18 providers of Interconnected VoIP, VRS, and IP Relay services to implement software upgrades that would detect when an end user’s location has changed and to identify the new location.  The Commission also sought comment on implementation costs for outbound-only VoIP providers. The Commission sought specific comment on three aspects of its rules that it anticipated would lead to additional implementation costs: (1) implementation of the proposed dispatchable location requirement by MLTS managers and (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 requirement for outbound-only VoIP service providers or other 911 VoIP service providers to comply with the dispatchable location rules.  Notice, 33 FCC Rcd at 9016, para 94.
  No commenter objected to the costs estimated in the Notice. See, e.g., RedSky Comments at 20; RedSky Reply at 9.
  One commenter, however, suggested that the Commission over-estimated the costs associated with building a “white pages like directory” or database and software development costs. RedSky disagrees with “the Commission’s basic premise that the highest initial cost is associated with building a ‘white pages like directory’ or database” and states that the device location technology in use by RedSky, Cisco, West, Avaya, and others does not rely on a static database “for the sole reason that it is static.”  RedSky Comments at 36.  RedSky states that it offers a commercially available, off-the-shelf solution that runs on any device that uses Windows 8 or higher, MAC, IoS, or Android and that allows the user to self-provision its dispatchable location, including address validation against a national MSAG database.  The application is called MyE911® and, according to RedSky, it can be used today to meet the Commission’s proposed rules.  Id. at 37.  But see Cisco Comments at 19-20 (stating that any dispatchable location requirement that the Commission adopts must strike a reasonable balance between the specificity of information that is provided and the costs imposed on enterprise customers, and noting that Cisco’ Emergency Responder, for instance, adds roughly 10 percent to the monthly base cost of Call Manager.).
   
228. Industry commenters recognize that accurate location information can be critical in ensuring a timely emergency response, including for vulnerable populations such as TRS users. See, e.g., TIA Comments at 2; Cisco Reply at 9-10; Sorenson Reply at 1; Sorenson and CaptionCall June 27, Ex Parte at 1.; Precision June 27, Ex Parte at 1.
  Commenters suggest that providers of fixed MLTS, fixed telephony, and interconnected VoIP already provide dispatchable location, See, e.g., Verizon Comments at 6-7; Cisco Reply at 8; ACA Connects April 22 Ex Parte at 1-2; Cisco May 23, Ex Parte at 2; VON Ex Parte at 1. 
 while some are concerned that applying dispatchable requirements to nomadic or remote, off-site MLTS could undermine incentives to use innovative solutions. See, e.g., AdHoc Comments at 13; Panasonic Comments at 21; RingCentral Comments at 4-5; TIA Comments at 5-6; Verizon Comments at 6-7; AdHoc Reply 9-10; Cisco Reply at 8; see also TIA Comments at 16; West Safety Comments at 13.  
  The record reflects that industry has incentives to continue to improve 911 location capabilities See, e.g., RingCentral Reply at 9-10; Sorenson and CaptionCall June 27 Ex Parte at 1-2; Precision June 27 Ex Parte at 1.
 and desires flexibility to adopt 911 solutions. BluIP Comments at 5-6; RedSky Comments at 18-20; West Safety Comments at 8-9.  
  However, industry commenters generally warn against applying rigid, overly-granular, See, e.g., AHLA Comments at 10-12; Avaya Comments at 7-8; Cisco Comments at i, 3-5, 23; Verizon Comments at 6; AdHoc Reply at 8; NCTA Reply at 6-7; TIA and DECT Forum Reply at 9-10; T-Mobile Reply at 3; Cisco May 22 Ex Parte at 2.
 “one-size fits all” See, e.g., Ad Hoc Comments at 3.
 dispatchable location mandates by February 16, 2020, that could be unduly burdensome on evolving technologies. See, e.g., Panasonic Comments at 20-21; TIA Comments at 1, 3; Verizon Comments at 7-10; Microsoft June 26 Ex Parte, at 1-2; TIA and DECT Forum Ex Parte at 2; VON Ex Parte at 1. 
  For example, Sorenson and CaptionCall note that “the technology for automatically locating mobile users is advancing rapidly and the technology for locating nomadic VoIP subscribers is improving, though it is still not reliable in every instance.” Sorenson Reply at 5 (citing West Comments at 11-14; VON Comments at 7-8.); see also RingCentral Comments at 11.    
  Microsoft suggests that prematurely applying such requirements would be unachievable and “runs the risk of preventing the use of readily available location technologies that can vastly improve the current location capabilities of MLTS and iVoIP, particularly nomadic MLTS and iVoIP services.” Microsoft June 26 Ex Parte at 1-2; see also Cisco May 22 Ex Parte at 2.
  Ad Hoc advises that “the Commission should not impose obligations on MLTS owners or operators to transmit any type of information that their MLTS equipment is not technically capable of transmitting or that would require assumption of any unreasonable costs to upgrade.” Ad Hoc Reply at ii, 8.
  Cisco expresses concerned that “[a] dispatchable location requirement would also amount to a de facto mandate for enterprise customers to purchase third-party solutions that may be cost-prohibitive or ineffective.” See Cisco Reply at 11.  But see West Safety Comments at 8.

229. Cost Mitigation.  Notwithstanding the lack of cost data, commenters suggest measures to mitigate potential costs and complexity of compliance, including enshrining the principles of technological neutrality, flexibility and maintaining service specific 911 rules. See, e.g., Microsoft Comments at 9; Cisco Reply at 7-10; ComTech Reply at 1-2; NCTA Reply at 6; Ring Central Reply at 3, 6-7.
  The requirements we adopt today are measured, technically feasible, and technologically neutral, so that service providers can choose the most effective solutions from a range of options.  In addition, our requirements allow sufficient time for advance planning and deployment of new location technology, beyond the February 16, 2020 compliance date proposed in the Notice.   
230. The record demonstrates that the scale of the potential benefits will increase over time given the magnitude of the problem we are facing, industry’s incentives to improve 911 location accuracy, and the fact that the requirements that we adopt today will render the conveyance of dispatchable location an even more effective emergency response tool as technology improves and becomes more widely available.
231. Outbound-only Interconnected VoIP.  In the Notice, the Commission acknowledged potential technical challenges for outbound-only interconnected VoIP services to automatically send a caller’s dispatchable location to a local PSAP during a 911 emergency. VON states that the Commission “should not enact 911 obligations on one-way, outbound only VoIP services because it would impose costs on what is typically a free service and there is no evidence that users of these service expect they can be used for 911 calls.”  VON Ex Parte at 1.  VON states that “the increased costs to manufacturers, developers, and service providers of complying with new 911 requirements would likely be passed onto consumers.”  VON Comments at 10.  “Currently, most outbound-only VoIP services are free.”  Id. at 10.  “It is unlikely that service providers would absorb the additional costs, which are estimated at 10 to 20 cents per line, per month, regardless of whether the line is used to make a 911 call, plus a one-time setup fee of $15,000 to $25,000.”  Id.
  Commenters submitted estimates for the costs of such a mechanism.  Precision Broadband, for example, noted in its ex parte its service of mapping a consumer broadband IP address to a dispatchable location, and projected “an expenditure of between $200 million and $275 million per year for the Fixed Broadband 911 system at full nationwide deployment.” Precision June 27, Ex Parte at 1-2 (explaining how their Fixed Broadband 911 System can improve location accuracy of 911 calls even expanding to ones made from non-phone, broadband-connected devices).  We note that Precision Broadband submitted this ex parte filing in multiple dockets besides those for this proceeding. Its $275 million estimate covers several proposals made in connection with these dockets.  Accordingly, these costs would be recovered over various other services.  As such, assigning the full $275 million solely to the implementation of Kari’s Law overstates the possible costs for implementing this rule.  See also Letter from Charles H. Simon, Jr., to Marlene H. Dortch, Secretary, FCC, PS Docket Nos. 118-64, 8-261, 17-239, at 2 (filed July 17, 2019) (stating that its estimates “may materially change once all participating parties have provided input regarding roles, responsibilities and costs.”).  
  We obtained a similar estimate for full nationwide coverage through alternative means. From our previous calculation of at most $49.6 million for MLTS operators to comply with our dispatchable location requirements we find that, even assuming the average household possesses five times as many outbound-only calling devices (e.g. Alexa Devices, Google Voice, and SkypeOut)—a generous assumption that likely will continue to overstate the number of devices in the near future—the total cost of expanding our ruling to incorporate outbound-only interconnected VoIP service providers is at most $248 million per year. 
  We also note this is an upper bound but an extremely unlikely scenario as many outbound-only interconnected VoIP services already have provision for delivering their location.  According to a 2016 study conducted by the Pew Research Center, See Pew Research Center, More Americans using smartphones for getting directions, streaming TV; (2016), https://www.pewresearch.org/fact-tank/2016/01/29/us-smartphone-use/.
 90% of smartphone users have location services enabled, meaning that these users can already be located automatically without the aid of a third-party technology like the one proposed by Precision Broadband. We also believe that this statistic would apply to other devices with location service capabilities For example, Alexa has location services available (see June Lee, Enhance Your Customer Experience with Real-Time Location Services for Alexa Skills, Alexa Blogs (Dec. 13, 2018), https://developer.amazon.com/blogs/alexa/post/f23d0796-6c98-40d4-b499-e198b347a998/location-services-launch) and most mobile devices and tablets have location services.  Moreover, devices such as Google Home have users enter their address (see Google Nest, Google Nest Help Center, https://support.google.com/googlenest/answer/7551002?co=GENIE.Platform%3DAndroid&hl=en (last visited July 8. 2019).  As such, not many devices will require alternate location services.  The $275 million figure presumes all devices require such support and is thus an upper bound even if its other assumptions were accurate.
 not just the smartphone.  Moreover, this Pew statistic suggests there would be a similar willingness of consumers to enter the dispatchable location into applications.  Thus, the costs imposed by this rule are for those consumers who neither have location services available nor enter an address.  Because the $275 million figure presumes there are no location services available today, we conclude that the total cost would be $27.5 million (10% of $275 million).  We believe it is a reasonable expectation that of the 506 lives saved, at least 25 lives (i.e., only 5% because, as explained above and in the Notice, about 95% of interconnected devices already have location ability) will be from this part of the rule.  Indeed, just three lives saved per year would fully cover the expected cost. Precision reports a per capita cost of approximately 61 cents to 84 cents, which suggests that annual costs vary with respect to the number of customers seeking such service.  Precision June 27, 2019 Ex Parte at 2.  If costs vary with respect to customer participation, a 10% participation nationwide would result in total annual costs of $27.5 million.  This cost would be more than covered by saving just 3 lives annually.  Yet, even if the cost were unaffected by the number of customers and thus imposed the full upper bound of Precision’s estimate at $275 million, that cost would be almost be fully covered by the benefits from the 25 saved lives alone (i.e., 25 x $9.6 million = $240 million).  As discussed earlier, we expect total benefits to far exceed the statistical value of lives saved due to numerous other benefits that cannot be quantified.  These include, e.g., reduction in pain and suffering, reduction in damaged property, and avoidance of damage from criminal activity.
  Furthermore, there are a variety of flexible options to provide 911 caller location information depending on the service, such as x-y-z coordinates or manually updated Registered Location, adding support for our finding that costs are likely to be on the lower end as we describe here.  We therefore find the benefits exceed the estimated costs imposed.  
232. We also require outbound-only interconnected VoIP service providers to comply with the customer notification requirements of our rules. See infra Appendix A, final rule § 9.11(b)(5).  
  We require outbound-only interconnected VoIP service providers to comply with the 911 requirements we adopt today two years after the effective date of the rules.  Regarding general 911 requirements that we extend to outbound-only interconnected VoIP, we envision that the costs for consumer notification and record-keeping would also be comparable to the information collection costs applicable to other interconnected VoIP service providers under the Commission’s rules.  In sum, the record indicates that the costs for outbound-only interconnected service providers to comply with our 911 rules, including dispatchable location, will not differ from the costs to interconnected VoIP providers that our well-established rules already cover and for which we have previously found to have the benefits outweigh the costs.    
C. Consolidating the Commission’s 911 Rules
233. In the Notice, the Commission proposed to consolidate all the existing 911 rules into a single rule part. Notice, 33 FCC Rcd at 9020, para. 104.
  The Commission also proposed to simplify and streamline the rules in some instances and to eliminate corresponding duplicative rules in other rule parts.  The Commission explained that rule consolidation will help to minimize the burden on small entities subject to the Commission’s 911 rules by making it easier to identify and comply with all 911 requirements. Id.
  
234. The majority of commenters who addressed the issue support the proposed 911 rule consolidation. APCO Comments at 7; Cisco Comments at 23; NASNA Comments at 4; NENA Comments at 9; RedSky Comments at 41; TIA comments at 3; West Safety Comments at 15.
  iCERT states that it does not object to a non-substantive rule reorganization, iCERT Reply at 2.
 and TIA supports removal of rules that are obsolete. TIA Comments at 22.
  Hamilton provided the sole comment expressing opposition, arguing that relay service rules “are integrated with non-911 related rules in such a way that removing the 911-related rules and transferring them to part 9 would be cumbersome and counterproductive. Hamilton Comment at 4 citing Notice, 33 FCC Rcd at 9022, para. 108.

235. We consolidate the existing 911 rules as proposed.  To address Hamilton’s concerns, we find that we can transfer and amend the relay service emergency calling rules without adversely affecting the integrity of the remaining non-911 relay service rules.  The revised part 9 differentiates between platforms and services where needed, but it also enables service providers, PSAPs, and other stakeholders to refer to a single part of the Commission’s rules to ascertain all 911 requirements.  
236. As noted in Appendix A and described for reference in conversion tables in Appendix B, we designate part 9, which currently contains our interconnected VoIP rules, as the rule part that contains the consolidated 911 rules, and we transfer and consolidate our existing 911 rules from parts 12, 20, 25, and 64 to part 9.  The revised part 9 will continue to differentiate between platforms where needed, but it will also enable service providers, PSAPs, and other stakeholders to refer to a single part of the Commission’s rules to ascertain all 911 requirements.  Specifically, we consolidate our 911 rules as follows:
· Move relevant definitions for all services to subpart A of part 9;
· Move telecommunications carrier obligations (section 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.
In addition, as proposed in the Notice, we remove section 12.3, an obsolete 911 rule that references a one-time information collection that has been completed, 47 CFR § 12.3; see also Notice, 33 FCC Rcd at 9020 para. 106; id. at 9078, Appendix C, Conversion Table B, Part 12.
 rather than recodify it in part 9.  The Commission also sought comment on whether to move section 22.921 of the rules, which addresses 911 call processing procedures for analog telephones in the Cellular Radiotelephone Service, 47 CFR § 22.921.
 into part 9 or whether that rule has become obsolete and should be removed. Notice, 33 FCC Rcd at 9020, para. 106.
  As proposed in the Notice, we remove section 22.921 as obsolete.
237. In proposing to consolidate the 911 rules, the Commission also invited commenters to identify any other rules that should be consolidated or updated. For simplicity and consistency with commenters, we refer to any cited rules using designations in part 9 as proposed in the Notice rather than current 911 rule sections.
  No commenters suggest additional rules for consolidation, but some commenters suggest substantive rule changes.  Several of these suggestions concern 911 call routing issues.  Specifically, BRETSA suggests that the Commission should require MLTS to be configured to route a 911 call to the PSAP serving the caller’s location to cover cases where a different PSAP serves the enterprise’s main office or location of the core MLTS equipment. BRETSA Reply at 10.
  MESB argues that federal intervention and enforcement mechanisms are needed to ensure accurate routing of 911 calls to the correct PSAP and accurate callback number delivery to the PSAP, noting that state MLTS statutes have not been successful in ensuring MLTS compliance with these requirements. MESB Comments at 4-5.  MESB also requests federal intervention and enforcement for delivery of accurate caller location to the PSAP, which we address above in dispatchable location.  Id. at 4.
  BRETSA also suggests that the Commission propose a “forward-looking” location rule that would require all devices (e.g., all types of computers, tablets, and phones) used for voice, text, or video communications to incorporate GPS chipsets and other location technologies such as Wi-Fi, so that the devices are location-aware and are able to route 911 calls to the appropriate PSAP. BRETSA Reply at 19-20.
  RedSky suggests that the Commission should give telecommunications carriers the ability to transmit a 911 call through a third party such as an incumbent local exchange carrier, a VoIP Provisioning Center (VPC), its agent, or directly to an Emergency Services IP Network (ESINet) or its agent, rather than have to transmit a 911 call directly to a PSAP. RedSky Comments at 41; see Notice at 9031, Appendix A, proposed rule § 9.4.  RedSky also states that proposed rule § 9.5 contains obsolete language as it does not include the ability to deliver a 911 call to an ESINet or its agent.  RedSky also states that proposed rule § 9.11(a)(2)(iv), which would require Registered Location of interconnected VoIP callers to be available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority, does not take into account the existing use of a “steered ALI query” to a VPC.  RedSky states that proposed rule § 9.11(b)(5)(i), which would require interconnected VoIP and 911 VoIP service to advise every subscriber of the circumstances under which E911 service may not be available, should not exclude non-native telephone numbers.  RedSky Comments at 41-42.
  In a similar vein, Texas 9-1-1 Entities request that the Commission allow 911 calls to be routed through third-party call centers when dispatchable location, geographic coordinates, or registered location are not available. Texas 9-1-1 Entities Comments at 10.
  But MESB states that MLTS and VoIP 911 calls should not be allowed to routinely route to national call centers rather than the local serving PSAPs. MESB Comments at 7.
  BRETSA similarly states that Regional or national call centers are not a permissible alternative to proper configuration of an MLTS. BRETSA Reply at 10.
  
238. Commenters suggest several other miscellaneous rule changes.  Specifically, APCO suggests that the Commission should monitor consumers’ use of new technological platforms for communications, and that the Commission consider further expanding the scope of the 911 rules to take into account such platforms and prevent subtle technology distinctions from impacting communications with 911. APCO Comments at 7-8.
  Ad Hoc states that the Commission should modify section 9.11(b)(5)(iii), which requires interconnected VoIP service providers to distribute stickers or other appropriate labels warning subscribers if E911 service may be limited or not available, to “permit carriers to discharge their ‘notification/warning label’ obligations differently for enterprise customers.” Ad Hoc Comments at 17-18.
  BRETSA suggests an inquiry into 911 fees related to digital broadband facilities connected to an MLTS. BRETSA Comments at 6-7.
  RedSky suggests that the Commission should revisit consent decrees that an individual carrier or service provider may have entered into with the FCC or other body because such decrees “serve to un-level the playing field.” RedSky Comments at 41.
  Next, RedSky, BRETSA, and APCO suggest modifying several terms in section 9.3 definitions. RedSky suggests modifying the terms: “Designated PSAP” to “Wireless Designated PSAP;” “Emergency Call Center” to “Satellite Emergency Call Center;” and “Public Switched Network” to “Public Switched Telephone Network.”  Id. at 39-40.  BRETSA suggests modifying the term “911 calls” to “911 call.”  APCO suggests modifying the term “Public Safety Answering Point” or PSAP to “Emergency Communications Center.”  APCO Comments at 7.
  RedSky and BRETSA also suggest amendments to several definitions. RedSky suggests modifying the definitions of:  “Appropriate local emergency authority” to clarify whether this definition includes a campus security department that may or not be an accredited law enforcement agency; “Location-capable handsets” to include and define soft phones; “Pseudo Automatic Number Identification” to remove the North American Numbering Plan reference; and “Real-Time Text” to include the concept of end-to-end IP data connections.  RedSky Comments at 39-40.  BRETSA suggests modifying the definitions of:  “911 call” to include other dialing codes or addresses, besides 911, established for the purpose of accessing an emergency service provider; “Automatic Location Information” to specify that location could be identified by “geographic coordinates or civic address, in some contexts including location within the interior of a structure;” “Public Safety Answering Point or PSAP” to specify that 911 calls originate within a specific area or jurisdiction; “Real-Time Text” to specify that the text communications are session-based; and “Station” to add the sentence, “[i]n the context of MLTS, a station is a device connected to the MLTS through which calls can be placed and received.”  BRETSA Comments at 7-8.
  Additionally, RedSky notes that several 911-related terms are missing from the part 9 terms and definitions, and Texas 9-1-1 Entities proposes adding a term and definition. RedSky suggests the following terms are missing from the terms and definitions:  MLTS end point location technology, emergency line identification number (ELIN), emergency response location (ERL), voice over IP provisioning center (VPC).  RedSky Comments at 41.  Texas 9-1-1 Entities suggests adding “Calling Party.  The person making the 9-1-1 call.  In the context of MLTS, the MLTS is not the calling party, but rather the person making the 9-1-1 call is the calling party.”  Texas 9-1-1- Entities Comments at 10.
  Finally, RedSky suggests retitling some rule section headings. RedSky suggests retitling proposed rule § 9.10 from “911 Service” to “CMRS 911 Service” and proposed rule § 9.11 from “E911 Service” to “Interconnected Voice over IP 9-1-1 Services.”  RedSky Comments at 41.  We note that subparts within part 9 carry appropriate service headings.

239. While many of the suggestions described above may be worth pursuing separately, we decline to address them in this proceeding.  The Commission stated that aside from the new MLTS and dispatchable location rules and deleting obsolete rules, the rule revisions in this proceeding would simply entail consolidating our existing 911 rules without making substantive changes. Notice, 33 FCC Rcd at 9021, para. 106.
  Limited exceptions would include certain conforming and technical changes, such as harmonizing definitions of 911-related terms. Id.
  We find that the commenters’ suggestions go well beyond the scope of issues the Commission intended to address in this proceeding.  We retain the discretion to address elsewhere, and parties have the option to file petitions for rulemaking or raise such issues in other appropriate proceedings. We note that the Commission has an open docket on location-based routing for wireless 911 calls.  See Location-Based Routing for Wireless 911 Calls, PS Docket No. 18-64, Notice of Inquiry, 33 FCC Rcd 3238 (2018).
  
240. We do make ministerial conforming changes to certain other rules in light of our decision to consolidate the existing 911 rules into part 9.  First, we found that part 1 contains several references to section 20.18, which is being moved to part 9 as the new section 9.10. 47 CFR §§ 1.9020(d)(8), 1.9030(d)(8), 1.9035(d)(4), 1.9049(c).
  Accordingly, we update those references to section 9.10.  Next, we found that four rules have references to part 20 governing CMRS. 47 CFR §§ 24.2, 27.3, 80.3, 90.5.
  Since part 20 will no longer cover CMRS 911 obligations after the relocation of section 20.18 to section 9.10, we are adding a reference to part 9 to each of the four rules to clarify the location of CMRS 911 rules.  Since these changes are ministerial in nature and facilitate the part 9 rule consolidation, for which the Commission has already provided notice and allowed for comment, we find for good cause that notice and comment are unnecessary. See 5 U.S.C. § 553(b)(B).
  Finally, we harmonize the section 9.3 definition of “Registered Internet-based TRS user” to conform with the recently updated definition in part 64 of the Commission’s rules. In 2019, the Commission revised the section 64.601 definition of “Registered Internet-based TRS user” to add IP CTS.  The revised definition reads: “An individual who has registered with a VRS, IP Relay, or IP CTS provider as described in § 64.611.”  IP CTS Further Notice, 34 FCC Rcd at 720; 47 CFR § 64.601(a).
  Because the Commission’s proposed section 9.3 definition of “Registered Internet-based TRS user” is sourced from section 64.601(a), Notice, 33 FCC Rcd at 9076, Appendix C, Conversion Table A.
 and because the Commission changed the definition in section 64.601(a) in a proper rulemaking proceeding, IP CTS Further Notice, 34 FCC Rcd at 720.
 we find for good cause that notice and comment to adopt the same definition change for part 9 are unnecessary. 5 U.S.C. § 553(b)(B).

IV. PROCEDURAL MATTERS
241. Final Regulatory Flexibility Analysis.  As required by the Regulatory Flexibility Act of 1980, as amended (RFA), 5 U.S.C. § 601 et seq.
 the Commission has prepared a Final Regulatory Flexibility Analysis (FRFA) relating to this Report and Order.  The FRFA is set forth in Appendix C.
242. Paperwork Reduction Act Analysis.  The requirements in sections 9.8(a) and 9.16(b)(3)(i), (ii) and (iii) constitute new information collections subject to the Paperwork Reduction Act of 1995 (PRA), Pub. L. No. 104-13, 109 Stat 163 (1995) (codified at 44 U.S.C. §§ 3501-3520).
 and the requirements in sections 9.8(a); 9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4); 9.11(b)(5)(ii); (iii); 9.14(a)(2); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v); 9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); 9.16(b)(3)(i); (ii); and (iii) constitute modified information collections.  They will be submitted to the Office of Management and Budget (OMB) for review under section 3507(d) of the PRA. 44 U.S.C. § 3507(d).
  OMB, the general public, and other Federal agencies are invited to comment on the new information collection requirements contained in this proceeding. This document will be submitted to OMB for review under section 3507(d) of the PRA. In addition, we note that, pursuant to the Small Business Paperwork Relief Act of 2002, Pub. L. No. 107-198, 116 Stat. 729 (2002) (codified at 44 U.S.C. § 3506(c)(4)).
 we previously sought, but did not receive, specific comment on how the Commission might further reduce the information collection burden for small business concerns with fewer than 25 employees. We describe impacts that might affect small businesses, which includes more businesses with fewer than 25 employees, in the Final Regulatory Flexibility Analysis in Appendix C.
243. Congressional Review Act.  The Commission has determined that these rules are non-major under the Congressional Review Act, 5 U.S.C. § 804(2).  The Commission will send a copy of this Report and Order to Congress and the Government Accountability Office pursuant to 5 U.S.C. § 801(a)(1)(A).
244. Further Information.  For further information, contact Brenda Boykin, Attorney-Advisor, Policy and Licensing Division, Public Safety and Homeland Security Bureau, (202) 418-2062 or via e-mail at Brenda.Boykin@fcc.gov; William Beckwith, Attorney-Advisor, Policy and Licensing Division, Public Safety and Homeland Security Bureau, (202) 418-0134 or via e-mail at William.Beckwith@fcc.gov; Thomas Eng, Engineer, Policy and Licensing Division, Public Safety and Homeland Security Bureau, (202) 418-0019 or via e-mail at Thomas.Eng@fcc.gov; Dr. Rasoul Safavian, Technologist, Policy and Licensing Division, Public Safety and Homeland Security Bureau, (202) 418-0754 or via e-mail at Rasoul.Safavian@fcc.gov.
V. ORDERING CLAUSES
245. 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, Pub. L. No. 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), Pub. L. No. 115-141, 47 U.S.C. § 615 note, Section 106 of the Twenty-First Century Communications and Video Accessibility Act of 2010, Pub. L. No. 111-260, 47 U.S.C. § 615c, Section 101 of the New and Emerging Technologies 911 Improvement Act of 2008, Pub. L. No. 110-283, 47 U.S.C. § 615a-1, Middle Class Tax Relief and Job Creation Act of 2012, Pub. L. No. 112-96, 47 U.S.C. § 1471, and the Wireless Communications and Public Safety Act of 1999, Pub. L. No. 106-81, 47 U.S.C. §§ 615 note, 615, 615a, 615b, that this Report and Order is ADOPTED.
246. IT IS FURTHER ORDERED that the amendments of the Commission’s rules as set forth in Appendix A ARE ADOPTED, effective thirty days from the date of publication in the Federal Register. As mentioned supra, paras. 100, 150, 157-160, 172, 176, 182, 183, 206, 211, and 220, compliance with requirements that we adopt pursuant to Kari’s Law and the RAY BAUM’S Act will not, in any event, be required prior to February 16, 2020, or thereafter (depending on the requirement).  
  Sections 9.8(a); 9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4); 9.11(b)(5)(ii); (iii); 9.14(a)(2); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v); 9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); 9.16(b)(3)(i); (ii); and (iii), contain new or modified information collection requirements that require review by the OMB under the PRA.  The Commission directs the Public Safety and Homeland Security Bureau (Bureau) to announce the effective date of those information collections in a document published in the Federal Register after the Commission receives OMB approval, and directs the Bureau to cause sections 9.8(b); 9.10(s); 9.11(c); 9.14(f); 9.16(c), to be revised accordingly. 
247. IT IS FURTHER ORDERED that the Commission SHALL SEND a copy of the Report and Order in a report to be sent to Congress and the Government Accountability Office pursuant to the Congressional Review Act, 5 U.S.C. § 801(a)(1)(A).
248. IT IS FURTHER ORDERED that the Commission’s Consumer and Governmental Affairs Bureau, Reference Information Center, SHALL SEND a copy of the Report and Order, including the Final Regulatory Flexibility Analysis, to the Chief Counsel for Advocacy of the Small Business Administration.

						FEDERAL COMMUNICATIONS COMMISSION




						Marlene H. Dortch
						Secretary


99
	Federal Communications Commission	FCC 19-76

APPENDIX A

Final Rules

PART 1 – PRACTICE AND PROCEDURE
1. The authority citation for part 1 continues to read as follows:
Authority: 47 U.S.C. 151, 154(i), 154(j), 155, 157, 225, 227, 303(r), 309, 1403, 1404, 1451, and 1452.
2. Section 1.9020 is amended by revising paragraph (d)(8) to read as follows:
§1.9020   Spectrum manager leasing arrangements.
* * * * *
(d)(8) E911 requirements.  If E911 obligations apply to the licensee (see §9.10 of this chapter), the licensee retains the obligations with respect to leased spectrum.  However, if the spectrum lessee is a Contraband Interdiction System (CIS) provider, as defined in §1.9003, then the CIS provider is responsible for compliance with §9.10(r) regarding E911 transmission obligations.
* * * * *
3. Section 1.9030 is amended by revising paragraph (d)(8) to read as follows:
§1.9030   Long-term de facto transfer leasing arrangements.
* * * * *
(d)(8) E911 requirements.  To the extent the licensee is required to meet E911 obligations (see §9.10 of this chapter), the spectrum lessee is required to meet those obligations with respect to the spectrum leased under the spectrum leasing arrangement insofar as the spectrum lessee's operations are encompassed within the E911 obligations.  If the spectrum lessee is a Contraband Interdiction System (CIS) provider, as defined in §1.9003, then the CIS provider is responsible for compliance with §9.10(r) regarding E911 transmission obligations.
* * * * *
4. Section 1.9035 is amended by revising paragraph (d)(4) to read as follows:
§1.9035   Short-term de facto transfer leasing arrangements.
* * * * *
(d)(4) E911 requirements.  If E911 obligations apply to the licensee (see §9.10 of this chapter), the licensee retains the obligations with respect to leased spectrum.  A spectrum lessee entering into a short-term de facto transfer leasing arrangement is not separately required to comply with any such obligations in relation to the leased spectrum.  However, if the spectrum lessee is a Contraband Interdiction System (CIS) provider, as defined in §1.9003, then the CIS provider is responsible for compliance with §9.10(r) regarding E911 transmission obligations.
* * * * *
5. Section 1.9049 is amended by revising paragraph (c) to read as follows:
§1.9049   Special provisions relating to spectrum leasing arrangements involving the ancillary terrestrial component of Mobile Satellite Services.
* * * * *
(c) For purposes of §1.9020(d)(8), the Mobile Satellite Service licensee's obligation, if any, concerning the E911 requirements in §9.10 of this chapter, will, with respect to an ATC, be specified in the licensing document for the ATC.
* * * * *
PART 9 – INTERCONNECTED VOICE OVER INTERNET PROTOCOL SERVICES 
6. Part 9 is amended by revising it to read as follows: 
PART 9 -- 911 REQUIREMENTS
Contents
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 
§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
7. The authority for part 9 is revised to read as follows:
Authority: 47 U.S.C. 151-154, 152(a), 155(c), 157, 160, 201, 202, 208, 210, 214, 218, 219, 222, 225, 251(e), 255, 301, 302, 303, 307, 308, 309, 310, 316, 319, 332, 403, 405, 605, 610, 615, 615 note, 615a, 615b, 615c, 615a-1, 616, 620, 621, 623, 623 note, 721, and 1471, unless otherwise noted.
Subpart A – Purpose and Definitions
§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).
§9.2 [Reserved]
§9.3   Definitions
Terms with definitions including the “(RR)” designation are defined in the same way in §2.1 of this chapter and in the Radio Regulations of the International Telecommunication Union. 
911 calls.  Any call initiated by an end user by dialing 911 for the purpose of accessing an emergency service provider.  For wireless carriers, all 911 calls include those they are required to transmit pursuant to subpart C of this part.
Alternative Location Information.  Location information (which may be coordinate-based) sufficient to identify the caller’s civic address and approximate in-building location, including floor level, in large buildings.
Appropriate local emergency authority.  An emergency answering point that has not been officially designated as a Public Safety Answering Point (PSAP), but has the capability of receiving 911 calls and either dispatching emergency services personnel or, if necessary, relaying the call to another emergency service provider.  An appropriate local emergency authority may include, but is not limited to, an existing local law enforcement authority, such as the police, county sheriff, local emergency medical services provider, or fire department.
Automated Dispatchable Location.  Automatic generation of dispatchable location.   
Automatic Location Information (ALI).  Information transmitted while providing E911 service that permits emergency service providers to identify the geographic location of the calling party.
Automatic Number Identification (ANI).  For 911 systems, the Automatic Number Identification (ANI) identifies the calling party and may be used as the callback number.
Commercial mobile radio service (CMRS).  A mobile service that is:
(a)(1) provided for profit, i.e., with the intent of receiving compensation or monetary gain;
(2) An interconnected service; and
(3) Available to the public, or to such classes of eligible users as to be effectively available to a substantial portion of the public; or
(b) The functional equivalent of such a mobile service described in paragraph (a) of this definition.
(c) 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.
(d) Unlicensed radio frequency devices under part 15 of this chapter are excluded from this definition of Commercial mobile radio service.
Common carrier or carrier.  Any common carrier engaged in interstate Communication by wire or radio as defined in section 3(h) of the Communications Act of 1934, as amended (the Act), and any common carrier engaged in intrastate communication by wire or radio, notwithstanding sections 2(b) and 221(b) of the Act.  
Communications assistant (CA).  A person who transliterates or interprets conversation between two or more end users of TRS. 
Configured.  The settings or configurations for a particular MLTS installation have been implemented so that the MLTS is fully capable when installed of dialing 911 directly and providing MLTS notification as required under the statute and rules.  This does not preclude the inclusion of additional dialing patterns to reach 911.  However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern.
Designated PSAP.  The Public Safety Answering Point (PSAP) designated by the local or state entity that has the authority and responsibility to designate the PSAP to receive wireless 911 calls.
Dispatchable location.  A location delivered to the PSAP with a 911 call that consists of the validated street address of the calling party, plus additional information such as suite, apartment or similar information necessary to adequately identify the location of the calling party, except for Commercial Mobile Radio Service providers, which shall convey the location information required by subpart C of this part.  
Earth station.  A station located either on the Earth’s surface or within the major portion of the Earth’s atmosphere intended for communication:
(1) With one or more space stations; or
(2) With one or more stations of the same kind by means of one or more reflecting satellites or other objects in space.  (RR)
Emergency Call Center.  A facility that subscribers of satellite commercial mobile radio services call when in need of emergency assistance by dialing “911” on their mobile earth station terminals.
Feeder link.  A radio link from a fixed earth station at a given location to a space station, or vice versa, conveying information for a space radiocommunication service other than the Fixed-Satellite Service. The given location may be at a specified fixed point or at any fixed point within specified areas.  (RR)
Fixed-Satellite Service (FSS).  A radiocommunication service between earth stations at given positions, when one or more satellites are used; the given position may be a specified fixed point or any fixed point within specified areas; in some cases this service includes satellite-to-satellite links, which may also be operated in the inter-satellite service; the Fixed-Satellite Service may also include feeder links of other space radiocommunication services.  (RR)
Handset-based location technology.  A method of providing the location of wireless 911 callers that requires the use of special location-determining hardware and/or software in a portable or mobile phone.  Handset-based location technology may also employ additional location-determining hardware and/or software in the CMRS network and/or another fixed infrastructure.
iTRS access technology.  Any equipment, software, or other technology issued, leased, or provided by an Internet-based TRS provider that can be used to make and receive an Internet-based TRS call.
Improvement to the hardware or software of the system.  An improvement to the hardware or software of the MLTS, including upgrades to the core systems of the MLTS, as well as substantial upgrades to the software and any software upgrades requiring a significant purchase.
Interconnected VoIP service. 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.
Notwithstanding the foregoing, solely for purposes of compliance with the Commission’s 911 obligations, an interconnected VoIP service includes a service that fulfills each of subsections (1)-(3) above and permits users generally to terminate calls to the public switched telephone network.
Internet-based TRS (iTRS).  A telecommunications relay service (TRS) in which an individual with a hearing or a speech disability connects to a TRS communications assistant using an Internet Protocol-enabled device via the Internet, rather than the public switched telephone network.  Except as authorized or required by the Commission, Internet-based TRS does not include the use of a text telephone (TTY) or RTT over an interconnected voice over Internet Protocol service.
Internet Protocol Captioned Telephone Service (IP CTS).  A telecommunications relay service that permits an individual who can speak but who has difficulty hearing over the telephone to use a telephone and an Internet Protocol-enabled device via the Internet to simultaneously listen to the other party and read captions of what the other party is saying.  With IP CTS, the connection carrying the captions between the relay service provider and the relay service user is via the Internet, rather than the public switched telephone network.
Internet Protocol Relay Service (IP Relay).  A telecommunications relay service that permits an individual with a hearing or a speech disability to communicate in text using an Internet Protocol-enabled device via the Internet, rather than using a text telephone (TTY) and the public switched telephone network.
Location-capable handsets.  Portable or mobile phones that contain special location-determining hardware and/or software, which is used by a licensee to locate 911 calls.
MLTS Notification.  An MLTS feature that can send notice to a central location at the facility where the system is installed or to another person or organization regardless of location.  Examples of notification include conspicuous on-screen messages with audible alarms for security desk computers using a client application, text messages for smartphones, and email for administrators.  Notification shall include, at a minimum, the following information:  (1) the fact that a 911 call has been made, (2) a valid callback number, and (3) the information about the caller’s location that the MLTS conveys to the public safety answering point (PSAP) with the call to 911; provided, however, that the notification does not have to include a callback number or location information if it is technically infeasible to provide this information.
Mobile Earth Station.  An earth station in the Mobile-Satellite Service intended to be used while in motion or during halts at unspecified points.  (RR)
Mobile-Satellite Service (MSS).  (1) A radiocommunication service:
(i) Between mobile earth stations and one or more space stations, or between space stations used by this service; or
(ii) Between mobile earth stations, by means of one or more space stations.
(2) This service may also include feeder links necessary for its operation.  (RR)
Mobile Service.  A radio communication service carried on between mobile stations or receivers and land stations, and by mobile stations communicating among themselves, and includes:
(a) Both one-way and two-way radio communications services;
(b) 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
(c) Any service for which a license is required in a personal communications service under part 24 of this chapter.
Network-based Location Technology.  A method of providing the location of wireless 911 callers that employs hardware and/or software in the CMRS network and/or another fixed infrastructure, and does not require the use of special location-determining hardware and/or software in the caller’s portable or mobile phone.
Multi-line telephone system or MLTS.  A system comprised of common control units, telephone sets, control hardware and software and adjunct systems, including network and premises based systems, such as Centrex and VoIP, as well as PBX, Hybrid, and Key Telephone Systems (as classified by the Commission under part 68 of title 47, Code of Federal Regulations), and includes systems owned or leased by governmental agencies and non-profit entities, as well as for profit businesses. 
Non-English language relay service.  A telecommunications relay service that allows persons with hearing or speech disabilities who use languages other than English to communicate with voice telephone users in a shared language other than English, through a CA who is fluent in that language.
On-premises.  In the context of a multi-line telephone system, within the fixed property (e.g. building(s), facilities, or campus) and under the operational control of a single administrative authority.
Person engaged in the business of installing an MLTS.  A person that configures the MLTS or performs other tasks involved in getting the system ready to operate.  These tasks may include, but are not limited to, establishing the dialing pattern for emergency calls, determining how calls will route to the Public Switched Telephone Network (PSTN), and determining where the MLTS will interface with the PSTN.  These tasks are performed when the system is initially installed, but they may also be performed on a more or less regular basis by the MLTS operator as the communications needs of the enterprise change.  The MLTS installer may be the MLTS manager or a third party acting on behalf of the manager.
Person engaged in the business of managing an MLTS.  The entity that is responsible for controlling and overseeing implementation of the MLTS after installation.  These responsibilities include determining how lines should be distributed (including the adding or moving of lines), assigning and reassigning telephone numbers, and ongoing network configuration. 
Person engaged in the business of manufacturing, importing, selling, or leasing an MLTS.  A person that manufactures, imports, sells, or leases an MLTS.
Person engaged in the business of operating an MLTS.  A person responsible for the day-to-day operations of the MLTS.
Pre-configured.  An MLTS that comes equipped with hardware and/or software capable of establishing a setting that enables users to directly dial 911 as soon as the system is able to initiate calls to the public switched telephone network, so long as the MLTS is installed and operated properly.  This does not preclude the inclusion of additional dialing patterns to reach 911.  However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern.  
Private Mobile Radio Service.  A mobile service that meets neither the paragraph (a) nor paragraph (b) definitions of commercial mobile radio service set forth in this section. A mobile service that does not meet the paragraph (a) 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:
(a) Not-for-profit land mobile radio and paging services that serve the licensee’s internal communications needs as defined in part 90 of this chapter.  Shared-use, cost-sharing, or cooperative arrangements, multiple licensed systems that use third party managers or users combining resources to meet compatible needs for specialized internal communications facilities in compliance with the safeguards of §90.179 of this chapter are presumptively private mobile radio services;
(b) Mobile radio service offered to restricted classes of eligible users.  This includes entities eligible in the Public Safety Radio Pool and Radiolocation service.
(c) 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
(d) Personal Radio Services under part 95 of this chapter (General Mobile Services, Radio Control Radio Services, and Citizens Band Radio Services); Maritime Service Stations (excluding Public Coast stations) (part 80 of this chapter); and Aviation Service Stations (part 87 of this chapter).
Pseudo Automatic Number Identification (Pseudo-ANI).  A number, consisting of the same number of digits as ANI, that is not a North American Numbering Plan telephone directory number and may be used in place of an ANI to convey special meaning.  The special meaning assigned to the pseudo-ANI is determined by agreements, as necessary, between the system originating the call, intermediate systems handling and routing the call, and the destination system.
Public safety answering point or PSAP.  An answering point that has been designated to receive 911 calls and route them to emergency services personnel.
Public Switched Network.  Any common carrier switched network, whether by wire or radio, including local exchange carriers, interexchange carriers, and mobile service providers, that uses the North American Numbering Plan in connection with the provision of switched services.
Real-Time Text (RTT).  Text communications that are transmitted over Internet Protocol (IP) networks immediately as they are created, e.g., on a character-by-character basis. 
Registered Internet-based TRS user.  An individual that has registered with a VRS, IP Relay, or IP CTS provider as described in §64.611.
Registered Location.  The most recent information obtained by a provider of interconnected VoIP service or telecommunications relay services (TRS), as applicable, that identifies the physical location of an end user.  
Space station.  A station located on an object which is beyond, is intended to go beyond, or has been beyond, the major portion of the Earth’s atmosphere.  (RR)
Speech-to-speech relay service (STS).  A telecommunications relay service that allows individuals with speech disabilities to communicate with voice telephone users through the use of specially trained CAs who understand the speech patterns of persons with speech disabilities and can repeat the words spoken by that person. 
Statewide default answering point.  An emergency answering point designated by the State to receive 911 calls for either the entire State or those portions of the State not otherwise served by a local PSAP.
Station.  A station equipped to engage in radio communication or radio transmission of energy (47 U.S.C. 153(k)).
Telecommunications relay services (TRS).  Telephone transmission services that provide the ability for an individual who has a hearing or speech disability to engage in communication by wire or radio with a hearing individual in a manner that is functionally equivalent to the ability of an individual who does not have a hearing or speech disability to communicate using voice communication services by wire or radio.  Such term includes services that enable two-way communication between an individual who uses a text telephone or other nonvoice terminal device and an individual who does not use such a device, speech-to-speech services, video relay services and non-English relay services.  TRS supersedes the terms “dual party relay system,” “message relay services,” and “TDD Relay.”
Text telephone (TTY).  A machine that employs graphic communication in the transmission of coded signals through a wire or radio communication system.  TTY supersedes the term “TDD” or “telecommunications device for the deaf,” and TT.
Video relay service (VRS).  A telecommunications relay service that allows people with hearing or speech disabilities who use sign language to communicate with voice telephone users through video equipment.  The video link allows the CA to view and interpret the party’s signed conversation and relay the conversation back and forth with a voice caller.
Wireline E911 Network.  A dedicated wireline network that: (1) Is interconnected with but largely separate from the public switched telephone network; (2) Includes a selective router; and (3) Is used to route emergency calls and related information to PSAPs, designated statewide default answering points, appropriate local emergency authorities or other emergency answering points.
Subpart B – Telecommunications Carriers
§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 §9.5.
§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.
§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.
§9.7   Obligation for providing an intercept message.
Upon termination of permissive dialing, as provided under §9.6, telecommunications carriers shall provide a standard intercept message announcement that interrupts calls placed to the emergency service provider using either a seven-or ten-digit emergency number or an abbreviated dialing code other than 911 and informs the caller of the dialing code change.
§9.8   Obligation of Fixed Telephony Providers to convey dispatchable location.
(a) Providers of fixed telephony services shall provide automated dispatchable location with 911 calls beginning [one year after the effective date of this rule].
(b) Compliance date.  Paragraph (a) of this section contains information-collection and recordkeeping requirements.  Compliance will not be required until after approval by the Office of Management and Budget.  The Commission will publish a document in the Federal Register announcing that compliance date and revising this paragraph accordingly.
Subpart C – Commercial Mobile Radio Service
§9.9   Definitions.
Interconnection or Interconnected.  Direct or indirect connection through automatic or manual means (by wire, microwave, or other technologies such as store and forward) to permit the transmission or reception of messages or signals to or from points in the public switched network.
Interconnected Service.  A service: (a) 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 (b) 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. 
§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 §9.4, provided that “all wireless 911 calls” is defined as “any call initiated by a wireless user dialing 911 on a phone using a compliant radio frequency protocol of the serving carrier.”
(c) Access to 911 services.  CMRS providers subject to this section must be capable of transmitting 911 calls from individuals with speech or hearing disabilities through means other than mobile radio handsets, e.g., through the use of Text Telephone Devices (TTY). CMRS providers that provide voice communications over IP facilities are not required to support 911 access via TTYs if they provide 911 access via real-time text (RTT) communications, in accordance with 47 CFR part 67, except that RTT support is not required to the extent that it is not achievable for a particular manufacturer to support RTT on the provider’s network.
(d) Phase I enhanced 911 services.  (1) As of April 1, 1998, or within six months of a request by the designated Public Safety Answering Point as set forth in paragraph (j) of this section, whichever is later, licensees subject to this section must provide the telephone number of the originator of a 911 call and the location of the cell site or base station receiving a 911 call from any mobile handset accessing their systems to the designated Public Safety Answering Point through the use of ANI and Pseudo-ANI.
(2) When the directory number of the handset used to originate a 911 call is not available to the serving carrier, such carrier’s obligations under the paragraph (d)(1) of this section extend only to delivering 911 calls and available call party information, including that prescribed in paragraph (l) of this section, to the designated Public Safety Answering Point.
Note to paragraph (d): With respect to 911 calls accessing their systems through the use of TTYs, licensees subject to this section must comply with the requirements in paragraphs (d)(1) and (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:
(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 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 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 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 §1.47 of this chapter.  The PSAP may challenge in writing the accuracy of the carrier’s certification and shall serve a copy of such challenge on the carrier.  See §§1.45 and 1.47 and §§1.720 through 1.740 of this chapter.
(viii) If a wireless carrier’s certification is facially inadequate, the six-month implementation period specified in paragraphs (d), (f) and (g) of this section will not be suspended as provided for in paragraph (m)(4) of this section.
(ix) If a wireless carrier’s certification is inaccurate, the wireless carrier will be liable for noncompliance as if the certification had not been filed.
(x) A carrier that files a certification under paragraph (m)(4) of this section 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.
(7) Notwithstanding any other provisions in this section, when a consumer is roaming on a covered text provider’s host network pursuant to §20.12, the covered text provider operating the consumer’s home network shall have the obligation to originate an automatic bounce-back message to such consumer when the consumer is located in an area where text-to-911 service is unavailable, or the home provider does not support text-to-911 service in that area at the time.  The host provider shall not impede the consumer’s 911 text message to the home provider and/or any automatic bounce-back message originated by the home provider to the consumer roaming on the host network.
(8) A software application provider that transmits text messages directly into the SMS network of the consumer’s underlying CMRS provider satisfies the obligations of paragraph (q)(3) of this section provided it does not prevent or inhibit delivery of the CMRS provider’s automatic bounce-back message to the consumer.
(9) 911 text message.  A 911 text message is a message, consisting of text characters, sent to the short code “911” and intended to be delivered to a PSAP by a covered text provider, regardless of the text messaging platform used.
(10) Delivery of 911 text messages.  (i) No later than December 31, 2014, all covered text providers must have the capability to route a 911 text message to a PSAP.  In complying with this requirement, covered text providers must obtain location information sufficient to route text messages to the same PSAP to which a 911 voice call would be routed, unless the responsible local or state entity designates a different PSAP to receive 911 text messages and informs the covered text provider of that change. All covered text providers using device-based location information that requires consumer activation must clearly inform consumers that they must grant permission for the text messaging application to access the wireless device’s location information in order to enable text-to-911.  If a consumer does not permit this access, the covered text provider’s text application must provide an automated bounce-back message as set forth in paragraph (q)(3) of this section.  (ii) Covered text providers must begin routing all 911 text messages to a PSAP by June 30, 2015, or within six months of the PSAP’s valid request for text-to-911 service, whichever is later, unless an alternate timeframe is agreed to by both the PSAP and the covered text provider.  The covered text provider must notify the Commission of the dates and terms of the alternate timeframe within 30 days of the parties’ agreement.
(iii) Valid Request means that:
(A) The requesting PSAP is, and certifies that it is, technically ready to receive 911 text messages in the format requested;
(B) The appropriate local or state 911 service governing authority has specifically authorized the PSAP to accept and, by extension, the covered text provider to provide, text-to-911 service; and
(C) The requesting PSAP has provided notification to the covered text provider that it meets the foregoing requirements.  Registration by the PSAP in a database made available by the Commission in accordance with requirements established in connection therewith, or any other written notification reasonably acceptable to the covered text provider, shall constitute sufficient notification for purposes of this paragraph.
(iv) The requirements set forth in paragraphs (q)(10)(i) through (iii) of this section do not apply to in-flight text messaging providers, MSS providers, or IP Relay service providers, or to 911 text messages that originate from Wi-Fi only locations or that are transmitted from devices that cannot access the CMRS network.
(v) No later than [two years after the effective date of this rule], covered text providers must  provide the following location information with all 911 text messages routed to a PSAP automated dispatchable location, if technically feasible; otherwise, either end-user manual provision of location information, or enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost. 
(11) Access to SMS networks for 911 text messages.  To the extent that CMRS providers offer Short Message Service (SMS), they shall allow access by any other covered text provider to the capabilities necessary for transmission of 911 text messages originating on such other covered text providers’ application services.  Covered text providers using the CMRS network to deliver 911 text messages must clearly inform consumers that, absent an SMS plan with the consumer’s underlying CMRS provider, the covered text provider may be unable to deliver 911 text messages.  CMRS providers may migrate to other technologies and need not retain SMS networks solely for other covered text providers’ 911 use, but must notify the affected covered text providers not less than 90 days before the migration is to occur.
(r) Contraband Interdiction System (CIS) requirement.  CIS providers regulated as private mobile radio service (see §9.3) must transmit all wireless 911 calls without respect to their call validation process to a Public Safety Answering Point, or, where no Public Safety Answering Point has been designated, to a designated statewide default answering point or appropriate local emergency authority pursuant to §9.4, provided that “all wireless 911 calls” is defined as “any call initiated by a wireless user dialing 911 on a phone using a compliant radio frequency protocol of the serving carrier.”  This requirement shall not apply if the Public Safety Answering Point or emergency authority informs the CIS provider that it does not wish to receive 911 calls from the CIS provider.
(s) Compliance date.  Paragraph (q)(10)(v) of this section contains information-collection and recordkeeping requirements.  Compliance will not be required until after approval by the Office of Management and Budget.  The Commission will publish a document in the Federal Register announcing that compliance date and revising this paragraph accordingly.
Subpart D – Interconnected Voice over Internet Protocol Services 
§ 9.11   E911 Service.
(a) Before [one year after the effective date of this rule] for fixed services and before [two years after the effective date of this rule] for non-fixed services.
(1) Scope.  The following requirements are only applicable to providers of interconnected VoIP services, except those interconnected VoIP services that fulfill each subsections (1)-(3) of the definition of interconnected VoIP service in §9.3, and also permit users generally to terminate calls to the public switched telephone network.  Further, the following requirements apply only to 911 calls placed by users whose Registered Location is in a geographic area served by a Wireline E911 Network (which, as defined in §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 §9.4, provided that “all 911 calls” is defined as “any voice communication initiated by an interconnected VoIP user dialing 911;”
(iii) All 911 calls must be routed through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network; and
(iv) The Registered Location must be available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.
(3) Service Level Obligation.  Notwithstanding the provisions in paragraph (a)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, an interconnected VoIP service provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (a)(2)(iii) of this section of an interconnected VoIP service provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller’s Registered Location and that has been designated for telecommunications carriers pursuant to §9.4.
(4) Registered Location Requirement.  As of November 28, 2005, interconnected VoIP service providers must:
(i) Obtain from each customer, prior to the initiation of service, the physical location at which the service will first be used; and
(ii) Provide their end users one or more methods of updating their Registered Location, including at least one option that requires use only of the CPE necessary to access the interconnected VoIP service.  Any method used must allow an end user to update the Registered Location at will and in a timely manner.
(5) Customer Notification.  Each interconnected VoIP service provider shall:
(i) Specifically advise every subscriber, both new and existing, prominently and in plain language, of the circumstances under which E911 service may not be available through the interconnected VoIP service or may be in some way limited by comparison to traditional E911 service.  Such circumstances include, but are not limited to, relocation of the end user’s IP-compatible CPE, use by the end user of a non-native telephone number, broadband connection failure, loss of electrical power, and delays that may occur in making a Registered Location available in or through the ALI database;
(ii) Obtain and keep a record of affirmative acknowledgement by every subscriber, both new and existing, of having received and understood the advisory described in paragraph (a)(5)(i) of this section; and
(iii) Either (A) distribute to its existing subscribers, and to each new subscriber prior to the initiation of that subscriber’s service, warning stickers or other appropriate labels warning subscribers if E911 service may be limited or not available and instructing the subscriber to place them on or near the equipment used in conjunction with the interconnected VoIP service; or (B) notify existing subscribers, and each new subscriber prior to the initiation of that subscriber’s service, by other conspicuous means if E911 service may be limited or not available.
(b) On or after [one year after the effective date of this rule] for fixed services, and on or after [two years after the effective date of this rule] for non-fixed services.  
(1) Scope.  The following requirements are only applicable to all providers of interconnected 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 §9.3, includes a selective router).
(2) E911 Service. 
(i) Interconnected VoIP service providers must, as a condition of providing service to a consumer, provide that consumer with E911 service as described in this section;
(ii) Interconnected VoIP service providers must transmit the following to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller’s dispatchable location and that has been designated for telecommunications carriers pursuant to §9.4: 
(A) All 911 calls, provided that “all 911 calls” is defined as “any voice communication initiated by an interconnected VoIP user dialing 911;”
(B) ANI; and
(C) The location information described in paragraph (b)(4) of this section.
(iii) All 911 calls must be routed through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network, provided that nothing in this subparagraph shall preclude routing the call first to a national emergency call center to ascertain the caller’s location in the event that the interconnected VoIP service provider is unable to obtain or confirm the caller’s location information; and
(iv) The location information described in paragraph (b)(4) of this section must be available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.
(3) Service Level Obligation.  Notwithstanding the provisions in paragraph (b)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, an interconnected VoIP service provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (b)(2)(iii) of this section of an interconnected VoIP service provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller’s dispatchable location and that has been designated for telecommunications carriers pursuant to §9.4.
(4) Location Requirements.  To meet E911 service requirements, interconnected VoIP service providers must provide location information with each 911 call as follows:
(i) Fixed interconnected VoIP services.  Providers of fixed interconnected VoIP services must provide automated dispatchable location with each 911 call. 
(ii) Non-fixed interconnected VoIP services.  For non-fixed interconnected VoIP service (service that is capable of being used from more than one location), interconnected VoIP service providers must provide location information in accordance with subparagraph (A) below, if technically feasible.  Otherwise, interconnected VoIP service providers must either provide location information in accordance with subparagraph (B) or (C), or meet subparagraph (D) below.  
(A) Provide automated dispatchable location, if technically feasible.  
(B) Provide Registered Location information that meets the following requirements: 
(1) The service provider has obtained from the customer, prior to the initiation of service, the Registered Location (as defined in §9.3) at which the service will first be used; 
(2) The service provider has provided end users one or more methods of updating their Registered Location, including at least one option that requires use only of the CPE necessary to access the interconnected VoIP service.  Any method used must allow an end user to update the Registered Location at will and in a timely manner; and
(3) The service provider must identify whether the service is being used to call 911 from a different location than the Registered Location, and if so, either: 
(i) prompt the customer to provide a new Registered Location; or
(ii) update the Registered Location without requiring additional action by the customer.
(C) Provide Alternative Location Information as defined in §9.3. 
(D) Route the caller to a national emergency call center.
(5) Customer Notification.
(i) Each interconnected VoIP service provider shall specifically advise every subscriber, both new and existing, prominently and in plain language, of the circumstances under which E911 service may not be available through the interconnected VoIP service or may be in some way limited by comparison to traditional E911 service.  Such circumstances include, but are not limited to, relocation of the end user’s IP-compatible CPE, use by the end user of a non-native telephone number, broadband connection failure, loss of electrical power, and delays that may occur in making a dispatchable location available in or through the ALI database;
(ii) Each interconnected VoIP service provider shall obtain and keep a record of affirmative acknowledgement by every subscriber, both new and existing, of having received and understood the advisory described in paragraph (b)(5)(i) of this section; and
(iii) Each interconnected VoIP service provider shall either: (A) distribute to its existing subscribers, and to each new subscriber prior to the initiation of that subscriber’s service, warning stickers or labels warning subscribers if E911 service may be limited or not available, and instructing the subscriber to place them on or near the equipment used in conjunction with the interconnected VoIP service; or (B) notify existing subscribers, and each new subscriber prior to the initiation of that subscriber’s service, by other conspicuous means if E911 service may be limited or not available.
(c) Compliance date.  Paragraphs (b)(2)(ii); (b)(2)(iv); (b)(4); (b)(5)(ii); (b)(5)(iii) of this section contain information-collection and recordkeeping requirements.  Compliance will not be required until after approval by the Office of Management and Budget.  The Commission will publish a document in the Federal Register announcing that compliance date and revising this paragraph accordingly.
§9.12   Access to 911 and E911 service capabilities.
(a) Access.  Subject to the other requirements of this part, an owner or controller of a capability that can be used for 911 or E911 service shall make that capability available to a requesting interconnected VoIP provider as set forth in paragraphs (a)(1) and (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.  An owner or controller makes a capability available to a CMRS provider if the owner or controller offers that capability to any CMRS provider.
(2) If the owner or controller does not make the requested capability available to a CMRS provider within the meaning of paragraph (a)(1) of this section, the owner or controller must make that capability available to a requesting interconnected VoIP provider only if that capability is necessary to enable the interconnected VoIP provider to provide 911 or E911 service in compliance with the Commission’s rules.
(b) Rates, terms, and conditions.  The rates, terms, and conditions on which a capability is provided to an interconnected VoIP provider under paragraph (a) of this section shall be reasonable. For purposes of this paragraph, it is evidence that rates, terms, and conditions are reasonable if they are:
(1) The same as the rates, terms, and conditions that are made available to CMRS providers, or
(2) In the event such capability is not made available to CMRS providers, the same rates, terms, and conditions that are made available to any telecommunications carrier or other entity for the provision of 911 or E911 service.
(c) Permissible use.  An interconnected VoIP provider that obtains access to a capability pursuant to this section may use that capability only for the purpose of providing 911 or E911 service in accordance with the Commission’s rules.
Subpart E – Telecommunications Relay Services for Persons With Disabilities
§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 §9.3.
§9.14   Emergency calling requirements.
(a) Emergency call handling requirements for TTY-based TRS providers.  TTY-based TRS providers must use a system for incoming emergency calls that, at a minimum, automatically and immediately transfers the caller to an appropriate Public Safety Answering Point (PSAP).  An appropriate PSAP is either a PSAP that the caller would have reached if the caller had dialed 911 directly, or a PSAP that is capable of enabling the dispatch of emergency services to the caller in an expeditious manner.
(b) Additional emergency calling requirements applicable to Internet-based TRS providers.  
(1) The requirements of paragraphs (b)(2)(i) and (b)(2)(iv) of this section shall not apply to providers of VRS and IP Relay to which §§9.14(c) and 9.14(d) apply.
(2) Each provider of Internet-based TRS shall:
(i) When responsible for placing or routing voice calls to the public switched telephone network, accept and handle emergency calls and access, either directly or via a third party, a commercially available database that will allow the provider to determine an appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority that corresponds to the caller’s location, and to relay the call to that entity;
(ii) Implement a system that ensures that the provider answers an incoming emergency call before other non-emergency calls (i.e., prioritize emergency calls and move them to the top of the queue);
(iii) Provide 911 and E911 service in accordance with paragraphs (c)-(e) of this section, as applicable;
(iv) Deliver to the PSAP, designated statewide default answering point, or appropriate local emergency authority, at the outset of the outbound leg of an emergency call, at a minimum, the name of the relay user and location of the emergency, as well as the name of the relay provider, the CA’s callback number, and the CA’s identification number, thereby enabling the PSAP, designated statewide default answering point, or appropriate local emergency authority to re-establish contact with the CA in the event the call is disconnected;
(v) In the event one or both legs of an emergency call are disconnected (i.e., either the call between the TRS user and the CA, or the outbound voice telephone call between the CA and the PSAP, designated statewide default answering point, or appropriate local emergency authority), immediately re-establish contact with the TRS user and/or the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority and resume handling the call; and
(vi) Ensure that information obtained as a result of this section is limited to that needed to facilitate 911 services, is made available only to emergency call handlers and emergency response or law enforcement personnel, and is used for the sole purpose of ascertaining a user’s location in an emergency situation or for other emergency or law enforcement purposes.
(c) E911 Service for VRS and IP Relay before [one year after the effective date of this rule] for fixed services, and before [two years after the effective date of this rule] for non-fixed services.
(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.  VRS or IP Relay providers must, as a condition of providing service to a user:
(i) Provide that user with E911 service as described in this section;
(ii) Request, at the beginning of each emergency call, the caller’s name and location information, unless the VRS or IP Relay provider already has, or has access to, Registered Location information for the caller;
(iii) Transmit all 911 calls, as well as ANI, the caller’s Registered Location, the name of the VRS or IP Relay provider, and the CA’s identification number for each call, to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller’s Registered Location and that has been designated for telecommunications carriers pursuant to §9.4, provided that “all 911 calls” is defined as “any communication initiated by an VRS or IP Relay user dialing 911”;
(iv) Route all 911 calls through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network, provided that nothing in this subparagraph shall preclude routing the call first to a call center to ascertain the caller’s location in the event that the VRS or IP Relay provider believes the caller may not be located at the Registered Location; and
(v) Make the Registered Location, the name of the VRS or IP Relay provider, and the CA’s identification number available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.
(3) Service level obligation.  Notwithstanding the provisions in paragraph (c)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, a VRS or IP Relay provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (c)(2)(iv) of this section of a VRS or IP Relay provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller’s Registered Location and that has been designated for telecommunications carriers pursuant to §9.4.
(4) Registered location requirement.  VRS and IP Relay providers must:
(i) Obtain from each Registered Internet-based TRS user, prior to the initiation of service, the physical location at which the service will first be used; and
(ii) If the VRS or IP Relay is capable of being used from more than one location, provide their registered Internet-based TRS users one or more methods of updating the user’s Registered Location, including at least one option that requires use only of the iTRS access technology necessary to access the VRS or IP Relay.  Any method used must allow a registered Internet-based TRS user to update the Registered Location at will and in a timely manner.
(d) E911 Service for VRS and IP Relay on or after [one year after the effective date of this rule] for fixed services, and on or after [two years after the effective date of this rule] for non-fixed services.
(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.  VRS or IP Relay providers must, as a condition of providing service to a user:
(i) Provide that user with E911 service as described in this section;
(ii) Request, at the beginning of each emergency call, the caller’s name and dispatchable location, unless the VRS or IP relay provider already has, or has access to the location information described in paragraph (d)(4) of this section;
(iii) Transmit the following to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller’s dispatchable location and that has been designated for telecommunications carriers pursuant to §9.4:
(A) All 911 calls, provided that “all 911 calls” is defined as “any communication initiated by an VRS or IP Relay user dialing 911;”
(B) ANI, the name of the VRS or IP Relay provider, and the CA’s identification number for each call; and
(C) The location information described in paragraph (d)(4) of this section.
(iv) Route all 911 calls through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network, provided that nothing in this subparagraph shall preclude routing the call first to a call center to ascertain the caller’s location in the event that the VRS or IP Relay provider is unable to obtain or confirm the caller’s location information; and
(v) Make the location information described in paragraph (d)(4) of this section, the name of the VRS or IP Relay provider, and the CA’s identification number available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.
(3) Service level obligation.  Notwithstanding the provisions in paragraph (d)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, a VRS or IP Relay provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (d)(2)(iv) of this section of a VRS or IP Relay provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller’s dispatchable location and that has been designated for telecommunications carriers pursuant to §9.4.
(4) Location Requirements.  To meet E911 service requirements, VRS and IP Relay providers must provide location information with each 911 call as follows:
(i) Fixed VRS and IP Relay services.  Providers of fixed VRS and IP Relay services must provide automated dispatchable location with each 911 call.
(ii) Non-fixed VRS and IP Relay services.  For non-fixed VRS and IP Relay services (service that is capable of being used from more than one location), VRS and IP Relay service providers must provide location information in accordance with subparagraph (A) below, if technically feasible.  Otherwise, VRS and IP Relay service providers must either provide location information in accordance with subparagraph (B) or (C), or meet subparagraph (D) below.  
(A) Provide automated dispatchable location, if technically feasible.  
(B) Provide Registered Location information that meets the following requirements: 
(1) The service provider has obtained from the customer, prior to the initiation of service, the Registered Location (as defined in §9.3) at which the service will first be used; 
(2) The service provider has provided end users one or more methods of updating their Registered Location, including at least one option that requires use only of the Internet-based TRS access technology necessary to access the VRS or IP Relay.  Any method used must allow an end user to update the Registered Location at will and in a timely manner; and
(3) If the VRS or IP Relay is capable of being used from more than one location, if it is not possible to automatically determine the Registered Internet-based TRS user’s location at the time of the initiation of an emergency call, verify the current location with the user at the beginning of an emergency call.
(C) Provide Alternative Location Information as defined in §9.3.
(D) Route the caller to a call center. 
(e) E911 Service for IP CTS on or after [one year after the effective date of this rule] for fixed services, and on or after [two years after the effective date of this rule] for non-fixed services.
(1) Scope.  The following requirements are only applicable to “covered IP CTS providers,” who are providers of IP CTS to the extent that the IP CTS provider, itself or through an entity with whom the IP CTS provider contracts, places or routes voice calls to the public switched telephone network.  Further, the following requirements apply only to 911 calls placed by a registered user whose dispatchable location is in a geographic area served by a Wireline E911 Network and is available to the provider handling the call. 
(2) E911 Service.  Covered IP CTS providers must, as a condition of providing service to a user:
(i) Provide that user with E911 service as described in this section; 
(ii) Transmit or provide the following to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller’s dispatchable location and that has been designated for telecommunications carriers pursuant to §9.4:
(A) All 911 calls, provided that “all 911 calls” is defined as “any communication initiated by an IP CTS user dialing 911;”
(B) With the call, a telephone number that is assigned to the caller and that enables the PSAP, designated statewide default answering point, or appropriate local emergency authority to call the 911 caller back directly, while enabling the caller to receive captions on the callback; and 
(C) The location information described in paragraph (e)(4) of this section.  
(iii) Route all 911 calls through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network, provided that nothing in this subparagraph shall preclude routing the call first to a call center to ascertain the caller’s location in the event that the covered IP CTS provider is unable to obtain or confirm the caller’s location information; and 
(iv) Make the location information described in paragraph (e)(4) of this section and callback number available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database. 
(3) Service level obligation.  Notwithstanding the provisions in paragraph (e)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, a covered IP CTS provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (e)(2)(iii) of this section of a covered IP CTS provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller’s dispatchable location and that has been designated for telecommunications carriers pursuant to §9.4. 
(4) Location Requirements.  To meet E911 service requirements, covered IP CTS providers must provide location information with each 911 call as follows:
(i) Fixed IP CTS.  Providers of fixed IP CTS must provide automated dispatchable location with each 911 call.
(ii) Non-fixed IP CTS.  For non-fixed IP CTS (service that is capable of being used from more than one location), covered IP CTS providers must provide location information in accordance with subparagraph (A) below, if technically feasible.  Otherwise, covered IP CTS providers must either provide location information in accordance with subparagraph (B) or (C), or meet subparagraph (D) below.  
(A) Provide automated dispatchable location, if technically feasible.  
(B) Provide Registered Location information that meets the following requirements: 
(1) The service provider has obtained from the customer, prior to the initiation of service, the Registered Location (as defined in §9.3) at which the service will first be used; and 
(2) The service provider has provided end users one or more methods of updating their Registered Location, including at least one option that requires use only of the Internet-based TRS access technology necessary to access the IP CTS.  Any method used must allow an end user to update the Registered Location at will and in a timely manner.
(C) Provide Alternative Location Information as defined in §9.3.
(D) Route the caller to a call center. 
(f) Compliance date.  Paragraphs (a)(2); (d)(2)(ii); (d)(2)(iii); (d)(2)(v); (d)(4); (e)(2)(ii); (e)(2)(iv); and (e)(4) of this section contain information-collection and recordkeeping requirements.  Compliance will not be required until after approval by the Office of Management and Budget.  The Commission will publish a document in the Federal Register announcing that compliance date and revising this paragraph accordingly.
Subpart F – Multi-Line Telephone Systems
§ 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 tele- phone 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.
§ 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 tele- phone 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), a user may directly initiate a call to 911 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9, regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls. 
(2) A person engaged in the business of manufacturing, importing, selling, or leasing multi-line telephone systems may not manufacture or import for use in the United States, or sell or lease or offer to sell or lease in the United States, a multi-line telephone system, unless such system has the capability, after proper installation in accordance with subsection (b), of providing the dispatchable location of the caller to the PSAP with 911 calls.
(b) Obligation of installers, managers, or operators.
(1) A person engaged in the business of installing, managing, or operating multi-line telephone systems may not install, manage, or operate for use in the United States such a system, unless such system is configured such that a user may directly initiate a call to 911 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9, regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls.
(2) A person engaged in the business of installing, managing, or operating multi-line telephone systems shall, in installing, managing, or operating such a system for use in the United States, configure the system to provide MLTS notification to a central location at the facility where the system is installed or to another person or organization regardless of location, if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system.  MLTS notification must meet the following requirements:
(i) MLTS notification must be initiated contemporaneously with the 911 call, provided that it is technically feasible to do so;
(ii) MLTS notification must not delay the call to 911; and
(iii) MLTS notification must be sent to a location where someone is likely to see or hear it.
(3) A person engaged in the business of installing multi-line telephone systems may not install such a system in the United States unless it is configured such that it is capable of being programmed with and conveying the dispatchable location of the caller to the PSAP with 911 calls consistent with subparagraphs (i), (ii) and (iii).  A person engaged in the business of managing or operating multi-line telephone systems may not manage or operate such a system in the United States unless it is configured such that the dispatchable location of the caller is conveyed to the PSAP with 911 calls consistent with subparagraphs (i), (ii) and (iii).  
(i) Dispatchable location requirements for on-premises fixed telephones associated with a multi-line telephone system.  An on-premises fixed telephone associated with a multi-line telephone system shall provide automated dispatchable location no later than [one year after the effective date of this rule]; 
(ii) Dispatchable location requirements for on-premises non-fixed devices associated with a multi-line telephone system.  No later than [two years after the effective date of this rule], an on-premises non-fixed device associated with a multi-line telephone system shall provide to the appropriate PSAP automated dispatchable location, when technically feasible; otherwise, it shall provide dispatchable location based on end user manual update, or alternative location information as defined in § 9.3.
 (iii) Dispatchable location requirements for off-premises devices associated with a multi-line telephone system.  No later than [two years after the effective date of this rule], an off-premises device associated with a multi-line telephone system shall provide to the appropriate PSAP  automatic  dispatchable location, if technically feasible; otherwise, it shall provide dispatchable location based on end user manual update, or enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost.
(c) Compliance Date.  Paragraphs (b)(3)(i); (b)(3)(ii); and (b)(3)(iii), of this section contain information-collection and recordkeeping requirements.  Compliance will not be required until after approval by the Office of Management and Budget.  The Commission will publish a document in the Federal Register announcing that compliance date and revising this paragraph accordingly.
§ 9.17   Enforcement, Compliance date, State law.
(a) Enforcement.
(1) Sections 9.16(a)(1) and 9.16(b)(1) and (2) shall be enforced under title V of the Communications Act of 1934, as amended, 5 U.S.C. 501 et seq., except that section 501 applies only to the extent that such section provides for the punishment of a fine.
(2) In the event of noncompliance with § 9.16(b), the person engaged in the business of managing the multi-line telephone system shall be presumed to be responsible for the noncompliance.
(3) Persons alleging a violation of the rules in § 9.16 may file a complaint under the procedures set forth in § 1.711 through § 1.737 of this chapter. 
 (b) Compliance date.  The compliance date for this subpart F is February 16, 2020, unless otherwise noted.  Accordingly, the requirements in this subpart apply to a multi-line telephone system that is manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020, unless otherwise noted.  
 (c) Effect on State law.  Nothing in §§ 9.16(a)(1) and 9.16(b)(1) and (2) is intended to alter the authority of State commissions or other State or local agencies with jurisdiction over emergency communications, if the exercise of such authority is not inconsistent with this subpart. 
Subpart G – Mobile-Satellite Service
§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
§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 §9.3; and/or
(B) Operates one or more central offices that directly serve a PSAP.  For purposes of this section, a central office directly serves a PSAP if it hosts a selective router or ALI/ANI database, provides equivalent NG911 capabilities, or is the last service-provider facility through which a 911 trunk or administrative line passes before connecting to a PSAP.
(ii) The term “covered 911 service provider” shall not include any entity that:
(A) Constitutes a PSAP or governmental authority to the extent that it provides 911 capabilities; or
(B) Offers the capability to originate 911 calls where another service provider delivers those calls and associated number or location information to the appropriate PSAP.
(5) Critical 911 circuits.  911 facilities that originate at a selective router or its functional equivalent and terminate in the central office that serves the PSAP(s) to which the selective router or its functional equivalent delivers 911 calls, including all equipment in the serving central office necessary for the delivery of 911 calls to the PSAP(s).  Critical 911 circuits also include ALI and ANI facilities that originate at the ALI or ANI database and terminate in the central office that serves the PSAP(s) to which the ALI or ANI databases deliver 911 caller information, including all equipment in the serving central office necessary for the delivery of such information to the PSAP(s).
(6) Diversity audit.  A periodic analysis of the geographic routing of network components to determine whether they are physically diverse. Diversity audits may be performed through manual or automated means, or through a review of paper or electronic records, as long as they reflect whether critical 911 circuits are physically diverse.
(7) Monitoring links.  Facilities that collect and transmit network monitoring data to a NOC or other location for monitoring and analyzing network status and performance.
(8) Physically diverse.  Circuits or equivalent data paths are Physically Diverse if they provide more than one physical route between end points with no common points where a single failure at that point would cause both circuits to fail. Circuits that share a common segment such as a fiber-optic cable or circuit board are not Physically diverse even if they are logically diverse for purposes of transmitting data.
(9) 911 service area.  The metropolitan area or geographic region in which a covered 911 service provider operates a selective router or the functional equivalent to route 911 calls to the geographically appropriate PSAP.
(10) Selective router.  A 911 network component that selects the appropriate destination PSAP for each 911 call based on the location of the caller.
(11) Tagging.  An inventory management process whereby critical 911 circuits are labeled in circuit inventory databases to make it less likely that circuit rearrangements will compromise diversity.  A covered 911 service provider may use any system it wishes to tag circuits so long as it tracks whether critical 911 circuits are physically diverse and identifies changes that would compromise such diversity.
(b) Provision of reliable 911 service.  All covered 911 service providers shall take reasonable measures to provide reliable 911 service with respect to circuit diversity, central-office backup power, and diverse network monitoring. Performance of the elements of the certification set forth in paragraphs (c)(1)(i), (c)(2)(i), and (c)(3)(i) of this section shall be deemed to satisfy the requirements of this paragraph. If a covered 911 service provider cannot certify that it has performed a given element, the Commission may determine that such provider nevertheless satisfies the requirements of this paragraph based upon a showing in accordance with paragraph (c) of this section that it is taking alternative measures with respect to that element that are reasonably sufficient to mitigate the risk of failure, or that one or more certification elements are not applicable to its network.
(c) Annual reliability certification.  One year after the initial reliability certification described in paragraph (d)(1) of this section and every year thereafter, a certifying official of every covered 911 service provider shall submit a certification to the Commission as follows.
(1) Circuit auditing.  (i) A covered 911 service provider shall certify whether it has, within the past year:
(A) Conducted diversity audits of critical 911 circuits or equivalent data paths to any PSAP served;
(B) Tagged such critical 911 circuits to reduce the probability of inadvertent loss of diversity in the period between audits; and
(C) Eliminated all single points of failure in critical 911 circuits or equivalent data paths serving each PSAP.
(ii) If a Covered 911 Service Provider does not conform with all of the elements in paragraph (c)(1)(i) of this section with respect to the 911 service provided to one or more PSAPs, it must certify with respect to each such PSAP:
(A) Whether it has taken alternative measures to mitigate the risk of critical 911 circuits that are not physically diverse or is taking steps to remediate any issues that it has identified with respect to 911 service to the PSAP, in which case it shall provide a brief explanation of such alternative measures or such remediation steps, the date by which it anticipates such remediation will be completed, and why it believes those measures are reasonably sufficient to mitigate such risk; or
(B) Whether it believes that one or more of the requirements of this paragraph are not applicable to its network, in which case it shall provide a brief explanation of why it believes any such requirement does not apply.
(2) Backup power.  (i) With respect to any central office it operates that directly serves a PSAP, a covered 911 service provider shall certify whether it:
(A) Provisions backup power through fixed generators, portable generators, batteries, fuel cells, or a combination of these or other such sources to maintain full-service functionality, including network monitoring capabilities, for at least 24 hours at full office load or, if the central office hosts a selective router, at least 72 hours at full office load; provided, however, that any such portable generators shall be readily available within the time it takes the batteries to drain, notwithstanding potential demand for such generators elsewhere in the service provider’s network.
(B) Tests and maintains all backup power equipment in such central offices in accordance with the manufacturer’s specifications;
(C) Designs backup generators in such central offices for fully automatic operation and for ease of manual operation, when required;
(D) Designs, installs, and maintains each generator in any central office that is served by more than one backup generator as a stand-alone unit that does not depend on the operation of another generator for proper functioning.
(ii) If a covered 911 service provider does not conform with all of the elements in paragraph (c)(2)(i) of this section, it must certify with respect to each such central office:
(A) Whether it has taken alternative measures to mitigate the risk of a loss of service in that office due to a loss of power or is taking steps to remediate any issues that it has identified with respect to backup power in that office, in which case it shall provide a brief explanation of such alternative measures or such remediation steps, the date by which it anticipates such remediation will be completed, and why it believes those measures are reasonably sufficient to mitigate such risk; or
(B) Whether it believes that one or more of the requirements of this paragraph are not applicable to its network, in which case it shall provide a brief explanation of why it believes any such requirement does not apply.
(3) Network monitoring.  (i) A covered 911 service provider shall certify whether it has, within the past year:
(A) Conducted diversity audits of the aggregation points that it uses to gather network monitoring data in each 911 service area;
(B) Conducted diversity audits of monitoring links between aggregation points and NOCs for each 911 service area in which it operates; and
(C) Implemented physically diverse aggregation points for network monitoring data in each 911 service area and physically diverse monitoring links from such aggregation points to at least one NOC.
(ii) If a Covered 911 Service Provider does not conform with all of the elements in paragraph (c)(3)(i) of this section, it must certify with respect to each such 911 Service Area:
(A) Whether it has taken alternative measures to mitigate the risk of network monitoring facilities that are not physically diverse or is taking steps to remediate any issues that it has identified with respect to diverse network monitoring in that 911 service area, in which case it shall provide a brief explanation of such alternative measures or such remediation steps, the date by which it anticipates such remediation will be completed, and why it believes those measures are reasonably sufficient to mitigate such risk; or
(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.
§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 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 Web site and/or within a subscriber portal accessed by logging through the provider’s Web site 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 §9.11(e).
(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 – RESILIENCY, REDUNDANCY AND RELIABILITY OF COMMUNICATIONS 
8. 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 12 [Reserved]
PART 20 – COMMERCIAL MOBILE SERVICES  
9. 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.
10. Section 20.2 is amended by adding paragraph (c) to read as follows:
§ 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.
11. 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.” 
12. Section 20.18 is amended by removing and reserving this section:
§ 20.18 [Reserved]  
* * * * *
PART 22 – PUBLIC MOBILE SERVICES
13. The authority citation for part 22 continues to read as follows:
Authority: 47 U.S.C. 154, 222, 303, 309, and 332.
14. Section 22.921 is amended by removing and reserving this section.
§ 22.921 [Reserved]  
* * * * *
PART 25 – SATELLITE COMMUNICATIONS 
15. 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.
16. Section 25.103 is amended by removing the definition of “Emergency Call Center.”
17. Part 25 is amended by removing and reserving Section 25.284:
§ 25.284 [Reserved]  
* * * * *
PART 64 – MISCELLANEOUS RULES RELATING TO COMMON CARRIERS 
18. 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.
19. Section 64.601 is amended by revising paragraph (a) to read as follows:
§ 64.601   Definitions and provisions of general applicability. 
(a) For purposes of this subpart, the term affiliate is defined in 47 CFR 52.12(a)(1)(i), and the terms majority and debt are defined in 47 CFR 52.12(a)(1)(ii).
* * * * *
20. Section 64.603 is amended by revising paragraph (a) to read as follows:
§ 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.
* * * * *
21. Section 64.604 is amended by removing and reserving paragraph (a)(4) and revising paragraph (d) to read as follows:
§ 64.604   Mandatory minimum standards.
(a) * * *
(4) [Reserved].
* * * * *
(d) Other standards.  The applicable requirements of § 9.14 of this chapter and §§ 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.
22. Part 64 is amended by removing and reserving Section 64.605:
§ 64.605 [Reserved]  
* * * * *
23. Part 64 is amended by removing and reserving subpart AA:
Subpart AA – [Reserved]  
* * * * *


145
APPENDIX B

Conversion Tables

Conversion Table A

Final Rule
Source Rule(s) 
Comment(s)
Subpart A – Purpose and Definitions


§ 9.1	Purpose


§ 9.2      Reserved


§ 9.3      Definitions
47 CFR §§ 9.3, 20.3, 25.103, 64.601(a), and 64.3000
Certain definitions from source rules added to § 9.3; some definitions revised; some definitions new.
Subpart B – Telecommunications Carriers

Part 64, subpart AA (Universal Emergency Telephone Number) is removed and reserved.
§ 9.4	Obligation to transmit 911 calls
47 CFR § 64.3001
Source rule moved to § 9.4 and subpart AA removed and reserved in Part 64.
§ 9.5	Transition to 911 as the universal emergency telephone number
47 CFR § 64.3002
Source rule moved to § 9.5 and subpart AA removed and reserved in Part 64. 
§ 9.6	Obligation for providing a permissive dialing period
47 CFR § 64.3003
Source rule moved to § 9.6 and subpart AA removed and reserved in Part 64.
§ 9.7	Obligation for providing an intercept message
47 CFR § 64.3004
Source rule moved to § 9.7 and subpart AA removed and reserved in Part 64.
§ 9.8	Obligation of fixed telephony providers to convey dispatchable location

New provision.
Subpart C - Commercial Mobile Radio Service


§ 9.9	Definitions
47 CFR § 20.3
Certain definitions from source rule added to § 9.9.
§ 9.10	911 Service Requirements
47 CFR § 20.18
Source rule moved to § 9.10 and revised to add paragraph (q)(10)(v); and removed and reserved in Part 20.
Subpart D - Interconnected Voice over Internet Protocol Services


§ 9.11	E911 Service
47 CFR § 9.5
Source rule moved to § 9.11 and revised except for § 9.5(f), which is omitted.
§ 9.12	Access to 911 and E911 service capabilities
47 CFR § 9.7
Source rule moved to § 9.12 and revised.


Subpart E - Telecommunications Relay Services for Persons With Disabilities


§ 9.13	Jurisdiction
47 CFR §§ 64.601(b) and 64.602
Source rules added to § 9.13.
§ 9.14    Emergency Calling Requirements 
47 CFR §§ 64.604(a)(4) and 64.605
Source rules moved to § 9.14 and revised; § 64.605 removed and reserved in Part 64.
Subpart F - Multi Line Telephone Systems

New provision
§ 9.15   Applicability


§ 9.16   General obligations – direct 911 dialing, notification and dispatchable location


§ 9.17   Enforcement, compliance date, State law


Subpart G – Mobile-Satellite Service


§ 9.18	Emergency Call Center Service
47 CFR § 25.284
Source rule moved to § 9.18 and removed and reserved in Part 25.
Subpart H - Resiliency, redundancy and reliability of 911 communications 

Part 12 is consolidated under Part 9, Subpart H and is removed and reserved.
§ 9.19	Reliability of covered 911 service providers
47 CFR § 12.4
Source rule moved to § 9.19 and removed and reserved in Part 12.
§ 9.20 	Backup power obligations
47 CFR § 12.5
Source rule moved to § 9.20 and removed and reserved in Part 12.

Conversion Table B
PART 1 – PRACTICE AND PROCEDURE
FINAL RULE CHANGES

CURRENT RULE NUMBER
SUBJECT
FINAL CHANGES
1.9020
Spectrum manager leasing arrangements. 
Updated cross-references.
1.9030
Long-term de facto transfer leasing arrangements.
Updated cross-references.
1.9035
Short-term de facto transfer leasing arrangements. 

Updated cross-references.

1.9049
Special provisions relating to spectrum leasing arrangements involving the ancillary terrestrial component of Mobile Satellite Services.
Updated cross-references.

PART 9 – INTERCONNECTED VOICE OVER INTERNET PROTOCOL SERVICES
FINAL RULE CHANGES

CURRENT RULE NUMBER
SUBJECT
FINAL 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
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.  Removed the obligation in 9.5(f).

9.7
Access to 911 and E911 service capabilities.
Moved to 9.12 and revised.

PART 12 – RESILIENCY, REDUNDANCY AND RELIABILITY OF COMMUNICATIONS
FINAL RULE CHANGES

CURRENT RULE NUMBER
SUBJECT
FINAL CHANGES
12.1
Purpose. 
Removed.
12.3
911 and E911 analyses and reports.
Removed (one-time reporting requirement has been completed).
12.4
Reliability of covered 911 service providers. 

Moved to 9.19; corrected internal cross-references.

12.5
Backup power obligations.
Moved to 9.20; corrected internal cross-references.

PART 20 – COMMERCIAL MOBILE SERVICES
FINAL RULE CHANGES

CURRENT RULE NUMBER
SUBJECT
FINAL CHANGES
20.2
Other applicable rule parts.
Section 20.2 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).
Added new paragraph (q)(10)(v).

PART 22 – PUBLIC MOBILE SERVICES
FINAL RULE CHANGES

CURRENT RULE NUMBER
SUBJECT
FINAL CHANGES
22.921
911 call processing procedures; 911-only calling mode. 
Removed and reserved.

PART 25 – SATELLITE COMMUNICATIONS
FINAL RULE CHANGES

CURRENT RULE NUMBER
SUBJECT
FINAL 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
Mobile-Satellite Service (MSS)
Space station

Definition of the following term added to 9.3 and removed from 25.103:
Emergency Call Center

25.284
Emergency Call Center Service.
Moved to 9.18; section 25.284 removed and reserved.

PART 64 – MISCELLANEOUS RULES RELATING TO COMMON CARRIERS
FINAL RULE CHANGES

CURRENT RULE NUMBER
SUBJECT
FINAL CHANGES
64.601
Definitions and provisions of general applicability. 
64.601(b), which states that “For purposes of this 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 remove the terms “Public Safety Answering Point (PSAP),” “statewide default answering point,” and “appropriate local emergency authority.”
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)
iTRS access technology
Internet-based TRS (iTRS)
Internet Protocol Captioned Telephone Service (IP CTS)
Internet Protocol Relay Service (IP Relay)
Non-English language relay service
Speech-to-speech relay service
Telecommunications relay services (TRS)
Text telephone (TTY)
Video relay service (VRS)

64.602
Jurisdiction.
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 services.
Section 64.603(a) 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 section 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 handling requirements for TTY-based TRS providers. 
Moved to 9.14(a); section 64.604(a)(4) removed and reserved; and section64.604(d) revised to update cross-reference from 64.605 to 9.14.
64.605
Emergency calling requirements.
Moved to 9.14(b) and (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 transmit 911 calls.
Moved to 9.4 and removed from Part 64 as subpart AA (Universal Emergency Telephone Number) is removed and reserved.
64.3002
Transition to 911 as the universal emergency telephone number.
Moved to 9.5 and removed from Part 64 as subpart AA (Universal Emergency Telephone Number) is removed and reserved.
64.3003
Obligation for providing a permissive dialing period.
Moved to 9.6 and removed from Part 64 as subpart AA (Universal Emergency Telephone Number) is removed and reserved.
64.3004
Obligation for providing an intercept message.
Moved to 9.7 and removed from Part 64 as subpart AA (Universal Emergency Telephone Number) is removed and reserved.


	Federal Communications Commission	FCC 19-76


APPENDIX C

Final Regulatory Flexibility Analysis

1. As required by the Regulatory Flexibility Act of 1980, as amended (RFA), See 5 U.S.C. § 603.  The RFA, 5 U.S.C. §§ 601–612, was amended by the Small Business Regulatory Enforcement Fairness Act of 1996 (SBREFA), Pub. L. No. 104-121, Title II, 110 Stat. 857 (1996).
  an Initial Regulatory Flexibility Analysis (IRFAs) was incorporated in the Notice of Proposed Rulemaking adopted in September 2018 (Notice). Implementing Kari’s Law and Section 506 of RAY BAUM’S Act, Inquiry Concerning 911 Access, Routing, and Location in Enterprise Communications Systems, PS Docket Nos. 18-261 and 17-239, Notice of Proposed Rulemaking, 33 FCC Rcd 8984 (2018).
  The Commission sought written public comment on the proposals in the Notice including comment on the IRFA.  The Comments received are discussed below.  This Final Regulatory Flexibility Analysis (FRFA) conforms to the RFA. See 5 U.S.C. § 604.

A. Need for, and Objectives of, the Report and Order
2. In the Report and Order, the Commission advances Congressional and Commission objectives to ensure that members of the public can successfully dial 911 to request emergency services and that Public Safety Answering Points (PSAPs) can quickly and accurately locate every 911 caller, regardless of the type of service that is used to make the call.  In 2018, the President signed into law Kari’s Law Act of 2017 (Kari’s Law), which requires implementation of direct 911 dialing and on-site notification capabilities in a multi-line telephone system (MLTS), Kari’s Law Act of 2017, Pub. L. No. 115-127, 132 Stat. 326 (2018) (codified at 47 U.S.C. § 623) (Kari’s Law).  Kari’s Law is named in honor of Kari Hunt, who was attacked and killed by her estranged husband in a motel room in Marshall, Texas in 2013.  Ms. Hunt’s 9-year-old daughter tried to call 911 for help four times from the motel room phone, as she had been taught to do.  The call never went through because she did not know that the hotel’s phone system required dialing “9” for an outbound line before dialing 911.  See Chairman Pai Statement on Passage of Kari’s Law (Feb. 6, 2018), https://docs.fcc.gov/public/attachments/DOC-349050A1.pdf; Texas 9-1-1, Kari’s Law, http://www.texas911.org/ (last visited Sept. 1, 2018).  Texas enacted a version of Kari’s Law on May 15, 2015.  See Tex. Health & Safety Code Ann. § 771A.001(d); 1 Tex. Admin. Code § 251.16.
 and Section 506 of RAY BAUM’S Act (RAY BAUM’S Act), which requires the Commission, within 18 months after the date of the legislation’s enactment (March 23, 2018), to “conclude a proceeding to consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call, regardless of the technological platform used and including with calls from [MLTS].” Section 506 of the Repack Airwaves Yielding Better Access for Users of Modern Services Act of 2018 (RAY BAUM’S Act), Pub. L. No. 115-141, 132 Stat. 348, 1095 (codified at 47 U.S.C. § 615 note).  The 18-month statutory deadline is September 23, 2019.

3. The Report and Order implements Kari’s Law by adopting direct dial and on-site notification rules governing calls to 911 made from a MLTS.  The Commission takes the following actions:   
· adopts 911 direct dialing requirements as proposed in the Notice, subject to clarification of some definitions and terms, including the term pre-configured.
· adopts a requirement that notification be sent to a location where someone is likely to hear or see it, but we do not require the location to be continuously staffed or monitored.  
· requires the notification to include the fact that a 911 call has been made, a valid callback number, and the same location information that is conveyed with the call to 911.  However, we provide an exception for callback number and location information in circumstances where including this information in the notification would be technologically infeasible.  We also require that initiation of the notification be contemporaneous with the call to 911, provided that it is technologically feasible to do so.  
· requires an MLTS to be configured to provide notification for any caller on the system, including callers at satellite or branch locations.
· adopts the statutory definition of MLTS cited in Kari’s Law and RAY BAUM’S Act.  In addition, we interpret this definition to cover the full range of networked communications systems that serve enterprises, including IP-based and cloud-based systems.  We also interpret the definition to include outbound-only MLTS systems that allow users to make 911 calls but do not enable PSAPs to place a return call directly to the 911 caller. 
· establishes February 16, 2020 as the compliance date for regulations implementing Kari’s Law.  
· adopts a presumption that if an MLTS fails to comply with the rules, the MLTS manager is responsible unless the manager can rebut the presumption by demonstrating compliance with its obligations under the statute and rules.  
· declines to adopt disclosure requirements for legacy MLTS that are not subject to the requirements of Kari’s Law and instead encourage enterprises to disclose the limitations on dialing 911 from legacy MLTS as part of voluntary best practices. 
4. As required by RAY BAUM’S Act, the Commission considered the feasibility of requiring dispatchable location for 911 calls from MLTS and other technological platforms that currently complete calls to 911, and established a dispatchable location requirement for MLTS 911 calls.  In keeping with the directive in RAY BAUM’S Act to address dispatchable location for 911 calls “regardless of the technological platform used,” the Report and Order adds dispatchable location requirements to the Commission’s existing 911 rules for fixed telephony providers, interconnected Voice over Internet Protocol (VoIP), Telecommunications Relay Services (TRS), Video Relay Services (VRS), and mobile text.  Finally, consistent with RAY BAUM’S Act, we do not make any changes to the Commission’s existing rules for CMRS providers to provide dispatchable location.      
5. More specifically, consistent with RAY BAUM’S Act the Commission adopts the following definition of dispatchable location and alternative location information: 
· Dispatchable Location.  A location delivered to the PSAP with a 911 call that consists of the validated street address of the calling party, plus additional information such as suite, apartment or similar information necessary to adequately identify the location of the calling party, except for Commercial Mobile Radio Service providers, which shall convey the location information required by our existing rules.
6. For MLTS systems subject to Kari’s Law, we separately address dispatchable location requirements for MLTS 911 calls from (1) fixed devices and non-fixed devices being used on-premises, and (2) non-fixed devices being used off-premises.  Accordingly, the Commission adopts the following dispatchable location rules:
· MLTS 911 calls from fixed devices: One year after the effective date of the rules, MLTS must provide automated dispatchable location with each 911 call.
· MLTS 911 calls from non-fixed devices:
· On-premises MLTS 911 calls from non-fixed devices: Two years after the effective date of the rules, MLTS must provide (1) automated dispatchable location, if technically feasible, or, otherwise, either (2) end-user manually-updated dispatchable location, or (3) alternative location information, which may be coordinate-based, sufficient to identify the caller’s civic address and approximate in-building location, including floor level, in large buildings. 
· Off-premises MLTS 911 calls from off-premises devices: Two years after the effective date of the rules, MLTS must provide (1) automated dispatchable location, if technically feasible, or, if otherwise, either (2) end-user manually-updated dispatchable location, or (3) enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost.  
7. For other services currently subject to 911 requirements (Fixed Telephony, Interconnected Voice over Internet Protocol (VoIP), Telecommunications Relay Service (TRS) and mobile text, the Commission adopts the following requirements:
· Fixed Telephony:  One year after the effective date of the rules, service providers must deliver automated dispatchable location with each 911 call.   
· Interconnected VoIP:
· Fixed interconnected VoIP: One year after the effective date of the rules, service providers must deliver automated dispatchable location with each 911 call or Registered Location.  Dispatchable location may be provided by means of a customer-generated Registered Location, under the same terms and conditions specified in our current VoIP 911 rules, or by automatic provision of dispatchable location by the VoIP service provider, without additional action by the caller, at the time the 911 call is made.   
· Non-fixed interconnected VoIP: Two years after the effective date of the rules, service providers must provide (1) automated dispatchable location, if technically feasible, or, otherwise, either (2) manual updating of Registered Location information, or (3) alternative location information, which may be coordinate-based, sufficient to identify the caller’s civic address and approximate in-building location, including floor level, in large buildings.  If the provider is unable to obtain or confirm the caller’s location, the provider may route the call to a national emergency call center.  
· Outbound-only interconnected VoIP:  For purposes of compliance with our 911 rules, we amend the definition of “Interconnected VoIP Service” in section 9.3 of the Commission’s rules to include “outbound-only” interconnected VoIP services that permit users generally to terminate calls to the public switched telephone network and extend the Interconnected VoIP location requirements described above to such providers.  
· Telecommunications Relay Services
· Fixed TRS: One year after the effective date of the rules, service providers must deliver automated dispatchable location with each 911 call.
· Non-fixed TRS:  Two years after the effective date of the rules, service providers must provide (1) automated dispatchable location, if technically feasible, or, otherwise, either (2) manual updating of Registered Location information, or (3) alternative location information sufficient to identify the caller’s civic address and approximate in-building location, including floor level, in large buildings.  If the provider is unable to obtain or confirm the caller’s location, the provider may route the call to a national emergency call center.
· Mobile Text: Two years after the effective date of the rules, covered text providers must provide (1) automated dispatchable location, if technically feasible, or, otherwise, either (2) end-user manually provisioned location information, or (3) enhanced location information consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost.
8. Lastly, as the Commission proposed in the Notice, the Report and Order consolidates the Commission’s existing 911 rules, and the direct dialing and dispatchable location rules proposed in the Notice, into a single rule part.  The Commission historically has taken a service-specific approach to 911, with the result that 911 requirements for different services are scattered across different sections of the agency’s rules.  Consolidating our 911 rules from these various rule sections into a single rule part furthers the goal of recognizing that all the components of 911 function as part of a single system and enables service providers, emergency management officials, and other stakeholders to refer to a single part of the Commission’s rules to more easily ascertain all 911 requirements.  
B. Summary of Significant Issues Raised by Public Comments in Response to the IRFA 
9. There were no comments that specifically addressed the proposed rules and policies presented in the IRFA.  
C. Response to Comments by the Chief Counsel for Advocacy of the Small Business Administration
10. Pursuant to the Small Business Jobs Act of 2010, which amended the RFA, the Commission is required to respond to any comments filed by the Chief Counsel for Advocacy of the Small Business Administration (SBA), and to provide a detailed statement of any change made to the proposed rules as a result of those comments. 5 U.S.C. § 604(a)(3).
  
11. The Chief Counsel did not file any comments in response to the proposed rules in this proceeding.
D. Description and Estimate of the Number of Small Entities To Which the Rules Will Apply
12. The RFA directs agencies to provide a description of, and where feasible, an estimate of the number of small entities that may be affected by the rule changes. Id. § 603(b)(3). 
  The RFA generally defines the term “small entity” as having the same meaning as the terms “small business,” “small organization,” and “small governmental jurisdiction.” Id. § 601(6). 
  In addition, the term “small business” has the same meaning as the term “small business concern” under the Small Business Act. Id. § 601(3) (incorporating by reference the definition of “small-business concern” in the Small Business Act, 15 U.S.C. § 632).  The statutory definition of a small business applies “unless an agency, after consultation with the Office of Advocacy of the Small Business Administration and after opportunity for public comment, establishes one or more definitions of such term which are appropriate to the activities of the agency and publishes such definition(s) in the Federal Register.”  
  A “small business concern” is one that:  (1) is independently owned and operated; (2) is not dominant in its field of operation; and (3) satisfies any additional criteria established by the SBA. 15 U.S.C. § 632. 
 
13. 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. 13 CFR § 121.201; see also U.S. Census Bureau, 2017 NAICS Definition, NAICS Code 334210 “Telephone Apparatus Manufacturing,” https://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=334210&search=2017%20NAICS%20Search.
  The SBA size standard for Telephone Apparatus Manufacturing consists of all such companies having 1,250 or fewer employees. 13 CFR § 121.201. 
  U.S. Census Bureau data for 2012 show that there were 266 establishments that operated that year. U.S. Census Bureau, 2012 Economic Census of the United States, Table EC1231SG2- Manufacturing: Summary Series: General Summary: Industry Statistics for Subsectors and Industries by Employment Size: 2012 NAICS Code 334210, https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/31SG2//naics~334210. 
  Of this total, 262 operated with fewer than 1,000 employees. Id.  Available census data does not provide a more precise estimate of the number of firms that have employment of 1,250 or fewer employees; the largest category provided is for firms with “1,000 or more.”
  Thus, under this size standard, the majority of firms in this industry can be considered small. 
14. Telephone Apparatus Manufacturing.  This industry comprises establishments primarily engaged in manufacturing wire telephone and data communications equipment. See U.S. Census Bureau, 2017 NAICS Definition, NAICS Code 334210 “Telephone Apparatus Manufacturing,” https://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=334210&search=2017%20NAICS%20Search. 
  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. Id.
  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. 13 CFR § 121.201; NAICS code 334210. 
  U.S. Census Bureau data for 2012 show that there were 266 establishments that operated that year. U.S. Census Bureau, 2012 Economic Census of the United States, Table EC1231SG2- Manufacturing: Summary Series: General Summary: Industry Statistics for Subsectors and Industries by Employment Size: 2012 NAICS Code 334210, https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/31SG2//naics~334210. 
  Of this total, 262 operated with fewer than 1,000 employees. Id.  Available census data does not provide a more precise estimate of the number of firms that have employment of 1,250 or fewer employees; the largest category provided is for firms with “1000 employees to 2,499.”
  Thus, under this size standard, the majority of firms in this industry can be considered small. 
15. Multi-Line Telephone System Operators, Installers and Managers.  Neither the Commission nor the SBA has developed a specific small business size standard for MLTS operators, installers and managers.  MLTS Operators, Installers and Managers cut across numerous industry segments and encompass all types of businesses and organization including for-profit, not-for-profit and government agencies.  Thus, for purposes of this FRFA, we group entities operating, installing, and managing MLTS in the Small Businesses, Small Organizations and Small Government Jurisdictions description contained in paragraph 21 infra.
16. 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. See U.S. Census Bureau, 2017 NAICS Definitions, NAICS Code “517919 All Other Telecommunications,” https://www.census.gov/cgi-bin/sssd/naics/naicsrch?input=517919&search=2017+NAICS+Search&search=2017.
  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. Id.
  Establishments providing Internet services or voice over Internet protocol (VoIP) services via client-supplied telecommunications connections are also included in this industry. Id.
  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. See 13 CFR § 121.201, NAICS code 517919.
  For this category, U.S. Census Bureau data for 2012 show that there were 1,442 firms that operated for the entire year. U.S. Census Bureau, 2012 Economic Census of the United States, Table EC1251SSSZ4, Information: Subject Series - Estab and Firm Size: Receipts Size of Firms for the United States: 2012, NAICS code 517919, https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/51SSSZ4//naics~517919.
  Of those firms, a total of 1,400 had annual receipts less than $25 million and 15 firms had annual receipts of $25 million to $49,999,999. Id.
  Thus, the Commission estimates that the majority of “All Other Telecommunications” firms potentially affected by our action can be considered small.
17. 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. See U.S. Census Bureau, 2017 NAICS Definition, NAICS Code 541513, “Computer Facilities Management Services,” https://www.census.gov/cgi-bin/sssd/naics/naicsrch?input=541513&search=2017+NAICS+Search&search=2017.
  Establishments providing computer systems or data processing facilities support services are included in this industry. Id.   
  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. See 13 CFR § 121.201, NAICS code 541513. 
  U.S. Census Bureau data for 2012 indicate that 4,828 firms operated the entire year. U.S. Census Bureau, 2012 Economic Census of the United States, Table EC1254SSSZ4, Professional, Scientific, and Technical Services: Subject Series - Estab & Firm Size: Receipts/Revenue Size of Firms for the U.S.: 2012, NAICS Code 541513, https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/54SSSZ4//naics~541513. 
  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. Id. 
  Thus, under the SBA size standard the majority of firms in this industry can be considered small. 
18. 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). See U.S. Census Bureau, 2017 NAICS Definition, NAICS Code 541519 “Other Computer Related Services,” https://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=334210&search=2017%20NAICS%20Search 514519.
 Establishments providing computer disaster recovery services or software installation services are included in this industry. Id.  
  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. 13 CFR § 121.201. 
  For this category, U.S. Census Bureau data for 2012 indicate that 6,354 firms operated the entire year. U.S. Census Bureau, 2012 Economic Census of the United States, Table EC1254SSSZ4, Professional, Scientific, and Technical Services: Subject Series - Estab & Firm Size: Receipts/Revenue Size of Firms for the U.S.: 2012 NAICS Code 541519, https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/54SSSZ4//naics~541519.  
  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. Id. 
  Thus, the Commission estimates that the majority of Other Computer Related Services firms in this industry can be considered small.
19. 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. See 13 CFR § 121.201 note 18; NAICS Code 541519_Except.
  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. Id.
  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. Id. 
  For this category, U.S. Census Bureau data for 2012 indicate that 6,354 firms operated the entire year. U.S. Census Bureau, 2012 Economic Census of the United States, Table EC1254SSSZ4, Professional, Scientific, and Technical Services: Subject Series - Estab & Firm Size: Receipts/Revenue Size of Firms for the U.S.: 2012 NAICS Code 541519, https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/54SSSZ4//naics~541519. 
  Of this total, 6,241 had less than 100 employees and 113 had 100 -1000 or more employees. Id.  Available census data does not provide a more precise estimate of the number of firms that have employment of 150 or fewer employees.  The closest category provided is for firms with fewer than 100 employees.
  Thus, the Commission estimates that the majority of Information Technology Value Added Resellers in this industry can be considered small.
20. Data Processing, Hosting, and Related Services. This industry comprises establishments primarily engaged in providing infrastructure for hosting or data processing services. See U.S. Census Bureau, 2017 NAICS Definition, NAICS Code 518210 “Data Processing, Hosting, and Related Services,” https://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=518210&search=2017%20NAICS%20Search.
  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. Id.
  Data processing establishments provide complete processing and specialized reports from data supplied by clients or provide automated data processing and data entry services. Id.
  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. 13 CFR § 121.201. 
  U.S. Census Bureau data for 2012 indicate that 8,252 firms operated the entire year. See U.S. Census Bureau, 2012 Economic Census of the United States, Table EC1251SSSZ4,  Information: Subject Series - Estab & Firm Size: Receipts Size of Firms for the U.S.: 2012, NAICS Code 518210, https://factfinder.census.gov/faces/tableservices/jsf/pages/productview.xhtml?pid=ECN_2012_US_51SSSZ4&prodType=table. 
  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. Id. 
  Thus, under this size standard the majority of firms in this industry are small businesses. 
21. 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. See 5 U.S.C. § 601(3)-(6).
  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. See SBA, Office of Advocacy, “Frequently Asked Questions, Question 1 – What is a small business?” (June 2016), https://www.sba.gov/sites/default/files/advocacy/SB-FAQ-2016_WEB.pdf. 
  These types of small businesses represent 99.9% of all businesses in the United States which translates to 28.8 million businesses. See SBA, Office of Advocacy, “Frequently Asked Questions, Question 2- How many small businesses are there in the U.S.?” (June 2016), https://www.sba.gov/sites/default/files/advocacy/SB-FAQ-2016_WEB.pdf.
  
22. Next, the type of small entity described as a “small organization” is generally “any not-for-profit enterprise which is independently owned and operated and is not dominant in its field.” 5 U.S.C. § 601(4).
  Nationwide, as of August 2016, there were approximately 356,494 small organizations based on registration and tax data filed by nonprofits with the Internal Revenue Service (IRS). Data from the Urban Institute, National Center for Charitable Statistics (NCCS) reporting on nonprofit organizations registered with the IRS was used to estimate the number of small organizations.  Reports generated using the NCCS online database indicated that as of August 2016 there were 356,494 registered nonprofits with total revenues of less than $100,000.  Of this number, 326,897 entities filed tax returns with 65,113 registered nonprofits reporting total revenues of $50,000 or less on the IRS Form 990-N for Small Exempt Organizations and 261,784 nonprofits reporting total revenues of $100,000 or less on some other version of the IRS Form 990 within 24 months of the August 2016 data release date.  See http://nccs.urban.org/sites/all/nccs-archive/html//tablewiz/tw.php where the report showing these data can be generated by selecting the following data fields: Report: “The Number and Finances of All Registered 501(c) Nonprofits”; Show: “Registered Nonprofits”; By: “Total Revenue Level (years 1995, Aug to 2016, Aug)”; and For: “2016, Aug” then selecting “Show Results”.
  
23. 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.” 5 U.S.C. § 601(5).
  U.S. Census Bureau data from the 2012 Census of Governments See 13 U.S.C. § 161. The Census of Government is conducted every five (5) years compiling data for years ending with “2” and “7”. See also Program Description Census of Government https://factfinder.census.gov/faces/affhelp/jsf/pages/metadata.xhtml?lang=en&type=program&id=program.en.COG#.
 indicate that there were 90,056 local governmental jurisdictions consisting of general purpose governments and special purpose governments in the United States. See U.S. Census Bureau, 2012 Census of Governments, Local Governments by Type and State: 2012 - United States-States. https://factfinder.census.gov/bkmk/table/1.0/en/COG/2012/ORG02.US01. Local governmental jurisdictions are classified in two categories - General purpose governments (county, municipal and town or township) and Special purpose governments (special districts and independent school districts).   
  Of this number there were 37, 132 General purpose governments (county See U.S. Census Bureau, 2012 Census of Governments, County Governments by Population-Size Group and State: 2012 - United States-States. https://factfinder.census.gov/bkmk/table/1.0/en/COG/2012/ORG06.US01.  There were 2,114 county governments with populations less than 50,000. 
, municipal and town or township See U.S. Census Bureau, 2012 Census of Governments, Subcounty General-Purpose Governments by Population-Size Group and State: 2012 - United States – States. https://factfinder.census.gov/bkmk/table/1.0/en/COG/2012/ORG07.US01. There were 18,811 municipal and 16,207 town and township governments with populations less than 50,000. 
) with populations of less than 50,000 and 12,184 Special purpose governments (independent school districts See U.S. Census Bureau, 2012 Census of Governments, Elementary and Secondary School Systems by Enrollment-Size Group and State: 2012 - United States-States. https://factfinder.census.gov/bkmk/table/1.0/en/COG/2012/ORG11.US01. There were 12,184 independent school districts with enrollment populations less than 50,000.

 and special districts See U.S. Census Bureau, 2012 Census of Governments, Special District Governments by Function and State: 2012 - United States-States. https://factfinder.census.gov/bkmk/table/1.0/en/COG/2012/ORG09.US01.  The U.S. Census Bureau data did not provide a population breakout for special district governments.
) with populations of less than 50,000.  The 2012 U.S. Census Bureau data for most types of governments in the local government category show that the majority of these governments have populations of less than 50,000. See U.S. Census Bureau, 2012 Census of Governments, County Governments by Population-Size Group and State: 2012 - United States-States - https://factfinder.census.gov/bkmk/table/1.0/en/COG/2012/ORG06.US01;   Subcounty General-Purpose Governments by Population-Size Group and State: 2012 - United States–States - https://factfinder.census.gov/bkmk/table/1.0/en/COG/2012/ORG07.US01; and Elementary and Secondary School Systems by Enrollment-Size Group and State: 2012 - United States-States. https://factfinder.census.gov/bkmk/table/1.0/en/COG/2012/ORG11.US01.  While U.S. Census Bureau data did not provide a population breakout for special district governments, if the population of less than 50,000 for this category of local government is consistent with the other types of local governments the majority of the 38, 266 special district governments have populations of less than 50,000.
  Based on these data we estimate that at least 49,316 local government jurisdictions fall in the category of “small governmental jurisdictions.” Id.

24. 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.” See 13 CFR § 120.201.  The Wired Telecommunications Carrier category formerly used the NAICS code of 517110.  As of 2017, the U.S. Census Bureau definition shows the NAICS code as 517311 for Wired Telecommunications Carriers.  See U.S. Census Bureau, 2017 NAICS Definition, https://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=517311&search=2017.
  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. Id.
  U.S. Census Bureau data for 2012 show that there were 3,117 firms that operated that year. See U.S. Census Bureau, 2012 Economic Census of the United States, Table No. EC1251SSSZ5, Information: Subject Series - Estab & Firm Size: Employment Size of Firms: 2012 (517110 Wired Telecommunications Carriers). https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/51SSSZ5//naics~517110.
  Of this total, 3,083 operated with fewer than 1,000 employees. Id.
 Thus, under this size standard, the majority of firms in this industry can be considered small.
25. 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. See 13 CFR § 121.201.  The Wired Telecommunications Carrier category formerly used the NAICS code of 517110.  As of 2017, the U.S. Census Bureau definition shows the NAICs code as 517311 for Wired Telecommunications Carriers.  See U.S. Census Bureau, 2017 NAICS Definition, https://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=517311&search=2017. 
  Under the applicable SBA size standard size standard, such a business is small if it has 1,500 or fewer employees. Id.
  U.S. Census Bureau data for 2012 show that there were 3,117 firms that operated for the entire year. See U.S. Census Bureau, 2012 Economic Census of the United States, Table No. EC1251SSSZ5, Information: Subject Series - Estab & Firm Size: Employment Size of Firms: 2012 (517110 Wired Telecommunications Carriers). https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/51SSSZ5//naics~517110.
  Of this total, 3,083 operated with fewer than 1,000 employees. Id. 
  Thus, under this category and the associated size standard, the Commission estimates that the majority of local exchange carriers are small entities.
26. 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. See 13 CFR § 121.201. The Wired Telecommunications Carrier category formerly used the NAICS code of 517110. As of 2017 the U.S. Census Bureau definition shows the NAICs code as 517311 for Wired Telecommunications Carriers.  See U.S. Census Bureau, 2017 NAICS Definition https://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=517311&search=2017.
  Under the applicable SBA size standard, such a business is small if it has 1,500 or fewer employees. Id. 
  According to U.S. Census Bureau data, 3,117 firms operated the entire year. See U.S. Census Bureau, 2012 Economic Census of the United States, Table No. EC1251SSSZ5, Information: Subject Series - Estab & Firm Size: Employment Size of Firms: 2012 (517110 Wired Telecommunications Carriers). https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/51SSSZ5//naics~517110. 
  Of this total, 3,083 operated with fewer than 1,000 employees. Id.
  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. See Federal Communications Commission, Wireline Competition Bureau, Industry Analysis and Technology Division, Trends in Telephone Service, at Table 5.3 (2010), https://docs.fcc.gov/public/attachments/DOC-301823A1.pdf (Trends in Telephone Service).
  Of this total, an estimated 1,006 have 1,500 or fewer employees. Id.
  Thus, using the SBA’s size standard the majority of incumbent LECs can be considered small entities.   
27. 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. See 13 CFR § 121.201.  The Wired Telecommunications Carrier category formerly used the NAICS code of 517110.  As of 2017, the U.S. Census Bureau definition shows the NAICs code as 517311 for Wired Telecommunications Carriers.  See U.S. Census Bureau, See U.S. Census Bureau, 2017 NAICS Definition, https://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=517311&search=2017.
  U.S. Census Bureau data for 2012 indicate that 3,117 firms operated during that year. See U.S. Census Bureau, 2012 Economic Census of the United States, Table No. EC1251SSSZ5, Information: Subject Series - Estab & Firm Size: Employment Size of Firms: 2012 (517110 Wired Telecommunications Carriers). https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/51SSSZ5//naics~517110.
  Of that number, 3,083 operated with fewer than 1,000 employees. Id.
  Based on these data, the Commission concludes that the majority of Competitive LECs, CAPs, Shared-Tenant Service Providers, and Other Local Service Providers are small entities.  According to Commission data, 1,442 carriers reported that they were engaged in the provision of either competitive local exchange services or competitive access provider services. See Trends in Telephone Service, at tbl. 5.3.
  Of these 1,442 carriers, an estimated 1,256 have 1,500 or fewer employees. Id.
  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. Id.
  In addition, 72 carriers have reported that they are Other Local Service Providers. Id.
  Of this total, 70 have 1,500 or fewer employees. Id.
  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. 
28. 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 Wired Telecommunications Carrier category formerly used the NAICS code of 517110.  As of 2017, the U.S. Census Bureau definition shows the NAICs code as 517311 for Wired Telecommunications Carriers.  See U.S. Census Bureau, See U.S. Census Bureau, 2017 NAICS Definition, https://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=517311&search=2017.
  The applicable size standard under SBA rules is that such a business is small if it has 1,500 or fewer employees. Id. 
  U.S. Census Bureau data for 2012 indicate that 3,117 firms operated for the entire year. U.S. Census Bureau, 2012 Economic Census of the United States, Table No. EC1251SSSZ5, Information: Subject Series - Estab & Firm Size: Employment Size of Firms: 2012 (517110 Wired Telecommunications Carriers). https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/51SSSZ5//naics~517110.
  Of that number, 3,083 operated with fewer than 1,000 employees. Id.
  According to internally developed Commission data, 359 companies reported that their primary telecommunications service activity was the provision of interexchange services. See Trends in Telephone Service, at tbl. 5.3.
  Of this total, an estimated 317 have 1,500 or fewer employees. Id.
  Consequently, the Commission estimates that the majority of interexchange service providers are small entities.
29. Local Resellers.  The SBA has developed a small business size standard for Telecommunications Resellers which includes Local Resellers. See 13 CFR § 121.201; NAICS Code 517911.
  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. U.S. Census Bureau, 2012 NAICS Definition, NAICS Code 517911 “Telecommunications Resellers,”, https://www.census.gov/cgi-bin/sssd/naics/naicsrch?input=517911&search=2017+NAICS+Search&search=2017.  
  Establishments in this industry resell telecommunications; they do not operate transmission facilities and infrastructure. Mobile virtual network operators (MVNOs) are included in this industry. Id.
  Under the SBA’s size standard, such a business is small if it has 1,500 or fewer employees. 13 CFR § 121.201; NAICS Code 517911.
  U.S. Census Bureau data for 2012 show that 1,341 firms provided resale services for the entire year. See U.S. Census Bureau, 2012 Economic Census of the United States, Table No. EC1251SSSZ5, Information: Subject Series - Estab & Firm Size: Employment Size of Firms: 2012 (517911 Telecommunications Resellers), https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/51SSSZ5//naics~517911.
  Of that number, all operated with fewer than 1,000 employees. Id. 
  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. See Trends in Telephone Service, at tbl. 5.3.
  Of these, an estimated 211 have 1,500 or fewer employees. Id.
  Consequently, the Commission estimates that the majority of Local Resellers are small entities.
30. 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. U.S. Census Bureau, 2012 NAICS Definitions, “517210 Wireless Telecommunications Carriers (Except Satellite),” See https://factfinder.census.gov/faces/affhelp/jsf/pages/metadata.xhtml?lang=en&type=
ib&id=ib.en./ECN.NAICS2012.517210
  The appropriate size standard under SBA rules is that such a business is small if it has 1,500 or fewer employees. 13 CFR § 121.201, NAICS code 517210.
  For this industry, U.S. Census Bureau data for 2012 show that there were 967 firms that operated for the entire year. U.S. Census Bureau, 2012 Economic Census of the United States, Table EC1251SSSZ5, Information: Subject Series: Estab and Firm Size: Employment Size of Firms for the U.S.: 2012 NAICS Code 517210.  https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/51SSSZ5//naics~517210.
  Of this total, 955 firms had had employment of 999 or fewer employees and 12 had employment of 1000 employees or more. Id.  Available census data does not provide a more precise estimate of the number of firms that have employment of 1,500 or fewer employees; the largest category provided is for firms with “1000 employees or more.”
  Thus, under this category and the associated size standard, the Commission estimates that the majority of wireless telecommunications carriers (except satellite) are small entities.  
31. 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. See Federal Communications Commission, Universal Licensing System, http://wireless.fcc.gov/uls (last visited Sept. 1, 2018).  For the purposes of this FRFA, consistent with Commission practice for wireless services, the Commission estimates the number of licensees based on the number of unique FCC Registration Numbers.  
  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.  Trends in Telephone Service, at tbl. 5.3.
  Of this total, an estimated 261 have 1,500 or fewer employees, and 152 have more than 1,500 employees. See id.
  Thus, using available data, we estimate that the majority of wireless firms can be considered small.  
32. 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. Amendment of the Commission’s Rules to Establish Part 27, the Wireless Communications Service (WCS), Report and Order, 12 FCC Rcd 10785, 10879, para. 194 (1997).
  The SBA has approved these small business size standards. See Letter from Aida Alvarez, Administrator, SBA, to Amy Zoslov, Chief, Auctions and Industry Analysis Division, Wireless Telecommunications Bureau, FCC (filed Dec. 2, 1998) (Alvarez Letter 1998).
  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.
33. 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). U.S. Census Bureau, 2012 NAICS Definitions, 517210 Wireless Telecommunications Carriers (Except Satellite), https://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=517210&search=2012+NAICS+Search.
 Under the SBA small business size standard a business is small if it has 1,500 or fewer employees. Id.
  For this industry, U.S. Census Bureau data for 2012 show that there were 967 firms that operated for the entire year. U.S. Census Bureau, 2012 Economic Census of the United States, Table EC1251SSSZ5, Information: Subject Series: Estab and Firm Size: Employment Size of Firms for the U.S.: 2012 NAICS Code 517210 (rel. Jan. 8, 2016).  https://factfinder.census.gov/bkmk/table/1.0/en/ECN/2012_US/51SSSZ5//naics~517210. 
  Of this total, 955 firms had fewer than 1,000 employees and 12 firms has 1000 employees or more. Id.  Available census data do not provide a more precise estimate of the number of firms that have employment of 1,500 or fewer employees; the largest category provided is for firms with “1000 employees or more.”
 Thus under this category and the associated size standard, the Commission estimates that a majority of these entities can be considered small.  According to Commission data, 413 carriers reported that they were engaged in wireless telephony. Trends in Telephone Service, tbl. 5.3.
  Of these, an estimated 261 have 1,500 or fewer employees and 152 have more than 1,500 employees. Id.
  Therefore, more than half of these entities can be considered small.
E. Description of Projected Reporting, Recordkeeping, and Other Compliance Requirements for Small Entities 
34. The Report and Order enacts rules that will affect the reporting, recordkeeping, and/or other compliance requirements of small businesses and enterprises of all sizes that are engaged in the business of manufacturing, importing, selling, leasing, installing, managing, or operating MLTS, provided that the MLTS is manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020.  The Report and Order will also affect small businesses and enterprises that are engaged in the business of offering fixed telephony service, wireless telecommunications, interconnected VoIP service, and TRS.  The Commission adopted these changes to implement Kari’s Law and RAY BAUM’S Act, which collectively address the inability of callers to directly dial 911 from MLTS and a lack of accurate and critical location information necessary for a PSAP to dispatch emergency services to those in need because of the communications system used in making a 911 call.  
35. The rules and compliance requirements the Commission adopted to implement the direct dialing and notification requirements of Kari’s Law sought to balance the needs of stakeholders and maximize the public safety benefits.  These benefits include potentially preventing fatalities, injuries, or property damage, improving emergency response time and access to emergency services, reducing delays in locating 911 callers, narrowing the gap between MLTS 911 service capabilities relative to other communications services subject to 911 requirements, and driving further technology development.  The Commission also sought to achieve the benefits of Kari’s Law in a cost-effective manner.  As a result, the rules adopted generally track the statutory requirements of Kari’s Law, are technologically neutral, and leverage advances in technology to improve access to emergency services as envisioned by Congress.  
36. The adopted rules provide small businesses and other enterprises impacted by these requirements wide flexibility and adopt minimum criteria in direct dialing and notification requirements which should offset any potential burdens associated with compliance with our rules.  
37. Consistent with Kari’s Law, the Commission establishes February 16, 2020, as the compliance date for regulations implementing Kari’s Law.  It declines to adopt disclosure requirements for legacy MLTS but, instead, encourages industry to consider disclosure and education as part of voluntary best practices.  The Commission also adopts a presumption that if an MLTS fails to comply with the rules, the MLTS manager is responsible unless the manager can rebut the presumption by demonstrating compliance with its obligations under the statute and rules.  
38. Similar to its approach to implement the requirements of Kari's Law, the Commission sought to craft dispatchable location rules that leverage existing market-driven advances in technology to improve location accuracy, and that provide small businesses and others significant flexibility, are technology neutral, encourage innovation and allow a wide array of options to for compliance while minimizing the compliance burden and cost.  Given the lack of cost data submitted in the record for meeting our 911 location rules or MLTS direct dialing and notification requirements, and in light of our flexible and technologically neutral approach to compliance, we do not believe compliance with these requirements will impose a significant economic burden for small businesses.
39. Similarly, we do not believe that the new or modified information collection requirements in sections 9.8(a); 9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4); 9.11(b)(5)(ii); (iii); 9.14(a)(2); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v); 9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); 9.16(b)(3)(i); (ii); and (iii), will be unduly burdensome on small businesses.  Rather than unduly burden small entities, applying the new and modified information collections will promote 911 service and emergency response, which should benefit small governmental jurisdictions, small businesses, small equipment manufacturers, and small business associations by giving them greater confidence in 911 location accuracy.  Moreover, the rules we adopt in the Report and Order provide regulatory flexibility to all entities, including small businesses, and encourage service providers to leverage technology to the extent possible to reduce the burden of the information collections adopted in the Report and Order.  Additionally, the Report and Order establishes a one- to two-year period from the effective date of the rules before requiring compliance with the revised rules.  We provide the following analysis:
40. For compliance with the Commission’s 911 requirements, interconnected VoIP service providers must collect and disclose certain information to third parties.  OMB approved the information collection for section 9.5 (redesignated section 9.11) under OMB Control No. 3060-1085.  This collection applies to interconnected VoIP providers obtaining and updating registered location from their customers and placing that information into ALI databases.  This collection also applies to interconnected VoIP providers’ customer notification obligations.  The Commission modifies the definition of interconnected VoIP, thus potentially increasing the number of respondents subject to these existing information collections.  The Commission also changes the wording of section 9.11’s registered location requirements to facilitate the provision of automated dispatchable location, registered location, or alternative location information for 911 calls.  Thus, we anticipate the burden and cost levels of these requirements would be comparable to the existing Registered Location and customer notification requirements, which OMB approved. 
41. TRS service providers must collect and disclose certain information to third parties for compliance with the Commission’s 911 rules.  OMB approved the information collection for section 64.604 (redesignated as section 9.14) under OMB Control No. 3060-1089.  This collection applies to TRS service providers transmitting location information to the PSAP, making location information available to the appropriate PSAP through the ALI database, and obtaining location information from the user.  The Commission makes changes to the wording of Section 9.14’s registered location requirements to facilitate the provision of automated dispatchable location, registered location, or alternative location information for 911 calls.  Thus, we anticipate the burden and cost levels of these requirements would be comparable to the existing location requirements, which OMB approved.  
42. Covered text providers must notify consumers that they must grant permission to covered text providers to access the device’s location information to enable the delivery and routing of text messages to PSAPs (i.e. Text-to-911) under section 20.18 (redesignated as 9.10).  OMB renewed the information collection under OMB Control No. 3060-1204, ICR Reference No: 201802-3060-012.  In this Report and Order, the Commission makes changes to the wording of section 9.10’s text-to-911 requirements to facilitate the provision of dispatchable location or best available location information along with 911 text messages.  Thus, we anticipate the burden and cost levels of these requirements will require covered text providers to update customer notification at a cost that would be comparable to the existing text-to-911 requirements, which OMB approved.       
43. Finally, new section 9.8 requires providers of fixed telephony services to provide automated dispatchable location with 911 calls beginning one year after the effective date of this rule.  Additionally, new section 9.16(b)(3)(i), (iii) and (iii) specifies dispatchable location requirements for on-premises fixed telephones; on premises non-fixed devices; and off-premises devices associated with a multi-line telephone system.  The Report and Order reflects that the costs to implement these requirements would be minimal.  For purposes of estimating projected costs to small businesses, we find that the costs would be comparable to the costs CMRS service providers incur in delivering uncompensated barometric pressure data, which OMB approved under OMB Control No. 3060-1210, ICR Reference No: 201801-3060-010.  Current rule section 20.18 (redesignated as 9.10) requires that CMRS providers shall deliver uncompensated barometric pressure data from any device capable of delivering such data to PSAPs.  The Commission stated that the furnishing of this information to PSAPs is necessary to ensure that PSAPs are receiving all location information possible to be used for dispatch.  
F. Steps Taken to Minimize the Significant Economic Impact on Small Entities, and Significant Alternatives Considered
44. The RFA requires an agency to describe any significant, specifically small business alternatives, that it has considered in reaching its approach, which may include the following four alternatives (among others): (1) the establishment of differing compliance or reporting requirements or timetables that take into account the resources available to small entities; (2) the clarification, consolidation, or simplification of compliance or reporting requirements under the rule for small entities; (3) the use of performance, rather than design, standards; and (4) an exemption from coverage of the rule, or any part thereof, for small entities. See 5 U.S.C. § 603(c)(1)-(4).
  To minimize any significant impact on small businesses, the Commission establishes a longer timetable for compliance timetable than that proposed in the Notice relative to dispatchable location requirements.  The Report and Order clarifies that the rules are flexible and technologically neutral so that small businesses may choose from a broad array of options to comply with the Commission’s rules.  We provide the following analysis of our rules. 
45. Direct Dialing and Notification Requirements for a Multi-Line Telephone System.  The Commission takes a number of steps in the Report and Order to provide flexibility and reduce costs for small businesses and other enterprises.  As a preliminary matter, Kari’s Law provides that the central notification requirements of the statute apply only if the MLTS can be configured to provide notification “without an improvement to the hardware or software of the system.” Notice, 33 FCC Rcd at 8995, para. 33 (citing 47 U.S.C. § 623(c)). 
  The legislative history of Kari’s Law notes that this provision is intended to “balance the need for an onsite notification with the goal of not placing an undue burden on MLTS owners or operators.” Section-by-Section Analysis of H.R. 582, 163 Cong. Rec. H589 (daily ed. Jan. 23, 2017).
  The Commission adopts rules to implement and clarify this provision.
46. The Commission requires the notification to include the fact that a 911 call has been made, a valid callback number, and the same location information that is conveyed with the call to 911.  However, the Commission also provides an exception for callback number and location information in circumstances where including this information in the notification would be technologically infeasible.  In addition, the Commission requires that initiation of the notification be contemporaneous with the call to 911, conditioned on whether it is technologically feasible to do so.  The Commission also requires that notifications be sent to a location where someone is likely to hear or see the notification but does not require the location to be continuously staffed or monitored.  The absence of a continuous staffing or monitoring requirement minimizes a potentially significant cost for small businesses.  The Report and Order also clarifies that an MLTS must be configured to provide notification for any caller on the system, including callers at satellite or branch locations.  These requirements are highly flexible and give enterprises, including small businesses, significant latitude to configure suitable notification mechanisms without unreasonable burden or cost.  
47. Consistent with Kari’s Law, the Commission establishes February 16, 2020, as the compliance date for the regulations implementing the statute.  The Commission also affords all entities flexibility, including small businesses, to come into compliance with the notification requirements of Kari’s Law.  This should give enterprises, including small businesses, sufficient advance notice to make informed manufacturing, planning, and purchasing decisions.  In addition, because the statute and regulations apply to MLTS that are manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020, enterprises have the flexibility to retain an existing MLTS until the end of its useful life should they choose to do so.  The Commission declines to adopt disclosure requirements for existing MLTS and, instead, encourages industry to consider disclosure and education as part of voluntary best practices.  This avoids “one-size-fits-all” disclosure requirements and allows enterprises the flexibility to disclose the limitations of calling 911 from legacy MLTS in a way that makes sense for their particular business.
48. Dispatchable Location.  In the Report and Order, the Commission adopts rules to implement the dispatchable location requirements that are measured, technologically neutral and include a phased-in compliance timetable in order to minimize implementation costs, and leverage technological advances.  The Commission’s measured approach seeks to minimize costs and burdens for small businesses and other enterprises where possible, while providing these MLTS and communications service providers significant flexibility to comply with the rules adopted.  For example, small businesses can take advantage of the option for MLTS and other communication service providers subject to 911 requirements that are unable to provide a dispatchable location consistent with the rules adopted in the Report and Order, to elect to provide alternative location information, and incur minimal to no implementation costs as a result.  Moreover, the Commission’s decision not to mandate any particular technology or model for implementing the 911 location rules gives small businesses the ability choose a compliance approach that best fits their economic circumstances.  Because delivering dispatchable location is already technically feasible for many services today, MLTS and other service providers subject to our 911 location rules need only choose the methods necessary to close the gap between already-deployed capabilities and the Commission’s requirements, “rather than starting from scratch” which should prove less costly for small businesses.  Similarly, the Commission’s decision to implement a phased-in approach for compliance and to tailor compliance deadlines to particular technologies rather than adopting a hard and fast, “one size fits all” approach takes into account the needs of small businesses for flexibility and a longer compliance timeframe.  Additionally, by apply the adopted rules on a prospective basis, the Commission will minimize costs for small businesses and legacy MLTS systems.
49. Finally, the Commission considered adopting a small business exemption for our dispatchable location requirements but declined to adopt such an exemption because the flexible rules afford small businesses a broad menu of options for compliance that we believe are scalable in ways to make them cost-effective for small businesses.  Further, the proposed criteria for small business exemptions would have undermined the purpose of the dispatchable location rules, i.e., to improve location accuracy, while offering no countervailing reduction in compliance costs.  Rather than an exemption that relies on proposed criteria that would have little or no practical effect on small businesses, we believe the flexible and scalable rules that we adopt will minimize burdens on small businesses while advancing Congress’s location accuracy goals.
50. Rule Consolidation.  The Report and Order also consolidates various 911 rules into a single rule part, i.e., part 9, to the extent practicable.  As part of this consolidation, the Commission simplifies and streamlines the rules in some instances and eliminates corresponding duplicative rules in other rule parts.  We believe the rule consolidation helps to minimize the burden on small entities subject to the Commission’s 911 rules because it simplifies and streamlines the rules, making it easier for small entities to identify and understand what’s required to comply with all 911 requirements.  
51. Report to Congress. The Commission will send a copy of the Report and Order, including this FRFA, in a report to Congress pursuant to the Congressional Review Act. See 5 U.S.C. § 801(a)(1)(A).
  In addition, the Commission will send a copy of the Report and Order, including this FRFA, to the Chief Counsel for Advocacy of the SBA.  A copy of the Report and Order, and FRFA (or summaries thereof) will also be published in the Federal Register. See 5 U.S.C. § 604(b).
 

174
APPENDIX D

List of Commenting Parties

Comments

ADT LLC d/b/a ADT Security Services (ADT) 
Alliance for Telecommunications Industry Solutions (ATIS) 
Association of Public-Safety Communications Officials-International, Inc. (APCO) 
AT&T Services, Inc. (AT&T) 
Ad Hoc Telecommunications Users Committee (Ad Hoc) 
American Cable Association (ACA) 
American Hotel and Lodging Association (AHLA) 
Avaya, Inc. (Avaya)
Bandwidth Inc. (Bandwidth) 
BluIP, Inc. (BluIP)
Boulder Regional Emergency Telephone Service Authority (BRETSA)
Cisco Systems, Inc. (Cisco)
Comtech Telecommunications Corp. (Comtech)
Dave Moore
DECT Forum
Hamilton Relay, Inc.
Metropolitan Emergency Services Board (MESB)
Microsoft Corporation (Microsoft)
National Association of State 911 Administrators (NASNA)
National Public Safety Telecommunications Council (NPSTC)
NCTA – The Internet & Television Association (NCTA)
NENA: The 9-1-1 Association (NENA)
NTCA – The Rural Broadband Association (NTCA)
Panasonic Corporation of North America (Panasonic)
RedSky Technologies Inc., (RedSky)
RingCentral, Inc. (RingCentral)
Sorenson Communication, LLC (Sorenson)
State of Florida Department of Management Services, Division of Telecommunications, Bureau of Public Safety (Bureau)
Telecommunications Industry Association (TIA)
Texas 9-1-1 Alliance, the Texas Commission on State Emergency Communications, and the Municipal Emergency Communication Districts Association (Texas 9-1-1 Entities)
USTelecom – The Broadband Association (USTelecom)
Verizon
Voice on the Net Coalition (VON)
West Safety Services, Inc. (West Safety)

Reply Comments
Ad Hoc
ACA
BRETSA
Cisco
ClearCaptions, LLC (ClearCaptions)
Comcast Corporation (Comcast)
Comtech
INCOMPAS
Industry Council for Emergency Response Technologies (iCERT)
RedSky
RingCentral
Sorenson and CaptionCall, LLC (CaptionCall)
T-Mobile USA, Inc. (T-Mobile)
Telecommunication Industry Association and DECT Forum (TIA and DECT Forum)
West Safety 

Ex Parte Comments Related to Issues Resolved in the Report and Order
ACA Connects, April 22, 2019
ACA Connects, July 25, 2019
APCO, April 22, 2019
APCO, July 26, 2019
Apple Inc., July 25, 2019
Avaya, July 22, 2019
Cisco, May 22, 2019
Cisco, July 24, 2019
Cisco, July 26, 2019
City of New York, July 29, 2019
ClearCaptions, February 8, 2019
Hamilton Relay, July 25, 2019
INCOMPAS, July 26, 2019
INCOMPAS, July 26, 2019 (also including WC Docket Nos. 19-195, 11-10)
IT&E, July 24, 2019 
Micronesian Telecommunications Corporation and PTI Pacifica Inc. dba IT&E (IT&E), July 24, 2019
Microsoft, June 26, 2019
Microsoft, July 26, 2019
National Association of Regulatory Utility Commissioners (NARUC), September 18, 2018
Precision Broadband LLC (Precision), May 30, 2019
Precision, June 19, 2019
Precision, June 20, 2019
Precision, June 27, 2019
Precision, July 1, 2019
Precision, July 17, 2019 (Corrected Precision June 27, 2019)
RingCentral, December 7, 2018
RingCentral, December 20, 2018
RingCentral, July 8, 2019
RingCentral, July 25, 2019
Sorenson and CaptionCall, March 21, 2019
Sorenson and CaptionCall, May 24, 2019
Sorenson and CaptionCall, June 27, 2019
TIA and DECT Forum, March 25, 2019
VON, May 24, 2019


STATEMENT OF
CHAIRMAN AJIT PAI
Re: 	Implementing Kari’s Law and Section 506 of RAY BAUM’S Act, PS Docket No. 18-261; 911 Access, Routing, and Location in Enterprise Communications Systems, PS Docket No. 17-239; Wireless E911 Location Accuracy Requirements, GN Docket No. 11-117.

One man with courage makes a majority.  There’s a dispute about whether that old saying originated with Andrew Jackson.  But today, there should be no dispute that Hank Hunt embodies the truth of this aphorism.
Over five years ago, Hank’s daughter Kari was murdered by her estranged husband in a Marshall, Texas hotel room.  Her then-nine-year old daughter tried to call 911 four times, as she had been taught to do.  But her calls for help never went through because the hotel’s phone system required guests to dial 9 before calling 911.
No one would have blamed Hank had he dealt with his grief privately and then tried to find a way to move on from this tragedy.  As a father, I can’t imagine how the days and months following Kari’s death must have been for him.  But Hank wasn’t finished.  Instead, he launched a nationwide movement for change.  He demanded that action be taken to solve the problem that led to his daughter’s death.
What began with one man in East Texas soon became a nationwide movement.  And that nationwide movement eventually led to congressional action.  Kari’s Law passed the U.S. House of Representatives by a vote of 408-0.  And it passed the U.S. Senate by unanimous consent.  One man with courage didn’t just produce a majority; he produced unanimity.  And given the state of politics in our nation’s capital these days, that was a remarkable accomplishment.
Then, on February 16, 2018, President Trump signed Kari’s Law in the Oval Office.  Hank and I were there that day.  And Kari’s daughter was there as well, and she had the chance to speak with the President.  It was a special event that I will never forget.
With the President’s signature, the baton was passed to the FCC.  And we began to run with it.  Last year, we proposed rules to implement Kari’s Law.  And today, we are adopting those rules.  In particular, these rules will make it easier for Americans in hotels, office buildings, and campuses to dial 911 and reach the help that they need in an emergency.  And they will make it more likely than when such a 911 call is placed, an on-site notification is provided so that an employee can help speed response times when emergency personnel arrives.
We’re also adopting rules pursuant to another piece of legislation, RAY BAUM’s Act, which require the conveyance of dispatchable location with a 911 call regardless of the technological platform used.  This is another important step forward that will help emergency personnel find 911 callers more quickly and thus save lives.
But today, I think that the spotlight should be on Hank.  Today brings to a close the legislative and regulatory journey that traces back to a Marshall, Texas hotel room.  None of this would have happened without the strength and fortitude of Hank.  Had he not chosen to embrace this issue and demand action, there would be no Kari’s Law, and we would not be here today taking the final step to implement this piece of legislation.
But he did act, and we are here.  Nothing that we do or say can ever bring back his daughter.  But because of what Hank has done, Kari will not be known only for her tragic death.  She will be remembered as the inspiration for the law bearing her name and the rules we are adopting which will save lives.  While I never had the privilege of meeting Kari, from speaking to those who did know her, that is a fitting legacy.  And it is one that has been secured by the efforts of one man with courage who has made a majority:  Hank Hunt.
Before closing, I’d also like to thank Commissioner Carr, who worked hard on this issue when serving as a Legal Advisor in my office.  And a special thanks to the FCC staff who furthered Kari’s memory by working on this important item:
William Beckwith, Brenda Boykin, Ken Carlberg, Elizabeth Cuttner, Tom Eng, John Evanoff, Lisa Fowlkes, David Furth, Erika Olsen, Rasoul Safavian, and Michael Wilhelm from the Public Safety and Homeland Security Bureau; Robert Aldrich, Rosaline Crawford, Elliot Greenwald, Michael Scott, and Suzy Rosen Singleton from the Consumer and Governmental Affairs Bureau; Jason Koslovsy, Chris Killion, and Jeremy Marcus from the Enforcement Bureau; Jennifer Gilsenan from the International Bureau; Chana Wilkerson from the Office of Communications Business Opportunities;  Jamison Prime from the Office of Engineering and Technology; Malena Barzilai, David Horowitz, William Richardson, and Anjali Singh from the Office of General Counsel; Rosa Bell from the Office of the Secretary;  Eric Burger, Chuck Needy, and Emily Talaga from the Office of Economic Analysis; Michele Berlove, Lisa Hone, Daniel Kahn, and Terri Natoli from the Wireline Competition Bureau; Jonathan Campbell from the Wireless Telecommunications Bureau.


STATEMENT OF
COMMISSIONER MICHAEL O’RIELLY

Re: 	Implementing Kari’s Lay and Section 506 of RAY BAUM’S Act, PS Docket 18-261; Inquiry Concerning 911 Access, Routing, and Location in Enterprise Communications Systems, PS Docket No. 17-239; Amending the Definition of Interconnected VoIP Service in Section 9.3 of the Commission’s Rules, GN Docket No. 11-117.

Today, the Commission adopts an item implementing two different, but related, statutory provisions in Kari’s Law and RAY BAUM’S Act, both enacted by Congress in 2018.  When Congress speaks and provides direction to the Commission, it is our obligation to implement its will.  For this reason, I will approve today’s item. 
There are, however, some issues with the item that I must note.  While a good part of the Kari’s Law section generally appears to implement the statute as written, there is one significant part that doesn’t seem to match up.  Specifically, the law’s 911 direct dialing and notification requirements apply to MLTS, which is defined, in pertinent part, 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….” 47 U.S.C. § 1471(2). 
  The Commission, however, expands that definition to include cloud-based IP technology and over-the-top applications that are not contemplated in the statutory definition.  And, I think that is problematic, even if I am going to support the entirety of the item.    
The Commission appears to think that, because the definition of MLTS from 2012 refers to systems such as VoIP, which was a newer technology at the time, Congress meant to capture all future technologies that can be used for MLTS without explicitly saying so.  It is as if the Commission believes that Congress isn’t capable of adding or is unfamiliar with over-the-top apps and the cloud.  To add to this, the item justifies this expansion by stating that “there is no language in the statute specifically excluding cloud-based IP technology and over-the-top applications from the definition of MLTS.”  I am at a loss for words to think that an agency can read any language it wants into a statute if not specifically banned, and I am surprised that my colleagues are being so whimsical about Congressional intent.  Congress needs to be on notice that their statutory language must be exact, to the point of explicitly noting what technologies are not included and possibly even technologies not used or in existence at the time, or else an agency has carte blanche to do whatever it wants in the future.  
The Commission also flat out ignores that Congress clearly knows how to broadly apply a statute to myriad technologies, because the same, exact Congress, in section 506 of the RAY BAUM’S Act, directed the Commission to look at whether dispatchable location could be transmitted with a 911 call “regardless of the technological platform used.” Repack Airwaves Yielding Better Access for Users of Modern Services Act of 2018, Pub. L. No. 115-141, §506, 132 Stat. 348, 1095.
  Congress could have easily done the same thing in Kari’s Law, but it didn’t.  Maybe it meant to or maybe it didn’t but just saying that the expanded definition is not banned by law is the worst type of agency arrogance I can imagine.    
In particular, the Commission unilaterally decides to include two other technologies, which then leads to an exhaustive discussion of all the possible permutations of who is responsible and liable for compliance as a manager, operator, installer, manufacturer, or owner of an such a system.  In the end, the party responsible will be determined on a case-by-case basis.  Shockingly, this is likely to lead to inconsistent enforcement actions and enhance regulatory uncertainty.  That’s good news for contract attorneys to draft creative indemnification clauses and descriptions of what tasks are performed by which parties.  Not to mention, as I raised in my statement to the 2018 Notice, I am not even sure how we can enforce this rule when apps and cloud-based systems can be developed, updated and distributed from anywhere in the world.  And, of course, there is no real cost-benefit analysis of how much these additions will cost industry.
As for the RAY BAUM’S Act section, Congress told the Commission to broadly “consider” dispatchable location for 911 calls. Id.
  Therefore, the question is not whether we can, but, instead, whether we should regulate.  The Commission has recognized that dispatchable location is the gold standard for 911 location accuracy and has been headed that direction in the context of wireless services, which make up a large percentage of 911 calls and continues to increase.  I strongly support providing first responders with the best location information possible, but recognize that in many circumstances dispatchable location and floor information are not technically feasible today.
My first concern is that the Commission requires different levels of location accuracy depending upon technology.  For example, there is fixed MLTS, non-fixed on-premises MLTS, non-fixed off-premises MLTS, and non-fixed interconnected VoIP.  The Commission applies a more flexible location standard for non-fixed, off-premises MLTS location accuracy than non-fixed VoIP, even though industry participants argue that determining an approximate in-building location, including the floor level, is challenging in both instances and the more flexible standard should be applied to both.  I am not sure if we got this right, and it is possible that the Commission may have to reconsider this issue in the future.
Further, there are submissions in the record that discuss the possible unintended consequences of requiring the delivery of outbound-only interconnected VoIP calls to 911.  When such calls have connected to emergency call centers, the calls have been of very short duration, indicating possible misdials or nefarious activity.  Concerns have been raised that this could create a situation similar to non-service initialized, or NSI, phones, which public safety has recognized are used in a high percentage of fraudulent 911 calls.  Instead of dismissing these concerns, the Commission should have considered this further, because, as we have learned with NSI phones, once you implement these rules, it is hard to undue them without concerns being raise about the one legitimate call that was could be missed and the legal liability that can result if it is not connected to a call center.
Finally, the cost-benefit analysis is lacking.  It primarily discusses what we stated in the Notice, which is mostly based on comparing the potential cost against the benefit of a hypothetical number of lives being saved based on the flawed “Value of a Statistical Life” metric.  Now that the Office of Economic and Analysis is up and running, we must do better.
In the end, the bulk of the item should enhance the safety of the public when it uses MLTS.  That should be lauded and applauded, even if some elements of it should have been resolved differently.  


STATEMENT OF
COMMISSIONER BRENDAN CARR

Re: 	Implementing Kari’s Law and Section 506 of RAY BAUM’S Act, PS Docket No. 18-261; Inquiry Concerning 911 Access, Routing, and Location in Enterprise Communications Systems, PS Docket No. 17-239; Amending the Definition of Interconnected VoIP Service in Section 9.3 of the Commission’s Rules, GN Docket No. 11-117.

I have no idea what it’s like to lose a child.  I hope never to find out.  My sons are the reason why I get up in the morning; my wife and I structure our lives around them, around their needs, around giving them every opportunity for joy, and learning, and growth.  That’s what parents do.  To lose one of our little ones would be beyond words, beyond “devastating” or “tragic.”  Strong people could be swallowed by those emotions.
Hank and DJ Hunt did something different when they lost Kari.  They made a promise.  In Hank’s words, “I made a promise to a nine-year-old,” his granddaughter, “that I’d fix it.  Boy I was scared to death I’d never be able to hold up that promise, but I found the right people to help me with that.”
Hank was being modest.  The truth is Hank went to state legislators, he went to governors, including his own, Governor Abbott.  He brought Commissioner Pai down to Texas and worked with him to push industry reform and change the FCC’s own phone system.  I watched with my own eyes as Hank buttonholed a Congressman to explain the problem that many didn’t understand.  The phone systems in large complexes such as hotels, offices, or schools often didn’t allow for direct dial 9-1-1 calls.  When 9-1-1 calls did go through, there weren’t proper notifications to staff at the complexes, and staff often weren’t trained on how to handle those emergencies.  “We don’t teach our children to dial an extra digit or pre-fix number.  We teach them to call 9-1-1,” Hank said.  “Your phone’s already capable of doing it.  Make your phone work.  Just make it work.”
Hank kept at it.  He started an online petition that gained more than 600,000 supporters.  Illinois, Maryland, Oklahoma, Pennsylvania, and Tennessee changed their laws.  Hank was in Austin when Governor Abbott signed a version of Kari’s Law for Texas.  And on February 9, 2018—Kari’s 36th birthday—Congress passed Kari’s Law for our entire country.  Of course Hank was there, in the Oval Office, when President Trump signed it into law.
As passage of Kari’s Law in Congress became certain, Hank for a moment could reflect on the journey from his loss to the accomplishment of protecting so many Americans.  “It’s going to be hard to figure out what to do the next day when I get up,” he said, “because every day for the past four years has been: Kari’s Law, who do I need to contact, who do I need to call, am I supposed to be anywhere?”  That was a year-and-a-half ago, and Hank’s still at it.  He has appeared in PSAs to encourage schools to comply with Kari’s Law at the state level, and it is our great honor to welcome him to the Commission today as we implement at the federal level the law he fought so hard for.
Hank, we are sorry for what DJ and you have gone through.  We thank you for your astounding strength and perseverance through all of it—and for turning your loss into help for others.  It is because of your efforts that we apply Kari’s Law today.  Your daughter’s memory will save the lives of other sons and daughters, who will never know you but will be blessed by your family’s contributions to our country.  And so it’s a privilege to vote for your work in memory of Kari.  You have my gratitude, and the item has my strong support.	


STATEMENT OF
COMMISSIONER JESSICA ROSENWORCEL
APPROVING IN PART, DISSENTING IN PART

Re: 	Implementing Kari’s Law and Section 506 of RAY BAUM’s Act, Inquiry Concerning 911 Access, Routing, and Location in Enterprise Communications Systems, Amending the Definition of Interconnected VoIP Service in Section 9.3 of the Commission’s Rules, PS Docket Nos. 18-261, 17-239, GN Docket No. 11-117, Report and Order (August 1, 2019).

In October of 1999, Congress designated 911 as the nationwide emergency number.  Today, there are more than 240 million calls made to 911 every year.  It’s the number we count on when the unthinkable occurs.
That’s what happened in December of 2013, when a nine-year old girl frantically dialed 911 for help from inside an East Texas hotel room.  That call never went through.  What she did not know was that the hotel’s phone system first requires dialing “9” just to reach an outside line.
This is the worst kind of tragedy.  It was preventable.  And I thank the Chairman for bringing this story to this agency’s attention and putting the shortcomings of multi-line telephone systems in the spotlight.
As a result, last year Congress passed Kari’s Law, which aims to ensure that multi-line telephone systems like the one in that East Texas hotel room can directly call emergency services by dialing 911 without first dialing an access code.  Today, we take steps to implement this new law here at the Federal Communications Commission.  I am glad the Chairman has chosen to so expeditiously.  This will save lives.
But this moment is bittersweet, for two reasons.  First, our efforts today stem from tragedy.  Second, our efforts do not go far enough to prevent another failure like the one that resulted in loss of life in that hotel room in December of 2013.  
Let me explain.  Today’s order is meant to ensure that the public can directly call 911 from any multi-line telephone system.  But our policies only apply on a going forward basis.  That means nothing in our rules will require that East Texas hotel—or any other business operating a multi-line telephone system today—to change their system.
This is a glaring omission.  That’s why I asked to have this agency adopt rules that will require these businesses to inform the public about the 911 capabilities and limitations of their phone systems.  But that request was rejected.
It’s why I asked to have this agency seek comment on what kind of upgrades to existing multi-line telephone systems would trigger a requirement to comply with our new rules, so we might speed the transition to a world where every phone is capable of directly dialing 911.  But that request was rejected.
It’s why I asked that we adopt a timetable for bringing these systems into compliance with at least our 911 location requirements, instead of exempting them entirely.  Indeed, the record evidence shows that most multi-line telephone systems today are capable of providing location information to first responders.  Those that can’t may need only a relatively small software upgrade.  There is no sensible reason, then, to allow operators of these systems to continue avoiding the rules.
The reality is that in December 2013 a 911 call failed because the caller was not appropriately informed about how to use a multi-line telephone system to reach out for emergency assistance.  Now, as new calling systems come to market that are capable of reaching 911 directly, this confusion will only grow.  In fact, it’s already happening.  Just read press stories about Kari’s Law.  Many of them suggest that starting in February of 2020, you will be able to dial 911 from any multi-line telephone system.  But we know that with millions and millions of old telephone lines still out there operating on these systems, this is not true.  We should be clearing up this confusion.  It could cost lives.  
In closing, I fully support our efforts today to ensure that going forward new multi-line telephone systems will have to implement the 911 direct dial and notification requirements of Kari’s Law.  I fully support our efforts today to impose technologically neutral dispatchable location requirements.  But as long as there is a phone system in an East Texas hotel—or any other building—that is unable to reach 911 directly, I think we have more work to do.  As long as the public remains unsure how to reach 911 from the phone they are using—I think we have more work to do.  So I dissent in part because we do not adopt any requirements for enterprises to inform callers about the 911 limits of their phone systems, because we do not provide any guidance about when upgrades to existing phone systems will trigger the rules we adopt today, and because we exempt the embedded base of millions of multi-line telephone systems from complying with location requirements.


STATEMENT OF
COMMISSIONER GEOFFREY STARKS
APPROVING IN PART, DISSENTING IN PART

Re: 	Implementing Kari’s Law and Section 506 of RAY BAUM’S Act, PS Docket Nos. 18-261 and 17-239, GN Docket No. 11-117.

Nearly 660,000 calls are made to 911 each day.  For many callers, that day may be the worst day of their lives.  They need to know that their call will go through and that help will soon be on the way.  They shouldn’t have to think about whether they’re calling from their mobile phone, their home line, or their office or school.  They shouldn’t have to think about whether they’re calling from a new phone system or an old one.  All they need to think about is the emergency at hand.
I heard about the importance of 911 services from operators I visited in Las Vegas this Spring and earlier this week in Brooklyn.  Time and again, 911 operators told me about callers reaching them in the worst possible circumstances, when the lives of friends and family members were in danger and where seconds mattered – literally making the difference between life and death.  In Las Vegas, I learned about 911 operators taking calls from and getting help to people under fire from the mass shooter a little more than two years ago.  In Brooklyn, I listened to 911 calls in real-time, including one where a mother pleaded for an ambulance for a child who was having trouble breathing.  Time and again, these 911 operators handled these calls with empathy and professionalism.  
Today’s item is another positive step in the Commission’s ongoing effort to ensure that our 911 system meets Americans’ expectations.  As the lines between different types of communications technologies continue to disappear, the Commission must update its policies so that all users receive the same protections, regardless of the platform that they’re using.  This is most critical in the context of 911 calls, where someone’s survival may depend on that call getting through.  
While these rule changes are a great step forward, I wish we could have done more.  Kari’s Law may apply only to systems going forward from February 2020, but the person calling 911 doesn’t care when her system was installed.  All she cares about is that she’s trying to reach 911 and her call isn’t going through.  I would have supported reasonable notice requirements for legacy MLTS, similar to state laws in Texas and Utah that require placement of a sticker or notice near non-compliant MLTS devices explaining how to reach 911.  As the National Association of State 911 Administrators has pointed out, this simple fix could help avoid future tragedies like the one that gave rise to Kari’s Law in the first place.
On a related note, our rules are too vague about the level of improvements to an existing MLTS that should trigger compliance with Kari’s Law.  That’s why I supported issuance of an FNPRM that would have sought comment about this issue.  MLTS operators, installers and managers already know enough about their existing systems to anticipate the likely upgrades in those systems.  The stakes are too high to delay action.
Finally, consumers expect that when they call 911, emergency responders should be able to find them.  This item establishes the automated provision of location information as the preferred approach, but also permits the use of information derived from manual entry or “alternative location information” such as xyz coordinates or data from Wi-Fi/access points.  In the order the Commission states that it believes these other options should sufficiently identify a caller’s civic address and approximate in-building location, including floor level and approximate location on the floor.
But in some cases, manual entry may not be accurate or possible; for example, if the caller is incapacitated, if they don’t know their floor or their location on it, or if the seconds it takes to gather and provide that information take critical time away from a first responder’s arrival.  That’s why I sought addition of an FNRPM to this item that would have asked how and when we could transition systems relying on manual entry to the other two approaches.  Similarly, I supported Commissioner Rosenworcel’s proposal to seek comment on transitioning legacy systems to provide dispatchable location information.  Unfortunately, the majority rejected these proposals, which I believe would have led to better systems and improved public safety.
Nevertheless, while not perfect, I believe this item overall is a good step forward to improving 911 services, and I look forward to implementation of these important requirements.
Thank you to the staff in the Public Safety and Homeland Security Bureau for their work on this item.