Skip Navigation

Federal Communications Commission

English Display Options

Commission Document

Interim Text to 9-1-1 Working Group

Download Options

Released: September 12, 2012
<this area for real time captions>
Interim Text to 9‐1‐1
Working Group
Co‐Chairs:
Brian Daly, AT&T
Gregg Vanderheiden, TRACE
1

<this area for real time captions>
Interim Text to 9‐1‐1 Subcommittee

This group is charged with developing a recommendation and draft language for the full 
committee with regard to Pre‐NG9‐1‐1 Mobile Text to 9‐1‐1 Solution(s). 

March 2012 EAAC recommendation:  
– EAAC Supports as an interim solution for text to 9‐1‐1, at a minimum, SMS, and other 
technologies as appropriate, with a three digit short code 9‐1‐1

Additional provisions from the EAAC recommendations that relate to the 
subcommittee work:
– Text to 911 before NG911 enabled
– Recommendation T1.2: Interim Mobile Text Solution: 
The EAAC recommends that the FCC work with Department of Justice, industry, 
academia, consumer groups and public safety entities to develop an interim 
solution that can be rapidly deployed to provide nationwide access to 9‐1‐1 
services through industry standards‐based mobile text communications solution(s) 
to provide critical coverage for this important constituency during the transition to 
NG9‐1‐1.
2

<this area for real time captions>
Subcommittee Assumptions

Using any number besides 9‐1‐1 creates the problem that the user will probably 
never remember it when they have an emergency, if they ever knew that there 
was a number besides 9‐1‐1. 

This short‐term solution should not necessarily be subject to all of the 
requirements of either voice 9‐1‐1 calls or long‐term solutions so that it can be 
implemented in the near term and without extensively reworking the carrier, 
handset, or PSAPs systems. 

The FCC should work with consumers and industry to secure any needed 
additional liability protection for all entities that are implementing these new text 
to 9‐1‐1 calls. 
3

<this area for real time captions>
Subcommittee Assumptions

The EAAC believes that if the text message to 9‐1‐1 solution is not available to all 
people, with and without disabilities, that it would be too complicated for carriers 
and others to qualify some people as eligible and others as ineligible to make an 
SMS/text message call to 9‐1‐1 during emergency situations. The liability issues 
from denying access to unregistered callers would complicate it further.

The EAAC directed for this subcommittee to take this topic up in 2012 and submit 
a separate report on this important topic.

From a consumer standpoint, direct access via mobile text to 9‐1‐1 is a critical 
goal.
4

<this area for real time captions>
High Level Architecture

E9‐1‐1 PSAP

Transport Network

Originating 

Network

User  & 

E  

User 

Gateway

Gateway

Interim PSAP

Device

PSAP  Capability 

Databases 

NG‐9‐1‐1 PSAP

5

<this area for real time captions>
Interim Text to 9‐1‐1 Subgroups
• Subcommittee decided to create 4 subgroups
– Each to focus on one section of the problem
• Subgroups were defined as follows:
– User View – Originating Devices
– Originating Devices & Networks
– Transport Networks
– PSAP end
6

<this area for real time captions>
Subcommittee Progress
• Bi‐weekly calls held by Interim text to 9‐1‐1 
subcommittee reviewing progress of the subgroups
• Breakout sessions to address specific subgroup focus 
areas
• Received input on Assumptions and Requirements from 
the ATIS SMS to 9‐1‐1 Standards Activity (now a joint 
activity with TIA)
7

<this area for real time captions>
What is Presented Today

Each subgroup lead will present their draft findings, conclusions, and 
recommendations
– As a draft, the material is being presented to get the full committee’s 
comments to bring back to the subgroup for further analysis

Note that each subgroup independently developed its own findings
– Thus some of these findings and draft recommendations appear to overlap 
another subgroup’s findings and draft recommendations
– Demonstrates that different stakeholder groups reached many of the same 
conclusions

As a subcommittee, we have not attempted to achieve overall consensus 
on each of the subgroups’ recommendations – this will be the next step 
for the subcommittee
8

<this area for real time captions>

ORIGINATING DEVICES SUBGROUP 

9

<this area for real time captions>
User View ‐ Originating Devices Subgroup 

Chairs:  Christian Vogler  and  Donna Platt 

