User Equipment Operation and Requirements for Sidelink Positioning

Abstract

This disclosure relates to user equipment (UE) operations and requirements for sidelink positioning. A target UE receives a Sidelink Positioning Protocol (SLPP) request and measures and reports sidelink (SL) positioning measurements. The target UE measures a set of SL positioning reference signals (PRS) based on the received request and transmits a measurement report. The measurement report includes positioning results based on measurements of the SL PRS set. Other embodiments may be described and / or claimed.

Description

[Technical Field]

[0001] [Related Applications] This application claims priority to U.S. Provisional Application No. 63 / 485,719 ("'719"), filed February 17, 2023, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] 3GPP® Fifth Generation (5G) / New Radio (NR) technologies, such as operation in low and high frequency bands (e.g., below and above 6 gigahertz (GHz)) and the use of large-scale antenna arrays, can provide enhanced positioning capabilities and improved positioning accuracy. To this end, sidelink (SL) reference signals and measurement procedures for SL positioning and ranging (SLPR) in NR systems are currently being designed. However, measurement reporting requirements for SL positioning and / or ranging methods are not specified or defined. Summary of the Invention

[0003]

[0013] Embodiments will be readily understood by the following detailed description taken in conjunction with the accompanying drawings, in which:

[0014] To facilitate this description, like reference numerals refer to like elements;

[0015] Embodiments are described by way of example, and not by way of limitation, with reference to the accompanying drawings in which: [Brief explanation of the drawings]

[0004] [Figure 1] An example of a PC5-only network scenario is shown. [Figure 2] An example of a PC5-Uu network scenario is shown. [Figure 3] 1 illustrates an example of ranging between user equipment (UE) with and without fifth generation (5G) coverage. [Figure 4] 1 illustrates an example network architecture. [Figure 5]1 illustrates an example UE positioning architecture. [Figure 6] An example network-assisted sidelink positioning architecture and an example location service reference architecture are shown. [Figure 7] An example of a reference architecture for SLPR-based services is shown. [Figure 8] 1 shows an example of a wireless network. [Figure 9] Examples of hardware resources are shown below. [Figure 10] 1 illustrates an example process for implementing various embodiments discussed herein. [Figure 11] 1 illustrates an example process for implementing various embodiments discussed herein. DETAILED DESCRIPTION OF THE INVENTION

[0005] 1. Sidelink Positioning The present disclosure relates generally to wireless communication technologies, network topologies, and communication device implementations, and more particularly to user equipment (UE) operation and requirements for sidelink (SL) positioning and / or ranging.

[0006] In Release (Rel-)17, 3GPP RAN conducted studies on "NR Positioning Enhancements" in 3GPP TR38.857 (see [TR38857]) and "Scenarios and requirements of in-coverage, partial coverage, and out-of-coverage NR positioning use cases" in 3GPP TR38.845 (see [TR38845]) focusing on Vehicle-to-Everything (V2X) and public safety use cases. Additionally, System Architecture Working Group 1 (SA1) developed 3GPP TS 22.261 ("TS22261") requirements for ranging-based services and 3GPP TS 22.104 ("TS22104") positioning accuracy requirements for industrial IoT (IIoT) use cases in out-of-coverage scenarios.

[0007] Positioning integrity is a measure of confidence in the accuracy of location-related data and the ability to provide timely warnings based on assistance data provided by the network. While Rel-17 work focused on GNSS integrity, it is natural to extend this in Rel-18 to accommodate other positioning technologies, and any mission-critical use case that relies on position estimates and corresponding uncertainty estimates will have a relevant integrity aspect. Integrity allows an application to make correct decisions based on the reported position, such as monitoring a robotic arm to determine whether its movements are within acceptable limits to ensure safe distances from humans and other objects.

[0008] Regarding higher accuracy, Rel-18 considers two additional technologies: one is to utilize the abundant 5G spectrum to increase the bandwidth for transmitting and receiving positioning reference signals based on PRS / SRS bandwidth aggregation of adjacent carriers in the band, and the other is to use NR carrier phase measurement. GNSS carrier phase positioning has been used very successfully for centimeter-level positioning accuracy, but is limited to outdoor applications.

[0009] Low-power, high-accuracy positioning (LPHAP) requirements have been introduced for industrial IoT scenarios, including use cases such as large-scale asset tracking, automatic guided vehicle (AGV) tracking in industrial factories, and personnel location in hazardous areas. These requirements are intended to achieve high accuracy and very low power consumption while maintaining a battery life of more than one year. A typical scenario of interest is Use Case #6 defined in [TS22104], which corresponds to tracking of workpieces (indoor and outdoor) in assembly areas and warehouses with a target accuracy of less than 1 m, a positioning interval of 15–30 seconds, and a battery life of 6–12 months. While Rel-17 NR positioning introduces support for positioning in the RRC_INACTIVE state, the ability of current systems to meet the LPHAP requirements was not evaluated in Rel-17.

[0010] Rel-17 specifies support for reduced-complexity (reduced capability (RedCap)) UEs 402, which have reduced bandwidth support, such as a reduced number of receive (Rx) chains. RedCap UEs 402 are UEs 402 with reduced capabilities, as defined in 3GPP TS38.306 §4.2. While such UEs 402 can support NR positioning functionality, there are gaps in that the core and performance requirements for positioning-related measurements performed by RedCap UEs 402 are not specified, and no evaluation has been performed to determine how the capabilities of RedCap UEs 402 affect the final positioning accuracy.

[0011] A Rel-18 research item on "Study on Expanded and Improved NR Positioning" was conducted by 3GPP and documented in 3GPP TR38.859 ("TS38859") to determine scenarios and requirements, bandwidth requirements, solutions, and evaluate the positioning performance of RedCap UE402 to support SL ranging / positioning and improve the integrity, accuracy, and power efficiency of NR positioning solutions.

[0012] Based on this research, various features and extensions are recommended to support SL ranging / positioning, support the consistency of RAT dependent positioning methods, extensions to enable the LPHAP use case defined in [TS22104], and support positioning of the RedCap UE402 with acceptable positioning accuracy considering the requirements of IIoT, commercial, public safety, and V2X use cases.

[0013] Based on this study, it was concluded that PRS / SRS bandwidth aggregation of in-band adjacent carriers is feasible with a single-chain Tx / Rx architecture for both the UE 402 and the RAN node 414 (e.g., gNB 414a). Another technique is NR carrier phase positioning, which offers the potential for significant performance improvements for indoor and outdoor deployments compared to existing NR positioning methods, with the potential for shorter latency and lower UE power consumption compared to RTK-GNSS outdoors. Based on this study, it was concluded that it is feasible to obtain carrier phase measurements using existing DL PRS and SRS signals to achieve horizontal accuracy down to a few centimeters with at least 50% accuracy under certain conditions.

[0014] The purpose of the 3GPP Work Item Description (WID), New WID on Expanded and Improved NR Positioning, 3GPP TSG RAN Meeting #98-e, Agenda Item 9.1.1, RP-223532 (December 12-16, 2022) (“RP-223532”) is to identify solutions to support SL positioning and ranging (SLPR) in NR systems. From a physical layer perspective, new measurement reference signals and procedures for SLPR can be designed and standardized. For example, measurement reporting requirements for different positioning methods (e.g., SL-Round Trip Time (RTT), SL-Angle of Arrival (AoA), SL-Time Difference of Arrival (TDoA), and / or other SLPR measurements) using new SL positioning reference signal (PRS) measurements should be specified in Rel-18.

[0015] The RTT and TDoA requirements for the new SL-PRS measurements need to be specified in Rel-18. Since there are no AoA requirements from Rel-17 onwards, whether SL-AoA should be defined in Rel-18 is for future study (FFS). Based on these observations, a first embodiment involves defining RTT and TDoA requirements for SL positioning, while other positioning methods (e.g., SL-AoA) are FFS.

[0016] Also, as explicitly stated in RP-223532, SL-PRS transmission is supported up to 100 MHz in Frequency Range 1 (FR1) spectrum, but not in Frequency Range 2 (FR2). Some implementations do not need to consider SL-PRS in FR2. In some implementations, SL positioning measurement requirements are defined only in FR1.

[0017] Furthermore, reporting signaling and procedures are considered to realize support for SL positioning in some or all coverage scenarios, as well as in PC5-only and joint PC5-Uu scenarios (see, for example, RP-223532). For example, UE measurement configuration and reporting for PC5 SL can be based on the new SL Positioning Protocol (SLPP) protocol. However, from the perspective of physical layer measurements themselves, the UE behavior itself may not change compared to the Uu link case.

[0018] In some instances, the SL positioning requirements for PC5-only can be separated from the joint PC5-Uu scenario. To simplify RAN4's work on SL requirements for all coverage scenarios (PC-only and joint PC5-Uu links), in some implementations, the SL positioning requirements can start with the PC5-only scenario first.

[0019] For new procedures for power control for SL-PRS transmissions, it is necessary to consider whether the existing power headroom reporting mapping is feasible. In some implementations, the reporting mapping for power control of SL-PRS can be FFS. In some instances, a relatively small resolution for this mapping table can be determined / generated.

[0020] According to various embodiments, UE behavior and requirements are provided when the UE performs positioning measurements in SL. In some embodiments, the positioning measurements can be for RTT and TDoA using a new SL-PRS. Additionally or alternatively, requirements can be defined for both PC5-only and PC5-Uu joint scenarios. Additionally or alternatively, requirements for PC5-Uu joint scenarios can be defined based on PC5-only and Uu-only. Additionally or alternatively, reporting mapping for power control of SL-PRS can be defined.

[0021] In some embodiments, NR measurements for SL positioning include requirements for RTT and TDoA, and new SL-PRS measurements are defined herein.

[0022] In some embodiments, NR measurements for SL positioning may be defined based on PC5 only and Uu only, including requirements for SL positioning in the case of a joint PC5-Uu scenario.

[0023] In some embodiments, NR measurements for SL positioning include reporting mapping for power control of SL-PRS and can be defined with a finer resolution than general power control procedures.

[0024] In some embodiments, NR measurements for SL positioning include reporting mapping for measured timing differences between reference signals. In these embodiments, SL positioning can take advantage of the finer resolution configured for measurement reporting.

[0025] In some implementations, the reporting range for the various reporting mappings is -985024Tc From +985024×T c (See, e.g., [TS38215]). Additionally or alternatively, the reporting resolution is uniform over the reporting range, T = Tc * 2 k where k is selected by the gNB 414 and / or the UE 402 from the set {0, 1, 2, 3, 4, 5}. c is defined in [TS38211].

[0026] 1.1. Positioning performance requirements Highly accurate positioning will be essential in the factory of the future and in other applications and use cases, as tracking mobile devices and assets becomes increasingly important for process improvement and increased flexibility in industrial environments.

[0027] 5GS provides positioning information for UEs outside the network range, with an accuracy of <1m relative to other UEs in the vicinity and range of the network.

[0028] Table 1.1-1 shows example scenarios and the corresponding high-precision positioning requirements in terms of horizontal and vertical accuracy, availability, heading, delay, and UE velocity (see also Table 5.7.1-1 in [TS22104]). [Table 1] The "Corresponding Positioning Service Level" column maps the scenarios listed in Table 1.1-1 to the service levels discussed in this specification and / or [TS22261].

[0029] 1.2. NR Sidelink Measurements for Positioning In various implementations, the NR SL positioning measurement requirements are applicable to a UE 402 capable of V2X and / or 5G Proximity Services (ProSe) operation. It is also capable of performing SL positioning measurements defined herein and / or in [TS38215]. This includes SL-RSTD, SL PRS-RSRP, SL Rx-Tx time difference, SL PRS-RSRPP measurements, SL-AoA, and SL-RTOA. This occurs when the SL-PRS is received on the NR PC5 interface (see, for example, Figures 5, 6, and 7) within a single SL BWP on a single carrier, and the UE 402 is in any cell selection state, or the UE 402 is within NG-RAN coverage and configured for SL positioning operation on the SL carrier. This is dedicated to SL operation, configured only on the PCell on the WAN carrier, and the UE 402 does not need to monitor the PSCCH. This is associated with the SL-PRS in the same slot, outside of SL-DRX active time.

[0030] In some examples, any cell selection state refers to a UE 402 that is out of network coverage and not associated with a serving cell on any carrier, as defined in [TS38304]. Additionally or alternatively, when the UE 402 is in the RRC_CONNECTED state and performing transmission and / or reception of SL positioning operations, the UE 402 satisfies all requirements specified in [TS38133] §9, assuming the UE 402 has an Rx / Tx chain dedicated to SL operations. Otherwise, the UE 402 may suspend SL positioning measurements to meet the measurement requirements specified in [TS38133] §9. Additionally or alternatively, the UE 402 may need to perform a discovery procedure before performing SL-PRS-based measurements.

[0031] 1.2.1.SL-RSTD Measurement The SL-RSTD measurement requirements apply when the UE 402 receives an SLPP-RequestLocationInformation message (e.g., CommonIEsRequestLocationInformation message, CommonSL-PRS-MethodsIEsRequestLocationInformation message, SL-TDOA-RequestLocationInformation message, SL-TOA-RequestLocationInformation message, SL-RTT-RequestLocationInformation message) from the LMF 470 or another UE 402 via SLPP (see, e.g., [TS38355]) requesting the UE 402 to measure and report SL RSTD measurements as defined in [TS38215] based on the SL-PRS.

[0032] SL RSTD measurement is T SL-RXi -T SL-RXj is the SL relative timing difference between UEj and reference UEi, defined as: where T SL-RXj is the time when a UE (e.g., target UE 402t) receives the start of one subframe from UEj. SL-RXi is the time at which a UE (e.g., target UE 402t) receives the corresponding start of one subframe from UEi that is closest in time to the subframe received from UEj. For FR1, the reference point for SL RSTD measurement is the Rx antenna connector of the UE 402. For FR2, the reference point for SL RSTD measurement is the Rx antenna of the UE 402. SL RSTD measurement is applicable to UEs 402 in RRC_CONNECTED and / or RRC_IDLE.

[0033] The requirements for SL-RSTD measurements apply to periodic, aperiodic, and triggered RSTD measurements, provided that the SL RSTD-related side conditions in FR1 are met in the corresponding bands.

[0034] The UE SL-RSTD measurement capability is indicated by the UE 402 in the sl-TDOA-ProvideCapabilities IE according to 3GPP TS38.355 ("TS38355"). The IESL-TDOA-ProvideCapabilities IE indicates support for SL-TDOA and is used to provide SL-TDOA positioning capabilities. The SL-TDOA-ProvideCapabilities IE includes an application layer ID IE / field (applicationLayerID), a positioning mode IE / field (positioningModes) that specifies the SL-TDOA modes supported by the UE, a periodic reporting IE / field (periodicalReporting) that, if present, specifies the positioning modes that the UE supports (periodicalReporting), and a "ten milliseconds" IE / field (tenMsUnitResponseTime) that, if present, specifies the positioning modes that the UE supports with the enumeration value "ten-milliseconds" in the IE ResponseTime in the IE CommonIEsRequestLocationInformation.

[0035] The measurement reporting delay is defined as the time between the moment the measurement reporting is triggered and the moment the UE 402 starts transmitting the measurement report over the air interface.

[0036] For UEs 402 reporting to the LMF 470, this measurement reporting requirement assumes that the measurement report is not delayed by other SLPP signaling on the DCCH. This measurement reporting delay eliminates the delay uncertainty that occurs when inserting the measurement report into the TTI of the uplink DCCH. The delay uncertainty is: 2xTTI DCCH , where TTI DCCH is the duration of a subframe, slot, or subslot when a measurement report is transmitted on a PSSCH using that duration.

[0037] For a UE 402 reporting to another UE 402, this measurement reporting requirement assumes that the measurement report is not delayed by other SLPP signaling on the STCH. This measurement reporting delay eliminates the delay uncertainty that occurs when inserting the measurement report into the TTI of the transmitted STCH. The delay uncertainty is: 2xTTI STCH , where TTI STCH is the duration of a subframe, slot, or subslot when a measurement report is transmitted on a PSSCH using that duration.

[0038] The measurement report delay excludes delays caused by the lack of SL and / or SL-PRS resources for the UE 402 to transmit the measurement report.

[0039] The reported SL RSTD measurements included in the measurement report are based on the measurement report mapping requirements, which may be predefined, configured, and / or implementation specific. In one example, the measurement report mapping requirements include a reporting range of -985024T c From +985024×T c is defined uniformly across the reporting range, and T = T c *2 k where k is selected by the gNB 414a or the UE 402 from the set {0, 1, 2, 3, 4, 5}, and T c is defined in [TS38211]. In this example, LMF470 provides a recommended resolution parameter timingReportingGranularityFactor, and the parameter k selected based on timingReportingGranularityFactor is indicated in LMF LMF470. Additionally or alternatively, the mapping of measurements for each reporting resolution (k) is defined in Tables 13.1.1-1 to 13.1.1-6 of [TS38133]. Additionally or alternatively, the measurement reporting mapping requirement is -8175×T c From +8175×T cThe reporting resolution is uniform across the reporting range, T=Tc*2 k where k is selected by the gNB 414a or the UE 402 from the set {0, 1, 2, 3, 4, 5}. c is defined in [TS38211]. In this example, LMF470 provides a recommended resolution parameter, timingReportingGranularityFactor, and the parameter k selected based on timingReportingGranularityFactor is indicated in LMF LMF470. Additionally or alternatively, the measurement quantity mapping for each reporting resolution (k) is defined in Tables 13.1.1A-1 to 13.1.1A-6 of [TS38133]. Additional or alternative measurement reporting mapping requirements may be used in other implementations.

[0040] SL RSTD measurements performed and reported in accordance with this section shall meet SL RSTD measurement accuracy requirements, which may be predefined, configurable, and / or implementation specific, for each SL-PRS resource being measured.

[0041] The measurement period requirement for SL-RSTD includes, for example, when the physical layer receives the last of the sl-TDOA-ProvideAssistanceData message and the sl-TDOA-RequestLocationInformation message from the LMF 470 or another UE 402 via SLPP (see, for example, [TS38355]), the UE 402 shall terminate the measurement period T SL RSTD,Total During T, at least X SL RSTD measurements (where X is a number that can be predefined, configured, and / or up to the UE implementation) can be performed, with each SL RSTD measurement including measurements on the measured target link and the reference link as defined in [TS38215]. SL RSTD,Total is defined as follows:

number

number

number

[0042] In examples, the measured target link is an SL link and / or PC5 interface and the reference link is a Uu link / interface. In these examples, SL RSTD measurements can be used for joint PC5-Uu scenarios. In other examples, the measured target link is an SL link and / or PC5 interface and the reference link is another SL link and / or PC5 interface.

[0043] If the synchronization reference source of the target measurement link or the reference link for the SL RSTD measurement (see, e.g., [TS38355]) is changed during T... (e.g., during the measurement period) for a measuring UE 402 or a UE 402 configured to transmit SL-PRS while the UE 402 is performing SL RSTD measurements, the UE 402 shall resume the SL RSTD measurements after the synchronization reference source change.

[0044] In some examples, if the synchronization reference source is changed in the measuring UE 402 or in a UE 402 configured to transmit SL-PRS for the target measurement link of the SL RSTD measurement or the reference link of the SL RSTD measurement (see, e.g., [TS38355]) while the measuring UE 402 is performing SL RSTD measurements, the measuring UE 402 restarts the SL RSTD measurements and:

number

[0045] 1.2.2.SL-RSRP Measurement The SL-RSRP measurement requirements apply when the UE 402 receives an SLPP-RequestLocationInformation message (e.g., CommonIEsRequestLocationInformation message, CommonSL-PRS-MethodsIEsRequestLocationInformation message, SL-TDOA-RequestLocationInformation message, SL-TOA-RequestLocationInformation message, SL-RTT-RequestLocationInformation message) from the LMF 470 or another UE 402 via SLPP (see, e.g., [TS38355]) requesting the UE 402 to measure and report SL PRS-RSRP measurements based on the SL-PRS as defined in [TS38215].

