Page1of45

TABLEOFCONTENTS
EXECUTIVESUMMARY................................................................................................................................................... 3 1. INTRODUCTION..................................................................................................................................................... 5 2. OVERVIEWOFPOTENTIALTECHNIQUES............................................................................................................... 6 2.1 INSTANTMESSAGING...................................................................................................................................... 6 2.2 VIDEOASL........................................................................................................................................................ 8 2.3 RTTENDTOEND........................................................................................................................................... 0 1 2.4 RTTWITHTTY................................................................................................................................................ 2 1 2.5 SMSTO911................................................................................................................................................. 4 1 2.6 VOICEEMERGENCYCALLTHENSMS............................................................................................................. 5 1 2.7 TTYEMULATION............................................................................................................................................ 8 1 2.8 NATIONALSMSRELAYCENTER..................................................................................................................... 1 2 2.9 VIDEORELAYSERVICE................................................................................................................................... 5 2 2.10 IPBASEDRELAYSERVICE.......................................................................................................................... 8 2

3. ANALSYSOFPOTENTIALTECHNIQUES................................................................................................................ 2 3 3.1 DEFINITIONOFANALYSISCRITERIA .............................................................................................................. 2 . 3 3.2 SIDEBYSIDETECHNIQUECOMPARISON...................................................................................................... 4 3 4. CONCLUSIONS ..................................................................................................................................................... 6 . 3 APPENDIXA. A.1 A.2 ACRONYMSANDDEFINITIONS........................................................................................................ 8 3

ACRONYMS.................................................................................................................................................... 8 3 DEFINITIONS.................................................................................................................................................. 0 4 DESCRIPTIONOFINSTANTMESSAGINGARCHITECTURE&PROTOCOLS........................................ 1 4

APPENDIXB. B.1 B.2

ARCHITECTURE&PROTOCOLS...................................................................................................................... 1 4 LIMITATIONS................................................................................................................................................. 3 4

ACKNOWLEDGEMENTS ............................................................................................................................................... 5 . 4
Page2of45

EXECUTIVESUMMARY
ThereisadesirebyboththeEmergencyServicescommunityandthecommunityofindividualswithdisabilitiesto have text based wireless communications with emergency services. Both NENA (National Emergency Number Association)and3GPP(3rdGenerationPartnershipProject)havedevelopedusecasesandrequirementsforalong term IMSbased multimediasolution andprovide a rich set of emergencycommunications capabilities in aNext Generation 911 (NG911) environment. This long term solution would provide accessibility to emergency services for the general public including individuals with disabilities. However, the development and implementationofthelongtermsolutionwilltakeseveralyears.Aninterimsolutionthatwillsupportatminimum textbasedcommunicationsforindividualswithdisabilitieshasbeenrequested. Thepurposeofthiswhitepaperistoinvestigateoptionsforaninterimsolutionthatcanbesupportedbytheboth the existing wireless networks and Public Safety Answering Points (PSAPs). Any interim solution chosen should haveminimalimpactsontheentireemergencyservicessystem.Enduserdevicesandoriginationnetworksshould useexistingtechnologiesandshouldbeavailabletosupportaninterimsolutionasquicklyaspossible.Likewise, theemergencyservicesnetworksshouldrequirelittletonochange.Thefocusofthiswhitepaperisbasedonthe useofexistingtechnologiessuchasGSMandUMTScircuitandpacketservices.TheLTEandIMStechnologiesare notwithinthescopeofthiswhitepapereventhoughtherearesomeLTEandIMSdeploymentsinexistence.Itis expected that the long term Multimedia Emergency Services (MMES) solution being specified in 3GPP will be supportedintheLTEandIMSenvironments. Thefollowingpotentialtechniquesforaninterimsolutionareexaminedinthiswhitepaper: InstantMessaging(IM) VideoAmericanSignLanguage(ASL) RealtimeText(RTT)EndtoEnd RTTwithTTY SMSto911 VoiceEmergencyCallthenSMS TTYEmulation NationalSMSRelayCenter VideoRelayService IPBasedRelayService

Eachofthesepotentialtechniquesisdescribedinsection2ofthiswhitepaperandthesedescriptionsincludethe benefits and limitations of each technique. Section 3 of this white paper provides a color coded sidebyside comparisonofeachpotentialtechnique. Basedupontheanalysiscontainedwithinthiswhitepaper,thefollowingconclusionscanbedrawnregardingan interimshorttermsolution: 1. Allofthesepotentialtechniqueshaveissuesandlimitationswhichimpactstheuseofthetechnique asaninterimshorttermsolution.Subscriberswillneedtobeeducatedthatanyinterimsolutionwill havelimitationsandrestrictions. RelaybasedservicessuchasVideoRelayServiceandIPBasedRelayServicearepotentialtechniques foraninterimsolution.Thesetechniqueshaveminimalimpacttoexistingmobiledevices,towireless networkinfrastructure,andtoemergencyservicesnetworks.
Page3of45

2.

3.

SMSbasedtechniquessuchasNationalSMSRelayCenterandtheVoiceEmergencyCallthenSMSare potentialtechniquesforaninterimsolution,ifanSMSbasedsolutionisrequired.TheseSMSbased techniqueshavethesameinherentissuesofSMSasdescribedinthe4GAmericaswhitepaperon textingto9111whichwaspublishedinOctober2010.Thesetechniqueshavelittleornoimpactto the wireless networks and limited impact to the emergency service networks. However, not all currently deployed mobile devices will support the Voice Emergency Call then SMS technique. The VoiceEmergencyCallthenSMStechniqueiscurrentlyundertrialinCanada. SMSto911continuestohaveseriousissuesandlimitationsasdescribedinthe4GAmericaswhite paperontextingto911.ImplementationofSMSto911wouldhavesignificantimpactstowireless networkinfrastructureandtotheemergencyservicesnetworksand,therefore,isnotconsideredto beasuitableinterimsolution. Interimsolutionsbaseduponrealtimetext(RTT)arenotfeasibleasinterimsolutionssincethe3GPP standards for the support of RTT in wireless networks requires the IMS (IP Multimedia Subsystem) subsystem.TheIMSsubsystemisnotwidelydeployed,isnotlikelytobedeployedon3Gsystems, willnotbedeployedon2Gsystems,andisnotsupportedbythemobiledevicescurrentlybeingused bythesubscribers. InstantMessaging(IM)isnotconsideredtobeaviabletechniqueforaninterimsolution.Generally, the IM services available to subscribers today are the services offered by the major IM service providers such as AOL, Yahoo, Google, and Microsoft. None of these services currently support emergencymessagingsoadditionaldevelopmentwouldberequiredbythesethirdpartyIMservice providers and by the PSAP systems. Additionally, since these systems are proprietary, the PSAP systemsmayhavetointerfacetoeachoftheseIMservices. Video ASL is not considered to be a viable technique for an interim solution. The ability of the existing wireless network to support the required video resolution is marginal. The PSAP systems wouldneedtobeupdatedtosupportincomingvideocalls.Additionally,proficiencyinAmericanSign LanguageisnotacommonskillforPSAPcalltakers. TTY Emulation is not a viable technique for the interim solution. For TTY Emulation to work effectively modifications to the mobile device operating systems are required which implies new mobiledevicedevelopmentandnewmobiledeviceacquisitionbythesubscribers.Initialprototype systemshavedemonstratedthepotentialoftheconceptbuthavenotyetbeenabletomeettheFCC requirementsforerrorrate.

4.

5.

6.

7.

8.

Noneoftheshorttermtechniquesformultimediaemergencyservicescanbesupportedwithoutasignificant developmenteffort.Theimplementationofanyshortterminterimtechniquesformultimediaemergencyservices willrequireresourcesandtimetodevelopanddeploy.Also,theissueoffundingforthedevelopmentand deploymentofanyshorttermtechniquealsoneedstobeaddressed.

1 4GAmericas,Textingto911:ExaminingtheDesignandLimitationsofSMS,October2010.
Page4of45

1.

INTRODUCTION

ThereisadesirebytheEmergencyServicescommunity,aswellas,thecommunityofindividualswithdisabilitiesto havemultimediaemergencyservicessupportedwiththesamegeneralcharacteristicsasemergencyvoicecalls.As aresult,thereisaneedtocommunicatewithemergencyservicesusingmechanismsthatarenotprimarilyvoice. NENA and 3GPP have developed use cases and requirements for multimedia emergency services. Multimedia EmergencyServices(MMES)standardswillofferalongtermIMSbasedmultimediasolutionandprovidearichset of emergencycommunications capabilities in a NG911environment.MMES standards are intended to support textcommunicationsbetweenendusersandemergencyservices. The MMES standards capabilities will facilitate emergency communications by the general public including individualswithdisabilities(e.g.,personswhoaredeaf,deafblind,hardofhearing,orhaveaspeechdisability). TheMMESstandardssolutionshouldbeviewedasthelongtermsolutionforprovidingaccessibilitytoemergency servicesnotonlytopeoplewithdisabilities. As this is a major change to the 911 system, adoption of MMES standards capabilities will take several years. Therewillbesignificantimpactstotheentireemergencyservicessystemresultingfromthechangesinnetworks anddevices.Itisexpectedthatenduserdevicesandoriginationnetworkswillultimatelyevolve,andthatthenext generation emergency services solution will allow this evolution to take place over time. Many systems in the emergency services network must eventually change. New endtoend messaging relationships must be established. Theremaybeaneedtoprovideamultimediaemergencycommunicationssolutionpriortotheavailabilityofthe long term MMES standards based upon IMSbased networks. A number of potential interim solutions are examinedinthiswhitepaper. Any interim solution chosen should have minimal impacts on the entire emergency services system. End user devices and origination networks should use existing technology and should be available to support an interim solution as quickly as possible. Likewise, emergency services networks should require little to no change. The focusofthiswhitepaperisontheuseofexistingpotentialtechnologiesthatincludesGSMandUMTScircuitand packetservices.TheLTEtechnologyisnotwithinthescopeofthiswhitepapereventhoughtherearesomeLTE deploymentsinexistence. Thispaperisintendedtoidentifyandanalyzethevariousinterimpotentialsolutions.Itwillalsoidentifythebest possibleinterimmultimediaemergencycommunicationsolution,andidentifyanygapsforanendtoendinterim multimediaemergencycommunicationsolution,includingimpactstosubscribersandtoPSAPs. TheacronymsanddefinitionsusedinthiswhitepaperareprovidedinAppendixA.

Page5of45

2.

OVERVIEWOFPOTENTIALTECHNIQUES

Thissectiondiscussesthefollowingpotentialtechniquesforprovidinganinterimsolution: InstantMessaging(IM) VideoAmericanSignLanguage(ASL) RealtimeText(RTT)EndtoEnd RTTwithTTY SMSto911 VoiceEmergencyCallthenSMS TTYEmulation NationalSMSRelayCenter VideoRelayService IPBasedRelayService

The discussion of each potential technique includes a description, the potential benefits, and any associated limitations. Thereisnoimpliedpreferenceofthepotentialtechniquesbasedupontheorderwithintheabovelistandwithin thissection.

2.1

INSTANTMESSAGING

