Content for TS 36.305 Word version: 16.2.0
7 General E-UTRAN UE Positioning procedures
7.1 General LPP procedures for UE Positioning
7.2 General LPPa Procedures for UE Positioning
7.3 Service Layer Support using combined LPP and LPPa Procedures
7.4 General SLmAP Procedures for UE Positioning
7.5 Service Layer Support using combined SLmAP and LPPa Procedures
7.6 Procedures for Broadcast of Assistance Data
...
...
7 General E-UTRAN UE Positioning procedures
7.1 General LPP procedures for UE Positioning
7.1.1 LPP Procedures
Positioning procedures in the E-UTRAN are modelled as transactions of the LPP protocol using the procedures defined in this specification. A procedure consists of a single operation of one of the following types:
- Exchange of positioning capabilities;
- Transfer of assistance data;
- Transfer of location information (positioning measurements and/or position estimate);
- Error handling;
- Abort.
7.1.2 Positioning procedures Word‑p. 29
7.1.2.1 Capability transfer
A UE request for capability from E-SMLC or delivery of the E-SMLC capability to the UE is not supported in this version of the specification.
Capabilities in an LPP context refer to the ability of a target or server to support different position methods defined for LPP, different aspects of a particular position method (e.g. different types of assistance data for A-GNSS) and common features not specific to only one position method (e.g. ability to handle multiple LPP transactions). These capabilities are defined within the LPP protocol and transferred between the target and the server using LPP transport.
The exchange of capabilities between a target and a server may be initiated by a request or sent as "unsolicited" information. If a request is used, the server sends an LPP Request Capabilities message to the target device with a request for capability information. The target sends an LPP Provide Capabilities message.
(not reproduced yet)
Figure 7.1.2.1 1: LPP Capability Transfer procedure
LPP Capability Indication procedure is used for unsolicited capability transfer.
(not reproduced yet)
Figure 7.1.2.1-2: LPP Capability Indication procedure
7.1.2.2 Assistance data transfer Word‑p. 30
Assistance data may be transferred either by request or unsolicited. In this version of the specification, assistance data delivery is supported only via unicast transport from server to target.
(not reproduced yet)
Figure 7.1.2.2 1: LPP Assistance Data Transfer procedure
Step 1.
LPP Assistance Data Delivery procedure is used for unilateral assistance data transfer.
The target may send a request to the server for assistance data and may indicate the particular assistance data needed.
Step 2.
The server transfers assistance data to the target. The transferred assistance data should match any assistance data requested in step 1.
Step 3.
Optionally, the server may transfer additional assistance data to the target in one or more additional LPP messages.
(not reproduced yet)
Figure 7.1.2.2-2: LPP Assistance Data Delivery procedure
This procedure is unidirectional; assistance data are always delivered from the server to the target.
7.1.2.3 Location information transfer
The term "location information" applies both to an actual position estimate and to values used in computing position (e.g., radio measurements or positioning measurements). It is delivered either in response to a request or unsolicited.
(not reproduced yet)
Figure 7.1.2.3 1: LPP Location Information Transfer procedure
Step 1.
LPP Location Information Delivery procedure is used for unilateral location information transfer.
The server may send a request for location information to the target, and may indicate the type of location information needed and associated QoS.
Step 2.
In response to step 1, the target transfers location information to the server. The location information transferred should match the location information requested in step 1.
Step 3.
Optionally (e.g., if requested in step 1), the target in step 2 may transfer additional location information to the server in one or more additional LPP messages.
(not reproduced yet)
Figure 7.1.2.3 2: LPP Location Information Delivery procedure
7.1.2.4 Multiple transactions Word‑p. 31
Multiple LPP transactions may be in progress simultaneously between the same target and server nodes, to improve flexibility and efficiency. However, no more than one LPP procedure between a particular pair of target and server nodes to obtain location information shall be in progress at any time for the same position method.
In this example, the objective is to request location measurements from the target, and the server does not provide assistance data in advance, leaving the target to request any needed assistance data. A message flow is shown in Figure 7.1.2.4-1.
(not reproduced yet)
Figure 7.1.2.4-1: Example of multiple LPP procedures
Step 1.
The server sends a request to the target for positioning measurements.
Step 2.
The target sends a request for particular assistance data.
Step 3.
The server returns the assistance data requested in step 2.
Step 4.
The target obtains and returns the location information (e.g., positioning method measurements) requested in step 1.
7.1.2.5 Sequence of Procedures Word‑p. 32
LPP procedures are not required to occur in any fixed order, in order to provide greater flexibility in positioning. Thus, a UE may request assistance data at any time in order to comply with a previous request for location measurements from the E-SMLC; an E-SMLC may instigate more than one request for location information (e.g., measurements or a location estimate) in case location results from a previous request were not adequate for the requested QoS; and the target device may transfer capability information to the server at any time if not already performed.
Despite the flexibility allowed by LPP, it is expected that procedures will normally occur in the following order:
- Capability Transfer;
- Assistance Data Transfer;
- Location Information Transfer (measurements and/or location estimate).
7.1.2.6 Error handling
The procedure is used to notify the sending endpoint by the receiving endpoint that the receiving LPP message is erroneous or unexpected. This procedure is bidirectional at the LPP level; either the target or the server may take the role of either endpoint in Figure 7.1.2.6-1.
(not reproduced yet)
Figure 7.1.2.6-1: Error handling
Step 1.
The target or server (indicated as "Target/Server" in Figure 7.1.2.6-1) sends a LPP message to the other endpoint (indicated as "Server/Target").
Step 2.
If the server or target ("Server/Target") detects that the receiving LPP message is erroneous or unexpected, the server or target transfers error indication information to the other endpoint ("Target/Server").
7.1.2.7 Abort Word‑p. 33
The procedure is used to notify the other endpoint by one endpoint to abort an ongoing procedure between the two endpoints. This procedure is bidirectional at the LPP level; either the target or the server may take the role of either endpoint in Figure 7.1.2.7-1.
(not reproduced yet)
Figure 7.1.2.7-1: Abort
Step 1.
A LPP procedure is ongoing between target and server.
Step 2.
If the server or target ("Server/Target") determines that the procedure must be aborted, and then the server or target sends an LPP Abort message to the other endpoint ("Target/Server") carrying the transaction ID for the procedure.
7.1.3 UE positioning measurements in idle state for NB-IoT |R14|
NB-IoT UEs may perform measurements for some positioning methods only when in idle state.
Figure 7.1.3-1 shows the general positioning procedure where the UE performs positioning measurements in idle state.
(not reproduced yet)
Figure 7.1.3-1: UE positioning measurements in idle state.
Step 1.
The E-SMLC is aware of the UE access type and/or coverage level if applicable from the Location Service Request message received from the MME. The E-SMLC may send a LPP Request Capabilities message to the UE to obtain the UE positioning method capabilities from the UE, as described in clause 7.1.2.1.
Step 2.
The UE sends its positioning method capabilities to the E-SMLC in a LPP Provide Capabilities message, including an indication of position methods for which the UE needs to make measurements in idle state.
Step 3.
The E-SMLC may determine the assistance data required for the selected position method or methods, and sends them in one or more LPP Provide Assistance data messages to the UE, as described in clause 7.1.2.2. If an LPP acknowledgement was requested, the UE sends an LPP acknowledgment for each received LPP Provide Assistance data message to the E-SMLC.
Step 4.
If the UE capabilities from step 2 indicate that idle state is required for positioning measurements, the E-SMLC may allow additional response time to the UE to obtain the location measurements, and sends one or more LPP Request Location Information messages to the UE requesting positioning measurements or a location estimate, and including the required response time, as described in clause 7.1.2.3. For E-CID positioning method, when NRSRP/NRSRQ measurements are requested the UE is requested to provide NRSRP/NRSRQ measurements for intra-frequency neighbour cells and for inter-frequency neighbour cells. The UE may use inter-frequency information in system information of the serving cell specified in TS 36.331 to decide on which inter-frequency cells to measure.
Step 5.
The UE sends an LPP acknowledgement for each received LPP Request Location Information message to the E SMLC, if an LPP acknowledgement was requested at step 4 but does not perform the requested measurements.
Step 6.
The UE may finish any other activities in progress (e.g., SMS or data transfer), and waits until the network releases or suspends the connection (after a certain period of inactivity). The UE will then receive an RRC connection release or suspend from the eNodeB due to the expiration of the inactivity timer.
Step 7.
When the UE has entered idle state, the UE performs the measurements requested in step 4.
Step 8.
Before the location measurements are to be sent to the E-SMLC, the UE instigates a UE triggered service request or, when User Plane CIoT EPS optimization applies, the Connection Resume procedure as defined in TS 23.401, if the UE is not using Control Plane CIoT EPS Optimisation, in order to establish a signalling connection with the MME. If the UE is using Control Plane CIoT EPS Optimisation, procedures for Mobile Originated Data Transport in Control Plane CIoT EPS optimisation as defined in TS 23.401 are performed by the UE to establish a signalling connection with the MME.
Step 9.
When the LPP response time received in step 4 expires (or when location measurements are available before expiry), the UE sends one or more LPP Provide Location Information messages containing the requested location measurements or location estimate obtained in step 7 to the E-SMLC.
7.2 General LPPa Procedures for UE Positioning Word‑p. 35
7.2.1 LPPa Procedures
Positioning and data acquisition transactions between an E-SMLC and eNodeB are modelled by using procedures of the LPPa protocol. There are two types of LPPa procedures:
- UE associated procedure, i.e. transfer of information for a particular UE (e.g. positioning measurements)
- Non UE associated procedure, i.e. transfer of information applicable to the eNodeB and associated TPs (e.g. eNB/TP timing differences)
(not reproduced yet)
Figure 7.2.1-1: A single LPPa transaction
Figure 7.2.1.1-1 shows a single LPPa transaction. The transaction is terminated in step 2 in the case of a non UE associated procedure. For a UE associated procedure to gather information concerning the access node, additional responses may be allowed (e.g. sending of updated information periodically and/or whenever there is some significant change). In this case, the transaction may be ended after some additional responses. In the LPPa protocol, the described transaction may be realized by the execution of one procedure defined as a request and a response, followed by one or several procedures initiated by the eNB (each procedure defined as a single message) to realize the additional responses. The Correlation ID provided by the MME in the LCS-AP PDU encapsulating the LPPa PDU may be used by the E-SMLC to identify the target UE positioning session.
7.2.2 LPPa transaction types
7.2.2.1 Location information transfer
The term "location information" applies both to an actual position estimate and to values used in computing position (e.g., radio measurements or positioning measurements). It is delivered in response to a request.
(not reproduced yet)
Figure 7.2.2 1: Location information transfer
Step 1.
The server sends a request for location related information to the eNodeB, and indicates the type of location information needed and associated QoS. The request may refer to a particular UE.
Step 2.
In response to step 1, the eNodeB transfers location related information to the server. The location related information transferred should match the location related information requested in step 1.
Step 3.
If requested in step 1, the eNodeB may transfer additional location related information to the server in one or more additional LPPa messages when the positioning method is E-CID.
7.3 Service Layer Support using combined LPP and LPPa Procedures Word‑p. 36
As described in TS 23.271, UE-positioning-related services can be instigated from the EPC in the case of an NI-LR or MT-LR location service, or from the UE in the case of an MO-LR location service. The complete sequence of operations in the EPC is defined in TS 23.271. This clause defines the overall sequences of operations that occur in the E-SMLC, E-UTRAN and UE as a result of the EPC operations.
Some flows in this scenario apply only in particular situations (e.g., only when the UE is in connected mode). The lower-layer details of such cases are not shown in the diagrams; for instance, the process of paging a UE to bring it to connected mode from idle is not explicitly indicated in these diagrams.
7.3.1 NI-LR and MT-LR Service Support
Figure 7.3.1-1 shows the sequence of operations for an NI-LR or MT-LR location service, starting at the point where the MME initiates the service in the E-SMLC.
(not reproduced yet)
Figure 7.3.1-1: UE Positioning Operations to support an MT-LR or NI-LR
Step 1.
The MME sends a location request to the E-SMLC for a target UE and may include associated QoS.
Step 2.
The E-SMLC may obtain location related information from the UE and/or from the serving eNode B. In the former case, the E-SMLC instigates one or more LPP procedures to transfer UE positioning capabilities, provide assistance data to the UE and/or obtain location information from the UE. The UE may also instigate one or more LPP procedures after the first LPP message is received from the E-SMLC (e.g., to request assistance data from the E-SMLC).
Step 3.
If the E-SMLC needs location related information for the UE from the eNode B, the E-SMLC instigates one or more LPPa procedures. Step 3 is not necessarily serialised with step 2; if the E-SMLC and eNode B have the information to determine what procedures need to take place for the location service, step 3 could precede or overlap with step 2.
Step 4.
The E-SMLC returns a location response to the MME with any location estimate obtained as a result of steps 2 and 3.
7.3.2 MO-LR Service Support Word‑p. 37
Figure 7.3.2-1 shows the sequence of operations for an MO-LR service, starting at the point where an LCS Client in the UE or the user has requested some location service (e.g., retrieval of the UE's location or transfer of the UE's location to a third party).
(not reproduced yet)
Figure 7.3.2-1: UE Positioning Operations to support an MO-LR
Step 1.
The UE sends a NAS level MO-LR request to the MME. The MO-LR request may carry an LPP PDU to instigate one or more LPP procedures to transfer capabilities, request assistance data, request location information and/or transfer location information (e.g. location measurements).
Step 2.
The MME sends a location request to the E-SMLC and includes any LPP PDU received in step 1.
Step 3.
The E-SMLC may obtain location related information from the UE and/or from the serving eNode B. In the former case or if an immediate response is needed to any LPP procedure instigated by the UE in step 1 (e.g., a request for assistance data), the E-SMLC instigates one or more LPP procedures to transfer UE positioning capabilities, provide assistance data to the UE and/or obtain location information from the UE. The UE may also instigate further LPP procedures after the first LPP message is received from the E-SMLC (e.g., to request assistance data or to request further assistance data).
Step 4.
If the E-SMLC needs location related information for the UE from the eNode B, the E-SMLC instigates one or more LPPa procedures. Step 4 may also precede step 3 or occur in parallel with it.
Step 5.
The E-SMLC returns a location response to the MME with any location estimate obtained as a result of steps 3 and 4, and/or with a final LPP message (e.g., that could provide a location estimate to the UE if requested by the UE in step 1).
Step 6.
If the UE requested location transfer to a third party the MME transfers the location received from the E-SMLC in step 5 to the third party as defined in TS 23.271.
Step 7.
The MME sends a NAS level MO-LR response to the UE, carrying any final LPP PDU that was received in step 5.
7.4 General SLmAP Procedures for UE Positioning |R11| Word‑p. 38
7.4.1 SLmAP Procedures
SLmAP includes positioning procedures, such as:
- Measurement request
- Measurement Update
- Measurement Abort
7.4.1.1 Measurement request
The measurement request procedure is used by the E-SMLC to obtain timing measurement for a particular target UE from an LMU.
(not reproduced yet)
Figure 7.4.1-1: Measurement request
Step 1.
The E-SMLC sends a measurement request to the LMU. The measurement request identifies the UE to be positioned and contains the data (including SRS transmission configuration) needed to obtain the measurements.
Step 2.
In response to step 1, the LMU transfers UL RTOA measurements to the E-SMLC.
7.4.1.2 Measurement Update
The Measurement Update procedure is used by the E-SMLC to inform the LMU of a change in the UE SRS transmission configuration during an ongoing SLmAP measurement reporting transaction.
(not reproduced yet)
Figure 7.4.1.2-1: Measurement update
Step 1.
An SLmAP Measurement reporting transaction is ongoing between the E-SMLC and LMU.
Step 2.
The E-SMLC determines that the SRS transmission configuration data previously sent to the LMU is no longer valid. The E-SMLC sends a Measurement Update to the LMU containing the new SRS transmission configuration data. The E-SMLC shall not send a Measurement Update after receiving a Measurement Response from the LMU.
Step 3.
The LMU continues UL RTOA measurements using the updated SRS configuration.
7.4.1.3 Measurement Abort Word‑p. 39
The measurement abort procedure is used by the E-SMLC to abort an ongoing SLmAP measurement reporting transaction.
(not reproduced yet)
Figure 7.4.1.3-1: Measurement abort
Step 1.
An SLmAP Measurement reporting transaction is ongoing between the E-SMLC and LMU.
Step 2.
The E-SMLC determines that the transaction should be aborted (e.g. due to UE detach or inter-MME handover). The E-SMLC sends a measurement abort to the LMU and the ongoing SLmAP Measurement reporting transaction is abandoned. The E-SMLC shall not send a Measurement Abort after receiving a Measurement response from the LMU.
7.5 Service Layer Support using combined SLmAP and LPPa Procedures |R11|
7.5.1 NI-LR and MT-LR Service Support
Figure 7.5.1-1 shows the sequence of operations for an NI-LR and MT-LR, starting at the point where the MME initiates the service in the E-SMLC.
(not reproduced yet)
Figure 7.5.1-1: UE Positioning Operations to support NI-LR or MT-LR
Step 1.
The MME sends a location request to the E-SMLC for a target UE and may include associated QoS.
Step 2.
The E-SMLC obtains target UE configuration information from the serving eNode B.
Step 3.
If the E-SMLC needs measurement results for the UE from multiple LMUs, the E-SMLC instigates SLmAP procedures to each LMU.
Step 4.
The E-SMLC returns a location response to the MME with any location estimate obtained as a result of steps 2 and 3.
7.5.2 MO-LR Service Support Word‑p. 40
Figure 7.5.2-1 shows the sequence of operations for an MO-LR service, starting at the point where an LCS Client in the UE or the user has requested some location service (e.g., retrieval of the UE's location or transfer of the UE's location to a third party).
(not reproduced yet)
Figure 7.5.2-1: UE Positioning Operations to support an MO-LR
Step 1.
The UE sends a NAS level MO-LR request to the MME.
Step 2.
The MME sends a location request to the E-SMLC.
Step 3.
The E-SMLC obtains target UE configuration information from the serving eNode B.
Step 4.
If the E-SMLC needs measurement results for the UE from multiple LMUs, the E-SMLC instigates SLmAP procedures to each LMU.
Step 5.
The E-SMLC returns a location response to the MME with any location estimate obtained as a result of steps 2 and 3.
Step 6.
If the UE requested location transfer to a third party LCS Client, the MME transfers the location received from the E-SMLC in step 5 to the third party as defined in TS 23.271.
Step 7.
The MME sends a NAS level MO-LR response to the UE carrying any location estimate.
7.6 Procedures for Broadcast of Assistance Data |R15| Word‑p. 41
7.6.1 General
Positioning assistance data can be included in positioning System Information Blocks (posSIBs) as described in TS 36.331 and TS 36.355. The posSIBs are carried in RRC System Information (SI) messages. The mapping of posSIBs (assistance data) to SI messages is flexibly configurable and provided to the UE in SIB1 (TS 36.331).
For each assistance data element, a separate posSIB-type is defined in TS 36.355. Each posSIB may be ciphered by the E SMLC using the 128-bit Advanced Encryption Standard (AES) algorithm (with counter mode) as described in TS 36.355, either with the same or different ciphering key. The posSIBs which exceed the maximum size limit defined in TS 36.331 shall be segmented by the E SMLC.
7.6.2 Broadcast Procedures
The general procedures for broadcast of positioning assistance data and delivery of ciphering keys to UEs is described in TS 23.271. This clause defines the overall sequences of operations that occur in the E-SMLC, E-UTRAN and UE.
(not reproduced yet)
Figure 7.6.2-1: Procedures to support broadcast of assistance data.
Step 1.
The E-SMLC sends an LPPa Assistance Data Information Control message to the eNB with an indication to start broadcasting assistance information. The message includes one or more System Information groups, where each group contains the broadcast periodicity and one or more posSIB types together with meta data. Each posSIB type may be ciphered and/or segmented at the E-SMLC. The meta data may include an indication whether the posSIB type in the System Information group is ciphered or not, as well as an indication of an applicable GNSS type.
Step 2.
The eNB includes the received System Information groups in RRC System Information Messages and corresponding scheduling information in SIB1 as described in [12]. The UE applies the system information acquisition procedure according to [12] for acquiring the assistance data information that is broadcasted.
Step 3.
If the posSIB types were ciphered by the E-SMLC, the E-SMLC provides the used ciphering keys, together with a validity time and validity area for each key, to the MME using an LCS-AP Ciphering Key Data message described in TS 29.171. The MME returns a LCS-AP Ciphering Key Data Result message back to the E-SMLC indicating whether the MME was able to successfully store the ciphering data sets. The MME may then distribute successfully stored ciphering keys and their validity times and validity areas to suitably subscribed UEs using a mobility management message as described in TS 23.271. The E SMLC repeats this procedure whenever a ciphering key changes.
Step 4.
At any time after Step 1, the eNB may send a LPPa Assistance Information Feedback message to the E-SMLC providing feedback on assistance information broadcasting. The message may include an assistance information failure list indicating that certain posSIB types could not be configured for broadcasting by the eNB.
Step 5.
If the assistance information in a System Information group changes, the E-SMLC provides updated information in a LPPa Assistance Information Control message.
Step 6.
The eNB replaces the previously stored System Information groups with the new information received at Step 5 and includes the new System Information groups in RRC System Information Messages.
Step 7.
If the E-SMLC wants to abort the broadcast of a System Information Group, it sends a LPPa Assistance Information Control message to the eNB including an indication to stop broadcasting the assistance information.
