Radio access network (RAN) analysis exposed to location server

Abstract

Techniques for communication are disclosed. In an aspect, a location server sends a request for a radio access network (RAN) data analysis associated with a positioning session between the location server and a user equipment (UE) to a RAN controller entity, the request including at least an identifier of the positioning session, receives a response to the request for the RAN data analysis from the RAN controller entity, the response including the RAN data analysis, and transmits the RAN data analysis to the RAN controller entity. And performing a positioning procedure with the UE to determine a location of the UE based at least in part on the RAN data analysis.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims priority to Greek patent application No. 20230100089, filed on February 3, 2023, entitled “RADIO ACCESS NETWORK (RAN) ANALYTICS EXPOSURE TO THE LOCATION SERVER,” which is assigned to the assignee of this application document and is expressly incorporated herein by reference in its entirety.

[0003] Background of the Disclosure Technical Field

[0004] Aspects of the present disclosure generally relate to wireless communications. Background Art

[0005] Wireless communication systems have evolved over several generations, including first-generation analog wireless telephone service (1G), second-generation (2G) digital wireless telephone service (including temporary 2.5G and 2.75G networks), third-generation (3G) high-speed data, internet-enabled wireless services, and fourth-generation (4G) services (e.g., Long Term Evolution (LTE) or WiMax). Currently, many different types of wireless communication systems are in use, including cellular and Personal Communications Service (PCS) systems. Examples of known cellular systems include the cellular analog Advanced Mobile Phone System (AMPS), and digital cellular systems based on code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), Global System for Mobile Communications (GSM), and others.

[0006] The fifth-generation (5G) wireless standard, known as New Radio (NR), enables higher data speeds, a greater number of connections, and better coverage, among other improvements. According to the Next Generation Mobile Networks Alliance, the 5G standard is designed to provide higher data rates, more accurate positioning (e.g., based on reference signals for positioning (RS-P), such as downlink, uplink, or sidelink Positioning Reference Signals (PRS)), and other technical enhancements compared to previous standards. These enhancements, along with the use of higher frequency bands, advances in PRS procedures and technology, and high-density deployments of 5G, enable highly accurate 5G-based positioning. Summary of the Invention

[0007] The following is a simplified summary of one or more aspects disclosed herein. Therefore, the following summary should not be considered an extensive overview of all contemplated aspects, nor should it be considered to identify key or important elements related to all contemplated aspects or to delineate the scope associated with any particular aspect. Therefore, the sole purpose of the following summary is to present certain concepts related to one or more aspects of the mechanisms disclosed herein in a simplified form prior to the detailed description given below.

[0008] In one aspect, a method of communication performed by a location server includes: sending a request for a radio access network (RAN) data analysis associated with a positioning session between the location server and a user equipment (UE) to a RAN controller entity, the request including at least an identifier of the positioning session; receiving a response to the request for the RAN data analysis from the RAN controller entity, the response including the RAN data analysis; and performing a positioning procedure with the UE to determine a location of the UE based at least in part on the RAN data analysis.

[0009] In one aspect, a method of communication performed by a radio access network (RAN) controller entity includes: receiving a request from a location server for RAN data analysis associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request including at least an identifier of the positioning session; and sending a response to the request for the RAN data analysis to the location server, the response including the RAN data analysis.

[0010] In one aspect, a location server comprises: one or more memories; one or more transceivers; and one or more processors communicatively coupled to the one or more memories and the one or more transceivers, the one or more processors being configured to: send a request for RAN data analysis associated with a positioning session between the location server and a user equipment (UE) to a radio access network (RAN) controller entity via the one or more transceivers, the request including at least an identifier of the positioning session; receive a response to the request for the RAN data analysis from the RAN controller entity via the one or more transceivers, the response including the RAN data analysis; and perform a positioning procedure with the UE to determine a location of the UE based at least in part on the RAN data analysis.

[0011] In one aspect, a radio access network (RAN) controller entity includes: one or more memories; one or more transceivers; and one or more processors, which are communicatively coupled to the one or more memories and the one or more transceivers, and the one or more processors are configured to: receive, from a location server via the one or more transceivers, a request for RAN data analysis associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request including at least an identifier of the positioning session; and send, to the location server via the one or more transceivers, a response to the request for RAN data analysis, the response including the RAN data analysis.

[0012] In one aspect, a location server includes: means for sending a request for a radio access network (RAN) data analysis associated with a positioning session between the location server and a user equipment (UE) to a RAN controller entity, the request including at least an identifier of the positioning session; means for receiving a response to the request for the RAN data analysis from the RAN controller entity, the response including the RAN data analysis; and means for performing a positioning procedure with the UE to determine a location of the UE based at least in part on the RAN data analysis.

[0013] In one aspect, a radio access network (RAN) controller entity includes: a component for receiving a request from a location server for a RAN data analysis associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request including at least an identifier of the positioning session; and a component for sending a response to the request for the RAN data analysis to the location server, the response including the RAN data analysis.

[0014] In one aspect, a non-transitory computer-readable medium stores computer-executable instructions that, when executed by a location server, cause the location server to: send a request to a radio access network (RAN) controller entity for a RAN data analysis associated with a positioning session between the location server and a user equipment (UE), the request including at least an identifier of the positioning session; receive a response to the request for the RAN data analysis from the RAN controller entity, the response including the RAN data analysis; and perform a positioning procedure with the UE to determine a location of the UE based at least in part on the RAN data analysis.

[0015] In one aspect, a non-transitory computer-readable medium stores computer-executable instructions that, when executed by a radio access network (RAN) controller entity, cause the RAN controller entity to: receive from a location server a request for RAN data analysis associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request including at least an identifier of the positioning session; and send to the location server a response to the request for the RAN data analysis, the response including the RAN data analysis.

[0016] Other objects and advantages associated with the aspects disclosed herein will be apparent to those skilled in the art based on the accompanying drawings and detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings are presented to aid in describing various aspects of the present disclosure and are provided solely for illustration of the aspects and not limitation thereof.

[0018] Figure 1

[0014] Figures illustrate example wireless communication systems in accordance with aspects of the present disclosure.

[0019] Figure 2A 、 Figure 2B and Figure 2C The diagram illustrates an example wireless network structure according to aspects of the present disclosure.

[0020] Figure 3A 、 Figure 3B and Figure 3C is a simplified block diagram of several sample aspects of components that may be employed in a user equipment (UE), a base station, and a network entity, respectively, and configured to support communications as taught herein.

[0021] Figure 4 The diagram illustrates examples of various positioning methods supported in New Radio (NR) according to aspects of the present disclosure.

[0022] Figure 5 Illustrated are example Long Term Evolution (LTE) Positioning Protocol (LPP) reference sources for positioning.

[0023] Figure 6

[0014] Example location service procedures are illustrated in accordance with aspects of the present disclosure.

[0024] Figure 7 The diagram illustrates an example LPP capability transfer procedure, assistance data transfer procedure, and location information transfer procedure between a target device and a location server according to aspects of the present disclosure.

[0025] Figure 8is a diagram illustrating an example scenario for positioning a UE using artificial intelligence / machine learning positioning techniques according to aspects of the present disclosure.

[0026] Figure 9 is a diagram of an example open radio access network (O-RAN) architecture in accordance with aspects of the present disclosure.

[0027] Figure 10 is a diagram of an example network architecture in which a modified Y1 interface is implemented in accordance with aspects of the present disclosure.

[0028] Figure 11 and Figure 12 Example communication methods according to aspects of the present disclosure are illustrated. DETAILED DESCRIPTION

[0029] Various aspects of the present invention are provided in the following description and related diagrams directed to various examples provided for illustrative purposes. Various alternative aspects may be designed without departing from the scope of the present disclosure. In addition, known elements of the present disclosure will not be described in detail or will be omitted to avoid blurring the relevant details of the present disclosure.

[0030] Various aspects generally relate to wireless technologies. Some aspects more specifically relate to exposing radio access network (RAN) analytics to a location server. In some examples, a location server may establish a positioning session with a user equipment (UE) to determine the UE's location. The location server may then send a request to a RAN controller entity for RAN data analytics associated with the UE's positioning session, the request including at least an identifier of the positioning session. In response, the location server may receive the RAN data analytics from the RAN controller entity. The location server may then perform a positioning procedure with the UE based at least in part on the RAN data analytics to determine the UE's location.

[0031] Certain aspects of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages: In some instances, the described techniques can be used to provide data exposure from a RAN (e.g., a RAN controller entity) to a core network (e.g., a location server) by sending a request for RAN data analytics associated with a UE's positioning session and receiving the data analytics in response.

[0032] As used herein, the words "exemplary" and / or "example" mean "serving as an example, instance, or illustration." Any aspect described herein as "exemplary" and / or "example" is not necessarily to be construed as preferred or advantageous over other aspects. Likewise, the term "aspects of the disclosure" does not require that all aspects of the disclosure include the discussed feature, advantage, or mode of operation.

[0033] Those skilled in the art will appreciate that the information and signals described below may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the following description may be represented by voltages, currents, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof, depending in part on the specific application, in part on the desired design, in part on the corresponding technology, etc.

[0034] In addition, many aspects are described in terms of sequences of actions to be performed by, for example, elements of a computing device. It will be appreciated that the various actions described herein may be performed by specific circuits (e.g., application-specific integrated circuits), by program instructions being executed by one or more processors, or by a combination of both. In addition, the sequences of actions described herein may be viewed as being fully embodied within any form of non-transitory computer-readable storage medium having a corresponding set of computer instructions stored therein that, when executed, will cause or instruct an associated processor of a device to perform the functionality described herein. Thus, various aspects of the present disclosure may be embodied in a variety of different forms, all of which are contemplated to be within the scope of the claimed subject matter. In addition, for each of the various aspects described herein, the corresponding form of any such aspect may be described herein as, for example, “logic configured to perform the described actions.”

[0035] As used herein, unless otherwise specified, the terms "user equipment" (UE) and "base station" are not intended to be specific to or otherwise limited to any particular radio access technology (RAT). In general, a UE can be any wireless communication device (e.g., a mobile phone, router, tablet, laptop, consumer asset location device, wearable device (e.g., smartwatch, glasses, augmented reality (AR) / virtual reality (VR) headsets, etc.), vehicle (e.g., car, motorcycle, bicycle, etc.), Internet of Things (IoT) device, etc.) used by a user to communicate over a wireless communication network. A UE can be mobile or (e.g., at certain times) stationary and can communicate with a radio access network (RAN). As used herein, the term "UE" can be interchangeably referred to as an "access terminal" or "AT," "client device," "wireless device," "subscriber device," "subscriber terminal," "subscriber station," "user terminal" or "UT," "mobile device," "mobile terminal," "mobile station," or variations thereof. Generally, a UE can communicate with a core network via the RAN, and through the core network, the UE can connect to external networks (such as the Internet) and other UEs. Of course, other mechanisms for connecting to the core network and / or the Internet are also possible for the UE, such as through a wired access network, a wireless local area network (WLAN) network (eg, based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 specification, etc.), etc.

[0036] A base station can operate in accordance with one of several RATs to communicate with UEs, depending on the network in which it is deployed, and may be referred to alternatively as an access point (AP), network node, NodeB, evolved NodeB (eNB), next-generation eNB (ng-eNB), new radio (NR) NodeB (also known as gNB or gNodeB), etc. A base station may primarily support radio access for UEs, including supporting data, voice, and / or signaling connections for the supported UEs. In some systems, a base station may provide pure edge node signaling functionality, while in other systems it may provide additional control and / or network management functionality. The communication link through which a UE can send signals to a base station is referred to as an uplink (UL) channel (e.g., reverse traffic channel, reverse control channel, access channel, etc.). The communication link through which a base station can send signals to a UE is referred to as a downlink (DL) or forward link channel (e.g., paging channel, control channel, broadcast channel, forward traffic channel, etc.). As used herein, the term traffic channel (TCH) may refer to either an uplink / reverse or a downlink / forward traffic channel.

[0037] The term "base station" may refer to a single physical transmit-receive point (TRP) or to multiple physical TRPs that may or may not be co-located. For example, where the term "base station" refers to a single physical TRP, the physical TRP may be an antenna of the base station corresponding to the cell (or several cell sectors) of the base station. Where the term "base station" refers to multiple co-located physical TRPs, the physical TRP may be an antenna array of the base station (e.g., as in a multiple-input multiple-output (MIMO) system or where the base station employs beamforming). Where the term "base station" refers to multiple non-co-located physical TRPs, the physical TRP may be a distributed antenna system (DAS) (a network of spatially separated antennas connected to a common source via a transmission medium) or a remote radio head (RRH) (a remote base station connected to a serving base station). Alternatively, the non-co-located physical TRP may be a serving base station that receives measurement reports from a UE and a neighbor base station whose reference radio frequency (RF) signal the UE is measuring. Because the TRP is the point from which a base station transmits and receives wireless signals, as used herein, references to transmissions from a base station or receptions at a base station should be understood to refer to the specific TRP of the base station.

[0038] In some implementations of supporting positioning of a UE, a base station may not support wireless access by the UE (e.g., may not support data, voice, and / or signaling connections for the UE), but may instead transmit a reference signal to the UE to be measured by the UE, and / or may receive and measure signals transmitted by the UE. Such a base station may be referred to as a positioning beacon (e.g., when transmitting a signal to the UE) and / or as a position measurement unit (e.g., when receiving and measuring a signal from the UE).

[0039] An "RF signal" comprises an electromagnetic wave of a given frequency that transmits information through the space between a transmitter and a receiver. As used herein, a transmitter may transmit a single "RF signal" or multiple "RF signals" to a receiver. However, due to the propagation characteristics of RF signals through multipath channels, a receiver may receive multiple "RF signals" corresponding to each transmitted RF signal. The same transmitted RF signal on different paths between a transmitter and a receiver may be referred to as a "multipath" RF signal. As used herein, an RF signal may also be referred to as a "wireless signal" or simply a "signal," where the context clearly indicates that the term "signal" refers to either a wireless signal or an RF signal.

[0040] Figure 1The diagram illustrates an example wireless communication system 100 according to various aspects of the present disclosure. The wireless communication system 100, which may also be referred to as a wireless wide area network (WWAN), may include various base stations 102 (labeled "BS") and various UEs 104. The base stations 102 may include macrocell base stations (high-power cellular base stations) and / or small cell base stations (low-power cellular base stations). In one aspect, the macrocell base stations may include eNBs and / or ng-eNBs (where the wireless communication system 100 corresponds to an LTE network), or gNBs (where the wireless communication system 100 corresponds to an NR network), or a combination of both, and the small cell base stations may include femtocells, picocells, microcells, etc.

[0041] The base stations 102 may collectively form a RAN and interface with a core network 170 (e.g., an evolved packet core (EPC) or a 5G core (5GC)) via backhaul links 122, and interface with one or more location servers 172 (e.g., a location management function (LMF) or a secure user plane location (SUPL) location platform (SLP)) via the core network 170. The location servers 172 may be part of the core network 170 or external to the core network 170. The location servers 172 may be integrated with the base stations 102. The UE 104 may communicate with the location servers 172 directly or indirectly. For example, the UE 104 may communicate with the location server 172 via the base station 102 currently serving the UE 104. The UE 104 may also communicate with the location server 172 via another path, such as via an application server (not shown), via another network (such as via a wireless local area network (WLAN) access point (AP) (e.g., AP 150 described below), etc.). For signaling purposes, communication between UE 104 and location server 172 may be represented as an indirect connection (e.g., through core network 170, etc.) or a direct connection (e.g., as shown via direct connection 128), with intermediate nodes (if any) omitted from the signaling diagram for clarity.

[0042] Among other functions, the base stations 102 may also perform functions related to one or more of the following: transmitting user data, wireless channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection establishment and release, load balancing, distribution of non-access stratum (NAS) messages, NAS node selection, synchronization, RAN sharing, multimedia broadcast multicast service (MBMS), subscriber and device tracking, RAN information management (RIM), paging, positioning, and delivery of warning messages. The base stations 102 may communicate with each other directly or indirectly (e.g., through the EPC / 5GC) over a backhaul link 134, which may be wired or wireless.

[0043] Base stations 102 can communicate wirelessly with UEs 104. Each of base stations 102 can provide communication coverage for a corresponding geographic coverage area 110. In one aspect, one or more cells can be supported by base station 102 in each geographic coverage area 110. A "cell" is a logical communication entity used for communicating with a base station (e.g., on a certain frequency resource, which is referred to as a carrier frequency, component carrier, carrier, frequency band, etc.) and can be associated with an identifier (e.g., a physical cell identifier (PCI), an enhanced cell identifier (ECI), a virtual cell identifier (VCI), a cell global identifier (CGI), etc.) that distinguishes cells operating on the same or different carrier frequencies. In some cases, different cells can be configured according to different protocol types (e.g., machine type communication (MTC), narrowband IoT (NB-IoT), enhanced mobile broadband (eMBB), or other protocol types) that can provide access to different types of UEs. Because a cell is supported by a specific base station, depending on the context, the term "cell" can refer to either or both the logical communication entity and the base station supporting it. Additionally, because the TRP is typically the physical transmission point of a cell, the terms "cell" and "TRP" may be used interchangeably. In some cases, the term "cell" may also refer to a geographic coverage area (e.g., a sector) of a base station, as long as the carrier frequency can be detected and used for communications within a portion of the geographic coverage area 110.

[0044] While the geographic coverage areas 110 of adjacent macrocell base stations 102 may partially overlap (e.g., in a handover zone), some geographic coverage areas 110 may be substantially overlapped by a larger geographic coverage area 110. For example, a small cell base station 102' (labeled "SC" for "small cell") may have a geographic coverage area 110' that substantially overlaps with the geographic coverage areas 110 of one or more macrocell base stations 102. A network that includes both small cell base stations and macrocell base stations may be referred to as a heterogeneous network. A heterogeneous network may also include Home eNBs (HeNBs). Home eNBs may provide services to a restricted group known as a Closed Subscriber Group (CSG).

[0045] The communication link 120 between the base station 102 and the UE 104 may include uplink (also known as reverse link) transmissions from the UE 104 to the base station 102 and / or downlink (DL) (also known as forward link) transmissions from the base station 102 to the UE 104. The communication link 120 may utilize MIMO antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link 120 may be over one or more carrier frequencies. The allocation of carriers may be asymmetric with respect to the downlink and uplink (e.g., more or fewer carriers may be allocated for the downlink compared to the uplink).

[0046] The wireless communication system 100 may also include a wireless local area network (WLAN) access point (AP) 150 in communication with a WLAN station (STA) 152 via a communication link 154 in an unlicensed spectrum (e.g., 5 GHz). When communicating in the unlicensed spectrum, the WLAN STA 152 and / or the WLAN AP 150 may perform a clear channel assessment (CCA) or listen-before-talk (LBT) procedure prior to communication to determine whether the channel is available.

[0047] The small cell base station 102' can operate in licensed and / or unlicensed spectrum. When operating in the unlicensed spectrum, the small cell base station 102' can adopt LTE or NR technology and use the same 5 GHz unlicensed spectrum used by the WLAN AP 150. The small cell base station 102' adopting LTE / 5G in the unlicensed spectrum can improve the coverage and / or increase the capacity of the access network. NR in the unlicensed spectrum can be referred to as NR-U. LTE in the unlicensed spectrum can be referred to as LTE-U, License Assisted Access (LAA), or MulteFire.

[0048] The wireless communication system 100 may also include a millimeter wave (mmW) base station 180, which can operate in mmW and / or near-mmW frequencies to communicate with UE 182. Extremely high frequencies (EHF) are part of the RF portion of the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and a wavelength between 1 mm and 10 mm. Radio waves in this frequency band may be referred to as millimeter waves. Near-mmW frequencies extend down to frequencies of 3 GHz, with a wavelength of 100 mm. Super high frequency (SHF) frequency bands extend between 3 GHz and 30 GHz and are also known as centimeter waves. Communications using mmW / near-mmW radio frequency bands have high path loss and relatively short range. The mmW base station 180 and the UE 182 may utilize beamforming (transmit and / or receive) on the mmW communication link 184 to compensate for the extremely high path loss and short range. Furthermore, it should be understood that in alternative configurations, one or more base stations 102 may also transmit using mmW or near-mmW frequencies and beamforming. Therefore, it should be understood that the foregoing description is merely exemplary and should not be construed as limiting the various aspects disclosed herein.

