HK1122444A1 - Voip emergency call handling - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide techniques which support emergency voice-over-Internet Protocol (VoIP) calls and are used for various 3GPP and 3GPP2 networks, various location architectures, and various types of user equipment (UE).SOLUTION: UE 110 communicates with a visited network 130 to send a request to establish an emergency VoIP call. The UE 110 interacts with a location server instructed by the visited network 130 to obtain a first position estimate for the UE 110. The UE 110 performs call setup via the visited network 130 to establish the emergency VoIP call with a PSAP 180, which may be selected based on the first position estimate. The UE 110 thereafter performs positioning with the location server to obtain an updated position estimate for the UE 110, e.g., if requested by the PSAP 180.

Description

VOIP emergency call handling

The application claims priority from provisional united states application No. 60/704,977 entitled "VOICE-OVER INTERNET PROTOCOL EMERGENCY CALL SUPPORT" filed on 8/2/2005, provisional united states application No. 60/713,199 entitled "VOIP EMERGENCY CALL SUPPORT" filed on 8/30/2005, provisional united states application No. 60/726,694 entitled "VOIP EMERGENCY CALL SUPPORT" filed on 10/13/2005, provisional united states application No. 60/732,226 entitled "VOIP EMERGENCY CALL SUPPORT" filed on 10/31/2005, and provisional united states application No. 60/748,821 entitled "SUPPORT FOREMERGENCY VoIP CALL USING SUPPORT" filed on 12/9/2005, all of which are assigned to the present assignee and are hereby incorporated by reference.

Technical Field

The present disclosure relates generally to wireless communications, and more specifically to techniques for supporting emergency calls.

Background

Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, and so on. These wireless networks may be multiple-access networks capable of supporting communication for multiple users by sharing the available network resources. Examples of such multiple-access networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, and orthogonal FDMA (ofdma) networks.

Wireless networks typically support communication for wireless users making service subscriptions with these networks. Service subscriptions may be associated with information for security, routing, quality of service (QoS), billing, and the like. The subscription-related information may be used to establish a call with the wireless network.

One of the most basic services that wireless networks provide for their users is the ability to send and receive voice calls. A recent enhancement to this service is the ability to send and receive voice over internet protocol (VoIP) calls. A VoIP call is a voice call in which voice data is sent in the form of packets that are routed as other packet data, rather than on a dedicated traffic channel.

A wireless user may establish an emergency voice or other media call with a wireless network, which may or may not be the home network for which the user made a service subscription. This call may use VoIP. The main challenge is to route the emergency call to the appropriate Public Safety Answering Point (PSAP) that can serve the call. This may entail obtaining an intermediate position estimate for the user and determining an appropriate PSAP based on the intermediate position estimate. The problem is compounded if the user is roaming and/or is not making a service subscription to any network.

Accordingly, there is a need in the art for techniques to support emergency calls and emergency VoIP calls.

Disclosure of Invention

Techniques for supporting emergency voice over internet protocol (VoIP) calls are described herein. The techniques may be used for various 3GPP and 3GPP2 networks, various location architectures, and User Equipment (UE) with and without service subscriptions.

In an embodiment, the UE communicates with the visited network to send a request to establish an emergency VoIP call. The UE interacts with a location server indicated by the visited network to obtain a first location estimate for the UE. The UE performs call setup via the visited network to establish an emergency VoIP call with a PSAP, which may be selected based on an initial position estimate. The UE may then perform positioning with the location server, for example, upon request by the PSAP, to obtain an updated location estimate for the UE. Various details of the emergency VoIP call are described below.

Various aspects and embodiments of the invention are also described in more detail below.

Drawings

Aspects and embodiments of the present invention will become better understood from the detailed description set forth below when considered in conjunction with the drawings in which like reference characters identify correspondingly throughout.

Fig. 1 shows a deployment supporting emergency VoIP calls.

Fig. 2 shows a 3GPP network architecture.

Fig. 3 shows a 3GPP2 network architecture.

Fig. 4 and 5 show the network architecture and message flow, respectively, for an emergency VoIP call with a SUPL location.

Fig. 6 and 7 show the network architecture and message flow, respectively, for an emergency VoIP call with 3GPP control plane location.

Fig. 8 and 9 show the network architecture and message flow, respectively, for an emergency VoIP call with an x.s0024 location.

Fig. 10 and 11 show the network architecture and message flow, respectively, for an emergency VoIP call for a UE that is not making a service subscription.

Fig. 12 shows a block diagram of several entities in fig. 1-3.

Detailed Description

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

Techniques for supporting emergency VoIP calls are described herein. The emergency VoIP call is a VoIP call or a packet switched call to emergency services. The emergency VoIP call may be so identified and may be distinguished from the normal VoIP call in several ways, as described below. The emergency VoIP call may be associated with various characteristics other than a normal VoIP call, such as obtaining a suitable position estimate for the user, routing the emergency VoIP call to a suitable PSAP, and so on. The position estimate (position estimate) is also referred to as a position estimate (position estimate), positioning, and the like.

Fig. 1 shows a deployment 100 that supports emergency VoIP calls. User Equipment (UE)110 communicates with access network 120 to obtain basic IP communication services. UE110 may be fixed or mobile and may also be referred to as a Mobile Station (MS), a terminal, a subscriber unit, a station, or some other terminology. The UE110 may be a cellular phone, a Personal Digital Assistant (PDA), a wireless device, a laptop computer, a telemetry device, a tracking device, and so on. UE110 may communicate with one or more base stations and/or one or more access points in access network 120. The UE110 may also receive signals from one or more satellites 190, which satellites 190 may be part of the Global Positioning System (GPS), the european Galileo system, the russian GLONASS system, or any Global Navigation Satellite System (GNSS). UE110 may measure signals from base stations in access network 120 and/or signals from satellite 190 and may obtain pseudorange (pseudo-range) measurements for the satellite and/or timing measurements for the base stations. The pseudorange measurements and/or timing measurements may be used to derive a position estimate for UE110 using one or a combination of positioning methods well known in the art, such as assisted GPS (a-GPS), standalone GPS, advanced forward link triangulation (a-FLT), enhanced observed time difference (E-OTD), observed time difference of arrival (OTDOA), enhanced cell ID, and so forth.

The access network 120 provides radio communication for UEs located within the coverage of the access network. Access network 120 may include base stations, network controllers, and/or other entities, as described below. Visited network 130, which is also referred to as a visited public land mobile network (V-PLMN), is the network currently serving UE 110. The home network 160, which is also referred to as a home PLMN (H-PLMN), is the network to which the UE110 makes subscriptions. Access network 120 is associated with 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 the home network 160 may or may not have roaming agreements. Networks 130 and 160 may each include entities that provide data connectivity, location services, and/or other functionality and services.

Network 170 may include the Public Switched Telephone Network (PSTN), the internet, and/or other voice and data networks. The PSTN supports communications for conventional Plain Old Telephone Service (POTS). PSAP180 is an entity responsible for answering emergency calls (e.g., for alarm, fire, and medical services) and may also be referred to as an Emergency Center (EC). Such a call may be initiated when the user dials a fixed well-known number (e.g., 911 in north america or 112 in europe). PSAP180 is typically operated or owned by a government agency (e.g., a country or city). PSAP180 may support IP connectivity for VoIP calls and thus support Session Initiation Protocol (SIP), which is a signaling protocol for initiating, modifying, and terminating interactive user sessions over IP, such as VoIP. Alternatively or additionally, PSAP180 may support communications with PSTN 170.

The techniques described herein may be used for emergency VoIP calls originating from wireline networks, such as DSL and cable, and for emergency VoIP calls originating from Wireless Wide Area Networks (WWANs), Wireless Local Area Networks (WLANs), wireless metropolitan networks (WMANs), and wireless networks with WWAN and WLAN coverage. The WWAN may be CDMA, TDMA, FDMA, OFDMA, and/or other networks. A CDMA network may implement one or more radio technologies such as wideband CDMA (W-CDMA), CDMA2000, and so on. cdma2000 covers IS-2000, IS-856, and IS-95 standards and includes Ev-DO revisions 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 phone system (D-AMPS), etc. D-AMPS covers IS-248 and IS-54. W-CDMA and GSM are described in literature from an organization named "3 rd Generation partnership project" (3 GPP). Cdma2000 is described in a document from an organization named "3 rd generation partnership project 2" (3GPP 2). The 3GPP and 3GPP2 documents are publicly available. A WLAN may implement a radio technology such as IEEE 802.11. WMAN may implement a 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. UE110 may obtain radio access via 3GPP access network 120a or WLAN access network 120 b. The 3GPP access network 120a can be a GSM EDGE Radio Access Network (GERAN), a Universal Terrestrial Radio Access Network (UTRAN), an evolved UTRAN (E-UTRAN), or some other access network. The 3GPP access network 120a includes a base station 210, a Base Station Subsystem (BSS)/Radio Network Controller (RNC)212, and other entities not shown in fig. 2. A base station is also called a node B, an enhanced node B (e-node B), a Base Transceiver Station (BTS), an Access Point (AP), or some other terminology. WLAN 120b includes access point 214 and may be any WLAN.

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

The V-PLMN core network 230a also includes a Home Subscriber Server (HSS)250 and various IP Multimedia Subsystem (IMS) entities including a proxy call session control function (P-CSCF)252, an emergency CSCF (E-CSCF)254, an interrogating CSCF (I-CSCF)256, and a Media Gateway Control Function (MGCF) 258. P-CSCF252, E-CSCF254, I-CSCF 256, and MGCF258 support IMS services, such as VoIP calls, and are part of a V-PLMN IMS network. P-CSCF252 accepts requests from UEs and processes them internally or forwards them to other entities, possibly after translation. The E-CSCF254 performs a session control service for the UE and maintains a session state for supporting the IMS emergency service. E-CSCF254 further supports emergency VoIP calls. MGCF258 directs signaling conversion between SIP/IP and PSTN (e.g., SS7ISUP), and is used whenever a VoIP call from one user arrives at a PSTN user. The HSS 250 stores subscription related information for UEs that have the V-PLMN130 a as the home network.

V-PLMN location entity 270a may include an emergency services SUPL location platform (E-SLP)272 and an access SLP (V-SLP)274, which support OMA Secure User Plane Location (SUPL). The V-SLP274 may be within or associated with a different network than the V-PLMN130 a and/or may be geographically closer to the UE 110. Alternatively or additionally, the V-PLMN location entity 270a may include a Gateway Mobile Location Center (GMLC)276, which is part of the 3GPP control plane location. The E-SLP272, V-SLP274 and GMLC276 provide location services for UE communication with the V-PLMN130 a.

The H-PLMN160 a is one embodiment of the home network 160 in fig. 1 and includes an H-PLMN core network 260. The H-PLMN core network 260 includes an HSS266 and further includes IMS entities supporting IMS for the home network 160, such as an I-CSCF262 and a serving CSCF (S-CSCF) 264. The I-CSCF262 and S-CSCF264 are part of the H-PLMN IMS network.

Fig. 3 shows a 3GPP2 network architecture. UE110 may obtain radio access via 3GPP2 access network 120c or WLAN access network 120 d. The 3GPP2 access network 120c may be a CDMA20001X network, a CDMA20001xEV-DO network, or some other access network. The 3GPP2 access network 120c includes a base station 220, a radio resource control/packet control function (RRC/PCF)222, and other entities not shown in fig. 3. RRC may also be referred to as a Radio Network Controller (RNC) or a base station. The 3GPP2 access network 120c may also be referred to as a Radio Access Network (RAN). WLAN 120d includes access point 224 and may be any WLAN associated with a 3GPP2 network.

The V-PLMN130 b is another embodiment of the visited network 130 in fig. 1 and includes a V-PLMN core network 230b and a 3GPP2 location entity 270 b. V-PLMN core network 230b includes a Packet Data Serving Node (PDSN)242, a Packet Data Interworking Function (PDIF)244, and an authentication, authorization, and accounting (AAA) server 246. PDSN242 and PDIF 244 provide packet-switched services for UEs communicating with 3GPP2 access network 120c and WLAN 120d, respectively. The V-PLMN core network 230a also includes IMS or multimedia domain (MMD) entities such as P-CSCF252, E-CSCF254, I-CSCF 256, and MGCF 258. E-CSCF 258 may also have other names such as ES-AM (emergency services application manager).

The 3GPP2 location entity 270b may include E-SLP272 and V-SLP274 for SUPL. Alternatively or additionally, the 3GPP2 location entity 270b may include an emergency services location server (E-PS)282 and a visited location server (V-PS)/Position Determining Entity (PDE)284, which are part of the x.s0024 location for cdma2000 networks. The E-PS282 may also be referred to as a proxy location server (S-PS). The E-SLP272, V-SLP274, E-PS282, and V-PS/PDE284 provide location services for the UE to communicate with the V-PLMN130 b.

For simplicity, fig. 2 and 3 show only some of the entities in 3GPP and 3GPP2 that are referenced in the following description. The 3GPP and 3GPP2 networks may include other entities defined by 3GPP and 3GPP2, respectively.

In the following description, a 3GPP network refers to the networks and network subsystems (e.g., access network subsystems) defined by 3GPP, as well as other networks and network subsystems (e.g., WLANs) operating in conjunction with the 3GPP network. The 3GPP networks and network subsystems can include GERAN, UTRAN, E-UTRAN, GPRS core network, IMS network, 3GPP PI-WLAN, and the like. A 3GPP2 network refers to the network and network subsystems defined by 3GPP2, as well as other networks and network subsystems that operate in conjunction with a 3GPP2 network. The 3GPP2 network may include CDMA20001X, CDMA20001xEV-DO, CDMA2000 core network, 3GPP2 IMS or MMD network subsystem, 3GPP2 associated WLAN, and so on. For simplicity, "3 GPP WLAN" refers to a WLAN associated with a 3GPP network, and "3 GPP2 WLAN" refers to a WLAN associated with a 3GPP2 network.

In the following description, GPRS access refers to access to GPRS via GERAN, UTRAN or some other 3GPP access network. 3GPP WLAN access refers to accessing a 3GPP core network via a WLAN. CDMA2000 access refers to access to a CDMA2000 core network via CDMA20001X, CDMA20001xEV-DO, or some other 3GPP2 access network. 3GPP2WLAN access refers to accessing a 3GPP2WLAN core network via a WLAN.

