4 Functionality of Protocol

37.3553GPPLTE Positioning Protocol (LPP)Release 17TS

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

4.1 General

4.1.1 LPP Configuration

LPP is used point-to-point between a location server (E-SMLC, LMF or SLP) and a target device (UE or SET) in order to position the target device using position-related measurements obtained by one or more reference sources. Figure 4.1.1-1 shows the configuration as applied to the control- and user-plane location solutions for E-UTRAN and NG-RAN (as defined in TS 36.305 [2], TS 38.305 [40], TS 23.273 [42] and TS 23.271 [3]).

NB-IoT is a non-backward compatible variant of E-UTRAN supporting a reduced set of functionalities. In this specification, procedures and messages specified for the UE equally apply to the UE in NB-IoT.

Figure 4.1.1-1: LPP Configuration for Control- and User-Plane Positioning in E-UTRAN or NG-RAN

4.1.2 LPP Sessions and Transactions

An LPP session is used between a Location Server and the target device in order to obtain location related measurements or a location estimate or to transfer assistance data. A single LPP session is used to support a single location request (e.g., for a single MT-LR, MO-LR or NI-LR). Multiple LPP sessions can be used between the same endpoints to support multiple different location requests (as required by TS 23.271 [3]). Each LPP session comprises one or more LPP transactions, with each LPP transaction performing a single operation (capability exchange, assistance data transfer, or location information transfer). In E-UTRAN and NG-RAN, the LPP transactions are realized as LPP procedures. The instigator of an LPP session will always instigate the first LPP transaction, but subsequent transactions may be instigated by either end. LPP transactions within a session may occur serially or in parallel. LPP transactions are indicated at the LPP protocol level with a transaction ID in order to associate messages with one another (e.g., request and response).

Messages within a transaction are linked by a common transaction identifier.

4.1.3 LPP Position Methods

Internal LPP positioning methods and associated signalling content are defined in this specification.

This version of the specification defines OTDOA (based on LTE signals), A-GNSS, E-CID (based on LTE signals), Sensor, TBS, WLAN, Bluetooth, NR E-CID, NR DL-TDOA, NR DL-AoD and NR Multi-RTT positioning methods.

4.1.4 LPP Messages

Each LPP transaction involves the exchange of one or more LPP messages between the location server and the target device. The general format of an LPP message consists of a set of common fields followed by a body. The body (which may be empty) contains information specific to a particular message type. Each message type contains information specific to one or more positioning methods and/or information common to all positioning methods.

The common fields are as follows:

Field	Role
Transaction ID	Identify messages belonging to the same transaction
Transaction End Flag	Indicate when a transaction (e.g. one with periodic responses) has ended
Sequence Number	Enable detection of a duplicate LPP message at a receiver
Acknowledgement	Enable an acknowledgement to be requested and/or returned for any LPP message

NOTE: Use of the Transaction ID and Transaction End fields conform to the procedures in clause 5 and are independent of the means used to transport LPP messages (e.g., whether using a NAS MO-LR Request, NAS Generic Transport or user-plane solution).

The following message types are defined:

– Request Capabilities;

– Provide Capabilities;

– Request Assistance Data;

– Provide Assistance Data;

– Request Location Information;

– Provide Location Information;

– Abort;

– Error.

4.2 Common LPP Session Procedure

The purpose of this procedure is to support an LPP session comprising a sequence of LPP transactions. The procedure is described in Figure 4.2-1.

Figure 4.2-1 LPP Session Procedure

1. Endpoint A, which may be either the target or the server, initiates an LPP session by sending an LPP message for an initial LPP transaction j to the other endpoint B (which has an opposite role to A).

2. Endpoints A and B may exchange further messages to continue the transaction started in step 1.

3. Either endpoint may instigate further transactions by sending additional LPP messages.

4. A session is terminated by a final transaction N in which LPP messages will be exchanged between the two endpoints.

Within each transaction, all constituent messages shall contain the same transaction identifier. The last message sent in each transaction shall have the IE endTransaction set to TRUE. Transactions that occur in parallel shall use different transaction IDs; transaction IDs for completed transactions may be reused at any time after the final message of the previous transaction with the same ID is known to have been received.

4.3 LPP Transport

4.3.1 Transport Layer Requirements

LPP requires reliable, in-sequence delivery of LPP messages from the underlying transport layers. This clause describes the transport capabilities that are available within LPP. A UE implementing LPP for the control-plane solution shall support LPP reliable transport (including all three of duplicate detection, acknowledgement, and retransmission).

LPP reliable transport functionality is not used in the user-plane solution.

The following requirements in clauses 4.3.2, 4.3.3, and 4.3.4 for LPP reliable transport apply only when the capability is supported.

4.3.2 LPP Duplicate Detection

A sender shall include a sequence number in all LPP messages sent for a particular location session. The sequence number shall be distinct for different LPP messages sent in the same direction in the same location session (e.g., may start at zero in the first LPP message and increase monotonically in each succeeding LPP message). Sequence numbers used in the uplink and downlink are independent (e.g., can be the same).

A receiver shall record the most recent received sequence number for each location session. If a message is received carrying the same sequence number as that last received for the associated location session, it shall be discarded. Otherwise (i.e., if the sequence number is different or if no sequence number was previously received or if no sequence number is included), the message shall be processed.

Sending and receiving sequence numbers shall be deleted in a server when the associated location session is terminated and shall be deleted in a target device when there has been no activity for a particular location session for 10 minutes.

NOTE: For LPP control-plane use, a target device can be aware of a location session from information provided at the NAS level for downlink transport of an LPP message.

4.3.3 LPP Acknowledgement