[0049] Transmit beamforming is a technique used to focus an RF signal in a specific direction. Traditionally, when a network node (e.g., a base station) broadcasts an RF signal, it broadcasts it in all directions (omnidirectionally). With transmit beamforming, the network node determines where a given target device (e.g., a UE) is located relative to the transmitting network node and projects a stronger downlink RF signal in that specific direction, thereby providing the receiving device with a faster (in terms of data rate) and stronger RF signal. To alter the directionality of the RF signal while transmitting, the network node can control the phase and relative amplitude of the RF signal at each of the one or more transmitters broadcasting the RF signal. For example, the network node may use an antenna array (referred to as a "phased array" or "antenna array") that creates an RF wave beam that can be "steered" to point in different directions without actually moving the antennas. Specifically, the RF currents from the transmitter are fed to the individual antennas in the correct phase relationship, so that the radio waves from the separate antennas add together to increase radiation in the desired direction while canceling to suppress radiation in undesired directions.

[0050] Transmit beams can be quasi-co-located, meaning they appear to have the same parameters to a receiver (e.g., a UE) regardless of whether the network node's transmit antenna is physically co-located. In NR, four types of quasi-co-location (QCL) relationships exist. Specifically, a given type of QCL relationship means that certain parameters about a second reference RF signal on a second beam can be derived from information about the source reference RF signal on the source beam. Therefore, if the source reference RF signal is QCL type A, the receiver can use it to estimate the Doppler shift, Doppler spread, average delay, and delay spread of a second reference RF signal transmitted on the same channel. If the source reference RF signal is QCL type B, the receiver can use it to estimate the Doppler shift and Doppler spread of the second reference RF signal transmitted on the same channel. If the source reference RF signal is QCL type C, the receiver can use it to estimate the Doppler shift and average delay of the second reference RF signal transmitted on the same channel. If the source reference RF signal is QCL type D, the receiver can use it to estimate the spatial reception parameters of the second reference RF signal transmitted on the same channel.

[0051] In receive beamforming, a receiver uses receive beams to amplify RF signals detected on a given channel. For example, a receiver may increase the gain setting of an antenna array and / or adjust the phase setting of an antenna array in a particular direction to amplify (e.g., increase the gain level of) RF signals received from that direction. Therefore, when a receiver is said to be beamforming in a certain direction, it means that the beam gain in that direction is high relative to the beam gain along other directions, or that the beam gain in that direction is highest compared to the beam gain in that direction for all other receive beams available to the receiver. This results in a stronger received signal strength (e.g., reference signal received power (RSRP), reference signal received quality (RSRQ), signal-to-interference-plus-noise ratio (SINR), etc.) for RF signals received from that direction.

[0052] The transmit and receive beams can be spatially correlated. This spatial correlation means that the parameters of the second beam (e.g., transmit or receive beam) used for the second reference signal can be derived from information about the first beam (e.g., receive beam or transmit beam) used for the first reference signal. For example, a UE can use a specific receive beam to receive a reference downlink reference signal (e.g., a synchronization signal block (SSB)) from a base station. The UE can then form a transmit beam for transmitting an uplink reference signal (e.g., a sounding reference signal (SRS)) to the base station based on the parameters of the receive beam.

[0053] Note that a "downlink" beam can be either a transmit beam or a receive beam, depending on the entity that forms it. For example, if a base station is forming a downlink beam to transmit a reference signal to a UE, the downlink beam is a transmit beam. However, if a UE is forming a downlink beam, it is a receive beam that receives downlink reference signals. Similarly, an "uplink" beam can be either a transmit beam or a receive beam, depending on the entity that forms it. For example, if a base station is forming an uplink beam, it is an uplink receive beam, and if a UE is forming an uplink beam, it is an uplink transmit beam.

[0054] The electromagnetic spectrum is typically subdivided into various categories, bands, channels, and so on, based on frequency / wavelength. In 5G NR, two initial operating bands have been identified with the frequency range designations FR1 (410 MHz-7.125 GHz) and FR2 (24.25 GHz-52.6 GHz). It should be understood that, although a portion of FR1 extends above 6 GHz, FR1 is often (interchangeably) referred to as the "sub-6 GHz" band in various documents and articles. A similar naming convention sometimes arises regarding FR2, although, unlike the Extremely High Frequency (EHF) band (30 GHz-300 GHz), which is designated as a "millimeter wave" band by the International Telecommunication Union (ITU), FR2 is often (interchangeably) referred to as the "millimeter wave" band in various documents and articles.

[0055] Frequencies between FR1 and FR2 are often referred to as mid-band frequencies. Recent 5G NR research has identified operating bands for these mid-band frequencies as Frequency Range Designation FR3 (7.125 GHz-24.25 GHz). Frequency bands falling within FR3 can inherit FR1 characteristics and / or FR2 characteristics, effectively extending the features of FR1 and / or FR2 to mid-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 FR4a or FR4-1 (52.6 GHz-71 GHz), FR4 (52.6 GHz-114.25 GHz), and FR5 (114.25 GHz-300 GHz). Each of these higher frequency bands falls within the EHF band.

[0056] In view of the above, unless otherwise specified, it should be understood that the term "sub-6 GHz" and the like, if used herein, can broadly refer to frequencies that can be less than 6 GHz, can be within FR1, or can include mid-band frequencies. In addition, unless otherwise specified, it should be understood that the term "millimeter wave" and the like, if used herein, can broadly refer to frequencies that can include mid-band frequencies, can be within FR2, FR4, FR4-a or FR4-1 and / or FR5, or can be within the EHF band.

[0057] In a multi-carrier system (such as 5G), one of the carrier frequencies is referred to as the "primary carrier" or "anchor carrier," or "primary serving cell" or "PCell," and the remaining carrier frequencies are referred to as "secondary carriers," "secondary serving cells," or "SCells." In carrier aggregation, the anchor carrier is the carrier operating on the primary frequency (e.g., FR1) utilized by the UE 104 / 182 and the cell in which the UE 104 / 182 performs an initial radio resource control (RRC) connection establishment procedure or initiates an RRC connection re-establishment procedure. The primary carrier carries all common and UE-specific control channels and can be a carrier in a licensed frequency (however, this is not always the case). A secondary carrier is a carrier operating on a second frequency (e.g., FR2) that can be configured once an RRC connection is established between the UE 104 and the anchor carrier and can be used to provide additional radio resources. In some cases, the secondary carrier can be a carrier in an unlicensed frequency. A secondary carrier may contain only necessary signaling information and signals; for example, UE-specific signaling information and signals may not be present in a secondary carrier, as primary uplink and downlink carriers are typically UE-specific. This means that different UEs 104 / 182 in a cell can have different downlink primary carriers. The same is true for uplink primary carriers. The network can change the primary carrier for any UE 104 / 182 at any time. This is done, for example, to balance the load on different carriers. Because a "serving cell" (whether a PCell or SCell) corresponds to the carrier frequency / component carrier on which a base station is communicating, the terms "cell," "serving cell," "component carrier," "carrier frequency," etc., are used interchangeably.

[0058] For example, still referring to Figure 1 One of the frequencies utilized by macrocell base station 102 may be an anchor carrier (or "PCell"), and the other frequencies utilized by macrocell base station 102 and / or mmW base station 180 may be secondary carriers ("SCells"). Simultaneous transmission and / or reception of multiple carriers enables UE 104 / 182 to significantly increase its data transmission and / or reception rate. For example, two 20 MHz aggregated carriers in a multi-carrier system would theoretically result in a two-fold increase in data rate (i.e., 40 MHz) compared to the data rate achieved with a single 20 MHz carrier.

[0059] The wireless communication system 100 may also include a UE 164, which may communicate with the macrocell base station 102 over a communication link 120 and / or with the mmW base station 180 over a mmW communication link 184. For example, the macrocell base station 102 may support a PCell and one or more SCells for the UE 164, and the mmW base station 180 may support one or more SCells for the UE 164.

[0060] In some cases, UE 164 and UE 182 may be capable of sidelink communication. Sidelink-capable UEs (SL-UEs) can communicate with base station 102 over communication link 120 using the Uu interface (i.e., the air interface between the UE and the base station). SL-UEs (e.g., UE 164, UE 182) can also communicate directly with each other via wireless sidelink 160 using the PC5 interface (i.e., the air interface between sidelink-capable UEs). A wireless sidelink (or just "sidelink") is an adaptation of core cellular (e.g., LTE, NR) standards that allows direct communication between two or more UEs without going through a base station. Sidelink communication can be unicast or multicast and can be used for device-to-device (D2D) media sharing, vehicle-to-vehicle (V2V) communication, vehicle-to-everything (V2X) communication (e.g., cellular V2X (cV2X) communication, enhanced V2X (eV2X) communication, etc.), emergency rescue applications, and more. One or more of a group of SL-UEs utilizing sidelink communication may be within the geographic coverage area 110 of the base station 102. Other SL-UEs in such a group may be outside the geographic coverage area 110 of the base station 102 or otherwise unable to receive transmissions from the base station 102. In some cases, a group of SL-UEs communicating via sidelink communication may utilize a one-to-many (1:M) system, where each SL-UE transmits to every other SL-UE in the group. In some cases, the base station 102 facilitates scheduling of resources for sidelink communication. In other cases, sidelink communication is performed between the SL-UEs without involving the base station 102.

[0061] In one aspect, sidelink 160 can operate on a wireless communication medium of interest, which can be shared with other vehicles and / or infrastructure access points, as well as other wireless communications between other RATs. A "medium" can consist of one or more time, frequency, and / or spatial communication resources (e.g., comprising one or more channels across one or more carriers) associated with wireless communications between one or more transmitter / receiver pairs. In one aspect, the medium of interest can correspond to at least a portion of an unlicensed frequency band shared between various RATs. While various licensed frequency bands have been reserved for certain communication systems (e.g., by government entities such as the Federal Communications Commission (FCC) in the United States), these systems (particularly those employing small cell access points) have recently expanded their operation into unlicensed frequency bands, such as the Unlicensed National Information Infrastructure (U-NII) band used by wireless local area network (WLAN) technologies (most notably the IEEE 802.11x WLAN technology commonly referred to as "Wi-Fi"). Example systems of this type include different variations of CDMA systems, TDMA systems, FDMA systems, Orthogonal FDMA (OFDMA) systems, Single-Carrier FDMA (SC-FDMA) systems, and the like.

