5 LPP Procedures

37.3553GPPLTE Positioning Protocol (LPP)Release 17TS

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

5.1 Procedures related to capability transfer

The purpose of the procedures that are grouped together in this clause is to enable the transfer of capabilities from the target device to the server. Capabilities in this context refer to positioning and protocol capabilities related to LPP and the positioning methods supported by LPP.

These procedures instantiate the Capability Transfer transaction from TS 36.305 [2] and TS 38.305 [40].

5.1.1 Capability Transfer procedure

The Capability Transfer procedure is shown in Figure 5.1.1-1.

Figure 5.1.1-1: LPP Capability Transfer procedure

1. The server sends a RequestCapabilities message to the target. The server may indicate the types of capability needed.

2. The target responds with a ProvideCapabilities message to the server. The capabilities shall correspond to any capability types specified in step 1. This message shall include the endTransaction IE set to TRUE.

5.1.2 Capability Indication procedure

The Capability Indication procedure allows the target to provide unsolicited capabilities to the server and is shown in Figure 5.1.2-1.

Figure 5.1.2-1: LPP Capability Indication procedure

1. The target sends a ProvideCapabilities message to the server. This message shall include the endTransaction IE set to TRUE.

5.1.3 Reception of LPP Request Capabilities

Upon receiving a RequestCapabilities message, the target device shall generate a ProvideCapabilities message as a response.

The target device shall:

1> for each positioning method for which a request for capabilities is included in the message:

2> if the target device supports this positioning method:

3> include the capabilities of the device for that supported positioning method in the response message;

1> set the IE LPP-TransactionID in the response message to the same value as the IE LPP-TransactionID in the received message;

1> deliver the response message to lower layers for transmission.

5.1.4 Transmission of LPP Provide Capabilities

When triggered to transmit a ProvideCapabilities message, the target device shall:

1> for each positioning method whose capabilities are to be indicated:

2> set the corresponding IE to include the device’s capabilities;

2> if OTDOA capabilities are to be indicated:

3> include the IE supportedBandListEUTRA;

1> deliver the response to lower layers for transmission.

5.2 Procedures related to Assistance Data Transfer

The purpose of the procedures in this clause is to enable the target to request assistance data from the server to assist in positioning, and to enable the server to transfer assistance data to the target in the absence of a request.

These procedures instantiate the Assistance Data Transfer transaction from TS 36.305 [2] and TS 38.305 [40].

5.2.1 Assistance Data Transfer procedure

The Assistance Data Transfer procedure is shown in Figure 5.2.1-1.

Figure 5.2.1-1: LPP Assistance data transfer procedure

1. The target sends a RequestAssistanceData message to the server.

2. The server responds with a ProvideAssistanceData message to the target containing assistance data. The transferred assistance data should match or be a subset of the assistance data requested in step 1. The server may also provide any not requested information that it considers useful to the target. If step 3 does not occur, this message shall set the endTransaction IE to TRUE.

3. The server may transmit one or more additional ProvideAssistanceData messages to the target containing further assistance data. The transferred assistance data should match or be a subset of the assistance data requested in step 1. The server may also provide any not requested information that it considers useful to the target. The last message shall include the endTransaction IE set to TRUE.

5.2.1a Periodic Assistance Data Transfer procedure

The Periodic Assistance Data Transfer procedure is shown in Figure 5.2.1a-1. This procedure enables a target to request a server to send assistance data periodically.

NOTE 1: In this version of the specification, periodic assistance data transfer is supported for HA GNSS (e.g., RTK) positioning only.

Figure 5.2.1a-1: LPP Periodic Assistance data transfer procedure

1. The target sends a RequestAssistanceData message to the server using some available transactionID T1. The message contains a periodicSessionID S (different to any other periodicSessionID currently in use between the target and server) in the IE CommonIEsRequestAssistanceData. The message also includes a positioning method specific assistance data request element (e.g., IE A-GNSS-RequestAssistanceData) identifying the type of assistance data being requested together with desired periodicity conditions for sending it and a duration for ending the assistance data transfer (e.g., in IE GNSS-PeriodicAssistDataReq).