What users want is to be able to use to make calls using text or text+voice or 
Text+video.  (Note that the focus of this EAAC‐#1 PreNG9‐1‐1 Mobile Text group 
is just on ensuring that text can be used to get to 9‐1‐1) 
– Which devices do users want to use to call 9‐1‐1  in the interim?
– Which programs (e.g. SMS, AIM, etc.) do they want to use to call 9‐1‐1  in 
the interim?
– What devices/programs/services do users want to use in the long run? 
– If we stage text implementation (first SMS and later others) what is the 
desired order (ignoring technical issues for the non‐SMS text formats)?
– Routing and information needed for routing, (both to the Gateway ‐ Router 
structure and to the PSAP)
10

<this area for real time captions>

KEY FINDINGS (SUBTEAM 1)

11

<this area for real time captions>
Which devices do users want to 
use to text 9‐1‐1?
• EAAC Survey Question #21
• In order of importance
1.
Mobile phones and devices (61.8% for cell phone, 53.7% for 
smartphone, pager, PDA)
• basic phone
• feature phone
• smartphone
2.
Tablets (Survey results under “Others” shows that 9 respondents 
mentioned I‐Pads or I‐Pods, but these results may be out of date; 
tablet market share has increased since survey)
3.
Computers 
12

<this area for real time captions>
Which texting options would 
respondents like to be able to use?
• For all possible interim solutions, EAAC Survey Question 
#16
• In order of importance:
1.
SMS (45.1%) 
2.
Real‐time text (45.7%)
3.
E‐mail (43.7%)
4.
IM (31.1%)
5.
Web page (30.2%)
6.
Systems built into car (21.3%)
13

<this area for real time captions>
SMS‐based interim solutions
• For SMS‐based solutions ONLY:
• In order of importance:
1.
Native SMS
2.
Over‐the‐top SMS apps (3rd party app that goes through 3rd 
party service to send SMS to another device, on tablets and 
computers)
3.
Initiate voice call and then receive SMS
Note: This option is particularly valuable to hard of hearing 
users who have some voice communication capabilities
14

<this area for real time captions>
Other possible medium‐term interim 
solutions
• In order of importance
• Based on what PSAPs might be capable of soon:
1. Native messenger applications (e.g. Blackberry 
Messenger, iMessenger)
2. Real‐time text (RTT) + audio
3. Instant Messenger (IM) + audio
4. E‐Mail
15

<this area for real time captions>
“Long‐term” interim solutions
• Not likely to happen soon due to PSAP 
constraints
– Multi‐Media Services (SMS, MMS or other + pictures 
or pre‐recorded video)
– Web apps (EAAC survey, question 16)
– Other non‐SMS/non‐standard custom 9‐1‐1 apps.  
Also see EAAC survey results question 30, page 44
– Information transmitted from an autonomous device 
or application (OnStar, medical devices, etc.)
16

<this area for real time captions>

DRAFT RECOMMENDATIONS 
(SUBTEAM 1)

17

<this area for real time captions>
DIRECT ACCESS EXPECTATION
• Expectation
– Users have DIRECT access to 9‐1‐1 services. There 
are no third parties sitting in the path between 
callers and telecommunicators.
18

<this area for real time captions>
Order of short‐term interim solutions
Draft Recommendation 1:
– Implement native SMS first, followed by over‐the‐
top SMS, then native messenger applications, and 
real‐time text
– All following recommendations pertain to native 
SMS.
19

<this area for real time captions>
Method of contact
Draft Recommendation 2:
– The primary method of initiating contact with 9‐1‐
1 is via sending a text message using the three‐
digit code 9‐1‐1.
20

<this area for real time captions>
Method of contact
Draft Recommendation 3:
– Calling 9‐1‐1 via voice and receiving SMS should be 
supported, but only in addition to, not instead of, the 
method described in recommendation #2.
– Note: This option is particularly valuable to hard of 
hearing users who have some voice communication 
capabilities and are used to making voice calls with 
occasional fallback to text messaging.
21

<this area for real time captions>
No registration requirement
Draft Recommendation 4:
– Users must never be required to register prior to 
using text‐to‐9‐1‐1 services.
– However, users should be allowed, at their choice 
and where available, to register their profile and 
preferences voluntarily, so as to let PSAPs obtain a 
caller profile.
22

<this area for real time captions>
Immediate feedback on availability
Draft Recommendation 5:
– If PSAPs in the area do not support text‐to‐9‐1‐1 yet, 
the user must receive an automated text response 
immediately, stating that text‐to‐9‐1‐1 is not 
available.
– The exact contents of this message should be worked 
out in consultation with the NENA accessibility 
committee and other stakeholders.
23