[0062] Note that although Figure 1 Only two of the UEs are illustrated as SL-UEs (i.e., UEs 164 and 182), but any of the illustrated UEs may be SL-UEs. Furthermore, while only UE 182 is depicted as capable of beamforming, any of the illustrated UEs (including UE 164) may be capable of beamforming. Where SL-UEs are capable of beamforming, they may beamform toward each other (i.e., toward other SL-UEs), toward other UEs (e.g., UE 104), toward a base station (e.g., base stations 102, 180, small cell 102', access point 150), and so forth. Thus, in some cases, UEs 164 and 182 may utilize beamforming on sidelink 160.

[0063] exist Figure 1 In the example of FIG. 1 , any of the UEs shown (for simplicity, in FIG. Figure 1A UE 104 (shown as a single UE 104) can receive signals 124 from one or more Earth-orbiting space vehicles (SVs) 112 (e.g., satellites). In one aspect, SVs 112 can be part of a satellite positioning system that UEs 104 can use as an independent source of location information. A satellite positioning system typically includes a system of transmitters (e.g., SVs 112) positioned to enable receivers (e.g., UEs 104) to determine their location on or above the Earth based, at least in part, on positioning signals (e.g., signals 124) received from the transmitters. Such transmitters typically transmit signals marked with a repeating pseudorandom noise (PN) code that is a set number of chips. While typically located in SVs 112, transmitters can sometimes be located in ground-based control stations, base stations 102, and / or other UEs 104. UEs 104 can include one or more specialized receivers specifically designed to receive signals 124 for deriving geographic location information from SVs 112.

[0064] In a satellite positioning system, the use of signal 124 may be enhanced by various satellite-based augmentation systems (SBAS), which may be associated with or otherwise enabled for use with one or more global and / or regional navigation satellite systems. For example, SBAS may include augmentation systems that provide integrity information, differential corrections, and the like, such as the Wide Area Augmentation System (WAAS), the European Geostationary Navigation Overlay Service (EGNOS), the Multifunctional Satellite Augmentation System (MSAS), the Global Positioning System (GPS) Assisted Geo-Augmented Navigation, or the GPS and Geo-Augmented Navigation System (GAGAN), among others. Thus, as used herein, a satellite positioning system may include any combination of one or more global and / or regional navigation satellites associated with such one or more satellite positioning systems.

[0065] In one aspect, SV 112 may additionally or alternatively be part of one or more non-terrestrial networks (NTNs). In an NTN, SV 112 connects to an earth station (also known as a ground station, NTN gateway, or gateway), which in turn connects to elements in the 5G network, such as an improved base station 102 (without a terrestrial antenna) or a network node in the 5GC. This element, in turn, provides access to other elements in the 5G network and ultimately to entities external to the 5G network, such as internet web servers and other user devices. In this manner, UE 104 can receive communication signals (e.g., signal 124) from SV 112 instead of, or in addition to, receiving communication signals from terrestrial base station 102.

[0066] The wireless communication system 100 may also include one or more UEs (eg, UE 190) indirectly connected to one or more communication networks via one or more device-to-device (D2D) peer-to-peer (P2P) links (referred to as "side links"). Figure 1 In the example of FIG. 1 , UE 190 has a D2D P2P link 192 with one of UEs 104 connected to one of base stations 102 (e.g., through which UE 190 can indirectly obtain cellular connectivity) and a D2D P2P link 194 with a WLAN STA 152 connected to a WLAN AP 150 (through which UE 190 can indirectly obtain WLAN-based Internet connectivity). In one example, D2D P2P links 192 and 194 can be supported using any well-known D2D RAT, such as LTE Direct (LTE-D), WiFi Direct (WiFi-D), Bluetooth®, etc.

[0067] Figure 2A An example wireless network architecture 200 is shown. For example, the 5GC 210 (also known as the Next Generation Core (NGC)) can be functionally considered to include control plane (C-plane) functions 214 (e.g., UE registration, authentication, network access, gateway selection, etc.) and user plane (U-plane) functions 212 (e.g., UE gateway functions, access to data networks, IP routing, etc.), which operate collaboratively to form the core network. A user plane interface (NG-U) 213 and a control plane interface (NG-C) 215 connect gNBs 222 to the 5GC 210, and specifically to the user plane functions 212 and control plane functions 214, respectively. In additional configurations, ng-eNBs 224 can also connect to the 5GC 210 via NG-C 215 to connect to the control plane functions 214 and to the user plane functions 212 via NG-U 213. Furthermore, ng-eNBs 224 can communicate directly with gNBs 222 via backhaul connections 223. In some configurations, the next generation RAN (NG-RAN) 220 may have one or more gNBs 222, while other configurations include one or more of ng-eNBs 224 and gNBs 222. Either (or both) the gNB 222 or the ng-eNB 224 may communicate with one or more UEs 204 (e.g., any of the UEs described herein).

[0068] Another optional aspect may include a location server 230 that can communicate with the 5GC 210 to provide location assistance for the UE 204. The location server 230 can be implemented as multiple separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively, each can correspond to a single server. The location server 230 can be configured to support one or more location services for the UE 204, which can connect to the location server 230 via the core network 5GC 210 and / or via the Internet (not shown). Furthermore, the location server 230 can be integrated into a component of the core network, or alternatively can be external to the core network (e.g., a third-party server, such as an original equipment manufacturer (OEM) server or a service server).

[0069] Figure 2B Another example wireless network structure 240 is shown. 5GC 260 (which may correspond to Figure 2AThe 5GC 210 in the 5GC 210 can be functionally considered to include control plane functions provided by the access and mobility management function (AMF) 264 and user plane functions provided by the user plane function (UPF) 262, which operate in collaboration to form the core network (i.e., 5GC 260). The functions of the AMF 264 include registration management, connection management, reachability management, mobility management, lawful interception, transmission of session management (SM) messages between one or more UEs 204 (e.g., any of the UEs described herein) and a session management function (SMF) 266, a transparent proxy service for routing SM messages, access authentication and access authorization, transmission of short message service (SMS) messages between the UE 204 and a short message service function (SMSF) (not shown), and a security anchor function (SEAF). The AMF 264 also interacts with an authentication server function (AUSF) (not shown) and the UE 204, and receives intermediate keys established as a result of the UE 204 authentication process. In the case of UMTS (Universal Mobile Telecommunications System) Subscriber Identity Module (USIM)-based authentication, the AMF 264 retrieves security material from the AUSF. The AMF 264's functionality also includes Security Context Management (SCM). The SCM receives keys from the SEAF, which it uses to derive access network-specific keys. The AMF 264's functionality also includes location service management for regulated services, transmission of location service messages between the UE 204 and the Location Management Function (LMF) 270 (which acts as the location server 230), transmission of location service messages between the NG-RAN 220 and the LMF 270, allocation of Evolved Packet System (EPS) bearer identifiers for interworking with the EPS, and notification of UE 204 mobility events. Furthermore, the AMF 264 supports functionality for non-3GPP (Third Generation Partnership Project) access networks.

[0070] The functions of the UPF 262 include serving as an anchor point for intra-RAT / inter-RAT mobility (when applicable), serving as an external protocol data unit (PDU) session point for interconnection to a data network (not shown), providing packet routing and forwarding, packet inspection, user plane policy rule enforcement (e.g., gating, redirection, traffic steering), lawful interception (user plane collection), traffic usage reporting, user plane quality of service (QoS) processing (e.g., uplink / downlink rate enforcement, reflective QoS marking in the downlink), uplink traffic verification (service data flow (SDF) to QoS flow mapping), transport-level packet marking in the uplink and downlink, downlink packet buffering and downlink data notification triggering, and sending and forwarding one or more "end markers" to the source RAN node. The UPF 262 may also support the transmission of location service messages between the UE 204 and a location server (such as the SLP 272) over the user plane.

[0071] The functions of the SMF 266 include session management, UE Internet Protocol (IP) address allocation and management, selection and control of user plane functions, configuring traffic steering at the UPF 262 to route traffic to the appropriate destination, controlling some policy enforcement and QoS, and downlink data notification. The interface through which the SMF 266 communicates with the AMF 264 is called the N11 interface.

[0072] Another optional aspect may include an LMF 270 that can communicate with the 5GC 260 to provide location assistance for the UE 204. The LMF 270 can be implemented as multiple separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively, each can correspond to a single server. The LMF 270 can be configured to support one or more location services for the UE 204, which can connect to the LMF 270 via the core network 5GC 260 and / or via the Internet (not shown). The SLP 272 may support similar functionality as the LMF 270, but whereas the LMF 270 may communicate with the AMF 264, the NG-RAN 220, and the UE 204 on a control plane (e.g., using interfaces and protocols intended to convey signaling messages rather than voice or data), the SLP 272 may communicate with the UE 204 and external clients (e.g., third-party servers 274) on a user plane (e.g., using protocols intended to carry voice and / or data, such as Transmission Control Protocol (TCP) and / or IP).

[0073] Yet another optional aspect may include a third-party server 274 that can communicate with the LMF 270, the SLP 272, the 5GC 260 (e.g., via the AMF 264 and / or the UPF 262), the NG-RAN 220, and / or the UE 204 to obtain location information (e.g., a location estimate) of the UE 204. Thus, in some cases, the third-party server 274 may be referred to as a location service (LCS) client or an external client. The third-party servers 274 may be implemented as multiple separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively, each may correspond to a single server.

[0074] The user plane interface 263 and the control plane interface 265 connect the 5GC 260 (specifically, the UPF 262 and the AMF 264, respectively) to one or more gNBs 222 and / or ng-eNBs 224 in the NG-RAN 220. The interface between the gNB 222 and / or ng-eNB 224 and the AMF 264 is referred to as the "N2" interface, and the interface between the gNB 222 and / or ng-eNB 224 and the UPF 262 is referred to as the "N3" interface. The gNBs 222 and / or ng-eNBs 224 of the NG-RAN 220 can communicate directly with each other via the backhaul connection 223 (referred to as the "Xn-C" interface). One or more of the gNBs 222 and / or ng-eNBs 224 can communicate with one or more UEs 204 via a wireless interface referred to as the "Uu" interface.

[0075] The functionality of a gNB 222 can be divided between a gNB Central Unit (gNB-CU) 226, one or more gNB Distributed Units (gNB-DUs) 228, and one or more gNB Radio Units (gNB-RUs) 229. The gNB-CU 226 is a logical node that includes base station functions such as user data transfer, mobility control, radio access network sharing, positioning, and session management, in addition to those functions specifically assigned to the gNB-DU 228. More specifically, the gNB-CU 226 typically hosts the Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP) protocols for the gNB 222. The gNB-DU 228 is a logical node that typically hosts the Radio Link Control (RLC) and Medium Access Control (MAC) layers for the gNB 222. Its operation is controlled by the gNB-CU 226. One gNB-DU 228 can support one or more cells, and one cell is supported by only one gNB-DU 228. The interface 232 between the gNB-CU 226 and one or more gNB-DUs 228 is referred to as the "F1" interface. The physical (PHY) layer functions of the gNB 222 are typically hosted by one or more independent gNB-RUs 229, which perform functions such as power amplification and signal transmission / reception. The interface between the gNB-DU 228 and the gNB-RU 229 is referred to as the "Fx" interface. Thus, the UE 204 communicates with the gNB-CU 226 via the RRC, SDAP, and PDCP layers, with the gNB-DU 228 via the RLC and MAC layers, and with the gNB-RU 229 via the PHY layer.

[0076] The deployment of a communication system (such as a 5G NR system) can be arranged in a variety of ways using various components or parts. In a 5G NR system or network, a network node, a network entity, a mobility element of a network, a RAN node, a core network node, a network element or a network device (such as a base station), or one or more units (or one or more components) performing base station functions can be implemented in a converged or disaggregated architecture. For example, a base station (such as a NodeB (NB), an evolved NB (eNB), a NR base station, a 5G NR base station, an access point (AP), a transmit / receive point (TRP), or a cell) can be implemented as a converged base station (also known as a standalone base station or a single-chip base station) or a disaggregated base station.

[0077] A converged base station can be configured to utilize a radio protocol stack that is physically or logically integrated within a single RAN node. A disaggregated base station can be configured to utilize a protocol stack that is physically or logically distributed across two or more units, such as one or more central or centralized units (CUs), one or more distributed units (DUs), or one or more radio units (RUs). In some aspects, a CU can be implemented within a RAN node, and one or more DUs can be co-located with the CU, or alternatively, can be geographically or virtually distributed across one or more other RAN nodes. A DU can be implemented to communicate with one or more RUs. Each of the CU, DU, and RU can also be implemented as a virtual unit, namely a virtual central unit (VCU), a virtual distributed unit (VDU), or a virtual radio unit (VRU).

[0078] Base station type operations or network design can take into account the aggregated nature of base station functionality. For example, disaggregated base stations can be utilized in integrated access backhaul (IAB) networks, open radio access networks (O-RAN, such as those sponsored by the O-RAN Alliance), or virtualized radio access networks (vRAN, also known as cloud radio access networks (C-RAN)). Disaggregation can include distributing functionality across two or more units at various physical locations, as well as virtually distributing functionality for at least one unit, which can enable flexibility in network design. The various units of a disaggregated base station or disaggregated RAN architecture can be configured for wired or wireless communication with at least one other unit.

[0079] Figure 2CAn example disaggregated base station architecture 250 is shown, in accordance with aspects of the present disclosure. The disaggregated base station architecture 250 may include one or more central units (CUs) 80 (e.g., gNB-CUs 226), which may communicate directly with a core network 267 (e.g., 5GC 210, 5GC 260) via backhaul links, or indirectly with the core network 267 through one or more disaggregated base station units, such as a near real-time (near-RT) RAN intelligent controller (RIC) 259 via an E2 link, or a non-real-time (non-RT) RIC 257 associated with a service management and orchestration (SMO) framework 255, or both. A CU 280 (also referred to as an "O-CU" 280) may communicate with one or more distributed units (DUs) 285 (e.g., gNB-DUs 228) via corresponding midhaul links (e.g., an F1 interface). The DU 285 (also referred to as an "O-DU" 285) can communicate with one or more radio units (RUs) 287 (e.g., gNB-RU 229) via corresponding fronthaul links. The RU 287 (also referred to as an "O-RU" 287) can communicate with a corresponding UE 204 via one or more radio frequency (RF) access links. In some implementations, a UE 204 can be served by multiple RUs 287 simultaneously.

[0080] Each unit (i.e., CU 280, DU 285, RU 287, and near-RT RIC 259, non-RT RIC 257, and SMO framework 255) may include one or more interfaces, or be coupled to one or more interfaces, configured to receive or transmit signals, data, or information (collectively, signals) via a wired or wireless transmission medium. Each of the units, or an associated processor or controller that provides instructions to the unit's communication interface, may be configured to communicate with one or more of the other units via a transmission medium. For example, a unit may include a wired interface that is configured to receive signals or transmit signals to one or more other units via a wired transmission medium. Additionally, a unit may include a wireless interface that may include a receiver, transmitter, or transceiver (such as a radio frequency (RF) transceiver) that is configured to receive or transmit signals, or both, to one or more other units via a wireless transmission medium.

[0081] In some aspects, the CU 280 may host one or more higher-layer control functions. Such control functions may include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function may be implemented using an interface configured to transmit signals with other control functions hosted by the CU 280. The CU 280 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 embodiments, the CU 280 may be logically split 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 may communicate bidirectionally with the CU-CP units via an interface (such as an E1 interface). The CU 280 may be implemented to communicate with the DU 285 as needed for network control and signaling.

[0082] The DU 285 may correspond to a logical unit that includes one or more base station functions for controlling the operation of one or more RUs 287. In some aspects, the DU 285 may host one or more of a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more higher physical (PHY) layers (e.g., modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.), depending at least in part on a functional partitioning (such as those defined by the Third Generation Partnership Project (3GPP)). In some aspects, the DU 285 may also host one or more lower PHY layers. Each layer (or module) may be implemented using an interface configured to communicate signals with other layers (and modules) hosted by the DU 285 or with control functions hosted by the CU 280.

[0083] Lower layer functions may be implemented by one or more RUs 287. In some deployments, a RU 287 controlled by a DU 285 may correspond to a logical node that hosts RF processing functions or low-PHY layer functions (e.g., performing Fast Fourier Transforms (FFTs), Inverse FFTs (iFFTs), digital beamforming, Physical Random Access Channel (PRACH) extraction and filtering, etc.), or both, based at least in part on functional partitioning (e.g., lower layer functional partitioning). In such an architecture, the RU 287 may be implemented to handle over-the-air (OTA) communications with one or more UEs 204. In some implementations, both real-time and non-real-time aspects of control and user plane communications with the RU 287 may be controlled by the corresponding DU 285. In some scenarios, this configuration may enable the DU 285 and CU 280 to be implemented in a cloud-based RAN architecture, such as a vRAN architecture.

[0084] The SMO framework 255 can be configured to support RAN deployment and the provisioning of non-virtualized and virtualized network elements. For non-virtualized network elements, the SMO framework 255 can be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which can be managed via operations and maintenance interfaces (such as the O1 interface). For virtualized network elements, the SMO framework 255 can be configured to interact with a cloud computing platform (such as Open Cloud (O-Cloud) 269) to perform network element lifecycle management (such as instantiating virtualized network elements) via cloud computing platform interfaces (such as the O2 interface). Such virtualized network elements may include, but are not limited to, CU 280, DU 285, RU 287, and near-RT RIC 259. In some implementations, the SMO framework 255 can communicate with 4G RAN hardware (such as Open eNB (O-eNB) 261) via the O1 interface. The SMO framework 255 may also include a non-RT RIC 257 configured to support the functions of the SMO framework 255.

[0085] The non-RT RIC 257 may be configured to include logic functions that implement non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updating, or policy-based guidance of applications / features in the near-RT RIC 259. The non-RT RIC 257 may be coupled to or in communication with the near-RT RIC 259 (e.g., via an A1 interface). The near-RT RIC 259 may be configured to include logic functions that implement near-real-time control and optimization of RAN elements and resources through data collection and actions via an interface connecting one or more CUs 280, one or more DUs 285, or both, and an O-eNB to the near-RT RIC 259 (e.g., via an E2 interface).

[0086] In some implementations, the non-RT RIC 257 can receive parameters or external enrichment information from an external server to generate the AI / ML model to be deployed in the near-RT RIC 259. This information can be used by the near-RT RIC 259 and can be received from non-network data sources or from network functions at the SMO framework 255 or the non-RT RIC 257. In some examples, the non-RT RIC 257 or the near-RT RIC 259 can be configured to tune RAN behavior or performance. For example, the non-RT RIC 257 can monitor long-term trends and patterns in performance and employ AI / ML models to perform corrective actions through the SMO framework 255 (such as via reconfiguration of O1) or through the creation of RAN management policies (such as A1 policies).

[0087] Figure 3A 、3B 3C illustrate a network entity 306 (which may correspond to or embody any of the network functions described herein, including location server 230 and LMF 270), which may be coupled to UE 302 (which may correspond to any of the UEs described herein), base station 304 (which may correspond to any of the base stations described herein), and network entity 306 (which may correspond to or embody any of the network functions described herein, including location server 230 and LMF 270), or alternatively may be independent thereof. Figure 2A and 2B Several example components (represented by corresponding blocks) within the NG-RAN 220 and / or 5GC 210 / 260 infrastructure (such as a dedicated network) depicted in the present disclosure are provided to support the operations described herein. It should be understood that, in different implementations, these components may be implemented in different types of devices (e.g., in an ASIC, in a system-on-chip (SoC), etc.). The illustrated components may also be incorporated into other devices within a communication system. For example, other devices within the system may include components similar to those described to provide similar functionality. Furthermore, a given device may include one or more components. For example, a device may include multiple transceiver components that enable the device to operate on multiple carriers and / or communicate via different technologies.

[0088] UE 302 and base station 304 each include one or more wireless wide area network (WWAN) transceivers 310 and 350, respectively, which provide means (e.g., means for transmitting, means for receiving, means for measuring, means for tuning, means for refraining from transmitting, etc.) for communicating via one or more wireless communication networks (not shown) (such as NR networks, LTE networks, GSM networks, etc.). WWAN transceivers 310 and 350 can each be connected to one or more antennas 316 and 356, respectively, for communicating with other network nodes (such as other UEs, access points, base stations (e.g., eNBs, gNBs), etc.) over a wireless communication medium of interest (e.g., a certain set of time / frequency resources in a specific spectrum) via at least one designated RAT (e.g., NR, LTE, GSM, etc.). The WWAN transceivers 310 and 350 can be variously configured to transmit and encode signals 318 and 358 (e.g., messages, indicators, information, etc.), respectively, and conversely, to receive and decode signals 318 and 358 (e.g., messages, indicators, information, pilots, etc.), respectively, according to a specified RAT. Specifically, the WWAN transceivers 310 and 350 include one or more transmitters 314 and 354, respectively, for transmitting and encoding the signals 318 and 358, respectively, and one or more receivers 312 and 352, respectively, for receiving and decoding the signals 318 and 358, respectively.

[0089] In at least some cases, the UE 302 and the base station 304 each further include one or more short-range wireless transceivers 320 and 360, respectively. The short-range wireless transceivers 320 and 360 can be connected to one or more antennas 326 and 366, respectively, and provide means (e.g., means for transmitting, means for receiving, means for measuring, means for tuning, means for refraining from transmitting, etc.) for communicating with other network nodes (such as other UEs, access points, base stations, etc.) over a wireless communication medium of interest via at least one designated RAT (e.g., WiFi, LTE-D, Bluetooth®, Zigbee®, Z-Wave®, PC5, Dedicated Short Range Communication (DSRC), Wireless Access for Vehicular Environments (WAVE), Near Field Communication (NFC), Ultra-Wideband (UWB), etc.). The short-range wireless transceivers 320 and 360 can be variously configured to transmit and encode signals 328 and 368 (e.g., messages, indications, information, etc.), respectively, and conversely, to receive and decode signals 328 and 368 (e.g., messages, indications, information, pilots, etc.), respectively, according to a designated RAT. Specifically, the short-range wireless transceivers 320 and 360 include one or more transmitters 324 and 364 for transmitting and encoding signals 328 and 368, respectively, and one or more receivers 322 and 362 for receiving and decoding signals 328 and 368, respectively. As specific examples, the short-range wireless transceivers 320 and 360 can be WiFi transceivers, Bluetooth® transceivers, Zigbee® and / or Z-Wave® transceivers, NFC transceivers, UWB transceivers, or vehicle-to-vehicle (V2V) and / or vehicle-to-everything (V2X) transceivers.

[0090] At least in some cases, UE 302 and base station 304 also include satellite signal receivers 330 and 370. Satellite signal receivers 330 and 370 can be connected to one or more antennas 336 and 376, respectively, and can provide components for receiving and / or measuring satellite positioning / communication signals 338 and 378, respectively. If satellite signal receivers 330 and 370 are satellite positioning system receivers, satellite positioning / communication signals 338 and 378 can be Global Positioning System (GPS) signals, Global Navigation Satellite System (GLONASS) signals, Galileo signals, BeiDou signals, Indian Regional Navigation Satellite System (NAVIC), Quasi-Zenith Satellite System (QZSS), etc. If satellite signal receivers 330 and 370 are non-terrestrial network (NTN) receivers, satellite positioning / communication signals 338 and 378 can be communication signals (e.g., carrying control and / or user data) originating from a 5G network. Satellite signal receivers 330 and 370 may include any suitable hardware and / or software for receiving and processing, respectively, satellite positioning / communication signals 338 and 378. Satellite signal receivers 330 and 370 may request information and operations from other systems as appropriate and, at least in some cases, perform calculations using measurements obtained by any suitable satellite positioning system algorithm to determine the positions of UE 302 and base station 304, respectively.

[0091] Base station 304 and network entity 306 each include one or more network transceivers 380 and 390, respectively, which provide means (e.g., means for transmitting, means for receiving, etc.) for communicating with other network entities (e.g., other base stations 304, other network entities 306). For example, base station 304 may employ one or more network transceivers 380 to communicate with other base stations 304 or network entities 306 via one or more wired or wireless backhaul links. As another example, network entity 306 may employ one or more network transceivers 390 to communicate with one or more base stations 304 via one or more wired or wireless backhaul links, or with other network entities 306 via one or more wired or wireless core network interfaces.

[0092] A transceiver can be configured to communicate over a wired or wireless link. A transceiver (whether a wired or wireless transceiver) includes transmitter circuitry (e.g., transmitters 314, 324, 354, 364) and receiver circuitry (e.g., receivers 312, 322, 352, 362). In some embodiments, a transceiver can be an integrated device (e.g., embodying the transmitter and receiver circuitry in a single device), in some embodiments, include separate transmitter and receiver circuitry, or in other embodiments, be embodied in other ways. The receiver and transceiver circuitry of a wired transmitter (e.g., network transceivers 380 and 390 in some embodiments) can be coupled to one or more wired network interface ports. Wireless transmitter circuitry (e.g., transmitters 314, 324, 354, 364) can include or be coupled to multiple antennas (e.g., antennas 316, 326, 356, 366), such as antenna arrays, that enable the corresponding device (e.g., UE 302, base station 304) to perform transmit "beamforming." Similarly, wireless receiver circuitry (e.g., receivers 312, 322, 352, 362) may include or be coupled to multiple antennas (e.g., antennas 316, 326, 356, 366), such as antenna arrays, that allow a corresponding device (e.g., UE 302, base station 304) to perform receive beamforming, as described herein. In one aspect, transmitter circuitry and receiver circuitry may share the same multiple antennas (e.g., antennas 316, 326, 356, 366), such that a corresponding device can only receive or transmit at a given time, rather than simultaneously. Wireless transceivers (e.g., WWAN transceivers 310 and 350, short-range wireless transceivers 320 and 360) may also include, for example, a network listening module (NLM) for performing various measurements.

[0093] As used herein, various wireless transceivers (e.g., in some embodiments, transceivers 310, 320, 350, and 360, and network transceivers 380 and 390) and wired transceivers (e.g., in some embodiments, network transceivers 380 and 390) may be generally characterized as a "transceiver," "at least one transceiver," or "one or more transceivers." Thus, whether a particular transceiver is a wired or wireless transceiver can be inferred from the type of communication being performed. For example, backhaul communications between network devices or servers will generally involve signaling via a wired transceiver, while wireless communications between a UE (e.g., UE 302) and a base station (e.g., base station 304) will generally involve signaling via a wireless transceiver.

[0094] UE 302, base station 304, and network entity 306 also include other components that can be used in conjunction with the operations disclosed herein. UE 302, base station 304, and network entity 306 each include one or more processors 332, 384, and 394 for providing functionality related to, for example, wireless communication, as well as for providing other processing functionality. Thus, processors 332, 384, and 394 can provide means for processing, such as means for determining, means for calculating, means for receiving, means for sending, means for indicating, and the like. In one aspect, processors 332, 384, and 394 can include, for example, one or more general-purpose processors, multi-core processors, central processing units, ASICs, digital signal processors, field programmable gate arrays, other programmable logic devices or processing circuitry, or various combinations thereof.

[0095] UE 302, base station 304, and network entity 306 include memory circuitry implementing memories 340, 386, and 396, respectively (e.g., each memory comprising a memory device), for maintaining information (e.g., information indicating reserved resources, thresholds, parameters, etc.). Thus, memories 340, 386, and 396 may provide means for storing, means for retrieving, means for maintaining, etc. In some cases, UE 302, base station 304, and network entity 306 may include positioning components 342, 388, and 398, respectively. Positioning components 342, 388, and 398 may be part of or hardware circuitry coupled to processors 332, 384, and 394, respectively, which, when executed, causes UE 302, base station 304, and network entity 306 to perform the functionality described herein. In other aspects, the positioning components 342, 388, and 398 can be external to the processors 332, 384, and 394 (e.g., part of a modem processing system, integrated with another processing system, etc.). Alternatively, the positioning components 342, 388, and 398 can be memory modules stored in the memories 340, 386, and 396, respectively, which, when executed by the processors 332, 384, and 394 (or a modem processing system, another processing system, etc.), cause the UE 302, the base station 304, and the network entity 306 to perform the functions described herein. Figure 3A Possible locations for a positioning component 342 are shown, which can be part of, for example, one or more WWAN transceivers 310, memory 340, one or more processors 332, or any combination thereof, or can be a standalone component. Figure 3B The diagram illustrates possible locations for a positioning component 388, which can be part of, for example, one or more WWAN transceivers 350, memory 386, one or more processors 384, or any combination thereof, or can be a standalone component. Figure 3CPossible locations for a location component 398 are shown, which can be, for example, part of one or more network transceivers 390, memory 396, one or more processors 394, or any combination thereof, or can be a standalone component.

[0096] The UE 302 may include one or more sensors 344 coupled to the one or more processors 332 to provide a means for sensing or detecting movement and / or orientation information independent of motion data derived from signals received by the one or more WWAN transceivers 310, the one or more short-range wireless transceivers 320, and / or the satellite signal receiver 330. For example, the sensors 344 may include an accelerometer (e.g., a microelectromechanical system (MEMS) device), a gyroscope, a geomagnetic sensor (e.g., a compass), an altimeter (e.g., a barometric altimeter), and / or any other type of motion detection sensor. Furthermore, the sensors 344 may include multiple different types of devices and combine their outputs to provide motion information. For example, the sensors 344 may use a combination of a multi-axis accelerometer and an orientation sensor to provide the ability to calculate position in a two-dimensional (2D) and / or three-dimensional (3D) coordinate system.

[0097] Additionally, the UE 302 includes a user interface 346 that provides means for providing indications to the user (e.g., auditory and / or visual indications) and / or for receiving user input (e.g., when the user actuates a sensing device such as a keypad, touch screen, microphone, etc.). Although not shown, the base station 304 and the network entity 306 may also include a user interface.

[0098] Referring in more detail to the one or more processors 384, in a downlink, IP packets from the network entity 306 may be provided to the processor 384. The one or more processors 384 may implement the functions of the RRC layer, the Packet Data Convergence Protocol (PDCP) layer, the Radio Link Control (RLC) layer, and the Medium Access Control (MAC) layer. The one or more processors 384 may provide RRC layer functionality associated with system information (e.g., Master Information Block (MIB), System Information Blocks (SIBs)), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-RAT mobility, and measurement configuration for UE measurement reporting; PDCP layer functionality associated with header compression / decompression, security (ciphering, deciphering, integrity protection, integrity verification), and handover support functions; RLC layer functionality associated with transmission of upper layer PDUs, error correction through automatic repeat request (ARQ), concatenation, segmentation and reassembly of RLC service data units (SDUs), re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, scheduling information reporting, error correction, priority handling, and logical channel prioritization.

[0099] Transmitter 354 and receiver 352 may implement Layer 1 (L1) 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) encoding / decoding of the transport channel, interleaving, rate matching, mapping onto the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. Transmitter 354 handles mapping to the 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), and M-quadrature amplitude modulation (M-QAM)). The coded and modulated symbols may then be split into parallel streams. Each stream may then be mapped to orthogonal frequency-division multiplexing (OFDM) subcarriers, multiplexed with reference signals (e.g., pilots) in the time and / or frequency domain, and then combined using an inverse fast Fourier transform (IFFT) to produce a physical channel carrying a time-domain OFDM symbol stream. The OFDM symbol stream is spatially precoded to generate multiple spatial streams. Channel estimates from a channel estimator can be used to determine the coding and modulation schemes, as well as for spatial processing. The channel estimates can be derived from a reference signal and / or channel condition feedback sent by the UE 302. Each spatial stream can then be provided to one or more different antennas 356. The transmitter 354 can modulate an RF carrier with the corresponding spatial stream for transmission.