2. The server responds with a ProvideAssistanceData message to the target. The message uses the transactionID T1 in step 1 and indicates the end of this transaction. The message contains the periodicSessionID S in IE CommonIEsProvideAssistanceData. If the request can be supported, the message contains the control parameters in the positioning method specific assistance data (e.g., IE A-GNSS-ProvideAssistanceData) which may confirm or redefine the type of assistance data or periodicity parameters requested at step 1 (e.g., in IE GNSS‑PeriodicAssistData). If the target requested non-periodic assistance data in addition to the periodic assistance data in step 1, the ProvideAssistanceData message may also include the non-periodic assistance data in this step 2 (but not any periodic assistance data).
If the request cannot be supported (fully or partly), an error reason is provided in the positioning method specific IE (e.g., IE A‑GNSS‑Error). If the request cannot even partly be supported remaining steps are then not performed.

NOTE 2: The target device infers from an absence of the periodicSessionID that the location server does not support periodic assistance data delivery. In that case, the target device does not expect the Data Transaction (Steps 3-7).

3. When the first periodic message is available, the server sends an unsolicited ProvideAssistanceData message to the target containing the periodicSessionID S and the periodic assistance data confirmed in step 2. The message uses some available transactionID T2 that may be different to T1.

NOTE 3: The positioning method specific control parameters (e.g., IE GNSS-PeriodicAssistData) are not included in the data transaction.

4. The server may continue to send further ProvideAssistanceData messages to the target containing the periodic assistance data confirmed or redefined in step 2 when each additional periodicity condition occurs.

NOTE 4: The target device expects a ProvideAssistanceData messages at the in Step 2 confirmed interval(s). If some or all of the assistance data is not available at each periodic interval, an error indication is provided in the positioning method specific IE (e.g., IE A‑GNSS‑Error).

5. If the target requires the session to end, the target sends an Abort message to the server for transaction T2 that may optionally include an abortCause. Remaining steps are then omitted.

6. If the server requires the session to end, the server sends an Abort message to the target for transaction T2 that may optionally include an abortCause. Remaining steps are then omitted.

7. When the duration or other conditions for ending the periodic assistance data transfer occur, the last ProvideAssistanceData message transferred indicates the end of transaction T2.

5.2.1b Periodic Assistance Data Transfer with Update procedure

Figure 5.2.1b-1: LPP Periodic Assistance data transfer with update procedure

1. Steps 1-2 and optionally steps 3-4 are performed for the Periodic Assistance Data Transfer procedure in clause 5.2.1a with the following exceptions:

– The RequestAssistanceData message in step 1 indicates the update capabilities of the target device.

– The ProvideAssistanceData message in step 2 indicates the update capabilities of the target device which are supported by the server.

2. If the target device changes its primary cell and if the update capabilities of the target device supported by the server in step 1 include update of a primary cell ID, the target device sends a RequestAssistanceData message to the server using some available transactionID T3, which is different from T2 (previously used in step 2). The message contains the periodicSessionID S (previously used in step 1) and the new primary cell ID in the IE CommonIEsRequestAssistanceData.

3. The server responds with a ProvideAssistanceData message to the target. The message uses the transactionID T3 in step 2 and indicates the end of this transaction. The message contains the periodicSessionID S in IE CommonIEsProvideAssistanceData. Steps 2-3 are repeated each time the target device changes its primary cell.

4. Steps 4-7 are performed for the Periodic Assistance Data Transfer procedure in clause 5.2.1a.

5.2.2 Assistance Data Delivery procedure

The Assistance Data Delivery procedure allows the server to provide unsolicited assistance data to the target and is shown in Figure 5.2.2-1.

Figure 5.2.2-1: LPP Assistance data transfer procedure

1. The server sends a ProvideAssistanceData message to the target containing assistance data. If step 2 does not occur, this message shall set the endTransaction IE to TRUE.

2. The server may transmit one or more additional ProvideAssistanceData messages to the target containing additional assistance data. The last message shall include the endTransaction IE set to TRUE.

5.2.2a Periodic Assistance Data Delivery procedure

The Periodic Assistance Data Delivery procedure allows the server to provide unsolicited periodic assistance data to the target and is shown in Figure 5.2.2a-1.

NOTE 1: In this version of the specification, periodic assistance data delivery is supported for HA GNSS (e.g., RTK) positioning only.

Figure 5.2.2a-1: LPP Periodic Assistance data delivery procedure

