JP2014131313A - Voip emergency call support - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide techniques of supporting emergency voice-over-Internet Protocol (VoIP) calls, which may be 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 interacts with a location server instructed by the visited network to obtain a first position estimate for the UE. The UE performs call setup via the visited network to establish the emergency VoIP call with a PSAP (public safety answering point) 180, which may be selected based on the first position estimate. The UE thereafter performs positioning with the location server to obtain an updated position estimate for the UE, e.g., if requested by the PSAP.

Description

Related applications

  This application is a provisional US application No. 60 / 704,977, August 30, 2005 entitled “VOICE-OVER INTERNET PROTOCOL EMERGENCY CALL SUPPORT” filed on August 2, 2005. Provisional US Application No. 60 / 713,199 entitled “VOIP EMERGENCY CALL SUPPORT”, filed October 13, 2005, and “VOIP EMERGENCY CALL SUPPORT” Provisional US Application No. 60 / 726,694, provisional US Application No. 60 / 732,226, entitled “VOIP EMERGENCY CALL SUPPORT”, filed October 31, 2005, and 2005 Provisional US application number 60 / entitled “SUPPORT FOR EMERGENCY VoIP CALLS USING SUPL” filed on Dec. 9 No. 748,821 is claimed and all is assigned to this assignee and is incorporated herein by reference.

Field of Invention

  The present disclosure relates generally to communications, and more particularly to techniques that support emergency calls.

Background of the Invention

  Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, message communication, broadcasting, and so on. These wireless networks are multiple access networks that can support communication for a large number of users by sharing 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 generally support communication for wireless users who have service reservations with these networks. Service reservations relate to information about safety, routing, quality of service (QoS), billing, and so on. The reservation related information is used to establish calls with the wireless network.

  One of the most basic services provided by the wireless network for its users is the ability to send and receive voice calls. One recent enhancement of this service is the ability to send and receive voice protocol (VoIP) calls over the Internet. A VoIP call is a voice call in which voice data is sent in packets that are routed like other packet data instead of a dedicated traffic channel.

  A wireless user makes an emergency voice or other media call over the wireless network, whether or not the home network that the user has subscribed to for service. Such a call uses VoIP. The main challenge is to send an emergency call to an appropriate Public Safety Answering Point (PSAP) that can provide the call. This requires obtaining a provisional position estimate for the user and determining an appropriate PSAP based on the provisional position estimate. The problem is complicated if the user is roaming and / or has not made any service reservations with the network.

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

  Techniques for supporting Voice-over-Internet Protocol (VoIP) calls on an emergency Internet are described herein. The technology is used for various 3GPP and 3GPP2 networks, various location architectures, and user equipment (UE) with and without service reservations.

  In an embodiment, the UE communicates via a visited network to send a request to establish an emergency VoIP call. The UE contacts a location server that is instructed by the visited network to obtain an initial location estimate for the UE. The UE performs call setup via the visited network to establish an emergency VoIP call via PSAP, which is selected based on the initial location estimate. Thereafter, the UE performs positioning by the location selection server to obtain an updated location estimate for the UE, for example, if requested by the PSAP. Various details of emergency VoIP calls are described below.

  Various aspects and embodiments of the disclosure are also described in further detail below.

  The disclosed forms and examples will become more apparent from the following detailed description, taken in conjunction with the drawings in which like reference characters correspond correspondingly throughout.

Fig. 4 illustrates an arrangement for supporting emergency VoIP requests. 3 shows a 3GPP network architecture. 3 shows a 3GPP network architecture. Fig. 4 shows the network architecture and message flow for emergency VoIP calls with SUPL location. Fig. 4 shows the network architecture and message flow for emergency VoIP calls with SUPL location. Fig. 4 shows the network architecture and message flow for emergency VoIP calls with 3GPP control plane location. Fig. 4 shows the network architecture and message flow for emergency VoIP calls with 3GPP control plane location. X. Fig. 5 shows the network architecture and message flow for emergency VoIP calls with S0024 location. X. Fig. 5 shows the network architecture and message flow for emergency VoIP calls with S0024 location. Fig. 4 shows the network architecture and message flow for emergency VoIP calls for UEs without service reservation. Fig. 4 shows the network architecture and message flow for emergency VoIP calls for UEs without service reservation. The block diagram of some real machines in FIGS. 1-3 is shown.

  The term “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.

  Techniques for supporting emergency VoIP requests are described herein. An emergency VoIP call is a VoIP call or packet switched call for emergency services. As described below, emergency VoIP calls are identified as such and are distinguished from normal VoIP calls in several ways. Emergency VoIP calls are different from normal VoIP calls and are associated with various features, such as obtaining an appropriate location estimate for the user and routing the emergency VoIP call to the appropriate emergency VoIP call. Position estimation is also called location estimation, position determination, etc.

  FIG. 1 shows an arrangement 100 that supports emergency VoIP requests. User equipment (UE) 110 communicates via access network 120 to obtain basic IP communication services. UE 110 may be stationary or mobile and may also be referred to as a mobile station (MS), terminal, subscriber station, station, or some other terminology. UE 110 is a cellular phone, personal digital assistant (PDA), wireless device, laptop computer, telemetry device, tracking device, and the like. UE 110 communicates with one or more base stations and / or one or more access points in an access network. UE 110 also receives signals from one or more satellites 190. These satellites are part of the Global Positioning System (GPS), the European Galileo system, the Russian Glonas system, or any Global Navigation Satellite System (GNSS). UE 110 measures signals from base stations and / or signals from satellites 190 in access network 120 and obtains pseudorange measurements for satellites and / or timing measurements for base stations. Pseudo-range measurements and / or timing measurements are aided GPS (AGPS), single GPS, advanced forward link three-sided measurement (A-FLT), enhanced observation time difference (E-OTD), arrival observation time difference (OTDOA), enhanced Used to obtain a location estimate for UE 110 using one or a combination of positioning methods well known in the art such as cell ID, etc.

  Access network 120 provides wireless communication for UEs located within the coverage area of the access network. As described below, the access network 120 includes a base station network controller and / or other entities. The visited network 130 is also called a visited public land mobile network (V-PLMN), and is a network currently serving UE 110. The home network 160 is also called a home PLMN (H-PLMN) and is a network that the UE 110 has reserved. Access network 120 is associated with visited network 130. Visited network 130 and home network 160 are also the same or different networks. The visited network 130 and the home network 160 may or may not have a roaming agreement. Networks 130 and 160 each include entities that provide data connectivity, location services, and / or other functions and services.

  The network 170 includes a public switched telephone network (PSTN), the Internet, and / or other voice and data networks. PSTN supports communication for traditional simple old telephone service (POTS). PSAP 180 is the entity responsible for answering emergency calls (eg, for police, fire, and medical services), and is also referred to as the Emergency Center (EC). Such a call is initiated when the user dials some known fixed number, such as 911 in North America or 112 in Europe. PSAP 180 is generally managed or owned by a government agency, such as a county or city. PSAP 180 supports IP connections for VoIP calls and thus supports Session Initiation Protocol (SIP), which initiates and modifies interactive user sessions based on IP such as VoIP, and It is a signal communication protocol for termination. Alternatively or in addition, PSAP 180 supports communication by PSTN 170.

  The techniques described here include emergency VoIP calls originating from wired networks such as DSL and cable, and wireless wide area network (WWAN), wireless local area network (WLAN), wireless metropolitan area network (WMAN), and WWAN Used for emergency VoIP calls originating from wireless networks with WLAN coverage. A CDMA network implements one or more radio technologies such as Wideband CDMA (W-CDMA), cdma2000. cdma2000 covers IS-2000, IS-856, and IS-95, and includes an Ev-DO revision to optimize IP support. A TDMA network implements one or more radio technologies such as the Pan-European Digital Cellular System (GSM), Advanced Digital Mobile Phone System (D-AMPS), and so on. D-AMPS covers IS-248 and IS-54. W-CDMA and GSM are described in documents from an organization named 3rd Generation Joint Project (3GPP). cdma2000 is described in documents from an organization named “3rd Generation Joint Project 2” (3GPP2). 3GPP and 3GPP2 documents are publicly available. WLAN implements wireless technologies such as IEEE 802.11. WMAN implements 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. UE 110 gains radio access via 3GPP access network 120a or WLAN access network 120b. The 3GPP access network 120a is 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 33GPP 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. Base station is also referred to as Node B, Enhanced Node B (e-Node B), Base Transceiver Station (BTS), Access Point (AP), or some other terminology. WLAN 120b includes an access point 214 and is any WLAN.

  V-PLMN is one embodiment of visited network 130 in FIG. 1, and includes V-PLMN core network 230a and V-PLMN location entity 270a. The V-PLMN core network 230a includes a service 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. SGSN 232a and GGSN 232b are part of the General Packet Radio Service (GPRS) core network and provide packet switched services for UEs communicating by 3GPP access network 120a. WAG 234 and PDG 236 are part of a 3GPP interworking WLAN (I-WLAN) core network and provide packet switched services for UEs communicating by WLAN 120b.

  The V-PLMN core network 230a includes a home subscriber server (HSS) 250, and a proxy call session control function (P-CSCF) 252, an emergency CSCF (E-CSCF) 254, an inquiry CSCF (I-CSCF) 256 , And various IP Multimedia Subsystem (IMS) entities including Media Gateway Control Function (MGCF) 258. P-CSCF 252, E-CSCF 254, I-CSCF 256 and MGCF 258 support IMS services, eg, VoIP calls, and are part of the V-PLMNIMS network. The P-CSCF 252 accepts requests from the UE and internally services these requests or sends the requests to other entities, possibly translated. E-CSCF 254 provides session control services for the UE and maintains the session state used to support IMS emergency services. E-CSCF 254 further supports emergency VoIP calls. MGCF 258 directs signaling conversion between SIP / IP and PSTN (eg, SS7 ISUP) and is used whenever a VoIP call from one user goes to the PSTN user. HSS 250 stores reservation related information for UEs where V-PLMN 130a is the home network.

  V-PLMN location entity 270a includes emergency service SUPL location platform (E-SLP) 272 and visited SLP (V-SLP) 274, which supports OMA Secure User Plane Location (SUPL) To do. V-SLP 274 is in a separate network or associated with V-PLMN 130a and / or is geographically closer to UE 110. Alternatively or on top of it, the V-PLMN location entity 270a includes a Gateway Mobile Location Center (GMLC) 276, which is part of the 3GPP control plane location. E-SLP 272, V-SLP 274 and GMLC 276 provide location services for UEs communicating by V-PLMN 130a.

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

  FIG. 3 shows a 3GPP2 network architecture. UE 110 gains radio access via 3GPP2 access network 120c or WLAN access network 120d. The 3GPP2 access network 120c is a CDMA20001X network, a CDMA2000 1 × EV-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. RRC is also called a radio network controller (RNC) or base station. The 3GPP2 access network 120c is also referred to as a radio access network (RAN). WLAN 120d is any WLAN that includes an access point 224 and is associated with a 3GPP2 network.

  V-PLMN 130b is another embodiment of visited network 130 in FIG. 1, and includes V-PLMN core network 230b and 3GPP2 location entity 270b. The V-PLMN core network 230b includes a packet data service node (PDSN) 242, a packet data interworking function (PDIF) 244, and an authentication, authorization and accounting (AAA) server 246. PDSN 242 and PDIF 244 provide packet switched services for UEs communicating by 3GPP2 access network 120c and WLAN 120d, respectively. V-PLMN core network 230b also includes IMS or multimedia domain (MMD) entities such as P-CSCF 252, E-CSCF 254, I-CSCF 256, and MGCF 258. E-CSCF 254 also has other names such as ES-AM (Emergency Service Application Manager).

  3GPP2 location entity 270b includes E-SLP 272 and V-SLP 274 for SUPL. Alternatively or in addition, the 3GPP2 location entity 270b includes an emergency service location server (E-PS) 282 and a visited location server (V-PS) / positioning entity (PDE) 284, which are part of the cdma2000 network. X. S0024 is a part of position selection. E-PS 282 is also referred to as a proxy location server (S-PS). E-SLP 272, V-SLP 274, E-PS 282, and V-PS / PDE 284 provide location services for UEs communicating by V-PLMN 180b.

  For simplicity, FIGS. 2 and 3 show only some entities in 3GPP and 3GPP2, which are referenced in the description below. 3GPP and 3GPP2 networks include other entities defined by 3GPP and 3GPP2.

  In the following description, a 3GPP network is defined by 3GPP as well as other networks and network subsystems (eg, WLAN) that operate with the 3GPP network (eg, access network subsystem). Say. 3GPP networks and network subsystems include GERAN, UTRAN, EUTRAN, GPRS core network, IMS network, 3GPP I-WRAN, and so on. A 3GPP2 network refers to a network and network subsystem defined by 3GPP2 as well as other networks and network subsystems that operate with the 3GPP2 network. 3GPP2 networks include CDMA2000 1X, CDMA2000 1 × EV-DO, cdma2000 core network, 3GPP2 IMS or MMD network subsystem, 3GPP2-related WRAN, and so on. For simplicity, “3GPP WRAN” refers to the WRAN associated with the 3GPP network, and “3GPP2 WRAN” refers to the WRAN associated with the 3GPP2 network.

  In the following description, GPRS access refers to access to the GPRS core network via GERAN, UTRAN, or some other 3GPP access network. 3GPP WLAN access refers to access to the 3GPP core network via the WLAN. cdma2000 access refers to access to the cdma2000 core network via CDMA2000 1X, CDMA2000 1 × EV-DO, or some other 3GPP access network. 3GPP2 WLAN access refers to access to a 3GPP2 WLAN core network via a WLAN.

  For 3GPP, UE 110 may or may not be equipped with a universal integrated circuit card (UICC). For 3GPP2, UE 110 may or may not be equipped with a user identification module (UIM). The UICC or UIM is generally specific to one subscriber and stores personal information, reservation information and / or other information. A UE without a UICC is a UE without a UICC, and a UE without a UIM is a UE without a UIM. A UICC / UIM-less UE does not have all of the reservation, home network, and authentication credentials (eg, secret key) to prove any required identity, which tends to make location services even more dangerous. is there.

  The techniques described here are used for various location architectures such as control plane and user plane architectures. The control plane (also referred to as the signaling plane) is a mechanism that performs signaling for higher layer applications and is typically implemented by network specific protocols, interfaces, and signaling messages. The user plane is a mechanism that performs signal communication for higher layer applications, but it is a mechanism that uses a user-plane bearer, which is generally a user datagram protocol (UDP), a transmission control protocol. Implemented by protocols such as (TCP) and Internet Protocol (IP), all of which are known in the art. Message assisted location services and positioning are performed as part of signal communication in the control plane architecture and as part of data (from the network view) in the user plane architecture. However, the message content is the same or similar in both architectures.