[0046] The SL PRS reference signal received power (SL PRS-RSRP) is defined as the linear average over the power contributions (in watts (W)) of the resource elements transmitting the SL PRS reference signals configured for RSRP measurement within the considered measurement frequency bandwidth. For FR1, the reference point for SL PRS-RSRP is the Rx antenna connector of the UE 402. For FR1, if receiver diversity is used by the UE 402, the reported SL PRS-RSRP value shall not be lower than the corresponding SL PRS-RSRP of any of the individual receiver branches. For FR2, the SL PRS-RSRP is measured based on the composite signal from the antenna elements corresponding to a specific receiver branch. If receiver diversity is used by the UE 402, the reported SL PRS-RSRP value shall not be lower than the corresponding SL PRS-RSRP of any of the individual receiver branches. SL PRS-RSRP measurement is applicable to UEs 402 in RRC_CONNECTED and / or RRC_IDLE.

[0047] The requirements for SL-RSRP measurements apply to periodic, aperiodic, and triggered SL PRS-RSRP measurements, provided that the SL PRS-RSRP related side conditions in FR1 are met in the corresponding band.

[0048] The UE 402 indicates its SL PRS-RSRP measurement capabilities in the sl-TDOA-ProvideCapabilities, sl-RTT-ProvideCapabilities, sl-AOA-ProvideCapabilities, or sl-TOA-ProvideCapabilities IEs according to [TS38355]. The SL-TDOA-ProvideCapabilities IE is the same as or similar to that described previously. The sl-RTT-ProvideCapabilities IE, sl-AOA-ProvideCapabilities IE, and sl-TOA-ProvideCapabilities IE each contain applicationLayerID, periodicReporting, and tenMsUnitResponseTime. The sl-RTT-ProvideCapabilities IE includes positioningModes, which specifies the SL-RTT modes supported by the UE 402. The sl-AOA-ProvideCapabilities IE further includes positioningModes, which specifies the SL-AoA modes supported by the UE 402. The sl-TOA-ProvideCapabilities IE further includes positioningModes, which specifies the SL-TOA modes supported by the UE 402.

[0049] The measurement reporting delay is defined as the time between the moment the measurement reporting is triggered and the moment the UE 402 starts transmitting the measurement report over the air interface.

[0050] For UEs 402 reporting to the LMF 470, this measurement reporting requirement assumes that the measurement report is not delayed by other SLPP signaling on the DCCH or SCCH. This measurement reporting delay eliminates the delay uncertainty that occurs when inserting the measurement report into the TTI of the uplink DCCH or SCCH. The delay uncertainty is: 2xTTI DCCH / SCCH , where TTI DCCH / SCCHis the duration of a subframe, slot, or subslot when a measurement report is transmitted on a PUSCH using that duration.

[0051] For a UE 402 reporting to another UE 402, this measurement reporting requirement assumes that the measurement report is not delayed by other SLPP signaling on the STCH. This measurement reporting delay eliminates the delay uncertainty that occurs when inserting the measurement report into the TTI of the transmitted STCH. The delay uncertainty is: 2xTTI STCH , where TTI STCH is the duration of a subframe, slot, or subslot when a measurement report is transmitted on a PSSCH using that duration.

[0052] The measurement report delay excludes delays caused by the lack of SL and / or SL-PRS resources for the UE 402 to transmit the measurement report.

[0053] The reported SL PRS-RSRP measurements included in the measurement report are based on a measurement report mapping requirement, which may be predefined and / or configured. In one example, the measurement report mapping requirement may include a reporting range of -985024T c From +985024×T c is defined uniformly across the reporting range, and T = T c *2 k where k is selected by the gNB 414a or the UE 402 from the set {0, 1, 2, 3, 4, 5}, and T cis defined in [TS38211]. In this example, LMF470 provides a recommended resolution parameter, timingReportingGranularityFactor, and the parameter k selected based on timingReportingGranularityFactor is indicated in LMF LMF470. Additionally or alternatively, the mapping of measurands for each reporting resolution (k) is defined in Tables 13.2.1-1 to 13.2.1-6 of [TS38133]. Additionally or alternatively, the reporting range, and T = T c *32, and the measurement mapping is defined in Table 13.7.1-1 of [TS38133]. Additionally or alternatively, the measurement report mapping requirement may be -8175×T c From +8175×T c The reporting resolution is uniform across the reporting range, T = T c *2 k where k is selected by the gNB 414a or the UE 402 from the set {0, 1, 2, 3, 4, 5}. c is defined in [TS38211]. In this example, LMF470 provides a recommended resolution parameter, timingReportingGranularityFactor, and the parameter k selected based on timingReportingGranularityFactor is indicated in LMF LMF470. Additionally or alternatively, the measurement quantity mapping for each reporting resolution (k) is defined in Tables 13.2.1A-1 to 13.2.1A-6 of [TS38133]. Additional or alternative measurement reporting mapping requirements may be used in other implementations.

[0054] SL PRS-RSRP measurements performed and reported in accordance with this section are intended to meet SL PRS-RSRP measurement accuracy requirements, which may be predefined and / or configured for each SL-PRS resource being measured. In one example, the accuracy requirements for SL Rx-Tx time difference measurements and / or SL-RTT include ±(X+Y)T under one or more conditions, such as additive white Gaussian noise (AWGN) propagation conditions, reference sensitivity requirements, etc. c This includes being within.

[0055] The measurement period requirement of SL-RSRP is that the UE 402 should enter measurement period T when the physical layer receives the last of the following: SLPRS-RSRP,Total The UE 402 may perform at least Y SL PRS-RSRP measurements as defined in [TS38215] during the SLPP (where Y is a number that is predefined, configured, and / or possible up to the UE location implementation): sl-TDOA-ProvideAssistanceData and sl-TDOA-RequestLocationInformation messages; sl-AOA-ProvideAssistanceData and sl-AOA-RequestLocationInformation messages; sl-TOA-ProvideAssistanceData and sl-TOA-RequestLocationInformation messages; or sl-RTT-ProvideAssistanceData and sl-RTT-RequestLocationInformation messages from the LMF 470 or another UE 402 via SLPP (see, e.g., [TS38355]). SLPRS-RSRP,Total is defined as:

number

number

number

[0056] If the synchronization reference source is changed in the measuring UE 402 or in a UE 402 configured to transmit SL-PRS for SL PRS-RSRP measurements while the measuring UE 402 is performing SL PRS-RSRP measurements, the UE 402 shall continue the SL PRS-RSRP measurements after the change of synchronization reference source and continue the measurement period T SL PRS-RSRP,Total and meet predefined and / or set accuracy requirements.

[0057] 1.2.3.SL-Rx-Tx measurement The SL-Rx-Tx measurement requirements apply when the UE 402 has received an NR-SL-RxTx-RequestLocationInformation (or CommonIEsRequestLocationInformation message, CommonSL-PRS-MethodsIEsRequestLocationInformation message, SL-TDOA-RequestLocationInformation message, SL-TOA-RequestLocationInformation message, SL-RTT-RequestLocationInformation message, etc.) from the LMF 470 or another UE 402 via SLPP, requesting the UE to measure and report SL Rx-Tx time difference measurements as defined in [TS38215] based on the SL-PRS.

[0058] The SL Rx-Tx time difference at UE402 is T UE-RX -T UE-TX It is defined as T UE-RX is the time when the UE 402 receives the SL subframe #i from the transmitting UE 402, and is defined by the first detected path in time. If the UE 402 reports the transmission timestamp of the SL PRS, T UE-TX is the transmission timing of SL subframe #j of the SL PRS of UE 402. Otherwise, T UE-TX is the UE 402 transmit timing of the SL subframe #j that is closest in time to the subframe #i received from the transmitting UE 402. The same antenna reference point is used for the receiver and transmitter for the Rx-Tx time difference measurement. When the UE 402 reports the transmit timestamp of the SL PRS, the SL Rx-Tx time difference is modulo wrapped to a value between -0.5 ms and +0.5 ms.

[0059] For FR1, T UE-RX The reference point for the measurement is the Rx antenna connector of the UE402, and the T UE-TX The reference point for the measurement is the Tx antenna connector of the UE402. UE-RXThe reference point for the measurement is the Rx antenna of UE 402, and T UE-TX The reference point for the measurement shall be the Tx antenna of the UE 402.

[0060] The SL-Rx-Tx measurement requirements apply to periodic, aperiodic and triggered SL Rx-Tx time difference measurements if the SL Rx-Tx time difference related side conditions of FR1 for the corresponding band are met and / or if the actual time difference between the corresponding SL-PRS transmit and receive used to derive the measurement is less than or equal to

[0160] milliseconds.

[0061] The SL Rx-Tx time difference measurement capability is indicated by the UE 402 in NR-SL-RxTx-ProvideCapabilities (or sl-TDOA-ProvideCapabilities, sl-RTT-ProvideCapabilities, sl-AOA-ProvideCapabilities, or sl-TOA-ProvideCapabilities) according to [TS38355].

[0062] The measurement reporting delay is defined as the time between the moment the measurement reporting is triggered and the moment the UE starts transmitting the measurement report over the radio interface.

[0063] For UEs reporting to LMF470, this requirement assumes that the measurement report is not delayed by other SLPP signaling on the DCCH. This measurement report delay eliminates the delay uncertainty that occurs when inserting the measurement report into the TTI of the uplink DCCH. The delay uncertainty is: 2xTTI DCCH , where TTI DCCH is the duration of a subframe, slot, or subslot when a measurement report is transmitted on a PSSCH using that duration.

[0064] For a UE 402 reporting to another UE 402, this requirement assumes that the measurement report is not delayed by other SLPP signaling on the STCH. This measurement report delay eliminates the delay uncertainty that occurs when inserting the measurement report into the TTI of the transmitted SL STCH. The delay uncertainty is: 2xTTI STCH , where TTI STCH is the duration of a subframe, slot, or subslot when a measurement report is transmitted on a PSSCH using that duration.

[0065] The measurement report delay excludes delays caused by the absence of SL and / or SL-PRS resources for the UE to transmit the measurement report.

[0066] The reported Rx-Tx time difference measurements included in the measurement report are based on measurement report mapping requirements, which may be predefined, configured, and / or implementation specific. In one example, the measurement report mapping requirements include a reporting range of -985024T c From +985024×T c is defined uniformly across the reporting range, and T = T c *2 k where k is selected by the gNB 414a or the UE 402 from the set {0, 1, 2, 3, 4, 5}, and T c is defined in [TS38211]. In this example, LMF470 provides a recommended resolution parameter, timingReportingGranularityFactor, and the parameter k selected based on timingReportingGranularityFactor is indicated in LMF LMF470. Additionally or alternatively, the mapping of measurands for each reporting resolution (k) is defined in Tables 13.2.1-1 to 13.2.1-6 of [TS38133]. Additionally or alternatively, the reporting range, and T = T c*32, and the measurement mapping is defined in Table 13.7.1-1 of [TS38133]. Additionally or alternatively, the measurement report mapping requirement may be -8175×T c From +8175×T c The reporting resolution is uniform across the reporting range, T = T c *2 k where k is selected by the gNB 414a or the UE 402 from the set {0, 1, 2, 3, 4, 5}. c is defined in [TS38211]. In this example, LMF470 provides a recommended resolution parameter, timingReportingGranularityFactor, and the parameter k selected based on timingReportingGranularityFactor is indicated in LMF LMF470. Additionally or alternatively, the measurement quantity mapping for each reporting resolution (k) is defined in Tables 13.2.1A-1 to 13.2.1A-6 of [TS38133]. Additional or alternative measurement reporting mapping requirements may be used in other implementations.

[0067] SL Rx-Tx time difference measurements performed and reported in accordance with this section meet SL Rx-Tx time difference measurement accuracy requirements that may be predefined, configured, and / or implementation specific for each SL-PRS resource being measured. In one example, the accuracy requirements for SL Rx-Tx time difference measurements include the following:

number

[0068] When the physical layer receives an NR-SL-RxTx-ProvideAssistanceData message from the LMF 470 or an NR-SL-RxTx-RequestLocationInformation message from another UE 402 via SLPP, the UE 402 SLRxTx,totalDuring the UE operation, at least Z SL Rx-Tx time difference measurements as defined in [TS38215] may be performed (where Z is a number that may be predefined, configured, and / or up to the UE implementation).

number

number

number

[0069] In some instances, the SL PRS measurement period for measurements on the SL-PRS of multiple UEs 402 is for future study.

[0070] In some examples, while the measuring UE 402 is performing SL Rx-Tx time difference measurements, the synchronization reference source is changed at the measuring UE 402 or at a UE 402 configured to transmit the SL-PRS for measurements, and the measuring UE 402 resumes the SL Rx-Tx time difference measurements and transmits a measurement report no later than:

number

[0071] 1.3.NR Sidelink Positioning SL positioning provides absolute position, geographic position, relative position, and / or ranging information (e.g., range and / or direction) of the UE 402, using at least the PC5 interface for positioning (see, e.g., FIGS. 5, 6, and 7). In some examples, SL positioning can be used to provide the velocity of the UE 402, such as the relative velocity of the UE 402. The located UE 402l can be used to determine the absolute position of the target UE 402t using SL positioning.

[0072] Ranging / SL Positioning (RSP) operations can be performed in NW-assisted, NW-based, or UE-only operation. In NW-assisted operation, one or more 5GC Network Functions (NFs) are involved in processing the service request and assist the UE 402 for result calculation. In NW-based operation, one or more 5GC Network Functions (NFs) are involved in processing the service request and result calculation. In UE-only operation, service request processing and result calculation are performed by the UE 402.

[0073] The result calculations for each of the aforementioned RSP operating modes may include any information obtained for the target UE 402t and obtained using SL positioning (e.g., absolute position, geographic position, relative position, relative position, ranging information, position results as discussed in 3GPP TS 23.032 (“[TS23032]”), and / or any other type of information such as any information discussed herein).

[0074] The purpose of the NR SL positioning procedure is to perform NR SL positioning as discussed herein and / or as specified in [TS38305], [TS23586], etc. For SLPR using SL-RTT, SL-AoA, SL-TDOA, and SL-TOA methods, the UE 402 transmits and / or receives the SL-PRS as specified in [TS38211] via the NR PC5 interface (see, e.g., Figures 5, 6, and 7). The UE 402 can be configured with one or more SL resource pools via system information (SI) or dedicated signaling (e.g., via downlink control information (DCI) format 3_0, DCI format 3_2, and / or other DCI formats, and / or via sidelink control information (SCI) format 1-B, SCI format 2-D, and / or other SCI formats) within NG-RAN coverage, or by pre-configuration outside NG-RAN coverage as specified in [TS38331].

[0075] SL-PRS resources refer to the time-frequency resources within a slot used for SL-PRS transmission. An SL resource pool that can be used for both SL-PRS and SL data transmission is called an SL-PRS shared resource pool. In a shared SL-PRS resource pool, the OFDM symbol immediately preceding the symbol configured for use with the PSFCH and the last symbol configured for SL in the slot serve as guard symbols (see, e.g., [TS38211] §8.3.4.2.2). An SL resource pool that can be used for SL-PRS transmission but cannot be used for SL data transmission is called an SL-PRS dedicated resource pool. In an SL-PRS dedicated resource pool, the last symbol configured for SL in the slot serves as a guard symbol (see, e.g., [TS38211] §8.4.1.6.3). Alternatively, the OFDM symbol immediately following the last symbol used for PSSCH, PSFCH, or S-SSB serves as a guard symbol (see, for example, [TS38211] §§8.3.1.5 and 8.3.2.3).

[0076] Two SL resource allocation schemes for SL-PRS are supported: Scheme 1 and Scheme 2. In Scheme 1, SL-PRS resource allocation is provided by the NW (e.g., NG-RAN 404 schedules transmission resources), and the UE 402 is in RRC_CONNECTED state to transmit the SL-PRS. In Scheme 2, the UE 402 determines the SL-PRS transmission resources in a resource pool, and the UE 402 can transmit the SL-PRS regardless of the RRC state the UE 402 is in when it is within NG-RAN coverage and when it is out of NG-RAN coverage. Furthermore, the UE autonomously selects transmission resources from the resource pool.

[0077] 1.3.1. NR Sidelink Positioning Reception An NRSL positioning capable UE 402 configured by higher layers to receive SL-PRS performs the following actions if the conditions for NR SL positioning operation defined in [TS38331] §5.8.2 (see e.g., Section 1.3.3 below) are met:

[0078] If the frequencies used for NR SL positioning are included in the sl-FreqInfoToAddModList of the RRCReconfiguration message or in the sl-FreqInfoList included in the SIB; and if UE402 is configured with sl-RxPool and / or sl-PRS-RxPool included in the RRCReconfiguration message using reconfigurationWithSync (e.g., handover): configure lower layers to monitor the SL control information and the corresponding SL-PRS using the pool of resources indicated in sl-RxPool and / or sl-PRS-RxPool. Otherwise, if the cell selected for NR SL positioning provides SIB23: configure lower layers to monitor the SL control information and the corresponding SL-PRS using the pool of resources indicated in sl-RxPool and / or sl-PRS-RxPool in SIB23.

[0079] If the frequencies used for NR SL positioning are not included in the sl-FreqInfoToAddModList of the RRCReconfiguration message or in the sl-FreqInfoList included in the SIB, configure lower layers to monitor SL control information and the corresponding SL-PRS using the pool of resources preconfigured in sl-RxPool and / or sl-PRS-RxPool of the SL-PreconfigurationNR as defined in [TS38331] §9.3.

[0080] 1.3.2.NR Sidelink Positioning Transmission An NR SL positioning capable UE 402 configured by higher layers to transmit SL-PRS performs the following actions when the conditions for NR SL positioning operation defined in [TS38331] §5.8.2 (see e.g., Section 1.3.3 below) are met:

[0081] If the frequency used for NR SL positioning is included in the sl-FreqInfoToAddModList of sl-ConfigDedicatedNR in the RRCReconfiguration message or in sl-PosConfigCommonNR in SIB23:

[0082] If the UE is RRC_CONNECTED and is using a frequency included in the sl-ConfigDedicatedNR in the RRCReconfiguration message:

[0083] If the UE is configured with sl-ScheduledConfig: T310 or T311 is running for MCG; and sl-PRS-TxPoolExceptional or sl-TxPoolExceptional is included in the sl-FreqInfoList for the relevant frequency in SIB23 or in sl-ConfigDedicatedNR in RRCReconfiguration; If T301 is being executed and the cell from which the UE initiated the re-establishment of the RRC connection provides a SIB23 containing an sl-PRS-TxPoolExceptional or sl-TxPoolExceptional for the relevant frequency; Or if T304 is performed for MCG and the UE is configured with sl-PRS-TxPoolExceptional or sl-TxPoolExceptional included in sl-ConfigDedicatedNR for the relevant frequency in RRCReconfiguration: Configure lower layers to perform SL resource allocation method 2 based on random selection using the resource pool indicated by sl-PRS-TxPoolExceptional or sl-TxPoolExceptional as defined in [TS38321]. Otherwise, configure lower layers to perform SL resource allocation method 1 for NR SL positioning. If T311 is being performed, configure lower layers to release the resources indicated by rrc-ConfiguredSidelinkGrant (if present).

[0084] If the UE is configured with sl-UE-SelectedConfig: The results of full sensing are not available according to [TS38214] for the relevant frequencies selected and included in sl-ConfigDedicatedNR in RRCReconfiguration if allowed by sl-PosAllowedResourceSelectionConfig on resources configured in sl-PRS-TxPoolSelectedNormal or by sl-AllowedResourceSelectionConfig on resources configured in sl-TxPoolSelectedNormal; If an sl-TxPoolExceptional or sl-PRS-TxPoolExceptional is included in the RRCReconfiguration for the relevant frequency, or if the PCell provides a SIB25 containing an sl-TxPoolExceptional or sl-PRS-TxPoolExceptional in the sl-FreqInfoList: Configure lower layers to perform SL resource allocation method 2 based on random selection using the pool of resources indicated by the sl-TxPoolExceptional or sl-PRS-TxPoolExceptional as defined in [TS38321];

