8 Common Procedures to Support Positioning

3GPP43.059Functional stage 2 description of Location Services (LCS) in GERANRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

The procedures described in this clause enable an SMLC to obtain positioning related information or instigate positioning for a particular target MS. The procedures are applicable to all positioning methods after an SMLC receives a BSSAP-LE Perform Location request for a target MS until a BSSAP-LE Perform Location response is returned to the originator.

8.1 Information Transfer between an SMLC and a Target MS in the CS Domain in A/Gb mode for E-OTD and A-GNSS positioning methods

An SMLC uses the procedure shown below in order to obtain the MS position or positioning measurements from a target MS or transfer location assistance information to a target MSin the CS domain after a request has been received from the BSC serving the target MS. More details of the location information transfer procedure between the BSC and MS can be found in 3GPP TS 24.008.

Figure 16: Information Transfer between an SMLC and a Target MS in CS domain

1) The SMLC passes a BSSAP-LE Connection Oriented Information message to the serving BSC containing an embedded BSSLAP MS Position Command with an RRLP message parameter. The message is transferred using the SCCP connection established between the SMLC and BSC for positioning the target MS If the BSSLAP message is too large to fit in a single BSSAP-LE Connection Oriented Information message, RRLP pseudo‑segmentation shall be used. Legacy SMLC may utilize BSSAP-LE layer segmentation instead of RRLP pseudo-segmentation. The SMLC shall indicate in the first BSSLAP MS Position Command whether the embedded RRLP message contains a positioning command versus positioning assistance data.

2) The BSC transfers the embedded RRLP message to the target MS inside an RR Application Information message. No later than when the RR Application Information message has been transferred, the BSC shall start a positioning supervision timer if none is already in progress or restart this if already in progress. If the timer expires before the final response in step 3 is received, the BSC shall return a BSSAP-LE Connection oriented Information message to the SMLC containing a BSSLAP Abort with a cause of BSC timeout.

3) When the target MS has positioning information to return to the SMLC, it sends an RR Application Information message to the BSC containing an embedded RRLP message. If the RRLP message is too large to fit in a single RR Application Information message, RRLP pseudo-segmentation shall be used. Legacy MS may utilize RR layer segmentation instead of RRLP pseudo-segmentation. . The last RR Application Information message shall indicate if this is the final response from the MS.

4) If the timer started in step 2 has already expired, the BSC discards the RRLP message received in step 3. Otherwise, the BSC forwards the RRLP message to the SMLC inside a BSSLAP MS Positioning Response message contained in a BSSAP-LE Connection Oriented Information message. If the SMLC indicated a positioning command in step 1 and the MS has indicated a final response, the BSC may add additional measurement information to the BSSLAP MS Position Response in the last BSSAP-LE message – if necessary, creating a new BSSAP-LE message if message size limitations would be exceeded. The BSC shall stop the supervision timer started in step 2 when the final segment of the final response from the MS has been transferred. If the MS did not indicate a final response in step 3, the SMLC may transfer a further RRLP message to the MS (e.g. containing assistance data) according to steps 1 and 2 and the MS may return a subsequent response according to steps 3 and 4.

8.1a Information Transfer between an SMLC and a Target MS in the PS Domain in A/Gb mode

Figure 16a: Information Transfer between an SMLC and a Target MS in PS Domain

1) The SMLC passes a BSSAP-LE Connection Oriented Information message to the serving BSS containing an embedded BSSLAP MS Position Command with an RRLP message parameter. The message is transferred using the SCCP connection established between the SMLC and BSS for positioning the target MS. If the RRLP message is larger than the RRLP maximum PDU size, RRLP pseudo-segmentation shall be used. The SMLC shall indicate in the positioning command bit in the RRLP flags IE in the BSSLAP MS Position Command whether the embedded RRLP message contains a positioning command versus a non-command – e.g. positioning assistance data.