These techniques are used for various location architectures / solutions such as those described in Table 1. SUPL and prognostic SUPL are described in documents 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 IS-881 and 3GPP2 X. It is described in S0002. The 3GPP2 user plane is 3GPP2 X. S0024.

  The UE supports zero, one or many solutions (eg, SUPL, or 3GPP control plane, or SUPL and 3GPP control plane, or SUPL and X.S0024) for emergency VoIP calls. When a call is made, for example, in a SIP INVITE and / or SIP REGISTER message, the UE notifies its potential location network. This information is stored in a local server (eg, a location selection server) for network retrieval.

  The technology described here supports the following features: (A) Support emergency VoIP calls for mobile, fixed and mobile users. (B) Applicable to VoIP calls using GPRS access, 3GPP WLAN access, cdma2000 access, and 3GPP2 WLAN access. (C) Support end-to-end connection to SIP / IP capable PSAP. (D) For example, when a VoIP service provider is far away from the UE, it supports connection to a PSTN capable PSAP that is close to the calling UE but geographically far from the SIP call server. (E) Support call routing to the appropriate PSAP using provisional location estimation. (F) Providing accurate location of the UE to the PSAP. (G) Support for initial and updated location using various location architectures. (H) Support emergency VoIP calls from UEs without UICC / UIM and UEs whose H-PLMN does not have a roaming agreement with V-PLMN. (I) Support call back from PSAP to UE without UICC / UIM and / or without roaming agreement in V-PLMN. (J) Known as IETF Ecrit solution and also as NENA 12 solution, compatible with NENA I2 solution such as provisional VoIP architecture for enhanced 9-1-1 service (i2). (K) Less impact and demand on H-PLMN.

  PSAP callback refers to the call returning from the PSAP to the UA because the emergency call disappears or is released too soon. Provisional location estimates generally refer to the approximate location used for routing, and the initial location estimate generally refers to the first accurate location estimate. In some cases, the initial position estimate is obtained after the provisional position estimate. In other cases, the provisional and initial position estimates are the same. In still other cases, provisional position estimates and / or initial position estimates are not used.

  For SUPL, the home SLP at H-PLMN 160 (H-SLP) is bypassed and one or more V-SLP and / or E-SLP at or associated with V-PLMN 130 is used for location. The X. For S0024, the home PS (H-PS) at H-PLMN 160 is bypassed and one or more V-PS and / or E-PS at or associated with V-PLMN 130 is used for location. The This is the case with SUPL and X. Meaning some changes to S0024, for example, SLP or H-PS configured at UE 110 is disabled for location during emergency calls. The use of V-SLP, E-SLP, E-PS or V-PS in V-PLMN 130 is desirable for the following reasons: (a) Special emergency call support in a specific region or region is not available in other networks Rather, the support from the network in those areas must be used. (B) UE without UICC / UIM does not have H-PLMN and depends on SLP or PS in V-PLMN. (C) For UEs with UICC / UIM, the H-PLMN has no roaming agreement with the V-PLMN and it is difficult to use H-SLP or H-PS. (D) H-SLP or H-PS does not support location requests from remote PSAPs (eg, in another region) due to signaling differences and lack of registration. (E) The H-SLP or H-PS cannot obtain a good location estimate without the help of SLP or PS in the V-PLMN (eg if the H-SLP or H-PS is far away from the UE) . (F) H-SLP or H-PS does not support the interface (eg, Li or LCSi interface) used by E-SLP or E-PS that supports emergency call service.

  E-SLP 272 or E-PS 282 are SUPL and X. In each S0024, positioning for the UE 110 is performed. Instead, V-SLP, V-PS, or PDE is selected to perform positioning for UE 110 if, for example, E-SLP 272 or E-PS 282 cannot perform this function. The V-SLP, V-PS, or PDE may, for example, select an E-SLP or E-PS where the SIP call server (eg, E-CSCF 254) is far from the UE 110 and is also far away. This is useful (which occurs when a worker uses a small number of call servers to service a large area or an entire province). E-SLP 272 or E-PS 282 selects the appropriate V-SLP, V-PS, or PDE using any of the following mechanisms: (a) UE 110 is attached to the access network or IP When establishing a connection, for example, when the access network provides a V-SLP or V-PS address to the UE 110, it finds the IP address or the name of the V-SLP or V-PS. After the UE 110 establishes the IP connection, it finds the V-SLP or V-PS address by DNS query. This is applicable if the DNS server used by UE 110 is closer to UE 110 than E-CSCF 254. UE 110 includes the V-SLP or V-PS address in the first SIP REGISTER sent to the IMS and in any subsequent re-REGISTER after taking over to the new access network. The IMS (eg, E-CSCF 254) forwards the V-SLP or V-PS address to E-SLP 272 or E-PS 282. (B) E-SLP 272 or E-PS 282 determines the V-SLP or V-PS address based on the location information provided by UE 110 in the first SIP INVITE. (C) E-SLP 272 or E-PS 282 determines the V-SLP or V-PS address based on the location selection information received from UE 110 at the SUPL START.

  In general, the location information provided by UE 110 is any information used to determine the location of UE 110. Location information includes geographical coordinates, GSM, UMTS, or cdma2000 cell identifier (ID), cdma2000 service cell information, WLAN access name identifier, WLAN MAC address, and the like. The location information also includes measurements used to determine the location of UE 110.

  SUPL and X.M. For S0024, E-SLP 272 or E-PS 282 sends a SUPL INIT to UE 110 to initiate a SUPL session. SUPL INIT is sent using WAP Push or SMS, which introduces a long delay. In an embodiment, in order to reduce delay, SUPL INIT uses IMS immediate messages, some other IMS messages, SIP 1xx responses (eg, 183 session advance), or other messages using IMS (eg, P -Sent to UE 110 via CSCF 252 and E-CSCF 254). The use of an existing (possibly secure) relationship between the IMS and the UE 110 allows for fast forwarding and / or establishes a new relationship and / or forwards messages through additional entities (eg, SMS service center) In order to avoid this, the delay is further avoided. This embodiment is also used when the UE 110 is not registered with the HPLMN, for example when it does not have a UICC or UIM. In another embodiment, SUPL INIT is sent to UE 110 using mobile termination IP or UDP / IP to reduce delay. In this case, the IP gateway serving the UE 110 (eg, GGSN 232b, PDG 236, PDSN 242 or PDIF 244) does not filter out IP packets from the E-SLP 272 to the UE 110 so that the E-SLP 272 Are pre-managed by the IP address. UE 110 is configured to support the TCP and / or UDP ports used for SUPL (and registered by IANA) for receipt of SUPL INIT.

  Emergency VoIP calls are made as follows: SUPL 1.0 and X. Supported by the first edition of S0024 (3GPP2 X.S0024-0). (A) If UE 110 is in H-PLMN 160, E-SLP 272 is H-SLP, or E-PS 282 is H-PS for the UE, and SUPL 1.0 or X. S0024-0 Initiates a network location request. The SUPL INIT is sent to UE 110 using SMS or WAP Push. (B) If the UE 110 is not in the H-PLMN 160 but is registered in the V-PLMN 130, the E-SLP 272 will follow the procedure in SUPL 1.0 and OMA RLP as a request SLP (R-SLP) Work and trigger a SUPL 1.0 location request by sending a location request for the UE 110 to the H-SLP. Similarly, the E-PS 282 uses the OMA RLP protocol for the UE 110 from the H-PS to the X. S0024 Trigger location selection request. (C) if UE 110 is not in H-PLMN 160 and is not registered in V-PLMN 130 (eg, there is no roaming agreement between V-PLMN 130 and H-PLMN 160), or If the UE 110 does not have a UICC or UIM, then SUPL 1.0 or X. S0024-0 location selection is not supported. However, E-SLP 272 or E-PS 282 may obtain location estimates for UE 110 using the location information provided by UE 110 in the initial SIP INVITE for emergency calls.

1. Emergency VoIP Call with SUPL FIG. 4 shows a block diagram of an embodiment of a network architecture 400 for emergency VoIP call with SUPL location. Network architecture 400 is applicable to both 3GPP and 3GPP2 networks. For simplicity, only the entities and interfaces related to supporting emergency VoIP calls using SUPL are shown.

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

  E-SLP 272 includes a SUPL location center (E-SLC) that performs various functions for location services, and a SUPL location center (E-SPC) that assists in positioning for UE 110. V-SLP 274 includes V-SLC 422 and V-SPC 424 as well. E-SLP 272 replaces H-SLP in H-PLMN 160 in the case of location selection for emergency calls. The entity in SUPL is a document OMA-AD-SUPL-V2_0-2006060704-D (July 4, 2006) entitled "Secure User Plane Location Architecture" draft 4.0, and " It is described in the document OMA-TS-ULP-V2_0-200607721-D (July 21, 2006) entitled “User Plane Location Protocol” draft 2.0, which is publicly available from OMA. Is available.

  SUPL supports two communication modes between SET and SLP for positioning by SPC. In 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 non-proxy mode, the SPC has direct communication with the SET.

  The PSTN / Internet 170 includes an entity (eg, a router) that supports a packet routing and selection router (S / R) 292 that sends emergency calls to the PSAP. S / R 292 belongs to PSAP 180 or is shared and connected by a set of individual PSAPs. If PSAP 180 supports SIP, UE 110 communicates with PSAP 180 via P-CSCF 252 and E-CSCF 254 for VoIP calls. If PSAP 180 does not support SIP, UE 110 also communicates with PSAP 180 via P-CSCF 252, E-CSCF 254, MGCF 258, and S / R 292. In this case, the media gateway (MGW) controlled by MGCF 258 performs VoIP for PCM circuit mode conversion for emergency calls.

  FIG. 4 shows the interface between the various entities. The call relation interface between UE 110, P-CSCF 252, E-CSCF 254, and MGCF 258 is SIP. The call related interface between MGCF 258, S / R 292, and PSAP 180 is MF / ISUP. The location relationship interface between PSAP 180 and E-SLP 272 is an E2 interface defined in JSTD036 revision B if PSAP 180 has PSTN capability, and an extended E2 interface if PSAP 180 has SIP capability. is there. The location relationship interface between PSAP 180 and E-SLP 272 is instead an MLP interface defined in an OMA or LIF mobile location protocol or some other interface, eg, an HTTP interface. The location relationship interface between UE 110 and V-SLP 274 and E-SLP 272 is SUPL ULP.

  The interface between E-CSCF 254 and E-SLP 272 carries information about UE 110 to E-SLP 272 and is used to facilitate SUPL positioning. This interface is an LCS IMS (eg, Li) interface and utilizes IMS Location Protocol (ILP) or other protocols. The Li / ELP interface is similar to the OMA roaming location protocol (RLP) interface between SLPs. The Li / ILP interface is used by any IMS entity (eg, S-CSCF or application server) and E-SLP 272 to support other features associated with IMS and IP compliant services such as: (A) Location-dependent billing for VoIP or other IP-compliant calls, (b) Providing location of one caller during a call to one or more parties, and (c) Additional services based on user location For example, location dependent call transfer, location dependent call constraints.

  The interface between E-SLP 272 and E-CSCF 254 is also “Draft NENA Standards for VoIP / Packet Migration i2 Solutions” or “Enhanced 9-1-1 Service ( v2 interface defined in Interim VoIP Architecture for Enhanced 9-1-1 Services (i2) (hereinafter referred to as “NENA I2 Solution”) for i2), the latter being E911 support in the US or other Several interfaces are considered.

  The network architecture 400 includes elements described in VoIP and / or other entities that support location, such as the NENA I2 solution or the NENA I2.5 and I3 solution drafts.

