Multiple Location Retrieval Function (LRF) Network Having Location Continuity

Abstract

An IMS emergency call is reliably handed off within the PS domain or from the PS domain to the CS domain, by providing continuous support of location of a user device on behalf of a PSAP. The invention provides for handover of an IMS emergency call with EPS/GPRS access in a multi-LRF environment. Emergency location services for CS based emergency and/or IMS based emergency location services are often provided by multiple emergency location service providers. The information element that is critical for supporting Location Continuity in Multi-LRF environment can be either the assigned ESQK or the Serving LRF address. ESQK is assigned by the Serving LRF during IMS emergency call setup, and is used to uniquely identify the emergency service provider that operates the serving LRF. A simpler implementation uses the Serving LRF's address to identify the Serving LRF during and after the handover (PS-PS or PS-CS).

Description

This application claims priority from U.S. Provisional Application No. 61/213,084, entitled “Multiple Location Retrieval Function (LRF) Network Having Location Continuity” to Yinjun Zhu, filed May 5, 2009, the entirety of which is explicitly incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to wireless telecommunication. More particularly, it relates to 3GPP (3^rd Generation Partnership Project) location continuity using long term evolution (LTE)/System Architecture Evolution (SAE) access.

2. Background of the Related Art

Long Term Evolution (LTE) of the 3^rd Generation Partnership Project (3GPP) is the next stage of wireless communications, introduced in the 3GPP Release 8. This 3GPP project improves the Universal Mobile Telecommunications System (UMTS) mobile phone standard to provide an enhanced user experience and simplified technology for next generation mobile broadband. Much of 3GPP Release 8 is oriented towards a 4^th Generation (4G) mobile communications technology and an all-Internet Protocol (IP) architecture system. A copy of “3^rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Application Part (MAP) Specification; (Release 8)”, 3GPP TS 29.002 V8.1.0 (2007-03), is filed herewith by way of Information Disclosure Statement, and is incorporated by reference into this background in its entirety.

SAE is an evolution of the General Packet Radio Service (GPRS) core network, but it's an all-IP network. The main component of the SAE architecture is the Evolved Packet Core (EPC), also known as the SAE Core. The EPC will serve as equivalent of GPRS networks (via the Mobility Management Entity, Serving Gateway and PDN Gateway subcomponents). The subcomponents of the EPC include a Mobility Management Entity (MME), a Serving Gateway (S-GW), and a Packet Data Network Gateway (PDN-GW).

The MME is the key control-node for the LTE access-network. It is responsible for idle mode UE (User Equipment) tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the SGW for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the HSS). The Non-Access Stratum (NAS) signaling terminates at the MME and it is also responsible for generation and allocation of temporary identities to UEs. It checks the authorization of the UE to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. Lawful interception of signaling is also supported by the MME. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN. The MME also terminates the S6a interface towards the home HSS for roaming UEs.

The SGW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and PDN). For idle state UEs, the SGW terminates the DL data path and triggers paging when DL data arrives for the UE. It manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.

The PDN provides connectivity to the UE to external packet data networks by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one PDN for accessing multiple PDNs. The PDN performs policy enforcement, packet filtering for each user, charging support, lawful Interception and packet screening. Another key role of the PDN is to act as the anchor for mobility between 3GPP and non-3GPP technologies such as WiMAX and 3GPP2 (CDMA 1X and EvDO).

Depending on the deployments of a telephony network operator, regional requirements, reliability of emergency services, and other operational reasons, it is very common in North America that a telephony network (wireless or fixed line) is divided into different emergency service regions. The emergency location services of the service regions may be provided by a single emergency location service provider, or very often by multiple emergency location service providers. Sometimes load balancing and redundancy requirements of emergency location services require multiple emergency location service providers for a network.

Location Retrieval Function (LRF) is a functional entity that handles the retrieval of location information for a user entity (UE).

For the existing 3GPP circuit switched (CS) based emergency location services defined in 23.271 of the 3GPP Specification, when a location estimate is required for a target user equipment (UE)/mobile station (MS) with an established emergency call in a state of inter-visited mobile switching center (VMSC)/MSC server handover, all location request related messages are sent via Mobile Application Part (MAP)/E interface piggy-backed in MAP_FORWARD_ACCESS_SIGNALLING and MAP PROCESS_ACCESS_SIGNALLING between the visited and serving MSCs/MSC servers. The serving GMLC only needs to communicate with an anchor MSC/MSC server during an emergency call.

