RU2391792C2 - SUPPORT OF EMERGENCY CALL VoIP - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: procedures are described to support emergency calls VoIP, which may be used for various networks 3GPP and 3GPP2, various architectures for detection of location and various types of user equipment (UE). UE communicates with visited network to send a request for establishment of emergency call VoIP. UE interacts with server of location detection, prescribed by visited network, to produce the first assessment of position for UE. UE establishes call via visited network in order to create emergency call VoIP with public safety point (PSAP), which may be selected on the basis of initial assessment of position. UE may detect position with the help of location detection server to produce updated assessment of position for UE.

EFFECT: invention provides for maintenance of emergency calls for users in roaming.

61 cl, 4 tbl, 12 dwg

Description

This application claims the priority of provisional application (USA) with serial number 60 / 704,977, entitled "support for emergency call VOIP (Voice over IP)", registered on August 2, 2005, provisional application (USA) with serial number 60 / 713,199 entitled "VOIP emergency call support" registered on August 30, 2005, provisional application (USA) with serial number 60 / 726,694, entitled "VOIP emergency call support" registered on October 13, 2005, provisional application (USA) with serial No. 60 / 732,226 entitled "Support the VOIP emergency call “registered on October 31, 2005 and the provisional application (USA) serial number 60 / 748,821 entitled“ support for emergency VOIP calls using SUPL ”registered on December 9, 2005, all assigned to the assignee of this application and thus expressly incorporated by reference in this document.

BACKGROUND OF THE INVENTION

1.1. Technical field

The present invention relates generally to communications, and more particularly to techniques for maintaining emergency calls.

1.2. BACKGROUND OF THE INVENTION

Wireless networks are widely used to provide various communication services, such as voice, video, packet data, sending messages, broadcasting and so on. These wireless networks can be multiple access networks that can communicate with multiple users by sharing available network resources. Examples of such multiple access networks include CDMA (code division multiple access) networks, TDMA (time division multiple access) networks, FDMA (frequency division multiple access) networks, and OFDMA (orthogonal FDMA) networks.

Wireless networks typically support communication for wireless users who have subscribed to the services of these networks. A service subscription can be associated with information for security, routing, quality of service (QoS), billing, and so on. Subscription information can be used to make calls with a wireless network.

One of the most basic services provided by wireless networks for its users is the ability to send and receive voice calls. One recent improvement to this service is the ability to send and receive VoIP (Voice over IP) calls. A VoIP call is a voice call in which voice data is sent in packets that are sent like other packets instead of a dedicated data channel.

A wireless network user can make an emergency voice call or call with another environment, which may or may not be a home network in which the user has a subscription to services. A similar call can use VoIP. The main problem is an emergency call to the appropriate public safety response point (PSAP) that can serve the call. This may result in an intermediate position estimate for the user and the determination of the appropriate PSAP based on the intermediate position estimate. The problem can be complicated if the user is roaming and / or does not have a subscription to a service with any network.

Therefore, there is a need in the art for techniques for supporting emergency calls and emergency VoIP calls.

SUMMARY OF THE INVENTION

Techniques for supporting VoIP calls are described in this document. The techniques can be used for various 3GPP and 3GPP2 networks, various location architectures and subscriber equipment (UE) with and without subscription to services.

In an embodiment, the UE interacts with the visited network to send a request to establish an emergency VoIP call. The UE interacts with the location server prescribed by the visited network to obtain a first position estimate for the UE. The UE establishes a call through a visited network to create an emergency VoIP call with a PSAP, which can be selected based on an initial position estimate. The UE may therefore perform positioning using the location server to obtain an updated position estimate for the UE, for example, if a PSAP is requested. Various details of an emergency VoIP call are described below.

Additionally, various aspects and embodiments of the invention are described in detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects and embodiments of the present invention will become more apparent from the detailed description set forth below, taken in connection with the drawings, in which similar reference symbols are defined, respectively.

FIG. 1 shows a deployment of equipment that supports emergency VoIP calls.

FIG. 2 shows a 3GPP network architecture.

FIG. 3 shows a 3GPP2 network architecture.

FIG. 4 and 5 show, respectively, the network architecture and, accordingly, the message flow for an emergency VoIP call using the SUPL location.

FIG. 6 and 7 show the network architecture and accordingly the message flow for an emergency VoIP call using the location of the 3GPP control plane.

FIG. 8 and 9 show the network architecture and, accordingly, the message flow for an emergency VoIP call using the X.S0024 location.

FIG. 10 and 11 show a network architecture and, accordingly, a message flow for an emergency VoIP call to a UE without subscribing to a service.

FIG. 12 shows a block diagram of several objects in FIG. 1-3.

DETAILED DESCRIPTION

The word “exemplary” is used herein to mean “serving as an example, sample, or illustration.” Any embodiment or scheme described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or schemes.

Techniques for maintaining emergency VoIP calls are described in this document. An emergency VoIP call is a VoIP call or a packet-switched call for emergency services. An emergency VoIP call can be defined as such and can differ from a regular VoIP call in several ways, as described below. An emergency VoIP call can be associated with various characteristics that differ from a regular VoIP call, for example, getting an appropriate position estimate for a user, routing an emergency VoIP call to the corresponding PSAP, and so on. A position estimate is also referred to as a position estimate, position determination, and so on.

FIG. 1 shows a deployment of equipment 100 that supports emergency VoIP calls. Subscriber equipment 110 (UE) communicates with access network 120 to obtain basic IP communication services. UE 110 may be fixed or mobile, and may also be called a mobile station (MS), terminal, subscriber unit, station, or some other terminology. UE 110 may be a cell phone, personal digital assistant (PDA), wireless device, laptop computer, telemetry device, tracking device, and so on. UE 110 may communicate with one or more base stations and / or one or more access points in access network 120. UE 110 may also receive signals from one or more satellites 190, which may be part of a global positioning system (GPS), the European Galileo system, the Russian GLONASS system, or any global navigation satellite system (GNSS). UE 110 may measure the parameters of signals from base stations in access network 120 and / or signals from satellites 190 and may obtain pseudorange measurements for satellites and / or time measurements for base stations. Pseudorange and / or time measurements can be used to obtain a position estimate for the UE 110 using one or a combination of methods well known in the art, for example Auxiliary GPS (A-GPS), Autonomous GPS, Advanced Forward Link Trilateration (A -FLT), improved observed time difference (E-OTD), observed arrival time difference (OTDOA), improved cell identifier, and so on.

Access network 120 provides radio communications to UEs located in the coverage area of the access network. Access network 120 may include base stations, network controllers, and / or other entities, as described below. The visited network 130, also called the Visited Public Land Mobile Network (V-PLMN), is the network that currently serves the UE 110. The home network 160, which is also called the home PLMN (H-PLMN), is a network in which UE 110 has a subscription. The access network 120 is associated with the visited network 130. The visited network 130 and the home network 160 may also be the same or different networks. The visited network 130 and home network 160 may or may not have a roaming agreement. Networks 130 and 160, each, may contain entities that provide data connectivity, location services, and / or other functionality and services.

Network 170 may include a public switched network (PSTN), the Internet, and / or other voice and data networks. PSTN supports communications for the implementation of traditional ordinary telephone service (POTS). PSAP 180 is responsible for responding to emergency calls (e.g. police, fire and medical services), and may also be referred to as an emergency center (EC). Such calls can be initiated when the user calls some well-known fixed-line number, such as 911 in North America or 112 in Europe. PSAP 180 typically works or is owned by a government agency, such as a country or city. PSAP 180 can support IP interoperability for VoIP calls and thus support Session Initiation Protocol (SIP), which is a signaling protocol for initiating, modifying, and terminating IP-based interactive user sessions, such as VoIP. Alternatively or in addition, the PSAP 180 may communicate with the PSTN 170.

The techniques described in this document can be used for emergency VoIP calls coming from wired networks, such as DSL (digital subscriber line) and cable, for emergency VoIP calls coming from wireless wide area networks (WWAN), wireless local area networks (WLANs) ), wireless metropolitan area networks (WMAN), and wireless networks with WWAN and WLAN coverage. WWANs may be CDMA, TDMA, FDMA, OFDMA and / or other networks. A CDMA network may implement one or more radio technologies, for example, Broadband CDMA (W-CDMA), cdma2000, and so on. cdma2000 covers the IS-2000, IS-856 and IS-95 standards and includes EV-DO modifications to optimize IP support. A TDMA network may implement one or more radio technologies such as Global System for Mobile Communications (GSM), Digital Advanced Mobile Communications System (D-AMPS), and so on. D-AMPS covers IS-248 and IS-54. W-CDMA and GSM are described in documents from an organization called the “Third Generation Partnership Project” (3GPP). cdma2000 is described in documents from an organization called "Third Generation Partnership Project 2" (3GPP2). 3GPP and 3GPP2 documents are publicly available. A WLAN may implement a radio technology such as IEEE 802.11. WMAN can implement radio technology such as IEEE 802.16. These various radio technologies and standards are known in the art.

FIG. 2 shows a 3GPP network architecture. UE 100 may access through a 3GPP access network 120a or a WLAN access network 120b. The 3GPP access network 120a may be a GSM EDGE radio access network (GERAN), a universal terrestrial radio access network (UTRAN), a dedicated UTRAN (E-UTRAN), or some other access network. The 3GPP access network 120a includes base stations 210, a base station subsystem (BSS) / radio network controller (RNC) 212, and other entities not shown in FIG. 2. The base station is also referred to as Node B, Enhanced Node B (e-Node B), Base Transceiver Station (BTS), Access Point (AP), or some other terminology. WLAN 120b includes access points 214 and may be any WLAN.

V-PLMN 130a is one embodiment of a visited network 130 in FIG. 1 and includes a V-PLMN core network 230a and V-PLMN location entities 270a. The V-PLMN core network 230a includes a GPRS Support Serving Node 232a (SGSN), GPRS Support Gateway Node 232b (GGSN), WLAN Access Gateway 234 (WAG), and Packet Data Gateway (PDG) 236. The SGSN 232a and GGSN 232b are part of the core GPRS (General Purpose Packet Radio) network and provide packet-switched services for communicating with the UE with the 3GPP access network 120a. WAG 234 and PDG 236 are part of the 3GPP WLAN Interconnect (I-WLAN) core network and provide packet-switched services for communicating UEs with WLAN 120b.

The V-PLMN core network 230a also includes a home subscriber server 250 (HSS) and various IP multimedia subsystem (IMS) objects, which include an access module call session management function (P-CSCF) 252, an emergency CSCF 254 (E-CSCF), a CSCF 256 polling entity (I-CSCF), and a media gateway control functional entity 258 (M.GCF). P-CSCF 252, E-CSCF 254, I-CSCF 256 and MGCF 258 support IMS services, such as VoIP calls, and are part of the IMS V-PLMN network. The P-CSCF 252 receives requests from the UE and serves these requests internally or forwards requests to other entities, possibly after conversion. The E-CSCF 254 performs session management services for the UE and maintains the session state used to support IMS emergency services. The E-CSCF 254 additionally supports emergency VoIP calls. The MGCF 258 controls the signaling conversion between SIP / IP and PSTN (for example, SS7ISUP) and is always used when a VoIP call from one user goes to the PSTN user. The HSS 250 stores subscription information for the UE for which the V-PLMN 130a is a home network.

V-PLMN location entities 270a may include an Emergency Service SUPL (E-SLP) location platform 272 and a visited SLP 274 (V-SLP) that supports the location of a secure OMA user plane (SUPL). V-SLP 274 may be in or associated with a different network in V-PLMN 130a and / or geographically closer to UE 110. Alternatively or additionally, V-PLMN location objects 270a may include a mobile gateway location center (GMLC) 276, which is part of the 3GPP control plane location. E-SLP 272, V-SLP 274 and GMLC 276 provide location services for the UE in conjunction with V-PLMN 130a.

H-PLMN 160a is one embodiment of a home network 160 in FIG. 1 and includes a core network 260 H-PLMN. H-PLMN core network 260 includes HSS 266 and further includes IMS entities, such as I-CSCF 262 and serving CSCF 264 (S-CSCF), which supports IMS for home network 160. I-CSCF 262 and S-CSCF 264 are part of the H-PLMN IMS network.

FIG. 3 shows a 3GPP2 network architecture. UE 110 may receive radio access via 3GPP2 access network 120c or WLAN access network 120d. The 3GPP2 access network 120c may be a CDMA2000 IX network, a CDMA2000 lxEV-DO network, or another access network. 3GPP2 access network 120c includes base stations 220, a radio resource / packet control (RRC / PCF) functional entity 222, and other entities not shown in FIG. 3. The RRC may also be called a radio network controller (RNC) or base station. 3GPP2 access network 120c may also be called a radio access network (RAN). WLAN 120d includes access points 224 and may be any WLAN associated with a 3GPP2 network.

V-PLMN 130b is another embodiment of a visited network 130 in FIG. 1 and includes a V-PLMN core network 230b and 3GPP2 location entities 270b. The V-PLMN core network 230b includes a serving packet data node 242 (PDSN), a packet data interaction functional entity (PDIF) 244, and an authentication, authorization, and accounting (AAA) server 246. PDSN 242 and PDIF 244 provide packet-switched services for the UE to interact with 3GPP2 access network 120c and, accordingly, WLAN 120d. The V-PLMN core network 230a also includes IMS and multimedia domain objects (MMDs), for example P-CSCF 252, E-CSCF 254, I-CSCF 256 and MGCF 258. E-CSCF 258 may also have other names, for example ES -AM (emergency application manager).

3GPP2 location entities 270b may include E-SLP 272 and V-SLP 274 for SUPL. Alternatively or additionally, 3GPP2 location objects 270b may include an Emergency Position (E-PS) server 282 and a visited Position Server (V-PS) / Position Determination (PDE) object 284, which are part of the X.S0024 location for cdma2000 networks . E-PS 282 may also be referred to as a replacement position server (S-PS). E-SLP 272, V-SLP 274, and E-PS 282 and V-PS / PDE 284 provide location services for the UEs in conjunction with V-PLMN 130b.

For simplicity, FIG. 2 and 3 show only some of the objects in 3GPP and 3GPP2, which are mentioned in the description below. 3GPP and 3GPP2 networks may include entities defined by 3GPP and 3GPP2, respectively.

In the following description, 3GPP networks refer to networks and network subsystems (eg, access network subsystems) defined by 3GPP, as well as other networks and network subsystems (eg, WLAN) operating in connection with 3GPP networks. 3GPP networks and network subsystems may include a core network GERAN, UTRAN, E-UTRAN, GPRS, GPP I-WLAN and so on. 3GPP2 networks refer to the networks and network subsystems defined by 3GPP2, as well as other networks and network subsystems operating in connection with 3GPP2 networks. 3GPP2 networks may include a CDMA2000 IX core network, CDMA2000 lxEV-DO, cdma2000, a 3GPP2 IMS or MMD network subsystem, a WLAN associated with 3GPP2, and so on. For simplicity, “3GPP WLAN” refers to a WLAN associated with a 3GPP network, and “3GPP2 WLAN” refers to a WLAN associated with a 3GPP2 network.

In the following description, GPRS access refers to access to a GPRS core network via GERAN, UTRAN, or another 3GPP access network. 3GPP WLAN access refers to access to a 3GPP core network via WLAN. Access to cdma2000 refers to access to the cdma2000 core network via CDMA2000 IX, CDMA2000 lxEV-DO, or another 3GPP2 access network. 3GPP2 WLAN access refers to access to a 3GPP2 core network via WLAN.