1.1 Call Setup FIG. 5 shows an example of a message flow 500 for emergency VoIP call setup using SUPL. For clarity, less relevant entities (eg, access network 120, P-CSCF 252 and S / R 292) are omitted from FIG. 5, but are included in the following description. Message flow 500 is used for 3GPP and 3GPP2 networks. Message flow 500 assumes that UE 110 has a UICC or UIM and that there is a roaming agreement between H-PLMN 160 and V-PLMN 130.

  In step 1, UE 110 finds an access network (AN), eg, 3GPP access network, 3GPP2 access network, 802.11 WLAN, etc. UE 110 makes any low-level connection (eg, 802.11 related) and attaches to the access network (eg, via GPRS attachment or 3GPP WLAN AAA procedures). UE 110 establishes an IP connection and finds a local SIP server address. In the following description, P-CSCF 252 is a local SIP server found by UE 110. Step 1 is performed differently for other networks and is described in further detail below.

  In step 2, UE 110 sends a SIP REGISTR to P-CSCF 252 (which is the local SIP server found in step 1). SIP REGISTR is an emergency service indication, an emergency public user ID (such as described in 3GPP TR23.867 and 3GPP TR23.167), a private user ID, an H-PLMN domain name, and step 1 Contains the obtained UE IP address. The SIP REGISTR also includes location information for UE 110, location capability of UE 110, and / or other information. UE location capabilities include UE assisted location solutions (eg, SUPL, 3GPP control plane, X.S0024, etc.), UE assisted positioning methods and / or other information. Due to the presence of an emergency service indication or emergency public user ID, the P-CSCF 252 sends a SIP REGISTR to the E-CSCF 254 over the same network as in the non-emergency case and not to the I-CSCF 262 in the H-PLMN 160.

  In step 3, E-CSCF 254 in V-PLMN 130 sends a SIP REGISTR to S-CSCF 264 in H-PLMN 160 where normal IMS registration occurs. The reason for registering with H-PLMN 160 is that if PSAP 180 later calls UE 110 back through H-PLMN 160, special treatment (eg, priority, restrictions on additional services) will apply. (1) to authenticate the user identifier, (2) to obtain a certified call back number from the S-CSCF 264, and (3) to alert the H-PLMN 160 for emergency calls. For IMS registration, the S-CSCF 264 in the H-PLMN 160 treats the E-CSCF 264 in the V-PLMN 130 like a P-CSCF. Public user TEL URI (eg, obtained from MSISDN in 3GPP or MIN in 3GPP2) is implicitly registered by the emergency public user ID for UE 110 and is used for PSAP callback from PSTN. For example, if the UE 110 has already registered a normal public user ID, or if the emergency public user ID is not supported by the H-PLMN 160, the H-PLMN 160 will add a registration of the emergency public user ID. Do not support. The E-CSCF 264 maintains a list of H-PLMNs where step 3 is omitted. If step 3 is omitted, call back from PSAP 180 is still possible using the normal public user ID of UE 110, which must be registered separately by UE 110. E-CSCF 254 assigns a temporary public user ID to UE 110, as described below, to allow call back directly from PSAP 180 via V-PLMN 130 instead of H-PLMN 160. . This temporary public user ID is particularly useful for foreign roaming UEs because both call back delay and reliability are improved. If registration at the H-PLMN 160 is not performed, the UE 110 is not authenticated and a secure IP connection between the UE 110 and the E-CSCF 254 at the V-PLMN 130 is not established, which is the E-SLP Reduces the security for the next location of UE 110.

  In step 4, E-CSCF 254 returns 200 OK to UE 110 (eg, after receiving SIP 200 OK from H-PLMN 160). Following emergency call setup, UE 110 may have another SGSN (for GPRS access), another WLAN (for WLAN access), or another PCF (for cdma2000 access) in the same V-PLMN. Or, if handed over to PDSN, UE 110 re-registers by repeating steps 2-4 to update location and V-SLP information. If UE 110 re-registers using its emergency public user ID, E-CSCF 254 forwards any new location information to E-SLP 272. If UE 110 has moved from a region supported by the previous V-SLP, re-registration allows the selection of another V-SLP.

  For 3GPP2 WLAN access, if the UE 110 moves from one WLAN to another WLAN or from the WLAN to the cdma2000 network, a handoff procedure is performed. The delivery procedure continues using the IP address associated with the previous PDIF and to avoid confusion with emergency VoIP calls (for delivery from one WLAN to another WLAN) or from a WLAN (from a WLAN) Establish a tunnel from the new PSDN to the previous PIDF (for delivery to the cdma2000 network). For delivery from the cdma2000 network to the WLAN, the PIDF associated with the new WLAN emulates the target PDSM to support delivery of fast handoff to the previous service PDSN. Following delivery, UE 110 re-registers to provide E-CSCF 254 with new location information relevant for V-SLP selection.

  In an alternative embodiment of steps 2, 3 and 4, after UE 110 sends a SIP REGISTER to P-CSCF 252 in step 2, P-CSCF 252 sends a SIP REGISTER directly to S-CSCF 264 in H-PLMN 160, Or send to I-CSCF 262 at H-PLMN 160 and bypass E-CSCF 254 at V-PLMN 130. In this case, the SIP 200 OK from H-PLMN 160 will be returned to P-CSCF 252 rather than to E-CSCF 254, and P-CSCF 252 will return 200 OK to UE 110 in step 4. . This alternative embodiment reduces or avoids the special impact on the P-CSCF 252 to support VoIP emergency calls, because the operation of the P-CSCF 252 is similar to that for normal registration.

  In step 5, UE 110 sends a SIP INVITE to P-CSCF 252. SIP INVITE includes an emergency call (eg, sos @ local-domain or “911” proposed by IETF Ecrit) and a global SIP URL or TEL URI indicating the type of emergency service requested. SIP INVITE also provides information on UE location available to UE 110 (eg, GPRS or cdma2000 cell ID, WLAN AP MAC address, etc.), otherwise UE 110 location provided during registration. Includes capabilities, contact information for callbacks, and / or other information. The callback information includes a TEL URI (eg, obtained from 3GPP MSISDN or 3GPP2 MDN) and possibly a SIP URL (eg, emergency public user ID used in step 2). The SIP REGISTER or SIP INVITE “supported” header field is also used to carry UE location capabilities. Location capabilities are also included as part of the location information provided by the UE (eg, in an IETF Geopriv pidf-lo object) or in several other ways in SIP INVITE. P-CSCF 252 sends a SIP INVITE to another SIP server, which (SIP server) sends the SIP INVITE to a routing proxy (eg, application server) dedicated to emergency calls. In FIG. 5, E-CSCF 254 is a SIP server that handles emergency calls.

  In step 6, E-CSCF 254 explicitly or implicitly allows UE 110 to support SUPL and send a routing request (or emergency location request) to E-SLP 272. decide. The routing request includes the UE public identifier (eg, emergency public user ID from step 5, TEL URI, etc.), location information received by the E-CSCF 254, and Mobile Termination IP (or UDP / IP) Is used in step 8, contains the UE IP. E-SLP 272 is in the same network as E-CSCF 254 or in several other networks. E-SLP 272 is selected because it covers the region that includes the approximate location of UE 110. E-CSCF 254 selects E-SLP 272, a general location server capable of acting as E-SLP, or other type of server, eg, GMLC 276. The selected location server decides to use SUPL based on the UE location capabilities transferred by E-CSCF 254 (or simply by assumption). E-CSCF 254 requests the selection of PSAP corresponding to the location information from E-SLP 272 and / or available location information and emergency service type.

  If the location information provided in step 6 allows E-SLP 272 to obtain a location estimate for UE 110 that is sufficiently accurate to satisfy the request in step 6, E-SLP 272 proceeds to step 12. move on. Otherwise, steps 7-11 are performed to obtain a suitable location estimate for UE 110.

  In step 7, E-SLP 272 determines from the received location selection information whether to use a separate V-SLP to assist with location selection. If so, a V-SLP (eg, V-SLP 274) is selected based on location information received from E-CSCF 254. E-SLP 272 is used for (a) SUPL 1.0 roaming assistance if V-SLP is selected, or (b) SUPL 1.0 non-roaming assistance if V-SLP is not selected. It acts as an H-SLP in performing the next SUPL location using a procedure similar to the one. In the case of roaming, E-SLP 272 exchanges some preliminary RLP signaling with V-SLC 422, which is not shown in FIG. E-SLP 272 then generates a SUPL INIT to drive the network start location procedure with UE 110 using either proxy or non-proxy mode in SUPL. E-SLP 272 sends the SUPL INIT directly to UE 110 using mobile terminated IP or UDP / IP, in which case step 8 is omitted. E-SLP 272 also sends a SUPL INIT in an immediate message (eg, an IMS immediate message, or some other IMS or SIP message) to E-CSCF 254. In any case, SUPL INIT is the IP address of the SPC used for positioning (if non-proxy mode is used, it is E-SPC 414 or V-SPC 424) Location quality (QoP) accuracy / delay requirement, proxy / non-proxy mode indication, authentication data and / or other information. For example, if UE 110 is not in its home network, E-SLP 272 is not an H-SLP for UE 110, or E-SLP 272 is an H-SLP but behaves as an H-SLP. If not selected (eg to avoid supporting one or more procedures for emergency calls), SUPL INIT also includes the IP address of E-SLP 272. SUPL INIT also includes an emergency call indication, for example, in a SUPL INIT notification parameter.

  In step 8, E-CSCF 254 may receive an IMS immediate message, some other IMS message, SIP 1xx response (eg, 183 session advance), or E-CSCF 254, P-CSCF 252 established in steps 2-4. And some other IP-compliant message using a secure IP relationship between UE 110 and send SUPL INIT to UE 110 via P-CSCF 252.

  In step 9, UE 110 establishes a secure IP (eg, secure TCP / IP) connection to E-SLP, which (E-SLP) is an H-SLP for UE 110, or The SUPL EXTET sent in includes the address. For non-proxy mode, UE 110 obtains authentication data from E-SLP 272 (not shown) and establishes a secure IP connection to E-SPC 414 or V-SPC 424 by mutual authentication. E-SLC 412 carries information to E-SPC 414 or V-SPC 424 for non-proxy mode (not shown in FIG. 5). UE 110 obtains location related measurements (eg, neighbor cell signal level and / or timing) or location estimates (eg, using standalone GPS) consistent with received QoS. UE 110 then returns a SUPL POS INIT to either E-SLP 272 (for proxy mode) or E-SPC 414 or V-SPC 424 (for non-proxy mode not shown in FIG. 5). The SUPL POS INIT contains a hash code used for authentication in proxy mode, UE positioning capability, location estimation or A-GPS assisted data (which is also included in the embedded SUPL POS message for IS-801). The SUPL POS INIT also assists in the derivation of fast provisional position estimates and further includes location related measurements that avoid SUPL POS signaling. For 3GPP, measurements include neighbor base station or access point signal levels, GPRS timing progression, and WCDMA® Rx-Tx time difference. For 3GPP2, measurements include location related measurements related to cdma2000 or 3GPP2 WLAN.

  If an appropriate location estimate (or location measurement) was not received in step 9, in step 10, E-SLP 272, E-SPC 414 or V-SPC 424 exchanges additional SUPL POS messages with UE 110. To do. Each SUPL POS message includes an embedded RRLP, RRC or IS-801 positioning message. This message exchange continues until an appropriate positioning measurement or position estimate is provided to E-SLP 272, E-SPC 414 or V-SPC 424. SUPL END is returned to UE 110 to finish the SUPL process.

  In step 12, E-SLP 272, E-SPC 414 or V-SPC 424 calculates a provisional location estimate for UE 110 from the location information received in step 9 or step 10. For non-proxy mode, E-SPC 414 or V-SPC 424 carries the position estimate to E-SLC 412. Based on the position estimate and if required by E-CSCF 254 in step 6, E-SLP 272 selects a PSAP. The following description assumes that PSAP 180 is the selected PSAP. If PSAP 180 is PSTN accessible / capable, E-SLP 272 may: (a) Emergency Services Routing Digit (ESRD) non-dialable phone number used to route to PSAP 180 (B) Obtain PSAP 180, E-SLP 272, and temporarily Emergency Service Routing Key (ESRK) non-dialable phone number identifying UE 110 . Each PSAP is associated with one ESRD as well as a set (pool) of ERKs that identify the E-SLP 272 and its PSAP. For each emergency call by the UE to this PSAP, one ESRK from the pool is allocated to the UE during the emergency call. Some of these functions (eg, ESRD / ESRK management) are not considered as part of SUPL and are individually queried by E-SLP 272 (eg, as shown in the NENA I2 solution) Supported in physical or logical entities. ESRD and ESRK correspond to the same named phone numbers used for emergency call assistance in circuit mode (eg, J-STD-036). ESRD and ESRK also correspond to ESRN and ESQK, respectively, described in the NENA I2 solution.

  In step 13, the E-SLP 272 (a) if the PSAP 180 has IP capability, is a PSAP identifier (it is either a SIP URL or an IP address), or (b) if the PSAP 180 has PSTN capability, ESRD. And a routing response (or emergency location response) including ESRK is returned to E-CSCF 254. The routing response also includes a provisional location estimate for UE 110 if requested by E-CSCF 254. E-SLP 272 stores a call record for UE 110 that includes all information gathered for UE 110.

  If the PSAP 180 has IP capability, steps 14a and 15a are executed. In step 14a, E-CSCF 254 sends the SIP INVITE (received in step 5) to PSAP 180. The SIP INVITE includes a provisional location estimate and possibly an identifier or address for UE 110 and the IP address or name of E-SLP 272. In step 15a, additional SIP signaling is exchanged to establish an emergency call.

  If the PSAP 180 has PSTN capability, steps 14b, 14c and 15b are executed. In step 14b, the E-CSCF 254 sends a SIP INVITE to the MGCF 258 via a breakout gateway control function (BGCF). The SIP INVITE includes a call back number for UE 110 (eg, MSISDN or MDN) and / or includes ESRD and ESRK (but probably does not include provisional location estimation). In step 14c, MGCF 258 uses SS7 ISUP and / or MF signaling to send an emergency call to PSAP 180 via PTSN and possibly via the selected router. ESRD or ESRK is used as a routing number, and ESRK and / or call back number is used as an identifier for UE 110 and as a key to obtain more information (eg, via MF CAMA signaling) 180. In step 15b, additional SIP signaling is exchanged with SS7 ISUP and interoperates and / or occurs at MGCF 258 for the MF to establish an emergency call.

  Call paths for IP capable PSAP and PSTN capable PSAP are established separately. For PSTN capable PSAPs, the interaction between VoIP (eg, RTP / IP) and circuit mode (eg, PCM) occurs at a media gateway (MGW) controlled by MGCF 258. For IP capable PSAPs, the call path is end-to-end IP and will go between UE 110 and PSAP 180, perhaps partly over the public Internet or extension IP network, but omit any MGW Will do.

  In step 16, after the call is established, PSAP 180 sends a location request to E-SLP 272, which is identified by the IP address or name obtained in step 14a or the ESRK obtained in step 14c. PSAP 180 uses the UE public user address (if PSAP 180 has IP capability), or a call back number or other address (eg, MSISDN or MDN) or ESRK (if PSAP 180 has PSTN capability). UE 110 is identified. The position selection request indicates a request for accurate position estimation. For emergency VoIP calls in the United States, if PSAP 180 has PSTN capability, the location request is identical to the emergency service location request in JSTD 036, and is an extension to this message if PSAP 180 has IP capability. For emergency VoIP calls in some other world regions, the location request is identical to the emergency location immediate request defined for OMA MLP.

  In step 17, if the location capability of E-SLP 272 does not extend to the geographic area where the last known location of UE 110 was reported, or if the use of V-SLP is more accurate and reliable. If provided, E-SLP 272 selects V-SLP. E-SLP 272 obtains the V-SLP address from the most recent location of UE 110 and / or from the most recent V-SLP address provided by E-CSCF 254. In order to ensure the correct V-SLP, if E-CSCF 254 does not forward this information automatically after re-registration of UE 110 in step 4, E-SLP 272 will send E-CSCF 254 to UE 110 Query location and / or V-SLP address (not shown in FIG. 5). E-SLP 272 then uses the mobile terminated IP or UDP / IP (in which case step 18 is omitted) by sending a SUPL INIT to the UE or by sending an immediate message containing the SUPL INIT. Open a new SUPL process with UE 110. SUPL INIT contains the parameters described above for step 7.

  In step 18, the E-CSCF 254 sends to the UE 110 a SUPL INITE in some IMS immediate message, some other IMS message, a SIP message (eg, re-INVITE), or a security between the P-CSCF 252 and the UE 110. Forward some other IP-compliant message that uses a secure IP relationship.

  In step 19, UE 110 establishes a secure IP connection to E-SLP 272. UE 110 then E-SLP 272 for proxy mode, or E-SPC 414 for non-proxy mode, or to obtain an accurate location estimate for UE 110 (as in steps 9, 10, 11). Exchange SUPL messages with V-SPC 424.

  In step 20, E-SLP 272 sends an accurate location estimate for UE 110 to PSAP 180 in the location response. For emergency calls in the United States, if the PSAP 180 has PSTN capability, the location response is identical to the emergency service location response message in J-STD-036 for the E2 interface (and thus added like MSISDN in UE 110) Information). For some other world region emergency calls, the location response is identical to the emergency location immediate response defined for OMA MLP.

  UE 110 will then communicate with PSAP 180 for emergency VoIP calls. When the call is later released, E-CSCF 254 sends an instruction to E-SLP 272, which then releases any record of the call. E-CSCF 254 or UE 110 also deregisters the emergency public user ID registered in steps 2-4. Instead, E-CSCF 254, E-SLP 272 and UE 110 may have some time period for registration and call records to support possible later call back and / or additional location requests from PSAP 180 to UE 110. Allowing you to last for a while.