<this area for real time captions>
Immediate feedback on availability
Draft Recommendation 6:
– If the user is roaming on a different wireless carrier from 
his own, thereby causing the routing of the text message 
to fail, or if routing the emergency text fails in any other 
way, the user must receive an automated text response 
immediately, stating that text‐to‐9‐1‐1 is not available.
– The exact contents of this message should be worked out 
in consultation with the NENA accessibility committee and 
other stakeholders.
24

<this area for real time captions>
Immediate feedback on availability
Draft Recommendation 7:
– If there is any delay in getting an SMS message 
processed by a PSAP (due to, for example, 
establishing a TTY call), the user must receive an 
automated text response, stating that the SMS 
message has been received and is being processed.
– The exact contents of this message should be worked 
out in consultation with the NENA accessibility 
committee and other stakeholders.
25

<this area for real time captions>
Routing
Draft Recommendation 8:
– The user must be able to text 9‐1‐1 and expect 
that the SMS message will be routed to an 
appropriate PSAP (and if a failure occurs, see 
recommendation #6). 
– At no point should the user be expected to 
provide routing information manually.
26

<this area for real time captions>
Information on availability of 
text‐to‐9‐1‐1
Draft Recommendation 9:
– The user must be able to easily obtain reliable and accurate 
information as to whether text‐to‐9‐1‐1 is available and 
possible in the current location with the current carrier and 
handset.
– At a minimum, there should be options to obtain this 
information (a) via the Web, and (b) directly via the user's 
handset (for example, a testing mechanism that yields an 
automated response from the gateway).
27

<this area for real time captions>
Not exposing inner workings
Draft Recommendation 10:
– The users need to not be required to know how 
exactly the appropriate PSAP receives an SMS  
message from the user.
– The call flow on the user side must remain the 
same, irrespective of how SMS messages are 
being processed by the PSAP.
28

<this area for real time captions>
Transition to NG‐9‐1‐1
Draft Recommendation 11:
– From the user view, the transition from an interim solution 
to NG‐9‐1‐1 solutions must be seamless. 
– If the carrier and PSAP support NG‐9‐1‐1, the user should 
not be required to switch to a different communications 
function, app, or handset in order to use the NG‐9‐1‐1 
functionality. 
– Nor should users be expected to know in advance of a call 
whether they will be using interim or NG‐9‐1‐1 methods.
29

<this area for real time captions>
Education and outreach
Draft Recommendation 12:
– Using categories and goals developed at the FCC 
outreach meeting on June 28, 2012 as a starting 
point, additional meetings with stakeholders 
should be convened to develop a detailed 
education and outreach plan for the interim SMS‐
based text‐to‐9‐1‐1 solution.
30

<this area for real time captions>

ORIGINATING DEVICES AND 
NETWORKS SUBGROUP 

31

<this area for real time captions>
Originating devices and networks view and issues Subgroup  

Chair:   Brian Daly         

The issues of concern, and the responsibilities of the originating devices 
and networks from a technical, service and policy point of view.

Which networks should support 9‐1‐1 mobile text ?

• mobile carrier voice networks (with SMS)
• mobile IP networks  (including SMS‐like over‐the‐top services)
• VoLTE (combination of above) (with SMS over IP)

Do phones or networks or both block three digit 9‐1‐1 SMS addresses?  (if phones ‐

how many phones?)

What are the originating network issues around SMS?

What are the originating network issues around other text formats?

• What order is most technically feasible to add other text formats?

Options for location provision. 

• Initial location provision in the call and possible updates from a moving caller.
32

<this area for real time captions>
Originating Networks Subgroup 
Draft Finding #1

Standards‐based open interoperable Solutions for 

Text to 911

:  the FCC should support non‐
proprietary, interoperable standards‐based text to 9‐
1‐1 solutions.
– The FCC should recognize that the joint ATIS‐TIA industry 
standards for wireless carrier native SMS to 9‐1‐1 is one 
such solution that is compliant with the FCC’s goal to 
encourage the rapid deployment of Text to 9‐1‐1. 
33

<this area for real time captions>
Rationale for:   Standards‐based open interoperable 
Solutions  for Text to 911

The FCC’s recognition of a standards‐based solution will encourage carriers and 
public safety to adopt Text‐to‐911in a consistent and timely fashion for the public.

The joint ATIS‐TIA SMS to 9‐1‐1 industry standards effort will support a flexible 
and interoperable environment for multiple wireless carrier and public safety 
network configurations.

The joint ATIS‐TIA SMS to 9‐1‐1 industry standard effort will define capabilities 
necessary to support SMS to 9‐1‐1, including standardized interfaces from the 
originating network to the PSAP, obtaining coarse location for routing, and 
managing the text message dialog between the originator and PSAP
telecommunicator.

The joint ATIS‐TIA SMS to 9‐1‐1 industry standards is an open standard available 
for any entity to adopt.
34

<this area for real time captions>
Originating Networks Subgroup 
Draft Finding #2

Interim Text‐to‐911 must use the Existing Standards‐based Network 

Architectures and Capabilities

:  any Text to 9‐1‐1 solutions, including SMS 
should be supported by the existing standards‐based network 
architectures. If SMS is to be utilized as the minimum technological 
solution, interim SMS based Text to 9‐1‐1 must utilize existing native 
wireless carrier SMS text capabilities. 
– The FCC  should recognize the capabilities and limitations of SMS as a 
9‐1‐1 service that have previously been documented and encourage 
consumers, industry and public safety to manage expectations and
provide liability protections to support Text‐to‐9‐1‐1 service 
accordingly.  
35

<this area for real time captions>
Rationale: Interim Text‐to‐911 must use the Existing 
Standards‐based Network Architectures and Capabilities

Delivery of Text to 9‐1‐1 from the wireless carrier infrastructure should be based on 
existing standards, interfaces and protocols used in that infrastructure. The existing 
wireless carrier SMS network architecture is standards based.  

Modification of the existing wireless carrier SMS network architecture is not 
technically or economically feasible because such modifications require 
development of new chipsets/firmware for mobile devices, and revision of existing 
network standards and elements in the core networks.  Modifications efforts will 
take many years by which time messaging capabilities for Next Generation 9‐1‐1 
could have already been developed and deployed.

Similarly, support for simultaneous voice and text (e.g. HCO/VCO) and the delivery 
of associated still or video images is not technically or economically feasible.

Enhanced capabilities should be addressed through the Next Generation 9‐1‐1 
standards that are under development.
36

<this area for real time captions>
Originating Networks Subgroup 
Draft Finding #3

Interim Text to 9‐1‐1 Will Only be Available to U.S. Wireless Subscribers Using 

Capable Wireless Handsets: 

Text to 9‐1‐1 may only be supported on service 
initialized and capable mobile devices for subscribers who maintain an 
appropriate wireless service plan that supports such text services. Text to 9‐1‐1 
should be available on existing and new text‐capable mobile devices which have a 
valid two‐way text messaging or data subscription which supports Text to 9‐1‐1 at 
the time of the initiation of a Text to 9‐1‐1 text message. Furthermore, the FCC 
should  recognize technical constraints which limit SMS‐based text to 9‐1‐1 as only 
being available while on the subscriber’s home network.

Consistent with the capabilities necessary to support Text to 9‐1‐1 services may 
not be technically or economically feasible. 
37

<this area for real time captions>
Rationale:
Interim Text to 9‐1‐1 Will Only be Available to U.S. 
Wireless Subscribers Using Capable Wireless Handsets

Wireless carrier SMS text message services are a subscription‐based 
service and only available on service initialized mobile devices.  Similarly, 
other text message capabilities are available only to subscribers of those 
services.

Support of SMS based Text to 9‐1‐1 on non‐service initialized mobile 
devices is not technically feasible with the existing design and, at a 
minimum, would require new standards and modifications to handsets 
and the wireless originator network radio and core infrastructure. In 
addition, Text to 9‐1‐1 supported on non‐service initialized mobile devices 
would impose significant technical and operational burdens on PSAPs.

Support for roaming inbound or outbound
38

<this area for real time captions>
Originating Networks Subgroup 
Draft Finding #4

Interim Text to 9‐1‐1 Messages Are Not Equivalent to Voice Calls 

Dialed to 9‐1‐1

:   The FCC should recognize that any Text to 9‐1‐1 
solution will not have the same capabilities or requirements as 
voice calls dialed to 9‐1‐1, including automatic number or location 
information, ability for a PSAP telecommunicator to listen to 
background audio, reliability, handling, security, privacy, etc.
– Consistent with Recommendation 1, however, a non‐proprietary, 
interoperable standards‐based text to 9‐1‐1 solution should support 
the capabilities necessary to support Text to 9‐1‐1, including 
standardized interfaces from the originating network to the PSAP, 
obtaining coarse location for routing, and managing the text message 
dialog between the originator and PSAP telecommunicator.
39

<this area for real time captions>
Originating Networks Subgroup 
Draft Finding #5

Managing Public Expectations is Critical during Interim Text‐to‐

911 Availability: The FCC  should take a lead role and work with the 
wireless industry, consumers and public safety to develop a public 
education program to appropriately explain the capabilities and 
limitations of interim Text to 9‐1‐1 service. The FCC should work 
with the wireless industry and mobile device manufacturers to 
identify and develop public education around wireless devices that 
do not support the ability to send a text message to the 3 digits “9‐
1‐1”. As part of managing public expectations, a text originator 
should receive a response notifying the originator if Text to 9‐1‐1 
service is not available.   
40

<this area for real time captions>
Rationale: Managing Public Expectations is Critical 
during Interim Text‐to‐911 Availability

Participating state and local jurisdictions must take a lead role in educating the 
public about the availability and limitations of Text‐to‐9‐1‐1 in their jurisdictions.  
Such entities should take comprehensive efforts to use available media for a 
period of three (3) months prior to initiating service.

If the text originator’s Text to 911 is delivered within the jurisdiction of a PSAP that 
supports Text to 9‐1‐1 capabilities, the PSAP must be responsible responding to 
the originator’s request.  

If text originator’s Text to 911 is sent within the jurisdiction of a PSAP that does 
not support Text to 9‐1‐1 capabilities, the originator should receive a text 
response message indicating that Text to 9‐1‐1 is not available in their location 
and that the originator should place a voice, relay or TTY call to the 9‐1‐1.  This 
text response message should be standardized across wireless operators as part of 
the joint ATIS‐TIA effort.
41

<this area for real time captions>
Originating Networks Subgroup 
Draft Finding #6

The originating networks subgroup identified an overall issue 

which should be addressed by each subgroup:

A Designated PSAP Must Demonstrate a Minimum Level of 

Readiness to Receive Text to 9‐1‐1

: The FCC should recognize that 
Text‐to‐9‐1‐1 should be implemented through a process whereby 
PSAPs must request to receive Text‐to‐9‐1‐1 messages from the 
appropriate entity and specifically authorize service providers or their 
designees to deliver Text‐to‐9‐1‐1 messages, demonstrate the 
technical ability to handle the receipt of the text messages in a 
standardized format, agree to a reasonable period of installation and 
testing prior to taking “live” calls, and demonstrate the operational 
ability to respond to an Text‐to‐9‐1‐1 message. 
42

<this area for real time captions>

TRANSPORT NETWORKS 
SUBGROUP

43

<this area for real time captions>
Transport Networks Subgroup
• Chairs:  Don Mitchell  and  Gunnar Hellstrom
A. Requirements
B.  Assumptions
C.  Architecture Components and Structure
D. Functionality and Protocols
E.  Organization and Responsibilities
F.  Limitations and Open Issues
44

<this area for real time captions>
Transport Networks Subgroup 
A)  Requirements
1. The transport network SHALL convey text messages directed to the short code “9‐1‐1” from 
a user’s terminals to the routing service which will select the geographically appropriate 
PSAP.
2. The transport network SHALL initially handle only SMS text originations but be standards‐
based and extendable to handle other text protocols.
3. The transport network SHALL link the user and the PSAP operator together in a session for 
the duration of a series of text interactions (a conversation).
4. The transport network SHALL adapt to protocols on the PSAP side based upon the 
capabilities of each PSAP.
5. The transport network SHALL support the initiation of text messages from the PSAP through 
the same infrastructure used in receiving text messages.
6. The transport network SHOULD, for the interim case, attempt to associate voice calls and 
text sessions with the same user device, with the goal that they end up in the same PSAP 
workstation
45

