Adaptive On-Demand Positioning

Abstract

The 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. For example, the configuration information may include PRS configuration information associated with each of the first set of TRPs. The WTRU may determine a metric (e.g., weight, rank, etc.) associated with a TRP that is not included in the first set of one or more TRPs. For example, the metric may be determined based on a location associated with the TRP, a location associated with the WTRU, and / or measurements associated with the TRP (e.g., using an AI / ML model). The WTRU may send a PRS activation request to activate a PRS from a TRP. For example, the PRS activation request may indicate a PRS configuration that the WTRU requests to be activated and a metric associated with that PRS configuration.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 308,295, filed February 9, 2022, No. 63 / 334,729, filed April 26, 2022, and No. 63 / 409,967, filed September 26, 2022, which are incorporated by reference in their entireties herein. [Background technology]

[0002] A specific downlink (DL) and uplink (UL) positioning method is used in a specific wired / wireless communication protocol.

[0003] As described herein, a DL positioning method may refer to any positioning method that uses a DL reference signal, such as a primary synchronization signal (PRS). The WTRU may, for example, receive one or more reference signals from one or more transmission points (TPs) and measure the DL reference signal time difference (RSTD) and / or reference signal received power (RSRP). Exemplary DL positioning methods may include DL angle of departure (DL-AoD) positioning and / or DL ​​time difference of arrival (DL-TDOA) positioning. Summary of the Invention

[0004] A wireless transmit / receive unit (WTRU) may be configured to perform adaptive on-demand positioning (e.g., by sending an adaptive positioning reference signal (PRS) activation request). The WTRU may receive configuration information indicating that the WTRU is configured to receive positioning signals (PRS) from a first set of one or more transmission-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., a weight, a rank, etc.) associated with a transmission-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 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 a PRS from a TRP. For example, the PRS activation request may indicate a PRS configuration that the WTRU requests to be activated (e.g., a TRP and / or respective PRS resource to be activated). The PRS activation request may include a determined metric associated with the TRP / PRS configuration. In response to the PRS activation request, the WTRU may receive a message indicating that the WTRU will receive a PRS from the TRP. For example, the message indicating that the WTRU will receive a PRS from the TRP may include PRS configuration information associated with the TRP.

[0005] In certain scenarios, the metric associated with the TRP may include a weight. The WTRU may determine a respective weight for each TRP of the second set of one or more TRPs. The WTRU may not be configured to receive a PRS from each TRP of the second set of one or more TRPs. The PRS activation request sent by the WTRU may further include the determined respective weight for each TRP of the 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. The WTRU may receive a PRS from a TRP in a first set of one or more TRPs. The WTRU may determine a location associated with the WTRU (e.g., an estimated location of the WTRU) based on the PRS received from the first set of one or more TRPs. For example, the 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 the like). The location of the WTRU may change over time. The WTRU may estimate its location at a given time based on the received PRS. The WTRU may transmit an indication of its location. For example, the WTRU may indicate its location as a difference value (e.g., relative to a determined location associated with the WTRU based on the PRS received from the first set of one or more TRPs).

[0007] The WTRU may use an artificial intelligence / machine learning (AI / ML) model to perform positioning and / or send a PRS activation request. For example, the WTRU may use the AI / ML model to determine weights to be included in the PRS activation request. Also, or alternatively, the WTRU may use the AI / ML model to determine its location (e.g., an 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 into the AI / ML model. Based on the input, the AI / ML model may output weights to be included in the PRS activation request. Also, or alternatively, the AI / ML model may output an estimated location of the WTRU. [Brief description of the drawings]

[0008] [Figure 1A] FIG. 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] FIG. 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1D is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Diagram 2] FIG. 2 shows an embodiment associated with a neural network. [Diagram 3]FIG. 3 illustrates an embodiment associated with a WTRU requesting activation of a set PRS resources for a set of TRPs. [Figure 4] FIG. 4 illustrates an exemplary hierarchical structure associated with a PRS configuration. [Diagram 5] FIG. 5 shows an example associated with measurements and TRPs. [Figure 6] FIG. 6 illustrates an example embodiment associated with a WTRU that is configured to request PRS resources. [Figure 7A] FIG. 7A illustrates an example associated with weight determination that may be used for positioning. [Figure 7B] FIG. 7B illustrates an example associated with weight determination that may be used for positioning. [Figure 7C] FIG. 7C illustrates an example associated with weight determination that may be used for positioning. [Figure 8A] FIG. 8A shows an example associated with a threshold for activating a TRP. [Figure 8B] FIG. 8B illustrates an example associated PRS configuration for an activated TRP. [Figure 8C] FIG. 8C illustrates an example associated with an activation request for a TRP. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. Communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communications system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communications 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 filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0010] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, paging, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable, 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 wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a WTRU.

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

[0012] The base station 114a may be part of the 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), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell, for example, using beamforming to transmit and / or receive signals in a desired spatial direction.

[0013] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless 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 noted above, the communications system 100 may be a multiple access system, but may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and the WTRUs 102a, 102b, 102c in the RAN 104 / 113 may implement a radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communications protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0015] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology 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 a radio technology 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, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to and / or from multiple types of base stations (e.g., eNBs and gNBs).

[0018] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology 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), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0019] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as an office, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

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

[0021] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 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 that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may use the same RAT as the RANs 104 / 113 or a different RAT.

[0022] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based wireless technology, and a base station 114b, which may employ an IEEE 802 wireless technology.

[0023] Figure 1B is a system diagram illustrating an example 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 source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0024] The processor 118 may be a general purpose processor, a special purpose 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 functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 1B illustrates the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may 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) over 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 IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0026] 1B as a single element, 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 wireless signals over the air interface 116.

[0027] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as, for example, NR and IEEE 802.11.

[0028] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from 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). 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 and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. 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, etc. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

[0029] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components in the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For example, the power source 134 may include one or more dry 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 in lieu of, information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or may determine its location based on the timing of signals being received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by way of any suitable position determination method while remaining consistent with an embodiment.

[0031] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the 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 peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0032] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals associated with a particular subframe (e.g., for both the UL (e.g., for transmission) and the downlink (e.g., for reception) may be 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., a choke) or via signal processing via a processor (e.g., a separate processor (not shown) or the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0033] 1C is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As mentioned above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

[0034] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0035] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As shown in FIG 1C, the eNodeBs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0036] 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 foregoing elements is illustrated as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0037] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0038] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNodeB handover, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0039] The SGW 164 may be connected to a PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0040] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0041] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, in certain representative embodiments it is contemplated that such a terminal may use a wired communications interface (e.g., temporarily or permanently) with the communications network.

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

[0043] A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS to the STA may arrive through the AP and be delivered to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within the BSS may be sent, for example, through the AP, where the source STA may send traffic to the AP, which 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 (e.g., 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 an Independent BSS (IBSS) mode may not have an AP, and STAs within or using an IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad-hoc" communication mode.

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

[0045] A High Throughput (HT) STA 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] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. A 40 MHz and / or 80 MHz channel may be formed by combining multiple contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be sent to the Medium Access Control (MAC).

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

[0048] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a 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 configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the 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 active due to a STA (that only supports the 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered active even though most of the frequency band may remain dormant and available.

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

[0050] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As mentioned above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also communicate with the CN 115.

[0051] The RAN 113 may include gNBs 180a, 180b, 180c, although it will be understood that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may transmit and / or receive wireless signals to and from the WTRU 102a, for example, using multiple antennas. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or gNB 180c).

[0052] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes (e.g., including varying numbers of OFDM symbols and / or lasting varying lengths of absolute time) or transmission time intervals (TTIs) of various or scalable lengths.

[0053] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing any other RAN (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0054] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the 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, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0055] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is illustrated as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0056] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. The network slices may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 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, services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0057] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0058] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0059] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0060] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

[0062] The one or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a test scenario in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to perform testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices 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). The WTRU may receive one or more (e.g., multiple) reference signals from a transmission point (TP) and measure a DL reference signal time difference (RSTD), a reference signal received power (RSRP), a line-of-sight (LOS) measurement, a non-line-of-sight (NLOS) measurement, a distance measurement (e.g., the distance between the WTRU and a given TRP), or a timing measurement. An example of a DL positioning method is 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. The WTRU may transmit the 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 DL reference signals, such as positioning reference signals (PRS), for positioning. The WTRU may receive one or more reference signals from a transmission point (TP). The WTRU may measure 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 any positioning method that utilizes both UL and DL reference signals for positioning. In an embodiment, the WTRU may be configured to transmit an SRS to one or more transmit-receive points (TRPs), and the 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 (PRSs) transmitted from one or more TRPs. The WTRU may also be configured with measurements (e.g., RSRP, LOS, NLOS, timing, etc.) for the received PRS. The Rx-TX time difference and / or RSRP measured at the WTRU and / or the network (e.g., gNB) 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 a reference signal transmitted by a TRP and the transmission time of a reference signal transmitted from a 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 described herein, AI may refer to behaviors exhibited by machines that mimic cognitive functions in order to sense, reason, adapt, and / or act.

