Patent Application
20180054721
Recently, cellular-capable end user (CCEU) devices and network/telephony infrastructure have evolved to allow CCEU devices to make cellular calls using either their cellular interfaces and protocols or using their data (non-cellular) interfaces and protocols, namely IP-based (Internet Protocol based) protocols. IP-based calling functionality in devices without a UICC/SIM (Universal Integrated Circuit Card/Subscriber Identity Module) card has been an afterthought and IP-based calling software has not been designed in ways that suit many IP-based calling scenarios. Rather, IP-based calling software has been designed under many of the assumptions that dictate how cellular or Voice over IP (VoIP) calling is handled. For example, when emergency calls are made, there is an assumption that the network infrastructure will identify the location of the calling device, route the call to the correct Public-Safety Answering Point (PSAP), notify the PSAP of the caller's location, etc.
Moreover, it has been assumed that when IP-based calls are made, they are done so by devices that are also cellular-capable (use a UICC/SIM Card) and are therefore registered with a Mobile Operator (MO), VoIP provider, or the like. Consequently, information about the caller's location, identity, etc., is assumed to be available through the MO or other downstream infrastructure. Although it has been recognized that IP-based emergency calls might be difficult to handle for downstream infrastructure, solutions have been limited. For example, some devices enable a user to manually input a static street address that is stored in a database for later use when the device originates an emergency call. An MO or other telephony entity handling an emergency call uses the calling device's identity to lookup the static manually pre-registered street location, which may or may not be accurate in the current situation.
In addition, although there are many well-known ways for end user devices to ascertain their current location, there has been an assumption that such location information is often unreliable or so slow to acquire that emergency calls are made without regard for a device's ability to determine its own location. Only the inventors have recognized that location-determining techniques have evolved to the point where data-only calling devices can be treated as reliable sources of calling locations when emergency calls are being made. The inventors alone have also recognized that certain techniques, discussed herein, can be used to avoid the problem of delaying initiation and setup of an emergency call while waiting for current location information to be acquired. Other techniques for incorporating a calling device's location into an IP-based call are described below.
The following summary is included only to introduce some concepts discussed in the Detailed Description below. This summary is not comprehensive and is not intended to delineate the scope of the claimed subject matter, which is set forth by the claims presented at the end.
Embodiments relate to making IP-based (Internet Protocol based) emergency calls. A device is capable of making calls over the Internet to an IP Multimedia Subsystem (IMS) core to a Public-Safety Answering Point (PSAP). The device computes location information based on its actual or estimated physical location. The location information may be computed and stored prior to making an emergency call, for instance by a location platform or service running on the computing device. When the device makes an emergency call, the device uses its location information to inform the emergency call. Specifically, a SIP message is formatted with the location information. The SIP message might be a SIP invitation formatted with a header indicating that an emergency call is being requested. The device might be capable of making only IP-based calls.
Many of the attendant features will be explained below with reference to the following detailed description considered in connection with the accompanying drawings.
The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein like reference numerals are used to designate like parts in the accompanying description.
The device 100 includes a location platform 106, which provides location information for various SIP (Session Initiation Protocol) messages that might be sent by the device 100 when initiating or conducting a call. The location platform 106 is discussed later with reference to
In addition to an IP protocol stack 103 and a network interface 105 for link-layer connections to networks, the device includes implementations of various protocols typically used for calls through IMS networks. For example, the device 100 may implement any/all of the Extensible Authentication Protocols (EAPs), the IP Security protocol (IPSec), SIP, the Real-time Transport Protocol (RTP), Transport Layer Security (TLS), and any other standard protocols used for voice or video IMS calls. The device 100 also includes application software for placing calls, for instance the softphone application 107, a contact manager, and the like. Application software for placing and managing calls may conform to the standard protocols noted above, with enhancements for incorporating location information into calls. In one embodiment, the softphone application 107 may implement calling protocols such as the Session Initiation Protocol (SIP).
Following is an example of how an IP-based emergency call can be made by the device 100. When a call has been initiated responsive to a user action or an automatic/heuristic determination that there is an emergency, IP connectivity is established if not already available. For example, the interface 105 may be a Wireless Fidelity (WiFi) interface and a WiFi connection may be established with the access point 132, which is connected to the Internet 134. With IP connectivity available, the device 100 may attempt to establish a connection with a gateway for linking Internet-based calls with the PSAP 104. Specifically, an IPSec tunnel is established with an Evolved Packet Data Gateway (EPDG) 136 or the like.
Authentication is established for a SIP session using an EAP authentication protocol such as the EAP-AKA (Authentication Key Agreement) or EAP-TLS protocol. The EPDG 136 then establishes (i) a SIP-TLS endpoint of a SIP session to the device 100 with a (ii) SIP-TLS endpoint of a SIP session that passes through an IMS core 138 to the PSAP 104. The IMS core 138 is typically provided by an MO. In sum, a SIP session is established between the PSAP 104 and the device 100. The RTP media stream is used to establish data exchange, through the EPDG 136, between the device 100 and the PSAP 104. Data exchange, for instance voice data, happens through the RTP as controlled by SIP signaling. Other mechanisms and IP-based protocols for accessing a PSAP through an Internet gateway may be used.
In embodiments where the device 100 is an IP-only device and lacks any cellular capacity or identity, SIP messages are used to provide the IMS core 138 and the PSAP 104 with information about the device 106 that it is making an emergency call.
After an emergency call has been triggered, a number of steps may be performed in parallel or in varying order. In one embodiment, at step 152 the calling device 152 checks for the availability of recent location information. A recency threshold may be checked to determine if the location information is sufficiently recent based on the application requirement, i.e., within the last hour, five minutes, etc. If location information is not available or if the location information is stale, a location is requested from the location platform106 through an application programming interface (API). The request may specify parameters suitable for an emergency call. For example, the request may specify a maximum amount of time for responding to the request, a preferred method or granularity of location measurement, etc. If a location is not available or cannot be acquired in sufficient time, the emergency call may proceed and location information may be conveyed through later SIP messages.
In addition to acquiring location information, the calling software may set up a hook to the location framework to receive updates corresponding to locational changes of the device 100. An event-driven model may be used where the location framework provides location update events either periodically or when the current location has changed by a threshold distance specified by the calling software. If the location is updated periodically to the calling software, the calling software may determine whether the location has changed enough to justify a new SIP message indicating a new location of the device making the emergency call.
Although a stream of locations might be available and locations might be signaled to the PSAP (in SIP messages sent by the calling device) at various times time during the emergency call, in one embodiment, at step 154, location information is inserted into a SIP emergency invite message that is generated by the device and transmitted through the IP-based channel to the PSAP, as discussed later with reference to
At step 156 the SIP emergency invite is received by the IMS core 138 and passed to the PSAP 104. Notably, because the calling device has included location information in the SIP invite message, the IMS core 138 and/or other telephony infrastructure can use the location in the location information to perform call-setup functions, call-routing, or select a PSAP assigned to the location in the location information. The location information may need to be transformed for SIP compliance depending on its purpose. At step 158 the IMS/PSAP proceeds with call setup, establishes a data stream for voice transmission (e.g., an RTP connection), and proceeds with known methods for implementing calls. At step 160, the device and the PSAP/IMS continue SIP signaling as needed. If, as discussed above, the calling application software determines that a location update is needed, for instance due to detection of a sufficient change in location or a transition to another emergency-handling district, the additional location updates may be issued via SIP update messages.
Regarding step 182, any one or more measuring//reporting sources 172 may be used. For example, a triangulation module might triangulate cell tower signals to determine a geographic location, a Global Positioning Satellite receiver might provide coordinates, a set of location hints might be mapped to a geographic location, and so forth. For example, a device might have a history of being at different locations at different times/days and a location or location hint might be inferred accordingly. In one embodiment, the location estimator 170 combines the various sources in a weighted fashion, and/or prioritizes one source over the other, and so forth. The location estimator's logic can be guided by parameters passed in from the calling software, as discussed above. In other embodiments, complex multi-source location logic is not used and instead one or more sources are simply selected in a prioritized order or only one location resource is used.
As discussed above, to facilitate the quick issuance of an emergency SIP invite message, the location of the device may be computed prior to an emergency call being requested and the made available in a current-location file, history buffer, a configuration setting, etc. If a history of locations is used, the history can be used to determine whether the most recent location is reliable, even if stale. For example, if the history indicates that the device has been relatively stationary then a stale last-location can be used. In any case, the initial speedy use of a pre-computed last-location that might be old and incorrect can be followed by later SIP updates to correct or update the PSAP with the calling device's current location. In many cases, initial stale location information will suffice to allow downstream infrastructure to perform call setup/routing functions and select a PSAP, and later SIP location updates can inform the PSAP of the current and perhaps more-precise location of the device.
Once formulated, the SIP invite 190 is passed via the EPDG 136 or similar gateway, to the IMS core 102, which establishes the connection to the PSAP 106. In an embodiment where the device 100 is an IP-only device and lacks cellular communication hardware yet is capable of IP-based communication, the device is able to place an IP-only call (at least up to a gateway of an MO or IMS, if not further), and yet the calling device can inform that call with relatively current and possibly pre-computed location information. The physical location or locale of the device is determined by the device itself so that there is little chance that downstream infrastructure will be mistaken about the location of the emergency call, even when initially routing the emergency call. The physical location of the device can be determined by the device by direct measurement, by GPS triangulation, radio tower triangulation, etc. The physical location can also be approximated based on, or informed with, clues about the current operational or configuration state of the device. The current/recent location information that is computed by emergency calling device can also be used to configure non-location parameters of SIP messages (e.g., URNs), including within the initial SIP invite.
The initial SIP invite can also be formatted with different headers for different types of location information; one form of location information can be included for PSAP selection and another form of location information can be included for use by the PSAP. In situations where a device has only a brief window for communication, such as when a battery is nearly depleted, radio contact is about to be lost, or the device is about to be physically damaged, the ability to include device-determined location information can be invaluable; waiting for an initial SIP invite/reply handshake to complete before sending location information from an IP-only calling device can result in an inability to find the location of an emergency.
In another embodiment, when a calling device determines that an emergency exists and/or that an emergency call is being made, the device automatically sends an emergency message through other messaging systems. If the calling device has access to a list of contacts associated with the device or a user of the device, the contact list may be used to initiate another form of emergency communication. Messages may be sent to contacts in the contact list through channels such as email, instant messaging, social networks, etc.
The computing device 250 may have a display 252, a network interface 254 (or several), as well as storage hardware 256 and processing hardware 258, which may be a combination of any one or more: central processing units, graphics processing units, analog-to-digital converters, bus chips, FPGAs, ASICs, Application-specific Standard Products (ASSPs), or Complex Programmable Logic Devices (CPLDs), etc. The storage hardware 256 may be any combination of magnetic storage, static memory, volatile memory, non-volatile memory, optically or magnetically readable matter, etc. The meaning of the term “storage”, as used herein does not refer to signals or energy per se, but rather refers to physical apparatuses and states of matter. The hardware elements of the computing device 250 may cooperate in ways well understood in the art of computing. In addition, input devices may be integrated with or in communication with the computing device 250. The computing device 250 may have any form-factor or may be used in any type of encompassing device. The computing device 250 may be in the form of a handheld device such as a smartphone, a tablet computer, a gaming device, a server, a rack-mounted or backplaned computer-on-a-board, a system-on-a-chip, or others.
Embodiments and features discussed above can be realized in the form of information stored in volatile or non-volatile computer or device readable media. This is deemed to include at least media such as optical storage (e.g., compact-disk read-only memory (CD-ROM)), magnetic media, flash read-only memory (ROM), or any current or future means of storing digital information. The stored information can be in the form of machine executable instructions (e.g., compiled executable binary code), source code, bytecode, or any other information that can be used to enable or configure computing devices to perform the various embodiments discussed above. This is also deemed to include at least volatile memory such as random-access memory (RAM) and/or virtual memory storing information such as central processing unit (CPU) instructions during execution of a program carrying out an embodiment, as well as non-volatile media storing information that allows a program or executable to be loaded and executed. The embodiments and features can be performed on any type of computing device, including portable devices, workstations, servers, mobile wireless devices, and so on.
