WO2019027537A1

WO2019027537A1 - User equipment enabling enhanced emergency call with sms

Info

Publication number: WO2019027537A1
Application number: PCT/US2018/033890
Authority: WO
Inventors: Vashishth Jhunjhunwala; Hargovind Prasad BANSAL; Stephen William Edge
Original assignee: Qualcomm Incorporated
Priority date: 2017-08-01
Filing date: 2018-05-22
Publication date: 2019-02-07

Abstract

Techniques described herein enable a user equipment (UE) to send a short message service (SMS) message to a public safety answering point (PSAP) during an emergency situation. Techniques can involve initiating an emergency call to a PSAP in response to a detected emergency condition and sending an emergency-related SMS message in response to detecting a trigger condition, where the SMS is sent via a serving network different than a home network of the UE and the sending bypasses the home network.

Description

USER EQUIPMENT ENABLING ENHANCED EMERGENCY CALL WITH

SMS

BACKGROUND

[0001] During an emergency call in a wireless communication network (e.g., Global System for Mobile communication (GSM), Universal Mobile Telecommunications Service (UMTS), or Long Term Evolution (LTE)), a voice channel may be established between a user equipment (UE) (such as a mobile phone) and a public safety answering point (PSAP), enabling a user of the UE to speak with an emergency services operator. Due to network or other issues, however, the call may not be established.

[0002] Traditional techniques for establishing an emergency call between a UE and a PSAP may address this by making additional attempts to establish the emergency call using alternative radio access technologies (RATs) and/or alternative networks. A UE capable of establishing an emergency call using multiple RATs may then try one RAT and/or one network after another until an emergency call is successfully established. But this may take a long time - e.g. when the UE resorts to using WiFi (which may take 20-40 seconds to establish an emergency call). Delays in establishing the emergency call may be extremely undesirable in some emergency situations and may even lead to a user abandoning the emergency call attempt before the call succeeds. SUMMARY

[0003] Techniques described herein are directed toward enabling a UE to send a short message service (SMS) message to a PSAP during an emergency situation.

Techniques can involve initiating an emergency call to a PSAP in response to a detected emergency condition and sending an emergency-related SMS message in response to detecting a trigger condition, where the SMS is sent via a serving network different than a home network of the UE and the sending bypasses the home network.

[0004] An example method of initiating an emergency call at a user equipment (UE) on a behalf of a user, according to the description comprises detecting, with the UE, an emergency condition, initiating, based on the emergency condition, the emergency call to a public safety answering point (PSAP) using a certain radio access type, detecting a trigger condition, and sending, based on the trigger condition, an emergency-related short message service (SMS) message to the PSAP via a serving network different than a home network of the UE, wherein the sending bypasses the home network.

[0005] The example method may include one or more of the following features. The emergency condition may comprise an automatically-detected emergency condition. The automatically-detected emergency condition may comprise a medical condition of the user, an indication of an accident involving the user, or an indication of an imminent danger to the user, or any combination thereof. The trigger condition further may comprise the emergency condition, a failure to establish the emergency call using the certain radio access type, a delay in establishing the emergency call exceeding a certain threshold of time, or a quality of the certain radio access type being below a certain threshold of quality, or any combination thereof. The emergency-related SMS message may comprise an emergency indication, a location of the UE, information regarding the user, or information regarding the emergency condition, or any combination thereof. The emergency-related SMS message may comprise a uniform resource locator (URL) that enables the PSAP to access data regarding the user.

Sending the emergency-related SMS message to the PSAP further may comprise sending the emergency-related SMS message to an IP Multimedia Subsystem (IMS) in the serving network using a session initiation protocol (SIP). The method further may comprise sending an updated emergency-related SMS message to the PSAP based on a subsequently detected change in a location of the UE, change in information regarding the user, or change in information regarding the emergency condition, or any combination thereof.

[0006] An example method of routing emergency-related short message service (SMS) messages at a network element of a serving network different than a home network of a user equipment (UE), according to the description, may comprise receiving a request for an emergency call from the UE, receiving an SMS message from the UE, the SMS message comprising an emergency indication, determining, based on the emergency indication, a destination address for the SMS message, and routing the SMS message towards a public safety answering point (PSAP) based on the destination address, wherein the routing bypasses the home network.

[0007] The example method may include one or more of the following features. The emergency indication may comprise an association of the SMS message with the emergency call. The association with the emergency call may comprise use of the same IP address by the UE for both the emergency call and the SMS message, use of the same emergency packet data network connection by the UE for both the emergency call and the SMS message, or use of the same identification of the UE for both the emergency call and the SMS message, or any combination thereof. The method may further comprise sending the SMS message towards the PSAP based on the routing. The network element may be part of an IP Multimedia Subsystem (IMS) in the serving network. The network element may comprise a Proxy Call Session Control Function (P- CSCF) or an Emergency Call Session Control Function (E-CSCF). The request for the emergency call may comprise a Session Initiation Protocol (SIP) REGISTER message or a SIP INVITE message. The SMS message may be received in a SIP MESSAGE. The association of the SMS message with the emergency call may comprise a first IP address for the UE in a SIP Contact header for the SIP REGISTER message or SIP INVITE message and a second IP address for the UE in a SIP Contact header for the SIP MESSAGE, where the first IP address is the same as the second IP address.

[0008] An example user equipment (UE), according to the description, comprises a wireless communication interface, a memory, and a processing unit communicatively coupled with the wireless communication interface and memory, and configured to cause the UE to detect an emergency condition, initiate, based on the emergency condition, an emergency call to a public safety answering point (PSAP) using a certain radio access type, detect a trigger condition, and send, based on the trigger condition, an emergency-related short message service (SMS) message to the PSAP. The emergency- related SMS message is sent, using the wireless communication interface, via a serving network different than a home network of the UE, bypassing the home network of the UE.

[0009] The user equipment may comprise one or more of the following features. The user equipment may comprise one or more sensors, wherein the processing unit is configured to cause the UE to detect an emergency condition using data from the one or more sensors. The one or more sensors may be configured to detect a medical condition of a user, an indication of an accident involving the user, or an indication of an imminent danger to the user, or any combination thereof. The processing unit may be configured to cause the UE to detect the trigger condition by detecting the emergency condition, a failure to establish the emergency call using the certain radio access type, a delay in establishing the emergency call exceeding a certain threshold of time, or a quality of the certain radio access type being below a certain threshold of quality, or any combination thereof. The processing unit may be configured to cause the UE to include, in the emergency-related SMS message, an emergency indication, a location of the UE, information regarding a user, or information regarding the emergency condition, or any combination thereof. The processing unit may be configured to cause the UE to include, in the emergency -related SMS message, a uniform resource locator (URL) that enables the PSAP to access data regarding a user. The processing unit may be configured to cause the UE to send the emergency-related SMS message to an IP Multimedia Subsystem (IMS) in the serving network using a session initiation protocol (SIP). The processing unit may be further configured to cause the UE to send an updated emergency-related SMS message to the PSAP based on a subsequently detected change in a location of the UE, change in information regarding a user, or change in information regarding the emergency condition, or any combination thereof.

[0010] An example network element, according to the description, comprises a communications interface configured to enable the network element to compose part of a serving network, a memory, and a processing unit communicatively coupled with the communications interface and the memory, and configured to cause the network element to receive a request for an emergency call from a user equipment (UE) having a home network different than the serving network, receive an short message service (SMS) message from the UE, the SMS message comprising an emergency indication, determine, based on the emergency indication, a destination address for the SMS message, and route the SMS message towards a public safety answering point (PSAP) based on the destination address, where the routing bypasses the home network of the UE.

[0011] The network element may comprise one or more of the following features.

The processing unit may be further configured to cause the network element to determine, from the SMS message, an association of the SMS message with the emergency call. The processing unit may be configured to cause the network element to determine the association of the SMS message with the emergency call by determining use of the same IP address by the UE for both the emergency call and the SMS message, use of the same emergency packet data network connection by the UE for both the emergency call and the SMS message, or use of the same identification of the UE for both the emergency call and the SMS message, or any combination thereof. The processing unit may be configured to cause the network element to send the SMS message towards the PSAP based on the routing. The network element may be configured to compose part of an IP Multimedia Subsystem (IMS) in the serving network. The network element may be configured to comprise a Proxy Call Session

Control Function (P-CSCF) or an Emergency Call Session Control Function (E-CSCF).

The processing unit may be configured to cause the network element to receive the request for the emergency call by receiving a Session Initiation Protocol (SIP)

REGISTER message or a SIP INVITE message. The processing unit may be configured to cause the network element to receive the SMS message in a SIP MESSAGE. The processing unit may be configured to cause the network element to determine the association of the SMS message with the emergency call by determining a first IP address for the UE in a SIP Contact header for the SIP REGISTER message or SIP INVITE message is the same as a second IP address for the UE in a SIP Contact header for the SIP MESSAGE.

[0012] An example UE, according to the description, comprises means for detecting, with the UE, an emergency condition, means for initiating, based on the emergency condition, an emergency call to a public safety answering point (PSAP) using a certain radio access type, means for detecting a trigger condition, and means for sending, based on the trigger condition, an emergency -related short message service (SMS) message to the PSAP via a serving network different than a home network of the UE, wherein the sending bypasses the home network.

[0013] The example UE may include one or more of the following features. The means for detecting an emergency condition may comprise means for automatically detecting the emergency condition. The means for automatically detecting the emergency condition may comprise means for detecting a medical condition of a user, an indication of an accident involving the user, or an indication of an imminent danger to the user, or any combination thereof. The means for detecting the trigger condition further may comprise means for detecting the emergency condition, a failure to establish the emergency call using the certain radio access type, a delay in establishing the emergency call exceeding a certain threshold of time, or a quality of the certain radio access type being below a certain threshold of quality, or any combination thereof The means for sending the emergency-related SMS message may comprise means for including, in the emergency-related SMS message, an emergency indication, a location of the UE, information regarding a user, or information regarding the emergency condition, or any combination thereof. The means for sending the emergency-related SMS message may comprise means for including, in the emergency-related SMS message, a uniform resource locator (URL) that enables the PSAP to access data regarding a user. The means for sending the emergency-related SMS message to the PSAP may further comprise means for sending the emergency-related SMS message to an IP Multimedia Subsystem (IMS) in the serving network using a session initiation protocol (SIP). The UE may further comprise means for sending an updated emergency- related SMS message to the PSAP based on a subsequently detected change in a location of the UE, change in information regarding a user, or change in information regarding the emergency condition, or any combination thereof.

[0014] An example network element, according to the description, comprises means for receiving a request for an emergency call from a user equipment (UE) at the network element, wherein the network element composes part of a serving network different than a home network of the UE, means for receiving a short message service (SMS) message from the UE, the SMS message comprising an emergency indication, means for determining, based on the emergency indication, a destination address for the SMS message, and means for routing the SMS message towards a public safety answering point (PSAP) based on the destination address, wherein the routing bypasses the home network.

[0015] The example network element may include one or more of the following features. The network element may include means for determining, from the emergency indication, an association of the SMS message with the emergency call. The means for determining the association with the emergency call may comprise means for determining use of the same IP address by the UE for both the emergency call and the SMS message, use of the same emergency packet data network connection by the UE for both the emergency call and the SMS message, or use of the same identification of the UE for both the emergency call and the SMS message, or any combination thereof. The network element may include means for sending the SMS message towards the PSAP based on the routing. The network element may be configured to compose part of an IP Multimedia Subsystem (IMS) in the serving network. The network element may comprise a Proxy Call Session Control Function (P-CSCF) or an Emergency Call Session Control Function (E-CSCF). The means for receiving the request for the emergency call may comprise means for receiving a Session Initiation Protocol (SIP) REGISTER message or a SIP INVITE message. The means for receiving the SMS messages may comprise means for receiving the SMS message in a SIP MESSAGE. The network element may further comprise means for determining the association of the SMS message with the emergency call by determining a first IP address for the UE in a SIP Contact header for the SIP REGISTER message or SIP INVITE message is the same as a second IP address for the UE in a SIP Contact header for the SIP MESSAGE.

