3GPP TSG-RAN2 Meeting #116-e R2-210xxxx

Online, 01- 11-November 2021

CR-Form-v12.1

CHANGE REQUEST
38.305 CR CRNum rev RevNu Current version: 16.6.0
m
For HELP on using this form: comprehensive instructions can be found at
http://www.3gpp.org/Change-Requests.

Proposed change affects: UICC apps ME X Radio Access Network X Core Network

Title: Running 38.305 CR for Positioning WI on RAT dependent positioning methods

Source to WG: Intel Corporation
Source to TSG: R2
Work item code: NR_pos_enh-Core Date: 2021-10-21
Category: B Release: Rel-17
Use one of the following categories: Use one of the following releases:
F (correction) Rel-8 (Release 8)
A (mirror corresponding to a change in an earlier Rel-9 (Release 9)
release) Rel-10 (Release 10)
B (addition of feature), Rel-11 (Release 11)
C (functional modification of feature) …
D (editorial modification) Rel-15 (Release 15)
Detailed explanations of the above categories can Rel-16 (Release 16)
be found in 3GPP TR 21.900. Rel-17 (Release 17)
Rel-18 (Release 18)
Reason for change: To capture positioning related agreements into TS38.305.

Summary of change: RAN2#116, capture following :

Latency reduction:
Scheduled location time, storing capability in AMF is captured in section
5.4.4, 7.3.2, 7.3.3 and 7.3.4;

Positioning in RRC_INACTVE:
Captured general note in section 5.2;

On-Demand PRS transmission:

Captured in section 7.x;

PRU:
Captured in section 3.2 and 5.4.x;

Consequences if not Rel-17 Positioning is not supported in 38.305.

approved:
Clauses affected: 3.2, 5.2, 5.4.4, 5.4.x, 7.x, 7.3.2, 7.3.3, 7.3.4
Y N
Other specs X Other core specifications TS/TR 38.331 CR TBD
TS/TR 37.355 CR TBD

affected: X Test specifications TS/TR ... CR ...

(show related CRs) X O&M Specifications TS/TR ... CR ...

Other comments:
This CR's revision history:
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [1].

5GC 5G Core Network

5GS 5G System
A-AoA Azimuth-Angle of Arrival
ADR Accumulated Delta Range
AoA Angle of Arrival
AP Access Point
ARP Antenna Reference Point
BDS BeiDou Navigation Satellite System
BSSID Basic Service Set Identifier
CID Cell-ID (positioning method)
CLAS Centimetre Level Augmentation Service
DL-AoD Downlink Angle-of-Departure
DL-PRS Downlink Positioning Reference Signal
DL-TDOA Downlink Time Difference Of Arrival
E-SMLC Enhanced Serving Mobile Location Centre
E-CID Enhanced Cell-ID (positioning method)
ECEF Earth-Centered, Earth-Fixed
ECI Earth-Centered-Inertial
EGNOS European Geostationary Navigation Overlay Service
E-UTRAN Evolved Universal Terrestrial Radio Access Network
FDMA Frequency Division Multiple Access
FKP Flächenkorrekturparameter (Engl: Area Correction Parameters)
GAGAN GPS Aided Geo Augmented Navigation
GLONASS GLObal'naya NAvigatsionnaya Sputnikovaya Sistema (Engl.: Global Navigation Satellite
System)
GMLC Gateway Mobile Location Centre
GNSS Global Navigation Satellite System
GPS Global Positioning System
GRS80 Geodetic Reference System 1980
HESSID Homogeneous Extended Service Set Identifier
LCS LoCation Services
LMF Location Management Function
LPP LTE Positioning Protocol
MAC Master Auxiliary Concept
MBS Metropolitan Beacon System
MO-LR Mobile Originated Location Request
MT-LR Mobile Terminated Location Request
Multi-RTT Multi-Round Trip Time
NG-C NG Control plane
NG-AP NG Application Protocol
NI-LR Network Induced Location Request
N-RTK Network – Real-Time Kinematic
NRPPa NR Positioning Protocol A
OTDOA Observed Time Difference Of Arrival
PDU Protocol Data Unit
posSI Positioning System Information
posSIB Positioning SIB
PPP Precise Point Positioning
PPP-RTK Precise Point Positioning – Real-Time Kinematic
PRS Positioning Reference Signal (for E-UTRA)
PRU Positioning Reference Unit
QZSS Quasi-Zenith Satellite System
RP Reception Point
RRM Radio Resource Management
 RSRP Reference Signal Received Power
