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

FEDERAL COMMUNICATIONS COMMISSION

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

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

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

AGENCY:

Federal Communications Commission.

ACTION:

Final rule.

SUMMARY:

In this document, the Federal Communications Commission (the FCC or Commission) adopts rules for 911 calls made from multi-line telephone systems (MLTS), pursuant to Kari's Law, the conveyance of dispatchable location with 911 calls, as directed by RAY BAUM'S Act, and the consolidation of the Commission's 911 rules. The President recently signed into law two statutes designed to improve emergency calling: Kari's Law applies to MLTS, which are telephone systems that serve consumers in environments such as office buildings, campuses, and hotels. Kari's Law requires MLTS systems in the United States to enable users to dial 911 directly, without having to dial a prefix to reach an outside line, and to provide for notification (

e.g.,

to a front desk or security office) when a 911 call is made; RAY BAUM'S Act requires the Commission to conduct a rulemaking proceeding to consider adopting rules to ensure that “dispatchable location” is conveyed with 911 calls, regardless of the technological platform used, so that 911 call centers will receive the caller's location automatically and can dispatch responders more quickly. “Dispatchable location” is defined as “the street address of the calling party, and additional information such as room number, floor number, or similar information necessary to adequately identify the location of the calling party.” The Commission adopts rules to implement Kari's Law and initiates the rulemaking on dispatchable location required by RAY BAUM'S Act. The Commission also consolidates the Commission's existing 911 rules into a single rule part.

DATES:

Effective date:

January 6, 2020.

Compliance date:

Compliance will not be required for §§ 9.8(a); 9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4); 9.11(b)(5)(ii); (iii); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v); 9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); and 9.16(b)(3)(i), (ii), and (iii) until the Commission publishes a document in the

Federal Register

announcing the compliance date.

ADDRESSES:

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

FOR FURTHER INFORMATION CONTACT:

For further information, contact Brenda Boykin, Attorney-Advisor, Policy and Licensing Division, Public Safety and Homeland Security Bureau, (202) 418-2062 or via email at

Brenda.Boykin@fcc.gov;

William Beckwith, Attorney-Advisor, Policy and Licensing Division, Public Safety and Homeland Security Bureau, (202) 418-0134 or via email at

William.Beckwith@fcc.gov;

Thomas Eng, Engineer, Policy and Licensing Division, Public Safety and Homeland Security Bureau, (202) 418-0019 or via email at

Thomas.Eng@fcc.gov;

Dr. Rasoul Safavian, Technologist, Policy and Licensing Division, Public Safety and Homeland Security Bureau, (202) 418-0754 or via email at

Rasoul.Safavian@fcc.gov.

SUPPLEMENTARY INFORMATION:

This is a summary of the Commission's Report and Order, FCC 19-76, adopted on August 1, 2019 and released on August 2, 2019. To request materials in accessible formats for people with disabilities (Braille, large print, electronic files, audio format), send an email to

FCC504@fcc.gov

or call the Consumer & Governmental Affairs Bureau at (202) 418-0530 (voice), (202) 418-0432 (TTY). The complete text of the order also is available on the Commission's website at

http://www.fcc.gov.

Synopsis

I. Introduction

1. In this Report and Order, we adopt measures to help ensure that members of the public can successfully dial 911 to request emergency services and that Public Safety Answering Points (PSAPs) can quickly and accurately locate every 911 caller, regardless of the type of service that is used to make the call. We act today pursuant to two federal statutes: Kari's Law Act of 2017, which requires implementation of direct 911 dialing and on-site notification capabilities in multi-line telephone systems (MLTS), and section 506 of RAY BAUM'S Act, which requires the Commission to “consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call, regardless of the technological platform used and including with calls from [MLTS].”

2. In particular, we adopt rules that implement the direct dialing and notification requirements of Kari's Law and clarify the law's application to both legacy MLTS and Internet Protocol (IP)-based systems, including cloud-based services, that support the communications needs of hotels, businesses, campuses, and other enterprises. And we adopt rules that will facilitate timely emergency response and improved location accuracy across communications platforms. These requirements are measured, technically feasible, and technologically neutral, so that providers can choose the most effective solutions from a range of options. In addition, our requirements allow sufficient time for advance planning and deployment of new location technology. Similar to the approach the Commission has taken in the wireless E911 context, we believe that “[c]lear and measurable timelines and benchmarks for all stakeholders are essential to drive the improvements that the public reasonably expects to see in 911 location performance.” We also take this opportunity to consolidate our existing 911 rules, as well as the direct dialing and dispatchable location rules adopted today, into a single rule part.

II. Background

3. Enhanced 911 (E911) was developed to provide PSAPs with the caller's location and a call-back number as part of each 911 call. Since its implementation, most E911 calls have conveyed information regarding the caller's location (with varying degrees of accuracy) and a call-back number to the PSAP. These enhancements have significantly improved PSAPs' ability to effectively deliver critical public safety and emergency response services in a timely manner. In many instances, E911 has proven to be a life-saving, essential emergency response tool for providing critical information when the caller is unable to verbally communicate his or her location, including when the voice call is dropped or discontinued and cannot be reestablished.

4. Under the Commission's rules, consumers generally have access to these capabilities when they make fixed telephony, mobile, and interconnected VoIP calls to 911. However, to date, the Commission's E911 rules have not applied to MLTS. Consequently, consumers in environments such as office buildings, campuses, and hotels may not have the same access to E911 services that is provided by fixed telephony, mobile, and VoIP systems,

namely direct dialing access to 911 and the provision of the MLTS user's location information.

5. MLTS include a widely embedded base of legacy private branch exchange (PBX), Centrex, and Key Telephone systems, IP-based systems, and hybrid systems. MLTS serve millions of employees, residents, and guests of businesses and educational facilities, including corporate parks, hotels, college campuses, and planned community developments. These systems can support anywhere from ten to thousands of telephone station/numbers. Emergency calls from MLTS stations generally only provide PSAPs the telephone or circuit number of the system's outgoing trunk, and not the emergency caller's individual station number. In some cases, the MLTS station that placed the call will not even have its own telephone number. As a result, PSAPs often find they are unable to locate an MLTS emergency call to the station from which it originated. The Commission in 2003 considered E911 requirements for MLTS but deferred to the states to address this issue, while preserving the option of acting should states fail to do so.

6. At least 23 states have enacted legislation that requires organizations over a certain size or purchasing a new PBX/MLTS system to implement E911 on the system. These states have adopted varied requirements for MLTS providers, and only in some instances have state laws specifically addressed prefix dialing requirements. In the absence of federal or consistent state regulation, some MLTS in operation today do not support direct 911 dialing, may not have the capability to route calls to the appropriate PSAP relative to the caller's location, or may not provide accurate information regarding the caller's location. The Commission has observed that these issues have persisted, even as many enterprises are increasingly relying on IP-based systems, including cloud-based services, to support their communications needs.

7. Given that the ongoing evolution of MLTS has not eliminated these shortfalls when serving 911 callers, the Commission has periodically sought to examine MLTS provision of 911, including the capabilities of MLTS to support direct 911 access, routing, callback, and automatic location. In September 2017, the Commission released a Notice of Inquiry (Enterprise Communications NOI) seeking information on the capabilities of enterprise communications systems to support direct 911 access, routing, and automatic location. The Commission noted that such systems may not provide consumers with the same access to E911 services as other wireline, wireless, and interconnected VoIP calls and asked whether it is still the case, as the Commission found in earlier proceedings, that the needs and circumstances of residential and business enterprise communications system users are suited to state-level action rather than federal regulation. The Enterprise Communications NOI also sought information on the state of the enterprise communications system industry; the costs and benefits of supporting E911 for enterprise communications system; the capability of enterprise communications system to provide accessible emergency communications for persons with disabilities; and options for ensuring that enterprise communications system keep pace with technological developments and consumer expectations for access to 911.

8. Kari's Law was enacted on February 16, 2018. Kari's Law establishes a federal multi-tiered approach to MLTS 911 requirements. First, Kari's Law applies to any “person engaged in the business of manufacturing, importing, selling, or leasing” MLTS. Such persons “may not manufacture or import for use in the United States, or sell or lease or offer to sell or lease in the United States, a [MLTS], unless such system is pre-configured such that, when properly installed . . . a user may directly initiate a call to 9-1-1 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit `9', regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls.”

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

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

11. Fourth, Kari's Law expressly provides that Congress did not intend to “alter the authority of State commissions or other State or local agencies with jurisdiction over emergency communications, if the exercise of such authority is not inconsistent with this [Act].” Kari's Law directs the Commission to enforce the provisions under Title V of the Communications Act of 1934, as amended, “except that section 501 applies only to the extent that such section provides for the punishment of a fine.” The effective date provision states that Kari's Law “shall apply with respect to a multi-line telephone system that is manufactured, imported, offered for first sale or lease, first sold or leased, or installed after” February 16, 2020.

12. On March 23, 2018, shortly after Kari's Law was enacted, the President signed the Consolidated Appropriations Act of 2018, including RAY BAUM'S Act, into law. Section 506 of RAY BAUM'S Act requires the Commission to “conclude a proceeding to consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call, regardless of the technological platform used and including with calls from multi-line telephone systems” by September 23, 2019. In conducting this proceeding, “the Commission may consider information and conclusions from other Commission proceedings regarding the accuracy of the dispatchable location for a 9-1-1 call, but nothing in this section shall be construed to require the Commission to reconsider any information or conclusion from a proceeding regarding the accuracy of the dispatchable location for a 9-1-1 call in which the Commission has adopted rules or issued an order” before the March 23, 2018 enactment date of section 506.

13. In September 2018, following the enactment of Kari's Law and RAY BAUM'S Act, the Commission proposed rules to implement Kari's Law and to support dispatchable location for 911 calls from MLTS and other communications platforms. Specifically, the NPRM proposed to implement Kari's Law by adopting direct dial and notification rules governing calls to 911 made from MLTS and clarifying the definitions associated with the law. As required by RAY BAUM'S Act, the Commission also initiated this proceeding to consider the feasibility of requiring dispatchable location for 911 calls from MLTS and other technological platforms. The

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

III. Discussion

A. Direct Dialing and Notification for MLTS

14. Because Congress incorporated Kari's Law into the Communications Act of 1934, as amended (the Act), the Commission has authority to prescribe such rules and regulations as are necessary to carry out Kari's Law. The implementing regulations we adopt in this Report and Order are intended to provide additional clarity and specificity regarding the terms used in the statute and the obligations placed on covered entities.

1. Direct Dialing

15. Kari's Law provides that any person engaged in the business of manufacturing, importing, selling, or leasing an MLTS may not manufacture or import the MLTS for use in the United States, or sell or lease or offer to sell or lease it in the United States, unless it is pre-configured so that when properly installed, a user may directly initiate a call to 911 from any station equipped with dialing facilities. In addition, any person engaged in the business of installing, managing, or operating an MLTS may not do so unless the MLTS is configured so that a user may dial 911 directly. In the NPRM, the Commission proposed rules that track these obligations.

16. We adopt the rules requiring direct dialing from MLTS generally as proposed in the NPRM. There is broad support among all types of commenters (industry and public safety entities) for the proposed direct dialing rules, although some commenters seek clarification of proposed definitions and other terms. The Texas 9-1-1 Entities state that the proposed rules “should generally be adopted as written.” Microsoft asserts that proposed direct dialing and notification requirements are consistent with Kari's Law and should be reasonably achievable. No commenter opposes adoption of the direct dialing requirements.

2. Notification

17. Kari's Law provides that any person engaged in the business of installing, managing, or operating an MLTS shall, in installing, managing, or operating such a system for use in the United States, configure the system to provide a notification to a central location at the facility where the system is installed or to another person or organization regardless of location, if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system. Consistent with this obligation, the Commission in the NPRM proposed rules providing that installers, managers, or operators must configure an MLTS to provide for transmission of a 911 notification if the system can be configured to do so without an improvement to the hardware or software of the system. The Commission stated that notification will potentially benefit three parties: (1) The 911 caller by speeding response time; (2) enterprise management and staff by providing needed information and reducing confusion and delay when emergency response teams arrive; and (3) first responders by reducing time spent responding to such calls.

a. Required Information and Purpose

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

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

20. We adopt the proposal from the NPRM with certain changes. As proposed, we find that the notification should include the fact that a 911 call has been made, a valid callback number, and the same location information that is conveyed with the call to 911. However, we provide an exception for callback number and location information in circumstances where including this information in the notification would be technically infeasible. We also clarify that the callback number in the notification does not have to be a Direct Inward Dialing number to the 911 caller's extension if one is not available.

21. Several commenters express support for the Commission's proposed notification requirements. APCO supports the Commission's proposal provided that notification does not delay the call to emergency responders. Verizon states that the Commission's proposed notification rule is straightforward and consistent with the statute's focus and notes that the technical details of how the capability is implemented will vary among enterprise customers based on their size, resources, and the particular network configuration involved.

22. We agree with commenters who contend that certain minimum content is necessary to ensure that notification serves the purpose intended for it, which is to help the enterprise provide assistance to first responders in the event of a 911 call. For example, NASNA states that the Commission “absolutely” should establish minimum content for the notification and that it