2) The BSS relays the embedded RRLP message and the RRLP flags IE to the SGSN inside a BSSGP Position Command message. When the BSSGP Position Command message has been transferred, the BSS shall start a positioning supervision timer if not already in progress or restart if the timer is already in progress. If the timer expires before the final response in step 5 is received, the BSS shall return a BSSAP-LE Connection Oriented Information message to the SMLC containing a BSSLAP Abort with a cause of BSS timeout.

3) The SGSN receives the RRLP message in the BSSGP Position Command message and relays it to the MS in an LLC UI frame. The TOM protocol with SAPI TOM8 is used for transfer of RRLP messages. The positioning command bit from the RRLP flags IE in the BSSGP message is also relayed using the C/R bit in the TOM header (see 3GPP TS 44.031 [15]). The received C/R bit may be ignored by the MS or used for implementation purposes.

4) When the target MS has positioning information to return to the SMLC, it sends an LLC UI Frame to the SGSN containing an embedded RRLP message. The TOM protocol is used for transfer of RRLP messages. If the RRLP message is larger than the RRLP maximum PDU size, RRLP pseudo-segmentation shall be used. If the RRLP pseudo-segmentation is used, the MS shall send several RRLP messages. In each message the MS shall indicate in the C/R bit in the TOM protocol header whether it is the final response or not. The final response shall be the last RRLP message that the MS expects to send in response to RRLP messages received so far from the SMLC. In the final message the MS shall indicate that it is the final response by setting the appropriate RRLP flag. For the MTA positioning method the MS does not send a RRLP message in response to the RRLP message it receives in step 3.

5) The SGSN relays the RRLP message to the BSS. The RRLP message is sent in a BSSG Position Response message. The C/R bit from the TOM header is relayed using the final response bit in the RRLP flags IE in the BSSGP message.

6) If the timer started in step 2 has already expired, the BSS discards the RRLP message received in step 5. Otherwise, the BSS relays the RRLP message and the RRLP flags IE to the SMLC inside a BSSLAP MS Positioning Response message contained in a BSSAP-LE Connection Oriented Information message. If the SMLC indicated a positioning command in the most recent message to be transferred in step 1 and the MS has indicated a final response, the BSS may add additional measurement information to the BSSLAP MS Position Response in the last BSSAP-LE message. The BSS shall stop the supervision timer started in step 2 when the final response from the MS has been transferred. The SMLC may transfer a further RRLP message to the MS (e.g. containing assistance data or a positioning command) according to steps 1, 2, and 3 and the MS may return a subsequent response according to steps 4, 5, and 6. Steps 4-6 are repeated if the RRLP pseudo-segmentation is used for the uplink message.

8.1b Information Transfer between an SMLC and a Target MS in Iu Mode

An SMLC uses the procedure shown below in order to obtain the MS position or positioning measurements from a target MS or transfer location assistance information to a target MS after a request has been received from the BSC serving the target MS.

Figure 16b: Information Transfer between an SMLC and a Target MS

1) The SMLC passes a BSSAP-LE Connection Oriented Information message to the serving BSC containing an embedded BSSLAP MS Position Command with an RRLP message parameter. The message is transferred using the SCCP connection established between the SMLC and BSC for positioning the target MS If the BSSLAP message is too large to fit in a single BSSAP-LE Connection Oriented Information message, RRLP pseudo‑segmentation shall be used. The SMLC shall indicate in the first BSSLAP MS Position Command whether the embedded RRLP message contains a positioning command versus positioning assistance data.

2) The BSC transfers the embedded RRLP message to the target MS inside an RRC LCS DL Information message. No later than when the RRC LCS DL Information message has been transferred, the BSC shall start a positioning supervision timer if none is already in progress or restart this if already in progress. If the timer expires before the final response in step 3 is received, the BSC shall return a BSSAP-LE Connection oriented Information message to the SMLC containing a BSSLAP Abort with a cause of BSC timeout.