For 3GPP, the UE 110 may or may not be equipped with a universal integrated circuit card (UICC). For 3GPP2, the UE 110 may or may not be equipped with a user identity module (UIM). A UICC or UIM is typically specific to a single subscriber and may store personal information, subscription information, and / or other information. A UICC-excluded UE is a UE without a UICC and a UIM-excluded UE is a UE without a UIM. A UICC / UIM-excluded UE has no subscription, no home network, and no authentication credentials (eg, no secret key) to verify any claimed identity that makes location services more at risk.

The techniques described herein can be used for various location architectures, for example, control plane and user plane architectures. The control plane (also called the signal plane) is a mechanism for signaling transfer for high-level applications and is typically implemented using specific network protocols, interfaces, and signaling messages. The user plane is a signaling transfer mechanism for high-level applications, but using a user plane unidirectional channel, which is typically implemented using protocols such as User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Internet Protocol (IP), each which are known in the art. Messages supporting location and positioning services are carried as part of the signaling in the control plane architecture and as part of the data (from the network projection) in the user plane architecture. The content of the messages may, however, be the same or similar in both architectures.

The techniques may be used for various architectures / location solutions, for example, those listed in Table 1. SUPL and predetermined SUPL in documents from the open community of mobile communications manufacturers (OMA). The 3GPP control plane is described in 3GPP TS 23.271, TS 43.059 and TS 25.305. The 3GPP2 control plane is described in IS-881 and 3GPP2 X.S0002. The 3GPP2 user plane is described in 3GPP2 X.S0024.

Table 1 Location architecture Type of architecture Applicable for ... Predefined SUPL custom plane 3GPP networks SUPL custom plane 3GPP and 3GPP2 networks 3GPP control plane control plane 3GPP networks 3GPP2 control plane control plane 3GPP2 network X.S0024 custom plane 3GPP2 network

The UE may support zero, one, or multiple location solutions (e.g., SUPL or 3GPP or SUPL control plane and 3GPP or SUPL and X.S0024 control plane) for emergency VoIP calls. The UE may inform the network of its location capabilities when a call is made, for example, in a SIP invitation message and / or a SIP registration message. This information may be stored in a local server (eg, location server) for retrieval via the network.

The techniques described herein may support the following features.

(a) Support for emergency VoIP calls for mobile, landline and roaming users.

(b) For VoIP calls that use GPRS access, 3GPP WLAN access, cdma2000 access, and 3GPP2 WLAN access.

(c) Supports end-to-end IP connectivity with SIP / IP enabled PSAPs.

(d) Support for connectivity to a PSTN that allows PSAPs that can be local to the calling UEs but geographically remote from the SIP call servers, for example, when the VoIP service provider is removed from the UE.

(e) Support for routing a call to the appropriate PSAP using an interim position estimate.

(f) Providing the exact location of the UE in the PSAP.

(g) Support for initial and updated locations using various location architectures.

(h) Support for VoIP emergency calls from UEs without UICC / UIM and UEs whose H-PLMN do not have roaming agreements in V-PLMN.

(i) Support for callback from PSAP to a UE without UICC / UIM and / or without a roaming agreement in V-PLMN.

(j) Compatible with the IETF Ecrit solution and NENA solutions, for example, the intermediate VoIP architecture for advanced services (i2) 9-1-1, also known as the NENA 12 solution.

(k) Small impacts and H-PLMN requirements.

The PSAP callback refers to a call from the PSAP back to the UE, for example, since the emergency call was dropped or disconnected too early. An intermediate position estimate typically refers to the approximate position used for routing, and an initial position estimate typically refers to a first accurate position estimate. In some cases, an initial position assessment may be obtained after an interim assessment of the situation. In other cases, the interim and initial position assessments may be the same. In some other cases, an interim position assessment and / or initial position assessment may not be used.

For SUPL, home SLP (H-SLP) in H-PLMN 160 may be bypassed and one or more V-SLPs and / or E-SLPs in / or associated with V-PLMN 130 may be used for location. For X.S0024, the home PS (H-PS) in the H-PLMN 160 can be bypassed and one or more V-PSs and / or E-PSs in / or associated with the V-PLMN 130 can be used for location. This imposes some changes on the SUPL and X.S0024, for example, the H-SLP or H-PS configured in the UE 110 may be replaced for location during an emergency call. The use of V-SLP, E-SLP, E-PS or V-PS in the V-PLMN 130 may be desirable due to the following reasons:

(a) Specialized emergency call support in specific areas or countries should only use support from networks in those areas, not other networks.

(b) A UE without UICC / UIM may not have an H-PLMN and may rely on SLP or PS in a V-PLMN.

(c) For UEs with UICC / UIM, the H-PLMN may not have roaming agreements with the V-PLMN, and it may be difficult to use H-SLP or H-PS.

(d) H-SLP or H-PS may not support location request from a remote PSAP (for example, in another country) due to signaling differences or lack of registration.

(e) H-SLP or H-PS cannot get a good position estimate (for example, if the H-SLP or H-PS is remote from the UE) without the help of the V-SLP or V-PS in the V-PLMN.

(f) H-SLPs or H-PSs cannot support the interface (e.g. Li or LCS-I interface) used by the E-SLP or E-PS to support the emergency call service.

E-SLP 272 or E-PS 282 can perform positioning for UE 110 in SUPL and, accordingly, X.S0024. Alternatively, V-SLPs, V-PSs or PDEs may be selected to determine the position for UE 110, for example, if E-SLP 272 or E-PS 282 are not able to perform this function. V-SLP, V-PS or PDE can be useful, for example, if the SIP call server (e.g. E-CSCF 254) is remote from UE 110 and selects E-SLP or E-PS, which are also remote, which can happen when an operator uses a small number of call servers to serve a large area or an entire country. E-SLP 272 or E-PS 282 can select the appropriate V-SLP, V-PS or PDE using any of the following mechanisms:

(a) UE 110 detects the IP address or name of V-SLP or V-PS when connecting to an access network or creating IP connectivity, for example, the access network provides a V-SLP or V-PS address of UE 110. UE 110 may also Detect a V-SLP or V-PS address using a DNS query after creating IP connectivity. This can be used if the DNS server used by UE 110 is closer to UE 110 than E-CSCF 254. UE 110 may include a V-SLP or V-PS address in the initial SIP REGISTER message sent to the IMS, and in any subsequent message re-registration following the handover to the new access network. An IMS (e.g., E-CSCF 254) can transfer a V-SLP or V-PS address to an E-SLP 272 or E-PS 282.

(b) E-SLP 272 or E-PS 282 determines the V-SLP or V-PS address based on the location information provided by UE 110 in the initial SIP invitation.

(c) E-SLP 272 or E-PS 282 determines a V-SLP or V-PS address based on location information received from UE 110 in the SUPL START.

In general, the location information provided by the UE 110 may be any information that can be used to determine the position of the UE 110. The location information may include geographic coordinates, GSM, UMTS, or cdma2000 cell identifier, serving cell information, identity WLAN access names, WLAN MAC address, and so on. The location information may also contain measurement results that can be used to determine the position of the UE 110.

For SUPL and X.S0024, E-SLP 272 or E-PS 282 can send SUPL INIT to UE 110 to start a SUPL session. SUPL INIT can be sent using active WAP or SMS delivery, which can lead to longer delays. In an embodiment, to reduce the delay, the SUPL INIT can be sent to the UE 110 via IMS (e.g., P-CSCF 252 and E-CSCF 254) using an immediate IMS message, another IMS message, a SIP response 1xx (e.g., continued session 183) or which Any other message. The use of existing (possibly safe) connections between IMS and UE 110 enables fast transmission and additionally avoids additional delay for creating new connections and / or message transmission using additional objects (for example, SMS services center). This embodiment may also be used when the UE 110 is not registered with the H-PLMN, for example, does not have a UICC or UIM. In another embodiment, to reduce delay, the SUPL INIT may be sent to UE 110 using mobile terminated IP or UDP / IP. In this case, the IP gateway serving the UE 110 (e.g., GGSN 232b, PDG 236, PDSN 242 or PDIF 244) can be pre-managed using the IP address (s) of the E-SLP 272 in order to filter IP packets from E-SLP 272 at UE 110. UE 110 may be configured to support the TCP port and / or UDP port used for SUPL (and registered with IANA, the Committee on Digital Addresses on the Internet, USA) to receive SUPL INIT.

Emergency VoIP calls can be supported by SUPL 1.0 and the initial version of X.S0024 (3GPP2 X.S0024-0) as follows.

(a) If the UE 110 is in the H-PLMN 160, then the E-SLP 272 is an H-SLP, or the E-PS 282 is an H-PS for the UE and initiates a location request triggered by SUPL 1.0 or X.S0024-0. SUPL INIT can be sent to UE 110 using SMS or active WAP delivery.

(b) If the UE 110 is not located in the H-PLMN 160, but is registered in the V-PLMN 130, then the E-SLP 272 may cause a SUPL 1.0 location request, acting as a requesting SLP (R-SLP) and sending a location request to H- SLP for UE 110 according to the procedure in SUPL 1.0 and OMA RLP. Similarly, the E-PS 282 may cause an X.S0024 location request from the H-PS to the UE 110 using, for example, the OMA RLP protocol.

(c) If UE 110 is not located in H-PLMN 160 and is not registered with V-PLMN 130 (for example, there is no roaming agreement between V-PLMN 130 and H-PLMN 160) or if UE 110 does not have UICC or UIM, then SUPL 1.0 or X.S0024-0 location is not supported. However, the E-SLP 272 or E-PS 282 can still obtain a position estimate for the UE 110 using the location information provided by the UE 110 in the initial SIP emergency call invitation.

1. Emergency VoIP Call with SUPL

FIG. 4 shows a block diagram of an embodiment of a network architecture 400 for an emergency VOIP call with a SUPL location. Network architecture 400 is used for both 3GPP and 3GPP2 networks. For simplicity, FIG. 4 shows only the objects and interfaces that are relevant for supporting emergency VoIP calls using SUPL.

UE 110 is referred to as a SUPL capable terminal (SET) in SUPL. Access network 120 may be a 3GPP access network, 3GPP2 access network, WLAN, or any other network. Access network 120 and / or V-PLMN 130 includes entities that support packet-switched calls, for example, as shown in FIG. 2 and 3. For 3GPP2, a simple IP and / or mobile IP can be used for emergency VoIP calls. In the following description, IMS may refer to P-CSCF 252, E-CSCF 254 and / or MGCF 258.

E-SLP 272 may include a SUPL location center 412 (E-SLC) that performs various functions for location services and an SUPL positioning center (E-SPC) 414 that supports positioning for the UE. V-SLP 274 may simply include V-SLC 422 and V-SPC 424. E-SLP 272 may replace the H-SLP in the H-PLMN 160 in the case of an emergency call location. Objects in SUPL are described in OMA-AD-SUPL-V2_0-20060704-D, entitled “Secure User Plane Location Architecture”, draft 4.0, July 4, 2006, and in OMA-TS-ULP-V2_0-20060721-D entitled "User Plane Location Protocol", draft 2.0, July 21, 2006, which are publicly available from OMA.

SUPL supports two communication modes between SET and SLP for positioning using SPC. In proxy mode, the SPC does not directly communicate with SET, and the SLP acts as an intermediary between SET and SPC. In direct mode, the SPC has a direct relationship with SET.

PSTN / Internet 170 may include entities (eg, routers) that support packet routing and a selective router (S / R) 292 that routes an emergency call to the PSAP. S / R 292 may belong to the PSAP 180, or be shared and connected to a set of separate PSAPs. UE 110 can communicate with the PSAP 180 through the P-CSCF 252 and E-CSCF 254 to call VoIP, if the PSAP 180 supports SIP. UE 110 may also communicate with PSAP 180 through P-CSCF 252, E-CSCF 254, MGCF 258, and S / R 292 if PSAP 180 does not support SIP. In this case, the media gateway (MGW) managed by the MGCF 258 performs VoIP in the PCM circuit mode conversion for emergency call.

FIG. 4 also shows the interfaces between various objects. Call-related interfaces between UE 110, P-CSCF 252, E-CSCF 254, MGCF 258 may be SIP. Call-related interfaces between the MGCF 258, S / R 292, and PSAP 180 may be MF / ISUP. The location-related interface between the PSAP 180 and the E-SLP 272 may be the E2 interface specified in J-STD-036 version B if the PSAP 180 is a PSTN that allows extensions to the E2 interface if the PSAP 180 allows SIP. The location-related interface between the PSAP 180 and the E-SLP 272 may, in contrast, be an MLP interface defined in a mobile location protocol (LIF) or some other interface, such as an HTTP interface. The location-related interface between the UE 110 and the V-SLP 274 and the E-SLP 272 may be a ULP SUPL.

The interface between the E-CSCF 254 and the E-SLP 272 is used to transmit information about the UE 110 to the E-SLP 272 and to initiate SUPL location determination. This interface may be an IMS LCS interface (e.g., Li) and may use an IMS location protocol (ILP) or some other protocol. The Li / ILP interface may be similar to the OMA roaming location protocol (RLP) interface between SLPs. The Li / ILP interface can be used by any IMS entity (e.g., S-CSCF or application server) and E-SLP 272 to support other capabilities associated with IMS and IP-based services, for example:

(a) location-based billing for VoIP or other IP-based calls,

(b) providing the location of one party on a call to one or more other parties, and

(c) additional services based on a user's location, for example, location-dependent call direction, location-dependent call barring.

The interface between the E-SLP 272 and the E-CSCF 254 can also be a v2 interface defined in the "Draft NENA Standards for VoIP / Transfer of Decision Packages i2" or the "Intermediate VoIP Architecture for Advanced Services 9-1-1 (i2)" (hereinafter referred to as the "NENA I2 Solution"), which is considered to support VoIP E 911 in the United States, or some other interface.

Network architecture 400 may include other entities for supporting VoIP and / or location, for example, the elements described in NENA I2 solution or draft NENA I2.5 and I3 solutions.

1.1. Call setup

FIG. 5 shows an embodiment of a message flow 500 for establishing an emergency VoIP call using SUPL. For clarity, objects that are less significant (e.g., access network 120, P-CSCF 252, S / R 292) are omitted from FIG. 5, but are included in the descriptions below. Message flow 500 can be used for 3GPP and 3GPP2 networks. Message flow 500 assumes that UE 110 has a UICC or UIM and that there is a roaming agreement between H-PLMN 160 and V-PLMN 130.

In step 1, the UE 110 detects an access network (AN), for example, a 3GPP access network, 3GPP2 access network, 802.11 WLAN, etc. UE 110 makes any low-level connection (e.g., 802.11 communication) and joins the access network (e.g., via GPRS connection or through the AAA WLAN procedure for 3GPP). UE 110 creates IP connectivity and can detect the local SIP server address. In the description below, P-CSCF 252 is a local SIP server detected by UE 110. Step 1 can be performed in various ways for different networks and is further described in detail below.