[0068] Machine learning (ML) may be used in certain positioning techniques. As described herein, ML may refer to a type of algorithm that solves problems based on learning through experience (e.g., data) without being explicitly programmed (e.g., a configured set of rules). Machine learning may also, or alternatively, be considered a subset of AI. Different ML paradigms may be envisioned 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 learning a function that maps one or more inputs to one or more outputs. The mapping of inputs to outputs may be based on labeled training examples, where each labeled training example may include an example pair of an input and a corresponding output. For example, unsupervised learning may include detecting patterns in a dataset that does not include existing labels. For example, reinforcement learning may include performing a sequence of actions in an environment to maximize a cumulative reward. In certain scenarios, machine learning algorithms may be implemented using a combination and / or interpolation of the above-mentioned techniques. For example, a semi-supervised learning approach may include a combination of labeled data (e.g., a small amount of labeled data) and unlabeled data (e.g., a large amount of unlabeled data) during training. In this regard, semi-supervised learning may fall between unsupervised learning (e.g., without labeled training data as described) and supervised learning (e.g., with labeled training data as described).

[0069] Neural networks may be used to implement certain positioning techniques. An example associated with a neural network 200 is shown in FIG. 2. As shown in FIG. 2, the neural network 200 may be trained, for example, by applying one or more inputs 201 and adjusting associated weights (e.g., shown as w and x in FIG. 2) such that an output 202 from the neural network 200 approaches a desired target value associated with a given input value. In certain scenarios, the neural network may include multiple layers (e.g., two layers). During training for a given input, a difference between the output and a desired value may be calculated. The difference between the output and the desired value may be used to update 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 certain scenarios, 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 weight 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 weight is expected.

[0070] As described herein, neural networks may be used in certain positioning techniques. In positioning, for example, inputs to the neural network may include reference signal parameters (e.g., RSRP measurements, WTRU location, TRP location, etc.) and outputs from the neural network may include an estimated position (e.g., an estimated position 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 may be used for positioning techniques, for example, by providing inputs to the neural network, and the output of the neural network may be an expected outcome for the associated input. For example, the output of the neural network may include an estimated position or location of the WTRU and / or weights associated with a PRS configuration (e.g., a TRP and / or PRS resources from a given TRP). An example of an estimated position may be the location of the WTRU approximately at the time the WTRU made measurements for a received PRS. The output of the neural network may also, or alternatively, include a predicted position or location of the WTRU. For example, the predicted position of the WTRU may be a future position of the WTRU.

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

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

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

[0075] As used herein, the term network may include an access and mobility management function (AMF), a location management function (LMF), a gNB, and / or a 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 "neighboring gNB", gNB and TRP, PRS and "PRS resource", PRS and "PRS resource" (e.g., PRS or PRS resource may belong to different PRS resource sets), PRS and DL-PRS or DL ​​PRS, and / or "measurement gap" and "measurement gap pattern". For example, the measurement gap pattern may include parameters such as measurement gap duration, measurement gap repetition period, and / or measurement gap periodicity.

[0076] As described herein, pre-configuration and configuration may be used interchangeably. As described herein, non-serving gNB and neighbor gNB may be used interchangeably. As described herein, gNB and TRP may be used interchangeably. As described herein, PRS and PRS resources may be used interchangeably. As described herein, PRS and PRS resources may be used interchangeably. As described herein, PRS and PRS resources may belong to different PRS resource sets. As described herein, PRS, DL-PRS, and DL PRS may be used interchangeably. As described herein, measurement gap and measurement gap pattern may be used interchangeably. For example, the measurement gap pattern may include one or more parameters such as a measurement gap duration, a measurement gap repetition period, and / or a measurement gap periodicity.

[0077] A positioning reference unit (PRU), as used herein, may include a WTRU or TRP whose location (e.g., altitude, latitude, geographic coordinates, or local coordinates) may be known by a network (e.g., gNB, LMF). For example, the capabilities of a PRU may be similar to (e.g., the same as) a WTRU or TRP configured to, for example, 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 the network for calibration purposes (e.g., to correct an unknown timing offset and / or to correct an unknown angular offset). In another example, a WTRU operating as a PRU may be configured to report measurements to the network.

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

[0079] The WTRU may be configured to receive a threshold (e.g., a preconfigured threshold) from the network (e.g., LMF, gNB, etc.). The PRS configuration may be used to indicate (e.g., indicate to the WTRU) the TRPs for which the WTRU is configured to receive the PRS. For example, the PRS configuration may indicate PRS resources associated with each of the TRPs for which the WTRU is configured to receive the PRS. A particular PRS configuration (e.g., the TRPs for which a given WTRU receives the PRS) may be configured such that the network is assumed to have certain information (e.g., the location of the WTRU) that may be used to perform the PRS and / or WTRU positioning. However, in certain scenarios (e.g., due to unexpected WTRU movement, unexpected obstructions, etc.), the network may not have knowledge of the location of the WTRU. For example, if the network does not have knowledge of the location of the WTRU), the PRS configuration may be determined using an iterative process, which may increase latency in the positioning. For example, the 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, or alternatively, be configured to send a PRS activation request for a set of PRS configurations, which may further increase the number of iterations to find an 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 in the network.

[0080] An adaptive PRS activation request 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, a PRS is used as an exemplary reference signal (RS) used for a positioning request (e.g., an on-demand positioning request). However, any DL or UL RS may also or alternatively be used for a positioning request, including, for example, a channel state information RS (CSI-RS), a demodulation RS (DM-RS), a phase tracking RS (PT-RS), a tracking reference signal (TRS), an SRS, and / or the like. PRS request and PRS activation request may be used interchangeably 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 transmitting a PRS to other WTRUs, and in other cases, a PRS activation request sent by a given WTRU may turn on a PRS from a TRP that is currently transmitting a PRS 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 PRS configuration (e.g., PRS duration) and / or whether a periodic / semi-persistent DL channel or RS is scheduled. The WTRU may determine an associated metric (e.g., weight, rank, etc.) for the request based on the latency requirement.

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

[0083] The WTRU may be configured to perform adaptive on-demand positioning (e.g., by sending an adaptive positioning reference signal (PRS) activation request). The WTRU may receive configuration information indicating that the WTRU 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). The WTRU may determine a metric (e.g., weight, rank, etc.) associated with a transmit-receive 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 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 a PRS from a TRP. For example, the PRS activation request may indicate a PRS configuration that the WTRU requests to be activated (e.g., a TRP and / or respective PRS resources to be activated). The PRS activation request may include the determined metrics associated with the TRP / PRS configuration. In response to the PRS activation request, the WTRU may receive a message indicating that the WTRU will receive the PRS from the TRP. For example, the message indicating that the WTRU will receive the PRS from the TRP may include PRS configuration information associated with the TRP.

[0084] In certain scenarios, the metric associated with the TRP may include a weight. The WTRU may determine a respective weight for each TRP of the second set of one or more TRPs. The WTRU may not be configured to receive a PRS from each TRP of the second set of one or more TRPs. The PRS activation request sent by the WTRU may further include the determined respective weight for each TRP of the 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. The WTRU may receive a PRS from a TRP in a first set of one or more TRPs. The WTRU may determine a location associated with the WTRU (e.g., an estimated location of the WTRU) based on the PRS received from the first set of one or more TRPs. For example, the 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 the like). The location of the WTRU may change over time. The WTRU may estimate its location at a given time based on the received PRS. The WTRU may transmit an indication of its location. For example, the WTRU may indicate its location as a difference value (e.g., relative to a determined location associated with the WTRU based on the PRS received from the first set of one or more TRPs).

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

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