RSRQ Reference Signal Received Quality
RSSI Received Signal Strength Indicator
RSTD Reference Signal Time Difference
RTK Real-Time Kinematic
SBAS Space Based Augmentation System
SDT Small Data Transmission
SET SUPL Enabled Terminal
SIB System Information Block
SLP SUPL Location Platform
SP Semi-Persistent
SRS Sounding Reference Signal
SSID Service Set Identifier
SSR State Space Representation
STEC Slant TEC
SUPL Secure User Plane Location
TADV Timing Advance
TBS Terrestrial Beacon System
TEC Total Electron Content
TP Transmission Point
TRP Transmission-Reception Point
UE User Equipment
UL-AoA Uplink Angle of Arrival
UL-RTOA Uplink Relative Time of Arrival
UL-SRS Uplink Sounding Reference Signal
UL-TDOA Uplink Time Difference of Arrival
URA User Range Accuracy
WAAS Wide Area Augmentation System
WGS-84 World Geodetic System 1984
WLAN Wireless Local Area Network
Z-AoA Zenith Angles of Arrival

/***Skip unrelated parts***/

5.2 UE Positioning Operations

To support positioning of a target UE and delivery of location assistance data to a UE with NG-RAN access in 5GS,
location related functions are distributed as shown in the architecture in Figure 5.1-1 and as clarified in greater detail in
TS 23.501 [2] and TS 23.273 [35]. The overall sequence of events applicable to the UE, NG-RAN and LMF for any
location service is shown in Figure 5.2-1.

Note that when the AMF receives a Location Service Request in case of the UE is in CM-IDLE state, the AMF
performs a network triggered service request as defined in TS 23.502 [26] and TS 23.273 [35] in order to establish a
signalling connection with the UE and assign a specific serving gNB or ng-eNB. The UE is assumed to be in connected
mode before the beginning of the flow shown in the Figure 5.2-1; that is, any signalling that might be required to bring
the UE to connected mode prior to step 1a is not shown. The signalling connection may, however, be later released (e.g.
by the NG-RAN node as a result of signalling and data inactivity) while positioning is still ongoing.

NOTE: The positioning procedures between a UE and the network for UEs in RRC_CONNECTED state are also
applyied for UEs in RRC_INACTIVE state using SDT.
 Figure 5.2-1: Location Service Support by NG-RAN

1a. Either: some entity in the 5GC (e.g. GMLC) requests some location service (e.g. positioning) for a target UE to
the serving AMF.

1b. Or: the serving AMF for a target UE determines the need for some location service (e.g. to locate the UE for an
emergency call).

1c. Or: the UE requests some location service (e.g. positioning or delivery of assistance data) to the serving AMF at
the NAS level.

2. The AMF transfers the location service request to an LMF.

3a. The LMF instigates location procedures with the serving and possibly neighbouring ng-eNB or gNB in the NG-
RAN – e.g. to obtain positioning measurements or assistance data.

3b. In addition to step 3a or instead of step 3a, the LMF instigates location procedures with the UE – e.g. to obtain a
location estimate or positioning measurements or to transfer location assistance data to the UE.

4. The LMF provides a location service response to the AMF and includes any needed results – e.g. success or
failure indication and, if requested and obtained, a location estimate for the UE.

5a. If step 1a was performed, the AMF returns a location service response to the 5GC entity in step 1a and includes
any needed results – e.g. a location estimate for the UE.

