2019-20137. 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, [phone] or via email at [e-mail]; William Beckwith, Attorney-Advisor, Policy and Licensing Division, Public Safety and Homeland Security Bureau, [phone] or via email at [e-mail]; Thomas Eng, Engineer, Policy and Licensing Division, Public Safety and Homeland Security Bureau, [phone] or via email at [e-mail]; Dr. Rasoul Safavian, Technologist, Policy and Licensing Division, Public Safety and Homeland Security Bureau, [phone] or via email at [e-mail].

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 [e-mail] or call the Consumer & Governmental Affairs Bureau at [phone] (voice), [phone] (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]

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]

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).”

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]

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]

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]

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]

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]

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.

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

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.

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.

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, and managers is warranted. We therefore adopt a proposal submitted by USTelecom to add specific rules that delineate the respective responsibilities of MLTS installers, managers, and operators relative to the provision of location information. We also clarify that in developing and implementing location solutions, MLTS managers and operators are entitled to rely on enterprise customers to acquire, maintain, and update location information.

d. Location Requirements for Small Businesses

165. The Commission sought comment on whether certain small business categories (e.g., of a specific size, or with a specific number of consumers) should be exempted from MLTS dispatchable location requirements. Commenters offered varying proposals for small businesses exemptions ranging from criteria based on square footage of enterprise; to allowing states and local jurisdictions to grant waivers; to applying requirements based on a minimum number of lines.

166. The rules we adopt today obviate the need for small business exemptions or waivers of MLTS location requirements based on square footage or number of lines. The rules afford all MLTS a broad menu of options for providing location information, and the requirements are also scalable to the needs of small businesses: In most instances, provision of street address information alone will be sufficient to identify the dispatchable location of MLTS 911 calls originating from small businesses. We believe this approach minimizes burdens and unnecessary complexity for small businesses while also preserving flexibility to advance the 911 location accuracy objectives of RAY BAUM'S Act.

e. Legacy MLTS

167. In the NPRM, the Commission proposed to apply location requirements to the same entities subject to the direct dialing and notification requirements of Kari's Law, which would exclude legacy MLTS. APCO argues that even though legacy MLTS is not subject to Kari's Law, legacy systems should be subject to location requirements because RAY BAUM'S Act does not prohibit applying such requirements to legacy systems, and some MLTS is capable of delivering dispatchable location today. Other parties support the NPRM proposal, arguing that requiring legacy MLTS to retrofit their systems to support dispatchable location would be disruptive and costly. On balance, we adopt the NPRM proposal. We decline to adopt APCO's request because doing so would require costly retrofitting of legacy MLTS—costs that would be more burdensome than for mass market services because legacy MLTS are specially configured for the particular enterprises they serve. In addition, applying Kari's Law and RAY BAUM'S Act to different classes of MLTS would create confusion and technical inconsistency, whereas applying the two statutes uniformly will encourage integrated 911 solutions for MLTS.^[18] We also disagree with APCO's suggestion that applying new location obligations to the existing MLTS ecosystem would be comparable to the Commission's approach to phased-in location accuracy for wireless services. In the wireless context, the increasingly precise location obligations adopted by the Commission were imposed on an industry already subject to extensive 911 obligations. In contrast, before Kari's Law and RAY BAUM'S Act were enacted, MLTS was not subject to any 911 obligations at the federal level. Adopting complex obligations from scratch for a legacy industry is vastly more complex and costly than an incremental change to an already-regulated service. We also believe our decision is consistent with Congressional intent to address MLTS 911 on a prospective basis and not to require retrofitting of existing MLTS.

f. Liability Protection

168. Microsoft requests that the Commission clarify that MLTS providers are entitled to the same liability protections afforded wireless carriers, iVoIP services and text-to-911 services. Microsoft observes that Congress has granted immunity from liability to certain emergency communications providers as follows:

A wireless carrier, IP-enabled voice service provider, or other emergency communications provider, and their officers, directors, employees, vendors, and agents, shall have immunity or other protection from liability in a State of a scope and extent that is not less than the scope and extent of immunity or other protection from liability that any local exchange company, and its officers, directors, employees, vendors, or agents, have under Federal and State law (whether through statute, judicial decision, tariffs filed by such local exchange company, or otherwise) applicable in such State, including in connection with an act or omission involving the release to a PSAP, emergency medical service provider or emergency dispatch provider, public safety, fire service or law enforcement official, or hospital emergency or trauma care facility of subscriber information related to emergency calls, emergency services, or other emergency communications services.

169. We find that this statutory liability shield extends to MLTS manufacturers, importers, sellers, lessors, installers, operators and managers. The statutory text applies its liability protections to “other emergency communications service providers,” which is defined to include “an entity other than a local exchange carrier, wireless carrier, or an IP-enabled voice service provider that is required by the Federal Communications Commission consistent with the Commission's authority under the Communications Act of 1934 [47 U.S.C. 151 et seq.] to provide other emergency communications services.” In this Report and Order, we find that MLTS manufacturers, importers, sellers, lessors, installers, operators and managers are subject to our jurisdiction and, consistent with the requirements of Kari's Law and RAY BAUM'S Act, we require them to configure MLTS systems to ensure delivery of 911 emergency information to PSAPs. Thus, we agree with Microsoft that MLTS plays a “significant role . . . in the provision of 911 services in the United States,” and that “MLTS apps will be engaged in the transmission of 911 information to PSAPs.” Accordingly, we find that because these entities are required to provide “emergency communications service,” MLTS manufacturers, importers, sellers, lessors, installers, operators and managers fall within the statutory definition of “other emergency communications provider.”

2. Fixed Telephony

170. In the NPRM, the Commission proposed to require fixed telephony providers to furnish dispatchable location with 911 calls. The Commission noted that these providers already provide validated street address information with 911 calls, which should meet the dispatchable location requirement for single-family dwellings, and asked about the feasibility of also providing floor level and room number for calls from multi-story buildings.

171. No commenter disagrees with our conclusion that by providing validated street address information with 911 calls, fixed telephony providers are already providing dispatchable location for single-family dwellings.^[19] With respect to fixed telephony calls from multi-story buildings, the limited comments we received on the issue support our view that fixed telephony providers are either already providing floor and room information or can readily do so at minimal cost. Panasonic states that “it is feasible for 911 calls from an endpoint assigned a [Direct Inward Dialing] number to convey a dispatchable location; each [Direct Inward Dialing] number can be assigned with a dispatchable location in the telephony carrier's database. West Safety states that it is “not aware of any technical limitations to fixed telephony providers conveying dispatchable location with a 9-1-1 call.” As a practical matter, for apartment building residents that are fixed telephony customers, dispatchable location can be readily provided because the apartment number (which often identifies floor level as well) is part of the customer's billing address. To the extent that fixed telephony providers need to provide more than street address and are not already doing so, the means to add this capability are readily available.

172. Based on these findings, we adopt our proposal requiring fixed telephony providers to deliver automated dispatchable location with 911 calls. This requirement will take effect one year from the effective date of the rules adopted in this order. Although the Commission proposed to implement this requirement on February 16, 2020, we conclude that a one-year timeframe is more reasonable to ensure timely implementation while affording affected parties a reasonable amount of time to take the necessary steps to come into compliance.

173. In an ex parte filing, IT&E requests that we exempt fixed telephone providers in U.S. territories from dispatchable location requirements, noting that one of the territories it serves has no street address database available and that territorial PSAPs do not have the capability to receive automated location information. To the extent that fixed telephony providers face limitations in providing automated dispatchable location due to factors beyond the provider's control, such providers may request relief under the Commission's waiver process.

3. Interconnected VoIP

174. In the NPRM, the Commission proposed to revise the E911 rules for interconnected VoIP to require the provision of dispatchable location for 911 calls. The Commission stated that with respect to fixed VoIP, it regards the current Registered Location approach as sufficient to support dispatchable location. With respect to nomadic VoIP, the Commission sought comment on the feasibility of providing automatic real-time dispatchable location but also proposed to allow VoIP providers to fall back to using Registered Location and manual updates if providing automated dispatchable location is not feasible or cost-effective. As discussed below, we adopt dispatchable location requirements that distinguish between fixed and non-fixed interconnected VoIP services.^[20] Also, we extend this requirement to “outbound only” interconnected VoIP providers as well as two-way interconnected VoIP providers covered by the current VoIP E911 rules.

a. Fixed VoIP

175. With regard to fixed interconnected VoIP, commenters generally agree with the Commission's tentative conclusion that Registered Location is already providing dispatchable location for single-family dwellings, and that using Registered Location to provide additional information for fixed VoIP serving multi-story dwellings is readily achievable in the near term. For example, VON states that it “generally agrees with the Commission's tentative assessment that current Registered Location obligations are sufficient to meet the definition of dispatchable location, and that such location information is already being conveyed.” VON further suggests that fixed VoIP providers have incentives to provide additional location information, noting that “customers now demand the ability to provide additional location information, including room and floor information where applicable, and VON members respond to these customer requirements.”

176. We adopt our proposal to require that fixed VoIP services providers transmit dispatchable location with each 911 call. While dispatchable location may be determined by means of a customer-generated Registered Location in the fixed VoIP context (to the extent a physical location conveys a street address that is validated), it must be provided automatically to the PSAP by the VoIP service provider, without additional action by the caller, at the time the 911 call is made. As in the case of our requirements for fixed MLTS and fixed telephony, and for the same reasons, this requirement will take effect one year from the effective date of the rules adopted in this order.^[21]

177. VON, however, also argues that the existing Registered Location rules are sufficient to ensure the provision of dispatchable location, and therefore no additional requirements for fixed VoIP providers are necessary. We reject VON's argument that there is no need to apply the new dispatchable location rules to fixed VoIP providers. Although the rules preserve the existing option of relying on Registered Location to provide the caller's location, they also establish a new requirement for providing dispatchable location automatically. Our inclusion of fixed VoIP in the new rules furthers the RAY BAUM'S Act objective of ensuring that dispatchable location is provided for all 911 calls regardless of the technological platform used.

b. Non-Fixed VoIP

178. The Commission sought comment in the NPRM on the feasibility of nomadic VoIP services providing automatic real-time dispatchable location, noting that “automatic provision of location is preferable because end users under stress in emergency situations may have difficulty providing manual updates and the updating process may delay the 911 call or subsequent location and dispatch.” The Commission sought comment on the capability of interconnected VoIP providers to dynamically determine the location of end users (1) when they are at home or their usual place of work, (2) when they move frequently between multiple locations, and (3) when they are at locations they do not regularly visit. The Commission also proposed to allow VoIP providers to fall back to using Registered Location if providing automated dispatchable location is not feasible or cost-effective. As a safeguard against sending incorrect location information, the Commission proposed that the VoIP provider “identify whether the service is being used from a different location than the Registered Location, and if so, either: (1) Prompt the customer to provide a new Registered Location; or (2) update the Registered Location without requiring additional action by the customer.”

179. As with non-fixed MLTS, we find that in the non-fixed VoIP environment, flexible rules and a longer time frame for providing accurate 911 location information are appropriate. In this respect, commenters generally agree on the desirability of automated validation of dispatchable location in the nomadic VoIP environment, but stress that there are challenges to providing such validation in many cases. RingCentral states that interconnected VoIP users “increasingly use browser-based applications for calling, but browser-based applications—by design—do not have the capability of detecting a user's location unless that user opts-in to location detection.” RingCentral states that similar challenges exist for users logging in with VPN, “as it may not be possible to detect . . . the user's true location.” Other commenters agree that the technology that would allow for automatic real-time dispatchable location for non-fixed VoIP users needs additional time to fully develop, and therefore agree with the Commission's proposal to allow providers to fall back to Registered Location options when dispatchable location is not feasible.

180. The record further indicates that non-fixed VoIP providers continue to rely heavily on Registered Location, but that alternative approaches are increasingly available that could support automatic location in some instances. For example, NENA states that the emergence of software-based VoIP applications on mobile phones has made automatic location updates more technically and economically feasible. RedSky states that “the technology exists” to provide dispatchable location for nomadic users through device-based location methods. Microsoft states that commercially available location services can improve interconnected VoIP location in ways “far more accurate and reliable than a `registered location' manually entered by the end-user[.]” The ability of non-fixed VoIP providers to provide automated real-time dispatchable location is highly dependent on whether granular location information is available for the access point from which the 911 call is placed, and whether the VoIP provider has access to that information. In some environments, particularly when end users are away from their home or regular workplace, this information is either unavailable or the development of information sources that could be leveraged by VoIP providers to provide dispatchable location (e.g., databases with access point location information) is in early stages. Therefore, we adopt rules that require automatic provision of dispatchable location when technically feasible, but also allow non-fixed VoIP providers to fall back on manual updating of Registered Location information by end users as a backstop approach.^[22]

181. We also conclude that it is important to encourage development of alternative approaches, based on the full range of device-based and other available location technologies, that place less burden on the end user than manual updates, and that can often provide more accurate, timely, and reliable location information for VoIP users that move frequently between multiple locations or are at locations they do not regularly visit. Such information may not always be precise enough to identify the caller's dispatchable location, but it can significantly reduce the potential for error or delay that otherwise occurs when a VoIP provider relies solely on Registered Location and uncertainty arises about whether the VoIP user is actually calling from that location. Commenters generally support giving interconnected VoIP providers the flexibility to provide alternative location information, including x/y/z coordinates, as a supplement or alternative to dispatchable location. Therefore, we give non-fixed VoIP providers flexibility to provide alternative location information, including coordinate-based information, from all available sources when providing dispatchable location is not technically feasible. This will provide flexibility for non-fixed VoIP providers to convey an accurate location to the PSAP while minimizing the burdens on the interconnected VoIP service provider and the end user.

182. We recognize that where a non-fixed VoIP provider provides alternative location information, the location fix may be less precise than a location that pinpoints the caller's location down to the room, office, or apartment level. We find that the record strongly supports allowing less precise—but still actionable—alternative location information as a fallback approach when providing dispatchable location is not technically feasible. Therefore, as an alternative to automated dispatchable location or end users' manual updating of Registered Location information, we allow non-fixed VoIP providers to provide alternative location information, which may be coordinate-based, sufficient to identify the caller's civic address and approximate in-building location, including floor level, in large buildings.^[23] We also clarify that as a last resort, a VoIP provider may route a 911 call to a national emergency call center for the operator to ask the caller about his or her location, so long as the provider has made a good-faith effort to obtain location data from all available alternative location sources. We also conclude that the two-year transition period established by this order is appropriate for implementation of these requirements, as it is consistent with implementation timeframes recommended by a number of industry commenters, provides time for development and deployment of improvements in technology that can refine the nomadic VoIP location process, including improvements to location databases and commercially available device-based technologies, and coincides with implementation of milestones intended to improve in-building location of wireless 911 calls under the Commission's wireless location accuracy rules.

c. Outbound-Only Interconnected VoIP

183. Consistent with Congress's approach of establishing regulatory parity across technological platforms and enabling the completion of outgoing 911 calls and messages from people in emergency situations, we adopt 911 location requirements for outbound-only interconnected VoIP providers. The requirements we adopt today are flexible and technologically neutral from a compliance standpoint and serve a vital public safety interest. We amend the definition of “Interconnected VoIP Service” used for 911 purposes to include outbound-only interconnected VoIP services that generally permit users to initiate calls that terminate to the PSTN. We thus require outbound-only interconnected VoIP providers to comply with our 911 obligations, including the requirement to notify subscribers of any limitations to E911 service. However, we modify the notification requirement to clarify that it may be satisfied through stickers or warning labels, or other conspicuous means, provided that the notification is prominently displayed or highlighted in a manner that makes it likely to be seen by the customer.^[24] Similar to our discussion of nomadic VoIP service above, we require outbound-only interconnected VoIP service providers, which are now encompassed by our amended language in the § 9.3 definition of “Interconnected VoIP Service,” to provide (1) dispatchable location if feasible, or, otherwise, either (2) manual updating of Registered Location information; or (3) alternative location information sufficient to identify the caller's civic address, floor level, and approximate floor location in large buildings. We require outbound-only interconnected VoIP providers to comply with the 911 requirements we adopt today two years after the effective date of the rules.

184. RAY BAUM'S Act directs the Commission to “conclude a proceeding to consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call, regardless of the technological platform used.” RAY BAUM'S Act also states that, “[i]n conducting the proceeding . . . the Commission may consider information and conclusions from other Commission proceedings regarding the accuracy of the dispatchable location for a 9-1-1 call . . . .” RAY BAUM'S Act defines a “9-1-1 call” as a voice call that is placed, or a message that is sent by other means of communication, to a PSAP for the purpose of requesting emergency services.

185. Consistent with RAY BAUM'S expansive approach, which recognized the Commission's existing 911 authority, the Commission broadly sought comment on what communications services not covered by existing 911 rules but that are capable of making 911 calls may fall within this definition. In the NPRM, the Commission asked whether (1) outcomes for 911 callers would be improved if it adopted 911 rules for these communications services that parallel existing rules, including any requirements for conveying dispatchable location and (2) new rules that are specifically tailored for those communications services would be more effective at improving outcomes. Specifically, the Commission observed that some outbound-only VoIP services partner with businesses that offer 911 smartphone applications that allow consumers to make calls to 911 and that 911 stakeholders have expressed concerns that calls received from these services may route to the incorrect PSAP, result in fraudulent calls, lack critical location information capabilities, and place the 911 caller at risk. The Commission noted that the current rules do not require outbound-only VoIP services to support 911 or convey dispatchable location with 911 calls, but it recounted that in 2011 the Commission sought comment on expanding 911 obligations to providers of outbound-only interconnected VoIP services.

186. The Commission has broad authority over interconnected VoIP services and 911. The RAY BAUM'S Act provided the Commission the flexibility to consider whether and how to apply dispatchable location requirements to services that provide the capability for users to make a 911 call, which includes outbound-only interconnected VoIP. We believe that the expansive scope of the legislative directive provides legal authority for the Commission to adopt regulations that will ensure dispatchable location data are conveyed with 911 calls with any voice service that satisfies the definition of “9-1-1 call,” including outbound-only interconnected VoIP service. It also leaves room to amend the definition of “Interconnected VoIP Service” at § 9.3 pursuant to the NET 911 Improvement Act and the CVAA.

187. We find that, from a 911 perspective, outbound-only interconnected VoIP services are functionally equivalent to landlines and other interconnected devices that connect to the PSTN and are 911-capable, and thus, we should require outbound-only interconnected VoIP service providers to comply with 911 obligations. As noted by West Safety, “[f]rom a caller's perspective, interconnected outbound-only VoIP service is, for the most part, similar to traditional telephone service, and its users reasonably expect it to function the same.” To illustrate further, Microsoft's Skype voice application facilitates internet-based calls yet also provides users the ability to call any landline or mobile device. Failing to require support for 911 services by outbound-only calling services that are able to place PSTN calls to any other North American Numbering Plan telephone number treats similarly-situated services differently and enables and rewards regulatory arbitrage. Moreover, treating these services inconsistently or 911 purposes is likely to breed consumer confusion, particularly when a caller is seeking help in a time of crisis.

188. Some commenters submit that the essential basis of Commission regulation of outbound-only VoIP services is whether those services would substitute for traditional telephone service. However, as discussed above, our 911 rules already apply to interconnected VoIP (as currently defined to refer to both inbound and outbound interconnection), and the Commission proposed extending those obligations to outbound-only interconnected VoIP more than eight years ago. To use Skype to call regular phones, consumers pay by purchasing credits, subscribe to Skype for unlimited calls, or buy a Skype phone number. Additionally, Skype emergency calling is enabled in certain countries, platforms, and versions of Skype software. Moreover, our current approach enables providers to avoid basic public interest obligations by offering purportedly separate “outbound-only” and “inbound-only” calling services, even though these services combined are functionally equivalent to traditional calling services and, in a regulatory sleight of hand, avoid basic public interest obligations. We decline to maintain this regulatory loophole to the benefit of one segment or market participants over another, and to the detriment of consumers.

189. Some commenters support expanding 911 obligations to outbound-only VoIP services on the grounds that consumers increasingly rely on a variety of interchangeable communications services to place 911 calls and expect those services to connect them to first responders. Others, however, argue that consumer expectations regarding outbound-only VoIP do not warrant imposing any obligations.

190. As an initial matter, we decline to make consumer expectations the touchstone for determining what types of services should be subject to 911 obligations. In this context, the relevant RAY BAUM'S Act provisions do not refer to consumer expectations; rather, they define “9-1-1- call” broadly, in relevant part, as “a voice call that is placed, or a message that is sent by other means of communication, to a public safety answering point . . . for the purpose of requesting emergency services.” The statutory focus, therefore, is on enabling the user to reach emergency services to request assistance, “regardless of the technological platform,” not on whether the service bears similarity to a traditional two-way phone call or whether consumers perceive it as such. Our decision to subject outbound-only VoIP service to 911 obligations is most consistent with Congress's focus on ensuring that all messages from a person to emergency services are received, regardless of the technology employed. A focus on consumer expectations, by contrast, would frustrate the statute by disadvantaging those people who were unaware that a particular device or technology was incapable of dialing 911—precisely the tragic circumstance that led to the adoption of Kari's Law.

191. In any event, we find that consumer expectations generally support our decision today. We find that consumer expectations on this issue have significantly changed since 2011. In this respect, we give significant weight to the fact that the increasing variety of interchangeable voice services on the market has changed the public's expectations about access to 911, and our rules today reflect those expectations. We are persuaded by BRETSA's comments that the fact that Microsoft has enabled emergency calling with Skype in some European countries and Australia demonstrates that 911 calling can be provided in the United States. BRETSA also asserts that it is more important for callers to be able to reach 911 in an emergency than that a PSAP can reconnect a dropped call, and we agree.

192. The commenters who assert that consumers do not expect to reach 911 from outbound-only systems present little data that support their position. In particular, Microsoft, VON, and INCOMPAS oppose the Commission's proposed expansion of 911 obligations to outbound-only VoIP calling applications, arguing that users of one-way calling capabilities do not expect to reach emergency services on these tools and do not use them for emergency calling. Microsoft adds that it voluntarily deployed emergency calling on its one-way, outbound-only calling feature Skype to Phone (formerly SkypeOut) in four foreign countries (Australia, Denmark, Finland, and the United Kingdom) and that only 1,788 emergency calls were made in those four countries in the most recent 23-month period. According to Microsoft, “[t]he low emergency call volumes are evidence that consumers do not expect to have the capability to make emergency calls through Skype desktop and tablet applications and, when this capability is provided to them, they tend not to use it.” Microsoft also states that many emergency calls placed from this calling feature lasted less than one minute, “strongly suggesting accidental or nefarious calls to emergency services since valid emergency calls tend to last longer than a minute.” Commenters argue that consumers do not expect to use outbound-only VoIP services to place emergency calls, in part because some expected features of 911 calling, specifically PSAP callback, are not readily available. Thus, according to Microsoft and INCOMPAS, the Commission would be creating consumer expectations for 911 services where certain features that customers have come to expect with emergency calling are technically not feasible. Microsoft and INCOMPAS also contend that expanding 911 rules to outbound-only VoIP will increase nuisance or accidental calls to emergency services, which is not in the public interest.^[25]

193. We find these arguments unpersuasive. First, it is unsurprising that some consumers may not presently expect outbound-only calling services to support 911 dialing and location services, as they have not been obligated to do so. In this respect, though, we disagree with the view that the Commission should refrain from acting for fear of “creating” expectations regarding the availability of 911 services; to the contrary, the Commission should act where it finds a need to support public safety. Second, the data presented prompt us to draw the opposite inference on calls to emergency services from SkypeOut in four foreign countries than that asserted by Microsoft. Rather than indicating that 911 connectivity was not expected in these instances, we find the existence of these calls is instead evidence that at least some users expected—and needed—to call for help via SkypeOut. We may further infer that as use of these services becomes more widespread, the expectations carried with these services will align with traditional voice services. That domestic expectations have also evolved with the technology is reflected in the congressional emphasis that the Commission should consider whether dispatchable location obligations apply “regardless of the technological platform.” Furthermore, concerns about overly broad regulation are misplaced because we apply the change in a limited way—solely to 911 obligations on outbound-only interconnected VoIP service providers. Finally, the possibility that there may be nuisance or inadvertent calls to 911 from outbound-only services is not a sufficient reason to exclude such services from the 911 obligations applicable to interconnected VoIP service providers, thereby providing no access to 911 for callers with legitimate emergency needs to use these services. While we recognize that accidental or nuisance calls can strain already limited PSAP resources, there has been no demonstration that these calls would overwhelm PSAP capabilities.^[26]

194. Several commenters support expanding 911 dispatchable location requirements to outbound-only VoIP services, and state that technically feasible solutions exist for such service providers to provide that data. Comtech states “it is imperative that any location requirements adopted for 911-capable services take into consideration the current state of technology and its rapid rate of change.” Verizon indicates that, like nomadic VoIP, the Commission should clarify that nomadic outbound services could use either dispatchable locations or registered locations because the same concerns raised in the context of nomadic VoIP services apply.

195. We find that it is technically feasible to require outbound-only interconnected VoIP service providers to convey the dispatchable or alternate location requirements we adopt today. The location requirements for outbound-only interconnected VoIP service providers allow for flexible, technologically neutral compliance. Although the NPRM sought comment on such communications services that are not covered by existing 911 rules yet are capable of making a 911 call and their ability to convey location information to the PSAP, no commenters submit that it is not possible for outbound-only interconnected VoIP providers to convey such location information. With the additional compliance time provided below, we anticipate that such a capability can be readily applied within the United States.

196. 911 VoIP Service. The Commission sought comment on expanding the scope of those IP-based services subject to our 911 rules to include not only interconnected VoIP but to also include “911 VoIP Services,” which was proposed to include those services that enable real-time, two-way voice communications that require IP-compatible customer premises equipment and permit users generally to initiate a 911 call, even if the service does not permit users generally to receive calls that originate on the PSTN, thus encompassing those services that are considered “outbound only VoIP.” The Commission further stated its intent to retain the existing definition of “Interconnected VoIP Service” to avoid inadvertent impact on the term as used by various non-911 statutory provisions. By proposing a new “911 VoIP Service” category for use in the Commission's 911 rules, the Commission sought to avert unintended consequences.

197. We conclude that the best approach to achieve what the public interest demands is to amend the definition of “Interconnected VoIP Service” to expand those services subject to our 911 rules, rather than to adopt a separate “911 VoIP Service” definition. In this respect, we find that the definition of “911 VoIP Service” proposed in the NPRM mirrors the existing definition of “Interconnected VoIP Service,” with the exception that the fourth element of the proposed definition does not reference calling numbers or interconnection to the PSTN and is limited to 911 calls. Amending the definition of “Interconnected VoIP Service” to include outbound-only VoIP services solely for purposes of extending our 911 obligations is consistent with our intent to apply only this set of obligations to such services, but in a manner that responds to record comments and avoids the unintended consequences to other uses of the term. For example, some commenters express concerns with the proposed definition of “911 VoIP Service” and the applicability of our 911 requirements, including dispatchable location, to those services. Verizon states that the Commission's proposal to apply the interconnected VoIP 911 rules, including the registered location choice, to newly defined outbound-only “911 VoIP Services” may be overbroad. Verizon asserts that it is unclear that outbound-only VoIP meets the New and Emerging Technologies (NET) 911 Improvement Act standard of “widely accepted and fungible substitutes for telephony” if there are no other connections to the public switched telephone network. According to Verizon, the proposed rule also is unclear because it would require that calling party number information be provided on all 911 VoIP services, which could enable callback for a service that supports both outbound and inbound calling, but “would not help for outbound-only services.”

198. Accordingly, we decline to adopt the defined term “911 VoIP Service” and instead add an additional category of services that constitute interconnected VoIP for the purposes of 911 obligations to expand the scope of services to those that are generally capable of allowing users to initiate calls that terminate to the public switched telephone network, including calls to 911.^[27] We expand the definition of “Interconnected VoIP Service” in § 9.3 of the Commission's rules to mean a service that permits users generally to terminate calls to the public switched telephone network.^[28]

199. We concur with BRETSA's concerns that outbound-calling voice applications or service providers could configure their services for the specific purpose of avoiding 911 compliance. As a result, the definition of “Interconnected VoIP Service” extends 911 calling requirements to interconnected, outbound-only VoIP services that generally permit users to terminate calls to the public switched telephone network. We further clarify that the revisions we adopt today preserve the application of the original definition of “Interconnected VoIP Service” to other parts of the Commission's rules while expanding those services to which the Commission's 911 rules apply. Thus, the non-911 statutory provisions and rules that reference the current definition of “Interconnected VoIP Service” in § 9.3 of the Commission's rules are not disturbed.^[29] Consistent with the directive of RAY BAUM'S Act, and as supported by the record, we find that expansion of the location requirements to interconnected VoIP service, which includes outbound-only interconnected VoIP service, enacts 911 rules that are flexible and technologically neutral from a compliance standpoint while limiting regulatory disruption.

200. Some commenters also argue that expanding 911 requirements to “911 VoIP Services” exceeds the scope of the Commission's statutory authority under the NET 911 Improvement Act. Microsoft states that the Commission has not proposed a sufficient basis of statutory authority to impose emergency calling obligations on outbound-only voice applications, and contends that the NET 911 Improvement Act provided the Commission authority to establish emergency calling requirements for IP-enabled voice services, which were defined to be synonymous with “Interconnected VoIP Service.” However, Microsoft asserts that the NPRM “does not propose to expand or modify the definition of `interconnected VoIP service' to include outbound-only calling apps. Nor does it propose an independent basis for imposing these requirements on applications that currently satisfy the statutory definition of `non-interconnected VoIP.' ” As a result, Microsoft claims that the Commission's proposal would “involve an extraordinary expansion of the scope of the FCC's regulatory authority and would exceed the limits of reasonable statutory interpretation.”

