Content for &nbsp; TS 38.305 &nbsp; Word version:&nbsp; 18.3.0

UE1 (e.g., target UE) may receive a Ranging/SL Positioning Service Request from a client UE or from its own application layer as defined in TS 23.586.

UE1 discovers UEs 2 to n, as described in TS 23.586, if not already discovered.

UE1 may obtain the sidelink positioning capabilities from UEs 2 to n using the SLPP Capability Transfer procedure described in clause 7.11.2.1.

Figure 7.14.2-1: Area-specific SRS (Pre-)configuration Allocation Procedure

If UE1 does not support SL Server UE functionality or decides to select a different SL Server UE, a SL Server UE may be discovered (if not already discovered at step 2) and selected as described in TS 23.586.

Step 5.

If step 4 was performed, UE1 may send a Supplementary RSPP SL Positioning/Ranging Service Request message to the SL Server UE including the Application Layer IDs of UEs 1 to n together with an indication of location results requested (e.g., absolute location, relative location or distances and directions) and desired QoS.

Step 6.

If step 4 was performed, the SL Server UE may request the SL positioning and ranging capabilities of UE1 using the SLPP Capability Transfer procedure described in clause 7.11.2.1.

Step 7.

If step 4 was performed, the SL Server UE may request the SL positioning and ranging capabilities of UEs 2 to n using the Supplementary RSPP Procedure. The Supplementary RSPP messages may include embedded SLPP Capability Transfer messages for UEs 2 to n together with their Application Layer IDs. If step 3 did not occur, UE1 obtains the sidelink positioning capabilities from UEs 2 to n using the SLPP Capability Transfer procedure described in clause 7.11.2.1 at this step.

Step 8.

If step 4 was performed, the SL Server UE may provide assistance data for UE1 using the SLPP Assistance Data Transfer procedure described in clause 7.11.2.2.

Step 9.

If step 4 was performed, the SL Server UE may provide assistance data for UEs 2 to n using the Supplementary RSPP Procedure. The Supplementary RSPP messages may include embedded SLPP Assistance Data Transfer messages for UEs 2 to n together with their Application Layer IDs.

Step 10.

UE1 may provide assistance data to UEs 2 to n using the SLPP Assistance Data Transfer procedure described in clause 7.11.2.2. If step 9 was performed, the SLPP Provide Assistance Data message includes the assistance data received from the SL Server UE at step 9.

Step 11.

If step 4 was performed, the SL Server UE may send a SLPP Request Location Information message to UE1 as described in clause 7.11.2.3 if the ranging/positioning result determination is performed by the SL Server UE.

Step 12.

If step 4 was performed, the SL Server UE may request location information for UEs 2 to n using the Supplementary RSPP Procedure if the ranging/positioning result determination is performed by the SL Server UE. The Supplementary RSPP messages may include embedded SLPP Request Location Information messages for UEs 2 to n together with their Application Layer IDs.

Step 13.

UE1 may send a request for sidelink location information to UEs 2 to n using the SLPP Location Information Transfer procedure described in clause 7.11.2.3. If step 12 was performed, the SLPP Location Information Request message includes the information received from the SL Server UE at step 12.

Step 14.

If step 11 was performed, UE1 sends a SLPP Provide Location Information message containing the sidelink location information obtained by UE1 to the SL Server UE as described in clause 7.11.2.3.

Step 15.

If step 12 was performed, UE1 provides the sidelink location information from UEs 2 to n to the SL Server UE using the Supplementary RSPP procedure. The Supplementary RSPP messages may include embedded SLPP Provide Location Information messages for UEs 2 to n together with their Application Layer IDs.

Step 16.

If steps 11 or 12 (and 14 or 15) were performed, the SL Server UE performs the ranging/SL positioning results calculation.

Step 17.

If step 5 was performed, the SL Server UE sends a SL Positioning/Ranging Service Response to UE1 including the results requested in step 5.

Step 18.

If step 5 was not performed, UE1 performs the ranging/SL positioning results calculation as requested at step 1.

Step 19.

The ranging/positioning result is delivered to the requestor from step 1.

7.13 Positioning Integrity |R18| p. 71

7.13.1 General p. 71

Positioning Integrity is supported for the following positioning methods:

GNSS positioning methods as specified in clause 8.1;
Multi-RTT positioning as specified in clause 8.10;
DL-AoD positioning as specified in clause 8.11;
DL-TDOA positioning as specified in clause 8.12;
UL-TDOA positioning as specified in clause 8.13;
UL-AoA positioning as specified in clause 8.14.

For UE-assisted mode and network-based positioning, an LMF may address the UE and TRP local errors from UE and/or TRP measurement results. A specific method for determining local UE and TRP errors/threats is not specified as this is implementation defined.

7.13.2 Integrity Principle of Operation p. 72

For integrity operation, the network will ensure that:

