2018-21888. Improving the 911 System by Implementing Kari's Law and RAY BAUM'S Act

AGENCY:

Federal Communications Commission.

ACTION:

Proposed rule.

SUMMARY:

In this document, the Federal Communications Commission (the FCC or Commission) proposes rules for 911 calls made from multi-line telephone systems (MLTS), pursuant to Kari's Law, the conveyance of dispatchable location with 911 calls, as directed by RAY BAUM'S Act, and the consolidation of the Commission's 911 rules. The Commission also proposes consolidating the Commission's existing 911 rules into a single rule part.

DATES:

Comments are due on or before December 10, 2018 and reply comments are due on or before January 9, 2019.

ADDRESSES:

You may submit comments, identified by PS Docket Nos. 18-261 and 17-239 by any of the following methods:

• Federal eRulemaking Portal: http://www.regulations.gov. Follow the instructions for submitting comments.
• Federal Communications Commission's Website: http://www.fcc.gov/​ecfs/​. Follow the instructions for submitting comments.
• Mail: Filings can be sent by hand or messenger delivery, by commercial overnight courier, or by first-class or overnight U.S. Postal Service mail (although the Commission continues to experience delays in receiving U.S. Postal Service mail). All filings must be addressed to the Commission's Secretary, Office of the Secretary, Federal Communications Commission.
• People with Disabilities: Contact the Commission to request reasonable accommodations (accessible format documents, sign language interpreters, CART, etc.) by email: [e-mail] or phone: [phone] or TTY: 202-418-0432.

For detailed instructions for submitting comments and additional information on the rulemaking process, see the SUPPLEMENTARY INFORMATION section of this document.

FOR FURTHER INFORMATION CONTACT:

Brenda Boykin, Attorney-Advisor, Policy and Licensing Division, Public Safety and Homeland Security Bureau, [phone] or via email at [e-mail]; Austin Randazzo, Attorney-Advisor, 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 Notice of Proposed Rulemaking (NPRM) in PS Docket Nos. 18-261 and 17-239, FCC 18-132, adopted and released on September 26, 2018. The full text of this document is available for inspection and copying during normal business hours in the FCC Reference Center (Room CY-A257), 445 12th Street SW, Washington, DC 20554. The full text may also be downloaded at: www.fcc.gov.

Synopis

I. Introduction

1. In this proceeding, the Commission takes steps to advance Congressional and Commission objectives to ensure that members of the public can successfully dial 911 to request emergency services and that Public Safety Answering Points (PSAPs) can quickly and accurately locate every 911 caller, regardless of the type of service that is used to make the call. The President recently signed into law two statutes directed to the improvement of 911: (1) Kari's Law Act of 2017 (Kari's Law), which requires implementation of direct 911 dialing and on-site notification capabilities in multi-line telephone systems (MLTS), and (2) Section 506 of RAY BAUM'S Act (RAY BAUM'S Act), which requires the Commission by September 23, 2019 to “conclude a proceeding to consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call, regardless of the technological platform used and including with calls from [MLTS].”

2. In this NPRM, we propose to implement Kari's Law by adopting direct dial and notification rules governing calls to 911 made from MLTS. As required by RAY BAUM'S Act, we also consider the feasibility of requiring dispatchable location for 911 calls from MLTS and other technological platforms that currently complete calls to 911. We propose establishing a dispatchable location requirement for MLTS 911 calls, which would apply contemporaneously with the February 16, 2020 compliance date of Kari's Law. Additionally, in keeping with the directive in RAY BAUM'S Act to address dispatchable location for 911 calls “regardless of the technological platform used,” we propose to add dispatchable location requirements to our existing 911 rules for fixed telephony providers, interconnected Voice over internet Protocol (VoIP) providers, and internet-based Telecommunications Relay Services (TRS). We also consider the feasibility of alternative location mechanisms for MLTS and other services that could be used as a complement to dispatchable location or as a substitute when dispatchable location is not available. Additionally, we consider whether dispatchable location requirements should be extended to other communications services that are not covered by existing 911 rules but are capable of making a 911 call.

3. Finally, we propose to take this opportunity to consolidate our existing 911 rules, as well as the direct dialing and dispatchable location rules proposed in this NPRM, into a single rule part. The Commission historically has taken a service-specific approach to 911, resulting in 911 requirements for different services scattered across different sections of the agency's rules. We believe that consolidating our 911 rules from these various rule sections into a single rule part will further the goal of recognizing that all the components of 911 function as part of a single system and will enable service providers, emergency management officials, and other stakeholders to refer to a single part of the Commission's rules to more easily ascertain all 911 requirements.

II. Background

A. E911 and Multi-Line Telephone Systems

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

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

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

7. The National Emergency Number Association (NENA) has proposed model MLTS legislation for states, as well as model federal MLTS legislation. To date, 23 states have enacted legislation that requires organizations over a certain size or purchasing a new PBX/MLTS system to implement E911 on the system. These states have adopted varied requirements for MLTS providers, and only in some instances have state laws specifically addressed prefix dialing requirements.

8. In the absence of federal or consistent state regulation, some MLTS in operation today do not support direct 911 dialing, may not have the capability to route calls to the appropriate PSAP relative to the caller's location, or may not provide accurate information regarding the caller's location. The Commission has observed that these issues have persisted, even as many enterprises are increasingly relying on IP-based systems, including cloud-based services, to support their communications needs. Given that the ongoing evolution of MLTS has not eliminated these shortfalls when serving 911 callers, the Commission has periodically sought to examine MLTS provision of 911, including the capabilities of MLTS to support direct 911 access, routing, callback, and automatic location

9. In September 2017, the Commission released a Notice of Inquiry (ECS NOI) seeking information on the capabilities of enterprise communications systems (ECS) to support direct 911 access, routing, and automatic location. The Commission noted that ECS may not provide consumers with the same access to E911 services as non-ECS wireline, wireless, and interconnected VoIP calls and asked whether it is still the case, as the Commission found in earlier proceedings, that the needs and circumstances of residential and business ECS users are suited to state-level action rather than federal regulation. The ECS NOI also sought information on the state of the ECS industry; the costs and benefits of supporting E911 for ECS; the capability of ECS to provide accessible emergency communications for persons with disabilities; and options for ensuring that ECS keep pace with technological developments and consumer expectations for access to 911.

10. The Commission received 19 comments and six reply comments in response to the ECS NOI. Commenters generally agreed that the ECS marketplace is diverse and complex. For example, Cisco categorized ECS as falling within three types: (1) On-premises hardware and software; (2) cloud solutions; and (3) over-the-top applications. West Safety categorized ECS as falling within three additional and different types: (1) Time-division multiplexing (TDM) ECS, which are self-contained and proprietary and use physical switches and wiring with localized infrastructure; (2) hybrid ECS, which have combined TDM and IP extensions and provide reduced infrastructure and interoperability; and (3) IP ECS, which have centralized infrastructure and servers, Session Initiation Protocol (SIP) capabilities with multimedia support, and scalability. West Safety noted that TDM-based ECS have been “nearing end-of-life for a long time now” and that the vast majority of enterprises have migrated, or will migrate soon, to pure IP-based ECS to support VoIP and Unified Communications (UC) systems, with an increasing trend toward cloud-based service offerings.

11. Commenters underscored the importance of ensuring the accessibility of ECS for persons with disabilities, including ECS capability to handle text (including real time text (RTT)), data, video, and text telephone (TTY) calls and the availability of dispatchable location information to PSAPs regardless of the type of call being made. Commenters, however, disagreed over whether it is feasible for all types of ECS to support precise location of 911 callers. In addition, commenters disagreed regarding the Commission's authority to establish 911 requirements for ECS. Some commenters asserted that the Commission lacked such authority because most enterprise owners and equipment manufacturers do not provide interstate communications, or because ECS owners and operators are not service providers under Title II of the Communications Act or licensees under Title III. Other commenters asserted that 911 calls from ECS are interstate in nature, and that the Commission has broad authority over public safety and 911, including authority over ECS operators and equipment and service vendors under Sections 1, 4, and 255 of the Communications Act, as well as the Twenty-First Century Communications and Video Accessibility Act of 2010 (CVAA). Finally, some commenters asserted that state regulation of ECS 911 service is not working and urged the Commission to begin a rulemaking, while others urged the Commission to continue to defer to the states to address ECS 911 functionality.

B. Kari's Law and RAY BAUM'S Act

12. Kari's Law. After the close of the ECS NOI comment/reply cycle, Kari's Law was enacted on February 16, 2018. Kari's Law has been added to the Communications Act of 1934 as amended (the Act) as section 721.

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

14. Second, Kari's Law applies to any “person engaged in the business of installing, managing, or operating” MLTS. Such persons “may not install, manage, or operate for use in the United States such a system, unless such system is configured such that a user may directly initiate a call to 9-1-1 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit `9', regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls.” Additionally, such persons “shall, in installing, managing, or operating such a system for use in the United States, configure the system to provide a notification to a central location at the facility where the system is installed or to another person or organization regardless of location, if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system.”

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

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

III. Discussion

A. Direct Dialing and Notification for MLTS

17. Kari's Law is a provision of the Communications Act of 1934, as amended. Accordingly, the Commission has authority to prescribe such rules and regulations as are necessary to carry out Kari's Law. We believe that adoption of implementing regulations would provide additional clarity and specificity regarding the terms used in the statute and the obligations placed on covered entities. Implementing regulations can provide important guidance to covered entities on complying with the law and the mechanism the Commission will use to enforce the statute. Accordingly, our proposed rules include definitions of some of the terms in Kari's Law, as well as other provisions to clarify the obligations of entities regulated under the statute.

1. Direct Dialing

18. Applicability and Obligations. We propose direct dialing requirements for persons engaged in the business of manufacturing, importing, selling, or leasing MLTS, as well as persons engaged in the business of installing, managing, or operating MLTS, that track the obligations in Kari's Law. We seek comment on these proposed implementing regulations.

2. Notification

19. Applicability and Obligations. Consistent with Kari's Law, we propose to adopt implementing regulations requiring that a person engaged in the business of installing, managing, or operating MLTS shall, in installing, managing, or operating the system, configure it to provide a notification that a 911 call has been placed by a caller on the MLTS system. The system configuration must provide for the notification to be transmitted to a central location at the facility where the system is installed or to another person or organization regardless of location, if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system. This notification requirement will potentially benefit three parties: (1) The 911 caller by speeding response time; (2) enterprise management and staff by providing needed information and reducing confusion and delay when emergency response teams arrive; and (3) first responders by reducing time spent responding to such calls.

20. Required Information and Purpose. Although Kari's Law requires MLTS to support notification when an MLTS user makes a 911 call, it does not specify what information must be provided in the notification. In comments on the ECS NOI, West Safety noted that on-site notification can be configured to include name, callback number, precise station-level location, and links to enhanced data such as detailed floor plans and emergency contacts. NENA's model federal MLTS legislation provides for on-site notification that would automatically alert a designated emergency station on the premises that 911 has been dialed from the MLTS and would include specific location information for the station from which the call originated. Rules implementing a Texas statute similar to Kari's Law provide that the notification should include the telephone number or extension and location information of the handset from which the 911 call is made, provided that it is feasible to do so.

21. We tentatively conclude that for notification to be capable of achieving the purpose of Kari's Law, it should include certain basic information, such as the caller's location, that will assist the enterprise and first responders in coordinating and expediting on-site response to the emergency. According to Avaya, the benefits of on-site notification include that it can “allow[] internal responders to confirm and assist the person who has dialed 9-1-1, and provide[] notice that first responders are on the way so that preparations can be made. This includes ensuring access doors are unlocked, elevators are available and hallways are unobstructed.” RedSky has stated that on-site notification “can save 2-3 minutes in emergency response time when a 9-1-1- call is made.”

22. We propose to require that notification at a minimum include the following information: (1) The fact that a 911 call has been made, (2) a valid callback number, and (3) the information about the caller's location that the MLTS conveys to the PSAP with the call to 911. Thus, under our dispatchable location proposal discussed in Section B.1 below, the notification to the enterprise would include the same dispatchable location information that the PSAP receives. Because the notification will help the enterprise to assist first responders, we believe it makes sense for the recipient of the notification to have the same information as the PSAP (and, indirectly, the first responders dispatched to the scene). In addition, because our proposal assumes the notification would only convey information that already exists for the 911 call, we tentatively conclude that providing the same information would minimize additional burdens. We seek comment on this proposed approach. Are there situations in which the callback or location information conveyed to the PSAP need not be included with an on-site notification? Instead of specifying the content of the notification, should we allow enterprises the flexibility to customize notification as they see fit? Is there an alternative approach that would be superior to the one proposed in terms of costs and benefits?

23. Notification Timing and Destination Points. Kari's Law is silent on when the notification must be provided. We believe that timely notification is essential, because delayed notification could impede coordination between enterprise management or staff and first responders seeking access to the enterprise premises. Therefore, we propose to require that MLTS covered by Kari's Law be configured so that notification is contemporaneous with the 911 call and does not delay the placement of the call to 911. We seek comment on this proposal, as well as any alternatives.

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

25. We seek comment on whether the Commission should specify any criteria for destination points to ensure that notifications, whether on-site or off-site, are likely to be received by someone able to take appropriate action to facilitate or assist the 911 response. Where on-site notification to a “central location” is provided, should we specify that the destination point must be a location that is normally staffed or, alternatively, a location where on-site staff are likely to hear or see the notification? This would afford the flexibility to direct the on-site notification to a security guard or facilities manager, to personnel who are otherwise employed and can support monitoring notifications as a part of existing duties, or to an on-site location where staff are normally present. We seek comment on this approach. Where notification is provided to a “person or organization regardless of location,” should we require that the person or organization be one that is authorized to provide first responders with access to the location from which the MLTS 911 call originated? This would allow notification to be directed to any offsite location, as the statute clearly allows, while furthering the statute's objective of facilitating access to first responders answering a 911 call. We seek comment on this approach.

26. We also seek comment on the cost and expected benefit of the above-mentioned options for implementing the notification requirement of Kari's Law. We note that while some state MLTS statutes include notification requirements, these statutes either expressly provide that the enterprise does not have to make a person available to receive a notification, or they are silent on whether the destination point must be staffed. We do not believe Congress intended to impose staffing or monitoring requirements that would impose unreasonable costs or limit the flexibility of MLTS installers, managers, and operators to develop efficient and cost-effective notification solutions that are appropriate for the technology they use, such as visual alerts on monitors, audible alarms, text messages, and/or email. Rather than requiring staffing or monitoring, we believe that allowing notifications to be directed to the points where they are likely to be seen or heard by existing staff achieves these goals at a negligible cost above what an MLTS manager would already spend when purchasing an MLTS. We seek comment on this approach. What means are available to reasonably ensure that notification will be timely received by a person with authority to act on it? For example, could alarm companies, security firms, or similar entities create efficiencies by providing 911 notification monitoring for multiple customers? Are there other means to reduce these costs?