[0088] The WTRU may be configured to receive a request (e.g., from the network) for the WTRU to return specific information associated with the positioning request (e.g., a desired / requested PRS configuration and associated weights for each PRS configuration) and a list of TRPs from which the WTRU can receive the PRS. In response to the 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 to have one or more TRPs for which the PRS should be received by the WTRU. The WTRU may perform measurements (e.g., RSRP, LOS, NLOS, timing, etc.) on the PRS received from the candidate TRPs. The WTRU may identify one or more TRPs (e.g., candidate TRPs) that are not part of one or more TRPs from which the PRS is not received. If the average RSRP of the PRS received from one or more configured TRPs is 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 of the candidate TRPs may be determined based on how close the respective candidate TRP is to the TRP having the highest RSRP. The WTRU may determine an estimated location of the WTRU based on, for example, measurements performed on PRSs received from one or more configured TRPs.

[0089] Based on information associated with each of the candidate TRPs transmitted by the WTRU, the WTRU may be configured (e.g., by the network) to have a new / updated set of TRPs for which PRSs are to be received by the WTRU. The WTRU may perform measurements (e.g., RSRP measurements) on the PRSs received from the new / updated set of TRPs. The WTRU may perform certain calculations on the measurements performed on the PRSs received from the new / updated set of TRPs. For example, if the average RSRP of the PRSs received from the updated / new set of TRPs is greater than a threshold, the WTRU may decide to terminate the on-demand PRS procedure. Also, or alternatively, the WTRU may decide to terminate the PRS activation request procedure if the number of iterations is above a threshold.

[0090] The WTRU may transmit a first PRS activation request. For example, the first PRS activation request may include an indication of 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 an indication of one or more TRPs (e.g., configured TRPs) for which the WTRU is configured to receive the PRS. The WTRU may receive the PRS from each of the one or more configured TRPs. The WTRU may perform Reference Signal Received Power (RSRP) measurements 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 metrics associated with the one or more configured TRPs. The WTRU may determine that the metrics associated with the one or more configured TRPs are below a threshold. For example, the threshold may be included in the PRS configuration information.

[0091] Based on a determination that a metric associated with one or more configured TRPs falls below a threshold, the WTRU may identify one or more candidate TRPs. For example, the one or more candidate TRPs may include a TRP closest to the TRP of the configured TRPs associated with the highest RSRP measurement value. The WTRU may determine / identify other TRPs proximate to the TRP of the one or more configured TRPs associated with the highest RSRP measurement value by determining, estimating, or otherwise ascertaining which TRP the WTRU believes to be the closest TRP to the TRP of the configured TRPs associated with the highest RSRP measurement value. The WTRU may transmit a second PRS activation request including an indication of the one or more candidate TRPs identified by the WTRU. The WTRU may estimate a location associated with the WTRU. For example, the location associated with the WTRU may be estimated based on measurements performed on PRSs 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 the second PRS activation request, the WTRU may receive updated PRS configuration information. For example, the updated PRS configuration information may include an indication of one or more updated TRPs for which the WTRU is configured to receive the PRS. The WTRU may receive the PRS from one or more (or each) of the one or more updated TRPs. The WTRU may perform RSRP measurements on the PRS received from each of the one or more updated TRPs. The WTRU may calculate metrics associated with the updated TRPs based on the measurements performed on the PRS received updated TRPs. The WTRU may determine that the metrics associated with the updated TRPs are greater than or equal to a threshold. Based on a determination that the metrics associated with the updated TRPs are greater than or equal to a threshold, the WTRU may send an on-demand PRS termination request.

[0093] The WTRU may send a request to activate PRS configuration information (e.g., a TRP, a PRS resource, a PRS resource group, etc.) based on a condition. The WTRU may receive a PRS configuration (e.g., a PRS transmission periodicity) associated with the requested PRS configuration, which may be considered as an acknowledgment to the request to activate the PRS configuration.

[0094] The WTRU may be configured to send a request to modify and / or update one or more parameters associated with a PRS (e.g., the TRP at which the WTRU receives the PRS). Such a request to modify and / or update one or more parameters associated with a PRS may be referred to herein as a PRS request. For example, the WTRU may be configured to send a PRS request to the network (e.g., LMF, gNB) to modify / update the WTRU's PRS configuration (e.g., to a requested value). The WTRU may be configured to send a PRS request to modify / update the value of at least one of the following PRS configuration parameters, for example: number of symbols, transmit power, number of PRS resources included in the PRS resource set, muting pattern for the PRS (e.g., the muting pattern may be represented by a bitmap), periodicity, type of PRS (e.g., periodic, semi-persistent, and / or aperiodic), slot offset for periodic transmission for the PRS, vertical shift of the PRS pattern in the frequency domain, time gap during repetition, repetition factor, resource element (RE) offset, comb pattern, comb size, spatial relationship or Quasi Co Location (QCL) information for the 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), starting PRB, bandwidth (e.g., bandwidth part (BWP), number of resource elements, number of resource blocks, bandwidth in Hz, etc.), BWP ID, number of frequency layers, start / end time of PRS transmission, PRS on / off indicator, TRP ID, PRS ID, cell ID, global cell ID, etc., and / or PRU ID. As 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, e.g., if / when a requested PRS configuration is to be 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., with respect to absolute time, and / or with respect to relative timing 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] The WTRU may be configured to transmit a PRS request to deactivate a particular PRS parameter. For example, the WTRU may be configured to transmit a PRS request to the network to deactivate a particular resource (e.g., a requested TRP or PRS resource). The WTRU may be configured to transmit the PRS request to deactivate the resource at an end time with respect to a (e.g., defined) frame, slot, symbol number, etc., an end time with respect to absolute time, and / or an end time with respect to relative timing with respect to a reference time (e.g., N slots from the time the request was transmitted by the WTRU and / or received by the network).

[0097] For example, to activate and / or deactivate certain PRS parameters, a PRS request may be sent, for example, via an LTE positioning protocol (LPP) message, a UL MAC control element (UL-MAC-CE), a UL downlink control information (UL-DCI), and / or an RRC message.

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

[0099] The WTRU may also or alternatively be configured to have an authorized PRS configuration set. For example, the 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 of the PRS parameters and respective values / value ranges for the PRS parameters. Each authorized PRS configuration set may also or alternatively be associated with a logical identification, and the WTRU may be configured to request a desired PRS configuration by including the logical identification of the desired PRS configuration in the authorized 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 identification of a default configuration from a default configuration set. A WTRU may also, or alternatively, be configured to indicate a desired PRS configuration by including a logical identification of 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 a specific configuration may override parameter values ​​from the default configuration.

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

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

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