[0085] Otherwise, if sl-PRS-TxPoolSelectedNormal or sl-TxPoolSelectedNormal for the relevant frequency is included in sl-ConfigDedicatedNR in RRCReconfiguration: configure lower layers to perform SL resource allocation method 2 based on resource selection operations in accordance with sl-PosAllowedResourceSelectionConfig (as defined in [TS38321] and [TS38214]) using the pool of resources indicated by sl-PRS-TxPoolSelectedNormalNormal for the relevant frequency, or based on resource selection operations in accordance with sl-AllowedResourceSelectionConfig (as defined in [TS38321] and [TS38214]) using the pool of resources indicated by sl-TxPoolSelectedNormal for the relevant frequency;

[0086] If the UE is not RRC_CONNECTED and / or does not use the frequencies included in sl-ConfigDedicatedNR in the RRCReconfiguration message:

[0087] If the cell selected for NR SL positioning transmission provides SIB23: If SIB23 contains sl-PosTxPoolSelectedNormal for the frequency in question and the result of full sensing is that the resource selected and configured in sl-PRS-TxPoolSelectedNormal is allowed by sl-PosAllowedResourceSelectionConfig and available according to [TS38214], or is a random selection, allowed and selected by sl-PosAllowedResourceSelectionConfig: configures lower layers to perform SL resource allocation method 2 based on resource selection behavior according to sl-PosAllowedResourceSelectionConfig using the pool of resources indicated by sl-PosTxPoolSelectedNormal for the relevant frequency, as defined in [TS38214];

[0088] If SIB23 contains sl-PosTxPoolSelectedNormal for the frequency in question and the result of full sensing is that the resources selected and configured in sl-TxPoolSelectedNormal are allowed by sl-AllowedResourceSelectionConfig and available according to [TS38214], or are randomly selected, if allowed by sl-AllowedResourceSelectionConfig: configures lower layers to perform SL resource allocation method 2 based on resource selection behavior according to sl-AllowedResourceSelectionConfig using the pool of resources indicated by sl-TxPoolSelectedNormal for the relevant frequency, as defined in [TS38214];

[0089] Otherwise, if SIB23 contains sl-PRS-TxPoolExceptional or sl-TxPoolExceptional for the relevant frequency: from the moment the UE initiates RRC connection establishment until it receives RRCReconfigurationincludingsl-ConfigDedicatedNR and / or receives RRCRelease or RRCReject; or if the result of full sensing is allowed by sl-PosAllowedResourceSelectionConfig on the resources selected and configured in sl-PRS-TxPoolSelectedNormal, or allowed by sl-AllowedResourceSelectionConfig on the resources selected and configured in sl-TxPoolSelectedNormal for the relevant frequency in SIB23 and are not available according to [TS38214]: configure lower layers to perform SL resource allocation scheme 2 based on random selection (as defined in [TS38321]) using the pool of resources indicated by sl-PRS-TxPoolExceptional or sl-TxPoolExceptional for the relevant frequency.

[0090] If the frequency used for NR SL is not included in the sl-FreqInfoToAddModList in the sl-ConfigDedicatedNR in the RRCReconfiguration message or is not included in the sl-PosConfigCommonNR in SIB23, configure the lower layers to perform SL resource allocation method 2 based on the resource selection operation according to the sl-PosAllowedResourceSelectionConfig (as defined in [TS38321] and [TS38214]) using the pool of resources indicated by the sl-PRS-TxPoolSelectedNormal in the SL-PosPreconfigurationNR for the corresponding frequency, or based on the sl-AllowedResourceSelectionConfig (as defined in [TS38321] and [TS38214]) using the pool of resources indicated by the sl-TxPoolSelectedNormal in the SidelinkPreconfigNR for the corresponding frequency.

[0091] Requirements for NR Sidelink Communication / Discovery / Positioning Operation The UE 402 performs NR SL communication / positioning operations if the following conditions are met: (i) The serving cell of the UE 402 is appropriate (RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED); and the selected cell on the frequency used for NR SL communication / discovery / positioning operations belongs to a registered or equivalent PLMN as specified in 3GPP TS 24.587 or 3GPP TS 24.554, or the UE 402 is out of coverage of the frequency used for NR SL communication / discovery / positioning operations as defined in 3GPP TS 38.304 and 3GPP TS 36.304; (ii) The serving cell (RRC_IDLE or RRC_CONNECTED) of the UE 402 meets the conditions for supporting NR SL communication / discovery / positioning in limited service states as defined in 3GPP TS 23.287; and the serving cell is on a frequency used for NR SL communication / discovery / positioning operations, or the UE 402 is out of coverage of a frequency used for NR SL communication / discovery / positioning operations as defined in 3GPP TS 38.304 and 3GPP TS 36.304; or (iii) When UE 402 does not have a serving cell (RRC_IDLE).

[0092] 1.4. Ranging-based Services Ranging-based services provide distances between multiple UEs 402 and / or the direction of one UE 402 (e.g., a target UE 402t) from another UE 402 (e.g., a SL reference UE 402) via PC5 operations. Furthermore, ranging-based services include applications that utilize distances between multiple UEs 402 and / or the direction of one UE 402 from another UE 402. In a three-dimensional (3D) context, the direction includes at least a horizontal direction (or horizontal component) and an elevation direction (or vertical component). Ranging-based services are applicable to various verticals, such as consumer, smart home, smart city, smart transportation (including (semi-)autonomous land, water, and air vehicles), smart retail, and Industry 4.0. Some ranging-based services may require distance measurement, direction measurement, or both distance and direction measurement. Ranging can be supported with or without 5G coverage.

[0093] 3 illustrates an example of ranging between UEs 402 (e.g., UE 402-1 and UE 402-2) in coverage 300, out of coverage 302, or partial coverage 301. Both licensed and unlicensed spectrum can be used for ranging. In some implementations, when licensed spectrum is used, it is entirely under operator control.

[0094] In some scenarios, it may be beneficial to determine the distance between multiple UEs 402 and / or the direction of one UE 402 from another UE 402 via a direct communication connection. Functional requirements related to ranging-based services are discussed herein and in [TS22261] §6.37. See Table 7.9-1 of [TS22261] for performance requirements for ranging-based services in various scenarios. Example KPIs and key attributes for ranging are shown in Table 1.4-1. [Table 2]

[0095] 1.5. Sidelink Positioning and Ranging Methods SLPR methods based on SL signals include SL Round Trip Time (SL-RTT) positioning, SL Angle of Arrival (SL-AoA) positioning, SL Time Difference of Arrival (SL-TDOA) positioning, SL Time of Arrival (SL-TOA) positioning, and SL Relative Time of Arrival (SL-RTOA) positioning. SLPR methods may be supported in SL target UE-based or SL target UE-assisted / server-based modes, where "server" may be the SL server UE 402 or LMF 470. Table 1.5-1 indicates which of these versions are supported in this version of the SLPR method specification. [Table 3]

[0096] The SL-RTT positioning method uses SL Rx-Tx time difference measurements (and optionally SL-PRS-RSRP and / or SL-PRS-RSRPP) of SL signals received at the target UE 402t from one or more peer UEs 402 (e.g., anchor UEs 402) and SL Rx-Tx time difference measurements (and optionally SL-PRS-RSRP and / or SL-PRS-RSRPP) performed at one or more peer UEs 402 (e.g., anchor UEs 402) of SL signals transmitted by the target UE 402t. The SL Rx-Tx time difference measurements performed by a pair of UEs 402 can determine the distance / range between the pair of UEs 402. The distance / range measurements between the target UE 402t and multiple peer UEs 402 can be used to determine the location of the target UE 402t relative to the location of the peer UEs (e.g., anchor UEs 402). The operation of the SL-RTT positioning method is described in [TS38305] §8.15.2.

[0097] In some examples, the SL-RTT positioning method utilizes SL Rx-Tx time difference measurements performed by a pair of UEs 402 (e.g., a target UE 402t and an anchor UE 402). Both UEs 402 measure the Rx-Tx time difference using the SL-PRS transmitted and received by the pair of UEs 402. The SL Rx-Tx time difference measurements performed by the pair of UEs 402 determine the RTT between the UEs 402, which can be converted into a range estimate for the UEs 402. For SL-RTT, the pair of UEs 402 can transmit and receive the SL-PRS once (also referred to as "one-sided RTT") or multiple times (also referred to as "two-sided RTT"). In some examples, the UE 402 can report multiple SL Rx-Tx time difference measurements for the same SL-PRS transmission and up to four different SL-PRS receptions, or multiple SL Rx-Tx time difference measurements for the same SL-PRS reception and up to four different SL-PRS transmissions, or both.

[0098] The SL-AoA positioning method uses SL AoA measurements (and optionally SL-PRS-RSRP and / or SL-PRS-RSRPP) of SL signals received at a target UE 402t from one or more peer UEs 402 (e.g., anchor UEs 402) and SL AoA measurements (and optionally SL-PRS-RSRP and / or SL-PRS-RSRPP) performed at one or more peer UEs (e.g., anchor UEs 402) for SL signals transmitted by the target UE 402t. The SL AoA measurements performed by the UEs 402 for SL signals transmitted by the peer UEs 402 determine azimuth and vertical angles (e.g., directions) between the pair of UEs 402 relative to a reference direction (e.g., geographic north and / or other geographic direction). The direction measurements between the target UE 402t and multiple peer UEs 402 can be used to determine the position of the target UE relative to the position of the peer UEs 402 (e.g., anchor UEs 402). The operation of the SL-AoA positioning method is described in [TS38305] §8.15.3.

[0099] The SL-TDOA positioning method uses SL-RSTD (and optionally SL-PRS-RSRP and / or SL-PRS-RSRPP) of SL signals received at a target UE 402t from multiple peer UEs 402 (e.g., anchor UEs 402). The target UE 402t measures SL-RSTD (and optionally SL-PRS-RSRP and / or SL-PRS-RSRPP) of the received SL signals transmitted by multiple peer UEs 402. The SL-RSTD measurements between the target UE 402t and multiple peer UEs 402 can be used to determine the location of the target UE 402t relative to the location of the peer UE 402 (e.g., anchor UE 402). The operation of the SL-TDOA positioning method is described in [TS38305] §8.15.4.

[0100] In some examples, the SL-TDOA positioning method uses SL-RSTD measurements of SL-PRS signals received at a target UE 402t from multiple peer UEs 402 (e.g., anchor UEs 402). The target UE 402t measures the SL-RSTD of the received SL-PRS signals transmitted by the multiple peer UEs 402. The location of the target UE is estimated based on the SL-RSTD measurements and knowledge of the geographic coordinates of the peer UEs 402 (e.g., anchor UEs 402) and their relative SL timing.

[0101] The SL-TOA positioning method uses the SL-RTOA (and optionally the SL-PRS-RSRP and / or SL-PRS-RSRPP) of SL signals transmitted by a target UE 402t and received by multiple peer UEs 402 (e.g., anchor UEs 402). The peer UEs 402 measure the SL-RTOA (and optionally the SL-PRS-RSRP and / or SL-PRS-RSRPP) of the SL signals transmitted by the target UE 402. The SL-RTOA measurements performed at the multiple peer UEs 402 can be used to determine the location of the target UE 402t relative to the location of the peer UE 402 (e.g., anchor UE 402). The operation of the SL-TOA positioning method is described in [TS38305] §8.15.5.

[0102] In some examples, the SL-TOA positioning method utilizes SL-RTOA measurements performed at multiple peer UEs 402 (e.g., anchor UEs 402). The target UE 402t transmits the SL-PRS, and the peer UEs 402 (e.g., anchor UEs 402) measure the SL-RTOA relative to their own time base. The target UE's location is estimated based on the SL-RTOA measurements and knowledge of the geographic coordinates of the peer UEs 402 (e.g., anchor UEs 402) and their relative SL timing.

[0103] 2. Network, system, and device configuration and layout 4 illustrates an example of a network architecture 400. Network 400 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G / NR systems. However, the exemplary embodiments are not limited in this regard, and the described examples may be applied to other networks that would benefit from the principles described herein, such as future 3GPP systems, WiMAX systems, GSMA systems, WiFi systems, etc.

[0104] The network 400 includes a UE 402, which is any mobile or non-mobile computing device designed to communicate over a wireless connection with a RAN 404. The UE 402 is communicatively coupled to the RAN 404 by a Uu interface, which is applicable to both LTE and NR systems. Examples of UE 402 include smartphones, tablet computers, wearable devices (e.g., smart watches, fitness trackers, smart glasses, smart clothing / fabrics, head-mounted displays, smart shows, etc.), desktop computers, workstations, laptop computers, servers, in-vehicle infotainment systems, in-vehicle entertainment systems, instrument clusters, head-up display (HUD) devices, augmented reality (XR) devices (e.g., including augmented reality, virtual reality (VR), and / or mixed reality), on-board diagnostic devices, dashboard mobile devices, mobile data terminals, electronic engine management systems, engine management systems, electronic / engine control units / modules, embedded systems, sensors, microcontrollers, control modules, networked appliances, machine-to-machine (M2M), Internet of Things (IoT) devices, smart appliances, flying drones or unmanned aerial vehicles (UAVs), ground drones or autonomous vehicles, robots, digital signs, single-board computers (SBCs) (e.g., Raspberry Pi, Arduino, Intel, etc.), and the like. The UE 402 may include, but is not limited to, any type of computing device, such as a UE (such as an Edison), a plug computer, and / or any of those described herein. In some examples, the UE 402 may include a desktop computer. The UE 402 may be the same as or similar to any of the other UEs described herein, such as, for example, the UE 702, hardware resources 800, and / or the like.

[0105] In some examples, the network 400 includes a set of UEs 402 directly coupled to one another via a ProSe, PC5, SR5, or sidelink (SL) interface, which includes communication between the plurality of UEs 402 using 3GPP techniques without passing through a network node, where the SL interface includes, for example, one or more SL logical channels (e.g., an SL broadcast control channel (SBCCH), an SL control channel (SCCH), an SL traffic channel (STCH)), one or more SL transport channels (e.g., an SL shared channel (SL-SCH) and an SL broadcast channel (SL-BCH)), and one or more SL physical channels (e.g., a physical SL shared channel (PSSCH), a physical SL control channel (PSCCH), a physical SL feedback channel (PSFCH), a physical SL broadcast channel (PSBCH), etc.). The UE 402 may perform blind decoding attempts of the SL channel / link in accordance with various examples herein.

[0106] In some examples, the UE 402 may communicate with the AP 406 via an over-the-air (OTA) connection. The AP 406 manages the WLAN connection between the UE 402 and the AP 406, consistent with any IEEE 802 protocol (e.g., IEEE 802.11, etc.). Additionally, the UE 402, the RAN 404, and the AP 406 may utilize cellular WLAN aggregation / integration (e.g., LWA / LWIP), which may help offload some or all network traffic from the RAN 404.

[0107] The RAN 404 includes one or more network access nodes (NANs) 414 (also referred to as “access network nodes,” “RAN nodes,” etc.). The NANs 414 terminate the air interface for the UE 402 by providing access stratum protocols, including RRC, PDCP, RLC, MAC, and PHY / L1 protocols. In this manner, the NANs 414 enable data / voice connectivity between the CN 440 and the UE 402. The NANs 414 may be macrocell base stations or low-power base stations, or some combination thereof, to provide femtocells, picocells, or other similar cells that have a smaller coverage area, lower user capacity, or higher bandwidth compared to macrocells. In these implementations, the NANs 414 may be referred to as BSs, gNBs, RAN nodes, eNBs, ng-eNBs, NodeBs, RSUs, TRPPs, etc. The RAN 404 may have an NG-RAN architecture, as described in 3GPP TS38.401.

[0108] The RAN 404 (or NAN 414) may provide an air interface over a licensed or unlicensed spectrum. To operate in the unlicensed spectrum, a node may use LAA, eLAA, and / or feLAA mechanisms based on CA techniques with PCells / SCells. Before accessing the unlicensed spectrum, the node may perform a medium / carrier sensing operation, for example, based on a listen-before-talk (LBT) protocol.

[0109] The set of NANs 414 are coupled to each other via their respective Xn interfaces. The Xn interface, in some examples, may be separated into a control / user plane interface, allowing the NANs 414 to communicate information related to handover, data / context transfer, mobility, load management, interference coordination, etc. The NANs 414 may each manage one or more cells, cell groups, component carriers (CCs), etc., to provide the UE 402 with a radio interface for network access. The UE 402 may simultaneously connect to a set of cells provided by the same or different NANs 414, which may be provided by the RAN 404 or different RANs 404. For example, the UE 402 and the RAN 404 may use carrier aggregation (CA) to enable the UE 402 to connect to a set of CCs, each corresponding to a primary cell (Pcell) or a secondary cell (Scell). The NG-RAN 404 supports multi-radio DC (MR-DC) operation. Here, the UE 402 is configured to utilize radio resources provided by two different schedulers located in at least two different NG-RAN nodes 414 connected via a non-ideal backhaul, one NG-RAN node 414 providing NR access and the other NG-RAN node 414 providing either E-UTRA or NR access. Further details of MR-DC operations, including conditional PSCell addition (CPA) and conditional PSCell change (CPC), are described in 3GPP TS 36.300 (“[TS36300]”), [TS38300], and 3GPP TS 37.340.

[0110] Each UE 402 may be configured to measure or collect radio information and provide the radio information to one or more NANs 414. The radio information may be in the form of one or more measurement reports and / or may include, for example, signal strength measurements, signal quality measurements, and / or the like. Each measurement report may be tagged with a timestamp and the location of the measurement (e.g., the current location of the UE 402). For example, the UE 402 may perform a reference signal (RS) measurement and reporting procedure to provide information to the NW regarding the quality of one or more radio channels and / or the general communication medium, which information can be used to optimize various aspects of the communication system. Additionally or alternatively, each UE 402 may be configured to perform or collect measurements for positioning, including DL, UL, and / or SL measurements for positioning, in accordance with various aspects described herein. By way of example, measurement and reporting procedures performed by UE 402 may include 3GPP TS38.211 ("TS38211"), 3GPP TS38.212 ("TS38212"), 3GPP TS38.213 ("TS38213"), 3GPP TS38.214 ("TS38214"), 3GPP TS38.215 ("TS38215"), 3GPP TS38.101-1 ("TS38101-1"), 3GPP TS38.104 ("TS38104"), 3GPP TS38.113 ("TS38113"), 3GPP TS38.133 ("TS38133"), 3GPP TS38.331 (“[TS38331]”), and / or the like.The physical signals and / or reference signals may include demodulation reference signals (DM-RS), phase-tracking reference signals (PT-RS), positioning reference signals (PRS), channel-state information reference signals (CSI-RS), synchronization signal blocks (SSB), primary synchronization signals (PSS), secondary synchronization signals (SSS), sounding reference signals (SRS), etc.Examples of measurements performed / collected by an individual UE 402 and / or included in a measurement report may include one or more of the following: angle of arrival (AoA), accumulated delta range (ADR), additive white Gaussian noise (AWGN), average noise plus interference (ANPI), bandwidth (BW), bit error rate, bit error ratio (BER), block error rate (BLER), carrier-to-interference plus noise ratio (CINR), channel interference measurements, channel load measurements, channel occupancy ratio (CR), channel busy ratio (CBR), cell load, cross link interference (CLI)), CLI-RSSI, CSI-RSRP, CSI-RSRQ, CSI-SINR, Data Rate, DLPRS-RSRP, DLPRS-RSRPP, DLRSCP, DLRCPD, DLRSTD, DL Timing Drift, Energy per Bit to Noise Power Density Ratio (E. b / N0), energy-to-interference power density ratio per chip (E c / I0), energy-to-noise power density ratio per chip (E c / N0), end-to-end (e2e) delay, GNSS carrier phase measurement, GNSS code measurement, GNSS timing of cell frame for UE positioning, GNSS carrier phase measurement, IEEE802.11WLAN RSSI, jitter, delay, network load, number of interrupts, out-of-order delivery, packet loss rate, packet error ratio (PER), packet reception rate (PRR), peak-to-average power ratio (PAPR), peak data rate, power histogram measurement, PSBCH-RSRP, PSSCH-RSRP, PSCCH-RSRP, received channel power indicator (RCPI), received interference power measurement, reference signal carrier phase (RSCP), RSCP difference (RSCPD), received signal code power, received signal to noise indicator (RSNI), received signal strength indicator (RSSI)), reference signal time difference (RSTD), reference signal antenna relative phase (RSARP), reference signal received power (RSRP), RSRP per branch (RSRPB), reference signal received path power (RSRPP), reference signal received quality (RSRQ), reference signal (RS)-SINR, round trip time (RTT), (UE and / or RAN node) Rx-Tx measurements, (UE and / or RAN node) Rx-Tx time difference subframe offset, secondary synchronization signalSynchronization signal (SSS) transmit power, SFN and frame timing difference (SFTD), signal-to-noise ratio (SNR), signal-to-noise and interference ratio (SINR), signal-plus-noise-plus-distortion to noise-plus-distortion (SINAD) ratio, SLAoA, SLCR, SLCBR, SL PRS-CR, SL PRS-CBR, SL PRS-RSRP, SL PRS-RSRPP, SL-RSRP, SL-RSRPP, SLRSSI, SL PRS-RSSI, SL-RSTD, SLRx-Tx measurements, SLRTOA, SS-RSARP, SS-RSRP, SS-RSRQ, SS-SINR, SS-RSRPB, Station (STA) statistics, transmit power, thermal noise power measurements, time domain channel properties (TDCP), Timing Advance, UL AoA, UL RSCP, UL SRS-RSRP, UL SRS-RSRPP, UL RTOA, and / or other similar measurements. Other measurements, such as those described in [TS36214], [TS38215], 3GPP TS38.314 ("TS38314"), 3GPP TS28.552 ("TS28552"), 3GPP TS32.425 ("TS32425"), IEEE 802.11, and / or the like, may additionally or alternatively be used. Additionally or alternatively, any of the foregoing measurements (or combinations of measurements) may be collected by one or more NANs 414 and / or other network nodes.