<this area for real time captions>
Transport Networks Subgroup 
B)  Assumptions

Communication service providers provide communication services to users 
including text. The possibility to handle text sessions with 9‐1‐1 is added to these 
services by the service providers.

The initially supported text service is the Short Message Service SMS. The 
architecture and functionality shall enable addition of other services in the same 
architecture. 

The mechanisms used shall work for both sessionless message communication 
(like SMS), and for session oriented messages initiated by a call to 9‐1‐1.

The communication service provider exchange user communication content with 
the transport network in specific interface points, where routing and protocol 
translation occurs.
46

<this area for real time captions>
Transport Networks Subgroup 
C)  Architecture components and structure

Descriptions of duties & requirements of C‐gateways. The transport and 
routing network is composed of i3 network ESRP/PRF/ECRF service 
elements.

It is recommended that an ESInet should be implemented which provides 
national level routing services to provide interconnection from carriers to 
State level ESInets (where they exist).
47

<this area for real time captions>
Transport Networks Subgroup 
D) Functionality and protocols

Routing protocols and information needed for routing are listed.

Pseudo session creation and maintenance, tying messages together into a 
session, and dissolving the session when appropriate.

What are the transcoding issues around SMS?

The main handling of transcoding issues is in the E‐gateway.

What are the transcoding issues around other text formats?

