FCC Order on Transition From TTY to Real-Time Text Technology Provides Better Option for IP-Based Wireless Communications

FCC Order on Transition From TTY to Real-Time Text Technology 
Provides Better Option for IP-Based Wireless Communications
In December 2016, the Federal Communications Commission (“FCC” or the “Commission”) adopted an Order and rules that allow IP-based wireless voice providers and manufacturers to utilize real-time text (“RTT”) technology in lieu of text telephony (“TTY”) technology (“TTY To RTT Order”).  The rule amendments became effective on February 22, 2017.
 
TTY Limitations Lead to New Rules for IP-Based Wireless Communications
 
TTY technology provides people with disabilities the means to send and receive text communications, notably emergency 911 communications.  Commission rules have required providers and device manufacturers of telecommunications services and advanced communications services to support TTY technology.  However, TTY technology has proven to be unsuitable for IP-based wireless communications networks.  Still, absent a waiver, providers and manufacturers have been required to support TTY.  Competitive Carriers Association previously obtained a waiver of this requirement on behalf of many providers.
 
Rules Allow Optional Transition to RTT for IP-Based Wireless Communications
 
In response to industry recommendations to transition to a new technology, specifically RTT, the Commission conducted a rulemaking to consider allowing providers and manufacturers to utilize RTT technology for IP-based wireless networks.  Late last year the Commission adopted the TTY To RTT Order, finding that RTT technology is an effective and efficient replacement for TTY technology for wireless IP-based voice services.  The Commission’s new rules provide that wireless carriers may opt to utilize RTT technology instead of TTY and may accordingly be relieved of TTY support obligations.  However, the Commission also imposed certain minimal functionality requirements and established requirements for core features.  The Commission established a timeline for transitioning from TTY to RTT and recommended public outreach and education.
 
The RTT rule changes cover only those entities that provide IP-based wireless voice communication service, and only to the extent that their services are subject to existing TTY technology support requirements under the Commission’s rules.  Wireless providers that support RTT in compliance with the new rules will be relieved of their TTY support requirements on all wireless networks and equipment, including services and devices use for legacy (non-IP) facilities as of the applicable compliance dates.  At this time, RTT will not apply to wireline services.  
 
Functionality Requirements for RTT
 
The Commission mandates certain minimum functionality requirements on RTT support. First, RTT platforms and networks must be interoperable with one another.  To this end, the Commission adopted RFC 4103 as the appropriate safe harbor standard for compliance with RTT interoperability requirements.  Second, RTT communications must be backward compatible with TTY.  As a safe harbor for transliterating RTT to TTY characters, the Commission will allow the use of ITU-T Recommendation V.18.  The Commission is currently seeking comments on the timeline for when this requirement should sunset in a Further Notice of Proposed Rulemaking.  Last, RTT must support 911 communications.  Once a public safety answering point is capable of receiving RTT text communications, the requested service provider must begin delivering RTT communications in a RTT format within six months after such request is made.  In the event that such request is infeasible, a service provider may request a waiver of this requirement. 
 
Required Core RTT Features
 
Wireless service providers and manufactures opting to support RTT must configure their networks and devices so that RTT communications can be initiated and received from the same telephone number used for voice communications.  The Commission also required that users of RTT be able to send and receive both text and voice simultaneously in both direction over IP on the same call session and via a single device. 
 
Timeline for RTT Implementation
 
1.   Initial Compliance Deadline – June 30, 2020 for Non-Tier 1 Providers
 
Wireless providers can meet the initial compliance requirement by either (1) offering a downloadable application or plug in that supports RTT, or (2) complying with one of the following: (i) implementing in their core network the capability to support RTT; (ii) offering at least one new handset that supports native RTT functionality, and (iii) for all authorized end user devises specified on or after that initial compliance date, including in future design specifications the requirement to support RTT.
 
All Tier 1 providers that opt to provide RTT and do not wish to seek an extension of the current waiver must meet an initial compliance deadline of December 31, 2017.  All non-Tier 1 providers opting to provide RTT support must meet an initial compliance deadline of June 30, 2020, unless it is not achievable for a particular manufacturer to support RTT on that provider’s network.  Mobile Virtual Network Operators and other CMRS resellers are not subject to this initial deadline as they may be unable to support RTT until after the technology has been implemented by both Tier 1 and non-Tier 1 facilities-based CMRS providers. 
 
2.   Second Compliance Deadline – June 30, 2021 for Non-Tier 1 Providers
 
By December 31, 2019, Tier-1 providers opting to support RTT must provide RTT support for all new authorized user devices activated on their networks.  Non-Tier 1 Providers must do so by June 30, 2021.
 
3.  Relief from TTY Support Obligations – Waiver Extended Until June 30, 2020
 
A wireless provider or manufacturer in compliance with the RTT obligations will be relieved of TTY support obligations.  Further, a provider or manufacturer that achieves early compliance with the RTT support requirements will be relieved of TTY obligations at the date it achieves RTT compliance.  For providers that are currently subject to a limited waiver of their TTY support requirements that expires December 31, 2017, which is well prior to the earliest RTT compliance deadline, the waiver granted to these providers will extend to the date of their first RTT compliance deadline, again June 30, 2020.  
 
Education and Outreach Guidelines
 
The Commission recommended guidelines (not requirements) for informing the public about the transition from TTY to RTT, specifically: (1) development and dissemination of educational materials; (2) Internet postings, in an accessible format; (3) creation of a telephone hotline and online interactive service to answer consumer questions; and (4) appropriate training of staff to effectively respond to consumer questions.
 
Further Notice of Proposed Rulemaking
 
The Commission sought further comment on establishing a sunset date for the obligation to make RTT backward compatible with TTY technology.  In addition, the Commission sought comment on the costs, benefits, and technical feasibility of integrating RTT into TRS services.  Last, the Commission sought comment on other RTT features, including Braille displays and block mode.  The deadline for comments and reply comments ended on March 24, 2017. 
 
Petition for Clarification, or in the Alternative, Petition for Reconsideration
 
T-Mobile has sought clarification of the obligation for wireless providers to deliver calls to Public Safety Answering Points (“PSAPs”) using an Emergency Services Internet Protocol Network (“ESINet”).  Specifically, T-Mobile requested that the Commission clarify that it did not intend to change the way providers deliver calls to PSAPs using an ESINet, but to the extent the Commission intended to shift the burden of conversion of RTT to TTY from the ESINet to wireless providers, T-Mobile alternatively has sought reconsideration of that determination and requested that the Commission refrain from placing this obligation on wireless providers.  Action on this petition is still pending.