should “require that what is sent to PSAPs be sent also to the notification center.” RedSky asserts that the notification should also include the date and time of the 911 call. Avaya suggests that notification should include “details that may not be conveyed to the PSAP,” such as “location information that clearly establishes the location of the caller” and alerts with acknowledgement and escalation functions.

23. At the same time, we seek to provide enterprises sufficient flexibility to tailor the notification to best suit their needs. In this respect, we note that some commenters urge the Commission to allow enterprises to determine the content of notifications as they see fit. Panasonic, for example, states that businesses should have the flexibility to customize notifications to meet their needs, given their understanding of the physical nature of their enterprise, the technical capabilities of their system, and the personnel who will be involved in assisting with an emergency response, including on-site private emergency response teams in some cases.

24. In the absence of direction in the statutory language about what the required notification should contain, we are also mindful of Congress's stated intent to “balance the need for an onsite notification with the goal of not placing an undue burden on MLTS owners or operators.” Reflecting this flexible approach, we define MLTS Notification as: “An MLTS feature that can send notice to a central location at the facility where the system is installed or to another person or organization regardless of location. Examples of notification include conspicuous on-screen messages with audible alarms for security desk computers using a client application, text messages for smartphones, and email for administrators. Notification shall include, at a minimum, the following information: (1) The fact that a 911 call has been made, (2) a valid callback number, and (3) the information about the caller's location that the MLTS conveys to the public safety answering point (PSAP) with the call to 911; provided, however, that the notification does not have to include a callback number or location information if it is technically infeasible to provide this information.”

25. Commenters raise concerns regarding the inclusion of a callback number and location information in the notification. Cisco, Panasonic, and TIA note that Kari's Law does not specifically require a callback number or location information in the notification. Cisco states that the callback number and location information conveyed in a notification can vary based on the technology deployed in the enterprise, so the Commission should ensure that this rule provides MLTS managers sufficient flexibility to determine the contents of the notification. Several commenters note that providing a callback number that reaches the 911 caller's specific phone is not possible in some enterprises because there is no Direct Inward Dialing phone number associated with the MLTS endpoints. Some commenters also point out that providing the caller's location in the notification may not be necessary or helpful in the case of enterprises that are small or have an open workspace.

26. We therefore provide an exception for callback number and location information in circumstances where including this information in the notification would not be technically feasible. We agree with commenters who assert that there may be MLTS solutions for which it is not technically feasible to include this information in the notification. For example, commenters point out that providing a callback number that reaches the 911 caller's specific phone is not possible in some enterprises because there is no phone number associated with the MLTS endpoints. Accordingly, we clarify that the callback number, if provided, need not be a Direct Inward Dialing number to the 911 caller's extension if a Direct Inward Dialing number is not available. This means, for example, that if the 911 call comes from a non-Direct Inward Dialing number, the callback number in the notification can be an internal extension that can be directly reached from inside the enterprise but not from outside it. Similarly, a hotel that does not provide a Direct Inward Dialing line to each guest room can provide the number of a central location, such as the front desk, in the notification. Notwithstanding that each of these MLTS notification examples would include callback number information in lieu of a Direct Inward Dialing number to the 911 caller, we reiterate that omission of callback number information in the notification is acceptable if it is technically infeasible to provide such information.

1

1

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

