7.11 Exception Procedures

03.713GPPFunctional descriptionLocation Services (LCS)Release 1999Stage 2TS

The procedures in this section apply to all variants of an MT-LR, NI-LR and MO-LR where a BSSMAP-LE Perform Location Request has been sent to an SMLC by a BSC or MSC requesting some location service (e.g. provision of a location estimate for a target MS or transfer of assistance data to a target MS).

7.11.1 Procedures in the SMLC

When a request for a location estimate fails due to failure of a position method itself (e.g. due to inaccurate or insufficient position measurements and related data) and the SMLC is unable to instigate another positioning attempt (e.g. due to a requirement on response time), the SMLC may return a BSSMAP-LE Perform Location response containing a less accurate location estimate (e.g. based on serving cell and timing advance). If a less accurate estimate is not available, the SMLC shall instead return a BSSMAP-LE Perform Location response message containing no location estimate and indicating the cause of failure.

When a request for any other location service (e.g. transfer of assistance data to a target MS) fails for any reason and the SMLC is unable to reattempt the service, the SMLC shall return a BSSMAP-LE Perform Location response message indicating the cause of failure.

When a location service request is interrupted by some other unrecoverable error event inside the SMLC, the SMLC shall immediately terminate the location service attempt and return a BSSMAP Perform Location Response message containing the reason for the location service cancellation. In that case, any dialogue previously opened with an LMU or BSC for the purpose of instigating position measurements for any MS being located may also be aborted by the SMLC.

If the SMLC receives a BSSMAP-LE Perform Location Abort indication for a previous location service request from the VMSC (NSS based SMLC) or BSC (BSS based SMLC), it shall immediately terminate the location service attempt and may abort any dialogues used for the location service attempt that may still exist with any LMUs. Although the SMLC cannot abort any location procedure instigated in the serving BSC (e.g. for TOA), the circumstances of the abort may still ensure cancellation of any such procedure (see section on BSC).

If the SMLC has instigated any location related procedure in the Target MS or its serving BSC and receives a BSSLAP Reject, BSSLAP Abort or BSSLAP Reset indication from the BSC, it shall cancel the location service attempt and may abort any dialogues for this that currently exist with any LMUs. For a BSSLAP Abort, the SMLC shall then either return any location estimate already derived, if this was requested, or return a BSSMAP-LE Perform Location response indicating failure of the location service and the cause of the failure in the BSSLAP Abort. For a BSSLAP Reject and BSSLAP Reset, the SMLC has the additional option of restarting the location service attempt and using the same or a different position method where a location estimate was requested. A decision to restart the location service shall take into account the cause of the location service failure as conveyed in the BSSLAP Reject or BSSLAP Reset and whether, in the case of successful intra-BSC handover, the new cell for the target MS is still associated with the SMLC. If the SMLC receives a BSSLAP Reject or BSSLAP Reset with a cause indicating intra-BSC handover and with a new cell identity for the target MS that is not associated with the SMLC, the SMLC shall return a BSSMAP-LE Perform Location response containing either a location estimate, if requested, and available, or a failure cause indicating “intra-BSC” handover.

NOTE: This procedure may only be needed for an NSS-based SMLC.

The SMLC may indicate an inability to support location due to overload by rejecting with a cause indicating congestion a BSSMAP-LE Perform Location request received from either an MSC or BSC.

7.11.2 Procedures in the VMSC

After the VMSC has requested a location service for a particular MS from the SMLC or BSC, certain events may occur that may temporarily or permanently interfere with the location service. For each such event notified to the VMSC, the VMSC 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, it shall immediately cancel the location service attempt and the associated BSSMAP-LE or BSSMAP dialogue with the SMLC (NSS based SMLC) or BSC (BSS based SMLC), respectively, if this still exists by sending a BSSMAP-LE or BSSMAP Perform Location Abort message to the SMLC or BSC, respectively. The Abort message shall contain the reason for the location procedure cancellation.

After aborting the location request dialogue with the SMLC or BSC, the VMSC may queue the location service request until the event causing the restart has terminated (if not already terminated). The VMSC 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 the SMLC have time to be released. The VMSC may then send another location service request to the SMLC or BSC associated with the current serving cell of the target MS.