In the Release 9 version of an SAE network, an IP Multimedia Subsystem (IMS) emergency call will be provided using the underlying IP Bearer established over E-UTRAN/UTRRN access network. It is very important to note that the IMS Emergency procedure defined in 23.167 is independent from the procedures of SAE/CPRS, including the Control Plane Location Service procedures, the only interworking function between these two service domains resides in the serving LRF. Some challenges/issues have been identified when there are multiple IMS emergency location service providers (i.e. multiple LRFs) in a network:

There is not a signal tunneling mechanism (like the one in the CS domain) available, the serving LRF needs to know the current serving location server (GMLC/MPC for control plane or E-SLP for user plane) and the serving node after a handover (either PS-PS or PS-CS) crossing the service regions of the emergency location service providers.

Due to the fact that IMS domain and signaling domain of U-IRAN Access and Location Services are decoupled, it is possible that IP Bearer has been established and emergency NI-LR has been initiated, but a handover occurs crossing the service regions of the emergency location service providers before an IMS Emergency call is initiated. Or it is possible that the IP bearer of an emergency IMS call would not yet be released after the IMS emergency call is terminated, another emergency call is placed using the same bearer (but where the emergency location area would be different).

MME Pool may be deployed; the MME may be dynamically assigned. But the inventor herein appreciates that there is not a fixed mapping between E-Cell and MME, thus the serving LRF cannot use the serving E-Cell ID that is available via IMS signaling to determine the serving node and serving location server after a handover crossing the service areas of emergency location service providers.

It has been noted that User Plane Location Service using OMA SUPL may also be used for IMS emergency location services, but there are limitations of OMA SUPL 2.0. The recommended solution preferably should support handover scenarios from a UP based emergency location service provider to a CP based emergency location service provider, but the requirements for an additional User Plane are not in the scope of 3GPP. Although in 3GPP Rel-9, the scope of emergency location continuity is limited to one single carrier, and the scope of IMS emergency voice call continuity (VCC) is limited to the PS to CS direction only. (Voice call continuity (VCC) is an IMS service standardized in 3GPP TS 23.206. Using VCC, ongoing calls can be switched from wireless to WiFi at any time using 2G/3G/WiFi handsets, or transferred at any time to another handset.)

Using current technology, emergency location services associated with IMS emergency calls may be interrupted when there are multiple LRFs deployed in the network. In such a case, a public service access point (PSAP) would not be supported following a handover of an IMS emergency call.

SUMMARY OF THE INVENTION

In accordance with the principles of the present invention, a location retrieval function network device in a multiple location retrieval function network to ensure voice call continuity (VCC) during a handover of an emergency call from a user wireless device comprises receiving control of an initiated IP Multimedia Subsystem (IMS) emergency call from a user wireless device, and participating in a handover of the IMS emergency call from a first emergency services network to a second emergency services network. Either an emergency services routing key (ESRK) or an emergency services query key (ESQK) is routed from a source server in the first emergency services network to a target server in the second emergency services network.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present invention will become apparent to those skilled in the art from the following description with reference to the drawings:

FIG. 1A illustrates a high-level call flow example of Location Continuity for IMS Emergency Call in a Multi-LRF 3GPP network that deploys control plane location services for IMS emergency, in accordance with the principles of the present invention.

FIG. 1B shows FIG. 1A with descriptive captions associated with various steps of the illustrated call flow.

FIG. 2 shows messaging between network elements supporting location continuity for handover of an IMS emergency call, in accordance with the principles of the present invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The present invention provides for the reliable handoff of an IMS emergency call within the PS domain or from the PS domain to the CS domain, by providing continuous support of location of a user equipment (UE) device on behalf of a Public Service Access Point (PSAP), particularly in a multi-LRF network environment.

A VMSC/MSC server procedure for Inter-VMSC/MSC server handover is provided to handle handover. When a location estimate is required for a target UE with an established call in a state of inter-VMSC/MSC server handover, the serving location area ID is preferably used by the visited MSC /MSC server to identify the correct RAN to serve the location request. All location request related messages are preferably sent via MAP/E interface piggy-backed in MAP_FORWARD_ACCESS_SIGNALLING and MAP PROCESS_ACCESS_SIGNALLING between the visited and serving MSCs/MSC servers.