[0111] In some examples, the UE 402 can measure physical (DL, UL, and / or SL) signals using its Rx capabilities, for example, by using its radio frequency (RF) front-end, digital baseband processing, and measurement algorithms (and using measurement configurations) to gather information about the characteristics of the signals. In these examples, the UE 402's RF front-end receives signals transmitted by other network nodes (e.g., the NAN 414 and / or other UEs 402 participating in SL communications). The received signals are downconverted to baseband or an intermediate frequency suitable for digital processing. The downconverted signals are sampled and converted from analog to digital by the UE 402's analog-to-digital conversion (ADC) circuitry, resulting in a digital representation of the received signal. The digital signals are processed by the UE's baseband processor (see, e.g., processor 910 in FIG. 9 ), which includes tasks such as filtering, synchronization, equalization, and demodulation, to extract useful information from the received signals. The UE 402 performs channel estimation by estimating various channel characteristics (e.g., path loss, fading, interference, etc.) based on the received signal and / or reference signals transmitted by neighboring UEs 402 and / or the NAN 414. Using the estimated channel characteristics, the UE 402 calculates measurements, such as any of the measurements described herein and / or other metrics that characterize the quality of the received signal. The UE 402 can then report the measured parameters to the NW or neighboring UEs 402 using configured resources and / or as described elsewhere herein.

[0112] As previously mentioned, the NG-RAN 404 provides a 5G-NR air interface (e.g., Uu interface) with the following characteristics: variable SCS, CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL, polar, repetition, simplex, and Reed-Muller codes for control, and LDPC for data. The 5G-NR air interface may rely on CSI-RS and PDSCH / PDCCH DMRS, similar to the LTE air interface. The 5G-NR air interface may not use CRS, but may use PBCH DMRS for PBCH demodulation, PTRS for PDSCH phase tracking, and tracking reference signals for time tracking. The 5G-NR air interface may operate in the FR1 band, which includes sub-6 GHz bands, or the FR2 band, which includes the 24.25 GHz to 52.6 GHz bands. The 5G-NR air interface may include SSB, which is a region of the downlink resource grid that includes PSS / SSS / PBCH. The 5G-NR air interface may utilize BWPs for various purposes. For example, BWPs can be used for dynamic SCS adaptation. For example, a UE 402 can be configured with multiple BWPs, each with a different SCS for each BWP configuration. When a BWP change is instructed to the UE 402, the SCS for transmission also changes. Another use case for BWPs is related to power saving. In particular, multiple BWPs with different amounts of frequency resources (e.g., PRBs) can be configured for the UE 402 to support data transmission in different traffic load scenarios. A BWP with a smaller number of PRBs can perform data transmission with a smaller traffic load while enabling power savings for the UE 402 and possibly the gNB 414a. A BWP with a larger number of PRBs can be used in scenarios with a higher traffic load.

[0113] The NG-RAN 404 can utilize one or more positioning methods to determine the location of the UE 402. Positioning the UE 402 (e.g., determining the location of the UE 402) involves two primary operations: signal measurement and position estimation, and optional velocity calculation based on the measurements. Signal measurements can be performed by the UE 402 and / or the serving ng-eNB 414b or gNB 414a. The primary signals measured for terrestrial positioning methods are typically LTE or NR radio transmissions. However, other methods can utilize other transmissions, such as common radio-navigation signals, including those from global navigation satellite systems (GNSS). The positioning function is not limited to a single method or measurement; other available and appropriate methods and measurements can be used to meet the service needs of the location service (LCS) client 480. This additional information can include readily available E-UTRAN or NG-RAN measurements. Position estimation calculations can be performed by the UE 402 and / or the LMF 470. The UE positioning method using SL may be used to obtain absolute position, relative position, or ranging information when the UE 402 is inside or outside of NG-RAN coverage.

[0114] The RAN 404 is communicatively coupled to the CN 440, which includes network elements and / or network functions (NFs) for providing various functions to support data and telecommunication services to customers / subscribers (e.g., UEs 402). The components of the CN 440 may be implemented on a single physical node or on separate physical nodes. In some examples, NFV may be used to virtualize any or all of the functions provided by the network elements of the CN 440 onto physical compute / storage resources, such as servers, switches, etc. A logical instantiation of the CN 440 is referred to as a network slice, and a logical instantiation of a portion of the CN 440 is referred to as a network sub-slice.

[0115] In the example of FIG. 4, CN 440 is a 5GC 440 that includes an Authentication Server Function (AUSF) 442, an Access and Mobility Management Function (AMF) 444, a Session Management Function (SMF) 446, a User Plane Function (UPF) 448, a Network Slice Selection Function (NSSF) 450, a Network Exposure Function (NEF) 452, a Network Repository Function (NRF) 454, a Policy Control Function (PCF) 456, a Unified Data Management (UDM) 458, a Unified Data Repository (UDR), an Application Function (AF) 440, and a Network Data Analytics Function (NWDAF) 462 coupled together via various interfaces as shown in the figure. Various aspects of the various NFs in 5GC 440 are discussed in more detail in '719 and [TS23501], among many other 3GPP standards / specifications. Although not shown in FIG. 4, system 400 may also include NFs not shown, such as, for example, any of those discussed in [TS23501].

[0116] The data network (DN) 436, in at least some examples, is a network hosting data-centric services, such as operator services, the Internet, third-party services, or enterprise networks. In some examples, the DN 436 includes one or more service networks belonging to an operator or a third party, which are provided as services to clients or UEs 402. Additionally or alternatively, the DN 436 is provided by one or more servers, including, for example, an application (app) / content server 438, an edge server and / or edge computing node, a cloud computing service, etc. The DN 436 can be an operator-external public or private packet data network (PDN), or an intra-operator PDN, for example, for the provision of IMS services. In this example, the app server 438 can be coupled to the IMS via an S-CSCF or I-CSCF. In some implementations, the DN 436 can represent one or more local-area DNs (LADNs), which are DNs (or DN names (DNNs)) accessible by UEs 402 in one or more particular areas. Outside of these specific regions, the UE 402 cannot access the DN / DN 436. Additionally or alternatively, the DN 436 may be an edge DN 436, which is a (local) DN that supports an architecture for enabling edge applications. In these examples, the application server 438 may represent a physical hardware system / device that provides application server functionality and / or application software that resides in the cloud or on an edge computing node that performs server functionality. In some examples, the application / content server 438 provides an edge hosting environment that provides the support necessary to run an edge application server.

[0117] In some examples, the 5GS may use one or more edge computing nodes to provide an interface and offload processing of wireless communication traffic. In these examples, the edge computing node may be included in or coexist with one or more RANs 404 or RAN nodes 414. For example, the edge computing node may provide connectivity between the RAN 404 and the UPF 448 in the 5GC 440. The edge computing node may process the wireless connection between the RAN 404 and the UPF 448 using one or more NFV instances instantiated on a virtualization infrastructure in the edge computing node. The edge computing node may include or be part of an edge system employing one or more edge computing technologies (ECTs) (also referred to as an "edge computing framework" or the like). The edge computing node may also be referred to as an "edge host" or "edge server." The edge system includes a collection of edge servers and an edge management system (not shown) necessary to run edge computing applications within an operator network or a subset of an operator network. An edge server is a physical computer system, which may include an edge platform and / or virtualization infrastructure, that provides compute, storage, and network resources for edge computing applications. Each edge server is located at the edge of a corresponding access network and is arranged to provide computing resources and / or various services (e.g., computational task and / or load offloading, cloud computing capabilities, IT services, and other similar resources and / or services described herein) in relative proximity to UEs 402. The VIs of the edge computing nodes provide virtualized environments and virtualized resources for edge hosts, and edge computing applications can run as VMs and / or application containers on the VIs.Examples of usable edge computing frameworks / ECTs and service deployment examples are described in '719.

[0118] The interfaces of the 5GC 440 include reference points and service-based interfaces. A reference point is, at least in some examples, the joining point between two non-overlapping functional groups, elements, or entities. The reference points of the 5GC 440 include N1, N2, N3, N4, N5, N6, N7, N8, N9, N10, N11, N12, N13, N14 (between two AMFs 444; not shown), N15, N16, and N22. Other reference points not shown in Figure 4 may also be used, any of which are discussed in [TS23501]. The service-based representation in Figure 4 represents an NF in the control plane that allows other authorized NFs to access services. A service-based interface (SBI) is, at least in some examples, an interface through which an NF can access the services of one or more other NFs. In some implementations, a service-based interface is an API-based interface (e.g., HTTP / 2, RESTful, SOAP, and / or other APIs or web services) that can be used by an NF to invoke a particular service or service operation. SBIs in 5GC440 include Namf, Nsmf, Nnef, Npcf, Nudm, Naf, Nnrf, Nnssf, and Nausf. Other service-based interfaces not shown in Figure 4 (e.g., Nudr, N5g-eir, Nudsf) can also be used, any of which are discussed in [TS23501].

[0119] Figure 5 shows an example of a UE positioning architecture sp00 applicable to NG-RAN. The UE positioning architecture sp00 is a 5GS architecture applicable to positioning of a UE 402 via NR and / or E-UTRA access. The positioning architecture sp00 also supports the NR PC5 interface. SL positioning can be supported when the UE 402 is within NG-RAN coverage (e.g., UE 402-A and UE 402-B) and when the UE 402 is outside NG-RAN coverage (e.g., UE 402-C, UE 402-D, etc.).

[0120] The AMF 444 receives a request for some location services associated with a particular target UE from another entity (such as a GMLC or a UE), or the AMF 444 itself decides to initiate some location services on behalf of a particular target UE 402t (e.g., in the case of an IMS emergency call from the UE 402). This is described in 3GPP TS 23.502 (“TS23502”) and 3GPP TS 23.273 (“TS23273”). The AMF 444 sends a location service request to the LMF 470. The LMF 470 processes the location service request. The request may include the transfer of assistance data to the target UE to assist in UE-based and / or UE-assisted positioning, and / or may include positioning of the target UE 402t. The LMF 470 then sends the results of the location services (e.g., a position estimate for the UE 402) back to the AMF 444. In the case of a location service requested by an entity other than the AMF 444 (e.g., the GMLC 472 or the UE 402), the AMF 444 returns the results of the location service to this entity.

[0121] The LMF 470 may have a characteristic signaling connection to an Enhanced Serving Mobile Location Center (E-SMLC) 515 that allows the LMF 470 to access information from the E-UTRAN (e.g., to support observed time difference of arrival (OTDOA) for E-UTRA positioning methods using downlink measurements obtained by the target UE of signals from eNBs and / or PRS-only TPs in the E-UTRAN). The details of the signaling interaction between the LMF 470 and the E-SMLC 515 may be defined in an appropriate specification / standard, may be implementation specific, and / or may involve proprietary signaling.

[0122] The LMF 470 may have its own signaling connection to the SUPL Location Platform (SLP) 510. The SLP 510 is the Secure User Plane Location (SUPL) entity responsible for positioning on the user plane. For details about user plane positioning, see Secure User Plane Location Architecture, Approved Version 2.0, Open Mobile Alliance (OMA), OMA-AD-SUPL-V2_0 (April 17, 2012), and User Plane Location Protocol Approved, Approved Version 2.0.6, Open Mobile Alliance (OMA), OMA-TS-ULP-V2_0_6 (August 4, 2020). The details of the signaling interaction between the LMF 470 and the SLP 510 may be defined in the appropriate specification / standard, may be implementation-specific, and / or may include proprietary signaling.

[0123] Individual NG-RAN nodes 414 can control one or more TRPs / transmission points (TPs), such as remote radio heads (RRHs) to support a PRS-based terrestrial beacon system (TBS) or DL-PRS-only TPs. In the case of a split gNB architecture, the gNB-DU can include the TRP functionality, which can support TP, RP, or both TP and RP functionality. The gNB-DU containing the TRP functionality does not need to provide cell service.

[0124] The gNB 414a provides measurement information for the target UE 402t and communicates this information to the LMF 470. To support NR RAT-dependent positioning, the gNB 414a can measure the target UE 402t's radio signals and provide the measurement results for position estimation. The gNB 414a can serve several TRPs, including, for example, RRHs, UL-SRS-only RPs, and DL-PRS-only TPs. For non-terrestrial networks (NTNs), the TRPs can be located on satellites. Additionally or alternatively, the gNB 414a can broadcast assistance data information received from the LMF 470 in positioning system information messages.

[0125] The ng-eNB 414b provides measurement results for position estimation, making measurements of the target UE 402t's radio signals and communicating these measurements to the LMF 470. The ng-eNB 414b makes measurements upon request (on-demand or periodically) from the LMF 470. The ng-eNB 414b can provide several TPs, including, for example, RRH and PRS-only TPs for PRS-based TBS positioning for E-UTRA. The ng-eNB 414b can broadcast assistance data information received from the LMF in positioning system information messages.

[0126] The UE 402 may make measurements of downlink signals from the NG-RAN 404, SL signals from other sources such as other UEs 402, E-UTRAN, different GNSS and TBS systems, WLAN access points, Bluetooth beacons, UE barometric and motion sensors, etc. The measurements made are determined by the selected positioning method.

[0127] The UE 402 may include an LCS application or may access an LCS application through communications with a network accessed by the UE 402 or through another application resident on the UE 402. This LCS application may include the measurement and calculation functionality necessary to determine the location of the UE with or without network assistance, which is beyond the scope of this specification.

[0128] The UE 402 may, for example, include independent positioning capabilities (such as GPS) and therefore be able to report its location independently of NG-RAN transmissions. UEs with independent positioning capabilities may also utilize assistance information obtained from the network.

[0129] In the 3GPP 5GS control plane solution defined in [TS23501], [TS23502], and [TS23273], the UE 402 is the target device and the LMF 470 is the server. In support of SUPL 2.0, the SUPL Enabled Terminal (SET) is the target device and the SLP 510 is the server. Operations controlled by the LPP are further described in [TS38305] Section 7.1.

[0130] A positioning reference unit (PRU) at a known location can perform positioning measurements (e.g., RSTD, RSRP, UE Rx-Tx time difference measurements, DL-RSCPD, DL-RSCP, etc.) and report these measurements to a location server. Additionally, the PRU can transmit an SRS to enable the TRP to measure and report UL positioning measurements (e.g., RTOA, UL-AoA, gNB Rx-Tx time difference, UL-RSCP, etc.) from the PRU at a known location. The location server can compare the PRU measurements with expected measurements at the known PRU location to determine correction terms for other nearby target devices. DL and / or UL position measurements for other target devices can be corrected based on previously determined correction terms. PRU measurements can also be provided to the target device in assistance data, as described in [TS38305] §8.12. From the location server's perspective, the PRU functionality is realized by the UE 402 using its known location.

[0131] The SL positioning protocol (SLPP) and / or ranging / SL positioning protocol (RSPP) are exchanged over the PC5-U reference point between UEs 402 (e.g., target UE 402t, anchor UE 402, server UE 402) and manage RSP sessions among a group of UEs 402. SLPP is also exchanged between the target UE 402t and the LMF 470 to support SL positioning. In this case, SLPP messages are transported as transparent PDUs over intermediate network interfaces using an appropriate protocol (e.g., NGAP over the NG-C interface, NAS / RRC over the NR-Uu interface). SLPP enables SLPR using multiple different positioning methods while separating the details of a specific positioning method from the details of the underlying transport. SLPP is used point-to-point between endpoints (e.g., a server and a target) to obtain absolute position, relative position, or ranging information of the target UE 402t using SL measurements obtained by one or more reference sources (see, e.g., [TS38355], [TS38305], and [TS23273]).

[0132] SLPP sessions are used between UEs 402 or between the UE 402 and the LMF 470 to fulfill RSP service requests and / or to obtain location-related measurements based on NRPC5 radio signals, for location estimation, or to transfer assistance data. A single SLPP session is used to support a single location request (LR) (e.g., in the case of a single SL-mobile terminated (MT)-LR or SL-mobile originated (MO)-LR). Multiple SLPP sessions can be used between the same endpoints to support multiple different location requests (see, e.g., [TS23273]). A UE 402 can participate in multiple SLPP sessions simultaneously.

[0133] Each SLPP session consists of one or more SLPP transactions, each performing a single operation (e.g., capabilities exchange, assistance data transfer, location information transfer, etc.). SLPP transactions are implemented as SLPP procedures. The initiator of an SLPP session initiates the first SLPP transaction, but subsequent transactions can be initiated by either side (or endpoint). SLPP transactions within a session can occur serially or in parallel. SLPP transactions are indicated at the SLPP protocol level using transaction identifiers (IDs) to correlate messages (e.g., requests and responses). Messages within a transaction are linked by a common transaction ID and / or session ID.

[0134] For UE-only operation, the SLPP session initiator, which is the endpoint that receives the LCS request (or SLPP request), initiates the SLPP session by sending an SLPP message containing the assigned (SLPP) session ID to the other endpoint. All configuration messages within the session contain the same session ID. In a UE-only scenario, the (SLPP) session ID is used to identify all SLPP transactions belonging to the SLPP session. This allows the UE 402 to uniquely distinguish SLPP messages of one session from SLPP messages of other sessions.

[0135] For operations involving an LMF, a session ID is assigned by the target UE 402t and included in SLPP messages used for communication between UEs 402. The (SLPP) session ID may be included in SLPP messages for communication between the target UE 402t and the LMF 470. When an LMF is involved, the (SLPP) session ID is assigned by the SL target UE 402t and used in SLPP messages exchanged between groups of UEs 402. Additionally or alternatively, when an LMF is involved, the SLPP session ID is optionally included in SLPP messages forwarded between the SL target UEs and the LMF 470.