P(Error > Bound for longer than TTA | NOT DNU) ≤ Residual Risk + IRallocation

(Equation 7.13.2-1)

for all values of IRallocation in the range: irMinimum ≤ IRallocation ≤ irMaximum

for all the errors in Table 8.1.2.1b-1, Table 8.11.2.1.1-1, and Table 8.12.2.1.1-1 which have corresponding integrity assistance data available and where the corresponding DNU flag(s) are set to false.

The integrity risk probability is decomposed into a constant Residual Risk component provided in the assistance data as well as a variable IRallocation component that corresponds to the contribution from the Bound according to the Bound formula in Equation 7.13.2-2. IRallocation may be chosen freely by the client based on the desired Bound, therefore the network should ensure that Equation 7.13.2-1 holds for all possible choices of IRallocation. The Residual Risk and IRallocation components may be mapped to fault and fault-free cases respectively, but the implementation is free to choose any other decomposition of the integrity risk probability into these two components.

For GNSS Integrity in SSR, the validity time of the integrity bounds is set as equal to twice the SSR Update Interval for the given SSR Assistance Data message, i.e. the time period between the SSR Epoch Time and the SSR Epoch Time plus twice the SSR Update Interval in the GPS time scale.

Equation 7.13.2-1 holds for all assistance data that has been issued that is still within its validity period. If this condition cannot be met then the corresponding DNU flag must be set.

Equation 7.13.2-1 holds at any epochs for which Assistance Data is provided. Providing Assistance Data without the Integrity Service Alert IE or GNSS Real Time Integrity IEs (in the case of GNSS) is interpreted as a DNU=FALSE condition. For any bound that is still valid (within its validity time), the network ensures that the Integrity Service Alert and/or GNSS Real Time Integrity IEs (in the case of GNSS) are also included in the provided Assistance Data if needed to satisfy the condition in Equation 7.13.2-1. It is up to the implementation how to handle epochs for which integrity results are desired but there are no DNU flag(s) available, e.g. the Time To Alert (TTA) may be set such that there is a "grace period" to receive the next set of DNU flags.

Only those satellites and TRPs for which the integrity assistance data are provided are monitored by the network and can be used for integrity related applications.

Where:

Error:

Error is the difference between the true value of a parameter (e.g. ionosphere, troposphere etc. in the case of GNSS, or ARP location, RTD, etc. in the case of NR positioning), and its value as estimated and provided in the corresponding assistance data as per Table 8.1.2.1b-1, Table 8.11.2.1.1-1, and Table 8.12.2.1.1-1.

Bound:

In the case of GNSS, Integrity Bounds provide the statistical distribution of the residual errors associated with the GNSS positioning corrections (e.g. RTK, SSR etc). In the case of GNSS, integrity bounds are used to statistically bound the residual errors after the positioning corrections have been applied.

In the case of NR positioning, Integrity Bounds provide the statistical distribution of the errors.

The bound is computed according to the Bound formula defined in Equation 7.13.2-2. The bound formula describes a bounding model including a mean and standard deviation (e.g. paired over-bounding Gaussian). The bound may be scaled by multiplying the standard deviation by a K factor corresponding to an IRallocation, for any desired IRallocation within the permitted range.

The bound for a particular error is computed according to the following formula:

Bound = mean + K * stdDev

K = normInv(IRallocation / 2)

irMinimum ≤ IRallocation ≤ irMaximum

(Equation 7.13.2-2)

where:

mean:

mean value for this specific error, as per Table 8.1.2.1b-1, Table 8.11.2.1.1-1, and Table 8.12.2.1.1-1.

stdDev:

standard deviation for this specific error, as per Table 8.1.2.1b-1, Table 8.11.2.1.1-1, and Table 8.12.2.1.1-1.

Time-to-Alert (TTA):

The maximum allowable elapsed time from when the Error exceeds the Bound until a DNU flag must be issued.

Target Integrity Risk (TIR):

The probability per unit of time that the Error exceeds the Bound without issuing a DNU flag within the TTA.

DNU:

The DNU flag(s) corresponding to a particular error as per Table 8.1.2.1b-1, Table 8.11.2.1.1-1, and Table 8.12.2.1.1-1. Where multiple DNU flags are specified, the DNU condition in Equation 7.13.2-1 is present when any of the flags are true (logical OR of the flags).

Residual Risk:

The residual risk is the component of the integrity risk provided in the assistance data as per Table 8.1.2.1b-1, Table 8.11.2.1.1-1, and Table 8.12.2.1.1-1. This may correspond to the fault case risk but the implementation is permitted to allocate this component in any way that satisfies Equation 7.13.2-1.

The Residual Risk is the Probability of Onset which is defined per unit of time and represents the probability that the feared event begins. Each Residual Risk is accompanied by a Mean Duration which represents the expected mean duration of the corresponding feared event and is used to convert the Probability of Onset to a probability that the feared event is present at any given time, i.e.

