Content for TS 23.271 Word version: 17.0.0

1… 5… 6… 6.2… 7… 8… 9… 9.1.1A… 9.1.2… 9.1.5… 9.1.6… 9.1.8… 9.1.9… 9.1.12… 9.1.13… 9.1.15… 9.1.19… 9.2… 9.2.2… 9.2.3… 9.3… 9.4… 9.5… 9.6… 10… 11… A… B… E F…

9.4 Exception Procedures 9.4.1 Procedures in the VMSC /MSC server 9.4.3 Procedures in the SGSN 9.4.3a Procedures in the MME 9.4.5 Handover handling
...

9.4 Exception Procedures p. 140

The procedures in this clause apply to all variants of an MT-LR, NI-LR and MO-LR where a Location Request message has been sent either to RAN, for a UE with GERAN or UTRAN access, or to an E-SMLC, for a UE with E-UTRAN access, in order to request some location service (e.g. provision of a location estimate for a target UE or transfer of assistance data to a target UE).

9.4.1 Procedures in the VMSC /MSC server p. 140

After the VMSC /MSC server has requested a location service for a particular UE from RAN, certain events may occur that may temporarily or permanently interfere with the location service attempt. For each such event notified to the VMSC /MSC server, the VMSC /MSC server shall employ one of the following error recovery actions.

Restart the Location Service

This action shall be employed for any event that temporarily impedes a location service attempt and cannot be delayed until the location service attempt is complete. When such an event is notified to the VMSC /MSC server, it shall immediately cancel the location service attempt and the associated signalling dialogue with RAN, if this still exists by sending a "stop reporting" message to RAN. The "stop reporting" message shall contain the reason for the location procedure cancellation in A/Gb mode or the indication about the type of location request to cancel (e.g. direct) in Iu mode.

After aborting the location request dialogue with RAN, the VMSC /MSC server may queue the location service request until the event causing the restart has terminated (if not already terminated). The VMSC /MSC server may optionally wait for an additional time period (e.g. if the queuing delay is minimal) to ensure that any resources allocated in and by RAN have time to be released. The VMSC /MSC server may then send another location service request to RAN associated with the target UE.

Abort the Location Service

This action shall be employed for any event that permanently impedes a location service attempt, such as loss of the dedicated signalling channel to the target UE. When such an event is notified to the VMSC /MSC server, it shall cancel the current location service attempt and the associated signalling dialogue with RAN, if still existing, by sending a "stop reporting" message to RAN. The "stop reporting" message shall contain the reason for the location procedure cancellation in A/Gb mode or the indication about the type of location request to cancel (e.g. direct) in Iu mode. The VMSC /MSC server shall then return an error response to the client or network entity from which the location request was originally received. The VMSC /MSC server shall also release all resources specifically allocated for the location attempt.

The following Table indicates the appropriate error recovery procedure for certain events. For events not listed in the Table, the VMSC /MSC server need take no action.

Table 9.1: LCS Error Recovery Procedures in the VMSC /MSC server for certain Events

Event	VMSC /MSC server Error Recovery
Release of radio channel to the UE	Abort
Any error response from RAN except for SRNC relocation or inter-MSC handover	Abort
In Iu mode inter RNC hard handover, SRNC relocation and inter- MSC or MSC server handover	Abort on Iu level Restart after process is completed
In A/Gb mode inter-MSC Handover and inter-BSC handover	Restart after handover is completed
InterSystem handover	Restart after handover is completed

If RAN is in an overload condition, it may reject a location request by indicating congestion. The VMSC /MSC server may reduce the frequency of future location service requests until rejection due to overload has ceased.

9.4.2 Void

9.4.3 Procedures in the SGSN p. 141

After the SGSN has requested a location service for a particular UE from RAN, certain events may occur that may temporarily or permanently interfere with the location service attempt. For each such event notified to the SGSN, the SGSN shall employ one of the following error recovery actions.

Restart the Location Service