In the case where a request for positioning arrives during the handling of an ongoing handover, if during the ongoing handover procedure a request for location information arrives, the request is preferably suspended until the handover is completed. On completion of the handover, the location preparation procedure may then continue.

In the case of hard handovers in Iu mode, e.g. inter RNC hard handover, or Serving RNC relocation, and inter- MSC, MSC Server or SGSN handovers, the ongoing positioning process is aborted on Iu level. In soft handovers where the Serving RNS and Ilu are relocated, any ongoing positioning process is also aborted on Iu level. The MSC, MSC Server or SGSN shall restart the Iu aborted location requests with the new Serving RNC. The new SGSN, however, shall not restart the location request after inter SGSN Routing Area Update or inter SGSN relocation. During intra and inter RNC soft and softer handovers, the existing RRC connection can normally be used without any need to abort the on-going positioning process on Iu level.

The invention also provides for handover of an IMS emergency call with EPS/GPRS access in a multi-LRF environment. As a deployment option in North America, the emergency location services for CS based emergency and/or IMS based emergency location services may be provided by a single emergency location service provider, or very often by multiple emergency location service providers. Handover of the IP bearer for an established or not yet established IMS emergency call may occur within the PS domain (i.e. intra E-UTRAN, intra UTRAN, E-UTRAN to UTRAN, UTRAN to E-UTRAN or E-UTRAN to HRPD) as defined in TS 23.401 [42], TS 23.402 [43] and TS 23.060 [15]. Handover of an already established IMS emergency call may also occur from the PS domain to the CS domain using single radio voice call continuity (SRVCC) as defined in TS 23.216 [41]. When such an event occurs in a context where location support for the emergency call is required on the source side, continuity of location support may be required on the target side. In this case, the location solution employed on the source and target access sides may stay the same or may change. In addition, some reconfiguration of the associated location server or servers (e.g. GMLC, LRF, E-SLP) and serving node may be needed whether or not the solution changes. Once the IMS emergency call is established, the serving LRF preferably remains the same after possible sequential handovers.

Some potential alternative solutions for supporting LCS Continuity in Multi-LRF environment have been identified:

Option 1: A central location server/register caches all the location information of an IMS emergency caller. At the minimum, the location information cached in the central location server includes the current Serving Node Identity, current Serving Location Server address, and optional last known location estimates.

Option 2: The serving LRF Identity (either LRF address or ESQK that the Serving LRF assigned to the IMS emergency call) is passed to a Source Location Server, Source Serving Node, Target Serving Node and Target Location Server. The Target Location Server uses the LRF Identity to determine where to send a handover location report. It should be noted that the LRF Identity is preferably included in the handoff signalling from the source serving node to the target serving node.

There are some other alternatives that had been considered, e.g., ensuring that the first Serving Node Identity is passed to the Target Serving Node and Target GMLC, in which case the Target GMLC can use the first Serving Node Identity to determine the actual Serving LRF. However, since the IMS Emergency Call setup procedure is independent from the procedure of IP Bearer Setup, PS handoff may already have happened before the IMS call is initiated. In addition, the MME Pool feature may be implemented, in which case there is no fixed mapping from Serving Node to Serving GMLC. A similar option ensures that the Source Serving Node always send the Target Serving Node Identity to the Target GMLC, but this option has the same limitations.

Another discussed alternative is to use ISUP signalling to pass the key information during the single radio-voice call continuity (SR-VCC) procedure. However, this alternative was rejected by the industry for lack of support.

The information element that is critical for supporting Location Continuity in Multi-LRF environment can be either the assigned ESQK or the Serving LRF address. ESQK is assigned by the Serving LRF during IMS emergency call setup per 23.167, and is used to uniquely identify the emergency service provider that operates the serving LRF. However, each emergency service provider may own a large ESQK pool for its service regions. A simpler implementation uses the Serving LRF's address to identify the Serving LRF during and after the handover (PS-PS or PS-CS).

FIG. 1A illustrates a high-level call flow example of Location Continuity for IMS Emergency Call in a Multi-LRF 3GPP network that deploys control plane location services for IMS emergency, in accordance with the principles of the present invention. FIG. 1B shows FIG. 1A with descriptive captions associated with various steps of the illustrated call flow.