5b. If step 1b occurred, the AMF uses the location service response received in step 4 to assist the service that
triggered this in step 1b (e.g. may provide a location estimate associated with an emergency call to a GMLC).

5c. If step 1c was performed, the AMF returns a location service response to the UE and includes any needed results
– e.g. a location estimate for the UE.

Location procedures applicable to NG-RAN occur in steps 3a and 3b in Figure 5.2-1 and are defined in greater detail in
this specification. Other steps in Figure 5.2-1 are applicable only to the 5GC and are described in greater detail and in
TS 23.502 [26] and TS 23.273 [35].

Steps 3a and 3b can involve the use of different position methods to obtain location related measurements for a target
UE and from these compute a location estimate and possibly additional information like velocity. Positioning methods
supported in this release are summarized in clause 4.3 and described in detail in clause 8.
The case that the NG-RAN node functions as an LCS client is not supported in this version of the specification.

5.3 NG-RAN Positioning Operations

5.3.1 General NG-RAN Positioning Operations
Separately from location service support for particular UEs, an LMF may interact with elements in the NG-RAN in
order to obtain measurement information to help assist one or more position methods for all UEs. An LMF may also
interact with NG-RAN node to provide assistance data information for broadcasting.

5.3.2 OTDOA Positioning Support

An LMF can interact with any ng-eNB reachable from any of the AMFs with signalling access to the LMF in order to
obtain location related information to support the OTDOA for E-UTRA positioning method, including PRS-based TBS
for E-UTRA. The information can include timing information for the TP in relation to either absolute GNSS time or
timing of other TPs and information about the supported cells and TPs including PRS schedule.

Signalling access between the LMF and ng-eNB may be via any AMF with signalling access to both the LMF and
ng-eNB.

An LMF can also interact with any gNB reachable from any of the AMFs with signalling access to the LMF in order to
obtain NR cell timing information to support the OTDOA for E-UTRA positioning method, in case the UE is served by
a NR cell.

5.3.3 Assistance Information Broadcast Support

An LMF can interact with any NG-RAN node reachable from any of the AMFs with signalling access to the LMF in
order to provide assistance data information for broadcasting. The information can include positioning System
Information Blocks (posSIBs) together with assistance information meta data, broadcast cells and broadcast periodicity.

Signalling access between the LMF and NG-RAN node is via any AMF with signalling access to both the LMF and
NG-RAN node.

5.3.4 NR RAT-Dependent Positioning Support

An LMF can interact with any gNB reachable from any of the AMFs with signalling access to the LMF in order to
obtain location related information to support the NR RAT-Dependent positioning methods. The information can
include timing information for the TRP in relation to either absolute GNSS time or timing of other TRPs and
information about the supported cells and TRPs including PRS schedule.

When an LMF determines a positioning method for a UE, which requires gNB measurements, the LMF can interact
with the gNB to support the positioning method. The LMF can request the gNB for SRS configuration for the UE and
the gNB can respond with the SRS configuration to the LMF. The gNB can provide an updated SRS configuration to
the LMF when the SRS configuration changes. If semi-persistent or aperiodic SRS is configured to the UE, the LMF
may activate/deactivate the SRS. When the SRS is transmitted by the UE, the LMF can request multiple TRPs to
perform uplink measurements and report the results.

Signalling access between the LMF and gNB for non-UE associated NRPPa procedure in Clause 7.2.1 may be via any
AMF with signalling access to both the LMF and gNB. Signalling access between the LMF and gNB for UE associated
NRPPa procedure in Clause 7.2.1 is via the serving AMF, as in TS 23.273 [35].
5.4 Functional Description of Elements Related to UE
Positioning in NG-RAN
5.4.1 User Equipment (UE)
The UE may make measurements of downlink signals from NG-RAN and other sources such as E-UTRAN, different
GNSS and TBS systems, WLAN access points, Bluetooth beacons, UE barometric pressure and motion sensors. The
measurements to be made will be determined by the chosen positioning method.