This action shall be employed for any event that temporarily impedes a location service attempt and cannot be delayed until the location service attempt is complete. When such an event is notified to the SGSN, it shall immediately cancel the location service attempt and the associated signalling dialogue with RAN, if this still exists by sending a "stop reporting" (Iu mode) or "location abort" (A/Gb mode) message to RAN. The "stop reporting"/"location abort" message shall contain the reason for the location procedure cancellation.

After aborting the location request dialogue with RAN, the SGSN may queue the location service request until the event causing the restart has terminated (if not already terminated). The SGSN may optionally wait for an additional time period (e.g. if the queuing delay is minimal) to ensure that any resources allocated in and by RAN have time to be released. The SGSN may then send another location service request to RAN associated with the target UE.

Abort the Location Service

This action shall be employed for any event that permanently impedes a location service attempt, such as loss of the radio channel to the target UE. When such an event is notified to the SGSN, it shall cancel the current location service attempt and the associated signalling dialogue with RAN, if still existing, by sending a "stop reporting"/"location abort" message to RAN. The "stop reporting"/"location abort" message shall contain the reason for the location procedure cancellation. The SGSN shall then return an error response to the client or network entity from which the location request was originally received. The SGSN shall also release all resources specifically allocated for the location attempt.

The following Table indicates the appropriate error recovery procedure for certain events. For events not listed in the Table, the SGSN need take no action.

Table 9.2: LCS Error Recovery Procedures in the SGSN for certain Events

Event	SGSN Error Recovery
Release of radio channel to the UE	Abort
Any error response from RAN causing unavailable signalling connections	Abort
Inter RNC hard handover, Inter SRNC relocation (Iu mode only)	Abort on Iu level Restart after process is completed
Suspend of GPRS services (A/Gb mode only)(During CS connection for class B UE)	Abort
Intra SGSN Routing Area Update (A/Gb mode only)	Restart
Inter SGSN Routing Area Update, inter SGSN relocation	Abort (Note: GMLC may restart)
Standalone P-TMSI Reallocation (A/Gb mode only)	Restart

9.4.3a Procedures in the MME |R9| p. 141

After the MME has requested a location service for a particular UE from an E-SMLC, certain events may occur that may temporarily or permanently interfere with the location service attempt. For each such event notified to the MME, the MME shall employ one of the following error recovery actions.

Abort the Location Service:

This action shall be employed for any event that permanently impedes a location service attempt, such as loss of the radio channel to the target UE or handover to a different MME. When such an event is notified to the MME, it shall cancel the current location service attempt and the associated signalling dialogue with the E-SMLC by sending a "location abort" message to the E-SMLC. The "location abort" message shall contain the reason for the location procedure cancellation. The MME shall then return an error response to the client or network entity (e.g. GMLC) from which the location request was originally received. The MME shall also release all resources specifically allocated for the location attempt.

The following Table indicates the appropriate error recovery procedure for certain events. For events not listed in the Table, the MME need take no action.

Table 9.4.3a: LCS Error Recovery Procedures in the MME for certain Events

Event	MME Error Recovery
UE Detach	Abort
Inter MME Tracking Area Update	Abort
E-UTRAN to UTRAN Routing Area Update	Abort
Inter MME and inter RAT handover	Abort
RRC or S1 connection release not due to User Inactivity (NOTE)	Abort
NOTE: The MME can determine the reason for an S1 connection release requested by the eNodeB from the Cause IE included in the UE Context Release Request message - see TS 36.413.

Release S1 Connection and Preserve the Location Service

This action shall be employed when the MME receives a UE Context Release Request from the serving eNodeB where the cause IE indicates user inactivity. The MME shall release the S1 connection but shall preserve and retain associated context information for the location service.

9.4.4 Void

9.4.5 Handover handling p. 142

9.4.5.1 VMSC /MSC server procedure for Inter-VMSC /MSC server Handover p. 142

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 shall be used by the visited MSC /MSC server to identify the correct RAN to serve the location request. All location request related messages shall be 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.

9.4.5.2 Handling of an ongoing handover while a request for positioning arrives p. 142