27. We also adopt BRETSA's suggestion to replace the term “screen pops” from the NPRM with “conspicuous on-screen messages,” which we find to be clearer. And we reject BRETSA's suggestion that the Commission revise the beginning of the definition of MLTS Notification to read, “[a]n MLTS feature that can send notice that a call has been placed to `9-1-1' from an MLTS station, to a central location at the facility where the system is installed or to another person.” We decline to add this language because we believe the reference to the required content of the notification later in the definition makes clear that notification includes the fact that a call to 911 has been made.

28. Because our requirements set a minimum, enterprises may add other information to the notification as useful and appropriate. This may include, for example, the occupancy status of a hotel room, or the specific location of an IP device. Enterprises are free to include such information in the notification as they see fit, so long as the notification includes the required elements. Although the additional information Avaya proposes for the content of the notification may be helpful for some enterprises, we do not believe it would be appropriate for all enterprises, particularly smaller businesses. We also do not have a sufficient record to determine whether to adopt date and time of the 911 call as required elements of the notification, as RedSky suggests, although we encourage enterprises to include this information at their discretion. We also encourage the development of voluntary best practices and employee training to prepare enterprises for responding to receipt of notification that a 911 call has been made. For instance, training could include the circumstances under which the notice recipient (or someone else at the enterprise) should dial the callback number included with the notification.

29. Finally, BRETSA asserts that PSAPs and first responders should determine the notification and location information provided by the enterprise, with a process for state and local public safety authorities to waive the Commission's MLTS rules where reasonable and appropriate. We decline to find that state and local public safety agencies have authority to waive the Commission's rules, as BRETSA requests. Requests for such waivers should, as with other Commission requirements, be presented to the Commission.

b. Notification Timing

30. Kari's Law is silent on when the notification must be provided. The Commission proposed to require that MLTS covered by Kari's Law be

configured so that notification is contemporaneous with the 911 call and does not delay the placement of the call to 911. Most commenters that address this issue support the Commission's proposal.

31. We adopt the timing requirement as proposed but clarify that initiation of the notification must be contemporaneous with the call to 911. As RedSky points out, notification can occur in many forms, including SMS text messages, email, screen display, and conference calls, and the delivery of text messages and email is not within the control of the MLTS provider or the MLTS user. Accordingly, RedSky asks the Commission to clarify that initiation of the notification must be contemporaneous with connection of the emergency caller to the PSAP. We concur. The record shows the importance of timely notification. According to NENA, “[n]otification contemporaneous with the 9-1-1 call has significantly greater value to all parties than after-the-fact notification, and the majority of a notification's benefits to response are lost if the notification is not conveyed in real-time.”

32. We also note Ad Hoc's concern that some enterprise owner/operators of MLTS currently report challenges in configuring MLTS equipment to provide contemporaneous notification in addition to placing the call to 911 emergency services. As a result, Ad Hoc states, the Commission should condition its proposal for the timing of notification on what is “technically feasible.” We condition this requirement on the technical feasibility of providing contemporaneous notification, as Ad Hoc requests.

c. Notification Destination Points

33. The Commission also sought comment in the NPRM on whether there should be any requirements relating to the location, configuration, or staffing of notification destination points. Kari's Law states that the notification may be provided either to a “central location at the facility where the system is installed” or to “another person or organization regardless of location.” The Commission noted that this language indicates Congress's recognition that in the enterprise settings where MLTS are typically used, providing someone other than the PSAP with notice of the call can be critical to helping first responders gain timely access. At the same time, the language “regardless of location,” as illuminated by legislative history, indicates that Congress sought to provide MLTS installers, managers, and operators with broad flexibility in selecting destination points to achieve this goal. For example, the notification could be directed to an on-site security desk that controls access to the premises, to an enterprise employee who may or may not be located at the facility where the MLTS is installed, or to a third party that provides security or safety services from an off-site location. MLTS notification could also be configured to combine these approaches,

e.g.,

by having notifications during business hours go to a central on-site location and off-hours notifications go to an off-site person or organization.

34. The Commission sought comment on whether it should specify criteria for destination points to ensure that notifications are likely to be received by someone able to take appropriate action to facilitate or assist the 911 response. Where on-site notification to a “central location” is provided, the Commission asked whether it should specify that the destination point must be a location that is normally staffed or, alternatively, a location where on-site staff are likely to hear or see the notification. The Commission noted that this approach would afford flexibility to direct the on-site notification to a security guard or facilities manager, to personnel who are otherwise employed and can support monitoring notifications as part of existing duties, or to an on-site location where staff are normally present.

35. We adopt a requirement that notifications be sent to a location on-site or off-site where someone is likely to hear or see the notification. Some commenters urge the Commission to establish criteria for notification destination points, while others urge the Commission to preserve flexibility for the enterprise. In this respect, we note NASNA's assertion that notification “absolutely” should be to a location that is normally staffed or where staff are likely to hear or see the notification and that “[t]o do otherwise would undermine the purpose of the notification requirement.” We agree with NASNA that the Commission should set some criteria for notification destination points to help ensure that they serve the purpose of Kari's Law.

36. The requirement we adopt preserves flexibility for the enterprise to select an appropriate destination point. For instance, we recognize AHLA's suggestion that “[h]ow an individual hotel determines to send a notification (via text message, a separate call or email), to whom the notification is sent, and where the recipient is at the time of receipt should be at the discretion of the hotel. For example, a hotel with a single on-duty employee overnight should not be required to send notification to a desk that may not be manned; a text message to the employee's mobile device might be more appropriate.” Our requirement would allow a hotel such as the one described by AHLA to send a text message to the overnight employee's mobile device.

2

2

The definition of MLTS notification we adopt does not specify any particular form for the notification and states that examples of notification include “conspicuous on-screen messages with audible alarms for security desk computers using a client application, text messages for smartphones, and email for administrators.”

37. In addition, we do not require that the notification point be continuously staffed or monitored, only that it be a location where someone is likely to see or hear the notification. The legislative history of Kari's Law provides that the statute “seeks to balance the need for an onsite notification with the goal of not placing an undue burden on MLTS owners or operators.” Consistent with this, the Commission in the NPRM stated that it did not believe Congress intended to impose staffing or monitoring requirements that would generate unreasonable costs, such as the need to hire additional staff, or limit the flexibility of MLTS installers, managers, and operators to develop cost-effective notification solutions to meet their particular needs. Based on the record before us, we adopt a requirement with which we intend to strike an appropriate balance between the increased benefits from having notifications sent to a location where they are likely to be received (

e.g.,

increased chances of assistance for first responders) and the increased costs that are likely to result if we were to adopt a less flexible approach (

e.g.,

increased staffing costs).

38. In the NPRM, the Commission also asked whether, in the case of off-site notification, it should require that notification be to a person or organization that is authorized to provide first responders with access to the location from which the MLTS 911 call originated. The Commission noted that this would allow notification to be directed to any offsite location, as the statute clearly allows, while furthering the statute's objective of facilitating access to first responders answering a 911 call.

39. We agree with Ad Hoc that requiring such notification may not make sense in all situations, such as where the enterprise does not control access to the premises or where access to the premises is unrestricted. We nonetheless encourage enterprises using the off-site notification option to choose someone who can assist first responders in gaining access to the facility if it is

feasible to do. As suggested by NENA's comments, it is a best practice for notification to go to whomever “has the keys” if a campus or building has restricted access and to whomever has any specialized knowledge of the facility layout that may assist public safety in locating and responding to a 911 call. And we encourage the development of voluntary best practices and training for enterprise personnel, including designated notice recipients, so that they are prepared to assist first responders in the event of an emergency call.

d. No Exemptions to Notification Requirement

40. In the NPRM, the Commission noted that large enterprises such as hotels, hospitals, and schools frequently have on-site personnel that control access to the premises, and notification of 911 calls to such personnel can improve outcomes by enabling them to assist first responders in accessing the premises and reaching the caller's location. The Commission sought comment on applying the statute's notification requirements to all MLTS operators, including small enterprises, and sought comment on whether the benefits and costs of notification apply differently to small businesses than large enterprises such as hotels, hospitals, and schools. Small businesses are less likely to have personnel controlling access, and first responders may not need the same level of assistance to reach a 911 caller. The Commission also asked whether small enterprises using MLTS may find benefits to notification in addition to access and support, such as the ability for the enterprise to intervene when 911 is dialed in error and avoid sending emergency responders to a location that does not require a response.

41. Commenters are divided on whether the Commission should provide a small business exemption for the notification requirements of Kari's Law. NASNA states that the benefits of notification are the same for a small business as for a large one and that small businesses should know that a 911 call was made from their MLTS so they are not surprised when first responders arrive and can assist if needed, including canceling the response if it turns out that 911 was dialed in error. Other commenters support a small business exemption, although their specific proposals for an exemption differ. RedSky, for example, argues that not every enterprise using an MLTS should be required to have emergency call notification, “let alone staff to receive a notification,” and that there are many circumstances where there is no one to consume the data and react. Proposed criteria for defining an exemption generally include limits on square footage or the number of lines used at a single location. In turn, RingCentral and VON urge the Commission to limit the notification requirement to on-site calls and not to require notification for 911 calls from distributed workforces,

i.e.,

those spread out over a large geographic region and relying on MLTS to centralize communications.

42. We decline to adopt a small business exemption because we agree with NASNA that small businesses should receive notice of 911 calls that have been made from their MLTS so that they can prepare for the arrival of first responders and assist if needed. We also decline to provide an exception to the location information requirement for enterprises that are small or have an open workspace, as some commenters suggest. We believe location information will be helpful even at a small business because it will confirm the caller's location for the notice recipient, who may be at an offsite location. In addition, the burden of providing this information should be minimal. We note that Kari's Law does not provide an exemption for small businesses—nor one for MLTS operators that are not always staffed. In addition, the requirements we adopt for notification are highly flexible and give small businesses significant latitude to configure suitable notification mechanisms without unreasonable burden or cost.

43. We also disagree with RingCentral and VON that notification as a rule is unlikely to be helpful at remote or satellite locations served by an MLTS. Rather, we agree with BRETSA that limiting application of the rules to only specific types of MLTS would distort the market by favoring newer technologies, notwithstanding that callers to 911 are no less impacted by failures of MLTS using those technologies to provide notification (and interior location information) than MLTS using other technologies. Indeed, we disagree with arguments that whenever an MLTS is used off-site, notification is not useful. Although RingCentral states that it has many customers that provide centralized phone numbers and extensions for a workforce that is working from home, the road, remote offices, or a mix of these locations, the fact that a “centralized location may be miles or states away from the emergency and have no special knowledge of the location where the emergency arose” is irrelevant—Congress recognized that notifications have value “regardless of location,” and it is not hard to recognize that having a centralized notification system could aid these multi-homed workers in reaching emergency services. Similarly, we disagree with VON that “a 911 call placed by a person working from a satellite office would trigger a notification to someone at the central office, who would not be able to aid first responders when they arrive at the satellite office or otherwise speed first responder response time,” because someone at a staffed central office may nonetheless aid remote first responders by, for example, alerting other personnel at the location of the emergency. Although there may be corner cases in which notification is not in fact helpful, we decline on this record to exempt any particular category of MLTS facilities from the notification requirements as a matter of policy (not to mention that Kari's Law itself draws no such lines).

3. Definitions

a. Definition of Multi-Line Telephone System

44. Kari's Law and RAY BAUM'S Act define the term “multi-line telephone system” by cross-referencing the definition in the Middle Class Tax Relief and Job Creation Act of 2012. That Act, in turn, defines an MLTS as:

A system comprised of common control units, telephone sets, control hardware and software and adjunct systems, including network and premises based systems, such as Centrex and VoIP, as well as PBX, Hybrid, and Key Telephone Systems (as classified by the Commission under part 68 of title 47, Code of Federal Regulations), and includes systems owned or leased by governmental agencies and non-profit entities, as well as for profit businesses.

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

46. The Commission also proposed in the NPRM to interpret the definition of MLTS to include enterprise-based systems that allow outbound calls to 911 without providing a way for the PSAP to place a return call (outbound-only calling service). The Commission stated that it believed requiring direct dialing for any MLTS that allows the user to call 911, regardless of whether the system also allows the PSAP to make a return call, would advance the purpose of Kari's Law. In addition, the Commission stated, there is nothing in the language of the definition of MLTS

from the Middle Class Tax Relief and Job Creation Act of 2012 that excludes systems allowing only outbound calls to 911.

47. The record is divided over the Commission's proposed definition of MLTS. Some commenters support the proposal, while others oppose the Commission's proposed interpretation. Commenters, however, generally support the Commission's proposed interpretation of the definition of MLTS to include outbound-only calling services, citing consumer expectations and the need for regulatory parity among services.

48. As proposed in the NPRM, and consistent with the statutory definition, we interpret the definition of MLTS to include the full range of networked communications systems that serve enterprises, including circuit-switched and IP-based enterprise systems, as well as cloud-based IP technology and over-the-top applications. West Safety endorses this approach and states that the statutory definition of MLTS is sufficiently broad to encompass the full range of enterprise communications systems, including “legacy TDM MLTS, hybrid MLTS and IP MLTS systems and software,” as well as “any and all endpoints supported by MLTS including mobile and smart devices, softphone clients, over-the-top (OTT) applications and outbound-only calling services.” RedSky similarly states that the term MLTS “should not be limited to any specific type of end point device” because the technology is constantly evolving. We agree.

49. TIA and VON, however, oppose the Commission's proposed interpretation. TIA asserts that if Congress had intended its definition to capture “the full range” of all technologies in the enterprise communications marketplace, including over-the-top applications, it could have done so in the definition. Instead, TIA asserts, “the definition refers by name to numerous traditional MLTS technologies and points to Part 68 of the FCC's rules—regulations established decades ago to govern interconnection with the PSTN [public switched telephone network] for traditional telephony services.” TIA adds that “[t]he Commission is right to think about the modern enterprise communications market which has certainly expanded beyond traditional locally-hosted PBX systems, but it should not expand the scope of Kari's Law as intended by Congress.” VON states that as proposed, the term could cover any business with more than one line using a cloud PBX and could therefore essentially turn any interconnected VoIP service into MLTS (or vice versa), contrary to the plain intent of Kari's Law. VON adds that this point becomes clearer when compared with RAY BAUM'S Act, which directs the Commission to “consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call, regardless of the technological platform used and including with calls from [MLTS].” In contrast, VON states, Kari's Law does not discuss other technological platforms, and as a result, “the NPRM's proposed interpretation of MLTS goes farther than the law allows, and should be limited to those systems provided for in 47 U.S.C. 1471.” Cisco and Panasonic note that the statutory definition of MLTS does not refer to the terms “cloud-based IP technology” and “over-the-top applications” and state that it is not clear Congress envisioned such a broad interpretation of the term.

50. We disagree with these commenters. In particular, we note that the statutory definition also refers to VoIP, which is a newer technology, and introduces the reference to VoIP with the term “such as.” The statute thus cites VoIP (and other technologies) as examples but not as limitations on the definition. If Congress had intended a more constrained view of the technologies that fall within the definition of MLTS, it would have stated that MLTS “consists of” or is “limited to” certain technologies. In addition, the statutory language refers broadly to a “system comprised of common control units, . . . control hardware and software and adjunct systems, including network and premises-based systems.” We find that this language broadly includes cloud-based IP technology and over-the-top applications. Further, there is no language in the statute specifically excluding cloud-based IP technology and over-the-top applications from the definition of MLTS.

51. We also believe interpreting the definition of MLTS broadly is consistent with the intent of Kari's Law. The enterprise market has already seen significant migration away from traditional MLTS and toward IP-based and cloud-based systems, and Kari's Law applies only to systems that are manufactured or brought into use after February 16, 2020. It is unlikely that Congress would seek to address the problems of direct dialing and notification for MLTS only with respect to traditional, non-IP-based MLTS technologies, which represent a declining share of the MLTS market. With respect to VON's assertion that the reference to other “technological platform[s]” in RAY BAUM'S Act shows that the definition of MLTS should be interpreted narrowly under Kari's Law, we disagree. We interpret the reference to technological platforms in RAY BAUM'S Act as a direction for the Commission to include other services, such as interconnected VoIP, TRS, and fixed telephony, in its consideration of dispatchable location rules. We do not interpret it as a limitation, explicit or implied, on the meaning of MLTS under Kari's Law.

52. We also interpret the definition of MLTS to include outbound-only calling systems.

3

The statutory definition of MLTS is broad enough to cover outbound-only calling services and does not expressly exclude such services. Commenters generally support interpreting the definition to include outbound-only services, and no commenter expressly opposes this interpretation. Avaya, for example, states that MLTS at a minimum should include any system capable of making an outbound call. BRETSA asserts that 911 calls are outbound calls, and it is counterintuitive that they cannot be made over outbound-only calling systems. AT&T urges the Commission to ensure that the MLTS rules maintain regulatory parity between new implementations of business VoIP services and traditional MLTS business solutions and states that one-way VoIP solutions should be required to support 911, as end users will expect their calling solutions to have this functionality and may rely on it in an emergency. Verizon states that applying Kari's Law requirements to MLTS that allow outbound-only 911 dialing is likely feasible, but that the scope of such requirements should focus on user expectations. Verizon suggests that the rules should protect users of outbound-only calling systems who are not employed by the enterprise or who are otherwise unfamiliar with the system and use it for outbound-only dialing. On the other hand, Verizon states, if the outbound-only system has a defined and restricted user group that is uniformly familiar with and trained in the enterprise's calling practices, and 911 is the only outbound number that users can dial, the direct dialing capability may be less critical. Verizon also states that requiring direct dialing capability for outbound-only MLTS services “may give enterprises incentive to not enable any 911 dialing at all (which has its own public safety implications).”

3

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

53. We find that Congress's intent in enacting Kari's Law was to require direct dialing for any MLTS phone that allows the user to call 911, regardless of whether the system also allows the PSAP to connect a return call directly to the 911 caller. We agree with the Texas 9-1-1 Entities that Kari's Law and the “utterly tragic circumstances” behind its enactment demonstrate that “it is simply unreasonable to expect 9-1-1 callers to know or remember when they are required to do something differently during a 9-1-1 call based on their particular device or location.” Moreover, as BRETSA states, calling 911 is inherently an outbound service. As a result, it is counter-intuitive to expect consumers to assume that they cannot reach 911 from such services.

54. We decline to adopt Verizon's suggestion that we narrow the requirements for outbound-only MLTS service to apply solely on the basis of user expectations. Rather, we believe Congress intended for direct 911 dialing and notification to be available for all outbound-only MLTS services. Similarly, public safety commenters such as the Texas 9-1-1 Entities and BRETSA point out that 911 callers in an emergency should not have to slow down and analyze whether 911 is available from a particular device, especially when they may not know the particular technology involved and may not have chosen it for themselves. Finally, although Verizon suggests that requiring direct dialing capability for outbound-only MLTS services may give enterprises incentive to not enable any 911 dialing at all, we do not believe this possibility, which is speculative, outweighs the benefits of ensuring that direct dialing is available with any MLTS phone that allows the caller to reach 911.

55. Internal systems. Cisco asks the Commission to clarify that the definition of MLTS excludes systems that are “used only for internal employee communications and . . . are not designed to interconnect with the PSTN,” such as internal messaging and data and video conference capabilities that are “increasingly displacing voice communications for employee collaboration.” Cisco states that “[w]here a technology is specifically deployed by an enterprise to support internal communications (

i.e.,

it cannot support a call outside the enterprise), or where a tool is designed and used for conferencing services or other non-point-to-point communications, there can be no reasonable expectation on the part of employees that such internal or conferencing tools would be used to summon emergency services.” BRETSA responds that limiting application of the rules to specific types of MLTS would distort the market and that Kari's Law and RAY BAUM'S Act do not support such a narrow reading of the definition of MLTS. Further, BRETSA states that exempting internal communications systems from the rules “would appear to create a loophole such as to negate the statutes and rules” because an MLTS in which a user must dial a number to access an outside line prior to placing a call to 911 would appear to be an internal communications system.

56. We agree with Cisco that Kari's Law and the rules arising out of RAY BAUM'S Act were not intended to apply to purely internal communications systems that do not rely on telephone numbers under the North American Numbering Plan. We clarify that a technology that is specifically deployed by an enterprise to support only internal communications and that does not connect to the public switched telephone network would not fall within the definition of MLTS. In response to BRETSA's concerns, we conclude that this will not distort the market or negate the statute and rules because the clarification applies only to systems that do not connect to the public switched telephone network. If an internal communications system or conferencing service connects to the public switched telephone network either on its own or through a third party and can establish calls to the public switched telephone network, including by dialing a prefix such as “9,” then it is within the definition of MLTS under our interpretation.

57. System components. Panasonic, Cisco, and TIA also urge the Commission to clarify that individual system components such as telephone sets and control software do not qualify as an MLTS. Panasonic states that Congress's use of the language “system comprised of” various parts, “

e.g.,

common control units, telephone sets, control software and hardware and adjunct systems,” dictates as a matter of logic that such individual parts are, in isolation, not MLTS themselves. To hold otherwise, Panasonic states, would be to ignore the plain meaning of the word “comprised,” effectively reading it out of the statute. Panasonic adds that it may be uniquely situated in that while the company offers a “full-blown MLTS” and is in that case an MLTS manufacturer, it also sells IP phones to other parties, who bundle Panasonic phones with other components that make up a full MLTS. To address this situation, Panasonic states, the Commission should clarify that sellers of individual MLTS components are not subject to the Commission's rules for MLTS. Cisco asserts that “[a]s a matter of common sense, individual system components are not even capable of dialing 911 or reaching the PSTN unless and until they are assembled by an installer.”

58. We agree that the definition of MLTS refers to a system and that individual components of such a system, including telephone sets, control software and hardware, and adjunct systems, do not by themselves constitute an MLTS. Consistent with this, we clarify that manufacturers, importers, sellers, or lessors of individual MLTS components are not subject to the Commission's MLTS rules to the extent that they manufacture, import, sell, or lease such components without the other components necessary for the system to function as an MLTS. In the scenario described by Panasonic, the entity that bundles the individual components into an MLTS would be the manufacturer and presumably also the seller or lessor of the MLTS and would have the obligations that fall on those parties under the statute and our rules.

4

However, we do not agree with Cisco that the test for whether one or more components constitute an MLTS is whether they can be used to dial 911 or reach the PSTN, as that would exclude all systems that have been manufactured but not yet installed. Such a result would clearly be at odds with Kari's Law, which places obligations on “persons engaged in the business of manufacturing, importing, selling, or leasing” an MLTS that apply before installation, operation, or management of the system.

5

4

To the extent individual components need certain functionality or pre-configuration to comply with Kari's Law, the bundler should require that in its contract with the manufacturer. The obligation to comply with the statute and our rules, however, would lie with the bundler.

5

Specifically, such persons may not manufacture, import, sell, lease, or offer to sell or lease an MLTS unless the system is “pre-configured” so that when properly installed, a user may directly initiate a call to 911 from any station equipped with dialing facilities.

b. Definition of Pre-Configured

59. The Commission proposed in the NPRM to define the statutory term “pre-configured” to mean:

An MLTS that comes equipped with a default configuration or setting that enables users to dial 911 directly as required under the statute and rules, so long as the MLTS is installed and operated properly. This does not preclude the inclusion of additional dialing patterns to reach 911. However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern.

60. The Commission stated that this would mean an MLTS may support additional dialing patterns but that manufacturers (and importers, sellers, or lessors) must ensure that the default, “out-of-the-box” configuration allows users to reach 911 directly.

61. Although some commenters agree with the Commission's proposed definition of pre-configured, others ask the Commission to clarify the proposed definition to acknowledge the role of the enterprise customer and MLTS installer in providing the MLTS with connectivity to the PSTN.

62. We find that the revisions proposed by Cisco and Microsoft are consistent with the statutory language and with the definition of “pre-configured” that the Commission proposed in the NPRM, and that they assist in providing clarity. In particular, Cisco states that MLTS manufacturers today can design systems that are capable of supporting direct 911 dialing patterns and that are shipped with software that, upon installation and configuration of the MLTS with PSTN connectivity, can enable direct 911 dialing. However, MLTS solutions of this type have no capability “out of the box” to make or complete a PSTN call, including an emergency call.

63. Cisco adds that in today's market, “MLTS manufacturers predominantly offer enterprise solutions over distributed systems, where the actual call control component of the solution need not be, and often is not, resident in each enterprise location where MLTS-to-PSTN calling takes place. PSTN connectivity, including the 911 dialing pattern, is therefore established by the installer at the direction of the enterprise, based on the unique attributes of its MLTS system, at the time PSTN connectivity is configured.” Cisco urges the Commission to clarify that the pre-configuration requirement in the context of distributed systems can be satisfied when a vendor includes software to support a direct 911 dialing pattern, which is available to the installer at the time the MLTS is configured for PSTN calling. Specifically, Cisco proposes that the Commission “slightly” modify the definition of pre-configured to read, “An MLTS that comes equipped with hardware and/or software capable of establishing a setting that enables users to directly dial 911 as soon as the system is able to initiate calls to the public switched telephone network, so long as the MLTS is installed and operated properly.” Microsoft similarly states that many, if not most, MLTS capabilities in today's marketplace are not available in a “plug and play” version and that the Commission should revise the definition of pre-configured so that it “recognizes the responsibilities of the customer with respect to implementation and provision of the service.” Microsoft recommends that the Commission revise the definition to read, “ `Pre-configured' means that the MLTS comes equipped with a default configuration or setting that enables users to dial 911 directly as required under the statute and rules, so long as the system is installed and operated properly or, where no default exists, such as when customer provisioning of the system is required, enables the customer to configure the system to dial 911 directly as required under the statute and rules.”