For 3GPP, UE110 may or may not be equipped with a Universal Integrated Circuit Card (UICC). For 3GPP2, UE110 may or may not be equipped with a User Identity Module (UIM). The UICC or UIM is typically specific to one subscriber and may store personal information, subscription information, and/or other information. UICC-less UE is UE without UICC, and UIM-less UE is UE without UIM. UICC/UIM-less UEs have no subscription, no home network, and no authentication credentials (e.g., no keys) to verify any purported identification information, which makes location services more vulnerable.

The techniques described herein may be used for various location architectures such as control plane and user plane architectures. The control plane (which is also referred to as the signaling plane) is a mechanism for carrying signaling for higher layer applications and is typically implemented with network specific protocols, interfaces, and signaling messages. The user plane is a mechanism for carrying signaling for higher layer applications but employs a user plane bearer, which is typically implemented with protocols such as User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Internet Protocol (IP), all known in the art. Messages supporting location services and positioning are carried as part of the signalling in the control plane architecture and as part of the data (from the network's point of view) in the user plane architecture. However, the content of the message may be the same or similar in both architectures.

The techniques may be used for various location architectures/solutions, such as those listed in table 1. SUPL and naive SUPL are described in literature from the Open Mobile Alliance (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	Can be applied to.
			Initial SUPL	User plane	3GPP networks
SUPL	User plane	3GPP and 3GPP2 networks
			3GPP control plane	Control plane	3GPP networks
3GPP2 control plane	Control plane	3GPP2 network
			X.S0024	User plane	3GPP2 network

The UE may support zero, one, or more location solutions for emergency VoIP calls (e.g., SUPL or 3GPP control plane, or SUPL and x.s0024). The UE may inform the network of its location capabilities when making a call, e.g., in SIP INVITE and/or SIP REGISTER messages. This information may be stored in a local server (e.g., a location server) for retrieval by the network.

The techniques described herein may support the following features.

(a) Emergency VoIP calls are supported for mobile, fixed and mobile users.

(b) Applicable to VoIP calls using GPRS access, 3GPP WLAN access, cdma2000 access, and 3GPP2WLAN access.

(c) End-to-end IP connectivity is supported with the PSAP where SIP/IP is available.

(d) Support connectivity with PSAPs of available PSTN that may be local to the UE making the call but geographically remote from the SIP call server, such as when the VoIP service provider is remote from the UE.

(e) Support for call routing to the appropriate PSAP using intermediate position estimates.

(f) The PSAP is provided with the exact location of the UE.

(g) Initial and updated locations using various location architectures are supported.

(h) Support emergency VoIP calls from UICC/UIM-less UEs and UEs where the H-PLMN and V-PLMN do not have roaming agreements.

(i) Callback from PSAP to UE without roaming agreement in UICC/UIM and/or V-PLMN is supported.

(j) Compatible with IETF Ecrit solutions and NENA solutions (e.g., intermediate VoIP architecture for enhanced 9-1-1 service (i2), also known as NENAI2 solutions).

(k) The impact and requirements on the H-PLMN are minimal.

PSAP call back refers to a call from the PSAP back to the UE, for example because the emergency call is dropped or placed too early. The intermediate position estimate generally refers to an approximate position fix for the route, and the initial position estimate generally refers to a first accurate position estimate. In some cases, an initial position estimate may be obtained after the intermediate position estimate. In other cases, the intermediate and initial position estimates may be the same. In still other cases, the intermediate position estimate and/or the initial position estimate may not be used.

For SUPL, a home SLP (H-SLP) in H-PLMN160 may be bypassed and one or more V-SLPs and/or E-SLPs in V-PLMN130 or associated with V-PLMN130 may be used for positioning. For x.s0024, the home PS (H-PS) in the H-PLMN160 may be bypassed, and one or more V-PS and/or E-PS in the V-PLMN130 or associated with the V-PLMN130 may be used for positioning. This implies that some variations to SUPL and x.s0024, such as H-SLP or H-PS configured in UE110 may be overridden for positioning during emergency calls. It may be desirable to use V-SLP, E-PS or V-PS in the V-PLMN130 for the following reasons:

(a) special emergency call support for a particular region or country should utilize support from only the networks in those regions and 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 a UE with UICC/UIM, the H-PLMN may not have a roaming agreement with the V-PLMN and it may be difficult to use H-SLP or H-PS.

(d) The H-SLP or H-PS may not support location requests from a remote PSAP (e.g., another country) due to signaling differences and lack of registration.

(e) The H-SLP or H-PS may not be able to obtain a good position estimate without assistance from the V-SLP or V-PS in the V-PLMN (e.g., if the H-SLP or H-PS is far away from the UE).

(f) The H-SLP or the H-PS may not support an interface (e.g., Li or LCS-i interface) used by the E-SLP or the E-PS to support the emergency call service.

The E-SLP272 or the E-PS282 may perform positioning for the UE110 in SUPL and x.s0024, respectively. Alternatively, for example, if the E-SLP272 or E-PS282 are unable to perform this function, then a V-SLP, V-PS, or PDE may be selected to perform positioning for the UE 110. For example, if a SIP call server (e.g., E-CSCF 254) is away from UE110 and selects an E-SLP or E-PS that is also away (which may occur when an operator uses a small number of call servers to serve a large area or an entire country), then a V-SLP, V-PS or PDE may be useful. The E-SLP272 or E-PS282 may select a V-SLP, a V-PS, or a PDE using any of the following mechanisms:

(a) UE110 discovers the IP address or name of the V-SLP or V-PS when attaching to the access network or establishing IP connectivity, e.g., the access network provides the V-SLP or V-PS address to UE 110. UE110 may also discover the V-SLP or V-PS address through DNS query after establishing IP connectivity. This may apply when the DNS server used by UE110 is more local to UE110 than E-CSCF 254. UE110 may include a V-SLP or V-PS address in an initial sip REGISTER sent to IMS or in any subsequent re-REGISTER after handover to a new access network. The IMS (e.g., E-CSCF 254) may pass the V-SLP or V-PS address to the E-SLP272 or E-PS 282.

When the server is more local to UE110 than E-CSCF 254. UE110 may include a V-SLP or V-PS address in an initial sip REGISTER sent to IMS or in any subsequent re-REGISTER after handover to a new access network. The IMS (e.g., E-CSCF 254) may pass the V-SLP or V-PS address to the E-SLP272 or E-PS 282.

(b) The E-SLP272 or E-PS282 determines the V-SLP or V-PS address based on the location information provided by the UE110 in the initial SIP INVITE.

(c) The E-SLP272 or the E-PS282 determines a V-SLP or a V-PS address based on location information received from the UE110 in the SUPL START.

In general, the location information provided by UE110 may be any information that may be used to determine the location of UE 110. The location information may include geographic coordinates, GSM, UMTS, or cdma2000 cell Identification (ID), cdma2000 serving cell information, WLAN access name identification, WLAN MAC address, etc. The location information may also include measurements that may be used to determine the location of UE 110.

For SUPL and x.s0024, the E-SLP272 or E-PS282 may send a SUPL INIT to the UE110 to start a SUPL session. SUPL INIT may be sent using WAP push or SMS, which may result in longer delay. In an embodiment, to reduce latency, the SUPL INIT may be sent to UE110 via the IMS (e.g., P-CSCF252 and E-CSCF 254) using an IMS instant message, some other IMS message, a SIP 1xx response (e.g., 183 session progress), or some other message. Using an existing (possibly secure) association between the IMS and the UE110 enables faster delivery and further avoids the additional delay of establishing a new association and/or delivering the message through an additional entity (e.g., an SMS service center). This embodiment may also be used when the UE110 is not registered in the H-PLMN (e.g., does not have a UICC or UIM). In another embodiment, to reduce latency, the SUPL INIT may be sent to UE110 using mobile terminal IP or UDP/IP. In this case, the IP gateway serving UE110 (e.g., GGSN 232b, PDG236, PDSN242, or PDIF 244) may be pre-managed with the IP address of the E-SLP272 so that IP packets are not filtered out from the E-SLP272 to the UE 110. UE110 may be configured to support TCP ports and/or UDP ports for SUPL (and register with IANA) for receiving SUPL INIT.

Emergency VoIP calls may be supported with the initial release of SUPL1.0 and x.s0024 (3GPP2 x.s0024-0) as follows.

(a) If the UE110 is in the H-PLMN160, then the E-SLP272 is the UE's H-SLP or the E-PS282 is the UE's H-PS and invokes SUPL1.0 or X.S0024-0 network initiated location request. The SUPL INIT may be sent to UE110 using SMS or WAP push.

(b) If the UE110 is not in the H-PLMN160 but is registered in the V-PLMN130, the E-SLP272 may invoke the SUPL1.0 location request by acting as the requesting SLP (R-SLP) and sending the location request to the H-SLP of the UE110 according to procedures in SUPL1.0 and OMA RLP. Similarly, the E-PS282 may invoke an x.s0024 location request from the H-PS for the UE110 using, for example, the OMARLP protocol.

(c) If the UE110 is not in the H-PLMN160 and is not registered in the V-PLMN130 (e.g., there is no roaming agreement between the V-PLMN130 and the H-PLMN 160) or if the UE110 does not have a UICC or UIM, SUPL1.0 or x.s0024-0 location is not supported. However, the E-SLP272 or the E-PS282 may still be able to obtain a location estimate for the UE110 using the location information provided by the UE110 in the initial SIP INVITE for the emergency call.

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. The network architecture 400 is applicable to both 3GPP and 3GPP2 networks. For simplicity, fig. 4 shows only the entities and interfaces related to supporting an emergency VoIP call using SUPL.

In SUPL, the UE110 is referred to as a SUPL-enabled terminal (SET). The access network 120 may be a 3GPP access network, a 3GPP2 access network, a WLAN, or some other network. The access network 120 and/or V-PLMN130 comprise entities that support packet-switched calls, for example, as shown in fig. 2 and 3. For 3GPP2, simple IP and or mobile IP may be used for emergency VoIP calls. In the following description, IMS may refer to P-CSCF252, E-CSCF254, and/or MGCF 258.

The E-SLP272 may include a SUPL location center (E-SLC)412 that performs various functions for location services and a SUPL location center (E-SPC)414 that supports positioning for UEs. V-SLP274 may similarly include V-SLC 422 and V-SPC 424. The E-SLP272 may replace the H-SLP in the H-PLMN160 in case of positioning for emergency calls. The entities in SUPL are described in the document OMA-AD-SUPL-V2_0-20060704-D entitled "Secure User Plane Location Architecture" (draft version 4.0, 4.7/2006) and in the document OMA-TS-ULP-V2_0-20060721-D entitled "User Plane Location Protocol" (draft version 2.0, 21/7/2006), which are publicly available from OMA.

SUPL supports two communication modes between SET and SLP for positioning with SPC. In the proxy mode, the SPC does not have direct communication with the SET, and the SLP acts as a proxy between the SET and the SPC. In the non-proxy mode, the SPC has direct communication with the SET.

PSTN/internet 170 may include entities that support packet routing, such as routers, and a selective router (S/R)292 that routes emergency calls to PSAPs. S/R292 may belong to PSAP180 or may be shared by and connected to a group of individual PSAPs. If PSAP180 supports SIP, UE110 may communicate with PSAP180 via P-CSCF252 and E-CSCF254 for a VoIP call. UE110 may also communicate with PSAP180 via P-CSCF252, E-CSCF254, MGCF258, and S/R292 if PSAP180 does not support SIP. In this case, a Media Gateway (MGW) controlled by MGCF258 performs conversion of VoIP to PCM line mode for the emergency call.

Fig. 4 also shows the interfaces between the various entities. The call related interface between UE110, P-CSCF252, E-CSCF254, MGCF258 may be SIP. The call related interface between MGCF258, S/R292 and PSAP180 may be MF/ISUP. The location-dependent interface between PSAP180 and E-SLP272 may be the E2 interface defined in J-STD-036 revision B (if PSAP180 has a PSTN available) or an extension of the E2 interface (if PSAP180 has a SIP available). The location-related interface between PSAP180 and E-SLP272 may instead be the MLP interface defined in the OMA or LIF mobile location protocol or some other interface, such as an HTTP interface. The location-related interface between the UE110 and the V-SLP274 and the E-SLP272 may be SUPL ULP.

The interface between the E-CSCF254 and the E-SLP272 is used to convey information about the UE110 to the E-SLP272 and to initiate SUPL positioning. This interface may be an LCS IMS (e.g., Li) interface and may utilize the IMS Location Protocol (ILP) or some other protocol. The Li/ILP interface may be similar to the OMA Roaming Location Protocol (RLP) between SLPs. The Li/ILP interface may be used by any IMS entity (e.g., S-CSCF or application server) and E-SLP272 to support other features associated with IMS and IP based services, such as:

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

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

(c) supplementary services based on the user's location, e.g. call forwarding per location, call barring per location.

The interface between the E-SLP272 and the E-CSCF254 may also be the v2 interface (which is considered for E911VoIP support in the united states) defined in the "draft NENA standard for VoIP/packet migration I2 solution" or "intermediate VoIP architecture for enhanced 9-1-1 services (I2) (hereinafter" NENA I2 solution "), or some other interface.

The network architecture 400 may include other entities that support VoIP and/or location, such as elements described in the 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 emergency VoIP call setup using SUPL. For clarity, the less relevant entities (e.g., access network 120, P-CSCF252, S/R292) are omitted from FIG. 5 but included in the following description. Message flow 500 may be used for 3GPP and 3GPP2 networks. The message flow 500 assumes that the UE110 has a UICC or UIM and that a roaming agreement exists between the H-PLMN160 and the V-PLMN 130.

In step 1, the UE110 discovers AN Access Network (AN), such as a 3GPP access network, a 3GPP2 access network, AN 802.11WLAN, etc. The UE110 performs any low-level connections (e.g., 802.11 association) and attaches to the access network (e.g., via GPRS attach or WLAN AAA procedures (for 3 GPP)). UE110 establishes IP connectivity and may discover a local SIP server address. In the following description, P-CSCF252 is a local SIP server discovered by UE 110. Step 1 may be performed in different ways for different networks and step 1 is described in further detail below.

In step 2, UE110 sends SIP REGISTER to P-CSCF252, and P-CSCF252 is the local SIP server found in step 1. SIP REGISTER may include an emergency service indication, an emergency public user ID (e.g., as described in 3GPP TR 23.867 and in 3GPP TS 23.167), a private user ID, an H-PLMN domain name, and the UE IP address obtained in step 1. SIP REGISTER may also include location information for UE110, positioning capabilities for UE110, and/or other information. The UE positioning capabilities may include location solutions supported by the UE110 (e.g., SUPL, 3GPP control plane, x.s0024, etc.), positioning methods supported by the UE110, and/or other information. Due to the presence of the emergency service indication or emergency public user ID, P-CSCF252 forwards SIP REGISTER to E-CSCF254 in the same network, and not to I-CSCF262 in H-PLMN160 as in the non-emergency case.

In step 3, the E-CSCF254 in the V-PLMN130 forwards the sip register to the S-CSCF264 in the H-PLMN160 in case of normal IMS registration. The reason for registering in the H-PLMN160 is (1) to verify the user identity, (2) to obtain a verified call back number from the S-CSCF264, (3) to alert the H-PLMN160 of the emergency call so that special processing (e.g., priority, restrictions on supplementary services) can be applied if the PSAP180 subsequently calls back the UE110 via the H-PLMN 160. For IMS registration, the S-CSCF264 in the H-PLMN160 treats the E-CSCF254 in the V-PLMN130 as if it were a P-CSCF. The public user TEL URI (e.g., derived from the MSISDN in 3GPP or the MIN in 3GPP2) may be implicitly registered with the emergency public user ID of the UE110 and may be used for PSAP callback from the PSTN. For example, if the UE110 has registered a normal public user ID or if the H-PLMN160 does not support an emergency public user ID, the H-PLMN160 may not support additional registration of the emergency public user ID. The E-CSCF254 may maintain a list of H-PLMNs for which step 3 may be skipped. If step 3 is skipped, a callback from PSAP180 is still possible by using the normal public user ID of UE110 that should be registered by UE110 alone. The E-CSCF254 may also assign a temporary public user ID to the UE110, as described below, to enable a call back from the PSAP180 directly via the V-PLMN130 and not via the H-PLMN 160. This temporary public user ID is particularly useful for UEs roaming abroad because both the latency and reliability of the callback can be improved. If registration in the H-PLMN160 is not performed, UE110 is not authenticated and a secure IP connection between UE110 and E-CSCF254 in V-PLMN130 may not be established, which may reduce security of subsequent positioning of UE110 by E-SLP 272.

In step 4, the E-CSCF254 (e.g., after receiving the SIP 200OK from the H-PLMN 160) returns a200 OK to the UE 110. After setting up the emergency call, if the UE110 is handed off to a different SGSN (for GPRS access), a different WLAN (for WLAN access), or a different PCF or PDSN (for cdma2000 access) within the same V-PLMN, the UE110 may re-register by repeating steps 2 through 4 in order to update the location and V-SLP information. If re-registered with its emergency public user ID, the E-CSCF254 may pass any new location information to the E-SLP 272. Re-registration enables selection of a different V-SLP if UE110 has moved out of the geographical area supported by the previous V-SLP.

For 3GPP2WLAN access, a handoff procedure may be performed if UE110 moves from one WLAN to another WLAN or from a WLAN to a cdma2000 network. The handoff procedure may establish a new tunnel from a new WLAN (for handoff from one WLAN to another) or from a new PSDN (for handoff from a WLAN to a cdma2000 network) to the previous PIDF in order to continue using the IP address associated with the previous PDIF and avoid interrupting the emergency VoIP call. For handoff from a cdma2000 network to a WLAN, the PDIF associated with the new WLAN may emulate the target PDSN to support a fast handoff to the previous serving PDSN. After handoff, UE110 may re-register to provide the associated new location information to E-CSCF254 for V-SLP selection.

In an alternative embodiment of steps 2, 3 and 4, after the UE110 sends SIP REGISTER to the P-CSCF252 in step 2, the P-CSCF252 may forward SIP REGISTER directly to the S-CSCF264 in the H-PLMN160 or to the I-CSCF262 in the H-PLMN160 and bypass the E-CSCF254 in the V-PLMN 130. In this case, the SIP 200OK from H-PLMN160 would return to P-CSCF252 and not to E-CSCF254, and P-CSCF252 would return a200 OK to UE110 in step 4. This alternative embodiment may reduce or avoid the special impact of supporting VoIP emergency calls for P-CSCF252, as the actions of P-CSCF252 then act as they would at normal registration.

In step 5, UE110 sends SIP INVITE to P-CSCF 252. SIP INVITE may contain a global SIP URL or TEL URI indicating an emergency call (e.g., sos local domain or "911" proposed by IETF Ecrit) and the type of emergency service requested. SIP INVITE may also include information regarding the UE location available to the UE110 (e.g., GPRS or cdma2000 cell ID, WLAN AP MAC address, etc.), location capabilities of the UE110 (if not provided during registration), contact information for callback, and/or other information. The callback information may include a tel uri (e.g., from 3GPP MSISDN or 3GPP2MDN) and possibly a SIP URL (e.g., the emergency public user ID used in step 2). The "supported" header field of SIP REGISTER or SIP INVITE may also be used to convey UE positioning capabilities. The positioning capabilities may also be included as part of the location information provided by the UE (e.g., in the ietf geopriv pidf-lo object) or in some other way in SIP INVITE. P-CSCF252 may forward the SIP invite to another SIP server, which may forward SIP INVITE to a routing agent (e.g., an application server) dedicated to the emergency call. In fig. 5, E-CSCF254 is a SIP server that handles emergency calls.

In step 6, the E-CSCF254 may explicitly or implicitly determine that the UE110 supports SUPL and send a routing request (or emergency location request) to the E-SLP 272. The routing request may contain the UE public identity (e.g., emergency public user ID, TEL URI, etc. from step 5), any location information received by the E-CSCF254 and the UE IP address (if mobile terminal IP (or UDP/IP) is to be used in step 8). The E-SLP272 may be in the same network as the E-CSCF254 or in some other network. E-SLP272 may be selected because it covers a geographic area that includes the approximate location of UE 110. The E-CSCF254 may select the E-SLP272 (a generic location server capable of acting as an E-SLP), or some other type of server, such as the GMLC 276. The selected location server may elect to use SUPL based on the UE positioning capabilities (or simply by hypothesis) conveyed by the E-CSCF 254. E-CSCF254 may request location information from E-SLP272 and/or select a PSAP corresponding to the location information and emergency service types available.

If the location information provided in step 6 enables the E-SLP272 to derive a location estimate for the UE110 that is accurate enough to satisfy the request in step 6 (e.g., uniquely determine the destination PSAP), then the E-SLP272 proceeds to step 12. Otherwise, steps 7 to 11 are performed to obtain an appropriate position estimate for the UE 110.

In step 7, the E-SLP272 determines from the received position information whether to use a separate V-SLP to assist positioning. If so, a V-SLP (e.g., V-SLP274) may be selected based on the location information received from E-CSCF 254. The E-SLP272 acting as an H-SLP performs subsequent SUPL positioning using a procedure that may be similar to the procedure for (a) SUPL1.0 roaming support (if V-SLP is selected) or (b) SUPL1.0 non-roaming support (if V-SLP is not selected). In the roaming case, the E-SLP272 may exchange some preliminary RLP signaling with the V-SLC 422, which is not shown in fig. 5. The E-SLP272 then generates SUPL INIT using proxy or non-proxy mode in SUPL to instigate a network initiated positioning procedure to the UE 110. The E-SLP272 may send the SUPL INIT directly to the UE110 using mobile terminal IP or UDP/IP, in which case step 8 may be skipped. The E-SLP272 may also send SUPL INIT to the E-CSCF254 inside an instant message (e.g., an IMS instant message or some other IMS or SIP message). In either case, the SUPL INIT may include the IP address of the SPC used for positioning, which may be E-SPC 414 or V-SPC 424 (if non-proxy mode is used), quality of position (QoP) accuracy/delay requirements for fast intermediate location estimation, proxy/non-proxy mode indication, authentication data, and/or other information. For example, the SUPL INIT may also include the IP address of the E-SLP272 if the UE110 is not in its home network, if the E-SLP272 is not an H-SLP for the UE110, or if the E-SLP272 is the H-SLP but chooses not to behave as an H-SLP (e.g., so as not to support more than one procedure for an emergency call). The SUPL INIT may also include an emergency call indication, for example, in the SUPL INIT notification parameter.

In step 8, E-CSCF254 forwards the SUPL INIT to UE110 via P-CSCF252 using an IMS instant message, some other IMS message, a SIP 1xx response (e.g., 183 Session progress), or some other IP-based message using the secure IP association between E-CSCF254, P-CSCF252, and UE110 established in steps 2 through 4.

In step 9, the UE110 establishes a secure IP (e.g., secure TCP/IP) connection to the E-SLP272, which E-SLP272 may be an H-SLP for the UE110 or may have included its address in the SUPL INIT sent in step 7. For non-proxy mode, UE110 obtains authentication data from E-SLP272 (not shown) and establishes a secure IP connection to E-SPC 414 or V-SPC 424 through mutual authentication. The E-SLC 412 also communicates information to the E-SPC 414 or V-SPC 424 in non-proxy mode (not shown in FIG. 5). UE110 may obtain location-related measurements (e.g., signal levels and/or timing of neighboring cells) or location estimates (e.g., using standalone GPS) consistent with the received QoP. UE110 then returns the SUPL POS INIT to either E-SLP272 (in proxy mode) or E-SPC 414 or V-SPC 424 (in non-proxy mode not shown in FIG. 5). The SUPL POS INIT may include a hash code used in proxy mode for authentication, UE positioning capabilities, location estimation, or a request for a-GPS assistance data (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 getting a fast intermediate location estimate and avoiding further SUPL POS signaling. For 3GPP, the measurements may include signal levels of neighboring base stations or access points, GPRS timing advance, wcdma rx-Tx time difference, and the like. For 3GPP2, the measurements may include location-related measurements related to cdma2000 or 3GPP2 WLANs.

In step 10, the E-SLP272, E-SPC 414, or V-SPC 424 may exchange additional SUPL POS messages with the UE110 if appropriate location estimates (or location measurements) are not received in step 9. Each SUPL POS message may include an embedded RRLP, RRC, or IS-801 location message. This exchange of messages continues until sufficient positioning measurements or position estimates have been provided to E-SLP272, E-SPC 414, or V-SPC 424. In step 11, the SUPL END is returned to the UE110 to END the SUPL transaction.

In step 12, the E-SLP272, E-SPC 414, or V-SPC 424 calculates an intermediate position estimate for the UE110 from the position information received in step 9 or step 10. For non-proxy mode, the E-SPC 414 or V-SPC 424 communicates the location estimate to the E-SLC 412. Based on the location estimate, and if the E-CSCF254 issues the request in step 6, the E-SLP272 selects the PSAP. The following description assumes PSAP180 to be the selected PSAP. If PSAP180 is accessible/enabled to the PSTN, E-SLP272 obtains (a) an emergency services routing number (ESRD) non-dialable telephone number that is available for routing to PSAP180 and (b) an Emergency Services Routing Key (ESRK) non-dialable telephone number that identifies PSAP180, E-SLP272 and (temporarily) UE 110. Each PSAP may be associated with one ESRD and an ESRK cluster that identifies the E-SLP272 and the PSAP. For each emergency call made by the UE to this PSAP, one ESRK from the cluster may be assigned to the UE for the duration of the emergency call. Some of these functions (e.g., ESRD/ESRK management) may not be considered part of SUPL and may be supported in a separate physical or logical entity that may be interrogated by E-SLP272 (e.g., as described in the NENA I2 solution). ESRD and ESRK correspond to the same name telephone number (e.g., J-STD-036) used for emergency call support in line mode. ESRD and ESRK also correspond to ESRN and ESQK, respectively, as described in the NENA I2 solution.

In step 13, E-SLP272 returns a routing response (or emergency location response) to E-CSCF254 that may include (a) a PSAP identification (which may be a SIP URL or an IP address) if PSAP180 has an available IP or (b) ESRD and ESRK if PSAP180 has an available PSTN. The routing response may also include an intermediate location estimate for UE110 if requested by E-CSCF 254. The E-SLP272 may store a call record for the UE110 that contains all the information collected for the UE.

If PSAP180 has IP available, steps 14a and 15a are performed. In step 14a, E-CSCF254 routes SIP INVITE (received in step 5) to PSAP 180. The sip invite may include an intermediate location estimate and possibly an identity or address of UE110 and an IP address or name of E-SLP 272. In step 15a, additional SIP signaling may be exchanged to establish the emergency call.

If the PSTN is available to PSAP180, steps 14b, 14c, and 15b are performed. In step 14b E-CSCF254 forwards SIP INVITE to MGCF258 via a Breakout Gateway Control Function (BGCF). SIP INVITE may include a callback number (e.g., an MSISDN or MDN) of the UE110 and/or may include an ESRD and an ESRK (but may not include an intermediate location estimate). In step 14c, MGCF258 routes the emergency call to PSAP180 via the PSTN (possibly via an optional router) using SS7ISUP and/or MF signaling. The ESRD or ESRK may be used as a routing number and the ESRK and/or callback number is passed to PSAP180 (e.g., via MF CAMA signaling) as an identification of UE110 and as a key to obtain more information. In step 15b, additional SIP signaling may be exchanged and interworking of SS7ISUP and/or MF may occur at MGCF258 to establish the emergency call.

Call paths are established separately for IP-capable PSAPs and PSTN-capable PSAPs. For PSAPs that have PSTN available, interworking between VoIP (e.g., RTP/IP) and wireline mode (e.g., PCM) occurs at a Media Gateway (MGW) controlled by MGCF 258. For PSAPs with available IP, the call path will be end-to-end IP and will likely travel between UE110 and PSAP180 in part via the public internet or private IP network, but will skip any MGWs.

In step 16, after establishing the call, PSAP180 may send a location request to E-SLP272, which E-SLP272 may be identified by the IP address or name obtained in step 14a or the ESRK obtained in step 14 c. PSAP180 identifies UE110 using the UE public user address (if PSAP180 has IP available) or a callback number or other address (e.g., MSISDN or MDN) or ESRK (if PSAP180 has PSTN available). The location request indicates a request for an accurate location estimate. For an emergency VoIP call in the united states, the location request may be the same as the emergency service location request in J-STD-036 (if PSAP180 has PSTN available) and may be an extension of this message (if PSAP180 has IP available). For emergency VoIP calls in some other areas of the world, the location request may be the same as the emergency location immediate request defined for oma mlp.

In step 17, the E-SLP272 may select a V-SLP if the positioning capabilities of the E-SLP272 do not extend to the geographical area where the last known location of the UE110 is reported or if using a V-SLP may provide a more accurate and reliable location. The E-SLP272 may derive the V-SLP address from the nearest location of the UE110 and/or from the nearest V-SLP address provided by the E-CSCF 254. To ensure a correct V-SLP, if the E-CSCF254 does not automatically deliver this information after any re-registration of the UE110 in step 4, the E-SLP272 may ask for the location of the UE110 and/or the V-SLP address (not shown in fig. 5) from the E-CSCF 254. The E-SLP272 may then start a new SUPL transaction with the UE110 by sending SUPL INIT directly to the UE using mobile terminal IP or UDP/IP (in which case step 18 may be skipped) or by sending an instant message containing SUPL INIT to the E-CSCF 254. SUPL INIT may include the parameters described above for step 7.

In step 18, E-CSCF254 delivers the SUPL INIT to UE110 within an IMS instant message, some other IMS message, a SIP message (e.g., re-INVITE), or some other IP-based message that uses a secure IP association between E-CSCF254, P-CSCF252, and UE 110.

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

In step 20, the E-SLP272 sends the accurate position estimate for the UE110 to the PSAP180 in a position response. For emergency calls in the united states, if PSAP180 has PSTN available, the location response may be the same as the emergency services location response message in J-STD-036 for the E2 interface (and thus may include additional information such as the MSISDN of UE 110). For emergency calls in some other areas of the world, the location response may be the same as the emergency location immediate answer defined for oma mlp.

UE110 may then communicate with PSAP180 for the emergency VoIP call. When a call is later placed, the E-CSCF254 may send an indication to the E-SLP272, which then the E-SLP272 may issue any record of the call. The E-CSCF254 or the UE110 may also deregister the emergency public user ID registered in steps 2 to 4. Or E-CSCF254, E-SLP

272 and the UE110 may allow registration and call recording for some period of time to support possible subsequent callbacks and/or additional location requests from 110.

1.2.Access

For step 1, UE110 may connect to the access network via GPRS access, cdma2000 access, or WLAN access. Step 1 may be performed in different ways for different types of access.

For GPRS access, UE110 may perform GPRS attach to a 3GPP access network and may perform GPRS Packet Data Protocol (PDP) context activation to establish IP connectivity in SGSN232 a and GGSN 232b, as described in 3GPP TR 23.867 and TS 23.060. The emergency indication may be used for GPRS attach and/or a global Access Point Name (APN) for emergency services may be used for PDP context activation, which may ensure that a GGSN and P-CSCF are provided in the V-PLMN 130. P-CSCF252 may be a P-CSCF in the serving GPRS PLMN as provided during PDP context activation.

For 3GPP WLAN access, UE110 may perform WLAN AAA procedures to attach to the WLAN and may perform I-WLAN tunnel establishment to enable IP connectivity to the PDG 236. The UE110 may select a service from the V-PLMN130 by using a roaming Network Access Identifier (NAI) indicating both the H-PLMN160 and the V-PLMN130 in the authentication and authorization request. Roaming NAIs are described in 3GPP TS 23.234 and TS 23.003. This ensures that UE110 may obtain IP access for IMS services from PDG236 in V-PLMN130 instead of from PDG in H-PLMN160 (which may restrict PSAP access if H-PLMN160 is far away). A global WLAN APN (W-APN) for emergency services may be used for PDG discovery and tunnel establishment. This service may use a globally unique external network identifier (for supporting emergency services) and V-PLMN identification. P-CSCF252 may be a P-CSCF in a V-PLMN associated with the WLAN and may be discovered via a DNS query for the W-APN.

For cdma2000 access, UE110 obtains a simple IP address instead of a mobile IP address because service is obtained from V-PLMN130 instead of H-PLMN 160. Alternatively, the UE110 may obtain the mobile IP address from the V-PLMN130 rather than from the H-PLMN160 as is more normal for mobile IP addresses. The IP address may be an IPv4 address or an IPv6 address. If UE110 has not established connectivity (e.g., has no assigned IP address), UE110 may establish a point-to-point protocol (PPP) session and perform any authentication and authorization to PDSN242 in V-PLMN130, as described in 3GPP2x. p0011d and TIA-835-D. UE110 may obtain a simple IP address, for example, using PPP Internet Protocol Control Protocol (IPCP). If UE110 has established IP connectivity and has a PPP session to PDSN242 but is assigned a mobile IP address in H-PLMN160 instead of a simple IP address, then UE110 may terminate any packet sessions associated with these IP addresses as well as any IMS registrations if UE110 cannot support simultaneous simple IP and mobile IP addresses (which is an optional but not mandatory UE capability in TIA-835D). UE110 may then obtain a simple IP address as described in TIA-835D. If UE110 can support simultaneous simple and mobile IP addresses, UE110 may obtain a simple IP address if it does not already have one.

For cdma2000 access, UE110 may discover the P-CSCF address by (a) using DHCP or IPCP to obtain the P-CSCF domain name and DNS address from a DHCP server or PDSN242 and then (b) using DNS to obtain one or more P-CSCF IP addresses from a DNS server. If UE110 moves and accesses a new RAN, V-PLMN130 and UE110 may use the fast handoff procedure described in TIA-835-D if a new target PDSN is needed and an emergency VoIP call has been established. This avoids the need to terminate and re-establish the call.

For 3GPP2WLAN access, UE110 may perform existing WLAN access procedures, including AAA, IP address acquisition, and discovery of default IP router and DNS server addresses (e.g., via DHCP). UE110 may then access a PDIF in a PLMN that supports emergency calls from the geographic location of the WLAN to which UE110 is accessed. The WLAN may advertise the associated cdma2000 network to be able to distinguish PLMNs that support emergency calls. This advertisement may be accomplished, for example, by sending an associated Service Set Identifier (SSID) in an IEEE 802.11 beacon frame or via a response to a UE probe request frame. The PLMNs may be prioritized in the order in which they are advertised by using an indicator for each advertised PLMN or by ensuring (e.g., requiring) that all advertised PLMNs support emergency calls. For initial WLAN access, AAA, and IP address acquisition, UE110 may select a PLMN (e.g., SSID) implied or indicated as supporting emergency calls.

After initial WLAN access, AAA, IP address acquisition, and discovery of default router and DNS server addresses, UE110 may create a Fully Qualified Domain Name (FQDN) indicating IMS services and use a domain associated with one of the PLMNs advertised by the WLAN to support emergency calls. UE110 may then use the FQDN to discover the IP addresses of one or more PDIFs from the DNS server. The UE may select a PDIF and establish an IPsec tunnel to the PDIF using the procedures described in 3gpp2 x.s0028-200. This provides UE110 with a second internal IP address, which may be used for subsequent IMS-related procedures.

After establishing the tunnel from the WLAN to the PDIF, the UE110 may discover the P-CSCF address in the same manner as the UE accesses a PDSN from a cdma2000 access network (e.g., obtaining the DNS server address and domain name via DHCP and then obtaining the P-CSCF IP address via DNS). In this case, the PDIF may act as a DHCP relay agent instead of the PDSN. Discovering the PIDF and P-CSCF address via DNS may include an indication that emergency calls need to be supported (e.g., in the name provided to the DNS server).

If UE110 already has an association (e.g., a tunnel) with a PDIF in an unsuitable PLMN and if UE110 does not simultaneously support tunnels to different PDIFs, UE110 may issue any packet sessions supported via the current PDIF and issue a tunnel to a PDIF before selecting and establishing a tunnel to a new PDIF in a new suitable PLMN.

After cdma2000 or WLAN access network connection, UE110 may discover the SUPL V-SLP address using a DNS query with a known V-PLMN domain name and V-SLP identification (e.g., supply _ vslpdomain _ name).

Message flow 500 has the following added features related to OMA SUPL version 1.0.

(a) An E-SLP address is added in SUPL INIT, which overrides and replaces the H-SLP address configured in UE 110.

(b) Interface between the IMS side (e.g., E-CSCF 254) and the location side (e.g., E-SLP 272).

(c) Use V-SLP274 and discover V-SLP address.

(d) Supline is communicated using mobile terminal IP, UDP/IP, SIP or IMS signaling instead of SMS or WAP push to reduce latency.

(e) An emergency service indication is added in SUPL INIT.

(f) The new location measurements are preferably added in SUPLPOS INIT.

(g) ILP protocol is used between E-CSCF254 and E-SLP272, which may be similar to existing RLP.

(h) And (4) safety.

2.Emergency VoIP call with 3GPP control plane

Fig. 6 shows a block diagram of an embodiment of a network architecture 600 suitable for 3GPP control plane location. For simplicity, fig. 6 shows only the entities and interfaces related to supporting an emergency VoIP call with GPRS access and 3GPP control plane location.

The access network 120 may be GERAN or UTRAN. The V-PLMN130 may include a P-CSCF252, an E-CSCF254, and an MGCF258 to support IMS (e.g., VoIP), an SGSN/GGSN 232 for packet switched services, and a GMLC276 for location services. GMLC276 replaces E-SLP272 and is an enhanced version of GMLC described in 3GPP 23.271, release 6. The V-PLMN130 may also include an E-SLP272 and a V-SLP274 (not shown in fig. 6) for location services.

In an embodiment, GMLC276 communicates with E-CSCF254 via the Li interface and PSAP180 via the J-STD-036E 2' interface. The location architecture differences between SUPL and 3GPP control plane from E-CSCF254 can be hidden using the same Li interface for GMLC276 and E-SLP 272. Similarly, the location architecture difference from PSAP180 may be hidden using the same J-STD-036E 2' interface for GMLC276 and E-SLP 272. 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 emergency VoIP call setup using the 3GPP control plane. For clarity, the less relevant entities (e.g., access network 120, P-CSCF252, S/R292) are omitted from FIG. 7 but included in the following description. Message flow 700 assumes that UE110 has a UICC and that a roaming agreement exists between H-PLMN160 and V-PLMN 130.

In step 1, UE110 performs a GPRS attach with an emergency services indication if the UE has not already performed a GPRS attach. GPRS attach may require gaining access to SGSN232 a, performing any authentication and downloading of subscription data from HLR/HSS266 in H-PLMN160 to SGSN232 a, etc. In step 2, UE110 performs PDP context activation using the global APN for emergency services. The PDP context is assigned to a local GGSN in the V-PLMN130 (e.g., and not to a GGSN in the H-PLMN 160). UE110 obtains the IP address and may discover a local SIP server address (e.g., P-CSCF252) during PDP context activation.

In step 3, the SGSN232 is aware of the initiation of the emergency call based on the emergency indication in step 1 or the global APN for emergency services in step 2. The SGSN232 a may then initiate a packet-switched network induced location request (PS-NI-LR) described in 3GPP TS 23.271 to obtain an intermediate or more accurate location estimate for the UE 110. The PS-NI-LR provides a faster response than if the SGSN232 awaits a request to obtain a location estimate from the GMLC276 (e.g., via the MAP PSL in step 17). The PS-NI-LR may be performed by the original SGSN. If the UE110 hands over to a new SGSN, the new SGSN does not need to perform another PS-NI-LR. In step 4, once the location estimate for UE110 is obtained, SGSN232 may determine the GMLC address (e.g., from the current cell ID) and may send a MAP Subscriber Location Report (SLR) containing the location estimate, UE identity, and/or other information to GMLC 276. The UE identity may be an International Mobile Subscriber Identity (IMSI), a mobile subscriber ISDN number (MSISDN), an International Mobile Equipment Identity (IMEI), an Electronic Serial Number (ESN), a Mobile Equipment Identifier (MEID), or some other identity. If step 4 is performed, steps 10 and 11 may be skipped.

In step 5, UE110 sends the sip register found in step 2 to P-CSCF 252. The sip register may include the information described above for step 2 in fig. 5, and may also include the SGSN address if steps 10 and 11 are to be performed. P-CSCF252 forwards SIP REGISTER to E-CSCF254 in the same network because of the presence of the emergency service indication or emergency public user ID. Step 5 may be performed in parallel with step 3. In step 6, the E-CSCF254 forwards SIP REGISTER to the H-PLMN160 in the event of a normal IMS registration, similar to step 3 in fig. 5.

In step 7, the 200OK is returned to the UE110 after the H-PLMN160 returns the 200OK to the E-CSCF 254. The UE110 may also re-register if there is a handoff to a different SGSN within the V-PLMN 130. If UE110 re-registers with its emergency public user ID, E-CSCF254 may pass any new location information and/or any new SGSN address to GMLC 276.

As in fig. 5, in an alternative embodiment of steps 5, 6 and 7, after the UE110 sends SIP REGISTER to the P-CSCF252 in step 5, the P-CSCF252 may forward SIP REGISTER directly to the S-CSCF264 or the I-CSCF262 in the H-PLMN160 and bypass the E-CSCF254 in the V-PLMN 130. In this case, the SIP 200OK from H-PLMN160 would be returned to P-CSCF252 instead of E-CSCF254, and P-CSCF252 would return the 200OK to UE110 in step 7. This alternative embodiment may reduce or avoid the special impact of supporting VoIP emergency calls for P-CSCF252, as the actions of P-CSCF252 then act as they would at normal registration.

In step 8, the UE110 sends SIP INVITE to the P-CSCF252, which SIP INVITE may include the information described above for step 5 in fig. 5. P-CSCF252 forwards SIP INVITE to E-CSCF 254.

In step 9, based on the UE support for the 3GPP control plane for packet mode, the E-CSCF254 sends a routing request to the GMLC276 indicated by the serving cell or other location information received in step 8. The routing request may contain the information described in step 6 of fig. 5 as well as the SGSN address (if provided during registration). The E-CSCF254 may select the GMLC276, a generic location server capable of acting as a GMLC, or some other type of server (e.g., SLP). The selected location server may elect to use the 3GPP control plane based on the UE positioning capabilities conveyed by E-CSCF 254. E-CSCF254 may request location information from GMLC276 and/or select a PSAP corresponding to the available location information and the type of emergency service requested.

If the location information provided in step 9 enables GMLC276 to derive a location estimate for UE110 that is accurate enough to satisfy the request in step 9, GMLC276 proceeds to step 12. GMLC276 may also wait until it receives a MAP SLR from SGSN232 in step 4 and proceed to step 12 if an appropriate location estimate is obtained. Otherwise, steps 10 and 11 are performed to obtain an appropriate position estimate for UE 110.

In step 10, GMLC276 sends a MAP Providing Subscriber Location (PSL) containing QoP accuracy/delay for fast intermediate location estimation to SGSN 232. If step 4 is not performed, GMLC276 may determine SGSN232 from any explicit address or location information (e.g., cell ID) received in step 9. If this information is not received and if the initially selected SGSN is not correct (error response received in step 11), GMLC276 may query the HSS indicated by the UE's IMSI or pseudo MSI or MSISDN to obtain the SGSN address. In step 11, SGSN232 may return the location estimate obtained in step 3, wait until step 3 is complete, and then return the location estimate, or obtain the location estimate from the RAN and then return the location estimate to GMLC 276.

In step 12, GMLC276 selects a PSAP based on the location estimate. The following description assumes PSAP180 to be the selected PSAP. If PSAP180 has a PSTN available, GMLC276 obtains an ESRD non-dialable telephone number that is available for routing to PSAP180 and an ESRK non-dialable telephone number that identifies PSAP180, GMLC276, and (temporarily) UE 110.

In step 13, the GMLC276 returns a routing response to the E-CSCF254 that may include the information described above for step 13 in fig. 5. In step 14, the emergency call is sent to PSAP180 as described with respect to steps 14a, 14b, and 14c in fig. 5. In step 15, the rest of the emergency call setup proceeds as described for steps 15a and 15b in fig. 5. In step 16, PSAP180 sends a location request to GMLC276 indicated by the IP address/name or ESRK in step 14, as described for step 16 in fig. 5.

In step 17, the GMLC276 sends a MAP PSL to the SGSN232 to request an accurate location. GMLC276 may obtain the SGSN address from the most recent location information for UE110 or from an update of the SGSN address from E-CSCF 254. GMLC276 may also query the SGSN address from E-CSCF254 if this address is received in a re-REGISTER message but not passed. GMLC276 may also query the SGSN address from the HSS indicated by the IMSI or pseudo MSI or MSISDN of the UE. In step 18, SGSN232 prompts RAN to locate UE 110. In step 19, the SGSN232 returns the location estimate to the GMLC 276. In step 20, the GMLC276 returns the location estimate to the PSAP180 as described with respect to step 20 in fig. 5.

UE110 may then communicate with PSAP180 for the emergency VoIP call. When a call is later placed, the E-CSCF254 may send an indication to the GMLC276, which GMLC276 may then issue any records of the call. The E-CSCF254 or the UE110 may also de-register the emergency public user ID registered in steps 5 to 7. Alternatively, E-CSCF254, GMLC276, and UE110 may allow registration and call recording for some period of time to support possible subsequent call backs and/or additional location requests from PSAP180 to UE 110.

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

(a) SGSN232 may obtain the UE location and push it to GMLC276 whenever the PDP context is activated and/or if requested by GMLC 276.

(b) GMLC276 may receive the public SIP-URI address of UE110 from E-CSCF 254.

(c) If PSAP180 has a PSTN available, GMLC276 and E-CSCF254 pass information (e.g., a10 digit ESRK) to PSAP180 identifying both the call and GMLC 276. This information enables PSAP180 to pull location and other information (e.g., MSISDN, SIP URI) from GMLC 276.

(d) When SUPL is used as a positioning method, the Li interface between the E-CSCF254 and the location server (e.g., E-SLP 272) may be used to support emergency calls from the I-WLAN. Using the same Li interface for UMTS, GPRS, and I-WLAN allows the IMS (e.g., E-CSCF 254) to operate without having to be aware of the location solution, which may simplify IMS processing.

(e) If the UE110 does not support positioning by the RAN (e.g., SUPL supported but not 3GPP control plane supported), the SGSN232 may skip the PS-NI-LR.

(f) PSAP180 may have certain location requirements that SGSN232 may not know, such as a certain accuracy or even support location coordinates (e.g., if PSAP180 supports E911 phase 0 or 1). Such requirements are supported in GMLC276 for circuit switched emergency calls.

The Li interface can be used to implement the features listed above. If the same platform supports GMLC and E-CSCF functionality, there may not be a need to support the Li interface externally. The Li interface may be extended to be used between any IMS entity and the GMLC to support other features associated with IMS and IP based services, as described above for SUPL.

SGSN232 may be selected based on an intermediate location estimate (e.g., serving cell) of UE 110. The GMLC276 may be selected by the E-CSCF254 based on the same intermediate location estimate. The intermediate position estimate may be pushed from SGSN232 to GMLC276 or pulled from SGSN232 by GMLC 276. One entity may determine the other entities as follows.

SGSN232 may push the intermediate location estimate to GMLC 276. SGSN232 may obtain this intermediate location estimate via PS-NI-LR, determine the GMLC address from the current UE location (e.g., current cell ID), and send/push the location estimate to GMLC276 using MAP Subscriber Location Report (SLR). E-CSCF254 may query GMLC276 for the PSAP address in order to route the emergency call. GMLC276 may wait, if needed, for a MAP SLR from SGSN232 to determine the PSAP address from the intermediate location estimate.

GMLC276 may pull the intermediate position estimate from SGSN 232. SGSN232 may still perform PS-NI-LR but does not send the location estimate to GMLC276 until after the GMLC queries the location estimate via a MAP PSL request. GMLC276 may determine the SGSN address using one of the following means.

(a) GMLC276 queries the SGSN address from HSS266 in H-PLMN160 (if UE 180 has UICC and roaming supported in V-PLMN 130) or HSS 250 in V-PLMN130 (if UE 180 does not have UICC or does not have roaming agreement in V-PLMN 130).

(b) UE110 includes the current SGSN address or location information (e.g., GPRS cell ID) that may be used to derive the SGSN address in each REGISTER and re-REGISTER message sent to the IMS for the emergency call or in each SIP INVITE message sent to the IMS. E-CSCF254 then passes the SGSN address or location information to GMLC 276. UE110 re-registers in IMS after any inter-SGSN handover.

3.Emergency VoIP call with x.s0024

Fig. 8 shows a block diagram of an embodiment of a network architecture 800 suitable for x.s0024 location for cdma2000 networks. The access network 120 may include a CDMA2000IX network, a CDMA20001xEV-DO network, a 3GPP2WLAN, and so forth. V-PLMN130 may include P-CSCF252, E-CSCF254, and MGCF258 to support IMS (e.g., VoIP) and PDSN242 for packet switched services (not shown). The V-PLMN130 may include E-PS282 and V-PS/PDE284 (as shown), and may also include E-SLP272 and V-SLP274 (not shown) for location services. E-PS282 replaces H-PS for location of emergency calls. The E-PS282 and V-PS/PDE284 may reside in other networks.

In an embodiment, the UE110 communicates with the E-PS282 via an LCS-x interface and communicates with the V-PS/PDE284 via an LCS-y interface. E-PS282 communicates with V-PS/PDE284 via an LCS-z interface, E-CSCF254 via an LCS-i interface, and PSAP180 via a J-STD-036E 2' interface. The LCS-I interface may be similar to the V2 interface in RLP or Li/ILP for SUPL, NENA I2 solutions, or some other interface. The protocol used for the LCS-i interface may be ILP for SUPL. 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 emergency VoIP call setup using x.s0024. In step 1, UE110 discovers and attaches to the access network, establishes IP connectivity, and may discover a local SIP server (e.g., P-CSCF252), as described above for step 1 in fig. 5. After accessing the network connection, UE110 may discover the V-PS address using a DNS query with a known V-PLMN domain name and V-SLP identification (e.g., xs0024_ vpscope _ name).

In step 2, UE110 sends SIP REGISTER to P-CSCF252 and P-CSCF252 forwards the message to E-CSCF 254. In step 3, the E-CSCF254 forwards the sip register to the H-PLMN160 in case of normal IMS registration. In step 4, the E-CSCF254 (e.g., after receiving the 200OK from the H-PLMN 160) returns the 200OK to the UE 110. The UE110 may re-register if the UE110 is handed off to a different PCF, PDSN, or WLAN within the same V-PLMN.

In an alternative embodiment of steps 2, 3 and 4, after the UE110 sends SIP REGISTER to the P-CSCF252 in step 2, the P-CSCF252 may forward SIP REGISTER directly to the S-CSCF264 or the I-CSCF262 in the H-PLMN160 and bypass the E-CSCF254 in the V-PLMN 130. In this case, the SIP 200OK from the H-PLMN160 would return to the P-CSCF252 and not to the E-CSCF254, and in step 4, the P-CSCF252 would return a200 OK to the UE 110. This alternative embodiment may reduce or avoid the special impact of supporting VoIP emergency calls for P-CSCF252, as the actions of P-CSCF252 then act as they would at normal registration.

In step 5, the UE110 sends SIP INVITE to the P-CSCF252 (not shown), and the P-CSCF252 forwards SIP INVITE to the E-CSCF 254. In step 6, the E-CSCF254 may determine that the UE110 supports x.s0024 and send a route request to the E-PS282 in the same or a different network. The route request may include the information and V-PS address (if obtained during registration) described above for step 6 in fig. 5.

If the location information provided in step 6 enables the E-PS282 to derive a sufficiently accurate location estimate for the UE110, the E-PS282 proceeds to step 12. Otherwise, steps 7 to 11 are performed to obtain an appropriate position estimate for the UE 110. In step 7, the E-PS282 acts as an H-PS, performing subsequent x.s0024 positioning using procedures that may be similar to those used for (a) x.s0024 roaming support (if V-PS is selected) or (b) x.s0024 non-roaming support (if V-PS is not selected). The E-PS282 generates x.s0024SUPL TNIT to instigate a network initiated positioning procedure to the UE 110. The E-PS282 may send the SUPL INIT directly to the UE110 using mobile terminal IP or UDP/IP, in which case step 8 is skipped. The E-PS282 may also send the SUPL INIT to the E-CSCF254 within the instant message. In either case, supline may include a positioning mode, QoP accuracy/delay for fast intermediate location estimation, E-PS IP address, emergency call indication, etc. Any E-PS address conveyed in SUPL INIT overrides any H-PS address configured in UE 110.

In step 8, E-CSCF254 forwards the SUPL INIT to UE110 via P-CSCF252 using IMS or SIP signaling. In step 9, the UE110 establishes a secure IP connection to the E-PS282, which E-PS282 may be an H-PS for the UE110 or may have included its IP address in the SUPL INIT in step 7. SUPL START, which may include UE positioning capabilities, location information for UE110, location estimates for UE110 (if available), etc., is then sent to E-PS 110 a. If a location estimate is received from the UE110 with sufficient accuracy to determine the PSAP in step 9, the E-PS282 may proceed to step 12 and terminate the location transaction with the UE110 by sending a SUPL END.

In step 10, the E-PS282 determines a suitable local PDE or a suitable remote V-PS for performing position location based on the position information received in step 9 or other position information received in step 6. The E-PS282 also decides whether to use proxy mode or non-proxy mode. The E-PS282 then interacts with the V-PS or PDE to locate and send x.s0024SUPL RESPONSE, which may include the PDE IP address, to the UE110 (if non-proxy mode is selected). In step 11, the UE110 exchanges SUPL POS messages with the PDE in the non-proxy mode or E-PS282 in the proxy mode to continue and complete positioning as described in 3GPP2 X.S0024-0. The SUPL POS message may carry an embedded IS-801 message. The positioning provides a position estimate for the UE110, which is passed to the E-PS 282.

In step 12, E-PS282 selects a PSAP (e.g., PSAP 180) and obtains the ESRD and ESRK (if PSAP180 has a PSTN available). In step 13, E-PS282 returns a routing response to E-CSCF254, which may include the PSAP identification (if PSAP180 has IP available), the ESRD and the ESRK (if PSAP180 has PSTN available), and the location estimate of UE110 (if requested by E-CSCF 254). The E-PS282 may store a call record for the UE110 that contains all the information collected for the UE. If PSAP180 has IP available, steps 14a and 15a are performed. If the PSTN is available to PSAP180, steps 14b, 14c, and 15b are performed. In step 16, after establishing the call, PSAP180 may send a location request for accurate location estimation to E-PS282, which E-PS282 may be identified by the IP address or name obtained in step 14a or the ESRK obtained in step 14 c.

In step 17, the E-PS282 may start a new x.s0024 transaction with the UE110 by sending SUPL INIT directly to the UE110 using mobile terminal IP or UDP/IP (in which case step 18 is skipped) or by sending an instant message to the E-CSCF254 containing x.s0024SUPL INIT with the parameters described in step 7 (except for QoP accuracy/delay for accurate position estimation). In step 18, the E-CSCF254 delivers the SUPL INIT to the UE110 inside an IMS instant message, a SIP message, or some other message. In step 19, the UE110 establishes an IP connection (e.g., a secure IP connection) to the E-PS282 and returns SUPLSTART to the E-PS 282. The E-PS282 determines a suitable PDE or V-PS for positioning based on any location information in the SUPL START and based on any other location information of the UE 110. The E-PS282 then begins positioning by returning SUPL RESPONSE to the UE 110. The UE110 may then exchange SUPLPOS messages with the E-PS282, the local PDE, and/or the remote PDE to perform positioning and obtain an accurate position estimate for the UE 110. In step 20, the E-PS282 sends the accurate position estimate for the UE110 to the PSAP180 in a position response.

UE110 may then communicate with PSAP180 for the emergency VoIP call. When a call is subsequently placed, the E-CSCF254 may send an indication to the E-PS282, which E-PS282 may then issue any records for the call. The E-CSCF254 or the UE110 may also de-register the emergency public user ID registered in steps 2 to 4. Alternatively, E-CSCF254, E-PS282, and UE110 may allow registration and call recording for a certain period of time to support possible subsequent call backs and/or additional location requests from PSAP180 to UE 110.

Additional details of steps 1 through 8 and steps 12 through 20 of fig. 9 may be described with respect to steps 1 through 8 and steps 12 through 20, respectively, of fig. 5.

The message flow 500 has the following features relating to x.s0024.

(a) An E-PS address is added in x.s0024suplinat, which overrides and replaces the H-PS address configured in the UE110 or UIM.

(b) Interface between the IMS side (e.g., E-CSCF 254) and the location side (e.g., E-PS 282).

(c) V-PS 284 is used and the V-PS address is found.

(d) X.S0024SUPL INIT is communicated using mobile terminal IP, UDP/IP, SIP signaling, or IMS signaling.

(e) An emergency service indication is added in x.s0024supl INIT.

(f) A new protocol is used between the E-CSCF254 and the E-PS282, which may be similar to the oma rlp or PS-PS protocol over the LCS-z interface in x.s0024.

(g) And (4) safety.

4.UE supporting UICC/UIM-less and/or roaming protocols

The above description assumes that UE110 has a UICC or UIM and that H-PLMN160 and V-PLMN130 have roaming agreements that permit UE registration in V-PLMN130 and subsequent emergency call access to PSAP 180. If this is not the case, UE110 may access and register in V-PLMN130 and may complete call setup to PSAP180 and possibly call back from PSAP180 as described below. Callback from PSAP180 without UICC/UIM is possible for VoIP, but is generally not possible for circuit switched emergency access due to inability to page unregistered UEs.

Fig. 10 shows a block diagram of an embodiment of a network architecture 1000 that supports emergency VoIP call setup and PSAP call back for UEs that do not have a UICC/UIM. The 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 some other location entity.

4.1.Access

UE110 may gain GPRS access, 3gpp wlan access, or IMS access without a UICC. UE110 may also obtain cdma2000 access, 3GPP2WLAN access, or IMS access without UIM. UE110 may perform different procedures for different types of accesses.

For GPRS access, UE110 may perform PDP context activation for emergency services without a UICC and/or without a roaming agreement in V-PLMN130 (as described in 3GPP TR 23.867). GPRS attach may be implemented using a pseudo IMSI, which may register UE110 in HSS 250 in V-PLMN130, which in turn may help support inter-SGSN handover. If the UE110 does not have a UICC, a pseudo IMSI may be created with a unique MCC-MNC combination and digits from the IMEI. If the UE110 has a UICC but does not have roaming access to the V-PLMN130, a pseudo IMSI may be created with digits from the IMSI instead of the IMEI, which may avoid duplicate pseudo IMSIs that may occur when all IMSI digits are used. GPRS attach may also be implemented using IMEI as an identification.

For 3gpp wlan access, UE110 may create a pseudo NAI from a pseudo IMSI (e.g., the same pseudo IMSI used for GPRS attach) as follows:

pseudo-NAI ═ n < pseudo-IMSI > V-PLMN _ network _ domain "

Where n is a fixed number in the range of 2 to 9 indicating that a non-verifiable pseudo NAI (0 or 1 has been taken for a normal NAI) is used for the emergency call. The UE110 may use a pseudo NAI for initial access and AAA procedures.

The WLAN may advertise a V-PLMN that can support AAA using a pseudo NAI for emergency calls or may present the V-PLMN in a prioritized order indicating the ability and willingness to support this. V-PLMN130 may treat UE110 as a temporary home subscriber and may skip AAA or ensure that it succeeds (e.g., by using well-known keys to ensure authentication succeeds). It may be desirable to follow as much as possible the normal procedure and register UE110 in HSS 250 in order to better support WLAN reselection and handover.

For cdma2000 access, UE110 may establish a PPP session with PDSN242 and may reject authentication during PPP establishment by returning a Link Control Protocol (LCP) configuration reject in reply to an LCP configuration request from PDSN242, e.g., as described in IETF RFC 1661. PDSN242 may support emergency calls for non-UIM or non-authenticated UEs and may continue the establishment of the PPP session without authenticating UE 110. PDSN242 may assign a simple IP address to UE110 and may apply IP packet filtering to limit entities that may communicate with UE 110. For example, PDSN242 may restrict UE110 from communicating with local servers (e.g., DHCP servers, DNS servers, and P-CSCF252) and entities associated with PSAP access (but not open internet access).

The PDSN242 may be notified of the emergency call in several ways. In an embodiment, UE110 sends an IPCP configure request to PDSN242 containing a unique IP address that is globally defined to indicate an IP address request for an emergency call. In other embodiments, the indication may be used during PPP establishment, or may be received from the RAN (RRC/PCF 222) via the cdma2000 a10 interface. In any case, the PDSN242 may assign a simple IP address to an unverified UE for emergency calls and may use special filtering (as described above). This IP address assignment may be achieved via PPP IPCP as described in the enhanced IETF RFC 1332. If UE110 does not indicate an emergency call, PDSN242 may disable PPP establishment and IP address assignment.

Instead of denying authentication, UE110 may allow authentication to proceed using the Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP) described in IETF RFC 1334 and RFC 1994, respectively. UE110 may receive the CHAP challenge or PAP verification request and may send a response including an identification indicating an emergency call from the UIM-free UE. This identification may be a pseudo IMSI for 3GPP2WLAN access. If the identity indicates the V-PLMN130 as the domain of UE110, then CHAP or PAP authentication proceeds to AAA server 246 in V-PLMN130 in the normal manner from the perspective of PDSN 242. AAA server 246 may recognize the pseudo IMSI as indicating emergency call access and may perform authentication prior to normal authentication or may use a known key. AAA server 246 may ensure that PDSN242 restricts IP access using restricted filtering, e.g., to allow emergency VoIP calls but not other types of access.

The PDSN242 may construct a NAI for billing and/or record keeping. If the UE110 has a UIM, the PDSN242 may use the UE's unique international identification (IMSI, MIN, or international roaming MIN-IRM). PDSN242 may also use the ESN or other identification of UE 110.

For 3GPP2WLAN access, after UE110 accesses the WLAN, the access point or authentication entity may initiate authentication of UE110 and may send an Extensible Authentication Protocol (EAP) request or some other request for the identity of UE 110. UE110 may respond by, for example, returning an EAP response in the form of userdomain, or some other response containing the identity of the UE, where the domain identifies the H-PLMN of UE 110. If UE110 does not have a UIM or does not have a roaming agreement in V-PLMN130, UE110 may return a pseudo-identity that may be the same as or similar to a pseudo-NAI for 3GPP WLAN. For example, if the UE110 has a UIM or otherwise has digits from a unique terminal ID (e.g., ESN), the user (e.g., pseudo-IMSI) portion of the pseudo-identification may contain digits from the UE's unique national identification (e.g., IMSI, MIN, or IRM). The user part may also contain a unique prefix (e.g., a unique number) to indicate that it is a pseudo-identity for emergency calls. The pseudo-identified domain portion may indicate the V-PLMN 130.

The access point or authentication entity may continue authentication using a local AAA server (e.g., AAA server 246). Authentication may be performed normally using a known key or may be truncated because true authentication has not occurred. Once pseudo-authentication is complete, the access point or associated router may use packet filtering to restrict UE110 access, as described above.

UE110 may access the WLAN, perform pseudo-authentication and discover the PDIF. The UE110 may then identify itself to the PDIF (or local AAA server) using the pseudo-identity, e.g., in place of the NAI for cdma2000 UE-PIDF authentication. The pseudo-identity may be the same or similar to the pseudo-identity used for WLAN authentication. Normal authentication and tunnel establishment (e.g., as described in 3GPP2x. p 0028-200) then proceeds using the local AAA server and using the known key to achieve some transparency to the PDIF. Alternatively, the verification may be truncated or exited. After verification, the PDIF may use packet filtering to restrict UE110 access.

The WLAN may advertise V-PLMNs capable of supporting the above procedures or may present the V-PLMNs in a prioritized order indicating the ability and willingness to support this.

For IMS access, SIP registration may be skipped if UE110 does not have a UICC/UIM and/or does not have a roaming agreement in V-PLMN130 (as described in 3GPP TR 23.867 and 3GPP2x. p 0013-002A). This enables emergency call setup to the PSAP but does not support callback. Alternatively, the UE110 may register by sending SIP REGISTER containing the V-PLMN domain name and the emergency private user ID, which SIP REGISTER may be created using the V-PLMN domain name and the pseudo IMSI. This SIP REGISTER will be recognized in the E-CSCF254 and HSS 250 but may be transparent to other entities.

The registration procedure may then proceed until SIP REGISTER is communicated from the UE110 to the E-CSCF254 (or other IMS server) in the V-PLMN 130. Registration in the H-PLMN160 is not performed but the E-CSCF254 will register the UE110 in the HSS 250 in the V-PLMN 130. The HSS 250 may assign the temporary TEL URI and/or the temporary sip URI (from a cluster in the HSS 250) as the temporary public user identity. The tel URI may be conveyed to PSAP180 in call setup and the SIP URI may be conveyed for SIP call setup if the signaling is over the PSTN. The URI will enable a call back from the PSAP180 if both the V-PLMN130 and the UE110 maintain IMS registration and IP connectivity for a certain period of time after the emergency call is terminated. The TEL URI and the SIP URI are recognized as temporary addresses by PSAP180 due to differences from normal permanent addresses because they are not used to globally identify UE 110. HSS 250 may "block" temporary addresses returned from completed emergency calls and not reassign these addresses for a period of time to prevent PSAP call backs from being routed incorrectly to the wrong UE.

PSAP callback may be supported in several ways. If the UE110 is registered in the H-PLMN160, the callback from the PSAP180 may use the SIP URI or TEL URI public user identity of the UE110 and may be routed initially to the H-PLMN160 as described in 3GPP TS 23.228 or 3GPP2 x.p 0013. For SIP-capable PSAPAs, the SIP INVITE may be routed to the I-CSCF262 in the H-PLMN160 (based on the H-PLMN domain name in the UE's SIP URI). The I-CSCF262 may query the HSS 250 for an S-CSCF264 in the H-PLMN160 and may then route the call to the S-CSCF 264. S-CSCF264 may then route the call to E-CSCF254 or P-CSCF252 in V-PLMN130 based on the previous registration information. In the former case, S-CSCF264 may treat E-CSCF254 as a P-CSCF, and may route the call to UE110 via P-CSCF 252. In the latter case, P-CSCF252 may route the call to UE 110. For PSAPs that have PSTN available, the call may be routed through the PSTN to the MGCF in the H-PLMN160 based on the TEL URI of the UE 110. The MGCF may operate intermediately between the PSTN and SIP signaling and may send SIP INVITE to the I-CSCF262 in the H-PLMN 160. The call routed from I-CSCF262 to UE110 will then continue in the same manner as the PSAP for available SIP.

If UE110 is not registered in H-PLMN160 (e.g., due to not having a UICC/UIM and/or not having a roaming agreement with V-PLMN 130), UE110 may be registered in HSS 250 in V-PLMN 130. The HSS 250 may assign a temporary TEL URI or sip URI public user identity to the UE 110. The call back from the PSAP may then be routed to either I-CSCF 256 (PSAP for SIP available) or MGCF258 (PSAP for PSTN available) without involving H-PLMN 160.

4.2.Call setup

Fig. 11 shows an embodiment of a message flow 1100 for emergency VoIP call setup for a UE without UICC/UIM. Message flow 1100 may be used for 3GPP control plane location, SUPL, and x.s0024.

In step 1, UE110 discovers and attaches to the access network, establishes IP connectivity, and may discover a local SIP server (e.g., P-CSCF252), as described above. UE110 may use a pseudo IMSI for GPRS or cdma2000 access, a pseudo NAI for WLAN access, and a pseudo identity for 3GPP2WLAN access. The UE110 may register with the HSS 250 in the V-PLMN130 using a pseudo identity (e.g., a pseudo IMSI).

In step 2, the UE110 attempts to register in the V-PLMN IMS network by sending SIP REGISTER to the P-CSCF252 found in step 1. For UICC/UIM-less or roaming-less SIP REGISTER may contain an emergency services indication, a V-PLMN domain name, the UE IP address obtained in step 1, an emergency private user ID created using the V-PLMN domain name and a pseudo IMSI (for GPRS) or pseudo identity (for cdma2000), and/or other information. For re-registration, SIP REGISTER may further include the temporary public user ID assigned in the initial registration. Due to the presence of the emergency service indication or emergency private user ID (which may indicate the V-PLMN130 as the home network for the UE 110), the P-CSCF252 forwards SIP REGISTER to the E-CSCF254 supporting the emergency service call in the same network. The forwarded SIP REGISTER may include location information for UE 110. SIP REGISTER may also contain a V-SLP or SGSN address (for 3GPP) or a V-SLP, PDSN or PIDF address (for 3GPP 2).

In step 3, the E-CSCF254 forwards the registration information to the HSS 250, e.g., in a Cx-Put/Cx-Pull (Cx-Put/Cx-Pull), because the emergency private user ID of the UE110 references the V-PLMN 130. In step 4, the HSS 250 verifies whether an emergency private user ID is registered, e.g. whether the UE110 is registered or whether another UE is registered with the same private user ID. HSS 250 may use the temporary public user ID (if provided) to distinguish between UEs with the same emergency private user ID due to a common UE entity number (e.g., a common IMEI or ESN number) and to distinguish between initial registration (without assigning a temporary public user) and re-registration. For initial registration, the HSS 250 stores the emergency private user ID and the E-CSCF address and assigns a temporary public user SIP URI and/or TEL URI back to the E-CSCF 254.

In step 5, E-CSCF254 returns a200 OK to UE110 via P-CSCF 252. The 200OK may include a temporary public user ID assigned by the HSS 250. If the UE110 is handed off to a different SGSN (for GPRS access), a different PCF or PDSN (for cdma2000 access), a different WLAN (for WLAN access) within the V-PLMN130, the UE110 may re-register. In step 6, the UE110 sends SIP INVITE to the P-CSCF252, SIP INVITE may include a global SIP URL or TEL URI indicating the emergency call, the type of emergency service required, and the temporary public user ID received in step 5 (if the UE110 does not have UICC/UIM and/or does not have roaming access to the V-PLMN 130). P-CSCF252 forwards SIP INVITE to E-CSCF 254. In step 7, E-CSCF254 interacts with location server 286 to obtain PSAP routing information (e.g., PSAP SIP URI or ESRD and ESRK) for the call, as described with respect to steps 6 through 13 of fig. 5 and steps 9 through 13 of fig. 7.

If PSAP180 has IP available, steps 8a and 9a are performed. In step 8a, E-CSCF254 routes SIP INVITE to PSAP180 using the sip uri. SIP INVITE may contain any intermediate location estimate for the UE110, the IP address or name of the location server 286, and the temporary public user SIP URI assigned to the UE 110. In step 9a, additional SIP signaling may be exchanged to establish the emergency call.

If the PSTN is available to PSAP180, steps 8b, 8c, and 9b are performed. In step 8b the E-CSCF254 forwards SIP INVITE via the BGCF to the MGCF 258. SIP INVITE may include an ESRD and an ESRK and possibly a temporary public user TEL URI assigned to UE 110. In step 8c, MGCF258 routes the call over the PSTN to PSAP180, possibly via a selective router, using SS7ISUP and/or MF signaling. The ESRD or ESRK is used as a routing number and the ESRK is passed to PSAP180 as an identification of UE110 and as a key to obtain more information. A temporary public user e.164 number may also be delivered to PSAP180 if the signaling capabilities allow. E.164 is the ITU-T standard defining the international telephone numbering system, and e.164 consists of a country code plus a national number. In step 9b, additional SIP signaling may be exchanged and interworking with SS7ISUP and/or MF may occur at MGCF258 to establish the call.

In step 10, PSAP180 may obtain an accurate location estimate for UE110 by querying location server 286, which may be indicated by a SIP URI or ESRK in the call setup. If PSAP180 has the PSTN available and if this number is not delivered to PSAP180 in the call setup, the response from location server 286 may include any temporary public user e.164 number. A call may be placed after a period of time (e.g., dropped due to temporary loss of radio coverage). E-CSCF254 may then wait a period of time before notifying location server 286 in order to support PSAP180 in locating UE110 for a subsequent callback.

PSAP180 attempts to call UE110 back using its temporary public user ID. Step 11a is performed for the PSAP for which SIP is available. In step 11a, PSAP180 sends SIP INVITE to I-CSCF 258, which I-CSCF 258 may be indicated by the network domain part of the temporary public user SEP URI assigned to UE 110. Steps 11b and 11c are performed for the PSAP of the available PSTN. In step 11b, PSAP180 sends ISUP LAM (or MF call setup) to MGCF258, which MGCF258 may be indicated by the first few digits in the temporary public user e.164 number assigned to UE 110. In step 11c, MGCF258 sends SIP INVITE containing the TEL URI constructed from the e.164 number received in step 11b to I-CSCF 258.

In step 12, I-CSCF 258 sends a location query to HSS 250, which may include the temporary public user SEP URI received in step 11a or the temporary public user TEL URI received in step 11 c. In step 13, the HSS 250 discovers the UE registration information and returns the address of the E-CSCF254 to the I-CSCF 258. In step 14, I-CSCF 258 forwards SIP INVITE to E-CSCF 254. In step 15, E-CSCF254 locates the P-CSCF address and sends SIP INVITE to UE110 via P-CSCF 252. In step 16, the call setup continues as in the normal case.

UE110 may then communicate with PSAP 180. When a call is placed later, or sometime after the call is placed, E-CSCF254 may send an indication to location server 286, and location server 286 may then issue any records of the call.

5.Supporting geographically distant legacy PSAP

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

In one embodiment, the emergency call is redirected to a different V-PLMN. Early in the processing of SIP INVITE, the E-CSCF or a location server (e.g., E-SLP, GMLC, etc.) may determine that the call should be redirected to a call server in another network. In that case, a SIP 3xx redirect response (e.g., 305 using a proxy) containing the SIP URI of the preferred replacement server may be returned to UE 110. UE110 may then retry the call procedure as described above, but may skip the access and IP connectivity procedures if the same access network is still available. If the call setup procedure has been continued until an intermediate location estimate and/or the correct PSAP (e.g., ESRD, SIP URI, or IP address) is determined, the E-CSCF may include these in the redirect response. UE110 may then include the information in SIP INVITE sent to the new PLMN, which may avoid additional delay for obtaining the same information and allow the PLMN to be used without the ability to obtain this information. The original E-CSCF may notify a location server (e.g., E-SLP or GMLC) which may then remove the call record for UE 110.

In another embodiment, the E-CSCF forwards the call to a SIP server in another network (or the same network) that is closer to the PSAP that can better forward the call into the PSTN. The V-PLMN may continue to support all functions previously described, including positioning functions and support for UEs that do not have a UICC or UIM. Forwarded SIP INVITE may contain the PSAP identity (e.g., SIP URI or ESRD), any ESRK assigned by the location server, and any temporary public user ID assigned for UICC-less UEs. The PSAP may continue to query the location server in the V-PLMN for location information and may send any callbacks to the V-PLMN (for normal cases) or direct to the V-PLMN (in the case of UICC-less UEs) via the H-PLMN. Continuing to support these functions in the V-PLMN avoids the need for subsequent SIP servers and will enable a larger number of other networks to support the forwarding service.

In yet another embodiment, local number portability may be used, for example, in north america. In addition to returning the ESRD and ESRK, the location server (e.g., E-SLP or GMLC) may return an LRN (location routing number) to the IMS network (e.g., E-CSCF), the LRN corresponding to the LEC exchange or PSAP selective router that may directly reach the PSAP. Alternatively, the IMS network (e.g., E-CSCF or MGCF) may obtain the LRN from the ESRD. The LRN is included in the information sent to the MGCF (if not obtained by the MGCF), and the MGCF sends the ISUP IAM to the PSTN with the following parameters:

the called party number is the LRN,

the common address parameter (GAP) ═ ESRD,

the FCI parameter bit M is set to "number translated",

the calling party number UE MSISDN or ESRK, and

the caller category is set to "emergency services call" (optional).

Since PSTN supports number portability (e.g., throughout the united states), calls (ISUP IAMs) can be routed correctly to a given LEC CO or selective router, provided that SS7 can be used throughout the country instead of MF trunks.

6.Security for SUPL and X.S0024

For SUPL, a security procedure may be established to support E-SLP272 in place of H-SLP for positioning in roaming and non-roaming scenarios as well as proxy or non-proxy modes. Existing SUPL security procedures are typically based on a common key in the UE110 and the H-SLP and/or based on other information provided in the UE110 about the H-SLP (e.g., a fully qualified domain name, a root x.509 public key certificate, etc.). This information may not be available to the E-SLP 272. For E-SLP272, authentication for proxy and non-proxy modes may be supported as described below.

For x.s0024, a security procedure may also be established to support E-PS282 instead of H-PS for positioning. Existing x.s0024 security procedures are described in 3gpp2x.s0024-0 and 3gpp2 s.p0110-0. These programs utilize a common root key provisioned in the user's H-PS and in the user's UIM. The additional keys may be derived from the provided root key as follows:

(a) keys for supporting secure storage and forward encapsulation (S-SAFE), where supline is sent to UE110 using SMS or WAP push and authenticated (as from H-PS) and optionally encrypted.

(b) Keys for supporting secure IP connections between UE110 and H-PS, where x.s0024 messages are sent between UE110 and H-PS and encrypted and authenticated.

(c) A key for supporting a secure IP connection between UE110 and a PDE for non-proxy mode, where x.s0024 messages are sent between UE110 and the PDE and are encrypted and authenticated.

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 may be derived from each of these fixed keys for encryption and authentication, the value of which depends on the random number provided for a particular positioning session of the UE with the H-PS or PDE. This key derivation and accompanying Security procedure utilizes the Transport Layer Security (TLS) procedure described in IETF RFC 2246, as well as the PSK-TLS variations of this procedure described in the IETF draft "Pre-Shared key cryptography policies for Transport Layer Security (TLS)". If x.s0024 is used for positioning in an emergency VoIP call and the E-PS282 is not an H-PS, it is no longer possible to rely on a common pre-configured root key for mutual authentication and ciphering in both the UE110 and the E-PS 282.

For SUPL, the UE110 may authenticate the E-SLP272 against unauthorized access to the UE location even during emergency calls. For x.s0024, the UE110 and the E-PS282 may perform mutual authentication. Table 2 lists five verification methods (denoted as methods A, B, C, D and E) and the characteristics of each method.

TABLE 2 verification method

Characteristics of	Method A	Method B	Method C	Method D	Method E
						Validating E-SLP	Whether or not	Is that	Is that	Is that	Is that
Authenticating a UE	Whether or not	Is limited by	Is that	Is that	Is that
						Supporting roaming	Is that	Is that	Is that	Is that	Whether or not
H-PLMN impact	Whether or not	Whether or not	Whether or not	Is that	Is that
						Security to a desired IMSUE connection	Whether or not	Whether or not	Is that	Whether or not	Whether or not
UICC-less/UIM support	Is that	Is (Note 1)	Is limited by	Whether or not	Whether or not

Note 1: it is assumed that the public key root certificate is provided in the Mobile Equipment (ME).

Method a provides minimal verification. If the SUPL EMIT message indicates the location of the emergency session and UE110 is currently engaged in the emergency session, UE110 allows a network initiated SUPL or x.s0024 location from a non-authenticated E-SLP or E-PS. The restriction on emergency sessions provides some protection. For SUPL, the UE110 may select method a by calling security procedures with E-SLP 272. In this case, the E-SLP272 can still verify the UE identity to a limited extent by the SUPL INIT hash code included in the SUPL POS INIT. In addition, the IP address of the UE110 provided by the E-CSCF254 to the E-SLP272 may provide some further assurance of correct UE identity. For x.s0024 and SUPL, delivery of SUPL INIT via IMS or SIP (if direct delivery via mobile terminal IP or UDP/IP is not used) may provide some additional credit in terms of UE authenticity, since IMS and SIP delivery rely on support and verification from the V-PLMN130 and/or H-PLMN 160.

Method B is used for TLS public key verification. UE110 and E-SLP272 or E-PS282 support public key authentication using TLS as described in ietf rfc 2246 and also an alternative client authentication mechanism as described in OMA SUPL1.0 "Secure User Plane Location Architecture". This mechanism supports the authentication of the H-SLP or E-PS by the UE using TLS and the ITU x.509 public key certificate sent by the H-SLP or E-PS to the UE during the TLS handshake phase. The public key certificate provides a chain of digital signatures, each signature verifying the next signature, such that the UE can verify the public key of the H-SLP or E-PS provided the UE is provided with the public key of at least one root certificate authority. The public key validation TLS procedure supports the transfer of symmetric keys for use in subsequent encryption and validation of signaling (e.g., for subsequent SUPL messages). Authentication and encryption between the UE110 and the SPC or PDE for the non-proxy mode may also be supported with these keys or by deriving additional keys from these keys. Method B relies on certifying the E-SLP or E-PS public key by one or more root certifying authorities (e.g., defined by OMA) and providing the key in a UE supporting SUPL or x.s0024 for emergency VoIP calls. This ensures that either the E-SLP272 or the E-PS282 is authenticated by the UE110, and for SUPL, the UE110 is limitedly authenticated by the E-SLP272 via a 64-bit SUPL INIT hash contained in the SUPL POS INIT and sent by the UE110 to the E-SLP 272.

For method B, the UE110 (e.g., UICC or UIM) may be provided with one or more root public key certificates that enable the UE to verify the public key of the E-SLP272 or E-PS 282. UE110 and E-SLP272 or E-PS282 may use the TLS procedure described in RFC 2246, as well as one or more secure public key delivery procedures, such as RSA, DSS, or Diffie-Hellman, to establish a common encryption key and Message Authentication Code (MAC) key. Encryption and authentication of the SUPL or x.s0024 message may be performed after the secure TLS connection is established. For non-proxy mode, the method defined in SUPL1.0 for 3GPP2 non-proxy mode may be used to generate a common key for authentication and encryption from IETF PSK-TLS between UE110 and V-SPC or H-SPC in SUPL or between UE110 and PDE in X.S0024.

Method C is used for PSK-TLS authentication. UE110 and E-SLP272 or E-PS282 support PSK-TLS according to the IETF draft "Pre-Shared Key graphics for Transport Layer Security (TLS)" (e.g., as described in SUPL1.0 for 3GPP2SET or 3GPP2X.S0024-0 and S.P0110-0). The pre-shared key (PSK) may be generated from the following information: (a) information (e.g., random information) given by UE110, an IMS network (e.g., E-CSCF 254), and/or E-SLP272 or E-PS282, (b) information (e.g., SIP parameters) sent by UE110 or to UE110 during SIP setup of an emergency call, (c) security information already present in P-CSCF252 and UE110 to support secure IMS access from UE110 (e.g., using Ipsec, PSK-TLS, TLS), and/or (d) other information. The security information in (c) may be available if UE110 is registered with the H-PLMN IMS network via V-PLMN 130.

PSK or information used to derive PSK may be made available to UE110 and E-SLP272 or E-PS282 during SIP registration and/or initiation of a SIP emergency call, and may be made available for SUPL or x.s0024 positioning using PSK-TLS. The trust relationship established during registration and SIP call setup between these entities is used to obtain secure PSK or common information that can be used to derive the secure keys. For SUPL, then, when the UE establishes an IP (PSK-TLS) connection to the E-SLP272 after transferring SUPL INIT from the E-SLP272 to the UE110, mutual authentication of the UE110 and the E-SLP272 may be supported using PSK-TLS. For x.s0024, secure PSK may be used as the root key from which the remaining security information may be derived as described in 3gpp2x.s0024-0 and s.p0110-0.

Method C relies on a secure connection between UE110 and IMS during SIP registration and/or SIP call setup, which implies that UE110 is registered in V-PLMN130 and H-PLMN160 and that UE110 and V-PLMN130 mutually authenticate. If UE110 does not have a UICC/UIM or if there is no roaming agreement between V-PLMN130 and H-PLMN160, mutual authentication of V-PLMN130 and UE110 and secure transfer between them may not be achieved during SIP registration and SIP call setup and any PSK generated will provide more limited protection.

Method D is used for validation with Generic Bootstrap Architecture (GBA) described in 3GPP ts 33.220 or 3GPP2TSG-S draft s.p 0109. The UE110 and the E-SLP272 or E-PS282 support GBA. This enables the UE110 and the E-SLP272 or E-PS282 to obtain a secure common key from the H-PLMN 160. For SUPL, this key may be used to support PSK-TLS mutual authentication between UE110 and E-SLP272, as described in 3GPP TS 33.222 or 3GPP2TSG-S draft S.P0114. This method is used in SUPL1.0 to support the 3GPP proxy mode. The key may also be used to support TLS using HTTP digest authentication (e.g., as described in 3GPP TS 33.222), except HTTP digest authentication between UE110 and E-SLP272 (e.g., as described in 3GPP2TSG-S draft s.p 0114) or other forms of authentication. For x.s0024, this key may be used as the root key that may be used to derive the remaining security information.

Method D relies on supporting GBA and roaming agreements between V-PLMN130 and H-PLMN160 in H-PLMN160 and V-PLMN130 to enable key information to be passed from a Bootstrap Service Function (BSF) in H-PLMN160 to an E-SLP Network Application Function (NAF) in V-PLMN 130.

Method E is used for SUPL1.0 or x.s0024 authentication. For SUPL, if UE110 is in H-PLMN160, E-SLP272 may be an H-SLP and may use the existing authentication mechanism defined in SUPL 1.0. For x.s0024, if the UE110 is in the H-PLMN160, the E-PS282 may be an H-PS and may use the existing authentication mechanism defined in x.s0024.

Fig. 12 shows a block diagram of an embodiment of UE110, access network 120, E-CSCF254, and location server 286. The location server 286 may be the E-SLP272, the GMLC276, the E-PS282, and/or some other entity. For simplicity, fig. 12 shows only one processor 1210, one memory unit 1212, and one transceiver 1214 for UE 110; only one processor 1220, one memory unit 1222, one transceiver 1224, and one communication (Comm) unit 1226 for accessing network 120; only one processor 1230, one memory unit 1232 and one communication unit 1234 for E-CSCF 254; and only one processor 1240, one memory unit 1242 and one communication unit 1244 for the location server 286. In general, each entity may include any number of processors, memory units, transceivers, communication units, controllers, and the like.

On the downlink, base stations and/or access points in access network 120 transmit traffic data, signaling, and pilot to UEs within their coverage area. These various types of data are processed by processor 1220 and conditioned by transceiver 1224 to generate a downlink signal, which is transmitted via an antenna. At UE110, downlink signals from base stations and/or access points are received via the antennas, conditioned by transceivers 1214, and processed by a processor 1210 to obtain various types of information for positioning, VoIP, and other services. For example, processor 1210 may decode messages for the message streams described above. Memory units 1212 and 1222 store program codes and data for UE110 and access network 120, respectively. On the uplink, UE110 transmits traffic data, signaling, and pilot to base stations and/or access points in access network 120. These various types of data are processed by processor 1210 and conditioned by transceiver 1214 to generate an uplink signal, which is transmitted via the UE antenna. At access network 120, uplink signals from UE110 and other UEs are received and conditioned by transceiver 1224 and further processed by a processor 1220 to obtain various types of information (e.g., data, signaling, reports, etc.). Access network 120 communicates with E-CSCF254 and other entities via a communication unit 1226.

Within E-CSCF254, 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. Processor 1230 may perform processing for E-CSCF254 for the message flow described above.

Within location server 286, a processor 1240 performs location and/or position location processing for the location server, a memory unit 1242 stores program codes and data for the location server, and a communication unit 1244 allows the location server to communicate with other entities. Processor 1240 may perform processing for the location server for the message streams described above.

The techniques described herein may 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 units used to perform the techniques may be implemented within one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, electronic devices, other electronic units designed to perform the functions described herein, or a combination thereof.

For a firmware and/or software implementation, the techniques may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The firmware and/or software codes may be stored in a memory (e.g., memories 1212, 1222, 1232, and/or 1242 in fig. 12) and executed by a processor (e.g., processors 1210, 1220, 1230, and/or 1240). The memory may be implemented within the processor or external to the processor.

Headings are included herein for reference and to aid in locating particular sections. These headings are not intended to limit the scope of the concepts described below, and these concepts may have applicability in other sections throughout the entire specification.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (57)

1. A method for supporting an emergency voice over internet protocol call, comprising:

communicating with the accessed IP multimedia subsystem to send a request to establish an emergency voice over internet protocol call;

interacting with a location server indicated by the visited IP multimedia subsystem to obtain a first location estimate of the user equipment; and are

Performing call setup via the accessed IP multimedia subsystem to establish the emergency Voice over Internet protocol call with a public safety answering Point.

2. The method of claim 1, further comprising utilizing session initiation protocol for the emergency voice over internet protocol call.

3. The method of claim 2, further comprising sending a session initiation protocol SIP REGISTER for the emergency voice over internet protocol call to register with a home network.

4. The method of claim 2, further comprising sending a session initiation protocol SIP REGISTER for the emergency voice over internet protocol call to register with the visited IP multimedia subsystem.

5. The method of claim 4, wherein the session initiation protocol SIP REGISTER comprises an emergency private user identifier formed by a domain name and a pseudo international mobile subscriber identity of the visited IP multimedia subsystem.

6. The method of claim 4, further comprising receiving a response to the session initiation protocol SIP REGISTER with a temporary public user identifier.

7. The method of claim 2, further comprising sending a session initiation protocol SIP INVITE as the request to establish the emergency voice over internet protocol call.

8. The method of claim 7, further comprising sending location information for the user equipment in the session initiation protocol SIP INVITE, and wherein the first location estimate for the user equipment is obtained based on the location information.

9. The method of claim 1, further comprising sending positioning capabilities of the user equipment in the request to establish the emergency voice over internet protocol call, and wherein the location server is selected based on the positioning capabilities of the user equipment.

10. The method of claim 1, further comprising sending location information for the user equipment in the request to establish the emergency voice over internet protocol call, and wherein the location server is selected based on the location information.

11. The method of claim 1, wherein the first position estimate is an intermediate position estimate corresponding to a coarse position estimate for call routing.

12. The method of claim 1, wherein the first location estimate is an initial location estimate corresponding to an accurate location estimate of the user equipment.

13. The method of claim 1, further comprising:

receiving a request for an updated location estimate for the user equipment from the public safety answering point; and performing positioning with the location server to obtain the updated location estimate.

14. The method of claim 13, further comprising performing positioning with the location server according to a secure user plane location.

15. The method of claim 13, further comprising performing positioning with the location server according to 3GPP2 user plane location.

16. The method of claim 13, further comprising performing positioning with a radio access network according to 3GPP control plane location.

17. The method of claim 1, further comprising:

accessing a radio access network;

establishing IP connectivity with the visited IP multimedia subsystem via the radio access network; and discovering an IP address of a local server for the emergency voice over internet protocol call.

18. The method of claim 1, further comprising:

accessing a wireless local area network using a network access identifier indicating the accessed IP multimedia subsystem;

establishing IP connectivity with the accessed IP multimedia subsystem via the wireless local area network; and are

An IP address of a local server is discovered for the emergency voice over Internet protocol call.

19. The method of claim 1, further comprising performing authentication with the location server.

20. An apparatus supporting an emergency voice over internet protocol call, comprising:

means for communicating with the accessed IP multimedia subsystem to send a request to establish an emergency voice over internet protocol call;

means for interacting with a location server indicated by the visited IP multimedia subsystem to obtain a first location estimate of a user equipment; and

means for performing call setup via the accessed IP multimedia subsystem to establish the emergency voice over Internet protocol call with a public safety answering point.

21. The apparatus of claim 20, further comprising:

means for utilizing session initiation protocol for the emergency voice over internet protocol call.

22. The apparatus of claim 21, further comprising:

means for sending a session initiation protocol SIP REGISTER for the emergency voice over internet protocol call to register with a home network.

23. The apparatus of claim 21, further comprising:

means for sending a session initiation protocol SIP REGISTER for the emergency voice over internet protocol call to register with the visited IP multimedia subsystem.

24. The apparatus of claim 21, further comprising:

means for sending a session initiation protocol SIP INVITE as the request to establish the emergency voice over internet protocol call.

25. The apparatus of claim 20, further comprising:

means for receiving a request for an updated location estimate for the user equipment from the public safety answering point; and

means for performing positioning with the location server to obtain the updated location estimate.

26. A method for supporting an emergency voice over internet protocol call, comprising:

receiving a request to route an emergency voice over internet protocol call to a user equipment to a public safety answering point;

obtaining a first position estimate for the user equipment;

selecting the public safety answering point based on the first position estimate; and are

And sending a response by using the routing information of the public safety answering point.

27. The method of claim 26, further comprising interacting with the user equipment to obtain the first position estimate for the user equipment.

28. The method of claim 26, further comprising:

receiving location information of the user equipment in the request to route the emergency voice over internet protocol call;

determining a location server accessed based on the location information; and are

Interacting with the visited location server and the user equipment as a home location server to obtain the first location estimate of the user equipment.

29. The method of claim 26, further comprising sending a message to the user equipment to perform positioning to obtain the first position estimate.

30. The method of claim 29, further comprising using mobile terminal IP, UDP/IP, or IP multimedia

Subsystem signaling sends the message to the user equipment.

31. The method of claim 29, further comprising including an address of a location server in the message sent to the user equipment, the address used by the user equipment to perform positioning.

32. The method of claim 29, further comprising including an indication of emergency services in the message sent to the user equipment.

33. The method of claim 26, further comprising:

receiving a message initiating positioning from the user equipment, the message containing location information; and deriving the first position estimate for the user equipment based on the position information.

34. The method of claim 26, further comprising:

receiving a message from the user equipment initiating a positioning, the message containing location related measurements; and deriving the first position estimate for the user equipment based on the position-related measurements.

35. The method of claim 26, further comprising:

receiving a request for an updated location estimate for the user equipment from the public safety answering point;

performing positioning with the user equipment to obtain the updated position estimate; and are

Sending the updated position estimate to the public safety answering point.

36. The method of claim 26, further comprising receiving the first position estimate of the user equipment from a general packet radio service support node.

37. The method of claim 26, further comprising:

receiving a request for an updated location estimate for the user equipment from the public safety answering point;

forwarding the request to an IP gateway;

receiving the updated location estimate from the IP gateway; and are

Sending the updated position estimate to the public safety answering point.

38. The method of claim 26, further comprising performing authentication with the user equipment.

39. An apparatus supporting an emergency voice over internet protocol call, comprising:

means for receiving a request to route an emergency voice over internet protocol call to a user equipment to a public safety answering point;

means for obtaining a first position estimate for the user equipment;

means for selecting the public safety answering point based on the first position estimate; and

means for sending a response with the routing information of the public safety answering point.

40. The apparatus of claim 39, further comprising means for sending a message to the user equipment to perform positioning to obtain the first position estimate.

41. The apparatus of claim 40, further comprising:

means for sending the message to the user equipment using mobile terminal IP, UDP/IP or IP multimedia subsystem signalling.

42. The apparatus of claim 39, further comprising:

means for receiving a request for an updated location estimate for the user equipment from the public safety answering point;

means for performing positioning with the user equipment to obtain the updated position estimate; and

means for sending the updated position estimate to the public safety answering point.

43. A method for supporting an emergency voice over internet protocol call, comprising:

accessing a 3GPP2 access network by using user equipment;

sending a request to a 3GPP2 core network to establish an emergency voice over internet protocol call;

performing registration with a home network;

interacting with a location server to obtain a first location estimate for the user equipment; and are

Performing call setup via the 3GPP2 core network to establish the emergency voice over Internet protocol call with a public safety answering point, the public safety answering point selected based on the first location estimate.

44. The method of claim 43, further comprising performing positioning with the location server according to secure user plane location, 3GPP2 user plane, or 3GPP2 control plane location.

45. The method of claim 43, further comprising:

receiving a request for an updated location estimate for the user equipment from the public safety answering point;

performing positioning with a location server to obtain the updated location estimate; and are

Sending the updated position estimate to the public safety answering point.

46. An apparatus supporting an emergency voice over internet protocol call, comprising:

means for accessing a 3GPP2 access network with a user equipment;

means for sending a request to a 3GPP2 core network to establish an emergency voice over internet protocol call;

means for performing a registration with a home network;

means for interacting with a location server to obtain a first location estimate for the user equipment; and

means for performing call setup via the 3GPP2 core network to establish the emergency voice over Internet protocol call with a public safety answering point selected based on the first position estimate.

47. The apparatus of claim 46, further comprising:

means for receiving a request for an updated location estimate for the user equipment from the public safety answering point;

means for performing positioning with a location server to obtain the updated location estimate; and

means for sending the updated position estimate to the public safety answering point.

48. A method for supporting an emergency voice over internet protocol call, comprising:

communicating with a first accessed IP multimedia subsystem to send a request to establish an emergency voice over internet protocol call;

and are

Communicating with a second visited IP multimedia subsystem selected by the first visited IP multimedia subsystem for the emergency voice over Internet protocol call.

49. The method of claim 48, further comprising:

receiving from the first visited IP multimedia subsystem an identification of a session initiation protocol in the second visited IP multimedia subsystem; and are

Performing call setup with the session initiation protocol server to establish the emergency voice over internet protocol call with the second accessed IP multimedia subsystem.

50. The method of claim 48, wherein the emergency voice over Internet protocol call is forwarded from the first accessed IP multimedia subsystem to the second accessed IP multimedia subsystem.

51. The method of claim 48, wherein the emergency voice over Internet protocol call is routed to a public safety answering point based on a Location Routing Number (LRN).

52. A method for supporting an emergency voice over internet protocol call, comprising:

communicating with the accessed IP multimedia subsystem to send a request to establish an emergency voice over internet protocol call;

performing authentication of a location server selected by the visited IP multimedia subsystem for the emergency voice over Internet protocol call; and are

Interacting with the location server for the emergency voice over internet protocol call to obtain at least one location estimate for a user equipment.

53. The method of claim 52, further comprising:

receiving a message from the location server initiating location processing; and are

Authenticating the location server when the message indicates location handling of an emergency call and the user equipment is engaged in the emergency voice over internet protocol call.

54. The method of claim 52, further comprising performing transport layer security public key authentication using a root public key certificate stored at the user equipment to verify a public key of the location server.

55. The method of claim 52, further comprising:

generating a pre-shared key based on security information available at the user equipment and the accessed IP multimedia subsystem; and are

Performing authentication using the pre-shared key.

56. The method of claim 52, further comprising performing authentication based on a generic bootstrap architecture.

57. The method of claim 52, further comprising performing authentication according to a secure user plane location release 1.0 or 3GPP2 user plane.