The UE may also contain LCS applications, or access an LCS application either through communication with a network
accessed by the UE or through another application residing in the UE. This LCS application may include the needed
measurement and calculation functions to determine the UE's position with or without network assistance. This is
outside of the scope of this specification.

The UE may also, for example, contain an independent positioning function (e.g., GPS) and thus be able to report its
position, independent of the NG-RAN transmissions. The UE with an independent positioning function may also make
use of assistance information obtained from the network.

5.4.2 gNB
The gNB is a network element of NG-RAN that may provide measurement information for a target UE and
communicates this information to an LMF.

To support NR RAT-Dependent positioning, the gNB may make measurements of radio signals for a target UE, and
provide measurement results for position estimation. A gNB may serve several TRPs, including for example remote
radio heads, and UL-SRS only RPs and DL-PRS-only TPs.

A gNB may broadcast assistance data information, received from an LMF, in positioning System Information messages.

5.4.3 ng-eNB
The ng-eNB is a network element of NG-RAN that may provide measurement results for position estimation and makes
measurements of radio signals for a target UE and communicates these measurements to an LMF.

The ng-eNB makes its measurements in response to requests from the LMF (on demand or periodically).

An ng-eNB may serve several TPs, including for example remote radio heads and PRS-only TPs for PRS-based TBS
positioning for E-UTRA.

An ng-eNB may broadcast assistance data information, received from an LMF, in positioning System Information
messages.

5.4.4 Location Management Function (LMF)

The LMF manages the support of different location services for target UEs, including positioning of UEs and delivery
of assistance data to UEs. The LMF may interact with the serving gNB or serving ng-eNB for a target UE in order to
obtain position measurements for the UE, including uplink measurements made by an NG-RAN and downlink
measurements made by the UE that were provided to an NG-RAN as part of other functions such as for support of
handover.

The LMF may interact with a target UE in order to deliver assistance data if requested for a particular location service,
or to obtain a location estimate if that was requested.

The LMF may interact with multiple NG-RAN nodes to provide assistance data information for broadcasting. The
assistance data information for broadcast may optionally be segmented and/or ciphered by the LMF. The LMF may also
interact with AMFs to provide ciphering key data information to the AMF as described in greater detail in TS 23.273
[35].
For positioning of a target UE, the LMF decides on the position methods to be used, based on factors that may include
the LCS Client type, the required QoS, UE positioning capabilities, gNB positioning capabilities and ng-eNB
positioning capabilities. The LMF then invokes these positioning methods in the UE, serving gNB and/or serving
ng-eNB. The positioning methods may yield a location estimate for UE-based position methods and/or positioning
measurements for UE-assisted and network-based position methods. The LMF may combine all the received results and
determine a single location estimate for the target UE (hybrid positioning). Additional information like accuracy of the
location estimate and velocity may also be determined.

The LMF may interact with the AMF to support the provision of UE positioning capability to the AMF as described in
greater detail in TS 23.273 [35].

5.4.x Positioning Reference Unit (PRU)

A Positioning Reference Unit (PRU) at a known location can perform positioning measurements (e.g., RSTD, RSRP,
UE Rx-Tx Time Difference measurements, etc.) and report these measurements to a location server. In addition, the
PRU can transmit SRS to enable TRPs to measure and report UL positioning measurements (e.g., RTOA, UL-AoA,
gNB Rx-Tx Time Difference, etc.) from PRUs at a known location (e.g., RTOA, UL-AoA, gNB Rx-Tx Time
Difference, etc.). The PRU measurements can be compared by a location server with the measurements expected at the
known PRU location to determine correction terms for other nearby target devices. The DL- and/or UL location
measurements for other target devices can then be corrected based on the previously determined correction terms.

From a location server perspective, the PRU functionality can beis realized asby a UE with known location.

Editor's Note: FFS: The exact positioning functionalities supported, and the assistance data/location information
transfers supported by PRU.

/***Skip unrelated parts***/

7.3 Service Layer Support using combined LPP and NRPPa