201. We disagree that expanding 911 requirements to the underlying services that would have met our proposed definition of “911 VoIP Services” exceeds the scope of the Commission's authority under the NET 911 Improvement Act, particularly when coupled with the directive of RAY BAUM'S Act.^[30] In this respect, by amending the definition of interconnected VoIP we meet both the letter and spirit of both laws, which provides the Commission discretion and flexibility to address new technologies. We find that Congress, in directing the Commission to consider all technological platforms, intended the Commission to consider 911 obligations for these technologies. Moreover, the NET 911 Improvement Act provides that “[i]t shall be the duty of each IP-enabled voice service provider to provide 9-1-1 and enhanced 9-1-1 service to its subscribers in accordance with the requirements of the Federal Communications Commission, as in effect on the date of enactment of the [NET 911 Improvement Act] . . . and as such requirements may be modified by the Commission from time to time.” Pursuant to subsequent legislation, the Commission also retains ample authority to amend the definition of interconnected VoIP. As a result, we find that the Commission has direct statutory authority to modify the definition of “Interconnected VoIP Service” to include outbound-only interconnected VoIP, and today we modify that definition.

202. Although in the NPRM the Commission stated its intention to avoid disturbing the existing definition of interconnected VoIP since it is referenced by various non-911 statutory provisions and rules, we find that our approach to amending the definition of “Interconnected VoIP Service” in § 9.3 of the Commission's rules satisfies our proposed intent and responds to concerns raised by commenters. Specifically, to implement RAY BAUM'S Act, the Commission led with a proposal to adopt the definition of “911 VoIP Services” and also sought comment on extending 911 requirements, including location obligations, to outbound-only VoIP services under the definition of “911 VoIP Services.” We note that entities which provide one-way, interconnected VoIP service have been on notice since 2011, and even as early as 2005, that the Commission was considering expanding the scope of its 911 rules to include their communications services. The NPRM was informed by, and cited to, these earlier rulemaking efforts, including the outstanding proposals from 2011, and RAY BAUM'S Act left the Commission discretion to consider these earlier efforts. The rule we adopt today reflects consideration of proposals raised in earlier Notices of Proposed Rulemaking and in the NPRM to extend dispatchable location obligations to one-way VoIP calls, the purpose of the NPRM to dispatch our RAY BAUM'S Act mandate to consider all technological platforms, and record comment received in response. In light of the comments received, we have not amended our definition of interconnected VoIP, except as it affects 911 service obligations for outbound-only interconnected VoIP service.

203. Furthermore, as stated above, commenters express concern about our statutory authority to expand our 911 rules to services beyond interconnected VoIP services, and in response we act upon their suggestion that an amendment of the definition of “Interconnected VoIP Service” would accomplish the Commission's intended objective, particularly where we limit the definition change solely to impose 911 obligations. Moreover, the similarities in the proposed language of the definition of “911 VoIP Services” largely tracks the language of “Interconnected VoIP Service,” and as such, regardless of the label used, the service to which our rules were to be applied is sufficiently apparent.

204. We amend the definition of “Interconnected VoIP Service” to include outbound-only interconnected VoIP services. The expansive scope of the legislative directive coupled with our discretion to amend the definition of “Interconnected VoIP Service” provides sufficient legal authority for the Commission to extend 911 regulations, including rules to convey dispatchable location with 911 calls, to outbound-only interconnected VoIP services. Doing so in this fashion also avoids loopholes for evading regulatory obligations that protect the health and safety of the American people, which commenters have pointed out to be a risk of attaching such obligations only to those who choose to provide “911 VoIP Services.” We believe that this approach is consistent with our objective to promote safety of life and property through communications.

205. Compliance Deadline. In the NPRM, the Commission proposed to require compliance for dispatchable location requirements on the same date as the proposed implementation for Kari's Law, i.e., February 16, 2020. The Commission further tentatively concluded that applying the same compliance date across all platforms will promote efficiency and encourage development of common dispatchable location solutions. No commenters addressed compliance deadlines for outbound-only interconnected VoIP service providers, but some commenters objected to the proposed February 16, 2020 date as premature for imposition of dispatchable location requirements for any service.

206. We adopt a two-year period for compliance for outbound-only interconnected VoIP service. Due to the similar nomadic or mobile functionality of the services, we find that similar implementation considerations for nomadic VoIP providers are applicable to outbound-only interconnected VoIP providers and warrant additional time for compliance. Furthermore, adopting a two-year compliance period for outbound-only interconnected VoIP service providers will result in a compliance date in the same time frame as the implementation deadline for wireless E911 location requirements, which will promote regulatory parity and encourage the development of common location solutions across all platforms.

4. Telecommunications Relay Services (TRS)

207. In the NPRM, the Commission observed that TRS providers are required to deliver emergency calls to an appropriate PSAP and to provide the location of the emergency. For some of these services, the service provider is required to ask callers for their location information at the beginning of the emergency call. For emergency calls made through a Video Relay Service (VRS) or IP Relay (collectively, “internet-based TRS”), the service provider must transmit location information to the PSAP in the form of a Registered Location under rules modelled on the Commission's interconnected VoIP 911 rules. In the NPRM, the Commission observed that “internet-based TRS and interconnected VoIP face similar concerns regarding the ability to accurately locate end users that use a mobile or portable device.” The Commission therefore proposed dispatchable location requirements for internet-based TRS paralleling the requirements it proposed for VoIP, i.e., allowing internet-based TRS providers flexibility to implement automated dispatchable location and to fall back to Registered Location options when real-time dispatchable location is not feasible. The Commission asked whether there are differences between internet-based TRS and interconnected VoIP that might require taking a different approach to TRS dispatchable location, and sought comment on alternative approaches.

208. We adopt flexible rules for internet-based TRS that largely parallel our rules for fixed and nomadic VoIP. In this respect, TRS commenters express many of the same views as VoIP commenters on the feasibility of providing automatic real-time dispatchable location. Sorenson and CaptionCall state that “the technology for automatically locating mobile users is advancing rapidly and the technology for locating nomadic VoIP subscribers is improving, though it is still not reliable in every instance.” Nevertheless, “[i]f solutions are not technically feasible for over-the-top VoIP services, whether mobile or nomadic, they will not be technically feasible for internet-based TRS providers involved in call routing.” Sorenson also states that in certain situations, internet-based TRS providers lack the capability to automatically detect whether a videophone or device has changed location, in which case the only remaining option is to prompt users to confirm or update their locations. Sorenson and other commenters therefore support the Commission's proposal that internet-based TRS providers should have the option to fall back to Registered Location when dispatchable location is not feasible.

209. TRS commenters also support being given flexibility to provide alternative location information when more precise location information is not available. Sorenson and CaptionCall state that “x,y,z needs to be a permissible alternative to dispatchable location, and may be necessary as location solutions evolve technologically.” Sorenson states that when its ability to use device-based location is fully implemented and operational “the customer's device will automatically determine an x, y (and, where available, z) location estimate,” provided the consumer has consented to allowing the VRS application to access location information from the device. In an ex parte filing, Sorenson and CaptionCall propose to require internet-based TRS providers to provide dispatchable location when it is available but to permit automatic geolocation when the dispatchable location is unavailable. If neither a dispatchable location nor geolocation information is available, their proposal would allow the provider to provide the Registered Location. Sorenson and CaptionCall also propose to specify in the rules that an internet-based TRS provider can use a back-up call center when the provider is not confident that it can otherwise reliably identify the caller's location.

210. We find that in the internet-based TRS environment, flexible rules and a longer time frame for providing accurate 911 location information are appropriate. The record indicates that internet-based TRS providers continue to rely heavily on Registered Location, but that alternative approaches are increasingly available that could support automated dispatchable location in some instances.

211. For 911 calls from fixed internet-based TRS,^[31] beginning one year from the effective date of the rules, we require internet-based TRS providers to provide automated, validated dispatchable location for each call. For 911 calls from non-fixed internet-based TRS,^[32] beginning two years from the effective date of the rules, we require internet-based TRS providers to provide with each 911 call (1) automated dispatchable location, if technically feasible, or, otherwise, either (2) manual updating of Registered Location, or (3) alternative location information, which may be coordinate-based, sufficient to identify the caller's civic address and approximate in-building location, including floor level, in large buildings when the first two are not technically feasible.

212. TRS commenters also identify a distinction between IP captioned telephone services (IP CTS), and relay services such as VRS and IP Relay. Commenters state that call set-up and routing for most IP CTS calls are handled by the user's underlying voice provider rather than the TRS provider. In case of a 911 call, the IP CTS Communications Assistant provides captioning but is not able to speak directly with the parties or generate location information, much less provide it to the PSAP. Sorenson and CaptionCall jointly suggest that the Commission should separate the dispatchable location requirements for VRS from the requirements for IP CTS, “allow[ing] each service to be treated in an appropriate manner.” Further, with respect to IP CTS, Sorenson and CaptionCall state that the ability of web/wireless IP CTS applications to provide information other than Registered Location is dependent upon the capabilities of underlying nomadic or mobile VoIP providers. To afford IP CTS providers time to implement these capabilities, they propose that the Commission set the implementation date for IP CTS one year after the implementation date for nomadic or mobile VoIP.

213. We clarify that these requirements do not apply to TTY-based TRS providers, or to internet-based TRS providers who completely rely on their customers' underlying voice service providers to handle emergency call set-up, routing, and provision of location information. In such cases, it is not necessary to impose requirements on the TRS provider because the underlying service provider is subject to the relevant 911 requirements, including location requirements, in connection with the call. Next, we are dismissing Sorenson and Caption Call's request to set the implementation date for IP CTS one year after the implementation date for non-fixed VoIP because the location rules we adopt herein provide sufficient flexibility including fall back to Registered Location, and they only apply to IP CTS providers that handle call set-up and routing.

214. We also clarify that the rules do not require TRS providers to automatically detect when a device is being used at a different location from the Registered Location to the extent doing so is not technically feasible. The record indicates that such detection is not technically feasible for some internet-based TRS providers. In such cases, the requirement can be met by a manual prompt to the user asking for confirmation whether the user is at the Registered Location or a different location.

215. We agree with commenters regarding routing of calls to Emergency Calling Relay Centers as a last resort in the occasional case where neither a prompt for a manual update nor any alternative technology confirms the validity of the caller's location or otherwise provides actionable dispatchable location information. In those isolated cases, we will allow internet-based TRS providers to route the call to an Emergency Calling Relay Center, so long as the provider has made a good-faith effort to obtain location data from all available alternative location sources.

216. Finally, we find that our TRS location rule amendments herein do not conflict with the IP CTS emergency calling requirement rule proposals in, or prejudge the outcome of, the IP CTS Reform Further Notice. The Commission did not propose any changes to location requirements in the IP CTS emergency call handling rules. We crafted our new TRS location rules so that they will harmonize with the proposed IP CTS emergency call handling rules in the event the latter are adopted, as well as with the existing TRS rules in the event that the proposed IP CTS emergency call handling rule amendments are not adopted. Further, the Commission noted that “issues regarding location determination by IP CTS providers, as well as other TRS providers, will be addressed in that docket,” which refers to the instant docket.

5. Mobile Text

217. In the NPRM, the Commission noted that our current Text-to-911 rules require mobile carriers and other covered text providers to obtain location information sufficient to route text messages to the appropriate PSAP, but text providers are not required to convey additional location information to the PSAP. The Commission stated that this approach has always been viewed as an interim solution, and noted the prior pending proposal in the Text-to-911 docket to require covered text providers to deliver enhanced location information (consisting of the best available location information that covered text providers can obtain from any available location technology or combination of technologies, including device-based location). In the NPRM, the Commission sought to refresh the record on text-to-911 location and asked whether to apply dispatchable location requirements to text-to-911, if it is technically feasible, consistent with requirements applied to other platforms.

218. The record indicates that the location technology options available to covered text providers have significantly expanded since the Commission adopted its text-to-911 rules five years ago. For example, commenters point to recent improvements in technology that have the potential to provide location information for an increasing percentage of 911 texts. First, wireless carriers note that they are starting to transition mobile wireless text services from SMS to more robust IP-enabled platforms, such as real-time text, which can support provision of location information with 911 texts using some of the same location methodologies that are used to support IP-based voice services. Second, Comtech and West Safety note the potential to use the device-based location capabilities of mobile handsets (e.g., Google's Emergency Location Service in Android devices) to generate location information, which can then be sent via text to the PSAP.

219. However, the transition away from SMS texting is far from complete, and the technologies being used to support text-to-911 location, while promising, have not yet been demonstrated to be capable of consistently supporting either dispatchable location or enhanced location accuracy comparable to the level of accuracy required for wireless voice services. In this respect, wireless carriers commenting on this issue caution against requiring them to implement dispatchable location capabilities in SMS-based text-to-911, which would require major retrofitting of legacy SMS networks that were not designed to support the provision of location information. Commenters express uncertainty about (1) when text-to-911 will fully migrate from SMS-based texting to newer technologies, and (2) how soon device-based location for 911 texts will be universally available. Comtech states that “some of the technological challenges that must be overcome to improve location information for text-to-911, when compared to wireless voice 911 location information, include: (1) The current configuration of mobile handsets, (2) the types of location technologies and protocols supported by mobile handsets, and (3) the availability of real-time location platforms across each individual carrier.” Consequently, while some commenters support establishing enhanced location requirements for text-to-911, others argue that such requirements are premature.

220. We therefore conclude that it would be premature to adopt dispatchable location requirements for text-to-911 comparable to the requirements applicable to other services covered by this order. Instead, we adopt a flexible approach to text-to-911 location requirements. We require covered text providers, within two years of the effective date of these rules, to provide (1) dispatchable location, if technically feasible, or, otherwise, either (2) end-user manual provision of dispatchable location, or (3) enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available existing technology or combination of technologies at reasonable cost. We clarify that the latter requirement does not require covered text providers to retrofit SMS-based text networks or to upgrade legacy mobile handsets that are only SMS-capable. We recognize that as a practical matter, covered text providers are unlikely to be capable of providing dispatchable location for most 911 texts, and that the quality of “best-available” location information provided with 911 texts may vary. Nevertheless, we believe that over time this requirement will encourage development of improved location capabilities for text-to-911, while accounting for technical feasibility issues raised in the current record.

6. Comparison of Benefits and Costs

221. In order to quantify the magnitude of the benefits to the public when dispatchable location is conveyed with a 911 call from MLTS and other communications services identified in the NPRM, the Commission anticipated that the increase in location accuracy that results from the use of dispatchable location will reduce the arrival time of ambulances for some 911 callers at least as much as was accomplished by the mobile location rules adopted in the Indoor Location Fourth Report and Order. In that Report and Order, the Commission found that the location accuracy improvements adopted for mobile 911 calls had the potential to save approximately 10,120 lives annually for an annual benefit of approximately $92 billion. Based on available 911 call volume data in the Commission's Ninth Annual Report and 911 Fees, the Commission estimated that approximately 75% of 911 calls come from mobile phones, which already are required to convey a dispatchable location. However, the Commission believed the remaining 25% of calls to which its proposed rules would apply will realize benefits. Because three times as many calls come from mobile phones as from non-mobile sources, the Commission estimated that the proposed rules have the potential to save a maximum of one third of the 10,120 lives that were projected to be saved annually by the mobile location rules adopted in the Indoor Location Fourth Report and Order, or 3,373 lives annually. However, because some providers already convey location information that is equivalent to dispatchable location, the Commission expected that the dispatchable location rules will save considerably fewer lives.

222. In the NPRM, the Commission assumed that the proposed rules would save 506 lives annually, or only one twentieth of the lives that it projected would be saved by the mobile location rules. The Commission relied on the U.S. Department of Transportation's estimate that the “Value of a Statistical Life” (VSL), defined as “the additional cost that individuals would be willing to bear for improvements in safety (that is, reductions in risks) that, in the aggregate, reduce the expected number of fatalities by one,” is $9.6 million. In doing so, the Commission estimated that the 506 lives saved by the proposed rules multiplied by the VSL establishes a benefit floor of $4.9 billion. The Commission sought comment on the reasonableness of its estimate, what other benefits can be expected to accrue, such as (but not limited to) reduced complications from medical issues, reduced damage to property, increased likelihood of forestalling crime and apprehending suspects, and increased confidence in the 911 system and emergency responders.

223. No commenter disagreed with the Commission's analysis of the benefits that the public should expect from the implementation of improved location accuracy requirements for MLTS and other services. Additionally, public safety commenters support improvements to location accuracy for calls to 911 from MLTS and other services, provided that dispatchable location information is validated. The Texas 9-1-1 Entities submit that “as legacy TDM landline continues to transition to IP as the dominant market solution, 9-1-1 calls are becoming increasingly less distinguishable based solely on technological platform.” “While consistency alone warrants that the definition of `dispatchable location' be the same across the Commission's 9-1-1 rules regardless of technological platform (e.g., CMRS, fixed telephone/legacy landline, MLTS),” the Texas 9-1-1 Entities argue, “this is particularly important as technological platforms morph and evolve (e.g., fixed wireless, mobile VoIP, Wi-Fi calling) and no longer fit neatly into traditionally defined and differentiated categories.” The Texas 9-1-1 Entities and MESB illustrate that validation is particularly necessary in an evolving IP environment, which appears vulnerable to 911 calls being misrouted across state lines and placing increased burdens on resource-limited PSAPs to re-route 911 calls to the appropriate jurisdiction.

224. Additionally, of the total reported calls to 911 in 2017, 155,231,318 calls came from wireless phones, representing approximately 70% of the total reported call volume. In addition, the ratio of wireless calls to total reported call volume remained steady even though there was a 135% increase in VoIP calls from 2016 and a 378% increase in the number of calls reported as “Other” from 2016 (VoIP calls reported in 2017 increased to 7,666,958 from 5,661,055 in 2016 and the number of calls reported as “Other” increased to 8,907,760 from 2,353,291 in 2016). While the Bureau believes that the 70% figure likely understated the percentage of wireless 911 calls because a number of states reported total 911 calls but did not break out all service categories separately, it is also likely that the Tenth Annual Fee Report underestimated the increase in VoIP and “Other” calls given that half of reporting jurisdictions did not report call volume for those categories. Thus, the record suggests that the problem of inaccurate location information or no location information being conveyed with a 911 call from MLTS and other 911 services is common and will continue to grow and potentially undermine public confidence in location accuracy of such calls absent a requirement for validated location information.

225. In the NPRM, the Commission proposed a dispatchable location implementation schedule across all technological platforms that tracked the February 16, 2020, compliance date for Kari's Law. The Commission sought comment on the costs of the proposed rules in the NPRM. The Commission observed that “911 location solutions that are capable of conveying dispatchable location to PSAPs are already offered by several MLTS market participants.” Further, the Commission noted that “several states already place requirements on MLTS providers to obtain and convey location information that is more detailed than street address alone, [footnote omitted] and we therefore conclude that MLTS manufacturers are producing and widely selling equipment that is capable of complying with our proposed rules.” The Commission asked commenters to address whether there are any cases “in which currently-available equipment will not be suitable.” In addition, the Commission observed that “to comply with current rules, interconnected VoIP service providers and internet-based TRS providers today obtain customers' Registered Location, which we believe would likely be sufficient to satisfy our proposed dispatchable location requirements in many circumstances.” Because these dispatchable location-capable solutions and equipment are already being widely offered by MLTS manufacturers, installers, and operators, the Commission stated its belief “that the implementation costs of our proposed dispatchable location rules to these entities would be negligible in most respects.” The Commission also expressed its belief “that our approach of granting flexibility in satisfying our proposed rules minimizes the potential cost of compliance.” Accordingly, the Commission sought comment on these observations and tentative conclusions.

226. As the Commission emphasized in the NPRM, we do not mandate any particular technology or model for implementing the 911 location rules we adopt today and apply these requirements on a technologically neutral basis. Moreover, service providers can leverage existing location technology solutions to mitigate costs. Further, we adopt a phased-in approach that allows service providers additional time beyond the February 16, 2020, proposal in the NPRM to come into compliance with our rules. Additionally, we have tailored the compliance deadlines to each particular service. Further, we apply our rules on a prospective basis, thus minimizing cost on legacy systems and small businesses. We find that applying our rules to these legacy systems would be too costly because there is such a great variety of systems that location technology solutions would have to be tailored for each enterprise. That said, the record demonstrates that delivering dispatchable location is technically feasible today for many services at a cost that is less than the $4.9 billion minimum benefit floor. Consistent with our approach in the Wireless Indoor Accuracy Fourth Report and Order, this means that MLTS and other service providers subject to our 911 location rules need only choose the methods necessary to close the gap between already-deployed capabilities and the Commission's requirements, “rather than starting from scratch.” So, although the cost of meeting our 911 location rules has not yet been determined to a dollar amount, the rules we adopt today provide MLTS and service providers a clear reference point from which to factor in compliance costs incrementally. We provide the following analysis of comments addressing compliance costs.

227. Compliance Costs. In the NPRM, the Commission estimated that the annual cost to MLTS operators to provide location information as proposed would be less than $49.6 million, and that such costs are likely to decline within a few years as databases and other sources of location information become increasingly centralized. The Commission also estimated a $460,000 per-provider cost for 18 providers of Interconnected VoIP, VRS, and IP Relay services to implement software upgrades that would detect when an end user's location has changed and to identify the new location. The Commission also sought comment on implementation costs for outbound-only VoIP providers. No commenter objected to the costs estimated in the NPRM. One commenter, however, suggested that the Commission over-estimated the costs associated with building a “white pages like directory” or database and software development costs.

228. Industry commenters recognize that accurate location information can be critical in ensuring a timely emergency response, including for vulnerable populations such as TRS users. Commenters suggest that providers of fixed MLTS, fixed telephony, and interconnected VoIP already provide dispatchable location, while some are concerned that applying dispatchable requirements to nomadic or remote, off-site MLTS could undermine incentives to use innovative solutions. The record reflects that industry has incentives to continue to improve 911 location capabilities and desires flexibility to adopt 911 solutions. However, industry commenters generally warn against applying rigid, overly-granular, “one-size fits all” dispatchable location mandates by February 16, 2020, that could be unduly burdensome on evolving technologies. For example, Sorenson and CaptionCall note that “the technology for automatically locating mobile users is advancing rapidly and the technology for locating nomadic VoIP subscribers is improving, though it is still not reliable in every instance.” Microsoft suggests that prematurely applying such requirements would be unachievable and “runs the risk of preventing the use of readily available location technologies that can vastly improve the current location capabilities of MLTS and iVoIP, particularly nomadic MLTS and iVoIP services.” Ad Hoc advises that “the Commission should not impose obligations on MLTS owners or operators to transmit any type of information that their MLTS equipment is not technically capable of transmitting or that would require assumption of any unreasonable costs to upgrade.” Cisco expresses concerned that “[a] dispatchable location requirement would also amount to a de facto mandate for enterprise customers to purchase third-party solutions that may be cost-prohibitive or ineffective.”

229. Cost Mitigation. Notwithstanding the lack of cost data, commenters suggest measures to mitigate potential costs and complexity of compliance, including enshrining the principles of technological neutrality, flexibility and maintaining service specific 911 rules. The requirements we adopt today are measured, technically feasible, and technologically neutral, so that service providers can choose the most effective solutions from a range of options. In addition, our requirements allow sufficient time for advance planning and deployment of new location technology, beyond the February 16, 2020 compliance date proposed in the NPRM.

230. The record demonstrates that the scale of the potential benefits will increase over time given the magnitude of the problem we are facing, industry's incentives to improve 911 location accuracy, and the fact that the requirements that we adopt today will render the conveyance of dispatchable location an even more effective emergency response tool as technology improves and becomes more widely available.

231. Outbound-only Interconnected VoIP. In the NPRM, the Commission acknowledged potential technical challenges for outbound-only interconnected VoIP services to automatically send a caller's dispatchable location to a local PSAP during a 911 emergency. Commenters submitted estimates for the costs of such a mechanism. Precision Broadband, for example, noted in its ex parte its service of mapping a consumer broadband IP address to a dispatchable location, and projected “an expenditure of between $200 million and $275 million per year for the Fixed Broadband 911 system at full nationwide deployment.” We obtained a similar estimate for full nationwide coverage through alternative means. We also note this is an upper bound but an extremely unlikely scenario as many outbound-only interconnected VoIP services already have provision for delivering their location. According to a 2016 study conducted by the Pew Research Center, 90% of smartphone users have location services enabled, meaning that these users can already be located automatically without the aid of a third-party technology like the one proposed by Precision Broadband. We also believe that this statistic would apply to other devices with location service capabilities not just the smartphone. Moreover, this Pew statistic suggests there would be a similar willingness of consumers to enter the dispatchable location into applications. Thus, the costs imposed by this rule are for those consumers who neither have location services available nor enter an address. Because the $275 million figure presumes there are no location services available today, we conclude that the total cost would be $27.5 million (10% of $275 million). We believe it is a reasonable expectation that of the 506 lives saved, at least 25 lives (i.e., only 5% because, as explained above and in the NPRM, about 95% of interconnected devices already have location ability) will be from this part of the rule. Indeed, just three lives saved per year would fully cover the expected cost. Furthermore, there are a variety of flexible options to provide 911 caller location information depending on the service, such as x-y-z coordinates or manually updated Registered Location, adding support for our finding that costs are likely to be on the lower end as we describe here. We therefore find the benefits exceed the estimated costs imposed.

232. We also require outbound-only interconnected VoIP service providers to comply with the customer notification requirements of our rules. We require outbound-only interconnected VoIP service providers to comply with the 911 requirements we adopt today two years after the effective date of the rules. Regarding general 911 requirements that we extend to outbound-only interconnected VoIP, we envision that the costs for consumer notification and record-keeping would also be comparable to the information collection costs applicable to other interconnected VoIP service providers under the Commission's rules. In sum, the record indicates that the costs for outbound-only interconnected service providers to comply with our 911 rules, including dispatchable location, will not differ from the costs to interconnected VoIP providers that our well-established rules already cover and for which we have previously found to have the benefits outweigh the costs.

C. Consolidating the Commission's 911 Rules

233. In the NPRM, the Commission proposed to consolidate all the existing 911 rules into a single rule part. The Commission also proposed to simplify and streamline the rules in some instances and to eliminate corresponding duplicative rules in other rule parts. The Commission explained that rule consolidation will help to minimize the burden on small entities subject to the Commission's 911 rules by making it easier to identify and comply with all 911 requirements.

234. The majority of commenters who addressed the issue support the proposed 911 rule consolidation. iCERT states that it does not object to a non-substantive rule reorganization, and TIA supports removal of rules that are obsolete. Hamilton provided the sole comment expressing opposition, arguing that relay service rules “are integrated with non-911 related rules in such a way that removing the 911-related rules and transferring them to part 9 would be cumbersome and counterproductive.

235. We consolidate the existing 911 rules as proposed. To address Hamilton's concerns, we find that we can transfer and amend the relay service emergency calling rules without adversely affecting the integrity of the remaining non-911 relay service rules. The revised part 9 differentiates between platforms and services where needed, but it also enables service providers, PSAPs, and other stakeholders to refer to a single part of the Commission's rules to ascertain all 911 requirements.

236. As noted in Appendix A and described for reference in conversion tables in Appendix B, we designate part 9, which currently contains our interconnected VoIP rules, as the rule part that contains the consolidated 911 rules, and we transfer and consolidate our existing 911 rules from parts 12, 20, 25, and 64 to part 9. The revised part 9 will continue to differentiate between platforms where needed, but it will also enable service providers, PSAPs, and other stakeholders to refer to a single part of the Commission's rules to ascertain all 911 requirements. Specifically, we consolidate our 911 rules as follows:

• Move relevant definitions for all services to subpart A of part 9;
• Move telecommunications carrier obligations (§ 64.3001 et seq.) to subpart B of part 9;
• Move CMRS obligations (§ 20.18) to subpart C of part 9;
• Move interconnected VoIP obligations (current part 9) to subpart D of part 9;
• Move emergency calling requirements for TRS providers (§§ 64.604(a)(4) and 64.605) to subpart E of part 9;
• Place proposed MLTS rules in subpart F of part 9;
• Move emergency call center requirements for MSS providers (§ 25.284) to subpart G of part 9; and
• Move 911 resiliency, redundancy, and reliability requirements (part 12) to subpart H of part 9.

In addition, as proposed in the NPRM, we remove § 12.3, an obsolete 911 rule that references a one-time information collection that has been completed, rather than recodify it in part 9. The Commission also sought comment on whether to move § 22.921 of the rules, which addresses 911 call processing procedures for analog telephones in the Cellular Radiotelephone Service, into part 9 or whether that rule has become obsolete and should be removed. As proposed in the NPRM, we remove § 22.921 as obsolete.

237. In proposing to consolidate the 911 rules, the Commission also invited commenters to identify any other rules that should be consolidated or updated. No commenters suggest additional rules for consolidation, but some commenters suggest substantive rule changes. Several of these suggestions concern 911 call routing issues. Specifically, BRETSA suggests that the Commission should require MLTS to be configured to route a 911 call to the PSAP serving the caller's location to cover cases where a different PSAP serves the enterprise's main office or location of the core MLTS equipment. MESB argues that federal intervention and enforcement mechanisms are needed to ensure accurate routing of 911 calls to the correct PSAP and accurate callback number delivery to the PSAP, noting that state MLTS statutes have not been successful in ensuring MLTS compliance with these requirements. BRETSA also suggests that the Commission propose a “forward-looking” location rule that would require all devices (e.g., all types of computers, tablets, and phones) used for voice, text, or video communications to incorporate GPS chipsets and other location technologies such as Wi-Fi, so that the devices are location-aware and are able to route 911 calls to the appropriate PSAP. RedSky suggests that the Commission should give telecommunications carriers the ability to transmit a 911 call through a third party such as an incumbent local exchange carrier, a VoIP Provisioning Center (VPC), its agent, or directly to an Emergency Services IP Network (ESINet) or its agent, rather than have to transmit a 911 call directly to a PSAP. In a similar vein, Texas 9-1-1 Entities request that the Commission allow 911 calls to be routed through third-party call centers when dispatchable location, geographic coordinates, or registered location are not available. But MESB states that MLTS and VoIP 911 calls should not be allowed to routinely route to national call centers rather than the local serving PSAPs. BRETSA similarly states that Regional or national call centers are not a permissible alternative to proper configuration of an MLTS.

238. Commenters suggest several other miscellaneous rule changes. Specifically, APCO suggests that the Commission should monitor consumers' use of new technological platforms for communications, and that the Commission consider further expanding the scope of the 911 rules to take into account such platforms and prevent subtle technology distinctions from impacting communications with 911. Ad Hoc states that the Commission should modify § 9.11(b)(5)(iii), which requires interconnected VoIP service providers to distribute stickers or other appropriate labels warning subscribers if E911 service may be limited or not available, to “permit carriers to discharge their `notification/warning label' obligations differently for enterprise customers.” BRETSA suggests an inquiry into 911 fees related to digital broadband facilities connected to an MLTS. RedSky suggests that the Commission should revisit consent decrees that an individual carrier or service provider may have entered into with the FCC or other body because such decrees “serve to un-level the playing field.” Next, RedSky, BRETSA, and APCO suggest modifying several terms in § 9.3 definitions. RedSky and BRETSA also suggest amendments to several definitions. Additionally, RedSky notes that several 911-related terms are missing from the part 9 terms and definitions, and Texas 9-1-1 Entities proposes adding a term and definition. Finally, RedSky suggests retitling some rule section headings.

239. While many of the suggestions described above may be worth pursuing separately, we decline to address them in this proceeding. The Commission stated that aside from the new MLTS and dispatchable location rules and deleting obsolete rules, the rule revisions in this proceeding would simply entail consolidating our existing 911 rules without making substantive changes. Limited exceptions would include certain conforming and technical changes, such as harmonizing definitions of 911-related terms. We find that the commenters' suggestions go well beyond the scope of issues the Commission intended to address in this proceeding. We retain the discretion to address elsewhere, and parties have the option to file petitions for rulemaking or raise such issues in other appropriate proceedings.

240. We do make ministerial conforming changes to certain other rules in light of our decision to consolidate the existing 911 rules into part 9. First, we found that part 1 contains several references to § 20.18, which is being moved to part 9 as the new § 9.10. Accordingly, we update those references to § 9.10. Next, we found that four rules have references to part 20 governing CMRS. Since part 20 will no longer cover CMRS 911 obligations after the relocation of § 20.18 to § 9.10, we are adding a reference to part 9 to each of the four rules to clarify the location of CMRS 911 rules. Since these changes are ministerial in nature and facilitate the part 9 rule consolidation, for which the Commission has already provided notice and allowed for comment, we find for good cause that notice and comment are unnecessary. Finally, we harmonize the § 9.3 definition of “Registered internet-based TRS user” to conform with the recently updated definition in part 64 of the Commission's rules. Because the Commission's proposed § 9.3 definition of “Registered internet-based TRS user” is sourced from § 64.601(a), and because the Commission changed the definition in § 64.601(a) in a proper rulemaking proceeding, we find for good cause that notice and comment to adopt the same definition change for part 9 are unnecessary.

IV. Procedural Matters

241. Final Regulatory Flexibility Analysis. As required by the Regulatory Flexibility Act of 1980, as amended (RFA), the Commission has prepared a Final Regulatory Flexibility Analysis (FRFA) relating to this Report and Order. The FRFA is set forth in Appendix C.

242. Paperwork Reduction Act Analysis. The requirements in §§ 9.8(a) and 9.16(b)(3)(i), (ii) and (iii) constitute new information collections subject to the Paperwork Reduction Act of 1995 (PRA), and the requirements in §§ 9.8(a); 9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4); 9.11(b)(5)(ii); (iii); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v); 9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); 9.16(b)(3)(i); (ii); and (iii) constitute modified information collections. They will be submitted to the Office of Management and Budget (OMB) for review under section 3507(d) of the PRA. OMB, the general public, and other Federal agencies will be invited to comment on the new information collection requirements contained in this proceeding. This document will be submitted to OMB for review under section 3507(d) of the PRA. In addition, we note that, pursuant to the Small Business Paperwork Relief Act of 2002, we previously sought, but did not receive, specific comment on how the Commission might further reduce the information collection burden for small business concerns with fewer than 25 employees. We describe impacts that might affect small businesses, which includes more businesses with fewer than 25 employees, in the Final Regulatory Flexibility Analysis in Appendix C.