[0104] With reference to the embodiment shown in FIG. 3, the WTRU 304 may be configured (e.g., via PRS configuration information) to receive PRS from TRPs 301, 302, and 303. For example, the WTRU 304 may be configured to receive PRS on PRS resources 1, 2, 3 from TRP 301, receive PRS on PRS resources 1, 2, 3 from TRP 302, and receive PRS on PRS resources 1, 2, and 3 from TRP 303. The WTRU may be configured to request a change or update to a PRS it has received, for example, by sending a PRS request. The PRS request may indicate the PRS resources on which the WTRU 304 requests to receive the PRS. The PRS request may include one or more PRS configurations. Each of the PRS configurations may be associated with a weight. For example, as shown in FIG. 3, the WTRU 304 may send a PRS request including one or a requested PRS configuration. For example, as shown in FIG. 3, the first PRS configuration 305 may request to receive a PRS on PRS resource 2 from TRP 301, on PRS resource 2 from TRP 302, and on PRS resource 2 from TRP 303. As shown in the example illustrated in FIG. 3, the PRS request transmitted by the WTRU 304 may include a second PRS configuration 306 requesting that a PRS be received on PRS resource 2 from TRP 301, on PRS resource 1 from TRP 302, and on PRS resource 2 from TRP 303. As described herein, each of the PRS configurations may be associated with a weight. As shown in FIG. 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 PRS configurations 305, 306, and / or respective weights assigned to the PRS configurations may be determined using an AI / ML model (e.g., AI / ML model 200 shown in FIG. 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. Additionally, or alternatively, locations associated with the TRPs 301, 302, 303 and / or an estimated location of the WTRU 304 may be input into the AI / ML model.Based on the input, the AI / ML model may output a PRS configuration and / or associated weights. As described herein, the WTRU 304 may use the received PRS to perform positioning. For example, the WTRU may provide measurements performed on the PRS, receiving the TRP, a location associated with the TRP, and / or the WTRU's location (e.g., a previous location) as inputs to the AI / ML model, and the AI / ML model may output an estimated location of the WTRU.

[0105] 3 illustrates an example in which the WTRU 304 sends a PRS activation request to activate a PRS from a TRP / PRS resource that is already configured to receive a PRS, it should be understood that the WTRU 304 may also send a PRS activation request for a TRP / PRS resource that is not yet configured. For example, based on measurements performed by the WTRU 304 and / or the output of an AI / ML model, the WTRU 304 may send a PRS activation request to activate a PRS from a TRP other than TRP 301, TRP 302, or TRP 303.

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

[0107] The WTRU may be configured to initiate a positioning request (e.g., an on-demand positioning request). For example, the WTRU may be configured to send a request (e.g., to the network) to initiate a positioning request procedure. In response, the network may return certain parameters (e.g., 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.) to initiate the positioning request procedure.

[0108] Also, or 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 an indication to the network after the WTRU receives the above-mentioned parameters to initiate the procedure.

[0109] The WTRU may be configured to determine if / when to send a request to initiate an on-demand positioning request. For example, the WTRU may determine 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., average RSRP of received PRSs that is less than or equal to a threshold), the number of requests the WTRU has sent to the network (e.g., above or below a threshold), the variation of certain measurements (e.g., RSRP, ToA, RSTD, angle of arrival (AoA), angle of departure (AoD) being greater than a threshold, the maximum value of weights associated with PRS parameters being below a threshold (e.g., a preconfigured threshold), the WTRU receiving a trigger from the network (e.g., via DCI) to send a (e.g., on-demand) positioning request including weights associated with the respective PRS configuration, and / or the WTRU receiving a command or signal from the network (e.g., via MAC-CE) (e.g., configured to trigger a PRS request procedure).

[0110] The WTRU may be configured to determine a set of PRS parameters to include in the PRS request. The WTRU may determine a set of parameter candidates for the request based on conditions (e.g., whether measurements needed to derive weights are available or not). For example, the WTRU may decide to request parameters that are not included in the pre-configuration (e.g., a pre-configured set of TRPs, a set of configured PRSs for which measurements are taken, etc.).

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

[0112] In certain scenarios, the WTRU may be configured to transmit a PRS request including weights for certain parameters (e.g., parameters that the WTRU is pre-configured to have). For example, the WTRU may be configured to transmit a PRS request after the WTRU performs certain measurements / calculations for a given PRS configuration (e.g., a current PRS configuration). The WTRU may be configured to derive weights for certain PRS parameters based on the measurements / calculations for 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 the PRS configurations are included in the PRS activation request, the weights may indicate and / or be used to determine a preferred / desired PRS configuration based on measurements made by the WTRU. In response to transmitting a PRS activation request including the respective weights, the WTRU may receive a new / updated configuration from the network.

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

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

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

[0116] As described herein, the 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 and may not transmit measurements to the network.

[0117] As shown in FIG. 5, the WTRU 508 may perform measurements (e.g., RSRP measurements) on PRS transmitted from one or more TRPs. The location of the WTRU may change. As the location of the WTRU changes, the WTRU may receive PRS from one or more TRPs. For example, as shown in FIG. 5, the WTRU 508 may be configured to measure RSRP from three TRPs, TRPs 504, 505, and 506. With reference to FIG. 5, at t=0, the WTRU 508 may be at location 0, and the WTRU 508 may measure RSRPs of −30 dBm, −40 dBm, and −60 dBm from TRPs 504, 505, and 506, respectively.

[0118] At t=T, the WTRU 508 may be at location 1.5, and the WTRU 508 may measure RSRPs of −30 dBm, −30 dBm, and −60 dBm from TRP 505, TRP 506, and TRP 507, respectively. The RSRP measurements performed by the WTRU 508 may be used as training data. For example, the RSRP measurements may be input into an AI / ML model. Also, or alternatively, the location of each TRP and / or an estimated location of the WTRU 508 may be input into an AI / ML model. Based on the input, the AI / ML may output a weight associated with each of the TRPs. The WTRU 508 may then transmit a PRS request using the weights as described herein.

[0119] The WTRU may be configured to determine a set (e.g., an initial set) of TRPs 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 initial candidates for requesting a PRS, which may be based on TRPs that are not part of the training data. Referring again to FIG. 5, the WTRU 508 may not perform measurements on a PRS from TRP 503, and as a result, measurements of TRP 503 may not be included in the training data. If TRP 503 is not included in the training data, the WTRU 508 may determine (e.g., based on measurements associated with PRSs received from the WTRU 508) to include TRP 503 in the initial set of candidates for the PRS request. Similarly, since TRP 504 is not included in the training data, the WTRU 508 may also determine to include TRP 504 in the initial set of candidates for the PRS activation request.

[0120] The WTRU may determine a weight associated with a given TRP, for example, based on measurements (e.g., RSRP measurements) performed by the WTRU. Referring again to FIG. 5, for example, if the WTRU 508 is located at location −0.5, the WTRU may be configured to send a PRS request to the network (e.g., LMF) to transmit a PRS from TRP 503 and / or TRP 504. Based on the measurements, the WTRU 508 may determine that the RSRP from the PRS received from TRP 504 is larger (e.g., larger than the PRS received from TRP 503). The WTRU 508 may also, or alternatively, determine that there is a higher probability of measuring a higher RSRP from TRP 504 (e.g., as opposed to TRP0). Based on the respective measurements, the WTRU 508 may be configured to determine weights associated with TRP 503 and TRP 504. And based on determining 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, the WTRU may determine weights associated with various PRS configurations. For example, the WTRU may determine weights associated with TRP candidates based on differences between measurements and training data. There may be a correlation between the training data and PRS measurements. For example, there may be training data (e.g., as shown in FIG. 5) and measurements (e.g., as shown in FIG. 6). The WTRU may determine that a PRS measurement from one TRP is likely to be higher than another TRP, and the WTRU may determine that a weight for a TRP with a higher PRS measurement is likely to be greater than a weight for a TRP with a lower PRS measurement.

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

[0123] The WTRU may determine a weight associated with a PRS resource (e.g., a beam) based on a line-of-sight (LOS) indicator. For example, if the LOS indicator indicates a 50% probability of the existence of multiple paths, the WTRU may be configured to transmit a request for multiple beams, each of which is associated with an equal weight.

[0124] The WTRU may determine a weight associated with the TRP candidates based on the distance of each TRP candidate from a TRP transmitting a PRS with a higher (eg, highest) RSRP.

[0125] The WTRU may receive a weight configuration from the network. For example, the WTRU may receive a configuration from the network and return a value of either 0 or 1 associated with a given PRS configuration. Also, or alternatively, the WTRU may receive a range of weight values. For example, the 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). The WTRU may be configured to have weights, for example, based on the capabilities of the WTRU. For example, if the WTRU reports a capability that can only return 0 or 1, the WTRU may be configured (e.g., by the network) to indicate a weight of either 0 or 1.

[0126] The WTRU may be configured to determine weights associated with particular PRS parameters associated with unobserved PRS resources. In certain scenarios, the WTRU may be configured to send a request (e.g., to the network) for a PRS from a resource not measured by the WTRU. Before sending the request, the WTRU may receive spatial information from the network regarding the PRS resource. For example, the spatial information may indicate a direction in which the PRS is transmitted from the gNB or TRP. Examples of spatial information include association of the 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 in a similar (e.g., same) direction from the gNB. The WTRU may also, or alternatively, receive spatial relationship information associating a PRS resource ID and an SRS resource ID, which may indicate that the PRS and SRS are transmitted in a similar (e.g., same) direction from the gNB and the WTRU, respectively. The WTRU may receive spatial relationship information or QCL information (eg, QCL-D, which indicates quasi-co-location information of multiple reference signals and / or channels) from the network.

[0127] The spatial information may include boresight information. For example, boresight information may be provided for each PRS resource from the network. The boresight 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 related to beam width or beam characteristics for each PRS resource (e.g., relative power difference per angle for each PRS resource). The WTRU may also receive an expected AoD and / or an expected AoA for the PRS resource.