[0136] SLPP operates on a transaction basis between UEs 402 and between the UE 402 and the LMF 470, with each transaction occurring as an independent procedure as described in [TS38355]. Multiple such procedures may be in progress at any time. SLPP procedures may include request / response message pairs or one or more "unsolicited" messages. Each procedure has a single purpose (e.g., transfer of assistance data, exchange of SLPP-related capabilities, target device positioning / ranging according to some QoS, and use of one or more SL positioning methods, and / or the like). Multiple procedures can be used in series or in parallel to achieve more complex purposes (e.g., target device positioning in conjunction with transfer of assistance data and exchange of SLPP-related capabilities).

[0137] Each SLPP transaction involves the exchange of one or more SLPP messages between at least two endpoints. The general format of an SLPP message includes a set of common fields followed by a body. The body (which may be empty) contains information specific to the particular message type. Each message type contains information specific to one or more positioning methods (e.g., SL-TDOA, SL-TOA, SL-AoA, and / or SL-RTT) and / or information common to all positioning methods. By way of example, fields common to some or all SLPP messages include: Session ID (which identifies messages belonging to the same session); Transaction ID (which identifies messages belonging to the same transaction); Transaction End Flag (which indicates when a transaction (e.g., one indicating periodic responses) has ended); Sequence Number (which allows the receiver to detect duplicate SLPP messages); and Acknowledgement (ACK) (which allows acknowledgment to be requested and / or returned for any SLPP message). By way of example, the following SLPP message types can be defined: Request Capability; Provide Capability; Request Assistance Data; Provide Assistance Data; Request Location Information; Provide Location Information; Abort; and Error.

[0138] FIG. 10 shows an example of an SLPP session procedure 1000 that can be performed by endpoints A and B. The SLPP session procedure 1000 can be used to support an SLPP session that includes a series of SLPP transactions. The SLPP session procedure 1000 includes an operation 1001, in which endpoint A is the endpoint that receives the LCS / SLPP request and initiates the SLPP session by sending an SLPP message to the other endpoint B that includes a session ID assigned to a first SLPP transaction j (transaction ID=j). In operation 1002, endpoints A and B exchange further messages to continue the transaction initiated in operation 1001. Each of these messages includes transaction ID=j. In operation 1003, either endpoint can initiate further transactions by sending additional SLPP messages (e.g., with transaction ID=k). In operation 1004, the session is terminated with a final transaction N in which SLPP messages are exchanged between both endpoints (e.g., for transaction ID=N).

[0139] Within the same session, all configuration messages contain the same session ID within each transaction, and all configuration messages also contain the same transaction ID. The last message sent in each transaction contains the IE endTransaction set to "TRUE". Transactions occurring in parallel use different transaction IDs. The transaction ID of a completed transaction can be reused any time after it is known that the last message of the previous transaction with the same ID has been received. Furthermore, the messages described in connection with FIG. 10 can be any type of SLPP message, such as request / provide capabilities messages, request / provide assistance data messages, request / provide location information messages, abort messages, and / or error messages.

[0140] The Capabilities message can be used during the SLPP Capabilities Transfer procedure. Capabilities in the SLPP context refer to capabilities supporting different SLPP / SLPR positioning methods (e.g., SL-RTT, SL-TDOA, SL-AoA, SL-TOA, SL-RSTD, SL-RSRP, SL-RSRPP, SL-Rx-Tx Time Difference, SL-RTOA), various aspects of a particular positioning method (e.g., different types of measurements or assistance data), and common features not specific to a single positioning method. The exchange of capabilities between different endpoints can be initiated by a request or sent as unsolicited information (e.g., no request). In the example of Figure 10, if the Request method is used, endpoint A sends an SLPP RequestCapabilities message to endpoint B with a request for capability information, and endpoint B responds by sending an SLPP OfferCapabilities message to endpoint A. The SLPP OfferCapabilities message contains or indicates the capabilities (positioning methods) supported by endpoint B. Capabilities may represent a specific positioning method or may be common to multiple positioning methods.

[0141] The Assistance Data message can be used during the SLPP Assistance Data Transfer procedure. The Assistance Data can contain SL-PRS information (e.g., SL-PRS Sequence ID, measurement reports, etc.) or location calculation information (e.g., SL anchor UE location information, etc.) and can be transferred requested or unsolicited. Additionally or alternatively, examples of assistance data that may be transferred between endpoints include assistance information common to all positioning methods (e.g., an application layer ID identifying the UE 402 as defined in [TS23287], an SL-PRS sequence ID as defined in [TS38211], an antenna reference point (ARP) ID identifying the SL-PRS Tx ARP associated with the UE 402, anchor UE position coordinates, and SL-PRS Tx ARP position coordinates), SL-RTT assistance information (e.g., common assistance information), SL-AoA assistance information (e.g., common assistance information and expected AoA uncertainty), SL-TDOA assistance information (e.g., common assistance information and synchronization information between anchor UEs), and / or SL-TOA assistance information (e.g., common assistance information and synchronization information between anchor UEs).

[0142] In the example of Figure 10, if the Request method is used for the SLPP Assistance Data transfer procedure, endpoint A can send an SLPP Request Assistance Data message to endpoint B indicating that Assistance Data is required, and endpoint B responds by sending an SLPP Provide Assistance Data message to endpoint A. The SLPP Provide Assistance Data message contains or indicates the Assistance Data requested by endpoint A. In some examples, endpoint B can transfer the additional Assistance Data to endpoint A in one or more additional SLPP messages.

[0143] The Location Information message can be used during the SLPP Location Information Transfer procedure. The term "location information" applies to both the actual location estimate and the values ​​used to calculate the location (e.g., SL-PRS measurements, etc.). Location information can be delivered in response to a request or unsolicited. In the example of Figure 10, if the request method is used, endpoint A can send an SLPP Request Location Information message to endpoint B indicating the type of location information required and the associated QoS (if any). In response, endpoint B forwards the requested location information to endpoint A in an SLP Provide Location Information message. If necessary (e.g., if requested in step 1), endpoint B can forward additional location information to endpoint A in one or more additional SLPP messages.

