Adaptive On-Demand Positioning

Abstract

Novel, adaptive on-demand positioning is needed. [Solution] A WTRU may be configured to perform adaptive on-demand positioning. The WTRU may receive configuration information for receiving positioning signals (PRS) from a first set of one or more TRPs. The configuration information may include PRS configuration information associated with each of the first set of TRPs. The WTRU may determine metrics (e.g., weight, rank, etc.) associated with TRPs that are not included in the first set of one or more TRPs. For example, the metrics may be determined based on a location associated with the TRP, a location associated with the WTRU, and / or a measurement associated with the TRP. The WTRU may send a PRS activation request to activate the PRS from the TRP. For example, a PRS activation request may indicate a PRS configuration that the WTRU requests to be activated, and metrics associated with that PRS configuration.

Description

Technical Field

[0004] , , ,

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 308,295, filed on February 9, 2022, U.S. Provisional Patent Application No. 63 / 334,729, filed on April 26, 2022, and U.S. Provisional Patent Application No. 63 / 409,967, filed on September 26, 2022, the entire disclosures of which are hereby incorporated by reference herein.

Background Art

[0002] Certain downlink (DL) and uplink (UL) positioning methods are used in certain wired / wireless communication protocols.

[0003] As described herein, the DL positioning method can refer to any positioning method that uses a DL reference signal such as a primary synchronization signal (PRS). A WTRU can receive, for example, one or more reference signals from one or more transmission points (TPs) and measure a DL reference signal time difference (RSTD) and / or a reference signal received power (RSRP). Exemplary DL positioning methods can include DL angle of departure (DL - AoD) positioning and / or DL time difference of arrival (DL - TDOA) positioning.<0​​​​​A wireless transmit / receive unit (WTRU) may be configured to perform adaptive on-demand positioning (for example, by transmitting an adaptive positioning reference signal (PRS) activation request). The WTRU may receive configuration information indicating that it is configured to receive positioning reference signals (PRS) from a first set of one or more transmit-reception points (TRPs). For example, the configuration information may include positioning reference signal (PRS) configuration information associated with the first set of TRPs (e.g., each of the TRPs in the first set of TRPs). The WTRU may determine a metric (e.g., weight, rank, etc.) associated with a transmit-reception point (TRP) that is not included in the first set of one or more TRPs. For example, the metric may be determined based on one or more of the following: a location associated with the TRP, a location associated with the WTRU, and / or a measurement associated with the TRP. The WTRU may send a PRS activation request to activate the PRS from the TRPs. For example, a PRS activation request may indicate a PRS configuration (e.g., the TRP and / or respective PRS resources to be activated) that the WTRU requests to be activated. A PRS activation request may include a determined metric associated with the TRP / PRS configuration. In response to a PRS activation request, the WTRU may receive a message indicating that it will receive PRS from the TRP. For example, a message indicating that a WTRU has received a PRS from a TRP may include PRS configuration information associated with the TRP.

[0005] In certain scenarios, metrics associated with TRPs may include weights. A WTRU may determine the respective weights for each TRP in a second set of one or more TRPs. A WTRU may not be configured to receive PRSs from each TRP in a second set of one or more TRPs. PRS activation requests sent by a WTRU may further include the respective weights determined for each TRP in a second set of one or more TRPs.

[0006] As described herein, a PRS activation request transmitted by a WTRU may include a location associated with the WTRU. A WTRU may receive PRS from a TRP in a first set of one or more TRPs. Based on the PRS received from the first set of one or more TRPs, a WTRU may determine a location associated with the WTRU (e.g., an estimated location of the WTRU). For example, a WTRU may determine its location using measurements performed on the received PRS (e.g., reference signal received power (RSRP) measurements, line of sight (LOS) measurements, non-line of sight (NLOS) measurements, distance measurements, timing measurements, and / or similar). The location of a WTRU may change over time. A WTRU may estimate its location at a given point in time based on the received PRS. A WTRU may transmit an indication of its location. For example, a WTRU may indicate its location as a difference value (e.g., to a determined location associated with the WTRU based on the PRS received from a first set of one or more TRPs).

[0007] A WTRU may use an artificial intelligence / machine learning (AI / ML) model to perform positioning and / or send a PRS activation request. For example, a WTRU may use an AI / ML model to determine the weights to be included in the PRS activation request. Alternatively, a WTRU may use an AI / ML model to determine its location (e.g., the estimated location of the WTRU). For example, measurements performed on the received PRS, the locations of each TRP receiving the PRS, and / or the WTRU location may be input to the AI / ML model. Based on the input, the AI / ML model may output the weights to be included in the PRS activation request. Alternatively, the AI / ML model may output the estimated location of the WTRU. [Brief explanation of the drawing]

[0008] [Figure 1A] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] Figure 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system of Figure 1A according to one embodiment. [Figure 1C] Figure 1C is a system diagram illustrating an exemplary radio access network (RAN) and core network (CN) that may be used in the communication system of Figure 1A according to one embodiment. [Figure 1D] Figure 1D is a system diagram illustrating further exemplary RAN and CN that may be used in the communication system of Figure 1A according to one embodiment. [Figure 2] Figure 2 shows an example associated with a neural network. [Figure 3]Figure 3 shows an example associated with a WTRU requesting the activation of a set PRS resource for a set of TRPs. [Figure 4] Figure 4 shows an exemplary hierarchical structure associated with the PRS configuration. [Figure 5] Figure 5 shows an example of the measured values ​​and their relationship to TRP. [Figure 6] Figure 6 shows an example associated with a WTRU configured to request PRS resources. [Figure 7A] Figure 7A shows an example associated with weight determination that can be used for positioning. [Figure 7B] Figure 7B shows an example associated with weight determination that may be used for positioning. [Figure 7C] Figure 7C shows an example associated with weight determination that may be used for positioning. [Figure 8A] Figure 8A shows an example associated with a threshold for activating TRP. [Figure 8B] Figure 8B shows an example of a PRS configuration associated with an activated TRP. [Figure 8C] Figure 8C shows an example associated with an activation request for TRP. [Modes for carrying out the invention]

[0009] Figure 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, message transmission, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block filtering OFDM, and filter bank multicarrier (FBMC).

[0010] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, 102d, any of which may be referred to as “station” and / or “STA (station)”, may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed subscriber units or mobile subscriber units, subscriber-based units, radio paging, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in industrial and / or automated processing chain contexts), consumer electronics devices, devices operating on commercial radio networks and / or industrial radio networks, etc. WTRU102a, 102b, 102c, and 102d can all be referred to as WTRU for compatibility purposes.

[0011] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be a base transceiver station (BTS), node B, enode B, home node B, home enode B, gNB, NR node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are illustrated as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0012] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), and relay nodes. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectra, unlicensed spectra, or a combination of licensed and unlicensed spectra. Cells may provide coverage of radio services to a particular geographic area, which may be relatively fixed or change over time. Cells may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and utilize multiple transceivers per sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0013] Base stations 114a and 114b may communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, which may be any suitable radio communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0014] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a within RAN104 / 113, and the WTRUs 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interfaces 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

[0015] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0016] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as NR radio access, which may establish the air interface 116 using New Radio (NR).

[0017] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of base stations (e.g., eNBs and gNBs) and / or multiple types of radio access technologies transmitted to and / or from such base stations.

[0018] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), IS-95, IS-856, Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0019] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home e-node B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in localized areas such as offices, homes, vehicles, campuses, industrial facilities, aerial walkways (e.g., for use by drones), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d may establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

[0020] RAN104 / 113 may communicate with CN106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or implement high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs using the same RAT as RAN104 / 113 or different RATs. For example, in addition to being connected to RAN104 / 113 which may utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0021] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, which use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the Internet protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN104 / 113 or a different RAT.

[0022] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a which may employ cellular-based radio technology and base station 114b which may employ IEEE 802 radio technology.

[0023] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.

[0024] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which can be coupled to a transmit / receive element 122. Figure 1B illustrates the processor 118 and the transceiver 120 as separate components, but it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0025] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR signals, UV signals, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.

[0026] Although the transmit / receive element 122 is illustrated as a single element in Figure 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the air interface 116.

[0027] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0028] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input data from them. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in such memory. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in that memory.

[0029] The processor 118 may be configured to receive power from the power supply 134 and distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0030] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its own location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred positioning method while maintaining consistency with one embodiment.

[0031] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripheral device 138 may include one or more sensors, one or more of which may be a gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0032] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of a signal associated with a specific subframe for both UL (e.g., for transmission) and downlink (e.g., for reception) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference via hardware (e.g., chokes) or via signal processing via a processor (e.g., a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of a signal (e.g., associated with a specific subframe for either UL (e.g., for transmission) or downlink (e.g., for reception).

[0033] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 may employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.

[0034] RAN104 may include e-nodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of e-nodes B while maintaining consistency with one embodiment. Each of e-nodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, e-nodes B160a, 160b, and 160c may implement MIMO technology. Thus, e-node B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

[0035] Each of the e-nodes B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. As shown in Figure 1C, the e-nodes B160a, 160b, and 160c may communicate with each other via the X2 interface.

[0036] The CN106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the aforementioned elements is illustrated as part of CN106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0037] The MME162 can be connected to each of the e-nodes B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0038] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during e-node B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0039] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0040] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, and 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0041] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (e.g., temporarily or permanently).

[0042] In a typical embodiment, the other network 112 may be a WLAN.

[0043] A WLAN in Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with other types of wired / wireless networks that carry traffic entering and / or leaving the Distribution System (DS) or BSS. Traffic originating outside the BSS and destined for the STAs may reach and be delivered to the STAs via the APs. Traffic originating from the STAs for destinations outside the BSS may be sent to the APs to be delivered to their respective destinations. Traffic between STAs within the BSS may, for example, be sent via the APs; a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent (for example, directly) between a source STA and a destination STA using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as “ad hoc” communication mode.

[0044] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS, but may be used by an STA to establish a connection with the AP. In certain typical embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented. In the case of CSMA / CA, an STA, including the AP (e.g., all STAs), may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA may be backed off. A single STA (e.g., only one station) may transmit at any given time in a given BSS.

[0045] High-throughput (HT) STAs may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0046] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining multiple consecutive 20 MHz channels. 160 MHz channels can be formed by combining eight consecutive 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data can pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the operation described above for the 80+80 configuration may be reversed, and the combined data may be sent to Medium Access Control (MAC).

[0047] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, while 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices within a macro communication range area. MTC devices may have limited capabilities, including, for example, support for specific and / or limited bandwidths (e.g., support only for those bandwidths). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0048] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that supports the minimum bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, even if other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is operational due to an STA (supporting only the 1 MHz operating mode) transmitting to the AP, the entire available frequency band may be considered operational, even if a large portion of the frequency band remains idle and may be available.

[0049] In the United States, the available frequency band that can be used by 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0050] Figure 1D is a system diagram illustrating RAN113 and CN115 according to one embodiment. As described above, RAN113 may employ NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN113 may also communicate with CN115.

[0051] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 108b may use beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals to and from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, while the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0052] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable neurology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes of varying or expandable lengths (e.g., containing a varying number of OFDM symbols and / or sustaining an absolute time of varying length) or transmission time intervals (TTI).

[0053] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-node-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unauthorized bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, e-nodes B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0054] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0055] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although each of the aforementioned elements is illustrated as part of the CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0056] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c in RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may perform roles such as user authentication for WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and services for machine type communication (MTC) access. AMF162 may provide control plane functions for exchanging between RAN113 and other RANs (not shown) using other radio technologies such as LTE, LTE-A, LTE-A Pro and / or WiFi.

[0057] SMF183a and 183b may be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b may also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b may select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b may perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.

[0058] UPF184a, 184b may be connected via the N3 interface to one or more of gNB180a, 180b, 180c in RAN113, thereby providing WTRU102a, 102b, 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, 102c and IP-enabled devices. UPF184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multiple home PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0059] CN115 can facilitate communication with other networks. For example, CN115 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. In addition, CN115 may provide WTRU102a, 102b, 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to the local data network (DN) 185a, 185b via UPF184a, 184b through an N3 interface to UPF184a, 184b, and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0060] In view of Figures 1A to 1D and their corresponding descriptions, one or more of the functions described herein may be implemented by one or more emulation devices (not shown) with respect to one or more of the WTRU102a to d, base stations 114a and b, e-nodes-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to ab, UPF184a and b, SMF183a and b, DN185a and b, and / or any other devices described herein. An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0061] Emulation devices may be designed to perform one or more tests on other devices in a laboratory and / or carrier network environment. For example, one or more emulation devices may perform one or more or all of the functions while fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more or all of the functions while temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using terrestrial wireless communication.

[0062] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test scenario to perform testing of one or more components in a test laboratory and / or in an undeployed (e.g., test) wired and / or wireless communication network. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0063] As described herein, a DL positioning method may refer to any positioning method that uses a downlink reference signal, such as a positioning reference signal (PRS). A WTRU may receive one or more (e.g., multiple) reference signals from a transmitting point (TP) and measure a DL reference signal time difference (RSTD), reference signal received power (RSRP), line-of-sight (LOS) measurement, non-line-of-sight (NLOS) measurement, distance measurement (e.g., the distance between the WTRU and a given TRP), or timing measurement. Embodiments of a DL positioning method are DL-AoD or DL-TDOA positioning.

[0064] As described herein, a UL positioning method may refer to any positioning method that uses a UL reference signal, such as a sounding reference signal (SRS), for positioning. A WTRU may transmit an SRS to one or more reception points (RPs), which may be configured to measure the UL relative time of arrival (RTOA) and / or the UL reference signal received power (RSRP). Exemplary UL positioning methods may include UL time difference of arrival (UL-TDOA) positioning and / or UL angle of arrival (UL-AoA) positioning.

[0065] As described herein, a DL positioning method may refer to any positioning method that uses a DL reference signal, such as a positioning reference signal (PRS), for positioning. A WTRU may receive one or more reference signals from a transmit point (TP). A WTRU may measure the DL reference signal time difference (RSTD) and / or RSRP. Exemplary DL positioning methods may include DL-AoD and / or DL-TDOA positioning.