DESCRIPTION Instant Messaging (IM) is apacket basedservice that isone of the fastest growing forms of communication. IM allows users to instantly exchange messages back and forth often within a session but also as standalone messages, thereby permitting communication to happen in near realtime on a message by message basis. Depending upon the IM application, messages are primarily simple textual messages or less frequently the IM messagesmayberichermultimediamessages.IMworkseitherfromauserspersonalcomputerormobiledevice. From an endusers perspective, IM is simple to operate. The user chooses an IM application, downloads and installsanIMclientsoftwareontheirdeviceusuallyalaptop,PCormobile.TheclientisaGUIbaseddevicewith interfacestotypemessagesandseetheresponses.Theuseralsocreatesauseraccountwithaloginandpassword thatisassociatedwiththeserviceandconfigurestheIMclientapplicationtologinunderthatidentity.Almostall IMapplicationsallowasubscribertocreateandmanageacontactslist(alsoknownasbuddiesorfriendslist ontheserver.Mostservicesallowthoseonthelisttoseetheusersstatusandtosendmessageswithoutfurther permission. The user also has the ability to set attributes relating to their IMpersona this may include their currentconnectionstatus(available,idle,donotdisturb,etc.),moods(happy,sad,boredetc.) Most IM services support presence, where the users friends and their corresponding statuses (online, invisible, idle,offline,mood,andstatusmessage)appearintheusersclientsoftwareGUIwindowontheenddevice. A user starts a chat session, often withanother userwho is ontheir friendslist and who is also online.Many servicesalsosupportsendingmessagesoutsideofasession(e.g.,standalonemessages)and/orsendingmessages or starting a chat session with a user who is not on the contacts list. The user doubleclicks on another users
Page6of45

nameinthefriendslisttopullupachatwindowortypesanIMidentityintoamessagewindow.Theusertypesin a message and presses send. This message appears on a GUI chatwindow on the users friends end device throughwhichtheusersfriendhasloggedintotheIMapplication.Messagescanbeexchangedbackandforththis way.Ausermaycommunicatewithmultipleusersviagroupchat. Mostservicesallowuserscontroloverwhocansendthemmessages,initiatechatsessions,andseetheirstatus, suchasallusers,onlythoseontheircontactlist,ortorequestpermissioneachtime. IMisnotlikeSMSbecausetherearemultipleproprietaryimplementationsofIM(suchasYahooMessenger,AOL IM,MSN,GoogleTalk,XMPP/JabberorSIP).DuetothemultipleimplementationsofIM,itispossibleforauserto subscribetomorethanoneIMserviceinordertobeabletocommunicatewithalloftheirfriends.Manyservices have their own dedicated client software application, but independent multiprotocol clients are also popular, which support simultaneous usage among multiple services and multiple instances of decentralized services. In addition to clientbased interworking, serverbased interworking is supported by some service applications and therebyhasmultipleIMclientsontheirenddeviceforinstance,ausermaysubscribesimultaneouslyanduse YahooMessenger,GoogleTalk,andMSNetc. Instant Messaging applications consist of two components: a) client software and b) server software. Although someIMapplicationsworkthroughawebbrowserinterface,mostIMapplicationsrequireclientsoftwaretobe installed on the client device and either preconfigured with the address and port of the IM server to which to connectto,ortouseadiscoverymechanismsuchasDNS.Additionally,theclientmayalsobeconfiguredwiththe users account information (Login and Password) using which the server authenticates the enduser. The server maintains the users contact list information and allows the user to manage it. It acts as a crossconnect for communicationtrafficbetweenconsentinguserswhoareonline.Someserversmayhavethecapabilitytostore offlinemessagesanddeliverthemlaterwhenausercomesbackonline2. AdescriptionofthearchitectureandprotocolsforInstantMessagingisprovidedinAppendixB. TheutilizationofIMforemergencycommunicationswiththePSAPwouldrequiretheendusertoestablishachat sessionwiththePSAP.ToestablishanemergencyIMsessionwithaPSAP,theIMservicewouldberequiredtodo thefollowing: BENEFITS IMlendsitselftomultimediacommunicationandparticularlytotheneedsofthedisabledcommunity.Itisnear realtime,widelyusedandfreelyavailable.ManyIMapplicationssuchasYahoo!MessengerandGoogleTalkcan befreelydownloadedfromtheInternetandworkwithmostoperatingsystem.Manypopulardevices,including desktop, laptop, notebook, mobile, and pad devices, come bundled with IM applications supported by the operatingsystemordevicevendor.IMcancarrytextorothermultimediacontentwithinthesamearchitectural
2

Recognizeemergencyservicesrequest(e.g.,SOS,911)asaspecialIMidentityforemergencyservices; Determinethesubscriberslocation(e.g.,promptthesubscriber); DeterminetheappropriatePSAPforthesubscriberslocation; MaintainachatassociationbetweenthesubscriberandthePSAP.

HowInstantMessagingWorks,InformationManagementJournalNov/Dec2003at
http://findarticles.com/p/articles/mi_qa3937/is_200311/ai_n9328272/(AccessibleasofJan31st,2011). Page7of45

framework. Additionally, it provides mechanisms for location to be specified as a Presence attribute although thisisnotyetprevalentlydeployed. Multiprotocol clients offer extremely broad interworking among virtually all IM services. Serverbased interworkingisalsoavailable. LIMITATIONS This service requires packet data service and an IM application that is compatible with the chosen PSAP IM application(s). Enhancements are required in the IM client application and in the IM service provider platforms to support IM basedemergencyserviceswithPSAPs. ThereisaplethoraofIMapplicationsavailablethatvarywidelyintheirfeatures,capabilities,andimplementation. ThispresentschallengestothePSAPwhomayhavetosupportallavailableIMtypesinorderforallsubscribersto beabletoreachthem. Interoperability between IM applications remains an issue. Most clientserver protocol implementations are proprietary.WhiletherehavebeensomecollaborationbetweenthemajorIMproviders,nouniversalstandardhas takenhold. Some IM applications have a store and forward capability. Like SMS, the store and forward capability could be detrimentalduringanemergency. IM applications do not have the capabilities of the current circuitswitch centric 911 call routing and location infrastructuretobeabletosupportthelocationdeterminationandIMsessionroutingtotheappropriatePSAP. AdditionalinformationaboutthelimitationsofIMforemergencyservicesiscontainedinAppendixB.

2.2

VIDEOASL

DESCRIPTION With the advent of smartphones with photo/video capability, people who communicate with American Sign Language(ASL)couldutilizesuchdevicestointeract.ResearchisbeingconductedintheUS3toimprovethevideo compressionratioinsituationswherewirelessbandwidthislimited.Suchtechniquesmustmaintaincompatibility with existing video compression standards like H.264/AVC. Any video telephony application that provides the capabilityforindividualstocommunicateusingASL,canbeconsideredasVideoASL. Basedonsomepublishedresults,thefollowingcharacteristicsareofinterest: 95%ofeyemovementswithin2degreesvisualangleofthesignersface o Implications:Faceregionofvideoismostvisuallyimportant Detailedgrammarinfacerequiresfovealvision Handsandarmscanbeviewedinperipheralvision

3 Foradditionaldetails,pleaserefertohttp://mobileasl.cs.washington.edu/
Page8of45

Increased bit rate improved user experience. Please refer to Figure 1: User Preferences Results for VariousBitRatesandFrameRates. Higherframerate,however,didnotresultinimproveduserexperience.

Figure1:UserPreferencesResultsforVariousBitRatesandFrameRates TheutilizationofVideoASLforemergencycommunicationswiththePSAPwouldrequiretheendusertoestablish avideosessionwiththePSAP.ToestablishanemergencyvideoASLsessionwithaPSAP,theVideoASLservice wouldberequiredtodothefollowing: BENEFITS This service enables hearing and speech impaired users to use and existing technology to interact. It requires minimalchangestostandardsandcanbereadilydeployedandused. LIMITATIONS EnhancementsarerequiredintheVideoASLclientapplicationandintheVideoASLserviceproviderplatformsto supportVideoASLbasedemergencyserviceswithPSAPs.
Page9of45

Recognizeemergencyservicesrequest; Determinethesubscriberslocation(e.g.,promptthesubscriber); DeterminetheappropriatePSAPforthesubscriberslocation.

There is a plethora of video applications available that vary widely in their features, capabilities, and implementation.ThispresentschallengestothePSAPwhomayhavetosupportallavailablevideotypesinorder forallsubscriberstobeabletoreachthem. Thisservicerequiresaphonecapableofvideotelephony(e.g.,frontfacingcamera,appropriatevideoapplications, handsetpositioningstand)thatiscompatiblewiththePSASvideotelephoneapplication(s).Although,manyofthe recentsmartphoneshavethiscapability,itisnotuniversallyavailableinalldevices. VideoASLrequiresadatapacketservicewithaminimumbitratetoworkproperly;assuch,itisnotsuitablefor legacy(2G)accesstechnologies. PSAPsarenotcurrentlyequippedtohandlethisservice.

2.3

RTTENDTOEND

DESCRIPTION Insomemarkets,thereareregulatoryrequirementsthatpeoplewithahearingorspeechdisabilitymustbeableto performtextbasedcommunication.Forthe3GPPpacketdatabasedIPMultimediaSubsystem(IMS),GlobalText TelephonyviatheRealTimeTextprotocoloverRTP(i.e.,GTTIP)hasbeenspecifiedby3GPPinTS22.2264andin TS23.2265toaddresstheseregulatoryrequirementsusingpacketdata.GTTIPissupportedusingIETFSIP/SDPfor thenegotiationofthetextmediaandIETFRFC41036RTPtextfortransport,withtextcodedaccordingtoITUT Recommendation T.1407. This allows conversation in a selection of simultaneous media, such as voice, text and potentiallyalsovideo. ThecallingpartyidentityandlocationinformationaresupportedasinIMSpacketdatavoiceemergencycalls. Dependingonlocalregulationandoperator'spolicy,itmayalsoberequiredtosupportemergencycallsoriginated byterminalswithoutavalidsubscription.InthesecasesRTTissupportedasinthecaseofIMSemergencycallsfor UEwithavalidsubscription. The figure below illustrates an IMS terminal that originates an IMS call containing both packet voice and RTT media,whereeachmediaisconveyedinanindependentmediastream.ThefarendcanbeanIMSnetwork,aPS packetdatanetworksupportingRTTusingSIP/SDPorapacketdataPSterminalsupportingRTTviaSIP/SDP.

3GPPTS22.226:GlobalTextTelephony(GTT),Stage1 5 3GPPTS23.226:GlobalTextTelephony(GTT),Stage2. 6 IETFRFC4103:"RTPText.RTPPayloadforTextConversation". 7 ITUTRecommendationT.140:"Textconversationpresentationprotocol".

4

Page10of45

Text/RTP Voice/RTP IMS Terminal

IMS/PS Originating Network

PS Terminating Network

Text/RTP Voice/RTP PS Terminal

Figure2:IMSTerminalwithvoiceandRTTmedia Inclusion of the text conversation is done according to normal SIP and IMS procedures, where the text media streamishandledasanyothermedia.ItispossiblethatanIMScallcanbesetupusingonlytextmedia. ItisassumedthatIMSterminalssupportingtextmediawillnotautomaticallyoffertextmedia,butthatthiswillbe insteadgovernedbyterminalconfigurationoptionsanduserinteractionstosuitthecommunicationpreferences andabilitiesoftheuser.However,anIMSterminaldesiringtosetupaRTTcallwillofferRealTimeTextmedia, possibly in parallel to voice media. For a call terminating to an IMS terminal configured to use RealTime Text TelephonybutreceivinganSDPofferforvoiceonlymediawillacceptthisofferandthensendasubsequentSDP offeraddingtextmediainadistinctSDPmedialine(e.g.,usingaSIPUPDATE). GTTIPhasnoarchitectureinfluenceonthe3GPacketServices(PS)network,onlythatthecomponentsmustallow handling of the standardized text media stream. If GTTIP will be used to support IMS emergency calls where terminals without a valid subscription must be supported then only PS for UTRAN and EUTRAN have been specifiedtoallowaccesstomeettheseregulatoryrequirements. BENEFITS RTTallowscharacterbycharactertransmission,similartoTTY. RTTmaybemorereliablethanTTYoverwirelesssincetheprotocolsupportssendingRTTwithredundancysent compared to TTY being sent as tones on the voice channel where some voice frames can be dropped and not recovered. Optionally, RTT can be used simultaneously with other media types (e.g., voice, video), unlike TTY that is transmittedonthevoicechannel. LIMITATIONS RTTsupportisneededbothinIMSandatthefarend(e.g.,otherIMSnetwork,IPnetworkorIPterminal). RTTrequirespacketdataserviceandIMS.

Page11of45

2.4

RTTWITHTTY

