Virtual positioning reference unit for positioning

Abstract

Embodiments presented herein may enable a UE to perform positioning using virtual anchors and / or positioning reference units. In one embodiment, the UE sends a request for support data for performing UE-based positioning, the request including at least one of the UE's location information or a list of anchors observed by the UE. The UE receives support data for UE-based positioning, the support data including a list of virtual anchors and a list of positioning reference units (PRUs) including a set of virtual positioning reference units (VPRUs), the list of virtual anchors and the list of PRUs being selected based on at least one of the UE's location information or a list of anchors observed by the UE. The UE performs UE-based positioning using at least one virtual anchor and at least one VPRU in the support data.

Description

[Technical Field]

[0001] (Cross-reference of related applications)

[0001] This application claims the benefit of U.S. Nonprovisional Patent Application No. 18 / 180,770, “VIRTUAL POSITIONING REFERENCE UNIT FOR POSITIONING,” filed on 8 March 2023, which is expressly incorporated herein by reference in its entirety.

[0002]

[0002] This disclosure relates in general to communication systems, and more specifically to wireless communications involving one or more virtual positioning reference units. [Background technology]

[0003]

[0003] Wireless communication systems are widely deployed to provide a variety of telecommunications services, including telephone, video, data, messaging, and broadcast. Typical wireless communication systems can employ multiple access technologies that support communication with multiple users by sharing available system resources. Examples of such multiple access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.

[0004]

[0004] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol that enables different wireless devices to communicate at the city, national, regional, and even global levels. An exemplary telecommunications standard is 5G New Radio (NR). 5G NR is part of the ongoing evolution of mobile broadband, announced by the Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (for example, for the Internet of Things, IoT), and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine type communications (mMTC), and ultra-reliable low latency communications (URLLC). Some aspects of 5G NR may be based on the 4G Long Term Evolution (LTE) standard. Further improvements are needed in 5G NR technology. These improvements may also be applicable to other multiple access technologies and the telecommunications standards that employ them. [Overview of the Initiative]

[0005]

[0005] Hereinafter, a simplified outline of one or more embodiments is presented to provide a basic understanding of such embodiments. This outline is not a comprehensive overview of all embodiments that have been conceived. This outline does not identify the main or important elements of all embodiments, nor does it define the scope of any or all embodiments. Its sole purpose is to present in a simplified form some concepts of one or more embodiments as an introduction to the more detailed descriptions that will be presented later.

[0006]

[0006] In one aspect of the present disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus transmits to a network entity a request for support data for performing user equipment (UE)-based positioning, the request comprising at least one of the location information of the UE or a list of anchors observed by the UE. Based on the request, the apparatus receives support data for UE-based positioning from the network entity, the support data comprising a list of virtual anchors and a list of positioning reference units (PRUs) including a set of virtual positioning reference units (VPRUs), the list of virtual anchors and the list of PRUs being selected based on at least one of the location information of the UE or a list of anchors observed by the UE. The apparatus performs UE-based positioning using at least one virtual anchor and at least one VPRU in the support data.

[0007]

[0007] In one aspect of the present disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus receives a request from a UE for support data for performing UE-based positioning, the request comprising at least one of the UE's location information or a list of anchors observed by the UE. The apparatus transmits support data for UE-based positioning to the UE based on the request, the support data comprising a list of virtual anchors and a list of PRUs including a set of VPRUs, the list of virtual anchors and the list of PRUs being selected based on at least one of the UE's location information or a list of anchors observed by the UE.

[0008]

[0008] In order to achieve the above and related objectives, one or more embodiments may include features that are fully described below and, in particular, indicated in the claims. The following description and drawings detail specific exemplary features of one or more embodiments. However, these features represent only a small number of the various methods that may employ the principles of the various embodiments. [Brief explanation of the drawing]

[0009] [Figure 1]

[0009] This figure shows an example of a wireless communication system and access network. [Figure 2]

[0010] Figure 2A shows an example of the first frame according to various aspects of the present disclosure.

[0011] Figure 2B shows an example of a downlink (DL) channel within a subframe according to various aspects of this disclosure.

[0012] Figure 2C shows an example of a second frame according to various aspects of the present disclosure.

[0013] Figure 2D shows an example of an uplink (UL) channel within a subframe according to various aspects of this disclosure. [Figure 3]

[0014] This figure shows an example of a base station and user equipment (UE) within an access network. [Figure 4]

[0015] This figure shows an example of UE positioning based on reference signal measurement values. [Figure 5]

[0016] This figure shows an example of Global Navigation Satellite System (GNSS) positioning according to various aspects of this disclosure. [Figure 6]

[0017] This figure shows an example of real-time kinematic (RTK) positioning according to various aspects of this disclosure. [Figure 7]

[0018] This figure shows an example of a positioning reference unit (PRU) according to various aspects of this disclosure. [Figure 8]

[0019] This figure shows examples of virtual anchor generation or protection of the true location of physical anchors according to various aspects of this disclosure. [Figure 9]

[0020] This figure shows an example of creating a virtual PRU (VPRU) based on a set of physical PRUs according to various aspects of this disclosure. [Figure 10]

[0021] A diagram showing an example of creating a VPRU based on a set of physical PRUs according to various aspects of the present disclosure. [Figure 11]

[0022] A diagram showing an example of generating a virtual PRU base station based on one or more physical PRU base stations according to various aspects of the present disclosure. [Figure 12]

[0023] A diagram showing an example of a pre-assigned location of virtual reference stations (VRSs) according to various aspects of the present disclosure. [Figure 13]

[0024] A diagram showing an example of generating VRS measurements, assistance data, and / or correction data according to various aspects of the present disclosure. [Figure 14]

[0025] A communication flow showing an example of network entities that configure a virtual anchor and a VPRU for a UE according to various aspects of the present disclosure. [Figure 15]

[0026] A communication flow showing an example of assistance data requests and information that may be included in the assistance data that may enable a network entity to more efficiently configure a virtual anchor and / or a VPRU for a UE according to various aspects of the present disclosure. [Figure 16]

[0027] A flowchart of a method of wireless communication. [Figure 17]

[0028] A flowchart of a method of wireless communication. [Figure 18]

[0029] A diagram showing an example of a hardware implementation form for an exemplary device and / or network entity. [Figure 19]

[0030] A flowchart of a method of wireless communication. [Figure 20]

[0031] A diagram showing an example of a hardware implementation form for an exemplary network entity.

Best Mode for Carrying Out the Invention

[0010]

[0032] Embodiments presented herein may enable a UE to achieve high-precision positioning without knowing the location of specific network nodes, such as positioning reference units (PRUs) and transmit / receive points (TRPs). Embodiments presented herein may enable a UE to perform positioning (e.g., UE-based positioning) using virtual PRUs (VPRUs) and / or virtual anchors, such that PRUs / anchors can provide the UE with measured values, reference signals, support data, and / or correction data without disclosing their actual locations. In one embodiment of this disclosure, a VPRU may indicate that there is no physical PRU (PPRU) located at the requested location of the VPRU, and measured values, support data, and / or correction data may be virtually generated for the UE based on VPRU and / or PPRU information / measurements. Thus, the network may generate a VPRU or virtual reference station for the UE at any location. Measured values, support data, and / or correction data from the VPRU may be based on measured values ​​from one or more physical PRUs and / or the network resolving / tracking various error sources.

[0011]

[0033] By enabling UEs to perform positioning using virtual anchors (e.g., TRP / satellites), carrier operators (e.g., operators for location servers, location management functions (LMF), non-terrestrial networks (NTN), etc.) can avoid disclosing / providing the precise or true location of their network nodes, such as anchor base stations and / or anchor satellites, thereby maintaining privacy and security for these network nodes. In addition, in the case of mobile anchors such as mobile UEs associated with side-link positioning or low Earth orbit (LEO) satellites associated with NTN, the location of these mobile anchors may be difficult to estimate and share with the UE in real time. Therefore, using virtual anchors may be more preferable and convenient for UEs to perform positioning. The embodiments presented herein may allow the ground truth location of the anchor to be protected from noise. Similarly, by enabling UEs to perform positioning using VPRUs, carrier operators or PRUs can also avoid disclosing / providing the precise or true ground location of the PRU, thereby maintaining privacy and security for the PRU. The location of the VPRU can be pre-assigned (for example, NTN may be more preferable) or generated based on the location of the target UE (e.g., the generated VPRU is close to the target UE). Embodiments presented herein may enable the UE to achieve high-precision positioning by allowing the UE to cancel common anchor location errors (e.g., using correction data from the PRU). Furthermore, while a physical PRU may not be able to receive measurements and / or signals from the same set of anchors as the UE, using a VPRU may enable the measurements from the VPRU to be associated with one or more common anchors of the UE. In other words, using a virtual PRU may ensure that the measurements are from common anchors.

[0012]

[0034] The "modes for carrying out the invention" described below in relation to the attached drawings are intended to illustrate various configurations and do not represent the only configuration capable of realizing the concepts described herein. The "modes for carrying out the invention" include specific details intended to provide a complete understanding of the various concepts. However, these concepts can be put into practice without these specific details. In some cases, well-known structures and components are shown in block diagrams to avoid obscuring such concepts.

[0013]

[0035] Several embodiments of telecommunications systems are presented with reference to various devices and methods. These devices and methods are described in the following “Modes for Carrying Out the Invention” and are illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “Elements”). These Elements can be implemented using electronic hardware, computer software, or any combination thereof. Whether such Elements are implemented as hardware or realized as software depends on the specific application and the design constraints imposed on the overall system.

[0014]

[0036] For example, an element, any part of an element, or any combination of elements can be implemented as a “processing system” comprising one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, systems on a chip (SoC), baseband processors, field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gate logic, discrete hardware circuits, and other suitable hardware configured to implement the various functions described throughout this disclosure. One or more processors in a processing system can execute software. Software, whether referred to as software, firmware, middleware, microcode, hardware description language, or any other name, shall be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, or any combination thereof.

[0015]

[0037] Accordingly, in one or more exemplary embodiments, implementations, and / or use cases, the functions described may be implemented in hardware, software, or any combination thereof. Where implemented in software, these functions may be stored or encoded on a computer-readable medium as one or more instructions or codes. Computer-readable medium includes computer storage media. Storage media can be any available medium accessible by a computer. Examples of such computer-readable media include random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage devices, magnetic disk storage devices, other magnetic storage devices, combinations of computer-readable media types, or any other medium that can be used to store computer executable code in the form of instructions or data structures accessible by a computer.

[0016]

[0038] While this application illustrates various embodiments, implementations, and / or use cases through examples of several embodiments, additional or different embodiments, implementations, and / or use cases may arise in many different configurations and scenarios. The embodiments, implementations, and / or use cases described herein can be realized across many different platform types, devices, systems, shapes, sizes, and packaging configurations. For example, embodiments, implementations, and / or use cases may arise through integrated chip implementations and other non-modular component-based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail / purchasing devices, medical devices, artificial intelligence (AI)-enabled devices, etc.). Some embodiments may or may not specifically address use cases or applications, but a wide range of combinations of the embodiments described may be applicable. The embodiments, implementations, and / or use cases can range from chip-level or modular components to non-modular, non-chip-level implementations, and further to aggregated, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more of the technologies described herein. In some practical settings, devices incorporating the described embodiments and features may also include additional components and features for the implementations and practices of the claimed and described embodiments. For example, wireless signal transmission and reception necessarily involve several components for analog and digital purposes (e.g., hardware components including antennas, RF chains, power amplifiers, modulators, buffers, processors (one or more), interleavers, adders / analog adders, etc.). The technologies described herein can be practiced in a wide variety of devices, chip-level components, systems, distributed configurations, aggregated or non-aggregated components, end-user devices, etc., of various sizes, shapes, and configurations.

[0017]

[0039] The deployment of communication systems such as 5G NR systems can be configured in multiple ways using various components or parts. In a 5G NR system or network, network equipment such as network nodes, network entities, network mobility elements, radio access network (RAN) nodes, core network nodes, network elements, or base stations (BS), or one or more units (or one or more components) that realize base station functions, can be implemented in an aggregated or unaggregated architecture. For example, a BS (such as node B (NB), advanced NB (eNB), NR BS, 5G NB, access point (AP), transmission reception point (TRP), or cell) can be implemented as an aggregated base station (also known as a standalone BS or monolithic BS) or an unaggregated base station.

[0018]

[0040] Aggregated base stations may be configured to utilize a radio protocol stack that is physically or logically integrated within a single RAN node. Non-aggregated base stations may be configured to utilize a protocol stack that is physically or logically distributed among two or more units (such as one or more centralized units (CUs), one or more distributed units (DUs), or one or more radio units (RUs)). In some embodiments, CUs may be implemented within a RAN node, and one or more DUs may be co-located with CUs or, alternatively, geographically or virtually distributed across one or more other RAN nodes. DUs may be implemented to communicate with one or more RUs. Each of CUs, DUs, and RUs may be implemented as a virtual unit, i.e., a virtual central unit (VCU), a virtual distributed unit (VDU), or a virtual radio unit (VRU).

[0019]

[0041] Base station operation or network design may take into account the aggregation characteristics of base station functions. For example, non-aggregated base stations can be used in integrated access backhaul (IAB) networks, open radio access networks (O-RAN (such as network configurations supported by the O-RAN Alliance)), or virtualized radio access networks (vRAN, also known as cloud radio access networks (C-RAN)). Non-aggregation may involve distributing functionality across two or more units in various physical locations, as well as virtually distributing the functionality of at least one unit, which can allow for flexibility in network design. Various units of a non-aggregated base station, or a non-aggregated RAN architecture, can be configured for wired or wireless communication with at least one other unit.

[0020]

[0042] Figure 100 shows an example of a wireless communication system and access network. The illustrated wireless communication system includes a non-aggregated base station architecture. The non-aggregated base station architecture may include one or more CUs 110 that can communicate directly with the core network 120 via a backhaul link, or indirectly with the core network 120 through one or more non-aggregated base station units (such as a quasi-real-time (quasi-RT) RAN intelligent controller (RIC) 125 via an E2 link, or a non-real-time (non-RT) RIC 115 associated with a Service Management and Orchestration (SMO) framework 105, or both). The CUs 110 can communicate with one or more DUs 130 via their respective midhaul links, such as an F1 interface. The DUs 130 can communicate with one or more RUs 140 via their respective fronthaul links. The RUs 140 can communicate with their respective UEs 104 via one or more radio frequency (RF) access links. In some implementations, UE104 can be serviced simultaneously by multiple RU140s.

[0021]

[0043] Each of the units, namely CU110, DU130, RU140, and the quasi-RT RIC125, non-RT RIC115, and SMO framework 105, includes, or may be coupled to, one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) over a wired or wireless transmission medium. Each of the units, or an associated processor or controller that provides instructions to the communication interface of a unit, may be configured to communicate with one or more of the other units over a transmission medium. For example, a unit may include a wired interface configured to receive or transmit signals to one or more of the other units over a wired transmission medium. In addition, a unit may include a wireless interface which may include a receiver, transmitter, or transceiver (such as an RF transceiver), and the wireless interface may be configured to receive or transmit signals, or both, to one or more of the other units over a wireless transmission medium.

[0022]

[0044] In some embodiments, the CU110 may host one or more higher-layer control functions. Such control functions may include, but are not limited to, Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), and Service Data Adaptive Protocol (SDAP). Each control function may be implemented using an interface configured to communicate signals with other control functions hosted by the CU110. The CU110 may be configured to handle user plane functions (i.e., central unit-user plane (CU-UP)), control plane functions (i.e., central unit-control plane (CU-CP)), or a combination thereof. In some implementations, the CU110 may be logically divided into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP units can communicate bidirectionally with the CU-CP units via an interface such as the E1 interface. The CU110 may be implemented to communicate with the DU130 as needed for network control and signaling.

[0023]

[0045] The DU130 may correspond to a logic unit containing one or more base station functions for controlling the operation of one or more RU140s. In some embodiments, the DU130 may host one or more of the following, at least in part, depending on a functional decomposition such as that defined by 3GPP: the Radio Link Control (RLC) layer, the Media Access Control (MAC) layer, and one or more higher physical (PHY) layers (such as modules for forward error correction (FEC) coding and decoding, scrambling, modulation, demodulation, etc.). In some embodiments, the DU130 may further host one or more low PHY layers. Each layer (or module) may be implemented using an interface configured to communicate signals with other layers (and modules) hosted by the DU130, or with control functions hosted by the CU110.

[0024]

[0046] Lower-layer functions can be implemented by one or more RU140s. In some deployments, RU140s controlled by DU130s may correspond to logical nodes hosting RF processing functions, or low-PHY layer functions (such as performing fast Fourier transforms (FFTs), inverse FFTs (iFFTs), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.), or both, at least partially based on functional partitioning such as lower-layer functional partitioning. In such architectures, RU(s)140s can be implemented to handle over-the-air (OTA) communication with one or more UE104s. In some implementations, real-time and non-real-time modes of control and user-plane communication with RU(s)140s can be controlled by the corresponding DU130s. In some scenarios, this configuration can enable DU(s)130s and CU110s to be implemented in cloud-based RAN architectures such as vRAN architectures.

[0025]

[0047] The SMO framework 105 may be configured to support RAN deployment and provisioning of non-virtualized and virtualized network elements. For non-virtualized network elements, the SMO framework 105 may be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which can be managed via an operation and maintenance interface (such as the O1 interface). For virtualized network elements, the SMO framework 105 may be configured to interact with a cloud computing platform (such as an open cloud (O-cloud) 190) via a cloud computing platform interface (such as the O2 interface) to perform network element lifecycle management (such as instantiating virtualized network elements). Such virtualized network elements may include, but are not limited to, the CU110, DU130, RU140, and quasi-RT RIC125. In some implementations, the SMO framework 105 may communicate with hardware embodiments of the 4G RAN, such as an open eNB (O-eNB) 111, via the O1 interface. Furthermore, in some implementations, the SMO framework 105 can communicate directly with one or more RU140s via the O1 interface. The SMO framework 105 may also include a non-RT RIC115 configured to support the functionality of the SMO framework 105.