[0066] As described herein, DL and UL positioning methods may refer to arbitrary positioning methods that utilize both UL and DL reference signals for positioning. In embodiments, a WTRU may be configured to transmit SRS to one or more transmit-receive points (TRPs), and a network (e.g., one or more gNBs) may measure the reception-transmission (Rx-Tx) time difference. The network may measure, for example, the RSRP for the received SRS. The WTRU may be configured to measure the Rx-Tx time difference for one or more positioning reference signals (PRS) transmitted from one or more TRPs. The WTRU may also be configured to measure (e.g., RSRP, LOS, NLOS, timing, etc.) for the received PRS. The Rx-TX time difference and / or RSRP measured in the WTRU and / or network (e.g., gNBs) may be used to calculate one or more metrics (e.g., round-trip time). As described herein, the Rx-Tx time difference refers to the difference between the arrival time of the reference signal transmitted by the TRP and the transmission time of the reference signal transmitted from the WTRU. Exemplary DL and UL positioning methods may include multiple round-trip time (multi-RTT) positioning.

[0067] Artificial intelligence (AI) may be used in certain positioning techniques. As used herein, AI may refer to behaviors exhibited by machines that mimic cognitive functions to sense, reason, adapt, and / or act.

[0068] Machine learning (ML) can be used in certain positioning techniques. As used herein, ML may refer to a type of algorithm (e.g., data) that solves problems based on learning through experience (e.g., a set of rules) without being explicitly programmed. Machine learning can also, or alternatively, be considered a subset of AI. Different ML paradigms may be assumed based on the nature of the data or feedback available to the ML system. For example, supervised learning techniques may involve a machine learning system that learns a function that maps one or more inputs to one or more outputs. The mapping of inputs to outputs is obtained based on labeled training examples, each labeled training example may include an exemplary pair of input and corresponding output. For example, unsupervised learning may involve detecting patterns in a dataset that does not have existing labels. For example, reinforcement learning may involve performing a set of actions in an environment to maximize cumulative reward. In certain scenarios, machine learning algorithms may be implemented using combinations and / or interpolations of the above techniques. For example, a semi-supervised learning method may include combinations of labeled dates (e.g., a small amount of labeled data) and unlabeled data (e.g., a large amount of unlabeled data) during training. In this respect, semi-supervised learning can fall between unsupervised learning (e.g., no labeled training data to explain) and supervised learning (e.g., with labeled training data to explain).

[0069] A neural network can be used to implement specific positioning techniques. An example associated with a neural network 200 is shown in Figure 2. As shown in Figure 2, the neural network 200 can be trained by, for example, applying one or more inputs 201 and adjusting the associated weights (for example, shown as w and x in Figure 2) so that the output 202 from the neural network 200 approaches a desired target value associated with a given input value. In a particular scenario, the neural network may include multiple layers (for example, two layers). During training for a given input, the difference between the output and the desired value can be calculated. The difference between the output and the desired value can be used to update the weights in the neural network. For example, there may be a direct relationship between the difference between the output and the desired value and the weight adjustment. In a particular scenario, for example, if the difference between the output value and the desired value is large (e.g., greater than a threshold), a large change in the associated weights is expected. Similarly, if the difference between the output value and the desired value is small (e.g., less than a threshold), a small change in the associated weights is expected.

[0070] As described herein, neural networks may be used in certain positioning techniques. In positioning, for example, the input to the neural network may include reference signal parameters (e.g., RSRP measurements, WTRU location, TRP location, etc.), and the output from the neural network may include an estimated location (e.g., an estimated location of the WTRU). In certain scenarios, the desired values ​​may include location information (e.g., location information obtained by a Global Navigation Satellite System (GNSS)).

[0071] After training, the neural network can be used for positioning techniques, for example, by providing input to the neural network, and the output of the neural network may be the expected result for the associated input. For example, the output of the neural network may include the estimated position or location of the WTRU and / or weights associated with the PRS configuration (e.g., TRP and / or PRS resources from a given TRP). An example of the estimated position may be the WTRU's location at the approximate time when the WTRU made a measurement against the received PRS. The output of the neural network may also, or alternatively, include the predicted position or location of the WTRU. For example, the predicted position of the WTRU may be the WTRU's future location.

[0072] With regard to training a neural network for positioning and / or PRS activation requests (e.g., training a neural network to estimate the position or location of a WTRU), one or more of the following may be identified: the inputs to the neural network, the expected outputs associated with each input, and / or target values ​​to which the actual outputs from the neural network can be compared.

[0073] As described herein, a neural network may be characterized by one or more parameters, namely the number of weights and / or the number of layers within the neural network.

[0074] Deep learning (DL) can be used in certain positioning techniques. As used herein, DL can refer to specific machine learning algorithms that employ artificial neural networks (e.g., deep neural networks (DNNs) that are roughly inspired by biological systems). A DNN may include a class of machine learning models in which the input is transformed (e.g., a linear transformation) and passed to a specific function (e.g., a nonlinear activation function). For example, the transferred input may pass through the DNN's function multiple times. A DNN may also include multiple layers, each layer of which may include one or more transformation functions (e.g., a linear transformation function and a nonlinear activation function). A DNN may be trained using training data via a backpropagation algorithm, for example. DNNs have been used in a variety of applications, including, for example, speech, vision, and natural language. DNNs have also been used in a variety of machine learning settings, including, for example, supervised, unsupervised, and semi-supervised applications. As described herein, an AI component may refer to the realization of behavior and / or adaptation to requirements by learning based on data (e.g., without constructing a sequence or steps of actions). For example, an AI component may be used to learn complex behaviors that may be difficult to specify and / or perform using other methods.

[0075] As used herein, the term "network" may include Access and Mobility Management Function (AMF), Location Management Function (LMF), gNB, and / or Radio Access Network (RAN) (e.g., Next Generation RAN (NG-RAN)), AMF, LMF, gNB, or NG-RAN). Similarly, the following terms may be used interchangeably: Pre-configuration and configuration, "Non-serving gNB" and "Adjacent gNB", gNB and TRP, PRS and "PRS Resource", PRS and "PRS Resource" (e.g., PRS or PRS Resource may belong to different sets of PRS Resources), PRS and DL-PRS or DL ​​PRS, and / or "Measurement Gap" and "Measurement Gap Pattern". For example, Measurement Gap Pattern may include parameters such as Measurement Gap Duration, Measurement Gap Repetition Period, and / or Measurement Gap Periodicity.

[0076] Where described herein, preconfigurations and configurations may be used interchangeably. Where described herein, non-serving gNBs and neighboring gNBs may be used interchangeably. Where described herein, gNBs and TRPs may be used interchangeably. Where described herein, PRSs and PRS resources may be used interchangeably. Where described herein, PRSs and PRS resources may be used interchangeably. Where described herein, PRSs and PRS resources may belong to different sets of PRS resources. Where described herein, PRSs, DL-PRSs, and DL PRSs may be used interchangeably. Where described herein, measurement gaps and measurement gap patterns may be used interchangeably. For example, a measurement gap pattern may include one or more parameters such as measurement gap duration, measurement gap repetition period, and / or measurement gap periodicity.

[0077] A positioning reference unit (PRU) may include a WTRU or TRP whose location (e.g., altitude, latitude, geographic coordinates, or local coordinates) can be known by a network (e.g., gNB, LMF), as used herein. For example, the capabilities of a PRU may be similar to (e.g., identical to) a WTRU or TRP configured to receive a positioning reference signal (PRS), transmit a sounding reference signal (SRS) (e.g., SRS for positioning), and / or transmit a PRS. For example, a WTRU operating as a PRU may be used by a network for calibration purposes (e.g., to compensate for unknown timing offsets and / or unknown angular offsets). In another embodiment, a WTRU operating as a PRU may be configured to report measurements to a network.

[0078] As used herein, an LMF may include nodes or entities (e.g., network nodes or entities) that can be used for or to support positioning. Other nodes or entities may also be used and / or substituted for an LMF.