[0016] An example non-transitory computer-readable medium, according to the description, has instructions embedded thereon for initiating an emergency call at a user equipment (UE) on behalf of a user. The instructions include computer code for detecting an emergency condition, initiating, based on the emergency condition, the emergency call to a public safety answering point (PSAP) using a certain radio access type, detecting a trigger condition, and sending, based on the trigger condition, an emergency-related short message service (SMS) message to the PSAP via a serving network different than a home network of the UE, wherein the sending bypasses the home network. [0017] The example non-transitory computer-readable medium may include one or more of the following features. The computer code for detecting an emergency condition may comprise computer code for automatically detecting the emergency condition. The computer code for automatically detecting the emergency condition may comprise computer code for detecting a medical condition of the user, an indication of an accident involving the user, or an indication of an imminent danger to the user, or any combination thereof. The computer code for detecting the trigger condition further comprise computer code for detecting the emergency condition, a failure to establish the emergency call using the certain radio access type, a delay in establishing the emergency call exceeding a certain threshold of time, or a quality of the certain radio access type being below a certain threshold of quality, or any combination thereof. The computer code for sending the emergency-related SMS message may comprise computer code for including, in the emergency-related SMS message, an emergency indication, a location of the UE, information regarding the user, or information regarding the emergency condition, or any combination thereof. The computer code for sending the emergency-related SMS message may comprise computer code for including, in the emergency-related SMS message, a uniform resource locator (URL) that enables the PSAP to access data regarding the user. The computer code for sending the emergency-related SMS message to the PSAP further may comprise computer code for sending the emergency-related SMS message to an IP Multimedia Subsystem (IMS) in the serving network using a session initiation protocol (SIP). The instructions further may comprise computer code for sending an updated emergency-related SMS message to the PSAP based on a subsequently detected change in a location of the UE, change in information regarding the user, or change in information regarding the emergency condition, or any combination thereof. [0018] An example non-transitory computer-readable medium, according to the description, has instructions embedded thereon for routing emergency -related short message service (SMS) messages at a network element of a serving network different than a home network of a user equipment (UE). The instructions comprise computer code for receiving a request for an emergency call from the UE at the network element, receiving a short message service (SMS) message from the UE, the SMS message comprising an emergency indication, determining, based on the emergency indication, a destination address for the SMS message, and routing the SMS message towards a public safety answering point (PSAP) based on the destination address, wherein the routing bypasses the home network.

[0019] The example non-transitory computer-readable medium may include one or more the following features. The instructions further comprise computer code for determining, from the emergency indication, an association of the SMS message with the emergency call. The computer code for determining the association with the emergency call may comprises computer code for determining use of the same IP address by the UE for both the emergency call and the SMS message, use of the same emergency packet data network connection by the UE for both the emergency call and the SMS message, or use of the same identification of the UE for both the emergency call and the SMS message, or any combination thereof. The instructions further may comprise computer code for sending the SMS message towards the PSAP based on the routing. The instructions further comprise computer code for causing a computer to perform functions as part of an IP Multimedia Subsystem (IMS) in the serving network.

The instructions further may comprise computer code for performing one or more functions of a Proxy Call Session Control Function (P-CSCF) or an Emergency Call

Session Control Function (E-CSCF). The computer code for receiving the request for the emergency call may comprise computer code for receiving a Session Initiation Protocol (SIP) REGISTER message or a SIP INVITE message. The computer code for receiving the SMS messages may comprise computer code for receiving the SMS message in a SIP MESSAGE. The instructions further may comprise computer code for determining the association of the SMS message with the emergency call by determining a first IP address for the UE in a SIP Contact header for the SIP

REGISTER message or SIP INVITE message is the same as a second IP address for the UE in a SIP Contact header for the SIP MESSAGE.

BRIEF DESCRIPTION OF DRAWINGS

[0020] Non-limiting and non-exhaustive aspects are described with reference to the following figures.

[0021] FIG. 1 is a simplified illustration of an embodiment of a communication system capable of transmitting an emergency short message service (SMS) message according to the techniques described herein.

[0022] FIG. 2 is a signaling flow diagram illustrating how an emergency SMS (ESMS) message can be communicated from a user equipment (UE) to a public safety answering point (PSAP) in conjunction with an emergency call, in an embodiment, for the communication system of FIG. 1.

[0023] FIG. 3 is a simplified illustration of a Long Term Evolution (LTE) communication system capable of transmitting an ESMS message according to the techniques described herein. [0024] FIG. 4 is a signaling flow diagram illustrating how an ESMS message can be communicated from a user equipment (UE) to a public safety answering point (PSAP) in conjunction with an emergency call, in an embodiment, for the communication system of FIG. 3.

[0025] FIG. 5 is a flow diagram illustrating a method of initiating an emergency call at a UE, according to an embodiment.

[0026] FIG. 6 is a flow diagram illustrating a method 600 of routing an ESMS message, according to an embodiment.

[0027] FIG. 7 is a block diagram illustrating an embodiment of a UE, according to an embodiment.

[0028] FIG. 8 is a block diagram illustrating an embodiment of a computer system.

[0029] Elements, stages, steps and actions with the same reference label in different drawings may correspond to one another (e.g. may be similar or identical to one another). Further, some elements in the various drawings are labelled using a numeric prefix followed by a numeric suffix. Elements with the same numeric prefix but different suffices may be different instances of the same type of element. The numeric prefix without any suffix is used herein to reference any element with this numeric prefix. For example, different instances 180-1 and 180-2 of a PSAP are shown in FIG. 3. A reference to a PSAP 180 then refers to either of PSAPs 180-1 and 180-2. DETAILED DESCRIPTION

[0030] During an emergency call in a wireless communication network (e.g., Global System for Mobile communication (GSM), Universal Mobile Telecommunications Service (UMTS), or Long Term Evolution (LTE)), a voice channel may be established between a user equipment (UE) (such as a mobile phone) and a public safety answering point (PSAP), enabling a user of the UE to speak with an emergency services operator. Due to network or other issues, however, the call may not be established.

[0031] Traditional techniques for establishing an emergency call between a UE and a PSAP may address this by making additional attempts to establish the emergency call using alternative radio access technologies (RATs) and/or alternative networks. A UE capable of establishing an emergency call using multiple RATs may then try one RAT and/or one network after another until an emergency call is successfully established. But this may take a long time - e.g. when the UE resorts to using WiFi (which may take 20-40 seconds to establish an emergency call). Delays in establishing the emergency call may be extremely undesirable in urgent emergency situations and may even lead to a user abandoning the emergency call attempt before the call succeeds.

[0032] Techniques described herein address this and other issues by enabling a UE to send a short message service (SMS) message to a PSAP during an emergency situation. The SMS message (also referred to herein as an "emergency-related SMS message," "emergency SMS message," "emergency SMS," "ESMS," or "ESMS message") can include information that may be valuable to the PSAP, such as the location of the UE, the identity of the UE or user, a call back number for the UE, available medical and/or emergency data, other identification information, and the like. Further, the SMS message may be sent via a serving network, different than the UE's home network, in order to improve reliability and/or reduce delay in transferring the SMS message.

[0033] Sending an emergency SMS message in this manner may be advantageous for a variety of reasons, primarily due the fact that an emergency message provides another means on contacting a PSAP in situations where an emergency call may not be reliable (e.g. not successful or sucessful only after a long delay). For example, an emergency call requires a large number of procedures between various network components to establish a dedicated signaling and voice bearer and a session with a PSAP. This requires the availability and assignment of resources (e.g. wireless bandwidth, bandwidth on wireline links and trunks) in the wireless network, in any intermediate networks and at the PSAP. In some situations, the resources may not be available at one or more entities. In other situations, resources may be available but the UE may have poor wireless reception and be unable to use a voice bearer with good enough Quality of Service (QoS) to permit intelligible voice communication. In some other situations, an emergency call may be established with acceptable voice quality, but a user may be unable to speak (e.g. due to a severe medical condition or as the result of an accident). An emergency SMS message is not session based, may not require a dedicated bearer or a continuously good wireless QoS and may not require voice interaction between a user and PSAP. Furthermore, an emergency SMS message can be sent in a short burst of wireless signaling and does not require the availability of signaling and voice transfer over a long period. Additional details regarding these advantages are provided below.

[0034] FIG. 1 is a simplified illustration of an embodiment of a communication system 100 capable of transmitting an ESMS according to the techniques described herein. More specifically, the techniques described herein may be implemented by one or more components of the communication system 100. The communication system 100 can include a UE 105, one or more space vehicles (SVs) 110, one or more base stations 120, one or more access points 130, a serving network 140, a location server 150, a home network 160, the Internet 170, and a PSAP 180.

[0035] It should be noted that FIG. 1 provides only a generalized illustration of various components, any or all of which may be utilized as appropriate, and each of which may be duplicated (or absent) as necessary. Specifically, although only one UE 105 is illustrated, it will be understood that many UEs (e.g., hundreds, thousands, millions, etc.) may utilize the communication system 100. Similarly, the

communication system 100 may include a larger or smaller number of base stations 120 and/or APs 130 than illustrated in FIG. 1. The illustrated connections that connect the various components in the communication system 100 comprise data and signaling connections which may include additional (intermediary) components, direct or indirect physical and/or wireless connections, and/or additional networks. Furthermore, components may be rearranged, combined, separated, substituted, and/or omitted, depending on desired functionality. In some embodiments, for example, the location server 150 may be incorporated into the serving network 140. Additionally or alternatively, depending on the capabilities of the UE 105, RATs other than those shown in and described for FIG. 1 may be available to the UE 105 for communicating with the PSAP 180. A person of ordinary skill in the art will recognize many modifications to the components illustrated.

[0036] The UE 105 may comprise and/or be referred to herein as a device, a mobile device, a wireless device, a mobile terminal, a terminal, a mobile station (MS), a Secure User Plane Location (SUPL) Enabled Terminal (SET), or by some other name.

Moreover, UE 105 may correspond to a cellphone, smartphone, laptop, tablet, PDA, tracking device or some other portable or moveable device. Typically, though not necessarily, the UE 105 may support wireless communication such as using GSM, Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), LTE, High Rate Packet Data (HRPD), WiFi (also referred to as Wi-Fi), Bluetooth® (BT), Worldwide Interoperability for Microwave Access (WiMAX), etc. The UE 105 may also support wireless communication using a Wireless Local Area Network (WLAN) which may connect to other networks (e.g. the Internet 170) using a Digital Subscriber Line (DSL) or packet cable for example. As indicated above, one or more of these RATs may enable the UE 105 to communicate with the PSAP 180.

[0037] The UE 105 may comprise a single entity or may comprise multiple entities such as in a personal area network where a user may employ audio, video and/or data I/O devices and/or body sensors and a separate wireline or wireless modem. An estimate of a location of the UE 105 may be referred to as a location, location estimate, location fix, fix, position, position estimate or position fix, and may be geographic, thus providing location coordinates for the UE 105 (e.g., latitude and longitude) which may or may not include an altitude component (e.g., height above sea level, height above or depth below ground level, floor level or basement level). Alternatively, a location of the UE 105 may be expressed as a civic location (e.g., as a postal address or the designation of some point or small area in a building such as a particular room or floor). A location of the UE 105 may also be expressed as an area or volume (defined either

geographically or in civic form) within which the UE 105 is expected to be located with some probability or confidence level (e.g., 67% or 95%). A location of the UE 105 may further be a relative location comprising, for example, a distance and direction or relative X, Y (and Z) coordinates defined relative to some origin at a known location which may be defined geographically, in civic terms, or by reference to a point, area, or volume indicated on a map, floor plan or building plan. In the description contained herein, the use of the term location may comprise any of these variants unless indicated otherwise.

[0038] Serving network 140 may provide wireless access to UE 105 (e.g. using any of the RATs described previously). Home network 160 may be a network with which the user of UE 105 maintains a subscription for wireless services. When UE 105 is served by home network 160, networks 140 and 160 may be the same network.

[0039] Depending on desired functionality, the serving network 140 and home network 160 may comprise any of a variety of wireless and/or wireline networks. These networks 140 and 160 can, for example, comprise any combination of public and/or private networks, local and/or wide-area networks, and the like. Furthermore, networks 140 and 160 may utilize one or more wired and/or wireless communication

technologies. In some embodiments, the networks 140 and 160 may comprise a cellular network, some other wireless wide area network (WW AN) network and/or a wireless local area network (WLAN), for example. Particular examples of networks 140 and 160 include an LTE wireless network, a Fifth Generation (5G) wireless network (also referred to as New Radio (NR) wireless network), a WiFi WLAN and the Internet. LTE, GSM, WCDMA, 5G and NR are wireless technologies defined, or being defined, by the 3^rd Generation Partnership Project (3GPP). Networks 140 and 160 may also include more than one network and/or more than one type of network.

[0040] Under non-emergency situations, the UE 105 can communicate with the home network 160 for authentication and authorization purposes. This communication from the UE 105 to the home network 160 may be made via the serving network 140 and Internet 170. (It will be understood, however, that the configuration of the serving network 140, home network 160, and/or Internet 170 can vary, depending on desired functionality.) The home network 160 may also provide IP multimedia subsystem (IMS) and/or other services. As discussed in further detail below, the home network 160 may be bypassed during emergency calls, for both voice channel establishment and for the transmission of an emergency SMS to the PSAP 180, in accordance with the techniques disclosed herein.