Procedures
7.3.1 General
As described in TS 23.502 [26] and TS 23.273 [35], UE-positioning-related services can be instigated from the 5GC for
an NI-LR or MT-LR location service, or from the UE in case of an MO-LR location service. The complete sequence of
operations in the 5GC is defined in TS 23.502 [26] and TS 23.273 [35]. This clause defines the overall sequences of
operations that occur in the LMF, NG-RAN and UE as a result of the 5GC operations.

7.3.2 NI-LR and MT-LR Service Support

Figure 7.3.2-1 shows the sequence of operations for an NI-LR or MT-LR location service, starting at the point where
the AMF initiates the service in the LMF.
 Figure 7.3.2-1: UE Positioning Operations to support an MT-LR or NI-LR

1. The AMF sends a location request to the LMF for a target UE and may include associated QoS, the scheduled
location time and the UE LPP positioning capabilities when available, as described TS 23.273 [35].

2. The LMF may obtain location related information from the UE and/or from the serving NG-RAN Node. In the
former case, the LMF 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 LMF (e.g., to request assistance data from
the LMF). If a scheduled location time is provided in step 1, the LMF may provide assistance data to the UE
ahead of time and schedule location measurements by the UE via LPP RequestLocationInforamtion message to
occur at or near to the scheduled location time. The LPP procedures to transfer UE LPP positioning capabilities
may be skipped if the LMF already obtained the UE positioning capabilities from the AMF in step 1.

3. If the LMF needs location related information for the UE from the NG-RAN, the LMF instigates one or more
NRPPa procedures. Step 3 is not necessarily serialised with step 2; if the LMF and NG-RAN Node have the
information to determine what procedures need to take place for the location service, step 3 could precede or
overlap with step 2. If scheduled location time is provided in step 1, the LMF may schedule location
measurements by the NG-RAN via NRPPA MESREUEMENT REQUEST message to occur at or near to the
scheduled location time.

4. The LMF returns a location response to the AMF with any location estimate obtained as a result of steps 2 and 3.
The LMF may also return the LPP UE capabilities as described in TS 23.273 [35].

Editor's Note: The scheduled location time and the storage of UE positioning capability in AMF may be updated
based on further inputs from SA2 and further discussion in RAN, e.g. when/whether LMF
forwards UE positioning capabilities to AMF, whether scheduled location time is signaled to
UE/NG-RAN ,etc.

7.3.3 MO-LR Service Support

Figure 7.3.3-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).
 Figure 7.3.3-1: UE Positioning Operations to support an MO-LR

1. The UE sends an MO-LR location service request message included in a UL NAS TRANSPORT message as
specified in TS 24.501 [29] to the AMF. The MO-LR location service request message may carry an LPP PDU
to instigate one or more LPP procedures to transfer capabilities, request assistance data, and/or transfer location
information and a scheduled location time , as described TS 23.273 [35].

2. The AMF invokes the Nlmf Determine Location Request service operation towards the LMF as specified in TS
29.572 [33] and includes any LPP PDU, scheduled location time received in step 1 and the UE LPP positioning
capabilities when available.

3. The LMF may obtain location related information from the UE and/or from the serving NG-RAN node. 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 LMF 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 LMF (e.g., to request assistance
data or to request further assistance data). If a scheduled location time is provided in step 2, the LMF may
provide assistance data to the UE ahead of time and schedule location measurements by the UE via LPP
RequestLocationInforamtion message to occur at or near to the scheduled location time. The LPP procedures to
transfer UE positioning capabilities may be skipped if the LMF already obtained the UE positioning capabilities
from the AMF in step 2.

4. If the LMF needs location related information for the UE from the NG-RAN, the LMF instigates one or more
NRPPa procedures. Step 4 may also precede step 3 or occur in parallel with it. If scheduled location time is
provided in step 1, the LMF may schedule location measurements by the NG-RAN via NRPPA
MESREUEMENT REQUEST message to occur at or near to the scheduled location time.