In step 2, the UE 110 sends a SIP REGISTER to the P-CSCF 252, which is the local SIP server detected in step 1. The SIP REGISTER may include an emergency service indication, an emergency public user identifier (for example, as described in 3GPP TR 23.867 and 3GPP TS 23.167), the private user identifier, the H-PLMN domain name, and the IP address of the UE obtained in step 1. SIP REGISTER may also include location information for UE 110, location capabilities of UE 110, and / or other information. The location capabilities of the UEs may include location solutions supported by the UE 110 (e.g., SUPL, 3GPP control plane, X.S0024, etc.), positioning methods supported by the UE 110 and / or other information. Due to the presence of an emergency service indication or an emergency public user identifier, the P-CSCF 252 forwards the SIP REGISTER to the E-CSCF 254 on the same network and not on the I-CSCF 262 on the H-PLMN 160, as in emergency cases.

In step 3, the E-CSCF 254 in the V-PLMN 130 routes the SIP REGISTER to the S-CSCF 264 in the H-PLMN 160, where the usual IMS registration takes place. The reasons for registering with the H-PLMN 160 are (1) authentication of user identity, (2) receiving a verified callback number from S-CSCF 264, (3) warning the H-PLMN 160 about an emergency call so that a special agreement (e.g. priority, limitation of additional services) could be used if the PSAP 180 later calls back the UE 110 through the H-PLMN 160. To register the IMS S-CSCF 264 in the H-PLMN 160 processes the E-CSCF 254 in the V-PLMN 130 similar to the P-CSCF. The TEL URI of a public user (for example, retrieved from MSISDN (mobile subscriber number of a digital network with service integration) in 3GPP or MIN (mobile identification number) in 3GPP2) can be implicitly registered with an emergency public user identifier for UE 110 and can be used for reverse call PSAP from PSTN. H-PLMN 160 may not support additional registration of an emergency public user identifier, for example, if UE 110 has already registered a regular public user identifier or if the emergency public user identifier is not supported by H-PLMN 160. E-CSCF 254 may support an H-PLMN list, for which stage 3 may be skipped. If step 3 is omitted, a callback from the PSAP 180 may still be possible using the regular public user identifier of the UE 110, which must be registered with the UE 110 separately. The E-CSCF 254 may also assign a temporary public user identifier to UE 110, as described below, to enable callback from the PSAP 180 directly via V-PLMN 130 rather than through H-PLMN 160. This temporary public user identifier may be particularly useful for a roaming UE overseas user, since both latency and callback reliability can be improved. If registration with the H-PLMN 160 is not completed, then the UE 110 is not authenticated and a secure IP connection between the UE 110 and the E-CSCF 254 in the V-PLMN 130 cannot be created, which may impair security for subsequent location of the UE 110 by E -SLP 272.

In step 4, the E-CSCF 254 (for example, after receiving a 200 OK SIP message from the H-PLMN 160) returns a 200 OK message to the UE 100. Following the establishment of an emergency call, if the service of the UE 100 is transferred in the same V-PLMN to another SGSN (for GPRS access), another WLAN (for WLAN access) or another PCF or PDSN (for cdma2000 access), then the UE 110 can re-register by repeating steps 2 through 4 in order to update the location information and about V -SLP. If the UE 110 is re-registered using its emergency public user identifier, then the E-CSCF 254 can transmit any new location information to the E-SLP 272. The re-registration makes it possible to select a different V-SLP if the UE 110 has moved from a geographic area supported by previous V-SLP.

For 3GPP2 access WLANs, handoff may be performed if UE 110 moves from one WLAN to another WLAN or from WLAN to cdma2000. Handoff can create a new tunnel with the previous PIDF from either the new WLAN (for handover from one WLAN to another WLAN) or the new PSDN (packet-switched data network) (for handover from WLAN to cdma2000) in order to Continue to use the IP address associated with the previous PDIF, and in order to avoid breaking with an emergency VoIP call. For handover from a cdma2000 network to a WLAN, the PDIF associated with the new WLAN can emulate the final PSDN to support fast handoff to the previous serving PDSN. Following the handover, the UE 110 may be re-registered to provide the E-CSCF 254 with new location information relevant to the selection of the V-SLP.

In an alternative embodiment, in steps 2, 3, and 4, after the UE 110 sends SIP REGISTER to the P-CSCF 252 in step 2, the P-CSCF 252 can forward the SIP REGISTER directly to the S-CSCF 264 in the H-PLMN 160 or in I -CSCF 262 in the H-PLMN 160 and bypass the E-CSCF 254 in the V-PLMN 130. In this case, the 200 OK SIP message from the H-PLMN 160 is returned to the P-CSCF 252, and not to the E-CSCF 254, and P- The CSCF 252 returns a 200 OK message to the UE 110 in step 4. This alternative embodiment can reduce or avoid specific impacts on the P-CSCF 252 to support emergency VoIP calls, as the actions of the P-CSCF 252 are then similar to those essentially t for regular registration.

In step 5, the UE 110 sends a SIP invitation to the P-CSCF 252. The SIP invitation may include a global SIP URL or TEL URI indicating an emergency call (for example, sos @ local domain or "911" suggested by IETF Ecrit) and the type of emergency requested service. The SIP invitation may also include information regarding the location of the UE that is available to the UE 110 (e.g., GPRS or cdma2000 cell identifier, AP WLAN MAC address, etc.), location possibilities of the UE 110, if not provided during registration, contact information for callback and / or other information. The callback information may include a TEL URI (for example, retrieved from 3GPP MSISDN or 3GPP2 MDN) and optionally a SIP URL (for example, a public user identifier used in step 2). The "supported" SIP REGISTER header or SIP invitation field may also be used to convey the location capabilities of the UE. Location capabilities may also be included as part of the location information provided by the UE (for example, in the IETF Geopriv pidf-lo object) or in some other way at the SIP invitation. The P-CSCF 252 may forward the SIP invitation to another SIP server, which may forward the SIP invitation to the routing proxy (eg, application server) assigned for emergency calls. In FIG. 5 The E-CSCF 254 is a SIP server that handles emergency calls.

At step 6, the E-CSCF 254 can determine either explicitly or implicitly that the UE 110 supports the SUPL and sends a routing request (or emergency location request) to the E-SLP 272. The routing request may include the identity of the public UEs (eg, emergency identifier public user from step 5, TEL URI, etc.), any location information received by the E-CSCF 254, and the IP address of the UE if the mobile interrupt IP (or UDP / EP) is used in step 8. E-SLP 272 may be on the same network as the E-CSCF 254, or on some other network. E-SLP 272 can be selected because it covers a geographic area that includes the approximate location of UE 110. E-CSCF 254 can select E-SLP 27, a common location server capable of acting as an E-SLP, or whatever or other types of server, for example GMLC 276. The selected location server may choose to use SUPL based on the location capabilities of the UE transmitted by the E-CSCF 254 (or simply by assumption). E-CSCF 254 may request location information from E-SLP 272 and / or PSAP selection corresponding to available location information and type of emergency service.

E-SLP 272 proceeds to step 12 if the location information provided in step 6 allows the E-SLP 272 to obtain a location estimate for UE 110 that is accurate enough to satisfy the request in step 6 (e.g., unambiguously determining the location of the PSAP). Otherwise, steps 7 through 11 are performed to obtain an appropriate position estimate for UE 110.

In step 7, the E-SLP 272 determines from the received location information whether to use a separate V-SLP to assist in positioning. If so, then the V-SLP (e.g., V-SLP 274) can be selected based on the location information received from the E-CSCF 254. The E-SLP 272 acts as an H-SLP when performing subsequent positioning of the SUPL using procedures, which may be similar to those used for (a) maintaining SUPL 1.0 roaming if V-SLP was selected, or (b) roaming-free SUPL 1.0 if V-SLP was not selected. In the case of roaming, the E-SLP 272 may exchange some RLP pre-signaling with the V-SLC 422, which is not shown in FIG. 5. The E-SLP 272 then generates a SUPL INIT message to initiate a network location procedure using the UE 110 using either the intermediary mode or the direct mode in the SUPL. The E-SLP 272 may send the SUPL INIT directly to the UE 110 using a mobile IP or UDP / IP, in which case step 8 may be skipped. E-SLP 272 may also send the SUPL INIT in an urgent message (for example, an IMS urgent message or some other IMS or SIP message) to the E-CSCF 254. In any case, the SUPL INIT may include the IP address of the SPC used for position determination (which can be E-SPC 414 or V-SPC 424 if direct mode is used), position quality (QoP), accuracy / delay requirements for quick intermediate position assessment, mediation / direct mode indication, authentication data and / or other information. The SUPL INIT may also include the IP address of the E-SLP 272, for example, if the UE 110 is not in its home network, if the E-SLP 272 is not an H-SLP for the UE 110, or if the E-SLP 272 is an H-SLP , but chooses not to manifest itself as an H-SLP (for example, to avoid supporting more than one procedure for emergency calls). SUPL INIT may also include an emergency call indication, for example, in the SUPL INIT notification parameter.

In step 8, the E-CSCF 254 routes the SUPL INIT to the UE 110 through the P-CSCF 252 using an IMS urgent message, another IMS message, a 1xx SIP response (e.g., continuing session 183), or another IP-based message that uses secure associative IPs -connections between the E-CSCF 254, the P-CSCF 252 and the UE 110 created in steps 2 through 4.

In step 9, the UE 110 creates a secure IP connection (for example, a secure TCP / IP connection) with the E-SLP 272, which may be an H-SLP for the UE 110 or whose address is included in the SUPL INIT message sent in step 7. For direct mode, the UE 110 receives authentication data from the E-SLP 272 (not shown) and creates a secure IP connection to the E-SPC 414 or V-SPC 424 with mutual authentication. The E-SLC 412 also transmits information to the E-SPC 414 or V-SPC 424 for direct mode (not shown in FIG. 5). UE 110 may obtain location-related measurements (e.g., signal strengths and / or timing of neighboring cells), or a position estimate (e.g., using a stand-alone GPS system) consistent with the received QoP. UE 110 then returns the SUPL POS INIT to either E-SLP 272 (for intermediary mode), or to E-SPC 414 or V-SPC 424 (for immediate mode, which is not shown in FIG. 5). The SUPL POS INIT may include a hash code used for proxy authentication, position determination capabilities of the UE, position estimation, or A-GPS assist data request (which may also be included in the embedded SUPL POS message for IS-801). The SUPL POS INIT may also include location-related measurements to assist in obtaining quick intermediate position estimates and to avoid additional SUPL POS signaling. For 3GPP, measurements may include measuring signal levels of neighboring base stations or access points, temporal GPRS advance, temporal difference Rx-Tx WCDMA, etc. For 3GPP2, the measurements may include location-related measurements that are relevant to the cdma2000 or 3GPP2 WLAN.

In step 10, E-SLP 272, E-SPC 414, or V-SPC 424 may exchange additional SUPL POS messages with UE 110 if an appropriate position (or location measurement) estimate was not received in step 9. Each SUPL POS message may include an embedded RRLP, RRC, or IS-801 location message. This messaging continues until adequate location measurements or position estimates are provided by E-SLP 272, E-SPC 414 or V-SPC 424. At step 11, the SUPL END message is returned to UE 110 to close the SUPL transaction.

In step 12, the E-SLP 272, E-SPC 414 or V-SPC 424 calculates an intermediate position estimate for the UE 110 based on the location information received in step 9 or in step 10. For the direct mode of the E-SPC 414 or V- The SPC 424 transmits the position estimate to the E-SLC 412. Based on the position estimate and if requested by the E-CSCF 254 in step 6, the E-SLP 272 selects the PSAP. The following description assumes that the PSAP 180 is the selected PSAP. If the PSAP 180 is available / capable of PSTN, then the E-SLP 272 receives (a) an emergency dialing routing sign (ESRD) for a non-dialing number that can be used for routing in the PSAP 180 and (b) an emergency dialing routing key (ESRK) for a non-dialing numbers that defines the PSAP 180, E-SLP 272 and, temporarily, the UE 110. Each PSAP can be associated with one ESRD, as well as with the ESRK group, which defines the E-SLP 272 and its PSAP. For each emergency call made by the UE to this PSAP, the UE may be assigned one ESRK from the group for the duration of the emergency call. Some of these functions (for example, ESRD / ESRK control) may not be considered part of the SUPL and may be supported in a separate physical or logical entity that may be requested by E-SLP 272 (for example, as described in NENA I2). ESRD and ESR correspond to the same named subscriber numbers used to support emergency call in circuit switched mode (for example, J-STD-036). ESRD and ESRK also correspond to ESRN and, accordingly, ESQK described in NENA decision I2.

At step 13, the E-SLP 272 returns to the E-CSCF 254 a routing response (or an emergency location response), which may include (a) a PSAP identifier (which can be either a SIP URL or an IP address) if the PSAP 180 allows IP, or (b) ESRD and ESRK if the PSAP 180 allows PSTN. The routing response may also include an intermediate position estimate for UE 110, if requested by E-CSCF 254. E-SLP 272 may store a call record for UE 110 that contains all the information received for the UE.

Steps 14a and 15a are performed if the PSAP 180 allows IP. In step 14a, the E-CSCF sends a SIP invitation (received in step 5) to the PSAP 180. The SIP invitation may include an interim assessment of position and possibly an identifier or address for UE 110 and an IP address or name of E-SLP 272. In step 15a additional SIP signaling may occur to establish an emergency call.

Steps 14b, 14c and 15b are performed if the PSAP 180 allows PSTN. At step 14b, the E-CSCF 254 forwards the SIP invitation through the interrupt gateway control function (BGCF) to the MGCF 258. The SIP invitation may include a callback number (e.g., MSISDN or MDN) for the UE 110 and / or may include an ESRD and ESRK (but possibly an interim assessment of the situation). In step 14c, the MGCF 258 routes the emergency call to the PSAP 180 via the PSTN, possibly through a selective router, using the SS7 ISUP and / or MF signaling. ESRDs or ESRKs can be used as routing numbers, and ESRKs and / or callback numbers are routed to PSAP 180 (for example, via MF CAMA signaling) as an identifier for UE 110 and as a key to obtaining more information. At step 15b, additional SIP signaling may occur, and interaction with the IS7 SSUP and / or MF in the MGCF 258 may occur to establish an emergency call.

The call route for IP-capable PSAP and PSTN-capable PSAP is set separately. For a PSTN-capable PSAP, the interaction between VoIP (eg, RTP / IP) and circuit switching mode (eg, PCM, Pulse Code Modulation) occurs in a network gateway (MGW) controlled by MGCF 258. For IP-enabled PSAP, the call route will be end-to-end IP and will pass between UE 110 and PSAP 180, possibly partially through the public Internet or private IP network; but miss any MGW.

In step 16, after the call is established, the PSAP 180 may send a location request to the E-SLP 272, which can be identified by the IP address or name obtained in step 14a or the ESRK obtained in step 14c. The PSAP 180 identifies the UE 110 using a public UE address (if the PSAP 180 allows IP), or a callback number, or another address (for example, MSISDN or MDN), or ESRK (if the PSAP 180 allows PSTN). A location request indicates requirements for an accurate position estimate. For an emergency VoIP call in the United States, a location request may be identical to the emergency location request in J-STD-036 if the PSAP 180 allows PSTN, and may be an extension to this message if the PSAP 180 allows IP. For an emergency VoIP call in some other regions of the world, a location request may be identical to the immediate emergency location request defined for OMA MLP.

