Interim Text to 9-1-1 Working Group
<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
<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>
<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>
<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>
<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>
<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.
–
• mobile IP networks (including SMS‐like over‐the‐top services)
• VoLTE (combination of above) (with SMS over IP)
–
–
–
32
<this area for real time captions>
Originating Networks Subgroup
Draft Finding #1
•
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
•
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
•
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
•
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
•
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
•
–
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>
<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>
<this area for real time captions>
PSAP End Subgroup
•
•
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>
<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>
<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
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 &
C
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)
<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
<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 SMSshould 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 serviceinitialized 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‐1solution 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 thewireless 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 thatText‐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
<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
<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.