27. We also seek comment on how the statute's notification requirements should be applied to small enterprises. Large enterprises such as hotels, hospitals, and schools frequently have on-site personnel that control access to the premises, and notification of 911 calls to such personnel can improve outcomes by enabling them to assist first responders in accessing the premises and reaching the caller's location. Do the benefits and costs of notification apply differently to small businesses? Small businesses are less likely to have personnel controlling access, and first responders may not need the same level of assistance to reach a 911 caller. At the same time, small enterprises using MLTS may find benefits to notification in addition to access and support. For example, on-site personnel can intervene when 911 is dialed in error, enabling them to contact the PSAP and avoid sending emergency responders to a location that does not require a response.

3. Definitions.

28. Multi-Line Telephone System. Kari's Law and RAY BAUM'S Act define the term “multi-line telephone system” as “a system comprised of common control units, telephone sets, control hardware and software and adjunct systems, including network and premises based systems, such as Centrex and VoIP, as well as PBX, Hybrid, and Key Telephone Systems (as classified by the Commission under part 68 of title 47, Code of Federal Regulations), and includes systems owned or leased by governmental agencies and non-profit entities, as well as for profit businesses.”

29. We propose to interpret this definition to include the full range of networked communications systems that serve enterprises, including circuit-switched and IP-based enterprise systems, as well as cloud-based IP technology and over-the-top applications. We further propose to interpret this definition to include enterprise-based systems that allow outbound calls to 911 without providing a way for the PSAP to place a return call. We believe requiring direct dialing for any MLTS that allows the user to call 911, regardless of whether the system also allows the PSAP to make a return call, advances the purpose of the statute. In addition, there is nothing in the language of the definition of MLTS from the Middle Class Tax Relief and Job Creation Act of 2012 that excludes systems allowing only outbound calls to 911.

30. We seek comment on our proposed definition of the term MLTS. Are there other ways in which the Commission should clarify the meaning of MLTS, and if so, what are they? Should we define MLTS to include systems that allow outbound calls to 911 but not inbound calls, as proposed above? How common are such systems? Are 911 calls from such systems identified as outbound-only at the PSAP? Are outbound-only systems ever deployed together with systems that allow two-way calling? If so, how do enterprise managers address the potential for end user confusion over the ability to receive a return call from the PSAP over a particular system?

31. Pre-configured and configured. Next, we propose to define the statutory terms “pre-configured” and “configured” as applied to MLTS direct dialing. First, we propose to define “pre-configured” to mean that the MLTS comes equipped with a default configuration or setting that enables users to dial 911 directly as required under the statute and rules, so long as the system is installed and operated properly. This does not preclude the inclusion of additional dialing patterns to reach 911. However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern. We believe this means that an MLTS may support additional dialing patterns, but manufacturers (and importers, sellers, or lessors) must ensure that the default, “out-of-the-box” configuration allows users to reach 911 directly.

32. Second, we propose to define “configured” to refer to the settings or configurations implemented for a particular MLTS installation. To meet this definition, the MLTS must be fully capable when installed of dialing 911 directly and providing notification as required under the statute and rules. As with “pre-configured,” an MLTS may be configured to support additional dialing patterns, but manufacturers (and importers, sellers, or lessors) must ensure that they are in addition to the default direct dialing pattern. We seek comment on this proposed definition. Cisco noted in its comments on the ECS NOI that “[c]onfiguring [MLTS] is an entirely different line of business than manufacturing [MLTS].” Under our proposed definitions, is the difference between “pre-configuring” an MLTS and “configuring” an MLTS sufficiently clear? If not, how can we clarify the differences?

33. Improvement to the hardware or software of the system. Kari's Law provides that the notification requirements of the statute apply only if the system can be configured to provide notification “without an improvement to the hardware or software of the system.” We propose to define the term “improvement to the hardware or software of the system” to include upgrades to the core systems of an MLTS, as well as substantial upgrades to the software and any software upgrades requiring a significant purchase. We seek comment on this proposed definition. Are there types of routine hardware or software changes that should be included in or excluded from the definition? For example, should we clarify that (1) improvements to the hardware of the system do not include the provision of additional extensions or lines, and (2) improvements to the software of the system do not include minor software upgrades that are easily achieved or made to improve the security of the system? What changes should we consider minor? Should upgrades requiring a significant purchase be determined based on total cost alone, or should we interpret significant to be a relative determination based on the size of the entity making the purchase?

34. A person engaged in the business of manufacturing, importing, selling, or leasing an MLTS. Kari's Law prohibits the manufacture or importation for use in the United States, or sale or lease or offer to sell or lease in the United States, of non-compliant MLTS. We tentatively conclude that the meaning of the term “person engaged in the business of manufacturing, importing, selling, or leasing an MLTS” is self-evident, and we do not propose to modify or add to this definition in our rules. We nonetheless seek comment on whether any additional clarification of this term is necessary for implementation or enforcement of Kari's Law. For instance, should we clarify that a person engaged in the business of manufacturing, importing, selling, or leasing MLTS includes a distributor or reseller of MLTS?

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

36. A person engaged in the business of managing an MLTS. We propose to define a person engaged in the business of managing an MLTS as the entity that is responsible for controlling and overseeing implementation of the MLTS after installation. These responsibilities include determining how lines should be distributed (including the adding or moving of lines), assigning and reassigning telephone numbers, and ongoing network configuration. We also propose to interpret the definition to mean that a user of MLTS services that does not own or lease the MLTS or exercise any control over it would not be deemed to be engaged in the business of managing the MLTS. Thus, an enterprise that contracts with a third party to provide a total solution for MLTS, including acquiring the MLTS equipment, configuring the system, completing calls, and providing services such as maintenance and end user support, would not be deemed to be engaged in the business of managing the MLTS unless it exercised actual control over the system. We seek comment on this proposed definition.

37. A person engaged in the business of operating an MLTS. We propose to define a person engaged in the business of operating an MLTS as an entity responsible for the day-to-day operations of the MLTS. As with our proposed definition of MLTS manager above, we also propose to interpret this term to mean that an MLTS user that does not own, lease, or exercise control over the MLTS would not be deemed to be engaged in the business of operating the MLTS. We seek comment on our proposed definition.

38. We also seek comment on whether there are circumstances in which our proposed definitions of MLTS “manager” or “operator” should extend to enterprise owners. Commenters on the ECS NOI emphasized that some enterprise owners purchase, operate, and maintain their own on-premises telephone systems with PBX equipment, while others enter contractual arrangements with third-party providers of network and hosted services. AT&T noted that the decision whether to purchase and implement an MLTS solution lies with the enterprise owner and that the owner “must have a role to play in ensuring that 911 capabilities are functioning as intended.” As noted above, we do not believe that Kari's Law was intended to extend liability to enterprise owners that purchase MLTS services but do not exercise control over the manner in which such services are configured or provided. Nevertheless, there may be instances where enterprise owners purchase, operate, and maintain their own MLTS systems, or they may exercise active control over the configuration and provision of MLTS by third parties. In such instances, should enterprise owners be deemed to be MLTS managers or operators? What indicia of active control should be considered in making this determination?

4. Other Issues

39. Compliance date. Consistent with the provisions of Kari's Law, we propose that the compliance date for our implementing regulations will be two years from the date of the law's enactment, i.e., on February 16, 2020. Thus, the proposed direct dialing and notification requirements would apply to MLTS that are manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020. We seek comment on this proposed compliance date for implementing regulations, as well as on alternatives. Those offering alternatives should explain how any proposed date that differs from the one that we propose would be consistent with the statutory language.

40. Transitional Issues. Kari's Law applies only with respect to MLTS that are manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020. Accordingly, MLTS manufactured, imported, offered for first sale or lease, first sold or leased, or installed on or before that date are grandfathered from compliance with the statute. To what extent is direct dialing of 911 already available and in use in MLTS? To the extent that MLTS in use do not support direct dialing, what options are currently available to installers, managers, and operators that may be planning to upgrade or replace their systems? Are there any barriers facing (1) MLTS manufacturers, importers, sellers, and lessors, and (2) MLTS installers, managers, and operators, to meet the statute's direct dialing requirements by the compliance date? If so, what are those barriers and what are the potential costs of overcoming them?

41. We also seek comment on whether we should adopt transitional rules to inform consumers of the 911 capabilities of grandfathered MLTS. For example, the state version of Kari's Law enacted in Texas requires enterprises to place a sticker adjacent to or on non-compliant MLTS devices that provides instruction in English and Spanish on how to call 911. Similarly, the Commission's interconnected VoIP E911 rules require service providers to distribute stickers or labels warning subscribers that E911 service may be limited. We seek comment on whether to require MLTS installers, operators, and managers to notify callers how to dial 911 from grandfathered systems, as well as options for doing so and their related costs. In addition, we seek comment on potential sources of statutory authority for such requirements.

42. Enforcement. Under Kari's Law, the Commission is empowered to enforce the statute under Title V of the Communications Act, “except that section 501 applies only to the extent that such section provides for the punishment of a fine.” We seek comment on how the Commission should enforce and provide oversight of the requirements of Kari's Law. As a general matter, we envision following the framework set forth by the statute. For example, a manufacturer could face enforcement action for offering to sell an MLTS that is not pre-configured to support direct 911 dialing, and an MLTS operator could face enforcement action for operating the system when it was not configured so that users could dial 911 directly. We seek comment on the potential use of this enforcement approach for Kari's Law.

43. Additionally, we seek comment on who, or which entities, should bear responsibility for violations of the proposed rules. Verizon comments that there can be great variation in the business relationships between MLTS installers, operators, and managers: “In some cases the service provider and the system operator or vendor will each have a direct relationship with an enterprise customer. In other cases the service provider may be a subcontractor to the system operator, and only provide certain components of the service (such as MPLS circuits for transport or other trunking services), with limited or no say in the design or configuration of the product. Or the reverse may be true—i.e., the enterprise system operator is a subcontractor of the service provider, and the service provider maintains the direct contractual relationship with the customer.”

44. We propose to apply a presumption that the MLTS manager bears ultimate responsibility for compliance with our proposed rules implementing Kari's Law. For example, if an MLTS fails to comply with our proposed rules, the MLTS manager would be presumed to be responsible for that failure, at least in part, unless the manager can rebut that presumption by demonstrating compliance with its obligations under the statute and our proposed rules. We seek comment on this proposal. How should we apportion liability in situations where multiple parties may be responsible for compliance with the statute and our proposed rules? For example, in a case where the MLTS manager contracts with a third party to install and operate an MLTS, but the third party fails to comply with the Commission's rules, should the MLTS manager and third-party contractor be held jointly or individually responsible? What evidence or factors should we look to in apportioning or rebutting a presumption of liability?

45. Complaint Mechanisms and Other Issues. We envision relying on existing Commission complaint mechanisms to facilitate the filing of complaints for potential violations of Kari's Law. For example, PSAPs and the public could report problems via the Public Safety and Homeland Security Bureau's Public Safety Support Center or the Commission's Consumer Complaint Center. We seek comment on this.

46. We also seek comment on whether to modify our equipment authorization rules as they apply to MLTS equipment manufactured after February 16, 2020. Should MLTS applications for equipment authorization under Parts 2, 15, or 68 constitute a representation that such equipment complies with MLTS 911 requirements?

47. Finally, we ask commenters to identify voluntary best practices that can improve the effectiveness of direct dialing and notification for MLTS. For example, the Michigan State 911 Committee has developed guidelines that call for MLTS operators to work directly with their local public safety entities to ensure compliance. The Michigan State 911 Committee also “strongly recommend[s] that every MLTS operator work with their local 911 system manager/director to test the ability to dial 911 from the station lines associated with MLTS systems any time an MLTS has been installed or upgraded.” We seek comment on this and other recommended or potential best practices that would help enterprises ensure the effectiveness of direct dialing and notification. Are there best practices for the training of on-site emergency personnel and others responsible for the implementation of direct dialing and notification? Similarly, are there best practices for the operation of an on-site or offsite notification point of contact?

5. Comparison of Benefits and Costs

48. According to a Congressional Budget Office analysis, most MLTS systems already are configured to meet the direct dialing and notification requirements of Kari's Law. In evaluating the Senate and House versions of Kari's Law, Cisco stated that it was not aware of any technological barriers to the implementation of Kari's Law as applied to MLTS. In addition, eight states and some local governments already have laws that require direct dialing for 911 from MLTS. For these state and local jurisdictions, our proposed rules would generally not affect the status quo and so would likely have little to no impact from a cost perspective. Moreover, the existence of state-level requirements has driven the manufacture of MLTS equipment that supports 911 direct dialing, much of which may have been marketed and sold in jurisdictions that do not have state or local requirements. We seek comment on the number of MLTS systems currently deployed that do not allow direct dialing of 911 and/or cannot be configured to provide notification of 911 calls to an MLTS manager.

49. Consistent with Kari's Law, our proposed rules would apply only with respect to MLTS that are manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020, which means that there should be no immediate costs or stranded investment with respect to existing MLTS or systems that first come into service on or before February 16, 2020. As noted above, many existing, installed MLTS support direct dialing to 911 and notification. Therefore, we tentatively conclude that there will be no immediate costs or benefits associated with meeting the requirements of our rules. For systems coming into service after February 16, 2020, we seek comment on the costs and benefits of satisfying our proposed rules. Are there alternative methods of meeting the requirements of Kari's Law that would reduce costs and/or increase benefits? Will any barriers exist for those wishing to replace their MLTS after this date that would be costly to overcome? We also seek comment on the expected lifespan of existing MLTS that are not currently able to meet the requirements of our proposed rules. What is the prevalence of such systems today, and what will the expected prevalence of such systems be in 2020? We seek comment on the cost of upgrading to an MLTS that supports the requirements of our proposed rules. Because most of the currently deployed MLTS are capable of being configured to meet the requirements of our rules today, without improvement to the hardware or software of the system, we tentatively conclude that our rules will impose no incremental costs to those who replace their MLTS as they come to the end of their useful life. We seek comment on this tentative conclusion.