PSAP capability data base.
48

<this area for real time captions>
Transport Networks Subgroup 
E)  Organization and responsibilities
• The architecture provides flexibility as to who owns and 
manages the C‐gateways.
• PSAPs own and manage the E‐gateways
• A PSAP capability database needs to be set up and managed.
49

<this area for real time captions>
Transport Networks Subgroup 
F)  Limitations and open issues (1)
• A.4.[ROAMING]
• C.5.[SESSION LENGTH]
• C.6.[FUNCTIONAL LIMITS OF TTY]
• C.5.[MULTIPLE C GATEWAYS]
50

<this area for real time captions>

PSAP END SUBGROUP

51

<this area for real time captions>
PSAP End Subgroup

Chairs:

Roger Hixson and  Kathy McMahon

What text protocols can PSAPs accept?
– Range of protocols  (from  NG9‐1‐1 leaders to legacy PSAPs)

What forms of text would NG9‐1‐1 centers and ESInets normally accept?
– what is in i3?
– is anything other than i3 reasonable in interim?    In what order? 
– (this defines the forms the Gateways serving NG9‐1‐1/ESInet PSAPs must transform into)

What forms can the most limited PSAPs accept?
– (this defines the forms that  Gateways serving legacy PSAP must transcode into)

Call handling requirement internally in and among PSAPs. 
– Do they need to create multi‐party calls with this type of sessions? 
– Do they need to transfer the calls between PSAPs at different stages ‐ legacy ‐ interim ‐ NG?
52