[0128] Based on the received spatial information, the WTRU may be configured to determine to send a PRS request including the associated weight to the network. 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] With reference to FIG. 6, for example, the WTRU 602 may be configured with one or more PRS resources. For example, the WTRU 602 may be configured with PRS resources #1, #2, and #3 from the TRP 601, where each of the PRS resources #1, #2, and #3 belongs to PRS resource set #1 (indicated by vertical lines in FIG. 6). The WTRU 602 may also be configured with PRS resources #4 and #5 from the TRP 601, where each of the PRS resources #4 and #5 belongs to PRS resource set #2 (indicated by horizontal lines in FIG. 6). As shown in FIG. 6, each of the PRS resources #1, #2, #3, #4, and #5 may be received from the TRP 601. The WTRU 602 may be configured to perform WTRU-based positioning and may receive spatial information related to the PRS resources. The WTRU 602 may perform measurements (e.g., RSRP measurements) on the PRS resources #1, #2, and #3. For example, the WTRU 602 may measure a higher RSRP from PRS resources #2 and #3 compared to PRS resource #1. Based on the measurements (e.g., RSRP) and spatial information for each PRS resource, the WTRU 602 may be configured to determine that PRS resource #5 may result in a higher RSRP than PRS resource #4. For example, as described herein, the WTRU 602 may use an AI / ML model to determine that PRS resource #5 may result in a higher RSRP than PRS resource #4. The WTRU 602 may send a PRS request to the network to activate PRS resources #4 and #5. For example, the PRS request sent by the WTRU 602 may include the determined weights for each PRS resource (e.g., 0.2 for PRS resource #4 and 0.8 for PRS resource #5).

[0130] The WTRU may be configured to determine to request PRS resources (e.g., PRS resources from one or more TRPs) that fall within a particular AoD / AoA (e.g., expected AoD / AoA of a received PRS resource). The PRS resources requested by the WTRU may belong to the same or different resource sets and / or same or different TRPs from PRS resources. Referring again to FIG. 6, for example, the WTRU 602 may receive, for example, PRS resource #1 and PRS resource #2, and the WTRU 602 may measure a higher RSRP for PRS resource #1. Based on the expected AoD for PRS resource #1 and PRS resource #2, the WTRU 602 may be configured to determine 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). The WTRU 602 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, the WTRU 602 may be configured to determine to associate a higher weight with PRS resources #3 and #4 compared to PRS resources #5 and #6. Also, or alternatively, the WTRU 602 may be configured to transmit a request to activate PRS resources #3, #4, #5, and #6 based on the measured RSRP. As described herein, the request to activate PRS resources #3, #4, #5, and #6 transmitted by the WTRU 602 may include the determined weights for the respective PRS resources (e.g., the weights for PRS resources #3, #4, #5, and #6 are 0.4, 0.4, 0.1, 0.1, respectively).

[0131] The WTRU may be configured to determine to request PRS resources based on a particular indicator associated with the PRS resource. For example, the WTRU may be configured to determine to request PRS resources based on a LOS indicator associated with the PRS resource. The WTRU may receive a particular indicator associated with the PRS resource, including, for example, a LOS indicator. Referring again to FIG. 6, for example, if PRS resource #1 is associated with a LOS indicator of 1, the WTRU 602 may determine that a LOS path exists along the direction of PRS resource #1. However, if the LOS indicator is 0.1, the WTRU 602 may determine that a LOS path along the direction of PRS resource #1 is unlikely to exist. The WTRU 602 may receive signals from PRS resource #1 and PRS resource #2. The 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, the WTRU 620 may determine that PRS resources #3 and #4 fall within the expected AoD of PRS resource #1 (e.g., the beams associated with PRS resources #3 and #4 are narrower than the beam associated with PRS resource #1). The WTRU 602 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 resource #1 and PRS resource #2 and spatial information associated with PRS resource #3, PRS resource #4, PRS resource #5, and PRS resource #6, the WTRU 602 may assign a higher weight to PRS resources #3 and #4 compared to PRS resource #5 and PRS resource #6 in the request.

[0132] 6 shows an example in which the WTRU 602 is configured to receive PRS from a single TRP 601, it should be understood that the WTRU 602 may also be configured to receive PRS from multiple TRPs (e.g., as described herein). Similarly, a PRS resource set may also, or alternatively, include PRS resources from one or more TRPs.

[0133] The WTRU may decide to send a PRS request, for example, when the WTRU is configured with multiple PRS resource sets (e.g., one resource set includes PRS resources with a wide beam and another resource set includes PRS resources with a finer beam). The WTRU may decide to send a request to terminate the PRS request procedure. For example, the WTRU may decide to send a request to terminate the 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 beamwidth).

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

[0135] The WTRU may send a PRS request 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 refer to 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 the WTRU's request, the turned on TRPs may transmit a PRS to the WTRU. The turned off TRPs may not transmit a PRS to the WTRU. The PRS request sent by the WTRU may assign / associate a weight to each of the TRPs, and the respective weight of the TRP may indicate whether the TRP should transmit the PRS. For example, if the WTRU is configured to perform measurements on PRSs received from multiple TRPs (e.g., TRP1, TRP2, and TRP3), the PRS request sent by the WTRU may indicate which TRP should transmit the PRS using the associated weight. For example, a PRS request may include weights of 1.0 for TRP1, 0.2 for TRP2, and 0 for TRP3. By sending such a PRS request, the WTRU may indicate that TRP1 should not transmit a PRS, but that TRP3 should continue to transmit a PRS (e.g., with high certainty). Similarly, such a PRS request may indicate that TRP2 should continue to transmit a PRS, but the certainty associated with TRP2 may be less (e.g., slightly less) than the certainty associated with TRP3.

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

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

[0138] The WTRU may perform a priority-based weight determination for the TRP. One or more of the following may be applied. For example, the WTRU may determine a weight for a PRS request based on a PRS priority level. The WTRU may receive a PRS priority level from the network (e.g., via a configuration associated with the PRS). If the priority level is high, the WTRU may decide to process the PRS measurement with a higher priority (e.g., compared to other DL signals or channels, such as PDCCH, PDSCH, etc.). The WTRU may determine to associate a weight for the request associated with the PRS parameter if the PRS priority level is high. For example, if 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 weight associated with the request. If the PRS priority level is low, the WTRU may decide to send a PRS request without an associated weight (e.g., due to lack of time to perform measurements).

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

[0140] The WTRU may request that additional positioning techniques be employed, e.g., to improve accuracy. One or more of the following may apply: The WTRU may transmit a request for a particular positioning technique that is associated with / assigned a weight. For example, the WTRU may be configured with a DL positioning method (e.g., DL-TDOA). Based on measurements performed on the PRS and / or the WTRU's estimated location, the WTRU may determine that additional positioning should be used, e.g., to improve the accuracy of the WTRU's location estimate. Based on such a determination, the WTRU may request an additional positioning technique, e.g., a PRS request using dedicated PRS resources (e.g., phase-based positioning).

[0141] The WTRU may assign a weight to a request for additional positioning techniques. For example, the WTRU may determine a weight assigned to the request based on a quality / accuracy associated with a location estimate obtained from a previous positioning technique. For example, if a standard deviation of a location estimate obtained from a previous positioning technique is equal to or greater than a preconfigured threshold, the WTRU may transmit a request for an additional positioning technique (e.g., phase-based positioning). The WTRU may determine a weight associated with the request for the additional positioning technique based on the standard deviation of the location estimate obtained from the previous positioning technique. In a particular implementation, the WTRU may be configured (e.g., preconfigured) with a table that associates a range of standard deviations with respective weights. For example, if the standard deviation is lower, the WTRU may associate / assign a lower weight to the request for the 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, the WTRU may determine to send a request for additional positioning techniques based on RSRP measurements. For example, if the average RSRP of the received PRS resources is greater than or equal to a threshold (e.g., a preconfigured threshold), the WTRU may determine to send a request for additional positioning techniques. As described herein, the weight associated with / assigned to the request for positioning techniques may be based on a configured (e.g., preconfigured) association rule between the range of RSRP and the weight value.

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

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

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