[0041] The base stations 120 and access points (APs) 130 are communicatively coupled to the serving network 140 and may be considered to be part of the serving network 140 (though are shown separately for greater clarity). Depending on the technology of the serving network 140, a base station 120 may comprise a Node B, an Evolved Node B (also referred to as an eNodeB or eNB), a base transceiver station (BTS), a radio base station (RBS), or the like. A base station 120 may support a WW AN technology or RAT such as GSM, WCDMA, LTE or 5G. An AP 130 may comprise a WiFi AP or a Bluetooth AP. Thus, the UE 105 can send and receive information to and from network-connected devices, such as the location server 150, by accessing the serving network 140 via a base station 120 using a first communication link 133. Additionally or alternatively, because APs 130 also may be communicatively coupled with the serving network 140, the UE 105 may communicate with network- connected devices, including the location server 150, using a second communication link 135.

[0042] The location server 150 may comprise a server and/or other computing device configured to determine a location estimate for the UE 105 and/or provide data (e.g., "assistance data") to the UE 105 to facilitate the location determination.

According to some embodiments, the location server 150 may comprise a Secure User Plane Location (SUPL) Location Platform (SLP) server, which may support the SUPL user plane (UP) location solution defined by the Open Mobile Alliance (OMA) and may support location services for UE 105 based on subscription information for UE 105 stored in the location server 150. In some embodiments, the location server 150 may comprise a Discovered SLP (D-SLP) or an Emergency SLP (E-SLP). The location server 150 may also comprise an Enhanced Serving Mobile Location Center (E-SMLC) that supports location of UE 105 using a control plane (CP) location solution for LTE access by UE 105. The location server 150 may further comprise a Location

Management Function (LMF) that supports location of UE 105 using a control plane (CP) location solution for 5G or R wireless access by UE 105. In a CP location solution, signaling to control and manage the location of UE 105 may be exchanged between elements of serving network 140, and with UE 105, using existing network interfaces and protocols and as signaling from the perspective of serving network 140. In a UP location solution, signaling to control and manage the location of UE 105 may be exchanged between location server 150 and UE 105 as data (e.g. data transported using the Internet Protocol (IP) or Transmission Control Protocol (TCP) and IP (TCP/IP)) from the perspective of serving network 140.

[0043] As previously mentioned, the UE 105 may include its location in an emergency SMS message sent to the PSAP 180. This location may be obtained using any of a variety of techniques. In particular implementations, UE 105 may have circuitry and processing resources capable of obtaining location related measurements (e.g. for signals received from SVs 1 10, APs 130, and/or base stations 120) and possibly computing a position fix or estimated location of the UE 105 based on these location related measurements. In some implementations, location related measurements obtained by the UE 105 may be transferred to the location server 150 after which the location server 150 may estimate or determine a location for the UE 105 based on the measurements. Location related measurements obtained by the UE 105 may include measurements of signals received from SVs 1 10 belonging to a Satellite Positioning System (SPS) or Global Navigation Satellite System (GNSS) such as the Global Positioning System (GPS), GLONASS, Galileo or Beidou, and/or may include measurements of signals received from terrestrial transmitters fixed at known locations (e.g., such as base stations 120 and/or APs 130). The UE 105 and/or location server 150 may then obtain a location estimate for the UE 105 based on these location related measurements using any one of several known position methods such as, for example, GNSS, Assisted GNSS (A-GNSS), Advanced Forward Link Trilateration (AFLT), Observed Time Difference Of Arrival (OTDOA), or Enhanced Cell ID (E-CID), or combinations thereof.

[0044] In some of these techniques (e.g. A-GNSS, AFLT and OTDOA), pseudoranges or timing differences may be measured at the UE 105 relative to three or more terrestrial transmitters fixed at known locations or relative to four or more satellites with accurately known orbital data, or combinations thereof, based at least in part, on pilots, navigation signals, positioning reference signals (PRS) or other positioning related signals transmitted by the transmitters or satellites and received at the UE 105. Here, the location server 150 may be capable of providing positioning assistance data to the UE 105 including, for example, information regarding signals to be measured (e.g., signal timing, frequency, coding and/or bandwidth), locations and identities of terrestrial transmitters and/or signal, timing and/or orbital information for GNSS satellites to facilitate positioning techniques such as A-GNSS, AFLT, OTDOA and E-CID. For example, the location server 150 may comprise an almanac which indicates locations and identities of base stations 120 and/or APs 130 in a particular region or regions such as a particular venue, and may provide information descriptive of signals transmitted by one or more of the terrestrial transceivers (e.g., base stations 120 and/or APs 130) such as transmission power and signal timing. In the case of positioning using E-CID, the UE 105 may obtain measurements of signal strengths for signals received from terrestrial transceivers and/or may obtain a round trip signal propagation time (RTT) between the UE 105 and a terrestrial transceiver.

[0045] The UE 105 may use the measurements obtained for signals received from satellites and/or terrestrial transceivers (or transmitters) together with assistance data (e.g. terrestrial almanac data or GNSS satellite data such as GNSS Almanac and/or GNSS Ephemeris information) received from the location server 150 to determine a location for the UE 105 or may transfer the measurements to the location server 150 to perform the same determination. An emergency and/or SMS message sent from the UE 105 may be routed to or towards the PSAP 180 based on the location of the UE. For eaxmple, the PSAP 180 may be a PSAP whose public safety service area includes the location that was determined for the UE 105.

[0046] The PSAP 180, as represented in FIG. 1, may comprise one or more devices to which emergency calls and/or SMS messages may be routed. Furthermore, although FIG. 1 illustrates the PSAP 180 as having separate connections with both the serving network 140 and the Internet 170, other configurations are possible. In some embodiments, the PSAP 180 may be directly connected with only one or the other.

[0047] FIG. 2 is a signaling flow diagram illustrating how an emergency SMS message can be communicated from the UE 105 to the PSAP 180 in conjunction with an emergency call, according to an embodiment. Here, it can be noted that although the home network 160 is illustrated, it may be largely bypassed to establish both the emergency call and send the emergency SMS message. This can help reduce the number of steps needed to route the emergency SMS message, reducing potential delay. In addition, bypassing the home network 160 may improve reliability by avoiding dependence on the home network 160. For example, if the home network 160 does not provide wireless coverage at or nearby to the present location of UE 105, the home network 160 may not be able to send an ESMS message to PSAP 180 due to connectivity limitations or inability to route the ESMS message to a preferred or correct PSAP 180. Therefore, bypassing home network 160 may avoid failure of ESMS message transfer to PSAP 180 due to such limitations of home network 160.

[0048] Communication between components in FIG. 2 may be made via messages provided in accordance with governing standards and/or protocols. A person of ordinary skill in the art will appreciate that alternative embodiments may perform functions in a different order, add functions, omit functions, and/or employ other variations from the functionality illustrated in FIG. 2, depending on desired

functionality.

[0049] At block 210 in FIG. 2, the UE 105 detects an emergency condition. This can be done in any of a variety of ways, depending on the scenario. The detection may be made using sensor, location, and/or other information obtained by the UE 105.

Accordingly, an emergency condition can comprise any of a variety of events detected by the UE 105, including the user dialing of an emergency number, entering a predetermined location, performing a certain gesture, speaking a certain word or phrase, and the like. Health information of the user may additionally or alternatively be considered, and may be obtained through health-monitoring sensors worn by, implanted in, or otherwise connected with the user. In such embodiments, an emergency condition may comprise the receipt of certain health information, such as an indication of an irregular heartbeat, high or low blood pressure, hyperventilation, high or low body temperature, high or low blood sugar, etc. In some embodiments, the emergency condition may be user defined.

[0050] In response to detecting the emergency condition, UE 105 then performs actions to initiate an emergency call. At action 215, the UE attaches to the serving network 140 (e.g., by sending an Attach Request message to serving network 140) if the UE 105 is not already attached. The UE 105 and serving network 140 then establish an emergency packet data network (PDN) connection at action 220, which may include assigning an IP address to the UE 105. The UE 105 then performs an IMS emergency registration at action 225 with both the serving network 140 and the home network 160 and may provide the IP address obtained at action 220 as a contact address to the serving network 140 and the home network 160. At actions 230 and 235, the UE 105 can attempt to establish an IMS emergency call with the PSAP 180 via the serving network 140. Timing, format, and/or other aspects of communication may be governed by applicable standards and/or protocols. Actions 215 to 235 may be as defined for IMS emergency call initiation with LTE wireless access - e.g. as in 3GPP Technical Specifications (TSs) 23.167, 23.401 and 24.229.

[0051] At block 240, the UE 105 may detect a trigger condition, which can trigger the sending of the emergency SMS message from the UE 105 to the PSAP 180 at actions 245 and 250. Similar to the emergency condition of block 210, the trigger condition can be any of a variety of events detected by the UE 105 that may be cause for sending an emergency SMS message. For example, the UE 105 may detect that the IMS emergency call establishment attempt (actions 230 and 235) has failed, or simply that the attempt was made but the emergency call was not established. As previously mentioned (and not shown in FIG. 2), emergency attempts may be made with a variety of different RATs, in which case embodiments may send an emergency SMS message (e.g., perform actions 245 and 250) after an emergency call establishment fails with each RAT and/or after each attempt with a particular RAT fails (e.g. in embodiments that make multiple attempts to establish an emergency call using a single RAT). In some embodiments, the trigger condition detected at block 240 may be time-based, such that, the trigger condition is detected after a certain amount of time passes since a previous event, such as the IMS emergency call establishment attempt (action 230), the emergency condition being detected (block 210), and/or another such event. As an example, the UE may instigate ESMS message sending at action 245 following the elapse of a short period (e.g. 10 to 20 seconds) following detection of the emergency condition at block 210 if an emergency is not yet established or was (briefly) established and has failed. In some embodiments, the trigger condition detected at block 240 may comprise a deterioration or seriousness in the emergency condition detected at block 210 - e.g. such as health monitoring indicating that the user may not be able to speak to a PSAP operator even if the emergency call initiated by actions 215 to 235 is successfully established.

[0052] The content of the emergency SMS message (sent at actions 245 and 250) can vary, depending on desired functionality, capabilities of the UE 105, type of emergency condition, and/or other factors. For example, if the UE 105 has access to information specific to the user of the UE 105, such as identification, address, health, age, and/or other information, the UE may include this information in the emergency

SMS message. (This information may be previously entered by the user specifically for this purpose and stored in the UE 105 and/or may be obtained through other usage of the UE 105.) Applicable data from health monitors and/or sensors such as pulse, blood pressure, heart rate, blood sugar, body temperature, etc., may be included, if available. Additionally or alternatively, location information can be provided, where available, to allow emergency services to locate the user (e.g. in cases where emergency services are dispatched to assist the user). Location information may include a current location of the UE 105, a recent previous location of the UE 105, a current velocity of the UE 105, a recent previous velocity of the UE 105, and/or indication of whether the UE 105 is currently stationary. In some embodiments, content included in the SMS message may be user definable and may be established in a setup procedure that may be performed, for example, when the UE 105 is being configured to enable emergency SMS messaging (e.g., when the UE 105 is used at an earlier time prior to the emergency condition).

[0053] In some embodiments, the emergency SMS message may include information regarding emergency call attempt history, which may help emergency responders further understand the urgency of an emergency situation. In some embodiments, the emergency SMS message may include an indication of the number of emergency call attempts made for the current emergency condition and/or recent previous emergency conditions and a time or period when the attempts took place. For example, the emergency SMS message may include timestamps or time deltas to show when previous emergency call attempts occurred. This may be limited to a certain number of attempts (e.g., the last 2 attempts) and/or a certain window of time (e.g., the last 24 hours). An indication of whether those previous attempts were successful (e.g., the call connected and/or the session successfully completed) may also be included, according to some embodiments.