At step 17, the E-SLP 272 can select the V-SLP if the location capabilities of the E-SLP 272 do not extend to the geographical area from where the last known location of the UE 110 was reported, or if using the V-SLP can provide a more accurate and reliable location. The E-SLP 272 may obtain the V-SLP address from the recent location of the UE 110 and / or from the recent V-SLP address provided by the E-CSCF 254. In order to ensure the correct V-SLP, the E-SLP 272 may request the location of the UE 110 and / or the V-SLP address from the E-CSCF 254 (not shown in FIG. 5) if the E-CSCF 254 does not automatically transmit this information, following the re-registration of the UE 110 in step 4. The E-SLP 272 may then open a new SUPL transaction with UE 110 by sending a SUPL INIT directly to the UE using a mobile interrupt IP or UDP / IP (in which case step 18 may be skipped) or sending an instant message, which contains the SUPL INIT, in the E-CSCF 254. SUPL INIT may include the parameters described above for step 7.

At step 18, the E-CSCF 254 transmits to the UE 110 SUPL INIT in an IMS instant message, some other IMS message, a SIP message (eg, re-invitation), or some other IP-based message that uses secure IP associative communications between E-CSCF 254, P-CSCF 252 and UE 110.

In step 19, the UE 110 creates a secure IP connection with the E-SLP 272. The UE 110 can then exchange SUPL messages with the E-SLP 272 for proxy mode or with the E-SPC 414 or V-SPC 424 for proxy mode (similar to steps 9, 10 and 11) to obtain an accurate position estimate for the UE.

At step 20, the E-SLP 272 sends an accurate position estimate to the UE 110 in the location response in the PSAP 180. For an emergency call in the United States, the location response may be identical to the emergency position response message in J-STD-036 for the E2 interface if PSAP 180 allows PSTN (and may thus include additional information, such as MSISDN UE 110). For emergency VoIP calls in some other regions of the world, the location response may be identical to the immediate emergency location response defined for OMA MLP.

UE 110 may therefore communicate with PSAP 180 for an emergency VoIP call. When the call is later disconnected, the E-CSCF 254 can send an indication to the E-SLP 272, which can then transmit any call record. The E-CSCF 254 or UE 110 may also deregister the emergency public user ID that was registered in steps 2 through 4. Alternatively, the E-CSCF 254, E-SLP 272 and UE 110 may allow the recording and recording of calls for some interval time to support a possible later callback from the PSAP 180 to the UE 110 and / or additional location requests.

1.2. Providing access

For step 1, the UE 110 may connect to the access network through access to GPRS, access to cdma2000, or through access to the WLAN. Step 1 can be performed in various ways for different types of access.

To access GPRS, the UE 110 can connect to GPRS to connect to a 3GPP access network, and can contextually activate GPRS Packet Data Protocol (PDP) to enable IP connectivity on SGSN 232a and GGSN 232b, as described in 3GPP TR 23.867 and TS 23.060. An emergency designation can be used in conjunction with GPRS, and / or a global access point name (APN) for emergency services can be used to contextually activate PDP, which can guarantee the provision of GGSN and P-CSCF in V-PLMN 130. P-CSCF 252 can be P-CSCF in serving GPRS PLMN as provided during PDP context activation.

For WLAN access, the 3GPP UE 110 may perform a WLAN AAA procedure for connecting to a WLAN and may create an I-WLAN tunnel for IP connectivity with the PDG 236. UE 110 may select a service from V-PLMN 130 using a roaming network access identifier ( NAI), which indicates both the H-PLMN 160 and the V-PLMN 130 in the authentication and authorization request. Roaming NAI is described in 3GPP TS 23.234 and TS 23.003. This ensures that the UE 110 can obtain IP access to IMS services from the PDG 236 in the V-PLMN 130, and not from the PDG in the H-PLMN 160 (which can restrict PSAP access if the H-PLMN 160 is remote). The Emergency WLAN Global APN (W-APN) can be used to detect PDGs and create a tunnel. This service can use the global unique identifier of the external network (to support emergency services) and the V-PLMN identifier. P-CSCF 252 may be a P-CSCF in a V-PLMN, with an associated WLAN, and may be detected through a DNS query on a W-APN.

For access, the cdma2000 UE 110 receives a simple IP address, not a mobile IP address, since the service is provided from V-PLMN 130, and not from H-PLMN 160. Alternatively, UE 110 can receive a mobile IP address from V-PLMN 130 and not from the H-PLMN 160, as is more common for a mobile IP address. The IP address can be an IPv4 address or an IPv6 address. If UE 110 has not established connectivity (for example, it does not have an assigned IP address), then UE 110 can establish a point-to-point protocol (PPP) session and perform any authentication and authorization with PDSN 242 on V-PLMN 130, as described in 3GPP2 X.P0011D and TIA-835-D. UE 110 may obtain a simple IP address, for example, using the PPP control IP protocol (IPCP).

If UE 110 has already established IP connectivity and has a PPP session with PDSN 242, but it is assigned mobile IP address (s) in H-PLMN 160 instead of simple IP address (s), then UE 110 can interrupt any packet sessions, associated with these IP addresses, as well as with any IMS registration, if the UE 110 cannot simultaneously support simple IP and mobile IP addresses, which is an additional, but not necessary, possibility of the UE in the TIA-835D. UE 110 may then obtain a simple IP address, as described in TIA-835D. If the UE 110 supports both simple and mobile IP addresses, then the UE 110 can only obtain a simple IP address if it does not already have one.

For access, the cdma2000 UE 110 can discover the P-CSCF address in the V-PLMN 130 by (a) using DHCP or IPCP to obtain the P-CSCF domain name and DNS address from the DHCP server or PDSN 242 and then (b) using DNS to obtain one or more P-CSCF IP addresses from a DNS server. If the UE 110 moves and accesses the new RAN, then the V-PLMN 130 and the UE 110 can use the fast handoff procedure described in TIA-835-D if a new end PDSN is needed and if an emergency VoIP call is already set up.

This avoids the need to interrupt and re-establish the call.

For 3GPP2 access, the WLAN UE 110 can perform an existing WLAN access procedure, including AAA, obtaining an IP address and discovering a default IP router and DNS server address (for example, via DHCP). UE 110 may then access the PDIF in the PLMN, which supports emergency calls from the geographic location of the WLAN accessed by the UE 110. The WLAN can notify cdma2000 networks so that emergency calls supporting PLMN can be distinguished. This notification can be obtained, for example, by sending the associated Service Set Identifiers (SSIDs) in IEEE 802.11 “Failure” frames or through responses to UE sounding request frames. The PLMNs may be prioritized in the order in which they are notified, using a pointer for each notified PLMN or by ensuring (for example, requiring) that all notified PLMNs support emergency calls. For initial access to the WLAN, AAA, and obtaining an IP address, the UE 110 may select a PLMN (e.g., SSID), which implies or indicates support for emergency calls.

Following the initial access to the WLAN, AAA, obtaining the IP address and finding the default router and the DNS server address, the UE 110 can create a fully qualified domain name (FQDN) that indicates the IMS service and uses the domain associated with one of the PLMNs. a proclaimed WLAN that supports emergency calls. UE 110 may then use the FQDN to discover the IP address (s) of one or more PDIFs from the DNS server. The UE can select a PDIF and establish an IPsec tunnel to it using the procedures described in 3GPP2 X.S0028-200. This provides the UE 110 with a second internal IP address that can be used for subsequent IMS related procedures.

Following the creation of a tunnel to the PDIF from the WLAN, the UE 110 can detect the P-CSCF address in the same way as the UE accessing the PDSN from the cdma2000 access network (for example, via DHCP to obtain the DNS server address and domain name and then through DNS to obtain the P-CSCF IP address). In this case, the PDIF can act as a DHCP translation agent instead of the PDSN. The discovery of PIDF and P-CSCF addresses through DNS may include an indication (for example, in the name provided to the DNS server) that emergency call support is required.

If the UE 110 already has a connection (e.g., a tunnel) with a PDIF in an inappropriate PLMN and if the UE 110 does not support tunnels simultaneously with different PDIFs, then the UE 110 can end any packet sessions supported through the current PDIF and release the tunnel with the PDIF before selecting and creating a tunnel with a new PDIF in a new suitable PLMN.

After connecting to the access network, either cdma2000 or WLAN, the UE 110 can detect the SUPL V-SLP address using a DNS query with the well-known V-PLMN domain name and V-SLP authentication (for example, supl_vslp @ domain_name).

The 500 message flow has the following feature additions related to OMA SUPL version 1.0.

(a) Adding an E-SLP address to the SUPL INIT, which cancels and replaces the H-SLP address configured in UE 110.

(b) An interface between an IMS side (e.g., E-CSCF 254) and a location side (e.g., E-SLP 272).

(c) Use of the V-SLP 274 and discovery of the V-SLP address.

(d) SUPL INIT transmission using mobile interruptable IP, UDP / IP, SIP or IMS signaling instead of SMS or active WAP delivery to reduce latency.

(e) Adding the emergency designation to SUPL INIT.

(f) Preference for adding new measurements to a new location in SUPL POS INIT.

(g) Use of an ILP protocol between E-CSCF 254 and E-SLP 272, which may be similar to an existing RLP.

(h) Security.

2. Emergency call VoIP control plane 3GPP

FIG. 6 shows a block diagram of an embodiment of a network architecture 600 applicable to a 3GPP control plane location. For simplicity, FIG. 6 shows only objects and interfaces that are relevant for supporting VoIP emergency calls with GPRS access and 3GPP control plane location.

Access network 120 may be a GERAN or UTRAN. V-PLMN 130 may include P-CSCF 252, E-CSCF 254 and MGCF 258 to support IMS (e.g., VoIP), SGSN / GGSN 232 for packet-switched services, and GMLC 276 for location services. GMLC 276 replaces E-SLP 272 and is an improved version of GMLC described in 3GPP 23.271 Release 6. V-PLMN 130 may also include E-SLP 272 and V-SLP 274 for location services (not shown in FIG. 6) .

In an embodiment, the GMLC 276 communicates with the E-CSCF 254 via the Li interface and communicates with the PSAP 180 through the J-STD-036 E2 'interface. Using the same Li interface for the GMLC 276 and E-SLP 272 can obscure the differences in the location architecture between the SUPL and 3GPP control plane from the E-CSCF 254. Similarly, using the same J-STD-036 E2 'interface for the GMLC 276 and E -SLP 272 may obscure differences in location architecture from PSAP 180. Other interfaces in FIG. 6 are known in the art.

2.1. Call setup

FIG. 7 shows an embodiment of a message flow 700 for establishing an emergency VoIP call using the 3GPP control plane. For clarity, objects that are less significant (e.g., access network 120, P-CSCF 252, S / R 292) are omitted from FIG. 7, but are included in the descriptions below. Message flow 700 assumes that UE 110 has a UICC and that there is a roaming agreement between H-PLMN 160 and V-PLMN 130.

In step 1, the UE 110 connects to the GPRS indicating emergency services if the UE is not yet connected to the GPRS. Connecting to GPRS may entail gaining access to the SGSN 232a, performing any authentication and downloading subscription data from the HLR / HSS 266 to the H-PLMN 160 on the SGSN 232a and so on. In step 2, the UE 110 performs contextual activation of the PDP using the global emergency APN. The PDP context is assigned to the local GGSN in V-PLMN 130 (for example, and not GGSN in H-PLMN 160). UE 110 obtains an IP address and can detect the address of a local SIP server (for example, P-CSCF 252) during PDP context activation.

In step 3, the SGSN 232 becomes aware of initiating an emergency call based on the emergency indication in step 1 or the global emergency APN in step 2. The SGSN 232a can then initiate a forced packet-switched network location request (PS-NI-LR) described in 3GPP TS 23.271, to obtain either an intermediate position estimate or a more accurate position estimate for UE 110. The PS-NI-LR provides a faster response than if the SGSN 232 were waiting for a request to obtain a position estimate (for example, via the PSL MAP in step 17 ) from GMLC 276. PS-NI-LR may for it performed the original SGSN. If the service of the UE 110 is transferred to the new SGSN, then the new SGSN does not need to execute another PS-NI-LR. In step 4, if a position estimate is obtained for UE 110, the SGSN 232 can determine the GMLC address (for example, from the current cell identifier) and can then send to the GMLC 276 a MAP subscriber location report (SLR) that contains the position estimate, the UE identifier and / or other information. The UE may be an international mobile subscriber identifier (IMSI), a mobile subscriber's ISDN number (MSISDN), an international mobile equipment identifier (IMEI), an electronic serial number (ESN), a mobile equipment identifier (MEID), or another identifier. If step 4 is performed, then steps 10 and 11 may be skipped.

In step 5, the UE 110 sends a SIP REGISTER to the P-CSCF 252, which was detected in step 2. The SIP REGISTER may include the information described above for step 2 in FIG. 5, and may also include an SGSN address if steps 10 and 11 are also to be performed. Due to the presence of an emergency service indication or an emergency public user identifier, the P-CSCF 252 forwards the SIP REGISTER to the E-CSCF 254 on the same network. Step 5 may be performed in parallel with step 3. In step 6, the E-CSCF 254 sends SIP REGISTER to the H-PLMN 160, where the usual IMS registration occurs, similar to step 3 in FIG. 5.

In step 7, after the H-PLMN 160 returns a 200 OK message to the E-CSCF 254, the 200 OK message returns to the UE 110. The UE 110 may also re-register if there is a handoff to another SGSN in the V-PLMN 130. If the UE 110 is re-registered using its emergency public user identifier, then the E-CSCF 254 may transmit any new location information and / or any new SGSN address to the GMLC 276.

As, for example, in FIG. 5, in an alternative embodiment, in steps 5, 6 and 7, after the UE 110 sends the SIP REGISTER to the P-CSCF 252 in step 5, the P-CSCF 252 can send the SIP REGISTER directly to the S-CSCF 264 or to the I-CSCF 262 to H-PLMN 160 and bypass E-CSCF 254 to V-PLMN 130. In this case, the 200 OK SIP message from H-PLMN 160 is returned to P-CSCF 252, and not to E-CSCF 254, and P-CSCF 252 returns 200 OK message to UE 110 in step 7. This alternative embodiment can reduce or avoid specific effects on the P-CSCF 252 to support emergency VoIP calls, as the actions of the P-CSCF 252 are then similar to those that exist for regular registration.

In step 8, the UE 110 sends a SIP invitation to the P-CSCF 252, which may include the information described above for step 5 of FIG. 5. The P-CSCF 252 sends a SIP invitation to the E-CSCF 254.

In step 9, based on UE support of the 3GPP control plane for burst mode, the E-CSCF 254 sends a routing request to the GMLC 276 indicated by the serving cell or other location information received in step 8. The routing request may include the information described in step 6 in FIG. 5, as well as the SGSN address, if provided at the time of registration. E-CSCF 254 may select GMLC 276, a common location server capable of acting like a GMLC, or some other type of server (e.g., SLP). The selected location server may choose to use the 3GPP control plane based on the location capabilities of the UE transmitted by the E-CSCF 254. The E-CSCF 254 may request location information from the GMLC 276 and / or PSAP selection corresponding to the available location information and type of emergency service, which is requested.

GMLC 276 proceeds to step 12 if the location information provided in step 9 allows the GMLC 276 to obtain a position estimate for UE 110 that is accurate enough to satisfy the request in step 9. GMLC 276 may also wait until it receives the MAP SLR from SGSN 232 in step 4, and if an appropriate position estimate is obtained, proceeds to step 12. Otherwise, steps 10 through 11 are performed to obtain an appropriate position estimate for UE 110.