4.3.3.1 General

Each LPP message may carry an acknowledgement request and/or an acknowledgement indicator. A LPP message including an acknowledgement request (i.e., that include the IE ackRequested set to TRUE) shall also include a sequence number. Upon reception of an LPP message which includes the IE ackRequested set to TRUE, a receiver returns an LPP message with an acknowledgement response (i.e., that includes the ackIndicator IE set to the same sequence number of the message being acknowledged). An acknowledgement response may contain no LPP message body (in which case only the sequence number being acknowledged is significant); alternatively, the acknowledgement may be sent in an LPP message along with an LPP message body. An acknowledgement is returned for each received LPP message that requested an acknowledgement including any duplicate(s). Once a sender receives an acknowledgement for an LPP message, and provided any included sequence number is matching, it is permitted to send the next LPP message. No message reordering is needed at the receiver since this stop-and-wait method of sending ensures that messages normally arrive in the correct order.

When an LPP message is transported via a NAS MO-LR request, the message does not request an acknowledgement.

4.3.3.2 Procedure related to Acknowledgement

Figure 4.3.3.2-1 shows the procedure related to acknowledgement.

Figure 4.3.3.2-1: LPP Acknowledgement procedure

1. Endpoint A sends an LPP message N to Endpoint B which includes the IE ackRequested set to TRUE and a sequence number.

2. If LPP message N is received and Endpoint B is able to decode the ackRequested value and sequence number, Endpoint B shall return an acknowledgement for message N. The acknowledgement shall contain the IE ackIndicator set to the same sequence number as that in message N.

3. When the acknowledgement for LPP message N is received and provided the included ackIndicator IE matches the sequence number sent in message N, Endpoint A sends the next LPP message N+1 to Endpoint B when this message is available.

4.3.4 LPP Retransmission

4.3.4.1 General

This capability builds on the acknowledgement and duplicate detection capabilities. When an LPP message which requires acknowledgement is sent and not acknowledged, it is resent by the sender following a timeout period up to three times. If still unacknowledged after that, the sender aborts all LPP activity for the associated session. The timeout period is determined by the sender implementation but shall not be less than a minimum value of 250 ms.

In addition, for NB-IoT the timeout period may be determined by the sender implementation based on e.g., the coverage level of the UE.

4.3.4.2 Procedure related to Retransmission

Figure 4.3.4.2-1 shows the procedure related to retransmission when combined with acknowledgement and duplicate detection.

Figure 4.3.4.2-1: LPP Retransmission procedure

1. Endpoint A sends an LPP message N to Endpoint B for a particular location session and includes a request for acknowledgement along with a sequence number.

2. If LPP message N is received and Endpoint B is able to decode the ackRequested value and sequence number (regardless of whether the message body can be correctly decoded), Endpoint B shall return an acknowledgement for message N. If the acknowledgement is received by Endpoint A (such that the acknowledged message can be identified and sequence numbers are matching), Endpoint A skips steps 3 and 4.

3. If the acknowledgement in step 2 is not received after a timeout period, Endpoint A shall retransmit LPP message N and shall include the same sequence number as in step 1.

4. If LPP message N in step 3 is received and Endpoint B is able to decode the ackRequested value and sequence number (regardless of whether the message body can be correctly decoded and whether or not the message is considered a duplicate), Endpoint B shall return an acknowledgement. Steps 3 may be repeated one or more times if the acknowledgement in step 4 is not received after a timeout period by Endpoint A. If the acknowledgement in step 4 is still not received after sending three retransmissions, Endpoint A shall abort all procedures and activity associated with LPP support for the particular location session.

5. Once an acknowledgement in step 2 or step 4 is received, Endpoint A sends the next LPP message N+1 for the location session to Endpoint B when this message is available.

4.3.5 LPP Message Segmentation

An LPP message body may be sent in several shorter LPP messages instead of one long LPP message to deliver a large amount of information (e.g., in case the LPP message size exceeds the maximum message size supported by lower layers). When a sender employs LPP message segmentation, the sender shall include the IE SegmentationInfo in each LPP message segment. The sender shall indicate in all but the final message segment that more messages are on the way.

When a receiver receives an LPP message indicating that more messages are on the way, the receiver may store the LPP message. If the receiver receives a subsequent LPP message for the same session and transaction ID, the receiver shall assume that the new LPP message continues the segmentation of the earlier message and may store the new message if the new message indicates that more messages are on the way. If the new message indicates that no more messages are on the way, the receiver shall assume that message segmentation is complete and shall process the new message and any stored message segments for the same session and transaction ID.

The reliable transport rules specified in clause 4.3.2, 4.3.3, and 4.3.4 apply to each individual LPP message segment, independently of the value of the IE SegmentationInfo.

The rules for setting the common fields of the LPP message specified in clause 4.1.4 (Transaction ID, Transaction End Flag, Sequence Number, Acknowledgment) apply to each individual LPP message segment, independently of the value of the IE SegmentationInfo.

Figure 4.3.5-1: LPP Message Segmentation procedure

1. Endpoint A sends an LPP message to Endpoint B for a particular location session and includes the IE SegmentationInfo set to moreMessagesOnTheWay to indicate that this is one of many LPP message segments used to deliver the entire LPP message body.

2 Endpoint A may send one or more additional LPP messages to Endpoint B with the IE SegmentationInfo set to moreMessagesOnTheWay to continue delivering the segmented LPP message.

3. Endpoint A sends the final LPP message segment to Endpoint B and includes the IE SegmentationInfo set to noMoreMessages to indicate that this is the final LPP message segment. Endpoint B assumes that the complete LPP message body has been received.