[0146] The WTRU may associate / assign a weight to a request for a MG or PRS processing window. For example, the associated weight value may be determined based on the latency requirement and / or the frequency of the scheduled PDSCH or PDCCH. For example, if the WTRU is configured with periodic reception of the PDSCH, the WTRU may determine 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 may not receive a downlink channel, which may allow the WTRU to perform PRS measurements. In certain implementations, the WTRU may associate a weight (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 with periodic or semi-persistent DL signals, PDCCH, and / or PDSCH, the WTRU may transmit a request for a PRS processing window. The WTRU may determine a weight associated with the processing window request based on the frequency of the scheduled DL signal, PDSCH, and / or PDCCH. If the frequency of the scheduled PDSCH or PDCCH is equal to or greater than a threshold (e.g., a preconfigured threshold), the WTRU may assign a weight of 1.0 to the PRS processing window request, which may indicate a higher demand for a PRS processing window from the WTRU. The WTRU may determine a weight for the request based on a configured (e.g., preconfigured) association rule between the frequency of the scheduled PDSCH / PDCCH and a weight value. For example, the configured association rule may assign a higher weight value to a higher frequency value for the scheduled PDSCH / PDCCH. As described herein, the frequency of the 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 that the downlink channel occupies within the time window, the WTRU may determine the frequency of the scheduled PDSCH and / or PDCCH.

[0148] In a particular implementation, the assigned weight value may depend on the latency requirement for positioning. For example, if the latency requirement is below a (e.g., preconfigured) threshold, the WTRU may transmit a MG request. If the latency requirement is equal to or greater than the threshold, the WTRU may make a PRS processing window request. The WTRU may determine an associated weight for the request based on an (e.g., preconfigured) association rule between latency and weight. For example, the WTRU may be configured (e.g., preconfigured) with a latency range and a corresponding weight. 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 1 second to 10 seconds, the corresponding weight may be 0.5.

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

[0150] For example, the WTRU may decide to send a request for an SRSp configuration based on RSRP measurements made on the PRS. If the RSRP corresponding to the PRS resource is above a (e.g., preconfigured) threshold, the WTRU may decide to request a particular SRSp configuration, e.g., having a higher time and / or frequency density. If the RSRP corresponding to the PRS resource is equal to or below a (e.g., preconfigured) threshold, the WTRU may decide to request a particular SRSp configuration, e.g., having a lower time and / or frequency density. For example, the WTRU may be configured (e.g., preconfigured) with an association rule between the SRSp configuration and the range of the RSRP for the DL PRS resource. In a particular implementation, if the RSRP of the PRS resource falls within a range of -70 dBm to -60 dBm, the corresponding repetition factor for the SRSp may be 4. In a particular implementation, if the RSRP of the PRS resource falls within a range of -60 dBm to -50 dBm, the corresponding repetition factor for the SRSp may be 2. The WTRU may determine the repetition factor for the SRSp according to the rule. The WTRU may receive a configuration associating PRS resources and SRSp resources. The WTRU may decide to send a request for a configuration for SRSp resources based on measurements made on the associated PRS resources. The WTRU may associate a weight to the request, e.g., based on measurements of the PRS. For example, the WTRU may associate a weight to the request based on characteristics (e.g., statistical characteristics) of the RSRP measurements on the PRS (e.g., RSRP standard deviation, RSRP variance). The WTRU may be configured with a range of RSRP standard deviation and a corresponding weight association rule. The WTRU may determine the weight value based on the association rule.

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

[0152] The training data may be associated with certain information including timing information (e.g., a timestamp). For example, if the training data is associated with a timestamp, the WTRU may be configured to associate the timestamp with the estimated location, which may indicate to the network how the estimated location was determined by the WTRU. The WTRU may also, or alternatively, be configured to associate the estimated location with the method used to determine the location estimate. For example, the WTRU may indicate to the network the type of AI / ML model (e.g., supervised, unsupervised, and semi-supervised) used to determine the estimated location. The WTRU may also include a timestamp in the PRS request (e.g., a request from the WTRU to the network for a new / updated PRS configuration) 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 certain information associated with the AI / ML model used to determine the estimated location. For example, the WTRU may be configured to include in the PRS request the amount of data (e.g., number of measurements, duration of training, etc.) that the AI / ML model acquired and / or processed to determine the estimated location.

[0154] The WTRU may be configured to determine weights for the PRS parameters based on a predicted location of the WTRU. An example of a predicted location may include, for example, the location of the WTRU 10 ms from a current time. The predicted location of the WTRU may be determined by the WTRU based on a mobility model. The WTRU may be configured (e.g., pre-configured) with one or more mobility models, including, for example, linear, curved trajectory models, by the network. Based on the trajectory model, for example, the WTRU may be configured to determine a predicted location of the WTRU in a prediction interval T (e.g., expressed in terms of a number of seconds, symbols, slots, subframes, or frames) from the current time. For example, the prediction interval T may be configured (e.g., by the network). Based on the predicted location of the WTRU, the WTRU may be configured to determine weights and associate the determined weights with particular 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, the PRS parameters and associated weights may be included in a PRS parameter reconfiguration request.

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

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

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

[0158] As shown in FIG. 7A, the WTRU 703 may be configured to receive PRS from TRPs 706, 707, 708. The WTRU may perform measurements (e.g., RSRP measurements) on the PRSs received from TRPs 706, 707, 708. For example, in the embodiment shown in FIG. 7A, the WTRU 703 may measure RSRPs of −40, −60, and −60 for TRPs 706, 707, and 708, respectively. An estimated location associated with the WTRU 703 may then be determined based on the RSRP measurements. For example, as shown in FIG. 7A, the estimated location of the WTRU 703 may be determined to be position 1. As described herein, the WTRU may determine the estimated location using an AI / ML model. For example, each measurement (e.g., RSRP measurement) and / or location associated with the TRP may be input into 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 models may be installed / implemented in the WTRU and / or another device (e.g., a device associated with a network or network function).

[0159] As shown in FIG. 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, 705. The WTRU 703 may assign a weight to each of the TRPs included in the PRS request and include the weights in the PRS request. For example, as shown in FIG. 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 the TRP may be input into 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 the network or a network function). For example, if the AI / ML is implemented in another device (e.g., a device associated with a network or network function), the WTRU may transmit information input into the AI / ML model to the other device.

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

[0161] 7A, if the WTRU703 is configured with a threshold of 0.4 and the WTRU returns decision weights of 0.4 and 0.6 for TRP704 and TRP705, respectively, the network may configure both TRP704 and TRP705 to transmit PRS to the WTRU703. The WTRU703 may send a PRS request to the network to stop PRS transmissions from TRP707 and TRP708 (e.g., because TRP707 and TRP708 are associated with the lowest measured RSRPs, as shown in FIG. 7A).

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

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

[0164] The WTRU may include additional PRS parameters in the PRS request. For example, as described herein, the WTRU may include weights associated with the TRPs that the WTRU requests the network to activate (e.g., receive a PRS from) in the PRS request. The WTRU may also include a periodicity value for PRS transmission from the requested TRP in the PRS request (e.g., such that, upon activation, the PRS may be transmitted from the requested TRP with a defined / requested periodicity). The 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, the WTRU 703 may receive an updated TRP / PRS configuration, for example, based on the PRS request sent by the WTRU 703 of Figure 7B. For example, the updated TRP / PRS configuration may activate a PRS from TRP 704. As shown in Figure 7C, the WTRU 703 may receive the PRS received from TRPs 704, 705, 706 and perform measurements on the PRS. The WTRU 703 may measure RSRPs of -30dbm, -60dbm, and -40dbm for TRPs 704, 705, and 706, respectively. The location of the WTRU 703 may be estimated to be position 0.

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

[0167] The WTRU may be configured with a PRS request limit. For example, the WTRU may be configured to have a PRS request limit (e.g., a maximum number of PRS requests that may be sent by the WTRU). The WTRU may be configured to terminate the PRS activation request procedure (e.g., by sending a termination request as described herein), for example, 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 latest PRS configuration (e.g., the most recent PRS configuration that the WTRU received from the network).

[0168] The WTRU may be configured to perform weight validation. As described herein, the WTRU may determine weights associated with particular PRS parameters based on, for example, an AI / ML algorithm, past measurements, and / or preconfigured data. The WTRU may also be configured (e.g., by the network) with a validation period or area. If the WTRU is configured by the 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 for additional training data for the AI / ML algorithm from the network (e.g., additional PRS configurations for which the WTRU may perform measurements). The WTRU may perform measurements on additional PRS configurations that may be used as training data for the AI / ML algorithm, as described herein. The WTRU may determine weights associated with the PRS parameters based on an AI / ML algorithm that incorporates the additional training data.

[0169] The WTRU may decide to send a PRS request to a TRP that is not included in the WTRU's PRS configuration. As described herein, the WTRU may be configured (e.g., pre-configured) with a set of PRS parameters from which the WTRU may select. The WTRU may indicate or include the selected PRS parameters in the PRS request. For example, the WTRU may decide to send a PRS request based on the pre-configured PRS parameters (e.g., the WTRU assigns a weight of 1 to the selected PRS parameters in the pre-configured set). The WTRU may also, or alternatively, decide to send a PRS request for a TRP that is not included in the set of pre-configured PRS parameters. For example, the WTRU may receive a pre-configuration for a list of TRPs that includes TRP0, TRP1, and TRP2. The WTRU may decide to send a PRS request to the network to activate PRS from TRP0, TRP1, and / or TRP2. However, the WTRU may decide to send a PRS request to activate PRS from TRP3 and TRP4, which may be outside the pre-configuration. The WTRU may, 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 a system information block (SIB) or LPP message, which may include an indication from the network (e.g., an assistance data request message) regarding whether a PRS request within a preconfigured list of PRS parameters or outside of a preconfigured list of PRS parameters may be transmitted.

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