243. Congressional Review Act. The Commission has determined that these rules are non-major under the Congressional Review Act, 5 U.S.C. 804(2). The Commission will send a copy of this Report and Order to Congress and the Government Accountability Office pursuant to 5 U.S.C. 801(a)(1)(A).

244. Further Information. For further information, contact Brenda Boykin, Attorney-Advisor, Policy and Licensing Division, Public Safety and Homeland Security Bureau, [phone] or via email at [e-mail]; William Beckwith, Attorney-Advisor, Policy and Licensing Division, Public Safety and Homeland Security Bureau, [phone] or via email at [e-mail]; Thomas Eng, Engineer, Policy and Licensing Division, Public Safety and Homeland Security Bureau, [phone] or via email at [e-mail]; Dr. Rasoul Safavian, Technologist, Policy and Licensing Division, Public Safety and Homeland Security Bureau, [phone] or via email at [e-mail].

V. Final Regulatory Flexibility Analysis

245. As required by the Regulatory Flexibility Act of 1980, as amended (RFA), an Initial Regulatory Flexibility Analysis (IRFAs) was incorporated in the Notice of Proposed Rulemaking adopted in September 2018 (NPRM). The Commission sought written public comment on the proposals in the NPRM including comment on the IRFA. The Comments received are discussed below. This Final Regulatory Flexibility Analysis (FRFA) conforms to the RFA.

A. Need for, and Objectives of, the Report and Order

246. In the Report and Order, the Commission advances Congressional and Commission objectives to ensure that members of the public can successfully dial 911 to request emergency services and that Public Safety Answering Points (PSAPs) can quickly and accurately locate every 911 caller, regardless of the type of service that is used to make the call. In 2018, the President signed into law Kari's Law Act of 2017 (Kari's Law), which requires implementation of direct 911 dialing and on-site notification capabilities in a multi-line telephone system (MLTS), and Section 506 of RAY BAUM'S Act (RAY BAUM'S Act), which requires the Commission, within 18 months after the date of the legislation's enactment (March 23, 2018), to “conclude a proceeding to consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call, regardless of the technological platform used and including with calls from [MLTS].”

247. The Report and Order implements Kari's Law by adopting direct dial and on-site notification rules governing calls to 911 made from a MLTS. The Commission takes the following actions:

• Adopts 911 direct dialing requirements as proposed in the NPRM, subject to clarification of some definitions and terms, including the term pre-configured.
• adopts a requirement that notification be sent to a location where someone is likely to hear or see it, but we do not require the location to be continuously staffed or monitored.
• requires the notification to include the fact that a 911 call has been made, a valid callback number, and the same location information that is conveyed with the call to 911. However, we provide an exception for callback number and location information in circumstances where including this information in the notification would be technologically infeasible. We also require that initiation of the notification be contemporaneous with the call to 911, provided that it is technologically feasible to do so.
• requires an MLTS to be configured to provide notification for any caller on the system, including callers at satellite or branch locations.
• adopts the statutory definition of MLTS cited in Kari's Law and RAY BAUM'S Act. In addition, we interpret this definition to cover the full range of networked communications systems that serve enterprises, including IP-based and cloud-based systems. We also interpret the definition to include outbound-only MLTS systems that allow users to make 911 calls but do not enable PSAPs to place a return call directly to the 911 caller.
• establishes February 16, 2020 as the compliance date for regulations implementing Kari's Law.
• adopts a presumption that if an MLTS fails to comply with the rules, the MLTS manager is responsible unless the manager can rebut the presumption by demonstrating compliance with its obligations under the statute and rules.
• declines to adopt disclosure requirements for legacy MLTS that are not subject to the requirements of Kari's Law and instead encourage enterprises to disclose the limitations on dialing 911 from legacy MLTS as part of voluntary best practices.

248. As required by RAY BAUM'S Act, the Commission considered the feasibility of requiring dispatchable location for 911 calls from MLTS and other technological platforms that currently complete calls to 911, and established a dispatchable location requirement for MLTS 911 calls. In keeping with the directive in RAY BAUM'S Act to address dispatchable location for 911 calls “regardless of the technological platform used,” the Report and Order adds dispatchable location requirements to the Commission's existing 911 rules for fixed telephony providers, interconnected Voice over Internet Protocol (VoIP), Telecommunications Relay Services (TRS), Video Relay Services (VRS), and mobile text. Finally, consistent with RAY BAUM'S Act, we do not make any changes to the Commission's existing rules for CMRS providers to provide dispatchable location.

249. More specifically, consistent with RAY BAUM'S Act the Commission adopts the following definition of dispatchable location and alternative location information:

• Dispatchable Location. A location delivered to the PSAP with a 911 call that consists of the validated street address of the calling party, plus additional information such as suite, apartment or similar information necessary to adequately identify the location of the calling party, except for Commercial Mobile Radio Service providers, which shall convey the location information required by our existing rules.

250. For MLTS systems subject to Kari's Law, we separately address dispatchable location requirements for MLTS 911 calls from (1) fixed devices and non-fixed devices being used on-premises, and (2) non-fixed devices being used off-premises. Accordingly, the Commission adopts the following dispatchable location rules:

○ MLTS 911 calls from fixed devices: One year after the effective date of the rules, MLTS must provide automated dispatchable location with each 911 call.

○ MLTS 911 calls from non-fixed devices:

○ On-premises MLTS 911 calls from non-fixed devices: Two years after the effective date of the rules, MLTS must provide (1) automated dispatchable location, if technically feasible, or, otherwise, either (2) end-user manually-updated dispatchable location, or (3) alternative location information, which may be coordinate-based, sufficient to identify the caller's civic address and approximate in-building location, including floor level, in large buildings.

○ Off-premises MLTS 911 calls from off-premises devices: Two years after the effective date of the rules, MLTS must provide (1) automated dispatchable location, if technically feasible, or, if otherwise, either (2) end-user manually-updated dispatchable location, or (3) enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost.

251. For other services currently subject to 911 requirements (Fixed Telephony, Interconnected Voice over Internet Protocol (VoIP), Telecommunications Relay Service (TRS) and mobile text, the Commission adopts the following requirements:

○ Fixed Telephony: One year after the effective date of the rules, service providers must deliver automated dispatchable location with each 911 call.

○ Interconnected VoIP:

○ Fixed interconnected VoIP: One year after the effective date of the rules, service providers must deliver automated dispatchable location with each 911 call or Registered Location. Dispatchable location may be provided by means of a customer-generated Registered Location, under the same terms and conditions specified in our current VoIP 911 rules, or by automatic provision of dispatchable location by the VoIP service provider, without additional action by the caller, at the time the 911 call is made.

○ Non-fixed interconnected VoIP: Two years after the effective date of the rules, service providers must provide (1) automated dispatchable location, if technically feasible, or, otherwise, either (2) manual updating of Registered Location information, or (3) alternative location information, which may be coordinate-based, sufficient to identify the caller's civic address and approximate in-building location, including floor level, in large buildings. If the provider is unable to obtain or confirm the caller's location, the provider may route the call to a national emergency call center.

○ Outbound-only interconnected VoIP: For purposes of compliance with our 911 rules, we amend the definition of “Interconnected VoIP Service” in § 9.3 of the Commission's rules to include “outbound-only” interconnected VoIP services that permit users generally to terminate calls to the public switched telephone network and extend the Interconnected VoIP location requirements described above to such providers.

• Telecommunications Relay Services

○ Fixed TRS: One year after the effective date of the rules, service providers must deliver automated dispatchable location with each 911 call.

○ Non-fixed TRS: Two years after the effective date of the rules, service providers must provide (1) automated dispatchable location, if technically feasible, or, otherwise, either (2) manual updating of Registered Location information, or (3) alternative location information sufficient to identify the caller's civic address and approximate in-building location, including floor level, in large buildings. If the provider is unable to obtain or confirm the caller's location, the provider may route the call to a national emergency call center.

• Mobile Text: Two years after the effective date of the rules, covered text providers must provide (1) automated dispatchable location, if technically feasible, or, otherwise, either (2) end-user manually provisioned location information, or (3) enhanced location information consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost.

252. Lastly, as the Commission proposed in the NPRM, the Report and Order consolidates the Commission's existing 911 rules, and the direct dialing and dispatchable location rules proposed in the NPRM, into a single rule part. The Commission historically has taken a service-specific approach to 911, with the result that 911 requirements for different services are scattered across different sections of the agency's rules. Consolidating our 911 rules from these various rule sections into a single rule part furthers the goal of recognizing that all the components of 911 function as part of a single system and enables service providers, emergency management officials, and other stakeholders to refer to a single part of the Commission's rules to more easily ascertain all 911 requirements.

B. Summary of Significant Issues Raised by Public Comments in Response to the IRFA

253. There were no comments that specifically addressed the proposed rules and policies presented in the IRFA.

C. Response to Comments by the Chief Counsel for Advocacy of the Small Business Administration

254. Pursuant to the Small Business Jobs Act of 2010, which amended the RFA, the Commission is required to respond to any comments filed by the Chief Counsel for Advocacy of the Small Business Administration (SBA), and to provide a detailed statement of any change made to the proposed rules as a result of those comments.

255. The Chief Counsel did not file any comments in response to the proposed rules in this proceeding.

D. Description and Estimate of the Number of Small Entities to Which the Rules Will Apply

256. The RFA directs agencies to provide a description of, and where feasible, an estimate of the number of small entities that may be affected by the rule changes. The RFA generally defines the term “small entity” as having the same meaning as the terms “small business,” “small organization,” and “small governmental jurisdiction.” In addition, the term “small business” has the same meaning as the term “small business concern” under the Small Business Act. A “small business concern” is one that: (1) Is independently owned and operated; (2) is not dominant in its field of operation; and (3) satisfies any additional criteria established by the SBA.

257. Multi-Line Telephone System Manufacturers, Importers, Sellers or Lessors. Neither the Commission nor the SBA has developed a specific small business size standard for MLTS manufacturers, importers, sellers or lessors. The closest applicable SBA category for entities manufacturing MLTS equipment used to provide wire telephone and data communications equipment, interconnected VoIP, non-interconnected VoIP, is Telephone Apparatus Manufacturing. The SBA size standard for Telephone Apparatus Manufacturing consists of all such companies having 1,250 or fewer employees. U.S. Census Bureau data for 2012 show that there were 266 establishments that operated that year. Of this total, 262 operated with fewer than 1,000 employees. Thus, under this size standard, the majority of firms in this industry can be considered small.

258. Telephone Apparatus Manufacturing. This industry comprises establishments primarily engaged in manufacturing wire telephone and data communications equipment. These products may be stand-alone or board-level components of a larger system. Examples of products made by these establishments are central office switching equipment, cordless and wire telephones (except cellular), PBX equipment, telephone answering machines, LAN modems, multi-user modems, and other data communications equipment, such as bridges, routers, and gateways. The SBA has developed a small business size standard for Telephone Apparatus Manufacturing, which consists of all such companies having 1,250 or fewer employees. U.S. Census Bureau data for 2012 show that there were 266 establishments that operated that year. Of this total, 262 operated with fewer than 1,000 employees. Thus, under this size standard, the majority of firms in this industry can be considered small.

259. Multi-Line Telephone System Operators, Installers and Managers. Neither the Commission nor the SBA has developed a specific small business size standard for MLTS operators, installers and managers. MLTS Operators, Installers and Managers cut across numerous industry segments and encompass all types of businesses and organization including for-profit, not-for-profit and government agencies. Thus, for purposes of this FRFA, we group entities operating, installing, and managing MLTS in the Small Businesses, Small Organizations and Small Government Jurisdictions description contained in paragraph 21 infra.

260. All Other Telecommunications. The “All Other Telecommunications” category is comprised of establishments primarily engaged in providing specialized telecommunications services, such as satellite tracking, communications telemetry, and radar station operation. This industry also includes establishments primarily engaged in providing satellite terminal stations and associated facilities connected with one or more terrestrial systems and capable of transmitting telecommunications to, and receiving telecommunications from, satellite systems. Establishments providing internet services or voice over internet protocol (VoIP) services via client-supplied telecommunications connections are also included in this industry. The SBA has developed a small business size standard for All Other Telecommunications, which consists of all such firms with annual receipts of $32.5 million or less. For this category, U.S. Census Bureau data for 2012 show that there were 1,442 firms that operated for the entire year. Of those firms, a total of 1,400 had annual receipts less than $25 million and 15 firms had annual receipts of $25 million to $49,999,999. Thus, the Commission estimates that the majority of “All Other Telecommunications” firms potentially affected by our action can be considered small.

261. Computer Facilities Management Services. This industry comprises establishments primarily engaged in providing on-site management and operation of clients' computer systems and/or data processing facilities. Establishments providing computer systems or data processing facilities support services are included in this industry. The SBA has developed a small business size standard for Computer Facilities Management Services which consists of all such firms with annual receipts of $27.5 million or less. U.S. Census Bureau data for 2012 indicate that 4,828 firms operated the entire year. Of this total, 4,743 had annual receipts less than $25 million and 38 firms had annual receipts of $25 million to $49,999,999. Thus, under the SBA size standard the majority of firms in this industry can be considered small.

262. Other Computer Related Services (Except Information Technology Value Added Resellers). This industry comprises establishments primarily engaged in providing computer related services (except custom programming, systems integration design, and facilities management services). Establishments providing computer disaster recovery services or software installation services are included in this industry. The SBA has developed a small business size standard for Other Computer Related Services, which consists of all such firms with annual receipts of $27.5 million or less. For this category, U.S. Census Bureau data for 2012 indicate that 6,354 firms operated the entire year. Of this total, 6,266 had annual receipts less than $25 million and 42 firms had annual receipts of $25 million to $49,999,999. Thus, the Commission estimates that the majority of Other Computer Related Services firms in this industry can be considered small.

263. Information Technology Value Added Resellers. Information Technology Value Added Resellers provide a total solution to information technology acquisitions by providing multi-vendor hardware and software along with significant value added services. Significant value added services consist of, but are not limited to, configuration consulting and design, systems integration, installation of multi-vendor computer equipment, customization of hardware or software, training, product technical support, maintenance, and end user support. The SBA has developed a small business size standard for Information Technology Value Added Resellers which consists of all such companies having 150 or fewer employees. For this category, U.S. Census Bureau data for 2012 indicate that 6,354 firms operated the entire year. Of this total, 6,241 had less than 100 employees and 113 had 100-1,000 or more employees. Thus, the Commission estimates that the majority of Information Technology Value Added Resellers in this industry can be considered small.

264. Data Processing, Hosting, and Related Services. This industry comprises establishments primarily engaged in providing infrastructure for hosting or data processing services. These establishments may provide specialized hosting activities, such as Web hosting, streaming services, or application hosting (except software publishing), or they may provide general time-share mainframe facilities to clients. Data processing establishments provide complete processing and specialized reports from data supplied by clients or provide automated data processing and data entry services. The SBA has developed a small business size standard for Data Processing, Hosting, and Related Services which consists of all such firms with annual receipts of $32.5 million or less. U.S. Census Bureau data for 2012 indicate that 8,252 firms operated the entire year. Of this total, 7,730 had annual receipts less than $25 million and 228 firms had annual receipts of $25 million to $49,999,999. Thus, under this size standard the majority of firms in this industry are small businesses.

265. Small Businesses, Small Organizations, Small Governmental Jurisdictions. Our actions, over time, may affect small entities that are not easily categorized at present. We therefore describe here, at the outset, three comprehensive small entity size standards that could be directly affected herein. First, while there are industry specific size standards for small businesses that are used in the regulatory flexibility analysis, according to data from the SBA's Office of Advocacy, in general a small business is an independent business having fewer than 500 employees. These types of small businesses represent 99.9% of all businesses in the United States which translates to 28.8 million businesses.

266. Next, the type of small entity described as a “small organization” is generally “any not-for-profit enterprise which is independently owned and operated and is not dominant in its field.” Nationwide, as of August 2016, there were approximately 356,494 small organizations based on registration and tax data filed by nonprofits with the Internal Revenue Service (IRS).

267. Finally, the small entity described as a “small governmental jurisdiction” is defined generally as “governments of cities, counties, towns, townships, villages, school districts, or special districts, with a population of less than fifty thousand.” U.S. Census Bureau data from the 2012 Census of Governments indicate that there were 90,056 local governmental jurisdictions consisting of general purpose governments and special purpose governments in the United States. Of this number there were 37, 132 General purpose governments (county, municipal and town or township) with populations of less than 50,000 and 12,184 Special purpose governments (independent school districts and special districts) with populations of less than 50,000. The 2012 U.S. Census Bureau data for most types of governments in the local government category show that the majority of these governments have populations of less than 50,000. Based on these data we estimate that at least 49,316 local government jurisdictions fall in the category of “small governmental jurisdictions.”

268. Wired Telecommunications Carriers. The U.S. Census Bureau defines this industry as “establishments primarily engaged in operating and/or providing access to transmission facilities and infrastructure that they own and/or lease for the transmission of voice, data, text, sound, and video using wired communications networks. Transmission facilities may be based on a single technology or a combination of technologies. Establishments in this industry use the wired telecommunications network facilities that they operate to provide a variety of services, such as wired telephony services, including VoIP services, wired (cable) audio and video programming distribution, and wired broadband internet services. By exception, establishments providing satellite television distribution services using facilities and infrastructure that they operate are included in this industry.” The SBA has developed a small business size standard for Wired Telecommunications Carriers, which consists of all such companies having 1,500 or fewer employees. U.S. Census Bureau data for 2012 show that there were 3,117 firms that operated that year. Of this total, 3,083 operated with fewer than 1,000 employees. Thus, under this size standard, the majority of firms in this industry can be considered small.

269. Local Exchange Carriers (LECs). Neither the Commission nor the SBA has developed a size standard for small businesses specifically applicable to local exchange services. The closest applicable NAICS Code category is for Wired Telecommunications Carriers. Under the applicable SBA size standard size standard, such a business is small if it has 1,500 or fewer employees. U.S. Census Bureau data for 2012 show that there were 3,117 firms that operated for the entire year. Of this total, 3,083 operated with fewer than 1,000 employees. Thus, under this category and the associated size standard, the Commission estimates that the majority of local exchange carriers are small entities.

270. Incumbent Local Exchange Carriers (Incumbent LECs). Neither the Commission nor the SBA has developed a small business size standard specifically for incumbent local exchange services. The closest applicable NAICS Code category is Wired Telecommunications Carriers. Under the applicable SBA size standard, such a business is small if it has 1,500 or fewer employees. According to U.S. Census Bureau data, 3,117 firms operated the entire year. Of this total, 3,083 operated with fewer than 1,000 employees. Consequently, the Commission estimates that most providers of incumbent local exchange service are small businesses that may be affected by the rules and policies adopted. According to Commission data, one thousand three hundred and seven (1,307) Incumbent Local Exchange Carriers reported that they were incumbent local exchange service providers. Of this total, an estimated 1,006 have 1,500 or fewer employees. Thus, using the SBA's size standard the majority of incumbent LECs can be considered small entities.

271. Competitive Local Exchange Carriers (Competitive LECs), Competitive Access Providers (CAPs), Shared-Tenant Service Providers, and Other Local Service Providers. Neither the Commission nor the SBA has developed a small business size standard specifically for these service providers. The appropriate NAICS Code category is Wired Telecommunications Carriers. Under that size standard, such a business is small if it has 1,500 or fewer employees. U.S. Census Bureau data for 2012 indicate that 3,117 firms operated during that year. Of that number, 3,083 operated with fewer than 1,000 employees. Based on these data, the Commission concludes that the majority of Competitive LECs, CAPs, Shared-Tenant Service Providers, and Other Local Service Providers are small entities. According to Commission data, 1,442 carriers reported that they were engaged in the provision of either competitive local exchange services or competitive access provider services. Of these 1,442 carriers, an estimated 1,256 have 1,500 or fewer employees. In addition, 17 carriers have reported that they are Shared-Tenant Service Providers, and all 17 are estimated to have 1,500 or fewer employees. In addition, 72 carriers have reported that they are Other Local Service Providers. Of this total, 70 have 1,500 or fewer employees. Consequently, the Commission estimates that most providers of competitive local exchange service, competitive access providers, Shared-Tenant Service Providers, and Other Local Service Providers are small entities.

272. Interexchange Carriers (IXCs). Neither the Commission nor the SBA has developed a definition for Interexchange Carriers. The closest NAICS Code category is Wired Telecommunications Carriers. The applicable size standard under SBA rules is that such a business is small if it has 1,500 or fewer employees. U.S. Census Bureau data for 2012 indicate that 3,117 firms operated for the entire year. Of that number, 3,083 operated with fewer than 1,000 employees. According to internally developed Commission data, 359 companies reported that their primary telecommunications service activity was the provision of interexchange services. Of this total, an estimated 317 have 1,500 or fewer employees. Consequently, the Commission estimates that the majority of interexchange service providers are small entities.

273. Local Resellers. The SBA has developed a small business size standard for Telecommunications Resellers which includes Local Resellers. The Telecommunications Resellers industry comprises establishments engaged in purchasing access and network capacity from owners and operators of telecommunications networks and reselling wired and wireless telecommunications services (except satellite) to businesses and households. Establishments in this industry resell telecommunications; they do not operate transmission facilities and infrastructure. Mobile virtual network operators (MVNOs) are included in this industry. Under the SBA's size standard, such a business is small if it has 1,500 or fewer employees. U.S. Census Bureau data for 2012 show that 1,341 firms provided resale services for the entire year. Of that number, all operated with fewer than 1,000 employees. Thus, under this category and the associated small business size standard, the majority of these resellers can be considered small entities. According to Commission data, 213 carriers have reported that they are engaged in the provision of local resale services. Of these, an estimated 211 have 1,500 or fewer employees. Consequently, the Commission estimates that the majority of Local Resellers are small entities.

274. Wireless Telecommunications Carriers (except Satellite). This industry comprises establishments engaged in operating and maintaining switching and transmission facilities to provide communications via the airwaves. Establishments in this industry have spectrum licenses and provide services using that spectrum, such as cellular services, paging services, wireless internet access, and wireless video services. The appropriate size standard under SBA rules is that such a business is small if it has 1,500 or fewer employees. For this industry, U.S. Census Bureau data for 2012 show that there were 967 firms that operated for the entire year. Of this total, 955 firms had had employment of 999 or fewer employees and 12 had employment of 1000 employees or more. Thus, under this category and the associated size standard, the Commission estimates that the majority of wireless telecommunications carriers (except satellite) are small entities.

275. The Commission's own data—available in its Universal Licensing System—indicate that, as of August 31, 2018 there are 265 Cellular licensees that will be affected by our proposed actions. The Commission does not know how many of these licensees are small, as the Commission does not collect that information for these types of entities. Similarly, according to internally developed Commission data, 413 carriers reported that they were engaged in the provision of wireless telephony, including cellular service, Personal Communications Service (PCS), and Specialized Mobile Radio (SMR) Telephony services. Of this total, an estimated 261 have 1,500 or fewer employees, and 152 have more than 1,500 employees. Thus, using available data, we estimate that the majority of wireless firms can be considered small.

276. Wireless Communications Services. This service can be used for fixed, mobile, radiolocation, and digital audio broadcasting satellite uses. The Commission defined “small business” for the wireless communications services (WCS) auction as an entity with average gross revenues of $40 million for each of the three preceding years, and a “very small business” as an entity with average gross revenues of $15 million for each of the three preceding years. The SBA has approved these small business size standards. In the Commission's auction for geographic area licenses in the WCS there were seven winning bidders that qualified as “very small business” entities, and one that qualified as a “small business” entity.

277. Wireless Telephony. Wireless telephony includes cellular, personal communications services, and specialized mobile radio telephony carriers. The closest applicable SBA category is Wireless Telecommunications Carriers (except Satellite). Under the SBA small business size standard a business is small if it has 1,500 or fewer employees. For this industry, U.S. Census Bureau data for 2012 show that there were 967 firms that operated for the entire year. Of this total, 955 firms had fewer than 1,000 employees and 12 firms has 1000 employees or more. Thus under this category and the associated size standard, the Commission estimates that a majority of these entities can be considered small. According to Commission data, 413 carriers reported that they were engaged in wireless telephony. Of these, an estimated 261 have 1,500 or fewer employees and 152 have more than 1,500 employees. Therefore, more than half of these entities can be considered small.

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

278. The Report and Order enacts rules that will affect the reporting, recordkeeping, and/or other compliance requirements of small businesses and enterprises of all sizes that are engaged in the business of manufacturing, importing, selling, leasing, installing, managing, or operating MLTS, provided that the MLTS is manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020. The Report and Order will also affect small businesses and enterprises that are engaged in the business of offering fixed telephony service, wireless telecommunications, interconnected VoIP service, and TRS. The Commission adopted these changes to implement Kari's Law and RAY BAUM'S Act, which collectively address the inability of callers to directly dial 911 from MLTS and a lack of accurate and critical location information necessary for a PSAP to dispatch emergency services to those in need because of the communications system used in making a 911 call.

279. The rules and compliance requirements the Commission adopted to implement the direct dialing and notification requirements of Kari's Law sought to balance the needs of stakeholders and maximize the public safety benefits. These benefits include potentially preventing fatalities, injuries, or property damage, improving emergency response time and access to emergency services, reducing delays in locating 911 callers, narrowing the gap between MLTS 911 service capabilities relative to other communications services subject to 911 requirements, and driving further technology development. The Commission also sought to achieve the benefits of Kari's Law in a cost-effective manner. As a result, the rules adopted generally track the statutory requirements of Kari's Law, are technologically neutral, and leverage advances in technology to improve access to emergency services as envisioned by Congress.

280. The adopted rules provide small businesses and other enterprises impacted by these requirements wide flexibility and adopt minimum criteria in direct dialing and notification requirements which should offset any potential burdens associated with compliance with our rules.

281. Consistent with Kari's Law, the Commission establishes February 16, 2020, as the compliance date for regulations implementing Kari's Law. It declines to adopt disclosure requirements for legacy MLTS but, instead, encourages industry to consider disclosure and education as part of voluntary best practices. The Commission also adopts a presumption that if an MLTS fails to comply with the rules, the MLTS manager is responsible unless the manager can rebut the presumption by demonstrating compliance with its obligations under the statute and rules.

282. Similar to its approach to implement the requirements of Kari's Law, the Commission sought to craft dispatchable location rules that leverage existing market-driven advances in technology to improve location accuracy, and that provide small businesses and others significant flexibility, are technology neutral, encourage innovation and allow a wide array of options to for compliance while minimizing the compliance burden and cost. Given the lack of cost data submitted in the record for meeting our 911 location rules or MLTS direct dialing and notification requirements, and in light of our flexible and technologically neutral approach to compliance, we do not believe compliance with these requirements will impose a significant economic burden for small businesses.

283. Similarly, we do not believe that the new or modified information collection requirements in §§ 9.8(a); 9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4); 9.11(b)(5)(ii); (iii); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v); 9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); 9.16(b)(3)(i); (ii); and (iii), will be unduly burdensome on small businesses. Rather than unduly burden small entities, applying the new and modified information collections will promote 911 service and emergency response, which should benefit small governmental jurisdictions, small businesses, small equipment manufacturers, and small business associations by giving them greater confidence in 911 location accuracy. Moreover, the rules we adopt in the Report and Order provide regulatory flexibility to all entities, including small businesses, and encourage service providers to leverage technology to the extent possible to reduce the burden of the information collections adopted in the Report and Order. Additionally, the Report and Order establishes a one- to two-year period from the effective date of the rules before requiring compliance with the revised rules. We provide the following analysis:

284. For compliance with the Commission's 911 requirements, interconnected VoIP service providers must collect and disclose certain information to third parties. OMB approved the information collection for § 9.5 (redesignated § 9.11) under OMB Control No. 3060-1085. This collection applies to interconnected VoIP providers obtaining and updating registered location from their customers and placing that information into ALI databases. This collection also applies to interconnected VoIP providers' customer notification obligations. The Commission modifies the definition of interconnected VoIP, thus potentially increasing the number of respondents subject to these existing information collections. The Commission also changes the wording of § 9.11's registered location requirements to facilitate the provision of automated dispatchable location, registered location, or alternative location information for 911 calls. Thus, we anticipate the burden and cost levels of these requirements would be comparable to the existing Registered Location and customer notification requirements, which OMB approved.

285. TRS service providers must collect and disclose certain information to third parties for compliance with the Commission's 911 rules. OMB approved the information collection for § 64.604 (redesignated as § 9.14) under OMB Control No. 3060-1089. This collection applies to TRS service providers transmitting location information to the PSAP, making location information available to the appropriate PSAP through the ALI database, and obtaining location information from the user. The Commission makes changes to the wording of § 9.14's registered location requirements to facilitate the provision of automated dispatchable location, registered location, or alternative location information for 911 calls. Thus, we anticipate the burden and cost levels of these requirements would be comparable to the existing location requirements, which OMB approved.

286. Covered text providers must notify consumers that they must grant permission to covered text providers to access the device's location information to enable the delivery and routing of text messages to PSAPs (i.e. Text-to-911) under § 20.18 (redesignated as 9.10). OMB renewed the information collection under OMB Control No. 3060-1204, ICR Reference No: 201802-3060-012. In this Report and Order, the Commission makes changes to the wording of § 9.10's text-to-911 requirements to facilitate the provision of dispatchable location or best available location information along with 911 text messages. Thus, we anticipate the burden and cost levels of these requirements will require covered text providers to update customer notification at a cost that would be comparable to the existing text-to-911 requirements, which OMB approved.

287. Finally, new § 9.8 requires providers of fixed telephony services to provide automated dispatchable location with 911 calls beginning one year after the effective date of this rule. Additionally, new § 9.16(b)(3)(i), (iii) and (iii) specifies dispatchable location requirements for on-premises fixed telephones; on premises non-fixed devices; and off-premises devices associated with a multi-line telephone system. The Report and Order reflects that the costs to implement these requirements would be minimal. For purposes of estimating projected costs to small businesses, we find that the costs would be comparable to the costs CMRS service providers incur in delivering uncompensated barometric pressure data, which OMB approved under OMB Control No. 3060-1210, ICR Reference No: 201801-3060-010. Current rule § 20.18 (redesignated as § 9.10) requires that CMRS providers shall deliver uncompensated barometric pressure data from any device capable of delivering such data to PSAPs. The Commission stated that the furnishing of this information to PSAPs is necessary to ensure that PSAPs are receiving all location information possible to be used for dispatch.

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

288. The RFA requires an agency to describe any significant, specifically small business alternatives, that it has considered in reaching its approach, which may include the following four alternatives (among others): (1) The establishment of differing compliance or reporting requirements or timetables that take into account the resources available to small entities; (2) the clarification, consolidation, or simplification of compliance or reporting requirements under the rule for small entities; (3) the use of performance, rather than design, standards; and (4) an exemption from coverage of the rule, or any part thereof, for small entities. To minimize any significant impact on small businesses, the Commission establishes a longer timetable for compliance timetable than that proposed in the NPRM relative to dispatchable location requirements. The Report and Order clarifies that the rules are flexible and technologically neutral so that small businesses may choose from a broad array of options to comply with the Commission's rules. We provide the following analysis of our rules.

289. Direct Dialing and Notification Requirements for a Multi-Line Telephone System. The Commission takes a number of steps in the Report and Order to provide flexibility and reduce costs for small businesses and other enterprises. As a preliminary matter, Kari's Law provides that the central notification requirements of the statute apply only if the MLTS can be configured to provide notification “without an improvement to the hardware or software of the system.” The legislative history of Kari's Law notes that this provision is intended to “balance the need for an onsite notification with the goal of not placing an undue burden on MLTS owners or operators.” The Commission adopts rules to implement and clarify this provision.

290. The Commission requires the notification to include the fact that a 911 call has been made, a valid callback number, and the same location information that is conveyed with the call to 911. However, the Commission also provides an exception for callback number and location information in circumstances where including this information in the notification would be technologically infeasible. In addition, the Commission requires that initiation of the notification be contemporaneous with the call to 911, conditioned on whether it is technologically feasible to do so. The Commission also requires that notifications be sent to a location where someone is likely to hear or see the notification but does not require the location to be continuously staffed or monitored. The absence of a continuous staffing or monitoring requirement minimizes a potentially significant cost for small businesses. The Report and Order also clarifies that an MLTS must be configured to provide notification for any caller on the system, including callers at satellite or branch locations. These requirements are highly flexible and give enterprises, including small businesses, significant latitude to configure suitable notification mechanisms without unreasonable burden or cost.

291. Consistent with Kari's Law, the Commission establishes February 16, 2020, as the compliance date for the regulations implementing the statute. The Commission also affords all entities flexibility, including small businesses, to come into compliance with the notification requirements of Kari's Law. This should give enterprises, including small businesses, sufficient advance notice to make informed manufacturing, planning, and purchasing decisions. In addition, because the statute and regulations apply to MLTS that are manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020, enterprises have the flexibility to retain an existing MLTS until the end of its useful life should they choose to do so. The Commission declines to adopt disclosure requirements for existing MLTS and, instead, encourages industry to consider disclosure and education as part of voluntary best practices. This avoids “one-size-fits-all” disclosure requirements and allows enterprises the flexibility to disclose the limitations of calling 911 from legacy MLTS in a way that makes sense for their particular business.

292. Dispatchable Location. In the Report and Order, the Commission adopts rules to implement the dispatchable location requirements that are measured, technologically neutral and include a phased-in compliance timetable in order to minimize implementation costs, and leverage technological advances. The Commission's measured approach seeks to minimize costs and burdens for small businesses and other enterprises where possible, while providing these MLTS and communications service providers significant flexibility to comply with the rules adopted. For example, small businesses can take advantage of the option for MLTS and other communication service providers subject to 911 requirements that are unable to provide a dispatchable location consistent with the rules adopted in the Report and Order, to elect to provide alternative location information, and incur minimal to no implementation costs as a result. Moreover, the Commission's decision not to mandate any particular technology or model for implementing the 911 location rules gives small businesses the ability choose a compliance approach that best fits their economic circumstances. Because delivering dispatchable location is already technically feasible for many services today, MLTS and other service providers subject to our 911 location rules need only choose the methods necessary to close the gap between already-deployed capabilities and the Commission's requirements, “rather than starting from scratch” which should prove less costly for small businesses. Similarly, the Commission's decision to implement a phased-in approach for compliance and to tailor compliance deadlines to particular technologies rather than adopting a hard and fast, “one size fits all” approach takes into account the needs of small businesses for flexibility and a longer compliance timeframe. Additionally, by apply the adopted rules on a prospective basis, the Commission will minimize costs for small businesses and legacy MLTS systems.

293. Finally, the Commission considered adopting a small business exemption for our dispatchable location requirements but declined to adopt such an exemption because the flexible rules afford small businesses a broad menu of options for compliance that we believe are scalable in ways to make them cost-effective for small businesses. Further, the proposed criteria for small business exemptions would have undermined the purpose of the dispatchable location rules, i.e., to improve location accuracy, while offering no countervailing reduction in compliance costs. Rather than an exemption that relies on proposed criteria that would have little or no practical effect on small businesses, we believe the flexible and scalable rules that we adopt will minimize burdens on small businesses while advancing Congress's location accuracy goals.

294. Rule Consolidation. The Report and Order also consolidates various 911 rules into a single rule part, i.e., part 9, to the extent practicable. As part of this consolidation, the Commission simplifies and streamlines the rules in some instances and eliminates corresponding duplicative rules in other rule parts. We believe the rule consolidation helps to minimize the burden on small entities subject to the Commission's 911 rules because it simplifies and streamlines the rules, making it easier for small entities to identify and understand what's required to comply with all 911 requirements.

295. Report to Congress. The Commission will send a copy of the Report and Order, including this FRFA, in a report to Congress pursuant to the Congressional Review Act. In addition, the Commission will send a copy of the Report and Order, including this FRFA, to the Chief Counsel for Advocacy of the SBA. A copy of the Report and Order, and FRFA (or summaries thereof) will also be published in the Federal Register.

VI. Conversion Tables

Conversion Table A

Final rule	Source rule(s)	Comment(s)
Subpart A—Purpose and Definitions
§ 9.1 Purpose
§ 9.2 Reserved
§ 9.3 Definitions	47 CFR 9.3, 20.3, 25.103, 64.601(a), and 64.3000	Certain definitions from source rules added to § 9.3; some definitions revised; some definitions new.
Subpart B—Telecommunications Carriers		Part 64, subpart AA (Universal Emergency Telephone Number) is removed and reserved.
§ 9.4 Obligation to transmit 911 calls	47 CFR 64.3001	Source rule moved to § 9.4 and subpart AA removed and reserved in part 64.
§ 9.5 Transition to 911 as the universal emergency telephone number	47 CFR 64.3002	Source rule moved to § 9.5 and subpart AA removed and reserved in part 64.
§ 9.6 Obligation for providing a permissive dialing period	47 CFR 64.3003	Source rule moved to § 9.6 and subpart AA removed and reserved in part 64.
§ 9.7 Obligation for providing an intercept message	47 CFR 64.3004	Source rule moved to § 9.7 and subpart AA removed and reserved in part 64.
§ 9.8 Obligation of fixed telephony providers to convey dispatchable location		New provision.
Subpart C—Commercial Mobile Radio Service
§ 9.9 Definitions	47 CFR 20.3	Certain definitions from source rule added to § 9.9.
§ 9.10 911 Service Requirements	47 CFR 20.18	Source rule moved to § 9.10 and revised to add paragraph (q)(10)(v); and removed and reserved in Part 20.
Subpart D—Interconnected Voice over Internet Protocol Services
§ 9.11 E911 Service	47 CFR 9.5	Source rule moved to § 9.11 and revised except for § 9.5(f), which is omitted.
§ 9.12 Access to 911 and E911 service capabilities	47 CFR 9.7	Source rule moved to § 9.12 and revised.
Subpart E—Telecommunications Relay Services for Persons With Disabilities
§ 9.13 Jurisdiction	47 CFR 64.601(b) and 64.602	Source rules added to § 9.13.
§ 9.14 Emergency Calling Requirements	47 CFR 64.604(a)(4) and 64.605	Source rules moved to § 9.14 and revised; § 64.605 removed and reserved in part 64.
Subpart F—Multi Line Telephone Systems		New provision.
§ 9.15 Applicability
§ 9.16 General obligations—direct 911 dialing, notification and dispatchable location
§ 9.17 Enforcement, compliance date, State law
Subpart G—Mobile-Satellite Service
§ 9.18 Emergency Call Center Service	47 CFR 25.284	Source rule moved to § 9.18 and removed and reserved in part 25.
Subpart H—Resiliency, redundancy and reliability of 911 communications		Part 12 is consolidated under part 9, subpart H and is removed and reserved.
§ 9.19 Reliability of covered 911 service providers	47 CFR 12.4	Source rule moved to § 9.19 and removed and reserved in part 12.
§ 9.20 Backup power obligations	47 CFR 12.5	Source rule moved to § 9.20 and removed and reserved in part 12.

Conversion Table B

Part 1—Practice and Procedure, Final Rule Changes

Current rule No.	Subject	Final Changes
1.9020	Spectrum manager leasing arrangements	Updated cross-references.
1.9030	Long-term de facto transfer leasing arrangements	Updated cross-references.
1.9035	Short-term de facto transfer leasing arrangements	Updated cross-references.
1.9049	Special provisions relating to spectrum leasing arrangements involving the ancillary terrestrial component of Mobile Satellite Services	Updated cross-references.

Part 9—Interconnected Voice Over Internet Protocol Services, Final Rule Changes

Current rule No.	Subject	Final changes
9.1	Purposes	Revised.
9.3	Definitions	Definition of “Registered Location” moved to § 9.3 and revised.
		All other definitions remain in § 9.3:
		ANI
		Appropriate local emergency authority.
		Automatic Location Information (ALI).
		CMRS.
		Interconnected VoIP service.
		PSAP.
		Pseudo Automatic Number Identification (Pseudo-ANI).
		Statewide default answering point.
		Wireline E911 Network.
9.5	E911 Service	Moved to § 9.11 and revised, except for § 9.5(f), which is a one-time information collection that has been completed. Removed the obligation in § 9.5(f).
9.7	Access to 911 and E911 service capabilities	Moved to § 9.12 and revised.

Part 12—Resiliency, Redundancy and Reliability of Communications, Final Rule Changes

Current rule No.	Subject	Final changes
12.1	Purpose	Removed.
12.3	911 and E911 analyses and reports	Removed (one-time reporting requirement has been completed).
12.4	Reliability of covered 911 service providers	Moved to § 9.19; corrected internal cross-references.
12.5	Backup power obligations	Moved to § 9.20; corrected internal cross-references.

Part 20—Commercial Mobile Services, Final Rule Changes

Current rule No.	Subject	Final changes
20.2	Other applicable rule parts	Section 20.2 specifies other FCC rule parts applicable to licensees in the commercial mobile radio services. Revised § 20.2 by adding a reference to compliance with the 911 requirements in part 9 of this chapter.
20.3	Definitions	Definitions of the following terms added to § 9.3 and removed from § 20.3:
		Appropriate local emergency authority.
		Automatic Number Identification (ANI) (The version in 9.3 is revised slightly to harmonize it with the definition of ANI from § 64.601.)
		Designated PSAP.
		Handset-based location technology.
		Location-capable handsets.
		Network-based Location Technology.
		Pseudo Automatic Number Identification (Pseudo-ANI).
		Public safety answering point (PSAP) (The version in § 9.3 is revised slightly for clarity by adding the word “answering” before “point.”).
		Statewide default answering point.
		Definitions of the following terms added to § 9.3 (but not removed from § 20.3)
		Commercial mobile radio service (acronym CMRS added to definition for clarity).
		Mobile Service.
		Public Switched Network.
		Private Mobile Radio Service.
		Definitions of the following terms added to § 9.9 (but not removed from § 20.3):
		Interconnection or Interconnected.
		Interconnected Service.
20.18	911 Service	Moved to § 9.10; corrected internal cross-references.
		Corrected certain internal references to paragraph (j), which was previously redesignated as paragraph (m).
		Corrected certain internal references to paragraph (n), which was previously redesignated as paragraph (q).
		Added new paragraph (q)(10)(v).

Part 22—Public Mobile Services, Final Rule Changes

Current rule No.	Subject	Final changes
22.921	911 call processing procedures; 911-only calling mode	Removed and reserved.

Part 25—Satellite Communications, Final Rule Changes

Current rule No.	Subject	Final changes
25.103	Definitions	Definitions of the following terms added to § 9.3 (but not removed from § 25.103):
		Earth station.
		Feeder link.
		Fixed-Satellite Service (FSS).
		Mobile Earth Station.
		Mobile-Satellite Service (MSS).
		Space station.
		Definition of the following term added to § 9.3 and removed from § 25.103:
		Emergency Call Center.
25.284	Emergency Call Center Service	Moved to § 9.18; § 25.284 removed and reserved.

Part 64—Miscellaneous Rules Relating to Common Carriers, Final Rule Changes

Current rule No.	Subject	Final changes
64.601	Definitions and provisions of general applicability	Section 64.601(b), which states that “For purposes of this subpart, all regulations and requirements applicable to common carriers shall also be applicable to providers of interconnected VoIP service,” is added to § 9.13, with reference to the definition of interconnected VoIP in § 9.3.
		Section 64.601(a), which lists several terms and defines them by cross-referencing other rule sections, is revised to remove the terms “Public Safety Answering Point (PSAP),” “statewide default answering point,” and “appropriate local emergency authority.”
		Definition of ANI added to § 9.3 but not removed from § 64.601.
		Definition of Registered Location added to § 9.3 and revised.
		Definition of Real-Time Text (RTT) is added to § 9.3 and revised to include definition from 67.1 (rather than cross-reference to § 67.1).
		Definition of the following terms added to § 9.3 (but not removed from § 64.601):
		Common carrier or carrier.
		Communications assistant (CA).
		Internet-based TRS (iTRS).
		iTRS access technology.
		Internet-based TRS (iTRS).
		Internet Protocol Captioned Telephone Service (IP CTS).
		Internet Protocol Relay Service (IP Relay).
		Non-English language relay service.
		Speech-to-speech relay service.
		Telecommunications relay services (TRS).
		Text telephone (TTY).
		Video relay service (VRS).
64.602	Jurisdiction	Section 64.602, which states that “Any violation of this subpart F by any common carrier engaged in intrastate communication shall be subject to the same remedies, penalties, and procedures as are applicable to a violation of the Act by a common carrier engaged in interstate communication,” is added to § 9.13 (with reference to subpart E of part 9).
64.603	Provision of services	Section 64.603(a) requires common carriers providing telephone voice transmission services to provide telecommunications relay services in compliance with the regulations prescribed in subpart F of part 64. Revised § 64.603(a) so that it also refers to compliance with the emergency calling requirements prescribed in part 9, subpart E of this chapter.
64.604(a)(4)	Emergency call handling requirements for TTY-based TRS providers	Moved to § 9.14(a); § 64.604(a)(4) removed and reserved; and § 64.604(d) revised to update cross-reference from § 64.605 to § 9.14.
64.605	Emergency calling requirements	Moved to § 9.14(b) and (c); § 64.605 removed and reserved.
64.3000	Definitions	Moved to § 9.3 and removed from part 64 as subpart AA (Universal Emergency Telephone Number) is removed and reserved.
		Definition of the following terms added to § 9.3 (and removed from Part 64 as subpart AA is removed and reserved):
		911 calls.
		Appropriate local emergency authority.
		Public safety answering point (PSAP) (The version in § 9.3 is revised slightly for consistency with the version from § 20.3 and for clarity; “facility” changed to “answering point.”).
		Statewide default answering point.
64.3001	Obligation to transmit 911 calls	Moved to § 9.4 and removed from part 64 as subpart AA (Universal Emergency Telephone Number) is removed and reserved.
64.3002	Transition to 911 as the universal emergency telephone number	Moved to § 9.5 and removed from part 64 as subpart AA (Universal Emergency Telephone Number) is removed and reserved.
64.3003	Obligation for providing a permissive dialing period	Moved to § 9.6 and removed from part 64 as subpart AA (Universal Emergency Telephone Number) is removed and reserved.
64.3004	Obligation for providing an intercept message	Moved to § 9.7 and removed from part 64 as subpart AA (Universal Emergency Telephone Number) is removed and reserved.

VII. Ordering Clauses