DESCRIPTION For the packet data based IP Multimedia Subsystem (IMS), IMS interworking between RealTime Text (RTT) and PSTNtexttelephonyisspecifiedby3GPPinTS22.2268,TS23.2269andTS29.16310byintroducingconversioninthe IMSPLMNbetweenIPbasedRealTimeTextviaRTPandmodembasedtransmissionofrealtimetextusingITUT RecommendationV.1811oranyofitsspecificsubmodesasspecifiedinTS26.11412. ThecallingpartyidentityandlocationinformationaresupportedasinIMSpacketdatavoiceemergencycalls. Dependingonlocalregulationandoperator'spolicy,itmayalsoberequiredtosupportemergencycallsoriginated byterminalswithoutavalidsubscription.InthesecasesRTT/V.18interworkingissupportedasinthecaseofIMS emergencycallsforUEwithavalidsubscription. CallbackfromemergencyservicesisinterworkedasanIMSMobileTerminatingcall. The interworking (conversion) function can be seen as a context containing a packet data Text/RTP termination plus a packet data voice/RTP termination on the IMS side and an ITUT Recommendation V.1811 text telephony terminationwithmultiplexedV.18andvoiceviaPCMonthePSTNsideasillustratedbelow.

Text/RTP Voice/RTP IMS Terminal IMS/PS Originating Network

Text/RTP

Text/V18/PCM

PSTN
Voice/RTP Voice/PCM

V18/PCM + Voice/PCM

MGCF/ IMS-MGW Interworking

legacy TTY phone

Figure3:RTTInterworkingwithPSTN InthePSTN,differentspecifiedsystemsfortexttelephonyexistandareusedindifferentregions,e.g.Baudot(in US), EDT, V.21, Bell103, Minitel and V.18. They all use different modem technologies within PCM and different charactercodingforthetransmissionoftext.TheyaredescribedintheannexesofITUTRecommendationV.18 [125]. ITUT Recommendation V.1811 is an international text telephone modem standard with an automoding mechanismthatenablescommunicationwithallthedifferentkindsofPSTNtexttelephonesystems.Optionally, anypartyofaRTTcallmayatanytimeinitiatetextorsendvoice.Speechandtextmaybeusedinanalternating mannerduringaconversationonthePSTN.Itisalsopossiblethatspeechistransferredinonedirectionandtextin theoppositedirection.However,speechandtextcannotbeusedinthesamedirectionatthesametimeinmost submodesofV.18. 8 3GPPTS23.226:GlobalTextTelephony(GTT),Stage1. 9 3GPPTS23.226:GlobalTextTelephony(GTT),Stage2. 10 3GPPTS29.163:"InterworkingbetweentheIMCNsubsystemandCSnetworksStage3". 11 ITUTRecommendationV.18(11/00):"OperationalandinterworkingrequirementsforDCEsoperatinginthetexttelephone mode"includingV.18(2000)Amendment1(11/02):"HarmonizationwithANSITIA/EIA825(2000)textphones". 12 3GPPTS26.114:"IPMultimediaSubsystem(IMS);MultimediaTelephony;Mediahandlingandinteraction".
Page12of45

In the3GPP CS radio interface, adedicated CTM modem is used which is terminated within theCS domainand interworkedtoPTSNinbandTTYformat. Similarly,interworkingbetweenRTToverRTPwithinIMSandPSTNTTYisprovidedattheMGCF/IMMGWbythe MGCFtriggeringtheinsertionofanInterworking(conversion)functionwithintheIMSMGWwhichthenbehaves inaccordancewithITUTRecommendationV.1811oranyofitsspecificsubmodes. The support of this Interworking function between IPbased RealTime Text over RTP and modem based transmission of realtime text is optional both at the MGCF and IMMGW, but can be required by national regulatorybodies. TheInterworkingfunctionintheIMMGWshallsupportthedetectionoftextmodemsignalsontheCSsideand theconversionbetweentext/modemsignalsandRealTimeTextoverRTP. TheIMMGWsupportsatleastoneofthesubmodeslistedinITUTRecommendationV.1811(e.g.Baudot). The procedures to detect and convert text/modem involve expensive MGW resources. The present RTT interworkingproceduresintendtoallowcosteffectiveimplementationsbyavoidingadditionalloadorresourcesin MGWforcallsnotusingtexttelephony(whichrepresentmostofthecalls). ItisassumedthatIMSterminalssupportingRTTwillnotautomaticallyofferRTTmedia,butthatthiswillbeinstead governed by terminal configuration options and user interactions to suit the communication preferences and abilitiesoftheuser.However,anIMSterminaldesiringtosetupaRTTcallwillofferRTTmedia,possiblyinparallel tovoicemedia.TheIMSMGWshallthenprovidetheconversionbetweenRTToverRTPandTTYmodemsignals. On the contrary, if the mobile does not request RTT support, no Interworking function is necessary. An IMS terminalconfiguredtouseRTTbutreceivinganSDPofferforvoiceonlymediawillacceptthisofferandthensend anownsubsequentSDPofferaddingRTTmedia.WhenreceivingsuchasubsequentofferforRTTmedia,theIMS MGWshallprovidetheconversionbetweenRTToverRTPandTTYmodemsignalsattheCSinterface. RTT/TTY interworking has no architecture influence on the 3G Packet Services (PS) network, only that the components must allow handling of the standardized text media stream and support RTT/TTY interworking. If RTT/TTY interworking will be used to support IMS emergency calls where terminals without a valid subscription must be supported then only PS for UTRAN and EUTRAN have been specified to allow access to meet these regulatoryrequirements. BENEFITS SeetheRTTbenefitsinsection2.3. Additionally,RTT/TTYinterworkingallowsRTTtobeusedforIMSemergencycallstoaPSTNbasedPSAP. LIMITATIONS ThistechniquerequirespacketdataservicesandIMS. ThistechniquerequiresRTT/TTYinterworkingfunction.
Page13of45

2.5

SMSTO911

DESCRIPTION Short Message Service (SMS) is a text based communications service which allows subscribers to send text messagestoeachotherviatheirmobilephones.MillionsofSMStextmessagesaresentandreceiveddaily.There isadesirewithintheusercommunity,especiallybyindividualswithdisabilities,tobeabletoalsosendandreceive SMStextmessagesfromtheemergencyservicesPSAP. In2010,4GAmericasconductedanextensiveevaluationoftheissuesandlimitationsregardingtheuseofSMSfor texting to 911. The full description of texting to 911 and the results of the evaluation where published in October2010inthe4GAmericaswhitepaperontextingto91113.

Figure4:SMSto911 BENEFITS SMSiscommonlyusedbymanywirelesssubscribers. LIMITATIONS ThisservicerequiresSMStobeactiveforthesubscriber.

13 4GAmericas,Textingto911:ExaminingtheDesignandLimitationsofSMS,October2010.
Page14of45

ThefulllistoflimitationsassociatedwithSMSto911isavailableinthe4GAmericaswhitepapermentionedin thedescriptionabove.Thefollowingaresomeofthelimitationsthatarementionedinthat4GAmericaswhite paper: SMSisaforwardandstoreservicewithnoserviceorperformanceguarantees; Nolocationinformationisprovidedbytheoriginatingnetworkormobiledevice; OriginatingnetworkunabletoroutetoPSAPsincenolocationinformationprovided; NopriorityorspecialhandlingisgiventoSMSmessages; No acknowledgments of sent, delivered or read SMS messages are provided by the originating network; Nosecurity,authentication,ornonrepudiationofanySMSmessageisprovided; SMSisnotasessionbasedprotocol.Thereisnoassociationmaintainingbytheoriginatingnetwork between the subscriber and the responding PSAP calltaker and, therefore, subsequent messages fromthesubscribermaybedeliveredtodifferentPSAPcalltakers.

2.6

VOICEEMERGENCYCALLTHENSMS

DESCRIPTION Currently Canadian telecom regulation CRTC is testing a shortterm solution for the SMS communication with a PSAP,whichmaybeapotentialinterimsolutionforvariouswirelesstechnologiesanddeploymentsintheUS. TheCanadiantelecomregulationnotedintheTelecomDecisionCRTC201022414(CanadianRadiotelevisionand TelecommunicationCommission)thatvariousformsoftextmessagingarenotviable911solutionsforthebenefit of persons with hearing or speech disabilities, i.e. the Deaf, Hard of Hearing, or Speech Impaired (DHHSI) community.SMS,IMRTT,andIPRelaydonotsupportautomaticroutingtotheappropriatePSAPortheautomatic provisionofcallerlocationinformationtothePSAP.IMandRTTdonotprovideautomaticsubscriberidentification information,suchasatelephonenumber,whichisprovidedautomaticallywithSMS.Inaddition,theCISCESWG (Canadian Radiotelevision Telecommunications Commission, Interconnection Steering Committee, Emergency ServiceWorkingGroup)indicatedinthereportTextMessagingto911(T911)Service15thatitwouldmonitor thelongtermsolutionviaNG911standardsandtechnologiestoenableuserstoaccessPSAPviamultimedia.The implementationofthesecapabilitieswilldependonthematurationlevelofIPnetworkingandNG911networks andplatforms. Thereforeintheshortterm,theCISCESWGproposestheinvestigationofapotentialworkaroundforthebenefit of persons from DHHSI community: testing a hybrid technology that a DHHSI person would dial 911 on a voice cellular phone, and their preregistered personal information would appear to a PSAP indicating their disability. Basically,awirelesssubscriberneedstopreregisterfortheDHHSIservicepossiblyviaawebsiteontheinternetor throughtheWSPs'customerserviceinfrastructure.Thispreregisteredusercanthenplacea"silent"911voice calltoindicatehisneedsfortextmessaginginadditiontotheregisteredinformation.Thevoicecallisroutedtothe 14 Canadian Radiotelevision and Telecommunication Commission (CRTC) Telecom Decision 2010224, CRTC Interconnection
SteeringCommitteeImprovingaccesstoemergencyservicesforpeoplewithhearingandspeechdisabilities,21April2010, http://www.crtc.gc.ca/eng/archive/2010/2010224.htm 15 CanadianRadiotelevisionandTelecommunicationsCommission(CRTC)InterconnectionSteeringCommittee(CISC),Report to the CRTC by the Emergency Services Working Group (ESWG), Text Messaging to 911 (T911) Service, Report Number: ESRE0051,January21,2010,http://pdf.911dispatch.com.s3.amazonaws.com/canada_txtmsg_rpt_2010.pdf Page15of45

designatedPSAPdestinationandlocationinformationisprovidedbythenetworkestablishingthevoicecall.The PSAP operator, receiving a "silent" wireless 911 call, will also receive a visual indication that the caller has registeredwiththeSMSto911serviceandrequires911serviceviaSMSmessaging.Thecaller'slocationwould use the existing cellular network methods in the same manner as a normal emergency voice call. The PSAP call taker would respond back to the caller using SMS messages based on the displayed callback information. Thus afterreceivingaPSAPSMSmessageattheemergencycaller,the911callerisenabledtotextbackandforthwith thePSAPcalltaker. ThissocalledSMST911methoddoesnotenablethe911callertoinitiatetheSMStextemergencycalldirectly toaPSAP;itrequiresPSAPstoreplybackwithSMS.TheCRTCacknowledgedthatthismethodwouldrequirePSAP to change their call handling procedures. The field trial could last 12 to 18 months. The trial will determine its effectiveness, develop and further validate a detailed technical service description and network architecture. At thetimeofwritingthispaper,nofieldtrialresultisavailableforthepublicaccess.TheCRTCproposedactivityplan ofthefieldtrialincludes: DeterminationofthemostefficientmethodforflaggingasilentT911toaPSAP; DeterminationofaSMST911registrationprocessandarchitecture; Developmentofadetailedtechnicalspecificationfortheservice; Developmentofaverificationtestplan; Validationofthetechnicalspecificationinacontrolledtelecommunicationsenvironment; PSAP determination of the technical means, costs, funding, budgeting, and timing of implementing theT911service; Costestimationtolaunchtheservicenationally,andproposingmethodstofundsame; Determinationofareasonablerolloutplanforallpartiesinvolved; IdentificationofspecificPSAPstafftrainingrequirements; Identification of specific DHHSI community education requirements, e.g. how to register, how to placeaT911call,howtoswitchfromvoicetoSMS; PreparationofatechnicaltrialconcludingreporttotheCommission.