In step 10, the GMLC 276 sends to the SGSN 232 a MAP subscriber location (PSL) provision that contains QoP accuracy / delay for a quick intermediate position estimate. If step 4 is not completed, then GMLC 276 may determine the SGSN 232 from the explicit address or location information (eg, cell identifier) received in step 9. If no such information was received or if the SGSN that was originally selected is erroneous ( the error response adopted in step 11), then the GMLC 276 may request the HSS indicated by the IMSI UE, or the pseudo-IMSI, or MSISDN to obtain the SGSN address. In step 11, the SGSN 232 may return the position estimate obtained in step 3, wait until step 3 is completed, and then return the position estimate or obtain a position estimate from the RAN and then return the position estimate to GMLC 276.

At step 12, the GMLC 276 selects the PSAP based on the position estimate. The following description assumes that the PSAP 180 is the selected PSAP. If the PSAP 180 is PSTN capable, then the GMLC 276 obtains an ESRD of a non-dialing number that can be used for routing in the PSAP 180, and an ESRK of a non-dialing number that identifies the PSAP 180, GMLC 276 and, temporarily, UE 110.

In step 13, the GMLC 276 returns a routing response to the E-CSCF 254, which may include the information described above for step 13 of FIG. 5. At step 14, an emergency call is sent to the PSAP 180, as described for steps 14a, 14b and 14c in FIG. 5. In step 15, the remaining emergency call setup proceeds as described for steps 15a and 15b in FIG. 5. In step 16, the PSAP 180 sends a location request to the GMLC 276, which is indicated in step 14 either with an IP address / name or ESRK, as described for step 16 in FIG. 5.

In step 17, the GMLC 276 sends the PSL MAP to the SGSN 232, requesting the exact location. GMLC 276 may obtain an SGSN address from the most recent location information for UE 110 or from updating the SGSN address from E-CSCF 254. GMLC 276 may also request an SGSN address from E-CSCF 254 if this address is received in the re-message registration, but not transferred. GMLC 276 may also request an SGSN address from an HSS indicated by an IMSI UE, or a pseudo-IMSI, or MSISDN. At step 18, the SGSN 232 initiates the positioning of the UE 110 using the RAN. In step 19, the SGSN 232 returns the position estimate in the GMLC 276. In step 20, the GMLC 276 returns the position estimate in the PSAP 180, as described for step 20 in FIG. 5.

UE 110 may therefore communicate with PSAP 180 for an emergency VoIP call. When the call is later disconnected, the E-CSCF 254 may send an indication to GMLC 276, which can then transmit any call record. The E-CSCF 254 or UE 110 may also deregister the emergency public user identifier that is registered in steps 5 through 7. Alternatively, the E-CSCF 254, GMLC 276 and UE 110 may allow the recording and recording of calls for a period of time, to support a possible later callback from the PSAP 180 to the UE 110 and / or additional location requests.

Message flow 700 performs call setup and positioning for UE 110 in a coordinated manner and has the following features.

(a) SGSN 232 can obtain the location of the UE and place it in GMLC 276 whenever the PDP context is activated and / or if requested by GMLC 276.

(b) GMLC 276 may receive a public SIP-URI address for UE 110 from E-CSCF 254.

(c) If the PSAP 180 allows PSTN, the GMLC 276 and the E-CSCF 254 can transmit information to the PSAP 180 (e.g., 10-bit ESRK) used for identification and calling, and GMLC 276. This information allows the PSAP 180 to retrieve information about location and other information (e.g. MSISDN, SIP URI) from GMLC 276.

(d) The Li interface between the E-CSCF 254 and the location server (e.g., E-SLP 272) can be used to support emergency calls from the I-WLAN when SUPL is used as a positioning method. Using the same Li interface for UMTS, GPRS, and I-WLAN allows IMS (for example, E-CSCF 254) to work without the need for knowledge of a location solution that can simplify IMS management.

(e) If the UE 110 does not support positioning using the RAN (for example, supports SUPL rather than the 3GPP control plane), then the SGSN 232 may skip the PS-NI-LR.

(f) PSAP 180 may have certain location requirements that may not be known to SGSN 232, for example, specific accuracy or even lack of support for location coordinates (for example, if PSAP 180 supports phase E911 0 or 1). Similar requirements are supported in GMLC 276 for circuit-switched emergency calls.

The Li interface can be used to achieve the capabilities listed above. Support for the Li interface may not be necessary externally if the GMLC and E-CSCF functions are supported on the same platform. The Li interface can be extended to use between the IMS entity and the GMLC to support other capabilities associated with IMS and IP-based services, as described above for SUPL.

SGSN 232 may be selected based on an intermediate position estimate (eg, discussing cells) for UE 110. GMLC 276 may be selected using E-CSCF 254 based on the same intermediate position estimate. An intermediate position estimate can be placed from SGSN 232 in GMLC 276 or retrieved using GMLC 276 from SGSN 232. One object can define another object as follows.

SGSN 232 can put an interim position estimate in GMLC 276. SGSN 232 can get an interim position estimate via PS-NI-LR, determine the GMLC address according to the current location of the UE (for example, the current cell identifier) and send / put the position estimate in GMLC 276, Using Subscriber Location Report (SLR) MAP. E-CSCF 254 may request a GMAP 276 PSAP address in order to place an emergency call. GMLC 276 can expect (if necessary) a MAP SLR from SGSN 232 in order to determine the PSAP address from an interim position estimate.

GMLC 276 may receive an interim position estimate from SGSN 232. SGSN 232 may still perform PS-NI-LR but does not send the position estimate to GMLC 276 until the GMLC requests a position estimate through the PSL MAP request. GMLC 276 may determine the SGSN address using one of the following.

(a) GMLC 276 requests an SGSN address either from HSS 266 to H-PLMN 160 (if UE 180 has UICC and roaming supported in V-PLMN 130) or HSS 250 to V-PLMN 130 (if UE 180 does not have UICC or roaming agreements in V-PLMN 130).

(b) UE 110 includes the current SGSN address or location information (e.g., GPRS cell identifier) from which the SGSN address can be derived in each registration or re-registration message sent to the IMS or in each invitation message SIP sent to the IMS for an emergency call. The E-CSCF 254 then transmits the SGSN address or location information to GMLC 276. UE 110 re-registers with the IMS, which follows any internal handoff to the SGSN.

3. Emergency VoIP Call with X.S0024

FIG. 8 shows a block diagram of an embodiment of a network architecture 800 applicable to an X.S0024 location for cdma2000 networks. Access network 120 may comprise a CDMA2000 1X network, a CDMA2000 lxEV-DO network, a 3GPP2 WLAN, and so on. V-PLMN 130 may include P-CSCF 252, E-CSCF 254, and MGCF 258 to support IMS (e.g., VoIP) and PDSN 242 for packet-switched services (not shown). V-PLMN 130 may include E-PS 282 and V-PS / PDE 284 (as shown) and may also include E-SLP 272 and V-SLP 274 (not shown) for location services. The E-PS 282 replaces the H-PS for locating emergency calls. The E-PS 282 and V-PS / PDE 284 can reside on other networks.

In an embodiment, the UE 110 communicates with the E-PS 282 through the LCS-x interface and communicates with the V-PS / PDE 284 through the LCS-y interface. The E-PS 282 communicates with the V-PS / PDE 284 through the LCS-z interface, communicates with the E-CSCF 254 through the LCS-i interface, and communicates with the PSAP 180 through the J-STD-036 E2 'interface. The LCS-i interface can be similar to RLP or Li / ILP for SUPL, the v2 interface in the NENA I2 solution, or another interface. The protocol for the LCS-i interface may be the ILP used for SUPL. The LCS-x, LCS-y, and LCS-z interfaces are described in X.S0024.

3.1. Call setup

FIG. 9 shows an embodiment of a message flow 900 for establishing an emergency VoIP call using X.S0024. In step 1, the UE 110 detects and connects to the access network, creates IP connectivity, and can detect the local SIP server (for example, P-CSCF 252), as described above for step 1 in FIG. 5. After connecting to the access network, the UE 110 can detect the V-PS address using a DNS query with the well-known V-PLMN domain name and V-PS identity (for example, xs0024_vps @ domain_name).

In step 2, the UE 110 sends a SIP REGISTER to the P-CSCF 252, which sends a message to the E-CSCF 254. In step 3, the E-CSCF 254 sends the SIP REGISTER to the H-PLMN 160, where normal IMS registration occurs. In step 4, the E-CSCF 254 (for example, after receiving a 200 OK message from the H-PLMN 160) returns a 200 OK message to the UE 110. The UE 110 may re-register if it is transferred to another PCF, PDSN, or WLAN in the same V-PLMN.

In an alternative embodiment, in steps 2, 3, and 4, after the UE 110 sends the SIP REGISTER to the P-CSCF 252 in step 2, the P-CSCF 252 can forward the SIP REGISTER directly to the S-CSCF 264 or to the I-CSCF 262 in H -PLMN 160 and bypass E-CSCF 254 in V-PLMN 130. In this case, the 200 OK SIP message from H-PLMN 160 is returned to P-CSCF 252, and not to E-CSCF 254, and P-CSCF 252 returns message 200 OK in UE 110 in step 4. This alternative embodiment can reduce or avoid specific impacts on the P-CSCF 252 to support emergency VoIP calls, as the actions of the P-CSCF 252 are then similar to those that exist for ychnoy registration.

In step 5, the UE 110 sends a SIP REGISTER to the P-CSCF 252 (not shown), which sends the SIP invitation to the E-CSCF 254. In step 6, the E-CSCF 254 can determine that the UE 110 supports X.S0024, and send a routing request on an E-PS 282 on the same or different network. The routing request may include the information described above for step 6 in FIG. 5, and the V-PS address, if received at the time of registration.

E-PS 282 proceeds to step 12 if the location information provided in step 6 allows the E-PS 282 to obtain a sufficiently accurate position estimate for UE 110. Otherwise, steps 7 through 11 are performed to obtain an appropriate position estimate for UE 110. At step 7, the E-PS 282 acts as an H-PS in performing the subsequent determination of the X.S0024 position, using procedures similar to those for (a) maintaining X.S0024 roaming if a V-PS was selected, or (b) X-roaming support. S0024 if V-PS has not been selected. The E-PS 282 generates an X.S0024 SUPL UNIT to invoke a network-initiated positioning procedure using the UE 110. The E-PS 282 can send the SUPL INIT directly to the UE 110 using a mobile interrupt IP or UDP / IP, in which case step 8 can to be skipped. E-PS 282 can also send SUPL INIT in instant message to E-CSCF 254. In any case, SUPL INIT can include positioning mode, QoP accuracy / delay for quick intermediate position estimation, E-PS IP address, emergency indication call and so on. Any E-PS address transmitted in SUPL INIT overrides any H-PS address configured in UE 110.

In step 8, the E-CSCF 254 sends the SUPL INIT to the UE 110 through the P-CSCF 252 using the IMS or SIP signaling. In step 9, the UE 110 creates a secure IP connection with the E-PS 282, which can be an H-PS for the UE 110 or the IP address of which can be included in the SUPL INIT in step 7. The UE 110 then sends a message to the E-PS 110 SUPL START, which may include location capabilities of the UE, location information for UE 110, position estimation for UE 110 (if available), and so on. The E-PS 282 may proceed to step 12 and abort the location transaction with the UE 110 by sending a SUPL END message if a position estimate with sufficient accuracy to determine the PSAP is received from the UE 110 in step 9.

In step 10, the E-PS 282 determines the corresponding local PDE or the corresponding remote V-PS to perform position determination based on the location information received in step 9, or other location information received in step 6. The E-PS 282 also decides whether to use the intermediary or immediate mode. The E-PS 282 then interacts with the V-PS or PDE to determine the position and sends an X.S0024 SUPL response to the UE 110, which may include the IP address of the PDE if direct mode is selected. At step 11, the UE 110 exchanges SUPL POS messages with the PDE in direct mode or with the E-PS 282 in mediation mode to continue and complete the position determination, as described in 3GPP2 X.S0024-0. Messages SUPL POS can carry embedded IS-801 messages. The position determination provides a position estimate for UE 110, which is transmitted to the E-PS 282.

In step 12, the E-PS 282 selects a PSAP (e.g., PSAP 180) and obtains an ESRD and ESRK if the PSAP 180 allows PSTN. At step 13, the E-PS 282 returns to the E-CSCF 254 a routing response that may include a PSAP identifier if the PSAP 180 allows IP, ESRD and ESRK if the PSAP 180 allows PSTN, and a position estimate for the UE 110 if requested using the E-CSCF 254. The E-PS 282 may store for the UE 110 a call record that contains all the information collected for the UE. Steps 14a and 15a are performed if the PSAP 180 allows IP. Steps 14b, 14c and 15b are performed if the PSAP 180 allows PSTN. In step 16, after the call is established, the PSAP 180 may send a location request for an accurate position estimate to the E-PS 282, which can be identified using the IP address or name obtained in step 14a or the ESRK obtained in step 14c .

In step 17, the E-PS 282 can open a new transaction X.S0024 with the UE 110 by sending a SUPL INIT directly to the UE 110 using a mobile interrupt IP or UDP / IP (in which case step 18 is skipped) or by sending to E- CSCF 254 instant message that contains X.S0024 SUPL INIT with the parameters described in step 7, excluding QoP accuracy / delay for accurate position estimation. At step 18, the E-CSCF 254 transmits the SUPL INIT in an IMS instant message, SIP message, or other message to the UE 110. At step 19, the UE 110 establishes an IP connection (eg, a secure IP connection) with the E-PS 282 and returns SUPL START with E-PS 282. E-PS 282 determines the appropriate PDE or V-PS for positioning based on any location information in the SUPL START and based on any other location information for UE 110. E-PS 282 then starts positioning, returning a SUPL response to UE 110. UE 110 may then exchange SUPL POS messages with the E-PS 282, a local PDE and / or a remote PDE for I perform positioning and obtain an accurate position estimate for UE 110. At step 20, the E-PS 282 sends an accurate position estimate to UE 110 in the location response in PSAP 180.

UE 110 may therefore communicate with PSAP 180 for an emergency VoIP call. When the call is later disconnected, the E-CSCF 254 can send an indication to the E-PS 282, which can then transmit any call record. The E-CSCF 254 or UE 110 may also deregister the emergency public user ID that was registered in steps 2 through 4. Alternatively, the E-CSCF 254, E-PS 282 and UE 110 may allow the recording and recording of calls for some a time interval to support a possible later callback from the PSAP 180 to the UE 110 and / or additional location requests.

Further details for steps 1 to 8 and steps 12 to 20 in FIG. 9 can be described for steps 1 to 8 and, respectively, steps 12 to 20 in FIG. 5.

The 500 message flow has the following features associated with X.S0024.

(a) Adding an E-PS address to the SUPL INIT X.S0024 that cancels and replaces the H-PS address configured in UE 110 or UIM.

(b) An interface between an IMS side (e.g., E-CSCF 254) and a location side (e.g., E-PS 282).

(c) Using the V-PS 284 and detecting the V-PS address.

(d) SUPL INIT X.S0024 transmission using mobile interruptible IP, UDP / IP, SIP or IMS signaling.

(e) Adding the emergency designation to SUPL INIT X.S0024.

(f) Using a new protocol between the E-CSCF 254 and the E-PS 282, which may be similar to the OMA RLP or PS-PS protocol in the LCS-z interface in X.S0024.