296. Accordingly, it is ordered, pursuant to sections 1, 4(i), 4(j), 4(o), 201(b), 251(e), 301, 303(b), 303(r), 307, 309, and 316 of the Communications Act of 1934, as amended, 47 U.S.C. 151, 154(i), 154(j), 154(o), 201(b), 251(e), 301, 303(b), 303(r), 307, 309, 316 and pursuant to Kari's Law Act of 2017, Public Law 115-127, 47 U.S.C. 623 and 623 note, section 506 of the Repack Airwaves Yielding Better Access for Users of Modern Services Act of 2018 (RAY BAUM'S Act), Public Law 115-141, 47 U.S.C. 615 note, Section 106 of the Twenty-First Century Communications and Video Accessibility Act of 2010, Public Law 111-260, 47 U.S.C. 615c, section 101 of the New and Emerging Technologies 911 Improvement Act of 2008, Public Law 110-283, 47 U.S.C. 615a-1, Middle Class Tax Relief and Job Creation Act of 2012, Public Law 112-96, 47 U.S.C. 1471, and the Wireless Communications and Public Safety Act of 1999, Public Law 106-81, 47 U.S.C. 615 note, 615, 615a, 615b, that this Report and Order is adopted.

297. It is further ordered that the amendments of the Commission's rules as set forth in Appendix A are adopted, effective thirty days from the date of publication in the Federal Register. Sections 9.8(a); 9.10(q)(10)(v); 9.11(b)(2)(ii); 9.11(b)(2)(iv); 9.11(b)(4); 9.11(b)(5)(ii); (iii); 9.14(d)(2)(ii); (iii); 9.14(d)(2)(v); 9.14(d)(4); 9.14(e)(2)(ii); 9.14(e)(2)(iv); 9.14(e)(4); 9.16(b)(3)(i); (ii); and (iii), contain new or modified information collection requirements that require review by the OMB under the PRA. The Commission directs the Public Safety and Homeland Security Bureau (Bureau) to announce the effective date of those information collections in a document published in the Federal Register after the Commission receives OMB approval, and directs the Bureau to cause §§ 9.8(b); 9.10(s); 9.11(c); 9.14(f); 9.16(c), to be revised accordingly.

298. It is further ordered that the Commission SHALL SEND a copy of the Report and Order in a report to be sent to Congress and the Government Accountability Office pursuant to the Congressional Review Act, 5 U.S.C. 801(a)(1)(A).

299. It is further ordered that the Commission's Consumer and Governmental Affairs Bureau, Reference Information Center, shall send a copy of the Report and Order, including the Final Regulatory Flexibility Analysis, to the Chief Counsel for Advocacy of the Small Business Administration.

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

• Communications
• Communications common carriers
• Communications Equipment
• Reporting and recordkeeping requirements
• Security measures
• Satellites
• Telecommunications
• Telephone

Federal Communications Commission.

Katura Jackson,

Federal Register Liaison Officer.

Final Rules

For the reasons discussed in the preamble, the Federal Communications Commission amends 47 parts 1, 9, 12, 20, 25, and 64 as follows:

PART 1—PRACTICE AND PROCEDURE

1. The authority citation for part 1 continues to read as follows:

Authority: 47 U.S.C. chs. 2, 5, 9, 13; 28 U.S.C. 2461 note, unless otherwise noted.

2. Section 1.9020 is amended by revising paragraph (d)(8) to read as follows:

§ 1.9020

Spectrum manager leasing arrangements.

* * * * *

(d) * * *

(8) E911 requirements. If E911 obligations apply to the licensee (see § 9.10 of this chapter), the licensee retains the obligations with respect to leased spectrum. However, if the spectrum lessee is a Contraband Interdiction System (CIS) provider, as defined in § 1.9003, then the CIS provider is responsible for compliance with § 9.10(r) regarding E911 transmission obligations.

* * * * *

3. Section 1.9030 is amended by revising paragraph (d)(8) to read as follows:

§ 1.9030

Long-term de facto transfer leasing arrangements.

* * * * *

(d) * * *

(8) E911 requirements. To the extent the licensee is required to meet E911 obligations (see § 9.10 of this chapter), the spectrum lessee is required to meet those obligations with respect to the spectrum leased under the spectrum leasing arrangement insofar as the spectrum lessee's operations are encompassed within the E911 obligations. If the spectrum lessee is a Contraband Interdiction System (CIS) provider, as defined in § 1.9003, then the CIS provider is responsible for compliance with § 9.10(r) regarding E911 transmission obligations.

* * * * *

4. Section 1.9035 is amended by revising paragraph (d)(4) to read as follows:

§ 1.9035

Short-term de facto transfer leasing arrangements.

* * * * *

(d) * * *

(4) E911 requirements. If E911 obligations apply to the licensee (see § 9.10 of this chapter), the licensee retains the obligations with respect to leased spectrum. A spectrum lessee entering into a short-term de facto transfer leasing arrangement is not separately required to comply with any such obligations in relation to the leased spectrum. However, if the spectrum lessee is a Contraband Interdiction System (CIS) provider, as defined in § 1.9003, then the CIS provider is responsible for compliance with § 9.10(r) regarding E911 transmission obligations.

* * * * *

5. Section 1.9049 is amended by revising paragraph (c) to read as follows:

§ 1.9049

Special provisions relating to spectrum leasing arrangements involving the ancillary terrestrial component of Mobile Satellite Services.

* * * * *

(c) For purposes of § 1.9020(d)(8), the Mobile Satellite Service licensee's obligation, if any, concerning the E911 requirements in § 9.10 of this chapter, will, with respect to an ATC, be specified in the licensing document for the ATC.

* * * * *

6. Revise part 9 to read as follows:

PART 9—911 REQUIREMENTS

Subpart A—Purpose and Definitions

9.1

Purpose.

9.2

[Reserved]

9.3

Definitions.

Subpart B—Telecommunications Carriers

9.4

Obligation to transmit 911 calls.

9.5

Transition to 911 as the universal emergency telephone number.

9.6

Obligation for providing a permissive dialing period.

9.7

Obligation for providing an intercept message.

9.8

Obligation of fixed telephony providers to convey dispatchable location.

Subpart C—Commercial Mobile Radio Service

9.9

Definitions.

9.10

911 Service.

Subpart D—Interconnected Voice over Internet Protocol Services

9.11

E911 Service.

9.12

Access to 911 and E911 service capabilities.

Subpart E—Telecommunications Relay Services for Persons With Disabilities

9.13

Jurisdiction.

9.14

Emergency calling requirements.

Subpart F—Multi-Line Telephone Systems

9.15

Applicability.

9.16

General obligations—direct 911 dialing, notification, and dispatchable location.

9.17

Enforcement, compliance date, State law.

Subpart G—Mobile-Satellite Service

9.18

Emergency Call Center service.

Subpart H—Resiliency, Redundancy, and Reliability of 911 Communications

9.19

Reliability of covered 911 service providers.

9.20

Backup power obligations.

Authority: 47 U.S.C. 151-154, 152(a), 155(c), 157, 160, 201, 202, 208, 210, 214, 218, 219, 222, 225, 251(e), 255, 301, 302, 303, 307, 308, 309, 310, 316, 319, 332, 403, 405, 605, 610, 615, 615 note, 615a, 615b, 615c, 615a-1, 616, 620, 621, 623, 623 note, 721, and 1471, unless otherwise noted.

Subpart A—Purpose and Definitions

§ 9.1

Purpose.

The purpose of this part is to set forth the 911 and E911 service requirements and conditions applicable to telecommunications carriers (subpart B); commercial mobile radio service (CMRS) providers (subpart C); interconnected Voice over Internet Protocol (VoIP) providers (subpart D); providers of telecommunications relay services (TRS) for persons with disabilities (subpart E); multi-line telephone systems (MLTS) (subpart F); and Mobile-Satellite Service (MSS) providers (subpart G). The rules in this part also include requirements to help ensure the resiliency, redundancy, and reliability of communications systems, particularly 911 and E911 networks and/or systems (subpart H).

§ 9.2

[Reserved]

§ 9.3

Definitions.

Terms with definitions including the “(RR)” designation are defined in the same way in § 2.1 of this chapter and in the Radio Regulations of the International Telecommunication Union.

911 calls. Any call initiated by an end user by dialing 911 for the purpose of accessing an emergency service provider. For wireless carriers, all 911 calls include those they are required to transmit pursuant to subpart C of this part.

Alternative location information. Location information (which may be coordinate-based) sufficient to identify the caller's civic address and approximate in-building location, including floor level, in large buildings.

Appropriate local emergency authority. An emergency answering point that has not been officially designated as a Public Safety Answering Point (PSAP), but has the capability of receiving 911 calls and either dispatching emergency services personnel or, if necessary, relaying the call to another emergency service provider. An appropriate local emergency authority may include, but is not limited to, an existing local law enforcement authority, such as the police, county sheriff, local emergency medical services provider, or fire department.

Automated dispatchable location. Automatic generation of dispatchable location.

Automatic Location Information (ALI). Information transmitted while providing E911 service that permits emergency service providers to identify the geographic location of the calling party.

Automatic Number Identification (ANI). For 911 systems, the Automatic Number Identification (ANI) identifies the calling party and may be used as the callback number.

Commercial mobile radio service (CMRS). A mobile service that is:

(1)(i) Provided for profit, i.e., with the intent of receiving compensation or monetary gain;

(ii) An interconnected service; and

(iii) Available to the public, or to such classes of eligible users as to be effectively available to a substantial portion of the public; or

(2) The functional equivalent of such a mobile service described in paragraph (1) of this definition.

(3) A variety of factors may be evaluated to make a determination whether the mobile service in question is the functional equivalent of a commercial mobile radio service, including: Consumer demand for the service to determine whether the service is closely substitutable for a commercial mobile radio service; whether changes in price for the service under examination, or for the comparable commercial mobile radio service, would prompt customers to change from one service to the other; and market research information identifying the targeted market for the service under review.

(4) Unlicensed radio frequency devices under part 15 of this chapter are excluded from this definition of Commercial mobile radio service.

Common carrier or carrier. Any common carrier engaged in interstate Communication by wire or radio as defined in section 3(h) of the Communications Act of 1934, as amended (the Act), and any common carrier engaged in intrastate communication by wire or radio, notwithstanding sections 2(b) and 221(b) of the Act. Communications assistant (CA). A person who transliterates or interprets conversation between two or more end users of TRS.

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

Designated PSAP. The Public Safety Answering Point (PSAP) designated by the local or state entity that has the authority and responsibility to designate the PSAP to receive wireless 911 calls.

Dispatchable location. A location delivered to the PSAP with a 911 call that consists of the validated street address of the calling party, plus additional information such as suite, apartment or similar information necessary to adequately identify the location of the calling party, except for Commercial Mobile Radio Service providers, which shall convey the location information required by subpart C of this part.

Earth station. A station located either on the Earth's surface or within the major portion of the Earth's atmosphere intended for communication:

(1) With one or more space stations; or

(2) With one or more stations of the same kind by means of one or more reflecting satellites or other objects in space. (RR)

Emergency Call Center. A facility that subscribers of satellite commercial mobile radio services call when in need of emergency assistance by dialing “911” on their mobile earth station terminals.

Feeder link. A radio link from a fixed earth station at a given location to a space station, or vice versa, conveying information for a space radiocommunication service other than the Fixed-Satellite Service. The given location may be at a specified fixed point or at any fixed point within specified areas. (RR)

Fixed-Satellite Service (FSS). A radiocommunication service between earth stations at given positions, when one or more satellites are used; the given position may be a specified fixed point or any fixed point within specified areas; in some cases this service includes satellite-to-satellite links, which may also be operated in the inter-satellite service; the Fixed-Satellite Service may also include feeder links of other space radiocommunication services. (RR)

Handset-based location technology. A method of providing the location of wireless 911 callers that requires the use of special location-determining hardware and/or software in a portable or mobile phone. Handset-based location technology may also employ additional location-determining hardware and/or software in the CMRS network and/or another fixed infrastructure.

iTRS access technology. Any equipment, software, or other technology issued, leased, or provided by an internet-based TRS provider that can be used to make and receive an internet-based TRS call.

Improvement to the hardware or software of the system. An improvement to the hardware or software of the MLTS, including upgrades to the core systems of the MLTS, as well as substantial upgrades to the software and any software upgrades requiring a significant purchase.

Interconnected VoIP service. (1) An interconnected Voice over Internet Protocol (VoIP) service is a service that:

(i) Enables real-time, two-way voice communications;

(ii) Requires a broadband connection from the user's location;

(iii) Requires internet protocol-compatible customer premises equipment (CPE); and

(iv) Permits users generally to receive calls that originate on the public switched telephone network and to terminate calls to the public switched telephone network.

(2) Notwithstanding the foregoing, solely for purposes of compliance with the Commission's 911 obligations, an interconnected VoIP service includes a service that fulfills each of paragraphs (1)(i) through (iii) of this definition and permits users generally to terminate calls to the public switched telephone network.

Internet-based TRS (iTRS). A telecommunications relay service (TRS) in which an individual with a hearing or a speech disability connects to a TRS communications assistant using an Internet Protocol-enabled device via the internet, rather than the public switched telephone network. Except as authorized or required by the Commission, internet-based TRS does not include the use of a text telephone (TTY) or RTT over an interconnected voice over Internet Protocol service.

Internet Protocol Captioned Telephone Service (IP CTS). A telecommunications relay service that permits an individual who can speak but who has difficulty hearing over the telephone to use a telephone and an Internet Protocol-enabled device via the internet to simultaneously listen to the other party and read captions of what the other party is saying. With IP CTS, the connection carrying the captions between the relay service provider and the relay service user is via the internet, rather than the public switched telephone network.

Internet Protocol Relay Service (IP Relay). A telecommunications relay service that permits an individual with a hearing or a speech disability to communicate in text using an Internet Protocol-enabled device via the internet, rather than using a text telephone (TTY) and the public switched telephone network.

Location-capable handsets. Portable or mobile phones that contain special location-determining hardware and/or software, which is used by a licensee to locate 911 calls.

MLTS notification. An MLTS feature that can send notice to a central location at the facility where the system is installed or to another person or organization regardless of location. Examples of notification include conspicuous on-screen messages with audible alarms for security desk computers using a client application, text messages for smartphones, and email for administrators. Notification shall include, at a minimum, the following information:

(1) The fact that a 911 call has been made;

(2) A valid callback number; and

(3) The information about the caller's location that the MLTS conveys to the public safety answering point (PSAP) with the call to 911; provided, however, that the notification does not have to include a callback number or location information if it is technically infeasible to provide this information.

Mobile Earth Station. An earth station in the Mobile-Satellite Service intended to be used while in motion or during halts at unspecified points. (RR)

Mobile-Satellite Service (MSS). (1) A radiocommunication service:

(i) Between mobile earth stations and one or more space stations, or between space stations used by this service; or

(ii) Between mobile earth stations, by means of one or more space stations.

(2) This service may also include feeder links necessary for its operation. (RR)

Mobile service. A radio communication service carried on between mobile stations or receivers and land stations, and by mobile stations communicating among themselves, and includes:

(1) Both one-way and two-way radio communications services;

(2) A mobile service which provides a regularly interacting group of base, mobile, portable, and associated control and relay stations (whether licensed on an individual, cooperative, or multiple basis) for private one-way or two-way land mobile radio communications by eligible users over designated areas of operation; and

(3) Any service for which a license is required in a personal communications service under part 24 of this chapter.

Network-based location technology. A method of providing the location of wireless 911 callers that employs hardware and/or software in the CMRS network and/or another fixed infrastructure, and does not require the use of special location-determining hardware and/or software in the caller's portable or mobile phone.

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

Non-English language relay service. A telecommunications relay service that allows persons with hearing or speech disabilities who use languages other than English to communicate with voice telephone users in a shared language other than English, through a CA who is fluent in that language.

On-premises. In the context of a multi-line telephone system, within the fixed property (e.g. building(s), facilities, or campus) and under the operational control of a single administrative authority.

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

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

Person engaged in the business of manufacturing, importing, selling, or leasing an MLTS. A person that manufactures, imports, sells, or leases an MLTS.

Person engaged in the business of operating an MLTS. A person responsible for the day-to-day operations of the MLTS.

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

Private mobile radio service. A mobile service that meets neither the paragraph (1) nor paragraph (2) in the definition of commercial mobile radio service in this section. A mobile service that does not meet paragraph (1) in the definition of commercial mobile radio service in this section is presumed to be a private mobile radio service. Private mobile radio service includes the following:

(1) Not-for-profit land mobile radio and paging services that serve the licensee's internal communications needs as defined in part 90 of this chapter. Shared-use, cost-sharing, or cooperative arrangements, multiple licensed systems that use third party managers or users combining resources to meet compatible needs for specialized internal communications facilities in compliance with the safeguards of § 90.179 of this chapter are presumptively private mobile radio services;

(2) Mobile radio service offered to restricted classes of eligible users. This includes entities eligible in the Public Safety Radio Pool and Radiolocation service.

(3) 220-222 MHz land mobile service and Automatic Vehicle Monitoring systems (part 90 of this chapter) that do not offer interconnected service or that are not-for-profit; and

(4) Personal Radio Services under part 95 of this chapter (General Mobile Services, Radio Control Radio Services, and Citizens Band Radio Services); Maritime Service Stations (excluding Public Coast stations) (part 80 of this chapter); and Aviation Service Stations (part 87 of this chapter).

Pseudo Automatic Number Identification (Pseudo-ANI). A number, consisting of the same number of digits as ANI, that is not a North American Numbering Plan telephone directory number and may be used in place of an ANI to convey special meaning. The special meaning assigned to the pseudo-ANI is determined by agreements, as necessary, between the system originating the call, intermediate systems handling and routing the call, and the destination system.

Public safety answering point or PSAP. An answering point that has been designated to receive 911 calls and route them to emergency services personnel.

Public Switched Network. Any common carrier switched network, whether by wire or radio, including local exchange carriers, interexchange carriers, and mobile service providers, that uses the North American Numbering Plan in connection with the provision of switched services.

Real-Time Text (RTT). Text communications that are transmitted over Internet Protocol (IP) networks immediately as they are created, e.g., on a character-by-character basis.

Registered internet-based TRS user. An individual that has registered with a VRS, IP Relay, or IP CTS provider as described in § 64.611.

Registered Location. The most recent information obtained by a provider of interconnected VoIP service or telecommunications relay services (TRS), as applicable, that identifies the physical location of an end user.

Space station. A station located on an object which is beyond, is intended to go beyond, or has been beyond, the major portion of the Earth's atmosphere. (RR)

Speech-to-speech relay service (STS). A telecommunications relay service that allows individuals with speech disabilities to communicate with voice telephone users through the use of specially trained CAs who understand the speech patterns of persons with speech disabilities and can repeat the words spoken by that person.

Statewide default answering point. An emergency answering point designated by the State to receive 911 calls for either the entire State or those portions of the State not otherwise served by a local PSAP.

Station. A station equipped to engage in radio communication or radio transmission of energy (47 U.S.C. 153(k)).

Telecommunications relay services (TRS). Telephone transmission services that provide the ability for an individual who has a hearing or speech disability to engage in communication by wire or radio with a hearing individual in a manner that is functionally equivalent to the ability of an individual who does not have a hearing or speech disability to communicate using voice communication services by wire or radio. Such term includes services that enable two-way communication between an individual who uses a text telephone or other nonvoice terminal device and an individual who does not use such a device, speech-to-speech services, video relay services and non-English relay services. TRS supersedes the terms “dual party relay system,” “message relay services,” and “TDD Relay.”

Text telephone (TTY). A machine that employs graphic communication in the transmission of coded signals through a wire or radio communication system. TTY supersedes the term “TDD” or “telecommunications device for the deaf,” and TT.

Video relay service (VRS). A telecommunications relay service that allows people with hearing or speech disabilities who use sign language to communicate with voice telephone users through video equipment. The video link allows the CA to view and interpret the party's signed conversation and relay the conversation back and forth with a voice caller.

Wireline E911 Network. A dedicated wireline network that:

(1) Is interconnected with but largely separate from the public switched telephone network;

(2) Includes a selective router; and

(3) Is used to route emergency calls and related information to PSAPs, designated statewide default answering points, appropriate local emergency authorities or other emergency answering points.

Subpart B—Telecommunications Carriers

§ 9.4

Obligation to transmit 911 calls.

All telecommunications carriers shall transmit all 911 calls to a PSAP, to a designated statewide default answering point, or to an appropriate local emergency authority as set forth in § 9.5.

§ 9.5

Transition to 911 as the universal emergency telephone number.

As of December 11, 2001, except where 911 is already established as the exclusive emergency number to reach a PSAP within a given jurisdiction, telecommunications carriers shall comply with the following transition periods:

(a) Where a PSAP has been designated, telecommunications carriers shall complete all translation and routing necessary to deliver 911 calls to a PSAP no later than September 11, 2002.

(b) Where no PSAP has been designated, telecommunications carriers shall complete all translation and routing necessary to deliver 911 calls to the statewide default answering point no later than September 11, 2002.

(c) Where neither a PSAP nor a statewide default answering point has been designated, telecommunications carriers shall complete the translation and routing necessary to deliver 911 calls to an appropriate local emergency authority, within nine months of a request by the State or locality.

(d) Where no PSAP nor statewide default answering point has been designated, and no appropriate local emergency authority has been selected by an authorized state or local entity, telecommunications carriers shall identify an appropriate local emergency authority, based on the exercise of reasonable judgment, and complete all translation and routing necessary to deliver 911 calls to such appropriate local emergency authority no later than September 11, 2002.

(e) Once a PSAP is designated for an area where none had existed as of December 11, 2001, telecommunications carriers shall complete the translation and routing necessary to deliver 911 calls to that PSAP within nine months of that designation.

§ 9.6

Obligation for providing a permissive dialing period.

Upon completion of translation and routing of 911 calls to a PSAP, a statewide default answering point, to an appropriate local emergency authority, or, where no PSAP nor statewide default answering point has been designated and no appropriate local emergency authority has been selected by an authorized state or local entity, to an appropriate local emergency authority, identified by a telecommunications carrier based on the exercise of reasonable judgment, the telecommunications carrier shall provide permissive dialing between 911 and any other seven-or ten-digit emergency number or an abbreviated dialing code other than 911 that the public has previously used to reach emergency service providers until the appropriate State or local jurisdiction determines to phase out the use of such seven-or ten-digit number entirely and use 911 exclusively.

§ 9.7

Obligation for providing an intercept message.

Upon termination of permissive dialing, as provided under § 9.6, telecommunications carriers shall provide a standard intercept message announcement that interrupts calls placed to the emergency service provider using either a seven-or ten-digit emergency number or an abbreviated dialing code other than 911 and informs the caller of the dialing code change.

§ 9.8

Obligation of fixed telephony providers to convey dispatchable location.

(a) Providers of fixed telephony services shall provide automated dispatchable location with 911 calls beginning January 6, 2021.

(b) Paragraph (a) of this section contains information-collection and recordkeeping requirements. Compliance will not be required until after approval by the Office of Management and Budget. The Commission will publish a document in the Federal Register announcing that compliance date and revising this paragraph accordingly.

Subpart C—Commercial Mobile Radio Service

§ 9.9

Definitions.

Interconnection or Interconnected. Direct or indirect connection through automatic or manual means (by wire, microwave, or other technologies such as store and forward) to permit the transmission or reception of messages or signals to or from points in the public switched network.

Interconnected service. (1) A service:

(i) That is interconnected with the public switched network, or interconnected with the public switched network through an interconnected service provider, that gives subscribers the capability to communicate to or receive communication from all other users on the public switched network; or

(ii) For which a request for such interconnection is pending pursuant to section 332(c)(1)(B) of the Communications Act, 47 U.S.C. 332(c)(1)(B).

(2) A mobile service offers interconnected service even if the service allows subscribers to access the public switched network only during specified hours of the day, or if the service provides general access to points on the public switched network but also restricts access in certain limited ways. Interconnected service does not include any interface between a licensee's facilities and the public switched network exclusively for a licensee's internal control purposes.

§ 9.10

911 Service.

(a) Scope of section. Except as described in paragraph (r) of this section, the following requirements of paragraphs (a) through (q) of this section are only applicable to CMRS providers, excluding mobile satellite service (MSS) operators, to the extent that they:

(1) Offer real-time, two way switched voice service that is interconnected with the public switched network; and

(2) Use an in-network switching facility that enables the provider to reuse frequencies and accomplish seamless hand-offs of subscriber calls. These requirements are applicable to entities that offer voice service to consumers by purchasing airtime or capacity at wholesale rates from CMRS licensees.

(b) Basic 911 service. CMRS providers subject to this section must transmit all wireless 911 calls without respect to their call validation process to a Public Safety Answering Point, or, where no Public Safety Answering Point has been designated, to a designated statewide default answering point or appropriate local emergency authority pursuant to § 9.4, provided that “all wireless 911 calls” is defined as “any call initiated by a wireless user dialing 911 on a phone using a compliant radio frequency protocol of the serving carrier.”

(c) Access to 911 services. CMRS providers subject to this section must be capable of transmitting 911 calls from individuals with speech or hearing disabilities through means other than mobile radio handsets, e.g., through the use of Text Telephone Devices (TTY). CMRS providers that provide voice communications over IP facilities are not required to support 911 access via TTYs if they provide 911 access via real-time text (RTT) communications, in accordance with 47 CFR part 67, except that RTT support is not required to the extent that it is not achievable for a particular manufacturer to support RTT on the provider's network.

(d) Phase I enhanced 911 services. (1) As of April 1, 1998, or within six months of a request by the designated Public Safety Answering Point as set forth in paragraph (j) of this section, whichever is later, licensees subject to this section must provide the telephone number of the originator of a 911 call and the location of the cell site or base station receiving a 911 call from any mobile handset accessing their systems to the designated Public Safety Answering Point through the use of ANI and Pseudo-ANI.

(2) When the directory number of the handset used to originate a 911 call is not available to the serving carrier, such carrier's obligations under the paragraph (d)(1) of this section extend only to delivering 911 calls and available call party information, including that prescribed in paragraph (l) of this section, to the designated Public Safety Answering Point.

Note to paragraph (d): With respect to 911 calls accessing their systems through the use of TTYs, licensees subject to this section must comply with the requirements in paragraphs (d)(1) and (2) of this section, as to calls made using a digital wireless system, as of October 1, 1998.

(e) Phase II enhanced 911 service. Licensees subject to this section must provide to the designated Public Safety Answering Point Phase II enhanced 911 service, i.e., the location of all 911 calls by longitude and latitude in conformance with Phase II accuracy requirements (see paragraph (h) of this section).

(f) Phase-in for network-based location technologies. Licensees subject to this section who employ a network-based location technology shall provide Phase II 911 enhanced service to at least 50 percent of their coverage area or 50 percent of their population beginning October 1, 2001, or within 6 months of a PSAP request, whichever is later; and to 100 percent of their coverage area or 100 percent of their population within 18 months of such a request or by October 1, 2002, whichever is later.

(g) Phase-in for handset-based location technologies. Licensees subject to this section who employ a handset-based location technology may phase in deployment of Phase II enhanced 911 service, subject to the following requirements:

(1) Without respect to any PSAP request for deployment of Phase II 911 enhanced service, the licensee shall:

(i) Begin selling and activating location-capable handsets no later than October 1, 2001;

(ii) Ensure that at least 25 percent of all new handsets activated are location-capable no later than December 31, 2001;

(iii) Ensure that at least 50 percent of all new handsets activated are location-capable no later than June 30, 2002; and

(iv) Ensure that 100 percent of all new digital handsets activated are location-capable no later than December 31, 2002, and thereafter.

(v) By December 31, 2005, achieve 95 percent penetration of location-capable handsets among its subscribers.

(vi) Licensees that meet the enhanced 911 compliance obligations through GPS-enabled handsets and have commercial agreements with resellers will not be required to include the resellers' handset counts in their compliance percentages.

(2) Once a PSAP request is received, the licensee shall, in the area served by the PSAP, within six months or by October 1, 2001, whichever is later:

(i) Install any hardware and/or software in the CMRS network and/or other fixed infrastructure, as needed, to enable the provision of Phase II enhanced 911 service; and