1.2 Access For step 1, UE 110 connects to the access network via GPRS access, cdma2000 access, or WLAN access. Step 1 is performed differently for different types of accesses.

  For GPRS access, as described in 3GPP TR 23.867, UE 110 performs GPRS attachment to attach to the 3GPP access network, and GPRS packet data data to establish IP connections in SGSN 232a and GGSN 232b. Performs protocol (PDP) context activation. Emergency indications are used in GPRS installations and / or global access point names (APNs) for emergency services are used for PDP context activation, which ensures provision of GGSN and P-CSCF in V-PLMN 130 . P-CSCF 252 is the P-CSCF in the service GPRS PLMN as provided during PDP context activation.

  For 3GPP WLAN access, UE 110 performs a WLAN AAA procedure to attach to the WLAN and establishes an I-WLAN tunnel for an IP connection to PDG 236. UE 110 selects a service from V-PLMN 130 by using a roaming network access identifier (NAI) that indicates both H-PLMN 160 and V-PLMN 130 in authentication and authorization requests. Roaming NAI is described in 3GPP TS 23.234 and TS 23.008. This ensures that the UE 110 obtains IP access to the IMS service from the PDG 236 at the V-PLMN 130 rather than from the PDG at the H-PLMN 160 (if the H-PLMN 160 is far it restricts PSAP access). . Wide area WLAN APN (W-APN) for emergency services is used for PDG discovery and tunnel establishment. This service uses a globally unique external network identifier (for emergency service support) and a V-PLMN identifier. P-CSCF 252 is the P-CSCF in the V-PLMN associated with the WLAN and is found by a DNS query on the W-APN.

  For cdma2000 access, the service is obtained from V-PLMN 130 instead of H-PLMN 160, so UE 110 obtains a simple IP address rather than a mobile IP address. Instead, UE 110 obtains the mobile IP address from V-PLMN 130 rather than from H-PLMN 160, which is more general for mobile IP addresses. The IP address is probably an IPv4 address or an IPv6 address. If UE 110 has not established a connection (eg, does not have an assigned IP address), UE 110 establishes a point-to-point protocol (PPP) session and 3GPP2 X. Authentication and authorization is performed by PDSN 242 at V-PLMN 130 as described in P0011D and TIA-835-D. UE 110 obtains a simple IP address using, for example, PPP Internet Protocol Control Protocol (IPCP). If UE 110 has already established an IP connection and has a PPP session to PDSN 242, but is assigned a mobile IP address in H-PLMN 160 instead of a simple IP address, UE 110 can use simple IP and mobile If IP addresses cannot be supported simultaneously, all packet sessions associated with these IP addresses will be terminated as well as any IMS registration (simultaneous support of simple IP and mobile IP addresses is optional in TIA-835-D Yes, not mandatory UE capability). UE 110 then obtains a simple IP address as described in TIA-835-D. If the UE 110 can support simple IP and mobile IP address at the same time, the UE 110 only obtains the simple IP address if it does not already have it.

  For cdma2000 access, UE 110 uses (a) DHCP or IPCP to obtain P-CSCF domain name and DNS address from DHCP server or PDSN 242 and then (b) one or more P- from DNS server. Find the P-CSCF at V-PLMN 130 using DNS to obtain the CSCF IP address. If UE 110 moves and accesses a new RAN, V-PLMN 130 and UE 110 will be described in TIA-835-D if a new target PDSN is required and an emergency VoIP call has already been established. Use a fast handoff procedure. This avoids the need to terminate and re-establish the call.

  For 3GPP2 WLAN access, UE 110 performs existing WLAN access procedures, including AAA, IP address acquisition, and discovery of default IP router and DNS server addresses (eg, via DHCP). UE 110 then accesses the PDIF in the PLMN that supports emergency calls from the geographical location of the WLAN accessed by UE 110. The WLAN exposes the associated cdma2000 network so that the emergency call assistance PLMN can distinguish. This publication is accomplished, for example, by sending relevant Service Set Identifiers (SSIDs) in IEEE 802.11 beacon frames or via responses to UE probe request frames. PLMNs can be prioritized by the order in which they are published, by using the published PLMN indicators, or by ensuring (eg, requesting) that all PLMNs support emergency calls. For initial WLAN access, AAA, and IP address acquisition, UE 110 selects a PLMN (eg, SSID) that is meant or shown to support emergency calls.

  Following initial WLAN access, AAA, IP address acquisition, and discovery of the default IP router and DNS server address, UE 110 marks the IMS service and is one of the PLMNs exposed by the WLAN that supports emergency calls. Create a fully conditional domain name (FQDN) that uses the associated domain. The UE 110 then uses the FQDN to find one or more PDIF IP addresses from the DNS server. UE selects PDIF and 3GPP2 X. An IPsec tunnel is established using the procedure described in S0028200. This provides the UE 110 with a second internal IP address, which is used for the next IMS related procedure.

  Following the establishment of the WLAN-to-PDIF tunnel, the UE 110 is in the same way as the UE accessing the PDSN from the cdma2000 access network (eg, via DHCP to obtain the DNS server address and domain name, and then Find the P-CSCF address (via DNS to get the P-CSCF IP address). In this case, the PDIF acts as a DHCP relay agent instead of the PDSN. Discovery of PDIF and P-CSCF addresses via DNS includes an indication that emergency call assistance is required (eg, provided to a DNS server).

  If UE 110 already has an association (eg, a tunnel) with a PDIF in an inappropriate PLMN, and UE 110 is not supporting a tunnel to another PDIF at the same time, UE 110 will be able to communicate via the current PDIF. Release any supported packet session and select the tunnel to the new PDIF in the new appropriate PLMN and release the tunnel to the PDIF before establishing it.

  Following either cdma200 or WLAN access network connection, UE 110 locates the SUPL V-SLP address using a DNS query with a known V-PLMN domain name and V-SLP identifier (eg, supl_vslp @ domain_name). .

  Message flow 500 has the following feature additions related to OMA SUPL version 1.0. (A) Add E-SLP address in SUPL INIT (it invalidates and replaces the H-SLP address formed at UE 110). (B) An interface between the IMS side (eg, E-CSCF 254) and the location selection side (eg, E-SLP 272). (C) Use of V-SLP 274 and discovery of V-SLP addresses. (D) Transport of SUPL INIT using mobile terminal IP, UDP / IP, SIP, or IMS signaling. (E) Addition of emergency service indication in SUPL INIT. (F) Additional preference for new location measurements in SUPL POS INIT. (G) Use of the ILP protocol between ECSCF 254 and ESLP (which is similar to existing RLP). (H) Safety.

2.3 Emergency VoIP Call by 3GPP Control Plane FIG. 6 shows a block diagram of an embodiment of a network architecture 600 that can be applied to 3GPP control plane location. For simplicity, FIG. 6 simply shows the entities and interfaces involved to support emergency VoIP calls through GRPS access and 3GPP control plane location, and the access network is probably GERAN or UTRAN. V-PLMN 130 includes P-CSCF 252, E-CSCF 254 and MGCF 258 supporting IMS (eg, VoIP), SGSN / GGSN 232 for packet switched services, and GMLC 276 for location services. GMLC 276 replaces E-SLP 272 and is an enhanced version of GMLC described in 3GPP 23.271, 6th edition. V-PLMN 130 also includes E-SLP 272 and V-SLP 274 for location services (not shown in FIG. 6).

  In an embodiment, GMLC 276 communicates via E-CSCF 254 and Li interface and communicates via PSAP 180 and J-STD-036 E2 'interface. Use of the same Li interface for GMLC 276 and E-SLP 272 hides the positioning architecture differences between SUPL from E-CSCF 254 and the 3GPP control plane. Similarly, the use of the same J-STD-036 'interface for GMLC 276 and E-SLP 272 hides the positioning architecture differences from PSAP 180. Other interfaces in FIG. 6 are known in the art.

2.1 Call Setup FIG. 7 shows an example of a message flow 700 for emergency VoIP call setup using the 3GPP control plane. For clarity, irrelevant entities (eg, access network 120, P-CSCF 252 and S / R 292) have been omitted from FIG. 7, but are included in the description below. Message flow 700 assumes that UE 110 has UICC and that there is a roaming agreement between H-PLMN 160 and V-PLMN 130.

  In step 1, if the UE 110 is not already GPRS attached, the UE 110 performs GPRS attachment according to the emergency service instruction. GPRS attachment requires obtaining access to SGSN 232a, performing any authentication, and downloading reservation data from HLR / HSS 266 in H-PLMN 160 to SGSN 232a. In step 2, UE 110 performs PDP context activation using a wide range APN for emergency services. The PDP context is assigned to the local GGSN at V-PLMN 130 (eg, not to the GGSN at H-PLMN 160). UE 110 obtains an IP address and finds a local SIP server address (eg, P-CSCF 252) during PDP context activation.

  In step 3, the SGSN 232 becomes aware of the start of an emergency call based on the emergency instruction in step 1 or the wide area APN for emergency service in step 2. The SGSN 232a may then receive a packet switched network induced location request (PS) as described in 3GPP TS 23.271 to obtain either a provisional location estimate or a more accurate location estimate for UE 110. -NI-LR). If the SGSN 232 waits for a request to obtain a position estimate from the GMLC 276 (eg, via the MAP PSL in step 17), the PS-NI-LR will respond faster. PS-NI-LR is performed by the first SGSN. If UE 110 is handed over to the new SGSN, the new SGSN need not perform another PS-NI-LR. In step 4, once the location estimate is obtained for the UE, the SGSN 232 determines the GMLC address (eg, from the current cell ID) and sends the location estimate, UE identification, and / or other information to the GMLC 276. MAP Subscriber Location Report (SLR) including The UE identifier includes an international mobile subscriber identity (IMSI), a mobile subscriber ISDN number (MSISDN), an international mobile equipment identifier (IMEI), an electronic serial number ( Electronic Serial Number (ESM), Mobile Equipment Identifier (MEID), or some other identifier. If step 4 is executed, steps 10 and 11 are probably omitted.

  In step 5, UE 110 sends the SIP REGISTER discovered in step 2 to PCSCF 252. The SIP REGISTER includes the information described above for step 2 of FIG. 2, and also includes the SGSN address if steps 10 and 11 are to be performed. Depending on the presence of an emergency service indication or emergency public user ID, P-CSCF 252 sends a SIP REGISTER to E-CSCF 254 in the same network. Step 5 is executed in parallel with Step 3. In step 6, E-CSCF 254 sends a SIP REGISTER to H-PLMN 160 where normal IMS registration occurs, similar to step 3 of FIG.

  In step 7, H-PLMN 160 returns 200 OK to E-CSCF 254 and then 200 OK is returned to UE 110. If there is a handoff to another SGSN in V-PLMN 130, UE 110 will also re-register. If UE 110 re-registers using its emergency public user ID, E-CSCF 254 forwards any new location information and / or a new SGSN address.

  Similar to FIG. 5, in an alternative embodiment of steps 5, 6 and 7, UE 110 sends a SIP REGISTER to P-CSCF 252 in step 5, and then P-CSCF 252 sends a SIP REGISTER directly to H-PLMN 160. Send to S-CSCF 264 or I-CSCF 262 and bypass E-CSCF 254 at V-PLMN 130. In this case, the SIP 200 OK from P-CSCF 252 will be returned to P-CSCF 252 rather than E-CSCF 254 and 200 OK will be returned to UE 110 in step 7. Since the behavior of P-CSCF 252 is similar to that for normal registration, this alternative embodiment reduces or avoids the special impact on P-CSCF 252 to support VoIP emergency calls.

  In step 8, UE 110 sends a SIP INVITE containing the information described above for step 5 in FIG. 5 to P-CSCF 252. P-CSCF 252 sends a SIP INVITE to E-CSCF 254.

  In step 9, based on 3GPP control plane UE assistance for packet mode, E-CSCF 254 sends a routing request to GMLC 276 indicated by the service cell or other location information received in step 8. ) The routing request includes the information described in step 6 of FIG. 5 as well as the SGSN address if provided during registration. E-CSCF 254 selects GMLC 276, a general location server capable of acting as GMLC, or other type of server (eg, SLP). The selected location server decides to use the 3GPP control plane based on the UE location capabilities transferred by E-CSCF 254. E-CSCF 254 requests location information from GMLC 276 and / or PSAP selection corresponding to available location information and the type of emergency service required.

  If the location information provided in step 9 allows GMLC 276 to obtain a location estimate for UE 110 that is sufficiently accurate to satisfy the request in step 9, GMLC 276 proceeds to step 12. GMLC 276 also waits until it receives a MAP SLR from SGSN 232 in step 4 and proceeds to step 12 if a suitable location estimate is obtained. In other cases, steps 1 and 11 are performed to obtain an appropriate location estimate for UE 110.

  In step 10, GMLC 276 sends a MAP Provider Subscriber Location (PSL) to the SGSN 232 that includes QoP accuracy / delay for fast provisional location estimation. If step 4 is not performed, GMLC 276 determines SGSN 232 from any obvious address or location information received in step 9 (eg, cell ID). If no such information is received, or if the initially selected SGSN is incorrect (error response received in step 11), GMLC 276 may request the UE's MSI or pseudo-signal to obtain the SGSN address. Queries the HHS indicated by the MSI or MSISDN. In step 11, SGSN 232 returns the position estimate obtained in step 3 and waits until step 3 ends and then returns a position estimate or obtains a position estimate from RAN and then returns the position estimate to GMLC 276. .

  In step 12, GMLC 276 selects a PSAP based on the position estimate. The following description assumes that PSAP 180 is the selected PSAP. If the PSAP has PSTN capability, the GMLC 276 will be used to route to the PSAP 180, and the ESRD non-dialable phone number used to route the PSAP 180, GMLC 276, and temporarily the ESRK non-dialable phone number that will identify the UE 110. To get.

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

  In step 17, GMLC 276 sends a MAP PSL to SGSN 232 requesting correct location. GMLC 276 obtains the SGSN address from the most recent location information for UE 110 or from an update of the SGSN address from E-CSCF 254. If this address is received in a re-REGISTER message but not forwarded, GMLC 276 also queries the SGSN address from E-CSCF 254. GMLC 276 also queries the SGSN address from the HHS indicated by the UE's MSI or pseudo MSI or MSISDN. In step 18, SGSN 232 drives the positioning of UE 110 by the RAN. In step 19, SGSN 232 returns the position estimate to GMLC 276. In step 20, GMLC 276 returns a position estimate to PSAP 180 as described for step 20 in FIG.

  UE 110 will then communicate with PSAP 180 for emergency VoIP calls. When the request is later released, E-CSCF 254 sends an indication to GMLC 276, which then releases any recording of the call. E-CSCF 254 or UE 110 also deregisters the emergency public user ID registered in steps 5-7. Instead, E-CSCF 254, GMLC 276 and UE 110 allow registration and call back to persist for a period of time to support possible subsequent call back from PSAP 180 to UE 110.

  Message flow 700 performs call setup and location for UE 110 in an integrated manner and has the following characteristics. (A) The SGSN 232 obtains the UE location and pushes it to the GMLC 276 whenever a PDP context is activated and / or if requested by the GMLC 276. (B) GMLC 276 receives a public SIP-URI address for UE 110 from E-CSCF 254. (C) If PSAP 180 has PSTN capability, GMLC 276 and E-CSCF 254 forward to PSAP 180 information used to identify both the call and GMLC 276 (eg, 10 digit ESRK). This information allows PSAP 180 to retrieve location selection and other information (eg, MSISDN, SIP URI). (D) The Li interface between the E-CSCF 254 and the location server (eg, E-SLP 272) is used to support emergency calls from I-WLAN when SUPL is used as a positioning method. . The use of the same Li interface for UMTS, GPRS and I-WLAN allows an IMS (eg, E-CSCF 254) to operate without knowing the location solution, which simplifies IMS handling. (E) If the UE 110 does not support location selection by RAN (supports SUPL but not the 3GPP control plane), the SGSN 232 omits the PS-NI-LR. (F) PSAP 180 has a specific location selection request unknown to SGSN 232, eg, special accuracy with respect to location coordinates, or even no support (eg, if PSAP 180 supports phase 0 or 1 of E911). Such a request is supported in GMLC 276 for circuit switching emergency calls.

  The Li interface is used to achieve the features listed above. If the GMLC and E-CSCF functions are supported by the same platform, external Li interface support is not required. The Li interface is extended for use between any IMS entity and GMLC to support IMS and other features associated with IP-compliant services, as described above for SUPL.

  SGSN 232 is selected for UE 110 based on provisional location estimation (eg, service cell). GMLC 276 is selected by E-CSCF 254 based on the same provisional position estimate. The provisional position estimate is pushed from SGSN 232 into GMLC 276 or pulled from SGSN 232 by GMLC 276. One entity determines the other as follows.

  SGSN 232 forwards the provisional position estimate to GMLC 276. SGSN 232 obtains this provisional location estimate via PS-NI-LR, determines GMLC address according to current UE location (eg, current cell ID), and uses MAP Subscriber Location Report (SLR) To send / push the position estimate to GMLC 276. E-CSCF 254 queries GMLC 276 for the PSAP address to route the emergency call. GMLC 276 waits for a MAP SLR from SGSN 232 to determine the PSAP address from the provisional location estimate (if needed).

  GMLC 276 derives a provisional position estimate from SGSN 232. SGSN 232 will still perform PS-NI-LR, but will not send the position estimate to GMLC 276 until GMLC queries the position estimate via a MAP SLR request. GMLC 276 determines the SGSN address using one of the following: (A) GMLC 276 (if UE 110 has a roaming agreement supported in UICC and V-PLMN 130) from HSS 266 in H-PLMN 160, or (UE 110 is in UICC and V-PLMN 130). Query the SGSN address from the HSS 250 at the V-PLMN 130 (unless you have a roaming agreement supported by (B) UE 110 is the current SGSN address, or location information where the SGSN address was obtained in each REGISTER and re-REGISTER message sent to IMS, or in each SIP INVITE message sent to IMS for emergency call. (For example, GPRS cell ID). E-CSCF 254 then forwards the SGSN address or location information to GMLC 276. UE 110 re-registers with IMS following any takeover between SGSNs.

3. X. Emergency VoIP Call by S0024 FIG. FIG. 7 shows a block diagram of an embodiment of a network architecture 800 that can be applied for S0024 location. Access network 120 includes a CDMA2000 1X network, a CDMA2000 1xEV-DO network, 3GPP WLAN, and so on. V-PLMN 130 includes P-CSCF 252, E-CSCF 254 and MGCF 258 to support IMS (eg, VoIP) and PDSN 242 for packet switched services (not shown). V-PLMN 130 includes E-PS 282 and V-PS / PDE 284 (as shown) and also includes E-SLP 272 and V-SLP 274 (not shown) for location services. E-PS 282 replaces H-PS for emergency call location selection. E-PS 282 and V-PS / PDE 284 reside in other networks.

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

3.1 Call setting FIG. FIG. 9 illustrates an example of a message flow 900 for emergency VoIP call setup using S0024. In step 1, UE 110 locates, installs, establishes an IP connection, and establishes a local SIP server (eg, P-CSCF 252) as described above for step 1 of FIG. Find out. After access network connection, UE 110 finds the V-PS address using a DNS query with a known V-PLMN domain name and V-PS identifier (eg, xs0024_vps @ domain_name).

  In step 2, UE 110 sends a SIP REGISTER to P-CSCF 252 which sends a message to E-CSCF 254. In step 3, E-CSCF 254 sends a SIP REGISTER to H-PLMN 160, where normal IMS registration occurs. In step 4, E-CSCF 254 returns 200 OK to UE 110 (eg, after receiving 200 OK from H-PLMN 160). UE 110 re-registers if passed to another PCF, PDSN or WLAN within the same V-PLMN.

  In an alternative embodiment of steps 2, 3 and 4, UE 110 sends a SIP REGISTER to P-CSCF 252 in step 2, and then P-CSCF 252 sends a SIP REGISTER to S-CSCF 264 or I-PL in H-PLMN 160. Send to CSCF 262 and bypass E-CSCF 254 at V-PLMN 130. In this case, SIP 200 OK from H-PLMN 160 will be returned to P-CSCF 252 rather than E-CSCF 254, and P-CSCF 252 will return 200 OK to UE 110 in step 4. Since the behavior of P-CSCF 252 is similar to that for normal registration, this alternative embodiment reduces or avoids the special impact on P-CSCF 252 to support VoIP emergency calls.

  In step 5, UE 110 sends a SIP INVITE to P-CSCF 252 (not shown), which sends a SIP INVITE to E-CSCF 254. In step 6, E-CSCF 254 determines that UE 110 has X. Decide to support S0024 and send a routing request to E-PS 282 in the same or another network. The routing request includes the information described above for step 6 of FIG. 5 and the V-PS address if obtained during registration. If the location information provided in step 6 allows a sufficiently accurate location estimate for UE 110 to be obtained, E-PS 282 proceeds to step 12. In other cases, steps 7-11 are performed to obtain an appropriate location estimate for UE 110. In step 7, E-PS 282 (a) if V-PS is selected, X. S0024 roaming support, or (b) X. if V-PS is not selected. Using the similar procedure to those for S0024 non-roaming support, Acts as H-PS when performing S0024 position selection. E-PS 282 is used by UE 110 to facilitate the network start location procedure. S0024SUPL INIT is generated. E-PS 282 sends the SUPL INIT directly to UE 110 using mobile terminated IP or UDP / IP. E-PS 282 also sends the SUPL INIT in the immediate message to E-CSCF 254. In any case, SUPL INIT includes positioning mode, QoS accuracy / delay for fast provisional position estimation, E-PS IP address, emergency call indication, and so on. Any E-PS address carried in the SUPL INIT invalidates the H-PS address configured at the UE 110.

  In step 8, E-CSCF 254 sends a SUPL INIT to UE 110 via P-CSCF 252 using IMS or SIP signaling. In step 9, UE 110 established a secure IP connection to the E-PS, which was the H-PS for UE 110, or included its IP address in the SUPL INIT in step 7. UE 110 then sends a SUPL INIT to E-PS 282 that includes UE location capability, location information for UE 110, location estimation for UE 110 (if available), and so on. If a location estimate with sufficient accuracy to determine the PSAP is received from UE 110 in step 9, E-PS 282 proceeds to step 12 and terminates the location process by UE 110 by sending SUPL END. To do.

  In step 10, E-PS 282 selects an appropriate local PDE or an appropriate remote V-PS to perform positioning based on the location information received in step 9 and other location information received in step 6. decide. E-PS 282 also determines whether to use proxy or non-proxy mode. The E-PS 282 then interacts with the V-PS or PDE for positioning, and if the non-proxy mode is selected, the X.E. Send S0024 SUPL RESPONCE to UE 110. In step 11, UE 110 performs 3GPP2 X. In order to continue and complete positioning as described in S0024, exchange the PDE for non-proxy mode or the E-PS 282 and SUPL POS messages for proxy mode. The SUPL POS message carries the embedded IS-801. The positioning provides a position estimate for UE 110, which is passed to E-PS 282.

  In step 12, E-PS 282 selects a PSAP (eg, PSAP 180) and obtains ESRD and ESRK if PSAP 180 has PTSN capability. In step 13, if the PSAP 180 has IP capability, a PSAP identifier is sent, and if the PSAP 180 has PTSN capability, ESRD and ESRK, and if required by the E-CSCF 254, a routing response including a location estimate for the UE 110 is received as E- Return to CSCF 254. E-PS 282 stores a call record for UE 110 that includes all information gathered for the UE. If the PSAP 180 has IP capability, steps 14a and 15a are executed. If the SAP 180 has PTSN capability, steps 14b, 14c and 15b are executed. In step 16, after the call is established, PSAP 180 sends an E-PS request for an accurate location estimate identified by the IP address or name obtained in step 14a or the ESRK obtained in step 14c. Send to 282.

  In step 17, the E-PS 282 sends the SUPL INIT directly to the UE 110 using the mobile terminal IP or UDP / IP (in which case step 18 is omitted) or an accurate location estimate. X. with the parameters described in step 7 excluding QoS accuracy / delay. A new X. with UE 110 by sending an immediate message containing the S0024 SUPL INIT to the E-CSCF 254. The S0024 process is opened. In step 18, E-CSCF 254 forwards the SUPL INIT in the IMS immediate message, SIP message or some other message to UE 110. In step 19, UE 110 establishes an IP connection (eg, a secure IP connection) to E-PS 282 and returns a SUPL START to E-PS 282. E-PS 282 determines the appropriate PDE or V-PS for positioning based on any location information in SUPL START, and any other location information for UE 110. E-PS 282 then begins positioning by returning a SUPL RESPONCE to UE 110. UE 110 exchanges SUPL POS messages with E-PS 282, local PDE, and / or remote PDE to locate and obtain an accurate location estimate for UE 110. In step 20, E-PS 282 sends an accurate location estimate for UE 110 to PSAP 180 in the location selection response.

  UE 110 thereafter communicates with PSAP 180 for emergency VoIP calls. When the request is later released, E-CSCF 254 sends an indication to E-PS 282, which then releases any record of the call. E-CSCF 254 or UE 110 also cancels the emergency public user ID registration registered in steps 2-4. Instead, E-CSCF 254, E-PS 282, and UE 110 may have some time period during which registration and call records may be supported to support possible subsequent call back and / or additional location requests from PSAP 180 to UE 110. Makes it possible to last.

  Additional details of steps 1-8 and steps 12-20 of FIG. 9 are described in steps 1-8 and steps 12-20 of FIG. 5, respectively.

  Message flow 500 is X.264. There are the following features related to S0024. (A) X. Addition of E-PS address in S0024 SUPL INIT (it invalidates and replaces H-PS address formed in UE 110 or UIM). (B) An interface between the IMS side (eg, E-CSCF 254) and the location selection side (eg, E-PS 282). (C) Use of V-PS 284 and discovery of V-PS addresses. (D) X. using mobile terminal IP, UDP / IP, SIP signaling or IMS signaling. Transport of S0024 SUPL INIT. (E) X. Added emergency service indication in S0024 SUPL INIT. (F) Use of a new protocol between E-CSCF 254 and E-PS 282 (which is similar to OMA RLP or PS-PS over the LCS-z interface in X.S0024). (G) Safety.

4). Supporting UEs without UICC / UIM and Roaming Agreement The above description assumes that UE 110 has UICC / UIM and that H-PLMN 160 and V-PLMN 130 have roaming agreement, Enable UE registration at PLMN 130 and next emergency call access to PSAP 180. If this is not the case, the UE 110 accesses and registers at the V-PLMN 130 and terminates the call setup to the PSAP 180 and possible call back from the PSAP 180 as described below. Callback from PSAP 180 in the absence of UICC / UIM is possible for VoIP, but is generally not possible for circuit switched emergency access because unregistered UEs cannot be called.

  FIG. 10 is a block diagram of an example network architecture 1000 that supports emergency VoIP call setup and PSAP callback for UEs without UICC / UIM. Network architecture 1000 includes a number of entities shown in FIGS. The network architecture 1000 includes a location server 286, which is an SLP, GMLC, PS, or some other location entity.