[0026]

[0048] Non-RT RIC115 may be configured to include logical functions that enable non-real-time control and optimization of RAN elements and resources, artificial intelligence (AI) / machine learning (ML) (AI / ML) workflows including model training and updating, or policy-based guidance for applications / features in quasi-RT RIC125. Non-RT RIC115 may be coupled to quasi-RT RIC125 or communicate with quasi-RT RIC125 (e.g., via the A1 interface). Quasi-RT RIC125 may be configured to include logical functions that enable quasi-real-time control and optimization of RAN elements and resources via data acquisition and actions via an interface connecting one or more CU110s, one or more DU130s, or both, and an O-eNB to quasi-RT RIC125 (e.g., via the E2 interface).

[0027]

[0049] In some implementations, the non-RT RIC115 may receive parameter or external enrichment information from an external server to generate an AI / ML model deployed to the quasi-RT RIC125. Such information may be utilized by the quasi-RT RIC125 and may be received in the SMO framework 105 or the non-RT RIC115 from a non-network data source or from a network function. In some examples, the non-RT RIC115 or quasi-RT RIC125 may be configured to tune RAN behavior or performance. For example, the non-RT RIC115 may monitor long-term trends and patterns in performance and employ an AI / ML model to implement corrective actions through the SMO framework 105 (e.g., reconfiguration via O1) or through the creation of a RAN management policy (e.g., an A1 policy).

[0028]

[0050] At least one of CU110, DU130, and RU140 may be called base station 102. Thus, base station 102 may include one or more of CU110, DU130, and RU140 (each component is indicated by a dotted line to show that each component may or may not be included in base station 102). Base station 102 provides an access point to the core network 120 for UE104. Base station 102 may include macrocells (high-power cellular base stations) and / or small cells (low-power cellular base stations). Small cells include femtocells, picocells, and microcells. A network including both small cells and macrocells may be known as a heterogeneous network. A heterogeneous network may also include Home Evolved Node Bs (eNBs) that are capable of serving a restricted group known as a closed subscriber group (CSG). The communication link between RU140 and UE104 may include uplink (UL) (also called reverse link) transmission from UE104 to RU140, and / or downlink (DL) (also called forward link) transmission from RU140 to UE104. The communication link may use multiple-input multiple-output (MIMO) antenna techniques, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link may be via one or more carriers. Base station 102 / UE104 may use a spectrum with a maximum bandwidth of Y MHz (e.g., 5, 10, 15, 20, 100, 400 MHz, etc.) per carrier, allocated in a carrier aggregation of a total of up to Yx MHz (x component carriers) for transmission in each direction. These carriers may or may not be adjacent to each other. Carrier allocation can be asymmetrical between DL and UL (for example, DL may be allocated more or fewer carriers than UL).A component carrier may include a primary component carrier and one or more secondary component carriers. A primary component carrier may be called a primary cell (PCell), and a secondary component carrier may be called a secondary cell (SCell).

[0029]

[0051] Certain UE104s may communicate with each other using a device-to-device (D2D) communication link 158. The D2D communication link 158 may use the DL / UL wireless wide area network (WWAN) spectrum. The D2D communication link 158 may use one or more sidelink channels, such as the physical sidelink broadcast channel (PSBCH), physical sidelink discovery channel (PSDCH), physical sidelink shared channel (PSSCH), and physical sidelink control channel (PSCCH). D2D communication may be via various wireless D2D communication systems, such as Bluetooth®, Wi-Fi® based on the IEEE 802.11 standard, LTE, or NR.

[0030]

[0052] The wireless communication system may further include a Wi-Fi AP150 that communicates with a UE104 (also called a Wi-Fi station (STA)) via a communication link 154, for example, in an unlicensed frequency spectrum such as 5 GHz. When communicating in an unlicensed frequency spectrum, the UE104 / AP150 may perform a clear channel assessment (CCA) before communication to determine whether the channel is available.

[0031]

[0053] The electromagnetic spectrum is often divided into various classes, bands, channels, etc., based on frequency / wavelength. In 5G NR, two initial operating bands are identified as frequency range designations FR1 (410 MHz to 7.125 GHz) and FR2 (24.25 GHz to 52.6 GHz). Although a portion of FR1 is above 6 GHz, FR1 is often referred to (interchangeably) as the "sub-6 GHz" band in various documents and papers. A similar nomenclature issue can arise with FR2, which is often referred to (interchangeably) as the "millimeter wave" band in documents and papers, even though it is different from the extremely high frequency (EHF) band (30 GHz to 300 GHz) which is identified as the "millimeter wave" band by the International Telecommunication Union (ITU).

[0032]

[0054] The frequencies between FR1 and FR2 are often referred to as intermediate band frequencies. In recent 5G NR research, the operating band for these intermediate band frequencies is identified as frequency range designation FR3 (7.125 GHz to 24.25 GHz). The frequency bands included within FR3 may inherit the characteristics of FR1 and / or FR2, and therefore, in effect, the characteristics of FR1 and / or FR2 may be extended to the intermediate band frequencies. Furthermore, higher frequency bands are currently being explored to extend 5G NR operation beyond 52.6 GHz. For example, three higher operating bands have been identified as frequency range designations FR2-2 (52.6 GHz to 71 GHz), FR4 (71 GHz to 114.25 GHz), and FR5 (114.25 GHz to 300 GHz). Each of these higher frequency bands falls within the EHF band.

[0033]

[0055] With the above embodiments in mind, unless otherwise specified, terms such as “sub-6GHz” as used herein may broadly refer to frequencies that may be below 6GHz, within FR1, or include intermediate band frequencies. Furthermore, unless otherwise specified, terms such as “millimeter wave” as used herein may broadly refer to frequencies that may include intermediate band frequencies, within FR2, FR4, FR2-2, and / or FR5, or within the EHF band.

[0034]

[0056] Base station 102 and UE 104 may each include multiple antennas, such as antenna elements, antenna panels, and / or antenna arrays, to facilitate beamforming. Base station 102 may transmit a beamformed signal 182 to UE 104 in one or more transmit directions. UE 104 may receive a beamformed signal from base station 102 in one or more receive directions. UE 104 may also transmit a beamformed signal 184 to base station 102 in one or more transmit directions. Base station 102 may receive its beamformed signal from UE 104 in one or more receive directions. Base station 102 / UE 104 may perform beam training to determine the best receive and transmit directions for each of them. The transmit and receive directions for base station 102 may or may not be the same. The transmit and receive directions for UE 104 may or may not be the same.

[0035]

[0057] Base station 102 may include and / or be referred to as gNB, node B, eNB, access point, transceiver base station, radio base station, radio transceiver, transceiver function, basic service set (BSS), extended service set (ESS), TRP, network node, network entity, network equipment, or any other suitable term. Base station 102 may be implemented as an aggregated (monolithic) base station having integrated access and backhaul (IAB) nodes, relay nodes, sidelink nodes, baseband units (BBUs) (including CUs and DUs) and RUs, or as a non-aggregated base station including one or more of CUs, DUs, and / or RUs. A set of base stations that may include non-aggregated and / or aggregated base stations may be referred to as next-generation (NG) RAN (NG-RAN).

[0036]

[0058] The core network 120 may include an Access and Mobility Management Function (AMF) 161, a Session Management Function (SMF) 162, a User Plane Function (UPF) 163, Unified Data Management (UDM) 164, one or more location servers 168, and other functional entities. The AMF 161 is a control node that handles signaling between the UE 104 and the core network 120. The AMF 161 supports registration management, connection management, mobility management, and other functions. The SMF 162 supports session management and other functions. The UPF 163 supports packet routing, packet forwarding, and other functions. The UDM 164 supports authentication and key agreement (AKA) certificate generation, user identification processing, access authorization, and subscription management. One or more location servers 168 are shown as including a Gateway Mobile Location Center (GMLC) 165 and a Location Management Function (LMF) 166. However, generally, one or more location servers 168 may include one or more location / positioning servers, which may include one or more of the GMLC 165, LMF 166, position determination entity (PDE), serving mobile location center (SMLC), mobile positioning center (MPC), etc. The GMLC 165 and LMF 166 support UE location services. The GMLC 165 provides an interface for clients / applications (e.g., emergency services) that access UE positioning information.LMF166 receives measurement and support information from NG-RAN and UE104 via AMF161 to calculate the position of UE104. NG-RAN may utilize one or more positioning methods to determine the position of UE104. Positioning UE104 may include signal measurement, position estimation, and an optional speed calculation based on these measurements. Signal measurement may be performed by UE104 and / or base station 102 servicing UE104. The signals measured include satellite positioning systems (SPS) 170 (e.g., one or more of the following: Global Navigation Satellite System (GNSS), global position system (GPS), non-terrestrial network (NTN), or other satellite position / location systems), LTE signals, wireless local area network (WLAN) signals, Bluetooth signals, terrestrial beacon systems (TBS), sensor-based information (e.g., barometric pressure sensors, motion sensors), NR enhanced cell ID (NR E-CID) methods, NR signals (e.g., multi-round trip time (Multi-RTT), DL angle-of-departure (DL-AoD), DL time difference of arrival (DL-TDOA), UL time difference of It may be based on one or more of the following: arrival (UL-TDOA), and UL angle-of-arrival (UL-AoA) positioning, and / or other systems / signals / sensors.

[0037]

[0059] Examples of UE104 include cellular phones, smartphones, session initiation protocol (SIP) phones, laptops, personal digital assistants (PDAs), satellite radios, global positioning systems, multimedia devices, video devices, digital audio players (e.g., MP3 players), cameras, game consoles, tablets, smart devices, wearable devices, vehicles, electric meters, gas pumps, large or small kitchen appliances, healthcare devices, implants, sensors / actuators, displays, or any other similar functional devices. Some of the UE104 may be called IoT devices (e.g., parking meters, gas pumps, toasters, vehicles, cardiac monitors, etc.). The UE104 may also be called a station, mobile station, subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, or any other suitable term. In some scenarios, the term UE can also be applied to one or more companion devices in a device constellation configuration, for example. One or more of these devices may have collective access to the network, and / or access to the network individually.

[0038]

[0060] Referring again to Figure 1, in a particular embodiment, the UE 104 may include a positioning component 198 which sends a request to a network entity for support data to perform UE-based positioning, the request including at least one of the UE's location information or a list of anchors observed by the UE, and based on the request, receives support data for UE-based positioning from the network entity, the support data including a list of virtual anchors and a list of PRUs including a set of VPRUs, the list of virtual anchors and the list of PRUs being selected based on at least one of the UE's location information or a list of anchors observed by the UE, and performs UE-based positioning using at least one virtual anchor and at least one VPRU in the support data.

[0039]

[0061] In a particular embodiment, the base station 102 may have virtual anchors and base station configuration components 199 which receive requests from the UE for support data for performing UE-based positioning, the requests comprising at least one of the UE's location information or a list of anchors observed by the UE, and transmits support data for UE-based positioning to the UE based on the request, the support data comprising a list of virtual anchors and a list of PRUs including a set of VPRUs, the list of virtual anchors and the list of PRUs being selected based on at least one of the UE's location information or a list of anchors observed by the UE.

[0040]

[0062] Figure 2A is Figure 200, which shows an example of a first subframe in a 5G NR frame configuration. Figure 2B is Figure 230, which shows an example of a DL channel in a 5G NR subframe. Figure 2C is Figure 250, which shows an example of a second subframe in a 5G NR frame configuration. Figure 2D is Figure 280, which shows an example of a UL channel in a 5G NR subframe. A 5G NR frame configuration can be frequency division duplexed (FDD), where a subframe within a set of subcarriers is dedicated to either DL or UL for a given set of subcarriers (carrier system bandwidth), or it can be time division duplexed (TDD), where a subframe within a set of subcarriers is dedicated to both DL and UL for a given set of subcarriers (carrier system bandwidth). In the examples provided in Figures 2A and 2C, it is assumed that the 5G NR frame configuration is TDD, subframe 4 is configured using slot format 28 (mostly DL), where D is DL, U is UL, and F is flexible for use between DL and UL, and subframe 3 is configured using slot format 1 (all UL). Subframes 3 and 4 are shown with slot formats 1 and 28 respectively, but any particular subframe can be configured to have any of the various available slot formats 0 to 61. Slot formats 0 and 1 are all DL and UL, respectively. The other slot formats 2 to 61 include a mixture of DL symbols, UL symbols, and flexible symbols. The UE is configured to have a slot format (dynamically via DL control information (DCI) or semi-statically / statically via Radio Resource Control (RRC) signaling) through the received slot format indicator (SFI). Note that the following description also applies to 5G NR frame configurations that are TDD.

[0041]

[0063] Figures 2A to 2D illustrate a particular frame configuration, and aspects of this disclosure may be applicable to other wireless communication technologies that may have different frame configurations and / or different channels. A frame (10 ms) can be divided into 10 subframes (1 ms) of equal size. Each subframe may contain one or more time slots. A subframe may also contain minislots that may contain 7, 4, or 2 symbols. Each slot may contain 14 or 12 symbols, depending on whether the cyclic prefix (CP) is normal or extended. In the case of a normal CP, each slot may contain 14 symbols, and in the case of an extended CP, each slot may contain 12 symbols. Symbols on the DL may be CP orthogonal frequency division multiplexing (OFDM) symbols. Symbols on the UL can be CP-OFDM symbols (for high-throughput scenarios) or Discrete Fourier Transform (DFT) Spread OFDM (DFT-s-OFDM) symbols (for power-limited scenarios, when limited to single-stream transmission). The number of slots within a subframe is based on CP and numerical logic. Numerology defines the subcarrier spacing (SCS) (see Table 1). Symbol length / duration can be scaled by 1 / SCS.

[0042] [Table 1]

[0043]

[0064] For a normal CP (14 symbols / slot), different Numerology μ0-4 allow 1, 2, 4, 8, and 16 slots per subframe, respectively. For an extended CP, Numerology 2 allows 4 slots per subframe. Therefore, for normal CP and Numerology μ, 14 symbols / slot and 2 μSlots / subframes exist. The subcarrier spacing is 2 μ* μ may be equal to 15 kHz, and μ is numerology 0 to 4. Therefore, numerology μ=0 has a subcarrier interval of 15 kHz, and numerology μ=4 has a subcarrier interval of 240 kHz. Symbol length / duration is inversely proportional to the subcarrier interval. Figures 2A to 2D provide an example of a normal CP with 14 symbols per slot and a numerology μ=2 with 4 slots per subframe. The slot duration is 0.25 ms, the subcarrier interval is 60 kHz, and the symbol duration is approximately 16.67 μs. Within a set of frames, there may be one or more different bandwidth parts (BWPs) (see Figure 2B) that are frequency-division multiplexed. Each BWP may have a specific numerology and CP (normal or extended).

[0044]

[0065] A resource grid can be used to represent the frame structure. Each time slot contains a resource block (RB) (also called physical RBs, PRBs) spanning 12 consecutive subcarriers. The resource grid is divided into multiple resource elements (REs). The number of bits carried by each RE depends on the modulation scheme.

[0045]

[0066] As shown in Figure 2A, some of the REs carry reference signals (RS) related to the UE. RS may include demodulation RS (DM-RS) (shown as R for one specific configuration, but other DM-RS configurations are possible) and channel state information reference signals (CSI-RS) for channel estimation in the UE. RS may also include beam measurement RS (BRS), beam refinement RS (BRRS), and phase tracking RS (PT-RS).

[0046]

[0067] Figure 2B shows an example of various DL channels within a frame subframe. A physical downlink control channel (PDCCH) carries DCI within one or more control channel elements (CCEs) (e.g., one, two, four, eight, or sixteen CCEs), each CCE containing six RE groups (REGs), each REG containing twelve consecutive REs within the OFDM symbol of the RB. A PDCCH within a single BWP may be called a control resource set (CORESET). The UE is configured to monitor PDCCH candidates within a PDCCH search space (e.g., common search space, UE-specific search space) during PDCCH monitoring occasions on the CORESET, in which case these PDCCH candidates have different DCI formats and different aggregation levels. Additional BWPs can be placed across the channel bandwidth at higher and / or lower frequencies. A primary synchronization signal (PSS) may be present within symbol 2 of a specific subframe of the frame. The PSS is used by UE104 to determine the timing of the subframe / symbol and the physical layer identification information. A secondary synchronization signal (SSS) may be present within symbol 4 of a specific subframe of the frame. The SSS is used by UE to determine the group number of the physical layer cell identification information and the timing of the radio frame. Based on the physical layer identification information and the group number of the physical layer cell identification information, UE can determine the physical cell identifier (PCI). Based on the PCI, UE can determine the location of the DM-RS.A physical broadcast channel (PBCH) carrying a master information block (MIB) can be logically grouped with PSS and SSS to form a synchronization signal (SS) / PBCH block (also called an SS block (SSB)). The MIB provides the number of RBs within the system bandwidth and the system frame number (SFN). The physical downlink shared channel (PDSCH) carries user data, broadcast system information not transmitted through the PBCH such as system information blocks (SIBs), and paging messages.

[0047]

[0068] As shown in Figure 2C, some REs carry DM-RS (shown as R for one particular configuration, but other DM-RS configurations are possible) for channel estimation at the base station. UEs may transmit DM-RS for the physical uplink control channel (PUCCH) and DM-RS for the physical uplink shared channel (PUSCH). PUSCH DM-RS may be transmitted within the first one or two symbols of a PUSCH. PUCCH DM-RS may be transmitted in different configurations depending on whether a short or long PUCCH is transmitted and the specific PUCCH format used. UEs may transmit sounding reference signals (SRS). SRS may be transmitted within the last symbol of a subframe. SRS may have a comb structure, and UEs may transmit SRS in one of those combs. SRS may be used by base stations for channel quality estimation to enable frequency-dependent scheduling on the UL.

[0048]

[0069] Figure 2D shows an example of various UL channels within a frame subframe. In one configuration, the PUCCH may be arranged as shown. The PUCCH carries uplink control information (UCI), such as scheduling requests, channel quality indicators (CQI), precoding matrix indicators (PMI), rank indicators (RI), and hybrid automatic repeat request (HARQ) acknowledgment (ACK) (hybrid automatic repeat request acknowledgment, HARQ-ACK) feedback (i.e., one or more HARQ ACK bits indicating one or more ACKs and / or negative ACKs, NACKs). The PUCCH may carry data and, in addition, buffer status reports (BSR), power headroom reports (PHR), and / or UCI.

[0049]

[0070] Figure 3 is a block diagram showing base station 310 communicating with UE350 in an access network. In DL, Internet Protocol (IP) packets can be provided to controller / processor 375. Controller / processor 375 implements Layer 3 and Layer 2 functions. Layer 3 includes the Radio Resource Control (RRC) layer, and Layer 2 includes the Service Data Adaptive Protocol (SDAP) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, and Medium Access Control (MAC) layer. The controller / processor 375 includes RRC layer functions associated with broadcasting system information (e.g., MIB, SIB), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection correction, and RRC connection release), mobility between radio access technologies (RATs), and measurement settings for UE measurement reporting; PDCP layer functions associated with header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functions associated with forwarding upper-layer packet data units (PDUs), error correction via ARQ, concatenation, segmentation, and reassembly of RLC service data units (SDUs), resegmentation of RLC data PDUs, and sorting of RLC data PDUs; and mapping between logical channels and transport channels, multiplexing MAC SDUs onto transport blocks (TBs), and MAC from TBs. It provides MAC layer functionality associated with SDU demultiplexing, scheduling information reporting, error correction via HARQ, priority processing, and logical channel prioritization.

