6 LCS-AP Procedures
29.1713GPPLCS Application Protocol (LCS-AP) between the Mobile Management Entity (MME) and Evolved Serving Mobile Location Centre (E-SMLC)Location Services (LCS)Release 17SLs interfaceTS
6.1 General
The LCS-AP interface can be divided into the following procedures:
– Location service request procedure
– Location information exchange procedure
The E-UTRAN positioning capabilities are intended to be forward compatible to other access types and other position methods, in an effort to reduce the amount of additional positioning support needed in the future.
6.2 Procedures Applicable to LCS-AP
6.2.1 Location Service Request
6.2.1.1 General
The purpose of the location service request procedure is to obtain the location estimate for a target UE in E-UTRAN.
6.2.1.2 Successful Operation
Figure 6.2.1.2-1 Location Service Request Procedure, Successful Operation
The initiator (MME) of the location service request procedure sends a LCS-AP Location Request message to the E-SMLC associated with the current or last known serving cell for the target UE and starts the timer T3x01. The message contains the following mandatory (M), conditional (C) and optional (O) information, where conditional parameters are required if available.
– Correlation ID (M)
– Location Type (M)
– Cell Identifier (M)
– LCS Client Type (C)
– LCS Priority (C)
– LCS Service Type ID (C)
– LCS QoS (C)
– UE Positioning Capability (O)
– Include Velocity (O)
– IMSI of target UE (O)
– IMEI of target UE (O)
– APDU (O)
– RAT Type (O)
– Coverage Level (O)
– UE Country Determination Indication (O)
The Correlation ID is assigned by the MME and enables association of the location response with the location request when more than one location service request procedure is ongoing for the UE with the same E-SMLC.
The Location Type IE indicates the type of Location Information being requested. The following types are supported:
– Current geographic location estimate
– Location assistance data for the target UE
– Last known location estimate
If the location estimate is requested, the E-SMLC performs positioning procedure on the target UE using a particular position method or a combination of more than one positioning method based on the UE capability. If UE capability is unknown, the E-SMLC may request UE position capability through LPP as defined in 3GPP TS 36.305 [2]. If the location estimate is requested and the UE Country Determination Indication is set to "required", the E-SMLC shall map the location estimate to the country or the area in the country or international area.
Alternatively, if assistance data was requested, the E-SMLC may provide positioning assistance data to the UE. The E-SMLC may invoke the following LCS-AP procedures to get assistance data:
– Connection Oriented Information Transfer
– Connectionless Information Transfer
Otherwise, if a last known location estimate is requested, the E-SMLC obtains a geographic location estimate using only the information provided in the LCS-AP Location Request message. The E-SMLC shall not attempt to obtain location information for the target UE from either the E-UTRAN or the target UE (e.g. because the UE may not be currently reachable).
If a location estimate or a last known location estimate was requested and was subsequently obtained, the E-SMLC shall return a LCS-AP Location Response to the initiator of the location request using the same SCTP association as the location request. This message contains the following mandatory (M), conditional (C) and optional parameters (O).
– Correlation ID (M)
– Location Estimate (M).
– Accuracy Fulfilment Indicator (O).
– Velocity estimate (C).
– Positioning Data (C).
– E-UTRAN Cell Identifier (O).
– Cell Portion ID (O).
– Civic Address (O).
– Barometric Pressure (O).
– UE Area Indication (O).
If assistance data was instead requested for an UE and the E-SMLC was able successfully to transfer this to the UE, the E-SMLC shall return a LCS-AP Location Response to the initiator of the location request (MME). This message shall contain no parameters. The absence of a LCS Cause parameter in this case implies that the transfer was successful.
If the MME receives the LCS-AP Location Response for corresponding request message, the MME shall stop the timer T3x01.
6.2.1.3 Unsuccessful Operation
If the E-SMLC is unable to obtain any of the location information requested or if requested LCS assistance data could not be transferred, the E-SMLC shall return a LCS-AP Location Response to the initiator of the Location Request carrying the following parameters:
– Correlation ID (M)
– LCS Cause (M)
– Positioning Data (O)
The E-SMLC shall use the same SCTP association for the Location Response as was used for the request.
If the MME receives the LCS-AP Location Response for corresponding request message, the MME shall stop the timer T3x01.
On the expiry of the timer T3x01, the MME shall abort the procedure, release any resources allocated for this location request procedure and notify the node that triggered the Location Request about the error.
6.2.2 Location Information Exchange
6.2.2.1 Connection Oriented Information Transfer
6.2.2.1.1 General
The Connection Oriented Information transfer procedure enables two-way transfer of LPP and LPPa messages between an E-SMLC and a MME. The procedure is only valid while a location request procedure for the target UE is ongoing. This procedure makes use of the same SCTP association as the location request procedure for the particular target UE.
6.2.2.1.2 Successful Operation
Figure 6.2.2.1.2-1 Connection Oriented Information, Successful Operation
The initiator of the procedure (E-SMLC or MME) with a LPP or LPPa message to transfer concerning a particular target UE sends a LCS-AP Connection Oriented Information message to a recipient carrying the following parameters:
– Correlation ID (M)
– Payload Type (M)
– APDU (M);
The Correlation ID in this message is the Correlation ID used for the Location Request. It shall be present for a message transfer from the E-SMLC to the MME and for a message transfer from the MME to the E-SMLC.
The Payload Type shall be present to indicate the type of the APDU. The supported information types are LPP and LPPa.
The APDU shall contain an LPP APDU when communicating between the E-SMLC and the target UE or an LPPa APDU when communicating between the E-SMLC and serving eNB. The MME shall forward this to the serving eNB for the target UE.
If the intended recipient is the E-SMLC for a target UE, the message is terminated in the E-SMLC. The E-SMLC shall then perform interpretation of the APDU.
6.2.2.1.3 Abnormal Conditions
At an intermediate entity, if a received LCS-AP Connection Oriented Information message contains unrecognized information or if the message cannot be sent on, the message shall be discarded.
6.2.2.2 Connectionless Information Transfer
6.2.2.2.1 General
The Connectionless Information transfer procedure enables two-way transfer of LPPa messages between an E-SMLC and a MME when there is no existing signalling connection association. This procedure can be used to query eNBs for the information not related to a UE connection, such as Timing information on the eNB.
6.2.2.2.2 Successful Operation
Figure 6.2.2.2.2-1 Connectionless Information Procedure, Successful Operation
The initiator of the procedure (either E-SMLC or MME) sends a LCS-AP Connectionless Information message to a recipient carrying the following parameters:
– Source Entity (M)
– Destination Entity (M)
– APDU (M)
– Return Error Request (O)
The source entity identifies the sender. The recipient entity identifies the final destination. The APDU contains a LPPa APDU to be transferred. The Return Error Request may be included to request notification in the event of unsuccessful transfer and indicate the type of notification needed. If the recipient entity is not the final destination, the recipient shall transfer the LCS-AP Connectionless Information message to either the final destination or an intermediate entity capable of forward it to the final destination.
6.2.2.2.3 Unsuccessful Operation
If the message cannot be transferred by an intermediate entity or destination entity and the Return Error Request is not included, the message shall be discarded. If the Return Error Request is included, the intermediate or destination entity shall, depending on the Return Error Request type, send a LCS-AP Connectionless Information message to, or towards, the original source containing the following parameters:
– Source Entity (M)
– Destination Entity (M)
– APDU (M)
– Return Error Cause (M)
The Source entity shall indicate the Destination Entity in the original received message. The Destination Entity shall indicate the Source Entity in the original message. The Return Error cause shall indicate the reason for unsuccessful transfer. The APDU shall contain any originally received APDU.
If a received LCS-AP Connectionless Information message containing a Return Error Cause cannot be transferred by an intermediate entity, it shall be discarded with no return error message.
6.2.2.2.4 Abnormal Conditions
At an intermediate entity, if a received LCS-AP Connectionless Information message contains unrecognized or invalid information, the message shall be discarded.
At the recipient entity, if a received LCS-AP Connectionless Information message contains invalid or unrecognized information as defined for LCS-AP, the message shall be discarded.
6.2.3 Ciphering Keys Delivery
6.2.3.1 General
The purpose of the ciphering keys delivery procedure is to enable the E-SMLC to send ciphering keys for broadcast assistance data to the MME so that the MME can then distribute the ciphering keys to suitably subscribed UEs.
6.2.3.2 Successful Operation
Figure 6.2.3.2-1 Ciphering Keys Delivery Procedure, Successful Operation
The initiator (E-SMLC) of the ciphering keys delivery procedure sends a Ciphering Key Data message to the MME and starts the timer T3x03. The message contains the following mandatory (M) information:
– Ciphering Data (M):
If the MME is able to successfully store all ciphering data sets included in the Ciphering Key Data message, the MME sends a Ciphering Key Data Result message. The message contains the following mandatory (M) information:
– Ciphering Data Ack (M)
If the E-SMLC receives the Ciphering Key Data Result message, the E-SMLC shall stop the timer T3x03.
6.2.3.3 Unsuccessful Operation
If the MME is unable to successfully store one or more ciphering data sets included in the Ciphering Key Data message, the MME shall return a Ciphering Key Data Result message carrying the following mandatory (M) information:
– Ciphering Data Error Report (M)
If the E-SMLC receives the Ciphering Key Data Result message message, the E-SMLC shall stop the timer T3x03.
On the expiry of the timer T3x03, the E-SMLC shall abort the procedure and release any resources allocated for this ciphering keys delivery procedure.
6.3 Exception Procedures
6.3.1 Location Abort
6.3.1.1 General
The purpose of the Location Abort procedure is to cancel an ongoing positioning attempt or the request for assistance data. This message can be sent from the MME to the E-SMLC. This procedure makes use of the same SCTP association as the location request procedure for the particular target UE.
6.3.1.2 Normal Operation
Figure 6.3.1.2-1 Location Abort Procedure, Normal Operation
The MME sends a LCS-AP Location Abort Request message to the E-SMLC across the SLs interface. The message contains a LCS Cause parameter indicating the reason of cancellation.
On receipt of this message, the E-SMLC shall stop the positioning transactions of the target UE and may release any resources previously allocated. The E-SMLC shall return a LCS-AP Location Response message containing the LCS Cause received in Location Abort Request and, optionally, positioning data. The E-SMLC may also optionally include in this response any "best-effort" location estimate that it has already determined prior to receiving the LCS-AP Location Abort Request.
6.3.1.3 Abnormal Conditions
At the recipient entity, if no ongoing location transaction for the target UE is found, the recipient entity shall discard the received LCS-AP Location Abort Request message with no return error message.
6.3.2 Reset
6.3.2.1 General
The Reset procedure is an optional procedure applicable to the LCS-AP. It enables an E-SMLC or a MME that has undergone a failure with loss of location service transactions to indicate this to a partner entity. The recipient entity can then release its own connection and transaction resources. The Reset procedure may not be applicable when only a limited part of an E-SMLC or a MME has suffered a failure, since error recovery procedures specific to individual connections and transactions may then be used. The Reset procedure applies to all transactions initiated on a single SCTP association.
6.3.2.2 Normal Operation
Figure 6.3.2.2-1 Reset Procedure, Normal Operation
In the event of a failure at an E-SMLC or a MME that results in the loss of location service transactions, a LCS-AP Reset Request message may be sent to the partner entity across the SLs interface. The message contains a LCS Cause parameter indicating the reason for the reset. The sending entity shall ensure that all information on location service transactions for the SCTP association on which the Reset Request was sent is reinitialized to indicate no existing transactions.
On receiving a LCS-AP Reset Request message, the recipient entity (E-SMLC or MME) shall clear all references and state information for the location service transactions on the SCTP association on which the Reset Request was received and shall release any associated resources. The recipient entity shall then return a LCS-AP Reset Acknowledge message using the same SCTP association as the Reset Request.
If the initiating entity (E-SMLC or MME) received the LCS-AP Reset Acknowledge message, it shall stop the timer T3x02.
6.3.2.3 Abnormal Conditions
On the first expiry of the timer T3x02, the Source entity (E-SMLC or MME) shall resend the LCS-AP Reset Request message and shall reset and restart timer T3x02. This retransmission is repeated a maximum of "n" times, where "n" is an O&M administered parameter. Following "n" unsuccessful reset attempts, the procedure shall be terminated and maintenance shall be informed.
6.4 Error Handling
6.4.1 Abnormal Conditions
If an ongoing location request is pre-empted at the initiator by an inter-eNB handover and MME relocation, or if the main signalling link to the target UE is released by the MME, or if a main signalling link failure indicated by the serving eNodeB persists for more than a certain timeout interval or if there is a timeout waiting for the positioning response, or any other abnormal conditions for which the positioning procedure cannot be maintained, the MME shall send a LCS-AP Location Abort message to the E-SMLC to terminate the positioning procedure.
For Intra-MME handovers, the location session between the MME and E-SMLC is not affected. Application layer impacts on these handovers are handled by higher protocol layers.
If the E-SMLC cannot proceed with positioning due to some protocol violation or error condition (e.g. inter-eNB handover), it shall return a LCS-AP Location Response message to the initiator containing a LCS cause and, optionally, positioning data.
6.4.2 Overload
If an E-SMLC is in overload condition, it may reject a LCS-AP Location Request by returning a LCS-AP Location Response containing a LCS Cause parameter indicating congestion. The initiator of the location requests (i.e. MME) may reduce the frequency of later location requests until rejection due to overload has ceased. In reducing the frequency of location service requests, the MME shall reduce lower priority requests, to zero if necessary, before reducing the frequency of higher priority requests. An E-SMLC shall similarly reject location requests of a lower priority, to zero if necessary, due to overload before rejecting location requests of a higher priority. An E-SMLC in overload condition may optionally employ the following procedures to alleviate overload:
a) Allow higher priority location service requests to pre-empt lower priority requests for which location service procedures are already in progress.
b) Abort lower priority location service requests already in progress.
c) Reduce the supported QoS for lower priority requests for a location estimate – e.g. by reducing accuracy or increasing response time.
d) Employ UE based positioning methods, where supported by the target UE and the E-SMLC, rather than UE assisted or network based methods (except TA).
The priority of a location request shall be defined according to the value in the LCS Priority parameter. If this parameter is absent in a LCS-AP Location Request, the lowest priority shall be assumed.