[0079] A WTRU may be configured to receive thresholds (e.g., pre-configured thresholds) from a network (e.g., LMF, gNB, etc.). A PRS configuration may be used to indicate (e.g., indicate to the WTRU) a TRP on which the WTRU is configured to receive PRS. For example, a PRS configuration may indicate the PRS resources associated with each of the TRPs on which the WTRU is configured to receive PRS. A particular PRS configuration (e.g., a TRP on which a given WTRU receives PRS) may be configured so that the network assumes it has certain information (e.g., the WTRU's location) that can be used to perform PRS and / or WTRU positioning. However, in certain scenarios (e.g., due to unexpected WTRU movement, unexpected obstacles, etc.), the network may not have knowledge of the WTRU's location. For example, if the network does not have knowledge of the WTRU's location, the PRS configuration may be determined using an iterative process, which may increase latency in positioning. For example, a WTRU may be configured to send one or more PRS activation requests to obtain a desired PRS configuration (e.g., an on-demand framework). In such an on-demand framework, the WTRU may also be configured to send PRS activation requests for a set of PRS configurations, which could further increase the number of iterations required to find the optimal PRS configuration. In WTRU-based positioning, for example, the network may not receive measurements from the WTRU, and the optimal PRS configuration may not be available on the network.

[0080] Adaptive PRS activation requests may be used to perform positioning. For example, a PRS request procedure (e.g., an adaptive on-demand PRS request procedure) may be employed. As described herein, PRS is used as an exemplary reference signal (RS) used for positioning requests (e.g., on-demand positioning requests). However, any DL RS or UL RS, including, for example, channel state information RS (CSI-RS), demodulation RS (DM-RS), phase tracking RS (PT-RS), tracking reference signal (TRS), SRS, and / or similar, may also be used, or alternatively, for positioning requests. PRS requests and PRS activation requests may be used interchangeably as described herein. As described herein, a PRS activation request may be WTRU-specific. For example, in certain scenarios, a PRS activation request sent by a given WTRU may turn on a PRS from a TRP that is not currently sending PRSs to other WTRUs, while in other cases, a PRS activation request sent by a given WTRU may turn on a PRS from a TRP that is currently sending PRSs to other WTRUs.

[0081] The WTRU may send a measurement gap (MG) request and / or a PRS processing window request based on one or more of the following: the PRS configuration (e.g., PRS duration) and / or whether a periodic / semi-persistent DL channel or RS is scheduled. The WTRU may determine the associated metric (e.g., weight, rank, etc.) for the request based on latency requirements.

[0082] A WTRU may decide to request that one or more PRS-enabled TRPS be turned on or off. For example, a WTRU may determine the metrics associated with the request (e.g., weight, rank, etc.) based on the LOS / NLOS indicator for the TRP.

[0083] A WTRU may be configured to perform adaptive on-demand positioning (for example, by sending an Adaptive Positioning Reference Signal (PRS) activation request). A WTRU may receive configuration information indicating that it is configured to receive positioning signals (PRS) from a first set of one or more transmit-receive points (TRPs). For example, the configuration information may include positioning reference signal (PRS) configuration information associated with the first set of TRPs (e.g., each of the TRPs in the first set of TRPs). A WTRU may determine metrics (e.g., weight, rank, etc.) associated with transmit-receive points (TRPs) that are not included in the first set of one or more TRPs. For example, the metrics may be determined based on one or more of the following: a location associated with the TRP, a location associated with the WTRU, and / or a measurement associated with the TRP. A WTRU may send a PRS activation request to activate the PRS from the TRPs. For example, a PRS activation request may indicate that the WTRU is requesting a PRS configuration (e.g., the TRPs and / or their respective PRS resources to be activated) to be activated. A PRS activation request may include determined metrics associated with the TRP / PRS configuration. In response to a PRS activation request, the WTRU may receive a message indicating that the WTRU will receive a PRS from the TRP. For example, a message indicating that the WTRU will receive a PRS from the TRP may include PRS configuration information associated with the TRP.

[0084] In certain scenarios, metrics associated with TRPs may include weights. A WTRU may determine the respective weights for each TRP in a second set of one or more TRPs. A WTRU may not be configured to receive PRSs from each TRP in a second set of one or more TRPs. PRS activation requests sent by a WTRU may further include the respective weights determined for each TRP in a second set of one or more TRPs.

[0085] As described herein, a PRS activation request transmitted by a WTRU may include a location associated with the WTRU. A WTRU may receive PRS from a TRP in a first set of one or more TRPs. Based on the PRS received from the first set of one or more TRPs, a WTRU may determine a location associated with the WTRU (e.g., an estimated location of the WTRU). For example, a WTRU may determine its location using measurements performed on the received PRS (e.g., reference signal received power (RSRP) measurements, line-of-sight (LOS) measurements, non-line-of-sight (NLOS) measurements, distance measurements, timing measurements, and / or similar). The location of a WTRU may change over time. A WTRU may estimate its location at a given point in time based on the received PRS. A WTRU may transmit an indication of its location. For example, a WTRU may indicate its location as a difference (e.g., to a determined location associated with the WTRU based on the PRS received from a first set of one or more TRPs).

[0086] A WTRU may use an artificial intelligence / machine learning (AI / ML) model to perform positioning and / or send a PRS activation request. For example, a WTRU may use an AI / ML model to determine the weights to be included in the PRS activation request. Alternatively, a WTRU may use an AI / ML model to determine its location (e.g., the estimated location of the WTRU). For example, measurements performed on the received PRS, the locations of each TRP receiving the PRS, and / or the WTRU location may be input to the AI / ML model. Based on the input, the AI / ML model may output the weights to be included in the PRS activation request. Alternatively, the AI / ML model may output the estimated location of the WTRU.

[0087] WTRU can be configured to perform adaptive on-demand positioning.

[0088] A WTRU may be configured to receive requests about itself (e.g., from the network) to return specific information associated with a positioning request (e.g., the desired / requested PRS configuration and associated weights for each PRS configuration) and a list of TRPs from which the WTRU can receive a PRS. In response to a request, the WTRU may be configured to transmit the requested information. Based on the information transmitted by the WTRU (e.g., information associated with the positioning request and / or the list of TRPs), the WTRU may be configured so that a PRS has one or more TRPs from which it should receive a PRS. The WTRU may perform measurements (e.g., RSRP, LOS, NLOS, timing, etc.) on the PRS received from candidate TRPs. The WTRU may identify one or more TRPs (e.g., candidate TRPs) from which the PRS is not received that are not part of one or more TRPs. If the average RSRP of the PRS received from one or more configured TRPs falls below a threshold, the WTRU may determine specific information (e.g., soft metrics) associated with each candidate TRP. For example, the information associated with each candidate TRP may be determined based on how close each candidate TRP is to the TRP with the highest RSRP. The estimated location of the WTRU may be determined, for example, based on measurements taken on PRS received from one or more configured TRPs.

[0089] Based on the information associated with each candidate TRP transmitted by the WTRU, the WTRU may be configured (e.g., by the network) so that the PRS has a new / updated set of TRPs that will be received by the WTRU. The WTRU may perform measurements (e.g., RSRP measurements) on the PRS received from the new / updated set of TRPs. The WTRU may perform certain calculations on the measurements performed on the PRS received from the new / updated set of TRPs. For example, if the average RSRP of the PRS received from the updated / new set of TRPs is greater than a threshold, the WTRU may decide to terminate the on-demand PRS procedure. Alternatively, the WTRU may decide to terminate the PRS activation request procedure if the number of iterations exceeds a threshold.

[0090] The WTRU may transmit a first PRS activation request. For example, the first PRS activation request may include instructions for one or more transmit-receive points (TRPs). In response to the first PRS activation request, the WTRU may receive configuration information (e.g., PRS configuration information). The PRS configuration information may include instructions for one or more TRPs (e.g., configured TRPs) to which the WTRU is configured to receive PRS. The WTRU may receive PRS from each of the one or more configured TRPs. The WTRU may perform a reference signal received power (RSRP) measurement on the PRS received from each of the one or more configured TRPs. Based on the measurements performed on the PRS received from each of the one or more configured TRPs, the WTRU may calculate a metric associated with the one or more configured TRPs. The WTRU may determine that the metric associated with the one or more configured TRPs falls below a threshold. For example, the threshold may be included in the PRS configuration information.

[0091] Based on the determination that one or more configured TRPs and associated metrics fall below a threshold, the WTRU may identify one or more candidate TRPs. For example, one or more candidate TRPs may include TRPs closest to the configured TRP associated with the highest RSRP measurement. The WTRU may determine / identify other TRPs close to the configured TRP associated with the highest RSRP measurement by determining, estimating, or otherwise confirming which TRP the WTRU considers to be the closest to the configured TRP associated with the highest RSRP measurement. The WTRU may send a second PRS activation request that includes instructions for one or more candidate TRPs identified by the WTRU. The WTRU may estimate a location associated with the WTRU. For example, a location associated with the WTRU may be estimated based on measurements taken for PRS received from each of the one or more configured TRPs. The WTRU may include the estimated location associated with the WTRU in the second PRS activation request.

[0092] In response to a second PRS activation request, the WTRU may receive updated PRS configuration information. For example, the updated PRS configuration information may include instructions for one or more updated TRPs in which the WTRU is configured to receive PRS. The WTRU may receive PRS from one or more (or each of) of the updated TRPs. The WTRU may perform RSRP measurements on the PRS received from each of the updated TRPs. Based on the measurements performed on the updated TRPs that received PRS, the WTRU may calculate a metric associated with the updated TRP. The WTRU may determine that the metric associated with the updated TRP is above a threshold. Based on the determination that the metric associated with the updated TRP is above a threshold, the WTRU may send an on-demand PRS termination request.

[0093] A WTRU may send a request to activate PRS configuration information (e.g., TRP, PRS resources, PRS resource groups, etc.) based on conditions. The WTRU may receive the requested PRS configuration and associated PRS configuration (e.g., PRS transmission periodicity), which may be considered an acknowledgment of the request to activate the PRS configuration.

[0094] A WTRU may be configured to send requests to change and / or update one or more parameters associated with the PRS (e.g., the TRP from which the WTRU receives the PRS). Such requests to change and / or update one or more parameters associated with the PRS may be referred to herein as PRS requests. For example, a WTRU may be configured to send PRS requests to a network (e.g., LMF, gNB) to change / update the WTRU's PRS configuration (e.g., to a requested value). A WTRU may be configured to send PRS requests to change / update the value of at least one of the following PRS configuration parameters: Number of symbols, transmit power, number of PRS resources included in the PRS resource set, muting pattern for PRS (e.g., muting pattern may be represented as a bitmap), periodicity, type of PRS (e.g., periodic, semi-permanent, and / or aperiodic), slot offset for periodic transmission for PRS, vertical shift of PRS pattern in the frequency domain, time gap during iteration, iteration coefficient, resource element (RE) offset, comb pattern, comb size, spatial relationship or quasi-colocation (QCL) information for PRS (e.g., QCL target, QCL source, etc.), number of positioning reference units (PRUs), number of TRPs, absolute radio-frequency channel number (ARFCN), subcarrier spacing, expected reference signal time difference (RSTD) (e.g., including uncertainty in expected RSTD), start PRB, bandwidth (e.g., bandwidth part (BWP), number of resource elements, number of resource blocks, bandwidth expressed in Hz, etc.), BWP ID, number of frequency layers, start / end times for PRS transmission, PRS on / off indicator, TRP ID, PRS ID, cell ID, global cell ID, and / or PRU ID. When described herein, this request may be referred to as a PRS activation request.

[0095] The WTRU may also, or alternatively, be configured to send a PRS request to the network when / when the requested PRS configuration is activated. For example, the WTRU may be configured to send a PRS request to the network to activate the requested TRP or PRS resource at a defined start time with respect to a frame, slot, symbol number, etc., an absolute start time, and / or a start time with respect to a reference time (e.g., N slots from the time the request was sent by the WTRU or received by the network).

[0096] A WTRU may be configured to send a PRS request to deactivate a specific PRS parameter. For example, a WTRU may be configured to send a PRS request to the network to deactivate a specific resource (e.g., a requested TRP or PRS resource). A WTRU may be configured to send a PRS request to deactivate a resource at an end time (e.g., a defined) frame, slot, symbol number, etc., an end time (e.g., an absolute time), and / or an end time (e.g., N slots from the time the request was sent by the WTRU and / or received by the network) relative to a reference time.

[0097] For example, to activate and / or deactivate specific PRS parameters, PRS requests may be transmitted via, for example, LTE positioning protocol (LPP) messages, UL MAC control element (UL-MAC-CE), UL downlink control information (UL-DCI), and / or RRC messages.

[0098] A WTRU may be configured to have PRS parameters (e.g., PRS ID, iteration coefficient, etc.) that the WTRU can modify / update (e.g., pre-configured by the network). As described herein, a WTRU may be configured by the network by receiving configuration information from the network. For example, a WTRU may be pre-configured to have a range or set of values ​​for each PRS parameter that the WTRU can modify / update. In an example, if a WTRU is configured to have the ability to modify / update a periodicity parameter for a PRS, the WTRU may be pre-configured (e.g., by the network) to have a set of periodicity values ​​that can be set by the WTRU (e.g., pre-configured to have three (3) periodicity values ​​[5ms, 10ms, 20ms]). Each value in the set may further be associated with an ID. And when the WTRU sends a request to the network to modify / update the relevant PRS parameter, the request sent by the WTRU may include the ID and / or name of the PRS parameter, thereby reducing the size of the request. A WTRU may be configured to receive preconfiguration from the network, for example, via LPP and / or RRC messages. If a WTRU is not preconfigured to have a range or set of values, it may be configured to request preconfiguration from the network.

[0099] A WTRU may also, or alternatively, be configured to have an authorized set of PRS configurations. For example, a WTRU may be pre-configured by the network to have one or more authorized PRS configuration sets. Each authorized PRS configuration set may include one or more PRS parameters and their respective values / value ranges. Each authorized PRS configuration set may also, or alternatively, be associated with a logical identifier, and a WTRU may be configured to request a desired PRS configuration by including the logical identifier of the desired PRS configuration within an authorized and pre-configured set.

[0100] A WTRU may be configured to have one or more default configuration sets and / or one or more specific configuration sets. For example, a WTRU may be configured to indicate a desired PRS configuration by including a logical identifier for a default configuration from a default configuration set. A WTRY may also, or alternatively, be configured to indicate a desired PRS configuration by including a logical identifier for a specific configuration from a specific configuration set. For example, a desired PRS configuration may be determined based on a combination of a default configuration and a specific configuration, and PRS parameter values ​​from the specific configuration may override parameter values ​​from the default configuration.

[0101] As described herein, a WTRU may be configured to determine and / or adjust the metrics (e.g., weights, ranks, etc.) used for positioning. For example, a WTRU may be configured to receive instructions from a network (e.g., LMF, gNB) to associate specific weights with specific PRS parameters. A WTRU may be configured to receive configurations from a network (e.g., via configuration information). Configuration information may include the number of weights that the WTRU should include in the request. For example, a WTRU may be pre-configured to have several periodic values ​​(e.g., five (5) periodic values: [1ms, 5ms, 10ms, 20ms, 50ms]). The WTRU may receive configurations from a network and return weights for some periodic values ​​(e.g., three periodic values) in the request. Based on the configuration, the WTRU may be configured to decide to associate weights with 1ms, 5ms, and 10ms, and the associated weights determined by the WTRU may be 0.1, 0.5, and 0.4 for 1ms, 5ms, and 10ms, respectively. The WTRU may determine weights based on measurements taken on PRS received at different periodicities. For example, the WTRU may be configured to have PRS transmitted from the TRP at a periodicity of 1 ms. Based on the measurements, the WTRU may determine that the average value of the RSRP is greater than a pre-configured threshold. In that case, the WTRU may decide to request PRS at a longer periodicity so that the number of measurement opportunities can be reduced in order to prioritize the reception of data or control channels. Thus, the WTRU may decide to assign weights to periodicities greater than 1 ms but within the range of the number of parameters that the WTRU may request (e.g., 3). Due to uncertainty in the request, the WTRU may assign approximately equal weights to periodicities of 5 ms and 10 ms. For example, since 5 ms is closer in periodicity to the currently configured 1 ms periodicity, the WTRU may assign a greater weight to 5 ms.

[0102] A WTRU may be configured to receive specific thresholds for determining each weight. For example, a WTRU may be configured to receive a threshold from the network indicating the minimum value of the associated weight. For instance, if the value of a given weight is greater than or equal to the received threshold, the WTRU may decide to include the weight in the request. Similarly, if a given TRP (e.g., TRP0) has an associated weight of 0.1 and the minimum weight threshold pre-configured by the network is 0.3, the WTRU may not need to request the network to activate TRP0.

[0103] Figures 3 to 7C show examples associated with the PRS activation request technique. Figure 3 shows example 300 associated with a WTRU requesting a set of PRS resources for a set of TRPs. Figure 4 shows an exemplary hierarchical structure 400 associated with the PRS configuration. Figure 5 shows example 500 associated with measurements and TRPs. Figure 6 shows example 600 associated with a WTRU configured to request PRS resources. Figures 7A to 7C show examples 700, 710, and 710, respectively, associated with weight determination.

[0104] Referring to the embodiment shown in Figure 3, WTRU304 may be configured to receive PRS from TRP301, 302, and 303 (for example, via PRS configuration information). For example, WTRU304 may be configured to receive PRS from TRP301 on PRS resources 1, 2, and 3, receive PRS from TRP302 on PRS resources 1, 2, and 3, and receive PRS from TRP303 on PRS resources 1, 2, and 3. WTRU may be configured to request changes or updates to PRS it has received by, for example, sending a PRS request. A PRS request may indicate a PRS resource that WTRU304 requests to receive a PRS from. A PRS request may include one or more PRS configurations. Each PRS configuration may be associated with a weight. For example, as shown in Figure 3, WTRU304 may send a PRS request including one or the requested PRS configurations. For example, as shown in Figure 3, the first PRS configuration 305 may request that PRS be received from TRP 301 on PRS resource 2, from TRP 302 on PRS resource 2, and from TRP 303 on PRS resource 2. As shown in the embodiment illustrated in Figure 3, a PRS request transmitted by WTRU 304 may include a second PRS configuration 306 that requests that PRS be received from TRP 301 on PRS resource 2, from TRP 302 on PRS resource 1, and from TRP 303 on PRS resource 2. As described herein, each PRS configuration may be associated with a weight. As shown in Figure 3, for example, the first PRS configuration 305 may be associated with a weight of 0.8, and the second PRS configuration 306 may be associated with a weight of 0.2. The weights assigned to PRS configurations 305, 306, and / or PRS configurations can be determined using an AI / ML model (e.g., AI / ML model 200 shown in Figure 2). For example, as described herein, one or more measurements associated with each of the TRP / PRS resources (e.g., RSRP, LOS, NLOS, timing, etc.) may be input into the AI / ML model. Alternatively, the locations associated with TRPs 301, 302, 303, and / or the estimated locations of WTRU 304 may be input into the AI / ML model.Based on the input, the AI / ML model may output the PRS configuration and / or associated weights. As described herein, the WTRU304 may use the received PRS to perform positioning. For example, the WTRU may provide the measurements performed on the PRS, the location associated with the TRP that receives the TRP, and / or the WTRU's location (e.g., previous location) as input to the AI / ML model, and the AI / ML model may output the estimated location of the WTRU.

[0105] Figure 3 shows an example in which WTRU304 sends a PRS activation request to activate a PRS from a TRP / PRS resource that is already configured to receive PRSs. However, it should be understood that WTRU304 may also send PRS activation requests to TRP / PRS resources that are not yet configured. For example, based on measurements and / or AI / ML model outputs performed by WTRU304, WTRU304 may send a PRS activation request to activate a PRS from a TRP other than TRP301, TRP302, or TRP303.

[0106] A WTRU may be configured to receive instructions to initiate a weight request process, for example, via LPP and / or RRC messages. For example, one or more of the following may apply to weights associated with a particular PRS parameter: the weights associated with the request may sum to a given value (e.g., 1); each weight associated with the request may be greater than 0 and less than or equal to 1; and / or each weight may be either 0 or 1.

[0107] A WTRU may be configured to initiate a positioning request (e.g., an on-demand positioning request). For example, a WTRU may be configured to send a request (e.g., to a network) to initiate a positioning request procedure. In response, the network may return specific parameters to initiate the positioning request procedure (e.g., the parameters the WTRU may request, the number of parameters the WTRU may request, whether the WTRU returns weights associated with the parameters, the number of iterations, etc.).

[0108] Alternatively, the WTRU may be configured to indicate to the network that the WTRU is initiating an on-demand request procedure. For example, the WTRU may be configured to send instructions to the network after it has received the parameters described above to initiate the procedure.

[0109] A WTRU may be configured to determine whether and when it should send a request to initiate an on-demand positioning request. For example, a WTRU may decide to send a request to initiate an on-demand positioning request based on one or more of the following: Average Reference Signal Received Power (RSRP) (e.g., the average RSRP of received PRS that are below a threshold); the number of requests the WTRU has sent to the network (e.g., above or below a threshold); the variation of a specific measurement (e.g., RSRP, ToA, RSTD, angle of arrival (AoA), angle of departure (AoD) is greater than a threshold); the maximum value of a weight associated with a PRS parameter is below a threshold (e.g., a pre-configured threshold); the WTRU receives a trigger from the network (e.g., via DCI) to send a positioning request (e.g., on-demand) including weights associated with each PRS configuration; and / or the WTRU receives a command or signal from the network (e.g., via MAC-CE) (e.g., configured to trigger a PRS request procedure).

[0110] WTRU may be configured to determine the set of PRS parameters that should be included in the PRS request. Based on conditions (e.g., whether the measurements needed to derive the weights are available), WTRU may determine a set of candidate parameters for the request. For example, WTRU may decide to request parameters not included in the preconfiguration (e.g., a preconfigured set of TRPs, a configured set of PRSs from which to take measurements, etc.).

[0111] In certain scenarios, the WTRU may be configured to determine the set of TRPs that receive PRS. For example, the WTRU may be configured to determine the set of TRPs that receive PRS by comparing a pre-configured set of parameters with training data. The set of TRPs that receive PRS may, for example, be included in the pre-configured PRS parameters and / or not included in the set of TRPs that have already received measurements.

[0112] In certain scenarios, a WTRU may be configured to send a PRS request that includes weights for specific parameters (e.g., parameters that the WTRU is pre-configured to have). For example, a WTRU may be configured to send a PRS request after it has performed certain measurements / calculations on a given PRS configuration (e.g., the current PRS configuration). The WTRU may be configured to derive weights for specific PRS parameters based on the measurements / calculations on the PRS configuration. The WTRU may be configured to include the determined weights in a PRS activation request. For example, if the determined weights associated with a PRS configuration are included in a PRS activation request, the weights may indicate and / or be used to determine a preferred / desired PRS configuration based on measurements performed by the WTRU. In response to sending a PRS activation request that includes the respective weights, the WTRU may receive a new / updated configuration from the network.

[0113] A WTRU may be configured to send a request for a specific PRS configuration (e.g., a preferred PRS configuration). In response to requesting a specific PRS configuration, the WTRU may receive updated iteration coefficients for WTRU-based positioning based on the specified PRS configuration. For example, a WTRU may be configured to decide to request a set of PRS resources for a set of TRPs (e.g., as described herein with respect to Figure 3). A WTRU may also be configured to perform specific measurements on the PRS transmitted from each TRP on the configured resources (e.g., time, frequency, and / or spatial resources). Based on the measurements performed by the WTRU, a WTRU may be configured to send a request to the network (e.g., gNB, LMF) indicating the set of PRS resources to be used (e.g., a preferred set of PRS resources).

[0114] A WTRU may be configured to determine weights associated with each set of PRS resources. For example, the determined weights associated with each set of PRS resources may be included in the on-demand request sent by the WTRU. The weights determined to be associated with a set of PRS resources may also, or alternatively, be associated with the PRS resources under the set. A WTRU may be configured to determine weights associated with a TRP and to include the weights associated with the TRP in the on-demand request. In that case, the PRS configuration associated with the TRP may be associated with the weights.

[0115] As described herein, the WTRU may be configured to determine the weights of selected PRS parameters associated with a PRS activation request. For example, the WTRU may be configured to use TRP as a parameter for the PRS activation request. Other parameters, including PRS parameters as described herein, may also or alternatively be used.

[0116] As described herein, training data may be used to perform positioning. One or more of the following may apply: The WTRU may be configured to perform WTRU-based positioning. In certain WTRU-based positioning techniques, the WTRU may not perform measurements or transmit measurements to the network.

[0117] As shown in Figure 5, WTRU508 can perform measurements (e.g., RSRP measurements) on PRS transmitted from one or more TRPs. The location of the WTRU can change. When the location of the WTRU changes, the WTRU can receive PRS from one or more TRPs. For example, as shown in Figure 5, WTRU508 can be configured to measure RSRP from three TRPs, TRP504, 505, and 506. Referring to Figure 5, at t=0, WTRU508 may be at location 0, and WTRU508 may measure RSRP of -30dBm, -40dBm, and -60dBm from TRP504, TRP505, and TRP506, respectively.

[0118] At t=T, WTRU508 may be located at location 1.5, and WTRU508 may measure RSRPs of -30dBm, -30dBm, and -60dBm from TRP505, TRP506, and TRP507, respectively. The RSRP measurements performed by WTRU508 can be used as training data. For example, RSRP measurements can be input into an AI / ML model. Alternatively, the locations of each TRP and / or the estimated location of WTRU508 can be input into an AI / ML modal. Based on the input, the AI / ML may output weights associated with each of the TRPs. WTRU508 can then use the weights to send a PRS request, as described herein.

[0119] The WTRU may be configured to determine a set of TRPs (e.g., an initial set) for initiating a PRS activation request. The WTRU may determine a weight associated with each TRP, which may be included in the PRS request. For example, the WTRU may determine an initial candidate for a PRS request based on TRPs that are not part of the training data. Referring again to Figure 5, WTRU508 may not perform a measurement on a PRS from TRP503, and as a result, the measurement for TRP503 may not be included in the training data. If TRP503 is not included in the training data, WTRU508 may decide to include TRP503 in the initial set of candidates for the PRS request (e.g., based on the measurement associated with the PRS received from WTRU508). Similarly, since TRP504 is not included in the training data, WTRU508 may also decide to include TRP504 in the initial set of candidates for the PRS activation request.

[0120] The WTRU may determine weights associated with a given TRP based, for example, on measurements taken by the WTRU (e.g., RSRP measurements). Referring again to Figure 5, for example, if WTRU508 is located at position -0.5, the WTRU may be configured to send a PRS request to the network (e.g., LMF) and send PRS from TRP503 and / or TRP504. Based on the measurements, WTRU508 may determine that the RSRP from the PRS received from TRP504 is large (e.g., larger than the PRS received from TRP503). WTRU508 may also, or alternatively, determine that there is a higher probability of measuring a higher RSRP from TRP504 (e.g., as opposed to TRP0). Based on each measurement, WTRU508 may be configured to determine weights associated with TRP503 and TRP504. Based on the determination that there is a higher probability of measuring a higher RSRP from TRP504, the determined weight associated with TRP504 may be greater than the determined weight associated with TRP503.

[0121] As described herein, WTRU can determine weights associated with various PRS configurations. For example, WTRU can determine weights associated with TRP candidates based on the difference between measured values ​​and training data. Correlations may exist between training data and PRS measurements. For example, there may be training data (e.g., as shown in Figure 5) and measured values ​​(e.g., as shown in Figure 6). WTRU may determine that a PRS measurement from one TRP may be higher than that from another TRP, and WTRU may determine that a weight for a TRP with a higher PRS measurement may be greater than a weight for a TRP with a lower PRS measurement.

[0122] WTRU can determine the weight associated with a TRP candidate based on the number of TRP candidates (e.g., the number of remaining TRP candidates). For example, if there is a single TRP candidate (e.g., the number of remaining TRP candidates is 1), the weight of that TRP candidate may be 1 (1).

[0123] A WTRU may determine weights associated with PRS resources (e.g., beams) based on line-of-sight (LOS) indicators. For example, if the LOS indicator indicates a 50% probability of multiple paths being present, the WTRU may be configured to send requests for multiple beams, each associated with an equal weight.

[0124] WTRU may determine the weights associated with TRP candidates based on the distance of each TRP candidate from the TRP that sends PRS with a higher (e.g., the highest) RSRP.

[0125] A WTRU may receive a weight configuration from the network. For example, a WTRU may receive a configuration from the network and return either a value of 0 or 1 associated with a given PRS configuration. Alternatively, a WTRU may receive a range of weight values. For example, a range of weight values ​​may be associated with a predefined granularity (e.g., [0, 0.1, 0.2, 0.3, ...1], where the minimum and maximum values ​​of the range are 0 and 1, respectively, and the granularity of the range is 0.1). A WTRU may be configured to have weights based on its capabilities, for example. For example, if a WTRU reports the capability to return only 0 or 1, it may be configured (e.g., by the network) to indicate a weight of either 0 or 1.

[0126] A WTRU may be configured to determine weights associated with specific PRS parameters associated with unobserved PRS resources. In certain scenarios, a WTRU may be configured to send requests (e.g., to the network) for PRS from resources not measured by the WTRU. Before sending a request, the WTRU may receive spatial information about the PRS resources from the network. For example, spatial information may indicate the direction in which the PRS is transmitted from the gNB or TRP. An embodiment of spatial information includes the association of a PRS resource with other DL reference signals (RS) or UL RS. For example, a PRS resource ID may be spatially associated with a CSI-RS resource ID, which may indicate that the CSI-RS and PRS are transmitted from the gNB in ​​similar (e.g., the same) directions. The WTRU may also, or alternatively, receive spatial relational information associating a PRS resource ID and an SRS resource ID, which may indicate that the PRS and SRS are transmitted similarly (e.g., in the same direction) from the gNB and the WTRU, respectively. The WTRU may receive spatial relationship information or QCL information (e.g., QCL-D indicating pseudo-collocation information of multiple reference signals and / or channels) from the network.

[0127] Spatial information may include boresite information. For example, boresite information may be provided from the network for each PRS resource. Boresite information may indicate the direction in which the PRS resource is transmitted from the gNB or TRP. The WTRU may also, or alternatively, receive information relating to beamwidth or beam characteristics for each PRS resource (e.g., relative power difference per angle for each PRS resource). The WTRU may also receive expected AoD and / or expected AoA with respect to the PRS resource.

[0128] Based on the received spatial information, the WTRU may be configured to decide to send a PRS request to the network, including associated weights. For example, the PRS request may include a PRS resource ID, a PRS resource set ID, a TRP ID, and / or a frequency layer ID.

[0129] Referring to Figure 6, for example, WTRU602 may be configured to have one or more PRS resources. For example, WTRU602 may be configured to have PRS resources #1, #2, and #3 from TRP601, each of which PRS resources #1, #2, and #3 belong to PRS resource set #1 (indicated by vertical lines in Figure 6). WTRU602 may also be configured to have PRS resources #4 and #5 from TRP601, each of which PRS resources #4 and #5 belong to PRS resource set #2 (indicated by horizontal lines in Figure 6). As shown in Figure 6, each of PRS resources #1, #2, #3, #4, and #5 may be received from TRP601. WTRU602 may be configured to perform WTRU-based positioning and to receive spatial information related to the PRS resources. WTRU602 may perform measurements (e.g., RSRP measurements) on PRS resources #1, #2, and #3. For example, WTRU602 may measure higher RSRP from PRS resources #2 and #3 compared to PRS resource #1. Based on the measurement (e.g., RSRP) and spatial information for each PRS resource, WTRU602 may be configured to determine that PRS resource #5 may yield a higher RSRP than PRS resource #4. For example, as described herein, WTRU602 may use an AI / ML model to determine that PRS resource #5 may yield a higher RSRP than PRS resource #4. WTRU602 may send PRS requests to the network to activate PRS resources #4 and #5. For example, a PRS request sent by WTRU602 may include determined weights for each PRS resource (e.g., 0.2 for PRS resource #4 and 0.8 for PRS resource #5).

[0130] A WTRU may be configured to decide to request PRS resources (e.g., PRS resources from one or more TRPs) that fall within a particular AoD / AoA (e.g., the expected AoD / AoA of the received PRS resource). PRS resources requested by a WTRU may belong to the same or different sets of resources and / or the same or different TRPs from which the PRS resources are derived. Referring again to Figure 6, for example, WTRU602 may receive PRS resource #1 and PRS resource #2, and WTRU602 may measure a higher RSRP for PRS resource #1. Based on the expected AoDs for PRS resource #1 and PRS resource #2, WTRU602 may be configured to decide that PRS resources #3 and #4 fall within the expected AoD of PRS resource #1 (e.g., PRS resources #3 and #4 have narrower beams compared to PRS resource #1). WTRU602 may also, or alternatively, determine that PRS resources #5 and #6 fall within the expected AoD of PRS resource #2. Based on the measured RSRP, WTRU602 may be configured to determine that PRS resources #3 and #4 are associated with higher weights compared to PRS resources #5 and #6. Alternatively, WTRU602 may be configured to send requests to activate PRS resources #3, #4, #5, and #6 based on the measured RSRP. As described herein, requests to activate PRS resources #3, #4, #5, and #6 sent by WTRU602 may include the determined weights for each PRS resource (for example, the weights for PRS resources #3, #4, #5, and #6 are 0.4, 0.4, 0.1, and 0.1, respectively).

[0131] A WTRU may be configured to decide whether to request a PRS resource based on a specific indicator associated with the PRS resource. For example, a WTRU may be configured to decide whether to request a PRS resource based on a LOS indicator associated with the PRS resource. A WTRU may receive a specific indicator associated with a PRS resource, including, for example, a LOS indicator. Referring again to Figure 6, for example, if PRS resource #1 is associated with an LOS indicator of 1, WTRU 602 may determine that an LOS path exists along the direction of PRS resource #1. However, if the LOS indicator is 0.1, WTRU 602 may determine that it is unlikely that an LOS path exists along the direction of PRS resource #1. WTRU 602 may receive signals from PRS resource #1 and PRS resource #2. WTRU 620 may receive LOS indicators for PRS resource #1 and PRS resource #2 having values ​​of 0.8 and 0.1, respectively. Based on the expected AoD for PRS Resource #1 and PRS Resource #2, WTRU620 may determine that PRS Resources #3 and #4 fall within the expected AoD of PRS Resource #1 (for example, the beams associated with PRS Resources #3 and #4 are narrower than the beam associated with PRS Resource #1). WTRU602 may also, or alternatively, determine that PRS Resource #5 and / or PRS Resource #6 fall within the expected AoD of PRS Resource #2. Based on the LOS indicators for PRS Resources #1 and PRS Resource #2, as well as the spatial information associated with PRS Resources #3, #4, #5, and #6, WTRU602 may assign higher weights to PRS Resources #3 and #4 compared to PRS Resources #5 and #6 in the request.

[0132] Figure 6 shows an embodiment in which WTRU602 is configured to receive PRS from a single TRP601, but it should be understood that WTRU602 can also be configured to receive PRS from multiple TRPs (for example, as described herein). Similarly, a PRS resource set can also, or alternatively, include PRS resources from one or more TRPs.

[0133] A WTRU may decide to send a PRS request, for example, when it is configured to have multiple PRS resource sets (e.g., one resource set contains PRS resources with wide beams, and another resource set contains PRS resources with narrower beams). A WTRU may decide to send a request to terminate a PRS request procedure. For example, a WTRU may decide to send a request to terminate a PRS request procedure when there are no more PRS resources to request in a particular resource set (e.g., the resource set with the narrowest beam width).

[0134] WTRU may send PRS requests associated with PRS measurement-related parameters. For example, a WTRU may send a PRS request to turn one or more TRPs on or off. One or more of the following may apply:

[0135] A WTRU may send PRS requests to the network indicating which TRPs should be turned on or off. As described herein, a PRS request to turn on or off a given TRP may mean turning on or off the PRS for a given PRS resource associated with the TRP, and / or turning on or off the PRS for one or more (e.g., all) PRS resources associated with the TRP. Based on a request from the WTRU, a TRP that has been turned on may send a PRS to the WTRU. A TRP that has been turned off does not have to send a PRS to the WTRU. A PRS request sent by a WTRU may assign / associate a weight to each of the TRPs, and each weight of the TRP may indicate whether the TRP should send a PRS. For example, if a WTRU is configured to perform measurements on PRS received from multiple TRPs (e.g., TRP1, TRP2, and TRP3), a PRS request sent by a WTRU may use the associated weights to indicate which TRPs should send a PRS. For example, a PRS request could include weights of 1.0 for TRP1, 0.2 for TRP2, and 0 for TRP3. By sending such a PRS request, a WTRU might indicate that TRP1 should not send a PRS, but TRP3 should continue to send PRSs (e.g., with high certainty). Similarly, such a PRS request might indicate that TRP2 should continue to send PRSs, but the certainty associated with TRP2 may be lower (e.g., slightly lower) than the certainty associated with TRP3.

[0136] In certain implementations, a WTRU may determine the weight associated with / assigned to each TRP based on the measurements (e.g., RSRP) and / or channel state (e.g., LOS indicator, where an LOS indicator of 1 or 0 indicates an LOS or NLOS state) performed on the PRS received from its TRP. For example, a WTRU may determine that the LOS indicator associated with TRP1 is 0 (e.g., there is no line of sight between WTRU and TRP1). Based on the measurements (e.g., RSRP) and / or the determined channel state (e.g., LOS indicator), a WTRU may associate a weight that turns off the PRS for TRP1 (e.g., assign a weight of 1.0 to TRP1) because, for example, the WTRU anticipates a relatively low RSRP / channel state between WTRU and TRP1.

[0137] A WTRU may receive a configuration from the network indicating how it should determine the respective weights for a given TRP. For example, a WTRU may be configured to derive the respective TRP weights in a PRS request using a combination of metrics. In certain implementations, a WTRU may receive instructions from the network to use RSRP measurements and LOS indicators corresponding to PRS resources received from the TRPs in order to derive the respective weights associated with that TRP.

[0138] A WTRU may perform priority-based weighting for TRPs. One or more of the following may apply: For example, a WTRU may determine weights for PRS requests based on the PRS priority level. A WTRU may receive the PRS priority level from the network (e.g., via a configuration associated with PRS). If the priority level is high, the WTRU may decide to process the PRS measurement with higher priority (e.g., compared to other DL signals or channels such as PDCCH, PDSCH, etc.). If the PRS priority level is high, the WTRU may decide to associate weights for requests associated with PRS parameters. For example, if the PRS processing is configured at a higher level (e.g., compared to other DL signals or channels), the WTRU may be able to process the weights associated with the request. If the PRS priority level is low, the WTRU may decide to send the PRS request without associated weights (e.g., due to insufficient time to perform the measurement).

[0139] A WTRU may send beam sweeping requests to the network. One or more of the following may apply: A WTRU may send a request containing a set of PRS resources and / or beams that the TRP should send PRS to. A WTRU may associate / assign weights in the request. For example, the requested set of PRS beams may be associated (e.g., spatially) with the PRS on which the WTRU performed its measurements. In certain implementations, the requested set of PRS beams may be narrower than the beams associated with the PRS on which the WTRU performed its measurements.

[0140] A WTRU may request that additional positioning techniques be employed to improve accuracy, for example. One or more of the following may apply: A WTRU may submit a request for a specific positioning technique to which weights are associated / to which weights are assigned. For example, a WTRU may consist of a DL positioning method (e.g., DL-TDOA). Based on measurements taken for the estimated location of the PRS and / or WTRU, a WTRU may decide that additional positioning should be used to improve the accuracy of the WTRU's location estimate, for example. Based on such a decision, a WTRU may request additional positioning techniques, such as a PRS request using dedicated PRS resources (e.g., phase-based positioning).

[0141] A WTRU can assign weights to requests for additional positioning techniques. For example, a WTRU may determine the weight assigned to a request based on the quality / accuracy associated with the location estimate obtained from a previous positioning technique. For instance, if the standard deviation of the location estimate obtained from a previous positioning technique is greater than or equal to a pre-configured threshold, a WTRU may submit a request for an additional positioning technique (e.g., phase-based positioning). A WTRU may determine the weight associated with a request for an additional positioning technique based on the standard deviation of the location estimate obtained from a previous positioning technique. In certain implementations, a WTRU may be configured using a table that associates a range of standard deviations with each weight (e.g., pre-configured). For example, if the standard deviation is lower, a WTRU may associate / assign a lower weight to a request for an additional positioning technique. A request for an additional positioning technique (e.g., phase-based positioning) that is assigned a lower weight may indicate a lower certainty of the request.

[0142] In certain implementations, a WTRU may decide to send a request for additional positioning techniques based on RSRP measurements. For example, if the average RSRP of received PRS resources is greater than or equal to a threshold (e.g., a pre-configured threshold), the WTRU may decide to send a request for additional positioning techniques. As described herein, the weights associated with / assigned to a request for positioning techniques may be based on configured (e.g., pre-configured) association rules between RSRP ranges and weight values.

[0143] The WTRU may transmit a request for a measurement gap (MG) or PRS processing window, including associated weights. One or more of the following may apply: The WTRU may transmit a request for an MG and / or PRS processing window to the network (e.g., gNB, LMF). During the MG, for example, the WTRU may not receive any DL channels (e.g., PDCCH, PDSCH) or signals (e.g., it may not expect to receive any). During the PRS processing window, for example, the WTRU may process PRS according to a configured PRS priority level (e.g., it is expected to process them). If the PRS priority level is lower than other DL signals or channels, the WTRU may not perform a measurement on PRS received during the PRS processing window (e.g., it is not expected to perform any measurements).

[0144] A WTRU may decide whether to send a request for a MG or a PRS processing window based on the PRS configuration. For example, a WTRU may decide to send a request for a MG to the network if the duration of the PRS (e.g., the number of symbols, slots, subframes, or frames) is shorter than a threshold (e.g., a pre-configured threshold). For example, a WTRU may send a request for a MG if the number of slots configured for the PRS is longer than a threshold. If the number of slots configured for the PRS is less than or equal to the threshold, a WTRU may decide to send a request for a PRS processing window. For example, the type of PRS processing window requested by a WTRU may depend on the WTRU's capabilities. In certain implementations, a WTRU may request a window, and PRS prioritization is applied to the processing window based on the WTRU's processing capabilities. In certain implementations, a WTRU may request a processing window to which PRS prioritization is applied to one or more PRS symbols / slots within the processing window.

[0145] A WTRU may, for example, send a request for a PRS processing window if its request for a MG is not permitted by the gNB. The WTRU may include in the request the desired PRS priority level (e.g., high, medium, low). For example, a WTRU may send MG and / or PRS processing window requests to the network via UCI, UL-MAC-CE, RRC, and / or LPP messages.

[0146] A WTRU can associate / assign weights to requests for MG or PRS processing windows. For example, the value of the associated weight may be determined based on latency requirements and / or the scheduled PDSCH or PDCCH frequency. For instance, if the WTRU consists of periodic reception of a PDSCH, the WTRU may decide to request a measurement gap associated with a weight of 1.0, which may indicate that the request is transmitted with higher priority / certainty. As described herein, during MG, the WTU does not need to receive downlink channels, which may allow the WTRU to perform PRS measurements. In certain implementations, the WTRU may associate weights (e.g., lower than 1.0) based on the priority level of the PDSCH. If the priority level associated with the PDSCH is higher, the WTRU may associate a weight lower than 1.0, which may indicate a lower demand for the MG configuration.

[0147] In certain implementations, for example, if the WTRU is not configured to have periodic or semi-persistent DL signals, PDCCHs, and / or PDSCHs, the WTRU may send requests for PRS processing windows. The WTRU may determine the weight associated with the processing window request based on the frequencies of the scheduled DL signals, PDSCHs, and / or PDCCHs. If the frequency of the scheduled PDSCH or PDCCH is greater than or equal to a threshold (e.g., a pre-configured threshold), the WTRU may assign a weight of 1.0 to the PRS processing window request, which may indicate a higher demand for the PRS processing window from the WTRU. The WTRU may determine the weight for the request based on configured (e.g., pre-configured) association rules between the frequency of the scheduled PDSCH / PDCCH and the weight value. For example, the configured association rules may assign higher weight values ​​to higher frequency values ​​for the scheduled PDSCH / PDCCH. As described herein, the frequencies of scheduled PDSCH and / or PDCCH may be measured by the number of slots / symbols / subframes / frames scheduled within a time window (e.g., 1 second). Based on the amount of time and / or frequency resources occupied by the downlink channel within the time window, the WTRU may determine the frequencies of scheduled PDSCH and / or PDCCH.

[0148] In certain implementations, the assigned weight values ​​may depend on the latency requirements for positioning. For example, if the latency requirement is below a (e.g., pre-configured) threshold, the WTRU may send an MG request. If the latency requirement is above the threshold, the WTRU may make a PRS processing window request. The WTRU may determine the associated weight for a request based on (e.g., pre-configured) association rules between latency and weights. For example, the WTRU may be configured (e.g., pre-configured) using a latency range and corresponding weights. For example, if the latency requirement is less than 1 second, the corresponding weight may be 1.0. For example, if the latency requirement is between 1 and 10 seconds, the corresponding weight may be 0.5.

[0149] A WTRU may transmit a request for a UL reference signal. One or more of the following may apply: In certain implementations, a WTRU may transmit a request for configuration for an SRS, PTRS, or SRS configuration. For example, a WTRU may decide whether to transmit a request for a UL reference signal based on measurements taken on a DL PRS. For example, if a WTRU is configured with an RTT positioning method or a UL-based positioning method (e.g., UL-TDOA), a WTRU may transmit a request for configuration for a UL reference signal. A WTRU may be configured with a list of UL RS (e.g., SRSp) configurations (e.g., pre-configured), and a WTRU may determine the UL RS configuration from the requested list.

[0150] For example, a WTRU may decide to send a request for an SRSp configuration based on RSRP measurements performed on the PRS. If the RSRP corresponding to the PRS resource exceeds a (e.g., pre-configured) threshold, the WTRU may decide to request a particular SRSp configuration with a higher time and / or frequency density, for example. If the RSRP corresponding to the PRS resource is below a (e.g., pre-configured) threshold, the WTRU may decide to request a particular SRSp configuration with a lower time and / or frequency density, for example. For example, a WTRU may be configured (e.g., pre-configured) using association rules between SRSp configurations and RSRP ranges for DL ​​PRS resources. In a particular implementation, if the RSRP of the PRS resource falls within the range of -70dBm to -60dBm, the corresponding iteration factor for the SRSp may be 4. In a particular implementation, if the RSRP of the PRS resource falls within the range of -60dBm to -50dBm, the corresponding iteration factor for the SRSp may be 2. The WTRU may determine the iteration factor for the SRSp according to the rules. A WTRU may receive configurations that associate PRS resources and SRSp resources. A WTRU may decide to send a request for a configuration for the SRSp resource based on measurements taken on the associated PRS resource. A WTRU may associate weights for the request based on, for example, measurements of the PRS. For example, a WTRU may associate weights for the request based on the characteristics of the RSRP measurement on the PRS (e.g., statistical characteristics) (e.g., standard deviation of RSRP, variance of RSRP). A WTRU may be configured using association rules for the range of the standard deviation of RSRP and the corresponding weights. A WTRU may determine the weight values ​​based on the association rules.

[0151] A WTRU may be configured to determine an estimated location. A WTRU may report an estimated location to the network. For example, a WTRU may include an estimated location in a message containing a request for new / updated parameters from the WTRU. A WTRU may determine an estimated location based on training data (for example, if training data is available to the WTRU). A WTRU may be configured to indicate to the network whether an estimated location has been determined. For example, a WTRU may be configured to indicate that an estimated location has been determined based on training data.

[0152] Training data can be associated with specific information, including timing information (e.g., timestamps). For example, if training data is associated with timestamps, a WTRU can be configured to associate the timestamps with estimated locations, which can show the network how the estimated locations were determined by the WTRU. A WTRU can also, or alternatively, be configured to associate estimated locations with the method used to determine the location estimates. For example, a WTRU can show the network the type of AI / ML model used to determine the estimated locations (e.g., supervised, unsupervised, and semi-supervised). A WTRU can also include timestamps in PRS requests (e.g., requests from the WTRU to the network about new / updated PRS configurations) so that the network can associate the determined weights with the time or relative / absolute timing when the request was sent from the WTRU.

[0153] As described herein, the WTRU may be configured to include specific information associated with the AI / ML model used to determine the estimated location. For example, WTRU may be configured to include in the PRS request the amount of data (e.g., the number of measurements, the duration of training, etc.) that the AI / ML model has acquired and / or processed to determine the estimated location.

[0154] A WTRU may be configured to determine the weights of PRS parameters based on the WTRU's predicted location. An example of a predicted location may include, for example, the WTRU's location 10 ms from the current time. The predicted location of a WTRU may be determined by the WTRU based on a mobility model. The WTRU may be configured by the network using one or more mobility models, including, for example, linear and curved trajectory models (e.g., pre-configured). Based on the trajectory model, for example, the WTRU may be configured to determine the predicted location of the WTRU at a predicted interval T from the current time (e.g., expressed in terms of seconds, symbols, slots, subframes, or the number of frames). For example, the predicted interval T may be configured (e.g., by the network). Based on the WTRU's predicted location, the WTRU may be configured to determine weights and associate the determined weights with specific PRS parameters (e.g., spatial direction of the PRS, periodicity, TRP ID, etc.). The WTRU may be configured to transmit the PRS parameters and associated weights to the network. For example, PRS parameters and their associated weights may be included in a PRS parameter reconfiguration request.

[0155] As explained, a WTRU can be configured to determine weights associated with one or more PRS parameters. For example, weights associated with TRP candidates can be determined based on the likelihood / probability that the WTRU will receive a PRS from a given TRP candidate. For instance, if, based on the predicted location of the WTRU, the WTRU determines that it is likely to measure a higher RSRP from TRP0 and a lower RSRP from TRP1, the WTRU can be configured to associate a higher weight with TRP0 than with TRP1.

[0156] WTRU may also, or alternatively, be configured to determine weights for TRP candidates based on the predicted quality of future TRP / PRS. For example, the associated weights determined by WTRU may be associated with validity time. For example, a WTRU that measures a higher RSRP from TRP0 at time T may determine that WTRU may measure a higher RSRP from TRP1 at time T+n. WTRU may determine a first set of weights (e.g., TRP0 may be assigned a higher weight compared to TRP1). The first set of weights may be associated with a first time interval (e.g., from time T to time T+n). WTRU may determine a second set of weights associated with a second time interval (e.g., from time T+n to time T+2n) (e.g., TRP1 may be assigned a higher weight compared to TRP0). WTRU may be configured to include two sets of weights in separate messages or in the same message. WTRU may also be configured to indicate a reference time (e.g., T) and / or a time window duration (e.g., n). The reference time and / or time window duration may also, or alternatively, be configured and / or preconfigured by the network.

[0157] The WTRU and / or network may be configured to determine new / updated PRS parameters based on associated weights. The WTRU may be configured to determine new / updated PRS parameters based on the weight values ​​associated with a given PRS request (for example, if the weights exceed a threshold). Figures 7A-7C show an embodiment associated with WTRU 703 configured to determine, for example, the weights associated with a PRS configuration included in a PRS request. As shown in Figures 7A-7C, WTRU 703 may be capable of receiving PRSs from TRP 704, 705, 706, 707, and 708. TRP 704, 705, 706, 707, and 708 may be located at positions -1, 0, 1, 2, and 3, respectively. Using the PRS request techniques described herein, WTRU 703 may receive PRS configurations. WTRU703 may perform measurements (e.g., RSRP measurements) for each of TRP704, 705, 706, 707, and 708 (e.g., PRS received from TRP704, 705, 706, 707, and 708). Based on the measurements, WTRU703 may send a PRS request containing the requested PRS configuration. Based on the PRS request sent by WTRU703 (e.g., in response thereto), WTRU703 may receive a new / updated PRS configuration.

[0158] As shown in Figure 7A, WTRU703 may be configured to receive PRS from TRP706, 707, and 708. WTRU may perform measurements (e.g., RSRP measurements) on the PRS received from TRP706, 707, and 708. For example, in the embodiment shown in Figure 7A, WTRU703 may measure RSRPs of -40, -60, and -60 for TRP706, 707, and 708, respectively. An estimated location associated with WTRU703 may then be determined based on the RSRP measurements. For example, as shown in Figure 7A, the estimated location of WTRU703 may be determined to be position 1. As described herein, WTRU may determine its estimated location using an AI / ML model. For example, each measurement (e.g., RSRP measurement) and / or location associated with the TRPs may be input to the AI / ML model. Based on the input, the AI / ML model may output the estimated location of WTRU. As described herein, AI / ML models may be installed / implemented in a WTRU and / or another device (e.g., a network or a device associated with network functionality).

[0159] As shown in Figure 7A, the WTRU may send a PRS request to the network (e.g., a network function such as LMF 702) to receive PRS from TRPs 704 and 705. The WTRU 703 may assign a weight to each of the TRPs included in the PRS request and include that weight in the PRS request. For example, as shown in Figure 7A, the WTRU 703 may assign a weight of 0.4 to TRP 704 and a weight of 0.6 to TRP 705. As described herein, the WTRU may determine the weights associated with the TRPs included in the PRS request based on an AI / ML model. For example, each measurement (e.g., RSRP measurement) and / or location associated with a TRP may be input to the AI / ML model. Based on the input, the AI / ML model may output an estimated location of the WTRU. As described herein, the AI / ML model may be installed / implemented in the WTRU and / or another device (e.g., a device associated with a network or network function). For example, if AI / ML is implemented on another device (e.g., a network or a device associated with network functionality), the WTRU may transmit the information input to the AI / ML model to the other device.

[0160] A new / updated PRS configuration may be based on the associated weights included in the PRS request sent by WTRU703. For example, if the weight associated with a PRS configuration is greater than or equal to a threshold, WTRU703 may be configured to determine that it is likely to receive a new / updated PRS configuration. In an embodiment, WTRU703 may be configured to have a threshold of 0.5. Since the weight associated with TRP705 is 0.6, WTRU703 may determine that the network is likely to activate TRP705 (e.g., WTRU703 is likely to receive a new / updated PRS configuration indicating that PRS should be sent from TRP705). WTRU703 may also, or alternatively, be configured to send a request to stop PRS transmission from a given TRP, for example, based on measurement. Referring again to Figure 7A, for example, WTRU703 may be configured to send a request to stop PRS on TRP708 (for example, due to TRP708 having the lowest measured RSRP). WTRU703 may also, or alternatively, be configured to determine activated and deactivated TRPs based on PRS configurations received from the network (e.g., after WTRU sends a PRS request to the network). WTRU703 may also be configured to receive new / updated PRS configurations from the network after WTRU703 sends a PRS request including relevant PRS parameters and associated weights. For example, WTRU703 may not receive the requested PRS configuration (e.g., newly activated TRPs) from the network.

[0161] Referring again to Figure 7A, if WTRU703 is configured to have a threshold of 0.4 and WTRU returns decision weights of 0.4 and 0.6 for TRP704 and TRP705, respectively, the network may configure both TRP704 and TRP705 to send PRS to WTRU703. WTRU703 may send a PRS request to the network to stop PRS transmissions from TRP707 and TRP708 (for example, due to TRP707 and TRP708 being associated with the lowest measured RSRP, as shown in Figure 7A).

[0162] The WTRU may be configured to decide to include PRS parameters that are not part of recent measurements. As shown in Figure 7B, for example, WTRU703 may be configured to receive PRS from TRP705, TRP2, and TRP3. At t=0, the WTRU may measure a low RSRP for the PRS transmitted from TRP705. For example, as shown in Figure 7B, WTRU703 may measure RSRPs of -60 dBm, -40 dBm, and -60 dBm for TRP705, 706, and 707, respectively. Based on the RSRP measurements and / or locations of each TRP, the estimated location of WTRU703 may be determined to be location 0.5. As described herein, the location of WTRU703 may be estimated using an AI / ML model, which may be implemented in WTRU703 and / or another device (e.g., a network or a device associated with network functionality). For example, if AI / ML is implemented on another device (e.g., a network or a device associated with network functionality), the WTRU may transmit the information input to the AI / ML model to the other device.

[0163] Based on a previous PRS request, for example, WTRU703 may send a PRS request to the network for TRP704 to send a PRS. The weight of TRP704 may be determined by WTRU as described herein (e.g., using an AI / ML model). A list of candidate TRPs that WTRU703's PRS request may include TRP704, TRP705, TRP706, TRP707, and TRP708. Since WTRU703 has already made measurements from TRP705 to TRP708, WTRU703 may measure the PRS received from TRP704 (e.g., only that). Furthermore, (for example, since TRP704 may be the only TRP that WTRU703 can request), WTRU703 may decide to assign a weight of 1 to TRP704 and include that weight in the PRS request. Based on the PRS request, WTRU703 may receive an updated PRS configuration.

[0164] A WTRU may include additional PRS parameters in a PRS request. For example, as described herein, a WTRU may include weights associated with TRPs from which the WTRU requests the network to activate (e.g., receive PRSs). A WTRU may also include periodicity values ​​in the PRS request for PRS transmissions from the requested TRPs (e.g., so that, once activated, PRSs can be transmitted from the requested TRPs at defined / requested periodicities). A WTRU may be configured to include a common periodicity for the requested TRPs, or a different periodicity for each of the requested TRPs.

[0165] As shown in Figure 7C, WTRU703 may receive an updated TRP / PRS configuration based on, for example, a PRS request sent by WTRU703 in Figure 7B. For example, the updated TRP / PRS configuration may activate the PRS from TRP704. As shown in Figure 7C, WTRU703 may receive the PRS received from TRP704, 705, and 706 and perform measurements of those PRS. WTRU703 may measure RSRPs of -30 dBm, -60 dBm, and -40 dBm for TRP704, 705, and 706, respectively. The location of WTRU703 can be estimated to be position 0.

[0166] A WTRU can be configured to terminate on-demand PRS procedures. For example, after a WTRU has exhausted its PRS requests to a TRP, it may decide to terminate on-demand PRS procedures. A WTRU may terminate a PRS request procedure by sending a PRS termination request (e.g., to the network).

[0167] A WTRU can be a configured PRS request limit. For example, a WTRU may be configured to have a PRS request limit (e.g., the maximum number of PRS requests that can be sent by the WTRU). A WTRU may be configured to terminate the PRS activation request procedure (e.g., by sending a termination request, as described herein) if the number of PRS requests sent by the WTRU exceeds the PRS request limit. After terminating the PRS activation request procedure, the WTRU may continue to use the most recent PRS configuration (e.g., the most recent PRS configuration the WTRU has received from the network).

[0168] A WTRU may be configured to perform weight validation. As described herein, a WTRU may determine weights associated with a particular PRS parameter based, for example, an AI / ML algorithm, historical measurements, and / or pre-configured data. A WTRU may also be configured with a validation period or area (e.g., by a network). If a WTRU is configured by a network (e.g., LMF, gNB) to have a validation period, the WTRU may be configured to start a timer in response to determining an initial set of PRS parameters. After the timer expires, the WTRU may be configured to send a request from the network for additional training data for an AI / ML algorithm (e.g., additional PRS configurations on which the WTRU may perform measurements). The WTRU may perform measurements on additional PRS configurations that can be used as training data for an AI / ML algorithm, as described herein. The WTRU may determine weights associated with a PRS parameter based on an AI / ML algorithm incorporating the additional training data.

[0169] A WTRU may decide to send a PRS request to a TRP not included in the WTRU's PRS configuration. As described herein, a WTRU may be configured with a set of PRS parameters that the WTRU can select (for example, it may be pre-configured). The WTRU may indicate or include the selected PRS parameters in the PRS request. For example, a WTRU might decide to send a PRS request based on pre-configured PRS parameters (e.g., the WTRU assigns a weight of 1 to selected PRS parameters within the pre-configured set). The WTRU might also, or alternatively, decide to send a PRS request for TRPs that are not included in the set of pre-configured PRS parameters. For example, a WTRU might receive a pre-configuration for a list of TRPs including TRP0, TRP1, and TRP2. The WTRU might decide to send a PRS request to the network to activate the PRS from TRP0, TRP1, and / or TRP2. However, the WTRU might decide to send a PRS request to activate the PRS from TRP3 and TRP4, which may not be pre-configured. The WTRU might, for example, assign a weight of 0.3 to TRP3 and a weight of 0.7 to TRP4. The WTRU may be configured to receive system information block (SIB) or LPP messages that may include instructions from the network (e.g., support data request messages) regarding whether a PRS request within a pre-configured list of PRS parameters or a PRS request outside of a pre-configured list of PRS parameters can be sent.

[0170] In certain scenarios, a WTRU may not receive a pre-configured list of PRS parameters (e.g., in an SIB or LPP message). If a WTRU does not receive a pre-configured list of PRS parameters, it may send a blind request. For example, a blind request may include specific information / ID associated with one of the PRS parameters / configurations supported by the network. A blind request may also include weights associated with the PRS parameters, where the weights may indicate the WTRU's desired / preferred PRS parameters. The weight values ​​may, for example, indicate the level of preference for the PRS parameters. A WTRU may also, or alternatively, send a blind request, for example, when it receives instructions / requests from the network for the WTRU to send a blind request.

[0171] A WTRU can be associated with active and / or inactive PRS configurations. For example, a PRS configuration may be inactive due to the expiration of its associated timer, and / or the WTRU may be in an area where the PRS configuration is not associated with an active area (e.g., the PRS configuration is not associated with the cell in which the WTRU is located). The WTRU may decide to associate a weight with a PRS configuration that is not part of an active PRS configuration.

[0172] As described herein, a WTRU may be configured to initiate and / or terminate a PRS activation request procedure. For example, a WTRU may send PRS requests periodically, semi-permanently, and / or aperiodicly. A WTRU may terminate a PRS activation request procedure in response to, for example, one or more conditions.

[0173] A WTRU may be configured to periodically, semi-permanently, and / or periodically transmit PRS activation requests (e.g., by a network). For example, a WTRU may be configured to have periodicity (e.g., opportunities) in the transmission of PRS requests by the network. If a WTRU decides to transmit a PRS activation request (e.g., as described herein), it may decide to transmit a PRS request including associated weights based on the configured periodicity.

[0174] The PRS activation request procedure can be triggered by the network. For example, a WTRU may receive an activation command (e.g., via DCI or MAC-CE), and the activation command may be configured to trigger / start the PRS activation request procedure (e.g., a PRS request trigger). The WTRU may be configured to have a periodicity during which it can send PRS activation requests.

[0175] A WTRU may be configured to initiate an on-demand PRS procedure by passing a trigger such as a MAC-CE. In response to sending a MAC-CR, the WTRU may receive an acknowledgment or denial from the network to initiate the on-demand request procedure. For example, the network may send a deactivation command (e.g., via MAC-CE) that indicates the network has refused to initiate the on-demand PRS request. After the WTRU receives a deactivation command from the network (e.g., via MAC-CE), the WTRU may decide to terminate the on-demand request procedure.

[0176] In certain scenarios, a WTRU may terminate a PRS activation request procedure if it no longer has parameters to request (for example, if the WTRU no longer has a TRP to request a PRS). For example, if there are no more TRPs remaining to request a PRS transmission, the WTRU may send a directive (e.g., a request) to terminate the PRS activation request procedure to the network. The WTRU may also, or alternatively, decide to terminate a PRS activation request procedure if one of the weights associated with the PRS configuration exceeds a threshold (e.g., a pre-configured threshold). For example, a weight above the threshold may indicate a level of certainty in the WTRU's request. The WTRU may also, or alternatively, terminate a PRS activation request procedure if the weights associated with the PRS configuration (e.g., all associated weights) fall below a threshold (e.g., a pre-configured threshold). For example, weights below the threshold (e.g., all associated weights) may indicate a level of uncertainty in the WTRU's request.

[0177] In another embodiment, a WTRU may receive configurations from the network regarding a time window for which the WTRU can make on-demand requests for PRS configurations. Configurations related to a time window may include the start and / or end times of the window, and the duration of the window (e.g., in terms of symbols, slots, frames, or milliseconds).

[0178] A WTRU may be configured to perform a PRS activation request procedure for a specific time period. For example, a WTRU may start / start a timer when it initiates a PRS activation request procedure (e.g., in response to receiving an activation command via MAC-CE). A WTRU may receive an expiration time for the timer, which may indicate the period during which it can perform the PRS activation request procedure. While the timer is active, a WTRU may send PRS activation requests, including associated weights (e.g., with configured periodicity), as described herein. After the timer expires, a WTRU may terminate an on-demand request procedure.

[0179] A WTRU may receive a trigger from the network (e.g., via DCI) to send a PRS activation request. In response to receiving a trigger, the WTRU may send an on-demand PRS request, including the associated weight, as described herein.

[0180] The WTRU may receive instructions from the network to modify / update one or more configurations associated with the PRS activation request procedure, increase / decrease the frequency (e.g., periodicity) of sending PRS requests, limit associated weight values ​​(e.g., upper limit on weight values), or normalize weights based on one or more criteria (e.g., the maximum weight is 1 and the average weight is 0.5).

[0181] In certain scenarios, a WTRU may send a PRS activation request to the network in response to the fulfillment of one or more of the conditions for triggering a PRS activation request. As described herein, the conditions for triggering the PRS activation request procedure may be configured by the network. A WTRU may also, or alternatively, send a PRS activation request if no pre-configured conditions exist.

[0182] A WTRU may receive instructions from the network to provide specific information associated with the PRS activation request procedure. For example, a WTRU may receive a request to return a PRS request, which includes the associated weights associated for the requested PRS configuration, and a list of TRPs from which the WTRU can receive PRS and their respective locations. A WTRU may be configured to have a set of TRPs from which it can receive / request PRS. The WTRU may perform measurements (e.g., RSRP measurements) on PRS from each TRP. The WTRU may determine that one or more TRPs that are not part of the configured TRPs (e.g., TRPs from which PRS are received / measured by the WTRU) are candidate TRPs. If the average RSRP of PRS received from the configured TRPs falls below a threshold, the WTRU returns the respective weights for each candidate TRP to the network. For example, the respective weights for each candidate TRP may be determined by the WTRU based on the proximity of a given TRP to the WTRU (e.g., how close a given TRP is to the TRP with the highest measured RSRP). Based on this information, the WTRU may determine and return its estimated location. Based on the WTRU's estimated location, the WTRU may receive a new / updated set of TRPs that receive PRS. The WTRU may receive each PRS from the updated set of TRPs and perform measurements on them. The WTRU may continue measuring PRS, determining a set of candidate TRPs, and determining its estimated location / position until the average RSRP of the configured set of TRPs exceeds a threshold. The WTRU may maintain a number of iterations in which it measures PRS, determines a set of candidate TRPs, and determines its estimated location / position. If the number of iterations exceeds the threshold, the WTRU requests termination of the PRS activation request procedure.

[0183] The WTRU may implement certain fallback and rejection techniques associated with the PRS activation request procedure. For example, the WTRU may transition to a default on-demand procedure (e.g., a request for a specific PRS parameter or a specific set of PRS parameters) and / or a non-on-demand procedure if one or more of the following conditions are met: the WTRU decides to terminate the on-demand request procedure as described herein; the timer associated with the PRS activation request procedure expires; there are no more PRS parameters (e.g., TRP) to associate weights with; or the WTRU receives a rejection message from the network (e.g., gNB, LMF) in response to the transmitted PRS activation request.

[0184] After the WTRU completes the PRS activation request procedure, the WTRU may continue to use the most recent PRS configuration received from the network. Alternatively, after the WTRU completes the on-demand PRS procedure, the WTRU may decide to send a request for specific PRS parameters or a specific set of PRS parameters. The WTRU may decide to use the PRS configuration it receives from the network.

[0185] A WTRU may decide to terminate the PRS activation request procedure. If a WTRU decides to terminate the PRS activation request procedure (for example, in response to receiving a rejection message from the network), the WTRU may use: the default positioning procedure (e.g., on-demand and / or non-on-demand PRS procedure), the default PRS configuration, and the / pr or previous PRS configuration. If a WTRU decides to terminate the PRS activation request procedure, the WTRU may be configured by the network to implement one of the techniques described herein. If a WTRU decides to terminate the PRS activation request procedure, the WTRU may send a request for a specific PRS configuration parameter or parameter set (e.g., without associated weights).

[0186] As described herein, a network may reject a PRS activation request, for example, by sending a rejection message to a WTRU. For example, a rejection message from the network may be explicit or implicit. A WTRU may receive an explicit rejection message in response to having sent a PRS activation request to the network. A WTRU may receive a rejection message associated with one or more of the PRS parameters that the WTRU sends to the network. For example, a WTRU may decide to send another PRS activation request, including different PRS parameters and associated weights.

[0187] The WTRU may determine that the network has rejected the PRS activation request if, for example, a PRS from one of the requested PRS parameters (e.g., a PRS from one of the requested TRPs) is not received within a certain amount of time (e.g., a pre-configured time window). The WTRU may start / start a timer after it has sent the PRS activation request to the network. If the WTRU does not receive the PRS configuration before the timer expires, the WTRU may determine that the PRS activation request has been rejected by the network.

[0188] A WTRU may transition to and from WTRU-based positioning and / or WTRU-assisted positioning. A WTRU may decide to switch from WTRU-based positioning to WTRU-assisted positioning in one or more of the following scenarios: the WTRU receives instructions from the network to switch to and from WTRU-based positioning and / or WTRU-assisted positioning; the WTRU determines that the quality of measurements (e.g., RSRP) for the PRS configured by the network falls below a threshold; and / or the WTRU determines that the variability of measurements (e.g., variance / standard deviation of RSRP, RSTD) for the PRS configured by the network exceeds a threshold.

[0189] After a WTRU transitions from WTRU-based positioning to WTRU-assisted positioning / from WTRU-assisted positioning, the WTRU may transmit specific measurements. For example, measurements may be based on PRS parameters configured by the network. PRS parameters configured by the network may be effective / valid for a configured duration. The WTRU may be configured to have a time window during which it performs measurements on received PRS and returns them to the network. The WTRU may be configured to have semi-persistent and / or aperiodic PRS, and the WTRU may perform measurements on semi-persistent and / or aperiodic PRS. The WTRU may return measurements to the network (e.g., for a configured duration), which may help the network train AI / ML models that can be used to perform positioning.

[0190] In certain scenarios, the WTRU may obtain a set (e.g., a subset) of PRS configurations (e.g., TRP ID, TRP location, etc.) from the network. For example, the subset of PRS configurations may be based on a hierarchical structure (e.g., hierarchical structure 400 shown in Figure 4). The WTRU may receive a first (e.g., initial) PRS configuration (e.g., TRP location, PRS periodicity, etc.) from the network. The WTRU may also, or alternatively, receive a set of TRP locations from the network.

[0191] Based on the initial (e.g., initial) PRS configuration received from the network, the WTRU may determine its location. Based on the WTRU's location, the WTRU may determine which TRPs should be activated for PRS transmission. The WTRU may receive a set of TRPs that should be activated for PRS transmission. The WTRU may determine which TRP to activate from the set. The WTRU may send a PRS configuration request to configure one or more PRS parameters other than TRPs, such as frequency layers, PRS resources, PRS resource sets, and / or similar.

[0192] In certain scenarios, a WTRU may send a request to activate a given PRS configuration. The network may activate the requested PRS configuration and return one or more PRS parameters associated with the requested PRS configuration. For example, a WTRU may request the activation of a TRP. As an acknowledgment message from the network (e.g., LMF, gNB), the WTRU may receive from the network the activated TRP and associated PRS configuration (e.g., number of PRS symbols / slots, periodicity, spatial information). In another embodiment, a WTRU may request the activation of one or more frequency layers. As an acknowledgment message for the request to activate the frequency layers, the WTRU may receive from the network the activated frequency layers and associated PRS configuration.

[0193] A WTRU can send one or more requests to the network. For example, each request may be associated with a given layer in the PRS configuration hierarchy (e.g., the PRS configuration hierarchy shown in Figure 4). In a particular scenario, a WTRU may send a request to activate one or more frequency layers. The WTRU may receive a list of TRPs that can be activated under the activated frequency layer, which can be considered an acknowledgment to the activation request. The WTRU may further decide which TRPs on the list should be activated and send a request to activate the selected TRPs. In response to the request to activate the selected TRPs, the WTRU may receive the PRS configuration associated with the activated TRPs from the network, which can be considered an acknowledgment to the TRP activation request.

[0194] A WTRU may receive a list of available (e.g., potential) PRS configurations (e.g., TRP, frequency layer, etc.). The WTRU may decide to send a request to activate a subset of the available PRS configurations. The activated PRS configurations are sometimes referred to as the activated (e.g., actual) PRS configurations.

[0195] The WTRU may use criteria (e.g., selection criteria) to select which TRPs to activate. One or more of the following may apply: The TRP selection criteria may be based on the distance between the TRP and the WTRU's location (e.g., the WTRU's current location). For example, the WTRU may decide to activate TRPs whose distance from the WTRU's location is below a threshold, as shown in Figure 8A, for example.