[0144] Examples of location request information that may be transferred between endpoints include location request information common to all positioning methods (e.g., requested location information type (e.g., position estimate, position measurement, range estimate, range measurement), periodic reporting criteria, positioning QoS (e.g., desired horizontal / vertical accuracy, desired range accuracy, response time, speed request), environmental information (e.g., expected multipath and non-line of sight (NLOS) in the current area), scheduled position time, requested measurement information (e.g., LOS-NLOS indicator request, SL-PRS-RSRP request, first pass SL-PRS-RSRPP request, and additional pass request)), SL-RTT location information (e.g., ARP information request, timing quality request, multiple SL-PRS Rx-Tx time difference request, and / or associated SL-PRS The location request information may include: SL-AoA location information (e.g., common location request information with additional required measurement information including a Tx timestamp request), SL-TDOA location information (e.g., common location request information with additional required measurement information including an ARP information request and an SL timing quality request), and / or SL-TOA location information (e.g., common location request information with additional required measurement information including an ARP information request and an SL timing quality request).

[0145] Additionally or alternatively, examples of location result information that may be transferred between endpoints include SL-RTT location result information (position estimate, range estimate, velocity estimate, SL-RTT measurement information (e.g., LOS-NLOS indicator, ARP ID, SL-PRS resource ID, SL-PRS Rx-Tx time difference measurement, SL-PRS-RSRP measurement, SL-PRS first-pass RSRPP measurement, additional path measurement, measurement timestamp, measurement timing quality, and SL-PRS Tx time information)), SL-AoA location result information (position estimate, direction estimate, velocity estimate, SL-AoA measurement information (e.g., LOS-NLOS indicator, measurement angle quality, additional path angle measurement, azimuth / elevation measurement, azimuth / elevation LCS to GCS conversion parameters, ARP ID, SL-PRS resource ID, SL-PRS-RSRP measurement, SL-PRS first-path RSRPP measurement, additional path measurement, and measurement timestamp), SL-TDOA position result information (position estimate, velocity estimate, SL-TDOA measurement information (e.g., LOS-NLOS indicator, ARP ID, SL-PRS resource ID, SL-PRS-RSRP measurement, SL-PRS first-path RSRPP measurement, additional path measurement, measurement timestamp, and measurement timing quality), and SL-TOA position result information (position estimate, velocity estimate, SL-TDOA measurement information (e.g., LOS-NLOS indicator, SL-TOA measurement, ARP ID, SL-PRS resource ID, SL-PRS-RSRP measurement, SL-PRS first-path RSRPP measurement, additional path measurement, measurement timestamp, and measurement timing quality), etc.).

[0146] Error messages can be used during the SLPP error handling procedure, which is used by a receiving endpoint (e.g., endpoint B) to notify a sending endpoint (e.g., endpoint A) that an SLPP message sent by the sending endpoint (e.g., endpoint A) is in error or unexpected.

[0147] The Abort message can be used during the SLPP Abort procedure, which is used by one endpoint to notify another endpoint to abort an ongoing SLPP procedure (or SLPP session) between the two endpoints. For example, during an ongoing SLPP procedure between endpoints A and B in Figure 10, if endpoint B determines that the procedure needs to be aborted, it sends an SLPP Abort message to endpoint A, holding the transaction ID of the procedure.

[0148] SLPP procedures do not need to be performed in a fixed order to allow for greater positioning flexibility. Even with the flexibility allowed by SLPP, in some instances, SLPP procedures may be performed in the following order: (1) Transfer of Capabilities; (2) Transfer of Assistance Data; and (3) Transfer of Location Information (measurements and / or location estimates).

[0149] Figure 6 shows an example network-assisted SL positioning architecture 600A and an example Location Services (LCS) reference architecture 600B in a reference point representation. Figure 7 shows an example reference architecture 700 for SLPR-based services.

[0150] 6 and 7 include, among other elements discussed below, a positioning UE 402l, an anchor UE 402a, and / or PRU 402p, a target UE 402t, a RAN 404, various NFs, a Location Management Function (LMF) 470, a Gateway Mobile Position Center (GMLC) 472, a Location Search Function (LRF) 474, and an LCS client 480. Aspects of SLPR are described in [TR38845] and [TS23273]. Network-assisted SL positioning allows the target UE 402t to obtain its location relative to the positioning UE 402l and the location of the positioning UE 402l.

[0151] The various UEs 402 described herein and illustrated by Figures 1-6 may be 5G ProSe-capable UEs (5PUEs) that support 5G ProSe requirements, operations, and related procedures as described in 3GPP TS 23.304 ("TS23304") and 3GPP TS 23.303 ("TS23303"). In some examples, the 5PUEs 402 can operate as 5G ProSe UE-to-UE relays and / or as 5G ProSe UE-to-Network relays that provide functionality to support connectivity to NWs and / or DNs 436 for one or more 5G ProSe remote UEs. In some examples, the SLPR mechanisms described herein can include ProSe Direct Discovery (including Model A and Model B discovery) and various procedures described in [TS23586] and / or the like. Additionally or alternatively, the SLPR server 498 of FIG. 7 may be or operate as a ProSe application (app) server 438, as described in [TS23304] and / or [TS23303].

[0152] The access network (e.g., RAN 404) is responsible for handling various SL positioning procedures (e.g., including the SL positioning methods discussed herein), including positioning the target UE 402t, providing location-related information not associated with a specific target UE 402t, and forwarding positioning messages between the AMF 444 or LMF 470 and the target UE 402t. The access network supports determining position estimates in geographic and / or local coordinates as defined in [TS23032]. LCS-specific functions of RAN elements are specified in [TS38305] of the NG-RAN 404.

[0153] The AF 460 and NF can access LCS services from a GMLC 472 within the same trust domain (e.g., within the same PLMN) using the Ngmlc interface, or access Event Exposure using location information from an AMF 444 within the same trust domain using the Namf interface. The NWDAF 462 collects UE location information by directly accessing the GMLC 472. The LCS client 480 can access LCS services from a GMLC 472 (e.g., H-GMLC) using the Le reference point. The external AF 460 can access LCS services from an NEF 452 using the Nnef interface or the CAPIF API. CAPIF and related API provider domain functions are specified in [TS23222]. The LCS client 480 or AF 460 can access LCS services from the UE 402 over a user plane connection for periodic or triggered 5GC-MT-LR location event reporting by the UE 402 when the UE can determine a location estimate.

[0154] The GMLC 472 contains the functionality necessary to support LCS. There may be multiple GMLCs 472 in one PLMN. The GMLC 472 is the first node that an external LCS client accesses within the PLMN (e.g., the Le reference point is supported by the GMLC 472). The AF 460 and NF can access the GMLC 472 directly or through the NEF 452. The GMLC 472 may request routing information and / or target UE 402t privacy information from the UDM 458 via the Nudm interface. After performing authorization of the external LCS client 480 or AF 460 and verifying the target UE 402t privacy, the GMLC 472 forwards the location request to the serving AMF 444 using the Namf interface or, in the case of a roaming UE 402, to a GMLC 472 in another PLMN using the Ngmlc interface. The target UE's 402t privacy profile setting is always checked in the UE's home PLMN before delivering a location estimate.

[0155] The LRF 474 can be collocated with the GMLC 472 or separate from the GMLC 472. The LRF 474 obtains or verifies location information and provides routing and / or correlation information for the UE 402 that initiated the IMS emergency session. This information is provided by the LRF 474 to the E-CSCF (see, e.g., 3GPP TS 23.167).

[0156] The LMF 470 manages the overall coordination and scheduling of resources required for the location of UEs registered with or accessing the 5GCN 440. It can also calculate or verify final position and velocity estimates and estimate the accuracy achieved. The LMF 470 receives location requests for target UEs 402t from the serving AMF 444 using the Nlmf interface. The LMF 470 interacts with the UE to exchange location information applicable to UE-assisted and UE-based positioning methods, and interacts with the NG-RAN 404, N3IWF, or TNAN to obtain location information.

[0157] The LMF 470 determines the positioning result in geographic coordinates as defined in [TS23032] and / or local coordinates as defined in [TS23032]. If requested and available, the positioning result may also include the velocity of the UE 402. The coordinate type is determined by the LMF 470 when receiving a position request based on the LCS client type and supported GAD shapes. If the position request indicates a regulatory LCS client type, the LMF 470 determines the geographic location and, if necessary, the local coordinate location. If the position request indicates a value-added LCS client type, the LMF 470 can determine the UE location in local coordinates, geographic coordinates, or both. If a supported GAD shape is not received or if the local coordinates are not included in the supported GAD shape, the LMF 470 determines the geographic location. Some RAT-independent positioning methods (such as GNSS-based positioning methods) can only determine the UE location in geographic coordinates. In such a case, the LMF 470 can convert the UE location in geographic coordinates to a location in local coordinates if the origin of the local coordinates has a known global coordinate. If the origin of the local coordinates does not have a known global coordinate, the UE location in local coordinates cannot be determined using a positioning method that can only determine the UE location in geographic coordinates.

[0158] Additional functions performed by the LMF 470 to support location services include: supporting a single location request received from the serving AMF 444 of the target UE 402t; supporting periodic or triggered location requests received from the serving AMF 444 of the target UE 402t; determining the type and number of positioning methods and procedures based on UE and PLMN capabilities, QoS, UE connection state per access type, LCS client type, coordinate type, and optionally service type, and an indication that reliable UE location information is required; reporting UE location estimates directly to the GMLC 472 for periodic or triggered location of the target UE 402t; supporting cancellation of periodic or triggered location of the target UE 402t; broadcasting assistance data to the UE via the NG-RAN 404 in encrypted or unencrypted format. and forwarding encryption keys to subscribing UEs via the AMF 444; supporting changing the serving LMF 470 for periodic or triggered position reporting of the target UE 402t; supporting receiving stored UE positioning capabilities from the AMF 444 and providing updated UE positioning capabilities to the AMF 444; mapping the UE location to geographical areas where PLMN operation is allowed or not allowed based on a request from the AMF 444; supporting determining the UE location at scheduled position times; determining whether to use the user plane or the control plane for positioning; supporting processing of periodic or triggered position 5GC-MT-LR, 5GC-NI-LR, 5GC-MO-LR, and delayed 5GC-MT-LR via the user plane connection between the UE 402 and the LMF 470; supporting collection of GNSS assistance data from the AF;and / or support service-level PRU association (e.g., PRU association is the association of a PRU 402p with an LMF 470 by providing PRU-related information to the LMF 470), PRU association update, or PRU disassociation (e.g., the LMF 470 supports verification of association or disassociation initiated by a PRU by checking whether there is a PRU verified instruction from the AMF 444, the LMF 470 stores the received PRU information included in the service-level PRU association message, the LMF 470 can indicate support for PRU functionality to the NRF via an NF profile and can further send PRU information to the NRF via an NF profile update, and the LMF 470 can request the PRU 402p to associate with a new LMF 470 by returning the routing ID of the new LMF 470); Supports the selection of a PRU 402p based on stored PRU information when it is necessary to obtain location measurements from the PRU 402p to assist in location; supports obtaining PRU location measurements as described in [TS38305] §5.4.5 by triggering the procedure of [TS23273] §6.11; supports obtaining PRU location measurements from other PRU serving LMFs 470 (e.g., as the serving LMF 470 of the target UE 402t, supports the discovery and selection of other PRU serving LMFs 470 by querying the NRF and supports requesting PRU location measurements from the selected LMF 470; as the serving LMF 470 of the PRU 402p, supports providing PRU location measurements to the other LMFs 470 after receiving a request from the other LMF 470); supports determining the UE location taking into account the obtained PRU location measurements;Supports requests for user plane reports from the UE to the LCS client 480 or AF 460 for periodic or triggered 5GC-MT-LR, and then supports forwarding of accumulated event reports from the target UE 402t to the H-GMLC 472 and the LCS client 480 or AF 460 via the control plane, and supports any requests for assistance data received in the accumulated event reports; and determines the UE location of UEs connected to the MBSR based on the location and velocity of the MBSR and the timing of the location estimates of the target UE 402t and the MBSR.

[0159] In addition to the functions defined in [TS23273], the LMF 470 supports the following functions: network-based SL positioning and network-assisted SL positioning: triggering RSP, exchanging RSP capabilities, exchanging RSP assistance data, and exchanging RSP signal measurement data / results; supporting receiving stored RSP capabilities from the AMF 444 and providing updated RSP capabilities to the AMF 444; determining the RSP method based on the positioning QoS requirements and / or the UE's RSP capabilities; determining the required QoS for designated UE positioning; optionally determining the same scheduled positioning time for RSP and positioning of the designated UE 402 if no scheduled positioning time exists; determining the location of the target UE 402t based on ranging / SL positioning measurement data or results reported by the target UE 402t and the location of the designated UE 402; and interacting with the GMLC 472 to obtain the location of the designated UE 402l / SL reference UE 402 using the application layer ID; and delivering an RSP service request / response for ranging service expose to the UE 402.

[0160] The RSP service request can be initiated by a UE 402 (e.g., SL positioning client UE 402, target UE 402t, SL reference UE 402, etc.), a 5GC NF, an LCS client 480, or an AF 460. If direct RSP between the SL reference UE 402 and the target UE 402t cannot be supported, RSP between the SL reference UE 402 and the target UE 402t over the PC5 interface can use the assistance of another UE 402.

[0161] The RSP service request includes identifiers of multiple UEs 402. If the service publication is done via the 5GC 440, the GMLC 472 converts the identifier of the target UE (e.g., in the RSP service request) into a subscription permanent identifier (SUPI). If the service publication is done via the PC5 or 5GC user plane, the identifier can be an RSP application-specific application layer ID.

[0162] The RSP service request may also include the required QoS, the required location result (e.g., absolute location, relative location or distance, and / or direction relative to the UE 402, as defined in [TS23586] §4.4). Additionally or alternatively, the RSP service request may include periodic or trigger event parameters, such as the time interval between successive location reports and the total number of reports, a trigger event, the period of the event report, the minimum and maximum time interval between successive event reports, the maximum event sampling interval, whether a location estimate is included in the event report, and whether only one or multiple location reports are required. By way of example, trigger events may be: the relative location / distance between at least one pair of UEs for a specified UE is less than a threshold; the relative location / distance between at least one pair of UEs for a specified UE is greater than a threshold; the relative location / distance between all UEs is less than a threshold; and / or the relative location / distance between all UEs is greater than a threshold.

[0163] In addition to the functionality defined in [TS23273], the GMLC 472 supports the following functions: enabling trusted AFs and NFs to perform MT-LR by directly accessing the GMLC 472 using additional service parameters in the RSP; enabling AFs 460 and NFs to perform MT-LR by accessing the GMLC 472 via the NEF 452 using additional service parameters in the RSP; determining the serving AMF instance of the UE 402 included in the RSP request and forwarding the request to the respective serving AMF 444; receiving responses and event reports from the AMF 444 and returning the RSP results to the NF and AF 460; and performing application layer ID to GPSI or GPSI to application layer ID resolution by querying the NEF 452.

[0164] In addition to the functions described herein and in [TS23501], the AMF 444 includes functionality to manage the positioning of target UEs 402t for all types of location requests. The AMF 444 has access to the GMLC 472 and NEF 452 via the Namf interface, to the RAN 404 via the N2 reference point, and to the UE 402 via the N1 reference point. Functions performed by the AMF 444 to support location services include: initiating a NI-LR location request for the UE 402 using an IMS emergency call or knowing the UE's geographical area using NR satellite access for PLMN selection validation; receiving and managing 5GC-MT-LR and delayed 5GC-MT-LR location requests from the GMLC 472 for periodic, triggered, and UE-enabled location events; receiving and managing 5GC-MO-LR location requests from the UE; receiving and managing location event publication requests from the NEF 452; selecting the LMF 470; receiving updated privacy requirements from the UE and forwarding them to the UDR 459 via the UDM 458. sending; supporting cancellation of periodic or triggered location reporting for the target UE402t; supporting changing the serving LMF470 for periodic or triggered location reporting for the target UE402t; if assistance data is broadcast by 5GS in encrypted form, the AMF444 receives an encryption key from the LMF470 and forwards it to appropriately subscribed UEs402 using mobility management procedures; storing the UE positioning capability received from the LMF470 and sending the UE positioning capability together with the received location request to the LMF470; receiving a UL NAS transport including a PRU association, association update, or disassociation request (contained in an LCS supplementary service message) from the UE402; the AMF444 can verify whether the UE can function as a PRU402p based on the UE subscription data after receiving the PRU association request, association update, or disassociation.The AMF444 may also use local policies to determine whether a UE can function as a PRU402p; send a PRU association request or a PRU disassociation request to the LMF470 and include a UE validation indication indicating whether the UE is authorized to function as a PRU402p; support triggering the LMF470 to establish a user plane connection to the UE if the UE requests it; store in the UE context that the UE maintains a user plane connection with a particular LMF470 (details of the UE positioning function are defined in 3GPP TS37.355); support local configuration of a mapping table of UE identifier ranges and LMF470 identifiers, or query the UDM458 for the UE's LMF470 identifier for 5GC-MO-LR; and / or support handover from 5G to EPS by providing a target MME ID to the GMLC472 as part of the LCS service response.

[0165] In addition to the functionality described herein and in [TS23501], the UDM 458 contains LCS subscriber and LCS privacy profile and routing information. The UDM 458 is accessible from the AMF 444, GMLC 472, or NEF 452 via the Nudm interface. The UDM 458 may also contain an indication of whether the UE 402 is authorized to function as a PRU 402p as part of the UE subscription data. The UDM 458 may also contain an LMF identifier for the UE LCS subscription data. In addition to the functionality described herein and in [TS23501], the UDR 459 contains privacy data information for the target UE 402t and may be updated with new privacy information received from the UE 402 by the serving AMF 444 via the UDM 458.

[0166] In addition to the functionality described herein and in [TS23501], the NEF 452 provides a means to access location services by an external AF 460 or an internal AF 460. The AF 460 uses an API to access location services from the NEF 452. Depending on the QoS requirements, the NEF 452 can either forward the location request to the GMLC 472 or request event publication of location information from the serving AMF 444 (optionally via the UDM 458). If event publication via the AMF 444 is used, the NEF 452 may request routing information and / or target UE privacy information from the UDM 458 via the Nudm interface. Additional functions performed by the NEF 452 to support location services include: supporting location requests from the AF for immediate location and delayed periodic and triggered location events; supporting publishing location information to the AF 460 based on the location request; supporting the decision of the GMLC 472 or AMF 444 based on QoS requirements, type of location request, etc. from the AF 460; selecting the serving AMF 444 for the target UE 402t when there are multiple serving AMFs 444; deciding whether to attempt a second location request for the target UE 402t from another AMF 444 when the location information returned from the first AMF 444 does not meet the QoS requirements and there are multiple serving AMFs 444; and supporting the GMLC 472 or AMF 444 decision from the AF 460. Supports provisioning of LCS privacy profiles; supports pausing and canceling periodic or triggered location requests; supports accepting LCS requests from the AF 460; supports rejecting LCS requests from the AF 460, for example, if the number of target UEs 402 in the LCS request exceeds the maximum number of target UEs for such client; supports assigning a reference number to each location request from the AF 460 for LDR. In some examples, the GMLC 472 or AMF 444 is determined based on QoS requirements, and if the QoS requirements include multiple QoS classes, the GMLC 472 or AMF 444 determination is based on the most stringent (e.g., primary) QoS requirement.

[0167] SLPR-based services are supported based on the architecture of FIG. 7 using the following reference points: The SR1 reference point is between the UE SLPR function 492 and the SLPR server 498 of the UE 402. The SR1 reference point can be used for configuration, application layer signaling, etc. The SR5 reference point is between the individual SLPR functions 492 of each UE 402. The SR5 reference point is carried over the PC5 interface / reference point (e.g., SR5 can be over the PC5-RRC, PC5-D, PC5-U, and / or PC5-S reference points). The PC5 reference point is between the individual UEs 402 and also supports various SLPR operations. When the UE 402 is in coverage, in addition to the related functions defined in [TS23501] (and / or described herein), the N1 interface / reference point can also be used to carry SLPR policies (SLPRPs) (e.g., including service authorizations) from the AMF 444 to the UE 402 and to carry UE 402 capabilities from the UE 402 to the AMF 444. If the LMF 470 supports SLPR-based services, it can also be used to carry signaling between the UE and the LMF 470, as defined in [TS23273]. In addition to the related functions defined in [TS23501] (and / or described herein) for the N2 interface / reference point, if SLPR-based services are supported by the NG-RAN 404, the N2 interface / reference point can also be used to carry SLPRPs and parameters (e.g., including service authorizations) from the AMF 444 to the NG-RAN 404. The Uu interface / reference point is between each UE 402 and the NG-RAN 404. In addition to the related functionality defined in [TS23273] (and / or described herein) for the NL10 interface / reference point, in the case of RSP services, it is used by the LMF 470 to obtain the location of the designated UE 402l and / or reference UE 402 from the GMLC 472 using the application layer ID.

[0168] Furthermore, there are the following service-based interfaces for SLPR-based services: In addition to the associated services defined in [TS23273] (and / or described herein), if the LMF 470 supports an SLPR-based service, it may use the Nlmf interface to provide services to other NFs associated with it. In addition to the associated services defined in [TS23501] (and / or described herein) for the Nudm interface, for SLPR-based services, the services provided by the UDM 458 are used to obtain the associated subscription information to the AMF 444 during the initial registration procedure and / or during the UE Configuration update (UCU) procedure to notify that the AMF 444 subscription information has changed. In addition to the related services defined in [TS23501] (and / or described herein) for the Npcf interface, in the case of SLPR-based services, in roaming scenarios, the services provided by the Home PCF 456 (H-PCF) are used to provide SLPR service-related parameters to the Visiting PCF 456 (V-PCF) of the UE 402 and the NG-RAN 404. In addition to the related services defined in [TS23501] (and / or described herein) for the Nudr interface, in the case of SLPR-based services, the services provided by the UDR 459 are used to notify the PCF 456 and UDM 458 of updates to SLPR-based service-related information. In addition to the associated services defined in [TS23501] (and / or described herein) for the Namf interface, in the case of SLPR-based services, the services provided by the AMF 444 are consumed by the PCF 456, which provides the SLPR-based service-related parameters of the UE 402 and the NG-RAN 404 to the AMF 444, enabling the AMF 444 to create or update a UE context related to the SLPR-based service.In addition to the associated services defined in [TS23501] (and / or described herein) for the Nnef interface, in the case of an RSP service, the services provided by the NEF 452 are used by the app server 438 / yx98 to update RSP service-related information in the 5GC 440. In addition to the associated services defined in [TS23501] (and / or described herein) for the Nnrf interface, in the case of an RSP service, the services provided by the NRF 454 are used to discover PCFs 456 that support the RSP.

[0169] In the example of Figure 7, the DN 436 includes an SLPR server 498, and the UEs 402-1 and 402-2 participating in the SLPR-based service 492 are subscribed to from the same PLMN. The reference architecture 700 also supports the case where the UEs 402-1 and / or 402-2 are not registered with the network or are not in coverage. The UEs 402-3 and 402-4 may be out of coverage or have partial network coverage. For simplicity, Figure 7 shows only the target UE 402t and reference UEs (e.g., UEs 402-1, 402-2, 402-3, and 402-4); an assistant UE 402, a designated UE 402l, and an SL positioning server UE 402 may also exist. Other 5GC entities not marked with an SLPR label may still need to participate in the SLPR 492 / yx98.

[0170] The target UE 402t may perform a discovery procedure to detect any candidate anchor UEs 402a in its vicinity. This discovery procedure may rely entirely on the legacy SL PC5 discovery procedure [TS23287], 3GPP TS23.304 ("TS23304"). In this case, both Model A and Model B discovery may be applied. Additionally or alternatively, the PC5 discovery procedure may be extended to include specific information in the discovery message that assists in supporting SL positioning.

[0171] In addition to the functions defined in [TS23287] and [TS23304], any UE 402 described herein may support the following functions: reporting the following RSP capabilities to the 5GC over the N1 reference point: Ability to support RSP on PC5 (based on RSP control, an RSP-capable UE can play different roles in operation, e.g., target UE, SL reference UE, designated UE, etc.) and Ability to support SL positioning server UE 402 on PC5; RSP on PC5 procedures; NW-based SL positioning and network-assisted SL positioning procedures; UE-only SL positioning procedures; RSP service publication procedures; and indicating UE policy provisioning requests in the UE policy container for UE-triggered RSP policy provisioning, as defined in [TS23273] §4.3.5. In addition to the defined functions, it also requests one or more types of policies / parameters, such as RSP policies / parameters on PC5, designated UE 402l policies / parameters, target UE 402t policies / parameters, SL positioning client UE 402 policies / parameters, and / or SL positioning server UE 402 policies / parameters; receives RSP policies from the 5GC 440 over the N1 reference point; and configures RSP parameters over the PC5 interface (these parameters can be pre-configured in the UE 402 or, if in coverage, can be provisioned or updated by signaling from the HPLMN's PCF 456 over the N1 reference point or from the RSP application server 438 / yx98 over the SR1 reference point).

[0172] The RSP service may be exposed to an authorized SL positioning client UE 402, 5GCNF, or AF 460 to obtain relative position or distance / direction results (or position results) between multiple RSP-capable UEs 402. The RSP service may also be used by an authorized SL positioning client UE 402, 5GCNF, AF 402, or LCS client 480 to obtain the absolute position of a target UE 402t if the 5GCNF, AF 402, or LCS client 480 determines that RSP is applicable.

[0173] In the example of Figure 6, the target UE 402t can support positioning according to four different modes, including: a UE-assisted mode (e.g., the UE obtains position measurements and sends the measurements to another entity (e.g., the LMF 470) to calculate a position); a UE-based mode (e.g., the UE obtains position measurements and calculates a position estimate using assistance data provided by the serving PLMN); a standalone mode (e.g., the UE obtains position measurements and calculates a position estimate without using assistance data provided by the serving PLMN); and a network-based mode (e.g., the serving PLMN obtains position measurements of signals transmitted by the target UE 402t and calculates a position estimate). Transmission of UE signals in network-based mode may or may not be transparent to the UE 402t.

[0174] The positioning procedures / methods used by the UE 402 for NG-RAN access are described in [TS38305]. UE positioning capabilities and a limited set of UE user plane positioning capabilities can be transferred to the 5GC 440 during UE 402 registration, as described in 3GPP TS24.501 ("TS24501"). Some of these positioning capabilities can then be transferred to the LMF 470, as described in 3GPP TS29.572 ("TS29572"). The UE positioning capabilities can also be transferred directly to a location server (e.g., the LMF 470).

[0175] Additional capabilities supported by the UE 402 to support location services include one or more of the following capabilities: supporting periodic or triggered location requests received from the network for 5GC-MT-LR, 5GC-NI-LR, or delayed 5GC-MT-LR; supporting location requests to the network for 5GC-MO-LR; supporting privacy notification and validation of periodic or triggered location 5GC-MT-LR or delayed 5GC-MT-LR; sending updated privacy requirements to the serving AMF 444 (for forwarding to UDR 459 via UDM 458); supporting periodic or triggered location reporting to the LMF 470; supporting periodic or triggered location reporting; supporting changes to the serving LMF 470 for periodic or triggered location reporting. support cancellation of previously received location reports; support multiple simultaneous location sessions; support reception of unencrypted and / or encrypted assistance data broadcast by the NG-RAN; support reception of encryption keys for assistance data from the AMF 444; support processing of periodic or triggered location related 5GC-MT-LR, 5GC-NI-LR, 5GC-MO-LR, and delayed 5GC-MT-LR via a user plane connection between the UE and the LMF 470; and / or support reporting of periodic or triggered 5GC-MT-LR location events via a user plane connection to the LCS client 480 or AF 460, where periodic cumulative event reports are sent via the control plane to the LMF 470, H-GMLC 472, and LCS client 480 or AF 460.

[0176] The UE 402 may support the functionality of the PRU 402p. In addition to the functionality described herein and / or defined in [TS38305], the PRU 402p supports the following functionality: service-level association, association update, and disassociation with the serving LMF 470; the PRU 402p sends service-level association, association update, or disassociation to the LMF via LCS supplementary service messages; and supports association with multiple LMFs 470 (e.g., when the PRU is in multiple LMF overlapping service areas). The PRU information included in the PRU association or PRU association update includes one or more of the following aspects: PRU positioning capabilities and / or location information (if known). PRU disassociation refers to the process of deleting PRU-related information and disassociating the PRU 402p from the LMF 470.

[0177] The Le reference point supports location requests sent from an LCS client to the GMLC 472 or LRF 474. The Le reference point may be supported using the Mobile Location Protocol (MLP) defined by OMA. The NL3 reference point supports location requests forwarded by the HGMLC 472 to the VGMLC 472.

[0178] The N1 reference point supports the transport of supplementary service messages between the serving AMF 444 and the target UE 402t to support privacy notification and verification, and modification of UE privacy settings. The N1 reference point also supports the transport of positioning protocol messages and location event reports between the target UE 402t and the LMF 470 via the serving AMF 444. The N1 reference point supports the transfer of encryption keys from the AMF 444 to appropriately subscribed UEs so that the UEs can receive encrypted broadcast assistance data. All messages sent over the N1 reference point to support location services are encapsulated in NAS transport messages as defined in [TS24501].

[0179] The N2 reference point supports the transport of positioning messages between the LMF 470 and RAN nodes, or the N3IWF in case of untrusted non-3GPP access, via the AMF 444. The N2 reference point also supports the transport of messages from the LMF 470 to NG-RAN nodes via the AMF 444, which carries assistance data broadcast by the NG-RAN nodes. Positioning messages related to the N2 interface are defined in 3GPP TS 38.455.

[0180] The NL5 reference point supports location requests sent by the NEF 452 and / or other NFs to the GMLC 472. The NL2 reference point supports location requests sent by the GMLC 472 to the serving AMF 444 of the target UE 402t. Messages at the NL2 reference point are defined in 3GPP TS 29.518 ("[TS29518]"). The NL6 reference point supports queries from the HGMLC 472 to the UDM 458 for privacy subscription information for the target UE 402t and routing information for the target UE 402t. The N51 reference point supports queries from the NEF 452 to the serving AMF 444 for the location of the target UE 402t. Messages at the N51 reference point are defined in [TS29518].

[0181] The NL1 reference point supports location requests for a target UE 402t sent from its serving AMF 444 to the LMF 470. Location requests are supported for immediate location and delayed location for periodic or triggered location events. The NL1 reference point also supports the transfer of encryption keys and associated data from the LMF 470 to the AMF 444 to enable decryption of encrypted broadcast assistance data by appropriately subscribed UEs. Messages at the NLI reference point are defined in [TS29518] and [TS29572].

[0182] The N52 reference point supports queries from the NEF 452 to the UDM 458 for privacy subscription information of the target UE 402t and routing information of the target UE 402t. The N52 interface also supports requests from the NEF 452 to the UDM 458 to forward location requests from the NEF 452 to the serving AMF 444 of the target UE 402t.

[0183] The NL7 reference point supports location context transfer between two LMFs 470. The NL8 reference point supports the LMF 470 receiving location related analytics from the NWDAF as defined in 3GPP TS 23.288. The NL9 reference point supports location requests sent from the NWDAF to the GMLC 472.

[0184] Further, the 5GS LCS architecture 600B may include the following service-based interfaces for the LCS: Nlmf (e.g., a service-based interface represented by LMF470) and Ngmlc (e.g., a service-based interface represented by GMLC472).

[0185] 8 illustrates a wireless network 800 including a UE 802 in wireless communication with a NAN 804. The UE 802 may be the same as, similar to, and substantially interchangeable with any of the UEs described herein, such as the UE 402, hardware resources 800, etc. The NAN 804 may be the same as, similar to, and substantially interchangeable with any of the NANs described herein, such as the AP 406, NAN 414, RAN 404, and hardware resources 900, etc.

[0186] The UE 802 can be communicatively coupled to the NAN 804 via a connection 806. The connection 806 is a wireless interface that enables the communicative coupling and can be consistent with a cellular communication protocol (e.g., LTE, 5G / NR, mmWave, or sub-6 GHz frequencies, and / or any other access network protocol). The connection 806 can correspond to the Uu interface described with respect to FIG.

[0187] The UE 802 includes a host platform 808 coupled to a modem platform 810. The host platform 808 includes an application processing circuit 812 that may be coupled to a protocol processing circuit 814 of the modem platform 810. The application processing circuit 812 may execute various applications for the UE 802 that source / sink application data. The application processing circuit 812 may further implement one or more layer operations for transmitting and receiving application data to and from a data network. These layer operations include transport (e.g., user datagram protocol (UDP), Quick UDP Internet Connections (QUIC), transmission control protocol (TCP), GPRS Tunneling (GTP), and / or some other transport layer protocol) operations, and network / internet (e.g., internet protocol (IP), IPSec, routing information protocol (RIP), external gateway protocol (EGP), internet control message protocol (ICMP), internet group management protocol (IGMP), and / or some other network and / or internet layer protocol) operations. The protocol processing circuit 814 can perform one or more protocol layer operations to facilitate transmission or reception of data over the connection 806.The protocol layer operations performed by the protocol processing circuit 814 may include, for example, operations of some or all of the following layers: physical layer (PHY) (see, e.g., 3GPP TS38.201), medium access control (MAC) (see, e.g., 3GPP TS38.321), radio link control layer (RLC) (see, e.g., 3GPP TS38.322), packet data convergence protocol (PDCP) (see, e.g., 3GPP TS38.323), service data adaptation protocol (SDAP) (see, e.g., 3GPP TS37.324), radio resource control (RRC) (see, e.g., 3GPP TS38.331 (see [TS38331])), and non-access stratum (NAS) (see, e.g., 3GPP TS24.301 and / or 3GPP TS24.501).

[0188] The modem platform 810 may further include digital baseband circuitry 816 that can implement one or more layer operations that are "lower" layer operations performed by protocol processing circuitry 814 within a network protocol stack. These operations include PHY operations, including, for example, one or more HARQ functions, scrambling / descrambling, encoding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bit metric determination, multi-antenna port precoding / decoding, which may include one or more space-time, space-frequency, or spatial coding, reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, control channel signal blind decoding, and other related functions. In some examples, the protocol processing circuitry 814 includes one or more instances of control circuitry (not shown) that provides control functions for the transmit / receive components.

[0189] The modem platform 810 further includes transmit circuitry 818, receive circuitry 820, RF circuitry 822, and an RF front end (RFFE) 824, which include or connect to one or more antenna panels 826. Briefly, the transmit circuitry 818 includes digital-to-analog converters, mixers, intermediate frequency (IF) components, and / or the like; the receive circuitry 820 includes analog-to-digital converters, mixers, IF components, and / or the like; the RF circuitry 822 includes low-noise amplifiers, power amplifiers, power tracking components, and / or the like; and the RFFE 824 includes filters (e.g., surface / bulk acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), and / or the like. The selection and arrangement of the transmit circuitry 818, receive circuitry 820, RF circuitry 822, RFFE 824, and antenna panel 826 components (collectively referred to as "transmit / receive components" or "Tx / Rx components") may be specific to the details of a particular implementation, such as whether communication is at TDM or FDM, mmWave or sub-6 GHz frequencies, etc. In some examples, the transmit / receive components may be arranged in multiple parallel Tx / Rx chains, may be located within the same or different chips / modules, etc.

[0190] UE reception can be established by or through the antenna panel 826, the RFFE 824, the RF circuits 822, the receive circuits 820, the digital baseband circuits 816, and the protocol processing circuits 814. In some examples, the antenna panel 826 can receive transmissions from the NAN 804 by receive beamforming signals that are received by one or more antennas / sets of antenna elements in the antenna panel 826. UE transmission can be established by or through the protocol processing circuits 814, the digital baseband circuits 816, the transmit circuits 818, the RF circuits 822, the RFFE 824, and the antenna panel 826. In some examples, the transmit components of the UE 804 can apply spatial filters to data to be transmitted to form transmit beams that are radiated by the antenna elements in the antenna panel 826.

[0191] Similar to the UE 802, the NAN 804 includes a host platform 828 coupled to a modem platform 830. The host platform 828 may include an application processing circuit 832 coupled to the protocol processing circuit 834 of the modem platform 830. The modem platform may further include a digital baseband circuit 836, a transmit circuit 838, a receive circuit 840, an RF circuit 842, an RFFE circuit 844, and an antenna panel 846. The components of the NAN 804 are similar to and substantially interchangeable with similarly named components of the UE 802. In addition to performing data transmission and reception as described above, the components of the NAN 804 may perform various logical functions, including RNC functions such as radio bearer management, UL and DL dynamic radio resource management, and data packet scheduling. Examples of antenna elements of antenna panel 826 and / or antenna panel 846 include planar inverted-F antennas (PIFAs), monopoles, dipoles, loop antennas, patch antennas, Yagi antennas, parabolic dish antennas, omnidirectional antennas, etc.

[0192] FIG. 9 illustrates components that can read instructions from a machine-readable medium or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies described herein. Specifically, FIG. 9 illustrates a schematic diagram of hardware resources 900, including one or more processors (or processor cores) 910, one or more memory / storage devices 920, and one or more communication resources 930, each communicatively coupled via a bus 940 or other interface circuitry. In examples where node virtualization (e.g., NFV) is utilized, a hypervisor 902 can execute to provide an execution environment for one or more network slices / sub-slices for utilizing the hardware resources 900. In some examples, the hardware resources 900 can be implemented within or by individual computing nodes housed in enclosures of various form factors. In other examples, the hardware resources 900 can be implemented by multiple computing nodes located in one or more data centers and / or distributed across one or more geographic regions.

[0193] The processor 910 may include processors (or cores) 910-1 through 910-p (where p is a number). Each processor may be, for example, a central processing unit (CPU) 910, a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), a microprocessor or controller, a multi-core processor, a multi-threaded processor, a very low voltage processor, an embedded processor, an xPU, a data processing unit (DPU), an infrastructure processing unit (IPU), a network processing unit (NPU), another processor (including any of those described herein), and / or any suitable combination thereof. Each processor (or core) 910-1 through 910-p may be the same as or different from the other processors (or cores) 910-1 through 910-p.

[0194] The memory / storage device 920 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 920 may include, but is not limited to, any type of volatile memory, non-volatile memory, semi-volatile memory, and / or any combination thereof. By way of example, the memory / storage device 920 may be a random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), conductive bridge random access memory (CB-RAM), spin transfer torque (STT)-MRAM, phase change RAM (PRAM), core memory, dual in-line memory modules (DIMMs), micro DIMMs, mini DIMMs, block addressable memory devices (e.g., based on NAND or NOR technology), read only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrical EPROM (EEPROM), flash memory, non-volatile RAM (NVRAM), solid state storage, magnetic disk storage media, optical storage media, memory devices using chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single The memory device may be or include single or multi-level phase change memory (PCM) and / or switched phase change memory (PCMS), NVM devices using chalcogenide phase change materials (e.g., chalcogenide glasses), resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), antiferroelectric memory, magnetoresistive random access memory (MRAM) memory incorporating memristor technology, phase change RAM (PRAM), resistive memory including metal oxide-based, oxygen vacancy-based, and conductive bridge random access memory (CB-RAM), or spin-transfer torque (STT)-MRAM, spintronic magnetic junction memory-based devices, magnetic tunnel junction (ROM)-based devices, domain wall (DW) and spin-orbit transfer (MTJ)-based devices, thyristor-based memory devices, and / or any combination of the above memory devices and / or other memories.

[0195] Communications resources 930 may include interconnect or network interface controllers, components, or other suitable devices for communicating with one or more peripheral devices 904 or one or more databases 6 or other network elements over network 908. For example, communications resources 930 may include wired communications components (e.g., when coupled via USB, Ethernet, etc.), cellular communications components, NFC components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components, and other communications components.

[0196] The instructions 950 may include software, programs, applications, applets, apps, or other executable code for causing at least one of the processors 910 to perform any one or more of the methods described herein. The instructions 950 may reside, completely or partially, within at least one of the processors 910 (e.g., in a processor's cache memory), memory / storage 920, or any suitable combination thereof. Furthermore, any portion of the instructions 950 may be transferred to the hardware resources 900 from any combination of the peripherals 904 or database 906. Thus, the memory of the processor 910, the memory / storage 920, the peripherals 904, and the database 906 are examples of computer-readable and machine-readable media.

[0197] In some examples, peripheral device 904 may represent one or more sensors, such as, for example, exteroceptive sensors, proprioceptive sensors, and / or exo-proprioceptive sensors (e.g., sensors that capture, measure, or correlate internal and external conditions). Examples of such sensors include, among others, inertial measurement units (IMUs) including accelerometers, gyroscopes, and / or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) including 3-axis accelerometers, 3-axis gyroscopes, and / or magnetometers; level sensors; flow sensors; temperature sensors / thermistors; pressure sensors; barometric pressure sensors; weigh scales; altimeters; image sensors / cameras; light detection and ranging (LiDAR) sensors; proximity sensors; depth sensors, ambient light sensors; light sensors; ultrasonic transceivers; microphones; power, energy, and environmental (PEE) sensors; gas sensors; and the like.

[0198] Additionally or alternatively, the peripheral device 404 may be, for example, a soft actuator (e.g., an actuator that changes its shape in response to a stimulus, such as a mechanical, thermal, magnetic, and / or electrical stimulus), a hydraulic actuator, a pneumatic actuator, a mechanical actuator, an electromechanical actuator (EMA), a microelectromechanical actuator, an electrohydraulic actuator, a linear actuator, a linear motor, a rotary motor, a DC motor, a stepper motor, a servomechanism, an electromechanical switch, an electromechanical relay (EMR), a power switch, a valve actuator, a piezoelectric actuator, and / or a biomorphic, a thermal biomorphic, a solid-state actuator, a solid-state relay (SSR), a shape memory alloy based actuator, a The actuator may represent one or more actuators such as a translator, an electroactive polymer-based actuator, a relay driver integrated circuit (IC), a solenoid, an impact actuator / mechanism (e.g., jaws, claws, tweezers, clamps, hooks, mechanical fingers, humanoid dexterous robotic hands, and / or other grasping mechanisms that physically grasp an object by applying direct impact), a propulsion actuator / mechanism (e.g., wheels, axles, thrusters, propellers, engines, motors (e.g., those described above), clutches, etc.), a firing actuator / mechanism (e.g., a mechanism that launches or propels an object or element), and / or an audible sound generator, a visual warning device, and / or other similar electromechanical component.

[0199] 3. Implementation example 11 shows an example of a process 1100 performed by a target UE 402t. The process 1100 includes, in operation 1101, the target UE 402t receiving an SLPP request to measure and report SL positioning measurements. In operation 1102, the target UE 402t measures the SL PRS set based on the received request. In operation 1103, the target UE 402t transmits a measurement report. The measurement report includes positioning results based on the measurements of the SL PRS set.

[0200] The example operations of processes 1000 and 1100 may be arranged in a different order, one or more of the illustrated operations may be combined and / or separated / divided into multiple operations, illustrated operations may be omitted, and / or additional or alternative operations may be included in any of the illustrated processes. Further examples of the methods, apparatus, systems, and networks described herein include the following non-limiting implementation examples.

[0201] Each of the following non-limiting examples can stand alone or can be combined in any permutation or combination with any one or more of the other examples provided below or throughout this disclosure.

[0202] Example A01 includes a method that includes defining UE behavior and requirements when the UE performs positioning measurements on a sidelink (SL).

[0203] Example A02 includes the method of Example A01 and / or other examples herein, wherein the positioning measurements may be for round trip time (RTT) and time difference of arrival (TDoA) using a new SL positioning reference signal (PRS).

[0204] Example A03 includes the methods of Examples A01-A02 and / or other examples herein, where requirements may be defined for both PC5-only and / or PC5-Uu joint scenarios.

[0205] Example A04 includes the method of Example A03 and / or some other examples herein, where the requirements for a PC5-Uu joint scenario can be defined based on only PC5 and only Uu.

[0206] Example A05 can include the method of Examples A01-A04 and / or any other example herein, where a reporting mapping for power control of an SL-PRS can be defined.

[0207] Example A06 can include the method of Examples A01-A04 and / or any other example herein, where a reporting mapping for measured timing differences between reference signals of SL-PRS can be defined.

[0208] Example A07 includes the method of Examples A01-A06 and / or any other example herein, where the method is performed by a user equipment (UE).

[0209] Example B01 is a method of operating a target user equipment (UE), the method comprising: receiving a Sidelink Positioning Protocol (SLPP) request to measure and report Sidelink (SL) positioning measurements; measuring a set of SL positioning reference signals (PRS) based on the received request; transmitting a measurement report, the measurement report including a positioning result based on measurements of the SL PRS set; The method includes:

[0210] Example B02 includes the method of Example B01 and / or some other examples herein, where if the UE is capable of performing SL Time Difference of Arrival (TDoA) positioning, the measurements include performing SL Reference Signal Time Difference (RSTD) measurements during a measurement period according to an accuracy requirement set, and the SL RSTD measurements include measurements of a second SL PRS in the SL PRS set from a first peer UE on a target link and measurements of a second SL PRS in the SL PRS set from a second peer UE on a reference link.

[0211] Example B03 includes the method of Example B02 and / or any other example herein, wherein the method includes determining a location of the target UE relative to a first location of the first peer UE and a second location of the second peer UE.

[0212] Example B04 includes the method of Example B03 and / or any other example herein, wherein the determining step includes estimating the location of the target UE based on the SL RSTD measurements, knowledge of the geographic coordinates of the first peer UE and the second peer UE, and relative SL timing of the first SL PRS and the second SL PRS.

[0213] Example B05 includes the method of Examples B02-B04 and / or any other example herein, wherein the method includes generating a measurement report including an SL RSTD measurement value of the SL RSTD measurement based on a measurement report mapping requirement.

[0214] Example B06 includes the method of Examples B02-B05 and / or any other example herein, wherein the target link includes a PC5 interface and the reference link includes a PC5 interface or a Uu interface.

[0215] Example B07 includes the method of Examples B02-B06 and / or any other example herein, wherein the measurement of the first SL PRS is a first SL PRS reference signal received power (RSRP) measurement and the measurement of the second SL PRS is a second SL PRS-RSRP measurement.

[0216] Example B08 includes the method of Example B01 and / or some other examples herein, where when the UE is capable of performing SL TDoA positioning or SL round trip time (RTT) positioning, the measurement includes performing an SL receive (Rx)-transmit (Tx) time difference measurement during a measurement period according to an accuracy requirement set, and the SL Rx-Tx time difference measurement is based on a measurement of an SL PRS in the SL PRS set transmitted by a peer UE.

[0217] Example B09 includes the method of Example B08 and / or any other example herein, wherein the method includes determining an SL RTT measurement based on a performed SLRx-Tx time difference measurement and another SLRx-Tx time difference measurement performed at the peer UE based on an SL signal transmitted by the target UE.

[0218] Example B10 includes the method of Examples B08-B09 and / or any other example herein, wherein the method includes generating a measurement report including an SL RTT measurement value for the SL RTT measurement based on a measurement report mapping requirement.

[0219] Example B11 includes the method of Examples B09-B10 and / or any other example herein, wherein the measurements of the SL PRSs in the SL PRS set sent by the peer UE are SL PRS-RSRP measurements.

[0220] Example B12 includes the method of Example B01 and / or some other examples herein, wherein when the UE is capable of performing SL TDoA positioning, SL RTT positioning, SL Angle of Arrival (AoA) positioning, or SL Time of Arrival (TOA) positioning, the measurement includes performing SL PRS-RSRP measurements during a measurement period according to an accuracy requirement set, and the SL PRS-RSRP measurements are linear averages of one or more resource elements carrying at least one SL PRS in the SL PRS set configured for RSRP measurements within a considered measurement frequency bandwidth.

[0221] Example B13 includes the method of Examples B01-B12 and / or any other example herein, wherein the SLPP request is an SLPP Request Location Information message or an SLPP Provide Assistance Data message.

[0222] Example B14 includes the method of Examples B01-B13 and / or any other example herein, wherein the measurement report is included in an SLPP Provide Location Information message.

[0223] Example B15 includes the method of Examples B01-B14 and / or any other example herein, wherein the measurement report mapping requirements include mapping requirements for power control of the SL PRS set.

[0224] Example B16 includes the method of Examples B01-B14 and / or any other example herein, wherein the measurement report mapping requirement includes a mapping requirement for measured timing differences between reference signals of SL-PRS.

[0225] Example B17 includes the method of Examples B01-B16 and / or any other example herein, wherein the receiving includes receiving the SLPP request from a Location Management Function (LMF) or another UE.

[0226] Example Z01 includes one or more computer-readable media containing instructions, the execution of which by a processor circuit causes the processor circuit to perform the method of any of Examples A01-A07, B01-B17. Example Z02 includes a computer program containing the instructions of Example Z01. Example Z03 includes an application programming interface defining functions, methods, variables, data structures, and / or protocols for the computer program of Example Z02. Example Z04 includes an API or specification that defines or includes the use of any of Examples A01-A07, B01-B17, or portions thereof, or that relates to any of Examples A01-A07, B01-B17, or portions thereof, defining functions, methods, variables, data structures, protocols, etc. Example Z05 includes an apparatus including circuitry loaded with the instructions of Example Z01. Example Z06 includes an apparatus including circuitry operable to execute the instructions of Example Z01. Example Z07 includes an integrated circuit including one or more processor circuits of Example Z01 and one or more computer-readable media of Example Z01. Example Z08 includes a computing system including one or more computer-readable media and the processor circuit of Example Z01. Example Z09 includes an apparatus including means for executing the instructions of Example Z01. Example Z10 includes a signal produced as a result of executing the instructions of Example Z01. Example Z11 includes a data unit produced as a result of executing the instructions of Example Z01. Example Z12 includes a data unit of Example Z10 and / or some other example herein, wherein the data unit is a datagram, a network packet, a data frame, a data segment, a protocol data unit (PDU), a service data unit (SDU), a message, or a database object. Example Z13 includes a signal encoded with the data unit of Example Z11 and / or Z12. Example Z14 includes an electromagnetic signal carrying the instructions of Example Z01. Example Z15 includes an apparatus including means for performing the method of any one of Examples A01-A07, B01-B17 and / or other examples herein.Example Z16 includes a compute node executing a service as part of one or more applications instantiated on a virtualization infrastructure, the service including a compute node associated with any of Example 4Z, portions thereof, and / or other examples herein. Example Z17 includes a method of communicating in a wireless network as shown and described herein. Example Z18 includes a system for providing wireless communication as shown and described herein. Example Z19 includes an apparatus for providing wireless communication as shown and described herein.

[0227] Any of the above examples can be combined with any other example (or combination of examples) unless otherwise noted. The above description of one or more implementations provides illustration and illustration and is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0228] term For purposes of this document, the following terms and definitions apply to the examples and embodiments discussed herein. Additionally, terms found in '719, [TS38133], [TS38215], [TR38857], [TR38845], [TS22261], [TS22104], [TS38355], [TS38305], [TS38859], and 3GPP TS21.905 may also apply to the examples and embodiments described herein.