<this area for real time captions>
PSAP End Subgroup 
Draft Finding #1
• The FCC should require Short Message Service (SMS) 
as the initial deployment priority for text to 9‐1‐1
– Maximum integration with existing PSAP call handling and 
logging systems is desirable.
– Should use digits 9‐1‐1 and not require a 9‐1‐1 voice call to 
be placed first 
53

<this area for real time captions>
PSAP End Subgroup 
Draft Finding #2
• Expectations of FCC
– Do not mandate PSAPs to accept text – pursue ongoing dialogue 
– Facilitate process for a national single point of contact for PSAPs to 
provide text readiness and delivery preferences
– Support public education of interim text to 9‐1‐1
– Assess expectations of proprietary solutions that have been deployed
54

<this area for real time captions>
PSAP End Subgroup 
Draft Finding #3
• Expectations of Wireless Service Providers (or their contracted 
vendor)
– Routing to designated 9‐1‐1 system or PSAP
– Caller location equivalent to WLS Phase I (cell/sector)
– Efficient process for gathering delivery preferences from PSAPs
– Continuous connection between text caller and PSAP
– Texts sent in chronological order
– Standardized automatic message to caller if text to 
– 9‐1‐1 is not supported in an area
– Message delivery confirmation to caller 
55

<this area for real time captions>
PSAP End Subgroup 
Draft Finding #4
• Expectations of PSAPs
– Proactively assess delivery interface options, consider 
designated PSAP/regional approach if necessary
– Formally designate willingness to accept text calls
– Keep delivery preferences up to date with service provider(s) or 
designated party/vendor
– Local policies to determine operational issues such as:
• How long a call taker remains ready to accept text from a specific 
caller
• How medical pre‐arrival instructions are handled 
56