50. Specifically as to notification, we tentatively conclude that the costs of implementing our proposed requirements will not exceed the value of their benefits. As discussed above, notification can assist MLTS managers in large enterprises in dealing with first responders. Prepared with information about a 911 call, a manager will be able to quickly direct and assist first responders at large enterprises, rather than spending time trying to gather such information. Notification will also benefit the 911 caller and first responders by allowing quicker response time. This analysis is supported by RedSky's ECS NOI comments, which state that, in its experience, ECS customers that receive these types of notifications “can save 2-3 minutes in emergency response time when a 911 call is made.” We also anticipate that notification will provide MLTS managers with opportunities to efficiently notify the PSAP of accidental 911 calls, preserving first responder resources and allowing the MLTS manager to avoid state or municipal fines or penalties for accidental 911 calls. We observe that some states already have laws and regulations that require on-site notification for 911 calls from MLTS. Similar to our proposed rules, the largest of these states defines notification to include the fact that a 911 call has been made, the caller's telephone number, and the caller's location. For these state and local jurisdictions, we anticipate that our proposed rules would have minimal impact. Moreover, the existence of state-level requirements has likely driven the manufacture of MLTS equipment that supports notification for 911 calls, much of which may have been marketed and sold in jurisdictions that do not have state or local requirements or to small businesses that are exempted from state or local requirements. We seek comment on our tentative conclusion, as well as particular costs involved in imposing the notification requirement and alternative methods consistent with Kari's Law that may reduce costs and/or improve benefits. We seek comment on the costs and benefits associated with our proposed definitions. We also seek comment on the benefits and costs associated with any additional notification requirements the Commission might adopt, such as requiring grandfathered MLTS to inform consumers of the 911 capabilities of those systems.

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

51. RAY BAUM'S Act directs us to consider rules requiring the conveyance of dispatchable location with 911 calls “regardless of the technological platform used.” Based on this directive, we consider whether to adopt dispatchable location requirements for MLTS and other 911-capable services. In addition to MLTS, we examine four types of communications services that are currently required under Commission rules to provide 911 service to their customers: (1) Fixed telephony, (2) mobile telecommunications, (3) interconnected VoIP service, and (4) internet-based Telecommunications Relay Services (TRS). In addition, we examine whether we should adopt dispatchable location rules for other 911-capable services that are not currently subject to 911 rules.

1. MLTS

52. Applicability and Obligations. When a 911 call is placed in an MLTS environment, a location may be included in the information sent to the PSAP, but that location may not be the location of the caller. On a large campus or in a hotel, for example, a 911 call may convey the location of the main entrance or administrative office. Such location imprecision can lead to delays in locating the person making the 911 call and result in further injury or loss of life.

53. By directing the Commission “to consider adopting rules to ensure that the dispatchable location is conveyed with a 9-1-1 call . . . including with calls from multi-line telephone systems,” Congress in RAY BAUM'S Act signaled its intent that the Commission focus on ensuring highly precise location information whenever feasible. Moreover, the enactment of RAY BAUM'S Act only weeks after Kari's Law indicates that Congress recognized the importance of providing accurate location information to PSAPs in connection with MLTS 911 calls. Dispatchable location is defined in the statute as “the street address of the calling party, and additional information such as room number, floor number, or similar information necessary to adequately identify the location of the calling party.” We therefore initiate this portion of our proceeding with Congress's stated goal in mind.

54. We propose to proscribe the manufacture, import, sale, or leasing of MLTS in the United States unless the system is pre-configured such that, when properly installed, the dispatchable location of the caller will be conveyed to the PSAP with 911 calls. Further, we propose to proscribe the installation, management, or operation of MLTS in the United States unless the system is configured such that the dispatchable location of the caller will be conveyed to the PSAP with 911 calls. And we propose to apply these proscriptions to the same entities subject to Kari's Law. We seek comment on these proposals.

55. In its comments to the ECS NOI, NCTA observed that “ECS involves not only the service provider and end user, but also manufacturers and ECS programmers. Coordination and assignment of responsibilities among these ECS functions must be done seamlessly to ensure that 911 services function properly.” For this reason, our proposals for dispatchable location parallel the direct dialing and notification requirements of Kari's Law in that they would apply to the participants in the MLTS marketplace we believe are best positioned to ensure that all installed MLTS are capable of conveying an accurate location to the appropriate PSAP. We seek comment on our approach to addressing the division of responsibilities when deploying and operating MLTS. Should more granular requirements be placed on any of the MLTS market participants to which our proposed rules would apply? Are new rules necessary to ensure that communication service providers (such as fixed telephony, mobile carriers, and interconnected VoIP service providers) that complete 911 calls originating from MLTS convey dispatchable location, or are existing 911 rules sufficient? Similarly, are rules needed to ensure that manufacturers and importers of MLTS incorporate capabilities in their products to enable them to convey dispatchable location information? Do standards exist for conveying dispatchable location information from MLTS? If so, should MLTS be required to conform to these standards? How should conformance of MLTS to such rules and standards be demonstrated?

56. Defining Dispatchable Location. RAY BAUM'S Act defines “dispatchable location” as “the street address of the calling party, and additional information such as room number, floor number, or similar information necessary to adequately identify the location of the calling party.” We note that the statutory definition of dispatchable location is nearly identical to the dispatchable location definition in the Commission's mobile E911 location accuracy rules. Given the substantial similarity between the two definitions, we propose to construe them as functionally identical, aside from the specification of the technological platform to which each definition applies. We seek comment on this proposal.

57. The mobile E911 definition of “dispatchable location” further requires that, when delivering dispatchable location, “[t]he street address of the calling party must be validated and, to the extent possible, corroborated against other location information prior to delivery of dispatchable location information by the CMRS provider to the PSAP.” We seek comment on whether we should require similar validation for dispatchable location information associated with MLTS 911 calls. Is there any reason why street address validation would be more difficult or costly for MLTS than for mobile E911?

58. We also seek comment on whether our rules should further define “additional information” that may be necessary in an MLTS context to “adequately identify the location of the calling party.” In the Indoor Location Fourth Report and Order, the Commission found that the definition of dispatchable location applicable to mobile carriers “strikes the appropriate balance between specificity and flexibility,” and therefore does not necessitate further specification of types of location information to be conveyed. We seek comment on applying the same approach for MLTS dispatchable location. We believe MLTS installers, managers, and operators will be able to identify situations in which street address is sufficient for first responders to quickly and accurately find the calling party. We also expect that street address would serve as a dispatchable location for the smallest enterprises. Nonetheless, should we specify the situations in which street address is not sufficient, and more granular location information is needed? For example, NENA's model federal MLTS legislation generally requires business MLTS to provide location information for each floor of each property served, as well as each 7,000 square feet of workspace beyond the first. Several commenters on the ECS NOI supported this approach to providing dispatchable location for MLTS. If commenters believe we should specify when more granular information is needed, what should be our criteria for identifying those situations? When more granular information is needed, what elements of location, in addition to room, floor, suite, or apartment number, could be used to locate a 911 caller using MLTS?

59. We agree with TIA that we “should be careful [not] to impose burdensome regulations that would eliminate the robust choices enjoyed by enterprises of all types in today's marketplace.” Accordingly, we do not propose to require implementation of specific location technologies or solutions but rather seek comment on functional requirements that would give participants in the MLTS marketplace flexibility to develop dispatchable location solutions. We believe that this approach will allow the entities affected by these proposed rules to implement them in a manner that is appropriate in terms of cost, enterprise size, site layout, and technical sophistication. We note that several states already place requirements on MLTS providers to obtain and convey location information that is more detailed than street address alone.

60. Feasibility of Conveying Dispatchable Location from MLTS. We tentatively conclude that it is feasible for 911 calls that originate from MLTS to convey dispatchable location to the appropriate PSAP, as several commenters to the ECS NOI indicate that they are already offering methods for dynamically determining and conveying an MLTS end user's location. We seek comment on this tentative conclusion. We observe that potential dispatchable location solutions for MLTS include solutions that require the customer to identify their own location and solutions that calculate a location by leveraging data available from the 911 caller's device and the network.

61. We also seek comment on whether additional dispatchable location solutions can be implemented for MLTS. Are there technical elements necessary for supporting dispatchable location that are shared by these solutions? Do technical elements differ across dispatchable location solutions, and if so, how? Are the required technical elements consistent across types of MLTS solutions, including on-premises solutions, hosted cloud solutions, and over-the-top application-based solutions? Are the required technical elements shared by legacy MLTS and IP-based MLTS, and if not, should differing requirements be placed on them? In its comments on the ECS NOI, West Safety observed that “[l]egacy-based solutions may not be able to support E9-1-1 routing for users accessing the ECS remotely.” We seek comment on that observation. Should we place differing requirements on premises-based, cloud-based, and over-the-top application-based solutions? Should we require MLTS to convey particular types of location information, such as room number or floor number, when it is available? If an MLTS handles calls initiated by remote users, e.g., off-site workers, should we require it to convey the remote user's location information?

62. We seek comment on whether the technical elements necessary for conveying dispatchable location with a 911 call are currently available in MLTS that are deployed today. We observe that several MLTS offered today provide 911 location solutions that are capable of conveying dispatchable location to PSAPs. Can currently-deployed MLTS that do not support provision of dispatchable location be upgraded to do so? If they can be upgraded, what would those upgrades entail, and what would they cost? For support of dispatchable location, what technical elements must be present in MLTS-related hardware, such as handsets, the device on which a softphone or voice application is installed, or other elements of the system? Which elements can be supported with updates to software or applications? If some MLTS in use today are not capable of supporting dispatchable location, we seek comment on whether those systems should be exempted from a dispatchable location requirement. For example, should we adopt compliance date provisions that track the provisions of Kari's Law as discussed above? Should we adopt disclosure requirements for grandfathered MLTS that are not subject to the rules? What should such disclosure rules require?

63. We also seek comment on the steps that an MLTS manager or operator must take, if any, to ensure that dispatchable location is conveyed to the PSAP. What is the most effective, least burdensome means to ensure that this happens? For example, some commenters on the ECS NOI suggest that managers of cloud-based MLTS are in a unique position to administer, maintain, and update location information for the enterprise. Should we adopt rules requiring MLTS managers to provision location information for the enterprise to the MLTS operator? To what extent does our legal authority under these new statutes or our existing authority extend to such entities? What information should be initially provisioned and how frequently should we require that information to be updated? What are the costs associated with such provisioning and updating? For situations in which MLTS operators are capable of calculating a dispatchable location by inputting one or more sources of device-generated location data into a location information server, what requirements, if any, should we place on (1) MLTS manufacturers and importers; (2) sellers and lessors; (3) MLTS installers, managers, and operators; and (4) communications service providers to ensure that this information or the resulting dispatchable location information is conveyed to the PSAP?

64. Although RAY BAUM'S Act directs the Commission to consider rules to ensure that dispatchable location is conveyed with 911 calls, there may be instances where location information that does not meet the definition of dispatchable location could still be useful to PSAPs and first responders, either as supplemental information to validate the dispatchable location or as an alternative in instances where dispatchable location information is not available. We therefore believe that our rules and policies should not preclude—and in fact should allow and encourage—potential alternatives to dispatchable location. We seek comment on this view. Could other types of location information (for example, x/y/z coordinates) be conveyed with a 911 call originating from MLTS? If we adopt dispatchable location requirements, should we allow provision of x/y/z/coordinates or other approaches to conveying location information to be alternatives to dispatchable location? We also seek comment on the usefulness of x/y/z coordinates to PSAPs and first responders for responding to MLTS 911 calls. Are they currently equipped to receive and use such information?

65. We also seek comment on whether there are other sources of location information, such as the National Emergency Address Database (NEAD), the location database being developed by the major mobile carriers to provide dispatchable location for indoor mobile 911 calls, that could potentially assist MLTS managers and operators in determining the dispatchable location of MLTS end users. Could MLTS managers and operators leverage these other sources of location information? What actions, if any, should we take to facilitate use of the NEAD and other location information sources for MLTS managers and operators? With respect to the NEAD in particular, are there obligations that should be placed on entities that seek to access the NEAD? As it has been contemplated that dispatchable location information from third-party sources will be integrated into the NEAD, we seek comment on whether MLTS managers and operators are positioned to contribute dispatchable location reference points to the database. If they are capable of making such contributions, should they be required to do so as a condition of leveraging the NEAD? Similarly, should they required to contribute to the operating costs of the NEAD as a condition of leveraging it?

2. Fixed Telephony Providers

66. Section 64.3001 of the Commission's rules requires all telecommunications carriers, including fixed telephony providers, to transmit all 911 calls to a PSAP, to a designated statewide default answering point, or to an appropriate local emergency authority. Section 64.3001 does not require telecommunications carriers to convey the location of the caller with the call, and there is no Commission 911 location rule applicable to fixed telephony carriers. However, pursuant to applicable state law, fixed telephony carriers typically provide validated street address information in conjunction with their customers' 911 calls.

67. We propose to amend our rules to require providers of fixed telephony services to provide dispatchable location with 911 calls. Fixed telephony carriers already provide validated street address information, which is likely sufficient in most cases, such as single family dwellings, to satisfy a dispatchable location requirement. However, dispatchable location as defined in RAY BAUM'S Act includes additional elements such as floor level and room number that may be necessary to locate the caller. We also believe that including fixed telephony carriers in our consideration of dispatchable location requirements at the federal level is consistent with the “all platforms” approach sought by Congress in the RAY BAUM'S Act, while omitting them could create the risk of gaps in the availability of location information. We seek comment on this approach.

68. We seek comment on whether it is technically feasible for fixed telephony carriers to convey dispatchable location with a 911 call. In many instances, as noted above, fixed telephony 911 calls from single family homes, feasibility appears to be established because fixed telephony carriers already provide validated street address information to the PSAP and first responders do not typically require additional room or floor level information. We seek comment on the extent to which fixed telephony carriers also provide other information, such as floor level and room number, for 911 calls from multi-story buildings and similar environments. How frequently do fixed telephony 911 calls convey only street addresses where additional information would be needed to locate the caller? What obstacles exist, if any, to fixed telephony carriers conveying dispatchable location to PSAPs? If obstacles exist, how could they be overcome, and at what cost? Could the NEAD, similar databases, or other sources of location information assist fixed telephony carriers in providing dispatchable location with 911 calls? What obligations, if any, should be placed on fixed telephony carriers that seek to access the NEAD? If so, what steps could the Commission take, if any, to facilitate the use of such databases by fixed telephony providers? Are there any alternatives to dispatchable location that fixed telephony carriers could use to provide in-building location information beyond street addresses, e.g., coordinate-based information?

