Content for  TS 38.305  Word version:  17.5.0

Top   Top   Up   Prev   None
1…   4…   5…   6…   6.5…   7…   7.4…   7.6…   8…   8.1.3…   8.2…   8.3…   8.4…   8.5…   8.6…   8.7…   8.8…   8.9…   8.10…   8.11…   8.12…   8.13…   8.14…   A…


A  Use of LPP with SUPLp. 129

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.

A.1  SUPL 2.0 Positioning Methods and Positioning Protocolsp. 129

The following Table shows how the 3GPP positioning protocols are supported in SUPL 2.0.
Positioning Protocol: RRLP
Positioning Method:
A-GPS (A-GANSS) SET Assisted
Autonomous GPS/GANSS
Enhanced Cell ID NOTE 1NOTE 2
Enhanced Observed Time Difference (E-OTD)✓ (GSM only)NANA
Observed Time Difference of Arrival (OTDOA) NOTE 1, NOTE 3NA
NR E-CID (downlink)NANA
Excludes methods based on NR signals.
For LPP, NR CID is supported.
This includes TBS positioning based on PRS signals, which is only supported in LPP (LTE).
TBS positioning based on MBS signals.
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).

A.2  SUPL 2.0 and NR Architecturep. 131

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.
Reproduction of 3GPP TS 38.305, Fig. A.2-1: System reference architecture reference for Location Services in reference point representation
The Lup and Llp interfaces shown in this architecture are part of the user-plane solution only and are not required for control-plane positioning.

A.3  LPP session procedures using SUPLp. 131

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.
Reproduction of 3GPP TS 38.305, Fig. A.3-1: LPP session over SUPL
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.
Reproduction of 3GPP TS 38.305, Fig. A.3-2: LPP session over SUPL

A.4  Procedures combining C-plane and U-plane operationsp. 132

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).
Reproduction of 3GPP TS 38.305, Fig. A.4-1: Transfer of OTDOA assistance data to UE via SUPL
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.
Reproduction of 3GPP TS 38.305, Fig. A.4-2: Transfer to the UE via SUPL of OTDOA assistance data not already available at the LMF
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.

$  Change historyp. 134

Up   Top