3) When the target MS has positioning information to return to the SMLC, it sends an RRC LCS UL Information message to the BSC containing an embedded RRLP message. If the RRLP message is too large to fit in a single RRC LCS UL Information message, RRLP pseudo-segmentation shall be used. The last RRC LCS UL Information message shall indicate if this is the final response from the MS.

4) If the timer started in step 2 has already expired, the BSC discards the RRLP message received in step 3. Otherwise, the BSC forwards the RRLP message to the SMLC inside a BSSLAP MS Positioning Response message contained in a BSSAP-LE Connection Oriented Information message. If the SMLC indicated a positioning command in step 1 and the MS has indicated a final response, the BSC may add additional measurement information to the BSSLAP MS Position Response in the last BSSAP-LE message – if necessary, creating a new BSSAP-LE message if message size limitations would be exceeded. The BSC shall stop the supervision timer started in step 2 when the final response from the MS has been transferred. If the MS did not indicate a final response in step 2, the SMLC may transfer a further RRLP message to the MS (e.g. containing assistance data) according to steps 1 and 2 and the MS may return a subsequent response according to steps 3 and 4.

8.2 Information Transfer between an SMLC and a BSC

An SMLC uses the procedure shown below in order to obtain positioning related information from the BSC serving a particular target MS after a positioning request has been received from the BSC. This procedure applies to positioning of an MS in both the CS and the PS domains.

Figure 17: Information Transfer between an SMLC and a BSC

1) The SMLC passes a BSSAP-LE Connection Oriented Information message to the BSC containing an embedded BSSLAP message. The BSSAP-LE message is transferred using the SCCP connection previously established between the SMLC and BSC when the positioning request for the target MS was initially sent to the SMLC. The BSC recognizes that it is the final destination due to the presence of the embedded BSSLAP message.

2) When the BSC has positioning information for the target MS to return to the SMLC, it sends a BSSAP-LE Connection Oriented Information message to the SMLC containing an embedded BSSLAP message. The message is sent using the SCCP connection previously established for positioning the target MS. For the Multilateration based positioning methods, the BSC does not include an embedded BSSLAP message in the BSSMAP-LE Connection Oriented Information message it sends to the SMLC.

8.3 Common Procedures to Support Access to an LMU

The procedures in this clause support the transfer of positioning related information and O&M data between an SMLC and a particular LMU associated with the SMLC. These procedures apply to positioning of an MS in both the CS and the PS domains.

8.3.1 Location Update Procedure between an SMLC and a Type A LMU

The following procedure supports a normal location update from the perspective of a Type A LMU. The location update can occur periodically, on power up, following recovery from some failure condition and when an LMU in idle mode detects that its closest BTS is in another location area.

Figure 18: Location Update Procedure between an SMLC and a Type A LMU

1) If the LMU does not currently have a signaling link, it sends an RR Channel Request to the serving BTS to request a SDCCH. The RR Channel Request contains an establishment cause identifying an LMU. After assignment of the SDCCH, the LMU sends a DTAP Location Updating request to the BSC. This shall indicate that a follow on request is pending if the LMU has more data to send.

2) Because the BSC serving the LMU is associated with an SMLC and the Channel Request message contained an LMU establishment cause, the BSC forwards the Location Updating request to the SMLC rather than MSC. If there was previously no SDCCH, this is sent inside a BSSMAP Complete Layer 3 Information message that is contained in an SCCP Connection Request.

3) The SMLC performs normal authentication and ciphering if needed for the LMU. The SMLC shall not assign a TMSI to the LMU to avoid duplicating a TMSI assigned to a normal MS by a VLR.

4) The SMLC returns a DTAP Location Updating Accept to the BSC. Unless the LMU indicated a follow on request, the SMLC may then initiate release of the SDCCH.

5) The BSC forwards the DTAP message to the LMU.

