US7602886B1 - Method and system for using a network-provided location for voice-over-packet emergency services calls - Google Patents

Method and system for using a network-provided location for voice-over-packet emergency services calls Download PDF

Info

Publication number
US7602886B1
US7602886B1 US11/185,094 US18509405A US7602886B1 US 7602886 B1 US7602886 B1 US 7602886B1 US 18509405 A US18509405 A US 18509405A US 7602886 B1 US7602886 B1 US 7602886B1
Authority
US
United States
Prior art keywords
network
location
client
provided location
emergency services
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US11/185,094
Inventor
Hal S. Beech
Douglas R. Green
Shingara S. Dhanoa
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sprint Spectrum LLC
Original Assignee
Sprint Spectrum LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=41138043&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=US7602886(B1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Assigned to SPRINT SPECTRUM L.P. reassignment SPRINT SPECTRUM L.P. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BEECH, HAL S., DHANOA, SHINGARA S., GREEN, DOUGLAS R.
Priority to US11/185,094 priority Critical patent/US7602886B1/en
Application filed by Sprint Spectrum LLC filed Critical Sprint Spectrum LLC
Publication of US7602886B1 publication Critical patent/US7602886B1/en
Application granted granted Critical
Assigned to DEUTSCHE BANK TRUST COMPANY AMERICAS reassignment DEUTSCHE BANK TRUST COMPANY AMERICAS GRANT OF FIRST PRIORITY AND JUNIOR PRIORITY SECURITY INTEREST IN PATENT RIGHTS Assignors: SPRINT SPECTRUM L.P.
Assigned to DEUTSCHE BANK TRUST COMPANY AMERICAS reassignment DEUTSCHE BANK TRUST COMPANY AMERICAS SECURITY AGREEMENT Assignors: ASSURANCE WIRELESS USA, L.P., BOOST WORLDWIDE, LLC, CLEARWIRE COMMUNICATIONS LLC, CLEARWIRE IP HOLDINGS LLC, CLEARWIRE LEGACY LLC, ISBV LLC, Layer3 TV, Inc., PushSpring, Inc., SPRINT COMMUNICATIONS COMPANY L.P., SPRINT INTERNATIONAL INCORPORATED, SPRINT SPECTRUM L.P., T-MOBILE CENTRAL LLC, T-MOBILE USA, INC.
Assigned to SPRINT SPECTRUM L.P. reassignment SPRINT SPECTRUM L.P. TERMINATION AND RELEASE OF FIRST PRIORITY AND JUNIOR PRIORITY SECURITY INTEREST IN PATENT RIGHTS Assignors: DEUTSCHE BANK TRUST COMPANY AMERICAS
Assigned to SPRINT SPECTRUM LLC reassignment SPRINT SPECTRUM LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: SPRINT SPECTRUM L.P.
Assigned to CLEARWIRE COMMUNICATIONS LLC, SPRINT SPECTRUM LLC, BOOST WORLDWIDE, LLC, SPRINT COMMUNICATIONS COMPANY L.P., SPRINT INTERNATIONAL INCORPORATED, IBSV LLC, CLEARWIRE IP HOLDINGS LLC, ASSURANCE WIRELESS USA, L.P., PUSHSPRING, LLC, T-MOBILE CENTRAL LLC, T-MOBILE USA, INC., SPRINTCOM LLC, LAYER3 TV, LLC reassignment CLEARWIRE COMMUNICATIONS LLC RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: DEUTSCHE BANK TRUST COMPANY AMERICAS
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • H04W4/029Location-based management or tracking services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/50Connection management for emergency connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W64/00Locating users or terminals or network equipment for network management purposes, e.g. mobility management

Definitions

  • the present invention relates to telecommunications and, more particularly, to methods and systems for using a client device location that is provided by an access network for routing an voice-over-packet (VoP) emergency services call from the client device to an appropriate public safety answering point (PSAP).
  • VoIP voice-over-packet
  • PSAP public safety answering point
  • the ability to place an emergency services call by dialing 9-1-1 has become widespread throughout the United States. When a 9-1-1 call is placed, it is typically answered at a PSAP. However, there are many PSAPs throughout the United States, each serving a particular area, such as a city, county, or metropolitan area.
  • the public switched telephone network (PSTN) can route a 9-1-1 call to the appropriate PSAP, i.e., the PSAP that servers the caller's area, because the caller's telephone number is associated with a fixed location.
  • the PSAP can also reliably determine the caller's location based on the caller's telephone number.
  • VoIP networks are being used for voice communications, including emergency services calls.
  • VoIP networks often route calls that are placed by client devices that can change their point of connectivity to the network. Because of this mobility, client devices and their associated telephone numbers may not be reliably associated with fixed locations. Even so, it is desirable for a user of a client device to be able to dial 9-1-1 from any location and have the call routed through the VoP network to the appropriate PSAP, i.e., the PSAP that serves the user's current location. In addition, it is desirable for the PSAP that answers the call to be able to reliably determine the caller's location, e.g., in order to dispatch assistance to the caller.
  • an exemplary embodiment of the present invention provides a method for emergency services call routing.
  • a message from a client device is received via a voice-over-packet (VoP) access network.
  • the message requests an emergency services call.
  • a network-provided location of the client device is obtained from the VoP access network.
  • the message is checked for any client-provided location of the client device.
  • An appropriate public safety answering point (PSAP) is determined, from among a plurality of PSAPs, based on at least one of the network-provided location and the any client-provided location.
  • PSAP public safety answering point
  • an exemplary embodiment of the present invention provides a method for providing location information for emergency services calls.
  • an outbound proxy server receives from a client device, via a voice-over-packet access network, a Session Initiation Protocol (SIP) INVITE message.
  • the SIP INVITE message includes a source address.
  • the outbound proxy server determines that the SIP INVITE message is requesting an emergency services call and, responsively, accesses a location database of the VoP access network to obtain a network-provided location of the client device based on the source address.
  • the outbound proxy server inserts the network-provided location into a network-provided location field of the SIP INVITE message.
  • an exemplary embodiment of the present invention provides a system for providing location information for emergency services calls.
  • the system comprises a voice-over-packet (VoP) access network to which a plurality of client devices are communicatively coupled, a location database that correlates locations of the client devices with source addresses assigned to the client devices, and an outbound proxy server communicatively coupled to the VoP access network so as to receive all initial call requests from the client devices.
  • VoIP voice-over-packet
  • the outbound proxy server obtains from the location database a network-provided location of the given client device and inserts the network-provided location into the emergency services call request.
  • FIG. 1 is a simplified block diagram of a telecommunications network, in accordance with an exemplary embodiment of the present invention
  • FIG. 2 is a flow chart illustrating a first part of a method for routing a voice-over-packet emergency services call to an appropriate PSAP, in accordance with an exemplary embodiment of the present invention
  • FIG. 3 is a flow chart illustrating a second part of a method for routing a voice-over-packet emergency services call to an appropriate PSAP, in accordance with an exemplary embodiment of the present invention
  • FIG. 4 is a flow chart illustrating a second part of a method for routing a voice-over-packet emergency services call to an appropriate PSAP, in accordance with an exemplary embodiment of the present invention.
  • FIG. 5 is a flow chart illustrating an algorithm for determining a best estimate of a client device's location for purposes of determining an appropriate PSAP, in accordance with an exemplary embodiment of the present invention.
  • the present invention in its exemplary embodiments, provides methods and systems for using location information that is provided by an access network to support a voice-over-packet (VoP) emergency services call, such as a 9-1-1 call, originated by a client device communicatively coupled to the access network.
  • VoIP voice-over-packet
  • the network-provided location can be used to support the emergency services call in different ways.
  • the network-provided location may be used to determine which public safety answering point (PSAP) is appropriate for answering the call.
  • PSAP public safety answering point
  • the call could be routed to any number of PSAPs.
  • different PSAPs typically serve different areas.
  • the PSAP that is appropriate for answering the call is usually the PSAP that serves the area in which the caller is located.
  • the network-provided location information may also be used to inform the PSAP of the caller's location, for example, in terms of geospatial coordinates (i.e., latitude and longitude) and/or civic coordinates (e.g., a street address). In this way, the PSAP will know where to dispatch emergency assistance.
  • geospatial coordinates i.e., latitude and longitude
  • civic coordinates e.g., a street address
  • the network-provided location may also be used to evaluate the reliability of any location information that is provided by the client device. For example, if the network-provided location and the client-provided location are inconsistent, then the network-provided location may be deemed to be more reliable and used to support the emergency services call (e.g., for routing the emergency services call). On the other hand, if the network-provided location and the client-provided location are consistent, and the client-provided location is more specific, then the client-provided location may be used to support the emergency services call.
  • the client device is communicatively coupled to the access network via a network access device, such as a digital subscriber line (DSL) modem, cable modem, or router.
  • the client device could be communicatively coupled to the network access device via a wired connection, such as a local area network (LAN).
  • the client device could be a wireless communication device, such as a wireless handset or wirelessly-equipped laptop computer that communicates with the network access device via a wireless access point, e.g., using an IEEE 802.11x, IEEE 802.16, HiperLAN, HomeRF, Bluetooth, or other wireless communications protocol.
  • the access network provides the client device with access to a wide-area network, such as the Internet.
  • the access network may be operated by an Internet Service Provider (ISP) to which the user of the client device subscribes.
  • ISP Internet Service Provider
  • the client device may use the access network for VoP communications and may also use the access network for e-mail, Web browsing, and other applications.
  • the client device uses the Session Initiation Protocol (SIP) to set up VoP calls.
  • SIP Session Initiation Protocol
  • the client device may transmit a SIP INVITE message. It is to be understood, however, that SIP is exemplary only, as other protocols could be used to set up VoP calls.
  • all initial call requests such as SIP INVITE messages
  • client devices communicatively coupled to the access network are received by an outbound proxy server that is associated with the access network.
  • the ISP that operates the access network may also operate the outbound proxy server.
  • the SIP user agents in the client devices may be appropriately configured. This may be accomplished by either a manual configuration process or by a network-based process, such as the Dynamic Host Configuration Protocol (DHCP).
  • DHCP Dynamic Host Configuration Protocol
  • DHCP-based configuration approaches are described in Schulzrinne, “Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers,” Request For Comments 3319 (July 2003) and in H. Schulzrinne, “Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers,” Request For Comments 3361 (March 2002), which documents are incorporated herein by reference.
  • DHCPv6 Dynamic Host Configuration Protocol
  • SIP Session Initiation Protocol
  • the access network may intercept and divert SIP messages from client devices to the outbound proxy server.
  • the access network may include a policy router that inspects packets from client devices and diverts any packets that appear to be SIP messages to the outbound proxy server.
  • Different schemes could be used for classifying packets as SIP messages. For example, UDP packets directed to port 5060 may be classified as SIP messages.
  • the outbound proxy server determines whether the message is requesting an emergency services call. For example, the outbound proxy server may determine whether the message includes an emergency services URI in a destination field.
  • An emergency services URI could, for example, include a designation such as “911” or “sos” that is associated with an emergency services call.
  • the outbound proxy server tries to obtain information regarding the location of the client device from the access network. Once the outbound proxy server obtains a location from the access network, the outbound proxy server inserts the location into the SIP INVITE message and forwards the modified SIP INVITE message.
  • the access network maintains a location database that stores the locations of the client devices that are communicatively coupled to the access network.
  • the locations could be expressed as geospatial coordinates (i.e., in terms of latitude and longitude), and/or in terms of civic coordinates (e.g., a street address).
  • the location database correlates the location of each client device with the Internet Protocol (IP) address that has been dynamically assigned to the client device.
  • IP Internet Protocol
  • the DHCP server may also be informed of a hardware element at a fixed location (e.g., a particular circuit or port) that the client device is using to communicate with the access network.
  • a hardware element e.g., a particular circuit or port
  • This DHCP-based approach is described in Patrick, “DHCP Relay Agent Information Option,” Request For Comments 3046 (January 2001), which is incorporated herein by reference.
  • the location database may then store a location for the client device, based on the hardware element's location, and associate that location with the IP address assigned to the client device.
  • the outbound proxy server can access the location database to determine a client device's location based on the client device's IP address, i.e., the source IP address included in the SIP INVITE message from the client device.
  • the outbound proxy server obtains the location information from the access network by invoking an active network location function of the access network.
  • the active network location function could involve, for example, a wireless triangulation technique and/or network-assisted GPS. Such active approaches may be more time consuming than looking up a previously-obtained location stored in a location database.
  • the active network location function may, at first, provide only an initial approximation of the client device's location. Later, the active network location function may follow up with a more precise location of the client device.
  • the outbound proxy server may use the initial approximation of the client device's location, inserting the initial approximation into the SIP INVITE message that the outbound proxy server then forwards. To remain in the signaling path, the outbound proxy server may also insert a record route header into the SIP INVITE message. Then, when the outbound proxy server receives a more precise location of the client device from the active network function, the outbound proxy server may send a follow-up message with the more precise location.
  • the outbound proxy server may be unable to obtain a specific location for the client device from the access network. This may occur when the source IP address of the SIP INVITE message is not the client device's actual IP address, for example, because the client device is using Network Address Translation (NAT) or because the client device is communicating via a Virtual Private Network (VPN). In such cases, the source IP address of the SIP INVITE message might not be listed in the location database at all.
  • the location database might list only a generic location for the source IP address, e.g., a location describing the entire area served by the access network, rather than a specific location. Such a generic location might be useful to determine which PSAP should answer the call, but might not be useful for dispatching assistance to the caller.
  • the client device may itself provide location information.
  • the client device could be manually provisioned with information regarding its location. If the client device is mobile, however, this client-provided location information might not be reliable.
  • the client device might use a wireless positioning technology such as the Global Positioning System (GPS) to determine its position.
  • GPS Global Positioning System
  • a GPS-based position might be reliable, provided that it is current.
  • a network-provided location may be compared to a client-provided location to obtain a more reliable estimation of the client device's location than could be obtained from a single source of location information.
  • the evaluation of the network-provided location, if any, and the client-provided location, if any, could be performed by the outbound proxy server.
  • the outbound proxy server simply inserts the network-provided location into the SIP INVITE message and forwards the modified SIP INVITE message to an emergency services routing server.
  • the emergency services routing server determines which PSAP should receive the call based on any network-provided location and/or any client-provided location included in the message.
  • the network-provided location may be identified as such in the SIP INVITE message.
  • the outbound proxy server may insert the network-provided location into a designated network-provided location field of the message. In so doing, the outbound proxy server may leave undisturbed any client-provided location that was already included in the message.
  • the client-provided location may be included in a client-provided location field that is separate from the network-provided location field.
  • One benefit of retaining the client-provided location in the message is that if routing based on the network-provided location is incorrect, then the call could be re-routed based on the client-provided location.
  • the outbound proxy server may receive a SIP INVITE message that already contains a network-provided location in a network-provided location field. This may occur, for example, when the client device is communicating via a private network that uses NAT.
  • the private network may have its own outbound proxy server that inserts private network-provided locations into SIP INVITE messages that request emergency services calls.
  • the private network's outbound proxy might obtain a private network-provided location from a private network location database, e.g., based on a client device's private network address. This approach can beneficially provide a more specific location for the client device than might be obtainable based on the client device's public IP address.
  • the outbound proxy server of the access network may retain this location rather than insert a location provided by the access network.
  • An emergency services routing server may then receive the SIP INVITE message from the outbound proxy server of the access network.
  • the SIP INVITE message might contain both a network-provided location and a client-provided location.
  • the routing server may evaluate the network-provided location and the client-provided to obtain a best estimate of the client device's location. The evaluation may involve determining whether the network-provided and client-provided locations are consistent, determining which location is more specific, and/or which location is more reliable.
  • the routing server might use either the network-provided location or the client-provided location as the best estimate of the client device's location, or the routing server might combine the locations to develop its own best estimate of the client device's location. For example, if the network-provided location and client-provided location define distinct but overlapping areas based on their uncertainties, then the client device may be assumed to be located in the area of overlap.
  • the emergency services routing server may apply an uncertainty model to the network-provided location and/or client-provided location in order to estimate the uncertainties of these locations.
  • the uncertainty model that is applied may depend on the type and implementation of the technology that was used to obtain the location. For example, a location that was obtained based on the fact that the client device is communicating via a particular wireless access point may depend on how precisely the location of the wireless access point is known (e.g., based on a wiring diagram) and on the effective communication range of the wireless access point (e.g., a 100 meter radius for an 802.11 wireless access point that is located indoors).
  • the emergency services routing server may determine which uncertainty model to apply based on one or more parameters included with the network-provided location and/or client-provided location in the SIP INVITE message.
  • the SIP INVITE message may include an actual uncertainty for the network-provided location and/or client-provided location.
  • the routing server uses that location to determine which PSAP is appropriate for answering the call. For example, the routing server may access a PSAP coverage database that specifies which PSAPs serve which areas. To route the SIP INVITE message so that the emergency services call will be established to the appropriate PSAP, the routing server may replace the emergency services URI in the message with a URI that corresponds to the PSAP determined to be appropriate to answer the call. To determine PSAP URIs, the routing server may access a PSAP routing database.
  • the emergency services call can be established to the PSAP that serves the area in which the client device is located.
  • the PSAP may receive both a network-provided location and a client-provided location in the signaling used to set up the call.
  • the PSAP may use one or more of these locations to determine where to dispatch emergency services.
  • the location information may be used to re-route the call to another PSAP.
  • FIG. 1 is a simplified block diagram of an exemplary telecommunications network 10 .
  • Network 10 includes a wide-area network 12 , which is communicatively coupled to a plurality of access networks, such as access network 14 and access network 16 .
  • wide-area network 12 may correspond to the Internet
  • access networks 14 and 16 may correspond to networks operated by two different ISPs to provide access to the Internet.
  • FIG. 1 shows only two access networks, it is to be understood that wide-area network 12 could be coupled to many more access networks.
  • networks 12 , 14 , and 16 are packet-switched networks that convey voice or other media in a packetized format.
  • networks 12 , 14 , and 16 may route packets based on network addresses, such as by using the Internet Protocol (IP) protocol in combination with the User Datagram Protocol (UDP) or Transmission Control Protocol (TCP).
  • IP Internet Protocol
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • the IP packets may be carried over lower level protocols, such as asynchronous transfer mode (ATM) protocols.
  • ATM asynchronous transfer mode
  • Application layer protocols such as the Session Initiation Protocol (SIP), may be used to set up and control voice calls and other communication sessions through networks 12 , 14 , and 16 .
  • SIP Session Initiation Protocol
  • Networks 12 , 14 , and 16 may carry the voice or other media in such calls, as UDP/IP or TCP/IP packets, in a real-time packet media format, e.g., by using the real-time transport protocol (RTP).
  • RTP real-time transport protocol
  • Relevant aspects of RTP are described in Schulzrinne, et al., “RTP: A Transport Protocol for Real-Time Applications,” Request for Comments 1889 (January 1996), which is incorporated herein by reference.
  • Access networks 14 and 16 may be communicatively coupled to network access devices such as DSL modems, cable modems, or routers.
  • network access devices such as DSL modems, cable modems, or routers.
  • FIG. 1 shows access network 14 connected to network access devices 18 and 20 and access network 16 connected to network access devices 22 and 24 . It is to be understood, however, that each access network may be connected to many network access devices, which may be distributed over a wide area.
  • Client devices may, in turn, be able to communicate with network access devices 18 , 20 , 22 , and 24 via either wired or wireless interfaces.
  • FIG. 1 shows network access devices 18 , 20 , 22 , and 24 connected to wireless access points 26 , 28 , 30 , and 32 , respectively.
  • FIG. 1 shows a wireless client device 34 in wireless communication with network access device 20 via wireless access point 28 .
  • client device 34 is able to access wide-area network 12 via wireless access point 28 , network access device 20 , and access network 14 , for VoP calls and for other types of communication.
  • client device 34 may be able to move to other locations where client device can access wide-area network 12 , e.g., via a different network access device and/or a different access network. For example, client device 34 may move out of the wireless coverage provided by wireless access point 28 and into the wireless coverage area provided by wireless access point 30 . At that point, client device 34 may then access wide-area network 12 via wireless access point 30 , network access device 22 and access network 16 , e.g., for VoP calls.
  • FIG. 1 shows wide-area network 12 communicatively coupled to PSAPs 36 and 38 .
  • PSAPs 36 and 38 may each include an answering center that answers emergency services calls, such as 9-1-1 calls, on behalf of a public safety organization.
  • Such public safety organizations may include, for example, law enforcement, fire protection, and/or medical assistance organizations.
  • a public safety organization may provide services in only a particular geographic area (e.g., a particular city, town, county, or metropolitan area) or in only a particular type of location (e.g., in a particular airport).
  • PSAP 36 may serve the area in which wireless access point 28 is located
  • PSAP 38 may serve the area in which wireless access point 30 is located.
  • emergency services calls originating from wireless access point 28 e.g., from client device 34
  • PSAP 36 rather than to PSAP 38
  • emergency services calls originating from wireless access point 30 should be routed to PSAP 38 .
  • PSAPs 36 and 38 could be directly connected to wide-area network 12 , as shown in FIG. 1 . However, it is to be understood that one or more of these PSAPs could be indirectly connected to wide-area network 12 .
  • a PSAP may be connected to one or more circuit-switched elements, such as in the public switched telephone network (PSTN), which, in turn, may be communicatively coupled to wide-area network 12 via a media gateway that converts between packet-switched and circuit-switched media formats.
  • PSTN public switched telephone network
  • FIG. 1 shows only two PSAPs, wide-area network 12 could be communicatively coupled to any number of PSAPs.
  • access networks 14 and 16 may maintain the locations of client devices, for example, stored in location databases 40 and 42 .
  • An access network may determine the locations of client devices based on the locations of hardware elements that the client devices use to access the access network.
  • a network access device may be connected to an access network via different types of physical links. At least part of the physical link may include a hardware element in a fixed location, such as an optical fiber, coaxial cable, or telephone line.
  • FIG. 1 shows network access devices 18 and 20 connected to a distribution hub 44 of access network 14 via physical links 46 and 48 , respectively, and shows network access devices 22 and 24 connected to a distribution hub 50 of access network 16 via physical links 52 and 54 , respectively.
  • these distribution hubs could be cable modem termination systems (CMTSs).
  • CMTSs cable modem termination systems
  • DSL modems digital subscriber line access multiplexers
  • Each of physical links 46 , 48 , 52 , and 54 may be connected to a single network access device or to a group of proximately-located network access devices.
  • the general location of a client device can be determined by identifying the physical link that a client device is using for communication.
  • the identification of the physical link that a client device is using may be made when the client device logs into the access network.
  • access networks 14 and 16 may include respective DHCP servers 56 and 58 that dynamically assign IP addresses to client devices when they log on.
  • the distribution hub may inform the DHCP server of which physical link the client device is using.
  • the distribution hub may identify the physical link, for example, as a particular circuit or port.
  • the DHCP server may then push the physical link identification and the IP address assigned to the client device to the location database.
  • the location database may then translate the physical link identification into a location, e.g., a street address where the terminus of the physical link is located.
  • distribution hub 44 may identify physical link 48 as corresponding to a telephone line that goes to the premises where network access device 20 is located.
  • DHCP server 56 may dynamically assign an IP address to client device 34 and then push the IP address and physical link identification to location database 40 .
  • Location database 40 may then translate the physical link identification into the street address of the premises at which physical link 48 terminates.
  • Location database to may store a correlation between this street address and the IP address assigned to client device 34 .
  • Access networks 14 and 16 include outbound proxy servers 60 and 62 , respectively.
  • Outbound proxy servers 60 and 62 receive all initial VoP call requests, e.g., SIP INVITE messages, from client devices coupled to their respective access networks in order to determine whether the VoP call requests are requesting emergency services calls. For example, when outbound proxy server 60 determines that an emergency services call is being requested, it may identify the source IP address contained in the request message and obtain the location information that is correlated with that source IP address in location database 40 . Outbound proxy server 60 may then insert this network-provided location information into the request message and forward the modified message to an emergency services routing server 64 .
  • SIP INVITE messages e.g., SIP INVITE messages
  • emergency services routing server 64 receives messages forwarded from multiple access networks, for example, from outbound proxy server 60 in access network 14 and from outbound proxy server 62 in access network 16 . As described in more detail below, routing server 64 then evaluates the location information provided in the message that it receives to determine how to route the message so that the emergency services call will be established to the appropriate PSAP. In this regard, routing server 64 may formulate a best estimate of the caller's location and then access a PSAP coverage database 66 to determine which PSAP serves this location. Routing server 64 may then access a routing database 68 to obtain a routing a routing address that can be used to route the call to the appropriate PSAP. Alternatively, PSAP coverage database 66 may itself provide PSAP routing addresses.
  • FIG. 1 shows a routing server separate from the outbound proxy servers
  • the outbound proxy servers may also function as routing servers.
  • FIG. 1 shows various databases as being separate from the servers that access them, the database could be integrated with the servers.
  • location database 40 could be integrated with outbound proxy server 60
  • location database 42 could be integrated with outbound proxy server 62
  • PSAP coverage database 66 and/or PSAP routing database 68 could be integrated with routing server 64 .
  • FIGS. 2-5 are flow charts illustrating steps of an exemplary method of operation.
  • SIP is the signaling protocol that the client device uses to set up calls.
  • SIP is exemplary only; other signaling protocols could be used.
  • FIGS. 2-5 assume the network architecture shown in FIG. 1 , though it is to be understood that other network architectures could be used.
  • the process may begin when the user of a client device dials digits for an emergency services call, as indicated by block 100 .
  • the particular digits that the user dials may depend on the jurisdiction in which the user is located. For example, in many parts of the United States, an emergency services call can be placed by dialing “911.” In other areas, particularly outside of the United States, other digits may be used to place emergency services calls.
  • the dialed digits may indicate an emergency services call without specifying which particular PSAP should answer the call. For example, there are many PSAPs in the United States that answer 9-1-1 calls.
  • the client device transmits, via an access network, a SIP INVITE message with an emergency services URI in a destination field, as indicated by block 102 .
  • the emergency services URI may include the digits that the user dialed, e.g., “911.”
  • the emergency services URI may include a designation other than the dialed digits to indicate that an emergency services call is being requested.
  • the emergency services URI may include an “sos” designation that could be used to indicate an emergency services call independently of the particular digits the user dialed.
  • such emergency services URIs indicate that an emergency services call is requested without specifying which particular PSAP should answer the call.
  • the SIP INVITE message may include other types of information to indicate that the client device is requesting establishment of an emergency services call.
  • the outbound proxy server of the access network receives the SIP INVITE message, as indicated by block 104 .
  • client device 34 may transmit the SIP INVITE message via wireless access point 20 , in which case outbound proxy server 60 would received receive the message via access network 14 .
  • the client device may specifically direct the SIP INVITE message to the outbound proxy server, e.g., because the client device has been configured to use the outbound proxy server for all initial call requests.
  • the access network rather than the client device, may direct the SIP INVITE message to the outbound proxy server, e.g., using policy-based routing.
  • the outbound proxy server determines whether the SIP INVITE message is requesting an emergency services call, e.g., by checking the destination field for an emergency services URI, as indicated by block 106 . If the SIP INVITE message is not requesting an emergency services call, then the outbound proxy server may route the message in accordance with standard SIP routing procedures, as indicated by block 108 . In this case, however, the SIP INVITE message contains is requesting an emergency services call. As a result, the outbound proxy server performs an emergency services routing procedure on the SIP INVITE message, as indicated by block 110 .
  • FIG. 3 illustrates the steps taken by the outbound proxy server for a SIP INVITE message that requests an emergency services call.
  • the outbound proxy server may first examine the SIP INVITE message to determine whether the message already contains a network-provided location, as indicated by block 112 . This may occur, for example, when an outbound proxy server in a private network inserts a network-provided location into the SIP INVITE message before the message reaches the access network.
  • a private network may have more specific information regarding a client device's location than the access network, because the access network may see only the client device's public address. Thus, a location provided by a private network may be retained as being more reliable than a location provided by the access network.
  • the outbound proxy server may simply forward a SIP INVITE message to an emergency services routing server without inserting any additional location information, as indicated by block 114 .
  • the outbound proxy server may try to obtain a location of the client device from the access network. To do this, the outbound proxy server may identify the source IP address of the SIP INVITE message, as indicated by block 116 . The outbound proxy server may then look up the source IP address in the access network's location database, as indicated by block 118 . Whether this approach is successful may depend on whether the location database lists a location for the source IP address, as indicated by block 120 .
  • the outbound proxy server If the outbound proxy server is able to obtain a location from the location database based on the source IP address, then the outbound proxy server inserts the location into a network-provided location field of the SIP INVITE message, as indicated by block 122 . The outbound proxy server then forwards the modified SIP INVITE message to an emergency services routing server, as indicated by block 124 .
  • the network-provided location field may be identified by a predefined header, which the outbound proxy server may also insert into the SIP INVITE message.
  • the location By placing the location in a network-provided location field, the location can be tagged as having been provided by the access network and can be distinguished from any client-provided location that may also be included in the SIP INVITE message.
  • some client devices may be configured to include a location in any SIP INVITE message that is transmitted to request an emergency services call.
  • Such client-provided location may be more or less reliable, e.g., depending on how it is obtained. For example, a manually provisioned location may not be reliable if the client device has moved. However, a GPS-derived location, if current, may be reliable. In any event, because the client-provided location can sometimes be reliable, it is preferable to retain it.
  • the outbound proxy server preferably leaves undisturbed any client-provided location when inserting the network-provided location into the SIP INVITE message.
  • the outbound proxy server may insert an indication into the SIP INVITE message that no network-provided location is available, as indicated by block 126 .
  • the outbound proxy server may insert text such as “network-derived location information unavailable” into a network-provided location field.
  • a network-provided location may be unavailable for any number of reasons.
  • the location database may simply not be current.
  • the client device may be communicating in such a way, e.g., through a VPN, that the client device's actual IP address is hidden.
  • FIG. 3 illustrates an example in which the outbound proxy server obtains a network-provided location of the client device by querying a location database
  • the outbound proxy could obtain the network-provided location in other ways.
  • the outbound proxy server could, in response to determining that the SIP INVITE message is requesting an emergency services call but does not already contain a network-provided location, invoke an active network function of the access network.
  • the outbound proxy server may insert into the SIP INVITE message an initial approximation of the client device's location that is obtained from the active network location function and then forward the SIP INVITE message to the emergency services routing server.
  • the active network location function may later provide a more precise location, which the outbound proxy server may then forward to the emergency services routing server in a subsequent message.
  • FIG. 4 illustrates the steps that may be performed by the emergency services routing server to route the emergency services call to the appropriate PSAP.
  • the emergency services routing server receives the SIP INVITE message from the outbound proxy server.
  • the emergency services routing server identifies any network-provided location and any client-provided location that may be included in the SIP INVITE message, as indicated by block 132 .
  • How the emergency services routing server proceeds depends on whether the SIP INVITE message includes any location for the client device, whether provided by the network or the client, as indicated by block 134 . If the message does not any client device location, then the emergency services routing server may route the SIP INVITE message to a default PSAP, as indicated by block 136 .
  • the default PSAP could be based, for example, on the identity of the outbound proxy server that sent the SIP INVITE message or on the source IP address of the message. Although this information might not pinpoint the location of the client device, the information may nonetheless indicate a general geographic area, such as a particular metropolitan area, that suggests an appropriate PSAP.
  • the emergency services routing server makes a best estimate of the client device's location based on the network-provided location and/or client-provided location, as indicated by block 138 .
  • the routing server may access a PSAP coverage base to determine which PSAP serves that location, as indicated by block 140 .
  • the PSAP that serves that location will typically be the PSAP that is appropriate to receive the emergency services call.
  • the emergency services routing server will route the SIP INVITE message so that the emergency services call will be established to that PSAP.
  • the emergency services routing server may access a PSAP routing database to obtain a routing address that can be used to route the SIP INVITE message to the appropriate PSAP, as indicated by block 142 .
  • the emergency services routing server then routes the SIP INVITE message based on the PSAP routing address, as indicated by block 144 .
  • the emergency services routing server may replace the emergency services URI with a PSAP URI that corresponds to the appropriate PSAP and then route the SIP INVITE message in accordance with standard SIP routing procedures.
  • the emergency services call can be established to the appropriate PSAP.
  • the PSAP may learn the caller's location from the location information included in the call set-up signaling. With this location information, the PSAP may be able to dispatch timely assistance to the caller.
  • FIGS. 2-4 illustrate an example in which various steps are performed by the outbound proxy server of the access network being used by the client device and various steps are performed by an emergency services routing server, which may server multiple access networks, it is to be understood that these steps could be distributed among a greater or fewer number of network elements.
  • the outbound proxy server might be configured to perform the steps of the emergency services routing server, i.e., steps illustrated in FIG. 4 .
  • FIG. 5 is a flow chart illustrating an exemplary algorithm for determining a best estimate of the client device's location for purposes of determining the appropriate PSAP.
  • an emergency services routing server determines a best estimate of the client device's location for purposes of determining the appropriate PSAP, e.g., as in block 138 of FIG. 4 .
  • the emergency services routing server may apply this algorithm.
  • the outbound proxy server of the client device's access network, or some other network element may apply this algorithm.
  • the first step might be to determine what location information is included in the SIP INVITE message, as indicated by block 200 . If there is only a network-provided location, then the network-provided location is used to determine the appropriate PSAP, as indicated by block 202 . If there is only a client-provided location, then the client-provided location is used to determine the appropriate PSAP, as indicated by block 204 .
  • the algorithm may determine whether these locations are consistent, as indicated by block 206 .
  • the emergency services routing server may apply uncertainty models to estimate the uncertainties of these locations.
  • the SIP INVITE message may already include uncertainties for the network-provided location and/or client-provided location.
  • the network-provided and client-provided locations are consistent, then the more specific location is used to determine the appropriate PSAP, as indicated by block 208 .
  • the network-provided and client-provided locations are not consistent, then one of the two locations may be deemed to be more reliable based on various considerations.
  • the network-provided location may be deemed to be more reliable, and, thus, used to determine the appropriate PSAP, as indicated by block 202 . This approach is based on the view that the client-provided location may have been manually configured, whereas the network-provided location may be determined automatically.
  • the network-provided location and client-provided location may be deemed to be partially consistent. This may occur, for example, when the uncertainties in the two locations define different but overlapping areas in which the client device could be located. In such cases, a location in the overlap area could be used to determine the appropriate PSAP, as indicated by block 210 .

Abstract

A client device transmits, via a voice-over-packet (VoP) access network, a message that requests an emergency services call. An outbound proxy server receives the message and obtains a network-provided location of the client device, e.g., by looking up the source address of the message in a location database maintained by the access network or by invoking an active network location function. The outbound proxy server inserts the network-provided location into the message, leaving any client-provided location in the message undisturbed, and forwards the message to an emergency services routing server. The emergency services routing server determines which public safety answering point (PSAP) should receive the call, based on at least one of the network-provided location and any client-provided location in the message.

Description

BACKGROUND
1. Field of the Invention
The present invention relates to telecommunications and, more particularly, to methods and systems for using a client device location that is provided by an access network for routing an voice-over-packet (VoP) emergency services call from the client device to an appropriate public safety answering point (PSAP).
2. Description of Related Art
The ability to place an emergency services call by dialing 9-1-1 has become widespread throughout the United States. When a 9-1-1 call is placed, it is typically answered at a PSAP. However, there are many PSAPs throughout the United States, each serving a particular area, such as a city, county, or metropolitan area. The public switched telephone network (PSTN) can route a 9-1-1 call to the appropriate PSAP, i.e., the PSAP that servers the caller's area, because the caller's telephone number is associated with a fixed location. The PSAP can also reliably determine the caller's location based on the caller's telephone number.
Increasingly, however, packet networks are being used for voice communications, including emergency services calls. Such voice-over-packet (VoP) networks often route calls that are placed by client devices that can change their point of connectivity to the network. Because of this mobility, client devices and their associated telephone numbers may not be reliably associated with fixed locations. Even so, it is desirable for a user of a client device to be able to dial 9-1-1 from any location and have the call routed through the VoP network to the appropriate PSAP, i.e., the PSAP that serves the user's current location. In addition, it is desirable for the PSAP that answers the call to be able to reliably determine the caller's location, e.g., in order to dispatch assistance to the caller.
Accordingly, there is a need for providing methods and systems for obtaining location information that can be relied upon to route an VoP emergency services call to the appropriate PSAP and to inform the PSAP of the caller's location.
SUMMARY
In a first principal aspect, an exemplary embodiment of the present invention provides a method for emergency services call routing. In accordance with the method, a message from a client device is received via a voice-over-packet (VoP) access network. The message requests an emergency services call. A network-provided location of the client device is obtained from the VoP access network. The message is checked for any client-provided location of the client device. An appropriate public safety answering point (PSAP) is determined, from among a plurality of PSAPs, based on at least one of the network-provided location and the any client-provided location. The emergency services call is routed to the appropriate PSAP.
In a second principal aspect, an exemplary embodiment of the present invention provides a method for providing location information for emergency services calls. In accordance with the method, an outbound proxy server receives from a client device, via a voice-over-packet access network, a Session Initiation Protocol (SIP) INVITE message. The SIP INVITE message includes a source address. The outbound proxy server determines that the SIP INVITE message is requesting an emergency services call and, responsively, accesses a location database of the VoP access network to obtain a network-provided location of the client device based on the source address. The outbound proxy server inserts the network-provided location into a network-provided location field of the SIP INVITE message.
In a third principal aspect, an exemplary embodiment of the present invention provides a system for providing location information for emergency services calls. The system comprises a voice-over-packet (VoP) access network to which a plurality of client devices are communicatively coupled, a location database that correlates locations of the client devices with source addresses assigned to the client devices, and an outbound proxy server communicatively coupled to the VoP access network so as to receive all initial call requests from the client devices. In response to an emergency services call request from a given one of the client devices, the outbound proxy server obtains from the location database a network-provided location of the given client device and inserts the network-provided location into the emergency services call request.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a simplified block diagram of a telecommunications network, in accordance with an exemplary embodiment of the present invention;
FIG. 2 is a flow chart illustrating a first part of a method for routing a voice-over-packet emergency services call to an appropriate PSAP, in accordance with an exemplary embodiment of the present invention;
FIG. 3 is a flow chart illustrating a second part of a method for routing a voice-over-packet emergency services call to an appropriate PSAP, in accordance with an exemplary embodiment of the present invention;
FIG. 4 is a flow chart illustrating a second part of a method for routing a voice-over-packet emergency services call to an appropriate PSAP, in accordance with an exemplary embodiment of the present invention; and
FIG. 5 is a flow chart illustrating an algorithm for determining a best estimate of a client device's location for purposes of determining an appropriate PSAP, in accordance with an exemplary embodiment of the present invention.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 1. Overview
The present invention, in its exemplary embodiments, provides methods and systems for using location information that is provided by an access network to support a voice-over-packet (VoP) emergency services call, such as a 9-1-1 call, originated by a client device communicatively coupled to the access network. The network-provided location can be used to support the emergency services call in different ways. For example, the network-provided location may be used to determine which public safety answering point (PSAP) is appropriate for answering the call. In particular, the call could be routed to any number of PSAPs. However, different PSAPs typically serve different areas. Thus, the PSAP that is appropriate for answering the call is usually the PSAP that serves the area in which the caller is located. The network-provided location information may also be used to inform the PSAP of the caller's location, for example, in terms of geospatial coordinates (i.e., latitude and longitude) and/or civic coordinates (e.g., a street address). In this way, the PSAP will know where to dispatch emergency assistance.
The network-provided location may also be used to evaluate the reliability of any location information that is provided by the client device. For example, if the network-provided location and the client-provided location are inconsistent, then the network-provided location may be deemed to be more reliable and used to support the emergency services call (e.g., for routing the emergency services call). On the other hand, if the network-provided location and the client-provided location are consistent, and the client-provided location is more specific, then the client-provided location may be used to support the emergency services call.
In an exemplary embodiment, the client device is communicatively coupled to the access network via a network access device, such as a digital subscriber line (DSL) modem, cable modem, or router. The client device could be communicatively coupled to the network access device via a wired connection, such as a local area network (LAN). Alternatively, the client device could be a wireless communication device, such as a wireless handset or wirelessly-equipped laptop computer that communicates with the network access device via a wireless access point, e.g., using an IEEE 802.11x, IEEE 802.16, HiperLAN, HomeRF, Bluetooth, or other wireless communications protocol.
The access network, in turn, provides the client device with access to a wide-area network, such as the Internet. Thus, the access network may be operated by an Internet Service Provider (ISP) to which the user of the client device subscribes. The client device may use the access network for VoP communications and may also use the access network for e-mail, Web browsing, and other applications. In an exemplary embodiment, the client device uses the Session Initiation Protocol (SIP) to set up VoP calls. Thus, to request a VoP call, the client device may transmit a SIP INVITE message. It is to be understood, however, that SIP is exemplary only, as other protocols could be used to set up VoP calls.
In accordance with an exemplary embodiment of the present invention, all initial call requests, such as SIP INVITE messages, transmitted by client devices communicatively coupled to the access network are received by an outbound proxy server that is associated with the access network. The ISP that operates the access network may also operate the outbound proxy server. To ensure that the outbound proxy server receives all initial call requests, the SIP user agents in the client devices may be appropriately configured. This may be accomplished by either a manual configuration process or by a network-based process, such as the Dynamic Host Configuration Protocol (DHCP). Exemplary DHCP-based configuration approaches are described in Schulzrinne, “Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers,” Request For Comments 3319 (July 2003) and in H. Schulzrinne, “Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers,” Request For Comments 3361 (August 2002), which documents are incorporated herein by reference.
Alternatively, the access network may intercept and divert SIP messages from client devices to the outbound proxy server. For example, the access network may include a policy router that inspects packets from client devices and diverts any packets that appear to be SIP messages to the outbound proxy server. Different schemes could be used for classifying packets as SIP messages. For example, UDP packets directed to port 5060 may be classified as SIP messages.
When the outbound proxy server receives a SIP INVITE message from a client device, the outbound proxy server determines whether the message is requesting an emergency services call. For example, the outbound proxy server may determine whether the message includes an emergency services URI in a destination field. An emergency services URI could, for example, include a designation such as “911” or “sos” that is associated with an emergency services call.
If an emergency services call is being requested, the outbound proxy server tries to obtain information regarding the location of the client device from the access network. Once the outbound proxy server obtains a location from the access network, the outbound proxy server inserts the location into the SIP INVITE message and forwards the modified SIP INVITE message.
How the outbound proxy server obtains the location information from the access network may depend on the particular configuration of the access network and/or on the particular technology the client device is using to communicate with the access network. In one exemplary embodiment, the access network maintains a location database that stores the locations of the client devices that are communicatively coupled to the access network. The locations could be expressed as geospatial coordinates (i.e., in terms of latitude and longitude), and/or in terms of civic coordinates (e.g., a street address). In an exemplary embodiment, the location database correlates the location of each client device with the Internet Protocol (IP) address that has been dynamically assigned to the client device. For example, when a DHCP server of the access network dynamically assigns an IP address to a client device, the DHCP server may also be informed of a hardware element at a fixed location (e.g., a particular circuit or port) that the client device is using to communicate with the access network. This DHCP-based approach is described in Patrick, “DHCP Relay Agent Information Option,” Request For Comments 3046 (January 2001), which is incorporated herein by reference. The location database may then store a location for the client device, based on the hardware element's location, and associate that location with the IP address assigned to the client device. Thus, the outbound proxy server can access the location database to determine a client device's location based on the client device's IP address, i.e., the source IP address included in the SIP INVITE message from the client device.
In another exemplary embodiment, the outbound proxy server obtains the location information from the access network by invoking an active network location function of the access network. The active network location function could involve, for example, a wireless triangulation technique and/or network-assisted GPS. Such active approaches may be more time consuming than looking up a previously-obtained location stored in a location database. In order to obtain a location more quickly, the active network location function may, at first, provide only an initial approximation of the client device's location. Later, the active network location function may follow up with a more precise location of the client device. The outbound proxy server may use the initial approximation of the client device's location, inserting the initial approximation into the SIP INVITE message that the outbound proxy server then forwards. To remain in the signaling path, the outbound proxy server may also insert a record route header into the SIP INVITE message. Then, when the outbound proxy server receives a more precise location of the client device from the active network function, the outbound proxy server may send a follow-up message with the more precise location.
In some cases, the outbound proxy server may be unable to obtain a specific location for the client device from the access network. This may occur when the source IP address of the SIP INVITE message is not the client device's actual IP address, for example, because the client device is using Network Address Translation (NAT) or because the client device is communicating via a Virtual Private Network (VPN). In such cases, the source IP address of the SIP INVITE message might not be listed in the location database at all. Alternatively, the location database might list only a generic location for the source IP address, e.g., a location describing the entire area served by the access network, rather than a specific location. Such a generic location might be useful to determine which PSAP should answer the call, but might not be useful for dispatching assistance to the caller.
However, the client device may itself provide location information. For example, the client device could be manually provisioned with information regarding its location. If the client device is mobile, however, this client-provided location information might not be reliable. On the other hand, the client device might use a wireless positioning technology such as the Global Positioning System (GPS) to determine its position. A GPS-based position might be reliable, provided that it is current. Thus, in an exemplary embodiment, a network-provided location may be compared to a client-provided location to obtain a more reliable estimation of the client device's location than could be obtained from a single source of location information.
The evaluation of the network-provided location, if any, and the client-provided location, if any, could be performed by the outbound proxy server. However, in an exemplary embodiment, the outbound proxy server simply inserts the network-provided location into the SIP INVITE message and forwards the modified SIP INVITE message to an emergency services routing server. The emergency services routing server then determines which PSAP should receive the call based on any network-provided location and/or any client-provided location included in the message.
In an exemplary embodiment, the network-provided location may be identified as such in the SIP INVITE message. For example, the outbound proxy server may insert the network-provided location into a designated network-provided location field of the message. In so doing, the outbound proxy server may leave undisturbed any client-provided location that was already included in the message. For example, the client-provided location may be included in a client-provided location field that is separate from the network-provided location field. One benefit of retaining the client-provided location in the message is that if routing based on the network-provided location is incorrect, then the call could be re-routed based on the client-provided location.
In some cases, the outbound proxy server may receive a SIP INVITE message that already contains a network-provided location in a network-provided location field. This may occur, for example, when the client device is communicating via a private network that uses NAT. In particular, the private network may have its own outbound proxy server that inserts private network-provided locations into SIP INVITE messages that request emergency services calls. The private network's outbound proxy might obtain a private network-provided location from a private network location database, e.g., based on a client device's private network address. This approach can beneficially provide a more specific location for the client device than might be obtainable based on the client device's public IP address. Thus, when the outbound proxy server of the access network receives a SIP INVITE message that already contains a network-provided location, the outbound proxy server may retain this location rather than insert a location provided by the access network.
An emergency services routing server may then receive the SIP INVITE message from the outbound proxy server of the access network. At this point, the SIP INVITE message might contain both a network-provided location and a client-provided location. The routing server may evaluate the network-provided location and the client-provided to obtain a best estimate of the client device's location. The evaluation may involve determining whether the network-provided and client-provided locations are consistent, determining which location is more specific, and/or which location is more reliable. As a result of the evaluation, the routing server might use either the network-provided location or the client-provided location as the best estimate of the client device's location, or the routing server might combine the locations to develop its own best estimate of the client device's location. For example, if the network-provided location and client-provided location define distinct but overlapping areas based on their uncertainties, then the client device may be assumed to be located in the area of overlap.
In this regard, the emergency services routing server may apply an uncertainty model to the network-provided location and/or client-provided location in order to estimate the uncertainties of these locations. The uncertainty model that is applied may depend on the type and implementation of the technology that was used to obtain the location. For example, a location that was obtained based on the fact that the client device is communicating via a particular wireless access point may depend on how precisely the location of the wireless access point is known (e.g., based on a wiring diagram) and on the effective communication range of the wireless access point (e.g., a 100 meter radius for an 802.11 wireless access point that is located indoors). The emergency services routing server may determine which uncertainty model to apply based on one or more parameters included with the network-provided location and/or client-provided location in the SIP INVITE message. Alternatively, the SIP INVITE message may include an actual uncertainty for the network-provided location and/or client-provided location.
Once the routing server determines the best estimate of the client device's location, the routing server uses that location to determine which PSAP is appropriate for answering the call. For example, the routing server may access a PSAP coverage database that specifies which PSAPs serve which areas. To route the SIP INVITE message so that the emergency services call will be established to the appropriate PSAP, the routing server may replace the emergency services URI in the message with a URI that corresponds to the PSAP determined to be appropriate to answer the call. To determine PSAP URIs, the routing server may access a PSAP routing database.
In this way, the emergency services call can be established to the PSAP that serves the area in which the client device is located. Moreover, the PSAP may receive both a network-provided location and a client-provided location in the signaling used to set up the call. The PSAP may use one or more of these locations to determine where to dispatch emergency services. In addition, if the PSAP that answers the call is not appropriate, then the location information may be used to re-route the call to another PSAP.
2. Exemplary Network Architecture
Referring to the drawings, FIG. 1 is a simplified block diagram of an exemplary telecommunications network 10. Network 10 includes a wide-area network 12, which is communicatively coupled to a plurality of access networks, such as access network 14 and access network 16. For example, wide-area network 12 may correspond to the Internet, and access networks 14 and 16 may correspond to networks operated by two different ISPs to provide access to the Internet. Although FIG. 1 shows only two access networks, it is to be understood that wide-area network 12 could be coupled to many more access networks.
In an exemplary embodiment, networks 12, 14, and 16 are packet-switched networks that convey voice or other media in a packetized format. Thus, networks 12, 14, and 16 may route packets based on network addresses, such as by using the Internet Protocol (IP) protocol in combination with the User Datagram Protocol (UDP) or Transmission Control Protocol (TCP). The IP packets may be carried over lower level protocols, such as asynchronous transfer mode (ATM) protocols. Application layer protocols, such as the Session Initiation Protocol (SIP), may be used to set up and control voice calls and other communication sessions through networks 12, 14, and 16. Relevant aspects of SIP are described in Rosenberg, et al., “SIP: Session Initiation Protocol,” Request for Comments 3261 (June 2002), which is incorporated herein by reference. Networks 12, 14, and 16 may carry the voice or other media in such calls, as UDP/IP or TCP/IP packets, in a real-time packet media format, e.g., by using the real-time transport protocol (RTP). Relevant aspects of RTP are described in Schulzrinne, et al., “RTP: A Transport Protocol for Real-Time Applications,” Request for Comments 1889 (January 1996), which is incorporated herein by reference.
Access networks 14 and 16 may be communicatively coupled to network access devices such as DSL modems, cable modems, or routers. For purposes of illustration, FIG. 1 shows access network 14 connected to network access devices 18 and 20 and access network 16 connected to network access devices 22 and 24. It is to be understood, however, that each access network may be connected to many network access devices, which may be distributed over a wide area.
Client devices may, in turn, be able to communicate with network access devices 18, 20, 22, and 24 via either wired or wireless interfaces. For purposes of illustration, FIG. 1 shows network access devices 18, 20, 22, and 24 connected to wireless access points 26, 28, 30, and 32, respectively. In addition, FIG. 1 shows a wireless client device 34 in wireless communication with network access device 20 via wireless access point 28. Thus, at this location, client device 34 is able to access wide-area network 12 via wireless access point 28, network access device 20, and access network 14, for VoP calls and for other types of communication. However, client device 34 may be able to move to other locations where client device can access wide-area network 12, e.g., via a different network access device and/or a different access network. For example, client device 34 may move out of the wireless coverage provided by wireless access point 28 and into the wireless coverage area provided by wireless access point 30. At that point, client device 34 may then access wide-area network 12 via wireless access point 30, network access device 22 and access network 16, e.g., for VoP calls.
These different areas may be served by different PSAPs. For example, FIG. 1 shows wide-area network 12 communicatively coupled to PSAPs 36 and 38. PSAPs 36 and 38 may each include an answering center that answers emergency services calls, such as 9-1-1 calls, on behalf of a public safety organization. Such public safety organizations may include, for example, law enforcement, fire protection, and/or medical assistance organizations. However, a public safety organization may provide services in only a particular geographic area (e.g., a particular city, town, county, or metropolitan area) or in only a particular type of location (e.g., in a particular airport). For example, PSAP 36 may serve the area in which wireless access point 28 is located, and PSAP 38 may serve the area in which wireless access point 30 is located. This means that emergency services calls originating from wireless access point 28, e.g., from client device 34, should be routed to PSAP 36, rather than to PSAP 38. Similarly, emergency services calls originating from wireless access point 30 should be routed to PSAP 38.
PSAPs 36 and 38 could be directly connected to wide-area network 12, as shown in FIG. 1. However, it is to be understood that one or more of these PSAPs could be indirectly connected to wide-area network 12. For example, a PSAP may be connected to one or more circuit-switched elements, such as in the public switched telephone network (PSTN), which, in turn, may be communicatively coupled to wide-area network 12 via a media gateway that converts between packet-switched and circuit-switched media formats. In addition, although FIG. 1 shows only two PSAPs, wide-area network 12 could be communicatively coupled to any number of PSAPs.
To facilitate the routing of emergency services calls to the appropriate PSAPs, and to provide location information that the appropriate PSAP can use for dispatch purposes, access networks 14 and 16 may maintain the locations of client devices, for example, stored in location databases 40 and 42. An access network may determine the locations of client devices based on the locations of hardware elements that the client devices use to access the access network. In this regard, a network access device may be connected to an access network via different types of physical links. At least part of the physical link may include a hardware element in a fixed location, such as an optical fiber, coaxial cable, or telephone line. Thus, FIG. 1 shows network access devices 18 and 20 connected to a distribution hub 44 of access network 14 via physical links 46 and 48, respectively, and shows network access devices 22 and 24 connected to a distribution hub 50 of access network 16 via physical links 52 and 54, respectively. In the case that the network access devices are cable modems, these distribution hubs could be cable modem termination systems (CMTSs). In the case that the network access devices are DSL modems, the distribution hubs could be digital subscriber line access multiplexers (DSLAMs).
Each of physical links 46, 48, 52, and 54 may be connected to a single network access device or to a group of proximately-located network access devices. As a result, the general location of a client device can be determined by identifying the physical link that a client device is using for communication. The identification of the physical link that a client device is using may be made when the client device logs into the access network. For example, access networks 14 and 16 may include respective DHCP servers 56 and 58 that dynamically assign IP addresses to client devices when they log on. As part of the DHCP process, the distribution hub may inform the DHCP server of which physical link the client device is using. The distribution hub may identify the physical link, for example, as a particular circuit or port. The DHCP server may then push the physical link identification and the IP address assigned to the client device to the location database. The location database may then translate the physical link identification into a location, e.g., a street address where the terminus of the physical link is located.
For example, if client device 34 logs into access network 14 via network access device 20 using DSL, then distribution hub 44 may identify physical link 48 as corresponding to a telephone line that goes to the premises where network access device 20 is located. DHCP server 56 may dynamically assign an IP address to client device 34 and then push the IP address and physical link identification to location database 40. Location database 40 may then translate the physical link identification into the street address of the premises at which physical link 48 terminates. Location database to may store a correlation between this street address and the IP address assigned to client device 34.
Access networks 14 and 16 include outbound proxy servers 60 and 62, respectively. Outbound proxy servers 60 and 62 receive all initial VoP call requests, e.g., SIP INVITE messages, from client devices coupled to their respective access networks in order to determine whether the VoP call requests are requesting emergency services calls. For example, when outbound proxy server 60 determines that an emergency services call is being requested, it may identify the source IP address contained in the request message and obtain the location information that is correlated with that source IP address in location database 40. Outbound proxy server 60 may then insert this network-provided location information into the request message and forward the modified message to an emergency services routing server 64.
In an exemplary embodiment, emergency services routing server 64 receives messages forwarded from multiple access networks, for example, from outbound proxy server 60 in access network 14 and from outbound proxy server 62 in access network 16. As described in more detail below, routing server 64 then evaluates the location information provided in the message that it receives to determine how to route the message so that the emergency services call will be established to the appropriate PSAP. In this regard, routing server 64 may formulate a best estimate of the caller's location and then access a PSAP coverage database 66 to determine which PSAP serves this location. Routing server 64 may then access a routing database 68 to obtain a routing a routing address that can be used to route the call to the appropriate PSAP. Alternatively, PSAP coverage database 66 may itself provide PSAP routing addresses.
Although FIG. 1 shows a routing server separate from the outbound proxy servers, in some embodiments, the outbound proxy servers may also function as routing servers. In addition, although FIG. 1 shows various databases as being separate from the servers that access them, the database could be integrated with the servers. Thus, location database 40 could be integrated with outbound proxy server 60, and location database 42 could be integrated with outbound proxy server 62. Similarly, PSAP coverage database 66 and/or PSAP routing database 68 could be integrated with routing server 64.
3. Exemplary Operation
FIGS. 2-5 are flow charts illustrating steps of an exemplary method of operation. In this exemplary operation, SIP is the signaling protocol that the client device uses to set up calls. However, it is to be understood that SIP is exemplary only; other signaling protocols could be used. In addition, FIGS. 2-5 assume the network architecture shown in FIG. 1, though it is to be understood that other network architectures could be used.
With reference to FIG. 2, the process may begin when the user of a client device dials digits for an emergency services call, as indicated by block 100. The particular digits that the user dials may depend on the jurisdiction in which the user is located. For example, in many parts of the United States, an emergency services call can be placed by dialing “911.” In other areas, particularly outside of the United States, other digits may be used to place emergency services calls. However, the dialed digits may indicate an emergency services call without specifying which particular PSAP should answer the call. For example, there are many PSAPs in the United States that answer 9-1-1 calls.
In response to these dialed digits, the client device transmits, via an access network, a SIP INVITE message with an emergency services URI in a destination field, as indicated by block 102. The emergency services URI may include the digits that the user dialed, e.g., “911.” Alternatively, the emergency services URI may include a designation other than the dialed digits to indicate that an emergency services call is being requested. For example, the emergency services URI may include an “sos” designation that could be used to indicate an emergency services call independently of the particular digits the user dialed. As noted above, such emergency services URIs indicate that an emergency services call is requested without specifying which particular PSAP should answer the call. In still other cases, the SIP INVITE message may include other types of information to indicate that the client device is requesting establishment of an emergency services call.
The outbound proxy server of the access network receives the SIP INVITE message, as indicated by block 104. For example, with reference to FIG. 1, client device 34 may transmit the SIP INVITE message via wireless access point 20, in which case outbound proxy server 60 would received receive the message via access network 14. In some cases, the client device may specifically direct the SIP INVITE message to the outbound proxy server, e.g., because the client device has been configured to use the outbound proxy server for all initial call requests. In other cases, the access network, rather than the client device, may direct the SIP INVITE message to the outbound proxy server, e.g., using policy-based routing.
The outbound proxy server then determines whether the SIP INVITE message is requesting an emergency services call, e.g., by checking the destination field for an emergency services URI, as indicated by block 106. If the SIP INVITE message is not requesting an emergency services call, then the outbound proxy server may route the message in accordance with standard SIP routing procedures, as indicated by block 108. In this case, however, the SIP INVITE message contains is requesting an emergency services call. As a result, the outbound proxy server performs an emergency services routing procedure on the SIP INVITE message, as indicated by block 110.
FIG. 3, illustrates the steps taken by the outbound proxy server for a SIP INVITE message that requests an emergency services call. The outbound proxy server may first examine the SIP INVITE message to determine whether the message already contains a network-provided location, as indicated by block 112. This may occur, for example, when an outbound proxy server in a private network inserts a network-provided location into the SIP INVITE message before the message reaches the access network. A private network may have more specific information regarding a client device's location than the access network, because the access network may see only the client device's public address. Thus, a location provided by a private network may be retained as being more reliable than a location provided by the access network. Following this approach, when the SIP INVITE message already contains a network-provided location, the outbound proxy server may simply forward a SIP INVITE message to an emergency services routing server without inserting any additional location information, as indicated by block 114.
However, when the SIP INVITE message does not contain a network-provided location, the outbound proxy server may try to obtain a location of the client device from the access network. To do this, the outbound proxy server may identify the source IP address of the SIP INVITE message, as indicated by block 116. The outbound proxy server may then look up the source IP address in the access network's location database, as indicated by block 118. Whether this approach is successful may depend on whether the location database lists a location for the source IP address, as indicated by block 120.
If the outbound proxy server is able to obtain a location from the location database based on the source IP address, then the outbound proxy server inserts the location into a network-provided location field of the SIP INVITE message, as indicated by block 122. The outbound proxy server then forwards the modified SIP INVITE message to an emergency services routing server, as indicated by block 124.
The network-provided location field may be identified by a predefined header, which the outbound proxy server may also insert into the SIP INVITE message. By placing the location in a network-provided location field, the location can be tagged as having been provided by the access network and can be distinguished from any client-provided location that may also be included in the SIP INVITE message. In this regard, some client devices may be configured to include a location in any SIP INVITE message that is transmitted to request an emergency services call. Such client-provided location may be more or less reliable, e.g., depending on how it is obtained. For example, a manually provisioned location may not be reliable if the client device has moved. However, a GPS-derived location, if current, may be reliable. In any event, because the client-provided location can sometimes be reliable, it is preferable to retain it. Thus, the outbound proxy server preferably leaves undisturbed any client-provided location when inserting the network-provided location into the SIP INVITE message.
If, however, the location database does not list a location for the source IP address, the outbound proxy server may insert an indication into the SIP INVITE message that no network-provided location is available, as indicated by block 126. For example, the outbound proxy server may insert text such as “network-derived location information unavailable” into a network-provided location field. A network-provided location may be unavailable for any number of reasons. In some cases, the location database may simply not be current. In other cases, the client device may be communicating in such a way, e.g., through a VPN, that the client device's actual IP address is hidden.
Although FIG. 3 illustrates an example in which the outbound proxy server obtains a network-provided location of the client device by querying a location database, it is to be understood that the outbound proxy could obtain the network-provided location in other ways. For example, the outbound proxy server could, in response to determining that the SIP INVITE message is requesting an emergency services call but does not already contain a network-provided location, invoke an active network function of the access network. The outbound proxy server may insert into the SIP INVITE message an initial approximation of the client device's location that is obtained from the active network location function and then forward the SIP INVITE message to the emergency services routing server. The active network location function may later provide a more precise location, which the outbound proxy server may then forward to the emergency services routing server in a subsequent message.
FIG. 4 illustrates the steps that may be performed by the emergency services routing server to route the emergency services call to the appropriate PSAP. As indicated by block 130, the emergency services routing server receives the SIP INVITE message from the outbound proxy server. The emergency services routing server then identifies any network-provided location and any client-provided location that may be included in the SIP INVITE message, as indicated by block 132. How the emergency services routing server proceeds depends on whether the SIP INVITE message includes any location for the client device, whether provided by the network or the client, as indicated by block 134. If the message does not any client device location, then the emergency services routing server may route the SIP INVITE message to a default PSAP, as indicated by block 136. The default PSAP could be based, for example, on the identity of the outbound proxy server that sent the SIP INVITE message or on the source IP address of the message. Although this information might not pinpoint the location of the client device, the information may nonetheless indicate a general geographic area, such as a particular metropolitan area, that suggests an appropriate PSAP.
On the other hand, if the SIP INVITE message includes a network-provided location and/or client-provided location, then the emergency services routing server makes a best estimate of the client device's location based on the network-provided location and/or client-provided location, as indicated by block 138. Once the emergency services routing server has determined a best estimate of the client device's location, the routing server may access a PSAP coverage base to determine which PSAP serves that location, as indicated by block 140. The PSAP that serves that location will typically be the PSAP that is appropriate to receive the emergency services call. Thus, the emergency services routing server will route the SIP INVITE message so that the emergency services call will be established to that PSAP. To do this, the emergency services routing server may access a PSAP routing database to obtain a routing address that can be used to route the SIP INVITE message to the appropriate PSAP, as indicated by block 142. The emergency services routing server then routes the SIP INVITE message based on the PSAP routing address, as indicated by block 144. To do this, the emergency services routing server may replace the emergency services URI with a PSAP URI that corresponds to the appropriate PSAP and then route the SIP INVITE message in accordance with standard SIP routing procedures.
In this way, the emergency services call can be established to the appropriate PSAP. Moreover, the PSAP may learn the caller's location from the location information included in the call set-up signaling. With this location information, the PSAP may be able to dispatch timely assistance to the caller.
Although FIGS. 2-4 illustrate an example in which various steps are performed by the outbound proxy server of the access network being used by the client device and various steps are performed by an emergency services routing server, which may server multiple access networks, it is to be understood that these steps could be distributed among a greater or fewer number of network elements. For example, the outbound proxy server might be configured to perform the steps of the emergency services routing server, i.e., steps illustrated in FIG. 4.
FIG. 5 is a flow chart illustrating an exemplary algorithm for determining a best estimate of the client device's location for purposes of determining the appropriate PSAP. Thus, if an emergency services routing server determines a best estimate of the client device's location for purposes of determining the appropriate PSAP, e.g., as in block 138 of FIG. 4, then the emergency services routing server may apply this algorithm. Alternatively, the outbound proxy server of the client device's access network, or some other network element, may apply this algorithm.
In accordance with this exemplary algorithm, the first step might be to determine what location information is included in the SIP INVITE message, as indicated by block 200. If there is only a network-provided location, then the network-provided location is used to determine the appropriate PSAP, as indicated by block 202. If there is only a client-provided location, then the client-provided location is used to determine the appropriate PSAP, as indicated by block 204.
However, if the SIP INVITE message includes both network-provided location and a client-provided location, then the algorithm may determine whether these locations are consistent, as indicated by block 206. To determine whether the network-provided and client-provided locations are consistent, partially consistent, or inconsistent, the emergency services routing server may apply uncertainty models to estimate the uncertainties of these locations. Alternatively, the SIP INVITE message may already include uncertainties for the network-provided location and/or client-provided location.
If the network-provided and client-provided locations are consistent, then the more specific location is used to determine the appropriate PSAP, as indicated by block 208. On the other hand, if the network-provided and client-provided locations are not consistent, then one of the two locations may be deemed to be more reliable based on various considerations. In an exemplary embodiment, the network-provided location may be deemed to be more reliable, and, thus, used to determine the appropriate PSAP, as indicated by block 202. This approach is based on the view that the client-provided location may have been manually configured, whereas the network-provided location may be determined automatically.
In some cases, the network-provided location and client-provided location may be deemed to be partially consistent. This may occur, for example, when the uncertainties in the two locations define different but overlapping areas in which the client device could be located. In such cases, a location in the overlap area could be used to determine the appropriate PSAP, as indicated by block 210.
4. Conclusion
Exemplary embodiments of the present invention have been described above. Those skilled in the art will understand, however, that changes and modifications may be made to these embodiments without departing from the true scope and spirit of the invention, which is defined by the claims.

Claims (19)

1. A method for emergency services call routing, said method comprising:
receiving from a client device, via a voice-over-packet (VoP) access network, a message requesting an emergency services call, said message including a client-provided location of said client device;
obtaining from said VoP access network a network-provided location of said client device;
determining whether said network-provided location and said client-provided location are consistent;
determining an appropriate public safety answering point (PSAP), from among a plurality of PSAPs, based on at least one of said network-provided location and said client-provided location; and
routing said emergency services call to said appropriate PSAP.
2. The method of claim 1, wherein said emergency services call is a 9-1-1 call.
3. The method of claim 1, wherein said message is a Session Initiation Protocol (SIP) INVITE message.
4. The method of claim 1, wherein obtaining from said VoP access network a network-provided location of said client device comprises:
accessing a location database of said VoP access network to obtain said network-provided location.
5. The method of claim 4, wherein said message includes a source address and wherein said location database correlates locations of client devices with source addresses.
6. The method of claim 5, wherein accessing a location database of said VoP access network to obtain said network-provided location comprises:
identifying a location that is correlated in said location database with said source address.
7. The method of claim 6, wherein said source address is an Internet Protocol (IP) address.
8. The method of claim 1, further comprising:
inserting said network-provided location into said message.
9. The method of claim 1, wherein determining an appropriate public safety answering point (PSAP), from among a plurality of PSAPs, based on at least one of said network-provided location and said client-provided location comprises:
determining that said network-provided location and said client-provided location are consistent; and
determining which of said network-provided and client-provided locations is more specific.
10. The method of claim 9, wherein determining an appropriate public safety answering point (PSAP), from among a plurality of PSAPs, based on at least one of said network-provided location and said client-provided location comprises:
determining that said network-provided location is more specific; and
identifying said appropriate PSAP based on said network-provided location.
11. The method of claim 9, wherein determining an appropriate public safety answering point (PSAP), from among a plurality of PSAPs, based on at least one of said network-provided location and said client-provided location comprises:
determining that said client-provided location is more specific; and
identifying said appropriate PSAP based on said client-provided location.
12. The method of claim 1, wherein determining an appropriate public safety answering point (PSAP), from among a plurality of PSAPs, based on at least one of said network-provided location and said client-provided location comprises:
determining that said network-provided location and said client-provided location are inconsistent; and
identifying said appropriate PSAP based on said network-provided location.
13. The method of claim 1, wherein obtaining from said VoP access network a network-provided location of said client device comprises:
invoking an active network location function of said VoP access network to obtain said network-provided location.
14. A method for providing location information for emergency services calls, said method comprising:
a client device logging into a voice-over-packet (VoP) access network via a physical link;
dynamically assigning a network address to said client device;
storing in a location database a correlation between said network address and a location associated with said physical link;
an outbound proxy server receiving from said client device, via said VoP access network, a Session Initiation Protocol (SIP) INVITE message, said SIP INVITE message including said network address;
said outbound proxy server determining that said SIP INVITE message is requesting an emergency services call and, responsively, accessing said location database to obtain said location based on said network address; and
said outbound proxy server inserting said location into said SIP INVITE message as a network-provided location.
15. The method of claim 14, wherein determining that said SIP INVITE message is requesting an emergency services call comprises:
determining that said SIP INVITE message contains an emergency services URI.
16. The method of claim 15, wherein said SIP INVITE message contains a client-provided location, further comprising:
determining an appropriate public safety answering point (PSAP), from among a plurality of PSAPs, based on at least one of said network-provided location and said client-provided location; and
replacing said emergency services URI with a PSAP URI corresponding to said appropriate PSAP.
17. The method of claim 14, further comprising:
said VoP access network diverting said SIP INVITE message to said outbound proxy server.
18. A system for providing location information for emergency services calls, said system comprising:
a voice-over-packet (VoP) access network to which a plurality of client devices are communicatively coupled;
an outbound proxy server communicatively coupled to said VoP access network so as to receive call requests from said client devices, wherein in response to an emergency services call request from a given one of said client devices said outbound proxy server is configured to (i) obtain a network-provided location of said given client device, based on a source address of said emergency services call request or by invoking an active network location function of said VoP access network, and (ii) insert said network-provided location into said emergency services call request; and
a routing server communicatively coupled to said outbound proxy server, wherein said routing server is configured to route said emergency services call request to an appropriate public safety answering point (PSAP), from among a plurality of PSAPs, based on an evaluation of said network-provided location and any client-provided location in said emergency services call request, wherein said evaluation involves determining whether said network-provided location and said any client-provided location are consistent.
19. The system of claim 18, further comprising:
a location database, wherein said location database correlates locations of said client devices with source addresses assigned to said client devices,
said outbound proxy server being configured to obtain said network-provided location of said given client device from said location database based on said source address of said emergency services call request.
US11/185,094 2005-07-20 2005-07-20 Method and system for using a network-provided location for voice-over-packet emergency services calls Active 2028-08-12 US7602886B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/185,094 US7602886B1 (en) 2005-07-20 2005-07-20 Method and system for using a network-provided location for voice-over-packet emergency services calls

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/185,094 US7602886B1 (en) 2005-07-20 2005-07-20 Method and system for using a network-provided location for voice-over-packet emergency services calls

Publications (1)

Publication Number Publication Date
US7602886B1 true US7602886B1 (en) 2009-10-13

Family

ID=41138043

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/185,094 Active 2028-08-12 US7602886B1 (en) 2005-07-20 2005-07-20 Method and system for using a network-provided location for voice-over-packet emergency services calls

Country Status (1)

Country Link
US (1) US7602886B1 (en)

Cited By (65)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070021125A1 (en) * 2005-07-19 2007-01-25 Yinjun Zhu Location service requests throttling
US20070026847A1 (en) * 2005-08-01 2007-02-01 Polk James M Technique for displaying information ancillary to a location of an entity in a communication network
US20070025339A1 (en) * 2005-07-29 2007-02-01 Cisco Technology, Inc. Acquiring information in a communication network relative to a location
US20070060097A1 (en) * 2005-08-02 2007-03-15 Edge Stephen W VOIP emergency call support
US20070218920A1 (en) * 2006-03-16 2007-09-20 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for location determination in fixed communication access networks
US20090059894A1 (en) * 2007-08-27 2009-03-05 James Jackson Methods and apparatus to select a peered voice over internet protocol (voip) border element
US20090196284A1 (en) * 2006-06-28 2009-08-06 Nokia Siemens Networks Gmbh & Co.Kg Method for Providing an Emergency Call Service for VoIP Subscribers
US20090219921A1 (en) * 2006-03-22 2009-09-03 Nokia Siemens Networks Gmbh & Co. Kg Method for localization and location-related connection of a mobile voice-over-ip subscriber to an emergency call station
US20100248740A1 (en) * 2009-03-26 2010-09-30 Andrew Llc System and method for managing created location contexts in a location server
US7856236B2 (en) 2002-03-28 2010-12-21 Telecommunication Systems, Inc. Area watcher for wireless network
US20100323674A1 (en) * 2003-06-12 2010-12-23 Yinjun Zhu Mobile based area event handling when currently visited network does not cover area
US7903587B2 (en) 2008-05-30 2011-03-08 Telecommunication Systems, Inc. Wireless emergency services protocols translator between ansi-41 and VoIP emergency services protocols
US7933385B2 (en) 2005-08-26 2011-04-26 Telecommunication Systems, Inc. Emergency alert for voice over internet protocol (VoIP)
US7966013B2 (en) 2006-11-03 2011-06-21 Telecommunication Systems, Inc. Roaming gateway enabling location based services (LBS) roaming for user plane in CDMA networks without requiring use of a mobile positioning center (MPC)
US20110188411A1 (en) * 2010-02-02 2011-08-04 Stefano Faccin System and method for packetized emergency messages
US20110189971A1 (en) * 2010-02-02 2011-08-04 Stefano Faccin System and method for packetized emergency messages
US20110188416A1 (en) * 2010-02-02 2011-08-04 Stefano Faccin System and method for packetized emergency messages
US8032112B2 (en) 2002-03-28 2011-10-04 Telecommunication Systems, Inc. Location derived presence information
US8059789B2 (en) 2006-02-24 2011-11-15 Telecommunication Systems, Inc. Automatic location identification (ALI) emergency services pseudo key (ESPK)
US8068587B2 (en) 2008-08-22 2011-11-29 Telecommunication Systems, Inc. Nationwide table routing of voice over internet protocol (VOIP) emergency calls
US8150363B2 (en) 2006-02-16 2012-04-03 Telecommunication Systems, Inc. Enhanced E911 network access for call centers
US8150364B2 (en) 2003-12-19 2012-04-03 Telecommunication Systems, Inc. Enhanced E911 network access for a call center using session initiation protocol (SIP) messaging
US8208605B2 (en) 2006-05-04 2012-06-26 Telecommunication Systems, Inc. Extended efficient usage of emergency services keys
US8290505B2 (en) 2006-08-29 2012-10-16 Telecommunications Systems, Inc. Consequential location derived information
US8442481B2 (en) 2006-05-16 2013-05-14 RedSky Technologies, Inc. Emergency location information gateway for public safety answering points (PSAPs) and method of use
US8467320B2 (en) 2005-10-06 2013-06-18 Telecommunication Systems, Inc. Voice over internet protocol (VoIP) multi-user conferencing
US8532266B2 (en) 2006-05-04 2013-09-10 Telecommunication Systems, Inc. Efficient usage of emergency services keys
US8538458B2 (en) 2005-04-04 2013-09-17 X One, Inc. Location sharing and tracking using mobile phones or other wireless devices
US8576991B2 (en) 2008-03-19 2013-11-05 Telecommunication Systems, Inc. End-to-end logic tracing of complex call flows in a distributed call system
US20140036658A1 (en) * 2007-02-16 2014-02-06 At&T Mobility Ii Llc Systems and Methods for Alternative Routing of Voice Over IP Originated Emergency Calls
US8666397B2 (en) 2002-12-13 2014-03-04 Telecommunication Systems, Inc. Area event handling when current network does not cover target area
US8682321B2 (en) 2011-02-25 2014-03-25 Telecommunication Systems, Inc. Mobile internet protocol (IP) location
US8688087B2 (en) 2010-12-17 2014-04-01 Telecommunication Systems, Inc. N-dimensional affinity confluencer
US8831556B2 (en) 2011-09-30 2014-09-09 Telecommunication Systems, Inc. Unique global identifier header for minimizing prank emergency 911 calls
US8942743B2 (en) 2010-12-17 2015-01-27 Telecommunication Systems, Inc. iALERT enhanced alert manager
US8983047B2 (en) 2013-03-20 2015-03-17 Telecommunication Systems, Inc. Index of suspicion determination for communications request
US8984591B2 (en) 2011-12-16 2015-03-17 Telecommunications Systems, Inc. Authentication via motion of wireless device movement
US9088614B2 (en) 2003-12-19 2015-07-21 Telecommunications Systems, Inc. User plane location services over session initiation protocol (SIP)
US9137770B2 (en) 2005-09-15 2015-09-15 Qualcomm Incorporated Emergency circuit-mode call support
US9154906B2 (en) 2002-03-28 2015-10-06 Telecommunication Systems, Inc. Area watcher for wireless network
US9210621B1 (en) 2013-09-23 2015-12-08 Sprint Spectrum L.P. Method and system for facilitating service level continuity
US9208346B2 (en) 2012-09-05 2015-12-08 Telecommunication Systems, Inc. Persona-notitia intellection codifier
US9232062B2 (en) 2007-02-12 2016-01-05 Telecommunication Systems, Inc. Mobile automatic location identification (ALI) for first responders
US9258386B2 (en) 2005-11-18 2016-02-09 Telecommunication Systems, Inc. Voice over internet protocol (VoIP) mobility detection
US9264537B2 (en) 2011-12-05 2016-02-16 Telecommunication Systems, Inc. Special emergency call treatment based on the caller
US9282451B2 (en) 2005-09-26 2016-03-08 Telecommunication Systems, Inc. Automatic location identification (ALI) service requests steering, connection sharing and protocol translation
US9301191B2 (en) 2013-09-20 2016-03-29 Telecommunication Systems, Inc. Quality of service to over the top applications used with VPN
US9307372B2 (en) 2012-03-26 2016-04-05 Telecommunication Systems, Inc. No responders online
US9313638B2 (en) 2012-08-15 2016-04-12 Telecommunication Systems, Inc. Device independent caller data access for emergency calls
US9313637B2 (en) 2011-12-05 2016-04-12 Telecommunication Systems, Inc. Wireless emergency caller profile data delivery over a legacy interface
US9338153B2 (en) 2012-04-11 2016-05-10 Telecommunication Systems, Inc. Secure distribution of non-privileged authentication credentials
US9384339B2 (en) 2012-01-13 2016-07-05 Telecommunication Systems, Inc. Authenticating cloud computing enabling secure services
US9408034B2 (en) 2013-09-09 2016-08-02 Telecommunication Systems, Inc. Extended area event for network based proximity discovery
US9420425B1 (en) 2015-09-01 2016-08-16 Sprint Spectrum L.P. Methods and systems for determining a change in location of a portable wireless access point
US9456301B2 (en) 2012-12-11 2016-09-27 Telecommunication Systems, Inc. Efficient prisoner tracking
US9479897B2 (en) 2013-10-03 2016-10-25 Telecommunication Systems, Inc. SUPL-WiFi access point controller location based services for WiFi enabled mobile devices
US9479344B2 (en) 2011-09-16 2016-10-25 Telecommunication Systems, Inc. Anonymous voice conversation
US9510171B1 (en) 2012-03-22 2016-11-29 Sprint Spectrum L.P. Provisioning mobile station with destination communication address during de-registration
US9516104B2 (en) 2013-09-11 2016-12-06 Telecommunication Systems, Inc. Intelligent load balancer enhanced routing
US9544260B2 (en) 2012-03-26 2017-01-10 Telecommunication Systems, Inc. Rapid assignment dynamic ownership queue
US9599717B2 (en) 2002-03-28 2017-03-21 Telecommunication Systems, Inc. Wireless telecommunications location based services scheme selection
US20170180966A1 (en) * 2015-12-17 2017-06-22 Rave Wireless, Inc. Notification of emergencies based on wireless signal recognition
US9924449B1 (en) 2015-04-14 2018-03-20 Sprint Spectrum L.P. Methods and systems for controlling implementation of a location-based service for a wireless communication device
US10631128B1 (en) * 2018-11-08 2020-04-21 Capital One Services, Llc Systems and methods for facilitating dynamic remote assistance networks
US10880219B2 (en) * 2012-04-27 2020-12-29 Level 3 Communications, Llc Load balancing of network communications

Citations (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6427001B1 (en) 2001-06-07 2002-07-30 Bellsouth Intellectual Property Corporation System and method for notification of 911 telephone calls using a link monitoring system
US6570974B1 (en) 1998-12-31 2003-05-27 At&T Corp. Cable connected network server platform for telephone white-yellow page services and emergency 911 location identification
US20030109245A1 (en) 2001-11-05 2003-06-12 Mccalmont Patti L Routing of emergency calls based on geographic location of originating telephone end office
US6650901B1 (en) * 2000-02-29 2003-11-18 3Com Corporation System and method for providing user-configured telephone service in a data network telephony system
US6665611B1 (en) 2001-06-19 2003-12-16 Cisco Technology, Inc. System for discovering and maintaining geographic location information in a computer network to enable emergency services
US6678357B2 (en) 2001-09-26 2004-01-13 Siemens Information And Communication Networks, Inc. Internet protocol (IP) emergency connections (ITEC) telephony
US20040057425A1 (en) 2002-09-25 2004-03-25 Brouwer Wim L. Location identification for IP telephony to support emergency services
US6744859B1 (en) 2002-05-21 2004-06-01 Intrado Inc. System and apparatus for providing telephone communication between a caller and a special number call answering facility
US6771742B2 (en) 2001-11-05 2004-08-03 Intrado Inc. Geographic routing of emergency service call center emergency calls
US20040190497A1 (en) 2003-03-29 2004-09-30 Mark Clinton Knox System and method for routing telephone calls involving internet protocol network
US20040192271A1 (en) 2003-03-29 2004-09-30 Gerald Eisner System and method for providing mobile caller information to a special number service station
US20050020241A1 (en) 1999-07-29 2005-01-27 Bryan Holland Locator system
US20050020281A1 (en) 1999-07-29 2005-01-27 Bryan Holland Locator system
US20050083911A1 (en) 2003-10-21 2005-04-21 3Com Corporation, A Corporation Of The State Of Delaware IP-based enhanced emergency services using intelligent client devices
US20050111630A1 (en) 2003-11-24 2005-05-26 Potorny Martin C. 911 Emergency voice/data telecommunication network
US20050174991A1 (en) * 2004-01-30 2005-08-11 Scott Keagy Apparatus and method for interfacing packet-based phone services with emergency call centers
US20050213716A1 (en) * 2004-03-23 2005-09-29 Yinjun Zhu Solutions for voice over internet protocol (VoIP) 911 location services
US20060072547A1 (en) * 2004-09-29 2006-04-06 Lucent Technologies Inc. Systems and methods for serving VolP emergency calls
US7042985B1 (en) * 2003-08-27 2006-05-09 Bellsouth Intellectual Property Corporation Method, system and computer program product for providing a regional E911 network
US20060193446A1 (en) * 2005-02-25 2006-08-31 Mci, Inc. Systems and methods for providing 9-1-1 services to nomadic internet telephony callers
US20060281437A1 (en) * 2005-06-13 2006-12-14 Qwest Communications International Inc. Systems and methods for supporting E911 emergency services in a data communications network
US20070003024A1 (en) * 2005-06-22 2007-01-04 Cml Emergency Services Inc. Network emergency call taking system and method

Patent Citations (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6570974B1 (en) 1998-12-31 2003-05-27 At&T Corp. Cable connected network server platform for telephone white-yellow page services and emergency 911 location identification
US20050026589A1 (en) 1999-07-29 2005-02-03 Bryan Holland Remote locator system using A E911-enabled wireless system
US20050020281A1 (en) 1999-07-29 2005-01-27 Bryan Holland Locator system
US20050020241A1 (en) 1999-07-29 2005-01-27 Bryan Holland Locator system
US20050020242A1 (en) 1999-07-29 2005-01-27 Bryan Holland Locator system
US20050020280A1 (en) 1999-07-29 2005-01-27 Bryan Holland Mobile station-based locator system
US6650901B1 (en) * 2000-02-29 2003-11-18 3Com Corporation System and method for providing user-configured telephone service in a data network telephony system
US6427001B1 (en) 2001-06-07 2002-07-30 Bellsouth Intellectual Property Corporation System and method for notification of 911 telephone calls using a link monitoring system
US6665611B1 (en) 2001-06-19 2003-12-16 Cisco Technology, Inc. System for discovering and maintaining geographic location information in a computer network to enable emergency services
US6678357B2 (en) 2001-09-26 2004-01-13 Siemens Information And Communication Networks, Inc. Internet protocol (IP) emergency connections (ITEC) telephony
US6771742B2 (en) 2001-11-05 2004-08-03 Intrado Inc. Geographic routing of emergency service call center emergency calls
US20040184584A1 (en) 2001-11-05 2004-09-23 Intrado Inc. Geographic routing of emergency service call center emergency calls
US20030109245A1 (en) 2001-11-05 2003-06-12 Mccalmont Patti L Routing of emergency calls based on geographic location of originating telephone end office
US6744859B1 (en) 2002-05-21 2004-06-01 Intrado Inc. System and apparatus for providing telephone communication between a caller and a special number call answering facility
US20040057425A1 (en) 2002-09-25 2004-03-25 Brouwer Wim L. Location identification for IP telephony to support emergency services
US20040192271A1 (en) 2003-03-29 2004-09-30 Gerald Eisner System and method for providing mobile caller information to a special number service station
US20040190497A1 (en) 2003-03-29 2004-09-30 Mark Clinton Knox System and method for routing telephone calls involving internet protocol network
US7042985B1 (en) * 2003-08-27 2006-05-09 Bellsouth Intellectual Property Corporation Method, system and computer program product for providing a regional E911 network
US20050083911A1 (en) 2003-10-21 2005-04-21 3Com Corporation, A Corporation Of The State Of Delaware IP-based enhanced emergency services using intelligent client devices
US20050111630A1 (en) 2003-11-24 2005-05-26 Potorny Martin C. 911 Emergency voice/data telecommunication network
US20050174991A1 (en) * 2004-01-30 2005-08-11 Scott Keagy Apparatus and method for interfacing packet-based phone services with emergency call centers
US20050213716A1 (en) * 2004-03-23 2005-09-29 Yinjun Zhu Solutions for voice over internet protocol (VoIP) 911 location services
US20060072547A1 (en) * 2004-09-29 2006-04-06 Lucent Technologies Inc. Systems and methods for serving VolP emergency calls
US20060193446A1 (en) * 2005-02-25 2006-08-31 Mci, Inc. Systems and methods for providing 9-1-1 services to nomadic internet telephony callers
US20060281437A1 (en) * 2005-06-13 2006-12-14 Qwest Communications International Inc. Systems and methods for supporting E911 emergency services in a data communications network
US20070003024A1 (en) * 2005-06-22 2007-01-04 Cml Emergency Services Inc. Network emergency call taking system and method

Non-Patent Citations (14)

* Cited by examiner, † Cited by third party
Title
"How VOIP E911 might work," Vonage(TM) VoIP Forum, Mar. 2005.
Avaya, Inc., "Comments on IP Telephony Support for Emergency Calling Service," TR 41.4.1/01-08-002, Jul. 25, 2001.
Brad Templeton, "DHCP Option for street address, PSAP for VoIP E911," Brad Ideas, May 2, 2005.
Cisco Systems, Inc., "Cisco Emergency Responder Version 1.2 (2)", Data Sheet, Sep. 2004.
Donny Jackson, "Nortel proposes VoIP 911 solution," Mobile Radio Technology, May 1, 2004.
H. Schulzrinne, Internet Draft, "Emergency Services for Internet Telephony Systems," Oct. 18, 2004.
H. Schulzrinne, Internet Draft, "Emergency Services URI for the Session Initiation Protocol," Feb. 8, 2004.
H. Schulzrinne, Internet Draft, "Requirements for Emergency Context Resolution with Internet Technologies," May 5, 2005.
H. Schulzrinne, Request for Comments 3319, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers," Jul. 2003.
H. Schulzrinne, Request for Comments 3361, "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers," Aug. 2002.
J. Polk et al., Request for Comments 3825, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information," Jul. 2004.
M. Patrick, Request for Comments 3046, "DHCP Relay Agent Information Option," Jan. 2001.
Schulzrinne, Internet Draft, "Providing Emergency Call Services for SIP-based Internet Telephony," Jul. 13, 2000.
Texas A&M University, Internet2 Technology Evaluation Center, "NG 911 Project," Mar. 29, 2005.

Cited By (99)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9220958B2 (en) 2002-03-28 2015-12-29 Telecommunications Systems, Inc. Consequential location derived information
US9599717B2 (en) 2002-03-28 2017-03-21 Telecommunication Systems, Inc. Wireless telecommunications location based services scheme selection
US8032112B2 (en) 2002-03-28 2011-10-04 Telecommunication Systems, Inc. Location derived presence information
US9154906B2 (en) 2002-03-28 2015-10-06 Telecommunication Systems, Inc. Area watcher for wireless network
US7856236B2 (en) 2002-03-28 2010-12-21 Telecommunication Systems, Inc. Area watcher for wireless network
US8666397B2 (en) 2002-12-13 2014-03-04 Telecommunication Systems, Inc. Area event handling when current network does not cover target area
US8249589B2 (en) 2003-06-12 2012-08-21 Telecommunication Systems, Inc. Mobile based area event handling when currently visited network does not cover area
US20100323674A1 (en) * 2003-06-12 2010-12-23 Yinjun Zhu Mobile based area event handling when currently visited network does not cover area
US8150364B2 (en) 2003-12-19 2012-04-03 Telecommunication Systems, Inc. Enhanced E911 network access for a call center using session initiation protocol (SIP) messaging
US9088614B2 (en) 2003-12-19 2015-07-21 Telecommunications Systems, Inc. User plane location services over session initiation protocol (SIP)
US9125039B2 (en) 2003-12-19 2015-09-01 Telecommunication Systems, Inc. Enhanced E911 network access for a call center using session initiation protocol (SIP) messaging
US9197992B2 (en) 2003-12-19 2015-11-24 Telecommunication Systems, Inc. User plane location services over session initiation protocol (SIP)
US8369825B2 (en) 2003-12-19 2013-02-05 Telecommunication Systems, Inc. Enhanced E911 network access for a call center using session initiation protocol (SIP) messaging
US8538458B2 (en) 2005-04-04 2013-09-17 X One, Inc. Location sharing and tracking using mobile phones or other wireless devices
US20070021125A1 (en) * 2005-07-19 2007-01-25 Yinjun Zhu Location service requests throttling
US9288615B2 (en) 2005-07-19 2016-03-15 Telecommunication Systems, Inc. Location service requests throttling
US8660573B2 (en) 2005-07-19 2014-02-25 Telecommunications Systems, Inc. Location service requests throttling
US20070025339A1 (en) * 2005-07-29 2007-02-01 Cisco Technology, Inc. Acquiring information in a communication network relative to a location
US8412804B2 (en) 2005-07-29 2013-04-02 Cisco Technology, Inc. Acquiring information in a communication network relative to a location
US8190134B2 (en) * 2005-08-01 2012-05-29 Cisco Technology, Inc. Technique for displaying information ancillary to a location of an entity in a communication network
US20070026847A1 (en) * 2005-08-01 2007-02-01 Polk James M Technique for displaying information ancillary to a location of an entity in a communication network
US9788181B2 (en) 2005-08-02 2017-10-10 Qualcomm Incorporated VOIP emergency call support
US20180199180A1 (en) * 2005-08-02 2018-07-12 Qualcomm Incorporated Voip emergency call support
US10178522B2 (en) * 2005-08-02 2019-01-08 Qualcomm Incorporated VoIP emergency call support
US10708748B2 (en) * 2005-08-02 2020-07-07 Qualcomm Incorporated VoIP emergency call support
US20070060097A1 (en) * 2005-08-02 2007-03-15 Edge Stephen W VOIP emergency call support
US9390615B2 (en) 2005-08-26 2016-07-12 Telecommunication Systems, Inc. Emergency alert for voice over internet protocol (VoIP)
US7933385B2 (en) 2005-08-26 2011-04-26 Telecommunication Systems, Inc. Emergency alert for voice over internet protocol (VoIP)
US9137770B2 (en) 2005-09-15 2015-09-15 Qualcomm Incorporated Emergency circuit-mode call support
US9282451B2 (en) 2005-09-26 2016-03-08 Telecommunication Systems, Inc. Automatic location identification (ALI) service requests steering, connection sharing and protocol translation
US8467320B2 (en) 2005-10-06 2013-06-18 Telecommunication Systems, Inc. Voice over internet protocol (VoIP) multi-user conferencing
US9258386B2 (en) 2005-11-18 2016-02-09 Telecommunication Systems, Inc. Voice over internet protocol (VoIP) mobility detection
US9420444B2 (en) 2006-02-16 2016-08-16 Telecommunication Systems, Inc. Enhanced E911 network access for call centers
US8150363B2 (en) 2006-02-16 2012-04-03 Telecommunication Systems, Inc. Enhanced E911 network access for call centers
US8406728B2 (en) 2006-02-16 2013-03-26 Telecommunication Systems, Inc. Enhanced E911 network access for call centers
US8059789B2 (en) 2006-02-24 2011-11-15 Telecommunication Systems, Inc. Automatic location identification (ALI) emergency services pseudo key (ESPK)
US20070218920A1 (en) * 2006-03-16 2007-09-20 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for location determination in fixed communication access networks
US20090219921A1 (en) * 2006-03-22 2009-09-03 Nokia Siemens Networks Gmbh & Co. Kg Method for localization and location-related connection of a mobile voice-over-ip subscriber to an emergency call station
US8249055B2 (en) * 2006-03-22 2012-08-21 Nokia Siemens Networks Gmbh & Co. Kg Method for localization and location-related connection of a mobile Voice-over-IP subscriber to an emergency call station
US9584661B2 (en) 2006-05-04 2017-02-28 Telecommunication Systems, Inc. Extended efficient usage of emergency services keys
US8532266B2 (en) 2006-05-04 2013-09-10 Telecommunication Systems, Inc. Efficient usage of emergency services keys
US8885796B2 (en) 2006-05-04 2014-11-11 Telecommunications Systems, Inc. Extended efficient usage of emergency services keys
US8208605B2 (en) 2006-05-04 2012-06-26 Telecommunication Systems, Inc. Extended efficient usage of emergency services keys
US8442481B2 (en) 2006-05-16 2013-05-14 RedSky Technologies, Inc. Emergency location information gateway for public safety answering points (PSAPs) and method of use
US20090196284A1 (en) * 2006-06-28 2009-08-06 Nokia Siemens Networks Gmbh & Co.Kg Method for Providing an Emergency Call Service for VoIP Subscribers
US8290505B2 (en) 2006-08-29 2012-10-16 Telecommunications Systems, Inc. Consequential location derived information
US8190151B2 (en) 2006-11-03 2012-05-29 Telecommunication Systems, Inc. Roaming gateway enabling location based services (LBS) roaming for user plane in CDMA networks without requiring use of a mobile positioning center (MPC)
US7966013B2 (en) 2006-11-03 2011-06-21 Telecommunication Systems, Inc. Roaming gateway enabling location based services (LBS) roaming for user plane in CDMA networks without requiring use of a mobile positioning center (MPC)
US9232062B2 (en) 2007-02-12 2016-01-05 Telecommunication Systems, Inc. Mobile automatic location identification (ALI) for first responders
US9185537B2 (en) * 2007-02-16 2015-11-10 At&T Mobility Ii Llc Systems and methods for alternative routing of voice over IP originated emergency calls
US20140036658A1 (en) * 2007-02-16 2014-02-06 At&T Mobility Ii Llc Systems and Methods for Alternative Routing of Voice Over IP Originated Emergency Calls
US20090059894A1 (en) * 2007-08-27 2009-03-05 James Jackson Methods and apparatus to select a peered voice over internet protocol (voip) border element
US9124603B2 (en) * 2007-08-27 2015-09-01 At&T Intellectual Property I., L.P. Methods and apparatus to select a peered voice over internet protocol (VoIP) border element
US8576991B2 (en) 2008-03-19 2013-11-05 Telecommunication Systems, Inc. End-to-end logic tracing of complex call flows in a distributed call system
US9042522B2 (en) 2008-03-19 2015-05-26 Telecommunication Systems, Inc. End-to-end logic tracing of complex call flows in a distributed call system
US9467560B2 (en) 2008-03-19 2016-10-11 Telecommunication Systems, Inc. End-to-end logic tracing of complex call flows in a distributed call system
US9001719B2 (en) 2008-05-30 2015-04-07 Telecommunication Systems, Inc. Wireless emergency services protocols translator between ANSI-41 and VoIP emergency services protocols
US9167403B2 (en) 2008-05-30 2015-10-20 Telecommunication Systems, Inc. Wireless emergency services protocols translator between ANSI-41 and VoIP emergency services protocols
US8369316B2 (en) 2008-05-30 2013-02-05 Telecommunication Systems, Inc. Wireless emergency services protocols translator between ANSI-41 and VoIP emergency services protocols
US7903587B2 (en) 2008-05-30 2011-03-08 Telecommunication Systems, Inc. Wireless emergency services protocols translator between ansi-41 and VoIP emergency services protocols
US8068587B2 (en) 2008-08-22 2011-11-29 Telecommunication Systems, Inc. Nationwide table routing of voice over internet protocol (VOIP) emergency calls
US8391884B2 (en) * 2009-03-26 2013-03-05 Andrew Llc System and method for managing created location contexts in a location server
US20100248740A1 (en) * 2009-03-26 2010-09-30 Andrew Llc System and method for managing created location contexts in a location server
US20110188411A1 (en) * 2010-02-02 2011-08-04 Stefano Faccin System and method for packetized emergency messages
US20110189971A1 (en) * 2010-02-02 2011-08-04 Stefano Faccin System and method for packetized emergency messages
US20110188416A1 (en) * 2010-02-02 2011-08-04 Stefano Faccin System and method for packetized emergency messages
US8942743B2 (en) 2010-12-17 2015-01-27 Telecommunication Systems, Inc. iALERT enhanced alert manager
US8688087B2 (en) 2010-12-17 2014-04-01 Telecommunication Systems, Inc. N-dimensional affinity confluencer
US9210548B2 (en) 2010-12-17 2015-12-08 Telecommunication Systems, Inc. iALERT enhanced alert manager
US8682321B2 (en) 2011-02-25 2014-03-25 Telecommunication Systems, Inc. Mobile internet protocol (IP) location
US9173059B2 (en) 2011-02-25 2015-10-27 Telecommunication Systems, Inc. Mobile internet protocol (IP) location
US9479344B2 (en) 2011-09-16 2016-10-25 Telecommunication Systems, Inc. Anonymous voice conversation
US9401986B2 (en) 2011-09-30 2016-07-26 Telecommunication Systems, Inc. Unique global identifier header for minimizing prank emergency 911 calls
US8831556B2 (en) 2011-09-30 2014-09-09 Telecommunication Systems, Inc. Unique global identifier header for minimizing prank emergency 911 calls
US9178996B2 (en) 2011-09-30 2015-11-03 Telecommunication Systems, Inc. Unique global identifier header for minimizing prank 911 calls
US9264537B2 (en) 2011-12-05 2016-02-16 Telecommunication Systems, Inc. Special emergency call treatment based on the caller
US9313637B2 (en) 2011-12-05 2016-04-12 Telecommunication Systems, Inc. Wireless emergency caller profile data delivery over a legacy interface
US9326143B2 (en) 2011-12-16 2016-04-26 Telecommunication Systems, Inc. Authentication via motion of wireless device movement
US8984591B2 (en) 2011-12-16 2015-03-17 Telecommunications Systems, Inc. Authentication via motion of wireless device movement
US9384339B2 (en) 2012-01-13 2016-07-05 Telecommunication Systems, Inc. Authenticating cloud computing enabling secure services
US9510171B1 (en) 2012-03-22 2016-11-29 Sprint Spectrum L.P. Provisioning mobile station with destination communication address during de-registration
US9307372B2 (en) 2012-03-26 2016-04-05 Telecommunication Systems, Inc. No responders online
US9544260B2 (en) 2012-03-26 2017-01-10 Telecommunication Systems, Inc. Rapid assignment dynamic ownership queue
US9338153B2 (en) 2012-04-11 2016-05-10 Telecommunication Systems, Inc. Secure distribution of non-privileged authentication credentials
US10880219B2 (en) * 2012-04-27 2020-12-29 Level 3 Communications, Llc Load balancing of network communications
US9313638B2 (en) 2012-08-15 2016-04-12 Telecommunication Systems, Inc. Device independent caller data access for emergency calls
US9208346B2 (en) 2012-09-05 2015-12-08 Telecommunication Systems, Inc. Persona-notitia intellection codifier
US9456301B2 (en) 2012-12-11 2016-09-27 Telecommunication Systems, Inc. Efficient prisoner tracking
US8983047B2 (en) 2013-03-20 2015-03-17 Telecommunication Systems, Inc. Index of suspicion determination for communications request
US9408034B2 (en) 2013-09-09 2016-08-02 Telecommunication Systems, Inc. Extended area event for network based proximity discovery
US9516104B2 (en) 2013-09-11 2016-12-06 Telecommunication Systems, Inc. Intelligent load balancer enhanced routing
US9301191B2 (en) 2013-09-20 2016-03-29 Telecommunication Systems, Inc. Quality of service to over the top applications used with VPN
US9210621B1 (en) 2013-09-23 2015-12-08 Sprint Spectrum L.P. Method and system for facilitating service level continuity
US9479897B2 (en) 2013-10-03 2016-10-25 Telecommunication Systems, Inc. SUPL-WiFi access point controller location based services for WiFi enabled mobile devices
US9924449B1 (en) 2015-04-14 2018-03-20 Sprint Spectrum L.P. Methods and systems for controlling implementation of a location-based service for a wireless communication device
US9420425B1 (en) 2015-09-01 2016-08-16 Sprint Spectrum L.P. Methods and systems for determining a change in location of a portable wireless access point
US20170180966A1 (en) * 2015-12-17 2017-06-22 Rave Wireless, Inc. Notification of emergencies based on wireless signal recognition
US10631128B1 (en) * 2018-11-08 2020-04-21 Capital One Services, Llc Systems and methods for facilitating dynamic remote assistance networks
US10743137B2 (en) * 2018-11-08 2020-08-11 Capital One Services, Llc Systems and methods for facilitating dynamic remote assistance networks

Similar Documents

Publication Publication Date Title
US7602886B1 (en) Method and system for using a network-provided location for voice-over-packet emergency services calls
US9020105B2 (en) Systems and methods for third party emergency call termination
US8004402B2 (en) Method and apparatus for determining a physical location of a customer
US8681782B2 (en) Method and system for routing a voice-over-packet emergency services call to an appropriate public safety answering point (PSAP)
US9426304B2 (en) Answering or releasing emergency calls from a map display for an emergency services platform
US9544429B2 (en) Solutions for voice over internet protocol (VoIP) 911 location services
US8265068B2 (en) Mapping of IP phones for E911
US7843903B2 (en) Methods, systems, and computer program products for emergency 911 (E911) registration assistance for subscribers using portable internet protocol (IP) communications devices
US20160014232A1 (en) Voice Over Internet Protocol (VoIP) Mobility Detection
US8903355B2 (en) Answering or releasing emergency calls from a map display for an emergency services platform
US8520805B2 (en) Video E911
US8289958B1 (en) Using a clearinghouse to determine caller location for VoIP calls
Rosen et al. Framework for emergency calling using internet multimedia
US20070121598A1 (en) Emergency call methodology for VoIP communications
US20100272242A1 (en) Voice over internet protocol (VolP) location based 911 conferencing
KR20060051756A (en) Systems and methods for serving voip emergency calls
US8787870B2 (en) Method, apparatus and computer program product for providing emergency service validation
US20150156320A1 (en) Systems and methods for locating endpoints in a communication network
CA2548943A1 (en) Method, system and apparatus for retrieving location information on behalf of a location-unaware device in a packet-switched environment
Venkataraman A framework for supporting 911 service in a PBX LAN: Protocol requirements and analysis
Rosen et al. RFC 6443: Framework for Emergency Calling Using Internet Multimedia
JP2005124060A (en) Method for confirming positional information of caller or called party using lsp

Legal Events

Date Code Title Description
AS Assignment

Owner name: SPRINT SPECTRUM L.P., KANSAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BEECH, HAL S.;GREEN, DOUGLAS R.;DHANOA, SHINGARA S.;REEL/FRAME:016802/0830

Effective date: 20050719

STCF Information on status: patent grant

Free format text: PATENTED CASE

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: DEUTSCHE BANK TRUST COMPANY AMERICAS, NEW YORK

Free format text: GRANT OF FIRST PRIORITY AND JUNIOR PRIORITY SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:SPRINT SPECTRUM L.P.;REEL/FRAME:041937/0632

Effective date: 20170203

FPAY Fee payment

Year of fee payment: 8

AS Assignment

Owner name: DEUTSCHE BANK TRUST COMPANY AMERICAS, NEW YORK

Free format text: SECURITY AGREEMENT;ASSIGNORS:T-MOBILE USA, INC.;ISBV LLC;T-MOBILE CENTRAL LLC;AND OTHERS;REEL/FRAME:053182/0001

Effective date: 20200401

AS Assignment

Owner name: SPRINT SPECTRUM L.P., KANSAS

Free format text: TERMINATION AND RELEASE OF FIRST PRIORITY AND JUNIOR PRIORITY SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:052313/0299

Effective date: 20200401

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12

AS Assignment

Owner name: SPRINT SPECTRUM LLC, WASHINGTON

Free format text: CHANGE OF NAME;ASSIGNOR:SPRINT SPECTRUM L.P.;REEL/FRAME:059044/0022

Effective date: 20210325

AS Assignment

Owner name: SPRINT SPECTRUM LLC, KANSAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822

Owner name: SPRINT INTERNATIONAL INCORPORATED, KANSAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822

Owner name: SPRINT COMMUNICATIONS COMPANY L.P., KANSAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822

Owner name: SPRINTCOM LLC, KANSAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822

Owner name: CLEARWIRE IP HOLDINGS LLC, KANSAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822

Owner name: CLEARWIRE COMMUNICATIONS LLC, KANSAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822

Owner name: BOOST WORLDWIDE, LLC, KANSAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822

Owner name: ASSURANCE WIRELESS USA, L.P., KANSAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822

Owner name: T-MOBILE USA, INC., WASHINGTON

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822

Owner name: T-MOBILE CENTRAL LLC, WASHINGTON

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822

Owner name: PUSHSPRING, LLC, WASHINGTON

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822

Owner name: LAYER3 TV, LLC, WASHINGTON

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822

Owner name: IBSV LLC, WASHINGTON

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:DEUTSCHE BANK TRUST COMPANY AMERICAS;REEL/FRAME:062595/0001

Effective date: 20220822