If during an ongoing handover procedure a request for location information arrives, the request shall be suspended until the handover is completed. On completion of the handover, the location preparation procedure shall continue.

9.4.5.3 Handover handling in Iu mode p. 142

In 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 Iu 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.

9.4.5.4 Handover of an IMS Emergency Call with EPS/GPRS/WLAN Access |R9| p. 142

9.4.5.4.1 Common Requirements |R14| p. 142

Handover of the PS 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, E-UTRAN to HRPD, WLAN to E-UTRAN, or E-UTRAN to WLAN) as defined in TS 23.401, TS 23.402 and TS 23.060. Handover of an already established IMS emergency call may also occur from the PS domain to the CS domain using SRVCC as defined in TS 23.216 or DRVCC as defined in TS 23.237. 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) may be needed whether or not the solution changes. Table 9.2a summarizes the support of all possible handover scenarios. Note that in all cases, the LRF that was originally assigned to the IMS emergency call as described in clause 9.8.4 must be retained after handover in order to avoid any impact to the emergency centre/PSAP. However, other location server changes (e.g. addition or removal of a GMLC) may occur following handover as summarized in Table 9.2a.

Table 9.2a: Location Reconfiguration Requirements for handover of an Emergency PS Bearer or IMS Emergency Call to support Location Continuity (Note 1)