[0054] In some embodiments, the ESMS message may include an emergency indication indicating that the ESMS message relates to an emergency situation. The emergency indication may distinguish the ESMS message from a normal (nonemergency) SMS message and may enable or assist routing of the ESMS message to a PSAP 180 rather than to some other destination. In some embodiments, the emergency indication may comprise a destination address for the ESMS message that corresponds to a dialed emergency number such as "911" in North America, "1 12" in Europe or "999" in the United Kingdom. The destination address in the ESMS message containing the emergency number may replace a normal destination address in the ESMS message such as a Mobile Station International Subscriber Directory Number (MSISDN) for a destination UE. In some embodiments, the emergency indication may comprise an association of the SMS message with (or a reference to) the IMS emergency call attempt at actions 230 and 235. For example, the association (or reference) may comprise: (i) the use of the same IP address by the UE 105 to send the ESMS message at action 245 as was obtained by the UE 105 for the emergency PDN connection established at action 220; (ii) the use of the emergency PDN connection obtained by the UE 105 at action 220 to send the ESMS message to the serving network 140 at action 245; or (iii) inclusion of an identification (e.g. an MSISDN or SIP public user ID) for UE 105 in a message (e.g. a SIP MESSAGE) used to transport the ESMS message to serving network 140 at action 245, wherein serving network 140 (e.g. a P-CSCF in serving network 140) has previously stored the identification and is aware that UE 105 instigated the IMS emergency call attempt at actions 230 and 235. When the ESMS message is received by serving network 140 from UE 105 at action 245, the emergency indication may indicate to serving network 140 that the ESMS message should not be routed to the home network 160 for UE 105 but should instead be routed to PSAP 180 by serving network 140 at action 250 by bypassing home network 160. [0055] In some embodiments or scenarios, the data to be included in the emergency SMS message may exceed size limits for a single SMS message. In such instances, data may be sent in multiple ESMS messages. Moreover, according to some embodiments, data may be prioritized such that higher-priority data is sent in earlier messages. This priority can be based on a variety of factors, such as the detected emergency condition, user preferences, and the like. For example, in a situation where the emergency condition detected at block 210 is a heart attack (based on health data), heart-related information (e.g., blood pressure, pulse, etc.) may be given a high priority.

[0056] Additionally or alternatively, according to some embodiments, the emergency SMS message may include a Uniform Resource Locator (URL) (or possibly a Uniform Resource Identifier (URI)) that enables the PSAP to access data regarding the user. The URL may, for example, indicate the location of a website, document, or other electronic file hosted on a server maintained by the home network 160, a third party, or another entity (even the PSAP 180 itself or another PSAP), accessible to the PSAP 180. Because there may be no size limits to the website, document, or other electronic file, it may include not only information that may be included in an emergency SMS message as described above, but additionally or alternatively, the website, document, or other electronic file may include information such as a picture, video, or other content that may not otherwise be included in an emergency SMS message. In some embodiments, a key, login and/or password may be included in the ESMS message along with the URL to enable a PSAP operator to access secure information for the user of the UE 105 that is only intended to be seen by authorized users such as PSAP 180.

[0057] In some embodiments, the ESMS message may be sent by UE 105 to serving network 140 at action 245 and serving network 140 may then forward the ESMS message to PSAP 180 at action 250 - e.g. based on an emergency indication in the ESMS message as described previously. In an embodiment, serving network 140 may forward the ESMS message to the same PSAP at action 250 as the PSAP to which the emergency call establishment attempt is sent at action 235. In another embodiment, serving network 140 may obtain a location estimate for UE 105 (e.g. based on a serving cell for UE 105 or positioning of UE 105 using a location solution such as the OMA SUPL solution or the 3 GPP control plane solution for LTE access) and may route the ESMS message at action 250 to a PSAP associated with this location estimate (e.g. a PSAP whose service area includes the location estimate for UE 105). In some embodiments, forwarding of the ESMS message to PSAP 180 by serving network 140 at action 250 may bypass the home network 160 for UE 105 which may result in ESMS message forwarding with lower delay and higher reliability.

[0058] Optionally, where the IMS Emergency Call Establishment of actions 230 and 235 are successful, the UE 105, the serving network 140 and PSAP 180 may engage in additional signaling (e.g. using the Session Initiation Protocol (SIP)) to establish a voice-dedicated bearer and complete the emergency call establishment at actions 255 and 260. The user of the UE 105 may then conduct a voice call with a responder at the PSAP 180 at action 265. It can be noted, however, that (again, due to network conditions and/or other factors) the emergency call may fail (e.g. may be released by the UE 105, serving network 140 or PSAP 180).

[0059] At block 270 and actions 275 and 280, the UE 105 may optionally detect a new trigger condition and send another emergency SMS message via the serving network 140 (e.g. repeating actions at block 240 and actions 245 and 250). This illustrates how embodiments may send additional emergency messages, depending on desired functionality. For example, detecting the new trigger condition may comprise detecting that the emergency call was dropped, that there was a change in the information sent in the first emergency SMS message (e.g., a change in UE 105 location, change in the emergency situation such as user health for a medical emergency, etc.), and the like. Additionally or alternatively, some embodiments may be configured to send emergency SMS messages periodically (e.g., every 10 seconds, 30 seconds, 60 seconds, etc.) during the emergency call and/or while the emergency condition is met.

[0060] It can be further noted that, in alternative embodiments, the detection of a trigger condition and subsequent sending of the emergency SMS message may be located at additional or alternative times or periods. In some embodiments, for example, the emergency SMS message may be sent at actions 245 and 250 as soon as possible after detecting the emergency condition (block 210). In some embodiments or scenarios, sending the emergency SMS message at actions 245 and 250 may be optional (e.g., only sent if the emergency call fails), whereas in other embodiments or scenarios the emergency SMS message may always be sent. Such variations can be made to accommodate different call flows, technologies, and/or desired functionality.

[0061] FIG. 3 is a simplified block diagram showing a communication system 300 that may be an example of the communication system 100 for the case that the serving network 140 supports LTE access for a UE 105. In this case, the serving network 140 may be referred to as an Evolved Packet System (EPS)). Communication system 300 includes a Legacy Emergency Services (ES) Network 345 attached to a Legacy PSAP 180-1, and a National Emergency Number Association (NENA) i3 Emergency Services IP network (ESInet) 355 attached to a NENA i3 capable PSAP 180-2. The serving network 140 may include an Evolved Node B (eNodeB, or eNB) 305 which may correspond to a base station 120, a Serving Gateway 315, a Packet Data Network (PDN) Gateway 320, a Mobility Management Entity (MME) 310, a Proxy Call Session Control Function (P-CSCF) 325, an Emergency Call Session Control Function (E-CSCF) 330, a Media Gateway Control Function (MGCF) 335, an Interconnection Border Control Function (IBCF) 340, a Serving Call Session Control Function (S-CSCF) 350, a Location Retrieval Function (LRF) 390, an IP Short Message Gateway (IP-SM-GW) 360, an SMS Gateway Mobile Switching Center (SMS-GMSC) 365 and an SMS Service Center (SMS SC) 370. In some embodiments, the MGCF 335 may be incorporated into or otherwise joined with a Media Gateway (MGW) (not shown in FIG. 3). The communication system 300 may comprise other components (some of which are shown in FIG. 3 but which are not discussed in this disclosure), and other embodiments may add, omit, join, separate, rearrange, or otherwise alter components depending on desired functionality. Such variations will be recognized by a person of ordinary skill in the art.

[0062] The eNB 305 may be a serving eNB for the UE 105 and may provide wireless communications access to the serving network 140 on behalf of UE 105. The MME 310 may be a serving MME for the UE 105 and may support mobility of UE 105 and provision of signaling access and voice bearer paths to UE 105. The serving gateway 315 and PDN gateway 320 may provide IP based signaling and IP transport support for UE 105 - e.g. with PDN gateway 320 assigning an IP address for UE 105 and providing IP access to other entities in serving network 140 such as P-CSCF 325.

[0063] Serving network 140 may include an IP Multimedia Subsystem (IMS) 380 that may include the P-CSCF 325, E-CSCF 330, MGCF 335, IBCF 340, S-CSCF 350 and LRF 390 IMS 380 may support an FMS emergency services call from UE 105 to a PSAP 180 such as i3 PSAP 180-2 or legacy PSAP 180-1. For example, in the case of an IMS emergency services call from UE 105 to i3 PSAP 180-2, a signaling path (not shown in FIG. 3) from UE 105 may pass through the e B 305, serving gateway 315, PDN gateway 320, P-CSCF 325, E-CSCF 330, IBCF 340, the i3 ESInet 355 and i3 PSAP 180-2. In the case of an IMS emergency services call from UE 105 to legacy PSAP 180-1, a signaling path (not shown in FIG. 3) from UE 105 may pass through the eNB 305, serving gateway 315, PDN gateway 320, P-CSCF 325, E-CSCF 330, a Breakout Gateway Control Function (BGCF), MGCF 335, the legacy ES Network 345 and legacy PSAP 180-1.

[0064] Elements in IMS 380 may provide call handling and call routing support to enable an FMS emergency services call from UE 105 to either i3 PSAP 180-2 or legacy PSAP 180-1. For example, P-CSCF 325 may detect an IMS emergency services call when instigated by UE 105 (e.g. by receiving, decoding and interpreting a SIP INVITE message sent by UE 105). E-CSCF 330 may support routing of an IMS emergency services call from UE 105 (e.g. by sending a SIP INVITE received from UE 105 via P- CSCF 325 towards either legacy PSAP 180-1 via MGCF 335 or i3 PSAP 180-2 via IBCF 340). LRF 390 may assist routing of an IMS emergency services call from UE 105 when queried by E-CSCF 330. For example, LRF 390 may determine a location for UE 105 (e.g. from information provided by UE 105 in a SIP INVITE) and may determine a PSAP (e.g. legacy PSAP 180-1 or i3 PSAP 180-2) that supports an emergency services call for that location and may return an identity or address for this PSAP to E-CSCF 330. MGCF 335 may perform conversion of SIP based signaling, received from or sent to UE 105, to or from signaling used by ES network 345 such as Integrated Services Digital Network (ISDN) User Part (ISUP) signaling in the case of an emergency services call to legacy PSAP 180-1. For example, MGCF 335 may convert an IMS emergency services call received from UE 105 into a Circuit Switched (CS) emergency services call in the case of an IMS emergency services call routed to legacy PSAP 180-1.

[0065] 13 ESInet 355 may support IP based emergency calls from UE 105 on behalf of i3 PSAP 180-2 - e.g. may route an IP based emergency services call from UE 105 to i3 PSAP 180-2. Legacy ES network 345 may similarly support Circuit Switched (CS) based emergency calls on behalf of legacy PSAP 180-1 received via MGCF 335 from UE 105 - e.g. may route a CS emergency services call from UE 105 received via MGCF 335 to legacy PSAP 180-1. An MGW connected to MGCF 335 (not shown in FIG. 3) may convert between a Voice over IP (VoIP) bit stream received from or sent to UE 105 and a CS based voice bit stream sent to or received from legacy PSAP 180-1 in the case of an emergency services call from UE 105 to legacy PSAP 180-1.

[0066] IP-SM-GW 360 may serve as gateway to route IP based SMS messages received from UE 105 to or towards SMS SC 370 and IP based SMS messages received from SMS SC 370 to or towards UE 105. Functions of the IP-SM-GW 360 can include (i) providing protocol interworking for transfer of an SMS message or ESMS message between UE 105 and SMS SC 370, (ii) determining the domain (e.g. CS, packet switched (PS) or IMS) for delivery of an SMS or ESMS message (e.g. to UE 105 or PSAP 180), (iii) connecting to the SMS-GMSC 365 using established Mobile

Application Part (MAP) or Diameter based protocols, (iv) appearing to (e.g. connecting to) the SMS-GMSC 365 as a Mobile Switching Center (MSC), Serving General Packet Radio Service (GPRS) Support Node (SGSN) or MME, (v) connecting to a Home Subscriber Server (HSS - not shown in FIG. 3) using established MAP or Diameter based protocols to obtain MSC/SGSN MME address(es) for SMS termination, and/or (vi) acting as an Application Server towards the IMS 380. [0067] SMS-GMSC 365, which may also function as (or be referred to as) an SMS Interworking MSC (SMS-IWMSC) may transfer SMS messages to and from SMS SC 370 and may serve as the access node in serving network 140 that provides access to SMS SC 370 using standardized protocols.

[0068] SMS SC 370 may provide a store and forward capability for SMS message transfer for serving network 140 by receiving SMS messages sent by UEs subscribed to serving network 140 and forwarding the SMS messages to their destinations such as other UEs or clients and servers access via a wireline network. In a conventional embodiment of communication system 300, when UE 105 is subscribed to serving network 140 (e.g. serving network 140 is the same as home network 160), an SMS message sent by UE 105 may be routed to SMS SC 370 via P-CSCF 325, S-CSCF 350, IP-SM-GW 360 and SMS-GMSC 365. For example, UE 105 may send the SMS message within a SIP MESSAGE to S-CSCF 350 via P-CSCF 325. S-CSCF 350 may forward the SIP MESSAGE to IP-SM-GW 360 which may extract the SMS message and forward the SMS message to SMS-GMSC 365. SMS-GMSC 365 may then forward the SMS message to SMS SC 370. SMS SC 370 may then forward the SMS message to a destination indicated by a destination address (e.g. an MSISDN) in the SMS message which may in some scenarios involve forwarding through similar or identical entities to those used to forward the SMS message to SMS SC 370 but in a reverse order (e.g. may involve forwarding through an SMS-GMSC, IP-SM_GW, S-CSCF, P-CSCF to a UE which may be associated with serving network 140 or with some other network).