P(Feared Event is Present) = Mean Duration * Probability of Onset of Feared Event

(Equation 7.13.2-3)

irMinimum, irMaximum:

Minimum and maximum allowable values of IRallocation that may be chosen by the client. Provided as service parameters from the Network according to Integrity Service Parameters.

Correlation Times:

The minimum time interval beyond which two sets of assistance data parameters for a given error can be considered to be independent from one another.

7.14 Procedures for Area-specific SRS Configuration |R18| p. 73

7.14.1 General p. 73

To support Low Power and High Accuracy Positioning (LPHAP) as defined in TS 23.273, area-specific SRS configuration is used to enable SRS transmission by the UE in RRC_INACTIVE state, within positioning validity cell list(s).

7.14.2 Area-specific SRS (Pre-)configuration Allocation Procedure p. 73

Figure 7.14.2-1 shows the Area-specific SRS (Pre-)configuration Allocation procedure.

Reproduction of 3GPP TS 38.305, Fig. 7.14.2-1: Area-specific SRS (Pre-)configuration Allocation Procedure

The LMF sends the NRPPa Positioning Information Request message to the serving gNB of the UE for Area-specific SRS (Pre-)configuration allocation. In case of Area-specific SRS configuration allocation, the LMF includes the Requested SRS Transmission Characteristics including an associated Positioning Validity Area Cell List. In case of Area-specific SRS pre-configuration allocation, the LMF includes a list of Requested SRS Transmission Characteristics, each with the associated Positioning Validity Area Cell List.

The serving gNB allocates the area-specific SRS resources, and moves the UE to RRC_INACTIVE state by sending the RRC Release message, which includes the area-specific SRS (pre-)configuration(s).

The serving gNB responds with the NRPPa Positioning Information Response message to the LMF, including one or more SRS configuration(s), each with the associated Positioning Validity Area Cell List.

Figure 7.14.3-1: Area-specific SRS Configuration Update Procedure

The LMF notifies the gNBs within the positioning validity area(s) to reserve the SRS resources.

7.14.3 Area-specific SRS Configuration Update Procedure p. 74

Figure 7.14.3-1 shows the Area-specific SRS Configuration Update procedure.

Reproduction of 3GPP TS 38.305, Fig. 7.14.3-1: Area-specific SRS Configuration Update Procedure

Step 0.

The UE in RRC_INACTIVE state is configured with an area-specific SRS configuration and reselects to a cell that is not included in the Validity Area Cell List.

The UE sends the RRC Resume Request message with the resume cause "srs-PosConfigOrActivationReq" to request for new SRS configuration.

The receiving gNB which receives the request from the UE triggers the Retrieve UE Context procedure towards the last serving gNB.

The last serving gNB sends the NRPPa Positioning Information Update message to notify the LMF that the UE moved out of the validity area by providing the Cell ID of the receiving gNB where the UE resumes.

Figure 7.14.4-1: Area-specific SRS Configuration Activation Procedure

The last serving gNB relocates the full UE context to the receiving gNB.

Step 5.

The receiving gNB triggers the Path Switch Request procedure towards the AMF.

Step 6.

The AMF responds with the NGAP Path Switch Request Acknowledge message.

Step 7.

The LMF requests the receiving gNB to allocate a new SRS configuration for the UE. If the Positioning Validity Area Cell List is included in the Requested SRS Transmission Characteristics, the Area-specific SRS Configuration Allocation procedure as specified in clause 7.14.2 is applied.

Step 8.

The receiving gNB indicates to the last serving gNB to release the UE context.

7.14.4 Area-specific SRS Configuration Activation Procedure p. 75

Figure 7.14.4-1 shows the Area-specific SRS Configuration Activation procedure.

Reproduction of 3GPP TS 38.305, Fig. 7.14.4-1: Area-specific SRS Configuration Activation Procedure

Step 0.

The UE in RRC_INACTIVE state is pre-configured with one or more area-specific SRS for positioning configurations as specified in clause 7.14.2 and receives a request from upper layers to activate a pre-configured SRS for positioning when the UE is camped on one of the cells indicated in the validity area(s) (e.g., when a configured periodic or triggered event is detected).

The UE sends a RRC Resume Request message with the resume cause "srs-PosConfigOrActivationReq" to request activation of the pre-configured SRS.

The receiving gNB which receives the request from the UE triggers the Retrieve UE Context procedure towards the last serving gNB and includes the pre-configured SRS activation request in the Retrieve UE Context Request message.

The last serving gNB sends a NRPPa Positioning Information Update message to the LMF including the Cell ID of the receiving gNB where the UE resumes from together with a pre-configured SRS activation indication to notify the LMF that the pre-configured SRS is activated in the UE.