[0196] As shown in Figure 8A, WTRU807 may be configured using TRP801, TRP802, and TRP803 (for example, initially). WTRU807 may decide to send a PRS request to the network to activate an additional TRP. WTRU807 may determine its location based on measurements taken on PRSs transmitted from TRP801, TRP802, and TRP803, for example, using techniques described herein (e.g., AI / ML models). WTRU807 may decide to send a request to the network to activate TRP805 and / or TRP806 based on thresholds indicated by circles in Figure 8A (e.g., pre-configured thresholds). For example, thresholds may be distance thresholds and / or measurement (e.g., RSRP) thresholds. As shown in Figure 8A, WTRU807 cannot decide to activate TRP804 because it is outside the threshold.

[0197] The WTRU may, for example, perform a measurement (e.g., RSRP) of a signal (e.g., SSB) from a reference signal (e.g., PRS, CSI-RS) or one or more TRPs (e.g., potential TRPs). The WTRU may, for example, decide to send an activation request associated with the TRP if the RSRP of the reference signal / signal from that TRP exceeds a threshold.

[0198] As described herein, a WTRU may determine a threshold distance (e.g., a threshold distance between a given TRP and a WTRU) that can be used to identify a TRP to activate. For example, the threshold distance may be configured (e.g., pre-configured by the network). Alternatively, the threshold distance may be determined based on a lookup table (e.g., a lookup table associating the RSRP of a PRS resource with a threshold). For example, the lookup table may include the RSRP of a reference PRS and / or the average RSRP of PRS resources from a reference TRP associated with a threshold. In certain scenarios, a lower RSRP value may correspond to a lower threshold.

