The design goal of LPP is to enable it to be used in user plane location solutions such as OMA SUPL ([15], [16]) and this informative Annex shows how LPP can be used in SUPL 2.0.
Observed Time Difference of Arrival (OTDOA) NOTE 1, NOTE 3
NA
✓
✓
Sensors
NA
✓
NOTE 5
✓
WLAN
NA
✓
✓
Bluetooth
NA
✓
✓
TBS NOTE 4
NA
✓
✓
NR DL-TDOA
NA
NA
✓
NR DL-AoD
NA
NA
✓
NR E-CID (downlink)
NA
NA
✓
NR Multi-RTT
NA
NA
✓
NR UL-TDOA
NA
NA
✓
NR UL-AoA
NA
NA
✓
NOTE 1:
Excludes methods based on NR signals.
NOTE 2:
For LPP, NR CID is supported.
NOTE 3:
This includes TBS positioning based on PRS signals, which is only supported in LPP (LTE).
NOTE 4:
TBS positioning based on MBS signals.
NOTE 5:
Only barometric pressure sensor is supported.
It should be noted that in addition to the container provided by SUPL itself, E-CID/NR E-CID positioning methods defined within LPP proper can be supported in SUPL, via tunnelling LPP as shown in this Annex (in the same manner that A-GNSS, OTDOA, Barometric Pressure Sensors, WLAN, Bluetooth and TBS are supported).
This clause describes interworking between the control-plane LCS architecture, as defined in the main body of this specification, and SUPL 2.0. Similarly, to the E-SMLC in the LTE architecture (TS 36.305), the LMF either includes or has an interface to an SPC function, as defined in OMA SUPL V2.0 ([15], [16]). It can thus provide a consistent set of positioning methods for deployments utilizing both control-plane and user-plane.
The interworking does not enable use of user-plane signalling for part of a control-plane positioning session. The user plane in the interworking here is not intended as an alternative path for control-plane signalling that would be needed between UE and NG-RAN for mechanisms such as A-GPS in a standalone control-plane solution.
This interworking does enable the SPC to retrieve measurements (e.g., GNSS-to-RAN time relations) from the NG-RAN.
The underlying architecture is shown in Figure A.2-1 (TS 23.501). Note that, for interworking between user-plane and control-plane positioning, no new interfaces need to be defined as compared to those in the Figure, assuming the SPC is either integrated in the LMF or attached to it with a proprietary interface.
This clause indicates how an LPP session relates to the SUPL message set. Figure A.3-1 shows how SUPL and LPP can be combined within a SUPL positioning session. Step 4 here is repeated to exchange multiple LPP messages between the SLP and SET.
For positioning operations which take place entirely within an LPP session (step 4 in Figure A.3-1), the flow of LPP messages can be the same as in the control-plane version of LPP; the role of the (LPP) target is taken by the target SET, and that of the (LPP) server by the SLP. An example LPP flow, including exchange of capabilities, request and delivery of assistance data, and request and delivery of positioning information, is shown in Figure A.3-2.
Since SUPL by definition is carried over the user plane, it is not applicable to operations terminating at the NG-RAN. SUPL operations must take place in combination with control-plane procedures over NRPPa.
This situation could arise in the case of UE-assisted OTDOA, for example, in which the SLP needs to provide the UE (in a SUPL session) with assistance data supplied by the NG-RAN. This clause uses a UE-assisted OTDOA positioning operation as an example.
Although the positioning server in this operation is the SLP, the existence of an interface to the LMF means that the SLP can communicate with the LMF via the SPC. In particular, this means that assistance data that was delivered to the LMF via NRPPa can be transferred over to the SLP for delivery to the UE via LPP over SUPL.
There are several ways to realise this general behaviour. In the simplest case, the LMF could be supplied with the necessary assistance data in advance, so that it can be supplied to the SLP without any actual NRPPa procedures taking place in real time (and possibly even before the positioning transaction begins).
In the event that the LMF does not have the required assistance data available, it would need to retrieve them from the NG-RAN once it was made aware that they were needed.
In both cases, it should be noted that the retrieval of the assistance data is transparent to the UE and to the actual SUPL session. This model is parallel to the approach used with A-GNSS, in which assistance data such as satellite ephemerides are retrieved from sources entirely external to the cellular network. For purposes of LPP over SUPL, the delivery of assistance data to the SLP can be viewed as an independent external process.
The delivery of assistance data to the UE, however, takes place through the same mechanisms as control-plane LPP, transported through SUPL.