[0229] As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly dictates otherwise. Furthermore, the terms "comprises" and / or "comprising," as used herein, specify the presence of stated features, integers, steps, operations, elements, epochs, iterations, stages, and / or components, but should be understood to not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. The phrase "A and / or B" means (A), (B), or (A and B). For purposes of this disclosure, the phrase "A, B, and / or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, C). The phrase "X" means one or more Xs or a set of Xs. The description may use phrases such as "in one embodiment," "in some embodiments," "in one embodiment," "in some embodiments," "in some implementations," "in some examples," and the like, each of which may refer to one or more of the same or different embodiments, implementations, and / or examples. Additionally, the terms "comprising," "including," "having," and the like, as used in connection with this disclosure, are synonymous.

[0230] The terms "coupled" and "communicatively coupled," along with their derivatives, are used herein. The term "coupled" may mean that two or more elements are in direct physical or electrical contact with each other, may mean that two or more elements are in indirect contact with each other but still cooperate or interact with each other, and / or may mean that one or more other elements are coupled or connected between the elements that are said to be coupled to each other. The term "directly coupled" may mean that two or more elements are in direct contact with each other. The term "communicatively coupled" may mean that two or more elements are in contact with each other by communication means, such as via a wire or other interconnection, via a wireless communication channel or link, and / or the like.

[0231] The term "absolute location" refers, in at least some instances, to an estimate of the UE's location in 2D / 3D geographic coordinates (latitude, longitude, elevation, etc.) within a coordinate system.

[0232] The term "access technology," in at least some examples, refers to the technology used for the underlying physical connection to a communications network. The term "radio access technology" or "RAT," in at least some examples, refers to the technology used for the underlying physical connection to a radio-based communications network. The term "radio technology," in at least some examples, refers to the technology for wireless transmission and / or reception of electromagnetic radiation for information transfer. The term "RAT type," in at least some examples, can identify the transmission technology and / or communication protocol used in an access network. Examples of access technologies are discussed in '719.

[0233] The term "alert limit" or "AL" refers, in at least some examples, to the maximum allowable positioning error for consistency. Additionally or alternatively, the term "alert limit" or "AL" refers, in at least some examples, to the maximum allowable positioning error such that the positioning system is usable for the intended application. In some examples, if the positioning error exceeds the AL, the calculated position consistency result may not meet the consistency requirement. Additionally or alternatively, if the positioning error exceeds the AL, the positioning system may be declared unusable for the intended application to prevent loss of positioning integrity. Additionally or alternatively, if the AL limits the positioning error on the horizontal plane or vertical axis, it is referred to as a horizontal AL (HAL) or a vertical AL (VAL), respectively.

[0234] In at least some examples, the term "anchor UE" refers to a UE that supports positioning of a target UE, e.g., by transmitting and / or receiving reference signals for positioning and / or providing positioning-related information via a sidelink interface.