In particular, as shown in step 1 of FIGS. 1A and 1B, following a request for an emergency call from a wireless device 107, a UE establishes an emergency PDN connection for E-UTRAN access or an emergency PDP context for UTRAN PS access. The serving MME (MME A) initiates an emergency NI-LR location procedure and a Subscriber Location Report with UE identity, emergency event indicator, Serving Node Identity and serving cell identity to the GMLC that MME A is associated with by configuration. Since no Serving LRF Address information is included in the report, GMLC A forwards the report to the LRF determined by the serving cell identity.

In step 2, at some later time, a PS to PS handover occurs before an IMS based emergency call is initiated.

In step 3, MME B (Target MME) initiates a Subscriber Location Report with UE identity, handover event indicator, Serving Node Identity and serving cell identity, to GMLC B to which MME B is associated based on configuration.

In step 4, since no Serving LRF Address information is included in the report, GMLC B forwards the received message to the LRF that is determined by the serving cell identity.

In step 5, an IMS emergency call is initiated by the UE to the Emergency Call Session Control Function (E-CSCF) per 23.167.

In step 6, based on the serving cell identity that is included in the IMS SIP INVITE signalling, the E-CSCF determines that the serving LRF is LRF B and sends a request to LRF B requesting emergency call routing instructions per 23.167.

In step 7, based on the serving cell identity and optional other location information provided, LRF B determines the PSAP that the IMS emergency call should be routed to, and assigned an ESQK to the call. LRF B then sends the assigned ESQK back to the E-CSCF.

In step 8, based on the serving cell identity, LRF B determines that the serving GMLC is GMLC B, then it sends a request to GMLC B for updated location.

In step 9, based on the cached information of IMS emergency call instances, GMLC B matches the UE identity and determines the Serving Node. It then initiates a MT-LR procedure and sends Provide Subscriber Location with UE identity, and a Serving LRF Address to MME B. MME B caches the Serving LRF Address. Depending on whether or not Control Plane Location is deployed, the MME B may initiate location procedure in the radio access network.

In step 10, another handover occurs, as part of the handover procedure, and MME B sends the Serving LRF Address in the handover request to MME C (Target Serving Node). Optionally MME B sends the handover location report to the serving GMLC (GMLC B) and Serving LRF (LRF B) with the UE's identity, Source Serving Node Identity, Target Serving Node Identity and a handover event indicator.

In step 11, upon completion of handover, MME C initiates a Subscriber Location Report message with the UE's identity, handover event indicator, serving cell identity, Serving Node Identity and Serving LRF Address to the associated GMLC (GMLC C) based on its configuration.

In step 12, when receiving a handover location report with the Serving LRF Address, GMLC C forwards the report to LRF B indicated by the Serving LRF's Address. If the PSAP requests an updated location of the UE, LRF B uses the Serving Node Identity to determine the Serving GMLC, and the serving cell identity to determine the Serving Node, and initiates MT-LR location procedures.

Option 2, shown in FIGS. 1A and 1B, fulfils the requirements of supporting all the scenarios of PS-to-PS handover and PS-to-CS handover, while Control Plane solutions are supported in the source and target networks. It should be noted that supporting IMS emergency call related User Plane location continuity is out of the scope of the Rel-9 recommendations. However, for information purposes, when a User Plane solution is deployed in the source network, it is recommended that the SLg/Lg interface (excluding E-SMLC/SMLC/SAS) should also be supported as part of the requirements to support Location Continuity in a multi-LRF environment, and then all possible handover scenarios are supported.

Below are preferable requirements to support location continuity in a multi-LRF environment. The following table summarizes the support of different handover scenarios of the proposed solution (Option 2). Note that in all cases, in a multi-LRF deployment environment, the LRF that was originally assigned to the IMS emergency call as was conventionally known must be retained after handover to avoid any impact to the emergency center/PSAP, although the network configuration for normal emergency call initiation may associate the target serving cell, and target serving GMLC, with a different LRF.