Source Access Side(s)	Target Access Side(s)	Source Location Solution	Target Location Solution	Reconfiguration Requirements
E-UTRAN, UTRAN PS	E-UTRAN, UTRAN PS	TS 23.271	TS 23.271	Either (a) Source side SGSN or MME transfers the target side SGSN or MME identity to the source side GMLC Or (b) Target side SGSN or MME transfers its own identity to the target side GMLC (Note 2) Source or target side GMLC updates the LRF LRF replaces the source side GMLC with the target side GMLC if the GMLCs are different
E-UTRAN, UTRAN PS	E-UTRAN, UTRAN PS	TS 23.271	OMA AD SUPL [38], OMA TS ULP [39] (Note 3)	Source side SGSN or MME transfers the target side SGSN or MME identity to the source side GMLC (Note 2) Source side GMLC updates the LRF LRF replaces the source side GMLC with a target side E-SLP LRF transfers the UE identity or address (e.g. IP address) to the target side E-SLP when the UE location is next needed.
E-UTRAN, UTRAN PS	E-UTRAN, UTRAN PS	OMA AD SUPL [38], OMA TS ULP [39]	TS 23.271 (Note 3)	Target side SGSN or MME transfers its own identity to the target side GMLC (Note 2) Target side GMLC updates the LRF LRF replaces the source side SUPL E-SLP with the target side GMLC
E-UTRAN, UTRAN PS, WLAN	E-UTRAN, UTRAN PS, WLAN	OMA AD SUPL [38], OMA TS ULP [39]	OMA AD SUPL [38], OMA TS ULP [39]	None identified
E-UTRAN	HRPD	TS 23.271	OMA AD SUPL [38], OMA TS ULP [39]	Source side MME transfers an HRPD indication and an HRPD identity if known (e.g. cell ID) to the source side GMLC (Note 2) Source side GMLC updates the LRF LRF replaces the source side GMLC with a target side E-SLP LRF transfers the UE identity or address (e.g. IP address) to the target side E-SLP when the UE location is next needed.
E-UTRAN, UTRAN PS	UTRAN CS GERAN CS	TS 23.271	TS 23.271	Either (a) Source side SGSN or MME transfers the target side SRVCC MSC identity to the source side GMLC Or (b) Target side SRVCC MSC transfers its own identity to the target side GMLC (Note 2) Source or target side GMLC updates the LRF LRF replaces the source side GMLC with the target side GMLC if the GMLCs are different
E-UTRAN, UTRAN PS	UTRAN CS GERAN CS	OMA AD SUPL [38], OMA TS ULP [39]	TS 23.271	Target side SRVCC MSC transfers its own identity to the target side GMLC (Note 2) Target side GMLC updates the LRF LRF replaces the source side SUPL E-SLP with the target side GMLC
E-UTRAN	1xRTT	TS 23.271	J-STD-036B [32] (Note 4)	Either (a) Source side MME transfers the 1xRTT Reference Cell ID to the source side GMLC Or (b) A target side update occurs (Note 2, Note 4) Source side GMLC or Target side updates the LRF (Note 4) LRF replaces the source side GMLC with location support on the target side (Note 4)
E-UTRAN	1xRTT	OMA AD SUPL [38], OMA TS ULP [39]	J-STD-036B [32] (Note 4)	The target side updates the LRF (Note 4) The LRF replaces the source side E-SLP with location support on the target side (Note 4)
E-UTRAN	WLAN	TS 23.271	OMA AD SUPL [38], OMA TS ULP [39] or UPLI/NPLI TS 23.167	Source side MME transfers an indication of handover to a non-3GPP access to the source side GMLC (Note 2) Source side GMLC updates the LRF LRF removes use of the GMLC If SUPL is used on the target side, the LRF assigns a target side E-SLP and transfers the UE identity or address (e.g. IP address) to the E-SLP when the UE location is next needed.
WLAN	E-UTRAN	OMA AD SUPL [38], OMA TS ULP [39] or UPLI/NPLI TS 23.167	TS 23.271	Target side MME transfers its own identity to the target side GMLC (Note 2) Target side GMLC updates the LRF LRF uses the target side GMLC and removes the source side SUPL E-SLP if previously used.
WLAN	UTRAN CS GERAN CS	OMA AD SUPL [38], OMA TS ULP [39] or UPLI/NPLI TS 23.167	TS 23.271	Target side MSC server transfers its own identity to the target side GMLC (Note 5) Target side GMLC updates the LRF LRF uses the target side GMLC and removes the source side SUPL E-SLP if previously used.
NOTE 1: It is assumed that all handovers are intra-operator and that a single LRF is used by an operator for all IMS emergency calls. Use of more than one LRF is FFS. NOTE 2: A source side update should be configured if the control plane location is used on the source side but will not be used on the target side. A target side update should be configured if the control plane location will be used on the target side but was not used on the source side. An update on either the source or target side but not both should be configured when the control plane location solution is or may be used on both sides. No update is needed when a user plane location solution is used on both sides. The knowledge of the location solution can also be configured - e.g. and may depend on the access type, the location capabilities of the UE and whether a UE is roaming or not. NOTE 3: It is allowed to change location solution for an intra E-UTRAN or intra UTRAN PS handover as well as for inter-RAT PS handover although this is expected to be an unlikely scenario for handover within the same operator's networks. NOTE 4: Actions on the target 1xRTT side are outside the scope of this TS. NOTE 5: The target side MSC server needs to be aware of E-STN-DR association with an emergency call.

9.4.5.4.2 Location Continuity for Handover between 3GPP and 3GPP2 Access Types |R14| p. 147

Details concerning the interactions between the LRF, GMLCs, E-SLPs and any 1xRTT location servers to support the reconfiguration requirements in Table 9.2a are outside the scope of this TS. Support of location continuity by other entities is defined below in association with Figure 9.8hx.

Reproduction of 3GPP TS 23.271, Fig. 9.8hx: Support of Location Continuity for Handover of an IMS Emergency Call

Figure 9.8hx: Support of Location Continuity for Handover of an IMS Emergency Call

Step 1.

Following the request for an emergency call, the UE establishes an emergency PDN connection for E-UTRAN access as defined in TS 23.401 or an emergency PDP context for UTRAN PS access as defined in TS 23.060. The UE may then establish an IMS emergency call as defined in TS 23.167 during which an LRF is assigned and a source location server (e.g. GMLC) may be chosen as described in clause 9.8.4

Step 2.

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 if the location solution defined in this TS is used on the source access side.

Step 3.

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.

Step 4.

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).

Step 5.

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 TS 23.401, TS 23.060 or TS 23.216. For handover from E-UTRAN to 1xRTT, the source MME initiates a handover to a target 1xRTT IWS using single radio voice call continuity procedures as described in TS 23.216. For handover from E-UTRAN to HRPD, this step does not occur.