However, in a conventional embodiment of communication system 300, when UE 105 is not subscribed to serving network 140 (e.g. serving network 140 is not the same as home network 160), an SMS message sent by UE 105 may be routed to an SMS SC in home network 160 and not to SMS SC 370 which may make routing an ESMS message to a PSAP 180 difficult or impossible.

[0069] FIG. 4 is a signaling flow diagram illustrating how an emergency SMS message can be communicated from the UE 105 to a PSAP 180 in conjunction with an emergency call for the communication system 300 described for FIG. 3. The signaling flow in FIG. 4 may be a particular example of the signaling flow in FIG. 2. In FIG. 4, the home network 160 is not illustrated, as it may be largely bypassed to establish both the emergency call and to send the emergency SMS message. Blocks and actions in FIG. 4 that may correspond to blocks and actions, respectively, in FIG. 2 are identified. For such blocks and actions, the description provided in FIG. 2 applies to FIG. 4, except as stated otherwise, and is thus not always repeated.

[0070] At block 410 in FIG. 4, the UE 105 detects an emergency condition. Block 410 may correspond to block 210 in FIG 2. Thus, for example, the detection may be made using sensor, location, and/or other information obtained by the UE 105. In response to detecting the emergency condition, UE 105 performs actions to initiate an emergency call. At action 415 which may correspond to action 215, the UE attaches to the serving network 140 (e.g., by sending an LTE Non Access Stratum (NAS) Attach Request message or a NAS Emergency Attach Request message to the serving MME 310) if the UE 105 is not already attached to serving network 140. The UE 105 and serving network 140 (e.g. serving eNB 305, MME 310, Serving Gateway 315 and PDN Gateway 320) then exchange signaling messages to establish an emergency packet data network (PDN) connection at action 420, which may correspond to action 220. As part of establishing the emergency PDN connection at action 420, the serving network 140 (e.g. the PDN Gateway 320) may assign and provide an IP address to UE 105. [0071] UE 105 then initiates and performs an IMS emergency registration at action 425, which may correspond to action 225, by performing a emergency registration with IMS 380 in the serving network 140 and with an IMS (not shown in FIG. 4) in the home network 160. For example, UE 105 may send a SIP REGISTER message to P-CSCF 325 (e.g. via eNB 305, Serving Gateway 315 and PDN Gateway 320) and P-CSCF 325 may forward the SIP REGISTER message to an S-CSCF (not shown in FIG. 3 or FIG. 4) in the home network 160, after which UE 105, P-CSCF 325 and the S-CSCF in home network 160 may exchange further SIP messages to complete the IMS emergency registration. The SIP REGISTER message sent by the UE 105 as part of action 425 may include (e.g. in a Contact header for the SIP REGISTER message) an IP address received by UE 105 from serving network 140 (e.g. from PDN Gateway 320) as part of emergency PDN connection establishment at action 420. The IP address may be stored by P-CSCF 325 as part of action 425.

[0072] At actions 430 and 435, which may correspond, respectively, to actions 230 and 235, the UE 105 can attempt to establish an IMS emergency call with the PSAP 180 via the serving network 140. For example, UE 105 may send a SIP INVITE message to

P-CSCF 325 at action 430 (e.g. via eNB 305, Serving Gateway 315 and PDN Gateway

320). The SIP TNVITE message may indicate an emergency call and may include (i) the serving cell identity (ID) for UE 105, (ii) an identification for UE 105 such as an

MSISDN, a SIP public user ID or an International Mobile Equipment Identity (IMEI), and/or (iii) the IP address received by the UE 105 from serving network 140 as part of emergency PDN connection establishment at action 420 and stored by P-CSCF 325 as part of IMS emergency registration at action 425. P-CSCF 425 may forward the SIP

INVITE message to E-CSCF 330 (not shown in FIG. 4) and E-CSCF 330 may request routing and/or location information for UE 105 from LRF 390 by forwarding the SIP INVITE to LRF 390 (not shown in FIG. 4). LRF 390 may use the serving cell ID (if present) in the SIP INVITE to determine a location estimate and/or routing information for UE 105 and may return these to E-CSCF 330 (not shown in FIG. 4). E-CSCF 330 may then forward the SIP INVITE towards either legacy PSAP 180-1 or i3 PSAP 180-2 based on the location information or routing information received from LRF 390. In the case of forwarding towards legacy PSAP 180-1, E-CSCF 330 may forward the SIP INVITE to MGCF 335 via a BGCF (not shown in FIG. 4) and MGCF 335 (not shown in FIG. 4) may interwork SIP signaling with ISUP signaling and forward the emergency call request indicated in the SIP INVITE as an ISUP Initial Address Message (IAM) to legacy ES network 345 at action 435. Legacy ES network 345 (not shown in FIG. 4) may then forward the emergency call request (e.g. the ISUP IAM) to legacy PSAP 180- 1.

[0073] In the case of forwarding the SIP INVITE received from UE 105 towards i3 PSAP 180-2, E-CSCF 330 may forward the SIP INVITE to IBCF 340 (not shown in FIG. 4) and IBCF 340 may forward the SIP INVITE to i3 ESInet 355 at action 435, with i3 ESInet 355 then forwarding the SIP INVITE to i3 PSAP 180-2. As described previously, it is possible that one of these forwarding actions may fail or may be delayed - e.g. due to lack of resources - in which case legacy PSAP 180-1 or i3 PSAP 180-2 may not receive the emergency call request (e.g. the ISUP IAM in the case of legacy PSAP 180-1 or the SIP INVITE in the case of i3 PSAP 180-2). Alternatively, legacy PSAP 180-1 or i3 PSAP 180-2 may receive the emergency call request but may delay answering the request (e.g. may queue the request) or may reject the request due to lack of resources (e.g., lack of telecommunication related resources or lack of a PSAP operator to answer the call). [0074] At block 440, which may correspond to block 240, UE 105 may detect a trigger condition, which can trigger the sending of an emergency SMS message from UE 105 to PSAP 180 at actions 445, 450 and 455. The trigger condition may be as described for block 240 in FIG. 2. The content of the emergency SMS message (sent at actions 445, 450 and 455) may be as described for actions 245 and 250 in FIG. 2. In addition (e.g. when the data to be included in the emergency SMS message exceeds size limits for a single SMS message), the data may be sent in multiple ESMS messages. Additionally or alternatively, as in the case of FIG. 2, the emergency SMS message may include a URL (or URI) that enables the PSAP to access data regarding the user.

Additionally, as described for actions 245 and 250 in FIG. 2, the ESMS message may include an emergency indication. For example, as for action 245 in FIG 2, the emergency indication may comprise a destination address for the ESMS message that corresponds to a dialed emergency number such as "911" in North America, "112" in Europe or "999" in the United Kingdom. The emergency indication may also or instead comprise an association with (or reference to) the IMS emergency call instigated by UE 105 at action 430.

[0075] In some embodiments, the ESMS message may be sent by UE 105 to serving network 140 at action 445, which may correspond to action 245 in FIG. 2. As an example, UE 105 may send the ESMS message to IMS 380 in serving network 140 by including the ESMS message in a SIP MESSAGE and sending the SIP MESSAGE to P-

CSCF 325 (not shown in FIG. 4) at action 445 (e.g. via eNB 305, Serving Gateway 315 and PDN Gateway 320). The UE 105 may associate the SIP MESSAGE with (or include a reference in the SIP MESSAGE to) the IMS emergency registration at action

425 and/or the SIP INVITE sent at action 430. The association (or reference) may comprise or serve as an emergency indication, as previously described for block 440, and may assist or enable the IMS 380 (e.g. the P-CSCF 325 and/or E-CSCF 330) to recognize the ESMS message as an emergency message. The association with (or reference to) the IMS emergency registration at action 425 and/or the SIP INVITE sent at action 430 may be indicated by UE 105 by including a SIP Contact header in the SIP MESSAGE sent at action 445. The SIP Contact header may comprise an IP address assigned to the UE 105 as part of emergency PDN connection establishment at action 420, included by UE 105 (e.g. in a SIP Contact header) for a SIP REGISTER message sent by UE 105 to P-CSCF 325 for action 425 and/or stored by P-CSCF 425 as part of action 425, as described previously. In some embodiments, as in FIG. 2, the emergency indication may comprise an association with (or reference to) the IMS emergency call attempt at actions 430 and 435. The association of the SIP MESSAGE sent at action 445 with (or the reference to) the IMS emergency registration at action 425 and/or the SIP INVITE sent at action 430 may also or instead comprise: (i) the use of the emergency PDN connection obtained by the UE 105 at action 420 to send the SIP MESSAGE to IMS 380 (e.g. P-CSCF 325) at action 445; or (ii) inclusion of an identification (e.g. an MSISDN or SIP public user ID) for UE 105 in the SIP MESSAGE (e.g. in a From header in the SIP MESSAGE) sent at action 445 to IMS 380 (e.g. to P-CSCF 325 in IMS 380).

[0076] An emergency indication in the SIP MESSAGE (or in the ESMS message) sent at action 445 or an association of the SIP MESSAGE with (or a reference in the SIP MESSAGE to) the IMS emergency registration at action 425 and/or the SIP INVITE sent at action 430 may enable P-CSCF 325 and/or E-CSCF 330 to recognize the ESMS message as being an emergency SMS message rather than a normal (nonemergency) SMS message. The recognition of the ESMS message as being an emergency SMS message may be used by P-CSCF 325 and/or E-CSCF 330 to transfer the ESMS message to a PSAP 180 via the serving network 140 rather than transferring the ESMS message to the home network 160 as for a normal (non-emergency) SMS message.

[0077] P-CSCF 325 may forward the SIP MESSAGE received at action 445 to E- CSCF 330 (not shown in FIG. 4). In one embodiment, P-CSCF 325 may forward the SIP MESSAGE based on recognizing the ESMS message contained in the SIP

MESSAGE as an emergency SMS message (e.g. based on an emergency indication in the ESMS message or an association of the SIP MESSAGE to the IMS Emergency Registration at action 425 or SIP INVITE at action 430). E-CSCF 330 may then forward the SIP MESSAGE to IP-SM-GW 360 (not shown in FIG. 4). In one embodiment, E- CSCF 330 may forward the SIP MESSAGE based on recognizing the ESMS message contained in the SIP MESSAGE as an emergency message (e.g. based on an emergency indication in the ESMS message or an association of the SIP MESSAGE to the SIP INVITE at action 430). IP-SM-GW 360 may extract the ESMS message from the SIP MESSAGE received from E-CSCF 330 and may forward the ESMS message to SMS- GMSC 365 (not shown in FIG. 4) which may forward the ESMS message to SMSC SC 370. Forwarding of the ESMS message from P-CSCF 325 to SMS SC 370 via E-CSCF 330, IP-SM-GW 360 and SMS-GMSC 365 as just described may correspond to action 450 in FIG. 4. SMS SC 370 may then forward the ESMS message to legacy PSAP 180- 1 or i3 PSAP 180-2 at action 455 (e.g. via legacy ES Network 345 or i3 ESInet 355, respectively), which may correspond to action 250 in FIG. 2.

[0078] As part of forwarding the ESMS message at action 450 in FIG. 4, E-CSCF 330 may determine routing information for the ESMS message. For example, after receiving the SIP MESSAGE containing the ESMS message from P-CSCF 325 as previously described for action 450, E-CSCF 330 may query LRF 390 for location information for UE 105 or routing information for the ESMS message (not shown in FIG. 4) and LRF 390 may return a location estimate for UE 105 and/or routing information for the ESMS message. The routing information may comprise the address of a PSAP 180 (e.g. a URL or URI). In another embodiment, E-CSCF 330 may have stored routing information (e.g. the address of a PSAP 180) that was obtained (e.g. from LRF 390) and used for initiating the establishment of the emergency call at actions 430 and 435 and may use the same routing information to route the ESMS message as part of action 450. In one embodiment, E-CSCF 330 may include the routing information (e.g., the address of a PSAP 180 or an address in the i3 ESInet 355 or legacy ES network 345) in the ESMS message as the destination address for the ESMS message. In this embodiment, the E-CSCF 330 may replace a destination address in the ESMS message that comprises a dialed emergency number with the routing information. SMS SC 370 may then forward the ESMS message to PSAP 180 at action 455 based on the destination address in the ESMS message, where the destination address may comprise an address for the PSAP 180 or an address in the i3 ESInet 355 or legacy ES network 345. In one embodiment, E-CSCF 330 may route the ESMS message to or towards the same PSAP 180 (e.g. the same legacy PSAP 180-1 or i3 PSAP 180-2) to which the emergency call establishment attempt at action 435 was sent.