3. Mobile Carriers

69. The E911 location accuracy rules applicable to mobile 911 voice service, set forth in Section 20.18 of our rules, provide that mobile carriers can meet our accuracy requirements by either conveying dispatchable location or coordinate-based location information. Because we have already incorporated dispatchable location into our E911 rules for mobile voice service, and mobile carriers are developing dispatchable location solutions based on those rules, we do not consider further changes in this proceeding to existing dispatchable location requirements. We note that this is consistent with RAY BAUM'S Act, which states that the Commission is not required to “reconsider any information or conclusion” made in proceedings prior to the statute's enactment.

70. With respect to text-to-911, our rules require mobile carriers and other covered text providers to obtain location information sufficient to route text messages to the appropriate PSAP, but text providers are not required to convey location information to the PSAP for the purpose of locating the person sending the text. The Commission has previously asserted that this approach is only an interim solution, and that it intends to require the delivery of enhanced location information with texts to 911 as soon as it is technically feasible to do so.

71. The Commission has previously proposed a requirement that, no later than two years after the effective date of the adoption of final rules on enhanced location for 911 texts, covered text providers must deliver enhanced location information (consisting of the best available location that covered text providers could obtain from any available location technology or combination of technologies, including device-based location) with texts to 911. We seek to refresh the record on how enhanced location information can be generated and delivered with text messages to 911. Is it technologically feasible today to convey a dispatchable location, or other types of enhanced location information, to the appropriate PSAP when a text message is sent to 911? If not, what is the likely timeframe for covered text providers to achieve such capability? Is there completed, ongoing, or anticipated future standards work that would facilitate delivery of dispatchable location information by covered text providers? If it is technologically feasible, should we apply dispatchable location requirements to text-to-911 consistent with requirements applied to other platforms? What would be the cost of such a requirement? To the extent that some text-to-911 dispatchable location requirement would be feasible but should differ from that applicable to other platforms, commenters should explain the basis for any distinctions, what alternative(s) could work for text-to-911 dispatchable location, and why.

4. Interconnected VoIP Providers

72. The Commission's rules require interconnected VoIP providers to transmit Automatic Number Identification (ANI) and the caller's Registered Location with each 911 call. Interconnected VoIP providers must obtain a Registered Location, which is the most recent information that identifies the physical location of an end user, from each customer prior to the initiation of service. In addition, providers must enable end users to update their Registered Location at will and in a timely manner. The Registered Location of such calls must be made available to the appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority from or through an appropriate automatic location information database. The Commission has also previously sought comment on the possibility of interconnected VoIP services providing real-time automatic location information to support 911 calls from consumers that use interconnected VoIP services from mobile or portable devices, such as smartphones or laptops.

73. The Commission adopted the Registered Location requirement in 2005 to support the provision of location information from 911 callers that typically use interconnected VoIP service from a single fixed location, such as a residence (fixed VoIP), or that move from one fixed location to another (nomadic VoIP). Although RAY BAUM'S Act provides that the Commission is not required to reconsider E911 location rules adopted in prior proceedings, as discussed below, we believe that it is appropriate to consider revising our E911 rules for interconnected VoIP to require the provision of dispatchable location.

74. Fixed VoIP. With respect to fixed VoIP, we believe it is feasible for 911 calls that originate from interconnected VoIP services to convey dispatchable location to the PSAP, in that the current Registered Location obligations are sufficient for this purpose. In this respect, we note that the Registered Location information that is already conveyed with such calls today typically includes street address information, which should be sufficient for dispatchable location in the case of single family homes and small buildings where the PSAP and first responders do not require additional room or floor level information. In addition, interconnected VoIP providers can also enable customers in multi-story buildings and similar environments to provide room or floor level information as part of the Registered Location when needed. We seek comment on this proposal.

75. Nomadic VoIP. With respect to nomadic VoIP, we seek comment on whether Registered Location satisfies a dispatchable location requirement. In particular, we note that a Registered Location that was recorded when service was initiated is less likely to accurately identify the real-time location of an end user that moves frequently between home, work, and other locations. Is Registered Location a sufficient proxy for dispatchable location in a nomadic environment, where the relevant device is able to prompt the user for an updated location when it has been moved? We seek comment on what technical elements would be required in the end user's device and/or the service provider's network to support the provision of real-time dispatchable location as proposed, and the degree to which those technical elements are already in place. For example, as we have noted in the discussion of MLTS location in Section B1 above, there appear to be IP-based solutions currently available for providing MLTS dispatchable location dynamically in buildings, campuses, and similar environments. We seek comment on whether these solutions could also be leveraged by interconnected VoIP providers when their customers call 911 from such environments.

76. We note that in the Registered Location context the burden is on the end user to update the Registered Location whenever the end user moves from one location to another. We seek comment on whether nomadic interconnected VoIP providers have, or can develop in the near term, the means to provide automatic dispatchable location with 911 calls in lieu of conveying the customer's Registered Location. We believe that automatic provision of location is preferable because end users under stress in emergency situations may have difficulty providing manual updates and the updating process may delay the 911 call or subsequent location and dispatch. Therefore, we seek comment on the degree to which mechanisms exist for interconnected VoIP providers to dynamically determine the location of end users (1) when they are at home or their usual place of work, (2) when they move frequently between multiple locations, and (3) when they are at locations they do not regularly visit. How accurate is the location information acquired in these scenarios, and would it be sufficient to meet the proposed definition of dispatchable location? Are sources of reliable location information available to interconnected VoIP providers? Could the NEAD assist interconnected VoIP providers with dynamic determination of the location of end users? If so, what steps could the Commission take, if any, to facilitate the use of the NEAD by interconnected VoIP providers? What obligations, if any, should be placed on interconnected VoIP providers that seek to access the NEAD?

77. While we prefer to encourage the development of dispatchable location solutions that do not require manual end user updates, we recognize that such solutions may not be feasible or cost-effective in all circumstances. For example, as part of the 911 call session, if real-time dispatchable location information cannot be generated automatically, the VoIP provider may need to send an interactive query to the end user to confirm the location identified by the provider, and to correct the location if needed. To enable interconnected VoIP providers to appropriately balance technical feasibility, functionality, customer impact, and cost, we propose to allow providers flexibility in implementing dispatchable location solutions, and to fall back to Registered Location options when dispatchable location is not feasible. Thus, solutions may include, but are not limited to, determining the customer's location dynamically, pre-populating a previously-supplied Registered Location based on the network attachment point, or requesting a new Registered Location from the customer when the customer initiates a new connection or attachment to the network. We seek comment on this approach.

78. Finally, we seek comment on any alternative approaches that would achieve the same aims as the proposed rules. Are there mechanisms or best practices for refreshing or validating location information that should be encouraged or required? Are there alternatives to dispatchable location that interconnected VoIP providers could use to provide location information, e.g., coordinate-based information? We seek comment on whether these, or other approaches, would provide the greatest likelihood of conveying an accurate location to the PSAP while minimizing the burdens on the interconnected VoIP service provider and the end user.

5. Telecommunications Relay Services

79. Section 64.604 requires Text Telephone-based (TTY-based) TRS providers to use a system for incoming emergency calls that, at a minimum, automatically and immediately transfers the caller to an appropriate PSAP. Section 64.605 generally requires internet-based TRS to deliver emergency calls to an appropriate PSAP and to provide the location of the emergency. For some of these services, the service provider is required to ask callers for their location information at the beginning of the emergency call. For other emergency calls (specifically those that use a Video Relay Service (VRS) or IP Relay), the service provider must transmit location information to the PSAP in the form of a Registered Location, including for devices capable of being moved to a different location. The Commission modeled these requirements after the 911 location requirements for interconnected VoIP services discussed above. We observe that internet-based TRS and interconnected VoIP service face similar concerns regarding the ability to accurately locate end users that use a mobile or portable device.

80. As in our discussion of interconnected VoIP above, although RAY BAUM'S Act does not require reconsideration of previously adopted E911 location rules, we believe it is appropriate as part of the Act's “all-platforms” approach to consider revising our TRS E911 rules. Specifically, we seek comment on whether TRS providers can develop the means to provide updated dispatchable location. In particular, we seek comment on the feasibility of using existing Registered Location mechanisms to provide dispatchable location for fixed and nomadic VRS and IP Relay users, paralleling the rules we propose above for interconnected VoIP service. Is Registered Location sufficient in the fixed TRS environment? If a mechanism exists for manual updates by the user when a nomadic TRS device is used, is Registered Location sufficient to satisfy a dispatchable location requirement? As with VoIP, we also seek comment on the feasibility of having TRS devices and/or networks support the automatic provision of real-time dispatchable location without requiring registration or manual location updates by the end user. What technical elements would be required in the end user's device and/or the service provider's network to support this capability, and to what degree are such technical elements already in place? To what degree are TRS providers able to dynamically determine the location of end users (1) when they are at home or their usual place of work, (2) when they move frequently between multiple locations, and (3) when they are at locations they do not regularly visit? How accurate is the location information acquired in these scenarios, and would it be sufficient to meet the proposed definition of dispatchable location?

81. To enable TRS providers to balance technical feasibility, functionality, customer impact, and cost, we propose to allow TRS providers flexibility in implementing dispatchable location solutions, and to fall back to Registered Location options when real-time dispatchable location is not feasible. We seek comment on this approach. We also seek comment whether there are differences between internet-based TRS and interconnected VoIP that might require taking a different approach to TRS dispatchable location from the approach proposed for interconnected VoIP. As with interconnected VoIP, we seek comment on whether the NEAD or a similar database could assist TRS providers in implementing dispatchable location solutions. If so, what steps could the Commission take, if any, to facilitate the use of such databases by TRS providers? What obligations, if any, should be placed on TRS providers that seek to access the NEAD? Finally, we seek comment on any alternative approaches that would achieve the same aims as our proposed rules for TRS.

6. Other 911-Capable Services

82. We seek comment on whether we should consider adopting 911 rules for any other communications services that are not covered by existing 911 rules but provide the capability for users to make a 911 call. RAY BAUM'S Act defines a “911 call” as a voice call that is placed, or a message that is sent by other means of communication, to a PSAP for the purpose of requesting emergency services. What communications services that are not covered by existing 911 rules are capable of making 911 calls that fall within this definition? Are there any services that provide one-way voice communications that are capable of making such a 911 call? How often do consumers use these services to call 911? How do these services complete calls to PSAPs? What kinds of information, including callback numbers and location information, is or could be conveyed to PSAPs with these calls? What are PSAPs' experiences in answering these calls? What do consumers using these services understand about the limitations on any 911 services provided? Are these 911 calls effective at conveying location information to the PSAP? Do any specific communication services from which these 911 calls originate create difficulties in locating the caller? Is there consistency in the way calls originating from a specific communication service are received and are presented to the PSAP? Would outcomes for 911 callers be improved if we adopted 911 rules for these communications services that parallel existing rules, including any requirements for conveying dispatchable location? Would new rules that are specifically tailored for those communications services be more effective at improving outcomes?

83. We observe that some outbound-only VoIP services partner with businesses that offer 911 smartphone applications that allow consumers to make calls to 911. Some 911 stakeholders have expressed concerns that calls received from these services may route to the incorrect PSAP, result in fraudulent calls, lack critical location information capabilities, and place the 911 caller at risk. Our current rules do not require outbound-only VoIP services to support 911 or convey dispatchable location with 911 calls. However, in 2011 the Commission sought comment on expanding 911 obligations to providers of outbound-only VoIP services. In that case, the Commission proposed to amend the definition of the subject services to include any service that: (1) Enables real-time, two-way voice communications; (2) requires an internet connection from the user's location (as opposed to a broadband connection); (3) requires internet protocol-compatible customer premises equipment; and (4) permits users to terminate calls to all or substantially all United States E.164 telephone numbers.

84. Based on the concerns noted above and in light of our previous proposal, we seek comment on expanding the scope of those IP-based services subject to our 911 rules to include not only interconnected VoIP, but to also include “911 VoIP Services,” defined as those services that enable real-time, two-way voice communications that require internet protocol-compatible customer premises equipment and permit users generally to initiate a 911 call, even if the service does not permit users generally to receive calls that originate on the PSTN. Is there any reason to exempt outbound-only VoIP services that allow 911 calls from our 911 requirements simply because the service is incapable of receiving an incoming call from the PSTN? Does the public expect all VoIP services that allow the completion of 911 calls to meet the same minimum standards, without regard to whether the service can receive an incoming call? We seek comment on our proposal.

7. Additional Considerations

85. For each of the communications service categories discussed above, we seek comment on common issues that are related to the implementation of dispatchable location requirements for 911 calls. We seek comment on how dispatchable location requirements for MLTS may interact with dispatchable location requirements for other 911-capable services. Are there situations in which the value of dispatchable location to first responders is diminished due to the availability of on-site notification to enterprises, or vice versa? In what situations, if any, should communications service providers be exempted from a dispatchable location requirement? Should providers be allowed or required to provide other types of location information, e.g., coordinate-based information, in addition to or as an alternative to satisfying a dispatchable location requirement? If communications services and/or certain types of providers (e.g., of a specific size, or with a specific number of consumers) are exempted from dispatchable location requirements, should we require them to provide consumer disclosure regarding the limitations of their 911 location capabilities? We also ask commenters to identify voluntary best practices that can improve the effectiveness of acquiring a 911 caller's dispatchable location.

86. As noted above, we believe MLTS installers, managers, and operators will be able to identify situations in which street address is sufficient for first responders to quickly and accurately find the calling party. We also expect that street address will suffice as a dispatchable location for the smallest enterprises. Accordingly, we do not propose size-based exceptions to the dispatchable location requirement. We seek comment on this approach.

8. Compliance Dates

87. For all communications platforms that are to be covered by the dispatchable location requirements proposed in this NPRM, we propose to require compliance on the same date as our proposed implementation of Kari's Law, i.e., February 16, 2020. We tentatively conclude a uniform compliance date will promote efficiency by enabling MLTS manufacturers to implement dispatchable location upgrades on the same timeline as any upgrades needed to comply with the direct dial and notification requirements of Kari's Law. In addition, we tentatively conclude that applying the same compliance date to dispatchable location requirements across all platforms will encourage the development of common dispatchable location solutions that can support multiple platforms. We seek comment on this approach, as well as alternatives. With respect to MLTS, is it reasonable to anticipate that by the February 16, 2020 compliance date for Kari's Law, newly manufactured MLTS will be capable of conveying dispatchable location with 911 calls? Are there dispatchable location solutions that can be widely and inexpensively implemented into MLTS being manufactured today? Do technical standards currently exist that would be appropriate for governing conveyance of dispatchable location from MLTS, or do such standards need to be developed? If the latter, how much time is needed to develop those standards, and who should develop them?