8.3.2 IMSI Detach Procedure between an SMLC and a Type A LMU

The following procedure supports a normal IMSI Detach from the perspective of a Type A LMU. This may be instigated if the LMU is to be deactivated – e.g. for offline maintenance.

Figure 19: IMSI Detach Procedure between an SMLC and a TypeA LMU

2) Because the BSC serving the LMU is associated with an SMLC and the Channel Request message contained an LMU establishment cause, the BSC forwards the IMSI Detach Indication to the SMLC rather than MSC. If there was previously no SDCCH, this is sent inside a BSSAP Complete Layer 3 Information message that is contained in an SCCP Connection Request. The SMLC marks the LMU as temporarily inactive and initiates release of the SDCCH.

8.3.3 LCS Information Transfer between an SMLC and a Type A LMU

8.3.3.1 Information Transfer using an SDCCH

The following procedure supports information transfer between an SMLC and a Type A LMU.

Figure 20: Information Transfer between an SMLC and a Type A LMU

1) If there is no signaling link yet for an LMU between the SMLC and the BSC serving the LMU, the SMLC sends a BSSAP Paging message to the serving BSC inside an SCCP Unitdata message.

2) The serving BSC broadcasts an RR Paging Request.

3) The LMU sends a Channel Request message containing an LMU establishment cause to request an SDCCH. After assignment of the SDCCH, the LMU returns an RR Paging Response.

4) Because the BSC serving the LMU is associated with an SMLC and the Channel Request message in step 3 contained an LMU establishment cause, the BSC transfers the Paging Response to the SMLC, rather than MSC, in a BSSAP Complete Layer 3 Information message contained in an SCCP Connection Request.

5) The SMLC performs normal authentication and ciphering if this is needed for the LMU. The SMLC shall not assign a TMSI to the LMU to avoid duplicating a TMSI assigned to a normal MS by a VLR.

6) If the SMLC needs to send data to the LMU, it may send one or more DTAP-LE REGISTER, FACILITY or RELEASE COMPLETE messages to the BSC. Each DTAP-LE message contains an embedded LLP message and an indication of whether release of the SDCCH by the LMU is forbidden. Each DTAP-LE message is transferred by the BSC to the LMU.

7) The SMLC may initiate release of the SDCCH to the LMU by sending a BSSAP Clear Command to the BSC.

8) The BSC returns a BSSAP Clear Complete.

9) The BSC orders release of the SDCCH by sending an RR Channel Release to the LMU.

10) The SMLC releases the SCCP connection to the BSC by sending an SCCP Released message.

11) When the LMU has LCS data to send and does not currently have a signaling link, it sends an RR Channel Request to the serving BTS to request an SDCCH. The RR Channel Request contains an establishment cause identifying an LMU. After assignment of the SDCCH, the LMU sends a DTAP CM Service request to the serving BSC.

12) Because the BSC serving the LMU is associated with an SMLC and the Channel Request message contained an LMU establishment cause, the BSC forwards the CM Service Request with an indication that this came from an LMU to the SMLC, rather than MSC, inside a BSSAP Complete Layer 3 Information message that is contained in an SCCP Connection Request.

13) The SMLC performs authentication and ciphering if needed for the LMU. Otherwise, a CM Service Accept is returned. The SMLC shall not assign a TMSI to the LMU to avoid duplicating a TMSI assigned to a normal MS by a VLR.

14) The LMU sends one or more DTAP-LE REGISTER, FACILITY or RELEASE COMPLETE messages to the serving BSC each containing an embedded LLP message. The BSC forwards each DTAP-LE message to the SMLC.

8.3.3.2 Information Transfer using a TCH

Figure 21: Information Transfer between an SMLC and a Type A LMU using a TCH

1) The SMLC establishes a signaling connection to the LMU using an SDCCH.

2) The SMLC sends a DTAP Setup to the LMU with the requested bearer capability.

3) The LMU returns a DTAP Call Confirmed.