[0100] At UE 302, receiver 312 receives the signal via its corresponding antenna 316. Receiver 312 recovers the information modulated onto the RF carrier and provides the information to one or more processors 332. Transmitter 314 and receiver 312 implement Layer 1 functionality associated with various signal processing functions. Receiver 312 can perform spatial processing on the information to recover any spatial streams destined for UE 302. If multiple spatial streams are destined for UE 302, receiver 312 can combine them into a single OFDM symbol stream. Receiver 312 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 includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols and reference signals on each subcarrier are recovered and demodulated by determining the most likely signal constellation point transmitted by base station 304. These soft decisions can be based on channel estimates calculated by a channel estimator. The soft decisions are then decoded and deinterleaved to recover the data and control signals originally transmitted by base station 304 on the physical channel. The data and control signals are then provided to one or more processors 332, which implement layer 3 (L3) and layer 2 (L2) functions.

[0101] In the downlink, one or more processors 332 provide demultiplexing between transport channels and logical channels, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets from the core network. One or more processors 332 are also responsible for error detection.

[0102] Similar to the functionality described in conjunction with downlink transmissions by the base station 304, the one or more processors 332 provide: RRC layer functionality associated with system information (e.g., MIB, SIB) acquisition, RRC connection, and measurement reporting; PDCP layer functionality associated with header compression / decompression and security (ciphering, deciphering, integrity protection, integrity verification); RLC layer functionality associated with transmission of upper layer PDUs, error correction through ARQ, concatenation, segmentation and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, MAC SDU to transport blocks (TBs) multiplexing, MAC SDU demultiplexing from TBs, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ), priority handling, and logical channel prioritization.

[0103] Channel estimates derived by a channel estimator from a reference signal or feedback sent by base station 304 may be used by transmitter 314 to select an appropriate coding and modulation scheme and facilitate spatial processing. The spatial streams generated by transmitter 314 may be provided to different antennas 316. Transmitter 314 may modulate an RF carrier with the corresponding spatial stream for transmission.

[0104] Uplink transmissions are processed at the base station 304 in a manner similar to that described with respect to the receiver functionality at the UE 302. The receiver 352 receives the signal through its respective antenna 356. The receiver 352 recovers the information modulated onto the RF carrier and provides the information to one or more processors 384.

[0105] In the uplink, one or more processors 384 provide demultiplexing between transport and logical channels, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets from UE 302. The IP packets from one or more processors 384 may be provided to the core network. One or more processors 384 are also responsible for error detection.

[0106] For convenience, UE 302, base station 304 and / or network entity 306 may be configured to: Figure 3A 、 3B and 3C are shown as including various components that can be configured according to the various examples described herein. However, it should be understood that the components illustrated can have different functions in different designs. In particular, Figures 3A to 3C Various components in are optional in alternative configurations, and various aspects include configurations that may vary due to design choice, cost, use of the device, or other considerations. For example, in Figure 3A In the case of , a specific embodiment of the UE 302 may omit the WWAN transceiver 310 (e.g., a wearable device or tablet or PC or laptop may have Wi-Fi and / or Bluetooth capabilities but no cellular capabilities), or may omit the short-range wireless transceiver 320 (e.g., only cellular, etc.), or may omit the satellite signal receiver 330, or may omit the sensor 344, etc. In another example, in Figure 3B In certain cases, particular implementations of the base station 304 may omit the WWAN transceiver 350 (e.g., a Wi-Fi "hotspot" access point without cellular capabilities), or may omit the short-range wireless transceiver 360 (e.g., cellular only, etc.), or may omit the satellite signal receiver 370, etc. For the sake of brevity, illustrations of various alternative configurations are not provided herein, but will be readily apparent to those skilled in the art.

[0107] The various components of the UE 302, base station 304, and network entity 306 may be communicatively coupled to one another via data buses 334, 382, ​​and 392, respectively. In one aspect, the data buses 334, 382, ​​and 392 may form or be part of communication interfaces for the UE 302, base station 304, and network entity 306, respectively. For example, where different logical entities are embodied in the same device (e.g., gNB and location server functionality incorporated into the same base station 304), the data buses 334, 382, ​​and 392 may provide communication therebetween.

[0108] Figure 3A 、 3B The components of 3C can be implemented in various ways. In some implementations, Figure 3A 、 3B The components of blocks 310 through 346 may be implemented in one or more circuits, such as one or more processors and / or one or more ASICs (which may include one or more processors). Each circuit may utilize and / or incorporate at least one memory component to store information or executable code used by the circuit to provide the functionality. For example, some or all of the functionality represented by blocks 310 through 346 may be implemented by the processor and memory components of UE 302 (e.g., by executing appropriate code and / or by appropriate configuration of the processor components). Similarly, some or all of the functionality represented by blocks 350 through 388 may be implemented by the processor and memory components of base station 304 (e.g., by executing appropriate code and / or by appropriate configuration of the processor components). Furthermore, some or all of the functionality represented by blocks 390 through 398 may be implemented by the processor and memory components of network entity 306 (e.g., by executing appropriate code and / or by appropriate configuration of the processor components). For simplicity, various operations, actions, and / or functions are described herein as being performed "by a UE," "by a base station," "by a network entity," and the like. However, as will be appreciated, such operations, actions and / or functions may actually be performed by a specific component or combination of components of the UE 302, base station 304, network entity 306, etc., such as processors 332, 384, 394, transceivers 310, 320, 350 and 360, memories 340, 386 and 396, positioning components 342, 388 and 398, etc.

[0109] In some designs, the network entity 306 may be implemented as a core network component. In other designs, the network entity 306 may be distinct from the network operator or operator of the cellular network infrastructure (e.g., NG RAN 220 and / or 5GC 210 / 260). For example, the network entity 306 may be a component of a dedicated network that may be configured to communicate with the UE 302 via the base station 304 or independently of the base station 304 (e.g., via a non-cellular communication link such as WiFi).

[0110] NR supports a variety of cellular network-based positioning technologies, including downlink-based positioning methods, uplink-based positioning methods, and downlink and uplink-based positioning methods. Downlink-based positioning methods include observed time difference of arrival (OTDOA) in LTE, downlink time difference of arrival (DL-TDOA) in NR, and downlink angle of departure (DL-AoD) in NR. Figure 4 The figure illustrates examples of various positioning methods according to various aspects of the present invention. In the OTDOA or DL-TDOA positioning procedure shown in scenario 410, the UE measures the difference between the arrival times (TOAs) of reference signals (e.g., positioning reference signals (PRS)) received from paired base stations, referred to as reference signal time difference (RSTD) or arrival time difference (TDOA) measurements, and reports them to a positioning entity. More specifically, the UE receives identifiers (IDs) of a reference base station (e.g., a serving base station) and multiple non-reference base stations in assistance data. The UE then measures the RSTD between the reference base station and each non-reference base station. Based on the known positions of the base stations involved and the RSTD measurements, a positioning entity (e.g., a UE for UE-based positioning or a location server for UE-assisted positioning) can estimate the UE's position.

[0111] For DL-AoD positioning, as illustrated by scenario 420, the positioning entity uses measurement reports of received signal strength measurements of multiple downlink transmit beams from the UE to determine the angle between the UE and the transmitting base station. The positioning entity can then estimate the UE's position based on the determined angle and the known location of the transmitting base station.

[0112] Uplink-based positioning methods include uplink time difference of arrival (UL-TDOA) and uplink angle of arrival (UL-AoA). UL-TDOA is similar to DL-TDOA, but is based on uplink reference signals (e.g., sounding reference signals (SRS)) transmitted by the UE to multiple base stations. Specifically, the UE sends one or more uplink reference signals measured by a reference base station and multiple non-reference base stations. Each base station then reports the time of receipt of the reference signal (called relative time of arrival (RTOA)) to a positioning entity (e.g., a location server) that knows the location and relative timing of the base stations involved. Based on the receive-to-receive (Rx-Rx) time difference between the reported RTOA of the reference base station and the reported RTOA of each non-reference base station, the known locations of the base stations, and their known timing offsets, the positioning entity can use TDOA to estimate the UE's position.

[0113] For UL-AoA positioning, one or more base stations measure the received signal strength of one or more uplink reference signals (e.g., SRS) received from the UE on one or more uplink receive beams. The positioning entity uses the signal strength measurements and the angle of the receive beams to determine the angle between the UE and the base station. Based on the determined angle and the known location of the base station, the positioning entity can then estimate the UE's position.

[0114] Downlink and uplink-based positioning methods include enhanced cell ID (E-CID) positioning and multiple round-trip time (RTT) positioning (also known as "multi-cell RTT" and "multi-RTT"). In the RTT procedure, a first entity (e.g., a base station or UE) transmits a first RTT-related signal (e.g., a PRS or SRS) to a second entity (e.g., a UE or base station), which then transmits a second RTT-related signal (e.g., an SRS or PRS) back to the first entity. Each entity measures the time difference between the time of arrival (ToA) of the received RTT-related signal and the transmission time of the transmitted RTT-related signal. This time difference is referred to as the received-to-transmit (Rx-Tx) time difference. The Rx-Tx time difference measurement can be performed or adjusted to include only the time difference between the nearest slot boundary of the received and transmitted signals. The two entities may then send their Rx-Tx time difference measurements to a location server (e.g., LMF 270), which calculates the round-trip propagation time (i.e., RTT) between the two entities from the two Rx-Tx time difference measurements (e.g., as the sum of the two Rx-Tx time difference measurements). Alternatively, one entity may send its Rx-Tx time difference measurement to the other entity, which then calculates the RTT. The distance between the two entities can be determined from the RTT and a known signal speed (e.g., the speed of light). For multi-RTT positioning, as illustrated in scenario 430, a first entity (e.g., a UE or base station) performs an RTT positioning procedure with multiple second entities (e.g., multiple base stations or UEs) to determine the first entity's position based on the distance to the second entities and the known positions of the second entities (e.g., using multilateration). RTT and multi-RTT methods can be combined with other positioning techniques (such as UL-AoA and DL-AoD) to improve position accuracy, as illustrated in scenario 440.

[0115] The E-CID positioning method is based on radio resource management (RRM) measurements. In E-CID, the UE reports the serving cell ID, timing advance (TA), and the identifiers, estimated timing, and signal strength of detected neighboring base stations. The UE's position is then estimated based on this information and the known locations of the base stations.

[0116] To assist in positioning operations, a location server (e.g., location server 230, LMF 270, SLP 272) may provide assistance data to the UE. For example, the assistance data may include the identifier of the base station (or cell / TRP of the base station) from which the reference signal is measured, reference signal configuration parameters (e.g., the number of consecutive time slots containing PRS, the periodicity of consecutive time slots containing PRS, muting sequence, frequency hopping sequence, reference signal identifier, reference signal bandwidth, etc.), and / or other parameters applicable to a particular positioning method. Alternatively, the assistance data may originate directly from the base station itself (e.g., in a periodically broadcast overhead message, etc.). In some cases, the UE may be able to detect neighboring network nodes itself without the use of assistance data.

[0117] In the case of OTDOA or DL-TDOA positioning procedures, the assistance data may also include an expected RSTD value and an associated uncertainty or search window around the expected RSTD. In some cases, the expected RSTD value range may be + / - 500 microseconds (μs). In some cases, when any resource used for positioning measurements is in FR1, the expected RSTD uncertainty value range may be + / - 32 μs. In other cases, when all resources used for positioning measurements are in FR2, the expected RSTD uncertainty value range may be + / - 8 μs.

[0118] A location estimate may be referred to by other names, such as location estimate, location, position fix, location fix, fix, etc. A location estimate may be geo-metric and include coordinates (e.g., latitude, longitude, and possibly altitude), or may be urban and include a street address, postal address, or some other verbal description of the location. A location estimate may also be defined relative to some other known location, or in absolute terms (e.g., using latitude, longitude, and possibly altitude). A location estimate may include expected error or uncertainty (e.g., by including an area or volume within which the location is expected to be located with some specified or default confidence level).