Source	Target	Source	Target
Access	Access	Location	Location
Side(s)	Side(s)	Solution	Solution	Reconfiguration Requirements
E-	E-	TS	TS	Either (a) Source side SGSN or
UTRAN,	UTRAN,	23.271	23.271	MME sends a location report for
UTRAN	UTRAN			handover with the UE identity,
PS	PS			target side SGSN or MME identity
				to the source side GMLC and the
				serving LRF;
				Or (b) Target side SGSN or MME
				sends location report for handover
				with UE identity, its own identity
				and the serving LRF address to
				the target side GMLC which
				forwards the serving LRF based
				on the Serving LRF address. The
				serving LRF address is passed
				during the handover procedure
				from source serving node to target
				serving node.
				LRF replaces the source side
				GMLC with the target side GMLC
				if the GMLCs are different, and the
				source side serving node with the
				target side serving node if they are
				different.
E-	E-	TS	OMA	(Note 3)
UTRAN,	UTRAN,	23.271	SUPL	Source side SGSN or MME sends
UTRAN	UTRAN		[38, 39]	a location report for handover with
PS	PS		(Note 1)	the UE identity, target side SGSN
				or MME identity to the source side
				GMLC and the serving LRF.
				Source side GMLC updates the
				serving LRF
				LRF replaces the source side
				GMLC with the target side E-SLP,
				and the source side serving node
				with null, indicate UP is supported
				at the target. LRF transfers the UE
				identity or address (e.g. IP
				address) to the target side E-SLP
E-	E-	OMA	TS	(Note 3)
UTRAN,	UTRAN,	SUPL	23.271	UP is deployed together with SLg
UTRAN	UTRAN	[38, 39]	(Note 1)	interface on the source side.
PS	PS			Either (a) Source side SGSN or
				MME sends a location report for
				handover with the UE identity,
				target side SGSN or MME identity
				to the source side GMLC/E-SLP
				and the serving LRF.
				Or (b) Target side SGSN or MME
				sends location report for handover
				with UE identity, its own identity
				and the serving LRF address to
				the target side GMLC which
				forwards the serving LRF based
				on the Serving LRF address. The
				serving LRF address is passed
				during the handover procedure
				from source serving node to target
				serving node.
				LRF replaces the source side
				GMLC with the target side GMLC
				if the GMLCs are different, and the
				source side serving node with the
				target side serving node if they are
				different.
				Updated location will be retrieved
				via UP.
E-	E-	OMA	OMA	None identified
UTRAN,	UTRAN,	SUPL	SUPL
UTRAN	UTRAN	[38, 39]	[38, 39]
PS	PS
E-	HRPD	TS	OMA	(Note 3)
UTRAN		23.271	SUPL	Source side SGSN or MME sends
			[38, 39]	a location report for handover with
				the UE identity, target side SGSN
				or MME identity to the source side
				GMLC and the serving LRF.
				Source side GMLC updates the
				LRF
				LRF replaces the source side
				GMLC with the target side E-SLP,
				and the source side serving node
				with null, indicate UP is supported
				at the target. LRF transfers the UE
				identity or address (e.g. IP
				address) to the target side E-SLP
E-	UTRAN	TS	TS	Either (a) Source side SGSN or
UTRAN,	CS	23.271	23.271	MME sends a location report for
UTRAN	GERAN			handover with the UE identity,
PS	CS			target side SGSN or MME identity
				to the source side GMLC and the
				serving LRF.
				Or (b) Target side SGSN or MME
				sends location report for handover
				with UE identity, its own identity
				and the serving LRF address to
				the target side GMLC which
				forwards the serving LRF based
				on the Serving LRF address. The
				serving LRF address is passed
				during the handover procedure
				from source serving node to target
				serving node.
				LRF replaces the source side
				GMLC with the target side GMLC
				if the GMLCs are different, and the
				source side serving node with the
				target side serving node if they are
				different.
E-	UTRAN	OMA	TS	(Note 3)
UTRAN,	CS	SUPL	23.271	OMA SUPL is deployed together
UTRAN	GERAN	[38, 39]		with SLg interface.
PS	CS			Either (a) Source side SGSN or
				MME sends a location report for
				handover with the UE identity,
				target side SGSN or MME identity
				to the source side GMLC/E-SLP
				and the serving LRF.
				Or (b) Target side SGSN or MME
				sends location report for handover
				with UE identity, its own identity
				and the serving LRF address to
				the target side GMLC which
				forwards the serving LRF based
				on the Serving LRF address. The
				serving LRF address is passed
				during the handover procedure
				from source serving node to target
				serving node.
				LRF replaces the source side
				GMLC with the target side GMLC
				if the GMLCs are different, and the
				source side serving node with the
				target side serving node if they are
				different.
				Updated location will be retrieved
				via UP.