4.1 Access UE 110 gains GPRS access, 3GPP WLAN access, or IMS access without UICC. UE 110 also gets cdma2000 access, 3GPP WLAN access, or IMS access without UM. UE 110 performs different procedures for different types of access.

  For GPRS access, UE 110 performs PDP context activation for emergency services without UICC and / or without roaming agreement in V-PLMN 130 described in 3GPP TR23.867. GPRS attachment is accomplished using pseudo IMSI, which registers UE 110 at HSS 250 in V-PLMN 130, which helps support inter-SGSN takeover. If UE 110 does not have UICC, the pseudo IMSI is generated by the unique MCC-MNC combination and digits from IMEI, but UE 110 has UICC, but does not have roaming access to V-PLMN 130, Pseudo IMSI is created by digits from MSI rather than IMEI, which avoids duplicate pseudo IMSI if all IMSI is used. GPRS attachment is also accomplished using IMEI as an identifier.

For 3GPP WLAN access, UE 110 creates a pseudo NAI from a pseudo IMSI (eg, the same pseudo MSI used for GPRS attachment) as follows:
Pseudo NAI = "n <pseudo IMSI> @ V-PLMN_network_domain" where n is a fixed digit ranging from 2 to 9 indicating the use of unauthenticated pseudo NAI for emergency calls (0 or 1 is normal NAI Already used). UE 110 uses the pseudo NAI for initial access and AAA procedures.

  The WLAN exposes V-PLMNs that can support AAA using pseudo-NAI for emergency services, or presents V-PLMNs in order of priority indicating the ability and propensity to support them. V-PLMN 130 treats UE 110 as a temporary home subscriber and either omits AAA or uses it well (eg, using a well-known key to ensure that authentication was successful). Guarantee). It is desirable to register UE 110 at HSS 250 to follow normal procedures as much as possible and better support WLAN reselection and takeover.

  For cdma2000 access, UE 110 establishes a PPP session with PTSN 242 and, for example, a Link Control Protocol (LCP) Configure Request from PDSN 242 as described in IETF RFC 1661. ) To reject authentication during PPP establishment by returning an LCP configuration request. PDSN 242 supports emergency calls for no UIM or unauthenticated UEs and continues PPP session establishment without authenticating UE 110. PDSN 242 assigns a simple IP address to UE 110 and applies IP packet filtering to limit the entities with which UE 110 communicates. For example, PDSN 242 limits UE 110 to communication with local servers (eg, DHCP server, DNS server, and P-CSCF 252) and to entities that are associated with PSAP access but do not have Internet access open. To do.

  The PDSN 242 is notified of an emergency call in several ways. In an embodiment, UE 110 sends an IECP configuration request to PDSN 242 that includes a widely defined unique IP address to indicate an emergency call IP address request. In other embodiments, the indication is used in PPP establishment, or the PDSN 242 receives an indication of an emergency call request from the RAN (RRC / PCF 222) via the cdma2000 A10 interface. In any case, PDSN 242 assigns a simple IP address to the unauthenticated UE for emergency calls and uses special filtering as described above. This IP address assignment is achieved through an enhancement to the PPP IPCP described in IETF RFC 1332. If UE 110 does not indicate an emergency call, PDSN 242 will not allow PPP establishment and IP address assignment.

  Instead of rejecting authentication, UE 110 allows authentication to proceed using either Password Authentication Protocol (PAP) or Revocation-Handshake Authentication Protocol (CHAP) (CHAP), which IETF RFC 1334 and RFC 1994. UE 110 receives a CHAP avoidance or PAP authentication request and sends a response including an identification indicating an emergency call from a UE without UIM. This identifier is a pseudo-IMSI used for 3GPP WLAN access. If the identifier indicates V-PLMN 130 as the domain for UE 110, CHAP or PAP authentication proceeds from the PDSN 242 view to AAA server 246 in V-PLMN 130 in the normal manner. AAA server 246 recognizes the pseudo-IMSI as an indication of emergency call access and either refrains from normal authentication or authenticates using a known key. AAA server 246 ensures that restricted filtering is used by PDSN 242 to restrict IP access, for example, to allow emergency VoIP requests, but not allow other types of access.

  PDSN 242 establishes a NAI for accounting and / or record keeping. If UE 110 has a UIM, PDSN 242 uses the UE's unique international identifier (IMSI, MIN, international roaming MIN-IRM). PDSN 242 also uses an ESN or other identifier for UE 110.

  For 3GPP WLANs, after UE 110 accesses the WLAN, the access point and authentication entity initiates UE 110 authentication and sends an Extended Authentication Protocol (EAP) request or some other request for UE 110 identification. The UE 110 responds by returning an EAP response or some other response containing the identifier of the UE, eg in the form of user @ domain where the domain identifies the H-PLMN of the UE 110. If UE 110 does not have a UIM or roaming agreement in V-PLMN 130, UE 110 returns a pseudo-identification that is the same as or similar to the pseudo-NAI used for 3GPP WLAN. For example, the user (eg, pseudo-IMSI) portion of the pseudo-identifier includes the UE's unique international identifier (eg, IMSI, MIN or IRM) if the UE 110 has a UIM, otherwise the UIM or unique terminal ID (eg, , ESN). The user part also includes a unique prefix (eg, a unique digit) that indicates that it is a pseudo-identification for emergency calls. The domain part of the pseudo-identification indicates V-PLMN 130.

  The access point or authentication entity continues to authenticate using a local AAA server, eg, the local AAA server 236. Since no real authentication is performed, authentication is usually performed using a known key or shortened. Once the pseudo-authentication is complete, as described above, the access point or associated router uses packet filtering to limit access by the UE 110.

  UE 110 accesses the WLAN, performs pseudo-authentication, and finds the PDIF. UE 110 then identifies itself to PIDF (or local AAA server) using pseudo-identification instead of, for example, NAI used for cdma2000 UE-PIDF authentication. The pseudo-identification is the same as or similar to that used for WLAN authentication. Normal authentication and tunnel establishment then uses a local AAA server to achieve some transparency of the PDIF and with a known key (eg as described in 3GPP2 X.P0028-200) proceed. Instead, authentication is shortened or interrupted. After authentication, PDIF uses packet filtering to restrict access by UE 110.

  The WLAN publishes a V-PLMN that can support the above procedure, or presents the V-PLMN in a priority order that indicates the ability and propensity to support this.

  For IMS access, GPP TR 28.867 and 3GPP2 X. As described in P0013-002A, if the UE 110 does not have UICC / UIM and roaming agreement with the V-PLMN, SIP registration is omitted. This allows emergency call setup to PSAP, but does not support call back. Instead, UE 110 registers by sending a SIP REGISTER containing the V-PLMN domain name and emergency private user ID (which is created using the V-PLMN domain name and pseudo-IMSI). This SIP REGISTER is recognized in E-CSCF 254 and HSS 250, but will be transparent to other entities.

  The registration procedure then proceeds as long as it is transported in the V-PLMN 130 from the UE 110 to the E-CSCF 254 (or other IMS server). Although registration at H-PLMN 160 is not performed, E-CSCF 254 will register UE 110 with HSS 250 at V-PLMN 130. HSS 250 assigns a TEL URI and / or a temporary SIP URI (from the pool in HSS 250) as a temporary public user identifier. If signaling was on the PSTN, the TEL URI is carried to the PSP 180 at call setup and the SIP URI is carried for SIP call setup. If IMS registration and IP connectivity are maintained by both V-PLMN 130 and UE 110 for some period following the termination of the emergency call, the URI will allow call back from PSAP 180. Since the TEL URI and SIP URI are not used to extensively identify the UE 110, they are recognized by the PSAP 180 as temporary addresses due to differences from normal permanent addresses. HSS 250 "isolates" temporary addresses returned from completed emergency calls and reassigns these addresses in a certain period of time to avoid PSAP callbacks that are misrouted to the wrong UE .

  Call back is supported in several ways. If UE 110 is registered in H-PLMN 160, 3GPP TS 23.228 or 3GPP2 X. Callback from PSAP 180 uses the SIP 110 or TEL URI public user identification of UE 110 and is initially routed to H-PLMN 160, as described in P0013. For SIP capable PSAPs, the SIP INVITE is routed to the I-CSCF 262 at the H-PLMN 160 (based on the H-PLMN domain name in the UE's SIP URI). I-CSCF 262 queries HSS 250 for S-CSCF 264 at H-PLMN 160 and routes the call to S-CSCF 264. S-CSCF 264 then routes the call to E-CSCF 254 or P-CSCF 252 at V-PLMN 130 based on the previous registration information. In the former case, E-CSCF 254 is treated as P-CSCF by S-CSCF 264 and routes the call to UE 110 via P-CSCF 252. In the latter case, P-CSCF 252 routes the call to UE 110. For PSTN capable PSTN, the call is routed through the PSTN to the MGCF at H-PLMN 160 based on the TEL URI of UE 110. The MGCF interoperates between PSTN and SIP signaling and sends a SIP INVITE to I-CSCF 262 at H-PLMN 160. Call routing from I-CSCF 262 to UE 110 will then proceed in the same manner for SIP capable PSAPs.

  If UE 110 is not registered at H-PLMN 160 (eg, due to lack of roaming agreement with UICC / UIM and / or V-PLMN 130), UE 110 is registered at HSS 250 at V-PLMN 130. HSS 250 assigns a temporary TEL URI or SIP URI public user identifier to UE 110. Callbacks from PSAP do not include HPLMN 160 and are routed either to I-CSCF 262 for SIP capable PSAPs or to MGCF 258 for PSTN capable PSAPs.

4.2 Call Setup FIG. 11 shows an example of a message flow 1100 for emergency VoIP call setup for a UE without UICC / UIM. Message flow 1100 includes 3GPP control plane positioning, SUPL, and X. Used for S0024.

  In step 1, as described above, UE 110 finds and connects to the access network, establishes an IP connection, and finds a local SIP server (eg, P-CSCF 252). UE 110 uses pseudo-IMSI for GPRS or cdma2000 access, pseudo-NAI for WLAN access, and pseudo-identification for 3GPP WLAN access. UE 110 registers with HSS 250 at V-PLMN 130 using a pseudo identifier (eg, pseudo MSI).

  In step 2, UE 110 attempts to register in the V-PLMN IMS network by sending a SIP REGISTER to P-CSCF 252 found in step 1. For no UICC / UIM or non-roaming, the SIP REGISTER is the emergency service indication, V-PLMN domain name, UE IP address obtained in step 1, V-PLMN domain name and (GPRS) pseudo-IMSI or (cdma2000) pseudo-identification Emergency private user ID created using and / or other information. For re-registration, the SIP REGISTER further includes a temporary public user ID assigned in the initial registration. Due to the presence of an emergency service indication or emergency private user ID (which indicates V-PLMN 130 as the home network for UE 110), P-CSCF 252 sends SIP REGISTER to E-CSCF 254 (which is an emergency service call). On the same network. The sent SIP REGISTER contains location information for UE 110. SIP REGISTER also includes a V-SLP or SGSN address (for 3GPP) or a V-SLP, PDSN or PDIF address (for 3GPP2).

  In step 3, the emergency private user ID for UE 110 refers to V-PLMN 130, so E-CSCF 254 sends registration information to HSS 250, eg, Cx-Put / Cx-Pull. In step 4, the HSS 250 checks whether an emergency private user ID has already been registered, for example, whether the UE 110 has already registered or another UE has registered the same private user ID. HSS 250 distinguishes UEs with the same emergency private user ID by a common UE entity digit (eg, common IMEI or ESN digit) and the first from re-registration (without an assigned temporary public user ID) In order to distinguish registrations, a temporary public user ID is used if provided. For initial registration, HSS 250 stores the emergency private user ID and E-CSCF address and is assigned a temporary public user SIP URI and TEL URI, which are returned to E-CSCF 254.

  In step 5, E-CSCF 254 returns 200 OK to UE 110 via P-CSCF 252. The 200 OK contains a temporary public user ID assigned by HSS 250. UE 110 will re-register if passed to another SGSN (for GPRS access), another PCF or PDSN (for cdma2000 access), another WLAN (for WLAN access). In step 6, if the UE 110 does not have roaming access to the UICC / UIM and / or V-PLMN 130, the UE 110 may provide an emergency call, the type of emergency service required, and a temporary public user ID. A SIP INVITE containing the wide-ranging SIP URL or TEL URI to be indicated is sent to the P-CSCF 252. P-CSCF 252 sends a SIP INVITE to E-CSCF 254. In step 7, E-CSCF 254 performs PSAP routing for the call (eg, PSAP SIP URI, or ESRD and ESRK) as described in steps 6-13 of FIGS. 5 and 9 and steps 9-13 of FIG. Interacts with location selection server 286 to obtain information.

  If PSAP 180 has IP capability, steps 8a and 9a are executed. In step 8a, E-CSCF 254 routes the SIP INVITE to PSAP 180 using the SIP URI. The SIP INVITE includes any provisional location estimate for the UE 110, the IP address or name of the location server 286, and a temporary public user SIP URI assigned to the UE 110. In step 9a, additional SIP signaling is exchanged to establish an emergency call.

  If PSAP 180 has PSTN capability, steps 8b, 8c and 9b are executed. In step 8b, E-CSCF 254 sends SIP INVITE to MGCF 258 via BGCF. The SIP INVITE contains the ESRD and ESRK assigned to the UE 110 and possibly the temporary public user TEL URI. In step 8c, MGCF 258 routes the call to PSAP 180 over the PTSN, possibly via the selected router, using SS7 ISUP and / or MF signaling. ESRD or ESRK is used as a routing number, and ESRK is passed to PSAP 180 as an identifier for UE 110 and as a key to obtain more information. Temporary public user The 164 number is also passed to PSAP 180 if allowed by the signaling capability. E. 164 is an ITU-T standard that defines the international telephone numbering system and The 164 number consists of a region code and a country number. In step 9b, additional SIP signaling is exchanged with SS7 ISUP and interoperates and / or MF in MGCF 258 occurs to establish a call.

  In step 10, PSAP 180 obtains an accurate location estimate for UE 110 by querying location server 286, which is indicated by SIP URI in the call setup. If PSAP 180 has PTSN capability, and this number was not passed to PSAP 180 in call setup, the response from location server 286 will be sent to any temporary public user E.E. 164 numbers. The call is released shortly and is interrupted, for example, by a temporary loss of radio coverage. The E-CSCF 254 then waits for a period of time before notifying the location server 286 to assist the location of the UE 110 by the PSAP 180 for the next call back.

  PSAP 180 attempts to call back UE 110 using its temporary public user ID. Step 11a is performed for SIP enabled PSAP. In step 11a, PSAP 180 sends a SIP INVITE to I-CSCF 258, which is indicated by the network domain portion of the temporary public user SIP URI assigned to UE 110. Steps 11b and 11c are performed for PSTN capable PSAPs. In step 11 b, PSAP 180 sends an ISUP IAM (or MF call setup) to MGCF 258, which is a temporary public user E. assigned to UE 110. Indicated by the first digit in the 164 number. In step 11c, the MGCF 258 receives the E.D. Send SIP INVITE containing TEL URI constructed from 164 number to I-CSCF 258.

  In step 11c, I-CSCF 258 sends to HSS 250 a location query that includes the temporary public user SIP URI received in step 11a or the temporary public user TEL URI received in step 11c. In step 13, HSS 250 finds the UE registration information and returns the address of E-CSCF 254 to I-CSCF 258. In step 14, I-CSCF 258 sends a SIP INVITE to E-CSCF 254. In step 15, E-CSCF 254 locates the P-CSCF dress and sends a SIP INVITE to UE 110 via P-CSCF 252. In step 16, call setup continues as in the normal case.

  UE 110 then communicates with PSP 180. When the call is later released or shortly thereafter, E-CSCF 254 sends an indication to location server 286, which then releases any record of the call.

5. Support for geographically remote legacy PSAPs In some cases, the V-PLMN and / or SIP server (eg, E-CSCF 254) is geographically remote from the UE 110. In such cases, if the PSTN does not support access to the remote PSAP, it is not possible to route the call to the PSTN capable PSAP via the local MGCF. The following are used to handle these cases.

  In an embodiment, the emergency call is redirected to another V-PLMN. At the beginning of the SIP INVITE process, the E-CSCF or location server (eg, ESLP, GMLC, etc.) determines that the call should be redirected to the call server in another network. In that case, a SIP 3xx redirection response (eg, 305 uses a proxy) is returned to the UE 110, including the preferred alternate server's SIP URI. If the same access network is still available, the access and IP connection procedure is omitted, but the UE 110 will then retry the call procedure as described above. If the call setup procedure has proceeded to the point where provisional location estimation and / or correct PSAP (eg, ESRD, SIP URI or IP address) has been determined, the E-CSCF includes these in the redirection response. UE 110 then includes the information in the SIP INVITE sent to the new PLMN, which avoids the extra delay to obtain the same information and allows the use of a PLMN that is not capable of obtaining this information. The original E-CSCF notifies the location server (eg, ESLP, GMLC), which then removes the call record for UE 110.

  In another embodiment, the E-CSCF sends the call to the SIP server in another network (or the same network) close to the PSAP where the call is sent to the PSTN even better. The V-PLMN supports all previously mentioned functions including the location function and continues to support UEs without UICC or UIM. The sent SIP INVITE contains the PSAP identifier (eg, SIP URI or ESRD), any ESRD assigned by the location server, and a temporary public user ID assigned for the UE without UICC. The PSAP continues to query the location server at the V-PLMN for location information, and any callback is sent to the V-PLMN via the H-PLMN for the normal case, or V- in the absence of UICC. Directed to PLMN. Ongoing support of these functions in the V-PLMN should avoid the request on the next SIP server and allow a larger number of other networks to support the forwarding service.

  In yet another embodiment, local number portability is used, for example, in North America. In addition to returning ESRD and ESRK, the location server (eg, E-SLP or GMLC) can directly connect the LRN (location) to the IMS network (eg, E-SCSF) corresponding to the LEC exchange or PSAP selection router that reaches the PSAP. Returns the selected route designation number). Alternatively, the IMS network (eg, E-SCSF or MGCF) obtains the LRN from ESRD. The LRN is sent to the MGCF (if not obtained by the MGCF), and the MGCF sends an ISUP IAM containing the following parameters to the PSTN: called party number = LRN, general address parameter (GAP) = ESRD, “translated FCI parameter bit M set to “number translated”, caller number = UE MSISDN or ESRK, and caller category set to “emergency service call” (optional).

  With the support of number portability by the PSTN (eg throughout the United States), the call (ISUP IAM) is routed correctly to the target LEC CO, or SS7 rather than the MF radio trunks The selected router provided is used until the end. The destination LEC CO or selective router supports number forwarding and recognizes the LRN as its own upon receipt of a call and obtains the true called party number (ESRD) from the GAP. The uniqueness of the ESRD or caller partition setting informs the LEC CO or selected router that this is an emergency call. At that point, the call is routed to the PSAP as if it originated nearby. This embodiment avoids a new impact on PSTN tariff exchange (eg, routing does not change) but affects the LEC CO or selected router.