[0199] A WTRU may be configured to have one or more parameters (e.g., conditions) for sending a PRS activation request (e.g., a request to activate PRS from a TRP and / or PRS resources). One or more of the following may apply: A WTRU may decide to send an activation request to the network to activate PRS from an additional TRP if, for example, the measured RSRP associated with a PRS received from a TRP (e.g., a reference TRP) falls below a threshold. For example, the reference TRP may be configured by the network. A WTRU may decide to send an activation request to the network to activate an additional TRP if the measured RSRP for a reference PRS (e.g., a PRS pre-configured by the network) falls below a threshold. A WTRU may decide to send an activation request to the network to activate an additional TRP if the minimum, maximum, and / or average PRS for each TRP (e.g., a reference TRP) falls below a threshold. A WTRU may decide to send an activation request to the network to activate an additional TRP if the minimum, maximum, and / or average PRS resources of a configured TRP fall below a threshold. A WTRU may decide to send an activation request to the network to activate an additional TRP if it receives instructions / configurations from the network for the WTRU to request an additional TRP. For example, the instructions / configurations may include conditions (e.g., pre-configured conditions), and the WTRU may send an activation request if the conditions are met. A WTRU may decide to send an activation request to the network to activate an additional TRP if the LOS indicator / NLOS indicator for a PRS / TRP falls below / above a threshold. For example, if an LOS indicator associated with a TRP (e.g., an indication of the possibility of an LOS path existing between the WTRU and the TRP) falls below a threshold, the WTRU may send a request to the network to activate an additional TRP. As described herein, RSRP can be used interchangeably with per-path RSRP (for example, when multiple paths exist between the WTRU and the TRP).