88. We also seek comment on our proposal to apply the same February 2020 compliance date for our proposed dispatchable location requirements for fixed telephony, interconnected VoIP, and TRS. We also seek comment on alternatives. Is there any reason to establish a compliance date or dates for these services that is either earlier or later than the proposed compliance date for implementation of Kari's Law? Should compliance for different service types be phased as a way to require greater accuracy over time or to provide additional time to small businesses to come into compliance? Will PSAPs be capable of receiving dispatchable location by February 16, 2020, or are there additional steps that either some or all PSAPs must take to achieve this capability? Are existing class of service definitions sufficient to support PSAP receipt of dispatchable location or must new ones be developed? Are there standards-based approaches that could be taken to improve the technological capabilities of emergency calling (particularly as it expands beyond PSTN calls) while also improving the economics of enabling effective emergency calling? Should international roaming scenarios be taken into consideration? Are other countries/regions of the world developing emergency calling standards that have addressed location accuracy, routing to the appropriate PSAP, and provision of dispatchable location in the context of interconnected VoIP and other new technologies?

9. Comparison of Benefits and Costs

89. We seek comment on whether providing dispatchable location for 911 calls from MLTS and other communications services would improve emergency response and the health and safety of the public, and whether this benefit would exceed the cost of providing it. Commenters to the ECS NOI argued that the life-saving benefits of adopting E911 requirements for MLTS are apparent. For example, NASNA asserted that just as E911 for landline, wireless, and VoIP has resulted in improvements in the speed at which emergency responders are able to reach the caller, so would E911 for ECS. NASNA stated, “The magnitude of this benefit would be analogous to the well-studied, documented and proven benefits of E911 in general.”

90. The scale of any potential benefits depends on the magnitude of the problem we are facing. Currently, how common are 911 calls from MLTS and other communications platforms that fail to convey any location information or that convey location information that is too imprecise or inaccurate to assist PSAPs and first responders in timely locating the caller? What is the expected lifespan of such systems? Is there any reason to expect that this situation will improve by 2020? If so, by how much? What cost differential will our proposed rules impose on MLTS and other systems purchased beginning in 2020? How many systems, at what additional cost, will be impacted? We seek comment on the 2013 decision attached to the California Public Utilities Commission (CPUC) comments on the ECS NOI, which found that potentially 70 percent of California's PBX MLTS systems were not at the time provisioned to display accurate caller location information to any PSAP and that only “350 of AT&T California's customers with PBX phone stations in 2007 had provisioned [PS/ALI] location information records in AT&T California's [E911] database.” To what extent do these findings accurately reflect caller location information provided by MLTS? Could the results of these findings be extrapolated more broadly (e.g., outside of California)? How often are those calls routed to the wrong PSAPs due to poor or nonexistent location information?

91. We also seek comment on the length and impact of delays in emergency response due to a lack of location information. RedSky asserts that “[p]lacing a detailed, accurate location record in the hands of emergency responders can save 3-5 minutes in response time particularly in complex environments.” Is 3-5 minutes a reasonable estimate of the improvement in response time? What are the consequences of those delays for a person needing emergency response? Can those consequences be quantified? Are there data on the speed of emergency response for calls that convey alternatives to dispatchable location, such as x/y/z coordinates? Are there other benefits that have accrued or could accrue in those systems and services that convey dispatchable location to PSAPs and first responders, such as reduced time spent on re-routing calls or arriving at the correct location? Are there any MLTS or other communications services (e.g., very small facilities) that would not benefit from conveying dispatchable location, or for whom the benefit would not exceed the cost?

92. We seek comment on the magnitude of the benefits to the public when dispatchable location is conveyed with a 911 call from MLTS and other communications services identified in this NPRM. We anticipate that the increase in location accuracy that results from the use of dispatchable location will reduce the arrival time of ambulances for some 911 callers at least as much as was accomplished by the mobile location rules adopted in the Indoor Location Fourth Report and Order. In that Report and Order, we found that the location accuracy improvements adopted for mobile 911 calls had the potential to save approximately 10,120 lives annually for an annual benefit of approximately $92 billion? Based on available 911 call volume data, we estimate that approximately 75% of 911 calls come from mobile phones, which already are required to convey a dispatchable location. However, we believe the remaining 25% of calls to which our proposed rules would apply will realize benefits. Because three times as many calls come from mobile phones as from non-mobile sources, we estimate that our proposed rules have the potential to save a maximum of one third of the 10,120 lives that were projected to be saved annually by the mobile location rules adopted in the Indoor Location Fourth Report and Order, or 3,373 lives annually. However, because some providers already convey location information that is equivalent to dispatchable location, we expect that our dispatchable location rules will save considerably fewer lives. Even if we were to assume our proposed rules would save only one twentieth of the lives that we projected would be saved by the mobile location rules, the proposed rules would save 506 lives annually. We rely on the U.S. Department of Transportation's estimate that the “Value of a Statistical Life” (VSL), defined as “the additional cost that individuals would be willing to bear for improvements in safety (that is, reductions in risks) that, in the aggregate, reduce the expected number of fatalities by one,” is $9.6 million. In doing so, we estimate that the 506 lives saved by the proposed rules multiplied by the VSL establishes a benefit floor of $4.9 billion. We seek comment on whether our estimate is reasonable. What other benefits can be expected to accrue, such as (but not limited to) reduced complications from medical issues, reduced damage to property, increased likelihood of forestalling crime and apprehending suspects, increased confidence in the 911 system and emergency responders? How can we assign a dollar figure to evaluate the magnitude of these and other benefits? We seek estimates of the time-saving value of dispatchable location and data demonstrating the value of a reduction in emergency response time.

93. We observe that 911 location solutions that are capable of conveying dispatchable location to PSAPs are already offered by several MLTS market participants. Further, several states already place requirements on MLTS providers to obtain and convey location information that is more detailed than street address alone, and we therefore conclude that MLTS manufacturers are producing and widely selling equipment that is capable of complying with our proposed rules. Are there any cases in which currently-available equipment will not be suitable? In addition, to comply with current rules, interconnected VoIP service providers and internet-based TRS providers today obtain customers' Registered Location, which we believe would likely be sufficient to satisfy our proposed dispatchable location requirements in many circumstances. Because these dispatchable location-capable solutions and equipment are already being widely offered by MLTS manufacturers, installers, and operators, we believe that the implementation costs of our proposed dispatchable location rules to these entities would be negligible in most respects. We also believe that our approach of granting flexibility in satisfying our proposed rules minimizes the potential cost of compliance. We seek comment on these observations and tentative conclusions.

94. We tentatively find that three aspects of our proposed rules may lead to additional implementation costs: (1) Implementation of the proposed dispatchable location requirement by MLTS managers; (2) implementation of the proposed requirement for interconnected VoIP, VRS, and IP Relay providers to identify when a customer uses the service from a new location and update the customer's location information; and (3) the proposed requirement for outbound-only VoIP service providers or other 911 VoIP service providers to comply with the Part 9 rules. First, we seek comment on any additional costs that our proposed rules may impose on MLTS managers. In comments responsive to the ECS NOI, for example, RedSky stated that it can provision its E911 system service for as little as a $2,500.00 one-time service installation fee and $100 per month. The service gives the ECS access to over 5,500 PSAPs in the U.S. and all regional ALI (Automatic Location Information) databases, as well as providing 911 call notifications to enterprise security personnel. West Safety stated that the 2010 MLTS workshop report of the California PUC concluded that third-party ECS 911 solutions “are going down in cost and are available for under $5,000” with “[s]mall business solutions as low as $1,250 for a one-time implementation fee and $65 to $100 per month in recurring fees.” However, because our proposed dispatchable location rules would only apply to those MLTS managers that install MLTS after February 16, 2020, at which time all MLTS must be dispatchable location-capable, we tentatively find that the only costs for which our rules would be responsible are marginal differences in MLTS price that are attributable to manufacturer efforts to comply with the rules. Because many MLTS manufacturers are producing and widely selling equipment that is capable of complying with our proposed rules, we anticipate that price increases will be minimal.

95. We seek comment on how our rules may affect the price of MLTS, especially recurring costs. We anticipate that the most significant costs would be for initial and recurring costs of provisioning location information to MLTS operators, but tentatively find that the cost of such provisioning will be significantly less than the benefits that arise from adopting the rule. Nearly 80% of businesses in the United States have fewer than ten employees. While we acknowledge that enterprises with few employees do not always have those employees work in close proximity to one another, we anticipate that a street address would likely satisfy the definition of dispatchable location for most of those businesses and would be available to the MLTS operator at no cost to the MLTS manager.

96. We expect larger companies to face some initial location provisioning costs. Because many MLTS manufacturers are producing and widely selling equipment that is capable of complying with our proposed rules, we tentatively find that the primary cost to MLTS managers is the cost of provisioning the location information in the MLTS. To estimate the cost to these enterprises, we seek to estimate the number of employees at the affected enterprises, determine the number of lines and the amount of time needed annually to provision dispatchable location for those lines, and finally determine the total cost for workers paid at an hourly wage to complete the task. We tentatively estimate the number of affected telephone lines in larger (>10) enterprises from Small Business Administration data, which indicates that there are approximately 109 million employees at larger firms. We initially estimate there are 1.1 employees per installed line, resulting in approximately 99.1 million lines. At an incremental effort of 1 minute per line and a $30 per hour labor rate, this results in a maximum one-time cost of approximately $49.6 million. Significantly, this cost assumes firms will need to create an employee phonebook database that duplicates that used in general enterprise systems, such as Microsoft Outlook. We expect that such duplication will be unnecessary for many enterprises. We also expect that within a few years, this setup cost will become minimal because manufacturers of MLTS and general enterprise systems will increasingly connect their systems, setting up a single phonebook database and making duplication unnecessary. We seek comment on our proposed methodology and estimates, including on the existing and future availability to connect general enterprise systems to MLTS.

97. Larger businesses that use MLTS are likely to initially face recurring costs to maintain a separate location database. To estimate the cost to these enterprises, we seek to estimate the number of lines at the affected enterprises, determine the number of provisioning changes and the amount of time needed annually to make those changes for those lines, and finally determine the total cost for workers paid at an hourly wage to complete the task. We tentatively estimate that entering the dispatchable address for a move, add, or change to an MLTS endpoint will take 1 minute of a manager's time. An industry rule-of-thumb is that 5% of endpoints will require a change of provisioning (moves, adds, or changes) in a year. With 99.1 million total incremental lines subject to this rule, 5% of this figure is approximately 5 million changes per year. At 1 minute per modification and $30 per hour labor rate, this results in a maximum annual cost of $2.5 million to keep the location databases up to date. As noted above, we expect this incremental cost will become minimal over time as manufacturers of MLTS and general enterprise systems start connecting their systems. At that point, enterprise information technology staff will only need to provision a single line when an employee moves. In addition, as noted above, several states already place requirements on MLTS providers to obtain and convey location information that is more detailed than street address alone. For those states, the incremental cost of our rules is potentially zero. We seek comment on these estimates, including on the existing and future availability to connect general enterprise systems to MLTS.

98. RedSky discusses the costs for providing E911 for both legacy and IP-based ECS, stating that “IP-based systems have a cost advantage over legacy systems because of their ability to use [Emergency Response Location] ERLs and [Emergency Location Information Numbers] ELINs and segment their networks into logical subnets or zones.” We seek comment on whether our proposed rules will hasten the ongoing transition to IP-based MLTS, and whether this transition will reduce the costs to MLTS managers over time, including the costs of provisioning location information to MLTS operators. If so, by how much? We seek additional cost data relative to provisioning dispatchable location from MLTS and other communications services identified in this NPRM.

99. Second, we seek comment on the costs of implementing our proposed requirement that interconnected VoIP, VRS, and IP Relay services identify when a customer uses the service from a new location and update the customer's location information. To estimate the cost to these service providers, we seek to estimate the amount of time required to develop and test the necessary software number and determine the total cost for workers paid at hourly wages to complete the task. We tentatively estimate a maximum initial cost of $8,280,000 industry-wide. We tentatively assume that eight months will be a sufficient time period for developing and testing and deploying the software modifications required for updating customer location information, as this would enable service providers to begin to comply with our proposed rules after their final adoption and finish before the February 16, 2020 compliance date. We estimate that six of the eight months will be devoted to software development and deployment, and two of the eight months will be devoted to testing and debugging. We estimate that the maximum cost of developing any software update necessary to comply with the rules we propose today for each interconnected VoIP-related entity, VRS provider, and IP Relay provider would be $92,000, the cost of compensating one full-time software engineer for six months of labor. We estimate that the cost of testing these modifications (including integration testing, unit testing, and failure testing), which requires as many as 12 software engineers working for two months, will be $368,000 for each interconnected VoIP-related entity, VRS provider, and IP Relay provider. Thus, we estimate that the total cost of software modifications for each interconnected VoIP-related entity, VRS provider, and IP Relay provider will be $460,000. We estimate that this requirement will be implemented by 12 interconnected VoIP-related entities and 6 VRS providers and IP Relay providers. Therefore, the total cost to the industry will be $8,280,000 (18 organizations times $460,000 per organization).

100. We further observe that some VoIP-based MLTS will not need to implement this functionality, as they are already capable of obtaining the customer's dispatchable location at the time a 911 call is initiated without requiring additional customer action. We seek comment on the extent to which interconnected VoIP, VRS, and IP Relay services already are able to identify when a customer uses the service from a new location and update the customer's location information. We seek comment on all of the assumptions upon which these cost estimates are based and on any recurring costs that interconnected VoIP, VRS, and IP Relay and service providers would incur in complying with our proposed rules.

101. Third, we seek comment on the prospective costs to outbound-only VoIP service providers or other 911 VoIP service providers for complying with the proposed Part 9 rules, including the proposed dispatchable location rules. We specifically seek comment on how the costs of compliance for these providers may differ from the costs to interconnected VoIP providers that the rules already cover, including increased costs that arise from unique technical obstacles and decreased costs that arise from technical solutions for complying with our rules being well-established and widely available.