1. The server sends a ProvideAssistanceData message to the target using some available transactionID T1 and indicates the end of this transaction. The message contains a periodicSessionID S (different to any other periodicSessionID currently in use between the server and target) in the IE CommonIEsProvideAssistanceData. The message includes positioning method specific assistance data control parameters (e.g., in IE A‑GNSS‑ProvideAssistanceData) identifying the type of periodic assistance data being delivered together with periodicity conditions for sending it and a duration for ending the assistance data delivery (e.g., in IE GNSS‑PeriodicAssistData). The ProvideAssistanceData message may also include non-periodic assistance data (but not any periodic assistance data).

2. When the first periodic message is available, the server sends an unsolicited ProvideAssistanceData message to the target containing the periodicSessionID S and the periodic assistance data announced in step 1. The message uses some available transactionID T2 that may be different to T1.

NOTE 2: The positioning method specific control parameters (e.g., IE GNSS-PeriodicAssistData) are not included in the data transaction.

3. The server may continue to send further ProvideAssistanceData messages to the target containing the periodic assistance data announced in step 2 when each additional periodicity condition occurs.

NOTE3: The target device expects a ProvideAssistanceData messages at the in Step 2 announced interval(s). If some or all of the assistance data is not available at each periodic interval, an error indication is provided in the positioning method specific IE (e.g., IE A‑GNSS‑Error).

4. If the target requires the session to end, the target sends an Abort message to the server for transaction T2 that may optionally include an abortCause. Remaining steps are then omitted.

5. If the server requires the session to end, the server sends an Abort message to the target for transaction T2 that may optionally include an abortCause. Remaining steps are then omitted.

6. When the duration or other conditions for ending the periodic assistance data transfer occur, the last ProvideAssistanceData message transferred indicates the end of transaction T2.

5.2.3 Transmission of LPP Request Assistance Data

When triggered to transmit a RequestAssistanceData message, the target device shall:

1> set the IEs for the positioning-method-specific request for assistance data to request the data indicated by upper layers.

5.2.4 Reception of LPP Provide Assistance Data

Upon receiving a ProvideAssistanceData message, the target device shall:

1> for each positioning method contained in the message:

2> deliver the related assistance data to upper layers.

5.3 Procedures related to Location Information Transfer

The purpose of the procedures in this clause is to enable the server to request location measurement data and/or a location estimate from the target, and to enable the target to transfer location measurement data and/or a location estimate to a server in the absence of a request.

These procedures instantiate the Location Information Transfer transaction in TS 36.305 [2] and TS 38.305 [40].

NOTE: The service layer (e.g. NAS or OMA SUPL ULP) would be used to transfer information associated with a location request from a target to a server (MO-LR).

5.3.1 Location Information Transfer procedure

The Location Information Transfer procedure is shown in Figure 5.3.1-1.

Figure 5.3.1-1: LPP Location Information transfer procedure

1. The server sends a RequestLocationInformation message to the target to request location information, indicating the type of location information needed and potentially the associated QoS.

2. The target sends a ProvideLocationInformation message to the server to transfer location information. The location information transferred should match or be a subset of the location information requested in step 1 unless the server explicitly allows additional location information. If step 3 does not occur, this message shall set the endTransaction IE to TRUE.

3. If requested in step 1, the target sends additional ProvideLocationInformation messages to the server to transfer location information. The location information transferred should match or be a subset of the location information requested in step 1 unless the server explicitly allows additional location information. The last message shall include the endTransaction IE set to TRUE.

5.3.2 Location Information Delivery procedure

The Location Information Delivery allows the target to provide unsolicited location information to the server. The procedure is shown in Figure 5.3.2-1.

Figure 5.3.2-1: LPP Location Information Delivery procedure

1. The target sends a ProvideLocationInformation message to the server to transfer location information. If step 2 does not occur, this message shall set the endTransaction IE to TRUE.

2. The target may send one or more additional ProvideLocationInformation messages to the server containing additional location information data. The last message shall include the endTransaction IE set to TRUE.

5.3.3 Reception of Request Location Information

Upon receiving a RequestLocationInformation message, the target device shall:

1> if the requested information is compatible with the target device capabilities and configuration:

2> include the requested information in a ProvideLocationInformation message;

2> set the IE LPP-TransactionID in the response to the same value as the IE LPP-TransactionID in the received message;

2> deliver the ProvideLocationInformation message to lower layers for transmission.

1> otherwise:

2> if one or more positioning methods are included that the target device does not support:

3> continue to process the message as if it contained only information for the supported positioning methods;

3> handle the signaling content of the unsupported positioning methods by LPP error detection as in 5.4.3.