6). SUPL and X.M. Security for S0024 For SUPL, a safety procedure is established to support E-SLP 272 to replace H-SLP for roaming and non-roaming scenarios and for positioning by proxy or non-proxy mode. Existing SUPL security procedures are generally based on shared keys at both UE 110 and H-SLP and / or other information provided at UE 110 related to H-SLP (eg, fully qualified domain names, Basic X.509 public key certificate). Such information is not available to E-SLP 272. For E-SLP 272, proxy and non-proxy mode authentication is supported as described below.

  X. For S0024, a safety procedure is also established to assist E-PS 282 to replace H-PS for positioning. Existing X. The S0024 safety procedure is 3GPP2 X. S0024-0 and 3GPP2 P0110-0. These procedures utilize a common root key provided in both the H-PS for the user and the user's UIM. The additional key is obtained from the provided base key as follows: (a) SUPL INIT is sent using SMS or WAP Push and authenticated (as from H-PS) and optionally A key to support secure storage and forward encapsulation (S-SAFE) encrypted in (B) X. Key that supports IP connection between UE 110 and H-PS, where S0024 message is encrypted and authenticated and sent between UE 110 and H-PS. (C) X. A key that supports the IP connection between UE 110 and PDE, where the S0024 message is encrypted and authenticated and sent between UE 110 and PDE in non-proxy mode.

  Each of the three keys mentioned above is established in the sense that there is a deterministic value for every value of the base key. However, from each of these determined keys, an additional key is derived for encryption and authentication, the value of which depends on a random number provided for a special positioning session by the UE and H-PS or PDE. . This key derivation and the accompanying security procedure are the Transport Layer Security (TLS) procedure described in IETF RFC 2246 and this IETF document “Pre-Shared Key Encryption for Transport Layer Security (TLS)”. A modification of PSK-TLS described in “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)” is used. X. If S0024 is used for positioning in emergency VoIP calls and E-PS 282 is not H-PS, a common pre-configured in both UE 110 and E-PS 282 for mutual authentication and encryption It is no longer possible to rely on the basic key.

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

  Method A provides minimal authentication. If the SUPL INIT message indicates the location for the emergency session and the UE 110 is currently engaged in the emergency session, the UE 110 may initialize the network initialization SUPL or X. from the unauthenticated E-SLP or E-PS. S0024 position selection is allowed. Restricting emergency sessions provides some protection. For SUPL, UE 110 selects Method A by not exercising safety procedures with E-SLP 272. In this case, the E-SLP 272 can still prove the UE identifier in a limited manner by the SUPL INIT hash code included in the SUPL POSINIT. Furthermore, the IP address of UE 110 provided to E-SLP 272 by E-CSCF 254 provides some further guarantee of the correct UE identifier. X. For S0024 and SUPL, IMS and SIP forwarding relies on support and certification from V-PLMN 130 and / or H-PLMN 160, so forwarding via IMS or SIP (direct forwarding via mobile terminated IP or UDP / IP) Provides some additional reliability in UE authentication (if is not used).

  Method B is for TLS public key authentication. UE 110 and E-SLP 272 or E-PS 282 as described in IETF RFC 2246, and also in the alternative client authentication mechanism “Secure User Plane Location Architecture” in OMA SUPL 1.0 TLS is used to support public key authentication as described. This mechanism is based on the ITU X .. ITU-X. Supports H-SLP or E-PS authentication by UE using TLS with 509 public key certificate. The public key certificate provides a series of digital signatures, each authenticating the following so that the UE can authenticate the E-SLP or E-PS public key if the UE is provided with at least one basic key authority . The public key authentication TLS procedure supports transfer of a symmetric key used in the next encryption authentication of signal communication, for example, for the next SUPL message. Authentication and encryption between UE 110 and SPC or PDE for non-proxy mode is also supported by these keys or by additional keys derived from these keys. Method B includes SUPL or X.X for E-SLP or E-PS public key certification with one or more basic certification authorities (eg, as defined by OMA) and emergency VoIP calls. Rely on providing keys in UEs that support S0024. This is the authentication of E-SLP 272 or E-PS 282 by UE 110 and, for SUPL, ESLP 272 via the 64-bit SUPL INIT hash included in SUPL POS INIT and sent by UE 110 to E-SLP 272 Guarantee limited authentication of UE 110 by

  For Method B, UE 110 (eg, UICC or UIM) is provided with one or more basic public keys that allow the UE to prove the public key of E-SLP272 or EPS282. UE 110 and E-SLP 272 or E-PS 282 are TLS procedures described in RFC 2246, and shared encryption keys using one or more secure public key transfer procedures, eg, RSA, DSS, or Diffie-Hellman And a message authentication (MAC) key. SUPL or X. The encryption and authentication of the S0024 message is done after establishing a secure TLS connection. For non-proxy mode, the method defined for 3GPP2 non-proxy mode in SUPL 1.0 is according to IETF PSK-TLS between UE 110 and V-SPC or H-SPC in SUPL and between UE 110 and X . Used to generate a shared key for authentication and encryption with the PDE in S0024.

  Method C is for PSK-TLS authentication. UE 110 and E-SLP 272 or E-PS 282 follow the IETF draft “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)” (eg, Support PSK-TLS (as described in 3GPP2 SET or 3GPP2 X.S0024-0 and S.P0110-0). The pre-shared key (PSK) is (a) information that is contributed by UE 110, IMS network (eg, ECSCF 254) and / or E-SLP 272 or E-PS 282 (eg, random information), (b) ) Information sent from or to UE 110 during SIP establishment of emergency call (eg, SIP parameters), (c) Safety from UE 110 (eg, using IPsec, PSK-TLS, TLS) Generated from PCSCF 252 and security information already present in UE 110 to support secure IMS access and / or (d) other information. If UE 110 registers with the HPLMN IMS network via VPLMN 130, the security information in (c) is available.

  The PSK or information used to obtain it is made available to UE 110 and E-SLP 272 or E-PS 282 during SIP registration and / or SIP emergency call initiation and uses PSK-TLS. SUPL or X. S0024 Used for position selection. The trust relationships established during registration and SIP call setup between these entities are used to obtain secure PSK or common information from which secure keys are derived. For SUPL, mutual authentication of UE 110 and E-SLP 272 is then PSK- when the UE establishes an IP (PSK-TLS) connection to E-SLP 272 after transfer of SUPL INIT from E-SLP 272 to UE 110. Assisted using TLS. X. For S0024, the secure PSK contains the remaining safety information 3GPP2 X. S00240 and S.W. Used as a base key derived as described in P01100.

  Method C includes UE 110 and IMS during SIP registration and / or SIP call setup (which means registration of UE 110 in V-PLMN 130 and H-PLMN 160 and mutual authentication of UE 110 and V-PLMN 130). Rely on a secure connection between. If UE 110 does not have UICC / UIM or if there is no roaming agreement between V-PLMN 130 and H-PLMN 160, mutual authentication of V-PLMN 130 and UE 110 and V-PLMN 130 and UE 110 Secure transmission to and from is not achieved during SIP registration and SIP call setup, and any PSK generated will provide even more limited protection.

  Method D is a 3GPP TS 33.220 or 3GPP2 TSG-S draft S.M. It is for authentication by the general bootstrap architecture (GBA) described in P0109. UE 110 and E-SLP 272 or E-PS 282 support GBA. This allows UE 110 and E-SLP 272 or E-PS 282 to obtain a secure shared key from H-PLMN 160. For SUPL, this key is the 3GPP TS 33.220 or 3GPP2 TSG-S draft S.P. Used to support PSK-TLS mutual authentication between UE 110 and E-SLP 272 as described in P0109. This method is used in SUPL 1.0 to support 3GPP proxy mode. The key may also be used for HTTP digest authentication (eg, as described in 3GPP TS 33.220), eg, 3GPP2 TSG-S draft S.P. Used to support TLS with just HTTP digest authentication between UE 110 and E-SLP 272, or other forms of authentication (as described in P0114). X. For S0024, this key is used as the base key from which the remaining security information is obtained.

  Method D uses V-PLMN 130 to enable the transfer of key information from a bootstrapping service function (BSF) at H-PLMN 160 to an ESLP network application function (NAF) at V-PLMN 130. As well as relying on GBA support in H-PLMN 160 and roaming agreement between V-PLMN 130 and H-PLMN 160.

  Method E is either SUPL 1.0 or X. It is for S0024 authentication. For SUPL, if UE 110 is in H-PLMN 160, E-SLP 272 is H-SLP and the existing authentication mechanism defined in SUPL 1.0 is used. X. For S0024, if UE 110 is in H-PLMN 160, E-PS 282 is H-PS and X. The existing authentication mechanism defined in S0024 is used. FIG. 12 shows a block diagram of an embodiment of UE 110, access network 120, E-CSCF 254, and location server 286. Location server 286 is E-SLP 272, GMLC 276, E-PS 282, and / or other entity. For simplicity, FIG. 12 shows only one processor 1210, one memory unit 1212 and one transceiver 1214 for UE 110, and only one processor 1220, one memory unit 1212 for access / network 120, One transceiver 1224, one communication (Comm) unit 1226, and one E-CSCF 254, one processor 1230, one memory unit 1232, one transceiver 1234, and one location server 286 One processor 1240, one memory unit 1242, and one communication unit 1244 are shown. In general, each entity includes a number of processors, memory units, transceivers, communication units, controllers, and so on.

  On the downlink, access points in the base station and / or access network 120 send traffic data, signaling, and pilot to the UE within their coverage area. These various types of data are processed by processor 1220 and coordinated by transceiver 1224 to produce a downlink signal that is transmitted via an antenna. At UE 110, downlink signals from base stations and / or access points are received via antennas to obtain various types of information for location, VoIP, and other services, and are received by transceiver 1214. Adjusted and processed by processor 1210. For example, the processor 1210 decodes the message used for the message flow described above. Memory unit 1212 stores program codes and data for UE 110 and access network 120, respectively. For the uplink, UE 110 transmits traffic data, signaling, and pilot to an access point in base station and / or access network 120. These data are processed by processor 1210 and coordinated by transceiver 1214 to generate an uplink signal that is transmitted via the UE antenna. In access network 120, uplink signals from UE 110 and other UEs are received and coordinated by transceiver 1224 and further obtain various types of information (eg, data, signaling, reports, etc.). To be processed by the processor 1220. Access network 120 communicates with E-CSCF 254 and other entities via communication unit 1226.

  Within E-CSCF 254, processor 1230 processes for E-CSCF, memory unit 1232 stores program code and data about E-CSCF, and communication unit 1234 communicates with other entities. Make it possible to do. The processor 1230 processes the E-CSCF 254 for the message flow described above.

  Within the location server 286, the processor 1240 performs location and / or positioning processing for the location server, the memory unit 1242 stores program codes and data for the location server, and the communication unit 124 Allows the selection server to communicate with other entities. The processor 1240 processes the message flow described above for the location server.

  The techniques described herein can be implemented by various means. For example, these techniques are implemented in hardware, firmware, software, or a combination thereof. For hardware implementation, the processing units used to implement the technology are one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs). , In a field programmable gate array (FPGA), processor, controller, microcontroller, microprocessor, electronic device, other electronic unit designed to perform the functions described herein, or combinations thereof Is done.

  For firmware and / or software implementation, the techniques are implemented by modules (eg, procedures, functions, etc.) that perform the functions described herein. Firmware and / or software code is stored in memory (eg, memory 1212, 1222, 1232 and / or 1242 in FIG. 12) and executed by a processor (eg, processors 1210, 1220, 1230, and / or 1240). The Memory is implemented within the processor or external to the processor.

  Headings are included here for reference and to assist in positioning certain sections. These headings are not intended to limit the scope of the concepts described therein, and these concepts are applicable in other sections throughout the 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, but is to be accorded the widest scope compatible with the principles and novel features disclosed herein.