(ii) Begin delivering Phase II enhanced 911 service to the PSAP.

(3) For all 911 calls from portable or mobile phones that do not contain the hardware and/or software needed to enable the licensee to provide Phase II enhanced 911 service, the licensee shall, after a PSAP request is received, support, in the area served by the PSAP, Phase I location for 911 calls or other available best practice method of providing the location of the portable or mobile phone to the PSAP.

(4) Licensees employing handset-based location technologies shall ensure that location-capable portable or mobile phones shall conform to industry interoperability standards designed to enable the location of such phones by multiple licensees.

(h) Phase II accuracy. Licensees subject to this section shall comply with the following standards for Phase II location accuracy and reliability, to be tested and measured either at the county or at the PSAP service area geographic level, based on outdoor measurements only:

(1) Network-based technologies:

(i) 100 meters for 67 percent of calls, consistent with the following benchmarks:

(A) One year from January 18, 2011, carriers shall comply with this standard in 60 percent of counties or PSAP service areas. These counties or PSAP service areas must cover at least 70 percent of the population covered by the carrier across its entire network. Compliance will be measured on a per-county or per-PSAP basis using, at the carrier's election, either:

(1) Network-based accuracy data; or

(2) Blended reporting as provided in paragraph (h)(1)(iv) of this section.

(B) Three years from January 18, 2011, carriers shall comply with this standard in 70 percent of counties or PSAP service areas. These counties or PSAP service areas must cover at least 80 percent of the population covered by the carrier across its entire network. Compliance will be measured on a per-county or per-PSAP basis using, at the carrier's election, either:

(1) Network-based accuracy data; or

(2) Blended reporting as provided in paragraph (h)(1)(iv) of this section.

(C) Five years from January 18, 2011, carriers shall comply with this standard in 100% of counties or PSAP service areas covered by the carrier. Compliance will be measured on a per-county or per-PSAP basis, using, at the carrier's election, either:

(1) Network-based accuracy data;

(2) Blended reporting as provided in paragraph (h)(1)(iv) of this section; or

(3) Handset-based accuracy data as provided in paragraph (h)(1)(v) of this section.

(ii) 300 meters for 90 percent of calls, consistent with the following benchmarks:

(A) Three years from January 18, 2011, carriers shall comply with this standard in 60 percent of counties or PSAP service areas. These counties or PSAP service areas must cover at least 70 percent of the population covered by the carrier across its entire network. Compliance will be measured on a per-county or per-PSAP basis using, at the carrier's election, either:

(1) Network-based accuracy data; or

(2) Blended reporting as provided in paragraph (h)(1)(iv) of this section.

(B) Five years from January 18, 2011, carriers shall comply in 70 percent of counties or PSAP service areas. These counties or PSAP service areas must cover at least 80 percent of the population covered by the carrier across its entire network. Compliance will be measured on a per-county or per-PSAP basis using, at the carrier's election, either:

(1) Network-based accuracy data; or

(2) Blended reporting as provided in paragraph (h)(1)(iv) of this section.

(C) Eight years from January 18, 2011, carriers shall comply in 85 percent of counties or PSAP service areas. Compliance will be measured on a per-county or per-PSAP basis using, at the carrier's election, either:

(1) Network-based accuracy data;

(2) Blended reporting as provided in paragraph (h)(1)(iv) of this section; or

(3) Handset-based accuracy data as provided in paragraph (h)(1)(v) of this section.

(iii) County-level or PSAP-level location accuracy standards for network-based technologies will be applicable to those counties or PSAP service areas, on an individual basis, in which a network-based carrier has deployed Phase II in at least one cell site located within a county's or PSAP service area's boundary. Compliance with the requirements of paragraphs (h)(1)(i) and (ii) of this section shall be measured and reported independently.

(iv) Accuracy data from both network-based solutions and handset-based solutions may be blended to measure compliance with the accuracy requirements of paragraphs (h)(1)(i)(A) through (C) and paragraphs (h)(1)(ii)(A) through (C) of this section. Such blending shall be based on weighting accuracy data in the ratio of assisted GPS (“A-GPS”) handsets to non-A-GPS handsets in the carrier's subscriber base. The weighting ratio shall be applied to the accuracy data from each solution and measured against the network-based accuracy requirements of paragraph (h)(1) of this section.

(v) A carrier may rely solely on handset-based accuracy data in any county or PSAP service area if at least 85 percent of its subscribers, network-wide, use A-GPS handsets, or if it offers A-GPS handsets to subscribers in that county or PSAP service area at no cost to the subscriber.

(vi) A carrier may exclude from compliance particular counties, or portions of counties, where triangulation is not technically possible, such as locations where at least three cell sites are not sufficiently visible to a handset. Carriers must file a list of the specific counties or portions of counties where they are using this exclusion within 90 days following approval from the Office of Management and Budget for the related information collection. This list must be submitted electronically into PS Docket No. 07-114, and copies must be sent to the National Emergency Number Association, the Association of Public-Safety Communications Officials-International, and the National Association of State 9-1-1 Administrators. Further, carriers must submit in the same manner any changes to their exclusion lists within thirty days of discovering such changes. This exclusion has sunset as of January 18, 2019.

(2) Handset-based technologies:

(i) Two years from January 18, 2011, 50 meters for 67 percent of calls, and 150 meters for 80 percent of calls, on a per-county or per-PSAP basis. However, a carrier may exclude up to 15 percent of counties or PSAP service areas from the 150-meter requirement based upon heavy forestation that limits handset-based technology accuracy in those counties or PSAP service areas.

(ii) Eight years from January 18, 2011, 50 meters for 67 percent of calls, and 150 meters for 90 percent of calls, on a per-county or per-PSAP basis. However, a carrier may exclude up to 15 percent of counties or PSAP service areas from the 150-meter requirement based upon heavy forestation that limits handset-based technology accuracy in those counties or PSAP service areas.

(iii) Carriers must file a list of the specific counties or PSAP service areas where they are using the exclusion for heavy forestation within 90 days following (approval from the Office of Management and Budget for the related information collection). This list must be submitted electronically into PS Docket No. 07-114, and copies must be sent to the National Emergency Number Association, the Association of Public-Safety Communications Officials-International, and the National Association of State 9-1-1 Administrators. Further, carriers must submit in the same manner any changes to their exclusion lists within thirty days of discovering such changes.

(iv) Providers of new CMRS networks that meet the definition of covered CMRS providers under paragraph (a) of this section must comply with the requirements of paragraphs (h)(2)(i) through (iii) of this section. For this purpose, a “new CMRS network” is a CMRS network that is newly deployed subsequent to the effective date of the Third Report and Order in PS Docket No. 07-114 and that is not an expansion or upgrade of an existing CMRS network.

(3) Latency (Time to First Fix): For purposes of measuring compliance with the location accuracy standards of this paragraph, a call will be deemed to satisfy the standard only if it provides the specified degree of location accuracy within a maximum latency period of 30 seconds, as measured from the time the user initiates the 911 call to the time the location fix appears at the location information center: Provided, however, that the CMRS provider may elect not to include for purposes of measuring compliance therewith any calls lasting less than 30 seconds.

(i) Indoor location accuracy for 911 and testing requirements—(1) Definitions. The terms as used in this section have the following meaning:

(i) Dispatchable location. A location delivered to the PSAP by the CMRS provider with a 911 call that consists of the street address of the calling party, plus additional information such as suite, apartment or similar information necessary to adequately identify the location of the calling party. The street address of the calling party must be validated and, to the extent possible, corroborated against other location information prior to delivery of dispatchable location information by the CMRS provider to the PSAP.

(ii) Media Access Control (MAC) Address. A location identifier of a Wi-Fi access point.

(iii) National Emergency Address Database (NEAD). A database that uses MAC address information to identify a dispatchable location for nearby wireless devices within the CMRS provider's coverage footprint.

(iv) Nationwide CMRS provider. A CMRS provider whose service extends to a majority of the population and land area of the United States.

(v) Non-nationwide CMRS provider. Any CMRS provider other than a nationwide CMRS provider.

(vi) Test cities. The six cities (San Francisco, Chicago, Atlanta, Denver/Front Range, Philadelphia, and Manhattan Borough) and surrounding geographic areas that correspond to the six geographic regions specified by the February 7, 2014 ATIS Document, “Considerations in Selecting Indoor Test Regions,” for testing of indoor location technologies.

(2) Indoor location accuracy standards. CMRS providers subject to this section shall meet the following requirements:

(i) Horizontal location. (A) Nationwide CMRS providers shall provide; dispatchable location, or; x/y location within 50 meters, for the following percentages of wireless 911 calls within the following timeframes, measured from the effective date of the adoption of this rule:

(1) Within 2 years: 40 percent of all wireless 911 calls.

(2) Within 3 years: 50 percent of all wireless 911 calls.

(3) Within 5 years: 70 percent of all wireless 911 calls.

(4) Within 6 years: 80 percent of all wireless 911 calls.

(B) Non-nationwide CMRS providers shall provide; dispatchable location or; x/y location within 50 meters, for the following percentages of wireless 911 calls within the following timeframes, measured from the effective date of the adoption of this rule:

(1) Within 2 years: 40 percent of all wireless 911 calls.

(2) Within 3 years: 50 percent of all wireless 911 calls.

(3) Within 5 years or within six months of deploying a commercially-operating VoLTE platform in their network, whichever is later: 70 percent of all wireless 911 calls.

(4) Within 6 years or within one year of deploying a commercially-operating VoLTE platform in their network, whichever is later: 80 percent of all wireless 911 calls.

(ii) Vertical location. CMRS providers shall provide vertical location information with wireless 911 calls as described in this section within the following timeframes measured from the effective date of the adoption of this rule:

(A) Within 3 years: All CMRS providers shall make uncompensated barometric data available to PSAPs with respect to any 911 call placed from any handset that has the capability to deliver barometric sensor information.

(B) Within 3 years: Nationwide CMRS providers shall develop one or more z-axis accuracy metrics validated by an independently administered and transparent test bed process as described in paragraph (i)(3)(i) of this section, and shall submit the proposed metric or metrics, supported by a report of the results of such development and testing, to the Commission for approval.

(C) Within 6 years: In each of the top 25 CMAs, nationwide CMRS providers shall deploy either;) dispatchable location, or; z-axis technology in compliance with any z-axis accuracy metric that has been approved by the Commission,

(1) In each CMA where dispatchable location is used: nationwide CMRS providers must ensure that the NEAD is populated with a sufficient number of total dispatchable location reference points to equal 25 percent of the CMA population.

(2) In each CMA where z-axis technology is used: nationwide CMRS providers must deploy z-axis technology to cover 80 percent of the CMA population.

(D) Within 8 years: In each of the top 50 CMAs, nationwide CMRS providers shall deploy either

(1) Dispatchable location or;

(2) Such z-axis technology in compliance with any z-axis accuracy metric that has been approved by the Commission.

(E) Non-nationwide CMRS providers that serve any of the top 25 or 50 CMAs will have an additional year to meet each of the benchmarks in paragraphs (i)(2)(ii)(C) and (D) of this section.

(iii) Compliance. Within 60 days after each benchmark date specified in paragraphs (i)(2)(i) and (ii) of this section, CMRS providers must certify that they are in compliance with the location accuracy requirements applicable to them as of that date. CMRS providers shall be presumed to be in compliance by certifying that they have complied with the test bed and live call data provisions described in paragraph (i)(3) of this section.

(A) All CMRS providers must certify that the indoor location technology (or technologies) used in their networks are deployed consistently with the manner in which they have been tested in the test bed. A CMRS provider must update certification whenever it introduces a new technology into its network or otherwise modifies its network, such that previous performance in the test bed would no longer be consistent with the technology's modified deployment.

(B) CMRS providers that provide quarterly reports of live call data in one or more of the six test cities specified in paragraph (i)(1)(vi) of this section must certify that their deployment of location technologies throughout their coverage area is consistent with their deployment of the same technologies in the areas that are used for live call data reporting.

(C) Non-nationwide CMRS providers that do not provide service or report quarterly live call data in any of the six test cities specified in paragraph (i)(1)(vi) of this section must certify that they have verified based on their own live call data that they are in compliance with the requirements of paragraphs (i)(2)(i)(B) and (i)(2)(ii) of this section.

(iv) Enforcement. PSAPs may seek Commission enforcement within their geographic service area of the requirements of paragraphs (i)(2)(i) and (ii) of this section, but only so long as they have implemented policies that are designed to obtain all location information made available by CMRS providers when initiating and delivering 911 calls to the PSAP. Prior to seeking Commission enforcement, a PSAP must provide the CMRS provider with [30] days written notice, and the CMRS provider shall have an opportunity to address the issue informally. If the issue has not been addressed to the PSAP's satisfaction within 90 days, the PSAP may seek enforcement relief.

(3) Indoor location accuracy testing and live call data reporting—(i) Indoor location accuracy test bed. CMRS providers must establish the test bed described in this section within 12 months of the effective date of this rule. CMRS providers must validate technologies intended for indoor location, including dispatchable location technologies and technologies that deliver horizontal and/or vertical coordinates, through an independently administered and transparent test bed process, in order for such technologies to be presumed to comply with the location accuracy requirements of this paragraph. The test bed shall meet the following minimal requirements in order for the test results to be considered valid for compliance purposes:

(A) Include testing in representative indoor environments, including dense urban, urban, suburban and rural morphologies;

(B) Test for performance attributes including location accuracy (ground truth as measured in the test bed), latency (Time to First Fix), and reliability (yield); and

(C) Each test call (or equivalent) shall be independent from prior calls and accuracy will be based on the first location delivered after the call is initiated.

(D) In complying with paragraph (i)(3)(i)(B) of this section, CMRS providers shall measure yield separately for each individual indoor location morphology (dense urban, urban, suburban, and rural) in the test bed, and based upon the specific type of location technology that the provider intends to deploy in real-world areas represented by that particular morphology. CMRS providers must base the yield percentage based on the number of test calls that deliver a location in compliance with any applicable indoor location accuracy requirements, compared to the total number of calls that successfully connect to the testing network. CMRS providers may exclude test calls that are dropped or otherwise disconnected in 10 seconds or less from calculation of the yield percentage (both the denominator and numerator).

(ii) Collection and reporting of aggregate live 911 call location data. CMRS providers providing service in any of the Test Cities or portions thereof must collect and report aggregate data on the location technologies used for live 911 calls in those areas.

(A) CMRS providers subject to this section shall identify and collect information regarding the location technology or technologies used for each 911 call in the reporting area during the calling period.

(B) CMRS providers subject to this section shall report Test City call location data on a quarterly basis to the Commission, the National Emergency Number Association, the Association of Public Safety Communications Officials, and the National Association of State 911 Administrators, with the first report due 18 months from the effective date of rules adopted in this proceeding.

(C) CMRS providers subject to this section shall also provide quarterly live call data on a more granular basis that allows evaluation of the performance of individual location technologies within different morphologies (e.g., dense urban, urban, suburban, rural). To the extent available, live call data for all CMRS providers shall delineate based on a per technology basis accumulated and so identified for:

(1) Each of the ATIS ESIF morphologies;

(2) On a reasonable community level basis; or

(3) By census block. This more granular data will be used for evaluation and not for compliance purposes.

(D) Non-nationwide CMRS providers that operate in a single Test City need only report live 911 call data from that city or portion thereof that they cover. Non-nationwide CMRS providers that operate in more than one Test City must report live 911 call data only in half of the regions (as selected by the provider). In the event a non-nationwide CMRS provider begins coverage in a Test City it previously did not serve, it must update its certification pursuant to paragraph (i)(2)(iii)(C) of this section to reflect this change in its network and begin reporting data from the appropriate areas. All non-nationwide CMRS providers must report their Test City live call data every 6 months, beginning 18 months from the effective date of rules adopted in this proceeding.

(E) Non-nationwide CMRS providers that do not provide coverage in any of the Test Cities can satisfy the requirement of this paragraph (i)(3)(ii) by collecting and reporting data based on the largest county within its footprint. In addition, where a non-nationwide CMRS provider serves more than one of the ATIS ESIF morphologies, it must include a sufficient number of representative counties to cover each morphology.

(iii) Data retention. CMRS providers shall retain testing and live call data gathered pursuant to this section for a period of 2 years.

(4) Submission of plans and reports. The following reporting and certification obligations apply to all CMRS providers subject to this section, which may be filed electronically in PS Docket No. 07-114:

(i) Initial implementation plan. No later than 18 months from the effective date of the adoption of this rule, nationwide CMRS providers shall report to the Commission on their plans for meeting the indoor location accuracy requirements of paragraph (i)(2) of this section. Non-nationwide CMRS providers will have an additional 6 months to submit their implementation plans.

(ii) Progress reports. No later than 18 months from the effective date of the adoption of this rule), each CMRS provider shall file a progress report on implementation of indoor location accuracy requirements. Non-nationwide CMRS providers will have an additional 6 months to submit their progress reports. All CMRS providers shall provide an additional progress report no later than 36 months from the effective date of the adoption of this rule. The 36-month reports shall indicate what progress the provider has made consistent with its implementation plan, and the nationwide CMRS providers shall include an assessment of their deployment of dispatchable location solutions. For any CMRS provider participating in the development of the NEAD database, this progress report must include detail as to the implementation of the NEAD database described in paragraphs (i)(4)(iii) and (iv) of this section.

(iii) NEAD privacy and security plan. Prior to activation of the NEAD but no later than 18 months from the effective date of the adoption of this rule, the nationwide CMRS providers shall file with the Commission and request approval for a security and privacy plan for the administration and operation of the NEAD. The plan must include the identity of an administrator for the NEAD, who will serve as a point of contact for the Commission and shall be accountable for the effectiveness of the security, privacy, and resiliency measures.

(iv) NEAD use certification. Prior to use of the NEAD or any information contained therein to meet such requirements, CMRS providers must certify that they will not use the NEAD or associated data for any non-911 purpose, except as otherwise required by law.

(j) Confidence and uncertainty data. (1) Except as provided in paragraphs (j)(2) and (3) of this section, CMRS providers subject to this section shall provide for all wireless 911 calls, whether from outdoor or indoor locations, x- and y-axis (latitude, longitude) confidence and uncertainty information (C/U data) on a per-call basis upon the request of a PSAP. The data shall specify:

(i) The caller's location with a uniform confidence level of 90 percent, and;

(ii) The radius in meters from the reported position at that same confidence level. All entities responsible for transporting confidence and uncertainty between CMRS providers and PSAPs, including LECs, CLECs, owners of E911 networks, and emergency service providers, must enable the transmission of confidence and uncertainty data provided by CMRS providers to the requesting PSAP.

(2) Upon meeting the 3-year timeframe pursuant to paragraph (i)(2)(i) of this section, CMRS providers shall provide with wireless 911 calls that have a dispatchable location the C/U data for the x- and y-axis (latitude, longitude) required under paragraph (j)(1) of this section.

(3) Upon meeting the 6-year timeframe pursuant to paragraph (i)(2)(i) of this section, CMRS providers shall provide with wireless 911 calls that have a dispatchable location the C/U data for the x- and y-axis (latitude, longitude) required under paragraph (j)(1) of this section.

(k) Provision of live 911 call data for PSAPs. Notwithstanding other 911 call data collection and reporting requirements in paragraph (i) of this section, CMRS providers must record information on all live 911 calls, including, but not limited to, the positioning source method used to provide a location fix associated with the call. CMRS providers must also record the confidence and uncertainty data that they provide pursuant to paragraphs (j)(1) through (3) of this section. This information must be made available to PSAPs upon request, and shall be retained for a period of two years.

(l) Reports on Phase II plans. Licensees subject to this section shall report to the Commission their plans for implementing Phase II enhanced 911 service, including the location-determination technology they plan to employ and the procedure they intend to use to verify conformance with the Phase II accuracy requirements by November 9, 2000. Licensees are required to update these plans within thirty days of the adoption of any change. These reports and updates may be filed electronically in a manner to be designated by the Commission.

(m) Conditions for enhanced 911 services—(1) Generally. The requirements set forth in paragraphs (d) through (h)(2) and in paragraph (j) of this section shall be applicable only to the extent that the administrator of the applicable designated PSAP has requested the services required under those paragraphs and such PSAP is capable of receiving and using the requested data elements and has a mechanism for recovering the PSAP's costs associated with them.

(2) Commencement of six-month period. (i) Except as provided in paragraph (m)(2)(ii) of this section, for purposes of commencing the six-month period for carrier implementation specified in paragraphs (d), (f) and (g) of this section, a PSAP will be deemed capable of receiving and using the data elements associated with the service requested, if it can demonstrate that it has:

(A) Ordered the necessary equipment and has commitments from suppliers to have it installed and operational within such six-month period; and

(B) Made a timely request to the appropriate local exchange carrier for the necessary trunking, upgrades, and other facilities.

(ii) For purposes of commencing the six-month period for carrier implementation specified in paragraphs (f) and (g) of this section, a PSAP that is Phase I-capable using a Non-Call Path Associated Signaling (NCAS) technology will be deemed capable of receiving and using the data elements associated with Phase II service if it can demonstrate that it has made a timely request to the appropriate local exchange carrier for the ALI database upgrade necessary to receive the Phase II information.

(3) Tolling of six-month period. Where a wireless carrier has served a written request for documentation on the PSAP within 15 days of receiving the PSAP's request for Phase I or Phase II enhanced 911 service, and the PSAP fails to respond to such request within 15 days of such service, the six-month period for carrier implementation specified in paragraphs (d), (f), and (g) of this section will be tolled until the PSAP provides the carrier with such documentation.

(4) Carrier certification regarding PSAP readiness issues. At the end of the six-month period for carrier implementation specified in paragraphs (d), (f), and (g) of this section, a wireless carrier that believes that the PSAP is not capable of receiving and using the data elements associated with the service requested may file a certification with the Commission. Upon filing and service of such certification, the carrier may suspend further implementation efforts, except as provided in paragraph (m)(4)(x) of this section.

(i) As a prerequisite to filing such certification, no later than 21 days prior to such filing, the wireless carrier must notify the affected PSAP, in writing, of its intent to file such certification. Any response that the carrier receives from the PSAP must be included with the carrier's certification filing.

(ii) The certification process shall be subject to the procedural requirements set forth in §§ 1.45 and 1.47 of this chapter.

(iii) The certification must be in the form of an affidavit signed by a director or officer of the carrier, documenting:

(A) The basis for the carrier's determination that the PSAP will not be ready;

(B) Each of the specific steps the carrier has taken to provide the E911 service requested;

(C) The reasons why further implementation efforts cannot be made until the PSAP becomes capable of receiving and using the data elements associated with the E911 service requested; and

(D) The specific steps that remain to be completed by the wireless carrier and, to the extent known, the PSAP or other parties before the carrier can provide the E911 service requested.

(iv) All affidavits must be correct. The carrier must ensure that its affidavit is correct, and the certifying director or officer has the duty to personally determine that the affidavit is correct.

(v) A carrier may not engage in a practice of filing inadequate or incomplete certifications for the purpose of delaying its responsibilities.

(vi) To be eligible to make a certification, the wireless carrier must have completed all necessary steps toward E911 implementation that are not dependent on PSAP readiness.

(vii) A copy of the certification must be served on the PSAP in accordance with § 1.47 of this chapter. The PSAP may challenge in writing the accuracy of the carrier's certification and shall serve a copy of such challenge on the carrier. See §§ 1.45 and 1.47 and 1.720 through 1.740 of this chapter.

(viii) If a wireless carrier's certification is facially inadequate, the six-month implementation period specified in paragraphs (d), (f), and (g) of this section will not be suspended as provided for in paragraph (m)(4) of this section.

(ix) If a wireless carrier's certification is inaccurate, the wireless carrier will be liable for noncompliance as if the certification had not been filed.

(x) A carrier that files a certification under this paragraph (m)(4) shall have 90 days from receipt of the PSAP's written notice that it is capable of receiving and using the data elements associated with the service requested to provide such service in accordance with the requirements of paragraphs (d) through (h) of this section.

(5) Modification of deadlines by agreement. Nothing in this section shall prevent Public Safety Answering Points and carriers from establishing, by mutual consent, deadlines different from those imposed for carrier and PSAP compliance in paragraphs (d), (f), and (g)(2) of this section.

(n) Dispatch service. A service provider covered by this section who offers dispatch service to customers may meet the requirements of this section with respect to customers who use dispatch service either by complying with the requirements set forth in paragraphs (b) through (e) of this section, or by routing the customer's emergency calls through a dispatcher. If the service provider chooses the latter alternative, it must make every reasonable effort to explicitly notify its current and potential dispatch customers and their users that they are not able to directly reach a PSAP by calling 911 and that, in the event of an emergency, the dispatcher should be contacted.

(o) Non-service-initialized handsets. (1) Licensees subject to this section that donate a non-service-initialized handset for purposes of providing access to 911 services are required to:

(i) Program each handset with 911 plus the decimal representation of the seven least significant digits of the Electronic Serial Number, International Mobile Equipment Identifier, or any other identifier unique to that handset;

(ii) Affix to each handset a label which is designed to withstand the length of service expected for a non-service-initialized phone, and which notifies the user that the handset can only be used to dial 911, that the 911 operator will not be able to call the user back, and that the user should convey the exact location of the emergency as soon as possible; and

(iii) Institute a public education program to provide the users of such handsets with information regarding the limitations of non-service-initialized handsets.

(2) Manufacturers of 911-only handsets that are manufactured on or after May 3, 2004, are required to:

(i) Program each handset with 911 plus the decimal representation of the seven least significant digits of the Electronic Serial Number, International Mobile Equipment Identifier, or any other identifier unique to that handset;

(ii) Affix to each handset a label which is designed to withstand the length of service expected for a non-service-initialized phone, and which notifies the user that the handset can only be used to dial 911, that the 911 operator will not be able to call the user back, and that the user should convey the exact location of the emergency as soon as possible; and

(iii) Institute a public education program to provide the users of such handsets with information regarding the limitations of 911-only handsets.

(3) The following definitions apply for purposes of this paragraph.

(i) Non-service-initialized handset. A handset for which there is no valid service contract with a provider of the services enumerated in paragraph (a) of this section.

(ii) 911-only handset. A non-service-initialized handset that is manufactured with the capability of dialing 911 only and that cannot receive incoming calls.

(p) Reseller obligation. (1) Beginning December 31, 2006, resellers have an obligation, independent of the underlying licensee, to provide access to basic and enhanced 911 service to the extent that the underlying licensee of the facilities the reseller uses to provide access to the public switched network complies with § 9.10(d) through (g).

(2) Resellers have an independent obligation to ensure that all handsets or other devices offered to their customers for voice communications and sold after December 31, 2006 are capable of transmitting enhanced 911 information to the appropriate PSAP, in accordance with the accuracy requirements of § 9.10(i).

(q) Text-to-911 requirements—(1) Covered text provider. Notwithstanding any other provisions in this section, for purposes of this paragraph (q) of this section, a “covered text provider” includes all CMRS providers as well as all providers of interconnected text messaging services that enable consumers to send text messages to and receive text messages from all or substantially all text-capable U.S. telephone numbers, including through the use of applications downloaded or otherwise installed on mobile phones.

(2) Automatic bounce-back message. An automatic text message delivered to a consumer by a covered text provider in response to the consumer's attempt to send a text message to 911 when the consumer is located in an area where text-to-911 service is unavailable or the covered text provider does not support text-to-911 service generally or in the area where the consumer is located at the time.

(3) Provision of automatic bounce-back messages. No later than September 30, 2013, all covered text providers shall provide an automatic bounce-back message under the following circumstances:

(i) A consumer attempts to send a text message to a Public Safety Answering Point (PSAP) by means of the three-digit short code “911”; and

(ii) The covered text provider cannot deliver the text because the consumer is located in an area where:

(A) Text-to-911 service is unavailable; or

(B) The covered text provider does not support text-to-911 service at the time.