(g) Security.

4. Support UE without UICC / UIM and / or roaming agreement

The description above assumes that the UE 110 has a UICC or UIM and that the H-PLMN 160 and V-PLMN 130 have a roaming agreement that allows registration of the UE in the V-PLMN 130 and subsequent emergency call access to the PSAP 180. If this is not the case then the UE 110 can access and register with the V-PLMN 130 and can complete the call setup in the PSAP 180 and a possible callback from the PSAP 180, as described below. A callback from the PSAP 180 in the absence of UICC / UIM is possible for VoIP, but is usually not possible for emergency packet-switched access due to the inability to send a message to an unregistered UE.

FIG. 10 shows a block diagram of an embodiment of a network architecture 1000 that supports the establishment of an VoIP emergency call and PSAP callback for a UE without UICC / UIM. Network architecture 1000 includes some of the entities shown in FIG. 2 and 3. The network architecture 1000 also includes a location server 286, which may be an SLP, GMLC, PS, or other location object.

4.1. Providing access

UE 110 may access GPRS, 3GPP WLAN access, or IMS access without UICC. UE 110 may access cdma2000, 3GPP WLAN access, or IMS access without UIM. UE 110 may perform various procedures for various types of access.

For GPRS access, UE 110 may perform PDP context activation for emergency services without UICC and / or without roaming agreement in V-PLMN 130, as described in 3GPP TR 23.867. A GPRS connection can be obtained using a pseudo-IMSI, which can register the UE 110 in the HSS 250 in the V-PLMN 130, which, in turn, can help support handoff within the SGSN. If the UE 110 does not have a UICC, then a pseudo-IMSI can be created with a unique MCC-MNC combination and bits from the IMEI. If the UE 110 has a UICC but does not have roaming access to the V-PLMN 130, then a pseudo-IMSI can be created with bits from the IMSI and not from the IMEI, which can avoid double pseudo-IMSI if all the IMSI bits are used. A GPRS connection can also be obtained using IMEI for identification.

For 3GPP access, the WLAN UE 110 may create pseudo-NAIs from pseudo-IMSIs (for example, the same IMSI used for GPRS connections) as follows:

Pseudo-NAI = "n <pseudo-IMSI> @ V-PLMN_network_domain",

where n is a fixed bit in the range from 2 to 9, indicating the use of an unauthenticated pseudo-NAI for emergency calls (0 or 1 has already been accepted for conventional NAI). UE 110 may use pseudo-NAI for initial access and AAA procedures.

The WLAN may advertise V-PLMNs capable of supporting AAA using pseudo-NAIs for emergency services, or may represent V-PLMNs in priority order, which indicates the possibility and readiness to support it. V-PLMN 130 may consider UE 110 as a temporary own subscriber and may either skip AAA or ensure that it succeeds (for example, using well-known keys to ensure that authentication succeeds). It may be desirable to follow the usual procedures, if possible, and register the UE 110 with the HSS 250 in order to better support WLAN reselection and handoff.

For access, the cdma2000 UE 110 may create a PPP session with PDSN 242 and may reject authentication during PPP creation, returning a Link Control Protocol (LCP) configuration rejection in response to a LCP configuration request from PDSN 242, for example, as described in IETF RFC 1661. The PDSN 242 can support emergency calls for non-UIM UEs or for unauthenticated UEs and can continue to establish a PPP session without authenticating the UE 110. PDSN 242 can assign a simple IP address to the UE 110 and can use IP packet filtering to restrict the objects that it can interfere with enable UE 110. For example, PDSN 242 can restrict UE 110 in interaction with local servers (for example, DHCP server, DNS server and P-CSCF 252) and with objects associated with access to PSAP, but not with open Internet access .

PDSN 242 can be informed of an emergency call in several ways. In an embodiment, the UE 110 sends to the PDSN 242 an IPCP configuration request containing a unique IP address that is set globally to indicate an IP address request for an emergency call. In other embodiments, directions may be used in establishing PPP, or the PDSN 242 may receive an emergency call indication from the RAN (RRC / PCF 222) via the cdma2000 A10 interface. In any case, the PDSN 242 can assign a simple IP address to an unauthenticated UE for an emergency call and can use special filtering, as described above. This IP address assignment can be obtained through the improvement in IPCP PPP described in IETF RFC 1332. If the UE 110 does not indicate an emergency call, then the PDSN 242 may prohibit PPP establishment and IP assignment.

Instead of rejecting authentication, the UE 110 may allow authentication to continue using either the password authentication protocol (PAP) or mutual authentication protocol (CHAP), which are described in IETF RFC 1334 and, accordingly, in RFC 1994. UE 110 can accept a CHAP call request or PAP authentication, and may send a response that includes an identifier that indicates an emergency call from a UE without a UIM. This identifier may be a pseudo-MSI used for 3GPP2 WLAN access. If the identifier indicated V-PLMN 130 as a domain for UE 110, then CHAP or PAP authentication can continue as usual from the point of view of PDSN 242 in AAA server 246 in V-PLMN 130. AAA server 246 AAA can recognize pseudo-IMSI as an indication emergency call access and may precede normal authentication or may authenticate using known keys. The AAA server 246 can ensure that limited filtering is used by the PDSN 242 to restrict IP access, for example, to allow emergency VoIP calls, but not other types of access.

PDSN 242 may create an NAI for accounting and / or registration.

PDSN 242 may use a unique international UE identifier (IMSI, MIN, or international roaming MIN-IRM) if the UE 110 has a UIM. PDSN 242 may also use an ESN or other identification for UE 110.

For 3GPP2 WLAN access, after the UE 110 accesses the WLAN, the access point or authentication object may initiate authentication of the UE 110 and may send an Extended Authentication Protocol (EAP) request or other identifier request of the UE 110. UE 110 may respond by returning an EAP response or another response containing the UE identifier, for example, in the form user @ domain, where the domain defines the H-PLMN of the UE 110. If the UE 110 does not have a UIM or roaming agreement in the V-PLMN 130, then the UE 110 may return a pseudo identifier, which may be same or similar Sevda-NAI, used for 3GPP WLAN. For example, a user (e.g., pseudo-IMSI) portion of a pseudo-identifier may contain bits from a unique international UE identifier (e.g., MSI, MIN, or IRM) if the UE 110 has a UIM or, otherwise, bits from a unique terminal identifier (e.g., ESN). The user part may also contain a unique prefix (for example, a unique rank) to indicate that it is a pseudo-identifier for emergency calls. The domain part of the pseudo-identifier may indicate V-PLMN 130.

The access point or authentication object can continue authentication using a local AAA server, for example, AAA server 246. Authentication can be performed usually using known keys, or it may be truncated because true authentication does not take place. If pseudo-authentication is complete, the access point or associated router may use packet filtering to restrict access to the UE 110, as described above.

UE 110 may access the WLAN, perform pseudo-authentication, and detect PDIF. UE 110 may then identify itself in a PDIF (or local AAA server) using a pseudo-identifier, for example, instead of the NAI used to authenticate the cdma2000 UE-PIDF. The pseudo identifier may be the same or similar to that used for WLAN authentication. Basic authentication and tunneling can then continue (for example, as described in 3GPP2 X.P0028-200) using a local AAA server and using known keys to obtain transparency for PDIF. Alternatively, authentication may be truncated or terminated. After authentication, the PDIF may use packet filtering to restrict access by the UE 110.

The WLAN may announce V-PLMNs that support the above procedures, or may represent V-PLMNs in priority order, which indicates the ability and readiness for support.

For IMS access, SIP registration may be skipped if the UE 110 does not have UICC / UIM and / or roaming agreements in V-PLMN 130, as described in 3GPP TR 23.867 and 3GPP2 X.P0013-002A. This allows you to set up an emergency call in PSAP, but not support callback. Alternatively, the UE 110 may register by sending a SIP REGISTER that contains the V-PLMN domain name and an emergency private user identifier that can be created using the V-PLMN domain name and pseudo-IMSI. This SIP REGISTER message is recognized in E-CSCF 254 and HSS 250, but may be transparent to other entities.

The registration procedure may then continue as SIP REGISTER is transmitted from the UE 110 to the E-CSCF 254 (or another IMS server) to the V-PLMN 130. Registration to the H-PLMN 160 is not performed, but the E-CSCF 254 registers the UE 110 to the HSS 250 in V-PLMN 130. The HSS 250 may designate a temporary TEL URI and / or a temporary SIP URI (from the aggregate in HSS 250) as temporary public user identifiers. A TEL URI can be transmitted to the PSAP 180 when a call is established, if signaling was in the PSTN, and a SIP URI can be transmitted to establish a SIP call. The URI allows a callback from the PSAP 180 if IMS registration and IP connectivity is supported, and the V-PLMN 130 and UE 110 during the interval following the interruption of the emergency call. TEL URIs and SIP URIs are recognized by the PSAP 180 as temporary addresses due to differences from regular fixed addresses, as they are not used to globally identify the UE 110. The HSS 250 can "isolate" the temporary addresses returned from completed emergency calls and does not reassign these addresses over a period of time in order to avoid PSAP callbacks erroneously routed to inappropriate UEs.

The PSAP callback can be supported in several ways. If the UE 110 is registered with the H-PLMN 160, then the callback from the PSAP 180 can use the public SIP URI or TEL URI of the UE 110 and can be routed initially to the H-PLMN 160, as described in 3GPP TS 23.228 or 3GPP2 X.P0013. For a SIP capable of PSAP, a SIP invitation may be routed to I-CSCF 262 in H-PLMN 160 (based on the H-PLMN domain name in SIP UIP UE). I-CSCF 262 can request an HSS 250 for S-CSCF 264 in H-PLMN 160 and can then route the call to S-CSCF 264. S-CSCF 264 can then route the call to E-CSCF 254 or P-CSCF 252 in V-PLMN 130 based on previous registration information. In the previous case, the E-CSCF 254 can be considered by the S-CSCF 264 as the P-CSCF and can route the call through the P-CSCF 252 to the UE 110. In the latter case, the P-CSCF 252 can route the call to the UE 110. For a PSAP that allows PSTN , the call can be routed through the PSTN to the MGCF in the H-PLMN 160 based on the TEL URI of the UE 110. The MGCF can communicate between the PSTN and the SIP signaling and can send a SIP invitation to the I-CSCF 262 to the H-PLMN 160. Call routing from the I-CSCF 262 at UE 110 then transitions in the same manner as for SIP allowing PSAP.

If UE 110 is not registered with H-PLMN 160 (for example, due to UICC / UIM and / or there is no roaming agreement with V-PLMN 130), then UE 110 can be registered in HSS 250 in V-PLMN 130. HSS 250 can assign a temporary public user ID TEL URI or SIP URI UE 110. The callback from the PSAP can then be routed either to the I-CSCF 256 for the SIP that allows PSAP, or MGCF 258 for the PSAP that allows PSTN, without the H-PLMN 160.

4.2. Call setup

FIG. 11 shows an embodiment of a message flow 1100 for establishing an emergency VoIP call for a UE without UICC / UIM. Message flow 1100 can be used to determine the position of the 3GPP, SUPL, and X.S0024 control plane.

In step 1, the UE 110 detects and connects to the access network, creates an IP connectivity, and can detect a local SIP server (eg, P-CSCF 252), as described above. UE 110 may use pseudo-IMSI for GPRS or cdma2000 access, pseudo-NAI for WLAN access, pseudo-identifier for 3GPP2 WLAN access. UE 110 may register with HSS 250 in V-PLMN 130 using a pseudo-identifier (e.g., pseudo-IMSI).

In step 2, the UE 110 attempts to register with the V-PLMN IMS network by sending a SIP REGISTER to the P-CSCF 252, which was detected in step 1. For the case without UICC / UIM or without roaming, the SIP REGISTER may include an indication of emergency services, V-PLMN domain name, UE IP address obtained in step 1, emergency private user identifier created using the V-PLMN domain name and pseudo-IMSI (for GPRS) or pseudo-identifier (for cdma2000) and / or other information. For re-registration, SIP REGISTER may further include a temporary public user identifier assigned during initial registration. Due to the presence of an emergency service indication or an emergency private user identifier (which may indicate V-PLMN 130 as the home network for UE 110), the P-CSCF 252 routes the SIP REGISTER to the E-CSCF 254, which supports emergency calls on the same network .

A forwarded SIP REGISTER message may include location information for UE 110. SIP REGISTER may also include a V-SLP or SGSN address (for 3GPP) or a V-SLP, PDSN or PIDF address (for 3GPP2).

In step 3, since the emergency private user identifier for UE 110 refers to V-PLMN 130, the E-CSCF 254 sends registration information to the HSS 250, for example, to the Cx location / Cx extraction. In step 4, the HSS 250 checks whether an emergency private user identifier is registered, for example, if the UE 110 has already registered or another UE has registered with the same private user identifier. The HSS 250 may use a temporary public user identifier, if provided, to distinguish between UEs that have the same emergency private user identifier due to the common bits of the UE (for example, common bits of the IMEI or ESN) and to distinguish the initial registration (without a designated temporary public user) from re-registering. For initial registration, the HSS 250 stores the emergency private user identifier and E-CSCF address and assigns a temporary SIP URI to the public user and / or TEL URI, which are returned to the E-CSCF 254.

In step 5, the E-CSCF 254 returns a 200 OK message to the UE 110 through the P-CSCF 252. The 200 OK message may include temporary public user identifiers assigned by the HSS 250. The UE 110 may be re-registered if its service is transferred to another SGSN (for GPRS access), another PCF or PDSN (for cdma2000 access), another WLAN (for WLAN access) in the V-PLMN 130. In step 6, the UE 110 sends a SIP invitation to the P-CSCF 252, which may include a global SIP URL or TEL URI that indicates the emergency call, type of emergency service required, and temporary community identifiers stupid user, taken in step 5, if the UE 110 does not have UICC / UIM and / or roaming agreements in V-PLMN 130, the P-CSCF 252 sends a SIP invitation to the E-CSCF 254. In step 7, the E-CSCF 254 interacts with location server 286 for receiving PSAP routing information for the call (e.g., PSAP SIP URI or ESRD and ESRK), as described for steps 6 through 13 in FIG. 5-9 and steps 9 to 13 in FIG. 7.

Steps 8a and 9a are performed if the PSAP 180 allows IP. In step 8a, the E-CSCF 254 forwards the SIP invitation to the PSAP 180 using the SIP URI. The SIP invitation may include an interim position estimate for UE 110, the IP address or name of local server 286, and a temporary SIP public user URI assigned to UE 110. In step 9a, additional SIP signaling may occur to establish an emergency call.

Steps 8b, 8c and 9b are performed if the PSAP 180 allows PSTN. In step 8b, the E-CSCF 254 sends the SIP invitation through the BGCF to the MGCF 258. The SIP invitation may include ESRD and ESRK, and possibly a temporary public user TEL URI assigned to the UE 110. In step 8c, the MGCF 258 routes the call to the PSAP 180 through PSTN, possibly through a selective router, using SS7 ISUP and / or MF signaling. ESRD or ESRK are used as route numbers, and the ESRK is routed to PSAP 180 as an identifier of UE 110 and as a key for more information. An E.164 public user temporary number can also be transmitted to PSAP 180, if permitted by signaling capabilities. E.164 is an ITU-T standard that defines an international telephone numbering system, and an E.164 number is composed of a country code plus a national subscriber number. In step 9b, additional SIP signaling may occur, and interaction with the IS7 SSUP and / or MF in the MGCF 258 may occur to establish a call.