102. We seek comment on any additional costs and benefits that arise from our proposed rules that we have not considered. For example, how would dispatchable location requirements for MLTS and other communications services affect PSAPs? How would such requirements affect customers of those services?

C. Consolidating the Commission's 911 Rules

103. Historically, the Commission has taken a service-by-service approach to establishing 911 obligations. As a result, our 911 rules are today scattered throughout different parts of Title 47. For example, our interconnected VoIP 911 rules are in Part 9, our 911 reliability rules are in Part 12, our mobile E911 rules are in Part 20, our emergency call center requirements for Mobile-Satellite Service (MSS) are in Part 25, and our telecommunications carrier obligations and emergency calling requirements for TRS providers are in Part 64. We believe that this siloed approach to the organization of our 911 rules does not adequately reflect that all of the individual services that enable 911 calls are functional parts of a single system. Moreover, we expect that the 911 system will become increasingly integrated as technology evolves and stakeholders migrate from legacy 911 to NG911.

104. Our initiation of this proceeding to develop 911 rules for MLTS and dispatchable location requirements for all 911-capable platforms provides us with a unique opportunity to simplify and streamline our 911 rules in the process. Therefore, in addition to proposing adoption of MLTS and dispatchable location rules as discussed above, we propose to consolidate all of our existing 911 rules in a single rule part, i.e., Part 9, to the extent practicable. We also propose to simplify and streamline the rules in some instances and to eliminate corresponding duplicative rules in other rule parts. We believe the proposed rule consolidation will help to minimize the burden on small entities subject to the Commission's 911 rules by making it easier to identify and comply with all 911 requirements.

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

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

106. Aside from the proposed MLTS and dispatchable location rules discussed in preceding sections, our proposed rule revisions would mainly entail consolidating our existing 911 rules without making substantive changes, but there are some exceptions. Specifically, consolidating the rules will entail making certain conforming and technical changes. For example, in instances where there are minor differences in the definitions of common 911-related terms in different rule parts, we propose to harmonize these definitions for purposes of providing a uniform definition in Part 9. In addition, we propose to remove a few obsolete 911 rules, e.g., rules referencing one-time information collections that have been completed, rather than recodify them in Part 9. We also seek comment on whether we should move Section 22.921 of the rules, which addresses 911 call processing procedures for analog telephones in the Cellular Radiotelephone Service, into Part 9 or whether that rule has become obsolete and should be removed. Further, we propose to update cross-references in other rule parts as needed, and to correct erroneous internal cross-references that appear in our existing rules.

107. We explain these proposed changes in greater detail in Appendix C of the NPRM, which contains conversion tables that track the proposed disposition of each rule in the consolidation process. We have prepared a separate table for each current rule part that would be affected by the proposed rule consolidation. The table identifies the existing rule section, the section in Part 9 where it would be located after the consolidation, and whether the rule would also be removed from its current location. In addition, to help interested parties quickly identify the source of each rule in proposed Part 9, Appendix C of the NPRM also contains a conversion table that lists the proposed Part 9 rules in numerical order and lists the current rule or rules from which each proposed new rule is derived.

108. We do not include some 911-related rules in our consolidation proposal, where such rules either do not relate to core 911 obligations or are integrated with non-911-related rules in such a way that removing the 911-related rules and transferring them to Part 9 would be cumbersome and counterproductive. For example, Part 4 of our rules contains rules relating to network outage reporting, including some rules that specifically address outages affecting 911 facilities. Because the Part 4 rules constitute an integrated whole, we do not propose to transfer or consolidate the 911-specific rules currently contained in Part 4.

109. Finally, we invite commenters to identify any additional rules that they recommend for consolidation in Part 9, as well as any rules that should be updated in light of our proposal.

IV. Procedural Matters

110. Ex Parte Presentations. The proceeding shall be treated as a “permit-but-disclose” proceeding in accordance with the Commission's ex parte rules. Persons making ex parte presentations must file a copy of any written presentation or a memorandum summarizing any oral presentation within two business days after the presentation (unless a different deadline applicable to the Sunshine period applies). Persons making oral ex parte presentations are reminded that memoranda summarizing the presentation must (1) list all persons attending or otherwise participating in the meeting at which the ex parte presentation was made, and (2) summarize all data presented and arguments made during the presentation. If the presentation consisted in whole or in part of the presentation of data or arguments already reflected in the presenter's written comments, memoranda or other filings in the proceeding, the presenter may provide citations to such data or arguments in his or her prior comments, memoranda, or other filings (specifying the relevant page and/or paragraph numbers where such data or arguments can be found) in lieu of summarizing them in the memorandum. Documents shown or given to Commission staff during ex parte meetings are deemed to be written ex parte presentations and must be filed consistent with rule 1.1206(b). In proceedings governed by rule 1.49(f) or for which the Commission has made available a method of electronic filing, written ex parte presentations and memoranda summarizing oral ex parte presentations, and all attachments thereto, must be filed through the electronic comment filing system available for that proceeding, and must be filed in their native format (e.g., .doc, .xml, .ppt, searchable .pdf). Participants in this proceeding should familiarize themselves with the Commission's ex parte rules.

111. Comment Filing Procedures. Pursuant to §§ 1.415 and 1.419 of the Commission's rules, 47 CFR 1.415, 1.419, interested parties may file comments and reply comments on or before the dates indicated on the first page of this document. Comments and reply comments may be filed using the Commission's Electronic Comment Filing System (ECFS). See Electronic Filing of Documents in Rulemaking Proceedings, 63 FR 24121 (1998).

• Electronic Filers: Comments may be filed electronically using the internet by accessing the ECFS: http://apps.fcc.gov/​ecfs/​.
• Paper Filers: Parties who choose to file by paper must file an original and one copy of each filing. If more than one docket or rulemaking number appears in the caption of this proceeding, filers must submit two additional copies for each additional docket or rulemaking number.

Filings can be sent by hand or messenger delivery, by commercial overnight courier, or by first-class or overnight U.S. Postal Service mail. All filings must be addressed to the Commission's Secretary, Office of the Secretary, Federal Communications Commission.

• All hand-delivered or messenger-delivered paper filings for the Commission's Secretary must be delivered to FCC Headquarters at 445 12th St. SW, Room TW-A325, Washington, DC 20554. The filing hours are 8:00 a.m. to 7:00 p.m. All hand deliveries must be held together with rubber bands or fasteners. Any envelopes and boxes must be disposed of before entering the building.
• Commercial overnight mail (other than U.S. Postal Service Express Mail and Priority Mail) must be sent to 9050 Junction Drive, Annapolis Junction, MD 20701.
• U.S. Postal Service first-class, Express, and Priority mail must be addressed to 445 12th Street SW, Washington DC 20554.

112. People with Disabilities: To request materials in accessible formats for people with disabilities (braille, large print, electronic files, audio format), send an email to [e-mail] or call the Consumer & Governmental Affairs Bureau at 202-418-0530 (voice), 202-418-0432 (tty).

113. Regulatory Flexibility Analysis. As required by the Regulatory Flexibility Act of 1980, see 5 U.S.C. 603, the Commission has prepared an Initial Regulatory Flexibility Analysis (IRFA) of the possible significant economic impact on small entities of the policies and rules addressed in this document. The IRFA is set forth in Appendix B of the NPRM. Written public comments are requested on the IRFA. These comments must be filed in accordance with the same filing deadlines as comments filed in response to this NPRM as set forth herein, and they should have a separate and distinct heading designating them as responses to the IRFA. The Commission's Consumer and Governmental Affairs Bureau, Reference Information Center, will send a copy of the NPRM, including this IRFA, to the Chief Counsel for Advocacy of the Small Business Administration (SBA).

114. Initial Paperwork Reduction Act Analysis. This NPRM may contain proposed new and modified information collection requirements. The Commission, as part of its continuing effort to reduce paperwork burdens, invites the general public and the Office of Management and Budget (OMB) to comment on the information collection requirements contained in this document, as required by the Paperwork Reduction Act of 1995 (PRA). In addition, pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 U.S.C. 3506(c)(4), we seek specific comment on how we might “further reduce the information collection burden for small business concerns with fewer than 25 employees.”

V. Initial Regulatory Flexibility Act

115. As required by the Regulatory Flexibility Act of 1980, as amended (RFA), the Commission has prepared this Initial Regulatory Flexibility Analysis (IRFA) of the possible significant economic impact on a substantial number of small entities by the policies and rules proposed in the NPRM. Written public comments are requested on this IRFA. Comments must be identified as responses to the IRFA and must be filed by the deadlines for comments provided in paragraph 113 of the NPRM. The Commission will send a copy of the NPRM, including this IRFA, to the Chief Counsel for Advocacy of the Small Business Administration (SBA). In addition, the NPRM and IRFA (or summaries thereof) will be published in the Federal Register.

A. Need for, and Objectives of, the Proposed Rules

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

117. The NPRM proposes to implement Kari's Law by adopting direct dial and on-site notification rules governing calls to 911 made from MLTS. As required by RAY BAUM'S Act, the Commission also considers the feasibility of requiring dispatchable location for 911 calls from MLTS and other technological platforms that currently complete calls to 911. The NPRM proposes establishing a dispatchable location requirement for MLTS 911 calls, which would apply contemporaneously with the February 16, 2020 compliance date of Kari's Law. Additionally, in keeping with the directive in RAY BAUM'S Act to address dispatchable location for 911 calls “regardless of the technological platform used,” the NPRM proposes to add dispatchable location requirements to the Commission's existing 911 rules for fixed telephony providers, interconnected Voice over internet Protocol (VoIP) providers, and Telecommunications Relay Services (TRS). The NPRM also considers the feasibility of alternative location mechanisms for MLTS and other services that could be used as a complement to dispatchable location or as a substitute when dispatchable location is not available. Additionally, the NPRM considers whether dispatchable location rules should be extended to other communications services that are not covered by existing 911 rules but are capable of making a 911 call.

118. Finally, the NPRM proposes to take this opportunity to consolidate the Commission's existing 911 rules, as well as the direct dialing and dispatchable location rules proposed in this NPRM, into a single rule part. The Commission historically has taken a service-specific approach to 911, with the result that 911 requirements for different services are scattered across different sections of the agency's rules. We believe that consolidating our 911 rules from these various rule sections into a single rule part will further the goal of recognizing that all the components of 911 function as part of a single system and will enable service providers, emergency management officials, and other stakeholders to refer to a single part of the Commission's rules to more easily ascertain all 911 requirements.

B. Legal Basis

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

C. Description and Estimate of the Number of Small Entities To Which the Proposed Rules Will Apply

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

142. The NPRM proposes rules and seeks comment on rule changes that will affect the reporting, recordkeeping and/or other compliance requirements of small businesses and entities of all sizes that are engaged in the business of manufacturing, importing, selling, installing, managing or operating MLTS that are manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020. The NPRM also proposes rules that will affect small businesses and entities of all sizes that are engaged in the business of offering fixed telephony service, wireless telecommunications, interconnected VoIP service, and TRS. The proposed changes are being implemented as a result of Congressional mandates in Kari's Law and RAY BAUM'S Act that require the Commission to address the inability of callers to directly dial 911 from MLTS and a lack of accurate and critical location information necessary for a PSAP to dispatch emergency services to those in need because of the communications system used in making a 911 call. The specific proposals in the NPRM are described below.

1. Direct Dialing and Notification for MLTS

143. To implement and enforce Kari's Law, the NPRM proposes rules that interpret the law's direct dialing and notification requirements for MLTS. First, the NPRM proposes that a person engaged in the business of manufacturing, importing, selling, or leasing multi-line telephone systems may not manufacture or import for use in the United States, or sell or lease or offer to sell or lease in the United States, a multi-line telephone system, unless such system is pre-configured such that, when properly installed in accordance with the rules, a user may directly initiate a call to 911 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9, regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls.

144. Second, the NPRM proposes that a person engaged in the business of installing, managing, or operating multi-line telephone systems may not install, manage, or operate for use in the United States such a system, unless such system is configured such that a user may directly initiate a call to 911 from any station equipped with dialing facilities, without dialing any additional digit, code, prefix, or post-fix, including any trunk-access code such as the digit 9, regardless of whether the user is required to dial such a digit, code, prefix, or post-fix for other calls. The NPRM also seeks comment on whether any additional elements should be included in the proposed regulations to facilitate compliance and enforcement.

145. Third, the NPRM proposes that a person engaged in the business of installing, managing, or operating multi-line telephone systems shall, in installing, managing, or operating such a system for use in the United States, configure the system to provide notification to a central location at the facility where the system is installed or to another person or organization regardless of location, if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system. The NPRM also proposes to require that notification at a minimum (1) the fact that a 911 call has been made, (2) a valid callback number, and (3) the information about the caller's location that the MLTS conveys to the public safety answering point (PSAP) with the call to 911. The notification must be contemporaneous with the 911 call and must not delay the placement of the call to 911. The NPRM also seeks comment on whether to require that a person be available on-site or off-site to receive the notification. The NPRM asks whether small businesses should be exempt from certain aspects of the notification requirement.

146. Fourth, Kari's Law applies only with respect to MLTS that are manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020. Accordingly, the NPRM notes that MLTS manufactured, imported, offered for first sale or lease, first sold or leased, or installed on or before that date are grandfathered from compliance with the statute, and it seeks comment on whether the Commission should adopt transitional rules to inform consumers of the 911 capabilities of grandfathered MLTS.

147. The NPRM also proposes and seeks comment on definitions for the following terms contained in the proposed regulations: (1) Multi-line telephone system, (2) Pre-configured and configured, (3) Improvement to the hardware or software of the system, (4) A person engaged in the business of managing an MLTS, (5) A person engaged in the business of operating an MLTS, and (6) A person engaged in the business of installing an MLTS, (7) notification, and (8) MLTS notification. The proposed definitions are described below.

148. Multi-line telephone system. The NPRM proposes to define MLTS consistent with Kari's Law and RAY BAUM'S Act which define MLTS as “a system comprised of common control units, telephone sets, control hardware and software and adjunct systems, including network and premises based systems, such as Centrex and VoIP, as well as PBX, Hybrid, and Key Telephone Systems (as classified by the Commission under part 68 of title 47, Code of Federal Regulations), and includes systems owned or leased by governmental agencies and non-profit entities, as well as for profit businesses.” The NPRM proposes to interpret this definition to include the full range of networked communications systems that serve enterprises, including circuit-switched and IP-based enterprise systems, as well as cloud-based IP technology and over-the-top applications. We further interpret this definition to include systems that allow outbound calls to 911 without providing a way for the PSAP to place a return call.