(4) Automatic bounce-back message exceptions. (i) A covered text provider is not required to provide an automatic bounce-back message when:

(A) Transmission of the text message is not controlled by the provider;

(B) A consumer is attempting to text 911, through a text messaging application that requires CMRS service, from a non-service initialized handset;

(C) When the text-to-911 message cannot be delivered to a PSAP due to failure in the PSAP network that has not been reported to the provider; or

(D) A consumer is attempting to text 911 through a device that is incapable of sending texts via three digit short codes, provided the software for the device cannot be upgraded over the air to allow text-to-911.

(ii) The provider of a preinstalled or downloadable interconnected text application is considered to have “control” over transmission of text messages for purposes of paragraph (q)(4)(i)(A) of this section. However, if a user or a third party modifies or manipulates the application after it is installed or downloaded so that it no longer supports bounce-back messaging, the application provider will be presumed not to have control.

(5) Automatic bounce-back message minimum requirements. The automatic bounce-back message shall, at a minimum, inform the consumer that text-to-911 service is not available and advise the consumer or texting program user to use another means to contact emergency services.

(6) Temporary suspension of text-to-911 service. Covered text providers that support text-to-911 must provide a mechanism to allow PSAPs that accept text-to-911 to request temporary suspension of text-to-911 service for any reason, including, but not limited to, network congestion, call taker overload, PSAP failure, or security breach, and to request resumption of text-to-911 service after such temporary suspension. During any period of suspension of text-to-911 service, the covered text provider must provide an automatic bounce-back message to any consumer attempting to text to 911 in the area subject to the temporary suspension.

(7) Roaming. Notwithstanding any other provisions in this section, when a consumer is roaming on a covered text provider's host network pursuant to § 20.12, the covered text provider operating the consumer's home network shall have the obligation to originate an automatic bounce-back message to such consumer when the consumer is located in an area where text-to-911 service is unavailable, or the home provider does not support text-to-911 service in that area at the time. The host provider shall not impede the consumer's 911 text message to the home provider and/or any automatic bounce-back message originated by the home provider to the consumer roaming on the host network.

(8) Software application provider. A software application provider that transmits text messages directly into the SMS network of the consumer's underlying CMRS provider satisfies the obligations of paragraph (q)(3) of this section provided it does not prevent or inhibit delivery of the CMRS provider's automatic bounce-back message to the consumer.

(9) 911 text message. A 911 text message is a message, consisting of text characters, sent to the short code “911” and intended to be delivered to a PSAP by a covered text provider, regardless of the text messaging platform used.

(10) Delivery of 911 text messages. (i) No later than December 31, 2014, all covered text providers must have the capability to route a 911 text message to a PSAP. In complying with this requirement, covered text providers must obtain location information sufficient to route text messages to the same PSAP to which a 911 voice call would be routed, unless the responsible local or state entity designates a different PSAP to receive 911 text messages and informs the covered text provider of that change. All covered text providers using device-based location information that requires consumer activation must clearly inform consumers that they must grant permission for the text messaging application to access the wireless device's location information in order to enable text-to-911. If a consumer does not permit this access, the covered text provider's text application must provide an automated bounce-back message as set forth in paragraph (q)(3) of this section.

(ii) Covered text providers must begin routing all 911 text messages to a PSAP by June 30, 2015, or within six months of the PSAP's valid request for text-to-911 service, whichever is later, unless an alternate timeframe is agreed to by both the PSAP and the covered text provider. The covered text provider must notify the Commission of the dates and terms of the alternate timeframe within 30 days of the parties' agreement.

(iii) Valid Request means that:

(A) The requesting PSAP is, and certifies that it is, technically ready to receive 911 text messages in the format requested;

(B) The appropriate local or state 911 service governing authority has specifically authorized the PSAP to accept and, by extension, the covered text provider to provide, text-to-911 service; and

(C) The requesting PSAP has provided notification to the covered text provider that it meets the foregoing requirements. Registration by the PSAP in a database made available by the Commission in accordance with requirements established in connection therewith, or any other written notification reasonably acceptable to the covered text provider, shall constitute sufficient notification for purposes of this paragraph.

(iv) The requirements set forth in paragraphs (q)(10)(i) through (iii) of this section do not apply to in-flight text messaging providers, MSS providers, or IP Relay service providers, or to 911 text messages that originate from Wi-Fi only locations or that are transmitted from devices that cannot access the CMRS network.

(v) No later than January 6, 2022, covered text providers must provide the following location information with all 911 text messages routed to a PSAP: Automated dispatchable location, if technically feasible; otherwise, either end-user manual provision of location information, or enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost.

(11) Access to SMS networks for 911 text messages. To the extent that CMRS providers offer Short Message Service (SMS), they shall allow access by any other covered text provider to the capabilities necessary for transmission of 911 text messages originating on such other covered text providers' application services. Covered text providers using the CMRS network to deliver 911 text messages must clearly inform consumers that, absent an SMS plan with the consumer's underlying CMRS provider, the covered text provider may be unable to deliver 911 text messages. CMRS providers may migrate to other technologies and need not retain SMS networks solely for other covered text providers' 911 use, but must notify the affected covered text providers not less than 90 days before the migration is to occur.

(r) Contraband Interdiction System (CIS) requirement. CIS providers regulated as private mobile radio service (see § 9.3) must transmit all wireless 911 calls without respect to their call validation process to a Public Safety Answering Point, or, where no Public Safety Answering Point has been designated, to a designated statewide default answering point or appropriate local emergency authority pursuant to § 9.4, provided that “all wireless 911 calls” is defined as “any call initiated by a wireless user dialing 911 on a phone using a compliant radio frequency protocol of the serving carrier.” This requirement shall not apply if the Public Safety Answering Point or emergency authority informs the CIS provider that it does not wish to receive 911 calls from the CIS provider.

(s) Compliance date. Paragraph (q)(10)(v) of this section contains information-collection and recordkeeping requirements. Compliance will not be required until after approval by the Office of Management and Budget. The Commission will publish a document in the Federal Register announcing that compliance date and revising this paragraph accordingly.

Subpart D—Interconnected Voice over Internet Protocol Services

§ 9.11

E911 Service.

(a) Before January 6, 2021, for fixed services and before January 6, 2022, for non-fixed services.—(1) Scope. The following requirements of paragraphs (a)(1) through (5) of this section are only applicable to providers of interconnected VoIP services, except those interconnected VoIP services that fulfill each paragraphs (1)(i) through (iii) of the definition of interconnected VoIP service in § 9.3, and also permit users generally to terminate calls to the public switched telephone network. Further, the following requirements apply only to 911 calls placed by users whose Registered Location is in a geographic area served by a Wireline E911 Network (which, as defined in § 9.3, includes a selective router).

(2) E911 Service. As of November 28, 2005:

(i) Interconnected VoIP service providers must, as a condition of providing service to a consumer, provide that consumer with E911 service as described in this section;

(ii) Interconnected VoIP service providers must transmit all 911 calls, as well as ANI and the caller's Registered Location for each call, to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's Registered Location and that has been designated for telecommunications carriers pursuant to § 9.4, provided that “all 911 calls” is defined as “any voice communication initiated by an interconnected VoIP user dialing 911;”

(iii) All 911 calls must be routed through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network; and

(iv) The Registered Location must be available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.

(3) Service Level Obligation. Notwithstanding the provisions in paragraph (a)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, an interconnected VoIP service provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (a)(2)(iii) of this section of an interconnected VoIP service provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's Registered Location and that has been designated for telecommunications carriers pursuant to § 9.4.

(4) Registered Location requirement. As of November 28, 2005, interconnected VoIP service providers must:

(i) Obtain from each customer, prior to the initiation of service, the physical location at which the service will first be used; and

(ii) Provide their end users one or more methods of updating their Registered Location, including at least one option that requires use only of the CPE necessary to access the interconnected VoIP service. Any method used must allow an end user to update the Registered Location at will and in a timely manner.

(5) Customer notification. Each interconnected VoIP service provider shall:

(i) Specifically advise every subscriber, both new and existing, prominently and in plain language, of the circumstances under which E911 service may not be available through the interconnected VoIP service or may be in some way limited by comparison to traditional E911 service. Such circumstances include, but are not limited to, relocation of the end user's IP-compatible CPE, use by the end user of a non-native telephone number, broadband connection failure, loss of electrical power, and delays that may occur in making a Registered Location available in or through the ALI database;

(ii) Obtain and keep a record of affirmative acknowledgement by every subscriber, both new and existing, of having received and understood the advisory described in paragraph (a)(5)(i) of this section; and

(iii) Either—

(A) Distribute to its existing subscribers, and to each new subscriber prior to the initiation of that subscriber's service, warning stickers or other appropriate labels warning subscribers if E911 service may be limited or not available and instructing the subscriber to place them on or near the equipment used in conjunction with the interconnected VoIP service; or

(B) Notify existing subscribers, and each new subscriber prior to the initiation of that subscriber's service, by other conspicuous means if E911 service may be limited or not available.

(b) On or after January 6, 2021, for fixed services, and on or after January 6, 2022, for non-fixed services—(1) Scope. The following requirements of paragraphs (b)(1) through (5) of this section are only applicable to all providers of interconnected VoIP services. Further, these requirements apply only to 911 calls placed by users whose dispatchable location is in a geographic area served by a Wireline E911 Network (which, as defined in § 9.3, includes a selective router).

(2) E911 Service—(i) Interconnected VoIP service providers must, as a condition of providing service to a consumer, provide that consumer with E911 service as described in this section;

(ii) Interconnected VoIP service providers must transmit the following to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's dispatchable location and that has been designated for telecommunications carriers pursuant to § 9.4:

(A) All 911 calls, provided that “all 911 calls” is defined as “any voice communication initiated by an interconnected VoIP user dialing 911;”

(B) ANI; and

(C) The location information described in paragraph (b)(4) of this section.

(iii) All 911 calls must be routed through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network, provided that nothing in this subparagraph shall preclude routing the call first to a national emergency call center to ascertain the caller's location in the event that the interconnected VoIP service provider is unable to obtain or confirm the caller's location information; and

(iv) The location information described in paragraph (b)(4) of this section must be available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.

(3) Service level obligation. Notwithstanding the provisions in paragraph (b)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, an interconnected VoIP service provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (b)(2)(iii) of this section of an interconnected VoIP service provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's dispatchable location and that has been designated for telecommunications carriers pursuant to § 9.4.

(4) Location requirements. To meet E911 service requirements, interconnected VoIP service providers must provide location information with each 911 call as follows:

(i) Fixed interconnected VoIP services. Providers of fixed interconnected VoIP services must provide automated dispatchable location with each 911 call.

(ii) Non-fixed interconnected VoIP services. For non-fixed interconnected VoIP service (service that is capable of being used from more than one location), interconnected VoIP service providers must provide location information in accordance with paragraph (b)(4)(ii)(A) of this section, if technically feasible. Otherwise, interconnected VoIP service providers must either provide location information in accordance with paragraph (b)(4)(ii)(B) or (C), or meet paragraph (b)(4)(ii)(D) of this section.

(A) Provide automated dispatchable location, if technically feasible.

(B) Provide Registered Location information that meets the following requirements:

(1) The service provider has obtained from the customer, prior to the initiation of service, the Registered Location (as defined in § 9.3) at which the service will first be used;

(2) The service provider has provided end users one or more methods of updating their Registered Location, including at least one option that requires use only of the CPE necessary to access the interconnected VoIP service. Any method used must allow an end user to update the Registered Location at will and in a timely manner; and

(3) The service provider must identify whether the service is being used to call 911 from a different location than the Registered Location, and if so, either:

(i) Prompt the customer to provide a new Registered Location; or

(ii) Update the Registered Location without requiring additional action by the customer.

(C) Provide Alternative Location Information as defined in § 9.3.

(D) Route the caller to a national emergency call center.

(5) Customer notification. (i) Each interconnected VoIP service provider shall specifically advise every subscriber, both new and existing, prominently and in plain language, of the circumstances under which E911 service may not be available through the interconnected VoIP service or may be in some way limited by comparison to traditional E911 service. Such circumstances include, but are not limited to, relocation of the end user's IP-compatible CPE, use by the end user of a non-native telephone number, broadband connection failure, loss of electrical power, and delays that may occur in making a dispatchable location available in or through the ALI database;

(ii) Each interconnected VoIP service provider shall obtain and keep a record of affirmative acknowledgement by every subscriber, both new and existing, of having received and understood the advisory described in paragraph (b)(5)(i) of this section; and

(iii) Each interconnected VoIP service provider shall either:

(A) Distribute to its existing subscribers, and to each new subscriber prior to the initiation of that subscriber's service, warning stickers or labels warning subscribers if E911 service may be limited or not available, and instructing the subscriber to place them on or near the equipment used in conjunction with the interconnected VoIP service; or

(B) Notify existing subscribers, and each new subscriber prior to the initiation of that subscriber's service, by other conspicuous means if E911 service may be limited or not available.

(c) Paragraphs (b)(2)(ii) and (iv), (b)(4), and (b)(5)(ii) and (iii) of this section contain information-collection and recordkeeping requirements. Compliance will not be required until after approval by the Office of Management and Budget. The Commission will publish a document in the Federal Register announcing that compliance date and revising this paragraph accordingly.

§ 9.12

Access to 911 and E911 service capabilities.

(a) Access. Subject to the other requirements of this part, an owner or controller of a capability that can be used for 911 or E911 service shall make that capability available to a requesting interconnected VoIP provider as set forth in paragraphs (a)(1) and (2) of this section.

(1) If the owner or controller makes the requested capability available to a CMRS provider, the owner or controller must make that capability available to the interconnected VoIP provider. An owner or controller makes a capability available to a CMRS provider if the owner or controller offers that capability to any CMRS provider.

(2) If the owner or controller does not make the requested capability available to a CMRS provider within the meaning of paragraph (a)(1) of this section, the owner or controller must make that capability available to a requesting interconnected VoIP provider only if that capability is necessary to enable the interconnected VoIP provider to provide 911 or E911 service in compliance with the Commission's rules.

(b) Rates, terms, and conditions. The rates, terms, and conditions on which a capability is provided to an interconnected VoIP provider under paragraph (a) of this section shall be reasonable. For purposes of this paragraph, it is evidence that rates, terms, and conditions are reasonable if they are:

(1) The same as the rates, terms, and conditions that are made available to CMRS providers, or

(2) In the event such capability is not made available to CMRS providers, the same rates, terms, and conditions that are made available to any telecommunications carrier or other entity for the provision of 911 or E911 service.

(c) Permissible use. An interconnected VoIP provider that obtains access to a capability pursuant to this section may use that capability only for the purpose of providing 911 or E911 service in accordance with the Commission's rules.

Subpart E—Telecommunications Relay Services for Persons with Disabilities

§ 9.13

Jurisdiction.

Any violation of this subpart E by any common carrier engaged in intrastate communication shall be subject to the same remedies, penalties, and procedures as are applicable to a violation of the Act by a common carrier engaged in interstate communication. For purposes of this subpart, all regulations and requirements applicable to common carriers shall also be applicable to providers of interconnected VoIP service as defined in § 9.3.

§ 9.14

Emergency calling requirements.

(a) Emergency call handling requirements for TTY-based TRS providers. TTY-based TRS providers must use a system for incoming emergency calls that, at a minimum, automatically and immediately transfers the caller to an appropriate Public Safety Answering Point (PSAP). An appropriate PSAP is either a PSAP that the caller would have reached if the caller had dialed 911 directly, or a PSAP that is capable of enabling the dispatch of emergency services to the caller in an expeditious manner.

(b) Additional emergency calling requirements applicable to internet-based TRS providers. (1) The requirements of paragraphs (b)(2)(i) and (iv) of this section shall not apply to providers of VRS and IP Relay to which § 9.14(c) and (d) apply.

(2) Each provider of internet-based TRS shall:

(i) When responsible for placing or routing voice calls to the public switched telephone network, accept and handle emergency calls and access, either directly or via a third party, a commercially available database that will allow the provider to determine an appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority that corresponds to the caller's location, and to relay the call to that entity;

(ii) Implement a system that ensures that the provider answers an incoming emergency call before other non-emergency calls (i.e., prioritize emergency calls and move them to the top of the queue);

(iii) Provide 911 and E911 service in accordance with paragraphs (c) through (e) of this section, as applicable;

(iv) Deliver to the PSAP, designated statewide default answering point, or appropriate local emergency authority, at the outset of the outbound leg of an emergency call, at a minimum, the name of the relay user and location of the emergency, as well as the name of the relay provider, the CA's callback number, and the CA's identification number, thereby enabling the PSAP, designated statewide default answering point, or appropriate local emergency authority to re-establish contact with the CA in the event the call is disconnected;

(v) In the event one or both legs of an emergency call are disconnected (i.e., either the call between the TRS user and the CA, or the outbound voice telephone call between the CA and the PSAP, designated statewide default answering point, or appropriate local emergency authority), immediately re-establish contact with the TRS user and/or the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority and resume handling the call; and

(vi) Ensure that information obtained as a result of this section is limited to that needed to facilitate 911 services, is made available only to emergency call handlers and emergency response or law enforcement personnel, and is used for the sole purpose of ascertaining a user's location in an emergency situation or for other emergency or law enforcement purposes.

(c) E911 Service for VRS and IP Relay before January 6, 2021, for fixed services, and before January 6, 2022, for non-fixed services—(1) Scope. The following requirements of paragraphs (c)(1) through (4) of this section are only applicable to providers of VRS or IP Relay. Further, these requirements apply only to 911 calls placed by registered users whose Registered Location is in a geographic area served by a Wireline E911 Network and is available to the provider handling the call.

(2) E911 Service. VRS or IP Relay providers must, as a condition of providing service to a user:

(i) Provide that user with E911 service as described in this section;

(ii) Request, at the beginning of each emergency call, the caller's name and location information, unless the VRS or IP Relay provider already has, or has access to, Registered Location information for the caller;

(iii) Transmit all 911 calls, as well as ANI, the caller's Registered Location, the name of the VRS or IP Relay provider, and the CA's identification number for each call, to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's Registered Location and that has been designated for telecommunications carriers pursuant to § 9.4, provided that “all 911 calls” is defined as “any communication initiated by an VRS or IP Relay user dialing 911”;

(iv) Route all 911 calls through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network, provided that nothing in this subparagraph shall preclude routing the call first to a call center to ascertain the caller's location in the event that the VRS or IP Relay provider believes the caller may not be located at the Registered Location; and

(v) Make the Registered Location, the name of the VRS or IP Relay provider, and the CA's identification number available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.

(3) Service level obligation. Notwithstanding the provisions in paragraph (c)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, a VRS or IP Relay provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (c)(2)(iv) of this section of a VRS or IP Relay provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's Registered Location and that has been designated for telecommunications carriers pursuant to § 9.4.

(4) Registered location requirement. VRS and IP Relay providers must:

(i) Obtain from each Registered internet-based TRS user, prior to the initiation of service, the physical location at which the service will first be used; and

(ii) If the VRS or IP Relay is capable of being used from more than one location, provide their registered internet-based TRS users one or more methods of updating the user's Registered Location, including at least one option that requires use only of the iTRS access technology necessary to access the VRS or IP Relay. Any method used must allow a registered internet-based TRS user to update the Registered Location at will and in a timely manner.

(d) E911 Service for VRS and IP Relay on or after January 6, 2021, for fixed services, and on or after January 6, 2022, for non-fixed services—(1) Scope. The following requirements of paragraphs (d)(1) through (4) of this section are only applicable to providers of VRS or IP Relay. Further, these requirements apply only to 911 calls placed by registered users whose dispatchable location is in a geographic area served by a Wireline E911 Network and is available to the provider handling the call.

(2) E911 Service. VRS or IP Relay providers must, as a condition of providing service to a user:

(i) Provide that user with E911 service as described in this section;

(ii) Request, at the beginning of each emergency call, the caller's name and dispatchable location, unless the VRS or IP relay provider already has, or has access to the location information described in paragraph (d)(4) of this section;

(iii) Transmit the following to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's dispatchable location and that has been designated for telecommunications carriers pursuant to § 9.4:

(A) All 911 calls, provided that “all 911 calls” is defined as “any communication initiated by an VRS or IP Relay user dialing 911;”

(B) ANI, the name of the VRS or IP Relay provider, and the CA's identification number for each call; and

(C) The location information described in paragraph (d)(4) of this section.

(iv) Route all 911 calls through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network, provided that nothing in this subparagraph shall preclude routing the call first to a call center to ascertain the caller's location in the event that the VRS or IP Relay provider is unable to obtain or confirm the caller's location information; and

(v) Make the location information described in paragraph (d)(4) of this section, the name of the VRS or IP Relay provider, and the CA's identification number available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.

(3) Service level obligation. Notwithstanding the provisions in paragraph (d)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, a VRS or IP Relay provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (d)(2)(iv) of this section of a VRS or IP Relay provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's dispatchable location and that has been designated for telecommunications carriers pursuant to § 9.4.

(4) Location requirements. To meet E911 service requirements, VRS and IP Relay providers must provide location information with each 911 call as follows:

(i) Fixed VRS and IP Relay services. Providers of fixed VRS and IP Relay services must provide automated dispatchable location with each 911 call.

(ii) Non-fixed VRS and IP Relay services. For non-fixed VRS and IP Relay services (service that is capable of being used from more than one location), VRS and IP Relay service providers must provide location information in accordance with paragraph (d)(4)(ii)(A) of this section, if technically feasible. Otherwise, VRS and IP Relay service providers must either provide location information in accordance with paragraph (d)(4)(ii)(B) or (C), or meet paragraph (d)(4)(ii)(D) of this section.

(A) Provide automated dispatchable location, if technically feasible.

(B) Provide Registered Location information that meets the following requirements:

(1) The service provider has obtained from the customer, prior to the initiation of service, the Registered Location (as defined in § 9.3) at which the service will first be used;

(2) The service provider has provided end users one or more methods of updating their Registered Location, including at least one option that requires use only of the internet-based TRS access technology necessary to access the VRS or IP Relay. Any method used must allow an end user to update the Registered Location at will and in a timely manner; and

(3) If the VRS or IP Relay is capable of being used from more than one location, if it is not possible to automatically determine the Registered internet-based TRS user's location at the time of the initiation of an emergency call, verify the current location with the user at the beginning of an emergency call.

(C) Provide Alternative Location Information as defined in § 9.3.

(D) Route the caller to a call center.

(e) E911 Service for IP CTS on or after January 6, 2021, for fixed services, and on or after January 6, 2022, for non-fixed services—(1) Scope. The following requirements of paragraphs (e)(1) through (4) of this section are only applicable to “covered IP CTS providers,” who are providers of IP CTS to the extent that the IP CTS provider, itself or through an entity with whom the IP CTS provider contracts, places or routes voice calls to the public switched telephone network. Further, these requirements apply only to 911 calls placed by a registered user whose dispatchable location is in a geographic area served by a Wireline E911 Network and is available to the provider handling the call.

(2) E911 Service. Covered IP CTS providers must, as a condition of providing service to a user:

(i) Provide that user with E911 service as described in this section;

(ii) Transmit or provide the following to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's dispatchable location and that has been designated for telecommunications carriers pursuant to § 9.4:

(A) All 911 calls, provided that “all 911 calls” is defined as “any communication initiated by an IP CTS user dialing 911;”

(B) With the call, a telephone number that is assigned to the caller and that enables the PSAP, designated statewide default answering point, or appropriate local emergency authority to call the 911 caller back directly, while enabling the caller to receive captions on the callback; and

(C) The location information described in paragraph (e)(4) of this section.

(iii) Route all 911 calls through the use of ANI and, if necessary, pseudo-ANI, via the dedicated Wireline E911 Network, provided that nothing in this subparagraph shall preclude routing the call first to a call center to ascertain the caller's location in the event that the covered IP CTS provider is unable to obtain or confirm the caller's location information; and

(iv) Make the location information described in paragraph (e)(4) of this section and callback number available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through the appropriate automatic location information (ALI) database.

(3) Service level obligation. Notwithstanding the provisions in paragraph (e)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, a covered IP CTS provider need not provide such ANI or location information; however, nothing in this paragraph affects the obligation under paragraph (e)(2)(iii) of this section of a covered IP CTS provider to transmit via the Wireline E911 Network all 911 calls to the PSAP, designated statewide default answering point, or appropriate local emergency authority that serves the caller's dispatchable location and that has been designated for telecommunications carriers pursuant to § 9.4.

(4) Location requirements. To meet E911 service requirements, covered IP CTS providers must provide location information with each 911 call as follows:

(i) Fixed IP CTS. Providers of fixed IP CTS must provide automated dispatchable location with each 911 call.

(ii) Non-fixed IP CTS. For non-fixed IP CTS (service that is capable of being used from more than one location), covered IP CTS providers must provide location information in accordance with paragraph (e)(4)(ii)(A) of this section, if technically feasible. Otherwise, covered IP CTS providers must either provide location information in accordance with paragraph (e)(4)(ii)(B) or (C), or meet paragraph (e)(4)(iii)(D) of this section.

(A) Provide automated dispatchable location, if technically feasible.

(B) Provide Registered Location information that meets the following requirements:

(1) The service provider has obtained from the customer, prior to the initiation of service, the Registered Location (as defined in § 9.3) at which the service will first be used; and

(2) The service provider has provided end users one or more methods of updating their Registered Location, including at least one option that requires use only of the internet-based TRS access technology necessary to access the IP CTS. Any method used must allow an end user to update the Registered Location at will and in a timely manner.

(C) Provide Alternative Location Information as defined in § 9.3.

(D) Route the caller to a call center.

(f) Paragraphs (d)(2)(ii), (iii), and (v), (d)(4), (e)(2)(ii) and (iv), and (e)(4) of this section contain information-collection and recordkeeping requirements. Compliance will not be required until after approval by the Office of Management and Budget. The Commission will publish a document in the Federal Register announcing that compliance date and revising this paragraph accordingly.

Subpart F—Multi-Line Telephone Systems

§ 9.15

Applicability.

The rules in this subpart F apply to:

(a) A person engaged in the business of manufacturing, importing, selling, or leasing multi-line telephone systems;

(b) A person engaged in the business of installing, managing, or operating multi-line telephone systems;

(c) Any multi-line telephone system that is manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020.

§ 9.16

General obligations—direct 911 dialing, notification, and dispatchable location.

(a) Obligation of manufacturers, importers, sellers, and lessors. (1) A person engaged in the business of manufacturing, importing, selling, or leasing multi-line telephone systems may not manufacture or import for use in the United States, or sell or lease or offer to sell or lease in the United States, a multi-line telephone system, unless such system is pre-configured such that, when properly installed in accordance with paragraph (b) of this section, a user may directly initiate a call to 911 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9, regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls.

(2) A person engaged in the business of manufacturing, importing, selling, or leasing multi-line telephone systems may not manufacture or import for use in the United States, or sell or lease or offer to sell or lease in the United States, a multi-line telephone system, unless such system has the capability, after proper installation in accordance with paragraph (b) of this section, of providing the dispatchable location of the caller to the PSAP with 911 calls.

(b) Obligation of installers, managers, or operators. (1) A person engaged in the business of installing, managing, or operating multi-line telephone systems may not install, manage, or operate for use in the United States such a system, unless such system is configured such that a user may directly initiate a call to 911 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9, regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls.

(2) A person engaged in the business of installing, managing, or operating multi-line telephone systems shall, in installing, managing, or operating such a system for use in the United States, configure the system to provide MLTS notification to a central location at the facility where the system is installed or to another person or organization regardless of location, if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system. MLTS notification must meet the following requirements:

(i) MLTS notification must be initiated contemporaneously with the 911 call, provided that it is technically feasible to do so;

(ii) MLTS notification must not delay the call to 911; and