E-	1xRTT	TS	J-STD-	Either (a) Source side SGSN or
UTRAN		23.271	036B [44]	MME sends a location report for
			(Note 2)	handover with the UE identity,
				target side 1xRTT MSC identity to
				the source side GMLC and the
				serving LRF.
				Or (b) Target side 1xRTT MSC
				sends location report for handover
				with UE identity, its own identity
				and the serving LRF address to
				the target side GMLC/MPC which
				forwards the serving LRF based
				on the Serving LRF address. The
				serving LRF address is passed
				during the handover procedure
				from source serving node to target
				serving node.
				LRF replaces the source side
				GMLC with the target side
				GMLC/MPC if they are different,
				and the source side serving node
				with the target side serving node if
				they are different.
				Source side GMLC or Target side
				updates the LRF (Note 2)
				LRF replaces the source side
				GMLC with location support on the
				target side (Note 2)
E-	1xRTT	OMA	J-STD-	(Note 3)
UTRAN		SUPL	036B [44]	OMA SUPL is deployed together
		[38, 39]	(Note 2)	with SLg interface.
				Either (a) Source side SGSN or
				MME sends a location report for
				handover with the UE identity,
				target side 1xRTT MSC identity to
				the source side GMLC/E-SLP and
				the serving LRF.
				Or (b) Target side 1xRTT MSC
				sends location report for handover
				with UE identity, its own identity
				and the serving LRF address to
				the target side GMLC/MPC which
				forwards the serving LRF based
				on the Serving LRF address. The
				serving LRF address is passed
				during the handover procedure
				from source serving node to target
				serving node.
				LRF replaces the source side
				GMLC with the target side
				GMLC/MPC if they are different,
				and the source side serving node
				with the target side serving node if
				they are different.
				Updated location will be retrieved
				via UP. The target side updates the
				LRF (Note 2)
				The LRF replaces the source side
				E-SLP with location support on the
				target side (Note 2)

It is to be noted that the present invention applies equally to a location solution for an intra E-UTRAN or intra UTRAN PS handover, as well as for an inter-RAT handover.

FIG. 2 shows messaging between network elements supporting location continuity for handover of an IMS emergency call, in accordance with the principles of the present invention.

In particular, as shown in step 1 of FIG. 2, following the request for an emergency call, the UE establishes an emergency PDN connection for E-UTRAN access as defined in TS 23.401 [42] or an emergency PDP context for UTRAN PS access as defined in TS 23.060 [15].

In step 2, as part of an emergency location service procedure, an NI-LR location session is initiated at the radio access network.

In step 3, the serving MME or SGSN (hereafter referred to as the source SGSN or MME) sends a Subscriber Location Report with UE identity(ies), emergency event indicator, serving cell identity, serving node identity and location estimates to the GMLC that it is associated by configuration. The GMLC determines the serving LRF based on the serving cell identity and forwards the Subscriber Location Report to the serving LRF.

In step 4, the UE may then establish an IMS emergency call as defined in TS 23.167 [36a] during which an LRF is determined based on the serving cell identity.

In step 5, at some later time, the serving MME or SGSN (hereafter referred to as the source SGSN or MME) may receive a request from an associated GMLC (hereafter referred to as the source GMLC) for the location of the UE using the location solution defined in accordance with this invention is used on the source access side requested by the serving LRF. The request contains the UE identity, serving LRF address and other information elements.

In step 6, if updated location is required in the location request received in step 5, a location session starts at the radio access network. If step 2 occurs or if support for an NI-LR is required, the source SGSN or MME starts a location session with the serving RNC or an E-SMLC, in each case respectively, to obtain the location of the UE.

In step 7, a request is later sent to the source SGSN or MME from the serving eNodeB (for E-UTRAN access) or serving RNC (for UTRAN access) for a handover to a particular target eNodeB (for handover to E-UTRAN) or target