Page16of45

ThefollowingfiguredepictstheVoiceEmergencyCallthenSMStechnique:

Figure5:VoiceEmergencyCallthenSMS BENEFITS ItisfurthernotedintheTelecomDecisionCRTC2010224thatthissilentwirelessvoicecallsolutionforapre registeredpersonhastheadvantages: LIMITATIONS ThisservicerequiresSMStobeactiveforthesubscriber. TheinterimsolutionisdesignedfordisabledcommunityandthefieldtrialtargettotheDHHSIusers;itisnotfor general public users. The precondition of this method is that SMS is supported by the enddevices, the user subscribestheSMSservicefromaserviceprovider,andregistersthemselvesasaDHHSIpersonwiththeirvoice serviceprovider. The SMS subscriber is restricted to use only the mobile device with the SIM/UICC card which has been pre registeredwiththePSAP.
Page17of45

Supportsautomaticroutingof911callstotheappropriatePSAP; Enablestheautomaticprovisionofthe911callerscontactandlocationinformationtothePSAP; Reducesimplementationtimewithusageofexistingnetworkinfrastructure.

Thesolutionsupportstextemergencyexcludingsomekindsofwirelessnetworkuser: nonsubscribersofawirelesscarrierorwithoutanUICC; roamedinusersatanetworkwithoutaroamingSMSagreementwithhishomenetwork; subscriberswithoutapreregistrationwithemergencycommunitytousethis911textbackservice maynotreceiveanSMSfromPSAPwiththesilentvoicecall,and aprepaidmobiledevicewithoutasufficientfundmaynotbeabletoreceivefromandtextbacktoa PSAP.

ThereareothertechnicallimitationsfromSMS,e.g.,delay,andpracticalmobiledeviceuserinterfacetoreceive andsendamessage.Theselimitationsaredescribedinthe4GAmericaspaperTextingto911:Examiningthe DesignandLimitationsofSMS16.ThestoreandforwardnatureofSMSisstillinherentintothismethodwiththe possibilityofdelays. In addition, this capability also requires the user to be able to SMS while on a voice call. Some mobile devices, including popular smartphones, this could be complex. For example, the receipt of an SMS message while on a voice call may only display a small icon with no other indication to the user of the received SMS message. To originateanSMSmessage,theusermayberequiredtogothroughmenustogettotheSMStextfield,allwithout droppingthevoicecall.Thesecomplicationsmaynotmakesuchasilencevoicecallsolutionuserfriendlyand practicaltoanemergencysituation.

2.7

TTYEMULATION

DESCRIPTION TTY(Teletypewriter),alsoknownasTelecommunicationDeviceforDeaf(TDD),isadevicethatallowsuserswith speechand/orhearingimpairedtocommunicateovertelephonelinesusingtextbasedmessages. TheTTYdeviceshaveakeyboardallowingtheuserswithhearingand/orspeechimpairedtotypethetextbased messagesandadisplayscreenallowingtheuserswithhearingand/orspeechimpairedtoseetheincomingtext based messages. The characters of the textbased messages from/to the TTY devices are transported over the telephone connection in the form of Baudot 45.5 baud codes, using Frequency Shift Keying (FSK) tones with 1400Hzand1800Hzfrequencytones. GSM/UMTSbased mobile devices provide the capabilities to transport these Baudot Tones over the air using Cellular Tone Modulation (CTM) techniques. The users with speech and/or hearing impaired would connect the TTY devices to GSM/UMTSbased mobile devices and then use the TTY device keyboard and display screen to performthetextbasedcommunicationovertheGSM/UMTSnetworks. The Title II of American Disability Act (ADA) of 1990 requires PSAP centers to have the equipment necessary to performthetextbasedcommunicationwiththepeoplewithspeechand/orhearingimpaired.TheTitleIVofADA 1990requiresthetelecommunicationserviceproviderstocompletecallsoriginatedfromTTYdevicesorTTYdevice connected mobile devices to PSAP centers. In the GSM/UMTSbased networks, since the TTY devices are connectedtomobiledevicesandthesignalsarecarriedovertheestablishedvoicecall,thelocationbasedrouting, 16 4GAmericas,Textingto911:ExaminingtheDesignandLimitationsofSMS,October2010.
Page18of45

location accuracy, call back requirements of E911 Phase I and Phase II requirements can be met in the same mannerasvoicecalls. ThefollowingfiguredepictsanoverviewofTTYusage:

Figure6:TTYtextbasedtelephoneconnectionusingaTTYDevice TTY Emulation is a method where the application software built on a computing device with a modem could emulatetheTTYdevicesconnectedtothetelephonelines. TheTTYEmulationapplicationsoftwarewouldprovidethenecessaryfunctionsothatthetextbasedmessagescan betransportedoverthetelephoneconnectionintheformofBaudot45.5baudcodesandwouldallowtheusersto usethekeyboardandthedisplayscreenofthecomputingdevicetotypeandreadthetextbasedmessages.The modem would ensure that the characters of the textbased messages are transported over the telephone connectionusingtheFSKtonesintheformofBaudot45.5baudtones. The project at the Rehabilitation Engineering Research Center (RERC) has developed a TTY Emulation prototype calledTTYPhonewhich,withthehelpoftheapplicationsoftware,basicallyemulatesaTTYdeviceconnectedtoa mobilephone.TheTTYPhoneapplicationsoftwarewhenloadedonmobilesmartphoneswouldenablethemobile smart phones to emulate the mobile TTY phones which in other words would allow users with hearing and/or speech impaired to make TTYtext based phone calls using smart phones without the need to carry around the bulkyTTYdevices.ThemobileTTYphoneswiththeinherentcapabilityofCTMtonegeneration/receptionwould emulateatruescenarioofTTYdeviceconnectedtoGSM/UMTSsmartphones.Userswithspeechand/orhearing impaired will be able to make TTY textbased emergency calls to PSAP centers using the mobile TTY phones. By allowingtheusersofmobileTTYphonestomake911callswithouttheneedtocarrythebulkyTTYdevices,the mobileserviceproviderscanfulfillthespiritoftherequirementsofTitleIVofADA1990inamorepracticalway.

Page19of45

ThefollowingfiguredepictsanoverviewofTTYEmulationusage:

Figure7:TTYtextbasedtelephoneconnectionusingtheTTYEmulationSoftwareonSmartMobileDevices ThefurtherdetailsabouttheRERCcanbefoundat: http://www.wirelessrerc.org/publications/wirelessemergencycommunications2009conference proceedings/sessions/applicationsthealertbeyondtechnicaltrack/deaf911 TTY phone performance must comply with 3GPP TS 26.23117 which defines the minimum performance requirementsforCTM. BENEFITS ATTYdeviceisbulkywithitskeyboardanddisplayscreenandhence,noteasytocarryaroundwhereasasmart phone with the built in TTY emulation software is basically a smart phone from hardware perspective. TTY EmulationrequiresnochangestotheprotocolandstandardsusedtomaketextbasedcallstothePSAP.ThePSAPs that support the Title II requirements of ADA 1990 require no changes to interwork with TTY Emulation. In summary,TTYEmulationcanbeusedwiththeexistingwirelessinfrastructureandwiththeexistingPSAP. TTY Emulation supports bidirectional or unidirectional text transmissions thus allowing users with speech and hearingimpairedoruserswithjustspeechimpairedortheuserswithjustthehearingimpairedtomakecallsto thePSAP. TTYEmulationcanbeusedtoemulateVoiceCarryOver(VCO)andHearingCarryOver(HCO)requirementsaswell. LIMITATIONS NocommerciallyavailablemobiledevicessupportTTYEmulationsoftwarecapabilities. SupportoftheTTYEmulationsoftwareonthemobiledevicesrequiresdevelopmentonthemobiledevices.The applicationAPIsneedtodeveloptoallowtheTTYEmulationsoftwaretoprovideCTMoverthevoicechanneland mustbetestedtocomplywiththe3GPPTS26.23118.
17

3GPPTS26.231:CellularTextTelephoneModem;MinimumPerformanceRequirements.
Page20of45

2.8

NATIONALSMSRELAYCENTER

DESCRIPTION SMSispopularamongthedeafandhardofhearingduetotheeaseofcommunicatingandthepossibilityofbeing alertedtoincomingmessagesimmediately,asforanincomingphonecall,bytactilemeans(e.g.phonevibration). EmergencySMSmessagesaresenttoacentralizednationalSMSrelaycenterthatservesasameansofprovidinga voiceconnectiontoanappropriatePSAP.Theservicewouldnormallybeusedbyhearingorspeechimpairedusers asasubstituteforaninabilitytotalkdirectlywithaPSAPoperator.Thefigurebelowprovidesanillustrationofthe service in the case that a separate PSAP is contacted either via a human operator or an automated textvoice conversionfacilityattherelaycenter.

MS

MSC/SGSN

Serving PLMN

MAP (Stage 1)

Home PLMN

National SMS Relay Center Home SMSC PSAP SMPP/EMI (Stage 2) SMS T-V 911 Voice Call (Stage 3) SMS Operator

T-V: optional automated text-voice translation as an alternative to manual operator translation

Figure8:SMSCommunicationwithaPSAPviaaNationalSMSRelayCenter EachSMSmessagecancontainupto140octetsofdataencodingupto1607bitcharacters.ConcatenatedSMS, whensupported,allowsmultipleseparateSMSmessagestobecombinedtoincreaseeffectivemessagesize.SMS messages are normally transferred from an originating Mobile Station (MS) to a terminating MS via a Short Message Service Center (SMSC) belonging to or associated with the home network of the originating MS. The originatingMSprovidestheE.164addressoftheSMSCtotheservingMSCtoenableroutingofanSMSmessageto theSMSC.AnSMSGMSCassociatedwiththeSMSCthenroutesareceivedSMSmessagetotheterminatingMSby
18

3GPPTS26.231:CellularTextTelephoneModem;MinimumPerformanceRequirements.
Page21of45