[0079] Optionally, where the IMS Emergency Call request of actions 430 and 435 is successful, the UE 105, the IMS 380 (e.g. the P-CSCF 325 and E-CSCF 330) and PSAP

180 may engage in additional signaling (e.g. using SIP) to complete the establishment of the IMS emergency call including a voice-dedicated bearer at action 460, which may correspond to actions 255 and 260. The user of the UE 105 may then conduct a voice call with a responder at the PSAP 180 at action 465, which may correspond to action 265. It can be noted, however, that (again, due to network conditions and/or other factors) the emergency call may fail (e.g. may be released by the UE 105, IMS 380 or PSAP 180).

[0080] At block 470, the UE 105 may optionally detect a new trigger condition and send another emergency SMS message to the PSAP 180 via the EVIS 380 at actions 475, 480 and 485 which may be similar to or the same as actions 445, 450 and 455, respectively. Here, block 470 may correspond to block 270 in FIG. 2, actions 475 and 480 may correspond to action 275, and action 485 may correspond to action 280.

[0081] It can be further noted that, as for FIG. 2, in alternative embodiments, the detection of a trigger condition at block 470 and subsequent sending of the emergency SMS message at actions 475-485 may be located at additional or alternative times or periods. In some embodiments, for example, the emergency SMS message may be sent at actions 445, 450 and 455 as soon as possible after detecting the emergency condition (block 410). In some embodiments or scenarios sending the emergency SMS message at actions 445, 450 and 455 may be optional (e.g., if the emergency call fails), whereas in other embodiments or scenarios the emergency SMS message may always be sent. Such variations can be made to accommodate different call flows, technologies, and/or desired functionality.

[0082] FIG. 5 is a flow diagram illustrating a method 500 of initiating an emergency call at a UE, according to an embodiment. The method 500 may be employed and/or implemented by a UE (e.g., UE 105 of FIGS. 1 to 4). As with other figures provided herein, FIG. 5 is provided as a non-limiting example. Alternative embodiments may include additional functionality to that shown in the figure, and/or the functionality shown in one or more of the blocks in the figure may be omitted, combined, separated, and/or performed simultaneously. Means for performing the functionality of the blocks may include one or more hardware and/or software components, such as those described with regard to the UE 105 of FIG. 7, described herein below. A person of ordinary skill in the art will recognize many variations.

[0083] At block 510, an emergency condition is detected with the UE. As previously indicated, this may be done in a variety of ways. In some embodiments, the emergency condition may be detected by user input (e.g., the user dialing an emergency number).

[0084] In some embodiments, the emergency condition may comprise an automatically-detected emergency condition, and may be automatically detected by the UE at block 510, such as by sensor(s), and/or device(s) coupled to and/or in

communication with the UE. For instance, the UE, sensor(s), and/or device(s) may automatically detect an emergency health condition for the user, an accident involving the user, and/or an imminent danger for the user. This detection may be based on data from one or more sensors capable of detecting movement, position, orientation, temperature, sound, proximity, a visual image, health conditions (e.g. blood pressure, heart rate, breathing rate), and/or the like. These sensors may be incorporated into the UE itself (see, for example, sensor(s) 740 of the UE 105 illustrated in FIG. 7 and discussed more below) and/or incorporated into a device or system related to the UE, such as a vehicle or building security system (e.g., securing a vehicle or building owned, rented, and/or otherwise used by the user, or securing a vehicle or building in which the user is located), a wearable device worn by the user, a health monitoring system or device, etc. [0085] Means for performing the functionality at block 510 may include hardware and/or software components of a UE, such as a bus 705, processing unit(s) 710, DSP 720, wireless communication interface 730, wireless communication antenna(s) 732, sensor(s) 740, memory 760, input device(s) 770, SPS receiver 780, SPS antenna 782, and/or other components of the UE 105 illustrated in FIG. 7 and described in detail below.

[0086] The functionality at block 520 includes initiating, based on the emergency condition, the emergency call to a PSAP using a certain radio access type (RAT) such as LTE, WCDMA, 5G etc. Such initiation can include one or more of actions (e.g., actions 215, 220, 225, or 230 illustrated in FIG. 2 or actions 415, 420, 425, or 430 illustrated in FIG. 4) taken by the UE in communicating with a serving network (e.g. serving network 140) to initiate the emergency call. As previously mentioned, the UE may be configured to communication using a plurality of RATs, and the certain RAT may be a preferred RAT or an available RAT for making an emergency call. Other RATs may be used if the UE is unable to establish and/or complete an emergency call with the certain RAT. In some embodiments, the other RATs may be used, one at a time in an order of preference, until the UE is able to establish and/or complete an emergency call. Applicable standards and/or protocols may govern how this process is executed.

[0087] Means for performing the functionality at block 520 may include hardware and/or software components of a UE, such as a bus 705, processing unit(s) 710, wireless communication interface 730, wireless communication antenna(s) 732, memory 760, and/or other components of the UE 105 illustrated in FIG. 7 and described in detail below. [0088] At block 530, a trigger condition is detected. As previously indicated the trigger condition can comprise any of a variety of conditions, based on desired functionality. In some instances, the trigger condition can comprise the emergency condition itself. In this case, according to some embodiments, an emergency SMS message based on the detected trigger condition may be sent to the PSAP at block 540 prior to the initiation of the emergency call at block 520. In some instances, the trigger condition can additionally or alternatively comprise a failure to establish the emergency call using the certain radio access type, a delay in establishing the emergency call exceeding a certain threshold of time, an escalation or worsening of the emergency condition detected at block 510, and/or a quality of the certain RAT being below a certain threshold of quality.

[0089] Means for performing the functionality at block 530 may include hardware and/or software components of a UE, such as a bus 705, processing unit(s) 710, wireless communication interface 730, wireless communication antenna(s) 732, sensor(s) 740, memory 760, and/or other components of the UE 105 illustrated in FIG. 7 and described in detail below.

[0090] The functionality at block 540 comprises sending, based on the trigger condition, an emergency-related SMS message to the PSAP via a serving network different than a home network for the UE, wherein the sending bypasses the home network. In some embodiments, sending the emergency related SMS message to the PSAP may comprise sending the emergency related SMS message to an IP Multimedia Subsystem (EVIS) in the serving network using the Session Initiation Protocol (SIP). In some embodiments sending the emergency related SMS message to an IMS in the serving network may comprise sending the emergency related SMS message to a Proxy Call Session Control Function (P-CSCF) (e.g. P-CSCF 325) in the IMS and/or sending a SIP MESSAGE containing the emergency related SMS message to the IMS. In some embodiments, the UE may include an emergency indication in the emergency related SMS message which may enable the serving network (e.g. the IMS in the serving network such as a P-CSCF or E-CSCF in the IMS) to determine that the emergency related SMS message is for an emergency condition. In some embodiments, the emergency indication may comprise a destination address for the emergency related SMS message that corresponds to a dialed emergency number. In some embodiments, the emergency indication may comprise an association with, or a reference to, the emergency call initiated at block 520. For example, the association or reference may comprise: (i) use of the same IP address for the UE to send the emergency related SMS message at block 540 as was used to initiate the emergency call at block 520; (ii) use of the same emergency packet data network (PDN) connection to send the emergency related SMS message at block 540 as was used to initiate the emergency call at block 540; and/or (iii) inclusion of the same identification for the UE in a message (e.g. a SIP MESSAGE) used to transport the emergency related SMS message sent at block 540 as was used to identify the UE for the emergency call initiated at block 520. In some embodiments, block 540 may correspond to action 245 in FIG. 2 and/or to action 445 in FIG. 4.

[0091] As discussed above, the emergency -related SMS can include any of a variety of types of information that may be useful to the PSAP in providing emergency services to the user. For instance, the emergency-related SMS message may comprise a location of the UE, personal information of the user, and/or information regarding the emergency condition. In some embodiments, the location of the UE may be an estimated location obtained by the UE using any of the location estimation techniques described herein (e.g., involving GPS and/or other SPS or GNSS SVs, terrestrial transceivers, motion sensor(s), location server(s), and the like). In some embodiments, the location may be entered manually by the user. In some embodiments, the personal information of the user may be identification, age, health-related, and/or other information regarding the user, which may be entered by the user and/or stored by the UE. In some embodiments, the information regarding the emergency condition may be based on the detected emergency condition. If, for example, the UE received data from one or more sensor(s) of a vehicle in which the user was traveling that indicated the vehicle was in an accident, the information regarding the emergency condition could indicate that the emergency condition is a traffic accident and/or include information regarding the severity of the traffic accident, if available. Similarly, if the UE received data from one or more sensor(s) associated with (e.g. attached) to a user of the UE, the information regarding the emergency condition could indicate a medical condition for the user (e.g. irregular heart rate, high or low blood pressure, high or low blood sugar level, etc.). As described above, in some embodiments, the emergency-related SMS message can comprise a URL (or URI) that enables the PSAP to access data regarding the user.

[0092] As previously noted, some embodiments may provide for sending one or more additional emergency-related SMS messages. For example, according to some embodiments, the method 500 may additionally or alternatively include sending an updated emergency-related SMS message to the PSAP based on a subsequently- detected change in a location of the UE, change in information regarding the user, and/or change in information regarding the emergency condition. The updated emergency-related SMS message may correspondingly include the updated information regarding the location, user, and/or emergency condition. As previously noted, such updated emergency-related SMS messages can be sent based on triggering events, such as, a change in location beyond a threshold distance, a detected change in urgency and/or type of emergency condition, a change in health-related data of the user, and the like.

[0093] Means for performing the functionality at block 540 may include hardware and/or software components of a UE, such as a bus 705, processing unit(s) 710, DSP 720, wireless communication interface 730, wireless communication antenna(s) 732, sensor(s) 740, memory 760, input device(s) 770, SPS receiver 780, SPS antenna 782, and/or other components of the UE 105 illustrated in FIG. 7 and described in detail below.

[0094] FIG. 6 is a flow diagram illustrating a method 600 of routing an emergency- related SMS message received from a UE (e.g. UE 105), according to an embodiment. The method 600 may be employed and/or implemented by a network element of a serving network for the UE (e.g., a network element may compose part of the serving network 140 of FIG. 1). The serving network may be different than a home network for the UE. The network element may be a network element in an IMS for the serving network (e.g. IMS 380) and may be a P-CSCF (e.g. P-CSCF 325) or an E-CSCF (e.g. E- CSCF 330). Moreover, the method 600 may be implemented by a network element of a serving network in conjunction with the UE performing the method 500 of FIG. 5. Alternative embodiments may also employ other techniques for routing emergency- related SMS messages.

[0095] As with other figures provided herein, FIG. 6 is provided as a non-limiting example. Alternative embodiments may include additional functionality to that shown in the figure, and/or the functionality shown in one or more of the blocks in the figure may be omitted, combined, separated, and/or performed simultaneously. A network element configured to performing the functionality of one or more of the blocks of the method 600 may comprise a computer system, such as a computer server. Accordingly, means for performing the functionality of one or more of the blocks of the method 600 may include one or more hardware and/or software components of a computer system as illustrated in FIG. 8 and described in more detail below. A person of ordinary skill in the art will recognize many variations.

[0096] At block 610, a request for an emergency call is received from the UE. The request may include receiving a request for a network attachment for an emergency call from the UE (e.g. as at action 215 and/or 415), receiving a request for an emergency PDN connection from the UE (e.g. as at action 220 and/or 420), receiving a request for an EVIS emergency registration (e.g. a SIP REGISTER message) from the UE (e.g. as at action 225 and/or 425) and/or receiving a request for an IMS emergency call (e.g. a SIP INVITE message) from the UE (e.g. as at action 230 and/or 430). In some

embodiments, the network element may route the request for the emergency call to or towards a PSAP (e.g. PSAP 180) (e.g. as at action 235 and/or action 435). Means for performing the functionality at block 610 may include hardware and/or software components of a computer system, such as a bus 805, processing unit(s) 810, communications subsystem 830, working memory 835, operating system 840, application(s) 845, and/or other components of the computer system 800 illustrated in FIG. 8 and described in detail below.