RNC (for handover to UTRAN PS) or target MSC server (for handover to UTRAN CS or GERAN CS) or target cell associated with a particular 1xRTT MSC (for handover to 1xRTT) or HRPD target cell (for handover to HRPD).

In step 8, for handover to E-UTRAN, UTRAN PS, UTRAN CS or GERAN CS, the source MME or SGSN sends a Handover Request message to the target MME, SGSN, MSC server or MSC server (hereafter referred to as the target serving node) in each case respectively as defined in technical specification (TS) 23.401 [42], TS 23.060 [15] or TS 23.216 [41]. For handover from E-UTRAN to 1xRTT, the source MME sends a Handover Request message to a target 1xRTT IWS as described in TS 23.216 [41]. The Handover Request includes the serving LRF address if it is known to the source MME or SGSN. For handover from E-UTRAN to HRPD, this step does not occur.

In step 9, the rest of the handover preparation and execution procedure is completed as defined in TS 23.401 [42], TS 23.402 [43], TS 23.060

or TS 23.216 [41].

In step 10, the location session started in step 3 may terminate normally before step 9 is complete. If not, the source SGSN or MME shall abort the session once step 9 is complete. This may lead to the provision of a location estimate for the UE to the source SGSN or MME.

In step 11, if the location solution defined in accordance with this invention is used on the source side and step 6 occurred, the source SGSN or MME returns a Provide Subscriber Location response to the source GMLC carrying any location estimate obtained previously for the UE. Depending on configuration information in the source SGSN or MME (e.g., which may be related to the source and target serving node identities, the location capabilities of the UE and whether the UE is roaming or not), the Provide Subscriber Location response may convey the identity of the target serving node.

In step 12, if the location solution defined in accordance with this invention is used on the source side but steps 6 and 11 do not occur, the source SGSN or MME may depending on configuration information in the source SGSN or MME (e.g. as in step 11), send a Subscriber Location Report to the GMLC associated with the source SGSN or MME, carrying the UE identity (IMSI, MSISDN and/or IMEI), and an event type indicating handover and the identity of the target serving node.

In step 13, the source GMLC acknowledges the message in step 12 if this occurs.

In step 14, depending upon configuration information in the target serving node (e.g., which may be related to the source and target serving node identities, the location capabilities of the UE and whether the UE is roaming or not), the target serving node may send a Subscriber Location Report to a GMLC after handover in step 9 is complete if the location solution defined in accordance with this invention will be used on the target side. The Subscriber Location Report carries the UE's identity (IMSI, MSISDN and/or IMEI), an event type indicating handover, the identity of the target serving node, and the serving LRF's address. The target serving node may determine the address of the target GMLC from configuration information. As the serving LRF address is received, the target GMLC forwards the message to the serving LRF identified by the serving LRF address.

In step 15, the serving LRF returns an acknowledgement of the message in step 14 to the target GMLC, which forwards the acknowledgement to the target serving node.

In step 16, reconfiguration of the LRF and the source and target location servers may occur as summarized in the above table, which may involve removal of a source location server, assignment of a new target location server and/or updating of information in the LRF.

In step 17, if the LRF needs an updated location estimate for the UE after handover has occurred. The LRF may instigate an MT-LR request via the target GMLC if the location solution defined in accordance with this invention will be used on the target side. This will involve a repetition of step 5 on the target side if the location solution defined in accordance with this invention is used. Steps 5 to 16 may also be repeated on the target side to support a further handover if the previous handover was to either E-UTRAN or UTRAN PS.

It will be evident to those of ordinary skill in the art that the present invention can be easily enhanced for future needs, e.g., for IMS emergency handover from CS to PS.

While the invention has been described with reference to the exemplary embodiments thereof, those skilled in the art will be able to make various modifications to the described embodiments of the invention without departing from the true spirit and scope of the invention.

Claims

1. A retrieval function network device in multiple location retrieval function network to ensure voice call continuity (VCC) during handover of an emergency call from a user wireless device, comprising:

receiving control of an initialed IP Multimedia Subsystem (IMS) emergency user call from a user wireless device;

participating in a handover of said IMS emergency call from a first emergency services network to a second emergency services network; and

routing an emergency services routing key (ESRK) of an emergency services query key (ESQK) from a source server in said first emergency services network to a target server in said second emergency services network.

2-12. (canceled)