5. The LMF invokes the Nlmf Determine Location Response service operation towards the AMF as specified in TS
29.572 [33] which includes any location estimate obtained as a result of steps 3 and 4. The LMF may also return
the LPP UE capabilities as described in TS 23.273 [35].

6. If the UE requested location transfer to a third party the AMF transfers the location received from the LMF in
step 5 to the third party as defined in TS 23.273 [35].

7. The AMF sends an MO-LR location service response message included in a DL NAS TRANSPORT message as
specified in TS 24.501 [29].

Editor's Note: The scheduled location time and the storage of UE positioning capability in AMF may be updated
based on further inputs from SA2 and further discussion in RAN, e.g. when/whether LMF
forwards UE positioning capabilities to AMF, whether scheduled location time is signaled to
UE/NG-RAN ,etc.
7.3.4 Deferred MT-LR Event Reporting Support
Figure 7.3.4-1 shows the sequence of operations for an Deferred MT-LR Event Reporting starting at the point where the
UE reports an event to the LMF.

Figure 7.3.4-1: UE Positioning Operations to support a Deferred MT-LR

1. The UE sends a supplementary services event report message to the LMF as described in TS 24.571 [41] which
is transferred via the serving AMF and is delivered to the LMF using an
Namf_Communication_N1MessageNotify service operation. The event report may indicate the type of event
being reported and may include an embedded positioning message which includes any location measurements or
location estimate.

2. If LMF determines no positioning procedure is needed, steps 3 and 4 are skipped.

3. The LMF may utilize any location information received in step 1. The LMF may also retrieve location related
information from the UE and/or from the serving NG-RAN Node. In the former case, the LMF instigates one or
more LPP procedures to 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 LMF (e.g.,
to request assistance data from the LMF).

4. If the LMF needs location related information for the UE from the NG-RAN, the LMF instigates one or more
NRPPa procedures. Step 3 is not necessarily serialised with step 2; if the LMF and NG-RAN Node have the
information to determine what procedures need to take place for the location service, step 3 could precede or
overlap with step 2.

5. The LMF invokes an Nlmf_Location_EventNotify service operation towards the GMLC with an indication of
the type of event being reported and any location estimate obtained as a result of steps 2 and 3.

Editor's Note: The scheduled location time and the storage of UE positioning capability in AMF may be updated
based on further inputs from SA2 and further discussion in RAN, e.g. when/whether LMF
forwards UE positioning capabilities to AMF, whether scheduled location time is signaled to
UE/NG-RAN ,etc.
7.x Procedures for On-Demand PRS transmission
7.x.1 General
On-Demand PRS transmission procedure allows a UE or LMF to request the PRS transmission or the change to PRS
transmission characteristics for positioning measurements. Either UE or LMF can initiate the On-Demand PRS
transmission request.

7.x.2 On-Demand PRS transmission procedures

Figure 7.x.2-1 shows the general positioning procedure for On-Demand PRS transmission.

Figure 7.x.2-1: Procedures to support On-Demand PRS transmission.

0. The LMF may receive information on the possible On-Demand PRS configurations that the gNB can support
during the TRP Configuration Information Exchange procedure.
1. In case of UE-initiated On-demand PRS, the LMF may configure the UE with available On-Demand pre-defined
PRS configurations via LPP Provide Assistance Data message or via posSI.

2a. In case of UE-initiated Oon-dDemand PRS, the UE sends an On-Demand PRS request to the LMF via LPP
Request Assistance Data message. The On-Demand PRS request may be a request for PRS transmission or
change to the PRS transmission characteristics for positioning measurements.

2b. In case of LMF-initiated On-Demand PRS, the LMF may obtain measurements from the UE using some existing
positioning methods to assist step 3 e.g., the LMF may obtain SSB/CSI-RS RSRP measurements (NR-ECID) or
DL-PRS RSRP measurements (DL-AoD).

3. The LMF determines the need for PRS transmission or change to PRS transmission characteristics. In case of
LMF-initiated On-demand PRS, the LMF may obtain assistance information, e.g. UE measurements prior to step
3.