interrogating the HLR for the terminating MS to determine the address of its serving MSC or SGSN. This set of procedures(definedin3GPPTS23.040)canintroducedelaye.g.duetocongestionintheSMSCandtemporary unavailabilityoftheterminatingMS. SOLUTIONA RoutingSMSmessagesthroughtheSMSCofanoriginatingMSwouldbeonepossiblesolutionandwouldenable theserviceforbothlegacyandnewMS.However,thehomeSMSCwouldneedtosupportSMSmessageroutingto thenationalSMSrelaycenterwhichmostlikelyrulesoutsupportforinternationalroamers.Moreseriouswould betheadditionaldelayinSMSmessagetransferwhichcouldbeparticularlysignificantifaconversationwillensue betweenaPSAPoperatoranduser. SOLUTIONB An alternative solution to reduce delay would be to equip a national SMS relay center with its own SMSC. This would require an originating MS to recognize any SMS message that is intended for emergency use (e.g. by inclusionofa"911"destinationaddressfortheSMSmessage)andtosubstitutetheE.164addressofanational SMSrelaycenterforthenormalE.164addressofthehomeSMSCwhenthemessageispassedtotheservingMSC orSGSN.ThisnationalE.164addresswouldneedtobeconfiguredintheMS.TheseadditionalMSfunctionsimply the need for new types of MS and also restrict the capability most likely to North American as opposed to internationalsubscribers. As outlined above, solution (A) is applicable to legacy MS but can add delay due to routing through the home PLMN. Solution (B) requires new MS but can reduce delay by cutting out transfer through the home PLMN and homeSMSC.AviableinterimsolutionneedstosupportexistingMSsandhenceproposesolution(A)here.Itisthe oneillustratedinFigure8andwouldoperateasfollows.Firstauserwouldcomposeatextmessagerelatedtoan emergencysituationandsendthistosuitablenewnationalemergencyshortcodeaddress.Whilesuchanaddress could simply be "911", it might be better to define a different standard 5 digit short code (e.g. "91163" representingthekeysequence"911ME")forconsistencywithothershortcodesandtoavoidmisleadingusersinto believingthisprovidesadirectlinktoalocalPSAP).TheservingMSCwouldroutetheSMSmessageusingthe3GPP Mobile Application Part (MAP) protocol (defined in 3GPP TS 29.00219) to the home SMSC indicated by the MS (stage1inFigure8).TheSMSmessagewouldcarryboththetextmessageenteredbytheuserandthenational emergency short code (e.g. "91163"). The MAP message transporting this SMS message would carry the home SMSCE.164addressandthetelephonenumber(MSISDN)oftheMS.ThehomeSMSCwouldrecognizethenational emergency short code address and forward the SMS message to the National SMS Relay Center (stage 2 in Figure8).WhileMAPcouldbeusedforthis,itwouldbebettertoemployanSMStransferprotocolthatcanuse TCP/IPfortransportsuchasShortMessagePeertoPeer(SMPP)orExternalMachineInterfaceUniversalComputer Protocol(EMIUCP).TheSMSmessagerelayedinthiscasewouldcontainjustthetextmessageenteredbytheuser and the SMPP or EMIUCP protocol would provide the MSISDN of the originating MS. The home SMSC address wouldalreadybeknowntotheNationalSMSRelayCenterfromtheSMPPbindingorEMIUCPsessionpreviously established with the SMSC to initiate SMS transfer. The MSISDN of the originating user and the home SMSC addresswouldneedtoberetainedbytheNationalSMSRelayCenterinordertocorrectlyrouteanySMSreplies backtotheuserthereplybeingroutedfirsttothehomeSMSCwhichcanemploynormal3GPPterminatingSMS procedurestoroutebacktotheMS

19 3GPPTS29.002:MobileApplicationPart(MAP)specification.
Page22of45

The above procedures avoid impacts to both the MS and the existing GSM and UMTS infrastructure although requiresomeadministrativeupdateofSMSCstorecognizethenationalemergencyshortcodeandcorrectlyroute toaNationalSMSRelayCenter.Alternatively,ifanoperatorreliesonanSMSaggregatortointerfacetheirSMSCto other networks, the SMSC can forward the SMS message received from the MS (in stage 1 in Figure 8) to an aggregatorforonwardtransfertotheNationalSMSRelayCenter.Inthiscase,administrativeimpactstotheSMSC canbeavoided. At the National SMS relay center, incoming SMS messages could be screened by human operators who could eitherdirectlyactasaPSAPororiginateavoicecalltoaPSAPandrelay(byvoice)thetextprovidedinanincoming SMS message. Very likely, twoway communication would need to ensue between the PSAP operator and originating user so the National SMS relaycenter operator would need to return SMS messages to the user. To ensurethatallSMSmessagesassociatedwithaparticularMSareseenbythesameoperator,theNationalSMS relaycenterwouldneedtoemployfilteringbasedontheMSISDNoftheoriginatingMS. During emergency calling situations SMS Relay providers encounter difficulties routing 911 calls to the appropriatePSAP.WhenaSMSRelayuserdialsSMSrelayserviceforanemergency,thecallisdeliveredtothe SMSRelayandtheSMSRelayuserindicatesthattheyhaveanemergency.TheSMSRelayinterpreterobtainsthe userslocationfromeithertheirpreregisteredlocationorfromtheuserthemselves.However,iftheSMSRelay interpreterdials911foremergencyservices,thatcallwouldbeconnectedtothePSAPthatservicestheSMSRelay providers location and not the PSAP that services the users current location. Additionally, the information displayedatthePSAPwouldbethatoftheSMSRelayprovider,nottheSMSuser. InorderfortheSMSRelayprovidertocontactemergencyservicesinthelocationoftheSMSRelayuser,theSMS RelayproviderhastodeterminealternativetelephonenumbersforthePSAPwhichservestheSMSRelayusers current location. These alternative telephone numbers are either PSAP administrative telephone numbers or other non911 emergency telephone numbers. The SMS Relay provider could determine these alternative telephonenumberseitherfromtheirowninternaldatabasesorfromothernationalcallroutingservices.Oncethe alternativetelephonenumberforthePSAPhasbeendetermined,theSMSRelayinterpretercancallthePSAPand indicatethattheyhaveanemergencycallonbehalfofanindividualwithdisabilities.TheSMSRelayusercanthen communicate with the PSAP dispatcher via the SMS Relay interpreter, in order to receive the appropriate emergencyservices. As a possible workaround, if the location of the MS user could not be subsequently determined by SMS communicationwiththeuser,theusermightbeinstructed(viaSMS)tooriginateanE911voicecall.IftheMS was suitably prerecorded with an appropriate message, it might play out a special announcement to the PSAP operatorwhomightthenseparatelycontacttheNationalSMSrelayCenterandprovidetheaccuratelocationof theMSuserasobtainedusingE911phase2capabilities. AnalternativetoemployinghumanoperatorswouldbetoconvertSMStextmessagecontentdirectlyintospeech formessagesoriginatedbyanMSuserandperformthereverseforvoicecommunicationfromaPSAPoperator. ThiswouldrequiresomespecialindicationinthecalllegtothePSAP(e.g.ashortannouncementatthestartofthe call)andwouldrequirethePSAPoperatortocommunicateinshortspeechsegments. The capability so far described can be employed for all users. To restrict the service to hearing and speech impairedusersonly,prospectiveuserscouldberequiredtoregistertheirMSISDNaddresswiththeNationalSMS Relay Center. This would allow incoming SMS messages to be filtered. Those from unregistered users would be discardedalthoughadefaultSMSresponsemightbereturnedtotheuseradvisingtheusertoplacea911voice

Page23of45