[0097] At block 620, an SMS message from the UE is received at the network element, where the SMS message comprises an emergency indication. As previously indicated, according to some embodiments, the receipt of the SMS message may be in conjunction with an attempt to establish the emergency call at block 610. Block 620 may correspond to action 245, action 445 and/or action 450. Means for performing the functionality at block 620 may include hardware and/or software components of a computer system, such as a bus 805, processing unit(s) 810, communications subsystem 830, working memory 835, operating system 840, application(s) 845, and/or other components of the computer system 800 illustrated in FIG. 8 and described in detail below.

[0098] In some embodiments, the emergency indication at block 620 comprises a destination address for the SMS message that comprises an emergency number (e.g. "91 1" in North America or " 1 12" in Europe). In some embodiments, the emergency indication at block 620 comprises an association with, or a reference to, the emergency call of block 610. This association may be determined by the network element from the SMS message. In some embodiments, the association with, or reference to, the emergency call comprises use of the same IP address for the UE as for the emergency call, use of the same emergency PDN connection for the UE as for the emergency call, use of the same identification for the UE as for the emergency call, or some combination thereof. For example, the network entity (e.g. a P-CSCF) may determine use of the same emergency PDN connection for the UE by determining if the SMS message is received through an emergency PDN connection for the UE that was previously established to support the emergency call received at block 610. In some embodiments, the SMS message is received at block 620 in a SIP MESSAGE. In some embodiments, the association with, or the reference to, the emergency call comprises a first IP address for the UE in a SIP Contact header for a SIP REGISTER message or SIP TNVITE message received at block 610 and a second IP address for the UE in a SIP Contact header for a SIP MESSAGE received at block 620, where the first IP address is the same as the second IP address.

[0099] The functionality at block 630 includes determining by the network element a destination address for the SMS message based on the emergency indication. In one embodiment, the destination address may be the address of another network element in the serving network that is closer to or better able to route the SMS message to a PSAP. For example, when the network element is a P-CSCF (e.g. P-CSCF 325), the other network element may be an E-CSCF (e.g. E-CSCF 330), as described for action 450 in FIG. 4. In another embodiment, the destination address may be an address of a PSAP (e.g. PSAP 180, legacy PSAP 180-1 or i3 PSAP 180-2) or an address in a legacy ES network (e.g. legacy ES network 345) or an address in an i3 ESInet (e.g. i3 ESInet 355). In some embodiments, for example when the network entity is an E-CSCF (e.g. E- CSCF 330), the network entity may obtain a location for the UE (e.g. from another network entity in the serving network such as LRF 390) and may determine the destination address based on the location. In some embodiments, the network entity (e.g. an E-CSCF such as E-CSCF 330) may determine the destination address based on a destination address determined for the emergency call received at block 610. For example, the network entity may determine the same destination address for the SMS message as the destination address determined for the emergency call received at block 610.

[0100] Means for performing the functionality at block 630 may include hardware and/or software components of a computer system, such as a bus 805, processing unit(s) 810, input device(s) 815, communications subsystem 830, working memory 835, operating system 840, application(s) 845, and/or other components of the computer system 800 illustrated in FIG. 8 and described in detail below.

[0101] The functionality at block 640 comprises routing the SMS message to or towards a PSAP (e.g. a PSAP 180), based on the destination address, wherein the routing bypasses the home network. As previously indicated, this can avoid additional steps that may delay the routing of the SMS message or fail to transfer the SMS messafge to a PSAP or to the correct PSAP. Block 640 may correspond to action 250 in FIG. 2 and/or to action 450 and/or action 455 in FIG. 4.

[0102] The method 600 may further include sending an updated SMS message to the PSAP. For example, the updated SMS message may be received from the UE based on a subsequently detected change in a location of the UE, a change in information regarding the user of the UE, or change in information regarding the emergency condition, or any combination thereof. However, in an embodiment, the updated SMS may be generated by the network element - e.g. based on a failure to successfully establish the emergency call requested at block 610. In this embodiment, the SMS generation may be based on information provided to the network element by the UE and/or other devices (e.g., a location server) regarding the location of the UE, information regarding the user, and/or information regarding the emergency condition.