4) The SMLC initiates traffic channel assignment by sending a BSSAP Assignment Request to the BSC.

5) The BSC requests channel activation in the BTS and then sends an RR Assignment Command to the LMU.

6) The LMU acknowledges TCH assignment.

7) The BSC confirms TCH assignment.

8) The LMU confirms call establishment.

9) The SMLC acknowledges the LMU confirm.

10) DTAP-LE Connection Oriented Information messages are transferred between the SMLC and LMU on the established TCH: these are transparent to the BSC.

11) The SMLC initiates release of the TCH by sending a DTAP Disconnect to the LMU

12) The LMU returns a DTAP Release.

13) The SMLC sends a DTAP Release Complete.

14) The SMLC initiates release of the TCH by sending a BSSAP Clear Command to the BSC.

15) The BSC returns a BSSAP Clear Complete.

16) The BSC orders release of the TCH by sending an RR Channel Release to the LMU.

17) The SMLC releases the SCCP connection to the BSC by sending an SCCP Released message.

8.3.4 LCS Information Transfer between an SMLC and a Type B LMU

A SMLC uses the procedure shown below in order to exchange LCS information with a TypeB LMU.

Figure 22: Information Transfer between a SMLC and a Type B LMU

1) The SMLC passes a BSSAP-LE Connectionless Information message to the BSC containing an embedded LLP message and the LAC/CI cell address identifying the LMU. The BSSAP-LE message is transferred inside an SCCP Unitdata message.

2) The BSC transfers the embedded LLP message to either the BTS associated with the LMU or the LMU itself inside a Location Information message. The BTS or LMU is identified using the LAC/CI received in step 1.

3) When the LMU has positioning information to return to the SMLC, either it or its associated BTS transfers this to the BSC inside a Location Information message..

4) The serving BSC forwards the LLP message to the SMLC inside a BSSAP-LE Connectionless Information message contained in an SCCP Unitdata message. The BSSAP-LE message contains the LAC/CI address identifying the LMU.

8.4 Common Control Procedures for LMUs

These procedures are applicable to any Type A LMU and may be used for any Type B LMU to enable control of the LMU by its associated SMLC. The procedures assume support for the establishment of a signaling link and the transfer of LLP messages between an SMLC and LMU that are defined in the common procedures to support access to an LMU, clause 8.3. Consequently, details of signaling link establishment and message transfer by a BSC and BTS are not shown.

8.4.1 Reset Procedure

The reset procedure enables an SMLC to return an LMU to a known initial state in which no measurement or O&M operations are outstanding or being performed.

Figure 23: Reset Procedure for a Circuit Mode LMU

1) After first establishing a signaling connection to the LMU (see clause 8.3), the SMLC sends an LLP Reset Invoke to the LMU via BSC.

2) The LMU cancels any LCS measurement and O&M tasks previously ordered by the SMLC. The LMU then returns an LLP Reset Return Result to the SMLC.

8.4.2 Status Query Procedure

The Status Query procedure enables an SMLC to verify the status of an associated LMU. The procedure may be instigated periodically or following any loss of communication with the LMU.

Figure 24: Status Query Procedure for a Circuit Mode LMU

1) After first establishing a signaling connection to the LMU (see clause 8.3), the SMLC sends an LLP Status Query Invoke to the LMU via BSC.

2) The LMU returns an LLP Status Query return result, indicating the number of active measurement jobs for each type of measurement (e.g. RIT) and the number of active O&M jobs in the LMU that were previously ordered by the SMLC.

8.4.3 Status Update Procedure

The Status Update procedure enables an LMU to report status information to its associated SMLC. The procedure may be instigated for the following reasons:

1. Periodically;

2. Power-on condition or recovery from failure with loss of memory;

3. Impending availability or unavailability for O&M reasons;

4. Location Update by a Type A LMU in a new Location Area.