149. Pre-configured and configured. The NPRM proposes to define “pre-configured” to mean that the MLTS is equipped with a default configuration or setting that enables users to dial 911 directly as required under the statute and rules, so long as the MLTS is installed and operated properly. However, if the system is configured with these additional dialing patterns, they must be in addition to the default direct dialing pattern. The NPRM proposes to include similar clarifying language in the definition of “pre-configure.” The NPRM also proposes to define “configured” to mean that the MLTS must be fully capable when installed of dialing 911 directly and providing notification as required under the statute and rules.

150. Improvement to the hardware or software of the system. Kari's Law provides that the notification requirements of the statute apply only if the system can be configured to provide notification without an improvement to the hardware or software of the system. The NPRM proposes to define the term “improvement to the hardware or software of the system” to include upgrades to the core systems of an MLTS, as well as substantial upgrades to the software and any software upgrades requiring a significant purchase.

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

152. A person engaged in the business of operating an MLTS. The NPRM proposes to define a person engaged in the business of operating an MLTS as an entity responsible for the day-to-day operations of the MLTS. The NPRM's proposed definition would specify that the MLTS operator may be the MLTS manager, or it may be a third-party acting on behalf of the manager. For example, an MLTS owner may contract with a third party to provide a total solution for MLTS, including acquiring the MLTS equipment, configuring the system, and providing services such as training, technical support, maintenance, and end user support.

153. A person engaged in the business of installing an MLTS. The NPRM proposes to define a person engaged in the business of installing an MLTS as a person who installs or configures the MLTS or performs other tasks involved in getting the system ready to operate. These tasks may include, but are not limited to, establishing the dialing pattern for emergency calls, determining how calls will route to the PSTN, and determining where the MLTS will interface with the PSTN. The MLTS installer may be the MLTS manager or a third-party acting on behalf of the manager.

154. MLTS Notification. The NPRM proposes to define MLTS notification as an MLTS feature that can send notice to a central location at the facility where the system is installed or to another person or organization regardless of location. Examples of notification include screen pops with audible alarms for security desk computers using a client application, text messages for smartphones, and email for administrators.

155. The NPRM observes that according to a Congressional Budget Office analysis, most MLTS systems already are configured to meet the direct dialing requirements of Kari's Law. In evaluating the Senate and House versions of Kari's Law, Cisco stated that it was not aware of any technological barriers to the implementation of Kari's Law as applied to MLTS. In addition, eight states and one local government already have laws that require direct dialing for 911 from MLTS. The NPRM also tentatively finds that there should be no immediate costs or stranded investment with respect to existing MLTS or systems that first come into service on or before February 16, 2020. Therefore, the Commission tentatively concludes that there will be no immediate costs or benefits associated with meeting the requirements of its rules. For systems coming into service after February 16, 2020, the NPRM seeks comment on the costs and benefits of satisfying its proposed rules. The NPRM also seeks comment on the expected lifespan of existing MLTS that are not currently able to meet the requirements of our proposed rules and the costs of upgrading to an MLTS that meets the requirements. The Commission seeks comment on its tentative conclusion that its rules will impose no incremental costs to those who replace their MLTS as they come to the end of their useful life.

2. Dispatchable Location for Other 911-Capable Communications Services

156. To facilitate the provisioning of dispatchable location by other communications services as contemplated by RAY BAUM'S Act, the NPRM generally proposes to amend existing location requirements with dispatchable location requirements. In addition to MLTS, the NPRM examines four types of communications services that are currently required under Commission rules to provide 911 service to their customers: (1) Fixed telephony, (2) mobile telecommunications, (3) interconnected VoIP service, and (4) Telecommunications Relay Services (TRS). In addition, we examine whether we should adopt dispatchable location rules for other 911-capable services that are not currently subject to 911 rules.

157. The NPRM proposes to proscribe the manufacture, import, sale, or leasing of MLTS unless the system is pre-configured such that, when properly installed, the dispatchable location of the caller is conveyed to the PSAP with 911 calls. Further, the NPRM proposes to proscribe the installation, management, or operation of MLTS in the United States unless the system is configured such that the dispatchable location of the caller is conveyed to the PSAP with 911 calls. The NPRM does not propose specific location technologies or solutions but, rather, seeks comment on implementing general dispatchable location requirements that would give participants in the MLTS marketplace flexibility. This approach will allow the entities affected by the proposed rules to implement them in a manner that is appropriate for them in terms of cost, enterprise size, site layout, and technical sophistication. The NPRM seeks comment on whether the dispatchable location requirement for MLTS should apply to the same entities subject to the MLTS direct dialing and notification requirements. Finally, the NPRM seeks comment on the technical feasibility of 911 calls that originate from MLTS to convey dispatchable location to the appropriate PSAP as well as alternatives for conveying dispatchable location such as the use of x/y/z coordinates to be conveyed with 911 calls originating from MLTS. The NPRM also seeks comment on alternative compliance timeframes for dispatchable location requirements for MLTS.

158. The NPRM proposes to define “dispatchable location” as “the street address of the calling party, and additional information such as room number, floor number, or similar information necessary to adequately identify the location of the calling party.” Given the substantial similarity between the statutory definition and the definition of dispatchable location in the FCC's wireless E911 rules, the NPRM proposes to construe them as functionally identical, aside from the specification of the technological platform to which each definition applies. The NPRM also seeks comment on whether to require validation for dispatchable location information associated with MLTS 911 calls. The NPRM also seeks comment on whether to define “additional information” that may be necessary in an MLTS context to “adequately identify the location of the calling party.” The NPRM also seeks comment on whether the National Emergency Address Database (NEAD), the location database being developed by the major mobile carriers to provide dispatchable location for indoor mobile 911 calls, could potentially assist MLTS managers and operators in determining the dispatchable location of MLTS end users

159. The NPRM proposes to amend the rules to require fixed telephony providers to provide dispatchable location with 911 calls. Although fixed telephony providers already provide validated street address information, dispatchable location includes additional elements such as floor level and room number that may be necessary to locate the caller. The NPRM also seeks comment on whether the NEAD or similar database could assist fixed telephony carriers in providing dispatchable location with 911 calls. The NPRM seeks comment on whether there any alternatives to dispatchable location that fixed telephony could use to provide in-building location information beyond street addresses, e.g., coordinate-based information.

160. The NPRM proposes to amend the Commission's rules to require interconnected VoIP providers to develop the means to provide updated dispatchable location with 911 calls in lieu of conveying the customer's Registered Location. Regarding Fixed VoIP, the NPRM observes that it is feasible for 911 calls that originate from interconnected VoIP services to convey dispatchable location to the PSAP. In a Nomadic VoIP context, the NPRM seeks comment on whether Registered Location represents sufficient proxy for dispatchable location in a nomadic environment, where the relevant device is able to prompt the user for an updated location when it has been moved. The NPRM also seeks to encourage having interconnected VoIP devices and/or networks support the automatic provision of real-time dispatchable location without requiring a manual location update by the end user.

161. The NPRM proposes to amend the Commission's rules to require TRS providers to develop the means to provide updated dispatchable location, paralleling the rules the NPRM proposes for interconnected VoIP service. The NPRM seeks comment on the feasibility of using existing Registered Location mechanisms to provide dispatchable location for fixed and nomadic TRS users. The NPRM also seeks comment on the feasibility of having TRS devices and/or networks support the dynamic provision of real-time dispatchable location without requiring registration or manual location updates by the end user.

162. The NPRM seeks comment on whether providing dispatchable location for 911 calls from MLTS and other communications services would improve emergency response and the health and safety of the public, and whether this benefit would exceed the cost of providing it. The NPRM seeks comment on the magnitude of the benefits to the public when dispatchable location is conveyed with a 911 call from MLTS and other communications services identified in this NPRM. The NPRM anticipates that the increase in location accuracy that results from the use of dispatchable location will reduce the arrival time of ambulances for some 911 callers at least as much as was accomplished by the mobile location rules adopted in the Indoor Location Fourth Report and Order.

163. The NPRM tentatively concludes that the benefits of adopting proposed dispatchable location rules for MLTS, fixed telephony providers, interconnected VoIP service providers, and TRS providers will outweigh the costs. The NPRM observes that 911 location solutions that are capable of conveying dispatchable location to PSAPs are already offered by several MLTS market participants. Further, several states already place requirements on MLTS providers to obtain and convey location information that is more detailed than street address alone, and we therefore conclude that MLTS manufacturers are producing and widely selling equipment that are capable of complying with our proposed rules. In addition, we observe that interconnected VoIP service providers and internet-based TRS providers today obtain customers' Registered Location, which would satisfy our proposed dispatchable location requirements. Because these dispatchable location-capable solutions and equipment are already widely available, the implementation costs of our proposed dispatchable rules to MLTS manufacturers, installers, and operators would be negligible in most respects. The NPRM also proposes to provide flexibility in how to satisfy the proposed dispatchable location requirements and should minimize the potential cost of compliance.

164. The NPRM identifies several aspects of the proposed rules that may lead to additional implementation costs. To assist the Commission in identifying and quantifying the additional costs that may impact small as well large entities, the Commission requests cost information from the parties. First, the NPRM seeks comment on any additional costs that our proposed rules may impose on MLTS managers. Second, the NPRM seeks comment on the costs of implementing our proposed requirement that interconnected VoIP and TRS services identify when a customer uses the service from a new location and update the customer's location information. Third, the NPRM seeks comment on the costs to outbound-only VoIP service providers of complying with the Part 9 rules, including the proposed dispatchable location rules. Finally, the NPRM seeks comment on any additional costs that arise from our proposed rules that we have not considered.

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

165. The RFA requires an agency to describe any significant alternatives that it has considered in reaching its proposed approach, which may include the following four alternatives (among others): (1) The establishment of differing compliance or reporting requirements or timetables that take into account the resources available to small entities; (2) the clarification, consolidation, or simplification of compliance or reporting requirements under the rule for small entities; (3) the use of performance, rather than design, standards; and (4) an exemption from coverage of the rule, or any part thereof, for small entities.

166. To assist the Commission's evaluation of the economic impact on small entities as a result of actions that have been proposed in this NPRM and to better explore options and alternatives, the Commission seeks comment from the parties. With respect to direct dialing and notification under Kari's Law, the NPRM seeks comment on alternatives to reduce the burden and minimize the costs of compliance on small entities. The NPRM observes that notification can be particularly important in large buildings such as hotels, hospitals, and schools, where on-site personnel are uniquely suited to provide information about the building and its occupants. The NPRM asks whether commenters agree that notification is more important for larger enterprises and, if so, whether small businesses should be exempt from certain aspects of the notification requirement, such as a requirement to staff the notification point. The NPRM also seeks comment on what entities should fall within an exception for small businesses. The NPRM asks whether the criterion should be the size of the business or the number of stations in the MLTS. In addition, the NPRM asks whether instead of specifying the content of the notification, the Commission should allow enterprises the flexibility to customize it as they see fit.

167. Regarding dispatchable location, the NPRM asks whether some MLTS in use today are not capable of supporting dispatchable location and whether such systems should be exempted from a dispatchable location requirement. The NPRM invites commenters to offer alternatives to reduce the cost burdens on MLTS entities and other communications services, including whether to allow the entity to pick the location methodology that works best. As mentioned above, giving participants in the MLTS marketplace the flexibility to choose how to implement the proposed rules will mitigate their cost of compliance. The NPRM also asks what steps an MLTS manager must take, if any, to ensure that dispatchable location is conveyed to the PSAP, what are the most effective, least burdensome means to ensure that these steps are taken.

168. The NPRM asks whether there are situations in which communications service providers should be exempted from a dispatchable location requirement. In addition, the NPRM asks whether there are any MLTS or other communications services (e.g., very small facilities) that would not benefit from conveying dispatchable location, or for whom the benefit would not exceed the cost. The NPRM also asks whether any communications services that are exempted from dispatchable location requirements should be required to provide consumer disclosure regarding the limitations of their 911 location capabilities. In addition, the NPRM asks whether dispatchable location requirements for different service types should become effective in phases to require greater accuracy over time or to provide additional time to small businesses to come into compliance.

169. The NPRM also proposes to consolidate all of the existing 911 rules into a single rule part, i.e., Part 9, to the extent practicable. As part of this consolidation, the Commission proposes to simplify and streamline the rules in some instances and to eliminate corresponding duplicative rules in other rule parts. In addition, the NPRM invites commenters to identify additional 911 service rules that should be consolidated under Part 9. We believe the proposed rule consolidation will help to minimize the burden on small entities subject to the Commission's 911 rules because it will simplify and streamline the rules, making it easier for small entities to identify and comply with all 911 requirements.

F. Federal Rules that May Duplicate, Overlap, or Conflict with the Proposed Rules

170. None.

G. Paperwork Reduction Act

171. This document may contain proposed new or modified information collection requirements. The Commission, as part of its continuing effort to reduce paperwork burdens, invites the general public and the Office of Management and Budget (OMB) to comment on the information collection requirements contained in this document, as required by the Paperwork Reduction Act of 1995, Public Law 104-13. In addition, pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 U.S.C. 3506(c)(4), we seek specific comment on how we might further reduce the information collection burden for small business concerns with fewer than 25 employees.”

VI. Conversion Tables

Appendix C

Conversion Table A

Proposed 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 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 removed and reserved in Part 20.
Subpart D—Interconnected Voice over Internet Protocol Services and 911 VoIP 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 9—Interconnected Voice Over Internet Protocol Services, Proposed Rule Changes

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

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

Current rule No.	Subject	Proposed changes
12.1	Purpose	Removed.
12.3	911 and E911 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, Proposed Rule Changes

Current rule No.	Subject	Proposed 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).

Part 25—Satellite Communications, Proposed Rule Changes

Current rule No.	Subject	Proposed changes
25.103	Definitions	Definitions of the following terms added to 9.3 (but not removed from 25.103):
		Earth station.
		Feeder link.
		Fixed-Satellite Service (FSS).
		Mobile Earth Station.
		Mobile-Satellite Service (MSS).
		Space station.
		Definition of the following term added to 9.3 and removed from 25.103:
		Emergency Call Center.
25.109	Cross-reference	Added new (e) to 25.109 stating that “Mobile-Satellite Service providers must comply with the emergency call center service requirements under 47 CFR part 9.”
25.284	Emergency Call Center Service	Moved to 9.18; section 25.284 removed and reserved.

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

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

VII. Ordering Clauses

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