[0050]

[0071] The transmit (TX) processor 316 and the receive (RX) processor 370 implement Layer 1 functions associated with various signal processing functions. Layer 1, including the physical (PHY) layer, may include error detection on the transport channel, forward error correction (FEC) coding / decoding of the transport channel, interleaving, rate matching, mapping to the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. The TX processor 316 processes mapping to a signal constellation based on various modulation schemes (e.g., binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM)). The coded and modulated symbols can then be divided into parallel streams. Next, each stream can be mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., a pilot) in the time domain and / or frequency domain, and then combined together using an Inverse Fast Fourier Transform (IFFT) to generate a physical channel that carries the time-domain OFDM symbol stream. This OFDM stream is spatially precoded to generate multiple spatial streams. The channel estimate from the channel estimator 374 can be used to determine the coding and modulation scheme and for spatial processing. The channel estimate can be derived from the reference signal and / or channel state feedback transmitted by the UE 350. Each spatial stream can then be provided to different antennas 320 via separate transmitters 318Tx. Each transmitter 318Tx can modulate a radio frequency (RF) carrier on its respective spatial stream for transmission.

[0051]

[0072] In UE350, each receiver 354Rx receives signals through its respective antenna 352. Each receiver 354Rx reconstructs the information modulated on the RF carrier and provides this information to the receiver (RX) processor 356. The TX processor 368 and RX processor 356 implement Layer 1 functions associated with various signal processing functions. The RX processor 356 can perform spatial processing on the information to reconstruct any spatial stream destined for UE350. If multiple spatial streams are destined for UE350, the RX processor 356 can combine them into a single OFDM symbol stream. The RX processor 356 then uses a Fast Fourier Transform (FFT) to convert the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal contains a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, and the reference signal, are reconstructed and demodulated by determining the most likely signal constellation point transmitted by the base station 310. These soft decisions can be obtained based on channel estimates calculated by the channel estimator 358. The soft decisions are then decoded and deinterleaved to reconstruct the data and control signals initially transmitted by the base station 310 on the physical channel. These data and control signals are then provided to the controller / processor 359, which implements Layer 3 and Layer 2 functions.

[0052]

[0073] The controller / processor 359 can be associated with memory 360, which stores program code and data. Memory 360 may be called computer-readable media. In UL, the controller / processor 359 performs demultiplexing between transport and logical channels, packet reassembly, decoding, header decompression, and control signal processing to reconstruct IP packets. The controller / processor 359 is also responsible for error detection using the ACK and / or NACK protocols to support HARQ operation.

[0053]

[0074] Similar to the functions described in relation to DL transmission by base station 310, the controller / processor 359 provides RRC layer functions associated with acquiring system information (e.g., MIB, SIB), RRC connection, and measurement reporting; PDCP layer functions associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functions associated with transferring upper-layer PDUs, error correction via ARQ, concatenation, segmentation, and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and sorting of RLC data PDUs; and MAC layer functions associated with mapping logical channels to transport channels, multiplexing MAC SDUs onto TB, demultiplexing MAC SDUs from TB, scheduling information reporting, error correction via HARQ, priority processing, and logical channel prioritization.

[0054]

[0075] The channel estimate derived by the channel estimator 358 from a reference signal or feedback transmitted by the base station 310 can be used by the TX processor 368 to select an appropriate coding and modulation scheme and to facilitate spatial processing. The spatial stream generated by the TX processor 368 can be provided to different antennas 352 via separate transmitters 354Tx. Each transmitter 354Tx can modulate the RF carrier in its respective spatial stream for transmission.

[0055]

[0076] UL transmission is processed at base station 310 in a manner similar to that described for receiver functions in UE350. Each receiver 318Rx receives the signal through its corresponding antenna 320. Each receiver 318Rx reconstructs the information modulated on the RF carrier and provides this information to RX processor 370.

[0056]

[0077] The controller / processor 375 can be associated with memory 376, which stores program code and data. Memory 376 may be called computer-readable media. In UL, the controller / processor 375 performs demultiplexing between transport and logical channels, packet reassembly, decoding, header decompression, and control signal processing to reconstruct IP packets. The controller / processor 375 is also responsible for error detection using the ACK and / or NACK protocols to support HARQ operation.

[0057]

[0078] At least one of the TX processor 368, RX processor 356, and controller / processor 359 may be configured to perform an action related to the positioning component 198 shown in Figure 1.

[0058]

[0079] At least one of the TX processor 316, RX processor 370, and controller / processor 375 may be configured to perform an action related to the component 199 of the virtual anchor and base station configuration in Figure 1.

[0059]

[0080] Figure 400 shows an example of UE positioning based on reference signal measurements (which may also be referred to as "network-based positioning") according to various aspects of this disclosure. UE404 is time T SRS_TX UL-SRS412 is transmitted at time T PRS_RX At this point, DL positioning reference signals (PRS) (DL positioning reference signals, DL-PRS) 410 can be received. TRP406 is time T SRS_RX UL-SRS412 is received at time T PRS_TXIn this case, DL-PRS410 can be transmitted. UE404 can receive DL-PRS410 before transmitting UL-SRS412, or can transmit UL-SRS412 before receiving DL-PRS410. In both cases, a positioning server (e.g., location server(s) 168) or UE404 can determine RTT414 based on ||T SRS_RX -T PRS_TX |-|T SRS_TX -T PRS_RX ||. Therefore, multi-RTT positioning can utilize the UE Rx-Tx time difference measurement values of downlink signals received from multiple TRPs 402, 406 and measured by UE404 (i.e., |T SRS_TX -T PRS_RX |) and the DL-PRS reference signal received power (RSRP) (DL-PRS-RSRP), and the measured TRP Rx-Tx time difference measurement values in multiple TRPs 402, 406 of the uplink signal transmitted from UE404 (i.e., |T SRS_RX -T PRS_TX |) and UL-SRS-RSRP. UE404 measures the UE Rx-Tx time difference measurement value (and optionally the DL-PRS-RSRP of the received signal) using the assistance data received from the positioning server, and TRPs 402, 406 measure the gNB Rx-Tx time difference measurement value (and optionally the UL-SRS-RSRP of the received signal) using the assistance data received from the positioning server. These measurement values can be used in the positioning server or UE404 to determine the RTT, and the RTT is used to estimate the position of UE404. For example, other methods for determining the RTT are possible, such as using DL-TDOA and / or UL-TDOA measurement values.

[0060]

[0081] PRS may be defined for network-based positioning (e.g., NR positioning) to enable the UE to detect and measure more neighboring transmit and receive points (TRPs), and multiple configurations are supported to allow various deployments (e.g., indoor, outdoor, sub-6, mmW, etc.). Beam sweep may be further configured for PRS to support PRS beam operation. UL positioning reference signals may be based on sounding reference signals (SRSs) with extensions / adjustments for positioning purposes. In some examples, UL-PRS may be referred to as "SRS for positioning," and new information elements (IEs) may be configured for SRS for positioning in RRC signaling.

[0061]

[0082] DL PRS-RSRP can be defined as a linear average of the power contributions (in watts) of resource elements of one or more antenna ports carrying the DL PRS reference signal configured for RSRP measurement within the measurement frequency bandwidth under consideration. In some examples, for FR1, the reference point for DL ​​PRS-RSRP may be the antenna connector of the UE. For FR2, DL PRS-RSRP may be measured based on the combined signal from the antenna elements corresponding to a given receiver branch. For FR1 and FR2, if receiver diversity is in use by the UE, the reported DL PRS-RSRP value may not be lower than the corresponding DL PRS-RSRP of any of the individual receiver branches. Similarly, UL SRS-RSRP can be defined as a linear average of the power contributions (in watts) of resource elements carrying the sounding reference signal (SRS). UL SRS-RSRP may be measured over configured resource elements within the measurement frequency bandwidth under consideration during a configured measurement time opportunity. In some cases, for FR1, the reference point for UL SRS-RSRP may be the antenna connector of the base station (e.g., gNB). For FR2, UL SRS-RSRP may be measured based on the combined signal from the antenna elements corresponding to a given receiver branch. For FR1 and FR2, if receiver diversity is in use by the base station, the reported UL SRS-RSRP value may not be lower than the corresponding UL SRS-RSRP of any of the individual receiver branches.

[0062]

[0083] The PRS path RSRP (PRS-RSRPP) can be defined as the linear average power of the channel response at the i-th path delay of the resource element carrying the DL PRS signal configured for measurement, where DL PRS-RSRPP for the first path delay is the power contribution corresponding to the path detected first in time. In some examples, the PRS path phase measurement may refer to the phase associated with the i-th path of the channel derived using the PRS resource.

[0063]

[0084] DL-AoD positioning can utilize the measured DL-PRS-RSRP of downlink signals received from multiple TRP402 and 406 in the UE404. The UE404 measures the DL-PRS-RSRP of the received signal using support data received from the positioning server, and the resulting measurement is used along with the azimuth angle of departure (A-AoD), zenith angle of departure (Z-AoD), and other configuration information to determine the position of the UE404 relative to neighboring TRP402 and 406.

[0064]

[0085] DL-TDOA positioning can utilize the DL reference signal time difference (RSTD) (and optionally DL-PRS-RSRP) of downlink signals received from multiple TRP402 and 406 in the UE404. The UE404 measures the DL RSTD (and optionally DL-PRS-RSRP) of the received signal using support data received from the positioning server, and the resulting measurement is used along with other configuration information to determine the position of the UE404 relative to neighboring TRP402 and 406.

[0065]

[0086] UL-TDOA positioning can utilize the UL relative time of arrival (RTOA) (and optionally UL-SRS-RSRP) at multiple TRPs 402 and 406 of the uplink signal transmitted from the UE404. TRPs 402 and 406 measure the UL-RTOA (and optionally UL-SRS-RSRP) of the received signal using support data received from the positioning server, and the resulting measurements are used along with other configuration information to estimate the position of the UE404.

[0066]

[0087] UL-AoA positioning can utilize the azimuth angle of arrival (A-AoA) and zenith angle of arrival (Z-AoA) measured at multiple TRPs 402 and 406 of the uplink signal transmitted from UE404. TRPs 402 and 406 measure the A-AoA and Z-AoA of the received signal using support data received from the positioning server, and the resulting measurements are used along with other configuration information to estimate the position of UE404. For the purposes of this disclosure, the operation in which the UE provides measurements used in the calculation of the UE's position to the base station / positioning entity / server may be described as “UE-assisted,” “UE-assisted positioning,” and / or “UE-assisted position calculation,” while a positioning operation in which the UE measures and calculates its own position may be described as “UE-based,” “UE-based positioning,” and / or “UE-based position calculation.”

[0067]

[0088] For example, additional positioning methods, such as UE-side UL-AoD and / or DL-AoA, can be used to estimate the location of the UE404. Note that data / measurements from various technologies can be combined in various ways to improve accuracy, determine and / or enhance certainty, supplement / complement measurements, and / or replace / provide missing information. For example, some UE positioning mechanisms may be radio access technology (RAT) dependent, such as downlink positioning (e.g., measurement of observed time-to-arrival difference (OTDOA)), uplink positioning (e.g., measurement of uplink time-to-arrival difference (UTDOA)), and / or combined DL and UL-based positioning (e.g., measurement of round-trip time to neighboring cells) (e.g., UE positioning is RAT-based). Some wireless communication systems may also support extended cell ID (E-CID) positioning procedures based on radio resource management (RRM) measurements. On the other hand, some UE positioning mechanisms may be RAT-independent, such as extended GNSS, and / or positioning techniques based on WLAN, Bluetooth, terrestrial beacon systems (TBS), and / or sensor-based (e.g., barometric pressure sensors, motion sensors) (e.g., UE positioning is not RAT-dependent). Some UE positioning mechanisms may be based on hybrid models, using multiple methods for positioning, and may include both RAT-dependent and RAT-independent positioning techniques (e.g., GNSS with OTDOA hybrid positioning).

[0068]

[0089] It should be noted that the terms “positioning reference signal” and “PRS” generally refer to specific reference signals used for positioning in NR and LTE systems. However, as used herein, the terms “positioning reference signal” and “PRS” may also refer to any type of reference signal that can be used for positioning, including but not limited to PRS as defined in LTE and NR, TRS, PTRS, CRS, CSI-RS, DMRS, PSS, SSS, SSB, SRS, UL-PRS, etc. Furthermore, the terms “positioning reference signal” and “PRS” may refer to downlink or uplink positioning reference signals unless otherwise indicated by the context. To further distinguish between types of PRS, downlink positioning reference signals may be called “DL-PRS,” and uplink positioning reference signals (e.g., positioning SRS, PTRS) may be called “UL-PRS.” In addition, for signals that can be transmitted both uplink and downlink (e.g., DMRS, PTRS), “UL” or “DL” may be prepended to the signal to distinguish direction. For example, "UL-DMRS" can be distinguished from "DL-DMRS".

[0069]

[0090] A device (e.g., a UE) equipped with a Global Navigation Satellite System (GNSS) receiver (which may include a Global Positioning System (GPS) receiver) can determine its location based on GNSS positioning. GNSS is a network of satellites that broadcast timing and orbital information used for navigation and positioning measurements. GNSS may include a group of satellites known as a constellation that broadcast signals (sometimes called GNSS signals) to control GNSS stations and users. Based on the broadcast signals, a user may be able to determine their location (e.g., through a trilateration process). For the purposes of this disclosure, a device (e.g., a UE) equipped with a GNSS receiver or capable of receiving GNSS signals may be referred to as a GNSS device, and a device capable of transmitting GNSS signals, such as a satellite, may be referred to as a spacecraft (SV).

[0070]

[0091] Figure 5 is a figure 500 illustrating an example of GNSS positioning according to various embodiments of the present disclosure. The GNSS device 506 can calculate its position and time at least in part on data (e.g., GNSS signals 504) received from a plurality of spacecraft (SVs) 502, and each SV 502 may carry a record of its position and time and transmit that data (e.g., a record) to the GNSS device 506. Each SV 502 may further include a clock synchronized with other clocks of the SVs and with one or more ground clocks. If the SV 502 detects a drift from the time maintained on the ground, the SV 502 may correct it. The GNSS device 506 may also include a clock, but the clock for the GNSS device 506 may be less stable and accurate compared to the clock for each SV 502.

[0071]

[0092] Since the speed of radio waves is constant and may be independent of satellite speed, the time delay between the time SV 502 transmits the GNSS signal 504 and the time GNSS device 506 receives the GNSS signal 504 may be proportional to the distance from SV 502 to GNSS device 506. In some examples, at least four SVs may be used by GNSS device 506 to calculate / calculate one or more unknown quantities associated with positioning (e.g., three position coordinates and a clock deviation from satellite time).

[0072]

[0093] Each SV 502 may continuously broadcast a GNSS signal 504 (e.g., a modulated carrier wave) which may contain a pseudo-random code (e.g., a sequence of 1s and 0s) that may be known to the GNSS device 506, and may also contain a message including the time of transmission and the SV position at that time. In other words, each GNSS signal 504 may carry two types of information: time and a carrier wave (e.g., a modulated waveform with an electromagnetically transmitted input signal). Based on the GNSS signals 504 received from each SV 502, the GNSS device 506 may measure the time of arrival (ToAs) of the GNSS signal 504 and calculate the time of flight (ToFs) of the GNSS signal 504. Then, based on the ToFs, the GNSS device 506 may calculate its three-dimensional position and clock deviation, and the GNSS device 506 may determine its position on Earth. For example, the location of the GNSS device 506 may be converted to latitude, longitude, and altitude relative to an elliptical Earth model. These coordinates may be displayed on a mobile map display or similar, or they may be recorded or used by some other system, such as a vehicle guidance system.

[0073]

