# Improving the 911 System by Implementing Kari's Law and RAY BAUM'S Act > Briefs, arguments, decisions, and more. URL: https://www.frixlaw.com/law-library/documents/fr%3A2018-21888 ## Record - **Collection:** Federal Register - **Document type:** Proposed Rule - **Published:** October 26, 2018 - **Citation:** 83 FR 54180 ## Text FEDERAL COMMUNICATIONS COMMISSION 47 CFR Parts 9, 12, 20, 25, and 64 [PS Docket Nos. 18-261, 17-239; FCC 18-132] Improving the 911 System by Implementing Kari's Law and RAY BAUM'S Act AGENCY: Federal Communications Commission. ACTION: Proposed rule. SUMMARY: In this document, the Federal Communications Commission (the FCC or Commission) proposes rules for 911 calls made from multi-line telephone systems (MLTS), pursuant to Kari's Law, the conveyance of dispatchable location with 911 calls, as directed by RAY BAUM'S Act, and the consolidation of the Commission's 911 rules. The Commission also proposes consolidating the Commission's existing 911 rules into a single rule part. DATES: Comments are due on or before December 10, 2018 and reply comments are due on or before January 9, 2019. ADDRESSES: You may submit comments, identified by PS Docket Nos. 18-261 and 17-239 by any of the following methods: • Federal eRulemaking Portal: http://www.regulations.gov. Follow the instructions for submitting comments. • Federal Communications Commission's Website: http://www.fcc.gov/ecfs/. Follow the instructions for submitting comments. • Mail: Filings can be sent by hand or messenger delivery, by commercial overnight courier, or by first-class or overnight U.S. Postal Service mail (although the Commission continues to experience delays in receiving U.S. Postal Service mail). All filings must be addressed to the Commission's Secretary, Office of the Secretary, Federal Communications Commission. • People with Disabilities: Contact the Commission to request reasonable accommodations (accessible format documents, sign language interpreters, CART, etc.) by email: FCC504@fcc.gov or phone: 202-418-0530 or TTY: 202-418-0432. For detailed instructions for submitting comments and additional information on the rulemaking process, see the SUPPLEMENTARY INFORMATION section of this document. FOR FURTHER INFORMATION CONTACT: Brenda Boykin, Attorney-Advisor, Policy and Licensing Division, Public Safety and Homeland Security Bureau, (202) 418-2062 or via email at Brenda.Boykin@fcc.gov ; Austin Randazzo, Attorney-Advisor, Policy and Licensing Division, Public Safety and Homeland Security Bureau, (202) 418-1462 or via email at Austin.Randazzo@fcc.gov. 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 fcc504@fcc.gov 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 Objec [Text truncated at 120,000 characters. The full text is on the page linked above.] --- Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3A2018-21888. Public record. Not legal advice.