64. We agree with these commenters that not all MLTS are “out of the box,” plug-and-play solutions and that the definition of pre-configured should recognize the role of the enterprise and installer with respect to implementation and provision of service. We believe that the proposed revisions suggested by Cisco and Microsoft are fundamentally consistent with each other, and we note that no commenter opposes these suggested revisions. In addition, Microsoft states that it supports either version of the definition. Accordingly, we revise the definition as requested by Cisco as follows:

`Pre-configured' means an MLTS that comes equipped with hardware and/or software capable of establishing a setting that enables users to directly dial 911 as soon as the system is able to initiate calls to the public switched telephone network, so long as the MLTS is installed and operated properly. This does not preclude the inclusion of additional dialing patterns to reach 911. However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern.

c. Definition of Configured

65. The Commission proposed in the NPRM to define the statutory term “configured” to mean:

The settings or configurations for a particular MLTS installation have been implemented so that the MLTS is fully capable when installed of dialing 911 directly and providing notification as required under the statute and rules. This does not preclude the inclusion of additional dialing patterns to reach 911. However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern.

The Commission also asked whether the difference between its proposed definitions of “pre-configured” and “configured” was sufficiently clear.

66. NASNA, Panasonic, and West Safety support the Commission's proposed definition of configured. BRETSA notes that the reference to “notification” in the definition should be to “MLTS notification,” because that is the term as defined in the rules. BRETSA also proposes line edits to specify that configuring an MLTS for direct dialing means configuring it for “direct dialing of 911 without a requirement of first dialing or entering an additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9.”

67. We adopt the definition largely as proposed. We also agree with BRETSA that the reference to notification should be corrected to “MLTS notification.”

6

But we decline to adopt BRETSA's other proposed line edits as unnecessary. The definition already requires configuration so that the MLTS is fully capable when installed of dialing 911 directly “as required under the statute and rules,” which includes dialing without a requirement of first dialing or entering an additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9.

7

6

Consistent with this, we also change a reference in section 9.16(b)(2) of the rules from configuring an MLTS to provide “a notification” to configuring it to provide “MLTS notification.”

7

RedSky states that the titles of the definitions of pre-configure and configure are too broad and suggests changing them to “Pre-configured MLTS” and “MLTS Configurations,” respectively. We decline to make these changes because we do not believe the existing titles will cause confusion. In addition, our definitions are intended to track the language used in Kari's Law as closely as possible, and the statute and our implementing rules do not use the terms “pre-configured MLTS” or “configured MLTS.”

68. The revised definition of “configured” reads as follows:

The settings or configurations for a particular MLTS installation have been implemented so that the MLTS is fully capable when installed of dialing 911 directly and providing MLTS notification, as required under the statute and rules. This does not preclude the inclusion of additional dialing patterns to reach 911. However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern.

d. Definition of Improvement to the Hardware or Software of the System

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

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

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

70. The Commission also noted that the proposed definition is consistent with the legislative history of Kari's Law, which provides that an improvement to the hardware or software of a system is intended to include upgrades to the core systems of an MLTS and substantial upgrades to the software, particularly those requiring a significant purchase. The Commission asked whether there are types of routine hardware or software changes that should be included in or excluded from the definition and whether it should clarify that (1) improvements to the hardware of the system do not include the provision of additional extensions or lines, and (2) improvements to the software of the system do not include minor software upgrades that are easily achieved or made to improve the security of the system. In addition, the Commission asked whether upgrades requiring a significant purchase should be determined based on total cost alone, or whether it should interpret significant to be a relative determination based on the size of the entity making the purchase.

71. We adopt the definition of improvement to the hardware or software of the system as proposed. Under this definition, enterprises are not required to undertake “upgrades to the core systems of an MLTS,” “substantial upgrades to the software,” or “any software upgrades that require a significant purchase” in order to comply with the notification obligation.

72. We find that this definition is necessary to implement Kari's Law, which makes clear that the notification requirements of the statute apply only if the MLTS can be configured to provide notification “without an improvement to the hardware or software of the system.” The definition we adopt also is consistent with the legislative history of Kari's Law, which states Congress's intention to balance the need for notification with the goal of “not placing an undue burden on MLTS owners or operators.”

73. While NCTA supports the Commission's approach to this definition, others express concerns. Although RedSky objects to the definition on the ground that the vast majority of deployed MLTS systems can meet the notification requirements without any modification of the core systems, NCTA points out that line-based MLTS cannot be upgraded to offer notification without upgrades to core systems that would present a “daunting technological and financial challenge.” In this respect, NCTA states that MLTS are provided to commercial customers in a variety of configurations involving both line-based and trunk-based products and that it is not aware of any line-based systems that currently have a notification capability.

74. We also disagree with NASNA that any improvements to an existing MLTS, no matter how minor, should trigger the obligation to comply with Kari's Law and the implementing regulations. We conclude that such a policy would be inconsistent with the language of Kari's Law, which limits application of the statute to MLTS manufactured or brought into use after February 16, 2020. In addition, we clarify that (1) improvements to the hardware of the system do not include the provision of additional extensions or lines, and (2) improvements to the software of the system do not include minor software upgrades that are easily achieved or made to improve the security of the system.

75. With respect to upgrades, Panasonic requests that we further clarify that substantial improvements to the software of the system do not include software updates for addressing bug fixes, security vulnerabilities, or the addition of ancillary features; that maintenance or reconfiguration of the system to support new users or extensions should not be considered a substantial upgrade; and that the cost of the upgrade or update or the size of the enterprise should not be a factor. RedSky asserts that the terms “substantial” and “significant” are subjective and “should be quantified to ease in both requirement and enforcement abilities.”

76. We believe the factors cited by Panasonic may be relevant to determining whether a specific upgrade is substantial, but that such factors, if applicable, should be evaluated in light of the total facts and circumstances presented in the specific case. We also decline to quantify the terms “substantial” and “significant” as requested by RedSky, as the record does not provide sufficient basis for such quantification at this time. We expect that as Kari's Law is implemented, cases will arise that will enable us to provide further guidance on these issues. For now, we conclude that the guidance provided above is sufficient and consistent with the statutory language and legislative history of Kari's Law.

e. Definition of Person Engaged in the Business of Manufacturing, Importing, Selling, or Leasing an MLTS

77. Kari's Law applies to any “person engaged in the business of manufacturing, importing, selling, or leasing” an MLTS and provides that such persons may not manufacture or import an MLTS for use in the United States, or sell or lease or offer to sell or lease an MLTS in the United States, unless the system is pre-configured so that, when properly installed, a user may directly initiate a call to 911 from any station equipped with dialing facilities. In the NPRM, the Commission tentatively concluded that the meaning of the term “person engaged in the business of manufacturing, importing, selling, or leasing” an MLTS is self-evident and did not propose to modify this definition or add it to the rules. The Commission sought comment whether any additional clarification of this term is necessary for implementation or enforcement of Kari's Law.

78. As proposed in the NPRM, we conclude that the meaning of the term “person engaged in the business of manufacturing, importing, selling, or leasing an MLTS” is self-evident and that there is no need to adopt a definition for it. Cisco and Panasonic agree that the meaning of this term is self-evident, and no commenter opposes that view.

f. Definition of Person Engaged in the Business of Installing an MLTS

79. Kari's Law also places obligations on any “person engaged in the business of installing, managing, or operating” an MLTS. Such persons may not install, manage, or operate the MLTS for use in the United States unless it is configured for direct dialing of 911. In addition, such persons shall, in installing, managing, or operating the MLTS, configure it to provide notification if the system is able to be configured to provide notification without an improvement to the hardware or software of the system. In the NPRM, the Commission proposed to define a person engaged in the business of installing an MLTS as:

A person that configures the MLTS or performs other tasks involved in getting the system ready to operate. These tasks may include, but are not limited to, establishing the dialing pattern for emergency calls, determining how calls will route to the Public Switched Telephone Network (PSTN), and determining where the MLTS will interface with the PSTN. These tasks are performed when the system is initially installed, but they may also be performed on a more or less regular basis by the MLTS operator as the communications needs of the

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

80. The Commission sought comment on this proposed definition. While some commenters support the proposed definition, others ask the Commission to clarify it.

81. We adopt the definition of “person engaged in the business of installing an MLTS” as proposed. We decline to revise the language of this definition as requested by some commenters because we conclude that such revisions are not warranted; however, we supply guidance on how to apply this definition given points raised by some commenters.

82. In this regard, RingCentral notes that although the NPRM defines a “person engaged in the business of installing an MLTS” to include a person who “configures the MLTS or performs other tasks involved in getting the system ready to operate,” these functions are often part of providing cloud-based MLTS. Accordingly, RingCentral states, an over-broad definition of installation risks imposing duties (such as configuring notification) that should rest with the MLTS owner/operator as the entity best positioned to make deployment decisions for the enterprise. According to RingCentral, the Commission should address this by making clear that manufacturers and sellers are not installers simply by virtue of providing systems; “rather, manufacturers and sellers become installers only when their customers specifically retain them for installation by, for example, purchasing installation or other professional services.” In addition, RingCentral states that the Commission should recognize that installers are acting at the direction of owners and operators and should adjust the responsibility for implementation of those directions accordingly.

83. We disagree with RingCentral that responsibility for configuring or other tasks that fall within the definition of installation should automatically rest with the owner/operator in some circumstances, and we believe that a manufacturer of a hosted MLTS that configures the system is serving in that respect as an installer. Similarly, we note that some manufacturers provide systems with self-installing software. In that event, the manufacturer is also performing some of the functions of an installer. We agree, however, with RingCentral that if an entity performs the functions of an installer at the direction of the enterprise operator or manager, then the operator or manager in that scenario is also serving as the installer. Consistent with this approach, there may be multiple parties performing installation functions for a single MLTS. An enterprise manager or operator that directs aspects of the installation may, depending on the degree of its involvement, be responsible for complying with the installer's obligations. Evidence that the manufacturer has been retained specifically to install the system could be relevant in showing that the manufacturer is at least partly responsible for the obligations of an installer under Kari's Law and our rules, but the absence of such an agreement would not necessarily mean that the manufacturer has not performed any installation functions.

84. Panasonic states that the definition of a “person engaged in the business of installing an MLTS” should be limited to initial installation and configuration of the system or substantial improvement, “lest over-long potential liability risk the exit of skilled installers from the market.” We decline to limit the definition to initial installation and configuration of the system, as Panasonic requests. Panasonic presents no data to support its conclusion that this would lead to the exit of skilled installers from the market.

8

8

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

g. Definition of Person Engaged in the Business of Managing an MLTS; Person Engaged in the Business of Operating an MLTS; Role of the Enterprise Owner

85. The Commission proposed to define a person engaged in the business of managing an MLTS as:

The entity that is responsible for controlling and overseeing implementation of the MLTS after installation. These responsibilities include determining how lines should be distributed (including the adding or moving of lines), assigning and reassigning telephone numbers, and ongoing network configuration.

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

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

87. Commenters raise a number of issues with respect to the proposed definitions of MLTS operator and manager. NASNA and West Safety generally agree with the proposed definitions, while other commenters seek changes to the definitions or ask the Commission to clarify the role of the manager, operator, and enterprise owner.

88. We clarify the allocation of responsibility among the installer, operator, manager, and enterprise owner in certain respects. With these clarifications, we do not believe any changes are needed in the wording of the definitions of person engaged in the business of managing an MLTS and

person engaged in the business of operating an MLTS. Accordingly, we adopt these definitions as proposed.

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

9

BRETSA states that the rules should hold MLTS customers responsible for compliance to the extent the customer installs, maintains, operates and/or configures the MLTS.

10

9

RedSky also states that the term “operator” is not as pertinent as the term and concept of provider and that the Commission should introduce the terms “MLTS provider” and “MLTS user” to capture the actual business environment. In addition, RedSky suggests that the Commission replace the term “person” throughout the rules with the term “person or entity.” We decline to use “MLTS provider” and “MLTS user” because those terms are not used in Kari's Law, and our intent is for the rules to track the language of the statute whenever possible. We decline to substitute the term “person or entity” for the same reason; “person” is the term used in Kari's Law. We also note that Kari's Law was codified as part of Chapter 5 of the Act, and that Chapter 5 defines “person” to include “an individual, partnership, association, joint-stock company, trust, or corporation.”

10

BRETSA also states that MLTS providers with superior knowledge of the rules will invariably include in their sales and service agreements indemnification provisions that will undermine the deterrent effect of penalties under the rules. To address this, BRETSA urges the Commission to prohibit MLTS providers from requiring customers to indemnify them against liability for rule violations. We decline to prohibit providers from requiring customers to indemnify them because we find that any conclusions about the effect of such agreements on compliance with Kari's Law and the implementing rules would be highly speculative at this time. BRETSA also interprets the “person engaged in the business of” language to exclude a person that is engaged in a business unrelated to the provision of configuration or operation of an MLTS but that purchases or leases an MLTS for its use, and BRETSA proposed revisions to bring such persons under the rules. We decline to adopt these proposed revisions because we believe it is clear that Kari's Law and the implementing rules apply to a person engaged in a business unrelated to the operation of an MLTS that purchases or leases an MLTS for its own use.

90. We agree with these commenters that an enterprise owner has an obligation to hold third-party service providers responsible for complying with Kari's Law and our rules. We clarify, however, that a passive owner generally should not face liability if the owner contracts with a responsible third party and includes compliance requirements in its agreement with the service provider. We decline to find that a hotel is not an installer, manager, or operator of MLTS under the rules absent “compelling evidence to the contrary,” as AHLA requests. AHLA states that hotels typically do not perform the functions of an installer, manager, or operator. In that event, and provided that the hotel contracts with responsible third parties and includes compliance requirements in the agreements, the hotel should not face potential liability under the statute or our rules.

91. Commenters also ask the Commission to clarify the allocation of responsibility for complying with Kari's Law and the regulations in the context of hosted, cloud-based MLTS service. AT&T asserts that any new MLTS rules should clearly delineate the roles and responsibilities of the various players in the MLTS ecosystem and that any single stakeholder may play multiple roles in the MLTS ecosystem depending on how an MLTS system is configured. “For example, when AT&T offers a hosted MLTS solution to a business, AT&T should be responsible for compliance with the requirements applicable to those engaged in the installing, managing, or operating MLTS. However, where AT&T offers a Session Initiation Protocol . . . trunking solution to provide Public Switched Telephone Network . . . access for call delivery and the customer operates and manages the PBX, the customer should have responsibility for compliance. In both cases, the manufacturer should bear responsibility for ensuring its products are compliant.”

92. We conclude that whether a party is a manager, operator, or installer should be based on the party's conduct and whether it has performed activities that fall within the definition in our rules. Consistent with this, we agree with AT&T that when it offers a hosted MLTS solution to a business, it is responsible for compliance with the requirements applicable to those engaged in installing, managing, or operating an MLTS to the extent that its hosting service includes those functions. On other hand, if AT&T offers a trunking solution that provides public switched telephone network access with the customer operating and managing the PBX, we agree that the customer should have responsibility for compliance as an operator and/or manager.

93. RingCentral disagrees with AT&T's suggestion that hosted PBX providers would be installers and managers and urges the Commission to clarify that manufacturers and sellers are not installers or managers simply by virtue of providing systems. RingCentral asserts that “[p]roviders of hosted cloud-based PBX may simply provide the MLTS, without installation or implementation of the system after installation. . . . The definition of `manager' could . . . inadvertently include a cloud-based MLTS provider, as the definition includes a person who is involved in `implementation of the MLTS after installation.'” We note that a manufacturer or seller would be deemed an installer or manager only to the extent that it provides installation or management services with respect to the system. We offer these as illustrative examples for guidance on how the Commission would apply the rule. Any determination of a particular party's liability will necessarily require a fact-specific, case-by-case inquiry. The parties' contractual arrangements may be relevant in this determination, but they are not determinative, and an entity that performs the functions of a manager in violation of a contractual obligation not to do so could still be deemed a “person engaged in the business of managing an MLTS.”