[0119] In LTE, and at least in some cases in NR, positioning measurements are reported through higher layer signaling, specifically the LTE Positioning Protocol (LPP) and / or RRC. LPP is used point-to-point between a location server (e.g., location server 230, LMF 270, SLP 272) and a UE (e.g., any of the UEs described herein) to position the UE using position-related measurements obtained from one or more reference sources. Figure 5 is a diagram 500 illustrating an example LPP reference source for positioning. Figure 5In the example of FIG, a target device (specifically, UE 504 (eg, any of the UEs described herein)) participates in an LPP session with a location server 530 (in Figure 5 5. The UE 504 also receives / measures data from a first reference source (specifically, one or more base stations 502 (which may correspond to any of the base stations described herein and which are Figure 5 ) and a second reference source (specifically, one or more Satellite Positioning System (SPS) satellites 520 (which may correspond to Figure 1 Wireless positioning signal of SV 112)).

[0120] An LPP session is used between location server 530 and UE 504 to obtain location-related measurements or a position estimate or to transmit assistance data. A single LPP session is used to support a single positioning request (e.g., for a single mobile-terminated positioning request (MT-LR), mobile-originated positioning request (MO-LR), or network-initiated positioning request (NI-LR)). Multiple LPP sessions can be used between the same endpoints to support multiple different positioning requests. Each LPP session includes one or more LPP transactions, each of which performs a single operation (e.g., capability exchange, assistance data transfer, location information transfer). LPP transactions are referred to as LPP procedures. The initiator of an LPP session initiates the first LPP transaction, but subsequent transactions can be initiated by either endpoint. LPP transactions within a session can occur serially or in parallel. LPP transactions are indicated at the LPP protocol level using transaction identifiers to associate messages (e.g., request and response). Messages within a transaction are linked by a common transaction identifier.

[0121] LPP signaling can be used to request and report measurements related to the following positioning methods: observed time difference of arrival (OTDOA), downlink time difference of arrival (DL-TDOA), assisted global navigation satellite system (A-GNSS), LTE enhanced cell identity (E-CID), NR E-CID, sensors, terrestrial beacon system (TBS), WLAN, Bluetooth, downlink angle of departure (DL-AoD), uplink angle of arrival (UL-AoA), and multiple round trip times (RTT). Currently, LPP measurement reports can contain the following measurement results: (1) one or more time of arrival (ToA), time difference of arrival (TDOA), reference signal time difference (RSTD), or received-transmitted (Rx-Tx) measurement results, (2) one or more AoA and / or AoD measurement results (currently only for base stations to report UL-AoA and DL-AoD to the location server 530), (3) one or more multipath measurement results (ToA per path, reference signal received power (RSRP), AoA / AoD), (4) one or more motion states (e.g., walking, driving, etc.). and traces (currently only for UE 504), and (5) one or more report quality indicators. In the present invention, regardless of the positioning technology, positioning measurements (such as the example measurements just listed) can be collectively referred to as positioning state information (PSI).

[0122] UE 504 and / or location server 530 may obtain the following information from one or more reference sources (in Figure 5 The example illustrates deriving position information for SPS satellites 520 and base station 502. Each reference source can be used to calculate an independent estimate of the position of UE 504 using an associated positioning technique. Figure 5 In the example of FIG5 , UE 504 measures characteristics (e.g., ToA, RSRP, RSTD, etc.) of positioning signals received from base station 502 to calculate or assist location server 530 in calculating an estimate of the position of UE 504 using one or more cellular network-based positioning methods (e.g., multi-RTT, OTDOA, DL-TDOA, DL-AoD, E-CID, etc.). Similarly, UE 504 is measuring characteristics (e.g., ToA) of global navigation satellite system (GNSS) signals received from SPS satellites 520 to triangulate its position in two or three dimensions, depending on the number of SPS satellites 520 measured. In some cases, UE 504 or location server 530 may combine the position solutions derived from each of the different positioning technologies to improve the accuracy of the final position estimate.

[0123] As described above, UE 504 uses LPP to report location-related measurements obtained from various reference sources (e.g., base station 502, Bluetooth beacons, SPS satellites 520, WLAN access points, motion sensors, etc.). For example, for GNSS-based positioning, UE 504 uses the LPP information element (IE) "A-GNSS-ProvideLocationInformation" to provide location measurements (e.g., pseudoranges, position estimates, velocity, etc.) along with time information to location server 530. This LPP information element can also be used to provide error reasons specific to GNSS positioning. The "A-GNSS-ProvideLocationInformation" IE includes IEs such as "GNSS-SignalMeasurementInformation," "GNSS-LocationInformation," "GNSS-MeasurementList," and "GNSS-Error." When UE 504 provides location and optional velocity information derived using GNSS or hybrid GNSS and other measurements to location server 530, UE 504 includes the "GNSS-LocationInformation" IE. The UE 504 uses the "GNSS-SignalMeasurementInformation" IE to provide GNSS signal measurement information to the location server 530 and, if requested by the location server 530, use the GNSS network time association. This information includes measurements of code phase, Doppler, C / No, and optionally accumulated carrier phase (also known as accumulated delta range (ADR)), which implements the UE-assisted GNSS method in which position is calculated in the location server 530. The UE 504 uses the "GNSS-MeasurementList" IE to provide measurements of code phase, Doppler, C / No, and optionally accumulated carrier phase (or ADR).

[0124] As another example, for motion sensor-based positioning, currently supported positioning methods use air pressure sensors and motion sensors. The UE 504 uses the LPP IE "Sensor-ProvideLocationInformation" to provide location information for sensor-based methods to the location server 530. This can also be used to provide sensor-specific error causes. The UE 504 uses the "Sensor-MeasurementInformation" IE to provide sensor measurements (e.g., air pressure readings) to the location server 530. The UE 504 uses the "Sensor-MotionInformation" IE to provide motion information to the location server 530. Motion information can include an ordered series of points. This information can be obtained by the UE 504 using one or more motion sensors (e.g., accelerometer, barometer, magnetometer, etc.).

[0125] As yet another example, for Bluetooth-based positioning, the UE 504 uses the "BT-ProvideLocationInformation" IE to provide measurement results of one or more Bluetooth beacons to the location server 530. This IE can also be used to provide Bluetooth positioning specific error reasons.

[0126] Figure 6 The diagram illustrates an example location service procedure 600 according to aspects of the present disclosure. The location service procedure 600 may be performed by the UE 204, an NG-RAN node 602 in the NG-RAN 220 (e.g., a gNB 222, a gNB-CU 226, an ng-eNB 224, or other node in the NG-RAN 220), the AMF 264, the LMF 270, and a 5GC location service (LCS) entity 680 (e.g., any third-party application requesting the location of the UE 204, a public service access point (PSAP), an E-911 server, etc.).

[0127] The location service request for obtaining the location of the target (ie, UE 204) may be initiated by the 5GC LCS entity 680, the AMF 264 serving the UE 204, or the UE 204 itself. Figure 6 These options are illustrated as stages 610a, 610b, and 610c, respectively. Specifically, at stage 610a, the 5GC LCS entity 680 sends a location service request to the AMF 264. Alternatively, at stage 610b, the AMF 264 itself generates the location service request. Alternatively, at stage 610c, the UE 204 sends the location service request to the AMF 264.

[0128] Once the AMF 264 has received (or generated) the location service request, it forwards the location service request to the LMF 270 at stage 620. The LMF 270 then performs NG-RAN positioning procedures with the NG-RAN node 602 at stage 630a and UE positioning procedures with the UE 204 at stage 630b. The specific NG-RAN positioning procedures and UE positioning procedures may depend on the type of positioning method used to locate the UE 204, which may depend on the capabilities of the UE 204. The positioning method may be downlink-based (e.g., LTE-OTDOA, DL-TDOA, DL-AoD, etc.), uplink-based (e.g., UL-TDOA, UL-AoA, etc.), and / or downlink and uplink-based (e.g., LTE / NR E-CID, multi-RTT, etc.). The NG-RAN positioning procedures and the UE positioning procedures may utilize LPP signaling between the UE 204 and the LMF 270 and LPP Type A (LPPa) or New Radio Positioning Protocol Type A (NRPPa) signaling between the NG-RAN node 602 and the LMF 270 .

[0129] A prerequisite for stage 630 is that the LCS Correlation Identifier (ID) and AMF ID have been passed to LMF 270 by the serving AMF 264. Both the LCS Correlation ID and the AMF ID can be represented as strings selected by the AMF 264. At stage 620, the LCS Correlation ID and the AMF ID are provided by the AMF 264 to the LMF 270 in the Location Service Request. When the LMF 270 then initiates stage 630, it also includes the LCS Correlation ID for this location session and the AMF ID, which indicates the AMF instance serving UE 204. The LCS Correlation ID is used to ensure that during the positioning session between the LMF 270 and the UE 204, the Positioning Response message from the UE 204 is returned by the AMF 264 to the correct LMF 270 and carries an identity (LCS Correlation ID) that can be recognized by the LMF 270.

[0130] Note that the LCS Correlation ID serves as a location session identifier, which may be used to identify messages exchanged between the AMF 264 and the LMF 270 for a specific location session of the UE 204. As mentioned above and shown in stage 620, the location session between the AMF 264 and the LMF 270 of a specific UE 204 is initiated by the AMF 264, and the LCS Correlation ID may be used to identify this location session (e.g., may be used by the AMF 264 to identify state information of this location session, etc.).

[0131] As part of the NG-RAN node positioning procedure (stage 630a) and the UE positioning procedure (stage 630b), the LMF 270 may provide LPP assistance data for the selected positioning method in the form of downlink positioning reference signal (DL-PRS) configuration information to the NG-RAN node 602 and the UE 204. Alternatively or additionally, the NG-RAN node 602 may provide the DL-PRS and / or uplink PRS (UL-PRS) configuration information for the selected positioning method to the UE 204. Note that while Figure 6 A single NG-RAN node 602 is shown, but multiple NG-RAN nodes 602 may be involved in a positioning session.

[0132] Once configured with the DL-PRS and / or UL-PRS configuration, the NG-RAN node 602 and the UE 204 transmit and receive / measure the corresponding PRS at the scheduled time. The NG-RAN node 602 and the UE 204 then send their respective measurement results to the LMF 270. In some cases, the NG-RAN node 602 may send its measurement results to the UE 204, which may forward them to the LMF 270 using LPP signaling. Alternatively, the NG-RAN node 602 may send its measurement results directly to the LMF 270 in LPPa or NRPPa signaling. In some cases, the UE 204 may send its measurement results to the NG-RAN node 602 in RRC, uplink control information (UCI), or MAC control element (MAC-CE) signaling, and the NG-RAN node 602 may forward the measurement results to the LMF 270 using LPPa or NRPPa signaling. Alternatively, the UE 204 may send its measurement results directly to the LMF 270 using LPP signaling.

[0133] Once the LMF 270 obtains measurement results from the UE 204 and / or the NG-RAN node 602 (depending on the type of positioning method), it uses these measurement results to calculate an estimate of the location of the UE 204. Next, at stage 640, the LMF 270 sends a location services response containing the location estimate of the UE 204 to the AMF 264. The AMF 264 then forwards the location services response to the entity that generated the location services request at stage 650. Specifically, if a location services request was received from the 5GC LCS entity 680 at stage 610a, then at stage 650a, the AMF 264 sends a location services response to the 5GC LCS entity 680. However, if a location services request was received from the UE 204 at stage 610c, then at stage 650c, the AMF 264 sends a location services response to the UE 204. Alternatively, if the AMF 264 generates a location services request at stage 610b, then at stage 650b, the AMF 264 stores / uses the location services response itself.

[0134] Note that while location service procedure 600 has been described above as a UE-assisted location service procedure, it can alternatively be a UE-based location service procedure. A UE-assisted location service procedure is one in which the LMF 270 calculates the location of the UE 204, while a UE-based location service procedure is one in which the UE 204 calculates its own location. In the case of a UE-based location service procedure, stages 610c and 650c will be performed. The LMF 270 may still coordinate the transmission / measurement of the DL-PRS (and possibly the UL-PRS), but the measurement results will be forwarded to the UE 204 rather than the LMF 270. Thus, the location service response at stages 640 and 650c may be measurements from the involved NG-RAN node 602 rather than a position estimate for the UE 204. Alternatively, where the involved NG-RAN nodes 602 forward their respective measurement results directly to the UE 204 (e.g. via RRC signaling), the location service response at stage 640 may simply be an acknowledgement of the completion of the NG-RAN node and UE positioning procedure at stage 630.

[0135] As mentioned above, a single LPP session is used to support a single positioning request, while multiple LPP sessions can be used between the same endpoints to support multiple different positioning requests. Each LPP session consists of one or more LPP transactions (or procedures), where each LPP transaction performs a single operation (capability exchange, assistance data transfer, or location information transfer). Each LPP transaction involves the exchange of one or more LPP messages between the location server and the target device. The general format of an LPP message consists of a set of common fields followed by a body. The body (which can be empty) contains information specific to a particular message type. Each message type contains information specific to one or more positioning methods and / or information common to all positioning methods.

[0136] An LPP session typically includes at least a capability transfer or indication procedure, an assistance data transfer or delivery procedure, and a location information transfer or delivery procedure. Figure 7 Illustrated are example LPP capability transfer procedures 710, LPP assistance data transfer procedures 730, and LPP location information transfer procedures 750 between a target device (labeled "Target") and a location server (labeled "Server") according to aspects of the present disclosure.

[0137] The purpose of the LPP Capabilities Transfer procedure 710 is to facilitate the transfer of capabilities from a target device (e.g., UE 204) to a location server (e.g., LMF 270). Capabilities, in this context, refer to positioning and protocol capabilities related to LPP and the positioning methods supported by LPP. In the LPP Capabilities Transfer procedure 710, the location server (e.g., LMF 270) indicates the types of capabilities required by the target device (e.g., UE 204) in an LPP Request Capabilities message. The target device responds with an LPP Offer Capabilities message. The capabilities included in the LPP Offer Capabilities message should correspond to any capability types specified in the LPP Request Capabilities message. Specifically, for each positioning method for which a capability request was included in the LPP Request Capabilities message, if the target device supports that positioning method, the target device includes the target device's capabilities for that supported positioning method in the LPP Offer Capabilities message. For the LPP Capabilities Indication procedure, the target device provides capabilities to the location server unsolicited (i.e., without receiving an LPP Request Capabilities message) in an LPP Offer Capabilities message.

[0138] The purpose of the LPP Assistance Data Transfer procedure 730 is to enable a target device to request assistance data from a location server to assist in positioning, and to enable the location server to transmit assistance data to the target device without a request. In the LPP Assistance Data Transfer procedure 730, the target device sends an LPP Request Assistance Data message to the location server. The location server responds to the target device with an LPP Provide Assistance Data message containing assistance data. The assistance data transmitted should match the assistance data requested in the LPP Request Assistance Data or be a subset of the assistance data requested in the LPP Request Assistance Data. The location server may also provide any unsolicited information it deems useful to the target device. The location server may also send one or more additional LPP Provide Assistance Data messages containing additional assistance data to the target device. With the LPP Assistance Data Transfer procedure, the location server provides unsolicited assistance data required for positioning. This assistance data may be provided periodically or aperiodically.

[0139] The purpose of the LPP Location Information Transfer procedure 750 is to enable a location server to request location measurement data and / or a position estimate from a target device, and to enable a target device to transmit location measurement data and / or a position estimate to a location server without a request. In the LPP Location Information Transfer procedure 750, the location server sends an LPP Request Location Information message to the target device to request location information, indicating the type of location information requested and potentially associated QoS. The target device responds to the location server with an LPP Offer Location Information message to transmit the location information. The transmitted location information should match or be a subset of the location information requested by the LPP Request Location Information message, unless the location server explicitly allows additional location information. More specifically, if the requested information is compatible with the capabilities and configuration of the target device, the target device includes the requested information in the LPP Offer Location Information message. Otherwise, if the target device does not support one or more of the requested positioning methods, the target device continues to process the message as if it contained only information for supported positioning methods and handles the signaling content of the unsupported positioning methods through LPP error detection. If requested by the LPP Request Location Information message, the target device sends an additional LPP Provide Location Information message to the location server to convey the additional location information.The LPP Location Information Delivery procedure supports the delivery of positioning estimates based on an unsolicited service.

[0140] LPP also defines procedures for error indication when a receiving endpoint (target device or location server) receives erroneous or unexpected data or detects that some data is missing. Specifically, when a receiving endpoint determines that a received LPP message contains errors, it may return an error message indicating one or more errors to the sending endpoint and discard the received / erroneous message. If the receiving endpoint is able to determine that the erroneous LPP message is an LPP error or abort message, the receiving endpoint discards the received message without returning an error message to the sending endpoint.

[0141] LPP also defines procedures related to abort indications, allowing a target device or location server to abort an ongoing procedure due to an unexpected event (e.g., an LCS client canceling a location request). The abort procedure can also be used to stop an ongoing procedure (e.g., periodic location reports from a target device). In the abort procedure, the first endpoint determines that procedure P must be aborted and sends an abort message to the second endpoint, carrying the transaction ID of procedure P. The second endpoint then aborts procedure P.

[0142] Artificial intelligence (AI) and machine learning (ML) technologies have been introduced for positioning purposes. Machine learning can be used to generate models that can be used to facilitate various aspects associated with data processing. Regarding positioning, machine learning can be used to generate measurement models for processing reference signals (e.g., PRS) used for positioning, such as feature extraction and reporting of reference signal measurement results (e.g., selecting which extracted features to report). In some cases, AI / ML positioning techniques can be applied at the RAN (e.g., near-real-time RIC 259), meaning the RAN can train the AI / ML model and provide the resulting inference model. This inference model can then be deployed within the RAN, for example, using near-real-time RIC. In other cases, AI / ML positioning techniques can be applied at the network (e.g., LMF 270), meaning the network trains the AI / ML model and provides the resulting inference model. This inference model can then be deployed at the LMF.

[0143] There are different scenarios where UE positioning using AI / ML positioning techniques at the RAN can increase the accuracy of deterministic positioning algorithms. As a first example scenario, optimization of the PRS pattern (including muting mode) can be applied at the RIC (e.g., near real-time RIC 259) taking into account the power saving mode of the O-RU involved (e.g., O-RU 287). As another example scenario, the RAN can use AI / ML positioning techniques to select a UE positioning method based on the current positioning scenario (e.g., line of sight (LOS), whether power saving is enabled, reference signal overhead, etc.).

[0144] Figure 8is a diagram 800 illustrating a third example scenario for locating a UE 204 using AI / ML positioning techniques according to aspects of the present disclosure. Figure 2C Described Figure 8 The various network components / entities are shown in FIG. In this example scenario, for UE 204 on a train, the track can be learned (or assumed to be known by the network), meaning that one dimension of UE positioning is known (the track geometry). In this case, AI / ML techniques implemented in the RAN can provide the LMF (e.g., LMF 270) with a prediction of the UE 204's position.

[0145] In the aforementioned example, the RAN has access to the information required by the AI / ML model. For example, the RAN can access the energy-saving mode of the involved O-RUs (e.g., RUs 287), the UE's Loss of Service (LOS) condition, whether energy-saving is enabled, reference signal overhead, and the train's track geometry. This allows the RAN to be better positioned to apply AI / ML positioning techniques. It would be beneficial for the RAN to provide the output of the AI / ML model to the location server when it calculates the UE's position. However, to do so, the RAN exposes RAN data analytics (e.g., the predicted UE location) to the core network (e.g., LMF 270). Therefore, this analytics information should be exposed in a secure manner.

[0146] The RAN can support multiple vertical use cases, such as positioning, extended reality (XR), NTN, and IoT. On one hand, the near-real-time RIC (deployed as part of the RAN) can generate analytics related to UE mobility, RAN congestion, and UE positioning (including prediction). On the other hand, the 5G core (e.g., 5GC 260) can generate analytics related to the 5G core, such as 5G core congestion, UE location, and PRS patterns. Therefore, RAN analytics will benefit the 5G core.

[0147] Figure 9 FIG900 is a diagram of an example O-RAN architecture according to aspects of the present disclosure. Figure 2C Described Figure 9 Various network components / entities are shown in FIG. Figure 9 As shown, an interface is defined between the near real-time RIC 259 and any 5G external application consumer (referred to as a Y1 consumer 910). It is assumed that the Y1 consumer 910 is in the O-RAN trusted domain. In other words, it is assumed that the Y1 consumer is in the same O-RAN or the same public land mobile network (PLMN) as the near real-time RIC 259 (i.e., belongs to the same network operator).

[0148] As described above, AI / ML positioning techniques can benefit from exposing near-real-time RIC data analytics to / from the LMF in the 5G core. However, there is currently no interface between the near-real-time RIC and the LMF, as there is with the Y1 consumer 910. Therefore, the present disclosure proposes extending the Y1 interface in a secure manner to support signaling between the near-real-time RIC in the RAN and the LMF in the 5G core. In this way, the near-real-time RIC treats the LMF as a new Y1 consumer in the 5G core (within the same PLMN), which will allow the LMF to subscribe to the near-real-time RIC to request RAN analytics data. This allows the LMF to retrieve and benefit from RAN analytics for positioning purposes. The Y1 interface between the near-real-time RIC 259 and the LMF 270 may be referred to herein as a "modified Y1" interface.

[0149] Figure 10 FIG. 1000 is a diagram of an example network architecture in which a modified Y1 interface is implemented according to aspects of the present disclosure. Figures 2A-2C Described Figure 10 Various network components / entities are shown in FIG. Figure 10 As shown, the modified Y1 interface allows communication from LMF 270 to near real-time RIC 259 and from near real-time RIC 259 to LMF 270. For example, LMF 270 can subscribe to near real-time RIC 259 and request data from or send data to near real-time RIC 259. For security and privacy reasons, the data sent / received should not include a UE identifier (e.g., International Mobile Equipment Identity (IMEI)). Near real-time RIC 259 can respond to the request via the modified Y1 interface.

[0150] Now refer to Figure 10 The positioning procedure between the LMF 270 and the UE 204 and involving the near real-time RIC 259 is described. At stage 1, the LMF 270 establishes a UE positioning session (or LPP session) with the UE 204, as in e.g. Figure 6 During phase 630b of the LPP session, LMF 270 controls the provision of any information about UE 204 to near real-time RIC 259. As a first option (referred to as "Alternative 1"), LMF 270 controls the provision of any information about UE 204 to near real-time RIC 259. That is, while messages between LMF 270 and UE 204 may pass through near real-time RIC 259, near real-time RIC 259 cannot decode them. Instead, LMF 270 sends any information about the UE / LPP session to near real-time RIC 259 as needed.

[0151] As a second option (referred to as "Alternative 2"), a UE session (or LPP session) is established between the UE 204 and the near real-time RIC 259, and between the near real-time RIC 259 and the LMF 270. In other words, the UE / LPP session is extended to pass through the near real-time RIC 259. In this way, the near real-time RIC 259 can decode messages (e.g., LPP messages) exchanged between the LMF 270 and the UE 204.

[0152] During session establishment for Alternatives 1 and 2, LMF 270 sends the identifier of the UE session (or LPP session) to near real-time RIC 259. The LPP session ID between LMF 270 and target UE 204 can be used to define the UE session ID on the modified Y1 interface. If necessary, near real-time RIC 259 can associate the UE / LPP session ID with a RAN UE identifier (i.e., a UE identifier used within the RAN domain and not exposed outside the RAN domain).

[0153] At stage 2, UE 204 reports positioning measurements to gNB 222 (e.g., as in the E-CID positioning procedure). These measurements are sent to LMF 270 via NRPPa. Alternatively, UE 204 may report the measurements to LMF 270 via LPP (e.g., in the LPP location information transfer procedure 750).

[0154] In Phase 3, the LMF 270 sends the reported UE measurement results to the near-real-time RIC 259 via a modified Y1 interface. Currently, the positioning capabilities of the UE 204 (e.g., whether DL-TDOA, DL-AOD, etc. are supported) are shared with the LMF 270 via an LPP session (e.g., via the LPP capability transfer procedure 710), but are not available to the RAN. Using the Y1 interface, the positioning capabilities of the UE 204 can be shared with the near-real-time RIC 259.

[0155] In stage 4, the near real-time RIC 259 may apply AI / ML techniques to the UE positioning measurements and expose the data analysis to the LMF 270 via the Y1 interface. For example, the AI / ML techniques may be used to predict the trajectory of the UE 204 and / or determine the appropriate inference model, PRS pattern, PRS muting pattern, positioning method, etc.

[0156] More specifically, the near real-time RIC 259 may provide the following information to assist the LMF 270 in determining the location of the UE 204. First, the near real-time RIC 259 may determine a positioning method to use (if more than one is available) based on the UE capabilities (e.g., obtained from the LMF 270 based on the LPP capability transfer procedure 710), the requested positioning accuracy, the response time, and / or the environmental scenario (e.g., a scenario with a higher probability of LOS than non-line-of-sight (NLOS) with respect to the O-RU 287 available for the positioning procedure, the type of network nodes deployed in the vicinity of the UE (e.g., positioning reference units (PRUs), access points, O-RUs, etc.), etc.).

[0157] Second, the near real-time RIC 259 may have access to information about the energy savings, component carriers, and / or cells of the O-RU 287 and may utilize this information to select an appropriate positioning method, an appropriate pattern for reference signals (e.g., DL-PRS, SL-PRS, SRS) to transmit and measure, and / or an appropriate PRU (a PRU is a UE or other mobile device whose location is known and may be used as a reference device / location for network calibration).

[0158] Third, the near real-time RIC 259 can optimize the reference signal pattern for joint selection with the selected positioning method. The near real-time RIC 259 can transmit the optimized reference signal pattern to the LMF 270 and / or directly to the gNB 222. For DL-PRS, the LMF 270 can provide the reference signal pattern to the UE 204 via the LPP assistance data transmission procedure 730. For SL-PRS or SRS, the gNB 222 can provide the reference signal pattern to the UE 204 via RRC.

[0159] Fourth, the near real-time RIC 259 may predict an estimated trajectory of the UE 204. For example, the topology of the train track may be known at the near real-time RIC 259 (e.g., Figure 8 ), only the topology of the base station sites is known at LMF 270. Near real-time RIC 259 can use this topology information to predict an estimated trajectory for UE 204. Near real-time RIC 259 can send the estimated trajectory to LMF 270 over a modified Y1 interface. Near real-time RIC 259 can encode the trajectory using LPP, for example, in a "Sensor-MotionInformation" IE.

[0160] Figure 11 An example communication method 1100 is illustrated in accordance with aspects of the present disclosure. In one aspect, the method 1100 may be performed by a location server (eg, LMF 270).

[0161] At 1110, the location server sends a request for RAN data analysis associated with a positioning session (e.g., location service procedure 600, LPP session, etc.) between the location server and a UE (e.g., UE 204) to a RAN controller entity (e.g., near real-time RIC 259), the request including at least an identifier of the positioning session. In an aspect, operation 1110 may be performed by one or more network transceivers 390, one or more processors 394, memory 396, and / or positioning component 398, any or all of which may be considered means for performing such operation.

[0162] At 1120, the location server receives a response to the request for RAN data analysis from the RAN controller entity, the response including the RAN data analysis. In an aspect, operation 1120 may be performed by one or more network transceivers 390, one or more processors 394, memory 396, and / or positioning component 398, any or all of which may be considered means for performing such operation.

[0163] At 1130, the location server performs a positioning procedure (e.g., an LPP procedure for a particular positioning method (such as multi-RTT, DL-TDOA, etc.), such as an LPP location information transmission procedure) with the UE based at least in part on the RAN data analysis to determine the location of the UE. In an aspect, operation 1130 may be performed by one or more network transceivers 390, one or more processors 394, memory 396, and / or positioning component 398, any or all of which may be considered means for performing such operation.

[0164] Figure 12 An example communication method 1200 is illustrated in accordance with aspects of the present disclosure. In one aspect, the method 1200 may be performed by a RAN controller entity (eg, near real-time RIC 259).

[0165] At 1210, the RAN controller entity receives a request from a location server (e.g., LMF 270) to analyze RAN data associated with a positioning session between the location server and a UE (e.g., UE 204) to determine a location of the UE, the request including at least an identifier of the positioning session. In an aspect, operation 1210 may be performed by one or more network transceivers 380, one or more processors 384, memory 386, and / or positioning component 388, any or all of which may be considered means for performing such operation.

[0166] At 1220, the RAN controller entity sends a response to the request for RAN data analysis to the location server, the response including the RAN data analysis. In an aspect, operation 1220 may be performed by one or more network transceivers 380, one or more processors 384, memory 386, and / or positioning component 388, any or all of which may be considered means for performing such operation.

[0167] As will be appreciated, a technical advantage of methods 1100 and 1200 is providing data exposure from the RAN (eg, a RAN controller entity) to the core network (eg, a location server) and from the core network to the RAN.

[0168] In the above detailed description, it can be seen that different features are grouped together in the examples. This disclosure should not be interpreted as an intention that the exemplary clauses have more features than those explicitly mentioned in each clause. On the contrary, various aspects of the present disclosure may include fewer than all the features of the various example clauses disclosed. Therefore, the following clauses should be considered to be incorporated into the specification, where each clause itself can serve as a separate example. Although each dependent clause may refer to a specific combination with one of the other clauses in the clause, the aspects of the dependent clause are not limited to that specific combination. It should be understood that other example clauses may also include combinations of dependent clause aspects with the subject matter of any other dependent clause or independent clause, or combinations of any features with other dependent and independent clauses. Various aspects disclosed herein explicitly include these combinations, unless an unintended specific combination is explicitly expressed or can be easily inferred (for example, contradictory aspects, such as defining an element as both an electrical insulator and an electrical conductor). In addition, it is also intended that various aspects of a clause may be included in any other independent clause, even if the clause is not directly dependent on the independent clause.

[0169] Examples of implementation are described in the following numbered clauses:

[0170] Clause 1. A method of communication performed by a location server, comprising: establishing a positioning session with a user equipment (UE) to determine a location of the UE; sending a request for a radio access network (RAN) data analysis associated with the positioning session of the UE to a RAN controller entity, the request including at least an identifier of the positioning session; receiving a response to the request for the RAN data analysis from a RAN controller entity, the response including the RAN data analysis; and performing a positioning procedure with the UE to determine the location of the UE based at least in part on the RAN data analysis.

[0171] Clause 2. The method of clause 1, wherein: the request for RAN data analysis is sent via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is received via the Y1 interface.

[0172] Clause 3. A method as described in any of clauses 1 to 2, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0173] Clause 4. The method of any of clauses 1 to 3, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0174] Clause 5. The method of any of clauses 1 to 4, wherein the identifier of the positioning session comprises an LPP session identifier.

[0175] Clause 6. A method according to any one of clauses 1 to 5, wherein the RAN data analysis includes: a positioning method used for a positioning procedure, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during a positioning procedure, a muting pattern for one or more PRS resources, an identification of one or more positioning reference units (PRUs) that may be used for the positioning procedure, a trajectory of the UE, an inference model used to determine the position of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0176] Clause 7. A method according to clause 6, wherein the positioning method to be used for the positioning procedure is determined based on the following: the positioning capability of the UE, the accuracy of the requested UE position, the response time to the positioning procedure, the environmental scenario of the UE, or any combination thereof.