[0235] The term "application layer ID" refers, at least in some instances, to an identifier that identifies an RSP-enabled UE within the context of a particular application. The format of this identifier is outside the scope of 3GPP.

[0236] The term "direction," in at least some examples, refers to a direction from another UE, such as another target UE, a designated UE, or an SL reference UE, to a target UE. Additionally or alternatively, the term "direction," in at least some examples, refers to a direction from a target UE to another UE, such as another target UE, a designated UE, or an SL reference UE.

[0237] The term "field" refers, at least in some instances, to the individual contents of an information element (IE).

[0238] The term "integrity availability" refers, at least in some instances, to the percentage of time that the integrity availability is below the required AL.

[0239] The term "designated UE" refers, in at least some examples, to an SL reference UE whose location is known or whose location can be learned using Uu-based positioning. In some examples, the designated UE can be used to determine the location of a target UE using SL positioning.

[0240] The term "measurement," in at least some instances, refers to the observation and / or quantification of an attribute of an object, event, or phenomenon. Additionally or alternatively, the term "measurement," in at least some instances, refers to a series of actions having the purpose of determining a measurement or measurement result, and / or an actual instance or execution of actions leading to a measurement. Additionally or alternatively, the term "measurement," in at least some instances, refers to data recorded during a test. In at least some instances, the term "metric" refers to a quantity generated in evaluating a measurement. Additionally or alternatively, the term "metric" refers to data obtained from a set of measurements, in at least some instances. Additionally or alternatively, the term "metric" refers to a set of events combined or grouped into one or more values, in at least some instances. Additionally or alternatively, the term "metric" refers to a combination of measurements or a set of collected data points, in at least some instances. Additionally or alternatively, the term "metric" refers to a standard definition of a quantity generated in evaluating network performance and / or reliability, which has an intended usefulness and is carefully specified to convey the precise meaning of the measurement.

[0241] The term "mobile TRP" refers, in at least some examples, to a TRP belonging to a mobile IAB node and / or UE.

[0242] The term "preconfigured assistance data," in at least some examples, refers to downlink (DL) positioning reference signal (PRS) assistance data (including associated validity criteria) that may be provided to a UE (before or during an ongoing positioning session) to be utilized for potential future (e.g., deferred MT-LR) positioning measurements. In some examples, the terms "preconfigured assistance data" and / or preconfigured DL-PRS assistance data include multiple instances, each applicable to a different region within the network.

[0243] The term "positioning" refers, at least in some instances, to the ability to determine the geographic location and / or velocity of an entity / element (such as a UE or other device).

[0244] The term "positioning integrity," in at least some examples, refers to a measure of confidence in the accuracy of location-related data and the ability to provide associated alerts. Additionally or alternatively, in at least some examples, the term "positioning integrity" refers to a measure of confidence in the accuracy of location-related data provided by a positioning system and the ability to provide timely and effective alerts to LCS clients when the positioning system does not meet the conditions for intended operation.

[0245] The term "positioning service availability," in at least some examples, refers to a percentage value that is the amount of time that the positioning service is delivering the required location-related data within performance requirements divided by the amount of time that the system is expected to deliver the positioning service according to the specifications for the target service area.

[0246] The term "positioning service delay" refers, in at least some examples, to the amount of time that elapses between an event that triggers the determination of location-related data and the availability of the location-related data at a system interface.

[0247] The term "protection level" or "PL" refers to a statistical upper bound on positioning error (PE) that ensures that, in at least some instances, the probability per unit time that the true error is greater than AL and the PL is less than or equal to AL for a period longer than the time-to-alert (TTA) is less than the target integrity risk (TIR).

[0248] The term "PRS-only transmission point" or "PRS-only TP" refers, in at least some examples, to a TP that transmits only PRS and / or DL-PRS signals and is not associated with a cell.

[0249] The term "PRS processing window" or "PPW" refers, in at least some examples, to a processing window configured by the network for a UE for NR DL-PRS measurements without measurement gaps.

[0250] The term "range," in at least some examples, refers to the straight-line distance between the target UE and another UE, such as another target UE, designated UE, or SL reference UE.

[0251] The term "ranging" refers, at least in some examples, to determining the distance between two UEs (or more than two UEs) and / or the direction of one UE (e.g., a target UE) from another UE (e.g., an SL Reference UE, an anchor UE, etc.) over a PC5 interface. Additionally or alternatively, the term "ranging" refers, at least in some examples, to determining the distance and / or direction between a UE and another entity (e.g., an anchor UE, an SL Reference UE, etc.).

[0252] The terms "ranging / sidelink positioning," "ranging / SL positioning," or "RSP," in at least some examples, refer to access stratum (AS) functionality that enables ranging-based services and sidelink positioning as specified in 3GPP TS 23.586 ("TS23586").

[0253] The terms "Ranging / Sidelink Positioning Protocol," "Ranging / SL Positioning Protocol," "RSP Protocol," or "RSPP" refer, at least in some examples, to a protocol for providing RSP services. In some examples, RSPP includes SLPP messages and supplementary service messages in accordance with [TS23586].

[0254] In at least some examples, the term "Ranging / Sidelink Positioning Application Identifier," "Ranging / SL Positioning Application Identifier," or "RSP App ID" refers to a globally unique identifier (ID) that identifies a particular RSP application, which can be mapped to a V2X service type or ProSe ID.

[0255] In at least some examples, the term "receive point" or "RP" refers to a cell, a portion of a cell, or a set of receive antennas (e.g., an antenna array (having one or more antenna elements)) geographically co-located with respect to a UL-SRS-only RP. A receive point may include a base station (ng-eNB or gNB) antenna, a remote radio head, a remote antenna at a base station, an antenna at a UL-SRS-only RP, etc. A cell may include one or more receive points. In a homogeneous deployment, each receive point may correspond to a cell.

[0256] In at least some examples, the term "relative location" refers to the location of a target UE relative to a network element or another UE. In some examples, the relative location can be two-dimensional or three-dimensional. In some examples, the location results obtained for the target UE are summarized and / or defined in more detail in [TS23032] and / or [TS23586]. In at least some examples, the term "relative location" refers to a location (or an estimate of the UE's location) relative to other network elements and / or relative to other UEs.

[0257] In at least some examples, the term "relative velocity" refers to velocity (or an estimate of UE velocity) relative to network elements, other UEs, and / or some other object. In some examples, the relative velocity of a target UE includes a radial component equal to the rate of change of range between the target UE and other UEs, and a lateral component orthogonal to the radial component.

[0258] The term "receive time delay" or "Rx time delay" refers, at least in some instances, to the time delay from the point of view of signal reception, from the time a radio frequency (RF) signal arrives at the Rx antenna to the time the signal is digitized and time-stamped at baseband.

[0259] The term "receive timing error" or "Rx timing error," in at least some examples, refers to the result of an Rx time delay associated with receiving a signal prior to reporting measurements derived from the signal. In some examples, the Rx timing error is the uncalibrated Rx time delay associated with receiving a DL-PRS / UL SRS signal, or the remaining delay after UE / TRP internal calibration / compensation of the Rx time delay. Additionally or alternatively, the calibration / compensation can also include calibration / compensation for relative time delays between different RF chains within the same UE / TRP, and possibly also account for the offset of the Rx antenna phase center relative to the physical antenna center.

[0260] The term "sidelink positioning" or "SL positioning" refers, at least in some examples, to the ability to determine a geographical location, an absolute location, a relative location, a relative location, ranging information, and possibly a velocity (e.g., absolute velocity and / or relative velocity) using sidelink measurements. Additionally or alternatively, at least in some examples, the term "sidelink positioning" or "SL positioning" refers to a positioning UE using PC5 to obtain absolute position, relative location, and / or ranging information.

[0261] In at least some examples, the term "sidelink anchor UE" or "SL anchor UE" refers to a UE that supports positioning of a target UE, e.g., by transmitting and / or receiving reference signals for positioning and / or providing positioning-related information using a sidelink.

[0262] The term "sidelink positioning client UE" or "SL positioning client UE" refers, at least in some examples, to a third-party UE other than the SL reference UE and target UE that initiates an RSP service request on behalf of an application residing therein. In some examples, the SL positioning client UE does not need to support RSP functionality, but communication between the SL positioning client UE and the SL reference UE / target UE needs to be established via either PC5 or 5GC for the transmission of the service request and results.

[0263] The terms "Sidelink Positioning Protocol," "SL Positioning Protocol," or "SLPP" refer, at least in some examples, to a protocol for sidelink positioning procedures.

[0264] In at least some examples, the term "sidelink positioning reference signal" or "SL PRS" refers to a reference signal transmitted over the sidelink for positioning purposes.

[0265] In at least some examples, the term "sidelink positioning server UE" or "SL positioning server UE" refers to a UE that provides method determination, assistance data delivery, and / or position calculation functionality for sidelink positioning and ranging-based services. It interacts with other UEs via PC5 as needed to determine ranging / SL position methods, deliver assistance data, and calculate the target UE's position. In some examples, a target UE or an SL Reference UE can act as an SL positioning server UE if any of the functionality is supported.

[0266] In at least some examples, the term "sidelink reference UE" or "SL reference UE" refers to a UE that supports positioning of a target UE, e.g., by using an SL to transmit and / or receive reference signals for positioning and / or provide positioning-related information. In some examples, an SL reference UE may be referred to as an "anchor UE."

[0267] In at least some examples, the term "sidelink server UE" or "SL server UE" refers to a UE that provides positioning method determination, assistance data delivery, and / or location calculation functionality for SL positioning and ranging-based services. In some examples, the SL server UE interacts with other UEs over a PC5 interface to determine RSP methods, deliver assistance data, and calculate the target UE's location. In some examples, the target UE and / or the SL anchor UE can act as an SL server UE if any of the functionality is supported.

[0268] In at least some examples, the term "sidelink target UE" or "SL target UE" refers to a UE whose distance, direction, and / or location is measured using support from one or more SL anchor UEs using sidelink.

[0269] In at least some examples, the term "SRS-only RP" refers to an RP that receives only UL-SRS signals and is not associated with a cell.

[0270] In at least some examples, the term "target integrity risk" or "TIR" refers to the probability that a positioning error will exceed an AL without alerting the user within the required TTA. In some examples, the TIR is typically defined as a probability rate per time unit (e.g., per hour, per second, or per independent sample).

[0271] In at least some examples, the term "target UE" refers to a UE whose distance, direction, and / or location is to be measured with support from one or more anchor UEs using ranging-based services and / or sidelink in sidelink positioning, for example.

[0272] The term "time to alert" or "Time-to-Alert" refers, in at least some embodiments, to the maximum allowable elapsed time from when a positioning error exceeds an AL until the function providing positioning integrity announces a corresponding alert.

[0273] In at least some examples, the term "transmission point" or "TP" refers to a cell, a portion of a cell, and / or a set of transmit antennas (e.g., an antenna array having one or more antenna elements) geographically co-located with a DL-PRS-only TP. In some examples, a TP may include a base station (e.g., ng-eNB or gNB) antenna, a remote radio head, a remote antenna at a base station, an antenna at a DL-PRS-only TP, etc. Additionally or alternatively, a cell may include one or more TPs. Additionally or alternatively, in a homogeneous deployment, each TP may correspond to a cell.

[0274] In at least some embodiments, the term "transmission / reception point" or "TRP" refers to an antenna array having one or more antenna elements available to a network located at a particular geographic location in a particular region. Additionally or alternatively, in at least some embodiments, the term "transmission / reception point" or "TRP" refers to a set of geographically co-located antennas (e.g., an antenna array having one or more antenna elements) that support TP and / or RP functions.

[0275] The term "Tx time delay" refers, at least in some embodiments, from a signal transmission perspective, to the time delay from when a digital signal is generated at baseband to when the RF signal is transmitted from a Tx antenna.

[0276] The term "Tx timing error," in at least some embodiments, refers to the result of a Tx time delay associated with the transmission of a signal. In some embodiments, the Tx timing error is the uncalibrated Tx time delay associated with the transmission of a DL-PRS / UL SRS signal, or the remaining delay after TRP / UE internal calibration / compensation of the Tx time delay. Additionally or alternatively, the calibration / compensation may include calibration / compensation of relative time delays between different RF chains within the same TRP / UE and may also account for the offset of the Tx antenna phase center relative to the physical antenna center.

[0277] The term "UE-only operation" refers, at least in some examples, to operation of the RSP where service request processing and result calculations are performed by the UE. In some examples, in UE-only operation, communication between UEs occurs via PC5.

[0278] The terms "UE-to-Network Relay UE," "U2N Relay UE," or "U2NR" refer, in at least some examples, to a UE that provides functionality to support the connection of U2N remote UEs to a network.

[0279] The terms "UE-to-Network Remote UE," "U2N Remote UE," or "U2N RUE" refer, in at least some examples, to a UE that communicates with the network via a U2N Relay UE.

[0280] The terms "UserInfo Identifier," "UserInfo ID," or "UserInfo ID" refer, in at least some examples, to an ID configured for RSP UE discovery based on the HPLMN's policy or via the RSP application server that assigns it. In some examples, the definition of the UserInfo ID value is predefined, configurable, and / or implementation specific.

[0281] While many of the examples described herein are provided using specific cellular / mobile network terminology, including the use of 4G / 5G 3GPP network components (or anticipated terahertz-based 6G / 6G+ technologies), these examples may apply to many other deployments of wide-area and local wireless networks, as well as the integration of wired networks (including optical networks and associated fibers, transceivers, etc.). Additionally, various standards (e.g., 3GPP, ETSI, IEEE, etc.) may define various message formats, PDUs, MAC CEs, containers, frames, and / or other data structures, including sequences of optional or mandatory containers, frames, data elements (DEs), data frames (DFs), information elements (IEs), information object classes (IOCs), managed object classes (MOCs), parameters, attributes, and / or other elements. However, the requirements of any particular standard should not limit the examples described herein, and thus any combination of containers, frames, DFs, DEs, IEs, IOCs, MOCs, parameters, attributes, values, operations, features, and / or other elements is possible in various examples, including any combination of containers, frames, DFs, DEs, IEs, IOCs, MOCs, parameters, attributes, values, operations, features, and / or other elements, or any combination of containers, frames, DFs, DEs, IEs, IOCs, MOCs, parameters, attributes, values, operations, features, and / or other elements that are required to be strictly followed in order to be compliant with such standard.

[0282] Additionally, this disclosure provides various examples of various systems, subsystems, devices, planes, layers, protocols, components, operations, containers, frames, DFs, DEs, IEs, IOCs, MOCs, parameters, attributes, values, operations, features, and / or other elements / data structures. However, the specific names or labels used for various systems, subsystems, devices, planes, layers, components, operations, parameters, attributes, IEs, IOCs, MOCs, and other elements / data structures are provided for purposes of discussion and explanation, and not limitation. The various systems, subsystems, devices, planes, layers, components, operations, parameters, attributes, IEs, IOCs, MOCs, and other elements / data structures may have names or labels other than those provided herein. Furthermore, additional or alternative embodiments, implementations, and / or iterations of 3GPP specifications and / or other related standards / specifications may name specific elements / entities differently from those described herein but still be within the context of this disclosure.

[0283] Aspects of the inventive subject matter may be referenced herein merely for convenience and / or collectively and are not intended to spontaneously limit the scope of the application to any single aspect or inventive concept. While specific aspects have been shown and described herein, the present disclosure covers any and all adaptations or modifications, and any configurations capable of achieving the same purpose may be substituted for the specific aspects shown and described herein. Combinations of the described aspects, and other aspects not specifically described herein, will be apparent to those skilled in the art upon reference to the present disclosure.

Claims

1. 1. A method of operating a target user equipment (UE), the method comprising: receiving a Sidelink Positioning Protocol (SLPP) request to measure and report Sidelink (SL) positioning measurements; measuring a SL positioning reference signal (PRS) set based on the received request; transmitting a measurement report, the measurement report including a positioning result based on measurements of the SL PRS set; A method comprising:

2. 2. The method of claim 1, wherein if the UE is capable of performing SL Time Difference of Arrival (TDoA) positioning, the measurements include performing SL Reference Signal Time Difference (RSTD) measurements during a measurement period according to an accuracy requirement set, the SL RSTD measurements including measurements of a first SL PRS in the SL PRS set from a first peer UE on a target link and measurements of a second SL PRS in the SL PRS set from a second peer UE on a reference link.

3. The method of claim 2 , wherein the method includes determining a location of the target UE relative to a first location of the first peer UE and a second location of the second peer UE.

4. 4. The method of claim 3, wherein the determining step includes estimating a location of the target UE based on the SL RSTD measurements, knowledge of geographic coordinates of the first peer UE and the second peer UE, and relative SL timing of the first SL PRS and the second SL PRS.

5. The method of claim 4 , wherein the method includes generating a measurement report including SL RSTD measurements of the SL RSTD measurements based on a measurement report mapping requirement.

6. The method of claim 5 , wherein the target link comprises a PC5 interface and the reference link comprises a PC5 interface or a Uu interface.

7. The method of claim 6 , wherein the measurement of the first SL PRS is a first SL PRS reference signal received power (RSRP) measurement and the measurement of the second SL PRS is a second SL PRS-RSRP measurement.

8. 2. The method of claim 1, wherein when the UE is capable of performing SL TDoA positioning or SL round-trip time (RTT) positioning, the measurements include performing SL receive (Rx)-transmit (Tx) time difference measurements during a measurement period according to an accuracy requirement set, and the SL Rx-Tx time difference measurements are based on measurements of SL PRSs in the SL PRS set transmitted by peer UEs.

9. 9. The method of claim 8, wherein the method comprises determining an SL RTT measurement based on a performed SL Rx-Tx time difference measurement and another SL Rx-Tx time difference measurement performed at the peer UE based on an SL signal transmitted by the target UE.

10. The method of claim 9 , wherein the method comprises generating a measurement report including an SL RTT measurement value for the SL RTT measurement based on a measurement report mapping requirement.

11. The method of claim 10 , wherein the measurements of the SL PRS in the SL PRS set transmitted by the peer UE are SL PRS-RSRP measurements.

12. 2. The method of claim 1, wherein when the UE is capable of performing SL TDoA positioning, SL RTT positioning, SL Angle of Arrival (AoA) positioning, or SL Time of Arrival (TOA) positioning, the measuring step includes performing SL PRS-RSRP measurements during a measurement period according to an accuracy requirement set, and the SL PRS-RSRP measurements are linear averages of one or more resource elements carrying at least one SL PRS in the SL PRS set configured for RSRP measurements within a considered measurement frequency bandwidth.

13. 13. The method of claim 12, wherein the SLPP request is an SLPP Request Location Information message or an SLPP Provide Assistance Data message.

14. The method of claim 13 , wherein the measurement report is included in a SLPP Provide Location Information message.

15. The method of claim 10 , wherein the measurement report mapping requirements include mapping requirements for power control of the SL PRS set.

16. The method of claim 10 , wherein the measurement report mapping requirement includes a mapping requirement for measured timing differences between reference signals of SL-PRS.

17. 17. The method of claim 16, wherein the receiving step includes receiving the SLPP request from a Location Management Function (LMF) or another UE.

18. The method of claim 17 , wherein the transmitting step includes transmitting the measurement report to the LMF or the other UE.

19. 1. An apparatus comprising: a memory circuit; a radio frequency (RF) circuit; and a processor circuit coupled to the memory circuit and the RF circuit, the processor circuit comprising: receiving a Sidelink Positioning Protocol (SLPP) request to measure and report Sidelink (SL) positioning measurements; measuring a SL positioning reference signal (PRS) set based on the received request; Sending measurement reports, It is configured as follows: The measurement report includes a positioning result based on measurements of the SL PRS set.

20. One or more computer-readable media containing instructions that, when executed by a processor circuit, cause the processor circuit to: receiving a Sidelink Positioning Protocol (SLPP) request to measure and report Sidelink (SL) positioning measurements; measuring a SL positioning reference signal (PRS) set based on the received request; transmitting a measurement report, the measurement report including a positioning result based on measurements of the SL PRS set; One or more computer-readable media.

Images