At step 10, the PSAP 180 can obtain an accurate position estimate for the UE 110 by requesting a location server 286, which can be indicated using the SIP URI or ESRK when the call is established. The response from the location server 286 may include any E.164 temporary user number assigned by the UE 110 if the PSAP 180 allows PSTN and if this number was not transmitted to the PSAP 180 when the call was established. The call may disconnect some time later, for example, dropped due to a temporary loss of radio coverage. The E-CSCF 254 may then wait a certain amount of time before the message to the location server 286 in order to maintain the location of the UE 110 using the PSAP 180 for subsequent callback.

The PSAP 180 attempts to call back the UE 110 using its temporary public user identifier.

Step 11a is performed for a PSAP capable of SIP. In step 11a, the PSAP 180 sends a SIP invitation to the I-CSCF 258, which can be indicated by the network domain part of the temporary SIP URI of the public user assigned to the UE 110. Steps 11b and 11c are performed for the PSAP that allows PSTN. In step 11b, the PSAP 180 sends an ISUP IAM (or MF call setup) to the MGCF 258, which may be indicated by the first bits in the E.164 temporary number of the public user assigned to the UE 110. In step 11c, the MGCF 258 sends an invitation to the I-CSCF 258 A SIP containing a TEL URI generated from an E.164 number received in step 11b.

In step 12, the I-CSCF 258 sends a location request to the HSS 250, which may include the temporary public user SIP URI received in step 11a or the temporary public user TEL URI received in step 11c. In step 13, the HSS 250 finds the registration information of the UE and returns the address of the E-CSCF 254 in the I-CSCF 258. In step 14, the I-CSCF 258 sends a SIP invitation to the E-CSCF 254. In step 15, the E-CSCF 254 determines the P-CSCF the address and sends the SIP invitation through the P-CSCF 252 to the UE 110. At step 16, the establishment of the call continues, as in the usual case.

UE 110 may therefore communicate with PSAP 180. When or after the call is later disconnected, the E-CSCF 254 may send an indication to the location server 286, which may then release any call record.

5. Support geographically remote live PSAP

In some cases, the V-PLMN and / or SIP server (eg, E-CSCF 254) may be geographically remote from the UE 110. In such cases, it may be possible to route the call through a local MGCF to a PSAP that allows PSTN if the PSTN does not support access to remote PSAPs. The following can be used to address these cases.

In an embodiment, the emergency call is redirected to another V-PLMN. At the beginning of the processing of the SIP invitation, the E-CSCF or the location server (for example, E-SLP, GMLC, etc.) may determine that the call should be redirected to the call server on another network. In this case, the SIP 3xx redirect response (for example, use proxy 305) containing the SIP URI of the preferred alternative server (s) may return to UE 110. UE 110 may then retry to call the procedures as described above, although access and procedures are IP-capable - Connections may be skipped if the same access network can still be used. If the call setup procedure has advanced to determining an intermediate position estimate and / or a valid PSAP (e.g., ESRD, SIP URI or IP address), then the E-CSCF may include this information in the redirect response. UE 110 may then include the information in the SIP invitation sent to the new PLMN, which may avoid additional delay to obtain the same information and allow the use of PLMN, not having the ability to receive this information. The source E-CSCF may notify the location server (e.g., E-SLP or GMLC), which may then delete all call records for UE 110.

In another embodiment, the E-CSCF routes the call to a SIP server on another network (or the same network), closer to the PSAP, from where the call can better be routed to the PSTN. The V-PLMN may continue to support all of the functions that have been described before, including positioning functions and support for UEs without UICC or UTM. The forwarded SIP invitation may include a PSAP identifier (e.g., SIP URI or ESRD), any ESRK assigned by the location server, and any temporary public user identifiers assigned to the UE without the UICC. The PSAP may continue to request location information from the location server in the V-PLMN, and any callback may be sent via the H-PLMN to the V-PLMN for the normal case, or routed to the V-PLMN in the case without the UICC. Continuing to support these features in V-PLMN avoids the requirements for a subsequent SIP server and should enable more other networks to support the redirected service.

In yet another embodiment, local number portability may be used, for example, in North America. In addition to returning ESRDs and ESRKs, a location server (e.g., E-SLP or GMLC) can return an LRN (Local Area Network Switch Number) to an IMS network (e.g., E-CSCF) that corresponds to an LEC exchange or a selective PSAP router through which PSAP can be achieved directly. Alternatively, an IMS network (eg, an E-CSCF or MGCF) may receive LRNs from ESRDs. The LRN is included in the information sent to the MGCF (if not received using the MGCF), and the MGCF sends to the PSTN ISUP IAM (initial address message) containing the following parameters:

Called Party Number = LRN,

Source Address Parameter (GAP) = ESRD,

The parametric bit M FCI, set to "converted number",

Caller Number = MSEDN or ESRK UE,

Caller category set to "emergency call service" (optional).

Due to the support of PSTN number portability (for example, in the USA), the call (ISUP IAM) can be routed correctly to the designated LEC CO (local telecommunications company) or to a selective router provided by SS7, rather than MF trunks that can be used everywhere . The location of the LEC CO or the selective router can support number portability and can recognize the LRN as its own when receiving a call and can receive a valid called party number (ESRD) from the GAP. The uniqueness of an ESRD or caller category setting can inform the LEC CO or selective router that it is an emergency call. From this point of view, the call can be routed to the PSAP as if it originated locally. This embodiment avoids new impacts on PSTN telephone service switches (eg, no routing changes), but may impact LEC CO and selective routers.

6. Security for SUPL and X.S0024

For SUPL, security procedures can be created to support E-SLP 272, replacing the H-SLP for positioning in both roaming and non-roaming scenarios and in intermediary and non-intermediary modes. Existing SUPL security procedures are mainly based on shared keys in both UE 110 and H-SLP and / or based on other information provided by UE 110 regarding H-SLP (e.g. fully qualified domain name, root public key certificate X .509, etc.).

This information may not be available for E-SLP 272. For E-SLP 272, authentication for intermediary and immediate modes can be supported as described below.

For X.S0024, security procedures can also be created to support the E-PS 282, replacing the H-PS for positioning. Existing X.S0024 security procedures are described in 3GPP2 X.S0024-0 and in 3GPP2 S.P0110-0. These procedures use a shared root key that is provided in both the H-PS and the user UIM. Additional keys can be inferred from the provided root key as follows:

(a) A key for supporting Secure Accumulation Encapsulation (S-SAFE), in which the SUPL INIT is sent to the UE 110 using SMS or active WAP delivery and authenticated (as incoming from the H-PS) and further encrypted.

(b) A key to support a secure IP connection between the UE 110 and the H-PS, in which X.S0024 messages are sent between the UE 110 and the H-PS with encryption and authentication.

(c) A key for maintaining a secure IP connection between the UE 110 and the PDE for immediate mode, in which X.S0024 messages are sent between the UE 110 and the PDE with encryption and authentication.

Each of the three keys described above is fixed in the sense that there is a deterministic value for any value of the root key. However, additional keys for encryption and authentication may be derived from each of these fixed keys, the values of which depend on random numbers provided by the UE and H-PS or PDE for a particular positioning session. This key output and accompanying security procedures use the Transport Layer Security (TLS) procedure described in IETF RFC 2246 and in this PSK-TLS variant described in the IETF "Transport Shared Security (TLS) Pre-Shared Encryption Key Modules (TLS)" design. If X.S0024 is used to determine the position of an emergency VoIP call and the E-PS 282 is not an H-PS, then it is no longer possible to rely on a common, pre-configured root key in both UE 110 and E-PS 282 for mutual authentication and encryption.

For SUPL, the UE 110 can authenticate the E-SLP 272 to avoid unauthorized access to the location of the UE even during an emergency call. For X.S0024, UE 110 and E-PS 282 can perform mutual authentication. Table 2 lists five authentication methods, designated as Methods A, B, C, D, and E, and the characteristics of each method.

table 2 Authentication Methods Characteristic Method A Method B Method C Method D Method E Authenticate E-SLP No Yes Yes Yes Yes Authenticate UE No Limited Yes Yes Yes Support roaming Yes Yes Yes Yes No Impact on H-PLMN No No No Yes Yes Secure UE connection with IMS required No No Yes No No Support without UICC / UIM Yes Yes (remark 1) Limited No No

Note 1: It is assumed that root certificates of public keys are provided in mobile equipment (ME). Method A provides minimal authentication. UE 110 allows a SUPL network initiated or X.S0024 location from an unauthenticated E-SLP or E-PS if the SUPL INIT message indicates locations for an emergency session and UE 110 is currently connected to the line in an emergency session. An emergency session restriction provides some protection. For SUPL, UE 110 may choose method A, but without invoking a security procedure using E-SLP 272. In this case, E-SLP 272 can still verify the UE identifier to a limited extent using the SUPL INIT hash code contained in SUPL POS INIT. In addition, the IP address of the UE 110 provided by the E-SLP 272 using the E-CSCF 254 may provide some additional guarantee of the correct UE identifier. For X.S0024 and SUPL, SUPL INIT transmission via IMS or SIP (if direct transmission via mobile interruptable IP or UDP / IP is not used) may provide some additional confidence in the authenticity of the UE, since IMS and SIP transmission is based on support and verification from V -PLMN 130 and / or H-PLMN 160.

Method B exists to authenticate the TLS public key. UE 110 and E-SLP 272 or E-PS 282 support public key authentication using TLS, as described in IETF RFC 2246 and as also described as an alternative authentication mechanism in OMA SUPL 1.0 "secure user plane location architecture". This mechanism supports H-SLP or E-PS authentication with the UE using TLS with ITU X.509 public key certificates sent via H-SLP or E-PS to the UE during the handshake phase. Public key certificates provide a chain of digital signatures, each signature that authenticates the next, so that the UE can authenticate the E-SLP or E-PS public key, provided that the UE is provided with the public key of at least one root certification authority. TLS procedure public key authentication supports the transfer of symmetric keys for use in subsequent encryption and signaling authentication, for example, for subsequent SUPL messages. Authentication and encryption between the UE 110 and the SPC or PDE for immediate mode can also be supported by these keys or by deriving additional keys from these keys. Method B is based on the certification of the public key (s) of the E-SLP or E-PS using one or more root certification authorities (for example, defined using OMA) and providing the key (s) to the UE supporting SUPL or X.S0024 for emergency VoIP calls. This guarantees authentication of the E-SLP 272 or E-PS 282 with the UE 110 and for SUPL limited authentication of the UE 110 with the E-SLP 272 via the 64-bit SUPL INIT hash code included in the SUPL INIT POS and sent using the UE 110 in E-SLP 272.

For method B, the UE 110 (e.g., UICC or UIM) may be provided with one or more root public key certificates allowing the UE to verify the public key (s) of E-SLP 272 or E-PS 282. UE 110 and E-SLP 272 or E- PS 282 can create a shared encryption key and a message authentication code (MAC) key using the TLS procedures described in RFC 2246 and one or more public key transfer procedures, such as RSA, DSS, or Diffie-Hellman. Encryption and authentication of SUPL or X.S0024 messages can be performed after creating a secure TLS connection. For direct mode, the method set for 3GPP2 direct mode in SUPL 1.0 can be used to generate a shared key for authentication and encryption according to the IETF PSK-TLS between UE 110 and V-SPC or H-SPC in SUPL or between UE 110 and PDE in X.S0024.

Method C exists for PSK-TLS authentication. UE 110 and E-SLP 272 or E-PS 282 support PSK-TLS (for example, as described in SUPL 1.0 for SET (secure electronic transactions) 3GPP2 or 3GPP2 X.S0024-0 and S.P0110-0) according to IETF project " Pre-Shared Encryption Key Modules for Transport Layer Security (TLS). " A pre-shared key (PSK) may be generated from (a) information (e.g., random information) provided by the UE 110, an IMS network (e.g., E-CSCF 254) and / or E-SLP 272 or E-PS 282, ( b) information (e.g., SIP parameters) sent by or to UE 110 during the creation of the SIP emergency call, (c) security information already present in P-CSCF 252 and UE 110 to maintain secure IMS access from UE 110 (e.g. using IPsec, PSK-TLS, TLS) and / or (d) other information. Security information in (c) may be available if the UE 110 registers with the I-H-PLMN network through the V-PLMN 130.

The PSK or information used to derive it can be made available to UE 110 and E-SLP 272 or E-PS 282 during SIP registration and / or SIP emergency call initiation and can be used for SUPL or X.S0024 location using the PSK -TLS. The reliable connection created during registration and the establishment of a SIP call between these entities is used to obtain a secure PSK or general information from which a secure key can be derived. For SUPL, mutual authentication of the UE 110 and the E-SLP 272 can then be supported using PSK-TLS when the UE creates an IP connection (PSK-TLS) with the E-SLP 272, following the transfer of the SUPL INIT from the E-SLP 272 to the UE 110 For X.S0024, the secure PSK can be used as the root key from which the remaining security information can be displayed as described in 3GPP2 X.S0024-0 and S.P0110-0.

Method C is based on a secure connection between the UE 110 and the IMS during SIP registration and / or the establishment of a SIP call, which involves registering the UE 110 with V-PLMN 130 and H-PLMN 160 and mutual authentication of UE 110 and V-PLMN 130. If UE 110 does not have UICC / UIM or if there is no roaming agreement between V-PLMN 130 and H-PLMN 160, mutual authentication and secure transmission between V-PLMN 130 and UE 110 cannot be obtained during SIP registration and establishment of a SIP call, and any generated PSK will provide more limited protection.

Method D exists for authentication using the initial bootstrapping architecture (GBA) described in 3GPP TS 33.220 or in the 3GPP2 TSG-S S.P0109 project. UE 110 and E-SLP 272 or E-PS 28 support GBA. This enables UE 110 and E-SLP 272 or E-PS 282 to obtain a secure shared key from H-PLMN 160. For SUPL, this key can be used to support mutual authentication of PSK-TLS between UE 110 and E-SLP 272, as described 3GPP TS 33.222 or 3GPP2 TSG-S S.P0114 project. This method is used in SUPL 1.0 to support 3GPP proxy mode. This key can also be used to support TLS with HTTP digest authentication (for example, as described in 3GPP TS 33.222) only for digest HTTP authentication between UE 110 and E-SLP 272 (for example, as described in 3GPP2 TSG-S S.P0114) or other forms of authentication. For X.S0024, this key can be used as the root key from which the remaining security information can be deduced.

Method D is based on GBA support in the H-PLMN 160 as well as the V-PLMN 130 and the roaming agreement between the V-PLMN 130 and the H-PLMN 160 to enable the transfer of key information from the serving boot function (BSF) to H -PLMN 160 to the network application function (NAF) object of the E-SLP in V-PLMN 130.

Method E exists for SUPL 1.0 or X.S0024 authentication. For SUPL, if UE 110 is located in H-PLMN 160, then E-SLP 272 may be H-SLP and the existing authentication mechanisms defined in SUPL 1.0 can be used. For X.S0024, if UE 110 is in H-PLMN 160, then E-PS 282 may be H-PS, and existing authentication mechanisms defined in X.S0024 can be used.