Figure 25: Status Update Procedure for a Circuit Mode LMU

1) After first establishing a signaling connection to the SMLC (see clause 8.3), the LMU sends an LLP Status Update Invoke to the SMLC via BSC. This message shall include the reason for the Status Update, the number of active and outstanding jobs of each category in the LMU and the current hardware status.

2) The SMLC returns an LLP Status Update return result to acknowledge receipt of the Status Update.

8.5 Exception Procedures

The procedures in this clause apply to all location procedures where a BSSAP-LE Perform Location Request has been sent to an SMLC by a BSC requesting some location service (e.g. provision of a location estimate for a target MS or transfer of assistance data to a target MS).

8.5.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 BSSAP-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 BSSAP-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 BSSAP-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 BSSAP-LE Perform Location Response message containing the reason for the location service cancellation. In that case, any dialogue previously opened with an LMU or BSS for the purpose of instigating position measurements for any MS being located may also be aborted by the SMLC.

If the SMLC receives a BSSAP-LE Perform Location Abort indication for a previous location service request from the BSS, 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. The circumstances of the abort may still ensure cancellation of any such procedure (see clause on BSS). For a BSSAP-LE Perform Location Abort, the SMLC shall then either return any location estimate (with optional velocity estimate) already derived, if this was requested, or return a BSSAP-LE Perform Location response indicating failure of the location service and the cause of the failure in the BSSAP-LE Perform Location Abort.

If the SMLC has instigated any location related procedure in the Target MS or its serving BSS and receives a BSSLAP Reject, BSSLAP Abort or BSSLAP Reset indication from the BSS, 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 (with optional velocity estimate) already derived, if this was requested and is sufficient for the requested QoS, or return a BSSAP-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 BSSAP-LE Perform Location response containing either a location estimate (with optional velocity estimate), if requested and available, or a failure cause indicating "intra-BSC" handover.

NOTE: In the CS domain, in the case of an intra-BSC handover to a cell in a different PLMN (different MCC, MNC combination), the SMLC may receive a BSSLAP Reset containing the new location area code and new cell ID. The SMLC may then deduce the new MCC and MNC from the uniqueness, when this applies, of the combined values for the new location area code and cell ID compared to the corresponding values for neighbouring cells.

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

8.5.3 Procedures in the BSC in the CS Domain

8.5.3.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. If a location information transfer to an MS initiated by an SMLC is not active, the BSC shall discard any RRLP message received from the MS. This precludes the initiation of any location service procedure from an MS.

The BSC may optionally allow one A-GNSS or E-OTD positioning procedure and one Cell-based or U-TDOA positioning procedure to be active concurrently for the same target MS. The BSC shall indicate the second independent location procedure is supported when SMLC instigates a first positioning procedure for any MS. The SMLC may initiate the concurrent positioning procedure only in when the BSC has indicated this capability. The BSC may disallow the concurrent positioning procedure at any time.

In the concurrent positioning procedure, if the SMLC invokes a first A-GNSS or E-OTD location procedure and then invokes a second A-GNSS or E-OTD then the BSC shall cancel the first procedure and proceed with the second without notifying the SMLC or target MS. In the concurrent location procedure, if the SMLC invokes a first cell-based or U-TDOA location procedure and then invokes a second cell-based or U-TDOA location procedure then the BSC shall cancel the first procedure and proceed with the second positioning procedure without notifying the SMLC or target 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 clauses for each positioning procedure. A serving BSC shall abort all existing location related procedures for a particular target MS without notifying a target MS if the DCCH to the target MS or the SCCP connection to the SMLC is released. In the event of an abort with an SMLC, the BSC shall attempt to notify the SMLC using a BSSAP-LE Perform Location Abort.

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

8.5.3.3 Interaction with Inter-BSC Handover

The BSC shall reject any request from an SMLC for positioning or transfer of assistance data while an inter-BSC 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 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 BSSAP 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.