94. Finally, we agree with commenters on the importance of the enterprise owner/MLTS customer's involvement in some situations. Commenters assert that the MLTS customer's involvement may be necessary for compliance, including updating end user location information and selecting an appropriate destination point for the 911 notification. As INCOMPAS and NCTA point out, the owner/customer in such situations is performing some of the functions of an MLTS operator or manager. Specifically, INCOMPAS states that in most circumstances, the customer or owner serves as the true operator of the system and exercises considerable control over MLTS service provided by INCOMPAS members. Once the system is installed and configured, the enterprise customer controls the amount of information that flows to managers and operators of these systems, including location information, and decides the responsibilities for the parties involved. Where enterprise customers have assumed primary operational roles with respect to the MLTS, INCOMPAS urges the Commission to “be careful not to attach liability for violations of the rules to

providers that are only engaged in technical support or network oversight.” NCTA asserts that some MLTS networks—typically those that use a customer-managed PBX—enable a customer to program or alter the calling pattern of a MLTS. In those instances, NCTA urges the Commission to assign sole responsibility for ensuring compliance with Kari's Law to the customer, who would be “engaged in the business of managing an MLTS,” rather than the voice service provider or equipment installer. Comcast also points out that an enterprise owner may choose to take on additional responsibilities with respect to the MLTS.

95. To the extent a violation of the statute or rules results from failure of the enterprise owner/customer to perform these tasks properly, the owner/customer will be responsible for that violation. Consistent with this approach, we agree with NCTA and Comcast that if the enterprise customer controls the routing of calls, the enterprise's voice service provider has fulfilled its responsibilities under the statute and regulations if it ensures that its service will not interfere with the customer's ability to configure the MLTS to be capable of transmitting direct-dialed calls to 911.

96. AT&T, RedSky, and USTelecom urge the Commission to clarify that the MLTS installer, manager, or operator need only offer the central notification capability to the customer to be in compliance with the law. AT&T states that some customers may not wish to have central notification if, for example, they have a small facility or they do not have staff to support monitoring notifications at all hours, and “the MLTS provider should not be responsible for compelling the customer to utilize a capability that the customer has judged unnecessary.” USTelecom states that an enterprise customer may choose not to designate or maintain a central notification point. We agree with these commenters that a manager, operator, or installer should not be liable if it performs its obligations in compliance with the statute and rules, but the enterprise customer declines to use the services offered.

4. Compliance Date and Transition Provisions

97. The effective date provision of Kari's Law states that the statute “shall apply with respect to a multi-line telephone system that is manufactured, imported, offered for first sale or lease, first sold or leased, or installed after” February 16, 2020. In the NPRM, the Commission proposed that the compliance date for regulations implementing Kari's Law would be consistent with this date. Accordingly, the proposed direct dialing and notification requirements would apply to MLTS manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020. The Commission sought comment on this proposed compliance date as well as on alternatives, and stated that commenters offering alternatives should explain how any date other than February 16, 2020, would be consistent with the statutory language.

98. The Commission also sought comment on whether to adopt transitional rules to inform consumers of the 911 capabilities of legacy MLTS that are not subject to the direct dialing and notification requirements of Kari's Law. The Commission noted, for example, that the direct 911 dialing and notification statute enacted in Texas requires enterprises to place a sticker adjacent to or on non-compliant MLTS devices providing instructions on how to call 911, and that the Commission's interconnected VoIP E911 rules require service providers to distribute stickers or labels warning subscribers that E911 service may be limited. The Commission sought comment on whether to require MLTS installers, operators, and managers to notify callers how to dial 911 from legacy systems, as well as options for doing so, associated costs, and potential sources of statutory authority for such requirements.

99. Some commenters support the proposed compliance date of February 16, 2020. Other commenters support an earlier compliance date. The record also is divided on whether the Commission should adopt transition rules, such as disclosure requirements, for legacy MLTS.

100. We adopt a compliance date of February 16, 2020, for the regulations implementing Kari's Law. This is supported by commenters such as West Safety, which asserts that the February 16, 2020, compliance date will afford market participants “sufficient advanced notice to make informed manufacturing, planning, and purchasing decisions and will give enterprises the proper level of financial and operational flexibility to retain their existing, grandfathered MLTS until end-of-life.”

101. We decline to adopt an earlier date because we find that the February 16, 2020, date is consistent with the plain language of Kari's Law, as well as with the intent of the statute. The statute applies prospectively as new MLTS are brought into use after February 16, 2020, or as existing systems are installed or first sold or leased after that date. This indicates that Congress intended to balance the benefits of requiring direct dialing before that date against the cost to enterprises of having to implement these requirements with respect to existing, legacy equipment currently in use. Commenters who urge the Commission to adopt an earlier date do not address how that would be consistent with the statutory language of Kari's Law.

102. With respect to transition obligations, Ad Hoc asserts that the Commission has no statutory authorization to adopt transitional rules for grandfathered MLTS equipment. Further, Ad Hoc urges the Commission to refrain from “impractical mandates” for notification to end users, such as stickers on equipment, also deeming them “ineffective.” AT&T similarly states that the Commission should not require warning labels for grandfathered MLTS because many of these systems have been in place for years, and requiring warning labels on each of them would be “incredibly disruptive to customers.” Panasonic states that the Commission should not impose specific employee notification requirements on MLTS installers, operators, and managers but should instead encourage “voluntary, industry-led initiatives” to do so. TIA urges the Commission to launch a public education campaign aimed at educating the public on the capabilities of legacy MLTS equipment and, as part of this program, to take steps to ensure that potential MLTS users are aware of their system's capabilities. NENA and NASNA, on the other hand, urge the Commission to adopt disclosure requirements for legacy MLTS. NENA asserts that it strongly supports some form of conspicuous notification on any MLTS handset not in compliance with the end-state Kari's Law implementation rules and that it has enumerated model requirements for such notification in its Model MLTS Legislation. NASNA states that the Commission should require MLTS owners to place a sticker near or on non-compliant MLTS devices “to avoid situations such as the one that gave rise to Kari's Law in the first place.”

103. We decline to require enterprises to notify end users of the 911 capabilities and limitations of MLTS that are not subject to the statute and our rules. Such a requirement falls outside the scope of Kari's Law and this proceeding to implement it. And even if we were consider adopting such a requirement under other statutory authority, neither the NPRM nor the record comment has addressed how the

benefits weigh against the costs of imposing such a requirement. Instead, as Panasonic suggests, we encourage enterprises to disclose the limitations on dialing 911 from such MLTS as part of voluntary best practices.

104. AT&T and NASNA also raise the issue of what level of upgrades to an existing MLTS would be significant enough to constitute manufacture, importation, sale, lease, or installation triggering compliance with Kari's Law when upgrades are made after February 16, 2020. AT&T states that upgrades unrelated to core MLTS functions in legacy systems should not trigger the obligation to comply with Kari's Law and the implementing rules. NASNA urges the Commission to ensure that any improvements to MLTS hardware or software that an enterprise makes in the future provide direct dialing and notification capabilities, as well as the same dispatchable location information that would be received by a PSAP.