[0171] The WTRU may be associated with valid and / or invalid PRS configurations. For example, a PRS configuration may be invalid due to expiration of an associated timer and / or the WTRU is in an area where the PRS configuration is not associated with a validity area (e.g., the PRS configuration is not associated with the cell in which the WTRU is located). The WTRU may decide to associate weights to PRS configurations that are not part of the valid PRS configurations.

[0172] As described herein, the WTRU may be configured to initiate and / or terminate a PRS activation request procedure. For example, the WTRU may transmit PRS requests periodically, semi-persistently, and / or aperiodically. The WTRU may terminate a PRS activation request procedure, for example, in response to one or more conditions.

[0173] The WTRU may be configured (e.g., by the network) to transmit a PRS activation request periodically, semi-persistently, and / or periodically. For example, the WTRU may be configured with a periodicity (e.g., opportunity) of PRS request transmission by the network. When the WTRU decides to transmit a PRS activation request (e.g., as described herein), the WTRU may determine to transmit a PRS request including an associated weight based on the configured periodicity.

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

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

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

[0177] In another embodiment, the WTRU may receive a configuration from the network for a time window during which the WTRU may make an on-demand request for a PRS configuration. The configuration related to the time window may be a start time and / or end time of the window, a duration of the window (e.g., in terms of symbols, slots, frames, milliseconds).

[0178] The WTRU may be configured to perform a PRS activation request procedure for a particular period of time. For example, the WTRU may start / initiate a timer when the WTRU initiates a PRS activation request procedure (e.g., in response to receiving an activation command over the MAC-CE). The WTRU may receive an expiration time of the timer, which may indicate a period during which the WTRU may perform a PRS activation request procedure. While the timer is active, the WTRU may transmit a PRS activation request including the associated weight as described herein (e.g., with a configured periodicity). After the timer expires, the WTRU may terminate the on-demand request procedure.

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

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

[0181] In certain scenarios, the WTRU may send a PRS activation request to the network in response to one or more of the conditions for triggering a PRS activation request being met. As described herein, the conditions that trigger a PRS activation request procedure may be configured by the network. The WTRU may also, or alternatively, send a PRS activation request in the absence of a preconfigured condition.

[0182] The WTRU may receive an instruction from the network to provide certain information associated with the PRS activation request procedure. For example, the WTRU may receive a request to return a PRS request including an associated weight associated for the requested PRS configuration and a list of TRPs from which the WTRU may receive the PRS and their respective locations. The WTRU may be configured with a set of TRPs from which it may receive / request the PRS. The WTRU may perform measurements (e.g., RSRP measurements) on the PRS from the respective TRPs. The WTRU may determine that one or more TRPs (e.g., TRPs from which the PRS is received / measured by the WTRU) that are not part of the set configured TRPs are candidate TRPs. If the average RSRP of the PRS received from the configured TRPs is below a threshold, the WTRU returns a respective weight for each of the candidate TRPs to the network. For example, the respective weight for each of the candidate TRPs may be determined by the WTRU based on the proximity of a given TRP to the WTRU (e.g., how close the given TRP is to the TRP with the highest measured RSRP). Based on this information, the WTRU may determine and return an estimated location of the WTRU. Based on the estimated location of the WTRU, the WTRU may receive a new / updated set of TRPs on which to receive the PRS. The WTRU may receive each PRS from the updated set of TRPs and perform measurements thereon. The WTRU may continue to measure the PRS, determine a set of candidate TRPs, and determine an estimated location / location of the WTRU until the average RSRP of the set of configured TRPs exceeds a threshold. The WTRU may maintain the number of iterations that the WTRU measures the PRS, determines a set of candidate TRPs, and determines an estimated location / location. If the number of iterations exceeds a 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., 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, a timer associated with the PRS activation request procedure expires, there are no more PRS parameters (e.g., TRPs) to associate weights with, 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. Also, or alternatively, after the WTRU completes the on-demand PRS procedure, the WTRU may decide to send a request for a particular PRS parameter or a particular set of PRS parameters. The WTRU may decide to use the PRS configuration that the WTRU receives from the network.

[0185] The WTRU may decide to terminate the PRS activation request procedure. If the WTRU decides to terminate the PRS activation request procedure (e.g., in response to receiving a rejection message from the network), the WTRU may use: a default positioning procedure (e.g., on-demand and / or non-on-demand PRS procedure), a default PRS configuration, and / pr or previous PRS configuration. If the 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 the WTRU decides to terminate the PRS activation request procedure, the WTRU may send a request for a particular PRS configuration parameter or parameter set (e.g., without an associated weight).

[0186] As described herein, the network may reject the PRS activation request, for example, by sending a rejection message to the WTRU. For example, the rejection message from the network may be explicit or implicit. The WTRU may receive an explicit rejection message in response to sending a PRS activation request to the network. The WTRU may receive a rejection message associated with one or more of the PRS parameters that the WTRU sends to the network. For example, the 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, for example, if 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 preconfigured time window). The WTRU may start / initiate a timer after the WTRU sends a PRS activation request to the network. If the WTRU does not receive a PRS configuration before the timer expires, the WTRU may determine that the PRS activation request has been rejected by the network.

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

[0189] After the WTRU transitions from WTRU-based to / from WTRU-assisted positioning, the WTRU may transmit certain measurements. For example, the measurements may be based on PRS parameters configured by the network. The 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 the WTRU performs measurements on a received PRS and returns them to the network. The WTRU may be configured with a semi-persistent and / or aperiodic PRS, and the WTRU may perform measurements on the 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 may 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., the hierarchical structure 400 shown in FIG. 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 a first (e.g., initial) PRS configuration received from the network, the WTRU may determine the location of the WTRU. Based on the location of the WTRU, the WTRU may determine which TRPs to activate for PRS transmission. The WTRU may receive a set of TRPs for which PRS transmissions should be activated. The WTRU may determine which TRPs to activate from the set. The WTRU may send a PRS configuration request to configure one or more PRS parameters other than the TRPs, e.g., a frequency layer, PRS resources, a PRS resource set, and / or the like.

[0192] In a particular scenario, the 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, the WTRU may request to activate a TRP. As an acknowledgement message from the network (e.g., LMF, gNB), the WTRU may receive a PRS configuration (e.g., number of PRS symbols / slots, periodicity, spatial information) associated with the activated TRP from the network. In another example, the WTRU may request to activate one or more frequency layers. As an acknowledgement message to the request to activate the frequency layers, the WTRU may receive a PRS configuration associated with the activated frequency layers from the network.

[0193] The WTRU may 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 FIG. 4). In a particular scenario, the WTRU may send a request to activate one or more frequency layers. The WTRU may receive a list of TRPs that may be activated under the activated frequency layers, which may be considered an acknowledgment to the activation request. The WTRU may further determine which TRPs in 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 a PRS configuration associated with the activated TRPs from the network, which may be considered an acknowledgment to the TRP activation request.

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

[0195] The WTRU may use criteria (e.g., selection criteria) for selecting a TRP to activate. One or more of the following may be applied: The selection criteria for a TRP may be based on the distance between the TRP and the location of the WTRU (e.g., the current location of the WTRU). For example, the WTRU may decide to activate a TRP whose distance from the WTRU location is equal to or less than a threshold, e.g., as shown in FIG. 8A.

[0196] As shown in FIG. 8A, the WTRU 807 may be configured (e.g., initially configured) with TRP 801, TRP 802, and TRP 803. The WTRU 807 may decide to send a PRS request to the network to activate additional TRPs. The WTRU 807 may determine its location based on measurements made on PRSs transmitted from TRP 801, TRP 802, and TRP 803, for example, using techniques described herein (e.g., AI / ML models). The WTRU 807 may decide to send a request to the network to activate TRP 805 and / or TRP 806, for example, based on a threshold (e.g., a preconfigured threshold) indicated by a circle in FIG. 8A. For example, the threshold may be a distance threshold and / or a measurement (e.g., RSRP) threshold. As shown in FIG. 8A, the WTRU 807 cannot decide to activate TRP 804 because it is outside the threshold.

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

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