5.3.4 Transmission of Provide Location Information

When triggered to transmit ProvideLocationInformation message, the target device shall:

1> for each positioning method contained in the message:

2> set the corresponding IE to include the available location information;

1> deliver the response to lower layers for transmission.

5.4 Error Handling Procedures

5.4.1 General

This clause describes how a receiving entity (target device or location server) behaves in cases when it receives erroneous or unexpected data or detects that certain data are missing.

5.4.2 Procedures related to Error Indication

Figure 5.4.2-1 shows the Error indication procedure.

Figure 5.4.2-1: LPP Error Indication procedure

1. Endpoint A sends an LPP message to Endpoint B.

2. Endpoint B determines that the LPP message in step 1 contains an error. Endpoint B returns an Error message to Endpoint A indicating the error or errors and discards the message in step 1. If Endpoint B is able to determine that the erroneous LPP message in step 1 is an LPP Error or Abort Message, Endpoint B discards the message in step 1 without returning an Error message to Endpoint A.

5.4.3 LPP Error Detection

Upon receiving any LPP message, the receiving entity shall attempt to decode the message and verify the presence of any errors and:

1> if decoding errors are encountered:

2> if the receiver can not determine that the received message is an LPP Error or Abort message:

3> return an LPP Error message to the sender and include the received LPP-TransactionID, if this was decoded, and type of error;

3> if the receiver can determine the session and the LPP-TransactionID and the received message includes the IE SegmentationInfo and the receiver has previously stored message segments for this session and LPP-TransactionID:

4> discard all stored LPP message segments for this session and LPP-TransactionID;

3> discard the received message and stop the error detection procedure;

1> if the message is a duplicate of a previously received message:

2> discard the message and stop the error detection procedure;

1> if the LPP-TransactionID matches the LPP-TransactionID for a procedure that is still ongoing for the same session and the message type is invalid for the current state of the procedure:

2> abort the ongoing procedure;

2> return an LPP Error message to the sender and include the received transaction ID and type of error;

2> if the message includes the IE SegmentationInfo and the receiver has previously stored message segments for this session and LPP-TransactionID:

3> discard all stored LPP message segments for this session and LPP-TransactionID;

2> discard the message and stop the error detection procedure;

1> if the message includes the IE SegmentationInfo:

2> if the receiver has previously stored LPP message segments for this session and LPP-TransactionID:

3> if the received message type is different to the stored message type:

4> return an LPP Error message to the sender and include the received transaction ID and type of error;

4> discard the message and all stored LPP message segments for this session and LPP-TransactionID and stop the error detection procedure;

2> if the IE SegmentationInfo has the value moreMessagesOnTheWay:

3> store the received message;

NOTE: As an implementation option, the receiver of an LPP Provide Assistance Data or LPP Provide Location Information message may process the received message segment instead of storing the message.

2> if the IE SegmentationInfo has the value noMoreMessages:

3> continue error detection for the received message and any stored LPP message segments for this session and LPP-TransactionID;

1> if the message type is an LPP RequestCapabilities and some of the requested information is not supported:

2> return any information that can be provided in a normal response.

1> if the message type is an LPP RequestAssistanceData or RequestLocationInformation and some or all of the requested information is not supported:

2> return any information that can be provided in a normal response, which includes indications on other information that is not supported.

5.4.4 Reception of an LPP Error Message

Upon receiving an Error message, a device shall:

1> abort any ongoing procedure associated with the LPP-TransactionID if included in the received message.

The device may:

1> restart the aborted procedure taking into consideration the returned error information.

5.5 Abort Procedure

5.5.1 General

The purpose of the abort procedure is to allow the target device or location server to abort an ongoing procedure due to some unexpected event (e.g., cancellation of a location request by an LCS client). It can also be used to stop an ongoing procedure (e.g., periodic location reporting from the target device).

5.5.2 Procedures related to Abort

Figure 5.5.2-1 shows the Abort procedure.

Figure 5.5.2-1: LPP Abort procedure

1. A procedure P is ongoing between endpoints A and B.

2. Endpoint A determines that the procedure must be aborted and sends an Abort message to Endpoint B carrying the transaction ID for procedure P. Endpoint B aborts procedure P.

5.5.3 Reception of an LPP Abort Message

Upon receiving an Abort message, a device shall:

1> abort any ongoing procedure associated with the transaction ID indicated in the message.