105. On the basis of the record here, we decline to specify the level of improvements to an existing MLTS that would trigger compliance with the statute and regulations. We disagree with NASNA that any improvements to an existing MLTS, no matter how minor, should trigger the obligation to comply with Kari's Law and the implementing regulations. We conclude that such a policy would be inconsistent with the plain language of Kari's Law, which limits application of the statute to MLTS manufactured or brought into use after February 16, 2020, and with our decisions about upgrades in the context of the discussion above regarding the definition of “improvement to the hardware of software of the system.” It is also unclear what would constitute core MLTS functions in this context and exploring this issue further and more broadly could add to the resources that will be required to comply with the requirements of Kari's Law and our implementing regulations. Thus, we believe it would be difficult to answer this question in the abstract and more appropriate for the Commission to address it in response to a specific fact pattern, should one arise. Parties may file a request for a declaratory ruling to eliminate uncertainty, and the Commission can resolve any uncertainty in the marketplace as warranted.

5. Enforcement

106. Kari's Law empowers the Commission to enforce the statute under Title V of the Act, “except that section 501 applies only to the extent that such section provides for the punishment of a fine.” The Commission sought comment in the NPRM on how it should enforce and provide oversight of the requirements of Kari's Law. The Commission also noted that there can be great variation in the business relationships between MLTS installers, operators, and managers and sought comment on who, or which entities, should bear responsibility for violations of the proposed rules. In addition, the Commission proposed to apply a presumption that the MLTS manager bears ultimate responsibility for compliance with the rules implementing Kari's Law. As an example, the Commission stated that if an MLTS fails to comply with the rules, the MLTS manager would be presumed to be responsible for that failure, at least in part, unless the manager can rebut that presumption by demonstrating compliance with its obligations under the statute and rules. The Commission sought comment on this proposal. The Commission also asked how it should apportion liability in situations where multiple parties may be responsible for compliance with the statute and proposed rules, including whether there are situations in which parties should be held jointly responsible.

107. As proposed, we adopt a rule that if an MLTS fails to comply with the rules, the MLTS manager is presumed to be responsible for that failure, at least in part, unless the manager can rebut the presumption by demonstrating compliance with its obligations under the statute and rules. Most commenters that address the issue support the proposal for a presumption that the MLTS manager bears ultimate responsibility for compliance with the rules implementing Kari's Law. INCOMPAS, for instance, states that it supports the presumption because where enterprise customers have assumed primary operational roles with respect to the MLTS, “the Commission needs to be careful not to attach liability for violations of the rules to providers that are only engaged in technical support or network oversight.”