Abort the Location Service

This action shall be employed for any event that permanently impedes a location service attempt, such as loss of the DCCH to the target MS. When such an event is notified to the VMSC, it shall cancel the current location service attempt and the associated BSSMAP-LE or BSSMAP dialogue with the SMLC (NSS based SMLC) or BSC (BSS based SMLC), respectively, if still existing, by sending a BSSMAP-LE or BSSMAP Perform Location Abort message to the SMLC or BSC, respectively. The Abort message shall contain the reason for the location procedure cancellation. The VMSC shall then return an error response to the client or network entity from which the location request was originally received. The VMSC shall also release all resources (e.g. DCCH) 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 need take no action.

Table 2: LCS Error Recovery Procedures in the VMSC for certain Events

Event

VMSC Error Recovery

Release of radio channel to the MS

Abort

Any error response from the SMLC or BSC except for intra-BSC, inter-BSC or inter-MSC handover

Abort

An error response from the SMLC indicating intra-BSC handover

Restart with no additional delay required

Inter-BSC Handover

Restart after handover completed

Inter-MSC Handover

Restart after handover completed

If a location service request is aborted due to an error response from the SMLC or BSC indicating congestion, the MSC may reduce the frequency of location service requests to this SMLC or BSC according to the rules in GSM 09.31, which give precedence to location service requests with a higher priority.

7.11.3 Procedures in an LMU

An LMU shall return an error indication to its controlling SMLC when location measurements previously ordered by the SMLC cannot be provided due to any error condition.

7.11.4 Procedures in the BSC

7.11.4.1 General Procedures

The BSC serving a target MS shall supervise any network or MS location service procedure, including transfer of positioning assistance data to an MS, and shall only allow one such procedure to be active at any time. If a new procedure is instigated by the SMLC for any target MS, the BSC shall cancel any previous procedure without notifying the SMLC or target MS. The new procedure shall then be treated according to the prevailing conditions – e.g. may be rejected if a previous TOA handover attempt was not yet completed. If a location information transfer to an MS initiated by an SMLC is not active, the BSC shall discard any RRLP message or message segment received from the MS. This precludes the initiation of any location service procedure from an MS.

Depending on the location procedure and its current state of execution, a serving BSC may chose to defer certain radio related events (e.g. handover) to avoid interference with location – refer to the later sections for each position method. A serving BSC shall abort all existing location related procedures for a particular target MS without notifying an NSS based SMLC or target MS if the DCCH to the target MS or the SCCP connection to the VMSC or a BSS based SMLC is released. In the event of an abort with a BSS based SMLC, the BSC shall attempt to notify the SMLC using a BSSMAP-LE Perform Location Abort.

7.11.4.2 Rejection of an SMLC Positioning Request

The BSC may reject any request from an SMLC for positioning or transfer of assistance data for a target MS if the request cannot be performed for reasons other than interaction with handover or other RR management. If the request is rejected, the BSC shall return a BSSLAP Reject to the SMLC containing the cause of rejection.

7.11.4.3 Interaction with Inter-BSC or Inter-MSC Handover

The BSC shall reject any request from an SMLC for positioning or transfer of assistance data while an inter-BSC or inter-MSC handover procedure is ongoing and shall return a BSSLAP Abort to the SMLC.

The BSC shall terminate any network or MS positioning procedure or any transfer of RRLP assistance data already in progress if inter-BSC or inter-MSC handover is needed and is not precluded by the particular location procedure and its current state. When a location procedure is terminated and there is an active BSSLAP transaction, the BSC shall return a BSSLAP Abort message to the SMLC after the BSSMAP Handover Required has been sent to the serving MSC. The BSSLAP Abort shall contain the cause of the location procedure failure. When a location procedure is terminated and there is no active BSSLAP transaction, the BSC shall send a BSSAP-LE Perform Location Abort message to the SMLC after the BSSMAP Handover Required has been sent to the serving MSC.

7.11.4.4 Interaction with Intra-BSC Handover and other RR Management Procedures

The BSC shall reject any request from an SMLC for positioning or transfer of assistance data while an intra-BSC handover or other intra-BSC RR management procedure involving the target MS is ongoing and shall return a BSSLAP Reset to the SMLC when the handover or other RR management procedure is complete in the BSC. If the handover or other RR management procedure times out in the BSC, the BSC shall instead return either a BSSLAP Reset or a BSSLAP Abort to the SMLC.