[0094] The distance between a GNSS device and a SV can be calculated based on the time it takes for the GNSS signal to reach the GNSS device, but the SV's signal sequence can be delayed relative to the GNSS device's sequence. Therefore, in some examples, a delay may be applied to the GNSS device's sequence so that the two sequences are matched. For example, to calculate the delay, the GNSS device may match the pseudo-random binary sequence contained in the SV's signal to an internally generated pseudo-random binary sequence. Because it takes time for the SV's GNSS signal to reach the GNSS device, the SV's sequence can be delayed relative to the GNSS device's sequence. By gradually delaying the GNSS device's sequence, the two sequences can eventually be matched.

[0074]

[0095] The accuracy of GNSS-based positioning can depend on various factors such as satellite geometry, signal obstruction, atmospheric conditions, and / or receiver design features / quality. For example, GNSS receivers used by smartphones or smartwatches may have lower accuracy compared to GNSS receivers used by vehicles and surveying equipment. To improve the accuracy of GNSS positioning (e.g., from meters to centimeters), real-time kinematic (RTK) technology or mechanism (hereinafter sometimes collectively referred to as RTK engines) may be used for positioning devices (e.g., UEs, surveying equipment, automotive GNSS systems, etc.). For example, an RTK engine may enable a positioning device to use correction information from a base station to mitigate one or more error sources in GNSS receiver pseudo-range (PR) and carrier phase (CP) measurements, which may include satellite orbit errors, satellite clock errors, and / or atmospheric errors. Thus, better accuracy can be achieved by positioning equipment.

[0075]

[0096] Figure 6 is a figure 600 illustrating an example of RTK positioning according to various aspects of the present disclosure. In one example, at least two receivers may be used in association with RTK positioning, at least one of the receivers may be fixed and may be called a base station 602 or RTK base station, and at least one other receiver may be mobile (e.g., may move from time to time) and may be called a mobile station or mobile station device 604 (e.g., a GNSS / GPS receiver, UE, mobile station, etc.). In other words, an RTK system may include at least a base station and a mobile station, and the base station may be a fixed receiver whose location is known.

[0076]

[0097] The distance between SV 606 (e.g., a GNSS / GPS satellite) and a mobile station device 604, or between SV 606 and a base station 602, can be calculated by determining the number of carrier cycles between SV 606 and the mobile station device 604 or base station 602, and multiplying this number by the carrier wavelength 612 of the carrier wave 610 (e.g., carrier signal) transmitted by SV 606. For example, if SV 606 transmits a carrier wave 610 with a wavelength 612 of 10 meters, and mobile station device 604 receives the carrier wave 610 and determines that there are 500 carrier cycles between SV 606 and mobile station device 604, then mobile station device 604 can calculate the distance between SV 606 and mobile station device 604 by multiplying the determined number of carrier cycles (e.g., 500) by the carrier wavelength 612 (e.g., 10 meters), which could be 5000 meters (e.g., 500 × 10 = 5000). Similarly, base station 602 may also receive a carrier wave 610 from SV 606 and determine its distance from SV 606 based on the wavelength 612 of the carrier wave 610 and the number of carrier cycles between base station 602 and SV 606. Mobile station devices 604 and / or base station 602 may calculate the range (e.g., distance) between mobile station devices 604 / base station 602 and a plurality of (e.g., four or more) SVs (e.g., SVs 606 and 608) to determine their geographical locations (e.g., their locations on Earth).

[0077]

[0098] During RTK positioning, a mobile station device 604 (e.g., a UE, client device, etc.) may undergo an "ambiguity resolution" process to determine the number of carrier cycles between the SV 606 and the mobile station device 604. In other words, once the mobile station device 604 receives a carrier wave from the SV 606, it may take some time for the mobile station device 604 to determine how many carrier cycles there are between the SV 606 and the mobile station device 604. In some cases, GNSS receivers with more advanced or high-end antennas / hardware, such as automotive-grade antennas, may be able to resolve the ambiguity in a relatively short time (e.g., within a few seconds), while GNSS receivers with less advanced or low-end antennas / hardware, such as mobile phone antennas and / or smartwatches, may require a longer time (e.g., 10-30 minutes or more) to resolve the ambiguity. In some cases, the ambiguity may be called an "integer value ambiguity." In some examples, the process by which a GNSS receiver resolves ambiguity can refer to convergence, and the time it takes for the device to resolve the ambiguity can be called the convergence time.

[0078]

[0099] In some scenarios, the distance calculated by the mobile station device 604 may include errors due to SV clock and ephemeris, as well as ionospheric and tropospheric delays. Furthermore, since the mobile station device 604 is likely to be moving, the quality of the signals / carrier waves received from each SV may change as the mobile station device moves from one location to another. For example, if the mobile station device 604 moves from an open-sky area to a buildingd area, signals from one or more SVs 606 / 608 may be blocked / reflected by the building. Therefore, the distance calculated by the mobile station device 604 may begin to drift and may contain errors (one or more).

[0079]

[0100] On the other hand, since base station 602 is likely to be stationary in a known location and may be equipped with a more advanced, high-end GNSS receiver, base station 602 may be able to maintain more accurate distance calculations compared to mobile station device 604. For example, base station 602 may be located in a site (e.g., an open sky area) where environmental influences such as interference and multipath are minimal. Therefore, under RTK positioning, since base station 602 may already know its location (e.g., through prior surveys), base station 602 may perform measurements on the SV to obtain base receiver measurements (e.g., to estimate the difference between the base station and the SV). Then, base station 602 may subtract the geometric distance between the base station location and the SV location from the base receiver measurements to obtain base correction (e.g., based on the difference or error). Based on the obtained base correction, base station 602 may generate correction data 614 (or correction signal) and transmit the correction data 614 to the mobile station device 604 to assist the mobile station device 604 in correcting the error. For example, since a mobile station device 604 may typically be configured to be located close to a base station 602 (e.g., within 6 or 12 miles), it is likely to encounter similar errors to the base station 602 (e.g., similar ionospheric and tropospheric delays). Therefore, the mobile station device 604 can use correction data 614 from the base station 602 to improve and quickly process its own calculated position from the GNSS constellation to achieve centimeter accuracy. In other words, the base station may remain in a fixed / known location and be configured to transmit correction data to one or more mobile station devices, which may use the correction data to increase the accuracy of their positioning and the speed of error correction. Thus, the mobile station device 604 may determine its position using an algorithm that incorporates ambiguity resolution and differential correction. The position accuracy achievable by the mobile station device 604 may depend on its distance from the base station 602 and the accuracy of the differential correction (e.g., correction data 614).

[0080]

[0101] In some cases, software or applications that receive positioning-related measurements from a GNSS chipset and / or sensors to estimate a device's position, speed, and / or altitude may be called a positioning engine. In addition, a positioning engine capable of achieving a certain high level of accuracy (e.g., centimeter / decimeter level accuracy) and / or latency may be called a precision positioning engine (PPE). For example, a positioning engine capable of performing RTK (e.g., receiving or processing correction data associated with RTK) may be considered a PPE.

[0081]

[0102] The accuracy of network-based positioning can depend on various factors, including the capabilities of the UE, the location of the UE, and the number of transmit and receive points (TRPs). For example, a low-end UE (or a UE with lower capabilities) may have lower transmit / receive capabilities and / or measurement capabilities compared to a high-end UE (or a UE with higher capabilities). Therefore, a low-end UE may provide lower accuracy for network-based positioning compared to a high-end UE.

[0082]

[0103] To improve the accuracy of network-based positioning, a Positioning Reference Unit (PRU) may be used to assist positioning devices (e.g., UEs, surveying equipment, automotive GNSS systems, etc.) when performing positioning. A PRU may be similar to an RTK base station. For example, a positioning engine may enable a positioning device to use measurements or correction information from the PRU to mitigate one or more sources of error in the positioning device's measurements. Thus, the positioning device may achieve better accuracy.

[0083]

[0104] In some examples, a PRU may refer to a device with a known location that can perform positioning measurements (e.g., RSTD, RSRP, UE Rx-Tx time difference measurements, etc.) and report these measurements to a location server (e.g., LMF). For example, a PRU could be a UE or a TRP with a known location. In addition, a PRU may transmit an SRS to enable one or more TRPs to measure and report UL positioning measurements (e.g., RTOA, UL-AoA, base station Rx-Tx time difference measurements, etc.) from the PRU at a known location. PRU measurements may be compared by the location server to expected measurements at the known PRU location to determine correction information for other nearby target devices. DL and / or UL location measurements for other target devices may then be corrected based on the correction information.

[0084]

[0105] Figure 7 is Figure 700, which shows an exemplary PRU in various aspects of the present disclosure. UE 702 may be configured to measure a first PRS (PRS 1) transmitted from a first TRP 708 and a second PRS (PRS 2) transmitted from a second TRP 710. PRU 704 may also be configured to measure a first PRS transmitted from a first TRP 708 and a second PRS transmitted from a second TRP 710. PRU 704 may then provide its measurements, support data, and / or correction data to other UEs (e.g., UE 702, or a UE adjacent to PRU 704) to help the other UEs achieve high-precision positioning. For example, a positioning engine 706 (which may be located in the UE 702 or in the location server) may receive raw measurements from the UE 702 (for example, for the first PRS and the second PRS) and measurement / correction data from the PRU 704, and the positioning engine 706 may apply or merge the measurement / correction data from the PRU 704 with the raw measurements from the UE 702 to reduce / eliminate errors (one or more) in the raw measurements.

[0085]

[0106] PRU 704 can be used for both terrestrial network (NT)-based positioning and non-terrestrial network (NTN)-based positioning. In some scenarios, a UE may have the ability to communicate with a server or another UE via NTN. NTN can refer to a network or segment of a network that uses at least one airborne device (e.g., an aircraft) or satellite (e.g., low Earth orbit (LEO) satellites, medium Earth orbit (MEO) satellites, geostationary Earth orbit (GEO) satellites, high elliptical orbit (HEO) satellites, and / or high-altitude pseudosatellites (HAPS)) for communication (e.g., to transmit or receive data). For example, NTN may support direct communication between a UE (e.g., a handset, mobile phone) and a satellite (e.g., a LEO satellite, a GEO satellite), and the UE may transmit data (e.g., text messages and / or voice services) to another UE via satellite. For the purposes of this disclosure, NTN may include only NTN cells, or a mixture of NTN cells and ground cells. Therefore, in the case of positioning operations associated with NTN, the positioning operations may include NTN cells without ground cells, a mixture of NTN and ground cells, and / or hybrid solutions involving NTN cells, ground cells, GNSS satellites, and / or other ground-based positioning reference points such as WiFi and Bluetooth. In some examples, a gateway associated with NTN may be configured to function like a PRU.

[0086]

[0107] For example, the NTN architecture may be configured to be based on a transparent payload. For instance, a data network (e.g., a 5G core (5GC) network) may be connected to a base station (e.g., a network entity, gNB) via a communication interface (e.g., a next-generation (NG) interface). The base station may be located on the ground and connected to an NTN gateway, which may be connected to an NTN payload (e.g., a network node mounted on a satellite, unmanned aerial system (UAS), or HAPS, etc.) via a feeder link. The NTN gateway may refer to a node in the network that acts as a repeater between the satellite and the UE, as the link budget between the satellite and the UE may be limited. The NTN gateway may have better Tx power or a larger antenna for communicating with the satellite compared to the UE. The NTN payload may be connected to the UE via a service link (e.g., using the UE-UTRAN (Uu) interface). Under the transparent payload NTN architecture, the base station may be a ground station, and the NTN payload (e.g., a satellite) may function as a repeater, providing radio frequency filtering, frequency conversion, and / or amplification for data / payload received from the base station via the NTN gateway, and relaying / transmitting the data / payload to the UE. Thus, the waveform or signal relayed / repeated by the NTN payload may remain unchanged.

[0087]

[0108] The PRU 704 may be stationary or moving, and the PRU 704 may be any device having the ability to measure a reference signal and / or transmit a reference signal. For example, the PRU 704 may be a UE / TRP / RSU capable of transmitting a reference signal to and / or receiving a reference signal from other devices. Since the PRU can measure reference signals transmitted from multiple devices (e.g., TRPs), the accuracy of difference-based positioning can be greatly improved. For the purposes of this disclosure, difference-based positioning may refer to any positioning method / mechanism that involves measuring the difference (one or more) between two receiving (Rx) nodes. For example, difference-based positioning may include double difference (DD)-time difference in arrival (TDoA) (DD-TDoA), DD-round-trip time (RTT) (DD-RTT), single difference RTT (D-RTT), (same Tx, different Rx), D / DD-AoD, D / DD-AoA, D / DD-carrier phase, etc.

[0088]

[0109] A PRU (e.g., PRU 704) may transmit its measured values, support data, and / or correction data to a location server (e.g., LMF) or to the UE (e.g., via a sidelink (SL) or via the location server). For example, in UE-based positioning configured so that the UE determines its own location, the UE may be specified to receive measured values, support data, and / or correction data from the PRU, and the UE may also be specified to know the locations of the PRU and TRP (e.g., to calculate its location). Correction data may be used by the UE to compensate for (e.g., cancel) various types of errors, such as TRP / UE group delay, synchronization error across TRPs, initial Tx / Rx carrier phase bias, and / or anchor location error. In some examples, anchor location error cancellation may not be accurate if the PRU and UE are far apart from each other. For the purposes of this disclosure, a device that transmits and / or receives a reference signal during UE positioning may be referred to as an anchor. For example, the anchor could be a fixed TRP that transmits PRS to a UE via Uu link, or a mobile UE that transmits a reference signal to another UE via sidelink (e.g., during sidelink positioning), or an anchor that is an NTN-affiliated satellite that transmits GNSS signals to a UE, and so on.

[0089]

[0110] While a PRU can improve the accuracy of UE-based positioning for a UE, the UE may be required to know the location of the PRU and its corresponding anchor (e.g., TRP, satellite, etc.) in order to determine / estimate its position. In some scenarios or areas, there may be privacy concerns or regulations regarding the sharing of anchor and / or PRU location information. For example, a network operator (e.g., for NT and NTN) may have strong concerns about disclosing the location of its TRP(s), gateway(s), and / or PRU(s). When the PRU is a UE, the UE may also be required to adhere to certain privacy protocols to protect the privacy of its users.

[0090]

[0111] The embodiments presented herein may enable a UE to achieve high-precision positioning without knowing the location of specific network nodes, such as PRUs and TRPs (one or more). The embodiments presented herein may enable a UE to perform positioning (e.g., UE-based positioning) using virtual PRUs (VPRUs) and / or virtual anchors, such that PRUs / anchors can provide the UE with measured values, reference signals, support data, and / or correction data without disclosing their actual locations. In one embodiment of this disclosure, a VPRU may indicate that there is no physical PRU (PPRU) located at the requested location of the VPRU, and measured values, support data, and / or correction data may be virtually generated for the UE based on VPRU and / or PPRU information / measurements. Thus, the network may generate a VPRU or virtual reference station for the UE at any location. Measured values, support data, and / or correction data from the VPRU may be based on measured values ​​from one or more physical PRUs and / or based on the network resolving / tracking various error source values.

[0091]

[0112] By enabling UEs to perform positioning using virtual anchors (e.g., TRP / satellites), carrier operators (e.g., operators for location servers, LMFs, NTN, etc.) can avoid disclosing / providing the precise or true location of their network nodes, such as anchor base stations and / or anchor satellites, thereby maintaining privacy and security for these network nodes. In addition, in the case of mobile anchors such as mobile UEs associated with side-link positioning or LEO satellites associated with NTN, the location of these mobile anchors may be difficult to estimate and share with the UE in real time. Therefore, using virtual anchors may be more preferable and convenient for UEs to perform positioning. The embodiments presented herein may allow the anchor's ground truth location to be protected from noise, and if the UE uses noisy anchor location information without a PRU, positioning accuracy may be degraded. Similarly, by enabling UEs to perform positioning using a VPRU, carrier operators or PRUs can also avoid disclosing / providing the precise or true ground location of the PRU, thereby maintaining privacy and security for the PRU. The location of the VPRU can be pre-assigned (for example, NTN may be more preferable) or generated based on the location of the target UE (e.g., the generated VPRU is close to the target UE). Embodiments presented herein may enable the UE to achieve high-precision positioning by allowing the UE to cancel common anchor location errors (e.g., using correction data from the PRU). Furthermore, while a physical PRU may not be able to receive measurements and / or signals from the same set of anchors as the UE, using a VPRU may enable the measurements from the VPRU to be associated with one or more common anchors of the UE. In other words, using a virtual PRU may ensure that the measurements are from common anchors.

[0092]

[0113] In one aspect of this disclosure, a network may generate a virtual anchor (e.g., a virtual TRP, virtual UE, or virtual satellite) by applying a location / distance / vector offset (which may be called noise or error) to the actual location of an anchor (sometimes called a ground truth location). Generally, in the case of UE-based positioning, a location server may transmit the precise locations of anchors involved in positioning (e.g., TRPs (one or more), UEs (one or more), and / or satellites (one or more)) to a target UE (e.g., the UE whose location is determined) via supporting data. However, by using a virtual anchor, the network may instead transmit a noisy / virtual anchor location to the UE.

[0093]

[0114] Figure 8 is a figure 800 illustrating an example of the generation of a virtual anchor or the protection of the true location of a physical anchor according to various aspects of this disclosure. In one example, as shown in 802, a physical anchor (e.g., TRP) may be located at a ground location sometimes called a ground truth location. For a mobile anchor (e.g., UE, satellite, etc.), the ground truth location may correspond to the anchor's current location (which may be in the air / space in the case of a satellite).

[0094]