<this area for real time captions>
PSAP End Subgroup 
Draft Finding #5
• Additional Considerations
– Other forms of interim media and text for 9‐1‐1 services 
already in‐place should be considered for national level 
support/delivery and worked in parallel to SMS
– Location of the calling device and ability to update location 
during a call
– Ability to transfer text calls 
– Class of Service defined and delivered for E9‐1‐1 text
57

<this area for real time captions>

JOINT ATIS/TIA SMS TO 9‐1‐1 
STANDARDS ACTIVITY

58

<this area for real time captions>
Joint ATIS‐TIA SMS to 9‐1‐1 Standards

There are currently multiple vendor‐specific solutions that are being 
adopted in various regions of the USA (e.g., some within a single city, 
others within an entire state) for texting to 9‐1‐1

ATIS members recognize that if this trend continues, then texting to 9‐1‐1 
will turn into a regional service
– The public’s expectations have been set for voice 9‐1‐1 calls such that they 
expect to be able to talk to an emergency attendant whenever and wherever 
they dial 9‐1‐1 in the United States
– Customer confusion will reign if texting to 9‐1‐1 does not meet similar 
nationwide service expectations, i.e., a similar “look and feel” for texting to 9‐
1‐1 regardless of where the text is originated in the United States
59

<this area for real time captions>
Joint ATIS‐TIA SMS to 9‐1‐1 Standards

The standards solution under development should allow any end user 
device with SMS capabilities and a valid SMS texting subscription to 
launch an SMS text message to begin a text communication with the 
relevant PSAP

Messaging applications that do not use 3GPP or 3GPP2‐defined SMS text 
messages are not within the scope of this project

The solution will require that a user subscribe to SMS text service, i.e., if a 
subscriber has an SMS‐capable phone but does not subscribe to an SMS 
texting service, the user cannot initiate SMS‐to‐9‐1‐1. Also, an 
uninitialized phone cannot participate in SMS‐to‐9‐1‐1. Other use cases 
are for further study, e.g., pre‐paid, services under treatment, etc. 
60

<this area for real time captions>
Joint ATIS‐TIA SMS to 9‐1‐1 Standards
• Some form of coarse location (e.g., serving cell site or coarse 
lat/long generated perhaps from an operator’s Location‐Based 
Services {LBS} platform) should be able to be used to allow for 
routing of the SMS‐to‐911 message to the correct PSAP
– Location, routing, and nationwide roaming are all critical aspects of 
this project, and requirements will need to be developed to ensure 
feasible solutions can be put into place
• The solution should be available to everyone with SMS texting 
capabilities, not just to people with disabilities (e.g., no advance 
registration procedures to “subscribe” to the SMS‐to‐9‐1‐1 service 
are required) 
61

<this area for real time captions>
Joint ATIS‐TIA SMS to 9‐1‐1 Standards
• The goal is to create a joint ATIS/TIA standard(s) for SMS‐to‐9‐
1‐1 that incorporates requirements, architecture, message 
flows, and protocol details
– Multi‐carrier, multi‐vendor, multi‐PSAP nationwide solution
– First major accomplishment is the completion of a vendor‐neutral 
common architecture (see next slide)
• Target completion is 4Q2012
62

<this area for real time captions>
63

<this area for real time captions>

NEXT STEPS FOR SUBCOMMITTEE

64

<this area for real time captions>
A Way Ahead

Interim Text to 9‐1‐1 Subcommittee will work to gain consensus on each 
of the subgroup recommendations as it prepares its final report and 
recommendations

Each subgroup will finalize draft conclusions and recommendations

Similar recommendations across subgroups will be consolidated into a single overall 
recommendation

Draft Interim Text to 9‐1‐1 Subcommittee Report & Recommendations 
document will be presented in the October 12 EAAC meeting

Final Interim Text to 9‐1‐1 Subcommittee Report & Recommendations 
document to be presented in the November 9 EAAC meeting
65

Note: We are currently transitioning our documents into web compatible formats for easier reading. We have done our best to supply this content to you in a presentable form, but there may be some formatting issues while we improve the technology. The original version of the document is available as a PDF, Word Document, or as plain text.

close
FCC

You are leaving the FCC website

You are about to leave the FCC website and visit a third-party, non-governmental website that the FCC does not maintain or control. The FCC does not endorse any product or service, and is not responsible for, nor can it guarantee the validity or timeliness of the content on the page you are about to visit. Additionally, the privacy policies of this third-party page may differ from those of the FCC.