[0199] The WTRU may be configured with one or more parameters (e.g., conditions) for sending a PRS activation request (e.g., a request to activate a PRS and / or PRS resources from a TRP). One or more of the following may apply: The WTRU may determine to send an activation request to the network to activate a PRS from an additional TRP, for example, if a measured RSRP associated with a PRS received from a TRP (e.g., a reference TRP) is below a threshold. For example, the reference TRP may be configured, for example, by the network. The WTRU may determine to send an activation request to the network to activate an additional TRP, for example, if a measured RSRP associated with a reference PRS (e.g., a PRS preconfigured by the network) is below a threshold. The WTRU may determine to send an activation request to the network to activate an additional TRP, for example, if a minimum, maximum, and / or average PRS per TRP (e.g., a reference TRP) is below a threshold. The WTRU may decide to send an activation request to the network to activate additional TRPs if the minimum, maximum, and / or average PRS resources of the configured TRPs are below a threshold. The WTRU may decide to send an activation request to the network to activate additional TRPs if the WTRU receives an instruction / configuration from the network to request additional TRPs. For example, the instruction / configuration may include a condition (e.g., a preconfigured condition), and the WTRU may send an activation request if the condition is met. The WTRU may decide to send an activation request to the network to activate additional TRPs if a LOS indicator / NLOS indicator for the PRS / TRP is below / above a threshold. For example, the WTRU may send a request to the network to activate additional TRPs if a LOS indicator associated with the TRP (e.g., an indication that a LOS path between the WTRU and the TRP may exist) is below a threshold. As described herein, RSRP may be used interchangeably with per-path RSRP (eg, when multiple paths exist between the WTRU and the TRP).

[0200] The WTRU may determine a weight associated with each PRS activation request, for example, after the requested TRPs are activated. The WTRU may determine a weight for each TRP based on, for example, the location of the WTRU and the distance from the respective TRP. For example, the weights of each of the TRPs 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 distance between the WTRU and the TRP). With reference to the example shown in FIG. 8A, if TRP805 and / or TRP806 are located at equal distances from the WTRU807, the WTRU807 may determine to assign the same weight, for example, 0.5, to TRP805 and TRP806. For example, if the distance between WTRU807 and TRP805 and TRP806 is 1 meter and 3 meters, respectively, then WTRU807 may determine weights for TRP805 and TRP806 of 0.75 and 0.25, respectively (e.g., indicating a preference of WTRU807 to activate TRP805, which is geographically closer to the WTRU).

[0201] The weights associated with the TRPs may 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 distances between the TRPs and the WTRU are equal, the WTRU may determine to set the weight for each weight as 1 / N.

[0202] In an embodiment, weights for the request may be determined based on an AI / ML model. For example, an AIML model may be trained in the WTRU based on measurements made from a PRS (e.g., RSRP, RSTD). For example, a 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). A PRS configuration to activate may include a set of TRPs that are available for activation. The WTRU may receive a set of PRS configurations (e.g., TRPs) from the network. For example, the set of PRS configurations may be based on a request from the WTRU. Based on the trained AIML model, the WTRU may obtain a metric (e.g., weight) associated with the request. For example, the metric (e.g., weight) associated with the request may be based on measurements made from a PRS configuration (e.g., initial / default PRS configuration).

[0203] The WTRU may receive a PRS configuration associated with the requested TRP (e.g., in response to an activation request sent to the network). The WTRU may receive a PRS configuration and / or an ACK / NACK message corresponding to the request from the WTRU (e.g., from the network). For example, the PRS configuration that the WTRU receives from the network may include, for example, a periodicity of the PRS, a number of symbols for the PRS, a bandwidth, and / or the like.

[0204] FIG. 8B illustrates an example associated with receiving a PRS configuration for an activated TRP (e.g., a newly activated TRP). With reference to FIG. 8B, a WTRU 807 may be configured to receive PRS from TRPs 801, 802, 803. The WTRU 807 may receive a PRS configuration (e.g., spatial information, number of symbols, periodicity, etc.) for the newly activated TRP from the network. For example, as shown in FIG. 8B, the WTRU 807 may receive a PRS configuration for activating a PRS from TRP 806. As shown, the WTRU 807 may not receive a PRS configuration for TRP 805, which may indicate that the activation request for TRP 805 has been rejected (e.g., the network did not allow a request from the WTRU 907 to activate TRP 805).

[0205] The WTRU may perform maintenance on the set of TRPs that can receive the PRS. 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 reactivation of the TRP.

[0206] The WTRU may send (e.g., continue to send) the activation request, for example, until one or more conditions are met. The WTRU may send (e.g., continue to send) the activation request if the set of TRPs available for activation is empty. The WTRU may send (e.g., continue to send) the activation request if a condition for stopping sending requests is met (e.g., the RSRP of the reference PRS is above a threshold). The WTRU may send (e.g., continue to send) the activation request if the WTRU receives a command (e.g., a deactivation command received from the network to stop the request procedure). The WTRU may send (e.g., continue to send) the activation request until the number of positive and / or negative responses to the activation request sent by the WTRU is equal to or greater than a threshold. The WTRU may send (e.g., continue to send) the activation request if a time window / duration for the on-demand PRS expires.

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

[0208] In an 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 configurations are allowed by the network. The WTRU may decide to send a request to cancel the activation request for the remaining subset of PRS configurations (e.g., PRS configurations that have not yet been activated). For example, referring again to FIG. 8C, the WTRU 807 may receive an indication that only TRP 805 is activated (e.g., even though the WTRU 807 has requested activation of TRP 806 and TRP 806). In this case, if the WTRU 807 determines that TRP 806 is activated, the WTRU 807 may decide to terminate the PRS request procedure and / or send a message to the network to cancel the request for activation of TRP 805.

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

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

Claims

1. 1. A wireless transmit / receive unit (WTRU) comprising a processor and a memory, the processor and the memory comprising: receiving configuration information indicating that the WTRU is configured to receive positioning reference signals (PRS) from a first set of one or more transmit-reception points (TRPs), the configuration information including positioning reference signal (PRS) configuration information associated with the first set of one or more TRPs; determining a metric associated with a transmit-receive point (TRP), the TRP not being included in the first set of one or more TRPs, the determined metric comprising: A location associated with said TRP; a location associated with the WTRU; or determining, based on one or more of the measurements associated with the TRP; sending a PRS activation request to activate a PRS from the TRP, the PRS activation request including the determined metric associated with the TRP; receiving a message indicating that the WTRU should receive a PRS from the TRP, the message including PRS configuration information associated with the TRP.

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

3. receiving a PRS from a first set of the one or more TRPs; 10. The WTRU of claim 1, further comprising: determining the location associated with the WTRU based on the PRS received from the first set of the one or more TRPs.

4. The processor and the memory determining an estimated location associated with the WTRU based on a PRS received from the TRP; The WTRU of claim 3 , configured to send an indication of the estimated location associated with the WTRU.

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

6. The WTRU of 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 of claim 4 , configured to send a second PRS activation request, the estimated location associated with the WTRU being included in the second PRS activation request.

8. 2. The WTRU of claim 1, wherein the measurement values ​​associated with the TRP include 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 of claim 1 , wherein the weights associated with the TRPs are determined using an artificial intelligence / machine learning (AI / ML) model.

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

11. 1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information indicating that the WTRU is configured to receive positioning reference signals (PRS) from a first set of one or more transmit-reception points (TRPs), the configuration information including positioning reference signal (PRS) configuration information associated with the first set of one or more TRPs; determining a metric associated with a transmit-receive point (TRP), the TRP not being included in the first set of one or more TRPs, the determined metric comprising: A location associated with said TRP; a location associated with the WTRU; or determining, based on one or more of the measurements associated with the TRP; sending a PRS activation request to activate a PRS from the TRP, the PRS activation request including the determined metric associated with the TRP; receiving a message indicating that the WTRU should receive a PRS from the TRP, the message including PRS configuration information associated with the TRP.

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

13. A base station comprising a processor and a memory, the processor and the memory comprising: transmitting 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; receiving a PRS activation request for activating a PRS from a transmit-receive point (TRP) not included in a first set of the one or more TRPs, the PRS activation request including a metric associated with the TRP; A base station configured to transmit a message indicating that the WTRU should receive a PRS from the TRP, the message including PRS configuration information associated with the TRP.

14. The metric associated with the TRP is: A location associated with said TRP; a location associated with the WTRU; or The base station of claim 13 , wherein the determined metric is based on one or more of the measurements associated with the TRP.

15. 14. The base station of 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