[0115] As shown in 804, in order to generate virtual anchors (or to protect the ground truth location of physical anchors), the network may apply an anchor location error to the ground truth location of a physical anchor so that the virtual anchor is generated at a virtual location sometimes called a noisy anchor location. In other words, the noisy anchor location of a virtual anchor may be equal to the ground truth location of the physical anchor plus the anchor location error (e.g., noisy anchor location = ground truth location + anchor location error). For example, the anchor location error may correspond to a location / distance / vector offset that sets the virtual anchor to X meters / kilometers in a particular direction from the physical anchor. In another example, the anchor location error may correspond to a coordinate offset that sets the virtual anchor to a specified latitude and longitude in a geographic coordinate system. In some examples, based on privacy specifications, the mean and / or variance of the anchor location error may be configured to vary. For example, the anchor location error may follow a specific type of distribution for privacy protection (e.g., Laplace distribution, truncated Gaussian, etc.). In some examples, the anchor location error may be applied to multiple physical anchors to generate multiple virtual anchors. In other examples, different anchor location errors may be applied to different physical anchors.

[0095]

[0116] After generating virtual anchors, the network may configure the UE to perform positioning using the virtual anchors based on the noisy anchor locations of the virtual anchors (and also based on the VPRU described below). For example, the network may provide the UE with a list of virtual anchors having those noisy anchor locations via support data, so that the UE can perform positioning using one or more virtual anchors from the list based on those noisy anchor locations. In some examples, a new virtual anchor location information element (IE) may be added to the support data for a particular positioning scheme, such as for UE-based positioning using a double-difference (DD) scheme. Since the UE may not recognize that an anchor is a virtual anchor, the virtual anchor location IE may indicate to the UE that a particular anchor is a virtual anchor. In the case of virtual anchors, the UE may transmit a reference signal (e.g., SRS) to the virtual anchor and / or receive a reference signal (e.g., PRS) from the virtual anchor, the signals being transmitted from and received by the corresponding physical anchor. In other words, the UE may treat a virtual anchor as a physical anchor.

[0096]

[0117] In one aspect of the present disclosure, a network may generate a virtual PRU (VPRU) or a set of VPRUs based on one or more physical PRUs, the physical PRUs may be configured to receive reference signals from and / or transmit reference signals to one or more anchors. The physical PRUs may then transmit their measurements for one or more anchors to a server such as a location server or LMF. Based on the measurements from one or more physical PRUs, the server may generate one or more VPRUs that can be used to assist the UE for positioning.

[0097]

[0118] Figures 9 and 10 are Figures 900 and 1000 illustrating an example of creating a VPRU based on a set of physical PRUs according to various aspects of the present disclosure. As shown by Figure 900 of Figure 9, a given area 902 may have a set of physical PRUs, which may include a first physical PRU 904, a second physical PRU 906, a third physical PRU 908, and up to an Nth physical PRU 910, and so on. The set of physical PRUs may be configured to measure / receive reference signals transmitted from one or more anchors and / or transmit reference signals to one or more anchors. For example, the set of physical PRUs may measure PRS transmitted from a first TRP 912 and a second TRP 914 and / or transmit SRS to the first TRP 912 and the second TRP 914.

[0098]

