Federal Communications Commission DA 17-1084 Before the Federal Communications Commission Washington, D.C. 20554 In the Matter of Transition from TTY to Real-Time Text Technology Petition for Rulemaking to Update the Commission’s Rules for Access to Support the Transition from TTY to Real-Time Text Technology, and Petition for Waiver of Rules Requiring Support of TTY Technology T-Mobile USA, Inc. ) ) ) ) ) ) ) ) ) ) ) ) CG Docket No. 16-145 GN Docket No. 15-178 ORDER Adopted: November 3, 2017 Released: November 3, 2017 By the Chief, Public Safety and Homeland Security Bureau, and the Acting Chief, Consumer and Governmental Affairs Bureau: I. INTRODUCTION 1. By this Order, we grant the Petition of T-Mobile USA, Inc. (T-Mobile) for Clarification and dismiss as moot its request, in the alternative, for reconsideration, 1 of the Commission’s Report and Order implementing new rules to facilitate the transition from text telephony (TTY) technology to real- time text (RTT). 2 Specifically, we clarify that when a Commercial Mobile Radio Services (CMRS) provider connects to an Emergency Services Internet Protocol Network (ESInet) to deliver RTT 911 calls, 3 the CMRS provider need not convert RTT to TTY format. Rather, any conversion from RTT to TTY (or other delivery means) is the responsibility of the ESInet provider. In light of this clarification, we also dismiss as moot T-Mobile’s alternative petition for reconsideration of the RTT Report and Order. 1 Petition of T-Mobile for Clarification, or, in the Alternative, Reconsideration, CG Docket No.16-145; GN Docket No 15-178 (filed Feb. 24, 2017), https://ecfsapi.fcc.gov/file/102231846629100/T- Mobile%20RTT%20Petition%20for%20Clarification%20(2-22-17)%20FINAL.pdf (Petition). 2 Transition from TTY to Real-Time Text Technology; Petition for Petition for Rulemaking to Update the Commission’s Rules for Access to Support the Transition from TTY to Real-Time Text Technology, and Petition for Waiver of Rules Requiring Support of TTY Technology, Report and Order and Further Notice of Proposed Rulemaking, 31 FCC Rcd 13568 (2016) (RTT Report and Order). 3 An ESInet is a managed Internet Protocol (IP) based emergency services network that supports voice and data call delivery to Public Safety Answering Points (PSAPs) -- both Next Generation (NG) 911-capable PSAPs (those that can receive calls directly in IP format) and legacy PSAPs (those using circuit-switched technology). ESInets are typically run by specific service providers or by government agencies. See National Emergency Number Association (NENA), NENA Emergency Services IP Network Design for NG9-1-1 (NID), NENA 08-506, Version 1 at 12 (2011), https://c.ymcdn.com/sites/www.nena.org/resource/collection/2851C951-69FF-40F0-A6B8- 36A714CB085D/NENA_08-506_Emergency_Services_IP_Network_Design_12142011.pdf. Federal Communications Commission DA 17-1084 2 II. BACKGROUND 2. In the RTT Report and Order, the Commission amended its rules to facilitate a transition from TTY technology to RTT as a reliable, interoperable universal text solution for people who are deaf, hard of hearing, deaf-blind, or have a speech disability. 4 Among other things, the Commission amended Part 20 of its rules to allow CMRS providers to support RTT in lieu of TTY technology for communications using wireless IP-based voice services, 5 and it established a timeline for providers that choose to do so. 6 The Commission also provided that RTT communications must support 911 communications and must be backward compatible with TTY technology to support communication with end points that still rely on TTY. 7 3. In the Petition, T-Mobile seeks clarification or reconsideration of the RTT Report and Order with respect to the scope of the obligation for CMRS providers to deliver 911 RTT calls to Public Safety Answering Points (PSAPs) that are accessed via an ESInet. Specifically, T-Mobile asks the Commission to clarify that it intended for CMRS providers to deliver 911 RTT calls to ESInets in an IP format, including in instances where the call is then routed by the ESInet to a legacy PSAP that uses circuit-switched technology. 8 In such instances, T-Mobile contends that the ESInet provider should be responsible for any RTT-to-TTY conversion required to enable the legacy PSAP to receive and process the call. 9 4. T-Mobile asserts that the alternative – requiring the CMRS provider to transcode the call from RTT to TTY – would create new technical challenges for all parties because ESInet architecture does not support receipt of circuit-switched calls. 10 Transcoding the RTT call to circuit-switched TTY prior to delivery to the ESInet, T-Mobile states, “would require the ESInet to transcode the TTY call back to IP format – that is, to RTT – in order to traverse the ESInet.” 11 T-Mobile asserts that it would also be inconsistent with ESInet architecture for wireless providers to handle the conversion from RTT to TTY after delivering the call to the ESInet because conversion from IP to circuit-switched formats occurs at the gateway where the legacy PSAP connects to the ESInet. 12 Thus, requiring the wireless provider to handle RTT-to-TTY transcoding “would require the carrier to somehow insert itself into the interconnection between the PSAP and the ESInet – something that would likely not be technically feasible.” 13 Finally, T-Mobile notes that it is not seeking clarification with respect to the delivery of 911 RTT calls to legacy PSAPs that are served by a selective router rather than an ESInet. In that circumstance, T-Mobile states, it will perform the necessary RTT-to-TTY conversion before it delivers the call to the selective router. 14 5. On February 27, 2017, the Consumer and Governmental Affairs Bureau released a Public 4 See RTT Report and Order, 31 FCC Rcd at 13569, para. 1. 5 Id. at 13581, para. 19; see also 47 CFR § 20.18(c). 6 See RTT Report and Order, 31 FCC Rcd at 13602, paras. 66-67. 7 Id. at 13573, 13589, 13591-92, paras. 6, 37, 43. 8 See Petition at 3-5. 9 Id. at 4-5. 10 Id. at 3-4. 11 Id. at 4. 12 Id. 13 See id. at 4-5. 14 See id. at 2 n.3. Federal Communications Commission DA 17-1084 3 Notice inviting comment on the Petition. 15 The Commission received five comments and two reply comments in response to the Public Notice. 16 Several commenters agree that in the situation described by T-Mobile, transcoding of RTT to TTY should not be the responsibility of the originating service provider, 17 and no commenter opposes the clarification requested by T-Mobile. NENA states that in the situation described in the Petition, “the hand-off between the access network provider (ANP) and the terminating ESInet is the last point at which an ANP has access to, or control of, the signaling, media, or additional data associated with an NG9-1-1 RTT ‘call,’” and that “[e]very PSAP served by an ESInet depends on the NG9-1-1 functional entities within that network to provide any protocol translations or interworking required to service that PSAP’s capabilities. 18 ” NENA therefore agrees with T-Mobile that “it would be difficult, if not impossible, for an ANP to insert its own systems between a terminating ESInet and a legacy PSAP. Doing so would require a novel call-routing mechanism, or would require a carrier to pay for all or part of the costs of installing and maintaining a Legacy PSAP Gateway (LPG).” 19 Texas 911 Entities state that the demarcation point defining T-Mobile’s operational responsibility to deliver traffic to an ESInet with NG911 Core Services “should be established at the session border controller (SBC) of the ESInet, unless otherwise negotiated by the parties.” 20 RERC et al. urge the Commission to confirm that “[c]arriers are NOT required to convert between RTT and TTY when the call is connected through an ESInet,” and “[c]arriers ARE required to convert between RTT and TTY if the call is connected directly to the PSTN WITHOUT going through an ESInet.” 21 III. DISCUSSION 6. T-Mobile asserts that Paragraph 46 of the RTT Report and Order creates uncertainty about the obligations of a provider delivering an RTT call to a legacy PSAP served by an ESInet. 22 In Paragraph 46, the Commission noted T-Mobile’s assertion in the record that an obligation to provide backward compatibility would shift certain burdens now borne by PSAPs onto wireless carriers by requiring carriers to support transcoding gateways “to ensure that 911 calls are delivered to PSAPs via the relevant selective router and, at the same time support TTY (Baudot) media, Automatic Number Identification (ANI), and Automatic Location Identification (ALI).” 23 The Commission noted that the 15 Consumer and Governmental Affairs Bureau Seeks Comment on T-Mobile USA, Inc. Petition for Clarification or, in the Alternative, Reconsideration of the Commission’s Real-Time Text Order, Public Notice, 32 FCC Rcd 1450 (CGB 2017). 16 Commenters are Boulder Regional Emergency Telephone Service Authority (BRETSA), Competitive Carriers Association (CCA), CTIA, NENA, and Texas 911 Alliance, Texas Commission on State Emergency Communications, and Municipal Emergency Communication Districts Association (collectively, Texas 911 Entities). Reply commenters are the Rehabilitation Engineering Research Center on Technology for the Deaf and Hard of Hearing (DHH-RERC), Rehabilitation Engineering Research Center on Universal Interface and IT Access (UIITA-RERC), and Omnitor (collectively, RERC et al.) and T-Mobile. 17 See NENA Comments at 2; CTIA Comments at 3; Texas 911 Entities Comments at 6; Letter from Rebecca Murphy Thompson, EVP and General Counsel, Competitive Carriers Association, to Marlene H. Dortch, Secretary, FCC, CG Docket No. 16-145, GN Docket No. 15-178, at 1-2 (filed March 31, 2017). 18 NENA Comments at 2 (citing National Emergency Number Association, NENA Detailed Functional and Interface Specifications for the NENA i3 Solution, NENA-STA-010.2-2016 at 103 (2016), https://c.ymcdn.com/sites/www.nena.org/resource/resmgr/standards/NENA-STA-010.2_i3_Architectu.pdf). 19 Id. 20 Texas 911 Entities Comments at 2. 21 RERC et al. Reply Comments at 4-5 (emphasis in original). 22 See Petition at 2. 23 RTT Report and Order, 31 FCC Rcd at 13593, para. 46 (citing T-Mobile Reply Comments (July 25, 2016) at 7 n.23) (footnote omitted). Federal Communications Commission DA 17-1084 4 components of 911 call delivery referenced by T-Mobile “are all basic 911 elements that carriers have been required to provide when transmitting calls from TTYs under section 20.18 of our rules” and stated that “we do not believe that requiring the delivery of RTT 911 calls with these elements would involve any burden shifting.” 24 T-Mobile asserts that “[t]his statement, read on its face, conflicts with the way ESInets are architected and would obligate carriers to take on responsibilities they do not have today, as well as impose a burden that is likely not technically achievable.” 25 7. The statement in the RTT Report and Order that T-Mobile cites was not intended to create an obligation for CMRS providers to convert 911 RTT calls to TTY before delivery of such calls to an ESInet. The RTT Report and Order established a general obligation for wireless service providers to ensure that RTT is backward compatible with TTY technology so that RTT users can place and receive calls to and from remaining TTY users, including legacy PSAPs. 26 However, the Commission’s discussion of backward compatibility in Paragraph 46 of the RTT Report and Order referred only to calls delivered to PSAPs “via the relevant selective router.” 27 It did not address the specific issue raised by T- Mobile’s Petition – i.e., the fact that providing backward compatibility when a PSAP is served by an ESInet entails different accommodations from those involved when the PSAP is served by a selective router. As NENA states, the access point between a CMRS provider and the ESInet is the last point at which the provider has “access to, or control of, the signaling, media, or additional data” associated with an RTT call. 28 We agree with NENA and T-Mobile that it would not be technologically feasible for a CMRS provider to insert its own systems between a terminating ESInet and a legacy PSAP. 29 The Commission also made clear in the RTT Report and Order that it was “not prescrib[ing] how 911 calls via RTT should reach a PSAP.” 30 8. Accordingly, we clarify that where a CMRS provider delivers RTT 911 calls to a legacy PSAP served by a selective router, the CMRS provider is responsible for performing the necessary conversion from IP to circuit-switched format before it delivers the call to the selective router. For RTT 911 calls to a legacy PSAP served by an ESInet, the conversion to circuit-switched format is the responsibility of the ESInet provider. In light of this clarification, we dismiss T-Mobile’s alternative petition for reconsideration of the RTT Report and Order as moot. 9. In its comments, NENA asks the Commission to recognize a limited qualification to the parties’ responsibilities when a legacy PSAP is served by an ESInet. 31 NENA notes that some PSAPs may transition to NG911 gradually, maintaining legacy analog or Time-Division Multiplexed (TDM) connections to a selective router while they are connected to an ESInet for other purposes. 32 Similarly, NENA states, “some NG9-1-1 system service providers may elect to keep in-place legacy Selective Routers to serve as temporary points of aggregation until full IP-to-IP interconnection can be negotiated 24 RTT Report and Order, 31 FCC Rcd at 13593, para. 46 (footnote omitted). 25 Petition at 2-3. 26 RTT Report and Order, 31 FCC Rcd at 13593, para. 46. 27 Id. The T-Mobile argument to which the Commission responded in Paragraph 46 was that “calls for shifting certain burdens to carriers from public safety are shortsighted.” T-Mobile Reply Comments (July 25, 2016) at 7. T- Mobile, in turn, was responding to a comment by NENA that carrier RTT to TTY gateways must provide certain components of an E911 TTY call. NENA Comments (July 11, 2016) at 8. 28 NENA Comments at 2. 29 Id.; Petition at 4. 30 RTT Report and Order, 31 FCC Rcd at 13592, para. 44. 31 NENA Comments at 3. 32 Id. Federal Communications Commission DA 17-1084 5 with all or most of the parties providing NG9-1-1 service to consumers in a given area.” 33 NENA asserts that in these “transitional scenarios” where PSAPs are continuing to receive 911 traffic via selective router, the transcoding obligation with respect to such traffic should remain with the CMRS provider unless the PSAP requests a different arrangement. 34 We agree with NENA and clarify that in these circumstances, the CMRS provider should convert the call from RTT to TTY unless the PSAP requests otherwise. 35 IV. ORDERING CLAUSES 10. Accordingly, IT IS ORDERED that, pursuant to sections 4(i), 225, 255, 301, 303(r), 316, 403, 405(a), 715, and 716 of the Communications Act of 1934, as amended, and section 106 of the Twenty-First Century Communications and Video Accessibility Act of 2010 (CVAA), 47 U.S.C. §§ 154(i), 225, 255, 301, 303(r), 316, 403, 405(a), 615c, 616, and 617, and Sections 0.141, 0.191, 0.361, 0.392, and 1.429 of the Commission’s Rules, 47 CFR §§ 0.141, 0.191, 0.361, 0.392, and 1.429, this Order is ADOPTED. 11. IT IS FURTHER ORDERED that the Petition of T-Mobile USA, Inc. for Clarification is GRANTED to the extent described herein, and its accompanying Petition in the Alternative for Reconsideration is DISMISSED. V. PROCEDURAL MATTERS 12. To request materials in accessible formats (such as Braille, large print, electronic files, or audio format), send an e-mail to fcc504@fcc.gov or call the Consumer and Governmental Affairs Bureau at (202) 418-0530 (voice), (844) 432-2275 (videophone), or (202) 418-0432 (TTY). FEDERAL COMMUNICATIONS COMMISSION Lisa M. Fowlkes Chief, Public Safety and Homeland Security Bureau Patrick Webre Acting Chief, Consumer and Governmental Affairs Bureau 33 Id. 34 Id. 35 Some commenters raise other issues with respect to RTT calls to legacy PSAPs. BRETSA, for example, suggests that legacy PSAPs should have the option of receiving RTT calls (i) outside of existing 911 and future NG911 systems via Text Control Center (TCC), and (ii) in block mode. See BRETSA Comments at 3-5. RERC et al., caution that using an enhanced TCC to collect RTT traffic into complete messages before transmission could cause delays that “put the proper and timely handling of the emergency case at risk.” See RERC et al. Reply Comments at 5; see also Texas 911 Entities Comments at 6-7 (asserting that it would be premature for the Commission to address the parties’ operational responsibilities with respect to use of an enhanced TCC with message session relay protocol (MSRP)). These comments are beyond the scope of the Petition, and we do not address them here. See T-Mobile Reply Comments at 2.