Step 6.

The rest of the handover preparation and execution procedure is completed as defined in TS 23.401, TS 23.402, TS 23.060 or TS 23.216.

Step 7.

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

Step 8a.

If the location solution defined in this TS is used on the source side and step 2 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, except for handover to HRPD, convey the identity of the target serving node. In the case of handover to 1xRTT, the Provide Subscriber Location response may convey the Reference Cell ID.

Step 8b.

If the location solution defined in this TS is used on the source side but steps 2 and 8a do not occur, the source SGSN or MME may depending on configuration information in the source SGSN or MME (e.g. as in step 8a) send a Subscriber Location Report to the source GMLC carrying the UE identity (IMSI, MSISDN and/or IMEI), an event type indicating handover and, except for handover to HRPD, the identity of the target serving node. In the case of handover to 1xRTT, the Subscriber Location Report may convey the Reference Cell ID.

Step 9.

The source GMLC acknowledges the message in step 8b if this occurs.

Step 10.

Steps 10 and 11 only apply when the target side supports a 3GPP access type (e.g. do not apply to 1xRTT or HRPD). Depending on 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 after handover in step 6 is complete send a Subscriber Location Report to a GMLC on the target side if the location solution defined in this TS will be used on the target side. The Subscriber Location Report carries the UE identity (IMSI, MSISDN and/or IMEI), an event type indicating handover and the identity of the target serving node. If the target serving node is an MSC, it will send the UE identity as received from source MME/SGSN in Handover Request message in step 5. If the MSC does not receive MSISDN from source MME/SGSN, MSISDN may be populated with a non-dialable callback number as specified in clause 6.4.3. However, no location estimate is included. The target serving node may determine the address of the target GMLC from configuration information.

Step 11.

The target GMLC acknowledges the message in step 10.

Step 12.

Reconfiguration of the LRF and the source and target location servers may occur as summarized in Table 9.2a which may involve removal of a source GMLC or E-SLP, assignment of a new target GMLC or E-SLP and/or updating of information in the LRF and in the source/target location server(s). The details of this step are outside the scope of this TS.

Step 13.

If the LRF needs a location estimate for the UE after handover has occurred, it may instigate an MT-LR request via either the target GMLC if the location solution defined in this TS will be used on the target side or a target E SLP if the location solution defined in OMA SUPL [38], [39] will be used. This will involve a repetition of step 2 on the target side if the location solution defined in this TS is used. Steps 2 to 12 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.

If target serving node is MME and it determines that emergency service is no longer active, the MME may send a Subscriber Location Report to the GMLC with the event (EMERGENCY_CALL_RELEASE) causing the message, see step 8-10 of Figure 9-20.

9.4.5.4.3 Location Continuity for E-UTRAN Handover to WLAN |R14| p. 150

Support of location continuity for E-UTRAN handover to WLAN is defined below in association with Figure 9.8ix.

Reproduction of 3GPP TS 23.271, Fig. 9.8ix: Location Continuity for Handover of an IMS Emergency Call from E-UTRAN to WLAN

Figure 9.8ix: Location Continuity for Handover of an IMS Emergency Call from E-UTRAN to WLAN

Step 1.

Following the request for an emergency call, the UE establishes an emergency PDN connection for E-UTRAN access as defined in TS 23.401. The UE may then establish an IMS emergency call as defined in TS 23.167 during which an LRF is assigned and a source location server (e.g. a GMLC) may be chosen as described in clause 9.8.4.

Step 2.

At some later time, the serving MME (hereafter referred to as the source MME) may receive a request from an associated GMLC (hereafter referred to as the source GMLC) for the location of the UE if the location solution defined in this TS is used on the source access side.

Step 3.

If step 2 occurs or if support for an NI-LR is required, the source MME starts a location session with the serving E-SMLC to obtain the location of the UE.

Step 4.