[0177] Clause 8. The method of clause 7, wherein the environmental context is based on a probability that the UE is in a line-of-sight (LOS) scenario or a non-line-of-sight (NLOS) scenario relative to one or more radio units (RUs) available for positioning procedures.

[0178] Clause 9. The method of any of clauses 7 to 8, further comprising: receiving positioning capabilities of the UE from the UE; and sending the positioning capabilities of the UE to the RAN controller entity.

[0179] Clause 10. A method as described in any of clauses 6 to 9, wherein the trajectory of the UE is based on a known topology of the route the UE is traveling.

[0180] Clause 11. The method of clause 10, wherein the route comprises train tracks.

[0181] Clause 12. A method as described in any of clauses 6 to 11, further comprising: receiving positioning measurement results of one or more PRS resources from the UE via LPP signaling; or receiving positioning measurement results of one or more PRS resources from a RAN controller entity via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0182] Clause 13. The method of clause 12, wherein the request for RAN data analysis further comprises positioning measurements for one or more PRS resources.

[0183] Clause 14. The method of any of clauses 6 to 13, wherein the one or more PRS resources comprise: one or more downlink PRS resources, one or more uplink PRS resources, one or more sidelink PRS resources, or any combination thereof.

[0184] Clause 15. A method as described in any of clauses 1 to 14, wherein messages exchanged between the location server and the UE during the positioning session are not exchanged via a RAN controller entity.

[0185] Clause 16. A method as described in any of clauses 1 to 14, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via a RAN controller entity.

[0186] Clause 17. A method as described in any of clauses 1 to 16, wherein the positioning session between the location server and the UE is established via a RAN controller entity.

[0187] Clause 18. A method of communication performed by a Radio Access Network (RAN) entity, comprising: receiving from a location server a request for RAN data analysis associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request comprising at least an identifier of the positioning session; and sending to the location server a response to the request for RAN data analysis, the response comprising the RAN data analysis.

[0188] Clause 19. The method of clause 18, wherein: the request for RAN data analysis is received via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is sent via the Y1 interface.

[0189] Clause 20. A method as described in any of clauses 18 to 19, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0190] Clause 21. The method of any of clauses 18 to 20, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0191] Clause 22. The method of any of clauses 18 to 21, wherein the identifier of the positioning session comprises an LPP session identifier.

[0192] Clause 23. A method as described in any of clauses 18 to 22, further comprising generating a RAN-specific identifier for the positioning session based on an identifier of the positioning session.

[0193] Clause 24. A method according to any of clauses 18 to 23, wherein the RAN data analysis includes: a positioning method to be used for the positioning session, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during the positioning session, a muting pattern of one or more PRS resources, an identity of one or more positioning reference units (PRUs) that can be used for the positioning session, a trajectory of the UE, an inference model used to determine the position of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0194] Clause 25. The method of clause 24, further comprising determining a positioning method to be used for the positioning session based on positioning capabilities of the UE, accuracy of the requested UE position, response time to the positioning session, environmental context of the UE, or any combination thereof.

[0195] Clause 26. The method of clause 25, further comprising: receiving positioning capabilities of the UE from the UE; or receiving positioning capabilities of the UE from a location server.

[0196] Clause 27. A method according to any of clauses 24 to 26, further comprising: receiving positioning measurement results of one or more PRS resources from the UE via radio resource control (RRC) signaling; and sending the positioning measurement results of the one or more PRS resources to the location server via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0197] Clause 28. A method as described in any of clauses 24 to 27, wherein the request for RAN data analysis further includes positioning measurements of one or more PRS resources obtained by the UE.

[0198] Clause 29. A method as described in any of clauses 18 to 28, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via a RAN controller entity.

[0199] Clause 30. A method as described in any of clauses 18 to 29, wherein the positioning session between the location server and the UE is established via a RAN controller entity.

[0200] Clause 31. A location server comprising: a memory; at least one transceiver; and at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver, the at least one processor being configured to: establish a positioning session with a user equipment (UE) to determine a location of the UE; send a request for RAN data analysis associated with the positioning session of the UE to a radio access network RAN ​​entity via the at least one transceiver, the request including at least an identifier of the positioning session; receive a response to the request for RAN data analysis from a RAN controller entity via the at least one transceiver, the response including the RAN data analysis; and perform a positioning procedure with the UE to determine the location of the UE based at least in part on the RAN data analysis.

[0201] Clause 32. The method of clause 31 , wherein: the request for RAN data analysis is sent via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is received via the Y1 interface.

[0202] Clause 33. The location server of any of clauses 31 to 32, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0203] Clause 34. The location server of any of clauses 31 to 33, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0204] Clause 35. The location server of any of clauses 31 to 34, wherein the identifier of the positioning session comprises an LPP session identifier.

[0205] Clause 36. A location server according to any of clauses 31 to 35, wherein the RAN data analysis includes: a positioning method to be used for a positioning procedure, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during a positioning procedure, a muting pattern of one or more PRS resources, an identification of one or more positioning reference units (PRUs) that can be used for a positioning procedure, a trajectory of the UE, an inference model used to determine the location of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0206] Clause 37. A location server according to clause 36, wherein the positioning method to be used for the positioning procedure is determined based on the following: the positioning capability of the UE, the accuracy of the requested UE position, the response time to the positioning procedure, the environmental scenario of the UE, or any combination thereof.

[0207] Clause 38. The location server of clause 37, wherein the environmental context is based on a probability that the UE is in a line-of-sight (LOS) scenario or a non-line-of-sight (NLOS) scenario with respect to one or more radio units (RUs) available for positioning procedures.

[0208] Clause 39. The location server of any of clauses 37 to 38, wherein the at least one processor is further configured to: receive the positioning capabilities of the UE from the UE via the at least one transceiver; and send the positioning capabilities of the UE to the RAN controller entity via the at least one transceiver.

[0209] Clause 40. The location server of any of clauses 36 to 39, wherein the trajectory of the UE is based on a known topology of the route the UE is travelling.

[0210] Clause 41. The location server of clause 40, wherein the route comprises train tracks.

[0211] Clause 42. A location server according to any of clauses 36 to 41, wherein the at least one processor is further configured to: receive positioning measurement results of one or more PRS resources from the UE via LPP signaling via the at least one transceiver; or receive positioning measurement results of one or more PRS resources from the RAN controller entity via New Radio Positioning Protocol Type A (NRPPa) signaling via the at least one transceiver.

[0212] Clause 43. The location server of clause 42, wherein the request for RAN data analysis further includes positioning measurement results for one or more PRS resources.

[0213] Clause 44. A location server as described in any of clauses 36 to 43, wherein the one or more PRS resources include: one or more downlink PRS resources, one or more uplink PRS resources, one or more sidelink PRS resources, or any combination thereof.

[0214] Clause 45. The location server of any of clauses 31 to 44, wherein messages exchanged between the location server and the UE during the positioning session are not exchanged via a RAN controller entity.

[0215] Clause 46. The location server of any of clauses 31 to 44, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via a RAN controller entity.

[0216] Clause 47. The location server of any of clauses 31 to 46, wherein the positioning session between the location server and the UE is established via a RAN controller entity.

[0217] Clause 48. A radio access network (RAN) entity comprising: a memory; at least one transceiver; and at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver, the at least one processor being configured to: receive, via the at least one transceiver, a request for RAN data analysis from a location server, the RAN data analysis being associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request including at least an identifier of the positioning session; and send, via the at least one transceiver, a response to the request for the RAN data analysis to the location server, the response including the RAN data analysis.

[0218] Clause 49. The RAN controller entity of clause 48, wherein: the request for RAN data analysis is received via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is sent via the Y1 interface.

[0219] Clause 50. The RAN controller entity of any of clauses 48 to 49, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0220] Clause 51. The RAN controller entity of any of clauses 48 to 50, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0221] Clause 52. The RAN controller entity of any of clauses 48 to 51, wherein the identifier of the positioning session comprises an LPP session identifier.

[0222] Clause 53. The RAN controller entity of any of clauses 48 to 52, wherein the at least one processor is further configured to generate a RAN specific identifier for the positioning session based on an identifier of the positioning session.

[0223] Clause 54. A RAN controller entity as described in any of clauses 48 to 53, wherein the RAN data analysis includes: a positioning method to be used for the positioning session, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during the positioning session, a muting pattern of one or more PRS resources, an identity of one or more positioning reference units (PRUs) that can be used for the positioning session, a trajectory of the UE, an inference model used to determine the position of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0224] Clause 55. A RAN controller entity according to clause 54, wherein the at least one processor is further configured to: determine the positioning method to be used for the positioning session based on: the positioning capability of the UE, the accuracy of the requested UE position, the response time to the positioning session, the environmental scenario of the UE, or any combination thereof.

[0225] Clause 56. The RAN controller entity of clause 55, wherein the at least one processor is further configured to: receive positioning capabilities of the UE from the UE via the at least one transceiver; or receive positioning capabilities of the UE from a location server via the at least one transceiver.

[0226] Clause 57. A RAN controller entity as described in any of clauses 54 to 56, wherein the at least one processor is further configured to: receive, via the at least one transceiver, positioning measurement results of one or more PRS resources from the UE via Radio Resource Control (RRC) signaling; and send, via the at least one transceiver, positioning measurement results of the one or more PRS resources to the location server via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0227] Clause 58. The RAN controller entity of any of clauses 54 to 57, wherein the request for RAN data analysis further comprises positioning measurements of one or more PRS resources obtained by the UE.

[0228] Clause 59. The RAN controller entity of any of clauses 48 to 58, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via the RAN controller entity.

[0229] Clause 60. The RAN controller entity of any of clauses 48 to 59, wherein the positioning session between the location server and the UE is established via the RAN controller entity.

[0230] Clause 61. A location server comprising: means for establishing a positioning session with a user equipment (UE) to determine the location of the UE; means for sending a request for RAN data analysis associated with the positioning session of the UE to a radio access network, RAN, entity, the request including at least an identifier of the positioning session; means for receiving a response to the request for RAN data analysis from a RAN controller entity, the response including the RAN data analysis; and means for performing a positioning procedure with the UE to determine the location of the UE based at least in part on the RAN data analysis.

[0231] Clause 62. The location server of clause 61, wherein: the request for RAN data analysis is sent via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is received via the Y1 interface.

[0232] Clause 63. The location server of any of clauses 61 to 62, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0233] Clause 64. The location server of any of clauses 61 to 63, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0234] Clause 65. The location server of any of clauses 61 to 64, wherein the identifier of the positioning session comprises an LPP session identifier.

[0235] Clause 66. A location server according to any of clauses 61 to 65, wherein the RAN data analysis includes: a positioning method to be used for a positioning procedure, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during a positioning procedure, a muting pattern of one or more PRS resources, an identity of one or more positioning reference units (PRUs) that can be used for a positioning procedure, a trajectory of the UE, an inference model used to determine the location of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0236] Clause 67. A location server according to clause 66, wherein the positioning method to be used for the positioning procedure is determined based on the positioning capability of the UE, the accuracy of the requested UE position, the response time to the positioning procedure, the environmental scenario of the UE, or any combination thereof.

[0237] Clause 68. The location server of clause 67, wherein the environmental context is based on a probability that the UE is in a line-of-sight (LOS) scenario or a non-line-of-sight (NLOS) scenario with respect to one or more radio units (RUs) available for positioning procedures.

[0238] Clause 69. The location server of any of clauses 67 to 68, further comprising: means for receiving positioning capabilities of the UE from the UE; and means for transmitting the positioning capabilities of the UE to the RAN controller entity.

[0239] Clause 70. The location server of any of clauses 66 to 69, wherein the trajectory of the UE is based on a known topology of the route the UE is travelling.

[0240] Clause 71. The location server of clause 70, wherein the route comprises train tracks.

[0241] Clause 72. A location server according to any of clauses 66 to 71, further comprising: means for receiving positioning measurement results of one or more PRS resources from a UE via LPP signaling; or means for receiving positioning measurement results of one or more PRS resources from a RAN controller entity via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0242] Clause 73. The location server of clause 72, wherein the request for RAN data analysis further includes positioning measurement results for one or more PRS resources.

[0243] Clause 74. A location server as described in any of clauses 66 to 73, wherein the one or more PRS resources include: one or more downlink PRS resources, one or more uplink PRS resources, one or more sidelink PRS resources, or any combination thereof.

[0244] Clause 75. The location server of any of clauses 61 to 74, wherein messages exchanged between the location server and the UE during the positioning session are not exchanged via a RAN controller entity.

[0245] Clause 76. The location server of any of clauses 61 to 74, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via a RAN controller entity.

[0246] Clause 77. The location server of any of clauses 61 to 76, wherein the positioning session between the location server and the UE is established via a RAN controller entity.

[0247] Clause 78. A radio access network, RAN, entity comprising: means for receiving, from a location server, a request for a RAN data analysis associated with a positioning session between the location server and a user equipment, UE, to determine the location of the UE, the request comprising at least an identifier of the positioning session; and means for sending, to the location server, a response to the request for the RAN data analysis, the response comprising the RAN data analysis.

[0248] Clause 79. The RAN controller entity of clause 78, wherein: the request for RAN data analysis is received via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is sent via the Y1 interface.

[0249] Clause 80. The RAN controller entity of any of clauses 78 to 79, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0250] Clause 81. The RAN controller entity of any of clauses 78 to 80, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0251] Clause 82. The RAN controller entity of any of clauses 78 to 81, wherein the identifier of the positioning session comprises an LPP session identifier.

[0252] Clause 83. The RAN controller entity of any of clauses 78 to 82, further comprising: means for generating a RAN specific identifier for the positioning session based on an identifier of the positioning session.

[0253] Clause 84. A RAN controller entity as described in any of clauses 78 to 83, wherein the RAN data analysis includes: a positioning method to be used for the positioning session, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during the positioning session, a muting pattern of one or more PRS resources, an identity of one or more positioning reference units (PRUs) that can be used for the positioning session, a trajectory of the UE, an inference model used to determine the position of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0254] Clause 85. The RAN controller entity according to clause 84 further comprises: means for determining a positioning method to be used for a positioning session based on: the positioning capability of the UE, the accuracy of the requested UE position, the response time of the positioning session, the environmental scenario of the UE, or any combination thereof.

[0255] Clause 86. The RAN controller entity of clause 85, further comprising: means for receiving positioning capabilities of the UE from the UE; or means for receiving positioning capabilities of the UE from a location server.

[0256] Clause 87. A RAN controller entity as described in any of clauses 84 to 86, further comprising: means for receiving positioning measurement results of one or more PRS resources from the UE via radio resource control (RRC) signaling; and means for sending the positioning measurement results of the one or more PRS resources to the location server via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0257] Clause 88. The RAN controller entity of any of clauses 84 to 87, wherein the request for RAN data analysis further comprises positioning measurements of one or more PRS resources obtained by the UE.

[0258] Clause 89. The RAN controller entity of any of clauses 78 to 88, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via the RAN controller entity.

[0259] Clause 90. The RAN controller entity of any of clauses 78 to 89, wherein the positioning session between the location server and the UE is established via the RAN controller entity.

[0260] Clause 91. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a location server, cause the location server to: establish a positioning session with a user equipment (UE) to determine the location of the UE; send a request to a radio access network (RAN) entity for RAN data analysis associated with the positioning session for the UE, the request including at least an identifier of the positioning session; receive a response to the request for RAN data analysis from a RAN controller entity, the response including the RAN data analysis; and perform a positioning procedure with the UE to determine the location of the UE based at least in part on the RAN data analysis.

[0261] Clause 92. The non-transitory computer-readable medium of clause 91, wherein: the request for RAN data analysis is sent via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is received via the Y1 interface.

[0262] Clause 93. The non-transitory computer-readable medium of any of clauses 91 to 92, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0263] Clause 94. The non-transitory computer-readable medium of any of clauses 91 to 93, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0264] Clause 95. The non-transitory computer-readable medium of any of clauses 91 to 94, wherein the identifier of the positioning session comprises an LPP session identifier.

[0265] Clause 96. A non-transitory computer-readable medium according to any one of clauses 91 to 95, wherein the RAN data analysis includes: a positioning method to be used for a positioning procedure, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during a positioning procedure, a muting pattern for one or more PRS resources, an identification of one or more positioning reference units (PRUs) that can be used for the positioning procedure, a trajectory of the UE, an inference model used to determine the location of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0266] Clause 97. A non-transitory computer-readable medium according to clause 96, wherein the positioning method to be used for the positioning procedure is determined based on the following: the positioning capability of the UE, the accuracy of the requested UE position, the response time to the positioning procedure, the environmental scenario of the UE, or any combination thereof.

[0267] Clause 98. The non-transitory computer-readable medium of clause 97, wherein the environmental scenario is based on a probability of the UE being in a line-of-sight (LOS) scenario or a non-line-of-sight (NLOS) scenario relative to one or more radio units (RUs) available for positioning procedures.

[0268] Clause 99. A non-transitory computer-readable medium according to any one of clauses 97 to 98, further comprising computer-executable instructions that, when executed by a location server, cause the location server to: receive positioning capabilities of the UE from the UE; and send the positioning capabilities of the UE to a RAN controller entity.

[0269] Clause 100. The non-transitory computer-readable medium of any of clauses 96 to 99, wherein the trajectory of the UE is based on a known topology of a route traveled by the UE.

[0270] Clause 101. The non-transitory computer-readable medium of clause 100, wherein the route comprises train tracks.

[0271] Clause 102. A non-transitory computer-readable medium according to any one of clauses 96 to 101, further comprising computer-executable instructions that, when executed by a location server, cause the location server to: receive positioning measurement results of one or more PRS resources from a UE via LPP signaling; or receive positioning measurement results of one or more PRS resources from a RAN controller entity via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0272] Clause 103. The non-transitory computer-readable medium of clause 102, wherein the request for RAN data analysis further comprises positioning measurements for one or more PRS resources.

[0273] Clause 104. The non-transitory computer-readable medium of any one of clauses 96 to 103, wherein the one or more PRS resources comprise: one or more downlink PRS resources, one or more uplink PRS resources, one or more sidelink PRS resources, or any combination thereof.

[0274] Clause 105. The non-transitory computer-readable medium of any of clauses 91 to 104, wherein messages exchanged between the location server and the UE during the positioning session are not exchanged via a RAN controller entity.

[0275] Clause 106. The non-transitory computer-readable medium of any of clauses 91 to 104, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via a RAN controller entity.

[0276] Clause 107. The non-transitory computer-readable medium of any of clauses 91 to 106, wherein the positioning session between the location server and the UE is established via a RAN controller entity.

[0277] Clause 108. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a radio access network (RAN) entity, cause a RAN controller entity to: receive from a location server a request for RAN data analysis associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request including at least an identifier of the positioning session; and send to the location server a response to the request for the RAN data analysis, the response including the RAN data analysis.

[0278] Clause 109. The non-transitory computer-readable medium of clause 108, wherein: the request for RAN data analysis is received via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is sent via the Y1 interface.

[0279] Clause 110. The non-transitory computer-readable medium of any of clauses 108 to 109, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0280] Clause 111. The non-transitory computer-readable medium of any of clauses 108 to 110, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0281] Clause 112. The non-transitory computer-readable medium of any of clauses 108 to 111, wherein the identifier of the positioning session comprises an LPP session identifier.