[0119] Next, as shown in 916, a set of physical PRUs may transmit their measurements to a server 918 (e.g., a location server or a network entity such as an LMF). In some examples, the measurements may include the TDoA of the PRS transmitted from the first TRP 912 and the second TRP 914, the RTT between the PRU and the TRP, the AoA of the PRS, and / or the carrier phase of the PRS. Server 918 may also collect uplink (UL) measurements from the first TRP 912 and the second TRP 914 (e.g., to measure reference signals transmitted from a set of physical PRUs). When UE 920 is performing UE-based positioning in a given area 902 and is configured to measure PRS transmitted from the first TRP 912 and the second TRP 914, as shown by Figure 1000 in Figure 10, Server 918 may generate a VPRU 922 in a virtual location adjacent to UE 920, as shown in 924. Server 918 may also calculate / calculate a set of measurements, supporting data, and / or corrected data for VPRU 922 based on measurements from a set of PRUs, a first TRP 912, and / or a second TRP 914, etc. For example, based on TDoA measurements from the first physical PRU 904 and the third physical PRU 908 for PRS transmitted from the first TRP 912 and the second TRP 914, the server 918 may estimate the TDoA measurement of a PRU located between the first physical PRU 904 and the third physical PRU 908 (e.g., a virtual PRU) (for example, if VPRU 922 is configured closer to the first physical PRU 904, the TDoA measurement may be closer to the first physical PRU 904; if VPRU 922 is configured closer to the third physical PRU 908, the TDoA measurement may be closer to the third physical PRU 908, etc.). In one example, the measurements of VPRU 922 may be based on geometric interpolation between measurements from a set of physical PRUs (e.g., based on the distance from VPRU 922 to physical PRUs 904, 906, 908, and 910). In another example, measurements from a set of physical PRUs may be used to estimate errors (e.g., synchronization errors, group delays, etc.).The estimated error can then be added to the error-free virtual measurement of VPRU 922 (for example, based on the ground truth (including location error) of the VPRU location and anchor location). For example, server 918 may estimate the RSTD error between the first TRP 912 and the second TRP 914 based on the third physical PRU 908, and then server 918 may add the estimated RSTD error to the error-free RSTD measurement of VPRU 922. Similarly, server 918 may estimate the RSTD error between the first TRP 912 and the second TRP 914 based on the first physical PRU 904, and server 918 may add the estimated RSTD to the error-free RSTD measurement of VPRU. Server 918 may then transmit the generated measurements, support data, and / or correction data associated with VPRU 922 (and the virtual location of VPRU 922) to UE 920. Based on the measured values, supporting data, correction data, and / or the location of VPRU 922, UE 920 (or the UE's positioning engine) may calculate / estimate its position, as described with respect to Figure 7, by applying the correction data to the measured values ​​of UE 920 itself, or by fusing the measured values ​​associated with VPRU 922 with the measured values ​​of UE 920.

[0099]

[0120] Figure 11 is an example illustrating the generation of a virtual PRU base station for NTN-based positioning based on one or more physical PRU base stations according to various aspects of the present disclosure. Similar to generating a VPRU based on a set of physical PRUs, a virtual PRU base station can be generated by the NTN network based on a set of physical PRU base stations associated with NTN. For example, a set of physical PRU base stations, which may include a first physical PRU base station, a second physical PRU base station, a third physical PRU base station, and up to an Nth physical PRU base station, may be configured to measure / receive positioning reference signals transmitted from one or more satellites. The set of physical PRU base stations may then transmit their positioning reference signal measurements or positioning reference signal observation data for one or more satellites to the LMF.

[0100]

[0121] Next, when the UE is configured to estimate its location, the LMF can generate a virtual PRU base station in a virtual location close to the UE. The LMF can also calculate a set of positioning reference signal measurements / observation data for the virtual PRU base station. Thus, the UE can determine its position using the positioning reference signal measurements / observation data for the virtual PRU base station(s), without knowing its ground truth location(s) or physical PRU base station(s).

[0101]

[0122] Using virtual PRU base stations can reduce the total number of physical PRU base stations deployed in an area. For example, if two physical PRU base stations are about 50 km apart and each physical PRU base station can provide a service coverage radius of about 20-30 km, and each physical PRU base station serves nearby UEs, more than 4,000 PRU base stations may be designated to cover the US continent.

[0102]

[0123] On the other hand, when virtual PRU base stations are used, the distance between two physical PRU base stations can be configured to be even greater, such as between 100 and 200 km, since the virtual PRU base station can be generated for the UE based on the UE's location. In other words, the UE may not be specified to be located close to the physical PRU base station in order to receive the corresponding correction data from the physical PRU base station. The LMF can collect data from the physical PRU base station, estimate the spatial distribution of correlation errors for the virtual PRU base station, and send corrections to the UE based on the virtual PRU base station. Such a configuration can significantly reduce the density of physical PRU base stations deployed (for example, only 400 PRU base stations may be specified instead of 4000 to cover the US continent). This can also improve positioning performance on the client (e.g., UE) side.

[0103]

[0124] In some examples, the LMF may specify that the PRU server knows the location of the UE (e.g., true location or estimated location) so that the LMF can generate a virtual PRU base station near the UE and calculate positioning reference signal observations for the virtual PRU base station. The LMF may correct the carrier phase ambiguity between physical PRU base stations and calculate the error for each physical PRU base station. The LMF may then interpolate the estimated PRU base station error to the location of the virtual PRU base station. The processing of PRU correction data at the UE may be the same as for a physically based PRU base station. For example, the LMF may provide the UE with semi-synthetic positioning reference signal observations (e.g., observed from a virtual PRU base station). Accordingly, the UE may calculate a virtual baseline from the UE to the virtual PRU base station, and the UE may use the virtual baseline and PRU correction data to determine its location.

[0104]

[0125] As explained with respect to Figures 9 to 11, the virtual location of a VPRU or virtual PRU base station (hereinafter collectively referred to as "virtual base station" or "VRS") may be configured to be as close as possible to the actual or estimated location of the UE in order to provide the UE with useful / beneficial measurements, supporting data, and / or corrective data. In some examples, a short baseline (e.g., threshold distance) between the UE and the PRU (or VRS) may be specified or defined for best common anchor error cancellation. For example, the ratio of the distance from the anchor to the UE to the distance from the PRU to the UE (e.g., ratio = anchor-UE distance / PRU-UE distance) may be configured to exceed or maintain a certain ratio threshold (which may be a large value). If the anchor is a GNSS satellite, the ratio may be approximately 20,000 km / 1 km. In other words, if the distance between the GNSS satellite and the UE is approximately 20,000 km, the distance between the UE and the PRU / VPRU may be specified to be within 1 km.

[0105]

[0126] In one aspect of this disclosure, the locations of the VRS (e.g., VPRUs, virtual PRU base stations, etc.) may be pre-assigned by the network to a list of locations, or may be pre-assigned based on predefined rules. In some examples, such a configuration may be preferred by NTN.

[0106]

[0127] Figure 12 is a diagram showing an example of pre-assigned locations for a VRS according to various aspects of the present disclosure. In one example, the network may generate a grid of X meters (m) or kilometers (km) on Earth, and the grid size may be predefined (e.g., 1m, 2m, 5m, etc. in indoor applications, and 5km, 10km, 50km, etc. in outdoor applications). The network may then associate each crosspoint on the grid with an identifier (ID). For example, as shown in 1202, a first crosspoint on the grid may be associated with a first ID (e.g., ID N), a second crosspoint on the grid may be associated with a second ID (e.g., ID L), and a third crosspoint on the grid may be associated with a third ID (e.g., ID N). The IDs and their corresponding locations may then be used by the network to assign VRSs. For example, the network may generate a VPRU or virtual PRU base station at each crosspoint.

[0107]

[0128] This grid information can also be pre-programmed into the UE or transmitted to the UE upon request (e.g., in response to an assistance data request). Based on the grid information, the UE may request different services from the network (e.g., positioning services) to directly use a particular VRS. For example, if the UE is near a crosspoint with ID N, the UE may request the network to provide a VPRU at that crosspoint based on the corresponding ID (e.g., the UE may provide ID N to the network). On the other hand, if the UE does not request a particular VRS, the network may provide a VRS that the network considers to be close to (or closest to) the UE.

[0108]

[0129] In another aspect of this disclosure, the VRS location may be generated based on the location of the UE (or mobile station device). This may be more preferable to TN. For example, based on a coarse estimate of the UE's location, a network server (e.g., a location server or LMF) may determine a VRS location that is as close as possible to the coarse estimate. In one example, the coarse estimate of the UE's location may be determined based on the UE's serving cell ID, the UE's serving beam ID, the UE's extended cell ID (ECID), the UE's previous estimated location, the UE's reported location, and / or RAN independent location estimate. In another example, the UE may send a difference-based positioning request to the network server along with its coarse / previous location for the VRS. For example, the UE may send its coarse location to the network server, and the network server may generate a VRS for the UE based on the UE's coarse location.

[0109]

[0130] In another example, a rough estimate of a UE's location may be determined based on the sidelink (SL) zone ID(s) associated with the UE. For example, in some network implementations, if a sidelink zone configuration (sl-ZoneConfig) is configured, the following formula may be used to determine the identifier (i.e., zone ID) of the zone in which the UE is located. x1 = Floor(x / L) Mod 64, y1 = Floor(y / L) Mod 64, Zone_id=y1 * 64 + x 1. L may represent the value of the sidelink zone length (sl-ZoneLength) and may be included in the sidelink zone configuration (sl-ZoneConfig). In other words, the sidelink zone configuration may define the sidelink zone length. In some examples, the sidelink zone length may be configured to be 5, 10, 20, 30, 40, or 50 meters long, which may be a suitable / reasonable range for SL-based positioning. x may represent the geodetic distance in longitude between the UE's current location and geographic coordinate (0,0) according to the World Geodetic System (e.g., the WGS84 model), and it is expressed in meters. y is the geodetic distance in latitude between the UE's current location and geographic coordinate (0,0) according to the World Geodetic System, and this is also expressed in meters. Thus, the UE's zone ID may be calculated using the UE's current location and geographic coordinate. In some examples, the UE's initial location (which may be rough) may be estimated by the UE with the help of the network.

[0110]

[0131] In cellular-based positioning (e.g., positioning based on a terrestrial network), the distance between the anchor and the UE (e.g., between the TRP and the UE) can be much smaller compared to GNSS or non-terrestrial network scenarios (e.g., between a satellite and the UE). Therefore, multiple iterations of double difference (DD) and VRS may be specified so that the UE's location can gradually converge to a final location estimate. In each iteration, the VRS location may be different. For example, based on the UE's initial coarse location, the network may generate a VPRU at a first location close to the UE's coarse location. Then, based on subsequent measurements from the UE, the network may have a better estimate of the UE's current / actual location, and the network may generate another VPRU close to the UE's current estimated location. The network may continue this process / iteration until certain conditions are met, such as when the UE's final location estimate reaches a certain accuracy threshold. For example, the termination condition for iterations may be covariance-based, delta-based (e.g., |L_(i-1)-L L_(i)|), or ratio-based (e.g., the ratio of anchor UE distance to PRU-UE distance).

[0111]

[0132] As described with respect to Figures 9 to 11, after the server generates a VRS (e.g., a VPRU, a virtual PRU base station, etc.), the server may also generate measurements, support data, and / or correction data associated with the VRS (hereinafter sometimes referred to as "virtual / VRS measurement support data, and / or correction data"), so that a client device (e.g., a UE, a mobile station device, etc.) can use the generated measurements, support data, and / or correction data to assist in its positioning (as if the VRS were an actual physical unit / device). In another aspect of this disclosure, a network or server may generate VRS measurements, support data, and / or correction data for the VRS based on the VRS's location, a noisy anchor location (e.g., a virtual anchor location), and an error source estimation.

[0112]

[0133] Figure 13 is a figure 1300 illustrating an example of generating VRS measurements, support data, and / or correction data according to various aspects of the present disclosure. In one example, UE 1302 may be configured to perform UE-based positioning, such as differential-based positioning (e.g., the UE determines its own location), and UE 1302 may send positioning requests to a network entity 1304, which may be a location server or LMF.

[0113]

[0134] Accordingly, the network entity 1304 may provide the UE 1302 with support data including a set of virtual anchors (as described with respect to Figure 8, for example) and at least one VRS (as described with respect to Figures 9 and 10) that the UE 1302 can use for positioning. For example, based on the support data, the UE 1302 may select a first virtual anchor 1308 (VAnchor1) having a corresponding noisy anchor location (e.g., a first virtual anchor location), a second virtual anchor 1310 (VAnchor2) having a corresponding noisy anchor location (e.g., a second virtual anchor location), and a VRS 1306 (e.g., a virtual VRS location) configured to be close to the UE 1302.

[0114]

[0135] In one example, to generate VRS measurements, supporting data, and / or corrected data for VRS 1306, network entity 1304 may determine each measurement, supporting data, and / or corrected data based on the location of VRS 1306, the noisy anchor locations of the first virtual anchor 1308 and the second virtual anchor 1310, and an error source estimate (sometimes called the estimated error source). As illustrated in relation to Figure 8, the noisy anchor locations of the virtual anchors may be based on applying the anchor location error to the ground truth location of the physical anchor (e.g., a physical anchor location with inherent errors and uncertainties). Error source estimation may include one or more error sources such as anchor clock bias (e.g., NTN satellite clock), hardware group delay (one or more) (e.g., delay in TRP), atmospheric effects (e.g., NTN ionospheric and / or tropospheric delay), non-line-of-sight (NLOS) effects (where applicable), and / or Earth rotation effects (e.g., Sagnac effect), tidal effects, nutation, relativity, and other applicable effects.

[0115]

[0136] In one embodiment, the estimation and tracking of these error sources may be performed in the network entity 1304 or in the PRUs (e.g., physical PRUs used to generate VPRUs as described with respect to Figures 9 and 10). If the estimation and tracking of error sources is performed by the network entity 1304, a number of physical PRUs may be configured to take measurements and report either raw measurements or corrected values ​​to the network entity 1304, as described with respect to Figure 9. On the other hand, if the estimation and tracking of error sources is performed by the PRU(s), the network entity 1304 may distribute the error estimations to the PRU(s). In other words, each PRU may track its own estimated error sources and provide them to the network entity 1304 on demand (e.g., after being requested by the network entity 1304).

[0116]

[0137] In one example, as shown in 1312, the network entity 1304 may broadcast tracked / estimated error sources based on an observation space representation (OSR) format or a state space representation (SSR) format, where the OSR format may use one field / value to cover all (multiple) error sources, and the SSR format may estimate and broadcast each error source.

[0117]

[0138] In another example, as shown in 1314, the VRS measurement for VRS 1306 may be calculated based on the distance between the virtual anchor to VRS 1306 and the error source. For example, network entity 1304 may calculate the virtual received signal time difference (RSTD) between the signal transmitted from the first virtual anchor 1308 to VRS 1306 and the signal transmitted from the second virtual anchor 1310 to VRS 1306 by subtracting the distance from the second virtual anchor 1310 to VRS 1306 (VAnchor2toVRS) from the distance from the first virtual anchor 1308 to VRS 1306 (VAnchor1toVRS) and adding the estimated error source: Virtual RSTD = Range VAnchor1toVRS -Rzane VAnchor2toVRS + Estimated source of error. Since anchor location errors can be canceled after UE 1302 or the positioning engine performs differential measurements between UE 1302 and VRS 1306, the embodiments presented herein may enable UE 1302 to perform UE-based positioning using virtual anchors and VPRUs (one or more). Thus, network entity 1304 can avoid disclosing the true ground locations of physical anchors and PRUs, thereby protecting the privacy and integrity of physical anchors and PRUs.

[0118]

[0139] Figure 14 is a communication flow 1400 illustrating an example of network entities constituting a virtual anchor and VPRU for a UE according to various aspects of this disclosure. The numbering associated with communication flow 1400 does not specify a particular chronological order and is simply used as a reference to communication flow 1400.

[0119]

[0140] In 1420, UE 1402 may send an indication to network entity 1404 (e.g., location server, LMF, etc.) for performing UE-based positioning. UE 1402 may send the indication directly to network entity 1404 or via another network node (e.g., serving base station). UE-based positioning may include at least one differential-based positioning method, such as DD-TDoA, DD-RTT, single differential RTT, D / DD-AoD, D / DD-AoA, D / DD-Carrier Phase, etc. In some examples, the indication may be sent via a support data request message and / or via a capability report. In some implementations, the UE may not be able to determine the positioning method (e.g., UE-based positioning or UE-assisted positioning), and such determination is made by the network entity (e.g., LMF). However, the UE may report its capabilities to the network entity / server, and the UE and the network entity / server may negotiate with each other to determine whether the positioning is UE-based or UE-assisted.

[0120]

[0141] In 1422, depending on the indication of UE 1402 to perform UE-based positioning, network entity 1404 may constitute support data 1406 for UE 1402, which may include a list of virtual anchors 1408 and a list of VPRUs 1410 for UE-based positioning, as described with respect to Figures 8 to 11 and Figure 13.

[0121]

[0142] In 1424, the network entity 1404 may send support data 1406 to the UE 1402, which includes a list of virtual anchors 1408 and a list of VPRUs 1410.

[0122]

[0143] In one example, as shown in 1428, the network entity 1404 may generate a list of virtual anchors 1408 based on applying a location / vector offset (e.g., anchor location error) to each physical anchor in the set of physical anchors, as described, for example, in relation to Figure 8.

[0123]

[0144] In another example, as shown in 1430, a network entity 1404 may generate a list of VPRUs 1410 based on at least one physical PRU, each VPRU may be associated with a corresponding virtual location, as described with respect to Figures 9–11.

[0124]

[0145] In another example, network entity 1404 may select a list of VPRUs 1410 based on the corresponding virtual location of each VPRU and the estimated location of UE 1402, as described with respect to Figures 10 and 11.

[0125]

[0146] In another example, the ratio between a first approximate distance from the estimated location of UE 1402 to the list of virtual anchors 1408 and a second approximate distance from the estimated location of the UE to the list of VPRUs 1410 may be configured to exceed a ratio threshold, as described with respect to Figures 10 and 11.

[0126]

[0147] In another example, as illustrated in relation to Figure 12, the corresponding virtual location for each VPRU in the VPRU list 1410 may be pre-assigned or pre-configured. For example, the virtual location for each VPRU may correspond to a grid crosspoint covering a specific area.

[0127]

[0148] In another example, as described with respect to Figures 10–12, the corresponding virtual location for each VPRU in the VPRU list 1410 may be generated based on the estimated location of UE 1402. In some implementations, network entity 1404 may determine the estimated location of UE 1402 based on the serving cell ID associated with UE 1402, the serving beam ID associated with UE 1402, the extended cell ID (ECID) associated with UE 1402, the previous location estimate of UE 1402, the location reported by UE 1402, the SL zone ID associated with UE 1402, and / or the radio access network (RAN) independent location estimate of UE 1402.

[0128]

[0149] In another example, as shown in 1432, UE 1402 may send a request to network entity 1404 for the use of a preferred or desired VPRU (or more preferred or desired VPRUs). Accordingly, network entity 1404 may configure support data 1406 to include the preferred or desired VPRU (one or more) in the VPRU list 1410 based on the request.

[0129]

[0150] In another example, as shown in 1434, UE 1402 may instruct network entity 1404 to use a designated VPRU for positioning, such as VPRU 1412. In 1436, depending on the indicated VPRU, network entity 1404 may generate a set of measurements or correction data for VPRU 1412 based on the virtual location of VPRU 1412 and the virtual locations of one or more virtual anchors. In 1438, network entity 1404 may transmit a set of measurements or correction data associated with VPRU 1412 to UE 1402, as described with respect to Figure 13. In one example, the indications transmitted by UE 1402 in 1434 and 1432 may be the same. In another example, network entity 1438 may transmit a set of measurements or correction data for VPRU 1412 via support data 1406 (if network entity 1404 knows that UE 1402 is using VPRU 1412). In another example, network entity 1404 may generate a set of measurements or correction data for each VPRU in the VPRU list 1410 (for example, based on the virtual location for each VPRU in the VPRU list 1410 and the virtual anchor list 1408), and network entity 1404 may transmit the set of measurements or correction data to the UE for UE-based positioning, based on which VPRU is used by the UE 1402.

[0130]

[0151] In one example, as illustrated with respect to Figure 13, a set of measurements or corrected data may be generated based on one or more error sources, such as anchor clock bias, group delay, atmospheric influence or delay, non-line-of-sight (NLOS) influence, and / or at least one environmental influence. Network entity 1404 may estimate or track one or more error sources based on raw measurements received from a set of physical PRUs.

[0131]

[0152] In another example, network entity 1404 may broadcast one or more error sources to multiple UEs (including UE 1402) based on an observation space representation (OSR) format or a state space representation (SSR) format.

[0132]

[0153] In 1426, based on the support data 1406, UE 1402 may perform UE-based positioning using at least one virtual anchor and / or at least one VPRU, as described with respect to Figures 7, 10, and 13.

[0133]

[0154] In another aspect of this disclosure, certain information may be specified to be included in the support data request from the UE and / or in the support data from the network so that the network (e.g., a location server, LMF, etc.) can configure virtual anchors and / or VRS(s) for the UE. For example, when the UE sends a support data request to the network (e.g., an LMF), as described with respect to Figure 1420, the support data request may include the UE's location (e.g., a rough location, an estimated location, or an exact location) and / or a list of observable anchors.

[0134]

[0155] Including its location in the support data request can be beneficial because it may allow the network to provide a VRS as close to the UE as possible. However, in the case of UE-based positioning, if the client (consumer) is the UE itself, the UE may not be specified to report its location. In other words, the network may not be specified to know the UE's location. In some scenarios, the network may not know the UE's current location(s) or historical location(s)(s) for UE-based positioning. Therefore, to reduce / minimize the distance between the UE and the VRS, the UE may be specified to provide / add its location information to the network for VRS-based high-precision positioning. Location estimation may be based on previous location estimations using the same positioning method, other RAN-independent methods, serving cells, etc., as described with respect to Figure 12.

[0135]

[0156] It may be beneficial for the UE to include a list of observable anchors (e.g., anchors that can be detected / observed by the UE) in its support data requests, as this may allow the network to construct more suitable virtual anchor correction data / measurements for the UE. For example, based on PRS reception at the UE (e.g., signal-to-noise ratio (SNR) and / or reference signal received power (RSRP) measured for the received PRS), the UE may observe a subset of anchors (e.g., anchors with good link quality or link quality above a quality threshold). The UE may then transmit information associated with these observable anchors to the network.

[0136]

[0157] In some scenarios, the network may generate a VRS at a virtual location using customized VRS measurements / correction data, as illustrated in relation to Figure 13, so that the customized VRS measurements / correction data may be more accurate if both the UE and VRS (e.g., VPRU) have common measurements using anchors. Also, compared to GNSS-based positioning, the embodiments presented herein may allow the UE to establish a bidirectional communication link with the location server (e.g., VRS), although most GNSS RTK / PPP may use a unidirectional communication link (broadcasting correction data). In some examples, to conserve resources and achieve better positioning performance, the UE may request VRS measurements using a set of anchors observed by the UE. The network may then generate customized VRS measurements based on the UE's request, instead of VRS measurements using all anchors.

[0137]

[0158] As illustrated with respect to Figure 14, 1424, when a network (e.g., an LMF) sends support data to a UE, the support data may include virtual anchor groups and / or PRU type fields / indications. For example, a virtual anchor group ID may be added to the support data for UE-based positioning, and each virtual anchor group ID may be associated with (or include) a set of noisy anchor locations (e.g., ground truth location + anchor location error). Such a configuration may be suitable for roaming scenarios, where this anchor group information (e.g., virtual anchor group ID + noisy anchor locations) can be shared / synchronized across network nodes supporting difference-based positioning (e.g., single-difference and double-difference) and VRS. Thus, when a UE enters a new area and / or moves / hands over to a different network (e.g., another LMF), the UE may send its virtual anchor group ID to the network in a support data request. The network can then know about the noisy anchor locations and generate VRS measurements / corrections for the VRS used by the UE.

[0138]

[0159] In some scenarios, it may be beneficial for the network to indicate to the UE whether a PRU is a VPRU or a physical PRU, for example, by including a PRU type field in the support data for the UE. For instance, a bit field or integer field could be used to indicate whether a PRU in a list of PRUs is a VPRU or a physical PRU. In some cases, the UE may be instructed to establish a direct connection with the PRU (e.g., an SL connection, a Uu connection, etc.), so that the UE can avoid attempting to establish a connection with a VPRU if it knows it is a virtual device. On the other hand, if the support data indicates that the PRU is a physical PRU, the UE can know that it is possible to establish an SL / Uu connection with the PRU to offload communication traffic.

[0139]

[0160] Figure 15 is a communication flow 1500 illustrating an example of support data requests and information that may be included within the support data, which may enable a network entity to more efficiently configure virtual anchors and / or VPRUs for a UE, according to various aspects of this disclosure. The numbering associated with communication flow 1500 does not specify a particular chronological order and is simply used as a reference to communication flow 1500.

[0140]

[0161] In 1510, UE 1502 may send an assistance data request 1506 to a network entity 1504 (e.g., a location server, LMF, etc.) to perform UE-based positioning. As shown in 1512, the assistance data request 1506 may include location information of UE 1502 and / or a list of anchors observed by UE 1502. UE-based positioning may be associated with at least one differential-based positioning method.

[0141]

[0162] For example, as shown in 1520, UE 1502 may obtain its location information before sending the support data request 1506. For example, UE 1502 may estimate its location based on the serving ID associated with UE 1502, the serving beam ID associated with UE 1502, the ECID associated with UE 1502, the previous location estimate for UE 1502, the SL zone ID associated with UE 1502, and / or the RAN independent location estimate for UE 1502.

[0142]

[0163] In 1514, based on the support data request 1506, the network entity 1504 may generate support data 1508 for UE-based positioning and transmit it to the UE 1502. As shown in 1516, the support data 1508 may include a list of PRUs, which may include a list of virtual anchors and a set of VPRUs. The network entity 1504 may select a list of virtual anchors and a list of PRUs based on the location information of the UE 1502 or a list of anchors observed by the UE 1502.

[0143]

[0164] For example, as shown in 1516, the support data 1508 may further include an indication of whether each PRU in the list of PRUs is a physical PRU or a VPRU. Based on the indication, UE 1502 may refrain from establishing a direct connection to the PRUs in the list of PRUs if each PRU is indicated as a VPRU, or the UE may allow a direct connection to be established to the PRUs in the list of PRUs if each PRU is indicated as a physical PRU.

[0144]

[0165] In another example, a list of virtual anchors may be associated with at least one group ID, such as a virtual anchor group ID. In one example, network entity 1404 may generate anchor group information that includes a set of associations between different groups of virtual anchors and their corresponding group IDs, and network entity 1404 may transmit anchor group information for one or more network nodes (e.g., network nodes capable of supporting at least one differential-based positioning method using at least one VPRU). In another example, network entity 1404 may also transmit at least one group ID (e.g., to a base station) depending on whether the UE is being handed over to a base station.

[0145]

[0166] As explained in relation to Figures 8 to 11, each virtual anchor in the list of virtual anchors may correspond to a physical anchor with a location / vector offset, and each VPRU in the set of VPRUs may be generated based on at least one physical PRU (each VPRU in the set of VPRUs is also associated with a virtual location).

[0146]

[0167] In 1518, UE 1502 may perform UE-based positioning using at least one virtual anchor and at least one VPRU in the support data 1508, as described with respect to Figures 9, 10, 13, and 14. In some examples, UE 1502 may also receive a set of measured or corrected data for a set of VPRUs from network entity 1504, based on a virtual location for each VPRU in the set of VPRUs and a list of virtual anchors, as described with respect to 1436 and 1438 in Figure 14.

[0147]

[0168] Figure 16 is a flowchart 1600 of a wireless communication method. This method can be performed by UEs (e.g., UEs 104, 404, 702, 920, 1302, 1402, 1502, GNSS device 506, mobile station device 604, and equipment 1804). The method may allow the UEs to perform UE-based positioning using virtual anchors and / or virtual PRUs.

[0148]

[0169] In 1604, the UE transmits to the network entity a request for support data to perform user equipment (UE)-based positioning, as described with respect to Figure 15, the request may include at least one of the UE's location information or a list of anchors observed by the UE. For example, as shown in 1510 of Figure 15, UE 1502 may transmit a request for support data 1506 to the network entity 1504 for performing UE-based positioning, the request may include at least one of the UE's location information or a list of anchors observed by the UE. Means for transmitting a request for support data may be performed, for example, by the positioning component 198, application processor 1806, cellular baseband processor 1824, and / or transceiver(s) 1822 of the device 1804 in Figure 18.

[0149]

[0170] For example, UE-based positioning is associated with at least one differential-based positioning method.

[0150]

[0171] In another example, the network entity is a location server or LMF.

[0151]

[0172] As described in relation to Figure 15 in 1606, the UE may, on request, receive support data for UE-based positioning from a network entity, the support data may include a list of virtual anchors and a list of PRUs including a set of VPRUs, and the list of virtual anchors and the list of PRUs may be configured to be selected based on at least one of the UE's location information or a list of anchors observed by the UE. For example, as shown in 1514 of Figure 15, the UE 1502 may receive support data 1508 from a network entity 1504, the support data 1508 may include a list of PRUs including a set of VPRUs and a list of virtual anchors, and the list of virtual anchors and the list of PRUs may be selected based on at least one of the UE's location information or a list of anchors observed by the UE. Means for receiving support data may be performed, for example, by the positioning component 198 of the device 1804 in Figure 18, the application processor 1806, the cellular baseband processor 1824, and / or the transceiver(s) 1822.

[0152]

[0173] For example, the support data may further include an indication of whether each PRU in the PRU list is a physical PRU or a VPRU. In some implementations, the UE may refrain from establishing a direct connection to a PRU in the PRU list if that PRU is indicated as a VPRU. In some implementations, the UE may allow the establishment of a direct connection to a PRU in the PRU list if that PRU is indicated as a physical PRU.

[0153]

[0174] In another example, the list of virtual anchors is associated with at least one group ID.

[0154]

[0175] In another example, each virtual anchor in the list of virtual anchors corresponds to a physical anchor with a location / vector offset.

[0155]

[0176] In another example, each VPRU in a set of VPRUs is generated based on at least one physical PRU, and each VPRU in a set of VPRUs is associated with a virtual location.

[0156]

[0177] In another example, a UE may send an indication to a network entity to use a preferred or desired VPRU, and the UE may, upon request, receive supporting data containing the preferred or desired VPRU from a list of PRUs.

[0157]

[0178] In another example, the UE may receive a set of measured or corrected data for a set of VPRUs from a network entity, based on a list of virtual locations and virtual anchors for each VPRU in the set of VPRUs, as described with respect to Figure 14. For example, as shown in 1438 of Figure 14, UE 1402 may receive a set of measured or corrected data for VPRU 1412 from network entity 1404. Means for transmitting indications may be performed, for example, by the positioning component 198, application processor 1806, cellular baseband processor 1824, and / or transceiver(s) 1822 of device 1804 in Figure 18. In some implementations, the UE may receive a set of measured or corrected data for a set of VPRUs from a network entity via auxiliary data or via separate signaling.

[0158]

[0179] In 1610, the UE may perform UE-based positioning using at least one virtual anchor and at least one VPRU in the support data, as described with respect to Figure 15. For example, as shown in 1518 of Figure 15, the UE 1502 may perform UE-based positioning using at least one virtual anchor and / or at least one VPRU. Means for performing UE-based positioning may be, for example, the positioning component 198 of the device 1804 in Figure 18, the application processor 1806, the cellular baseband processor 1824, and / or the transceiver(s) 1822. In some implementations, if the UE receives from a network entity a set of measurements or correction data for a set of VPRUs, based on a list of virtual locations and virtual anchors for each VPRU in the set of VPRUs, the UE may perform UE-based positioning based on the set of measurements or correction data.

[0159]

[0180] In one example, a UE may obtain its location information based on at least one of the following: a serving cell ID associated with the UE, a serving beam ID associated with the UE, an ECID associated with the UE, a previous location estimate of the UE, an SL zone ID associated with the UE, or a RAN-independent location estimate of the UE. For example, as shown in 1520 of Figure 15, UE 1502 obtains its location information. Means for obtaining the location information of a UE may be performed, for example, by the positioning component 198 of the device 1804 in Figure 18, the application processor 1806, the cellular baseband processor 1824, and / or the transceiver(s) 1822.

[0160]

[0181] Figure 17 is a flowchart 1700 of a wireless communication method. This method can be performed by UEs (e.g., UEs 104, 404, 702, 920, 1302, 1402, 1502, GNSS device 506, mobile station device 604, and equipment 1804). The method may allow the UEs to perform UE-based positioning using virtual anchors and / or virtual PRUs.

[0161]

[0182] In 1704, the UE transmits to the network entity a request for support data to perform user equipment (UE)-based positioning, as described with respect to Figure 15, the request may include at least one of the UE's location information or a list of anchors observed by the UE. For example, as shown in 1510 of Figure 15, UE 1502 may transmit a request for support data 1506 to the network entity 1504 for performing UE-based positioning, the request may include at least one of the UE's location information or a list of anchors observed by the UE. Means for transmitting a request for support data may be performed, for example, by the positioning component 198, application processor 1806, cellular baseband processor 1824, and / or transceiver(s) 1822 of the device 1804 in Figure 18.

[0162]

[0183] For example, UE-based positioning is associated with at least one differential-based positioning method.

[0163]

[0184] In another example, the network entity is a location server or LMF.

[0164]

[0185] As described in relation to Figure 15 in 1706, a UE may, on request, receive support data for UE-based positioning from a network entity, which may include a list of virtual anchors and a list of PRUs including a set of VPRUs, and the list of virtual anchors and the list of PRUs may be configured to be selected based on at least one of the UE's location information or a list of anchors observed by the UE. For example, as shown in 1514 of Figure 15, a UE 1502 may receive support data 1508 from a network entity 1504, which may include a list of PRUs including a set of VPRUs and a list of virtual anchors, and the list of virtual anchors and the list of PRUs may be selected based on at least one of the UE's location information or a list of anchors observed by the UE. Means for receiving support data may be performed, for example, by the positioning component 198 of the device 1804 in Figure 18, the application processor 1806, the cellular baseband processor 1824, and / or the transceiver(s) 1822.

[0165]

[0186] For example, the support data may further include an indication of whether each PRU in the PRU list is a physical PRU or a VPRU. In some implementations, the UE may refrain from establishing a direct connection to a PRU in the PRU list if that PRU is indicated as a VPRU. In some implementations, the UE may allow the establishment of a direct connection to a PRU in the PRU list if that PRU is indicated as a physical PRU.

[0166]

[0187] In another example, the list of virtual anchors is associated with at least one group ID.

[0167]

[0188] In another example, each virtual anchor in the list of virtual anchors corresponds to a physical anchor with a location / vector offset.

[0168]

[0189] In another example, each VPRU in a set of VPRUs is generated based on at least one physical PRU, and each VPRU in a set of VPRUs is associated with a virtual location.

[0169]

[0190] In another example, a UE may send an indication to a network entity to use a preferred or desired VPRU, and the UE may, upon request, receive supporting data containing the preferred or desired VPRU from a list of PRUs.

[0170]

[0191] In another example, in 1708, the UE may receive a set of measured or corrected data for a set of VPRUs from a network entity, based on a list of virtual locations and virtual anchors for each VPRU in the set of VPRUs, as described with respect to Figure 14. For example, as shown in 1438 of Figure 14, UE 1402 may receive a set of measured or corrected data for VPRU 1412 from network entity 1404. Means for transmitting indications may be performed, for example, by the positioning component 198, application processor 1806, cellular baseband processor 1824, and / or transceiver(s) 1822 of device 1804 in Figure 18. In some implementations, the UE may receive a set of measured or corrected data for a set of VPRUs from a network entity via auxiliary data or via separate signaling.

[0171]

[0192] In 1710, the UE may perform UE-based positioning using at least one virtual anchor and at least one VPRU in the support data, as described with respect to Figure 15. For example, as shown in 1518 of Figure 15, the UE 1502 may perform UE-based positioning using at least one virtual anchor and / or at least one VPRU. Means for performing UE-based positioning may be, for example, the positioning component 198 of the device 1804 in Figure 18, the application processor 1806, the cellular baseband processor 1824, and / or the transceiver(s) 1822. In some implementations, if the UE receives from a network entity a set of measurements or correction data for a set of VPRUs, based on a list of virtual locations and virtual anchors for each VPRU in the set of VPRUs, the UE may perform UE-based positioning based on the set of measurements or correction data.

[0172]

[0193] In one example, in 1702, the UE may obtain its location information based on at least one of the following: the serving cell ID associated with the UE, the serving beam ID associated with the UE, the ECID associated with the UE, the previous location estimate of the UE, the SL zone ID associated with the UE, or the RAN independent location estimate of the UE, as described with respect to Figure 15. For example, as shown in 1520 of Figure 15, UE 1502 obtains its location information. Means for obtaining the location information of the UE may be performed, for example, by the positioning component 198 of the device 1804 in Figure 18, the application processor 1806, the cellular baseband processor 1824, and / or the transceiver(s) 1822.

[0173]

[0194] Figure 18 is Figure 1800, which shows an example of a hardware implementation for device 1804. Device 1804 may be a UE, a component of a UE, or implement UE functions. In some embodiments, device 1804 may include a cellular baseband processor 1824 (also called a modem) coupled to one or more transceivers 1822 (e.g., cellular RF transceivers). The cellular baseband processor 1824 may include on-chip memory 1824'. In some embodiments, device 1804 may further include one or more subscriber identity module (SIM) cards 1820 and an application processor 1806 coupled to a secure digital (SD) card 1808 and a screen 1810. The application processor 1806 may include on-chip memory 1806'. In some embodiments, the device 1804 may further include a Bluetooth module 1812, a WLAN module 1814, an SPS module 1816 (e.g., a GNSS module), one or more sensor modules 1818 (e.g., motion sensors such as a barometric pressure sensor / altimeter, an inertial measurement unit (IMU), a gyroscope, and / or accelerometer(s), light detection and ranging (LIDAR), radio-assisted detection and ranging (RADAR), sound navigation and ranging (SONAR), a magnetometer, audio, and / or other technologies used for positioning), an additional memory module 1826, a power supply 1830, and / or a camera 1832. The Bluetooth module 1812, the WLAN module 1814, and the SPS module 1816 may include an on-chip transceiver (TRX) (or, in some cases, simply a receiver (RX)).The Bluetooth module 1812, the WLAN module 1814, and the SPS module 1816 may include their own dedicated antennas and / or utilize antenna 1880 for communication. The cellular baseband processor 1824 communicates with the RU associated with the UE 104 and / or network entity 1802 via one or more antennas 1880 and transceiver(s) 1822. The cellular baseband processor 1824 and the application processor 1806 may each include computer-readable media / memory 1824', 1806', respectively. An additional memory module 1826 may also be considered computer-readable media / memory. Each computer-readable media / memory 1824', 1806', 1826 may be non-transient. The cellular baseband processor 1824 and the application processor 1806 are each responsible for general processing, including the execution of software stored in computer-readable media / memory. When the software is executed by the cellular baseband processor 1824 / application processor 1806, it causes the cellular baseband processor 1824 / application processor 1806 to perform the various functions described above. Computer-readable media / memory may also be used to store data manipulated by the cellular baseband processor 1824 / application processor 1806 when the software is executed. The cellular baseband processor 1824 / application processor 1806 may be a component of the UE350 and may include memory 360 and / or at least one of the TX processor 368, RX processor 356, and controller / processor 359. In one configuration, the device 1804 may be a processor chip (modem and / or application), or may include only the cellular baseband processor 1824 and / or application processor 1806, while in another configuration, the device 1804 may be the entire UE (see, for example, the UE350 in Figure 3), or may include additional modules of the device 1804.

[0174]

[0195] As described above, the positioning component 198 may send a request to a network entity for support data to perform UE-based positioning, the request may be configured to include at least one of the UE's location information or a list of anchors observed by the UE. The positioning component 198 may also receive support data for UE-based positioning from the network entity based on the request, the support data may include a list of virtual anchors and a list of PRUs including a set of VPRUs, the list of virtual anchors and the list of PRUs may be configured to be selected based on at least one of the UE's location information or a list of anchors observed by the UE. The positioning component 198 may also be configured to perform UE-based positioning using at least one virtual anchor and at least one VPRU in the support data. The positioning component 198 may reside in the cellular baseband processor 1824, the application processor 1806, or both the cellular baseband processor 1824 and the application processor 1806. The positioning component 198 may be one or more hardware components specifically configured to perform the described process / algorithm, may be implemented by one or more processors configured to perform the described process / algorithm, may be stored in a computer-readable medium for implementation by one or more processors, or may be any combination thereof. As illustrated, the device 1804 may include various components configured for various functions. In one configuration, the device 1804, and in particular the cellular baseband processor 1824 and / or application processor 1806, transmits a request to a network entity for support data for performing UE-based positioning, the request may include means for including at least one of the location information of the UE or a list of anchors observed by the UE.The device 1804, upon request, receives support data for UE-based positioning from a network entity, the support data including a list of virtual anchors and a list of PRUs including a set of VPRUs, the list of virtual anchors and the list of PRUs may further include means for selecting the virtual anchors and the list of PRUs based on at least one of the location information of the UE or a list of anchors observed by the UE. The device 1804 may further include means for performing UE-based positioning using at least one virtual anchor and at least one VPRU in the support data.

[0175]

[0196] In one configuration, UE-based positioning is associated with at least one differential-based positioning method.

[0176]

[0197] In another configuration, the network entity is either a location server or an LMF.

[0177]

[0198] In an alternative configuration, the support data may further include an indication of whether each PRU in the list of PRUs is a physical PRU or a VPRU. In some implementations, device 1804 may further include means to refrain from establishing a direct connection with the PRUs in the list of PRUs when each PRU is indicated as a VPRU. In some implementations, device 1804 may further include means to enable the establishment of a direct connection with the PRUs in the list of PRUs when each PRU is indicated as a physical PRU.

[0178]

[0199] In another configuration, the list of virtual anchors is associated with at least one group ID.

[0179]

[0200] In another configuration, each virtual anchor in the list of virtual anchors corresponds to a physical anchor with a location / vector offset.

[0180]

[0201] In another configuration, each VPRU in a set of VPRUs is generated based on at least one physical PRU, and each VPRU in the set of VPRUs is associated with a virtual location.

[0181]

[0202] In another configuration, the device 1804 may further include means for sending an indication to a network entity to use a suitable or preferred VPRU, and means for receiving, on request, support data including a suitable or preferred VPRU in a list of PRUs.

[0182]

[0203] In an alternative configuration, the device 1804 may further include means for obtaining location information of the UE based on at least one of the following: a serving cell ID associated with the UE, a serving beam ID associated with the UE, an ECID associated with the UE, a previous location estimate of the UE, an SL zone ID associated with the UE, or a RAN-independent location estimate of the UE.

[0183]

[0204] In another configuration, the device 1804 may further include means for receiving a set of measured or corrected data for a set of VPRUs from a network entity, based on a list of virtual locations and virtual anchors for each VPRU in the set of VPRUs.

[0184]

[0205] The means may be a positioning component 198 of the device 1804 configured to perform the enumerated functions by the means. As described above, the device 1804 may include a TX processor 368, an RX processor 356, and a controller / processor 359. Therefore, in one configuration, the means may be the TX processor 368, the RX processor 356, and / or the controller / processor 359, configured to perform the enumerated functions by the means.

[0185]

[0206] Figure 19 is a flowchart 1900 of a wireless communication method. The method may be performed by network entities (e.g., base station 102, server 918, network entities 1304, 1404, 1504, 2002). The method may enable network entities to generate and configure virtual anchors and / or VPRUs for UEs for UE-based positioning.

[0186]

[0207] In 1902, a network entity may receive a request from a UE for support data to perform UE-based positioning, as described with respect to Figure 15, the request may include at least one of the UE's location information or a list of anchors observed by the UE. For example, as shown in 1510 of Figure 15, network entity 1504 may receive a support data request 1506 from UE 1502 for performing UE-based positioning, the support data request 1506 may include at least one of the UE's location information or a list of anchors observed by the UE. Means for receiving requests for support data may be performed, for example, by the virtual anchor and base station configuration components 199 of network entity 2002 in Figure 20, the RU processor 2042, and / or transceiver(s) 2046.

[0187]

[0208] In 1904, a network entity may, on request as described with respect to Figure 15, transmit to a UE support data for UE-based positioning, which may include a list of virtual anchors and a list of PRUs including a set of VPRUs, and the list of virtual anchors and the list of PRUs may be selected based on at least one of the UE's location information or a list of anchors observed by the UE. For example, as shown in 1514 of Figure 15, a network entity 1504 may transmit support data 1514 to a UE 1502 on request 1506 for support data for UE-based positioning, which may include a list of virtual anchors and a list of PRUs including a set of VPRUs, and the list of virtual anchors and the list of PRUs may be selected based on at least one of the UE's location information or a list of anchors observed by the UE. Means for transmitting support data may be performed, for example, by the virtual anchor and base station configuration components 199 of the network entity 2002 in Figure 20, the RU processor 2042, and / or transceiver(s) 2046.

[0188]

[0209] For example, the supporting data may further include an indication of whether each PRU in the list of PRUs is a physical PRU or a VPRU.

[0189]

[0210] In another example, a list of virtual anchors may be associated with at least one group ID. In some implementations, a network entity may generate anchor group information that includes a set of associations between different groups of virtual anchors and their corresponding group IDs, and the network entity may transmit anchor group information for one or more network nodes. In some implementations, one or more network nodes may be able to support at least one differential-based positioning method using at least one VPRU.

[0190]

[0211] In another example, a network entity may send at least one group ID to a base station in response to the UE being handed over to the base station.

[0191]

[0212] In another example, each virtual anchor in the list of virtual anchors may correspond to a physical anchor with a location / vector offset.

[0192]

[0213] In another example, each VPRU in a set of VPRUs may be generated based on at least one physical PRU, and each VPRU in the set of VPRUs may be associated with a virtual location.

[0193]

[0214] In another example, UE-based positioning may be associated with at least one differential-based positioning method.

[0194]

[0215] In another example, the network entity could be a location server or an LMF.

[0195]

[0216] Figure 20 is Figure 2000, which shows an example of a hardware implementation for network entity 2002. Network entity 2002 may be a BS, a component of a BS, or may implement BS functionality. Network entity 2002 may include at least one of CU2010, DU2030, or RU2040. For example, depending on the layer functionality processed by the component sensing component 199 of the virtual anchor and base station configuration, network entity 2002 may include CU2010, both CU2010 and DU2030, each of CU2010, DU2030, and RU2040, both DU2030, DU2030, and RU2040, or RU2040. CU2010 may include a CU processor 2012. CU processor 2012 may include on-chip memory 2012'. In some embodiments, CU2010 may further include an additional memory module 2014 and a communication interface 2018. CU2010 communicates with DU2030 via a midhaul link such as an F1 interface. DU2030 may include a DU processor 2032. DU processor 2032 may include on-chip memory 2032'. In some embodiments, DU2030 may further include an additional memory module 2034 and a communication interface 2038. DU2030 communicates with RU2040 via a fronthaul link. RU2040 may include an RU processor 2042. RU processor 2042 may include on-chip memory 2042'. In some embodiments, RU2040 may further include an additional memory module 2044, one or more transceivers 2046, an antenna 2080, and a communication interface 2048. RU2040 communicates with UE104. On-chip memories 2012', 2032', 2042', and additional memory modules 2014, 2034, 2044 can each be considered computer-readable media / memory. Each computer-readable media / memory may be non-transient. Each of processors 2012, 2032, and 2042 is responsible for general processing, including the execution of software stored in computer-readable media / memory.When software is executed by a corresponding processor(s), it causes the processor(s)(s)(s)(s)(s) to perform the various functions described above. Computer-readable media / memory may also be used to store data that is manipulated by the processor(s)(s) when the software is executed.

[0196]

[0217] As described above, the virtual anchor and base station configuration component 199 may be configured to receive requests from the UE for support data for performing UE-based positioning, the requests including at least one of the UE's location information or a list of anchors observed by the UE. The virtual anchor and base station configuration component 199 may also transmit support data for UE-based positioning to the UE on the basis of the request, the support data including a list of virtual anchors and a list of PRUs including a set of VPRUs, the list of virtual anchors and the list of PRUs may be configured to be selected on the basis of at least one of the UE's location information or a list of anchors observed by the UE. The virtual anchor and base station configuration component 199 may be located in one or more processors of one or more of the CU2010, DU2030, and RU2040. The virtual anchor and base station configuration components 199 may be one or more hardware components specifically configured to perform the described process / algorithm, which may be implemented by one or more processors configured to perform the described process / algorithm, which may be stored in a computer-readable medium for implementation by one or more processors, or which may be any combination thereof. The network entity 2002 may include various components configured for various functions. In one configuration, the network entity 2002 receives a request from the UE for support data for performing UE-based positioning, and the request may include means for including at least one of the UE's location information or a list of anchors observed by the UE. Based on the request, the network entity 2002 transmits to the UE support data for UE-based positioning, which includes a list of virtual anchors and a list of PRUs including a set of VPRUs, and the list of virtual anchors and the list of PRUs may further include means for selecting based on at least one of the UE's location information or a list of anchors observed by the UE.

[0197]

[0218] In one configuration, the supporting data may further include an indication of whether each PRU in the PRU list is a physical PRU or a VPRU.

[0198]

[0219] In an alternative configuration, a list of virtual anchors may be associated with at least one group ID. In some implementations, a network entity may generate anchor group information containing a set of associations between different groups of virtual anchors and their corresponding group IDs, and the network entity may transmit anchor group information for one or more network nodes. In some implementations, one or more network nodes may be able to support at least one differential-based positioning method using at least one VPRU.

[0199]

[0220] In an alternative configuration, a network entity may transmit at least one group ID to a base station in response to the UE being handed over to the base station.

[0200]

[0221] In an alternative configuration, each virtual anchor in the list of virtual anchors may correspond to a physical anchor with a location / vector offset.

[0201]

[0222] In an alternative configuration, each VPRU in a set of VPRUs is generated based on at least one physical PRU, and each VPRU in the set of VPRUs may be associated with a virtual location.

[0202]

[0223] In another configuration, UE-based positioning may be associated with at least one differential-based positioning method.

[0203]

[0224] In an alternative configuration, the network entity could be a location server or an LMF.

[0204]

[0225] The means may be a component 199 of the virtual anchor and base station configuration of the network entity 2002, configured to perform the enumerated functions. As described above, the network entity 2002 may include a TX processor 316, an RX processor 370, and a controller / processor 375. Therefore, in one configuration, the means may be the TX processor 316, the RX processor 370, and / or the controller / processor 375, configured to implement the enumerated functions.

[0205]

[0226] It should be understood that the specific order or hierarchy of blocks in the disclosed process / flowchart is an example of exemplary technique. It should be understood that the specific order or hierarchy of blocks in those process / flowcharts can be rearranged based on design preferences. Furthermore, some blocks can be combined or omitted. The claims of the attached method present various block elements in exemplary order, and are not limited to the specific order or hierarchy presented.

[0206]

[0227] The foregoing explanations are provided so that any person skilled in the art may practice the various embodiments described herein. Various modifications to these embodiments will be readily apparent to a person skilled in the art, and the general principles defined herein may be applicable to other embodiments. Therefore, the claims should not be limited to the embodiments described herein, but should encompass the entire scope consistent with the language of the claims. References to elements in the singular form should mean "one or more" rather than "only one" unless otherwise specified. Terms such as "if," "when," and "while" do not imply an immediate temporal relationship or response. That is, these phrases, for example, "when," do not imply an immediate action in response to or during the occurrence of an action, but simply mean that an action will occur if the conditions are met, but without any specific or immediate temporal constraints for that action to occur. The word "exemplary" is used herein to mean "serving as an example, case, or illustration." None of the embodiments described herein as “exemplary” should be construed as necessarily preferable or advantageous to any other embodiment. Unless otherwise specified, the term “several” means one or more. Combinations such as “at least one of A, B, or C,” “one or more of A, B, or C,” “at least one of A, B, and C,” “one or more of A, B, and C,” and “A, B, C, or any combination thereof” include any combination of A, B, and / or C, and may include multiple A, multiple B, or multiple C.Specifically, combinations such as "at least one of A, B, or C," "one or more of A, B, or C," "at least one of A, B, and C," "one or more of A, B, and C," and "A, B, C, or any combination thereof" can be A only, B only, C only, A and B, A and C, B and C, or A and B and C, and any such combination may contain one or more elements of A, B, or C. A set should be interpreted as a set of elements, having one or more elements. Therefore, with respect to a set of X, X will contain one or more elements. When the first device receives data from or transmits data to the second device, the data can be received / transmitted directly between the first and second devices, or indirectly between the first and second devices through a set of devices. A device configured to “output” data such as transmissions, signals, or messages may, for example, use a transceiver to transmit data or send data to a device that transmits data. A device configured to “receive” data such as transmissions, signals, or messages may, for example, use a transceiver to receive data or receive data from a device that receives data. All structural and functional equivalents to elements of various aspects described throughout this disclosure, whether known to those skilled in the art or to become known thereafter, are expressly incorporated herein by reference and are encompassed by the claims. Furthermore, nothing disclosed herein is intended to be made public, whether such disclosure is expressly enumerated in the claims or not. The terms “module,” “mechanism,” “element,” and “device” may not be substitutes for the term “means.” Therefore, no element of the claims should be interpreted as means plus function unless it is expressly enumerated using the phrase “means of.”

[0207]

[0228] Where used herein, the phrase “based on” should not be interpreted as a reference to a closed set such as information, one or more conditions, one or more factors. In other words, the phrase “based on A” (where “A” may be information, a condition, a factor, etc.) shall be interpreted as “based on at least A” unless otherwise specified.

[0208]

[0229] The following embodiments are illustrative and may be combined with other embodiments or teachings described herein without limitation.

[0209]

[0230] Embodiment 1 is a method of wireless communication in a UE, comprising: sending a request to a network entity for support data for performing UE-based positioning, the request comprising at least one of the location information of the UE or a list of anchors observed by the UE; receiving support data for UE-based positioning from the network entity based on the request, the support data comprising a list of virtual anchors and a list of PRUs including a set of VPRUs, the list of virtual anchors and the list of PRUs being selected based on at least one of the location information of the UE or a list of anchors observed by the UE; and performing UE-based positioning using at least one virtual anchor and at least one VPRU in the support data.

[0210]

[0231] Embodiment 2 is the method described in Embodiment 1, wherein the supporting data further includes an indication of whether each PRU in the list of PRUs is a physical PRU or a VPRU.

[0211]

[0232] Embodiment 3 is the method of Embodiment 2, further comprising refraining from establishing a direct connection with the PRUs in the list of PRUs when each PRU is indicated as a VPRU.

[0212]

[0233] Embodiment 4 is the method of Embodiment 2, further comprising enabling the establishment of direct connections with PRUs in a list of PRUs, where each PRU is indicated as a physical PRU.

[0213]

[0234] Embodiment 5 is the method according to any one of Embodiments 1 to 4, wherein the list of virtual anchors is associated with at least one group identifier (ID).

[0214]

[0235] Embodiment 6 is the method according to any one of Embodiments 1 to 5, further comprising obtaining location information of the UE based on at least one of the following: a serving cell ID associated with the UE, a serving beam ID associated with the UE, an ECID associated with the UE, a previous location estimate of the UE, an SL zone ID associated with the UE, or a RAN-independent location estimate of the UE.

[0215]

[0236] Embodiment 7 is the method according to any one of Embodiments 1 to 6, wherein each virtual anchor in the list of virtual anchors corresponds to a physical anchor having a location offset.

[0216]

[0237] Embodiment 8 is the method according to any one of Embodiments 1 to 7, wherein each VPRU in the set of VPRUs is generated based on at least one physical PRU, and each VPRU in the set of VPRUs is associated with a virtual location.

[0217]

[0238] Embodiment 9 is a method according to any one of Embodiments 1 to 8, further comprising sending an indication to a network entity for the use of a suitable VPRU and, on request, receiving support data containing a suitable VPRU in a list of PRUs.

[0218]

[0239] Embodiment 10 is the method according to any one of Embodiments 1 to 9, further comprising receiving from a network entity a set of measurements or correction data for a set of VPRUs based on a list of virtual locations and virtual anchors for each VPRU in the set of VPRUs.

[0219]

[0240] Embodiment 11 is a method according to any of Embodiments 1 to 10, wherein UE-based positioning is associated with at least one difference-based positioning method.

[0220]

[0241] Embodiment 12 is the method according to any one of Embodiments 1 to 11, wherein the network entity is a location server or LMF.

[0221]

[0242] Embodiment 13 is a device for wireless communication in a UE, comprising a memory and at least one processor coupled to the memory, wherein the at least one processor is configured to perform any of embodiments 1 to 12, at least in part, based on information stored in the memory.

[0222]

[0243] Embodiment 14 is the apparatus according to Embodiment 13, further comprising at least one transceiver or antenna coupled to at least one processor.

[0223]

[0244] Embodiment 15 is an apparatus for wireless communication that includes means for carrying out any of Embodiments 1 to 12.

[0224]

[0245] Embodiment 16 is a computer-readable medium (e.g., a non-temporary computer-readable medium) for storing computer-executable code, wherein the code, when executed by a processor, causes the processor to execute any of embodiments 1 to 12.

[0225]

[0246] Embodiment 17 is a method for wireless communication in a network entity, comprising receiving a request from a UE for support data for performing UE-based positioning, the request comprising at least one of the UE's location information or a list of anchors observed by the UE, and transmitting support data for UE-based positioning to the UE based on the request, wherein the support data comprises a list of virtual anchors and a list of PRUs, the list of virtual anchors and the list of PRUs being selected based on at least one of the UE's location information or a list of anchors observed by the UE.

[0226]

[0247] Embodiment 18 is the method described in Embodiment 17, wherein the supporting data further includes an indication of whether each PRU in the list of PRUs is a physical PRU or a VPRU.

[0227]

[0248] Embodiment 19 is the method according to either Embodiment 17 or 18, wherein the list of virtual anchors is associated with at least one group identifier (ID).

[0228]

[0249] Embodiment 20 is the method according to Embodiment 19, further comprising generating anchor group information which includes a set of associations between different groups of virtual anchors and their corresponding group IDs, and transmitting the anchor group information for one or more network nodes.

[0229]

[0250] Embodiment 21 is the method according to Embodiment 20, wherein one or more network nodes can use at least one VPRU to support at least one differential-based positioning method.

[0230]

[0251] Embodiment 22 is the method of Embodiment 19, further comprising transmitting at least one group ID to the base station in response to the UE being handed over to the base station.

[0231]

[0252] Embodiment 23 is the method according to any one of Embodiments 17 to 22, wherein each virtual anchor in the list of virtual anchors corresponds to a physical anchor having a location offset.

[0232]

[0253] Embodiment 24 is the method according to any one of Embodiments 17 to 23, wherein each VPRU in the set of VPRUs is generated based on at least one physical PRU, and each VPRU in the set of VPRUs is associated with a virtual location.

[0233]

[0254] Embodiment 25 is the method according to any one of Embodiments 17 to 24, wherein the UE-based positioning is associated with at least one difference-based positioning method.

[0234]

[0255] Embodiment 26 is the method according to any one of Embodiments 17 to 25, wherein the network entity is a location server or LMF.

[0235]

[0256] Embodiment 27 is an apparatus for wireless communication in a network entity, comprising a memory and at least one processor coupled to the memory, wherein the at least one processor is configured to perform any of embodiments 17 to 26, at least in part, based on information stored in the memory.

[0236]

[0257] Embodiment 28 is the apparatus according to Embodiment 27, further comprising at least one transceiver or antenna coupled to at least one processor.

[0237]

[0258] Embodiment 29 is an apparatus for wireless communication that includes means for performing any of embodiments 17 to 26.

[0238]

[0259] Embodiment 30 is a computer-readable medium (e.g., a non-temporary computer-readable medium) for storing computer-executable code, wherein the code, when executed by a processor, causes the processor to execute any of embodiments 17 to 26.

Claims

1. A device for wireless communication in user equipment (UE), Transceiver and, Memory and The system comprises the transceiver and at least one processor coupled to the memory, wherein the at least one processor is The transceiver transmits a request to a network entity for support data for performing UE-based positioning, the request comprising at least one of the location information of the UE or a list of anchors observed by the UE. Based on the above request, the network entity receives the support data for UE-based positioning via the transceiver, the support data comprising a list of virtual anchors and a list of positioning reference units (PRUs) including a set of virtual positioning reference units (VPRUs), wherein the list of virtual anchors and the list of PRUs are selected based on at least one of the location information of the UE or a list of anchors observed by the UE, A device configured to perform UE-based positioning using at least one virtual anchor and at least one VPRU in the aforementioned support data.

2. The apparatus according to claim 1, wherein the support data further includes an indication of whether each PRU in the list of PRUs is a physical PRU or a VPRU.

3. The aforementioned at least one processor is The apparatus according to claim 2, further configured to refrain from establishing a direct connection with a PRU in the list of PRUs when each of the aforementioned PRUs is indicated as the VPRU.

4. The aforementioned at least one processor is The apparatus according to claim 2, further configured to allow a direct connection to a PRU in the list of PRUs to be established when each of the PRUs is indicated as the physical PRU.

5. The apparatus according to claim 1, wherein the list of virtual anchors is associated with at least one group identifier (ID).

6. The aforementioned at least one processor is The location information of the aforementioned UE The serving cell identifier (ID) associated with the aforementioned UE, The serving beam ID associated with the aforementioned UE, The Extended Cell ID (ECID) associated with the aforementioned UE, The previous location estimation of the aforementioned UE, The side link (SL) zone ID associated with the aforementioned UE, or The apparatus according to claim 1, further configured to acquire based on at least one of the wireless access network (RAN) independent location estimations of the UE.

7. The apparatus according to claim 1, wherein each virtual anchor in the list of virtual anchors corresponds to a physical anchor having a location offset.

8. The apparatus according to claim 1, wherein each VPRU in the set of VPRUs is generated based on at least one physical PRU, and each VPRU in the set of VPRUs is associated with a virtual location.

9. The aforementioned at least one processor is Send an indication to the network entity to use a suitable VPRU, The apparatus according to claim 1, further configured to receive the support data, including the preferred VPRU in the list of PRUs, based on the aforementioned request.

10. The aforementioned at least one processor is The apparatus according to claim 1, further configured to receive from the network entity a set of measured or corrected data for the set of VPRUs, based on a list of virtual locations for each VPRU in the set of VPRUs and the list of virtual anchors.

11. The aforementioned at least one processor, The apparatus according to claim 10, further configured to perform UE-based positioning based on the set of measured values ​​or the correction data.

12. The apparatus according to claim 1, wherein the network entity is a location server or a location management function (LMF).

13. A method of wireless communication in user equipment (UE), Sending a request to a network entity for support data for performing UE-based positioning, wherein the request includes at least one of the location information of the UE or a list of anchors observed by the UE. Based on the above request, the network entity receives the support data for UE-based positioning, wherein the support data includes a list of virtual anchors and a list of positioning reference units (PRUs) including a set of virtual positioning reference units (VPRUs), the list of virtual anchors and the list of PRUs being selected based on at least one of the location information of the UE or a list of anchors observed by the UE. Performing UE-based positioning using at least one virtual anchor and at least one VPRU in the aforementioned support data, Methods that include...

14. The method according to claim 13, wherein the support data further includes an indication of whether each PRU in the list of PRUs is a physical PRU or a VPRU.

15. The method of claim 14, further comprising refraining from establishing a direct connection with a PRU in the list of PRUs when each of the PRUs is indicated as the VPRU.

16. The method of claim 14, further comprising enabling a direct connection to a PRU in the list of PRUs when each of the PRUs is indicated as the physical PRU.

17. The location information of the aforementioned UE The serving cell identifier (ID) associated with the aforementioned UE, The serving beam ID associated with the aforementioned UE, The Extended Cell ID (ECID) associated with the aforementioned UE, The previous location estimation of the aforementioned UE, The side link (SL) zone ID associated with the aforementioned UE, or The method according to claim 13, further comprising obtaining based on at least one of the Wireless Access Network (RAN) independent location estimations of the UE.

18. Sending an indication to the network entity for using a suitable VPRU, The method of claim 13, further comprising receiving the support data, which includes the preferred VPRU in the list of PRUs, based on the request.

19. From the network entity, receive a set of measured values ​​or correction data for the set of VPRUs, based on the virtual location of each VPRU in the set of VPRUs and the list of virtual anchors. The method according to claim 13, further comprising performing UE-based positioning based on the set of measured values ​​or the correction data.

20. A device for wireless communication in a network entity, Transceiver and, Memory and The system comprises the transceiver and at least one processor coupled to the memory, wherein the at least one processor is A request for support data for performing user equipment (UE)-based positioning via the transceiver, wherein the request includes at least one of the location information of the UE or a list of anchors observed by the UE, upon receiving the request, A device configured to transmit, via the transceiver, the support data for UE-based positioning based on the request, wherein the support data includes a list of virtual anchors and a list of positioning reference units (PRUs) including a set of virtual positioning reference units (VPRUs), the list of virtual anchors and the list of PRUs being selected based on at least one of the location information of the UE or a list of anchors observed by the UE.

21. The apparatus according to claim 20, wherein the support data further includes an indication of whether each PRU in the list of PRUs is a physical PRU or a VPRU.

22. The apparatus according to claim 20, wherein the list of virtual anchors is associated with at least one group identifier (ID).

23. The aforementioned at least one processor, Generate anchor group information that includes a set of associations between different groups of virtual anchors and their corresponding group IDs. The apparatus according to claim 22, further configured to transmit the anchor group information to one or more network nodes.

24. The aforementioned at least one processor, The apparatus according to claim 22, further configured to transmit the at least one group ID in response to the UE being handed over to a base station.

25. The apparatus according to claim 20, wherein each virtual anchor in the list of virtual anchors corresponds to a physical anchor having a location offset.

26. The apparatus according to claim 20, wherein each VPRU in the set of VPRUs is generated based on at least one physical PRU, and each VPRU in the set of VPRUs is associated with a virtual location.

27. A method for wireless communication in a network entity, Receiving a request from a user device (UE) for support data for performing UE-based positioning, wherein the request includes at least one of the location information of the UE or a list of anchors observed by the UE, A method comprising transmitting the support data for UE-based positioning to the UE based on the request, wherein the support data comprises a list of virtual anchors and a list of positioning reference units (PRUs) including a set of virtual positioning reference units (VPRUs), the list of virtual anchors and the list of PRUs being selected based on at least one of the location information of the UE or a list of anchors observed by the UE.

28. The method according to claim 27, wherein the support data further includes an indication of whether each PRU in the list of PRUs is a physical PRU or a VPRU.

29. The method according to claim 27, wherein the list of virtual anchors is associated with at least one group identifier (ID).

30. This involves generating anchor group information that includes a set of associations between different groups of virtual anchors and their corresponding group IDs, The method according to claim 29, further comprising transmitting the anchor group information to one or more network nodes.

31. The method according to claim 29, further comprising transmitting the at least one group ID in response to the UE being handed over to a base station.

32. The method according to claim 27, wherein each virtual anchor in the list of virtual anchors corresponds to a physical anchor having a location offset.

33. The method according to claim 27, wherein each VPRU in the set of VPRUs is generated based on at least one physical PRU, and each VPRU in the set of VPRUs is associated with a virtual location.

Images