A handover of the UE to WLAN access occurs as defined in TS 23.402. The source MME is informed of the handover to a non-3GPP access through the PDN GW Initiated PDN Disconnection at the end of the handover procedure (see TS 23.401 and TS 23.402).

Step 5.

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

Step 6a.

If the location solution defined in this TS is used on the source side and step 2 occurred, the source MME returns a Provide Subscriber Location response to the source GMLC carrying any location estimate obtained previously for the UE and including an indication of handover to a non-3GPP access.

Step 6b.

If the location solution defined in this TS is used on the source side but steps 2 and 6a do not occur, the source MME shall send a Subscriber Location Report to the source GMLC carrying the UE identity (IMSI, MSISDN and/or IMEI), an event type indicating handover and an indication of handover to a non-3GPP access.

Step 7.

The source GMLC acknowledges the message in step 6b if this occurs.

Step 8.

Reconfiguration of the LRF and the source and target location servers may occur as summarized in Table 9.2a which may involve removal of a source GMLC, assignment of a new target E-SLP and/or updating of information in the LRF and in the source/target location server(s). The details of this step are outside the scope of this TS.

Step 9.

If the LRF needs a location estimate for the UE after handover has occurred, it may either instigate an MT-LR request via a target E SLP if the location solution defined in OMA SUPL [38], [39] will be used on the target side or instigate a location request for a UPLI or NPLI as defined in TS 23.167.

9.4.5.4.4 Location Continuity for WLAN Handover to E-UTRAN, UTRAN or GERAN |R14| p. 151

Support of location continuity for WLAN handover to E-UTRAN, UTRAN or GERAN is defined below in association with Figure 9.8j.

Reproduction of 3GPP TS 23.271, Fig. 9.8j: Location Continuity for Handover of an IMS Emergency Call from WLAN to E-UTRAN, UTRAN or GERAN

Figure 9.8j: Location Continuity for Handover of an IMS Emergency Call from WLAN to E-UTRAN, UTRAN or GERAN

Step 1.

Following the request for an emergency call, the UE establishes an emergency PDN connection for WLAN access as defined in TS 23.402. The UE may then establish an IMS emergency call as defined in TS 23.167 during which an LRF is assigned and a source location server (e.g. an E-SLP) may be chosen as described in clause 9.8.4.

Step 2.

A handover of the UE to either E-UTRAN access or UTRAN/GERAN CS access occurs as defined in TS 23.402 or TS 23.237, respectively. For handover to E-UTRAN, the target MME is informed of the handover through the UE Attach Request indicating "handover for emergency services" at the start of the handover procedure as defined in TS 23.402. For handover to GERAN or UTRAN CS access, the target MSC server is informed of the handover through receipt of a normal CS call setup request from the UE using an E-STN-DR assigned by the serving network as defined in TS 23.237.

Step 3.

After the handover in step 2 is complete, the target MME or MSC server shall send a Subscriber Location Report to a GMLC on the target side if the location solution defined in this TS will be used on the target side. The Subscriber Location Report carries the UE identity (IMSI, MSISDN and/or IMEI), an event type indicating handover and the identity of the target serving node. The target serving node may determine the address of the target GMLC from configuration information.

Step 4.

The target GMLC acknowledges the message in step 3.

Step 5.

Reconfiguration of the LRF and the source and target location servers may occur as summarized in Table 9.2a which may involve removal of a source E-SLP, assignment of a new target GMLC and/or updating of information in the LRF and in the source/target location server(s). The details of this step are outside the scope of this TS.

Step 6.

If the LRF needs a location estimate for the UE after handover has occurred, it may instigate an MT-LR request via the target GMLC if the location solution defined in this TS will be used on the target side.

If the location solution defined in this TS will be used on the target side and the target MME or MSC server determines that emergency service is no longer active, the MME or MSC server may send a Subscriber Location Report to the GMLC with the event (EMERGENCY_CALL_RELEASE) causing the message, see steps 8-10 of Figure 9.20 in the case of a target MME or steps 11-12 of Figure 9.4 in the case of a target MSC server.