[0282] Clause 113. The non-transitory computer-readable medium of any of clauses 108 to 112, further comprising computer-executable instructions that, when executed by a RAN controller entity, cause the RAN controller entity to: generate a RAN-specific identifier for the positioning session based on an identifier of the positioning session.

[0283] Clause 114. A non-transitory computer-readable medium according to any of clauses 108 to 113, wherein the RAN data analysis includes: a positioning method to be used for a positioning session, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during a positioning session, a muting pattern to be used for one or more PRS resources, an identity of one or more positioning reference units (PRUs) that may be used for the positioning session, a trajectory of the UE, an inference model used to determine the location of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0284] Clause 115. The non-transitory computer-readable medium of clause 114 further comprises computer-executable instructions that, when executed by the RAN controller entity, cause the RAN controller entity to: determine a positioning method to be used for a positioning session based on: the positioning capabilities of the UE, the accuracy of the requested UE position, the response time to the positioning session, the environmental scenario of the UE, or any combination thereof.

[0285] Clause 116. The non-transitory computer-readable medium of clause 115, further comprising computer-executable instructions that, when executed by a RAN controller entity, cause the RAN controller entity to: receive positioning capabilities of the UE from the UE; or receive positioning capabilities of the UE from a location server.

[0286] Clause 117. A non-transitory computer-readable medium according to any of clauses 114 to 116, further comprising computer-executable instructions that, when executed by a RAN controller entity, cause the RAN controller entity to: receive positioning measurement results of one or more PRS resources from a UE via radio resource control (RRC) signaling; and send positioning measurement results of one or more PRS resources to a location server via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0287] Clause 118. The non-transitory computer-readable medium of any of clauses 114 to 117, wherein the request for RAN data analysis further comprises positioning measurements of one or more PRS resources obtained by the UE.

[0288] Clause 119. The non-transitory computer-readable medium of any of clauses 108 to 118, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via a RAN controller entity.

[0289] Clause 120. The non-transitory computer-readable medium of any of clauses 108 to 119, wherein the positioning session between the location server and the UE is established via a RAN controller entity.

[0290] Additional implementation examples are described in the following numbered clauses:

[0291] Clause 1. A method of communication performed by a location server, comprising: sending a request for RAN data analysis associated with a positioning session between the location server and a user equipment (UE) to a radio access network RAN ​​entity, the request including at least an identifier of the positioning session; receiving a response to the request for RAN data analysis from a RAN controller entity, the response including the RAN data analysis; and performing a positioning procedure with the UE to determine a location of the UE based at least in part on the RAN data analysis.

[0292] Clause 2. The method of clause 1, wherein: the request for RAN data analysis is sent via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is received via the Y1 interface.

[0293] Clause 3. A method as described in any of clauses 1 to 2, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0294] Clause 4. The method of any of clauses 1 to 3, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0295] Clause 5. The method of any of clauses 1 to 4, wherein the identifier of the positioning session comprises an LPP session identifier.

[0296] Clause 6. A method according to any of clauses 1 to 5, wherein the RAN data analysis includes: a positioning method to be used for the positioning procedure, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during the positioning procedure, a muting pattern for one or more PRS resources, an identity of one or more positioning reference units (PRUs) that can be used for the positioning procedure, a trajectory of the UE, an inference model used to determine the position of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0297] Clause 7. A method according to clause 6, wherein the positioning method to be used for the positioning procedure is determined based on the following: the positioning capability of the UE, the accuracy of the requested UE position, the response time to the positioning procedure, the environmental scenario of the UE, or any combination thereof.

[0298] Clause 8. The method of clause 7, wherein the environmental context is based on a probability that the UE is in a line-of-sight (LOS) scenario or a non-line-of-sight (NLOS) scenario relative to one or more radio units (RUs) available for positioning procedures.

[0299] Clause 9. The method of any of clauses 7 to 8, further comprising: receiving positioning capabilities of the UE from the UE; and sending the positioning capabilities of the UE to the RAN controller entity.

[0300] Clause 10. A method as described in any of clauses 6 to 9, wherein the trajectory of the UE is based on a known topology of the route travelled by the UE.

[0301] Clause 11. The method of clause 10, wherein the route comprises train tracks.

[0302] Clause 12. A method as described in any of clauses 6 to 11, further comprising: receiving positioning measurement results of one or more PRS resources from the UE via LPP signaling; or receiving positioning measurement results of one or more PRS resources from a RAN controller entity via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0303] Clause 13. A method as described in any of clauses 6 to 12, wherein the request for RAN data analysis further includes positioning measurements of one or more PRS resources received from the UE.

[0304] Clause 14. The method of any of clauses 6 to 13, wherein the one or more PRS resources comprise: one or more downlink PRS resources, one or more uplink PRS resources, one or more sidelink PRS resources, or any combination thereof.

[0305] Clause 15. A method as described in any of clauses 1 to 14, wherein messages exchanged between the location server and the UE during the positioning session are not exchanged via a RAN controller entity.

[0306] Clause 16. A method as described in any of clauses 1 to 14, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via a RAN controller entity.

[0307] Clause 17. A method as described in any of clauses 1 to 16, wherein the positioning session between the location server and the UE is established via a RAN controller entity.

[0308] Clause 18. A method of communication performed by a Radio Access Network (RAN) entity, comprising: receiving from a location server a request for RAN data analysis associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request comprising at least an identifier of the positioning session; and sending to the location server a response to the request for RAN data analysis, the response comprising the RAN data analysis.

[0309] Clause 19. The method of clause 18, wherein the request for RAN data analysis is received via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is sent via the Y1 interface.

[0310] Clause 20. A method as described in any of clauses 18 to 19, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0311] Clause 21. The method of any of clauses 18 to 20, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0312] Clause 22. The method of any of clauses 18 to 21, wherein the identifier of the positioning session comprises an LPP session identifier.

[0313] Clause 23. A method as described in any of clauses 18 to 22, further comprising generating a RAN-specific identifier for the positioning session based on an identifier of the positioning session.

[0314] Clause 24. A method according to any of clauses 18 to 23, wherein the RAN data analysis includes: a positioning method to be used for the positioning session, a pattern of one or more positioning reference signal (PRS) resources (e.g., one or more DL-PRS resources, one or more UL-PRS resources, one or more SL-PRS resources, or any combination thereof) to be sent and measured during the positioning session, a muting pattern for one or more PRS resources, an identity of one or more positioning reference units (PRUs) that can be used for the positioning session, a trajectory of the UE (e.g., where the trajectory of the UE is based on a known topology of a route on which the UE is traveling, such as a train track), an inference model used to determine the position of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0315] Clause 25. The method according to clause 24 further includes: determining a positioning method to be used for the positioning session based on the positioning capability of the UE, the accuracy of the requested UE position, the response time to the positioning session, the environmental scenario of the UE (for example, wherein the environmental scenario is based on the probability that the UE is in a line-of-sight (LOS) scenario or a non-line-of-sight (NLOS) scenario relative to one or more radio units (RUs) available for the positioning procedure), or any combination thereof.

[0316] Clause 26. The method of clause 25, further comprising: receiving positioning capabilities of the UE from the UE; or receiving positioning capabilities of the UE from a location server.

[0317] Clause 27. A method according to any of clauses 24 to 26, further comprising: receiving positioning measurement results of one or more PRS resources from the UE via radio resource control (RRC) signaling; and sending the positioning measurement results of the one or more PRS resources to the location server via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0318] Clause 28. A method as described in any of clauses 24 to 27, wherein the request for RAN data analysis further includes positioning measurements of one or more PRS resources obtained by the UE.

[0319] Clause 29. A method as described in any of clauses 18 to 28, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via a RAN controller entity.

[0320] Clause 30. A method as described in any of clauses 18 to 29, wherein the positioning session between the location server and the UE is established via a RAN controller entity.

[0321] Clause 31. A location server comprising: a memory; at least one transceiver; and at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver, the at least one processor being configured to: send a request for RAN data analysis associated with a positioning session between the location server and a user equipment (UE) to a radio access network (RAN) entity via the at least one transceiver, the request including at least an identifier of the positioning session; receive a response to the request for RAN data analysis from a RAN controller entity via the at least one transceiver, the response including the RAN data analysis; and perform a positioning procedure with the UE to determine a location of the UE based at least in part on the RAN data analysis.

[0322] Clause 32. The location server of clause 31, wherein: the request for RAN data analysis is sent via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is received via the Y1 interface.

[0323] Clause 33. The location server of any of clauses 31 to 32, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0324] Clause 34. The location server of any of clauses 31 to 33, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0325] Clause 35. The location server of any of clauses 31 to 34, wherein the identifier of the positioning session comprises an LPP session identifier.

[0326] Clause 36. A location server according to any of clauses 31 to 35, wherein the RAN data analysis includes: a positioning method to be used for a positioning procedure, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during a positioning procedure, a muting pattern of one or more PRS resources, an identification of one or more positioning reference units (PRUs) that can be used for a positioning procedure, a trajectory of the UE, an inference model used to determine the location of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0327] Clause 37. A location server according to clause 36, wherein the positioning method to be used for the positioning procedure is determined based on the following: the positioning capability of the UE, the accuracy of the requested UE position, the response time to the positioning procedure, the environmental scenario of the UE, or any combination thereof.

[0328] Clause 38. The location server of clause 37, wherein the environmental context is based on a probability that the UE is in a line-of-sight (LOS) scenario or a non-line-of-sight (NLOS) scenario with respect to one or more radio units (RUs) available for positioning procedures.

[0329] Clause 39. A location server according to any of clauses 37 to 38, wherein the at least one processor is further configured to: receive positioning capabilities of the UE from the UE via the at least one transceiver; and send the positioning capabilities of the UE to the RAN controller entity via the at least one transceiver.

[0330] Clause 40. The location server of any of clauses 36 to 39, wherein the trajectory of the UE is based on a known topology of a route that the UE is travelling.

[0331] Clause 41. The location server of clause 40, wherein the route comprises train tracks.

[0332] Clause 42. A location server according to any of clauses 36 to 41, wherein the at least one processor is further configured to: receive positioning measurement results of one or more PRS resources from the UE via LPP signaling via the at least one transceiver; or receive positioning measurement results of one or more PRS resources from the RAN controller entity via New Radio Positioning Protocol Type A (NRPPa) signaling via the at least one transceiver.

[0333] Clause 43. The location server of any of clauses 36 to 42, wherein the request for RAN data analysis further comprises positioning measurements of one or more PRS resources received from the UE.

[0334] Clause 44. A location server as described in any of clauses 36 to 43, wherein the one or more PRS resources include: one or more downlink PRS resources, one or more uplink PRS resources, one or more sidelink PRS resources, or any combination thereof.

[0335] Clause 45. The location server of any of clauses 31 to 44, wherein messages exchanged between the location server and the UE during the positioning session are not exchanged via a RAN controller entity.

[0336] Clause 46. The location server of any of clauses 31 to 44, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via a RAN controller entity.

[0337] Clause 47. The location server of any of clauses 31 to 46, wherein the positioning session between the location server and the UE is established via a RAN controller entity.

[0338] Clause 48. A radio access network (RAN) entity comprising: a memory; at least one transceiver; and at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver, the at least one processor being configured to: receive, via the at least one transceiver, a request for RAN data analysis from a location server, the RAN data analysis being associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request comprising at least an identifier of the positioning session; and send, via the at least one transceiver, a response to the request for RAN data analysis to the location server, the response comprising the RAN data analysis.

[0339] Clause 49. The RAN controller entity of clause 48, wherein: the request for RAN data analysis is received via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is sent via the Y1 interface.

[0340] Clause 50. The RAN controller entity of any of clauses 48 to 49, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0341] Clause 51. The RAN controller entity of any of clauses 48 to 50, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0342] Clause 52. The RAN controller entity of any of clauses 48 to 51, wherein the identifier of the positioning session comprises an LPP session identifier.

[0343] Clause 53. The RAN controller entity of any of clauses 48 to 52, wherein the at least one processor is further configured to generate a RAN specific identifier for the positioning session based on an identifier of the positioning session.

[0344] Clause 54. A RAN controller entity as described in any of clauses 48 to 53, wherein the RAN data analysis includes: a positioning method to be used for a positioning session, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during a positioning session, a muting pattern of one or more PRS resources, an identity of one or more positioning reference units (PRUs) that can be used for the positioning session, a trajectory of the UE, an inference model used to determine the position of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0345] Clause 55. A RAN controller entity according to clause 54, wherein the at least one processor is further configured to: determine the positioning method to be used for the positioning session based on: the positioning capability of the UE, the accuracy of the requested UE position, the response time of the positioning session, the environmental scenario of the UE, or any combination thereof.

[0346] Clause 56. The RAN controller entity of clause 55, wherein the at least one processor is further configured to: receive positioning capabilities of the UE from the UE via the at least one transceiver; or receive positioning capabilities of the UE from a location server via the at least one transceiver.

[0347] Clause 57. A RAN controller entity as described in any of clauses 54 to 56, wherein the at least one processor is further configured to: receive positioning measurement results of one or more PRS resources from the UE via radio resource control (RRC) signaling via the at least one transceiver; and send the positioning measurement results of the one or more PRS resources to the location server via New Radio Positioning Protocol Type A (NRPPa) signaling via the at least one transceiver.

[0348] Clause 58. The RAN controller entity of any of clauses 54 to 57, wherein the request for RAN data analysis further comprises positioning measurements of one or more PRS resources obtained by the UE.

[0349] Clause 59. The RAN controller entity of any of clauses 48 to 58, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via the RAN controller entity.

[0350] Clause 60. The RAN controller entity of any of clauses 48 to 59, wherein the positioning session between the location server and the UE is established via the RAN controller entity.

[0351] Clause 61. A location server comprising: means for sending a request for RAN data analysis associated with a positioning session between the location server and a user equipment (UE), the request comprising at least an identifier of the positioning session; means for receiving a response to the request for RAN data analysis from a RAN controller entity, the response comprising the RAN data analysis; and means for performing a positioning procedure with the UE to determine a location of the UE based at least in part on the RAN data analysis.

[0352] Clause 62. The location server of clause 61, wherein: the request for RAN data analysis is sent via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is received via the Y1 interface.

[0353] Clause 63. The location server of any of clauses 61 to 62, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0354] Clause 64. The location server of any of clauses 61 to 63, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0355] Clause 65. The location server of any of clauses 61 to 64, wherein the identifier of the positioning session comprises an LPP session identifier.

[0356] Clause 66. A location server according to any of clauses 61 to 65, wherein the RAN data analysis includes: a positioning method to be used for a positioning procedure, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during a positioning procedure, a muting pattern of one or more PRS resources, an identity of one or more positioning reference units (PRUs) that can be used for a positioning procedure, a trajectory of the UE, an inference model used to determine the location of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0357] Clause 67. A location server according to clause 66, wherein the positioning method to be used for the positioning procedure is determined based on the positioning capability of the UE, the accuracy of the requested UE position, the response time to the positioning procedure, the environmental scenario of the UE, or any combination thereof.

[0358] Clause 68. The location server of clause 67, wherein the environmental context is based on a probability that the UE is in a line-of-sight (LOS) scenario or a non-line-of-sight (NLOS) scenario with respect to one or more radio units (RUs) available for positioning procedures.

[0359] Clause 69. The location server of any of clauses 67 to 68, further comprising: means for receiving positioning capabilities of the UE from the UE; and means for transmitting the positioning capabilities of the UE to the RAN controller entity.

[0360] Clause 70. The location server of any of clauses 66 to 69, wherein the trajectory of the UE is based on a known topology of the route the UE is travelling.

[0361] Clause 71. The location server of clause 70, wherein the route comprises train tracks.

[0362] Clause 72. A location server according to any of clauses 66 to 71, further comprising: means for receiving positioning measurements of one or more PRS resources from a UE via LPP signaling; or means for receiving positioning measurements of one or more PRS resources from a RAN controller entity via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0363] Clause 73. The location server of any of clauses 66 to 72, wherein the request for RAN data analysis further comprises positioning measurements of one or more PRS resources received from the UE.

[0364] Clause 74. A location server as described in any of clauses 66 to 73, wherein the one or more PRS resources include: one or more downlink PRS resources, one or more uplink PRS resources, one or more sidelink PRS resources, or any combination thereof.

[0365] Clause 75. The location server of any of clauses 61 to 74, wherein messages exchanged between the location server and the UE during the positioning session are not exchanged via a RAN controller entity.

[0366] Clause 76. The location server of any of clauses 61 to 74, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via a RAN controller entity.

[0367] Clause 77. The location server of any of clauses 61 to 76, wherein the positioning session between the location server and the UE is established via a RAN controller entity.

[0368] Clause 78. A radio access network, RAN, entity comprising: means for receiving, from a location server, a request for a RAN data analysis associated with a positioning session between the location server and a user equipment, UE, to determine the location of the UE, the request comprising at least an identifier of the positioning session; and means for sending, to the location server, a response to the request for the RAN data analysis, the response comprising the RAN data analysis.

[0369] Clause 79. The RAN controller entity of clause 78, wherein: the request for RAN data analysis is received via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is sent via the Y1 interface.

[0370] Clause 80. The RAN controller entity of any of clauses 78 to 79, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0371] Clause 81. The RAN controller entity of any of clauses 78 to 80, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0372] Clause 82. The RAN controller entity of any of clauses 78 to 81, wherein the identifier of the positioning session comprises an LPP session identifier.

[0373] Clause 83. The RAN controller entity of any of clauses 78 to 82, further comprising means for generating a RAN specific identifier for the positioning session based on an identifier of the positioning session.

[0374] Clause 84. A RAN controller entity as described in any of clauses 78 to 83, wherein the RAN data analysis includes: a positioning method to be used for the positioning session, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during the positioning session, a muting pattern of one or more PRS resources, an identity of one or more positioning reference units (PRUs) that can be used for the positioning session, a trajectory of the UE, an inference model used to determine the position of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0375] Clause 85. The RAN controller entity according to clause 84 further comprises: a unit for determining a positioning method to be used for the positioning session based on: the positioning capability of the UE, the accuracy of the requested UE position, the response time to the positioning session, the environmental scenario of the UE, or any combination thereof.

[0376] Clause 86. The RAN controller entity of clause 85, further comprising: means for receiving positioning capabilities of the UE from the UE; or means for receiving positioning capabilities of the UE from a location server.

[0377] Clause 87. A RAN controller entity as described in any of clauses 84 to 86, further comprising: means for receiving positioning measurement results of one or more PRS resources from the UE via radio resource control (RRC) signaling; and means for sending the positioning measurement results of the one or more PRS resources to the location server via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0378] Clause 88. The RAN controller entity of any of clauses 84 to 87, wherein the request for RAN data analysis further comprises positioning measurements of one or more PRS resources obtained by the UE.

[0379] Clause 89. The RAN controller entity of any of clauses 78 to 88, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via the RAN controller entity.

[0380] Clause 90. The RAN controller entity of any of clauses 78 to 89, wherein the positioning session between the location server and the UE is established via the RAN controller entity.

[0381] Clause 91. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a location server, cause the location server to: send a request to a radio access network (RAN) entity for RAN data analysis associated with a positioning session between the location server and a user equipment (UE), the request including at least an identifier of the positioning session; receive a response to the request for RAN data analysis from a RAN controller entity, the response including the RAN data analysis; and perform a positioning procedure with the UE to determine a location of the UE based at least in part on the RAN data analysis.

[0382] Clause 92. The non-transitory computer-readable medium of clause 91, wherein: the request for RAN data analysis is sent via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is received via the Y1 interface.

[0383] Clause 93. The non-transitory computer-readable medium of any of clauses 91 to 92, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0384] Clause 94. The non-transitory computer-readable medium of any of clauses 91 to 93, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0385] Clause 95. The non-transitory computer-readable medium of any of clauses 91 to 94, wherein the identifier of the positioning session comprises an LPP session identifier.

[0386] Clause 96. A non-transitory computer-readable medium according to any one of clauses 91 to 95, wherein the RAN data analysis includes: a positioning method to be used for a positioning procedure, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during a positioning procedure, a muting pattern for one or more PRS resources, an identification of one or more positioning reference units (PRUs) that can be used for the positioning procedure, a trajectory of the UE, an inference model used to determine the location of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0387] Clause 97. A non-transitory computer-readable medium according to clause 96, wherein the positioning method to be used for the positioning procedure is determined based on the following: the positioning capability of the UE, the accuracy of the requested UE position, the response time to the positioning procedure, the environmental scenario of the UE, or any combination thereof.

[0388] Clause 98. The non-transitory computer-readable medium of clause 97, wherein the environmental scenario is based on a probability of the UE being in a line-of-sight (LOS) scenario or a non-line-of-sight (NLOS) scenario relative to one or more radio units (RUs) available for positioning procedures.