[0103] Means for performing the functionality at block 640 may include hardware and/or software components of a computer system, such as a bus 805, processing unit(s) 810, input device(s) 815, communications subsystem 830, working memory 835, operating system 840, application(s) 845, and/or other components of the computer system 800 illustrated in FIG. 8 and described in detail below. [0104] FIG. 7 illustrates an embodiment of a UE 105, which can be utilized as described herein above. For example, the UE 105 can be used in the communication system 100 and/or communication system 300 for initiating an emergency call, which may comprise performing one or more of the UE functions described for FIGS. 2, 4 and 5. It should be noted that FIG. 7 is meant only to provide a generalized illustration of various components, any or all of which may be utilized as appropriate. It can be noted that, in some instances, components illustrated by FIG. 7 can be localized to a single physical device and/or distributed among various networked devices, which may be disposed at different physical locations (e.g., located at different parts of a user' s body, in which case the components may be communicatively connected via a Personal Area Network (PAN) and/or other means).

[0105] The UE 105 is shown comprising hardware elements that can be electrically coupled via a bus 705 (or may otherwise be in communication, as appropriate). The hardware elements may include a processing unit(s) 710 which can include without limitation one or more general-purpose processors, one or more special-purpose processors (such as digital signal processing (DSP) chips, graphics acceleration processors, application specific integrated circuits (ASICs), and/or the like), and/or other processing structure or means. As shown in FIG. 7, some embodiments may have a separate DSP 720, depending on desired functionality. Location determination and/or other determinations based on wireless communication may be provided in the processing unit(s) 710 and/or wireless communication interface 730 (discussed below).

The UE 105 also can include one or more input devices 770, which can include without limitation a touch screen, a touch pad, microphone, button(s), dial(s), switch(es), and/or the like; and one or more output devices 715, which can include without limitation a display, light emitting diode (LED), speakers, and/or the like. [0106] The UE 105 may also include a wireless communication interface 730, which can include without limitation a modem, a network card, an infrared

communication device, a wireless communication device, and/or a chipset (such as a Bluetooth device, an IEEE 802.1 1 device, an IEEE 802.15.4 device, a WiFi device, a WiMax device, cellular communication facilities, etc.), and/or the like. The wireless communication interface 730 may permit data to be exchanged with a network, wireless access points, base stations, other computer systems, and/or any other electronic devices described herein. The communication can be carried out via one or more wireless communication antenna(s) 732 that send and/or receive wireless signals 734.

[0107] Depending on desired functionality, the wireless communication interface

730 can include separate transceivers to communicate with one or more wireless networks using various RATs. The one or more wireless networks can include various network types (e.g. associated with different RATs) such as a CDMA network, a Time

Division Multiple Access (TDMA) network, a Frequency Division Multiple Access

(FDMA) network, an Orthogonal Frequency Division Multiple Access (OFDMA) network, a Single-Carrier Frequency Division Multiple Access (SC-FDMA) network, a

WiMax network (IEEE 802.16), a Wireless Local Area Network (WLAN), and so on.

A CDMA network may implement one or more radio access technologies (RATs) such as cdma2000, Wideband CDMA (WCDMA), and so on. Cdma2000 includes IS-95, IS-

2000, and/or IS-856 standards. A TDMA network may implement Global System for

Mobile Communications (GSM), Digital Advanced Mobile Phone System (D-AMPS), or some other RAT. An OFDMA network may employ LTE, LTE Advanced, and so on. LTE, LTE Advanced, GSM, and WCDMA are described in documents from 3GPP.

Cdma2000 is described in documents from a consortium named "3rd Generation

Partnership Project 2" (3GPP2). 3 GPP and 3GPP2 documents are publicly available. A WLAN may be an IEEE 802.1 lx network (also referred to as WiFi network), a

Bluetooth network, an IEEE 802.15x network, or some other type of network. The techniques described herein may also be used for any combination of two or more wireless networks or for wireless networks combined with wireline networks.

[0108] The UE 105 can further include sensor(s) 740. Such sensors can include, without limitation, one or more accelerometer(s), gyroscope(s), camera(s),

magnetometer(s), altimeter(s), barometer(s), compass(es), microphone(s), proximity sensor(s), light sensor(s), blood pressure monitors, heart rate monitors, blood sugar level monitors, and the like. Some or all of the sensor(s) 740 can be utilized, among other things, to determine a location and/or sense an emergency condition that may be used to initiate an emergency call and/or emergency SMS message in accordance with the techniques described herein. Some or all of sensor(s) 740 may be attached to, connected to or embedded in a user of UE 105 and may communicate with other components of UE 105 (e.g. wireless communication interface 730) by wireless or wireline means (e.g. using BT or Zigbee).

[0109] Embodiments of the UE 105 may also include an SPS receiver 780 capable of receiving and measuring signals 784 from one or more SPS satellites (e.g., SVs 1 10 of FIG. 1) using an SPS antenna 782 (e.g. which may or may not be the same as wireless communication antenna(s) 732). SPS receiver 780 may provide SPS location measurements to a location server (e.g. an E-SLP or E-SMLC in serving network 140) to enable a position of the UE 105 to be obtained by the location server or may enable UE 105 (e.g. processing units 710) to obtain the UE 105 location. Location of UE 105 may assist the techniques described herein and may use conventional location techniques associated with signal measurements for an SPS system or GNSS such as the GPS, Galileo, Glonass, Quasi-Zenith Satellite System (QZSS) over Japan, Indian Regional Navigational Satellite System (IRNSS) over India, Beidou over China, and/or the like. Moreover, the SPS receiver 780 may receive signals from various

augmentation systems (e.g., a Satellite Based Augmentation System (SBAS)), such as Wide Area Augmentation System (WAAS), European Geostationary Navigation Overlay Service (EGNOS), Multi -functional Satellite Augmentation System (MS AS), GPS Aided Geo Augmented Navigation or GPS and Geo Augmented Navigation system (GAGAN), and/or the like. The SPS receiver 780 may be configured to determine or help determine a location (e.g. latitude and longitude coordinates, and optionally an altitude) for the UE 105, based on measuring SPS signals 784, either by itself or in combination with other elements of the UE 105 such as processing unit(s) 710. The location may be determined periodically (e.g. at 1 or 2 second intervals) and may be included within the emergency SMS sent to a PSAP.

[0110] The UE 105 may further include and/or be in communication with a memory 760. The memory 760 can include, without limitation, local and/or network accessible storage, a disk drive, a drive array, an optical storage device, a solid-state storage device, such as a random access memory ("RAM"), and/or a read-only memory ("ROM"), which can be programmable, flash-updateable, and/or the like. Such storage devices may be configured to implement any appropriate data stores, including without limitation, various file systems, database structures, and/or the like.

[0111] The memory 760 of the UE 105 also can comprise software elements (not shown in FIG. 7), including an operating system, device drivers, executable libraries, and/or other code, such as one or more application programs, which may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more procedures described with respect to the method(s) discussed above may be implemented as code and/or instructions executable by the UE 105 (and/or a processing unit(s) 710 or DSP 720 within UE 105). In an aspect, then, such code and/or instructions can be used to configure and/or adapt a general purpose computer (or other device) to perform one or more operations in accordance with the described methods.

[0112] FIG. 8 illustrates an embodiment of a computer system 800, which may be utilized and/or incorporated into one or more components of a communication system (e.g., communication system 100 of FIG. 1 and/or communication system 300 of FIG. 3) capable of routing an emergency SMS message according to the techniques described herein (and/or components of a similar system configured to implement the techniques disclosed above). FIG 8 provides a schematic illustration of one embodiment of a computer system 800 that can perform the methods provided by various other embodiments, such as the method described in relation to FIGS. 2, 4 and/or 6. It should be noted that FIG. 8 is meant only to provide a generalized illustration of various components, any or all of which may be utilized as appropriate. FIG. 8, therefore, broadly illustrates how individual system elements may be implemented in a relatively separated or relatively more integrated manner. In addition, it can be noted that components illustrated by FIG. 8 can be localized to a single device and/or distributed among various networked devices, which may be disposed at different physical or geographical locations. The computer system 800 may correspond to any of P-CSCF 325, E-CSCF 330, IP-SM-GW 360, SMS-GMSC 365, SMS SC 370 or LRF 390 in communication system 300. [0113] The computer system 800 is shown comprising hardware elements that can be electrically coupled via a bus 805 (or may otherwise be in communication, as appropriate). The hardware elements may include processing unit(s) 810, which can include without limitation one or more general-purpose processors, one or more special- purpose processors (such as digital signal processing chips, graphics acceleration processors, and/or the like), and/or other processing structure, which can be configured to perform one or more of the methods described herein, including the method described in relation to FIG. 6. The computer system 800 also can include one or more input devices 815, which can include without limitation a mouse, a keyboard, a camera, a microphone, other biometric sensors, and/or the like; and one or more output devices 820, which can include without limitation a display device, a printer, and/or the like.

[0114] The computer system 800 may further include (and/or be in communication with) one or more non-transitory storage devices 825, which can comprise, without limitation, local and/or network accessible storage, and/or can include, without limitation, a disk drive, a drive array, an optical storage device, a solid-state storage device, such as a random access memory ("RAM"), and/or a read-only memory ("ROM"), which can be programmable, flash-updateable, and/or the like. Such storage devices may be configured to implement any appropriate data stores, including without limitation, various file systems, database structures, and/or the like.

[0115] The computer system 800 may also include a communications subsystem 830, which can include support of wireline communication technologies and/or wireless communication technologies managed and controlled by a wireless communication interface 833. The communications subsystem 830 may include a modem, a network card (wireless or wired), an infrared communication device, a wireless communication device, and/or a chipset, and/or the like. The communications subsystem 830 may include one or more input and/or output communication interfaces, such as the wireless communication interface 833, to permit data to be exchanged with a network, mobile devices, other computer systems, and/or any other electronic devices described herein. Note that the terms "mobile device" and "UE" are used interchangeably herein to refer to any mobile communications device such as, but not limited to, mobile phones, smartphones, wearable devices, mobile computing devices (e.g., laptops, PDAs, tablets), embedded modems, and automotive and other vehicular computing devices.

[0116] In many embodiments, the computer system 800 will further comprise a working memory 835, which can include a RAM and/or or ROM device. Software elements, shown as being located within the working memory 835, can include an operating system 840, device drivers, executable libraries, and/or other code, such as application(s) 845, which may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more procedures described with respect to the method(s) discussed above, such as the method described in relation to FIG. 6, may be implemented as code and/or instructions executable by a computer (and/or a processing unit within a computer); in an aspect, then, such code and/or instructions can be used to configure and/or adapt a general purpose computer (or other device) to perform one or more operations in accordance with the described methods.

[0117] A set of these instructions and/or code might be stored on a non-transitory computer-readable storage medium, such as the storage device(s) 825 described above. In some cases, the storage medium might be incorporated within a computer system, such as computer system 800. In other embodiments, the storage medium might be separate from a computer system (e.g., a removable medium, such as an optical disc), and/or provided in an installation package, such that the storage medium can be used to program, configure, and/or adapt a general purpose computer with the instructions/code stored thereon. These instructions might take the form of executable code, which is executable by the computer system 800 and/or might take the form of source and/or installable code, which, upon compilation and/or installation on the computer system 800 (e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.), then takes the form of executable code.

[0118] It will be apparent to those skilled in the art that substantial variations may be made in accordance with specific requirements. For example, customized hardware might also be used, and/or particular elements might be implemented in hardware, software (including portable software, such as applets, etc.), or both. Further, connection to other computing devices such as network input/output devices may be employed.

[0119] With reference to the appended figures, components that can include memory can include non-transitory machine-readable media. The term "machine- readable medium" and "computer-readable medium" as used herein, refer to any storage medium that participates in providing data that causes a machine to operate in a specific fashion. In embodiments provided hereinabove, various machine-readable media might be involved in providing instructions/code to processing units and/or other device(s) for execution. Additionally or alternatively, the machine-readable media might be used to store and/or carry such instructions/code. In many implementations, a computer- readable medium is a physical and/or tangible storage medium. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Common forms of computer-readable media include, for example, magnetic and/or optical media, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read instructions and/or code.

[0120] The methods, systems, and devices discussed herein are examples. Various embodiments may omit, substitute, or add various procedures or components as appropriate. For instance, features described with respect to certain embodiments may be combined in various other embodiments. Different aspects and elements of the embodiments may be combined in a similar manner. The various components of the figures provided herein can be embodied in hardware and/or software. Also, technology evolves and, thus, many of the elements are examples that do not limit the scope of the disclosure to those specific examples.

[0121] It has proven convenient at times, principally for reasons of common usage, to refer to such signals as bits, information, values, elements, symbols, characters, variables, terms, numbers, numerals, or the like. It should be understood, however, that all of these or similar terms are to be associated with appropriate physical quantities and are merely convenient labels. Unless specifically stated otherwise, as is apparent from the discussion above, it is appreciated that throughout this Specification discussions utilizing terms such as "processing," "computing," "calculating," "determining," "ascertaining," "identifying," "associating," "measuring," "performing," or the like refer to actions or processes of a specific apparatus, such as a special purpose computer or a similar special purpose electronic computing device. In the context of this Specification, therefore, a special purpose computer or a similar special purpose electronic computing device is capable of manipulating or transforming signals, typically represented as physical electronic, electrical, or magnetic quantities within memories, registers, or other information storage devices, transmission devices, or display devices of the special purpose computer or similar special purpose electronic computing device.

[0122] Terms, "and" and "or" as used herein, may include a variety of meanings that also is expected to depend at least in part upon the context in which such terms are used. Typically, "or" if used to associate a list, such as A, B, or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B, or C, here used in the exclusive sense. In addition, the term "one or more" as used herein may be used to describe any feature, structure, or characteristic in the singular or may be used to describe some combination of features, structures, or characteristics. However, it should be noted that this is merely an illustrative example and claimed subject matter is not limited to this example. Furthermore, the term "at least one of if used to associate a list, such as A, B, or C, can be interpreted to mean any combination of A, B, and/or C, such as A, AB, AA, AAB, AABBCCC, etc.

[0123] Having described several embodiments, various modifications, alternative constructions, and equivalents may be used without departing from the spirit of the disclosure. For example, the above elements may merely be a component of a larger system, wherein other rules may take precedence over or otherwise modify the application of the various embodiments. Also, a number of steps may be undertaken before, during, or after the above elements are considered. Accordingly, the above description does not limit the scope of the disclosure.

Claims

CLAIMS What is claimed is:

1. A method of initiating an emergency call at a user equipment (UE) on a behalf of a user comprising:

detecting, with the UE, an emergency condition;

initiating, based on the emergency condition, the emergency call to a public safety answering point (PSAP) using a certain radio access type;

detecting a trigger condition; and

sending, based on the trigger condition, an emergency -related short message service (SMS) message to the PSAP via a serving network different than a home network of the UE, wherein the sending bypasses the home network.

2. The method of claim 1, wherein the emergency condition comprises an automatically-detected emergency condition.

3. The method of claim 2, wherein the automatically-detected emergency condition comprises a medical condition of the user, an indication of an accident involving the user, or an indication of an imminent danger to the user, or any combination thereof.

4. The method of claim 1, wherein the trigger condition further comprises the emergency condition, a failure to establish the emergency call using the certain radio access type, a delay in establishing the emergency call exceeding a certain threshold of time, or a quality of the certain radio access type being below a certain threshold of quality, or any combination thereof.

5. The method of claim 1, wherein the emergency-related SMS message comprises an emergency indication, a location of the UE, information regarding the user, or information regarding the emergency condition, or any combination thereof.

6. The method of claim 1, wherein the emergency-related SMS message comprises a uniform resource locator (URL) that enables the PSAP to access data regarding the user.

7. The method of claim 1, wherein sending the emergency-related SMS message to the PSAP further comprises sending the emergency-related SMS message to an IP Multimedia Subsystem (IMS) in the serving network using a session initiation protocol (SIP).

8. The method of claim 1, further comprising:

sending an updated emergency-related SMS message to the PSAP based on a subsequently detected change in a location of the UE, change in information regarding the user, or change in information regarding the emergency condition, or any combination thereof.

9. A user equipment (UE) comprising:

a wireless communication interface;

a memory; and

a processing unit communicatively coupled with the wireless communication interface and the memory, and configured to cause the UE to:

detect an emergency condition;

initiate, based on the emergency condition, an emergency call to a public safety answering point (PSAP) using a certain radio access type;

detect a trigger condition; and

send, based on the trigger condition, an emergency-related short message service (SMS) message to the PSAP, wherein the emergency-related SMS message is sent, using the wireless communication interface, via a serving network different than a home network of the UE, bypassing the home network of the UE.

10. The UE of claim 9, further comprising one or more sensors, wherein the processing unit is configured to cause the UE to detect the emergency condition using data from the one or more sensors.

11. The UE of claim 10, wherein the one or more sensors are configured to detect a medical condition of a user, an indication of an accident involving the user, or an indication of an imminent danger to the user, or any combination thereof.

12. The UE of claim 9, wherein the processing unit is configured to cause the UE to detect the trigger condition by detecting the emergency condition, a failure to establish the emergency call using the certain radio access type, a delay in establishing the emergency call exceeding a certain threshold of time, or a quality of the certain radio access type being below a certain threshold of quality, or any combination thereof.

13. The UE of claim 9, wherein the processing unit is configured to cause the UE to include, in the emergency-related SMS message, an emergency indication, a location of the UE, information regarding a user, or information regarding the emergency condition, or any combination thereof.

14. The UE of claim 9, wherein the processing unit is configured to cause the UE to include, in the emergency-related SMS message, a uniform resource locator (URL) that enables the PSAP to access data regarding a user.

15. The UE of claim 9, wherein the processing unit is configured to cause the UE to send the emergency-related SMS message to an IP Multimedia Subsystem (IMS) in the serving network using a session initiation protocol (SIP).

16. The UE of claim 9, wherein the processing unit is further configured to cause the UE to:

send an updated emergency-related SMS message to the PSAP based on a subsequently detected change in a location of the UE, change in information regarding a user, or change in information regarding the emergency condition, or any combination thereof.

17. A user equipment (UE) comprising:

means for detecting, with the UE, an emergency condition; means for initiating, based on the emergency condition, an emergency call to a public safety answering point (PSAP) using a certain radio access type;

means for detecting a trigger condition; and

means for sending, based on the trigger condition, an emergency-related short message service (SMS) message to the PSAP via a serving network different than a home network of the UE, wherein the sending bypasses the home network.

18. The UE of claim 17, wherein the means for detecting the emergency condition comprise means for automatically detecting the emergency condition.

19. The UE of claim 18, wherein the means for automatically detecting the emergency condition comprise means for detecting a medical condition of a user, an indication of an accident involving the user, or an indication of an imminent danger to the user, or any combination thereof.

20. The UE of claim 17, wherein the means for detecting the trigger condition further comprise means for detecting the emergency condition, a failure to establish the emergency call using the certain radio access type, a delay in establishing the emergency call exceeding a certain threshold of time, or a quality of the certain radio access type being below a certain threshold of quality, or any combination thereof.

21. The UE of claim 17, wherein the means for sending the emergency-related SMS message comprise means for including, in the emergency- related SMS message, an emergency indication, a location of the UE, information regarding a user, or information regarding the emergency condition, or any combination thereof.

22. The UE of claim 17, wherein the means for sending the emergency-related SMS message comprise means for including, in the emergency- related SMS message, a uniform resource locator (URL) that enables the PSAP to access data regarding a user.

23. The UE of claim 17, wherein the means for sending the emergency-related SMS message to the PSAP further comprise means for sending the emergency-related SMS message to an IP Multimedia Subsystem (IMS) in the serving network using a session initiation protocol (SIP).

24. The UE of claim 17, further comprising:

means for sending an updated emergency-related SMS message to the PSAP based on a subsequently detected change in a location of the UE, change in information regarding a user, or change in information regarding the emergency condition, or any combination thereof.

25. A non-transitory computer-readable medium having instructions embedded thereon for initiating an emergency call at a user equipment (UE) on behalf of a user, the instructions including computer code for:

detecting an emergency condition;

detecting a trigger condition; and

26. The non-transitory computer-readable medium of claim 25, wherein the computer code for detecting the emergency condition comprises computer code for automatically detecting the emergency condition.

27. The non-transitory computer-readable medium of claim 26, wherein the computer code for automatically detecting the emergency condition comprises computer code for detecting a medical condition of the user, an indication of an accident involving the user, or an indication of an imminent danger to the user, or any combination thereof.

28. The non-transitory computer-readable medium of claim 25, wherein the computer code for detecting the trigger condition further comprises computer code for detecting the emergency condition, a failure to establish the emergency call using the certain radio access type, a delay in establishing the emergency call exceeding a certain threshold of time, or a quality of the certain radio access type being below a certain threshold of quality, or any combination thereof

29. The non-transitory computer-readable medium of claim 25, wherein the computer code for sending the emergency-related SMS message comprises computer code for including, in the emergency-related SMS message, an emergency indication, a location of the UE, information regarding the user, or information regarding the emergency condition, or any combination thereof.

30. The non-transitory computer-readable medium of claim 25, wherein the computer code for sending the emergency-related SMS message comprises computer code for including, in the emergency-related SMS message, a uniform resource locator (URL) that enables the PSAP to access data regarding the user.