4. If the LMF determines to perform on-demand PRS request, tThe LMF requests the serving and non-serving
gNBs/TRPs for new PRS transmission or PRS transmission with changes to the PRS configuration via NRPPa
PRS CONFIGURATION REQUEST message.

5. The gNBs/TRPs provide the PRS transmission update in the NRPPa PRS CONFIGURATION RESPONSE
message accordingly if the request from the LMF is accepted.

6. LMF provides the updated PRS configuration used for PRS transmission via LPP Provide Assistance Data
message or posSI to the UE.

NOTE 1: LMF may use existing positioning methods to obtain (ECID) SSB/CSI-RS RSRP measurements or (DL-
AoD) DL-PRS RSRP measurements in order to assist step 3.

NOTE 12:It is up to Network (LMF) implementation on the steps to follow (accept/reject/ignore) on receiving UE-
initiated On-Demand PRS request.

NOTE 2: It is up to Network (TRP) implementation on the steps to follow (accept/reject/ignore) on receiving LMF-
initiated On-Demand PRS requests.

Editor's Note: Depending upon RAN3 input, the above description may need to be updated especially for NRPPa
procedure, e.g. the name of the message, exchange between RAN and LMF on allowed PRS
configuration, etc.

Editor's Note: FFS if the UE can send the MO-LR to request On-Demand PRS.

Editor's Note: FFS on the condition when UE can trigger the On-Demand PRS request.

Editor's Note: FFS on the content of On-Demand PRS request.

Annex-Agreements on RAT dependent positioning methods

Latency reduction
3GPP TSG-RAN WG2 Meeting #114-eR2-21xxxxx Online, 19-27 May 2021

Agreements:
Support pre-configuration of assistance data to the UE at least in an LPP session. Details of
how to enable this are FFS (e.g. what additional functionality beyond deferred location
procedure might be needed).
The LPP Request Location Information message can serve as an indication to the UE to utilize
the pre-configured AD. FFS additional conditions/validity criteria for using the pre-
configured AD.

3GPP TSG-RAN WG2 Meeting #115 electronic R2-2108835

Agreement:
Proposal 3:Regarding the validity conditions/criteria associated with pre-configured assistance
data, consider at least the following options:
 Option A: Based on a validity area (e.g. a list of cells)
 Option B: Based on a (configured) validity timer or a numerical limit on number of times it
is utilized
 Option C: Based on explicit modification or release from the LMF/NG-RAN
 Option D: Based on the UE’s current location and/or the time

Agreement:
Proposal 6 (modified): In response to the question asked by SA2 regarding UE positioning
capability, it is proposed to capture that the positioning related UE capabilities can be
variable.
NOTE: P6 was edited after agreement for clarity (deletion marked with strikeout). Checked in
email discussion [AT115-e][600].

RRC_INACTIVE
3GPP TSG-RAN WG2 Meeting #113b-e R2-21xxxxx Online, 12-20 April
2021

Agreements:
WA: Any uplink LCS or LPP message can be transported in RRC_INACTIVE from RAN2
perspective, subject to the data volume supported by AS layers. I.e. RAN2 do not specify
a restriction on message type.
FFS if LPP needs to select transport, i.e. if the message is just submitted to lower layers which
decide how to deliver it (SDT, change state, etc.).
FFS if RRC state is exposed to LPP.

3GPP TSG-RAN WG2 Meeting #114-eR2-21xxxxx Online, 19-27 May 2021

 Agreements:
Any uplink LCS or LPP message can be transported in RRC_INACTIVE from RAN2
perspective.
Follow Rel-17 SDT framework for INACTIVE UL and DL positioning:
 If the UE initiated data transmission using UL SDT, the network can send DL LCS, LPP
message and RRC message (e.g. to configure SRS (TBD on what message is used), if UL
positioning supported) to the UE.
 Otherwise, if UE did not initiate UL SDT, rely on legacy operation, i.e. the network shall