8.5.3.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 procedure times out in the BSC, the BSC shall instead return either a BSSLAP Reset or a BSSLAP Abort to the SMLC.

A BSSLAP Reset shall contain a cause indication, the current serving cell identity, the current location area code if this has just changed due to intra-BSC handover and may contain measurement information for the target MS (e.g. TA value). A BSSLAP Reset shall also include the current location area code if there has been any change of location area since the location request for the target MS was first sent to the SMLC and if the current location area code was not yet reported to the SMLC in a previous BSSLAP Reset.

8.5.3.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 3GPP TS 44.006 and 3GPP TS 24.008. 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 not transmitted 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.

8.5.3.6 Interaction with Segmentation support for Legacy MS

If a location information transfer to an MS initiated by an SMLC is not active, the BSC shall discard any RRLP message segment received from the MS. 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 clause 8.1.

Further details regarding transfer and segmentation of RRLP messages between a BSC and MS can be found in 3GPP TS 44.018.

8.5.3.7 Overload

The BSC may indicate an inability to support location due to overload by rejecting with a cause indicating congestion a BSSAP Perform Location request received from the MSC. If an 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 3GPP TS 49.031, which give precedence to location service requests with a higher priority.

8.5.4 Procedures in the BSS in the PS Domain

8.5.4.1 General Procedures

The BSS 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 for any one TLLI. If a new procedure is instigated by the SMLC for any target MS, the BSS shall cancel any previous procedure without notifying the SMLC or target MS. The new procedure shall then be treated according to the prevailing conditions. If a location information transfer to an MS initiated by an SMLC is not active, the BSS shall discard any RRLP message received from the MS via the SGSN.

A serving BSS shall abort all existing location related procedures for a particular target MS without notifying a target MS if the SCCP connection to the SMLC is released. In the event of an abort when no BSSLAP procedure is active, but a location procedure is active, the BSS shall attempt to notify the SMLC using a BSSAP-LE Perform Location Abort.

A serving BSS shall abort all existing location related procedures for a particular target MS if the radio connection to the MS is lost. The SMLC shall be notified with a BSSAP-LE Perform Location Abort if no BSSLAP procedure is currently active. If there is an active BSSLAP procedure, the BSSLAP Abort message shall be sent to the SMLC.

A serving BSS shall return a BSSLAP Reject to the SMLC containing the cause of rejection, if the BSS receives the BSSGP Position Response message from the SGSN indicating a failure.

8.5.4.2 Rejection of an SMLC Positioning Request

The BSS may reject any request from an SMLC for positioning or transfer of assistance data for a target MS if the request cannot be performed. If the request is rejected, the BSS shall return a BSSLAP Reject to the SMLC containing the cause of rejection.

8.5.4.3 Overload

The BSS may indicate an inability to support location due to overload by rejecting with a cause indicating congestion sent in a BSSGP Perform Location Response message to the SGSN. If an SMLC has rejected a request from the BSS to perform location with a cause indicating congestion, the BSS shall convey the rejection and cause to the SGSN if the request was initiated by the SGSN. If the request was initiated by the BSS, the BSS may reduce the frequency of its location requests to the SMLC according to the rules in 3GPP TS 49.031, which give precedence to location service requests with a higher priority.

8.5.4.4 Inter BSS Cell Change

If the BSS detects (e.g. when it receives a BSSGP-FLUSH-LL PDU from the SGSN) that a target MS has changed cell to another BSS, it shall abort the positioning procedure by sending the BSSAP-LE Perform Location Abort to the SMLC.

8.5.5 Void

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

A target MS shall terminate any positioning procedure or the transfer of RRLP positioning assistance data without sending any response to the SMLC if a Routing Area Update Request message is sent to the SGSN or if a suspension request message is sent to the network or if its P-TMSI is reallocated.

8.7 Further Procedures for Handover

Handover procedures are described in 3GPP TS 23.271 [7].