[0200] The WTRU may, for example, determine the weight associated with each PRS activation request after the requested TRP has been activated. The WTRU may determine the weight for each TRP based, for example, on the location of the WTRU and its distance from each TRP. For example, the weight of each TRP requested for activation may sum to 1. In certain scenarios, the weight may be determined based on a ratio (e.g., the ratio of the distances between the WTRU and the TRPs). Referring to the embodiment shown in Figure 8A, if TRP 805 and / or TRP 806 are located at equal distances from WTRU 807, WTRU 807 may decide to assign the same weight, for example, 0.5, to TRP 805 and TRP 806. For example, if the distances between WTRU807 and TRP805 and TRP806 are 1 meter and 3 meters, respectively, WTRU807 may determine weights of 0.75 and 0.25 for TRP805 and TRP806, respectively (indicating WTRU807's preference to activate TRP805, which is geographically closer to WTRU).

[0201] The weights associated with a TRP can be determined based on the number of TRPs to be activated. For example, if the number of TRPs to be activated is N, and the distance between the TRPs and the WTRU is equal, the WTRU may decide to set the weight for each weight as 1 / N.

[0202] In the embodiment, the weights for a request may be determined based on an AI / ML model. For example, an AIML model may be trained in WTRU based on measurements (e.g., RSRP, RSTD) created from a PRS. For example, the target metric used during training may include a PRS configuration (e.g., TRP) and / or associated weights (e.g., 1.0 for activation, 0.0 for deactivation). The PRS configuration for activation may include a set of TRPs available for activation. A WTRU may receive a set of PRS configurations (e.g., TRP) from the network. For example, a set of PRS configurations may be obtained based on a request from the WTRU. Based on a trained AIML model, the WTRU may obtain metrics (e.g., weights) associated with the request. For example, metrics (e.g., weights) associated with the request may be obtained based on measurements taken from the PRS configuration (e.g., initial / default PRS configuration).

[0203] A WTRU may receive a PRS configuration associated with a requested TRP (for example, in response to an activation request sent to the network). A WTRU may also receive a PRS configuration and / or ACK / NACK message from the network in response to a request. For example, a PRS configuration received by a WTRU from the network may include, for example, the periodicity of the PRS, the number of symbols for the PRS, the bandwidth, and / or similar.

[0204] Figure 8B shows an embodiment associated with receiving a PRS configuration for an activated TRP (e.g., a newly activated TRP). Referring to Figure 8B, WTRU807 may be configured to receive PRS from TRP801, 802, and 803. WTRU807 may receive PRS configurations (e.g., spatial information, symbol count, periodicity, etc.) for newly activated TRPs from the network. For example, as shown in Figure 8B, WTRU807 may receive a PRS configuration for activating a PRS from TRP806. As shown, WTRU807 may not receive a PRS configuration for TRP805, which may indicate that the activation request for TRP805 was rejected (e.g., the network did not allow the request from WTRU907 to activate TRP805).

[0205] The WTRU may perform maintenance on the set of TRPs that can receive PRSs. For example, when a requested TRP is activated, the WTRU may remove the newly activated TRP from the set of configured TRPs (e.g., pre-configured TRPs), which may prevent the WTRU from requesting the TRP to be activated again.

[0206] A WTRU may send (e.g., continue sending) activation requests until one or more conditions are met. A WTRU may send (e.g., continue sending) activation requests if the set of TRPs available for activation is empty. A WTRU may send (e.g., continue sending) activation requests if the conditions for stopping sending requests are met (e.g., the RSRP of the reference PRS exceeds a threshold). A WTRU may send (e.g., continue sending) activation requests if the WTRU receives a command (e.g., a deactivation command received from the network to stop the request procedure). A WTRU may send (e.g., continue sending) activation requests until the number of acknowledgments and / or negations to activation requests sent by the WTRU exceeds a threshold. A WTRU may send (e.g., continue sending) activation requests if the time window / duration for an on-demand PRS has expired.

[0207] Figure 8C shows an embodiment associated with an activation request sent by the WTRU. One or more of the following may apply. For example, as shown in Figure 8C, WTRU807 may send another PRS activation request to the network (e.g., or a network function such as LMF 808) to activate TRP805. For example, TRP805 may not have been activated in response to a previous activation request sent by WTRU807 (e.g., as described herein with respect to Figure 8A). WTRU807 may decide to associate a weight of 1.0 with TRP805, as shown in Figure 8C, and include that weight in the PRS request sent to the network. For example, WTRU807 may assign a weight of 1.0 to TRP805 because TRP805 is the only TRP within the configured threshold (e.g., the only TRP available for activation). For example, a WTRU may periodically send activation requests (e.g., at a configured interval) until one of the conditions described herein is met. A WTRU may send requests using a configured uplink grant and / or a dynamic uplink grant.

[0208] In the embodiment, the WTRU may decide to terminate the PRS request procedure. For example, the WTRU may decide to terminate the on-demand procedure if a subset of the requested PRS configuration is permitted by the network. The WTRU may decide to send a request to cancel the activation request for the remaining subset of the PRS configuration (e.g., PRS configurations that have not yet been activated). For example, referring again to Figure 8C, WTRU807 may receive an indication that only TRP805 is activated (even though WTRU807 has requested activation of TRP806 and TRP806). In this case, if WTRU807 determines that TRP806 is activated, WTRU807 may decide to send a message to the network to terminate the PRS request procedure and / or cancel the request to activate TRP805.

[0209] In certain scenarios, a WTRU may receive a first PRS configuration from the network. A WTRU may receive a set of PRS configurations (e.g., TRP locations) from the network. Based on the first PRS configuration, a WTRU may receive PRS from one or more TRPs. A WTRU may perform measurements on the received PRS. A WTRU may determine its location based on measurements of the PRS received from the TRPs (e.g., RSRP, RSTD) using the first PRS configuration. For example, a WTRU may use an AI / ML model to determine its location. Based on the WTRU's location, the TRP locations, and / or PRS measurements, a WTRU may determine weights for each PRS configuration in the set of PRS configurations received from the network. As described herein, a WTRU may use an AI / ML model to determine weights for each PRS configuration in the set of PRS configurations from the network. For example, a WTRU may determine higher weights for PRS configurations that include TRPs closer to the WTRU location. As described herein, the weights determined for each PRS configuration in a set may sum to 1. The WTRU may send a PRS request to the network. For example, a PRS request may include the determined weights associated with each PRS configuration (e.g., each PRS configuration in the set). The WTRU may receive PRS resource configurations (e.g., PRS resources, spatial information, etc.) from the network to activate. The received PRS configurations to be activated may be based on the weights associated with the PRS requests sent by the WTRU and / or each of the PRS configurations in the set. For example, the received PRS configuration to be activated may be the one associated with the highest weight. Alternatively, the received PRS configuration to be activated may be the one associated with a weight above a threshold. The WTRU may remove PRS configurations from the set that should be activated. The WTRU may determine their location based on the received PRS resource configurations, for example. The WTRU may report their location and / or PRS configuration ID to the network.The WTRU, for example, continues to receive PRS configurations, determine their location, and report them to the network until the set or PRS configuration becomes empty.

[0210] The WTRU may decide to send a differential location. As described herein, a differential location may be defined as the difference between a location and a reference location. For example, if the coordinates of the location and the reference location are (x, y) and (x1, y1), respectively, the differential location may be represented as (x1-x, y1-y). The WTRU may decide to send the differential location and / or the reference location. One or more of the following may apply: The WTRU may decide to send the differential location and / or the reference location if the differential location is determined based on a newly activated TRP (e.g., TRP806, referring to the embodiment shown in Figures 8A-8C). Alternatively, the WTRU may decide to send the differential location and / or the reference location if the PRS configuration and reference location are determined based on an initial set of TRPs (e.g., TRP801, TRP802, TRP803, referring to the embodiment shown in Figures 8A-8C). The WTRU may decide to send the differential location and / or the reference location if the location is determined based on a combination of the newly activated TRP / PRS configuration and the initial set of TRP / PRS configurations (for example, TRP801, TRP802, TRP803, and TRP806, as shown in the embodiments in Figures 8A to 8C), and / or if the reference location is determined based on the initial set of TRP / PRS configurations.

Claims

1. A wireless transmit / receive unit (WTRU) comprising a processor and memory, wherein the processor and the memory are Configuration information indicating that the WTRU is configured to receive positioning reference signals (PRS) from a first set of one or more transmit-receive points (TRPs), wherein the configuration information includes positioning reference signal (PRS) configuration information associated with the first set of one or more TRPs, and the reception of such configuration information. Determining a metric associated with a transmit-receive point (TRP), wherein the TRP is not included in a first set of one or more TRPs, and the determined metric is The location associated with the aforementioned TRP, Location associated with the aforementioned WTRU, or The determination is based on one or more of the measured values ​​associated with the aforementioned TRP, A PRS activation request for activating the PRS from the TRP, wherein the PRS activation request includes the determined metric associated with the TRP, The WTRU is configured to receive a message from the TRP indicating that it should receive a PRS, wherein the message includes PRS configuration information associated with the TRP.

2. The metric includes weights, and the processor and the memory, The WTRU according to claim 1, configured to determine the respective weights for each TRP in a second set of one or more TRPs, the WTRU is not configured to receive PRSs from each TRP in the second set of one or more TRPs, and the PRS activation request further comprises the respective weights determined for each TRP in the second set of one or more TRPs.

3. Receiving PRS from the first set of one or more TRPs, The WTRU according to claim 1, further comprising determining the location associated with the WTRU based on the PRS received from a first set of one or more TRPs.

4. The processor and the memory, Based on the PRS received from the TRP, the estimated location associated with the WTRU is determined. The WTRU according to claim 3, configured to send instructions for the estimated location associated with the WTRU.

5. The WTRU according to claim 4, wherein the instruction for the estimated location associated with the WTRU is signaled as a difference value to the determined location associated with the WTRU, based on the PRS received from a first set of one or more TRPs.

6. The WTRU according to claim 4, wherein the estimated location associated with the WTRU is determined using an artificial intelligence / machine learning (AI / ML) model.

7. The processor and the memory, The WTRU according to claim 4, configured to send a second PRS activation request, wherein the estimated location associated with the WTRU is included in the second PRS activation request.

8. The WTRU according to claim 1, wherein the measurement associated with the TRP includes at least one of a reference signal received power (RSRP) measurement, a line-of-sight (LOS) measurement, a non-line-of-sight (NLOS) measurement, a distance measurement, or a timing measurement.

9. The WTRU according to claim 1, wherein the weight associated with the TRP is determined using an artificial intelligence / machine learning (AI / ML) model.

10. The WTRU according to claim 1, wherein the PRS configuration information includes PRS configuration information for each of the first sets of TRPs.

11. A method carried out by a wireless transmit / receive unit (WTRU), wherein the method is Configuration information indicating that the WTRU is configured to receive positioning reference signals (PRS) from a first set of one or more transmit-receive points (TRPs), wherein the configuration information includes positioning reference signal (PRS) configuration information associated with the first set of one or more TRPs, and the reception of such configuration information. Determining a metric associated with a transmit-receive point (TRP), wherein the TRP is not included in a first set of one or more TRPs, and the determined metric is The location associated with the aforementioned TRP, Location associated with the aforementioned WTRU, or The determination is based on one or more of the measured values ​​associated with the aforementioned TRP, A PRS activation request for activating the PRS from the TRP, wherein the PRS activation request includes the determined metric associated with the TRP, A method comprising: the WTRU receiving a message from the TRP indicating that it should receive a PRS, wherein the message includes PRS configuration information associated with the TRP.

12. The method according to claim 11, wherein the metric is determined using an artificial intelligence / machine learning (AI / ML) model.

13. A base station comprising a processor and memory, wherein the processor and memory transmit configuration information indicating that a wireless transmit / receive unit (WTRU) is configured to receive positioning reference signals (PRS) from a first set of one or more transmit-receive points (TRPs), the configuration information including positioning reference signal (PRS) configuration information associated with the first set of TRPs, A PRS activation request for activating a PRS from a transmit-receive point (TRP) not included in the first set of one or more TRPs, wherein the PRS activation request receives a PRS activation request including a metric associated with the TRP, A base station configured to send a message indicating that the WTRU should receive a PRS from the TRP, wherein the message includes PRS configuration information associated with the TRP.

14. The metric associated with the TRP is The location associated with the aforementioned TRP, Location associated with the aforementioned WTRU, or The base station according to claim 13, which is a metric determined based on one or more measurements associated with the TRP.

15. The base station according to claim 13, wherein the processor and the memory are further configured to determine whether to accept the received PRS activation request based on an artificial intelligence / machine learning (AI / ML) model.

Images