Claims (62)

  Interact with a location server directed by the visited network to obtain an initial location estimate for the UE to communicate by the visited network to send a request to establish an emergency voice protocol (VoIP) call over the Internet And a user equipment (UE) that operates to set up a call through a visited network to establish an emergency VoIP with a Public Safety Answering Point (PSAP).   The user equipment of claim 1, further operating to utilize a Session Initiation Protocol (SIP) for emergency VoIP calls.   The user equipment of claim 1 further operable to send a SIPRGISTER for registration by the home network for emergency VoIP calls.   The user equipment of claim 2, further operable to send a SIP RGISTER for registration by the visited network for emergency VoIP calls.   5. The user equipment according to claim 4, wherein the SIP RGISTER includes an emergency secret user identifier (ID) formed by a domain name related to the visited network and a pseudo international mobile subscriber identity (IMSI).   5. The user equipment of claim 4, further operative to receive a response for a SIP REGISTER with a temporary public user ID.   The user equipment of claim 2, further operable to send a SIP INVITE as a request to establish an emergency VoIP call.   8. The user equipment of claim 7, further operable to send location information for the UE in SIP INVITE, and wherein an initial location estimate for the UE is obtained based on the location information.   The user equipment of claim 1, further operable to send a location capability in a request to establish an emergency VoIP call, and wherein the location server is selected based on the UE location capability.   The user equipment of claim 1, further operative to send a location capability in a request to establish an emergency VoIP call, and wherein the location server is selected based on location information.   The user equipment of claim 1, wherein the initial position estimate is a provisional position estimate corresponding to a coarse position estimate used for call routing.   The user equipment of claim 1, wherein the initial position estimate is an initial position estimate corresponding to an accurate position estimate for the UE.   The user equipment of claim 1, further operable to receive a request for an update location estimate for the UE from the PSAP and to perform positioning by a location server to obtain an update location estimate.   14. The user equipment according to claim 13, further operable to perform positioning by a location selection server in accordance with secure user plane location (SUPL).   Further X. 14. User equipment according to claim 13, wherein the user equipment is operative to perform positioning by a location selection server according to S0024 location selection.   14. The user equipment of claim 13, further operable to perform positioning by a radio access network according to 3GPP control plane location selection.   The system further operates to access a radio access network (RAN), to establish an IP connection with the network via the RAN, and to locate the local server's IP address for emergency VoIP calls. User equipment.   In addition, to access a wireless local area network (WLAN) using a network access identifier (NAI) that indicates the visited network, to establish a visited network IP connection over the WLAN, and an emergency VoIP call The user equipment of claim 1, wherein the user equipment is operative to find an IP address of a local server for the purpose.   The user equipment according to claim 1, further operating for authentication by a location selection server. Communicating by the visited network to send a request to establish an emergency voice protocol (VoIP) call over the Internet;