call.However,messagesfromregistereduserswouldbeforwardedtothePSAPeitherattheNationalSMSRelay CenterorviaaVoicecalltoaremotePSAPasshowninFigure8. BENEFITS SolutionAwillenablehearingandspeechimpaireduserstousenormalSMSforemergencyaccess. Existinglegacyphonescanbesupportedandexistingnetworkinfrastructurewillrequireonlyminoradministrative updateatanSMSC. LIMITATIONS ThevoicecallfromtheSMSRelayServicetothePSAPisnota911calltothePSAP.Rather,thesecallsareplaced toadministrativeorotherauxiliaryphonenumbersassociatedwiththePSAPandtherecanbedelaysofseveral minutesbeforethePSAPanswersthesecalls ThecallermusthaveSMSactiveandknowtheSMSshortcodefortheNationalSMSRelayCenter.Theservicewill mostlikelyberestrictedtoNorthAmericansubscribersduetotheneedforahomeSMSCtorecognizeanational emergencyshortcodeandestablishasessionorbindingwiththeNationalSMSRelayCenterfortransferringSMS messages. TheremaybedelaysincommunicatingwiththefinalPSAPoperatore.g.duetodelaysinroutingtoandfromthe home SMSC and delays internal to the SMSC. There may be additional delays if there are insufficient human operatorsortextvoicetranslationfacilitiesattheNationalSMSRelayCenter. It will not be possible to obtain an accurate location for the calling user by automatic means. If the caller loses consciousness,isforcedtoabandonthecall,orisunabletocommunicate,therelayoperatordoesnotknowthat anemergencyisoccurring(andmaynotknowthecaller'slocation). TheSMSRelayServiceneedsasuitablemechanismfordeterminingtheappropriatePSAPforthecallerandrouting acalltoit. TheSMSisnotrecognizedasemergencyrelatedbythehandsetornetwork,thusdoesnothaveprioritytreatment andthedevicedoesnotenteremergencymode. Theservicemaybesubjecttomisusebothaccidentalanddeliberateunlessusersarerequiredtoregisterwith theNationalSMSRelayCenter.Forexample,itcouldbesubjecttofrivolousmessages(spam)aswellasadenialof serviceattack.Inaddition,ifthereisahighuptakeforvalidusage,facilitiesataNationalSMSRelayCentermay becomeoverloadedandunabletoprovideadequateemergencyservice. Theservicewillnotbepossibleinanefficientformwithoutthecreationandprobablysomeminimalstaffingofa NationalSMSRelayCenter. The service may later become redundant when equivalent and better multimedia services become available as partofNG911deployment.

Page24of45

2.9

VIDEORELAYSERVICE

DESCRIPTION With the development of highquality video equipment, the availability of high speed Internet, and video relay servicesauthorizedbytheFCC,VideoRelayServices(VRS)forthedeafhaveundergonerapidgrowth.Usingsuch video equipment in the present day, the deaf, hardofhearing and speechimpaired can communicate between themselvesandwithhearingindividualsusingsignlanguage.Telecommunicationequipmentcanbeusedtotalk toothersviaasignlanguageinterpreter,whousesaconventionaltelephoneatthesametimetocommunicate with the deaf person's party. Video equipment is also used to do onsite sign language translation via Video RemoteInterpreting(VRI).Thedevelopmentof3Gmobilephonetechnologywithvideocallingcapabilitieshave givendeafandspeechimpairedusersagreaterabilitytocommunicatewiththesameeaseasothers. With video interpreting, sign language interpreters work remotely with live video and audio feeds, so that the interpreter can see the deaf or mute party, and converse with the hearing party, and vice versa. Much like telephoneinterpreting,videointerpretingcanbeusedforsituationsinwhichnoonsiteinterpretersareavailable. However,videointerpretingcannotbeusedforsituationsinwhichallpartiesarespeakingviatelephonealone.VRI andVRSinterpretationrequiresallpartiestohavethenecessaryequipment.Someadvancedequipmentenables interpreterstocontrolthevideocameraremotely,inordertozoominandoutortopointthecameratowardthe partythatissigning. IntheU.S.,theFCCregulatesthestandardsthatVRScompaniesandtheiremployeesmustfollowinhandlingcalls. TheseregulationsensurethatVRScallsarehandledappropriatelyandethically.TheFCCissuedrulingsinclude: The time it takes an interpreter to answer an incoming VRS call. As of July 1, 2006, VRS providers mustanswer80%ofcallswithintwoandahalfminutes.StartingonJanuary1,2007VRSproviders mustanswer80%ofcallswithintwominutes; asofJanuary1,2006,allVRSprovidersarerequiredtoprovideservice24hoursaday,sevendaysa week; reimbursement of VRS Video Mail: if a Hearing person calls a sign language user, but there is no answer, the VI signs a message and delivers it to the sign language user's email, similar to an answeringmachine. VRSprovidersarenotpermittedtocallbackwhenacustomerhangsupbeforeaVRScallisplaced.

TypicalcallingprocedureforVRSincludesthefollowing: An individual who communicates by American Sign Language uses video equipment to connect via broadbandInternettoaVideoRelayService; thecallerisroutedtoasignlanguageinterpreter,knownasaVideoInterpreter(VI).TheVIisinfront ofacameraorvideophone; thevideousergivestheVIavoicenumbertodial,aswellasanyspecialdialinginstructions; the VI places the call and interprets as a neutral, nonparticipating third party. Anything that the audiousersaysissignedtothevideouser,andanythingsignedbythevideouserisspokentothe audiouser; oncethecallisover,thecallercanmakeanothercallorhangupwiththeinterpreter; thecompanythatprovidestheinterpreterserviceswillthensubmitbillingstotheFCC.
Page25of45

VRScanbeusedbyanyonetocontactaDHHSIperson.Toinitiateacall,ahearingpersoncallsaVRSandconnects toavideointerpreterwhothencontactsthevideouser.SomeVRSservicesalsooffer: Voice Carry Over (VCO): The video user may use his/her own voice instead of the interpreter speaking; Hearing Carry Over (HCO): the video user may listen for him/herself instead of relying on the interpreter; LanguagePreference:ThevideouserrequeststhattheinterpreteruseAmericanSignLanguage; theabilitytoconnecttoasignlanguageinterpreterwhocaninterpretintoanotherlanguage,suchas Spanish.

SomerelayservicesallowcallerstoregisterandobtainastandardDirectoryNumber(DN),forexample,a10digit NorthAmericanNumberingPlan(NANP)numberintheU.S.Whenavailable,anddependingontheservice,the user'sDNmaybeprovidedtotherelayoperatorandmaybeprovidedtothePSAP,allowingforcallbacks. During emergency calling situations VRS providers encounter difficulties routing 911 calls to the appropriate PSAP.WhenaVRSuserdialsvideorelayserviceforanemergency,thecallisdeliveredtotheVRSandtheVRS userindicatesthattheyhaveanemergency.TheVRSinterpreterobtainstheuserslocationfromeithertheirpre registeredlocationorfromtheuserthemselves.However,iftheVRSinterpreterdials911foremergencyservices, thatcallwouldbeconnectedtothePSAPthatservicestheVRSproviderslocationandnotthePSAPthatservices theuserscurrentlocation.Additionally,theinformationdisplayedatthePSAPwouldbethatoftheVRSprovider, nottheVRSuser. InorderfortheVRSprovidertocontactemergencyservicesinthelocationoftheVRSuser,theVRSproviderhasto determine alternative telephone numbers for the PSAP which serves the VRS users current location. These alternative telephone numbers are either PSAP administrative telephone numbers or other non911 emergency telephone numbers. The VRS provider could determine these alternative telephone numbers either from their owninternaldatabasesorfromothernationalcallroutingservices.Oncethealternativetelephonenumberfor thePSAPhasbeendetermined,theVRSinterpretercancallthePSAPandindicatethattheyhaveanemergency callonbehalfofanindividualwithdisabilities.TheVRSusercanthencommunicatewiththePSAPdispatchervia theVRSinterpreter,inordertoreceivetheappropriateemergencyservices.

Page26of45

 Figure9:VideoRelayService BENEFITS This service enables hearing and speech impaired users to use and existing technology to interact. This service requiresminimalchangestostandardsandcanbereadilydeployedandused. Thehearingandspeechimpairedusersarealreadyfamiliarwithusingthisservicetocommunicate. LIMITATIONS ThevoicecallfromtheVideoRelayServicetothePSAPisnotan911calltothePSAP.Rather,thesecallsare placed toadministrative or other auxiliaryphone numbers associatedwith the PSAP and there can be delays of severalminutesbeforethePSAPanswersthesecalls. Thisservicerequiresaphonecapableofvideotelephony(e.g.,frontfacingcamera,appropriatevideoapplications, handset positioning stand) that iscompatible with theVideo RelayService video application.Although, many of the recent smartphones have this capability, it is not universally available in all devices. It also requires a data packet service with a minimum bit rate to work properly; as such, it is not suitable for legacy (2G) access technologies. ThecallermustbeabletocontacttheVideoRelayService,orhaveaclientpreconfiguredwiththisinformation.If theVideoRelayServiceisnotnationwide,thendeterminingthisbecomessignificantlymoredifficult.

Page27of45

WhenpriorregistrationandcalltimeauthenticationareusedbytheVRS,thebroadusefulnessoftherelayservice is limited by requiring advance action by all users who need the service. Without prior registration, protection againstattacksismoredifficult(buttotheextentthatauthenticationandregistrationaretrivialandeasilyminted, theprotectionaffordedislimited).Calltimeauthenticationoftenmeansthatcredentialsneedtobestoredon thedevice(sinceenteringthemduringanemergencymaybeimpracticable).Thiscreatesadditionalchallengesin caseswhereadeviceisreplacedorborrowed. It will not be possible to obtain an accurate location for the calling user by automatic means. If the caller loses consciousness,isforcedtoabandonthecall,orisunabletocommunicate,therelayoperatordoesnotknowthat anemergencyisoccurring(andmaynotknowthecaller'slocation). The Video Relay Service needs a suitable mechanism for determining the appropriate PSAP for the caller and routingacalltoit. The video session is not recognized as an emergency session by the handset or network, thus does not have prioritytreatmentandthedevicedoesnotenteremergencymode. ForthoseservicesthatdonotassignastandardDN,callbackbythePSAPisdifficultandmaynotbepossible,since no calling number information is sent. Even thoughthe Video RelayService does have access tothe source IP address,thisisoflittlepracticaluseindeterminingthecaller. TheinterfacesandinteractionsbetweentheindividualwithdisabilitiesandtheVideoRelayServiceareproprietary innatureandaredependentontheimplementationoftheVideoRelayService.

2.10 IPBASEDRELAYSERVICE
DESCRIPTION IP based relay service allows various IP based texting message services to interoperate. Various IPbased text messaging service protocols can be used between the caller and the IP Relay Service. These may include web pages or web services (using HTTP or HTTPS), open standards instant messaging (XMPP (Jabber), SIP/SIMPLE), commercialinstantmessaging(GoogleTalk/GoogleChat,iChat,AIM,Yahoo,MSN),proprietaryprotocols(Yahoo IM,AIM,MSM),etc.Therelayservicemightbelimitedtoonemodeorprotocol,orsupportmultipleprotocols,for example,oneormoreformsofIMplusawebbasedservice. SomerelayservicesallowcallerstoregisterandobtainastandardDirectoryNumber(DN),forexample,a10digit NorthAmericanNumberingPlan(NANP)numberintheU.S.Whenavailable,anddependingontheservice,the user'sDNmaybeprovidedtotherelayoperatorandmaybeprovidedtothePSAP,allowingforcallbacks.Some servicesallowtheusertoregisteralocation,whichisthenprovidedtotherelayserviceorthePSAP.Suchservices generallypermituserstoupdatetheirregisteredlocationasneeded.

Page28of45

 Figure10:IPBasedRelayService DuringemergencycallingsituationsIPRelayprovidersencounterdifficultiesrouting911callstotheappropriate PSAP.WhenanIPRelayuserdialsanIPrelayserviceforanemergency,thecallisdeliveredtotheIPRelayService andtheIPRelayServiceuserindicatesthattheyhaveanemergency.TheIPRelayServiceinterpreterobtainsthe userslocationfromeithertheirpreregisteredlocationorfromtheuserthemselves.However,iftheIPRelay Serviceinterpreterdials911foremergencyservices,thatcallwouldbeconnectedtothePSAPthatservicestheIP RelayServiceproviderslocationandnotthePSAPthatservicestheuserscurrentlocation.Additionally,the informationdisplayedatthePSAPwouldbethatoftheIPRelayServiceprovider,nottheIPRelayServiceuser. InorderfortheIPRelayServiceprovidertocontactemergencyservicesinthelocationoftheIPRelayServiceuser, theIPRelayServiceproviderhastodeterminealternativetelephonenumbersforthePSAPwhichservestheIP RelayServiceuserscurrentlocation.ThesealternativetelephonenumbersareeitherPSAPadministrative telephonenumbersorothernon911emergencytelephonenumbers.TheIPRelayServiceprovidercould determinethesealternativetelephonenumberseitherfromtheirowninternaldatabasesorfromothernational callroutingservices.OncethealternativetelephonenumberforthePSAPhasbeendetermined,theIPRelay ServiceinterpretercancallthePSAPandindicatethattheyhaveanemergencycallonbehalfofanindividualwith disabilities.TheIPRelayServiceusercanthencommunicatewiththePSAPdispatcherviatheIPRelayService interpreter,inordertoreceivetheappropriateemergencyservices.

Page29of45

 BENEFITS Fundamentally,allthatisrequiredonthehandsetisIP(andTCPformanyprotocols)andatextmessagingclient which supports one of the protocols used by the relay service. All that is required in the network is IP. No additionalrequirementsareplacedonthePSAP.Hence,thisapproachintheorycanbeprovidedtothebroadest possiblesetofusers. Multiple IM protocols can be supported within one client. (For example, one popular opensource20 client available for various platforms today supports the following IM protocols: AIM, MobileMe/.Mac, ICQ, XMPP/Jabber, Google Talk, Facebook Chat, LiveJournal, .NET Messenger Service/MSN/Windows Live, Yahoo! Messenger, MySpaceIM, GaduGadu, Novell GroupWise, Lotus Sametime, Tencent QQ, MeBeam with a plugin, Tlen with a plugin, Xfire with the XBlaze plugin, Skype with a plugin, IRC, Twitter, and NateOn with a plugin; another21supportsAIM,Bonjour,GaduGadu,GoogleTalk,Groupwise,ICQ,IRC,MSN,MXit,MySpaceIM,QQ,SILC, SIP/SIMPLE, Sametime, XMPP, Yahoo!, and Zephyr). Thus, it is not conceptually difficult to support multiple IM protocols within the IP Relay Service or the client, although of course there are fewer resource limitations and easierupgradesontheserverside. Aservicemaybeopentoanonymoususers(noauthenticationatcalltime),ormayrequireadvanceregistration withcalltimeauthentication.Theregistrationandauthenticationmaybeessentiallytrivial(suchasrequiringonly anemailaccount),ormaybetiedtosomeexternalaccount. LIMITATIONS ThevoicecallfromtheIPRelayServicetothePSAPisnotan911calltothePSAP.Rather,thesecallsareplaced toadministrativeorotherauxiliaryphonenumbersassociatedwiththePSAPandtherecanbedelaysofseveral minutesbeforethePSAPanswersthesecalls. ThehandsetmustsupportatleastoneprotocolincommonwiththeIPRelayServiceandhavepacketdataservices active.Withsomeservices,neitherlocationnorcallingnumberinformationissent(althoughsomeprotocolshave provisionsfortransmittinglocationinformation,eitherdirectlyfromtheoriginatingendpointtotherelay'send point,orfromtheoriginatingendpointtoalocationorpresenceserverwhichinturnmaymakeitavailabletothe relay'sendpoint).Inserviceswithoutautomaticlocationinformation,therelayoperatormustobtainalocationby askingthecaller,whichdelaysroutingthecalltotheappropriatePSAP.Evenforthoseservicesthatdoprovide location, because the location may be out of date, the relay operator will usually ask the caller to confirm it. Generally,therelayoperatorverifiesthatthecallerrequiresemergencyservicesandasksforalocationpriorto determiningthePSAPandthenplacingthecall.(Thisissimilartotheoperationofinvehicletelematicsservices suchasOnStar,exceptthatOnStarhasthelocationautomatically.) ThecallermustbeabletocontacttheIPRelayService,orhaveaclientpreconfiguredwiththisinformation.Ifthe IPRelayServiceisnotnationwide,thendeterminingthisbecomessignificantlymoredifficult.

20 SeeAdium:http://adium.im/ 21 SeePidgin:http://www.pidgin.im/
Page30of45

It will not be possible to obtain an accurate location for the calling user by automatic means. If the caller loses consciousness,isforcedtoabandonthecall,orisunabletocommunicate,therelayoperatordoesnotknowthat anemergencyisoccurring(andmaynotknowthecaller'slocation). Thetextcommunicationsessionisnotrecognizedasanemergencysessionbythehandsetornetwork,thusdoes nothaveprioritytreatmentandthedevicedoesnotenteremergencymode. ForthoseservicesthatdonotassignastandardDN,callbackbythePSAPisdifficultandmaynotbepossible,since nocallingnumberinformationissent.EventhoughtheIPRelayServicedoeshaveaccesstothesourceIPaddress, thisisoflittlepracticaluseindeterminingthecaller. The caller must know the domain name of the IP Relay Service, or have a client preconfigured with this information.IftheIPRelayServiceisnotnationwide,thendeterminingthisbecomessignificantlymoredifficult. Whenpriorregistrationandcalltimeauthenticationareused,thebroadusefulnessoftherelayserviceislimited by requiring advance action by all users who need the service. Without prior registration, protection against attacks is more difficult (but to the extent that authentication and registration are trivial and easily minted, the protectionaffordedislimited).Calltimeauthenticationoftenmeansthatcredentialsneedtobestoredonthe device (since entering them during an emergency may be impracticable). This creates additional challenges in caseswhereamobiledeviceisreplacedorborrowed. TheIPRelayServiceneedsasuitablemechanismfordeterminingtheappropriatePSAPforthecallerandroutinga calltoit.Suchsolutionsdoexistandareinuse(e.g.,OnStar),buttheneedforthisisalimitation.

Page31of45

3.

ANALSYSOFPOTENTIALTECHNIQUES

Thissectionofthewhitepaperprovidestheanalysisofthepotentialtechniquesincludingacolorcodedsideby sidecomparison.Section3.1providesthedefinitionoftheanalysiscriteriaandtheassociatedcolorcodingthat willbeusedinthesidebysidecomparison.Section3.2providesthecolorcodedsidebysidecomparisontable includinganyappropriatenoteswhichareprovidedimmediatelyfollowingthetable.

3.1

DEFINITIONOFANALYSISCRITERIA

Thefollowingtabledefinestheanalysiscriteriaandassociatedcolorcodingthatwillbeutilizedfortheevaluation ofthevariouspotentialtechniques: Table1:DefinitionofAnalysisCriteria DefinitionofAnalysisColorCoding AnalysisCriteria

Realtime communication

Definition
Isthemultimediacommunications betweentheenduserand emergencyservicesconductedin realtimeordoesqueuing,store andforward,orothersuch techniquesoccur? Doesthepotentialtechnique supportenduserlocation determinationordoestheend userhavetoprovidetheirlocation duringthemultimedia communicationswithemergency services? Howisreliableisthepotential technique?

Red
Communications withextensive delaysdueto queuing,storeand forward,orother delaysoccur Enduserhasto providetheir location

Yellow
Communications withappreciable delays

Green
Communications withnonoticeable delay

Enduserlocation determination

N/A

Potentialtechnique candetermineend userlocation

Reliability

Littletono reliability

Highreliabilitybut couldfail

Supportstelco gradeoffive9s reliability (99.999%) Extensivesecurity capabilities

Security

Arethecommunicationsbetween enduserandemergencyservices secureandprotectedagainstfalse messages,alteredmessages,man inthemiddleattacks,etc?

Nosecurity capabilities

Limitedsecurity capabilities

Page32of45

DefinitionofAnalysisColorCoding AnalysisCriteria
Maintaining association betweenenduser andPSAPcalltaker whenenduseris mobile

Definition
Doesthetechniquemaintainthe associationofmultimedia emergencyservicesbetweenthe enduserandthePSAPcalltaker whentheenduserismobile?

Red
Communications maynotstaywith thesamecalltaker. N/A

Yellow

Green
Communications stayswiththesame calltaker.

Preregistration withemergency services required?

Doestheuserneedtobeknownin advancetoemergencyservices perapreregistrationfunction?

Noserviceis enabledtotheend userwithoutapre registration

N/A

Nopreregistration isrequired.No actionrequiredby wirelessoperator oremergency services

ImpacttoPSAP systems

Whatistheimpacttotheexisting PSAPsystemsandtheassociated calltakers?

Newcapabilities requiredinPSAP systems.

Capabilitiesexisting NoimpacttoPSAP incurrentPSAP systems systemsbut trainingofPSAPcall takersmaybe required Supportedby existingnetwork componentsand interfaces.Network engineeringmaybe neededfor additionaltraffic load. Newapplicationon smartphone required Noimpactto wirelessoperator networks

Impacttowireless operatorsnetworks

Whatistheimpacttotheexisting wirelessoperatornetworks?

Newnetwork components and/ornew interfacesrequired

Impacttoenduser

Arenewhandsetsand/or applicationsrequired?

Newhandsets required

Existinghandset supportstechnique

Migrationimpact toenduserfor transitiontolong term

Whatarethemigrationimpacts fromtheshorttermtechniqueto thelongtermsolution?

Enduserwillhave touseadifferent techniqueforthe longterm multimedia emergency communications

Endusercoulduse Longtermsolution thesametechnique willbethesameto theenduser butanewversion oftheapplication mayberequireand theremaybe changestotheuser interface

Page33of45

3.2

SIDEBYSIDETECHNIQUECOMPARISON

The following table provides a color coded sidebyside summary comparison of the potential techniques. The definition of the Analysis Criteria column and the explanation of the color coding are provided in Table 1: DefinitionofAnalysisCriteriainSection3.1.Thedescriptionofthepotentialtechniquesisprovidedinsection2. Any notes referenced within the color coded sidebyside comparison table are provided immediately following thecomparisontable.

Page34of45

 Table2:SidebySideTechniqueComparison Voice Emergency CallthenSMS National SMSRelay Center Video Relay Service IPBased Relay Services

AnalysisCriteria
Realtime communication Enduserlocation determination Reliability Security Maintainingassociation betweenenduserand PSAPcalltakerwhen enduserismobile Preregistrationwith emergencyservices required? ImpacttoPSAPsystems Impacttowireless operatorsnetworks Impacttoenduser Migrationimpacttoend userfortransitionto longterm

Instant Messaging
Note 1

VideoASL

RTTEnd toEnd

RTTwith TTY

SMSto 911

TTY Emulation

Note 2

Note 2

Note 2

Note 3

Note 3

Note 3 Note 4 Note 4

Note 3

Note 3

Note 5

Note 5

Note 5

Note 5 Note 7 Note 7

Note 6 Note 7

Page35of45

Note1: SomeIMimplementationmayusestoreandforwardcapabilities. Note2: MaintenanceofassociationbetweenenduserandPSAPcalltakerwouldbeprovidedbytherelayservice. Note3: UpdatestoexistingPSAPsystemsrequired. Note4: IMSisrequiredinthewirelessoperatornetwork Note5: Subscriber would need to download application if current mobile device supports downloaded application.Ifnot,subscriberwouldneedtogetanewmobiledevice. Note6: Subscriberwouldneedtogetanewmobiledevice. Note7: Long term solution will support text messaging but the text messaging capability will be supported by othertechniquesinsteadofSMS.

4.

CONCLUSIONS

Basedupontheanalysiscontainedwithinthiswhitepaper,thefollowingconclusionscanbedrawnregardingan interimshorttermsolution: 1. Allofthesepotentialtechniqueshaveissuesandlimitationswhichimpactstheuseofthetechnique asaninterimshorttermsolution.Subscriberswillneedtobeeducatedthatanyinterimsolutionwill havelimitationsandrestrictions. RelaybasedservicessuchasVideoRelayServiceandIPBasedRelayServicearepotentialtechniques foraninterimsolution.Thesetechniqueshaveminimalimpacttoexistingmobiledevices,towireless networkinfrastructure,andtoemergencyservicesnetworks. SMSbasedtechniquessuchasNationalSMSRelayCenterandtheVoiceEmergencyCallthenSMSare potentialtechniquesforaninterimsolution,ifanSMSbasedsolutionisrequired.TheseSMSbased techniqueshavethesameinherentissuesofSMSasdescribedinthe4GAmericaswhitepaperon textingto91122whichwaspublishedinOctober2010.Thesetechniqueshavelittleornoimpactto the wireless networks and limited impact to the emergency service networks. However, not all currently deployed mobile devices will support the Voice Emergency Call then SMS technique. The VoiceEmergencyCallthenSMStechniqueiscurrentlyundertrialinCanada. SMSto911continuestohaveseriousissuesandlimitationsasdescribedinthe4GAmericaswhite paper on texting to 91122. Implementation of SMS to 911 would have significant impacts to wireless network infrastructure and to the emergency services networks and, therefore, is not consideredtobeasuitableinterimsolution.

2.

3.

4.

Interimsolutionsbaseduponrealtimetext(RTT)arenotfeasibleasinterimsolutionssincethe3GPP standards for the support of RTT in wireless networks requires the IMS subsystem. The IMS subsystemisnotwidelydeployed,isnotlikelytobedeployedon3Gsystems,willnotbedeployedon 2Gsystems,andisnotsupportedbythemobiledevicescurrentlybeingusedbythesubscribers. 22 4GAmericas,Textingto911:ExaminingtheDesignandLimitationsofSMS,October2010.
Page36of45

5.

6.

InstantMessaging(IM)isnotconsideredtobeaviabletechniqueforaninterimsolution.Generally, the IM services available to subscribers today are the services offered by the major IM service providers such as AOL, Yahoo, Google, and Microsoft. None of these services currently support emergencymessagingsoadditionaldevelopmentwouldberequiredbythesethirdpartyIMservice providers and by the PSAP systems. Additionally, since these systems are proprietary, the PSAP systemsmayhavetointerfacetoeachoftheseIMservices. Video ASL is not considered to be a viable technique for an interim solution. The ability of the existing wireless network to support the required video resolution is marginal. The PSAP systems wouldneedtobeupdatedtosupportincomingvideocalls.Additionally,proficiencyinAmericanSign LanguageisnotacommonskillforPSAPcalltakers. TTY Emulation is not a viable technique for the interim solution. For TTY Emulation to work effectively modifications to the mobile device operating systems are required which implies new mobiledevicedevelopmentandnewmobiledeviceacquisitionbythesubscribers.Initialprototype systemshavedemonstratedthepotentialoftheconceptbuthavenotyetbeenabletomeettheFCC requirementsforerrorrate.

7.

8.

Noneoftheshorttermtechniquesformultimediaemergencyservicescanbesupportedwithoutasignificant developmenteffort.Theimplementationofanyshortterminterimtechniquesformultimediaemergencyservices willrequireresourcesandtimetodevelopanddeploy.Also,theissueoffundingforthedevelopmentand deploymentofanyshorttermtechniquealsoneedstobeaddressed.

Page37of45

APPENDIXA. ACRONYMSANDDEFINITIONS A.1

3GPP AGPS ADA AIM APEX ASL CISC CRTC CS CTM DHHSI DN E911 DNS EMI ESWG FCC FSK GPS GSM GTT GUI HCO HLR HTTP HTTPS IETF IM IMPS IMS IMSI IP

ACRONYMS
3rdGenerationPartnershipProject AssistedGPS AmericanDisabilityAct AOLInstantMessaging ApplicationExchange AmericanSignLanguage CanadianRadiotelevisionTelecommunicationsInterconnectionSteeringCommittee CanadianRadiotelevisionandTelecommunicationsCommission CircuitSwitched CellularToneModulation Deaf,HardofHearing,orSpeechImpaired DirectoryNumber Enhanced911 DomainNameService ExternalMachineInterface EmergencyServicesWorkingGroup FederalCommunicationsCommission FrequencyShiftKeying GlobalPositioningSystem GlobalSystemforMobilecommunications GlobalTextTelephony GraphicalUserInterface HearingCarryOver HomeLocationRegister HypertextTransferProtocol HypertextTransferProtocolSecure InternetEngineeringTaskForce InstantMessaging InstantMessagingandPresenceService IPMultimediaSubsystem InternationalMobileSubscriberIdentity InternetProtocol

Page38of45

ITU ITUT LTE MMES MS MSC MSISDN NANP NG911 NENA OMA PLMN PRIM PSAP PSTN RERC RFC RTT SDP SIM SIMPLE SIP SMPP SMS SMSC T911 TCP TCP/IP TDD TTY UCP UICC UMTS VCO VI

InternationalTelecommunicationUnion ITUTelecommunicationstandardizationsector LongTermEvolution MultimediaEmergencyServices MobileStation MobileSwitchingCenter MobileStationIntegratedServicesDigitalNetwork NorthAmericanNumberingPlan NextGeneration911 NationalEmergencyNumberAssociation OpenMobileAlliance PublicLandMobileNetwork PresenceandInstantMessaging Protocol PublicSafetyAnsweringPoint PublicSwitchedTelephoneNetwork RehabilitationEngineeringResearchCenter RequestforComments RealTimeText SessionDescriptionProtocol SubscriberIdentityModule SIPforInstantMessagingandPresenceLeveragingExtensions SessionInitiationProtocol ShortMessagePeertoPeer ShortMessageService ShortMessageServiceCenter Textmessagingto911 TransmissionControlProtocol TransmissionControlProtocol/InternetProtocol TelecommunicationDeviceforDeaf Teletype UniversalComputerProtocol UniversalIntegratedCircuitCard UniversalMobileTelecommunicationsSystem VoiceCarryOver VRSInterpreter

Page39of45

VRI VRS XML XMPP

VideoRemoteInterpreting VideoRelayService ExtensibleMarkupLanguage ExtensibleMessagingandPresenceProtocol

A.2
PSAP

DEFINITIONS

A PSAP is a set of call takers authorized by a governing body and operating under common management which receives 911 calls and asynchronous event notifications for a defined geographic area and processes those calls and events according to a specifiedoperationalpolicy. TheShortMessageService(SMS)providesameansofsendingmessagesoflimitedsize toandfrommobiles.TheprovisionofSMSmakesuseofaServiceCenter,whichactsas astoreandforwardcenterforshortmessages.

SMS

Page40of45

APPENDIXB. DESCRIPTIONOFINSTANTMESSAGINGARCHITECTURE&PROTOCOLS B.1 ARCHITECTURE&PROTOCOLS

ThegeneralprinciplesofarchitecturebehindIMimplementationsmaybeabstractedtoagenericPresenceservice architectureofwhichIMmaybethoughtofasbeingaspecificinstance.WhileIMapplicationshavebeenaround for a few decades and implementations vary dramatically, more recently, the Open Mobile Alliance (OMA) standardsbodyhasformalizedanInstantMessagingandPresenceServices(IMPS)architecture.Thestatedgoalof IMPS is to define and promote a set of universal specifications for mobile instant messaging and presence services. The specifications are to be used for exchanging messages and presence information between mobile devices, mobile services and Internetbased instant messaging services, all fully interoperable and leveraging existingwebtechnologies.TheIMPSsystemisaclientserverbasedsystem,wheretheserveristheIMPSserver andclientscanbeeithermobileterminals,orotherservices/applications,orfixedPCclients23.Thefigurebelow depictstheOMAdefinedarchitectureforIMPS:

Figure11:OMAIMPSArchitecture ThekeyelementsoftheOMAIMPSarchitecturepertainingtoIMareasfollows: IMPS Server The central point of an IMPS system which houses the Service Elements and the ServiceAccessPointfunctions;

23 IMPSArchitectureApprovedversion1.3,23Jan2007OpenMobileAlliance
Page41of45

IMPS Service Element The Presence Service Elements provides functionality for Presence InformationManagementthisincludesabilityforusersorthesystemtoupdate,retrieve,setand storepresenceandlocationinformation.UserscansubscribetothePresenceinformationofother users as specified in a contact list. Presence information can be obtained from multiple sources includingthemobilecorenetwork.IMisaspecificinstanceofaServiceElementofferedbyanIMPS server.OtherServiceElementsincludeGroup,ContentandGeneralPresenceservices; ServiceAccessPoint(SAP)TheinterfacebetweenanIMPSserveranditsenvironsi.e.totheIMPS Client,otherIMPSservers,tothemobilecorenetworketc.Thefunctionsofthiselementinclude authentication and authorization, service discovery and agreement, user profile management, and servicerelay; IMPSClientReferstotheenddevice.ForIM,thiscouldbealaptop,PCormobiledevice.

Thekeyinterfaces/protocolsaspertainingtoIMcanbeoutlinedasfollows24: ClientServer Protocol (CSP) The IMPS client communicates with the IMPS Service Element (for instance,IM)ontheIMPSServerusingaClientServerProtocol(CSP).TheCSPisbeareragnostici.e. itcanbebuiltonmultipletransporttypesdependingonthespecificimplementation; ServerServerProtocol(SSP)IMPSserversmaycommunicationwithoneanotherusingServerServer Protocol (SSP) either within one service providers domain or across multiple serviceproviders domains.

Figure12:OMAIMPSInterfacesandProtocols 24 IMPSArchitecture,ApprovedVersion1.323Jan2007,OpenMobileAlliance,OMAADIMPSv120070123A;Availableat http://openmobilealliance.org

Page42of45

IMapplicationscomeintwoflavorsEnterpriseIMandConsumerIM.InatypicalEnterpriseIMapplication,the IM server is hosted by the Enterprise with the user community being limited to other Enterprise members althoughsomeEnterprisesmaypermituserstocommunicateoutsidetheecosystem.EnterpriseIMsrequirethe deployment of dedicated hardware server to run the server application. It allows Enterprises to manage communicationsmorecloselyandinalignmentwithbusinessinterestsforinstance,encryptionandarchivingof conversations are considered important features for corporate users. Companies such as Oracle, IBM and MicrosofthaveEnterpriseIMapplicationsthatareintegratedaspartofanOfficeWorkflowsystem.Ontheother hand, Consumer IM applications do not require dedicated hardware. Users are able to access an Internet accessibleIMServerandareabletocommunicatewithotheruserswhoalsousethatIMapplication.Examplesof suchapplicationincludeYahoo!MessengerandGoogleTalketc.Ineithercase,itmaybepossibletousetheIM applicationfromeitherafixedormobiledevice. MobileOperatorsmayalsodeployIMserverswithintheirIPMultimediaService(IMS)domain.Suchadeployment wouldpermitmobileuserstouseanOperatorprovidedIMapplicationtocommunicatewithothermobileorfixed lineuserdependingontheimplementation.Althoughsuchdeploymentsarepossible,theyarenotwidespreadat the timeof this writing andhence are not consideredfurther in thispaper. Most mobile operators permit their users to access overthetop IM applications where an IM client installed on the mobile phone communicates directlywithagloballyaccessibleIMserveroveradataconnectionbuiltusinganoperatorspacketcore.

B.2

LIMITATIONS

ThereisaplethoraofIMapplicationsavailablethatvarywidelyintheirfeatures,capabilities,andimplementation. Someapplications(e.g.GoogleTalk)onlyallowforexchangeoftextualmessages,whileotherspermitexchangeof voice,videoandothermultimediaformats(e.g.Yahoo!Messenger)whichmayrequireadditionalhardwaretobe installedontheendusersdeviceforinstance,awebcamtosupportvideooramicrophonetosupportvoice. Thus,IMapplicationcapabilitiesarenotstandardizedacrossallapplications.ThispresentschallengestothePSAP whomayhavetosupportallavailableIMtypesinorderforallsubscriberstobeabletoreachthem. Interoperability between IM applications remains a concern though popular multiprotocol client software has beenveryeffective..Therehavebeeneffortstounifyandstandardizetheprotocolsmostnotably,theIETFhas recommendedtheuserofSessionInitiationProtocol(SIP)andSIPforInstantMessagingandPresenceLeveraging Extensions (SIMPLE). Other efforts include APEX (Application Exchange), PRIM (Presence and Instant Messaging Protocol), the open XMLbased XMPP (Extensible Messaging and Presence Protocol), and OMA's (Open Mobile Alliance)IMPS(InstantMessagingandPresenceService)createdspecificallyformobiledevices.Theseareyetto catch on with most clientserver protocol implementations remaining proprietary. There have been some collaborationbetweenthemajorIMprovidersthatareworthyofnoteYahoo!andMicrosoftIMapplicationsdo interworkusingtheSIP/SIMPLEprotocol.GoogleandAOLcollaboratetoenableGoogleTalkuserstocommunicate withAOLInstantMessaging(AIM)users.However,nouniversalstandardhastakenhold. IM applications challenge the capabilities of the current circuitswitch centric 911 call routing and location infrastructure. Traditional voicebased 911 calls made over circuitswitched wireless networks involve two distinct events a) location based routing i.e. based on the Cell of Origin the network routes the call to an appropriate PSAP that has jurisdiction over the callers location and b) automatic location determination i.e. when the call is answered by the PSAPcalltaker the system automatically provides location information associatedwiththecallusingthelocationdeterminationinfrastructuredeployedintheoperatorsnetwork.The characteristic of circuitswitched network which make both these functions possible is the close association

Page43of45

betweentheaccessproviderandtheserviceproviderwhichareoneandthesamei.e.theaccessinthiscaseis thecircuitconnectionandtheserviceisthevoicecallandtheyarebothprovidedbyoneandthesameoperator. IM is a packetswitched/ Internet Protocol based service that breaks this close association that exists in the CS domain.Asnoted,mostIMapplicationsareprovidedby3rdpartiessuchasGoogle,Yahoo,SkypeorMSNwhodo notcontroltheaccessnetworkandinvirtuallyallcasesmayevenbeunawareoftheaccesstypeusedtoconnect totheirservice.AnIMsubscribermayaccesstheservicefromanypointofInternetconnectivitybeitwireless broadband network (2.5G or 3G), Cable, DSL or other WiFi hotspots. From the perspective of the IM service, it worksinthesamemannerirrespectiveoftheunderlyingconnectiontype.Theaccessnetworkforitspartmaynot beawareoftheservicesthatthesubscriberisaccessing. AnotherkeydifferencebetweenthecircuitswitchedandIPservicesistheuseridentity.InthecaseofCSservices, itiscloselytiedtothedevice.Forinstance,inthecaseofCS,asubscriberregisterswiththenetworkusingamobile ID (typically an IMSI or MSISDN) and when making a call, uses the same identity. However, in the case of IP servicessuchasIM,multipleidentitiesareusuallyinvolvedFore.g.ausermaysignontotheiraccess(Wireless, DSLorcable)usingaparticularidentitybutmayuseacompletelydifferentidentitytoaccesstheirIMapplication. The differences between the traditional CSservice and IPservices detailed above poses issues for routing and location determination when it comes to providing the same services for IM. In CSnetwork, the MSC (the CS equivalentofthevoiceserviceproviderinthePSnetwork)recognizesanEmergencyCallOriginationandroutes the call to the PSAP based on the Cell of Origin (COO) obtained from the Radio Access Network (RAN). Simultaneously, it also kicks off the location determination process towards a Positioning Determination Entity (PDE) that is located within the access network and which uses the measurements obtained from the access network and perhaps the device itself to determine the callers location. However, the same model cannot be transferred over to support IM applications. For instance, the IM Server may not be able to recognize an emergencysituation.Furthermore,notknowingtheidentityorthenatureoftheaccesstypethroughwhichthe userisconnectedtomeansthatIMservermaynotbeabletokickoffalocationdeterminationprocessnorroute thecalltoaPSAPthathasjurisdictionoverthecallerslocation.ThereareseveralarchitecturesdefinedbyNENA (i3),3GPP(IMSarchitecture)andIETF(IPLocationArchitecture)whichaddresstheissueofseparationofservice andaccesslayersandhowlocationacquisitionandconveyancecanworkundertheseenvironments.Theseinvolve newnodessuchastheLocationRoutingFunction(LRF),LocationInformationServer(LIS),LoST(LocationtoService Translation) which provide location determination and routing functions in an IP environment. However, these haventbeenwidelyimplementedasyetandmaynotbedonesoforquiteawhile.

Page44of45

ACKNOWLEDGEMENTS

The mission of 4G Americas is to promote, facilitate and advocate for the deployment and adoption of the 3GPP family of mobile broadband technologies throughout the ecosystem includingnetworks,services,applicationsandwirelesslyconnecteddevicesintheAmericas. 4G Americas would like to recognize the significant project leadership and important contributions of DeWayne Sennett and Brian K. Daly of AT&T as well as the other member companies from 4G Americas Board of Governors who participated and contributed to the developmentofthiswhitepaper. 4GAmericasBoardofGovernorsmembersincludeAlcatelLucent,AmericaMvil,AT&T,Cable &Wireless,CommScope,Ericsson,Gemalto,HP,Huawei,NokiaSiemensNetworks,Openwave, Powerwave,Qualcomm,ResearchInMotion,RogersWireless,ShawCommunications,TMobile USAandTelefnica.

Page45of45