The BSC shall terminate any network or MS positioning procedure or any transfer of RRLP assistance data already in progress if an intra-BSC handover or other intra-BSC RR management procedure is needed and is not precluded by the particular location procedure and its current state. When location procedure is terminated, the BSC shall return a BSSLAP Reset message to the SMLC after the intra-BSC handover or other RR management procedure is complete in the BSC. If the intra-BSC handover or other RR management proceduretimes out in the BSC, the BSC shall instead return either a BSSLAP Reset or a BSSLAP Abort to the SMLC. The BSSLAP Reset shall contain a cause indication, the current serving cell identity and may contain measurement information for the target MS (e.g. TA value).

7.11.4.5 Priority of Handover and Other RR Management Procedures

If the transfer of RRLP messages between an SMLC and target MS is interrupted by intra-BSC handover, inter-BSC handover or any other intra-BSC RR management procedure, the BSC shall avoid delay to the handover or RR management procedure by employing the preemption capability defined in GSM 04.06 and 04.08. This allows an RR Handover Command or other RR management command sent to the target MS to be assigned a “high” priority at the data link level enabling preemption of “low” priority RR Application Information messages (carrying RRLP messages) which may have been sent earlier. This procedure ensures that any RRLP data still untransmitted to the MS will be preempted (and discarded) by the data link layer in the BTS prior to transmission of the Handover Command or other RR Management command.

7.11.4.6 Interaction with Segmentation

When requested to transfer a segmented RRLP message between an SMLC and target MS, the BSC shall discard all received RRLP segments if the transfer procedure in the BSC cannot be supported or is aborted. The BSC need not wait until all RRLP segments are received before notifying the SMLC of the failure of the RRLP procedure with a BSSLAP Abort, Reject or Reset message.

If a location service procedure for a target MS is not currently underway or previously failed, the BSC shall discard all BSSLAP segments received from an SMLC for this MS until it receives the first or only segment of a new BSSLAP message. Once a location service procedure has been started involving RRLP message transfer to a target MS, the BSC shall discard all RRLP segments received from the MS until it receives the first or only segment of a new RRLP message. The new RRLP message shall then be treated according to the state of the RRLP message transfer as described in section 7.7.

Further details regarding transfer and segmentation of RRLP messages between a BSC and MS can be found in GSM 04.08.

7.11.4.7 Overload

The BSC may indicate an inability to support location due to overload by rejecting with a cause indicating congestion a BSSMAP Perform Location request received from the MSC. If a BSS based SMLC has rejected a request from the BSC to perform location with a cause indicating congestion, the BSC shall convey the rejection and cause to the MSC if the request was MSC initiated. If the request was initiated by the BSC, the BSC may reduce the frequency of its location requests to the SMLC according to the rules in GSM 09.31, which give precedence to location service requests with a higher priority.

7.11.5 Procedures in the Target MS

A target MS shall terminate any positioning procedure or the transfer of RRLP positioning assistance data without sending any response to the SMLC if any RR message is received from the BSC that starts some other RR management procedure, including a new positioning procedure. The new RR procedure shall then be executed by the MS.

7.11.6 Further Procedures for Handover

7.11.6.1 MSC procedure for Inter-MSC Handover

When a location estimate is required for a target MS with an established call in a state of inter-MSC handover, the serving cell ID or serving location area ID shall be used by the visited MSC to identify the correct SMLC to perform the location. All layer-3 BSSMAP and DTAP Location request related messages that are transferred over the A-interface shall now be sent via MAP/E interface piggy-backed in MAP_FORWARD_ACCESS_SIGNALLING and MAP PROCESS_ACCESS_SIGNALLING between the visited and serving MSCs.

7.11.6.2 Handling of an ongoing handover while a request for positioning arrives at MSC/VLR

If during an ongoing radio handover procedure a request for location information arrives at the MSC/VLR, the request shall be suspended until the HANDOVER COMPLETE message is received at the MSC/VLR. On completion of the handover, the MSC/VLR shall issue continue with location preparation procedure.