(iii) MLTS notification must be sent to a location where someone is likely to see or hear it.

(3) A person engaged in the business of installing multi-line telephone systems may not install such a system in the United States unless it is configured such that it is capable of being programmed with and conveying the dispatchable location of the caller to the PSAP with 911 calls consistent with paragraphs (i), (ii) and (iii) of this section. A person engaged in the business of managing or operating multi-line telephone systems may not manage or operate such a system in the United States unless it is configured such that the dispatchable location of the caller is conveyed to the PSAP with 911 calls consistent with paragraphs (i), (ii) and (iii) of this section.

(i) Dispatchable location requirements for on-premises fixed telephones associated with a multi-line telephone system. An on-premises fixed telephone associated with a multi-line telephone system shall provide automated dispatchable location no later than January 6, 2021;

(ii) Dispatchable location requirements for on-premises non-fixed devices associated with a multi-line telephone system. No later than January 6, 2022, an on-premises non-fixed device associated with a multi-line telephone system shall provide to the appropriate PSAP automated dispatchable location, when technically feasible; otherwise, it shall provide dispatchable location based on end user manual update, or alternative location information as defined in § 9.3.

(iii) Dispatchable location requirements for off-premises devices associated with a multi-line telephone system. No later than January 6, 2022, an off-premises device associated with a multi-line telephone system shall provide to the appropriate PSAP automatic dispatchable location, if technically feasible; otherwise, it shall provide dispatchable location based on end user manual update, or enhanced location information, which may be coordinate-based, consisting of the best available location that can be obtained from any available technology or combination of technologies at reasonable cost.

(c) Compliance date. Paragraphs (b)(3)(i) through (iii) of this section contain information-collection and recordkeeping requirements. Compliance will not be required until after approval by the Office of Management and Budget. The Commission will publish a document in the Federal Register announcing that compliance date and revising this paragraph accordingly.

§ 9.17

Enforcement, compliance date, State law.

(a) Enforcement. (1) Sections 9.16(a)(1) and (b)(1) and (2) shall be enforced under title V of the Communications Act of 1934, as amended, 5 U.S.C. 501 et seq., except that section 501 applies only to the extent that such section provides for the punishment of a fine.

(2) In the event of noncompliance with § 9.16(b), the person engaged in the business of managing the multi-line telephone system shall be presumed to be responsible for the noncompliance.

(3) Persons alleging a violation of the rules in § 9.16 may file a complaint under the procedures set forth in §§ 1.711 through 1.737 of this chapter.

(b) Compliance date. The compliance date for this subpart F is February 16, 2020, unless otherwise noted. Accordingly, the requirements in this subpart apply to a multi-line telephone system that is manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020, unless otherwise noted.

(c) Effect on State law. Nothing in § 9.16(a)(1) and (b)(1) and (2) is intended to alter the authority of State commissions or other State or local agencies with jurisdiction over emergency communications, if the exercise of such authority is not inconsistent with this subpart.

Subpart G—Mobile-Satellite Service

§ 9.18

Emergency Call Center service.

(a) Providers of Mobile-Satellite Service to end-user customers (47 CFR part 25, subparts A through D) must provide Emergency Call Center service to the extent that they offer real-time, two way switched voice service that is interconnected with the public switched network and use an in-network switching facility which enables the provider to reuse frequencies and/or accomplish seamless hand-offs of subscriber calls. Emergency Call Center personnel must determine the emergency caller's phone number and location and then transfer or otherwise redirect the call to an appropriate public safety answering point. Providers of Mobile-Satellite Services that use earth terminals that are not capable of use while in motion are exempt from providing Emergency Call Center service for such terminals.

(b) Each Mobile-Satellite Service carrier that is subject to the provisions of paragraph (a) of this section must maintain records of all 911 calls received at its emergency call center. By October 15, of each year, Mobile-Satellite Service carriers providing service in the 1.6/2.4 GHz and 2 GHz bands must submit a report to the Commission regarding their call center data, current as of September 30 of that year. By June 30, of each year, Mobile-Satellite Service carriers providing service in bands other than 1.6/2.4 GHz and 2 GHz must submit a report to the Commission regarding their call center data, current as of May 31 of that year. These reports must include, at a minimum, the following:

(1) The name and address of the carrier, the address of the carrier's emergency call center, and emergency call center contact information;

(2) The aggregate number of calls received by the call center each month during the relevant reporting period;

(3) An indication of how many calls received by the call center each month during the relevant reporting period required forwarding to a public safety answering point and how many did not require forwarding to a public safety answering point.

Subpart H—Resiliency, Redundancy, and Reliability of 911 Communications

§ 9.19

Reliability of covered 911 service providers.

(a) Definitions. Terms in this section shall have the following meanings:

(1) Aggregation point. A point at which network monitoring data for a 911 service area is collected and routed to a network operations center (NOC) or other location for monitoring and analyzing network status and performance.

(2) Certification. An attestation by a certifying official, under penalty of perjury, that a covered 911 service provider:

(i) Has satisfied the obligations of paragraph (c) of this section.

(ii) Has adequate internal controls to bring material information regarding network architecture, operations, and maintenance to the certifying official's attention.

(iii) Has made the certifying official aware of all material information reasonably necessary to complete the certification.

(iv) The term “certification” shall include both an annual reliability certification under paragraph (c) of this section and an initial reliability certification under paragraph (d)(1) of this section, to the extent provided under paragraph (d)(1).

(3) Certifying official. A corporate officer of a covered 911 service provider with supervisory and budgetary authority over network operations in all relevant service areas.

(4) Covered 911 service provider. (i) Any entity that:

(A) Provides 911, E911, or NG911 capabilities such as call routing, automatic location information (ALI), automatic number identification (ANI), or the functional equivalent of those capabilities, directly to a public safety answering point (PSAP), statewide default answering point, or appropriate local emergency authority as defined in § 9.3; and/or

(B) Operates one or more central offices that directly serve a PSAP. For purposes of this section, a central office directly serves a PSAP if it hosts a selective router or ALI/ANI database, provides equivalent NG911 capabilities, or is the last service-provider facility through which a 911 trunk or administrative line passes before connecting to a PSAP.

(ii) The term “covered 911 service provider” shall not include any entity that:

(A) Constitutes a PSAP or governmental authority to the extent that it provides 911 capabilities; or

(B) Offers the capability to originate 911 calls where another service provider delivers those calls and associated number or location information to the appropriate PSAP.

(5) Critical 911 circuits. 911 facilities that originate at a selective router or its functional equivalent and terminate in the central office that serves the PSAP(s) to which the selective router or its functional equivalent delivers 911 calls, including all equipment in the serving central office necessary for the delivery of 911 calls to the PSAP(s). Critical 911 circuits also include ALI and ANI facilities that originate at the ALI or ANI database and terminate in the central office that serves the PSAP(s) to which the ALI or ANI databases deliver 911 caller information, including all equipment in the serving central office necessary for the delivery of such information to the PSAP(s).

(6) Diversity audit. A periodic analysis of the geographic routing of network components to determine whether they are physically diverse. Diversity audits may be performed through manual or automated means, or through a review of paper or electronic records, as long as they reflect whether critical 911 circuits are physically diverse.

(7) Monitoring links. Facilities that collect and transmit network monitoring data to a NOC or other location for monitoring and analyzing network status and performance.

(8) Physically diverse. Circuits or equivalent data paths are Physically Diverse if they provide more than one physical route between end points with no common points where a single failure at that point would cause both circuits to fail. Circuits that share a common segment such as a fiber-optic cable or circuit board are not Physically diverse even if they are logically diverse for purposes of transmitting data.

(9) 911 service area. The metropolitan area or geographic region in which a covered 911 service provider operates a selective router or the functional equivalent to route 911 calls to the geographically appropriate PSAP.

(10) Selective router. A 911 network component that selects the appropriate destination PSAP for each 911 call based on the location of the caller.

(11) Tagging. An inventory management process whereby critical 911 circuits are labeled in circuit inventory databases to make it less likely that circuit rearrangements will compromise diversity. A covered 911 service provider may use any system it wishes to tag circuits so long as it tracks whether critical 911 circuits are physically diverse and identifies changes that would compromise such diversity.

(b) Provision of reliable 911 service. All covered 911 service providers shall take reasonable measures to provide reliable 911 service with respect to circuit diversity, central-office backup power, and diverse network monitoring. Performance of the elements of the certification set forth in paragraphs (c)(1)(i), (c)(2)(i), and (c)(3)(i) of this section shall be deemed to satisfy the requirements of this paragraph. If a covered 911 service provider cannot certify that it has performed a given element, the Commission may determine that such provider nevertheless satisfies the requirements of this paragraph based upon a showing in accordance with paragraph (c) of this section that it is taking alternative measures with respect to that element that are reasonably sufficient to mitigate the risk of failure, or that one or more certification elements are not applicable to its network.

(c) Annual reliability certification. One year after the initial reliability certification described in paragraph (d)(1) of this section and every year thereafter, a certifying official of every covered 911 service provider shall submit a certification to the Commission as follows.

(1) Circuit auditing. (i) A covered 911 service provider shall certify whether it has, within the past year:

(A) Conducted diversity audits of critical 911 circuits or equivalent data paths to any PSAP served;

(B) Tagged such critical 911 circuits to reduce the probability of inadvertent loss of diversity in the period between audits; and

(C) Eliminated all single points of failure in critical 911 circuits or equivalent data paths serving each PSAP.

(ii) If a Covered 911 Service Provider does not conform with all of the elements in paragraph (c)(1)(i) of this section with respect to the 911 service provided to one or more PSAPs, it must certify with respect to each such PSAP:

(A) Whether it has taken alternative measures to mitigate the risk of critical 911 circuits that are not physically diverse or is taking steps to remediate any issues that it has identified with respect to 911 service to the PSAP, in which case it shall provide a brief explanation of such alternative measures or such remediation steps, the date by which it anticipates such remediation will be completed, and why it believes those measures are reasonably sufficient to mitigate such risk; or

(B) Whether it believes that one or more of the requirements of this paragraph are not applicable to its network, in which case it shall provide a brief explanation of why it believes any such requirement does not apply.

(2) Backup power. (i) With respect to any central office it operates that directly serves a PSAP, a covered 911 service provider shall certify whether it:

(A) Provisions backup power through fixed generators, portable generators, batteries, fuel cells, or a combination of these or other such sources to maintain full-service functionality, including network monitoring capabilities, for at least 24 hours at full office load or, if the central office hosts a selective router, at least 72 hours at full office load; provided, however, that any such portable generators shall be readily available within the time it takes the batteries to drain, notwithstanding potential demand for such generators elsewhere in the service provider's network.

(B) Tests and maintains all backup power equipment in such central offices in accordance with the manufacturer's specifications;

(C) Designs backup generators in such central offices for fully automatic operation and for ease of manual operation, when required;

(D) Designs, installs, and maintains each generator in any central office that is served by more than one backup generator as a stand-alone unit that does not depend on the operation of another generator for proper functioning.

(ii) If a covered 911 service provider does not conform with all of the elements in paragraph (c)(2)(i) of this section, it must certify with respect to each such central office:

(A) Whether it has taken alternative measures to mitigate the risk of a loss of service in that office due to a loss of power or is taking steps to remediate any issues that it has identified with respect to backup power in that office, in which case it shall provide a brief explanation of such alternative measures or such remediation steps, the date by which it anticipates such remediation will be completed, and why it believes those measures are reasonably sufficient to mitigate such risk; or

(B) Whether it believes that one or more of the requirements of this paragraph are not applicable to its network, in which case it shall provide a brief explanation of why it believes any such requirement does not apply.

(3) Network monitoring. (i) A covered 911 service provider shall certify whether it has, within the past year:

(A) Conducted diversity audits of the aggregation points that it uses to gather network monitoring data in each 911 service area;

(B) Conducted diversity audits of monitoring links between aggregation points and NOCs for each 911 service area in which it operates; and

(C) Implemented physically diverse aggregation points for network monitoring data in each 911 service area and physically diverse monitoring links from such aggregation points to at least one NOC.

(ii) If a Covered 911 Service Provider does not conform with all of the elements in paragraph (c)(3)(i) of this section, it must certify with respect to each such 911 Service Area:

(A) Whether it has taken alternative measures to mitigate the risk of network monitoring facilities that are not physically diverse or is taking steps to remediate any issues that it has identified with respect to diverse network monitoring in that 911 service area, in which case it shall provide a brief explanation of such alternative measures or such remediation steps, the date by which it anticipates such remediation will be completed, and why it believes those measures are reasonably sufficient to mitigate such risk; or

(B) Whether it believes that one or more of the requirements of this paragraph are not applicable to its network, in which case it shall provide a brief explanation of why it believes any such requirement does not apply.

(d) Other matters—(1) Initial reliability certification. One year after October 15, 2014, a certifying official of every covered 911 service provider shall certify to the Commission that it has made substantial progress toward meeting the standards of the annual reliability certification described in paragraph (c) of this section. Substantial progress in each element of the certification shall be defined as compliance with standards of the full certification in at least 50 percent of the covered 911 service provider's critical 911 circuits, central offices that directly serve PSAPs, and independently monitored 911 service areas.

(2) Confidential treatment. (i) The fact of filing or not filing an annual reliability certification or initial reliability certification and the responses on the face of such certification forms shall not be treated as confidential.

(ii) Information submitted with or in addition to such certifications shall be presumed confidential to the extent that it consists of descriptions and documentation of alternative measures to mitigate the risks of nonconformance with certification elements, information detailing specific corrective actions taken with respect to certification elements, or supplemental information requested by the Commission or Bureau with respect to a certification.

(3) Record retention. A covered 911 service provider shall retain records supporting the responses in a certification for two years from the date of such certification, and shall make such records available to the Commission upon request. To the extent that a covered 911 service provider maintains records in electronic format, records supporting a certification hereunder shall be maintained and supplied in an electronic format.

(i) With respect to diversity audits of critical 911 circuits, such records shall include, at a minimum, audit records separately addressing each such circuit, any internal report(s) generated as a result of such audits, records of actions taken pursuant to the audit results, and records regarding any alternative measures taken to mitigate the risk of critical 911 circuits that are not physically diverse.

(ii) With respect to backup power at central offices, such records shall include, at a minimum, records regarding the nature and extent of backup power at each central office that directly serves a PSAP, testing and maintenance records for backup power equipment in each such central office, and records regarding any alternative measures taken to mitigate the risk of insufficient backup power.

(iii) With respect to network monitoring, such records shall include, at a minimum, records of diversity audits of monitoring links, any internal report(s) generated as a result of such audits, records of actions taken pursuant to the audit results, and records regarding any alternative measures taken to mitigate the risk of aggregation points and/or monitoring links that are not physically diverse.

§ 9.20

Backup power obligations.

(a) Covered service. For purposes of this section, a Covered Service is any facilities-based, fixed voice service offered as residential service, including fixed applications of wireless service offered as a residential service, that is not line powered.

(b) Obligations of providers of a Covered Service to offer backup power. Providers of a Covered Service shall, at the point of sale for a Covered Service, offer subscribers the option to purchase backup power for the Covered Service as follows:

(1) Eight hours. Providers shall offer for sale at least one option with a minimum of eight hours of standby backup power.

(2) Twenty-four hours. By February 13, 2019, providers of a Covered Service shall offer for sale also at least one option that provides a minimum of twenty-four hours of standby backup power.

(3) Options. At the provider's discretion, the options in paragraphs (b)(1) and (2) of this section may be either:

(i) A complete solution including battery or other power source; or

(ii) Installation by the provider of a component that accepts or enables the use of a battery or other backup power source that the subscriber obtains separately. If the provider does not offer a complete solution, the provider shall install a compatible battery or other power source if the subscriber makes it available at the time of installation and so requests. After service has been initiated, the provider may, but is not required to, offer to sell any such options directly to subscribers.

(c) Backup power required. The backup power offered for purchase under paragraph (b) of this section must include power for all provider-furnished equipment and devices installed and operated on the customer premises that must remain powered in order for the service to provide 911 access.

(d) Subscriber disclosure. (1) The provider of a Covered Service shall disclose to each new subscriber at the point of sale and to all subscribers to a Covered Service annually thereafter:

(i) Capability of the service to accept backup power, and if so, the availability of at least one backup power solution available directly from the provider, or after the initiation of service, available from either the provider or a third party. After the obligation to offer for purchase a solution for twenty-four hours of standby backup power becomes effective, providers must disclose this information also for the twenty-four-hour solution;

(ii) Service limitations with and without backup power;

(iii) Purchase and replacement information, including cost;

(iv) Expected backup power duration;

(v) Proper usage and storage conditions, including the impact on duration of failing to adhere to proper usage and storage;

(vi) Subscriber backup power self-testing and -monitoring instructions; and

(vii) Backup power warranty details, if any.

(2) Disclosure reasonably calculated to reach each subscriber. A provider of a Covered Service shall make disclosures required by this rule in a manner reasonably calculated to reach individual subscribers, with due consideration for subscriber preferences. Information posted on a provider's public website and/or within a subscriber portal accessed by logging through the provider's website are not sufficient to comply with these requirements.

(3) The disclosures required under this paragraph are in addition to, but may be combined with, any disclosures required under § 9.11(a)(5) and (b)(5).

(e) Obligation with respect to existing subscribers. Providers are not obligated to offer for sale backup power options to or retrofit equipment for those who are subscribers as of the effective date listed in paragraph (f) of this section for the obligations in paragraph (b)(1) of this section, but shall provide such subscribers with the annual disclosures required by paragraph (d) of this section.

(f) Dates of obligations. (1) Except as noted in paragraphs (b)(2) and (f)(2) of this section, the obligations under paragraph (b) of this section are in effect February 16, 2016, and the obligations under paragraph (d) of this section are in effect August 5, 2016.

(2) For a provider of a Covered Service that (together with any entities under common control with such provider) has fewer than 100,000 domestic retail subscriber lines, the obligations in paragraph (b)(1) of this section are in effect August 11, 2016, the obligations in paragraph (b)(2) of this section are in effect as prescribed therein, and the obligations under paragraph (d) of this section are in effect February 1, 2017.

(g) Sunset date. The requirements of this section shall no longer be in effect as of September 1, 2025.

PART 12—[REMOVED AND RESERVED]

7. Under the authority of 47 U.S.C. 154(i), part 12 is removed.

PART 20—COMMERCIAL MOBILE SERVICES

8. The authority citation for part 20 continues to read as follows:

Authority: 47 U.S.C. 151, 152(a), 154(i), 157, 160, 201, 214, 222, 251(e), 301, 302, 303, 303(b), 303(r), 307, 307(a), 309, 309(j)(3), 316, 316(a), 332, 610, 615, 615a, 615b, 615c, unless otherwise noted.

9. Section 20.2 is amended by adding paragraph (c) to read as follows:

§ 20.2

Other applicable rule parts.

* * * * *

(c) Part 9. This part contains 911 and E911 requirements applicable to telecommunications carriers and commercial mobile radio service (CMRS) providers.

§ 20.3

[Amended]

10. Section 20.3 is amended by removing the definitions of “Appropriate local emergency authority,” “Automatic Number Identification (ANI),” “Designated PSAP,” “Handset-based location technology,” “Location-capable handsets,” “Network-based Location Technology,” “Pseudo Automatic Number Identification (Pseudo-ANI),” “Public safety answering point (PSAP),” and “Statewide default answering point”.

§ 20.18

[Removed and Reserved]

11. Section 20.18 is removed and reserved.

PART 22—PUBLIC MOBILE SERVICES

12. The authority citation for part 22 continues to read as follows:

Authority: 47 U.S.C. 154, 222, 303, 309, and 332.

§ 22.921

[Removed and Reserved]

13. Section 22.921 is removed and reserved.

PART 25—SATELLITE COMMUNICATIONS

14. The authority citation for part 25 continues to read as follows:

Authority: 47 U.S.C. 154, 301, 302, 303, 307, 309, 310, 319, 332, 605, and 721, unless otherwise noted.

§ 25.103

[Amended]

15. Section 25.103 is amended by removing the definition of “Emergency Call Center”.

§ 25.284

[Removed and Reserved]

16. Section 25.284 is removed and reserved.

PART 64—MISCELLANEOUS RULES RELATING TO COMMON CARRIERS

17. The authority citation for part 64 continues to read as follows:

Authority: 47 U.S.C. 154, 201, 202, 217, 218, 220, 222, 225, 226, 227, 228, 251(a), 251(e), 254(k), 262, 403(b)(2)(B), (c), 616, 620, 1401-1473, unless otherwise noted.

18. Section 64.601 is amended by revising paragraph (a) to read as follows:

§ 64.601

Definitions and provisions of general applicability.

(a) For purposes of this subpart, the term affiliate is defined in 47 CFR 52.12(a)(1)(i), and the terms majority and debt are defined in 47 CFR 52.12(a)(1)(ii).

* * * * *

19. Section 64.603 is amended by revising paragraph (a) to read as follows:

§ 64.603

Provision of services.

(a) Each common carrier providing telephone voice transmission services shall provide, in compliance with the regulations prescribed herein and the emergency calling requirements in part 9, subpart E of this chapter, throughout the area in which it offers services, telecommunications relay services, individually, through designees, through a competitively selected vendor, or in concert with other carriers. Interstate Spanish language relay service shall be provided. Speech-to-speech relay service also shall be provided, except that speech-to-speech relay service need not be provided by IP Relay providers, VRS providers, captioned telephone relay service providers, and IP CTS providers. In addition, each common carrier providing telephone voice transmission services shall provide access via the 711 dialing code to all relay services as a toll free call. CMRS providers subject to this 711 access requirement are not required to provide 711 dialing code access to TTY users if they provide 711 dialing code access via real-time text communications, in accordance with 47 CFR part 67.

* * * * *

20. Section 64.604 is amended by removing and reserving paragraph (a)(4) and revising paragraph (d).

The revision reads as follows:

§ 64.604

Mandatory minimum standards.

* * * * *

(d) Other standards. The applicable requirements of § 9.14 of this chapter and §§ 64.611, 64.615, 64.617, 64.621, 64.631, 64.632, 64.5105, 64.5107, 64.5108, 64.5109, and 64.5110 of this part are to be considered mandatory minimum standards.

§ 64.605

[Removed and Reserved]

21. Section 64.605 is removed and reserved.

Subpart AA—[Removed and Reserved]

22. Subpart AA, consisting of §§ 64.3000 through 64.3004, is removed and reserved.

Footnotes

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.

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.”

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.

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.

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.”

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.

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.

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.

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.

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.

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.

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.

18.  In this respect, we find that requiring retrofitting existing systems solely to address dispatchable location may result in a failure to promote more integrated technological solutions that could address both the direct dialing and notification provisions of Kari's Law and the dispatchable locations provisions of RAY BAUM'S Act on a holistic basis.

19.  RedSky notes that fixed telephone providers typically have no control over inside wiring in single family homes, and therefore are unlikely to be able to identify floor level for a fixed telephone call originating from a single family home that is more than one story. However, we see no practical benefit to requiring floor level identification as a component of dispatchable location for calls from single family dwellings, nor has any public safety commenter suggested this is necessary.

20.  Fixed VoIP services are services that provide the functional equivalent of fixed telephony by means of a device that connects to a single access point and is not capable of being moved by the end user. Non-fixed VoIP services are VoIP services that enable the end user to connect a handset or other IP-enabled device to multiple access points. Such services are variously described as “nomadic” or “mobile” VoIP, depending on the degree of functional mobility that the service allows the end user. We use the term “non-fixed VoIP” to refer to the full range of such services, except where referring to comments that specifically discuss nomadic or mobile VoIP. We also note that the term “non-fixed VoIP” does not extend or apply to Commercial Mobile Radio Services that are subject to our wireless E911 rules.

21.  INCOMPAS requests that the Commission “extend the compliance deadline for fixed services and give all providers two years to comply with these new obligations.” However, the record confirms that providing dispatchable location within a year is technically feasible for fixed services.

22.  We note that AT&T points out that automatic location solutions could raise network security concerns because some proposed solutions, which would have limited applicability, would involve scanning of the Data Link Layer (Layer 2) of IP networks, which would violate cybersecurity protocols and expose cyber vulnerabilities. AT&T states that solutions based on scanning networks may require customer disclosure of sensitive data, which they may be unwilling to give vendors because doing so would present a cybersecurity risk. In light of AT&T's concerns, providers may fall back on manual registered location if automatic solutions raise security concerns.

23.  We agree that the MLTS and interconnected VoIP location rules do not overlap, and that providers should be subject to only one set of requirements for any particular service they provide. If a service meets the definition of interconnected VoIP service in section 9.3 of our newly adopted rules, it will be subject to the interconnected VoIP location rules and not the MLTS location rules.

24.  In this regard, inclusion of the notification in the fine print of an online customer agreement would not be sufficient.

25.  Microsoft analogizes its argument to the Commission's 1996 decision to extend emergency calling requirements to non-service-initialized (NSI) phones, which similarly lacked callback capabilities, by requiring carriers to forward to PSAPs automatically all 911 calls from wireless mobile handsets which transmit a code identification, without requiring user validation or any similar procedure. Although the Commission has acknowledged that fraudulent 911 calls from NSI devices impose a substantial burden on PSAPs, we disagree with Microsoft that this is a result of the lack of the callback feature.

26.  Microsoft speculates that relying on end users to manually update their location information could create an additional risk that applications like Skype could be downloaded easily by a nefarious actor who could then “input a false location, and then a make a 911 call for the purpose of dispatching public safety resources to a particular location under false pretenses.” We find this argument implausible. For one, interconnected VoIP providers are already required to require their end users to register a location for 911 calls, and yet the record presents no evidence that this is a problem today. Given that distinguishing feature between such services and outbound-only interconnected VoIP services is solely the lack of a callback feature—which is unrelated to the problem Microsoft alleges—we see no reason to think improper location information will suddenly become a problem should Microsoft be required to allow its SkypeOut users call emergency services effectively. More broadly, nefarious actors can give false information to a PSAP via any technological platform—and there is nothing distinctive about outbound-only interconnected VoIP services that would lead us to believe including them would have a material impact. What is more, we do not mandate registered locations to be collected but instead empower providers to use other technologies to facilitate dispatchable location or alternative location information for such 911 calls—and of course we expect providers like Microsoft to take into account the risks to public safety it has flagged when choosing how to comply with our rules. Finally, to the extent that Registered Location still presents any “additional risk,” as Microsoft posits, that risk is outweighed by the need for people to be able call 911 and for emergency responders to find them.

27.  We acknowledge that some voice applications may provide users with both interconnected and non-interconnected VoIP services and emphasize that applicability of our 911 requirements to interconnected VoIP service providers hinges on whether the service satisfies all prongs of the definition, including interconnection to the PSTN.

28.  We note that the definition we adopt today tracks more closely to the existing definition of “Interconnected VoIP Service” as it is currently defined to refer to both inbound and outbound interconnection than the definition proposed in the 2011 NPRM, which permitted users to terminate calls to all or substantially all United States E.164 telephone numbers. As we describe above, this is in-line with our intended approach to minimize disruption to the current definition of “Interconnected VoIP Service” in section 9.3 of the Commission's rules.

29.  We further clarify that outbound-only interconnected VoIP services, which are now encompassed within the section 9.3 definition of “Interconnected VoIP Service,” are still considered non-interconnected VoIP services for the purposes of section 716 of the Communications Act of 1934, and therefore remain subject to part 14 of the Commission's rules.

30.  To the extent commenters argued that the Commission lacks statutory authority to create a “911 VoIP Services” definition that includes non-interconnected VoIP, we conclude that the issue is moot as we are not addressing those services at this time.

31.  We define TRS fixed services to include hardware-based TRS and videophone equipment that are professionally installed and cannot be moved by the customer without professional assistance.

32.  We define TRS nomadic and mobile services to include TRS facilities that use software-based endpoints.