173. It is further ordered that the Commission's Consumer and Governmental Affairs Bureau, Reference Information Center, shall send a copy of this Notice of Proposed Rulemaking, including the Initial Regulatory Flexibility Analysis, to the Chief Counsel for Advocacy of the Small Business Administration.

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

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

Federal Communications Commission.

Marlene Dortch,

Secretary, Office of the Secretary.

Proposed Rules

For the reasons discussed in the preamble, the Federal Communications Commission proposes to amend 47 CFR parts 9, 12, 20, 25, and 64 as follows:

1. Part 9 is revised 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 to convey dispatchable location

Subpart C—Commercial Mobile Radio Service

9.9

Definitions

9.10

911 Service Requirements

Subpart D—Interconnected Voice over internet Protocol Services and 911 VoIP Services

9.11

E911 Service

9.12

Access to 911 and E911 service capabilities

Subpart E—Telecommunications Relay Services for Persons With Disabilities

9.13

Jurisdiction

9.14

Emergency Calling Requirements

Subpart F—Multi Line Telephone Systems

9.15

Applicability

9.16

General obligations—direct 911 dialing, notification and dispatchable location

9.17

Enforcement, compliance date, State law

Subpart G—Mobile-Satellite Service

9.18

Emergency Call Center

Subpart H—Resiliency, redundancy and reliability of 911 communications

9.19

Reliability of covered 911 service providers

9.20

Backup power obligations

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

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

911 VoIP Service. A 911 VoIP service is a service that:

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

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

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

(4) Permits users generally to initiate a 911 call.

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

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

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

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

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

(ii) An interconnected service; and

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

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

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

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

Common carrier or carrier. Any common carrier engaged in interstate Communication by wire or radio as defined in section 3(h) of the Communications Act of 1934, as amended (the Act), and any common carrier engaged in intrastate communication by wire or radio, notwithstanding sections 2(b) and 221(b) of the Act.

Communications assistant (CA). A person who transliterates or interprets conversation between two or more end users of TRS. CA supersedes the term “TDD operator.”

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

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

Dispatchable location. A location delivered to the PSAP with a 911 call that consists of the street address of the calling party, plus additional information such as suite, apartment or similar information necessary to adequately identify the location of the calling party.

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

(1) With one or more space stations; or

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

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

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

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

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

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

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

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

Interconnected VoIP service. An interconnected Voice over internet protocol (VoIP) service is a service that:

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

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

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

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

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

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

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

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

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

(2) A valid callback number, and

(3) The information about the caller's location that the MLTS conveys to the public safety answering point (PSAP) with the call to 911.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Registered Location. Before February 16, 2020: The most recent information obtained by a provider of interconnected VoIP service or telecommunications relay services (TRS), as applicable, that identifies the physical location of an end user. On or after February 16, 2020: The most recent information obtained by a provider of interconnected VoIP service, 911 VoIP service, or telecommunications relay services (TRS), as applicable, that identifies the dispatchable location of an end user.

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

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

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

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

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

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

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

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

Wireline E911 Network. A dedicated wireline network that:

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

(2) Includes a selective router; and

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

Subpart B—Telecommunications Carriers

§ 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 to convey dispatchable location.

All telecommunications carriers shall convey the dispatchable location of the caller to the PSAP with 911 calls, except for wireless carriers, which shall convey the location information required by subpart C of this part.

Subpart C—Commercial Mobile Radio Service

§ 9.9

Definitions.

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

Interconnected Service. A service:

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

(2) For which a request for such interconnection is pending pursuant to section 332(c)(1)(B) of the Communications Act, 47 U.S.C. 332(c)(1)(B). A mobile service offers interconnected service even if the service allows subscribers to access the public switched network only during specified hours of the day, or if the service provides general access to points on the public switched network but also restricts access in certain limited ways. Interconnected service does not include any interface between a licensee's facilities and the public switched network exclusively for a licensee's internal control purposes.

§ 9.10

911 Service.

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

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

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

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

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

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

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

Note to paragraph (d):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(1) Network-based technologies: (i) 100 meters for 67 percent of calls, consistent with the following benchmarks:

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

(1) Network-based accuracy data, or

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

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

(1) Network-based accuracy data, or

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

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

(1) Network-based accuracy data,

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

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

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

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

(1) Network-based accuracy data, or

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

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

(1) Network-based accuracy data, or

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

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

(1) Network-based accuracy data,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(1) Dispatchable location or;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(1) Each of the ATIS ESIF morphologies;

(2) On a reasonable community level basis; or

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(iii) Valid Request means that:

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

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

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

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

(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 of this chapter, provided that “all wireless 911 calls” is defined as “any call initiated by a wireless user dialing 911 on a phone using a compliant radio frequency protocol of the serving carrier.” This requirement shall not apply if the Public Safety Answering Point or emergency authority informs the CIS provider that it does not wish to receive 911 calls from the CIS provider.

Subpart D—Interconnected Voice Over Internet Protocol Services and 911 VoIP Services

§ 9.11

E911 Service.

(a) Before February 16, 2020. (1) Scope of Section. The following requirements are only applicable to providers of interconnected VoIP services. Further, the following requirements apply only to 911 calls placed by users whose Registered Location is in a geographic area served by a Wireline E911 Network (which, as defined in § 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 of this chapter, provided that “all 911 calls” is defined as “any voice communication initiated by an interconnected VoIP user dialing 911;”

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

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

(3) Service Level Obligation. Notwithstanding the provisions in paragraph (a)(2) of this section, if a PSAP, designated statewide default answering point, or appropriate local emergency authority is not capable of receiving and processing either ANI or location information, an interconnected VoIP service provider need not provide such ANI or location information; however, nothing in this paragraph 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 of this chapter.

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

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

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

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

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

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

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

(b) On or after February 16, 2020. (1) Scope of Section. The following requirements are only applicable to providers of interconnected VoIP services and 911 VoIP services. Further, the following requirements apply only to 911 calls placed by users whose dispatchable location is in a geographic area served by a Wireline E911 Network (which, as defined in § 9.3, includes a selective router).

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

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

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

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

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

(4) Dispatchable Location Requirement. Interconnected VoIP service providers and 911 VoIP service providers must comply with either subparagraph (4)(i) or (4)(ii) below.

(i)(A) Obtain from each customer, prior to the initiation of service, the Registered Location at which the service will first be used;

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

(C) For interconnected VoIP service or 911 VoIP service that is capable of being used from more than one location, identify whether the service is being used from a different location than the Registered Location, and if so, either:

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

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

(ii) Obtain the customer's dispatchable location at the time the customer initiates a 911 call without requiring additional action by the customer.

(5) Customer Notification. Each interconnected VoIP service provider and 911 service provider shall:

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

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

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

§ 9.12

Access to 911 and E911 service capabilities.

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

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

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

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

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

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

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

Subpart E—Telecommunications Relay Services for Persons With Disabilities

§ 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.2.

§ 9.14

Emergency calling requirements.

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

(2) On or after February 16, 2020. TTY-based TRS providers must use a system for incoming emergency calls that, at a minimum, automatically and immediately transfers the caller to an appropriate Public Safety Answering Point (PSAP) and transmits the caller's dispatchable location to the PSAP. An appropriate PSAP is either a PSAP that the caller would have reached if he had dialed 911 directly, or a PSAP that is capable of enabling the dispatch of emergency services to the caller in an expeditious manner.

(b) Additional emergency calling requirements applicable to internet-based TRS providers. (1) As of December 31, 2008, the requirements of paragraphs (b)(2)(i) and (b)(2)(v) of this section shall not apply to providers of VRS and IP Relay to which §§ 9.14(c) and 9.14(d) apply.

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

(i) Accept and handle emergency calls and access, either directly or via a third party, a commercially available database that will allow the provider to determine an appropriate PSAP, designated statewide default answering point, or appropriate local emergency authority that corresponds to the caller's location, and to relay the call to that entity;

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

(iii) Before February 16, 2020. Request, at the beginning of each emergency call, the caller's name and location information, unless the internet-based TRS provider already has, or has access to, a Registered Location for the caller;

(iv) On or after February 16, 2020. Request, at the beginning of each emergency call, the caller's name and dispatchable location, unless the internet-based TRS provider already has, or has access to, a dispatchable location for the caller;

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

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

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

(c) E911 Service for VRS and IP Relay before February 16, 2020. (1) Scope. The following requirements are only applicable to providers of VRS or IP Relay. Further, the following requirements apply only to 911 calls placed by registered users whose Registered Location is in a geographic area served by a Wireline E911 Network and is available to the provider handling the call.

(2) E911 Service. (i) VRS or IP Relay providers must, as a condition of providing service to a user, provide that user with E911 service as described in this section;

(ii) VRS or IP Relay providers must transmit all 911 calls, as well as ANI, the caller's Registered Location, the name of the VRS or IP Relay provider, and the CA's identification number for 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 of this chapter, provided that “all 911 calls” is defined as “any communication initiated by an VRS or IP Relay user dialing 911”;

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

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

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

(4) Registered location requirement. As of December 31, 2008, VRS and IP Relay providers must:

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

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

(d) E911 Service for VRS and IP Relay on or after February 16, 2020. (1) Scope. The following requirements are only applicable to providers of VRS or IP Relay. Further, the following requirements apply only to 911 calls placed by registered users whose dispatchable location is in a geographic area served by a Wireline E911 Network and is available to the provider handling the call.

(2) E911 Service. (i) VRS or IP Relay providers must, as a condition of providing service to a user, provide that user with E911 service as described in this section;

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

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

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

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

(4) Dispatchable location requirement. VRS and IP Relay providers must comply with either paragraphs (4)(i) or (4)(ii) of this section.

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

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

(C) If the VRS or IP Relay is capable of being used from more than one location, identify whether the service is being used from a different location than the Registered Location, and if so, either:

(1) Prompt the Registered internet-based TRS User to provide a new Registered Location; or

(2) Update the Registered Location without requiring additional action by the Registered internet-based TRS User.

(ii) Obtain the Registered internet-based TRS User's dispatchable location at the time they initiate a 911 call without requiring additional action by the Registered internet-based TRS User.

Subpart F—Multi-Line Telephone Systems

§ 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 is pre-configured such that, when properly installed in accordance with subsection (b), the dispatchable location of the caller is conveyed to the PSAP with 911 calls.

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

(2) A person engaged in the business of installing, managing, or operating multi-line telephone systems shall, in installing, managing, or operating such a system for use in the United States, configure the system to provide a notification to a central location at the facility where the system is installed or to another person or organization regardless of location, if the system is able to be configured to provide the notification without an improvement to the hardware or software of the system. The MLTS notification must be contemporaneous with the 911 call and must not delay the call to 9-1-1.

(3) A person engaged in the business of installing, managing, or operating multi-line telephone systems may not install, manage, or operate such a system in the United States unless it is configured such that the dispatchable location of the caller is conveyed to the PSAP with 911 calls.

§ 9.17

Enforcement, Compliance date, State law.

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

(b) Compliance date. The compliance date for this subpart F is February 16, 2020. Accordingly, the requirements in this subpart apply to MLTS that are manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020.

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

Subpart G—Mobile-Satellite Service

§ 9.18

Emergency Call Center Service.

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

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

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

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

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

Subpart H—Resiliency, redundancy and reliability of 911 communications

§ 9.19

Reliability of covered 911 service providers.

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

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

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

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

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

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

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

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

(4) Covered 911 service provider.

(i) Any entity that:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

§ 9.20

Backup power obligations

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

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

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

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

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

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

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

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

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

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

(ii) Service limitations with and without backup power;

(iii) Purchase and replacement information, including cost;

(iv) Expected backup power duration;

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

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

(vii) Backup power warranty details, if any.

(2) Disclosure reasonably calculated to reach each subscriber. A provider of a Covered Service shall make disclosures required by this rule in a manner reasonably calculated to reach individual subscribers, with due consideration for subscriber preferences. Information posted on a provider's public 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(e) of this chapter.

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

(f) Effective dates of obligations. (1) Except as noted in paragraphs (b)(2) and (f)(2) of this section, the obligations under paragraph (b) of this section are effective February 16, 2016, and the obligations under paragraph (d) of this section are effective 120 days after the Commission announces approval from the Office of Management and Budget.

(2) For a provider of a Covered Service that (together with any entities under common control with such provider) has fewer than 100,000 domestic retail subscriber lines, the obligations in paragraph (b)(1) of this section are effective August 11, 2016, the obligations in paragraph (b)(2) of this section are effective as prescribed therein, and the obligations under paragraph (d) of this section are effective 300 days after the Commission announces approval from the Office of Management and Budget.

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

PART 12—[REMOVED AND RESERVED]

2. Under the authority of 47 U.S.C. 151, 154(i), 154 (j), 154 (o), 155(c), 201(b), 214(d), 218, 219, 251(e)(3), 301, 303(b), 303(g), 303(j), 303(r), 307, 309(a), 316, 332, 403, 405, 615a-1, 615c, 621(b)(3), and 621(d)), 47 CFR chapter I is amended by removing and reserving part 12.

PART 20—COMMERCIAL MOBILE SERVICES

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

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

4. 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]

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

§ 20.18

[Removed and Reserved]

6. Remove and reserve § 20.18.

PART 25—SATELLITE COMMUNICATIONS

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

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

§ 25.103

[Amended]

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

9. Section 25.109 is amended by adding paragraph (e) to read as follows:

§ 25.109

Cross-reference

* * * * *

(e) Mobile-Satellite Service providers must comply with the emergency call center service requirements under 47 CFR part 9.

§ 25.284

[Removed and Reserved]

10. Remove and reserve § 25.284.

PART 64—MISCELLANEOUS RULES RELATING TO COMMON CARRIERS

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

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

12. 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 terms Public Safety Answering Point (PSAP), statewide default answering point, and appropriate local emergency authority are defined in 47 CFR 9.3; the term affiliate is defined in 47 CFR 52.12(a)(1)(i), and the terms majority and debt are defined in 47 CFR 52.12(a)(1)(ii).

* * * * *

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

* * * * *

14. Section 64.604 is amended by revising paragraphs (a)(4) and (d) to read as follows:

§ 64.604

Mandatory minimum standards.

(a) * * *

(4) Emergency call handling requirements for TTY-based TRS providers. TTY-based TRS providers are subject to the emergency call handling requirements in § 9.14(a).

* * * * *

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

§ 64.605

[Removed and Reserved]

15. Remove and reserve § 64.605.

Subpart AA [Removed and reserved]

16. Remove and reserve Subpart AA, consisting of §§ 64.3000 through 64.3004.