Interact with the location server indicated by the visited network to obtain an initial location estimate for the user equipment (UE); and establish emergency VoIP by Public Safety Answering Point (PSAP) Performing call setup via the visited network. Use the Session Initiation Protocol (SIP) for emergency VoIP;
21. The method of claim 20, further comprising: sending a SIP REGISTER to register by a home network or visited network for emergency VoIP; and sending a SIP INVITE as a request to establish an emergency VoIP call. 21. The method of claim 20, further comprising: receiving an update location estimate request for the UE from the PSAP; and positioning by a location server to obtain an update location estimate. Means for communicating by the visited network to send a request to establish an emergency voice protocol (VoIP) call over the Internet;
Means for interacting with a location server directed by the visited network to obtain an initial location estimate for the user equipment (UE); and emergency VoIP by Public Safety Answering Point (PSAP) Means for setting up a call via a visited network to establish a network. Means for using Session Initiation Protocol (SIP) for emergency VoIP;
A means for sending a SIP REGISTER to register by a home network or visited network for emergency VoIP; and means for sending a SIP INVITE as a request to establish an emergency VoIP call 23. Apparatus according to 23. 24. The apparatus of claim 23, further comprising: means for receiving a request for an updated location estimate for the UE from the PSAP; and means for positioning by a location server to obtain an updated location estimate.   To receive a request to route an emergency Internet Voice Protocol (VoIP) call to a user equipment (UE) to a Public Safety Answering Point (PSAP), first to obtain an initial location estimate for the UE A location server that operates to select a PSAP based on its location estimate and to send a response with routing information about the PSAP.   27. The location server of claim 26, further operable to interoperate with the UE to obtain an initial location estimate for the UE.   Further, a home location server for receiving location information for the UE in a request to route an emergency VoIP call, for determining a destination location server based on the location information, and for obtaining an initial location estimate for the UE 27. The location server of claim 26, wherein the location server is operable to interact with the visited location server and the UE.   27. The location server of claim 26, further operable to send a positioning message to the UE to obtain an initial location estimate.   30. The location server according to claim 29, further operable to send a message to the UE using mobile terminated IP, UDP / IP or IP Multimedia Subsystem (IMS) signaling.   30. The location server according to claim 29, further operable to include a location server address in a message sent to the UE, wherein the address is used by the UE to perform positioning.   30. The location server according to claim 29, further operable to include an emergency service indication in a message sent to the UE.   27. The location server according to claim 26, further operable to receive a message to start positioning from the UE, a message including location information and to obtain an initial location estimate for the UE based on the location information.   27. The location server according to claim 26, further operable to receive a message to initiate positioning from the UE, a message including a location relationship measurement, and to obtain an initial location estimate for the UE based on the location relationship measurement.   27. The location server of claim 26, further operable to receive a request for an update location estimate for the UE from the PSAP, to perform positioning by the UE to obtain an update location estimate, and to send an update location estimate to the PSAP.   27. The location server according to claim 26, operable to receive an initial location estimate for a UE from a General Packet Radio Service (GPRS) support node.   27. The method of claim 26, further operable to receive a request for an update location estimate for the UE from the PSAP, send a request to the IP gateway, receive an update location estimate from the IP gateway, and send an update location estimate to the PSAP. Location selection server.   27. The location server according to claim 26, further operable to authenticate by a UE. Receiving a request to route an emergency voice protocol (VoIP) call over a user equipment (UE) to a Public Safety Answering Point (PSAP);
Obtaining an initial location estimate for the UE;
Selecting a PSAP based on an initial location estimate; and sending a response with routing for the PSAP.   40. The method of claim 39, further comprising: sending a message to perform positioning to the UE using mobile terminated IP, UDP / IP or IP Multimedia Subsystem (IMS) signaling. Receiving an update location estimation request for the UE from the PSAP;
40. The method of claim 39, further comprising: positioning by the UE to obtain an updated position estimate; and sending the updated position estimate to the PSAP. Means for receiving a request to route an emergency Internet voice protocol (VoIP) call for a user equipment (UE) to a public security answer point (PSAP);
Means for obtaining an initial position estimate for the UE;
Means for selecting a PSAP based on an initial position estimate; and means for sending a response with routing for the PSAP.   43. The apparatus of claim 42, further comprising means for sending a message to perform positioning to the UE using mobile terminated IP, UDP / IP or IP Multimedia Subsystem (IMS) signaling. And further comprising: means for receiving a request for an update location estimate for the UE from the PSAP; means for positioning by the UE to obtain an update location estimate; and means for sending the update location estimate to the PSAP. 42. Apparatus according to 42.   Interact with location server to obtain initial location estimate for UE to send request to 3GPP2 core network to establish emergency Internet Voice Protocol (VoIP) call to access 3GPP2 access network And operates to perform call setup via the 3GPP2 core network to establish an emergency VoIP call by public safety answer point (PSAP), and the PSAP is selected based on an initial location estimate. User equipment (UE).   Furthermore, safe user plane position selection (SUPL), X. 46. The apparatus of claim 45, wherein the apparatus is operative for positioning by a location server according to S0024, or 3GPP2 control plane location selection.   46. The apparatus of claim 45, further operable to receive an updated location estimate for the UE from the PSAP, to perform positioning by a location selection server to obtain an updated location estimate, and to send the updated location estimate to the PSAP. Accessing the 3GPP2 access network by a user equipment (UE);
Sending a request to the 3GPP2 core network to establish an emergency Internet Voice Protocol (VoIP) call;
Registering via the home network;
Interworking with a location server to obtain an initial location estimate for the UE; and performing call setup via a 3GPP2 core network to establish an emergency VoIP call via public stability answer point (PSAP) , The PSAP is selected based on an initial position estimate.   49. The method of claim 48, further interacting with a location server to obtain an initial location estimate for the UE, wherein the initial location estimate is used to select a PSAP. Receiving an update location estimation request for the UE from the PSAP;
49. The method of claim 48, further comprising: positioning by a location server to obtain an updated position estimate; and sending the updated position estimate to the PSAP. Means for accessing a 3GPP2 access network by a user equipment (UE);
Means for sending a request to the 3GPP2 core network to establish a voice (VoIP) call over an emergency Internet protocol;
Means for registering via the home network;
Means for interacting with a location server to obtain an initial location estimate for the UE; and call setup via a 3GPP2 core network to establish an emergency VoIP call by public stability answer point (PSAP) Comprising means for performing
PSAP is a device that is selected based on an initial position estimate. Means for receiving an update location estimation request for the UE from the PSAP;
52. The apparatus of claim 51, comprising: means for positioning by a location server to obtain an updated position estimate; and means for sending an updated position estimate to the PSAP.   A second destination selected by the first visited network to communicate with the first visited network to send a request to establish a voice protocol (VoIP) call over the emergency Internet, and for the emergency VoIP call User equipment (UE) that operates to communicate over a network.   In addition, a call setup is performed by the SIP server to receive a Session Initiation Protocol (SIP) identifier in the second visited network from the first visited network and to establish an emergency VoIP call by the second visited network. 54. The UE of claim 53, wherein the UE operates for.   54. The UE of claim 53, wherein the emergency VoIP is sent from the first visited network to the second visited network.   54. The UE of claim 53, wherein emergency VoIP is routed to a public safety answer point (PSAP) based on a Location Routing Number (LRN).   Communicating with a visited network to send a request to establish a voice protocol (VoIP) call over an emergency internet, authenticating a location server selected by the visited network for an emergency VoIP call, and emergency VoIP User equipment (UE) that operates to interact with a location server to obtain at least one location estimate for a call.   In addition to receive a message to start the location process from the location server and to authenticate the location server if the message indicates the emergency call location process and the UE is engaged in an emergency VoIP call 58. The UE of claim 57, wherein the UE operates.   58. The UE of claim 57, further operable to perform Transport Layer Security (TLS) public key authentication using a base key stored at the UE to prove the location server public key. .   Operates to generate a pre-share key (PSK) based on secure information available at the UE and visited network and to authenticate using the pre-shared key 58. The UE according to item 57.   58. The UE of claim 57, further operable to perform authentication for proof based on a Generic Bootstrap Architecture (GBA).   Furthermore, safe user plane position selection (SUPL) version 1.0 or X. 58. The UE of claim 57, operable to perform authentication according to S0024.

Images