108. Verizon, on the other hand, asserts that the Commission should not adopt the presumption because it would not reflect the variety of contractual arrangements that can allocate implementation and system maintenance duties among installers, operators, managers, and enterprise customers. Instead, Verizon asserts, the Commission should assess compliance “based on how the contractual arrangements allocate the respective responsibilities.” We disagree that the presumption would be inconsistent with such multi-party contractual arrangements. We intend to have a case-by-case determination of who is “engaged in the business of managing” the MLTS (including by looking at the parties' contracts) before imposing liability. The party or parties that managed the MLTS would then have the burden of going forward with evidence to show that they met their obligations under the statute and rules.

109. We decline to adopt the proposals of RedSky and Avaya for apportioning liability in situations where multiple parties may be responsible for compliance. RedSky states that if the MLTS manufacturer does not provide a system that can meet the requirements, it should bear 100% of the responsibility; if the MLTS manufacturer provides a system that can meet the requirements and the operator chooses not to offer the required services, the operator should bear 100% of the responsibility; and if the manufacturer and the operator offer to meet the required services, then the MLTS end user should bear 100% of the responsibility. Avaya asserts that the MLTS operator ultimately should be responsible for compliance and that if services are subcontracted, the operator must ensure that the subcontractor implements compliant technologies and should remain primarily responsible for compliance. Ad Hoc responds that the proposals of RedSky and Avaya would amount to a presumption that the operator is liable in certain circumstances and that the Commission should “reject this premature, overzealous and ineffective approach to enforcement of any rules it may adopt in this proceeding.” Instead, we believe a case-by-case assessment of liability based on the facts specific to the particular investigation is the most appropriate way to enforce Kari's Law and our rules.

11

11

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

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

equipment manufacturers should not be liable for noncompliance of an MLTS manager with Commission rules unless the reason for the noncompliance is the design of the MLTS equipment. A manager, an operator, or an installer would not be liable if it performs its obligations in compliance with the statute and rules, but the enterprise customer declines to use the services offered. The same principle would apply to MLTS manufacturers, importers, sellers, and lessors; if the manufacturer, importer, seller, or lessor satisfies its obligations under the statute and rules, but the enterprise declines to use the system properly, then the manufacturer, importer, seller, or lessor should not be liable for the resulting noncompliance. Determinations of responsibility among multiple parties will necessarily be fact-specific, and we do not believe a safe harbor is appropriate or needed.

111. We also decline to exclude equipment manufacturers from liability for the noncompliance of an MLTS manager unless the noncompliance results from the equipment's design, as Panasonic and TIA request. We find that the manufacturer's obligations and potential liability under Kari's Law and our rules are sufficiently clear and that the enforcement approach Panasonic and TIA propose is not needed. Further, Kari's Law and our rules do not reference the “design” of an MLTS, and we believe doing so would introduce ambiguity into the enforcement process.

6. Complaint Mechanisms

112. In the NPRM, the Commission stated that it envisioned relying on existing Commission complaint mechanisms to facilitate the filing of complaints for potential violations of Kari's Law. For example, the Commission stated, PSAPs and the public could report problems via the Public Safety and Homeland Security Bureau's Public Safety Support Center or the Commission's Consumer Complaint Center.

113. We conclude that our existing complaint mechanisms should be sufficient for addressing potential violations of Kari's Law. Several commenters assert that the Commission's existing mechanisms are sufficient for the filing of complaints for potential violations of Kari's Law. We also provide that persons alleging a violation of the rules implementing Kari's Law may file a complaint under the procedures set forth in part 1, subpart E of our rules.

114. We also decline to establish procedures similar to those used for accessibility complaints under the Twenty-First Century Communications and Video Accessibility Act (CVAA) and section 255 of the Act. Panasonic and TIA urge the Commission to consider establishing a mechanism similar to that used for accessibility complaints under the CVAA or section 255 of the Act, including a mechanism for giving MLTS manufacturers, installers, operators, and managers an opportunity to resolve complaints informally before the Commission undertakes any enforcement action. Although the CVAA includes a provision directing the Commission to establish procedures for complaints and enforcement actions arising out of violation of certain accessibility requirements, Kari's Law does not include a corresponding provision. In addition, the Public Safety Support Center and Consumer Complaint Center procedures are flexible enough to provide an opportunity for informal resolution of complaints prior to enforcement should the Commission determine that such an opportunity would be appropriate.

115. BRETSA urges the Commission to establish a separate mechanism for PSAPs to report MLTS noncompliance. We decline to do so, given that the Public Safety Support Center process will be sufficient for this purpose.

7. Preemption of State Law

116. The preemption provision of Kari's Law states that “[n]othing in this section is intended to alter the authority of State commissions or other State or local agencies with jurisdiction over emergency communications, if the exercise of such authority is not inconsistent with this chapter.” Commenters sought guidance, however, regarding the general effects of this provision on state and local law.

117. Specifically, AT&T and BRETSA ask the Commission to clarify the effect of Kari's Law on state laws affecting 911 service for MLTS. AT&T urges the Commission to clarify how any new federal MLTS requirements will operate “vis-à-vis additional, and sometimes conflicting, state MLTS requirements.” AT&T, however, does not provide specific examples of any state requirements that appear to have the potential for conflicting with federal regulations implementing Kari's Law. BRETSA asks the Commission to find that state laws requiring existing MLTS systems to provide direct dialing, on-site notification, and interior location information are not inconsistent with Kari's Law, RAY BAUM'S Act, or the Commission's proposed rules. BRETSA, however, does not cite any such state laws, or even assert that any such laws exist. In addition, BRETSA asserts that federal rules implementing Kari's Law may establish grounds for civil claims and liability under state common law and statutes and urges the Commission not to limit a state's authority to “determine civil liability or presumptions thereof, and any immunities therefrom, and any penalties for violation arising from violation of state MLTS 9-1-1 obligations.” NARUC notes that it has adopted a resolution suggesting that any federal rules on MLTS direct dialing and notification “should be written to permit States to impose additional requirements `presuming that such additional requirements do not contradict or conflict with federal requirements.' ” NARUC's resolution does not supply specific examples, however.

118. As mentioned above, our objectives in the context of this broader rulemaking are to prescribe rules and regulations that we find are necessary to carry out Kari's Law, and to provide additional clarity and specificity regarding some of the terms used in the statute and the obligations placed on covered entities. We chose, in our discretion, to proceed incrementally, and thus did not propose to offer interpretations or rules going to the preemption provision of Kari's Law. Thus, at this time, and based on the record in this proceeding, we decline to provide guidance on the general effect of Kari's Law and our implementing regulations on individual state and local laws or on the “exercise of . . . authority” of a state's or locality's “jurisdiction” over “emergency communications” under a hypothetical set of facts. The record does not reflect specific examples (or even sufficient indication of a widespread problem) of state or local exercise of jurisdiction that may be inconsistent with the federal regulatory regime.

119. In addition, BRETSA asserts that waiver is an essential element of a regulatory scheme and asks the Commission to clarify that state or local public safety agencies and officials have authority to grant waivers of the federal MLTS 911 rules “upon finding that alternative deadlines and arrangements better serve the public safety or will avoid undue financial hardship.” BRETSA also asserts that state and local public safety officials and agencies should have the opportunity to impose conditions on waivers, such as training requirements for enterprise personnel or contractors. We decline to find that state and local public safety authorities have authority to waive the Commission's MLTS rules, as BRETSA requests, or to

impose conditions on such waivers. Requests for such waivers should, as with other Commission requirements, be presented to the Commission, while requests for waivers of state and local requirements should be presented to the appropriate state or local governmental entity.

8. Equipment Authorization Rules

120. The Commission also sought comment in the NPRM on whether to modify the equipment authorization rules as they apply to MLTS equipment manufactured after February 16, 2020. In addition, the Commission asked whether MLTS applications for equipment authorization under parts 2, 15, or 68 should constitute a representation that such equipment complies with MLTS 911 requirements.

121. Commenters largely support using existing equipment authorization rules. While NPSTC recommends that the Commission implement a formal process for compliance with the provisions of Kari's Law as part of an equipment authorization process, other commenters state that a formal process would be unworkable because many MLTS products are software-based solutions that need to be configured and installed on premises. Panasonic and TIA also assert that any modified equipment authorization rules would apply only to hardware-based solutions and that this would constitute an unequal burden on such solutions.

122. We decline to amend our equipment authorization procedures because we conclude that the existing equipment authorization procedures are sufficient. The MLTS marketplace represents a broad range of technologies that are continuing to evolve from more traditional, circuit-based solutions to wireless, cloud-based, and VoIP solutions, and we seek to ensure that our rules preserve flexibility and maintain technological neutrality.

9. Voluntary Best Practices

123. The Commission in the NPRM asked commenters to identify voluntary best practices that can improve the effectiveness of direct dialing and notification for MLTS. The Commission noted, for example, that the Michigan State 911 Committee encourages MLTS operators to work directly with local public safety entities to ensure compliance and “strongly recommend[s] that every MLTS operator work with their local 911 system manager/director to test the ability to dial 911 from the station lines associated with MLTS systems any time an MLTS has been installed or upgraded.” The Commission sought comment on this and other recommended or potential best practices that would help enterprises ensure the effectiveness of direct dialing and notification, including best practices for training on-site emergency personnel and others responsible for the implementation of direct dialing and notification. Commenters that address this issue generally encourage the development of voluntary best practices for direct dialing and notification under Kari's Law.

124. We encourage industry and the public safety community to work together to develop voluntary best practices that will help enterprises facilitate first responder access and minimize delays to response. NENA states that “[r]ecognizing the diversity in enterprise IT staffing . . . means all players in the MLTS 9-1-1 space—including manufacturers, sellers, and 9-1-1—should contribute to education and development of best practices for MLTS operation.” Cisco and BRETSA note the need for development of a standard testing protocol that would be employed when installers configure MLTS for 911, which we believe may be helpful. TIA states that efforts are underway to create a working group with members from industry and public safety to develop best practices and standards regarding Kari's Law requirements and the dispatchable location mandate under RAY BAUM'S Act. Several commenters also emphasize the need for a public awareness or education campaign for entities affected by the new rules. As noted above, we also believe it may be helpful for this effort to include guidance on disclosing the limitations of 911 dialing from legacy MLTS equipment.

125. Some commenters make suggestions we believe are more appropriate for inclusion in voluntary best practices. BRETSA suggests that the Commission require MLTS providers to supply a copy of the rules to each customer. NENA asserts that although MLTS operators and managers are generally in the best position to maintain the unique registered locations of their MLTS, vendors and manufacturers “must bear some responsibility to (1) encourage accurate and regular update of location information, and (2) provide means to alert operators and managers when registered location information has become out-of-date or hardware has been moved.” We decline to require these practices, but we encourage industry and public safety entities to consider them in the development of best practices.

126. We also agree with commenters about the importance of public outreach, and we intend to quickly develop and disseminate informational materials and to collaborate on outreach with our federal, state, and local partners, the public safety community, and industry.

10. Comparison of Benefits and Costs

127. The Commission sought comment on the costs and benefits of satisfying its proposed direct dialing and notification rules for MLTS coming into service after February 16, 2020. The Commission asked whether there are alternative methods of meeting the requirements of Kari's Law that would reduce costs and/or increase benefits and whether there are any barriers for those wishing to replace their MLTS after this date that would be costly to overcome. The Commission also requested comment on the expected lifespan of existing MLTS that are not currently able to meet the requirements of the proposed rules, the prevalence of such systems today, and the expected prevalence of such systems in 2020. In addition, the Commission sought comment on the cost of upgrading to an MLTS that supports the requirements of the proposed rules. The Commission noted that “[b]ecause most of the currently deployed MLTS are capable of being configured to meet the requirements of our rules today, without improvement to the hardware or software of the system, we tentatively conclude that our rules will impose no incremental costs to those who replace their MLTS as they come to the end of their useful life.” Accordingly, the Commission sought comment on this tentative conclusion.

128. Regarding notification, the Commission sought comment on its tentative conclusion that the costs of implementing its proposed requirements will not exceed the value of their benefits. The Commission also sought comment on any particular costs involved in imposing the notification requirement and alternative methods consistent with Kari's Law that may reduce costs and/or improve benefits. Further, the Commission sought comment on the costs and benefits associated with its proposed definitions. The Commission also asked for comment on the benefits and costs associated with any additional notification requirements the Commission might adopt, such as requiring operators of legacy MLTS to inform consumers of the 911 capabilities of those systems.

129. Some commenters support the Commission's tentative conclusions.

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

130. Other commenters generally agree with the Commission's proposals, but advocate that the Commission take a more measured approach towards adopting rules implementing Kari's Law than that suggested in the NPRM. To illustrate, Ad Hoc advises that as the Commission “considers how best to implement the statutory mandates of Kari's Law and section 506 of RAY BAUM's Act, the Commission should strictly adhere to its `light touch' regulatory philosophy.” Regarding notification, for example, Ad Hoc urges the Commission to avoid imposing detailed requirements beyond the proposed rule and to refrain from imposing transitional requirements on legacy MLTS.

131. The rules we adopt today to implement the direct dialing and notification requirements of Kari's Law balance the needs of stakeholders and maximize many public safety benefits. These benefits include potentially preventing fatalities, injuries, or property damage, improving emergency response time and access to emergency services, reducing delays in locating 911 callers, narrowing the gap between MLTS 911 service capabilities relative to other communications services subject to 911 requirements, driving further technology development, and lowering the cost of 911 solutions for MLTS. The record developed in response to the NPRM confirms that many existing, installed MLTS support direct dialing to 911 and notification. Further, the record developed in response to the 2017 Enterprise Communications NOI suggests that direct dialing and notification rules will impose no incremental costs to those replacing their MLTS at the end of its useful life. Because Congress mandated compliance with its direct dialing and notification requirements after February 16, 2020, and expressly grandfathered MLTS systems in service before that date, Congress has already crafted a balance of costs and benefits with respect to compliance to which the Commission is bound. Further, when Congress adopted Kari's Law, it contemplated that the requirements would evolve with advancements in MLTS technology. The record in this proceeding reflects that the modern enterprise communications ecosystem is complex and that legacy TDM-based technology is evolving towards an IP-based MLTS environment.

132. As Congress has specifically legislated to create this framework and identified areas in which the Commission shall enforce the statute, Congress has already assessed the benefits of its requirements. In the NPRM, the Commission observed that a Congressional Budget Office analysis concluded that most MLTS systems already are configured to meet the direct dialing and notification requirements of Kari's Law. In evaluating the Senate and House versions of Kari's Law, Cisco stated that it was not aware of any technological barriers to the implementation of Kari's Law as applied to MLTS. In the NPRM, the Commission cited eight states and some local governments that already have laws requiring direct dialing for 911 from MLTS. For these state and local jurisdictions, the Commission noted that its proposed rules would generally not affect the status quo and so would likely have little to no impact from a cost perspective. Moreover, the Commission observed that the existence of state-level requirements has already driven the manufacture of MLTS equipment that supports 911 direct dialing, much of which may have been marketed and sold in jurisdictions that do not have state or local requirements.

133. In this analysis, we address whether our rules achieve the benefits of Kari's Law in a cost-effective manner. The record supports adopting implementing regulations of Kari's Law and the Commission's conclusion in the NPRM that these rules are necessary to provide additional clarity and specificity regarding the terms used in the statute and the obligations placed on covered entities. As demonstrated by commenters, implementing regulations can provide important guidance to covered entities on complying with the law and the mechanism the Commission will use to enforce the statute. Accordingly, our rules include definitions of some of the terms in Kari's Law, as well as other provisions to clarify the obligations of entities regulated under the statute. The rules we adopt today generally track the statutory requirements of Kari's Law, are technologically neutral, and leverage advances in technology to improve access to emergency services as envisioned by Congress. The flexibility and minimum criteria we establish for direct dialing and notification should offset any potential burdens associated with compliance with our rules. Therefore, we conclude that there will be no immediate costs associated with meeting the requirements of our rules and that the amount of flexibility and lead time for compliance will help to minimize future potential costs.

134. The Commission also sought comment on the cost and expected benefit of the options proposed in the NPRM for implementing the notification requirement of Kari's Law, including whether to specify staffing requirements for the notification point. The Commission noted that while some state MLTS statutes include notification requirements, these statutes either expressly provide that the enterprise does not have to make a person available to receive a notification, or they are silent on whether the destination point must be staffed. The Commission stated that it did “not believe Congress intended to impose staffing or monitoring requirements that would impose unreasonable costs or limit the flexibility of MLTS installers, managers, and operators to develop efficient and cost-effective notification solutions that are appropriate for the technology they use, such as visual alerts on monitors, audible alarms, text messages, and/or email.” Rather than requiring staffing or monitoring, the Commission believed “that allowing

notifications to be directed to the points where they are likely to be seen or heard by existing staff achieves these goals at a negligible cost above what an MLTS manager would already spend when purchasing an MLTS.”

135. The record supports the Commission's view that Congress did not intend to impose burdensome staffing or monitoring requirements that would impose unreasonable costs or limit the flexibility of MLTS installers, managers, and operators to develop efficient and cost-effective notification solutions. The record supports setting minimum criteria for the notification to maximize benefits but also providing enterprises significant flexibility to tailor notifications to meet their specific needs. Similarly, the record supports adopting a requirement that notifications be sent to a location on-site or off-site where someone is likely to hear or see the notification, but not requiring that enterprise staff or monitor the notification point at all times. Additionally, the record suggests that the Commission's definition of “improvements to the hardware or software of the system” strikes the right balance to ensure that enterprises will not incur significant costs or core system upgrades in connection with providing notification, as provided under Kari's Law.

136. Taken together, the notification requirements we adopt today establish the necessary conditions that will make it more likely than not that 911 callers using an MLTS upgraded or placed into service after February 16, 2020, will benefit from the notification provisions of Kari's Law at a negligible cost above what an MLTS manager or owner would already spend when purchasing or upgrading an MLTS. In sum, the record suggests that establishing some minimum criteria represents a cost-effective means to reasonably ensure that notification will be timely received by a person with authority to act on it while balancing the needs of stakeholders, maintaining technological neutrality, preserving flexibility for enterprises, and minimizing burdens associated with implementing the notification requirement of Kari's Law.

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

137. RAY BAUM'S Act directs us to consider rules requiring the conveyance of dispatchable location with 911 calls “regardless of the technological platform used.” Based on this directive, we adopt dispatchable location requirements for MLTS and other 911-capable services that do not have such requirements, including fixed telephony, interconnected VoIP service, Telecommunications Relay Services (TRS), and mobile text.

1. MLTS

138. In the NPRM, the Commission observed that when a 911 call is placed in an MLTS environment, the system may provide the PSAP with the location of a main entrance or administrative office rather than the location of the caller, which can lead to delays in locating the caller and result in injury or loss of life. By directing the Commission “to consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call . . . including with calls from multi-line telephone systems,” Congress in RAY BAUM'S Act signaled its intent that the Commission focus on ensuring highly precise location information whenever feasible in connection with MLTS 911 calls.

139. In the NPRM, the Commission proposed to proscribe the manufacture, import, sale, or leasing of MLTS in the United States unless the system is pre-configured such that, when properly installed, the dispatchable location of the caller will be conveyed to the PSAP with 911 calls. The Commission further proposed to proscribe the installation, management, or operation of MLTS in the United States unless the system is configured such that the dispatchable location of the caller will be conveyed to the PSAP with 911 calls. The NPRM proposed to apply these requirements to the same entities subject to Kari's Law. We adopt these proposals with certain modifications.

a. Definition of Dispatchable Location

140. Section 506 of RAY BAUM'S Act defines “dispatchable location” as “the street address of the calling party, and additional information such as room number, floor number, or similar information necessary to adequately identify the location of the calling party.” In the NPRM, the Commission noted the substantial similarity of this statutory definition to the definition of “dispatchable location” in the Commission's wireless E911 location accuracy rules. The Commission proposed to construe the definitions as functionally identical, aside from the specification of the technological platform to which each definition applies. The Commission also sought comment on whether to further define “additional information” that may be necessary to “adequately identify the location of the calling party.” Finally, the Commission noted that the wireless E911 definition of dispatchable location requires street address information to be validated, and asked whether validation should similarly be required for dispatchable location information associated with MLTS 911 calls.

141. We adopt the definition of dispatchable location proposed in the NPRM, without further specifying the types of location information that may be required to locate callers in specific instances. We also require that to meet the definition of dispatchable location for MLTS 911 calls (and for calls from other platforms discussed in succeeding sections below), street address information must be validated. We agree with commenters that the definition of dispatchable location needs to be both functional and flexible. As APCO states, “[d]ispatchable location is well understood by public safety communications professionals to mean information sufficient for guiding first responders to the right door to kick down.” However, what constitutes “sufficient” information will vary significantly depending on the environment from which a 911 call originates. For calls placed from multi-story buildings or campus environments, first responders will typically require specific floor and room information, in addition to the street address of the building. For calls placed from many small businesses, on the other hand, a street address alone may provide first responders all the information they need to quickly locate the caller.

142. Accordingly, the definition of dispatchable location that we adopt today gives participants in the MLTS marketplace flexibility in deciding what level of detail should be included in the location information provided to PSAPs for particular environments, so long as the level of detail is functionally sufficient to enable first responders to identify the location of a 911 caller in that environment. Given the diverse and evolving nature of the MLTS market and the breadth of enterprise environments at issue in this proceeding, we decline to expand upon the statutory definition in specifying instances in which “additional information” beyond street address must be made available, or in identifying specific categories of additional location information beyond floor level or room number.

143. We also conclude that the definition of dispatchable location for MLTS 911 calls should include a requirement that street addresses be validated. The majority of commenters who addressed this issue indicate that such validation is essential to ensure that a location is sufficiently reliable for dispatch of first responders.

Commenters also state that street address validation is feasible and can be implemented by MLTS managers and operators without incurring significant costs. NENA states that MLTS managers or operators have “numerous methods” for validating addresses against databases like the Master Street Address Guide or databases that support the Location Validation Function in the NG911 environment. Finally, including street address validation in our dispatchable location definition for MLTS and other services covered by this order establishes parity with the dispatchable location definition in our wireless E911 rules and renders the two definitions functionally identical.

144. Cisco and ATIS express concern about the cost and feasibility of validation requirements imposed on large enterprises if validation beyond street address or building level is required. We emphasize that our adopted definition of dispatchable location—as in the case of our wireless rules—only references validation of street address information. While we encourage the development of solutions that will support validation of more granular location information than street address, including floor and room number, we agree with commenters who caution against imposing overly prescriptive requirements at this time that could inhibit the development of innovative solutions.

b. MLTS Provision of Dispatchable Location or Alternative Location Information

145. In the NPRM, the Commission “tentatively conclude[d] that it is feasible for 911 calls that originate from a MLTS to convey dispatchable location to the appropriate PSAP.” The Commission based this tentative conclusion on the record in the Enterprise Communications NOI proceeding, in which several commenters stated that they already offered methods for dynamically determining and conveying an MLTS end user's location. The Commission also noted the potential availability of dispatchable location solutions that require the customer to identify their own location and solutions that calculate a location by leveraging data available from the 911 caller's device and the network. The Commission sought comment on this tentative conclusion and on the range of potential approaches to providing dispatchable location. The Commission also sought comment on whether a MLTS that handles calls initiated by remote users,

e.g.,

off-site workers, should be required to convey location information about remote users.

146. The Commission noted that there may be instances where location information that does not meet the definition of dispatchable location could still be useful to PSAPs and first responders, either as supplemental information to validate the dispatchable location or as an alternative in instances where dispatchable location information is not available. The Commission stated its belief that “our rules and policies should not preclude—and in fact should allow and encourage—potential alternatives to dispatchable location.” The Commission asked whether other types of location information (for example, x/y/z coordinates) could be conveyed with a 911 call originating from an MLTS. Finally, the Commission proposed to require implementation of dispatchable location requirements for MLTS systems by February 16, 2020, the same as the implementation date for the requirements of Kari's Law.

147. Numerous commenters address the issue of MLTS dispatchable location, expressing a variety of viewpoints. Some commenters agree with the Commission's tentative conclusion that it is feasible to provide dispatchable location with MLTS 911 calls, and state that they are already capable of providing highly specific real-time location information for MLTS users. Other commenters, however, contend that while dispatchable location may be feasible for some MLTS 911 calls, it is not feasible in all cases, and that attempting to impose “one-size-fits-all” dispatchable location requirements on all MLTS would be unworkable.

148. Because the MLTS marketplace serves an enormous range of enterprise environments and includes systems that vary greatly in size, scope, and technological capability, we agree with commenters that our approach must take this variety into account.

12

In this regard, the comments suggest that the feasibility of providing dispatchable location for an MLTS 911 call, and the means available to provide it, vary significantly depending on whether the call is from a fixed or non-fixed device

13

and, in the case of non-fixed devices, whether the device is being used on or off the enterprise premises. Cisco points out that “dispatchable location is more supportable from on-premises fixed or `hardwired' MLTS stations (such as desk phones), more challenging for on-premises mobile clients (such as softphones), and even more difficult, if not impossible, for off-premises softphones using public internet or Virtual Private Network connections.” We find this assessment to provide a useful framework for addressing MLTS location issues. Therefore, in the discussion below, we separately address dispatchable location requirements for MLTS 911 calls from fixed devices, non-fixed devices being used on-premises, and non-fixed devices being used off-premises.

12

We agree with Avaya that service providers may use any technology that delivers dispatchable location, including any technology that complies with NENA i3 specifications.

13

For purposes of this proceeding, we define “fixed” MLTS devices as devices that connect to a single end point (

e.g.,

a desk or office phone) and are not capable of being moved to another endpoint by the end user, although they may be capable of being moved to a different endpoint by a professional installer or network manager. “Non-fixed” MLTS devices are devices that the end user can move from one endpoint to another without assistance.

(i) Fixed MLTS Calls

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

14

We also conclude that dispatchable location from fixed MLTS devices should be provided automatically

15

and that the street address associated with the fixed end-point should be validated.

14

We infer that fixed MLTS use occurs solely through connection of fixed devices with on-premises endpoints. Commenters did not cite any instances of MLTS supporting fixed devices off-premises. In the unlikely event that an MLTS were to support a fixed off-premises device, however, we see no reason why providing dispatchable location for such a device would be any less feasible than in the case of an on-premises device.

15

In other words, the dispatchable location information associated with a fixed MLTS device must be conveyed to the PSAP when a user places a 911 call, without further intervention by the user at the time it places the call. As noted below, an MLTS operator or manager may rely on an enterprise customer to acquire, maintain, and keep up-to-date the location information associated with a fixed MLTS device.

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

the Commission proposed in the NPRM to implement dispatchable location requirements for MLTS on February 16, 2020, contemporaneous with the compliance date for the requirements of Kari's Law, most industry commenters oppose this proposal, arguing that it would give them only a few months to implement requirements and noting that RAY BAUM'S Act, unlike Kari's Law, does not specify an implementation date for requirements the Commission may adopt. We conclude that a one-year timeframe is more reasonable to ensure timely implementation while affording affected parties reasonable time to take the necessary steps to come into compliance.

(ii) Non-Fixed MLTS Calls

151. Commenters express divergent views as to the feasibility of providing dispatchable location for on-premises MLTS 911 calls from non-fixed devices,

e.g.,

softphones or mobile handsets that that are capable of connecting to multiple Wi-Fi access points and can move from one location to another within a building.

16

Some MLTS service providers (

e.g.,

RedSky, Avaya, BluIP) state that they currently offer enterprise services that use access point location information to dynamically determine and convey an MLTS end user's precise location within a building. Such services typically rely on storing location information for each access point in a database (maintained by the enterprise customer or the MLTS provider) that can be referenced when a 911 call is placed from a particular access point.

16

While such devices are capable of being moved from one access point to another, we note that they may be only be capable of conducting a communications session with one access point at a time,

i.e.,

the system may not support seamless handoff of the device from one access point to another without interrupting the session.

152. However, other commenters point out that the effectiveness of enterprise database approaches is dependent on a number of variables and could be prohibitively costly. Relying on an enterprise database to provide location information requires the enterprise customer to either develop and maintain the database or to pay a third-party vendor to provide database services. It also requires procedures and safeguards to ensure that access point location data are entered accurately and kept up-to-date. In addition, depending on the density and distribution of in-building access points, access point location information may provide the caller's approximate location but may not be precise enough to provide dispatchable location,

e.g.,

the caller's specific room or office number. Commenters anticipate that over time, database location solutions for MLTS will become more widely available and capable of providing more precise location information, but they caution against adopting requirements that assume the near-term availability of database solutions to support dispatchable location across the full array of enterprise environments.

153. To address these concerns, we adopt a more flexible approach to providing dispatchable location for MLTS 911 calls from non-fixed devices. MLTS providers must convey automated dispatchable location for such devices when technically feasible but may rely on the MLTS end user to provide or confirm dispatchable location information manually,

e.g.,

by responding to a system prompt. Commenters generally agree that enabling such manual confirmation of location information by MLTS end users is both feasible and potentially beneficial.

154. We recognize that relying solely on end users to provide manual location updates can lead to user fatigue, and that manually provided information may not be accurate or up-to-date. As an additional fallback, commenters strongly agree with the Commission's statement in the NPRM that our rules and policies should “allow and encourage” alternatives to dispatchable location. Microsoft states that commercially available location services already in use around the globe can be leveraged “relatively quickly and effectively” to enhance the 911 capabilities of IP-based and cloud-MLTS and interconnected VoIP services in ways “far more accurate and reliable than a `registered location' manually entered by the end-user.” According to Microsoft, location technologies that could be leveraged include GPS/GNSS location, device-based sensing of Wi-Fi hotspots, and use of commercially available crowd-sourced location data. Comtech states that newer MLTS hardware can incorporate GNSS signals, which could be used to automatically corroborate any human-provisioned dispatchable location information. INCOMPAS contends that “relying on a `superset of location information' such as a wireless carrier's cell site, GPS, the Wi-Fi hotspots, and commercial location information gives regulated voice providers several opportunities to provide accurate dispatchable location data rather than relying on a static address.”

155. We agree with these commenters that our rules should harness the potential for commercially available device-based technologies and coordinate-based location methods to support the provision of MLTS 911 location information. Therefore, as proposed in the NPRM, we afford MLTS providers flexibility to provide alternative location information, including coordinate-based information, when providing dispatchable location is not feasible or cost-effective.

17

We also adopt a technology-neutral approach, as uniformly advocated by commenters, so that providers have the widest latitude to choose among available solutions.

17

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

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

e.g.,

building quadrant). We note that this approach is similar to the approach the Commission took in its wireless E911

rules, which allow wireless carriers to provide either dispatchable location or x/y/z coordinate-based location information for indoor wireless 911 calls.

157. These requirements will take effect two years from the effective date of rules adopted in this order. Although the Commission proposed to make dispatchable location requirements effective on February 16, 2020, we agree with commenters that a longer transition period is needed for MLTS providers to implement “granular” location requirements, particularly for non-fixed services. Cisco states that for “on-premises MLTS stations,” the Commission should consider a phased approach whereby the Commission would require MLTS managers to provide the street address of the caller's location while having the flexibility to provide additional information that they determine is sufficient for the enterprise “following a minimum transition period of two years.” Panasonic states that the Commission “should extend the compliance date for 3-5 years if [validation] capability is deemed necessary for all MLTS systems.” RingCentral states that the Commission should allow at least 18 to 24 months to develop solutions to meet the complex challenges posed by any new location requirements. VON states that the compliance date for nomadic VoIP providers should be at least 24 months after the effective date of our implementing order.

158. We conclude that a two-year transition period is appropriate for implementation of these requirements. It is consistent with implementation timeframes recommended by many commenters. We also agree with Microsoft, Cisco, and other commenters that within the next two years, MLTS will likely be able to leverage improvements in technology that can refine the location process, including improvements to location databases and commercially available device-based technologies that can provide a “superset” of location information on a standalone basis or in combination with network-based tools. Finally, we note that the two-year deadline adopted in this order will likely fall in late 2021, which will roughly coincide with implementation of milestones intended to improve in-building location of wireless 911 calls under the Commission's wireless location accuracy rules. This provides an opportunity for MLTS, as well as other services covered by this order, to explore opportunities with wireless carriers for developing common location solutions that can support in-building location regardless of the platform used to make the 911 call.

159. In contrast, we conclude that MLTS providers should not be subject to the same location requirements for off-premises MLTS calls to the extent compliance is not technically feasible. When an MLTS end user is off-premises, the MLTS does not typically control or have access to location information. Remote access instead may involve connecting via a third-party access point that is outside the control of the enterprise or the MLTS operator, and for which location information may not be available. We agree with commenters that this lack of access or control makes it considerably more challenging and costly for an MLTS to provide location information for off-premises users than on-premises users. TIA states that for an end-user connected remotely to an enterprise via a VPN, “ensuring accurate location data is difficult, if not impossible” because a VPN user's location is reported as an IP address of the enterprise at end of the IP tunnel. Panasonic states that where an employee uses an IP-capable client off-premises, “there is no way to locate such callers today without requiring the purchase of expensive third-party services that require manual location entry.” RingCentral states that “when a user goes off-site and leaves the enterprise network, it may not be possible to locate that user or even detect that the user has moved.”

160. In light of these factors, we conclude it is premature to prescribe specific standards for location of off-premises MLTS calls when compliance with our on-site requirements would not be technically feasible, and we therefore adopt a flexible approach that avoids imposing impossible requirements. For off-premises 911 calls, the MLTS operator or manager must provide (1) dispatchable location, if technically feasible, or, otherwise, either (2) manually-updated dispatchable location, or (3) enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost. This requirement will take effect two years from the effective date of rules adopted by this order. The flexibility inherent in this requirement should lessen the burden and the amount of time it will take to comply. We recognize that as a practical matter, MLTS providers are unlikely to be capable of providing dispatchable location for most off-premises calls, and that “best-available” location information may be limited in the near term. Nevertheless, over time this requirement will encourage development of improved location capabilities for off-premises MLTS 911 calls.

c. Roles and Responsibilities of MLTS Participants

161. The Commission proposed to apply MLTS dispatchable location requirements to “the participants in the MLTS marketplace we believe are best positioned to ensure that all installed MLTS are capable of conveying an accurate location to the appropriate PSAP.” As in the case of Kari's Law, the Commission proposed distinct requirements for MLTS manufacturers, importers, sellers, and lessors, on the one hand, and MLTS installers, operators, and managers on the other: The former group would be required to ensure that MLTS systems are “pre-configured” to convey dispatchable location with 911 calls, while the latter group would be required to ensure that MLTS systems are “configured” to convey dispatchable location with 911 calls. The Commission sought comment on whether more granular requirements should be placed on any of the MLTS market participants to which the proposed rules would apply and whether rules are needed to ensure that MLTS manufacturers and importers incorporate capabilities in their products to enable them to convey dispatchable location information.

162. Commenters are generally supportive of the Commission clarifying the roles and responsibilities of MLTS market participants with respect to providing location information with 911 calls. Commenters also agree with the Commission's proposal that responsibility for dispatchable location be apportioned in the same manner as responsibility for the direct dialing and notification requirements of Kari's Law. Therefore, as proposed in the NPRM, we impose pre-configuration requirements on MLTS manufacturers, importers, sellers and lessors, and configuration requirements on MLTS installers, operators, and managers. In light of our adoption of flexible location requirements, these pre-configuration and configuration requirements now reference the conveyance of dispatchable location and alternative location information.

163. Some commenters propose additional clarification of the respective roles and responsibilities of MLTS installers, operators, and managers in ensuring that accurate location information is provided with MLTS 911 calls. NTCA states that a service provider should be required “to configure proper location information

upon installation and initiation of service only to the extent they are involved in configuration of handsets and systems in the first instance.” RedSky states that “the level closest to the end user has the most accurate device . . . location data and should be held responsible for the provisioning of data.” Several commenters also note that MLTS operators and managers will need the assistance of enterprise customers to acquire, maintain, and update location information. Accordingly, Comcast contends, MLTS operators and managers should not be held responsible when a customer moves MLTS stations to new locations without their knowledge.

164. We agree with commenters that additional clarification of the role of MLTS installers, operators,

This text is long and has been trimmed here. Open the source document for the complete record.