transition the UE to RRC_CONNECTED, e.g. based on RAN paging.

Agreements:
Exposure of the RRC state of the UE to the LPP layer of the UE for RRC_INACTIVE UL and
DL positioning will not be specified. This does not exclude cross-layer behaviour in
implementations.
The RRC state of the UE is not exposed to the LMF for INACTIVE UL and DL positioning.

3GPP TSG-RAN WG2 Meeting #115 electronic R2-2108835

Agreements:
LPP PDU and LCS message transfer:
Proposal 1:The LPP PDU Transfer Procedure in Annex A is used as baseline for further work.
NOTE 1: Some details may depend on further progress of the SDT work item.
NOTE 2: Whether such a procedure needs to be captured in Stage 2 specification or not can
be decided later when the procedure has been fully developed/agreed. That is, the
procedure can be considered as "running baseline".

Proposal 2:The LCS Message Transfer Procedure in Annex B is used as baseline for further
work.
NOTE 1: Some details may depend on further progress of the SDT work item.
NOTE 2: Whether such a procedure needs to be captured in Stage 2 specification or not can
be decided later when the procedure has been fully developed/agreed. That is, the
procedure can be considered as "running baseline".

Proposal 3:UL LPP message segmentation can also be used by the UE in RRC_INACTIVE
state; i.e., a LPP message body can be sent in several shorter LPP messages instead of
one long LPP message by using the SDT "Subsequent Data Transmission" phase. FFS
spec impact.

DL and RAT-independent positioning:

Proposal 4:The Deferred 5GC-MT-LR Procedure with SDT for DL-only and RAT-independent
positioning in Annex C is used as baseline for further work.
NOTE 1: Some details may depend on further progress of SDT work item.
NOTE 2: Whether such a procedure needs to be captured in Stage 2 specification or not can
be decided later when the procedure has been fully developed/agreed. That is, the
procedure can be considered as "running baseline".
NOTE 3: Once the procedure is stable from RAN2 perspective, send an LS to SA2 including
the baseline procedure.

Agreement:
(High priority)Proposal 1: Support all the RAT independent positioning methods in
RRC_INACTIVE state.

Agreement:
 gNB can configure the UE with periodic SRS (assuming periodic SRS is supported in
RRC_INACTIVE) by RRCRelease with suspendConfig at least when periodic event is
configured for deferred MT-LR. Other cases can be further discussed.

On demand PRS
3GPP TSG-RAN WG2 Meeting #113b-e R2-21xxxxx Online, 12-20 April
2021

Agreements:
UE-initiated on-demand PRS request is enabled by enhancing LPP RequestAssistanceData.
FFS how much control the network has over the UE request.
The UE-initiated mechanism is enabled by the UE request triggering a request from the LMF,
and the C.
Put the stage 2 description for UE-initiated and LMF-initiated PRS request under the same
framework.

3GPP TSG-RAN WG2 Meeting #115 electronic R2-2108835

Agreements:
Before providing available DL-PRS configuration to the UE, the LMF may obtain configuration
information on what DL-PRS can be supported from one or more TRPs via NRPPa.
Capture the steps provided above as a baseline, along with a note indicating it remains FFS if
the UE can send the MO-LR to request on-demand PRS.
FFS if we indicate to SA2 that MO-LR can be used to trigger on-demand PRS procedure.
It is up to Network (LMF) implementation on the steps to follow (accept/reject/ignore) on
receiving request from UE for changing the DL-PRS configurations.

PRU

3GPP TSG-RAN WG2 Meeting #115 electronic R2-2108835

Agreements:
Proposal 1 (modified): For purposes of RAN2 discussion, the PRU functionality as described in
the RAN1 LS can be considered as UE with known location (to some degree of accuracy)
at least (16/17).
PRU modelled as a gNB can be discussed in RAN3 (no RAN2 action).

Agreement:
RAN2 confirm that the PRU considered as a UE supports the normal LPP procedures for
assistance data transfer and location information transfer.