FIG. 12 shows a block diagram of an embodiment of UE 110, access network 120, E-CSCF 254, and location server 286. The location server 286 may be an E-SLP 272, GMLC 276, E-PS 282 and / or another entity. For simplicity, FIG. 12 shows only one processor 1210, one memory block 1212 and one transceiver 1214 for UE 110, only one processor 1220, one memory block 1222, one transceiver 1224 and one communication unit 1226 for access network 120, only one processor 1230, one memory block 1232 and one communication block 1234 for the E-CSCF 254 and only one processor 1240, one memory block 1242 and one communication block 1244 for the location server 286. In general, each object can include any number of processors, memory units, transceivers, communication units, controllers, and so on.

On a downlink, base stations and / or access points in access network 120 transmit traffic data, signaling, and control signals to the UEs in their coverage area. These various types of data are processed by a processor 1220 and a transceiver 1224 to generate a downlink signal that is transmitted through an antenna. At UE 110, downlink signals from base stations and / or access points are received via an antenna, processed by transceiver 1214 and processor 1210 to obtain various types of location information, VoIP, and other services. For example, processor 1210 may decode messages used in the message flows described above. The memory units 1212 and 1222 store program codes and data for the UE 110 and, respectively, the access network 120. On the uplink, UE 110 may transmit traffic data, signaling, and control signals to base stations and / or access points in access network 120. These various types of data are processed by a processor 1210 and a transceiver 1214 to generate an uplink signal that is transmitted through a UE antenna. In access network 120, uplink signals from UE 110 and other UEs are received and processed by transceiver 1224 and optionally processor 1220 to obtain various types of information (eg, data, signaling, reports, and so on). The access network 120 communicates with the E-CSCF 254 and other entities via a communications unit 1226.

At E-CSCF 254, processor 1230 performs processing for the E-CSCF, memory unit 1232 stores program codes and data for the E-CSCF, and communication unit 1234 allows the E-CSCF to communicate with other entities. A processor 1230 may perform processing for the E-CSCF 254 for the message flows described above.

In location server 286, processor 1240 performs position determination and / or location processing for the location server, memory unit 1242 stores program codes and data for the location server, and communication unit 1244 allows the location server to interact with other objects. A processor 1240 may perform processing for the location server for the message flows described above.

The techniques described in this document can be implemented by various means. For example, these techniques may be implemented in hardware, firmware, software, or a combination thereof. For a hardware implementation, the processing modules used to execute the techniques can be implemented in one or more specialized integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), user programmable gate arrays (FPGA), processors, controllers, microcontrollers, microprocessors, electronic devices, other electronic modules designed to perform the functions described here, or a combination thereof yah.

To implement firmware or software implementations, techniques can be implemented using modules (eg, procedures, functions, and so on) that perform the functions described here. The firmware and / or program codes may be stored in memory (e.g., memory 1212, 1222, 1232 and / or 1242 in FIG. 12) and executed by a processor (e.g., processor 1210, 1220, 1230 and / or 1240). The memory may be implemented in the processor or external to the processor.

Headings are included herein for reference and to assist in locating specific sections. These headings are not intended to limit the scope of the concepts described below in the document, and these concepts may be applicable in other sections throughout the description of the invention.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the invention. Various modifications in these embodiments will become readily apparent to those skilled in the art, and the general principles defined herein may be used in other embodiments without departing from the spirit or scope of the invention. Thus, the invention is not intended to be limited by the embodiments shown herein, but rather should satisfy the broadest scope consistent with the principles and new features disclosed herein.

Claims (61)

1. Subscriber equipment (UE) configured to communicate with a visited network to send an emergency VoIP call (Voice over IP) to interact with a location server instructed by the visited network to obtain a first position estimate for the UE , and establish a call through the visited network to establish an emergency VoIP call with a public safety response point (PSAP). 2. The subscriber equipment according to claim 1, which is additionally capable of using a session initiation protocol (SIP) for an emergency VoIP call. 3. The subscriber equipment according to claim 2, which is additionally capable of sending a SIP REGISTER message for registration in the home network for an emergency VoIP call. 4. The subscriber equipment according to claim 2, which is additionally capable of sending SIP REGISTER for registration in the visited network for an emergency VoIP call. 5. The subscriber equipment according to claim 4, wherein the SIP REGISTER contains an emergency private identifier (ID) of the user created using the domain name of the visited network and the pseudo-international identifier of the mobile subscriber (IMSI). 6. The subscriber equipment according to claim 4, which is further capable of receiving a response to SIP REGISTER with a temporary public user identifier. 7. The subscriber equipment according to claim 2, which is additionally able to send SIP INVITE as a request to establish an emergency VoIP call. 8. The subscriber equipment according to claim 7, which is further capable of sending location information for the UE to the SIP INVITE, and wherein the first position estimate for the UE is obtained based on the location information. 9. The subscriber equipment according to claim 1, which is additionally able to send the location capabilities of the UE in the request for establishing an emergency VoIP call, and the location server is selected based on the location capabilities of the UE. 10. The subscriber equipment according to claim 1, which is further capable of sending location information to the UE in a request for establishing an emergency VoIP call, and wherein the location server is selected based on the location information. 11. The subscriber equipment according to claim 1, wherein the first position estimate is an intermediate position estimate corresponding to a rough position estimate used to route the call. 12. The subscriber equipment according to claim 1, wherein the first position estimate is an initial position estimate corresponding to an accurate position estimate for the UE. 13. The subscriber equipment according to claim 1, which is further capable of receiving an updated position estimate request from the PSAP for the UE and performing position determination using the location server to obtain an updated position estimate. 14. The subscriber equipment according to item 13, which is additionally capable of performing position determination using the location server according to the location of a secure user plane (SUPL). 15. The subscriber equipment according to item 13, which is additionally capable of performing position determination using the location server according to the location of X.S0024. 16. The subscriber equipment according to item 13, which is additionally capable of performing position determination using a radio access network according to the location of the 3GPP control plane. 17. The subscriber equipment according to claim 1, which is additionally capable of accessing the radio access network (RAN) to establish the possibility of IP-connection with the visited network through the RAN and detect the IP address of the local server for emergency VoIP call. 18. The subscriber equipment according to claim 1, which is further capable of accessing a wireless local area network (WLAN) using a network access identifier (NAI) that indicates a visited network in order to establish the possibility of IP connection with the visited network via WLAN and detect IP Local server address for emergency VoIP call. 19. The subscriber equipment according to claim 1, which is additionally able to authenticate with the location server. 20. A method for establishing an emergency call through an visited network, comprising the steps of:
communicate with the visited network to send a request to establish an emergency VoIP call (voice over IP);
interacting with a location server instructed by the visited network to obtain a first position estimate for a user equipment (UE); and
perform call setup via the visited network to establish an emergency VoIP call with a public safety response point (PSAP). 21. The method according to claim 20, further comprising stages in which:
use a session initiation protocol (SIP) for emergency VoIP call;
send SIP REGISTER to register in the home network or visited network for emergency VoIP call
and send a SIP INVITE as a request to establish an emergency VoIP call. 22. The method according to claim 20, further comprising stages in which:
receive an updated position estimate request from the PSAP for the UE, and perform position determination using the location server to obtain an updated position estimate. 23. Device for establishing an emergency call through a visited network, which contains:
means for communicating with the visited network to send a request to establish an emergency VoIP call (voice over IP);
means for interacting with a location server instructed by the visited network to obtain a first position estimate for a user equipment (UE); and
means for making a call over the visited network to establish an emergency VoIP call with a public safety response point (PSAP). 24. The device according to item 23, further comprising:
means for using a session initiation protocol (SIP) for an emergency VoIP call;
means for sending a SIP REGISTER for registration in a home network or a visited network for an emergency VoIP call and
means for sending a SIP INVITE as a request to establish an emergency VoIP call. 25. The device according to item 23, further comprising:
means for receiving from the PSAP a request for an updated position estimate for the UE and
means for performing position determination using the location server to obtain an updated position estimate. 26. A location server capable of receiving a request for routing an emergency VoIP call (Voice over IP) for a user equipment (UE) to a public safety response point (PSAP), obtain a first position estimate for the UE, select a PSAP based on the first estimate locations and send a response with the routing information for the PSAP, and further able to receive location information for the UE in the VoIP emergency call routing request, determine the visited location server based on e location information and interact as a home location server with a visited location server and UE to obtain a first position estimate for the UE. 27. The server according to p. 26, which is further able to interact with the UE to obtain a first position estimate for the UE. 28. The server according to p. 26, which is additionally able to send a message to the UE to perform position determination to obtain a first position estimate. 29. The server according to claim 28, which is further capable of sending the said message to the UE using IP, UDP / IP terminated on the mobile device, or IP multimedia subsystem (IMS) signaling. 30. The server according to p, which is further able to include the address of the location server in a message sent to the UE, the address being used by the UE to perform position determination. 31. The server according to p. 28, which is additionally able to include an indication of emergency services in the message sent to the UE. 32. The server according to p. 26, which is additionally able to receive a message from the UE to initiate positioning, and this message includes location information, and to output a first position estimate for the UE based on the location information. 33. The server according to p. 26, which is additionally able to receive a message from the UE to initiate positioning, and this message includes the results of measurements related to the location, and to derive a first position estimate for the UE based on the results of measurements related to the location . 34. The server according to p. 26, which is additionally able to receive from the PSAP a request for an updated position estimate for the UE, perform position determination using the UE to obtain an updated position estimate and send the updated position estimate to the PSAP. 35. The server according to claim 26, which is capable of receiving a first position estimate for the UE from a GPRS support node (general packet radio communication system). 36. The server according to p. 26, which is additionally able to receive from the PSAP a request for an updated position estimate for the UE, send this request to the IP gateway, receive the updated position estimate from the IP gateway and send the updated position estimate to the PSAP. 37. The server according to p, which is additionally capable of authenticating the UE. 38. A method for routing an emergency call, comprising the steps of:
receive a request for routing an emergency VoIP call (voice over IP) for a subscriber equipment (UE) to a public safety response point (PSAP);
get a first position estimate for the UE;
selecting a PSAP based on the first position estimate and sending a response with routing information for the PSAP;
moreover, the method further comprises stages in which:
receiving location information for the UE in the VoIP emergency call routing request;
determining a visited location server based on location information and
interacting as a home location server with a visited location server and UE to obtain a first position estimate for the UE. 39. The method according to § 38, further comprising stages, in which
send a message to perform positioning in the UE using IP, UDP / IP terminated on the mobile device, or IP multimedia subsystem (IMS) signaling. 40. The method according to § 38, further comprising stages in which:
accept from the PSAP a request for an updated position estimate for the UE;
performing position determination using the UE to obtain an updated position estimate and
send an updated position estimate to the PSAP. 41. An emergency call routing device that comprises:
means for receiving a request to route an emergency VoIP call (voice over IP) for a subscriber equipment (UE) to a public safety response point (PSAP);
means for obtaining a first position estimate for the UE;
means for selecting a PSAP based on a first position estimate and
means for sending a response with routing information for the PSAP;
moreover, the device further comprises:
means for receiving location information for the UE in a request for routing an emergency VoIP call;
means for determining a visited location server based on location information and
means for interacting as a home location server with a visited location server and a UE to obtain a first position estimate for the UE. 42. The device according to paragraph 41, further comprising
means for sending a message for performing position determination in the UE using IP, UDP / IP terminated on the mobile device, or IP multimedia subsystem (IMS) signaling. 43. The device according to paragraph 41, further comprising:
means for receiving from the PSAP a request for an updated position estimate for the UE;
means for performing position determination using the UE to obtain an updated position estimate and
means for submitting an updated position estimate to the PSAP. 44. Subscriber equipment (UE) capable of accessing the 3GPP2 access network, sending a request to the 3GPP2 core network to establish an emergency VoIP call (voice over IP), registering in the home network, interacting with the location server to obtain the first evaluating the position for the UE and making a call through the 3GPP2 core network to establish an emergency VoIP call with a public safety response point (PSAP), the PSAP being selected based on the first position estimate. 45. The subscriber equipment according to item 44, which is additionally capable of performing position determination using the location server according to the location of the secure user plane (SUPL), X.S0024 or the location of the 3GPP2 control plane. 46. The subscriber equipment according to item 44, which is further capable of receiving from the PSAP a request for an updated position estimate for the UE, perform position determination using the location server to obtain an updated position estimate, and send the updated position estimate to the PSAP. 47. A method for establishing an emergency call, comprising the steps of:
accessing the 3GPP2 access network using user equipment (UE);
send a request to the 3GPP2 core network to establish an emergency VoIP call (voice over IP);
register in the home network;
interacting with the location server to obtain a first position estimate for the UE and
performing call setup via a 3GPP2 core network to establish an emergency VoIP call with a public safety response point (PSAP), the PSAP being selected based on the first position estimate. 48. The method according to item 47, further comprising stages, in which
interacting with the location server to obtain a first position estimate for the UE, the first position estimate being used to select a PSAP. 49. The method according to clause 47, further comprising stages in which:
accept from the PSAP a request for an updated position estimate for the UE;
performing positioning using the location server to obtain an updated position estimate and
send an updated position estimate to the PSAP. 50. An emergency call setting device, which comprises:
means for accessing the 3GPP2 access network using user equipment (UE);
means for sending a request to the 3GPP2 core network to establish an emergency VoIP call (voice over IP);
means for registering in a home network;
means for interacting with a location server to obtain a first position estimate for the UE and
means for making a call over the 3GPP2 core network to establish an emergency VoIP call with a public safety response point (PSAP), the PSAP being selected based on the first position estimate. 51. The device according to item 50, further comprising:
means for receiving from the PSAP a request for an updated position estimate for the UE;
means for performing positioning using the location server to obtain an updated position estimate and
means for submitting an updated position estimate to the PSAP. 52. Subscriber equipment (UE) capable of communicating with a first visited network to send a request to establish an emergency VoIP call (Voice over IP) and interacting with a second visited network selected by the first visited network for an emergency VoIP call. 53. The subscriber equipment according to paragraph 52, which is further capable of receiving from the first visited network the Session Initiation Protocol (SIP) server identifier in the second visited network and performing a call setup with the SIP server to establish an emergency VoIP call with the second visited network. 54. The UE according to paragraph 52, wherein the emergency VoIP call is routed from the first visited network to the second visited network. 55. The UE of claim 52, wherein the emergency VoIP call is routed to a public safety response point (PSAP) based on the local network switch number (LRN). 56. Subscriber equipment (UE) capable of communicating with the visited network to send a request to establish an emergency VoIP call (voice over IP protocol), authenticate the location server selected by the visited network for an emergency VoIP call, and communicate with the server location to obtain at least one position estimate for the UE for emergency VoIP call. 57. The UE of claim 56, which further is capable of receiving a message from the location server to initiate location processing and authenticating the location server if the message indicates location processing for an emergency call and the UE is involved in an emergency VoIP call. 58. The UE of claim 56, which further is capable of authenticating the TLS public key (transport security level) using the root key of the public key stored in the UE to verify the public key of the location server. 59. The UE of claim 56, which further is capable of generating a pre-shared key (PSK) based on security information available in the UE and the visited network, and performing authentication using the pre-shared key. 60. The UE according to clause 56, which is additionally able to perform authentication based on the architecture of the initial bootstrap (GBA). 61. The UE according to clause 56, which is additionally able to perform authentication according to the location of the secure user plane (SUPL) version 1.0 or X.S0024.

Images