Content for TS 38.355 Word version: 18.2.0
4 Functionality of Protocol
4.1 General
4.1.1 SLPP Configuration
4.1.2 SLPP Sessions and Transactions
4.1.3 SLPP Positioning Methods
4.1.4 SLPP Messages
4.2 Common SLPP Session Procedure
4.3 SLPP Transport
4.3.1 Transport Layer Requirements
4.3.2 SLPP Duplicate Detection
4.3.3 SLPP Acknowledgement
4.3.3.1 General
4.3.3.2 Procedure related to Acknowledgement
4.3.4 SLPP Retransmission
4.3.4.1 General
4.3.4.2 Procedure related to Retransmission
...
...
4 Functionality of Protocol p. 9
4.1 General p. 9
4.1.1 SLPP Configuration p. 9
SLPP is used point-to-point between Endpoints, e.g. Location Server (SL Server UE or LMF) and target in order to obtain absolute position, relative position, or ranging information of target UE using sidelink measurements obtained by one or more reference sources.
(no figure)
4.1.2 SLPP Sessions and Transactions p. 9
An SLPP session is used between UEs or a Location Server and a UE in order to obtain location related measurements based on NR PC5 radio signals, a location estimate or to transfer assistance data. A single SLPP session is used to support a single location request (e.g., for a single SL-MT-LR, or SL-MO-LR). Multiple SLPP sessions can be used between the same endpoints to support multiple location requests (as required by TS 23.273). For UE-only Operation, the instigator of an SLPP session which is the Endpoint who receives the LCS request, initiates an SLPP session by sending an SLPP message containing an assigned session ID (session identifier) to the other endpoint (s). All constituent messages within a session shall contain the same session ID. For LMF involved Operation, the session ID is assigned by target UE and contained in the SLPP messages used for communication between UEs. The session ID may be included in the SLPP message for the communication between a UE and the LMF.
Each SLPP session comprises one or more SLPP transactions, with each SLPP transaction performing a single operation (capability exchange, assistance data transfer, or location information transfer). The SLPP transactions are realized as SLPP procedures. The instigator of an SLPP session will always instigate the first SLPP transaction, but subsequent transactions may be instigated by either end. SLPP transactions within a session may occur serially or in parallel. SLPP transactions are indicated at the SLPP 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 SLPP Positioning Methods p. 9
This version of the specification defines SL-TDOA, SL-TOA, SL-AoA and SL-RTT positioning methods based on NR PC5 radio signals.
4.1.4 SLPP Messages p. 9
Each SLPP transaction involves the exchange of one or more SLPP messages between Endpoint A and Endpoint B. The general format of an SLPP 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 |
|---|---|
| sessionID | Identify messages belonging to the same session |
| transactionID | Identify messages belonging to the same transaction |
| endTransaction | Indicate when a transaction (e.g. one with periodic responses) has ended |
| sequenceNumber | Enable detection of a duplicate SLPP message at a receiver |
| acknowledgement | Enable an acknowledgement to be requested and/or returned for any SLPP message |
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 SLPP Session Procedure p. 10
The purpose of this procedure is to support an SLPP session comprising a sequence of SLPP transactions. The procedure is described in Figure 4.2-1.
Step 1.
Within the same session, all constituent messages shall contain the same session ID and within each transaction, all constituent messages shall contain the same transaction ID. The last message sent in each transaction shall have the field 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.
Endpoint A, which is the Endpoint who receives the LCS request, initiates an SLPP session by sending an SLPP message containing an assigned session ID for an initial SLPP transaction j to the other endpoint B.
Step 2.
Endpoints A and B may exchange further messages to continue the transaction started in step 1.
Step 3.
Either endpoint may instigate further transactions by sending additional SLPP messages.
Step 4.
A session is terminated by a final transaction N in which SLPP messages will be exchanged between the two endpoints.
4.3 SLPP Transport p. 11
4.3.1 Transport Layer Requirements p. 11
SLPP requires reliable, in-sequence delivery of SLPP messages from the underlying transport layers. This clause describes the transport capabilities that are available within SLPP. A UE implementing SLPP shall support SLPP reliable transport (including all three of duplicate detection, acknowledgement, and retransmission).
4.3.2 SLPP Duplicate Detection p. 11
A sender shall include a sequence number in all SLPP messages sent for a particular location session. The sequence number shall be distinct for different SLPP messages sent by the same endpoint for the same endpoint in the same location session (e.g., may start at zero in the first SLPP message and increase monotonically in each succeeding SLPP message). Sequence numbers used in the messages transmitted from different endpoints or for different endpoints are independent (e.g., can be the same).
A receiver shall record the most recent received sequence number for each pair of endpoints of each location session. If a message is received carrying the same sequence number as that last received for the same pair of endpoints and the associated location session, it shall be discarded. Otherwise (i.e., if the sequence number is different or the sequence number is same but for different pair of endpoints), 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 the UE(s) when there has been no activity for a particular location session for 10 minutes.
4.3.3 SLPP Acknowledgement p. 11
4.3.3.1 General p. 11
Each SLPP message may carry an acknowledgement request and/or an acknowledgement indicator. A SLPP message including an acknowledgement request (i.e., that include the field ackRequested set to TRUE) shall also include a sequence number. Upon reception of an SLPP message which includes the field ackRequested set to TRUE, a receiver returns an SLPP message with an acknowledgement response (i.e., that includes the field ackIndicator set to the same sequence number of the message being acknowledged). An acknowledgement response may contain no SLPP message body (in which case only the sequence number being acknowledged is significant); alternatively, the acknowledgement may be sent in an SLPP message along with an SLPP message body. An acknowledgement is returned for each received SLPP message that requested an acknowledgement including any duplicate(s). Once a sender receives an acknowledgement for an SLPP message, and provided any included sequence number is matching, it is permitted to send the next SLPP 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 SLPP message is transported via a NAS SL-MO-LR request, the message does not request an acknowledgement.
4.3.3.2 Procedure related to Acknowledgement p. 11
Figure 4.3.3.2-1 shows the procedure related to acknowledgement.
Step 1.
Endpoint A sends an SLPP message N to Endpoint B which includes the field ackRequested set to TRUE and a sequence number.
Step 2.
If SLPP 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 field ackIndicator set to the same sequence number as that in message N.
Step 3.
When the acknowledgement for SLPP message N is received and provided the included the field ackIndicator matches the sequence number sent in message N, Endpoint A sends the next SLPP message N+1 to Endpoint B when this message is available.
4.3.4 SLPP Retransmission p. 12
4.3.4.1 General p. 12
This capability builds on the acknowledgement and duplicate detection capabilities. When an SLPP 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 SLPP activity for this Endpoint. The timeout period is determined by the sender implementation but shall not be less than a minimum value of 250 ms.
4.3.4.2 Procedure related to Retransmission p. 12
Figure 4.3.4.2-1 shows the procedure related to retransmission when combined with acknowledgement and duplicate detection.
Step 1.
Endpoint A sends an SLPP message N to Endpoint B for a particular location session and includes a request for acknowledgement along with a sequence number.
Step 2.
If SLPP 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.
Step 3.
If the acknowledgement in step 2 is not received after a timeout period, Endpoint A shall retransmit SLPP message N and shall include the same sequence number as in step 1.
Step 4.
If SLPP 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 SLPP support for this Endpoint B.
Step 5.
Once an acknowledgement in step 2 or step 4 is received, Endpoint A sends the next SLPP message N+1 for the location session to Endpoint B when this message is available.