[0389] Clause 99. The non-transitory computer-readable medium of any one of clauses 97 to 98, further comprising computer-executable instructions that, when executed by a location server, cause the location server to: receive positioning capabilities of the UE from the UE; and send the positioning capabilities of the UE to a RAN controller entity.

[0390] Clause 100. The non-transitory computer-readable medium of any of clauses 96 to 99, wherein the trajectory of the UE is based on a known topology of a route traveled by the UE.

[0391] Clause 101. The non-transitory computer-readable medium of clause 100, wherein the route comprises train tracks.

[0392] Clause 102. A non-transitory computer-readable medium according to any one of clauses 96 to 101, further comprising computer-executable instructions that, when executed by a location server, cause the location server to: receive positioning measurement results of one or more PRS resources from a UE via LPP signaling; or receive positioning measurement results of one or more PRS resources from a RAN controller entity via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0393] Clause 103. The non-transitory computer-readable medium of any of clauses 96 to 102, wherein the request for RAN data analysis further comprises positioning measurements of one or more PRS resources received from the UE.

[0394] Clause 104. The non-transitory computer-readable medium of any one of clauses 96 to 103, wherein the one or more PRS resources comprise: one or more downlink PRS resources, one or more uplink PRS resources, one or more sidelink PRS resources, or any combination thereof.

[0395] Clause 105. The non-transitory computer-readable medium of any of clauses 91 to 104, wherein messages exchanged between the location server and the UE during the positioning session are not exchanged via a RAN controller entity.

[0396] Clause 106. The non-transitory computer-readable medium of any of clauses 91 to 104, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via a RAN controller entity.

[0397] Clause 107. The non-transitory computer-readable medium of any of clauses 91 to 106, wherein the positioning session between the location server and the UE is established via a RAN controller entity.

[0398] Clause 108. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a radio access network (RAN) entity, cause a RAN controller entity to: receive from a location server a request for RAN data analysis associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request including at least an identifier of the positioning session; and send to the location server a response to the request for the RAN data analysis, the response including the RAN data analysis.

[0399] Clause 109. The non-transitory computer-readable medium of clause 108, wherein: the request for RAN data analysis is received via a Y1 interface between the location server and the RAN controller entity, and the response to the request for RAN data analysis is sent via the Y1 interface.

[0400] Clause 110. The non-transitory computer-readable medium of any of clauses 108 to 109, wherein the RAN controller entity comprises a near real-time RAN intelligent controller (RIC).

[0401] Clause 111. The non-transitory computer-readable medium of any of clauses 108 to 110, wherein the positioning session comprises a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

[0402] Clause 112. The non-transitory computer-readable medium of any of clauses 108 to 111, wherein the identifier of the positioning session comprises an LPP session identifier.

[0403] Clause 113. The non-transitory computer-readable medium of any of clauses 108 to 112, further comprising computer-executable instructions that, when executed by a RAN controller entity, cause the RAN controller entity to: generate a RAN-specific identifier for the positioning session based on an identifier for the positioning session.

[0404] Clause 114. A non-transitory computer-readable medium according to any of clauses 108 to 113, wherein the RAN data analysis includes: a positioning method to be used for a positioning session, a pattern of one or more positioning reference signal (PRS) resources to be sent and measured during a positioning session, a muting pattern for one or more PRS resources, an identity of one or more positioning reference units (PRUs) that can be used for the positioning session, a trajectory of the UE, an inference model used to determine the location of the UE, types of network nodes deployed in the vicinity of the UE, or any combination thereof.

[0405] Clause 115. The non-transitory computer-readable medium of clause 114 further comprises computer-executable instructions that, when executed by the RAN controller entity, cause the RAN controller entity to: determine a positioning method to be used for a positioning session based on: the positioning capability of the UE, the accuracy of the requested UE position, the response time of the positioning session, the environmental scenario of the UE, or any combination thereof.

[0406] Clause 116. The non-transitory computer-readable medium of clause 115, further comprising computer-executable instructions that, when executed by a RAN controller entity, cause the RAN controller entity to: receive positioning capabilities of the UE from the UE; or receive positioning capabilities of the UE from a location server.

[0407] Clause 117. A non-transitory computer-readable medium according to any of clauses 114 to 116, further comprising computer-executable instructions that, when executed by a RAN controller entity, cause the RAN controller entity to: receive positioning measurement results of one or more PRS resources from a UE via radio resource control (RRC) signaling; and send positioning measurement results of one or more PRS resources to a location server via New Radio Positioning Protocol Type A (NRPPa) signaling.

[0408] Clause 118. The non-transitory computer-readable medium of any of clauses 114 to 117, wherein the request for RAN data analysis further comprises positioning measurements of one or more PRS resources obtained by the UE.

[0409] Clause 119. The non-transitory computer-readable medium of any of clauses 108 to 118, wherein messages exchanged between the location server and the UE during the positioning session are exchanged via a RAN controller entity.

[0410] Clause 120. The non-transitory computer-readable medium of any of clauses 108 to 119, wherein the positioning session between the location server and the UE is established via a RAN controller entity.

[0411] Those skilled in the art will appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be mentioned throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0412] Furthermore, those skilled in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithmic steps described in conjunction with the aspects disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

[0413] The various illustrative logical blocks, modules, and circuits described in connection with the various aspects disclosed herein may be implemented or performed using a general purpose processor, a digital signal processor (DSP), an ASIC, a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, a combination of one or more microprocessors and a DSP core, or any other such configuration.

[0414] The methods, sequences, and / or algorithms described in conjunction with the various aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software module may reside in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An example storage medium is coupled to the processor so that the processor can read information from and write information to the storage medium. In an alternative embodiment, the storage medium may be integrated into the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user terminal (e.g., a UE). In an alternative embodiment, the processor and storage medium may reside in the user terminal as discrete components.

[0415] In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on or transmitted via a computer-readable medium. Computer-readable media include both computer storage media and communication media, including any medium that facilitates the transfer of computer programs from one location to another. Storage media may be any available medium that can be accessed by a computer. By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. In addition, any connection is appropriately referred to as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies (such as infrared, radio, and microwaves), the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies (such as infrared, radio, and microwaves) are included in the definition of medium. As used herein, disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc. Disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0416] Although the foregoing disclosure shows illustrative aspects of the present disclosure, it should be noted that various changes and modifications may be made herein without departing from the scope of the present disclosure as defined by the appended claims. For example, the functions, steps, and / or actions of the method claims according to aspects of the present disclosure described herein do not need to be performed in any particular order. Furthermore, unless explicitly described as such, components, functions, actions, or instructions described or claimed herein should not be construed as critical or essential. Furthermore, as used herein, the terms “set,” “group,” and the like are intended to include one or more of the elements. Furthermore, as used herein, the terms “has,” “have,” “having,” “comprises,” “comprising,” “includes,” “including,” and the like do not exclude the presence of one or more additional elements (e.g., an element “having” A may also have B). Furthermore, the phrase “based on” is intended to mean “based at least in part on.” unless expressly stated otherwise. Furthermore, as used herein, the term “or” is intended to be inclusive when used in series and can be used interchangeably with “and / or” unless expressly stated otherwise (e.g., if used in combination with “any one” or “only one of”) or the alternatives are mutually exclusive (e.g., “one or more” should not be interpreted as “one and more”). Furthermore, although components, functions, acts, and instructions may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated. Thus, as used herein, the articles “a,” “an,” “an,” and “the” are intended to be inclusive when used in series and can be used interchangeably with “and / or” unless expressly stated otherwise (e.g., if used in combination with “any one” or “only one of”). "The" and "said" are intended to include one or more of the elements described. Additionally, as used herein, the terms "at least one" and "one or more" encompass "one" component, function, action, or instruction that performs or is capable of performing the function described or claimed, and in combination also encompass "two or more" components, functions, actions, or instructions that perform or are capable of performing the function described or claimed.

Claims

1. A method of communication performed by a location server, comprising: sending a request for analysis of RAN data associated with a positioning session between the location server and a user equipment (UE) to a radio access network (RAN) controller entity, the request including at least an identifier of the positioning session; receiving a response to the request for the RAN data analysis from the RAN controller entity, the response including the RAN data analysis; as well as A positioning procedure is performed with the UE to determine a location of the UE based at least in part on the RAN data analysis.

2. The method according to claim 1, wherein: sending said request for said RAN data analysis via a Y1 interface between said location server and said RAN controller entity, and A response to the request for the RAN data analysis is received via the Y1 interface.

3. The method according to claim 1, wherein The RAN controller entity includes a near real-time RAN intelligent controller (RIC).

4. The method according to claim 1, wherein The positioning session includes a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

5. The method according to claim 1, wherein The identifier of the positioning session comprises an LPP session identifier.

6. The method according to claim 1, wherein The RAN data analysis includes: the positioning method to be used for the positioning procedure, a pattern for one or more Positioning Reference Signal (PRS) resources to be sent and measured during said positioning procedure, a muting pattern for the one or more PRS resources, the identification of one or more Positioning Reference Units (PRUs) that may be used in the positioning procedure, The trajectory of the UE, an inference model for determining the location of the UE, The type of network nodes deployed near the UE, or any combination thereof.

7. The method according to claim 6, wherein: The positioning method to be used for the positioning procedure is determined based on: the positioning capability of the UE, the requested accuracy of the location of the UE, response time to the positioning procedure, The UE's environmental scenario, or any combination thereof.

8. The method according to claim 7, wherein: The environmental scenario is based on a probability that the UE is in a line-of-sight (LOS) scenario or a non-line-of-sight (NLOS) scenario with respect to one or more radio units (RUs) available for the positioning procedure.

9. The method according to claim 7, further comprising: receiving the positioning capability of the UE from the UE; as well as Sending the positioning capability of the UE to the RAN controller entity.

10. The method according to claim 6, wherein: The trajectory of the UE is based on a known topology of a route the UE is traveling.

11. The method according to claim 10, wherein: The route includes train tracks.

12. The method according to claim 6, further comprising: receiving positioning measurement results of the one or more PRS resources from the UE via Long Term Evolution (LTE) Positioning Protocol (LPP) signaling; or The positioning measurement results of the one or more PRS resources are received from the RAN controller entity via New Radio Positioning Protocol Type A (NRPPa) signaling.

13. The method according to claim 6, wherein: The request for the RAN data analysis also includes positioning measurements of the one or more PRS resources received from the UE.

14. The method according to claim 6, wherein The one or more PRS resources include: one or more downlink PRS resources, one or more uplink PRS resources, One or more sidelink PRS resources, or any combination thereof.

15. The method according to claim 1, wherein Messages exchanged between the location server and the UE during the positioning session are not exchanged via the RAN controller entity.

16. The method according to claim 1, wherein Messages exchanged between the location server and the UE during the positioning session are exchanged via the RAN controller entity.

17. The method according to claim 1, wherein The positioning session between the location server and the UE is established via the RAN controller entity.

18. A method of communication performed by a Radio Access Network (RAN) controller entity, comprising: receiving, from a location server, a request for analysis of RAN data associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request including at least an identifier of the positioning session; as well as A response to the request for the RAN data analysis is sent to the location server, the response including the RAN data analysis.

19. The method according to claim 18, wherein: receiving said request for said RAN data analysis via a Y1 interface between said location server and said RAN controller entity, and A response to the request for the RAN data analysis is sent via the Y1 interface.

20. The method according to claim 18, wherein The RAN controller entity includes a near real-time RAN intelligent controller (RIC).

21. The method according to claim 18, wherein The positioning session includes a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

22. The method according to claim 18, wherein The identifier of the positioning session comprises an LPP session identifier.

23. The method of claim 18, further comprising: A RAN-specific identifier for the positioning session is generated based on the identifier of the positioning session.

24. The method according to claim 18, wherein The RAN data analysis includes: the positioning method to be used for the positioning session, a pattern for one or more Positioning Reference Signal (PRS) resources to be sent and measured during said positioning session, a muting pattern for the one or more PRS resources, the identities of one or more Positioning Reference Units (PRUs) that may be used for the positioning session, The trajectory of the UE, the type of network nodes deployed near the UE, an inference model for determining the location of the UE, The type of network nodes deployed near the UE, or any combination thereof.

25. The method according to claim 24, further comprising: The positioning method to be used for the positioning session is determined based on: the positioning capability of the UE, the requested accuracy of the location of the UE, the response time to the positioning session, The UE's environmental scenario, or any combination thereof.

26. The method according to claim 25, further comprising: receiving the positioning capability of the UE from the UE; or The positioning capabilities of the UE are received from the location server.

27. The method of claim 24, further comprising: receiving positioning measurement results of the one or more PRS resources from the UE via radio resource control (RRC) signaling; as well as The positioning measurement results of the one or more PRS resources are sent to the location server via New Radio Positioning Protocol Type A (NRPPa) signaling.

28. The method according to claim 24, wherein The request for the RAN data analysis also includes positioning measurement results of the one or more PRS resources obtained by the UE.

29. The method according to claim 18, wherein Messages exchanged between the location server and the UE during the positioning session are exchanged via the RAN controller entity.

30. The method of claim 18, wherein The positioning session between the location server and the UE is established via the RAN controller entity.

31. A location server comprising: one or more memories; one or more transceivers; as well as One or more processors communicatively coupled to the one or more memories and the one or more transceivers, the one or more processors individually or in combination configured to: sending, via the one or more transceivers, a request for RAN data analysis associated with a positioning session between the location server and a user equipment (UE) to a radio access network RAN ​​controller entity, the request comprising at least an identifier of the positioning session; receiving, from the RAN controller entity via the one or more transceivers, a response to the request for the RAN data analysis, the response comprising the RAN data analysis; as well as A positioning procedure is performed with the UE to determine a location of the UE based at least in part on the RAN data analysis.

32. The location server of claim 31 , wherein: sending said request for said RAN data analysis via a Y1 interface between said location server and said RAN controller entity, and The response to the request for the RAN data analysis is received via the Y1 interface.

33. The location server according to claim 31, wherein: The RAN controller entity includes a near real-time RAN intelligent controller (RIC).

34. The location server of claim 31, wherein: The positioning session includes a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

35. The location server of claim 31, wherein: The identifier of the positioning session comprises an LPP session identifier.

36. The location server of claim 31, wherein: The RAN data analysis includes: the positioning method to be used for the positioning procedure, a pattern for one or more Positioning Reference Signal (PRS) resources to be sent and measured during said positioning procedure, a muting pattern for the one or more PRS resources, the identification of one or more Positioning Reference Units (PRUs) that may be used in the positioning procedure, The trajectory of the UE, an inference model for determining the location of the UE, The type of network node deployed near the UE, or any combination thereof.

37. The location server according to claim 36, wherein: The positioning method to be used for the positioning procedure is determined based on: the positioning capability of the UE, the requested accuracy of the location of the UE, response time to the positioning procedure, The UE's environmental scenario, or any combination thereof.

38. The location server according to claim 37, wherein: The environmental scenario is based on a probability that the UE is in a line-of-sight (LOS) scenario or a non-line-of-sight (NLOS) scenario with respect to one or more radio units (RUs) available for the positioning procedure.

39. The location server of claim 37, wherein: The one or more processors, individually or in combination, are further configured to: receiving the positioning capabilities of the UE from the UE via the one or more transceivers; and The positioning capabilities of the UE are sent to the RAN controller entity via the one or more transceivers.

40. The location server of claim 36, wherein: The trajectory of the UE is based on a known topology of a route the UE is traveling.

41. The location server according to claim 40, wherein: The route includes train tracks.

42. The location server of claim 36, wherein: The one or more processors, individually or in combination, are further configured to: receiving, via the one or more transceivers, positioning measurement results of the one or more PRS resources from the UE via Long Term Evolution (LTE) Positioning Protocol (LPP) signaling; or The positioning measurements of the one or more PRS resources are received from the RAN controller entity via New Radio Positioning Protocol Type A (NRPPa) signaling via the one or more transceivers.

43. The location server of claim 36, wherein: The request for the RAN data analysis also includes positioning measurements of the one or more PRS resources received from the UE.

44. The location server of claim 36, wherein: The one or more PRS resources include: one or more downlink PRS resources, one or more uplink PRS resources, One or more sidelink PRS resources, or any combination thereof.

45. The location server of claim 31 , wherein: Messages exchanged between the location server and the UE during the positioning session are not exchanged via the RAN controller entity.

46. ​​The location server of claim 31, wherein: Messages exchanged between the location server and the UE during the positioning session are exchanged via the RAN controller entity.

47. The location server of claim 31, wherein: The positioning session between the location server and the UE is established via the RAN controller entity.

48. A Radio Access Network (RAN) controller entity comprising: one or more memories; one or more transceivers; as well as One or more processors communicatively coupled to the one or more memories and the one or more transceivers, the one or more processors individually or in combination configured to: receiving, from a location server via the one or more transceivers, a request for analysis of RAN data associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request including at least an identifier of the positioning session; as well as A response to the request for the RAN data analysis is sent to the location server via the one or more transceivers, the response including the RAN data analysis.

49. The RAN controller entity according to claim 48, wherein: receiving said request for said RAN data analysis via a Y1 interface between said location server and said RAN controller entity, and The response to the request for the RAN data analysis is sent via the Y1 interface.

50. The RAN controller entity according to claim 48, wherein The RAN controller entity includes a near real-time RAN intelligent controller (RIC).

51. The RAN controller entity according to claim 48, wherein The positioning session includes a Long Term Evolution (LTE) Positioning Protocol (LPP) positioning session.

52. The RAN controller entity according to claim 48, wherein The identifier of the positioning session comprises an LPP session identifier.

53. The RAN controller entity according to claim 48, wherein The one or more processors, individually or in combination, are further configured to: A RAN-specific identifier for the positioning session is generated based on the identifier of the positioning session.

54. The RAN controller entity according to claim 48, wherein The RAN data analysis includes: the positioning method to be used for the positioning session, a pattern for one or more Positioning Reference Signal (PRS) resources to be sent and measured during said positioning session, a muting pattern for the one or more PRS resources, the identities of one or more Positioning Reference Units (PRUs) that may be used for the positioning session, The trajectory of the UE, the type of network nodes deployed near the UE, an inference model for determining the location of the UE, The type of network nodes deployed near the UE, or any combination thereof.

55. The RAN controller entity according to claim 54, wherein The one or more processors, individually or in combination, are further configured to: The positioning method to be used for the positioning session is determined based on: the positioning capability of the UE, the requested accuracy of the location of the UE, the response time to the positioning session, The UE's environmental scenario, or any combination thereof.

56. The RAN controller entity according to claim 55, wherein: The one or more processors, individually or in combination, are further configured to: receiving the positioning capabilities of the UE from the UE via the one or more transceivers; or The positioning capabilities of the UE are received from the location server via the one or more transceivers.

57. The RAN controller entity according to claim 54, wherein The one or more processors, individually or in combination, are further configured to: receiving, via the one or more transceivers, positioning measurements of the one or more PRS resources from the UE via radio resource control (RRC) signaling; and The positioning measurements of the one or more PRS resources are sent to the location server via New Radio Positioning Protocol Type A (NRPPa) signaling via the one or more transceivers.

58. The RAN controller entity according to claim 54, wherein The request for the RAN data analysis also includes positioning measurement results obtained by the UE for the one or more PRS resources.

59. The RAN controller entity according to claim 48, wherein Messages exchanged between the location server and the UE during the positioning session are exchanged via the RAN controller entity.

60. The RAN controller entity according to claim 48, wherein The positioning session between the location server and the UE is established via the RAN controller entity.

61. A location server comprising: means for sending a request for analysis of RAN data associated with a positioning session between said location server and a user equipment (UE) to a Radio Access Network (RAN) controller entity, said request comprising at least an identifier of said positioning session; means for receiving a response to said request for said RAN data analysis from said RAN controller entity, said response comprising said RAN data analysis; as well as Means for performing a positioning procedure with the UE to determine a location of the UE based at least in part on the RAN data analysis.

62. A Radio Access Network (RAN) controller entity comprising: means for receiving, from a location server, a request for analysis of RAN data associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request comprising at least an identifier of the positioning session; as well as means for sending a response to the request for the RAN data analysis to the location server, the response comprising the RAN data analysis.

63. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a location server, cause the location server to: sending a request for analysis of RAN data associated with a positioning session between the location server and a user equipment (UE) to a radio access network (RAN) controller entity, the request including at least an identifier of the positioning session; receiving a response to the request for the RAN data analysis from the RAN controller entity, the response including the RAN data analysis; as well as A positioning procedure is performed with the UE to determine a location of the UE based at least in part on the RAN data analysis.

64. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a Radio Access Network (RAN) controller entity, cause the RAN controller entity to: receiving, from a location server, a request for analysis of RAN data associated with a positioning session between the location server and a user equipment (UE) to determine a location of the UE, the request including at least an identifier of the positioning session; and A response to the request for the RAN data analysis is sent to the location server, the response including the RAN data analysis.

Images