Inter-WTRU channel evaluation for aggregated terminals

Abstract

A wireless transmit / receive unit (WTRU) comprises a processor configured to receive a configuration of channel correlation measurements from a network. The configuration may be associated with an aggregation group. The processor may detect a trigger to perform the channel correlation measurements, determine one or more WTRUs associated with the aggregation group to perform the channel correlation measurements, send a request to perform the channel correlation measurements to each WTRU of the one or more WTRUs associated with the aggregation group, receive a response from at least one WTRU of the one or more WTRUs associated with the aggregation group, determine a correlation of the channel correlation measurements performed by the one or more WTRUs in the aggregation group, and send a reporting message to the network or the at least one WTRU of the one or more WTRUs.

Description

INTER-WTRU CHANNEL EVALUATION FOR AGGREGATED TERMINALS CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of United States Provisional Application No.63 / 556,013 filed on February 21, 2024, the entire contents of which are incorporated herein by reference. BACKGROUND

[0002] A wireless transmit / receive unit (WTRU) aggregation may be used by WTRUs to assist each other to perform various tasks in a collaborative / joint manner. Tasks may include various aspects of the communication protocols, for both higher layers and lower layers stacks. For instance, data transmissions and receptions may be performed with aggregation, but also some decisions or measurements may be aggregated. The collaboration in some cases may aim at collecting and regrouping distributed knowledge and decisions to improve the overall system. In other cases, a WTRU may perform some tasks on behalf of another WTRU, in a delegative manner. SUMMARY

[0003] A wireless transmit / receive unit (WTRU) may comprise a processor. The processor may be configured to receive a configuration of channel correlation measurements from a network. The configuration may be associated with an aggregation group. The processor may be configured to detect a trigger to perform the channel correlation measurements. The processor may be configured to determine, based on the trigger, one or more WTRUs associated with the aggregation group to perform the channel correlation measurements. The processor may be configured to send a request to perform the channel correlation measurements to each WTRU of the one or more WTRUs associated with the aggregation group. The processor may be configured to receive a response from at least one WTRU of the one or more WTRUs associated with the aggregation group. The response may include, for example, the channel correlation measurements performed by the at least one WTRU. The processor may be configured to determine, based on the received response from the at least one WTRU, a correlation of the channel correlation measurements performed by the one or more WTRUs in the aggregation group. The processor may be configured to send, based on the determined channel correlation of the channel correlation measurements performed by the one or more WTRUs in the aggregation group, a reporting message to the network or the at least one WTRU of the one or more WTRUs. In some examples, the WTRU may itself beincluded in the WTRUs channel to evaluate the correlation. For example, the processor may be configured to determine the correlation between a received (e.g., second) WTRU’s measurement and its own measurement. In that case, the processor may be configured to send a request and / or receive measurement to collect other WTRUs' measurement, but may in parallel trigger itself to perform a measurement, and / or use an already performed measurement.

[0004] The configuration may include, for example, a first configuration. The trigger to perform channel correlation measurements may include, for example, an indication of a second configuration associated with the aggregation group. The trigger to perform channel correlation measurements may include an indication to perform channel correlation measurements from a network. The trigger to perform channel correlation measurements may include an indication to activate a feature associated with the aggregation group.

[0005] The indication of a second configuration associated with the aggregation group may include, for example, one or more of an addition of a new WTRU, and / or a removal of one WTRU of the one or more WTRUs. The indication to perform channel correlation measurements from a network may be indicated via medium access control (MAC) and / or downlink control information (DCI).

[0006] The configuration may include, for example, one or more reference signals (RSs) to use for the channel correlation measurements. The reference signals may include, for example, one or more of reference signal received power (RSRP) and / or received signal strength indicator (RSSI). The configuration may include, for example, an indication of channel correlation types and an indication of channel correlation evaluation thresholds.

[0007] The channel correlation type may include, for example, small-scale channel correlation and / or large-scale correlation. Small-scale channel correlation may be based on, for example, metrics of channel coefficient matrix and channel impulse response. Large-scale channel correlation may be based on, for example, metrics of one or more of RSRP, RSSI, signal-to-interference plus noise ratio (SINR), and / or line- of-sight (LoS).

[0008] The reporting message may include, for example, the determined correlation results. The determined correlation results may include, for example, one or more of WTRU ID, corresponding RSs, correlation types, and / or correlation metrics. In some examples, the determination may lead to a simple “yes or no" result (e.g., correlated vs non-correlated), based on correlation metrics and / or thresholds. In some examples, the determination may result in some granularity of correlation (e.g., low, medium, or highcorrelation). In some examples, the determination may result in which correlation type and / or conditions are satisfied or not.

[0009] The processor may be configured to determine low power of one or more WTRUs associated with the aggregation group. The processor may be configured to determine which RS measurements to delegate to another WTRU. The delegation may be based on, for example, established inter-WTRU correlation and RS monitoring delegation requirements. The processor may be configured to send an indication of the delegation to the network. The processor may be configured to determine the channel correlation based on quasi co-location (QCL) and transmission configuration indicator (TCI).

[0010] A WTRU may be configured to perform a method that includes one or more of the following steps. The method may include receiving a configuration of channel correlation measurements from a network. The configuration may be associated with an aggregation group. The method may include detecting a trigger to perform the channel correlation measurements. The method may include determining, based on the trigger, one or more WTRUs associated with the aggregation group to perform the channel correlation measurements. The method may include sending a request to perform the channel correlation measurements to each WTRU of the one or more WTRUs associated with the aggregation group. The method may include receiving a response from at least one WTRU of the one or more WTRUs associated with the aggregation group. The response may include, for example, the channel correlation measurements performed by the at least one WTRU. The method may include determining, based on the received response from the at least one WTRU, a correlation of the channel correlation measurements performed by the one or more WTRUs in the aggregation group. The method may include sending, based on the determined channel correlation of the channel correlation measurements performed by the one or more WTRUs in the aggregation group, a reporting message to the network or the at least one WTRU of the one or more WTRUs.

[0011] The configuration may include, for example, a first configuration. The trigger to perform channel correlation measurements may include, for example, an indication of a second configuration associated with the aggregation group. The trigger to perform channel correlation measurements may include an indication to perform channel correlation measurements from a network. The trigger to perform channel correlation measurements may include an indication to activate a feature associated with the aggregation group.

[0012] The indication of a second configuration associated with the aggregation group may include, for example, one or more of an addition of a new WTRU, and / or a removal of one WTRU of the one or moreWTRUs. The indication to perform channel correlation measurements from a network may be indicated via medium access control (MAC) and / or downlink control information (DCI).

[0013] The configuration may include, for example, one or more reference signals (RSs) to use for the channel correlation measurements. The reference signals may include, for example, one or more of reference signal received power (RSRP) and / or received signal strength indicator (RSSI). The configuration may include, for example, an indication of channel correlation types and an indication of channel correlation evaluation thresholds.

[0014] The channel correlation type may include, for example, small-scale channel correlation and / or large-scale correlation. Small-scale channel correlation may be based on, for example, metrics of channel coefficient matrix and channel impulse response. Large-scale channel correlation may be based on, for example, metrics of one or more of RSRP, RSSI, signal-to-interference plus noise ratio (SINR), and / or line- of-sight (LoS).

[0015] The reporting message may include, for example, the determined correlation results. The determined correlation results may include, for example, one or more of WTRU ID, corresponding RSs, correlation types, and / or correlation metrics. In some examples, the determination may lead to a simple “yes or no" result (e.g., correlated vs non-correlated), based on correlation metrics and / or thresholds. In some examples, the determination may result in some granularity of correlation (e.g., low, medium, or high correlation). In some examples, the determination may result in which correlation type and / or conditions are satisfied or not.

[0016] The method may include determining low power of one or more WTRUs associated with the aggregation group. The method may include determining which RS measurements to delegate to another WTRU. The delegation may be based on, for example, established inter-WTRU correlation and RS monitoring delegation requirements. The method may include sending an indication of the delegation to the network. The method may include determining the channel correlation based on quasi co-location (QCL) and transmission configuration indicator (TCI). BRIEF DESCRIPTION OF THE DRAWINGS

[0017] FIG.1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0018] 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 an embodiment.

[0019] 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 communications system illustrated in FIG.1A according to an embodiment.

[0020] FIG.1D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG.1A according to an embodiment.

[0021] FIG.2 is a system diagram illustrating an example WRTU aggregation with a group coordinator (GC) according to an embodiment.

[0022] FIG.3 is a flowchart illustrating an example procedure for inter-WTRU channel correlation evaluation according to an embodiment.

[0023] FIG.4 is a flowchart illustrating an example procedure of the interaction between an assistant WTRU, an assisted WTRU and a gNB for the delegation of reference signal (RS) measurement. DETAILED DESCRIPTION

[0024] FIG.1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ 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.

[0025] As shown in FIG.1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or a “STA”, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit,a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0026] The communications systems 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 the 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, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0027] 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 a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be 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 for each sector of the cell. In an 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, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0028] 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., radiofrequency (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).

[0029] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c 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 communication 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 UL Packet Access (HSUPA).

[0030] In an 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).

[0031] In an 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).

[0032] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

[0033] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA20001X, 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), and the like.

[0034] The base station 114b in FIG.1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in alocalized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. 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 an 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 utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. 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 be required to access the Internet 110 via the CN 106 / 115.

[0035] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid 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 be in direct or indirect communication with other RANs that employ 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 be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0036] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit- switched telephone networks that provide 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) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications 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 employ the same RAT as the RAN 104 / 113 or a different RAT.

[0037] 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 the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0038] FIG.1B is a system diagram illustrating an example WTRU 102. As shown in FIG.1B, the WTRU 102 may include 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, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0039] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. 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. While FIG.1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0040] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the 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 an 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.

[0041] Although the transmit / receive element 122 is depicted in FIG.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.

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

[0043] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or 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 the non-removable memory 130 and / or the 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, and the like. 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 a home computer (not shown).

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

[0045] The processor 118 may also be coupled to the 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, the 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 determine its location based on the timing of the signals being received from two or more nearby base stations. It willbe appreciated that the WTRU 102 may acquire location information by way of any suitable location- determination method while remaining consistent with an embodiment.

[0046] 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 e-compass, a satellite transceiver, a digital camera (for photographs and / or video), 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, the sensors 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.

[0047] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

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

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

[0050] Each of the eNode-Bs 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, and the like. As shown in FIG.1C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0051] The CN 106 shown in FIG.1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0052] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. 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.

[0053] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0054] The SGW 164 may be connected to the 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.

[0055] 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 may 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 the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

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

[0057] In representative embodiments, the other network 112 may be a WLAN.

[0058] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to- peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad- hoc” mode of communication.

[0059] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), 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.

[0060] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0061] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 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, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0062] Sub 1 GHz modes of operation are supported by 802.11af and 802.11ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative 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 Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0063] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 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. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remain idle and may be available.

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

[0065] FIG.1D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0066] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated 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 one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an 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 unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0067] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a 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 gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or lasting varying lengths of absolute time).

[0068] 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 the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b,102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0069] 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 of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG.1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0070] The CN 115 shown in FIG.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. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0071] 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 serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized 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, and / or the like. The AMF 162 may provide acontrol 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.

[0072] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 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 notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0073] The UPF 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 UPF 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, and the like.

[0074] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may 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 the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0075] In view of Figures 1A-1D, and the corresponding description of Figures 1A-1D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) 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.

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

[0077] The one or more emulation devices may perform the one or more, including all, functions 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 testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0078] A WTRU may receive RS measurement and reporting configuration including quantities for inter- WTRU correlation or orthogonality evaluation. A WTRU may receive inter-WTRU channel correlation and / or orthogonality types and evaluation parameters. A WTRU may trigger the channel correlation and / or orthogonality measurement based on (re)configuration of the aggregation group, (re)configuration of the RS measurements and reporting, a received indication from network and / or the activation of an aggregation feature. A WTRU may determine which WTRU(s) of the aggregation group to perform the RS measurements, and on which sub-set(s) of the (pre)configured set of RS measurements, based on the trigger event. A WTRU may request the determined WTRU(s) to perform the measurement on determined RS(s) and associated reporting, based on determined subset of WTRUs and RSs. A WTRU may perform the measurement on the determined RS(s) based on the received inter-WTRU correlation and / or orthogonality evaluation configuration (e.g., channel coefficient matrix). A WTRU may receive the measurement reporting from determined WTRU(s) based on the request, including RS IDs, measurement timestamps, etc. A WTRU may evaluate the metrics for correlation and / or orthogonality and may determine the WTRUs subgroups whose channels with gNB are correlated and / or orthogonal based on measured and received measurements, and based on received correlation and / or orthogonality criterion configuration. A WTRU may report to the network and / or to a WTRU the correlation and / or orthogonality evaluation result(e.g., a correlation type) based on determined subgroups of WTRUs and RSs with correlation. A WTRU may determine a correlation and / or orthogonality on a RS based on the correlation on another RS and the quasi co-location (QCL) / transmission configuration indicator (TCI) state / spatial relation between the two RSs. A WTRU may be enabled to delegate RS measurement and / or reporting based on receiving configuration with correlation requirements. A WTRU may determine a subset of RS measurement and / or reporting configuration to delegate to other WTRU(s), based on configured RS measurement reporting type and / or (pre)configured inter-WTRU channel correlation corresponding to the configured RS. A WTRU may send a request to the determined WTRU(s) to perform the measurements according to the determined delegated subset of RS measurement and / or reporting configuration. A WTRU may receive a request to perform the measurements including determined delegated subset of RS measurement and / or reporting configuration and may determine if it is able to perform the delegated RS measurement. A WTRU may report to the network the determined set of RSs that are delegated and for and / or to which WTRU. A WTRU may perform RS measurements and / or reports to the network based on (e.g., received) delegated RS measurements and / or reporting configuration. A WTRU may be configured with triggers to report delegated RS measurement to another WTRU, based on assisted WTRU measurement requirements. A WTRU may report a delegated RS measurement to another WTRU based on configured triggers, upon triggering conditions being met. A WTRU may trigger a procedure based on a received report of delegated RS measurements.

[0079] WTRU aggregation may be implemented. Applications for 5G and beyond are expanding in many vertical directions such as, for example, extended reality (XR), industrial IoT, intelligent transportation systems, etc. Such new scenarios impose new service requirements with reasonable resource and power efficiency, such as ultra-high UL data rate, ultra-low latency, and high reliability. Some services such as XR, VR / AR may even require a tight synchronization among data flows from different devices (e.g., gloves, glasses, etc.) running a single application layer. The conventional cellular network managing a service per WTRU basis may not be sufficient to guarantee the more stringent requirement of multiple devices simultaneously. To overcome such challenges, WTRU aggregation (e.g., where multiple WTRUs collaborates for uplink transmission and / or downlink reception to boost the capability of the system) may be considered.

[0080] Regarding WTRU aggregation, multipath relays are being used, in which a WTRU may be connected to the network via the Uu interface and a single U2N relay. However, in certain relays (e.g., R18 multipath relays), PDCP layer aggregation may be adopted, in which the WTRU may primarily use the Uupath for uplink transmission. Indirect path via U2N relay may play a role as a supplementary link to support uplink transmission when the amount of data in the buffer is sufficiently large. Lower layer conditions, such as channel gain, transmission layer, etc., may not be considered in higher layer aggregation as PDCP.

[0081] For WTRU aggregation uplink transmission and downlink reception, it is assumed that one WTRU may perform uplink transmission and / or downlink reception with the support of one or multiple assistant WTRUs to take advantage of WTRU diversity gain in transmission / reception.

[0082] For WTRU aggregation in a group, the network may be able to take advantage of multiple Uu links and / or sidelinks among WTRUs to dynamically route the uplink and downlink data considering different conditions, such as transmission power, channel condition, QoS of the data to efficiently manage the group to guarantee the quality of service (QoS) / quality of experience (QoE) of the service.

[0083] Lower layer (e.g., MAC, PHY) aggregation may allow the network to take advantage of combining gain at lower layer to boost the system’s performance. Physical downlink shared channel (PDSCH) / physical uplink shared channel (PUSCH) data may be transmitted on the same resources to reduce resource overhead and / or enhance WTRU antenna capability. For example, system frame number (SFN) transmissions may be joint transmissions of the same signal on the same resource from different WTRUs to create increases in the received power at the gNB side. As a result, decoding performance may be improved due to combining gain at lower layers. On the DL side, WTRUs may both receive the transmission and / or combine the physical signals before decoding, or decode and exchange their results afterwards. Moreover, hybrid automatic repeat request (HARQ) retransmission may not be needed as long as transmission on one WTRU succeeds, which may reduce the latency and / or avoid unnecessary re- transmission.

[0084] In 3GPP new radio (NR), the channel state information is acquired by the network and WTRUs using reference signals (RSs). In a brief overview, for beam management and channel state information (CSI) acquisition, the RSs include CSI-RS, demodulation reference signals (DMRSs) (e.g., physical uplink control channel (PUCCH) DMRS, physical downlink control channel (PDCCH) DMRS, PUSCH DMRS, PDSCH DMRS and physical broadcast channel (PBCH) DMRS), and sounding reference signal (SRS). The reference signals may be (pre)configured by the network.

[0085] Synchronization signal blocks (SSBs) may be blocks of signals, for example, including the primary synchronization signal (PSS), secondary synchronization signal (SSS), PBCH and PBCH DMRS, and may be cell specific (e.g., common to the WTRUs in a cell). SSBs may, for example, be used as reference forbeam management and transmission configuration indicator (TCI) states, and the RS may correspond to the PSS / SSS or PBCH DMRS of the SSB.

[0086] For non-zero-power (NZP) CSI-RSs, the configuration may be given using the NZP-CSI-RS- Resource information element (IE), which may include the resource mapping (e.g., resourceMapping) the power configuration, the RS identifier (ID) (e.g., nzp-CSI-RS-ResourceId), scrambling ID (e.g., scramblingID), and optionally the periodicity (e.g., periodicityAndOffset) and / or quasi co-location (QCL) information (e.g., qcl-InfoPeriodicCSI-RS). The CSI resource configurations may be grouped into a resource set, NZP-CSI-RS-ResourceSet, including: an ID (e.g., nzp-CSI-ResourceSetId), the corresponding resources and optional repetition (e.g., to identify whether the RS is using the same or different beam / spatial filter for the transmission) and / or triggers (aperiodicTriggeringOffset). The CSI resource configurations may be grouped into the configuration IE CSI-ResourceConfig which is bandwidth part (BWP) specific and may indicate whether the CSI is periodic, aperiodic and / or semi-persistent using resourceType.

[0087] CSI may be reported to the network based on report configuration in radio resource control (RRC) IEs CSI-ReportConfig which may include several aspects of the reporting. For instance, CSI-ReportConfig may include: the associated CSI resource IDs, the reporting configuration type (reportConfigType), which may be periodic, semiPersistentOnPUCCH, semiPersistentOnPUSCH and / or aperiodic and the corresponding report resource configuration. The report content / quantity “reportQuantity” may be one of: none, cri-RI-PMI-CQI, cri-RI-i1, cri-RI-i1-CQI, cri-RI-CQI, cri-RI-LI-PMI-CQI, cri-RSRP, and / or ssb-Index- RSRP; and may indicate which of the channel quality indicator (CQI), precoding matrix indicator (PMI), CSI reference signal resource indicator (CRI), synchronization signal / PBCH block resource indicator (SSBRI), layer indicator (LI), rank indicator (RI), and / or reference signal received power (RSRP) may be reported to the network. The reports may be configured in reportFreqConfiguration to indicate whether the CQI / PMI or for some subbands or for wideband.

[0088] A group of WTRUs may be in an aggregation group, with a group coordinator (GC). The GC may be responsible for handling some group management functionality and / or for centralizing some knowledge that may not be known at the network side about the group.

[0089] The aggregation group may be predetermined (e.g., but may be dynamically updated) and / or may be a group of WTRUs sharing common data interest, belonging to the same user / subscriber, same set of devices and / or WTRUs in close proximity with each other. For example, use cases may include: extended reality (XR), internet of things (IoT), and / or wearables.

[0090] If the channel conditions between each WTRU and the gNB are similar, the network, GC and WTRUs may use this information, for example, to improve scheduling and beam management of multiple WTRUs, to manage aggregation features, and / or to use one CSI report for multiple WTRUs. In these cases, WTRUs may have inter-WTRU channel correlation.

[0091] No measurements for channel correlation between different WTRUs and gNB are currently supported. In some examples, channel correlation evaluation may be beneficial to be done at the WTRU side, for example, a group coordinator to manage the relationship between members of the group. The measured channel response information may have a large pay load and may cause signaling overhead on Uu reporting.

[0092] The following discusses techniques that may enable a group of WTRUs to establish and / or take advantage of the correlation of their channel as part of an aggregation.

[0093] Inter-WTRU correlation establishment may be implemented. For example, a GC may determine whether the Uu channels of the WTRUs in the aggregation group are correlated. The group may be configured with a set of RSs with specific measurement quantities to report to the GC. The GC may request one or more (e.g., some) WTRUs of the group to perform measurements and / or reporting based on triggers. The GC may receive the measurement reports and compares them, for example, to determine whether the WTRUs that have correlated channels. The GC may report to the WTRUs and to the network to use this information for aggregation features (e.g., delegate functionalities, joint scheduling, etc.).

[0094] In some examples, a WTRU (e.g., a Group Coordinator (GC)) may receive the following (pre)configuration, as part of an aggregation group. For example, a GC may receive RSs measurement and / or reporting configuration, including one or more of the quantities: Channel coefficient matrix, Channel impulse response, line of sight (LoS), RSRP, received strength signal indicator (RSSI). A GC may receive inter-WTRU channel correlation types and / or evaluation parameters (e.g., small-scale channel correlation, based on metrics of channel coefficient matrix, channel impulse response; large-scale channel correlation, based on metrics of RSRP, RSSI, signal to interference plus noise ratio (SINR), LoS; and / or timing for evaluation: single-shot evaluation or over a time window). Small-scale channel correlation and / or large- scale channel correlation and their respective metrics are examples, and other channel correlation types and / or metrics and / or parameters may be implemented.

[0095] In some examples, a GC may trigger the channel correlation measurement based on one or more of the following events. For example, a GC may trigger the channel correlation measurement based on (re)configuration of the aggregation group (e.g., WTRU addition, WTRU removal, WTRU (re)configuration,(re)configuration of RS measurements, etc.). A GC may trigger the channel correlation measurement based on receiving an explicit indication from the network to perform the measurement using medium access control (MAC) and / or downlink control information (DCI). A GC may trigger the channel correlation measurement based on activation of an aggregation feature requiring channel correlation between some WTRUs.

[0096] In some examples, a GC may determine which WTRU(s) of the aggregation group to perform the RS measurements, and on which sub-set(s) of the (pre)configured set of RS measurement, based on one or more trigger events. For example, a GC may determine which WTRU(s) of the aggregation group to perform the RS measurements, and on which sub-set(s) of the (pre)configured set of RS measurement, based on when a new member WTRU may be added, select the new added WTRU. A GC may determine which WTRU(s) of the aggregation group to perform the RS measurements, and on which sub-set(s) of the (pre)configured set of RS measurement, based on when a new RS measurement is configured, select that RS for measurement. A GC may determine which WTRU(s) of the aggregation group to perform the RS measurements, and on which sub-set(s) of the (pre)configured set of RS measurement, based on when an aggregation feature is activated for a subset of WTRUs requiring a small-scale channel correlation measurement, select the corresponding WTRUs and RSs based on measurement (pre)configuration.

[0097] In some examples, a GC may request the determined WTRU(s) to perform the measurement on determined RS(s) and associated reporting, based on determined subset of WTRUs and RSs (e.g., via sidelink (SL) sidelink control information (SCI), MAC and / or RRC.

[0098] In some examples, if the GC is part of the determined WTRUs, the GC may perform the measurement on the determined RS(s) for the inter-WTRU correlation evaluation (e.g. channel coefficient matrix).

[0099] In some examples, the GC may receive the measurement reporting from determined WTRU(s) based on the request, including RS IDs, measurement timestamps.

[0100] In some examples, the GC may evaluate the metrics for correlation and may determine the WTRUs subgroups whose channels with gNB are correlated, with respect to the (pre)configured RS(s) and corresponding timestamps based on, for example: reported channel measurements, own channel measurements, and / or (pre)configured channel correlation metrics.

[0101] In some examples, the GC may report to gNB and / or the determined WTRU(s) the determined correlation results (e.g., WTRU ID(s), corresponding RS, and / or correlation types / metrics).

[0102] In some lower-layer aggregation for communications, it may be beneficial to identify whether the WTRUs may be experiencing similar radio channel conditions. In WTRU aggregation, the WTRUs may be typically located in proximity with each other (e.g., for Personal Area Networks, Body Area Networks, XR, wearables, etc.) and thus their channel conditions with the network may be similar. For example, the network and / or the WTRUs may use this to improve the scheduling or beam management or these WTRUs.

[0103] When the radio conditions are similar (e.g., similar enough), some aggregated or collaborative features may be enabled or help the network and user in making their decisions. For example, the network and / or the WTRUs may use this to delegate some functionalities requiring the WTRUs to have correlation, for instance, such as delegating some measurements or delegating some receptions or transmissions. In some examples, when the radio conditions are different enough, some aggregated and / or collaborative features may be enabled and / or help the network and / or user to make the appropriate decisions. For example, the network and / or the WTRUs may use this to take advantage of the radio channel diversity between the network and the WTRUs, such as to increase their capacity or redundancy.

[0104] As described herein, the following types of WTRUs may be used and / or referred to. For example, a source WTRU may refer to an initiator of a packet data unit (PDU) to transmit to another node such as gNB or another WTRU. A destination WTRU may refer to an end receiver of a PDU, which may be transmitted from gNB or another WTRU. An assistant WTRU may refer to a WTRU supporting another WTRU (e.g., source WTRU and / or destination WTRU) in performing a procedure, measurement, or transmitting and receiving a PDU. An assisted WTRU may refer to a WTRU supported by another WTRU (e.g., source WTRU or destination WTRU) in performing a procedure, measurement, or transmitting and receiving a PDU. A group coordinator (GC) WTRU may refer to a WTRU supporting the gNB to perform one or more functions such as centralizing information, determining aggregation features and / or scheduling for one or more WTRUs, which may belong to a group (e.g., group of WTRUs). A member WTRU may refer to one WTRU in a group, which may interact with the group coordinator WTRU and / or other member WTRU to perform one or more procedures under the coordination of the group coordinator WTRU. A member WTRU may refer to one WTRU in a group, which coordinates with other WTRUs in the group to perform a group- related application.

[0105] A WTRU may transmit or receive a physical channel and / or reference signal according to at least one spatial domain filter. The term “beam” may be used to refer to a spatial domain filter. The WTRU may transmit a physical channel or signal using the same spatial domain filter as the spatial domain filter usedfor receiving an RS (e.g., such as channel state information (CSI)-RS) or a synchronization signal SS block. The WTRU transmission may be referred to as “target,” and the received RS or SS block may be referred to as “reference” or “source.” In such case, the WTRU may be said to transmit the target physical channel or signal according to a spatial relation with a reference to such an RS or SS block.

[0106] The WTRU may transmit a first physical channel or signal according to the same spatial domain filter as the spatial domain filter used for transmitting a second physical channel or signal. The first and second transmissions may be referred to as “target” and “reference” (or “source”), respectively. In such a case, the WTRU may be said to transmit the first (target) physical channel or signal according to a spatial relation with a reference to the second (reference) physical channel or signal.

[0107] A spatial relation may, for example, be implicit, configured by RRC, and / or signaled by medium access control-control element (MAC-CE) or DCI. For example, a WTRU may implicitly transmit PUSCH and DMRS of PUSCH according to the same spatial domain filter as an SRS indicated by an SRS resource indicator (SRI) included in the DCI or configured by RRC. In another example, a spatial relation may be configured by RRC for an SRI or signaled by MAC-CE for a PUCCH. Such a spatial relation may also be referred to as a “beam indication.”

[0108] The WTRU may receive a first (target) downlink channel or signal according to the same spatial domain filter or spatial reception parameter as a second (reference) downlink channel or signal. For example, such association may exist between a physical channel such as PDCCH or PDSCH and its respective DMRS. If, for example, the first and second signals are reference signals, such association may exist when the WTRU may be configured with a quasi-colocation (QCL) assumption type D between corresponding antenna ports. Such association may be configured as a transmission configuration indicator (TCI) state. A WTRU may be indicated an association between a CSI-RS or SS block and a DMRS by an index to a set of TCI states configured by RRC and / or signaled by MAC-CE. Such indication may also be referred to as a “beam indication.”

[0109] In 3GPP NR, the channel state information is acquired by the network and WTRUs using Reference Signals. For beam management and CSI acquisition, RSs may include CSI-RS, DMRS (e.g., PUCCH DMRS, PDCCH DMRS, PUSCH DMRS, PDSCH DMRS and PBCH DMRS), and SRS. The reference signals may be (pre)configured by the network.

[0110] As described herein, the terms RS, spatial filters, and beams may be used interchangeably, and may refer to the RS carried on the beams and / or transmissions. As described herein, SSB may sometimesbe referred to as one RS for simplicity, and may actually refer to the underlying RS used to measure and monitor the SSB (e.g., the PBCH DMRS, PSS or SSS).

[0111] As described herein, the WTRU may be configured with or (pre)-configured, which may refer to a scenario where the WTRU receives a configuration from the gNB or another node (e.g., group coordinator WTRU). In examples where a WTRU receives configuration from the gNB, the WTRU may receive a dedicated MAC indication, RRC configuration or system information block (SIB) from the gNB. Unless specifically mentioned otherwise, communication (e.g., message, indication, request, report, confirmation, etc.) between the network and a WTRU may be treated as communication using the Uu interface (e.g., RRC (re)configuration, SIB (re)configuration, MAC-CE indication, DCI, etc.). In examples where a WTRU may receive configuration from another node, the WTRU may receive configuration via sidelink communication (e.g., PC5 RRC, SL MAC-CE, SCI). Unless specifically mentioned otherwise, communication (e.g., message, indication, request, report, confirmation, etc.) between WTRUs may also, or alternatively, be treated as communication using the sidelink (e.g., PC5 RRC, SL MAC-CE, SCI).

[0112] As described herein, the radio link quality between two nodes (e.g., between a source and assistant WTRUs, between two assistant WTRUs, between the group coordinator and member WTRUs, between two member WTRUs, and / or between a WTRU and gNB) may refer to one or any combination of the following: RLF status between two nodes; a synchronization status between two nodes; Beam management status between two nodes; layer 1 or layer 3 measurements of transmission(s) between two nodes; the distance between two nodes; a channel busy ratio (CBR) of the resource pool used to exchange PDUs between two nodes; and / or the transmission latency of a PDU between the two nodes.

[0113] Referring to an RLF status between two nodes, for example, the link quality between two nodes may refer to whether RLF is detected / declared by the evaluating node (e.g., evaluating WTRU).

[0114] Referring to the synchronization status between two nodes, for example, the link quality between two nodes may refer to whether the evaluating node (e.g., evaluating WTRU) is synchronized with the peer node (e.g., gNB or the peer WTRU).

[0115] Referring to the beam management status between two nodes, for example, the link quality between two nodes may refer to whether beam failure is detected / declared by the evaluating node (e.g., evaluating WTRU).

[0116] Referring to layer 1 (L1) and / or layer 3 (L3) measurements of transmission(s) between two nodes (e.g., which may include but not limited to RSRP, RSRQ, SINR, RSSI, Pathloss, BLER, etc.), for example, the L1 or L3 measurement may be performed at the evaluating node (e.g., evaluating WTRU). Also, oralternatively, the L1 or L3 measurement may be performed at the peer node (e.g., gNB) and sent to the evaluating node (e.g., evaluating WTRU). For example, the link quality between two nodes may refer to the L3 RSRP of transmission from the peer node.

[0117] Referring to the distance between two nodes, for example, the link quality between two nodes may refer to the distance between the two nodes. For example, the WTRU may determine the link quality between two nodes as good if the distance between two nodes is smaller than a configured threshold. Otherwise, the WTRU may determine the link quality between two nodes as not good.

[0118] Referring to the CBR of the resource pool used to exchange PDUs between two nodes, for example, the link quality between two nodes may refer to the CBR of the resource pool used to transmit data between the source and the assistant WTRUs.

[0119] Referring to the transmission latency of a PDU between the two nodes, for example, the link quality between two nodes may refer to the maximum / minimum latency requirement to transmit a PDU between the two nodes. The link quality between two nodes may be considered as good if the latency is smaller than a configured threshold. Otherwise, the link quality between two nodes may be considered not good.

[0120] Aggregation groups may be implemented. In some examples, a WTRU may be configured to be associated with one or more other WTRUs as a group for aggregation. For example, a WTRU may be configured (e.g., preconfigured) with an aggregation group (e.g., based devices specific implementation, hardware and / or application-based pairing). For instance, a group of devices belonging to the same subscriber, a group of devices belonging to the same set (e.g., for XR or wearable devices) or a group of devices for the same service.

[0121] In some examples, a WTRU may be (pre)configured with an aggregation group by another WTRU (e.g., a GC) or by the network, and may be explicitly configured as an aggregation group (e.g., with specific signaling so that WTRUs and network have a common understanding). Also, or alternative, the WTRU may be (pre)configured to associate with other WTRUs that may use some aggregation features opportunistically.

[0122] In some examples, a WTRU may use one or more of the following characteristics to determine aggregation groups. For example, a WTRU may use inter-WTRU connectivity (e.g., connection type (SL and / or proprietary), signal quality, etc.) to determine aggregation groups. A WTRU may use inter-WTRU distance to determine aggregation groups. A WTRU may use WTRU battery status / energy saving mode to determine aggregation groups. A WTRU may use Uu signal quality and selected cell to determine aggregation groups. A WTRU may use WTRU capabilities (e.g., supported aggregation features) todetermine aggregation groups. A WTRU may use the received SL discovery messages to determine aggregation groups. A WTRU may use QoS requirements, data queue, buffer status, etc., to determine aggregation groups. A WTRU may send (e.g., to the network and / or another WTRU (e.g., a GC)), the above mentioned characteristics so that the network and / or another WTRU may perform the determination of aggregation groups.

[0123] A WTRU (pre)configured with an aggregation group may be reconfigured and / or updated. For example, as devices are mobile and may be active or inactive, updating the group may be caused by one or more factors or factor changes, similar as the grouping characteristics described herein.

[0124] A WTRU may be (pre)configured with an aggregation group that has a GC. The GC may be responsible for handling group management functionality and / or may centralize knowledge that may not be known at the network side about the group. For example, this centralized knowledge may include the inter- WTRU connectivity, their relative position, channel etc. In an aggregation setup, the GC may also be responsible for performing tasks that are similar to what the network traditionally handles, but that may be delegated to the GC for the group.

[0125] The GC may be a WTRU that is part of the aggregation group and acting on its own as a regular WTRU, and / or be a dedicated device for the purpose of being a GC. The selection or designation of the GC amongst WTRUs of the group may be based on a WTRU’s capabilities, connectivity, battery status, etc. Although some of the following description refers to the GC specifically, a person having ordinary skill in the art would understand that these techniques may apply to any WTRU supporting the feature without specifically being configured, designated, and / or selected as a GC. The GC may perform some tasks for other WTRUs in the group, but may also perform similar tasks for itself, as a WTRU part of the group. FIG. 2 illustrates an example associated with WTRU aggregation group with a GC.

[0126] Inter-WTRU Uu channel correlation establishment may be implemented. To enable some aggregation features and / or features requiring channel correlation between WTRUs, the WTRUs may establish and / or determine the channels between the network and the WTRUs may be correlated, and thus channel comparison may be performed.

[0127] FIG.3 illustrates an example procedure associated with inter-WTRU channel correlation evaluation. As illustrated in procedure 300, the measurements for correlation may be performed on RS(s) based on WTRU decisions. WTRUs may be configured by the network with CSI measurement configuration with RRC (re)configuration, and the WTRUs may also be configured with inter-WTRU correlation measurement settings. Depending on the aggregation feature the WTRU wants to perform andthe CSI configuration received, the WTRU may select the correlation measurement to perform by the other WTRUs, the RSs to be measured and the other WTRUs. The WTRU may then request the measurement to the other WTRU(s) and may forward some measurement configuration if needed. The WTRU may receive a report acknowledging whether the requested WTRU may be capable or not capable of performing the measurement. If not capable, the WTRU may redetermine another set of WTRU and / or RS(s). The WTRUs may measure the RS(s), and may report back the measurement. The WTRU may compute the correlation metric(s) with the channels of the other WTRUs (e.g., the channel matrix distance) and evaluate them against the configured threshold. The WTRU may determine a (sub)set of WTRUs and RS(s) that satisfies the correlation type requirement (e.g., based on the aggregation feature the WTRU may be activating). The WTRU may report the correlation to the selected WTRUs, and / or may also report it to a coordinator WTRU and / or to the network.

[0128] For example, procedure 300 may be performed by a WTRU. At 302, a WTRU (e.g., a Group Coordinator (GC)) may receive the following (pre)configuration, as part of an aggregation group. For example, a GC may receive RSs measurement and / or reporting configuration, including one or more of the quantities: Channel coefficient matrix, Channel impulse response, line of sight (LoS), RSRP, received strength signal indicator (RSSI). A GC may receive inter-WTRU channel correlation types and / or evaluation parameters (e.g., small-scale channel correlation, based on metrics of channel coefficient matrix, channel impulse response; large-scale channel correlation, based on metrics of RSRP, RSSI, signal to interference plus noise ratio (SINR), LoS; and / or timing for evaluation: single-shot evaluation or over a time window).

[0129] At 304, a GC may trigger the channel correlation measurement based on one or more of the following events. For example, a GC may trigger the channel correlation measurement based on (re)configuration of the aggregation group (e.g., WTRU addition, WTRU removal, WTRU (re)configuration, (re)configuration of RS measurements, etc.). A GC may trigger the channel correlation measurement based on receiving an explicit indication from the network to perform the measurement using medium access control (MAC) and / or downlink control information (DCI). A GC may trigger the channel correlation measurement based on activation of an aggregation feature requiring channel correlation between some WTRUs.

[0130] At 306, a GC may determine which WTRU(s) of the aggregation group to perform the RS measurements, and on which sub-set(s) of the (pre)configured set of RS measurement, based on one or more trigger events. For example, a GC may determine which WTRU(s) of the aggregation group to perform the RS measurements, and on which sub-set(s) of the (pre)configured set of RS measurement,based on when a new member WTRU may be added, select the new added WTRU. A GC may determine which WTRU(s) of the aggregation group to perform the RS measurements, and on which sub-set(s) of the (pre)configured set of RS measurement, based on when a new RS measurement is configured, select that RS for measurement. A GC may determine which WTRU(s) of the aggregation group to perform the RS measurements, and on which sub-set(s) of the (pre)configured set of RS measurement, based on when an aggregation feature is activated for a subset of WTRUs requiring a small-scale channel correlation measurement, select the corresponding WTRUs and RSs based on measurement (pre)configuration.

[0131] At 308, a GC may request the determined WTRU(s) to perform the measurement on determined RS(s) and associated reporting, based on determined subset of WTRUs and RSs (e.g., via sidelink (SL) sidelink control information (SCI), MAC and / or RRC.

[0132] At 310, if the GC is part of the determined WTRUs, the GC may perform the measurement on the determined RS(s) for the inter-WTRU correlation evaluation (e.g. channel coefficient matrix).

[0133] At 312, if the GC receives a report that the other WTRUs are not able to perform the measurement and / or if receiving no report, then repeat step 306.

[0134] At 314, the GC may receive the measurement reporting from determined WTRU(s) based on the request, including RS IDs, measurement timestamps.

[0135] At 316, the GC may evaluate the metrics for correlation and may determine the WTRUs subgroups whose channels with gNB are correlated, with respect to the (pre)configured RS(s) and corresponding timestamps based on, for example: reported channel measurements, own channel measurements, and / or (pre)configured channel correlation metrics.

[0136] At 318, the GC may report to gNB and / or the determined WTRU(s) the determined correlation results (e.g., WTRU ID(s), corresponding RS, and / or correlation types / metrics).

[0137] Configurations for measuring channel correlation may be received. One or more of the following may apply. In some examples, the WTRU may be (pre)configured to perform measurements on downlink (DL) RSs that will be used to evaluate the channel correlation between the WTRUs. The WTRU may be (pre)configured to perform measurements on these RSs (e.g., channel matrix coefficients), and may report these measurements to other WTRUs (e.g., to perform the comparison). For example, the configuration may include the RSs configuration (e.g., resource configuration, RS type, reporting configuration, RSs sets, etc.).

[0138] In some examples, the WTRU may receive the (pre)configuration from the network (e.g., using RRC (re)configuration). In some examples, the WTRU may receive the (pre)configuration from anotherWTRU (e.g., a group coordinator, using SL-RRC (re)configuration). In this case, the configuration may further indicate the gNB and / or cell transmitting the RS (e.g., using cell ID).

[0139] In some examples, the WTRU may receive a RS (pre)configuration with one or more RS resource sets, including one or more RS resources. The WTRU may be configured to measure the RSs periodically, semi-persistently, and / or aperiodically. The WTRU may be configured to measure the SSBs, CSI-RS, or any type of DL RS (e.g., such as a dedicated type of RS for inter-WTRU correlation measurement).

[0140] In some examples, the WTRU may receive a group-common RS (pre)configuration (e.g., for the aggregation group) so that the WTRUs in the group have the same (CSI-)RS configuration (e.g., RS resources, RS reporting configuration, RS ID, etc.).

[0141] In some examples, a WTRU (e.g., member WTRU and / or GC) in an aggregation group may receive a group-common RS configuration by the network (e.g., using RRC (re)configurations with similar content and / or a common (re)configuration using group a group-indication) at the RRC and / or MAC level. Also, or alternatively, the WTRU in an aggregation group may receive a group-common RS from another WTRU of the aggregation group (e.g., the GC via SL-RRC (re)configuration).

[0142] In some examples, a WTRU may be (pre)configured by the network with a specific (e.g., WTRU specific) RS. For example, different WTRUs in the group may be configured with their own RSs, and the network may control the RS configurations so that the RS of different WTRUs are actually the same RS transmission (e.g., same type, same resources), This may be transparent to the WTRUs, for example, different WTRUs may have different RS IDs.

[0143] In examples, a WTRU may be (pre)configured with an RS that has (e.g., explicitly has) an indication that the RS (e.g., or RS set) is dedicated to, supporting or compatible with correlation evaluation.

[0144] In some examples, a WTRU may be (pre)configured with an RS that includes a binary / flag indicator to enable the inter-WTRU correlation measurement. A WTRU may be (pre)configured with an RS indicated as a new RS type for inter-WTRU correlation evaluation.

[0145] In some examples, a WTRU may be (pre)configured with an RS that does not indicate (e.g., explicitly indicate) that the RS is configured for a correlation evaluation. For example, implicit indications may be used to indicate whether a given RS may be used for (e.g., is compatible with) inter-WTRU correlation measurement. For example, a WTRU may be (pre)configured with the types of RS that are compatible with inter-WTRU correlation (e.g., SSBs only, or SSB and CSI-RS only, etc.). The WTRU may then determine the RSs that are compatible for the correlation measurement based on the RS type.

[0146] In some examples, a WTRU may be (pre)configured with an RS to use for inter-WTRU measurements, which may, for example, be allocated with fewer resources than regular RSs (e.g., when such measurements are expected to be sparse).

[0147] In examples, a WTRU may be (pre)configured with periodic or semi-persistent RS for inter-WTRU measurements that require continuous and / or regular evaluation of their correlation. Also, or alternatively a WTRU may be (pre)configured with aperiodic RS, for instance, when the measurements are performed once (e.g., in response to a specific trigger).

[0148] In some examples, a WTRU may be (pre)configured with the RS used for the inter-WTRU measurement that are not dedicated to the inter-WTRU measurement, and re-use regular (e.g., not specifically for inter-WTRU correlation measurements) RS configuration. The RS configuration may further include additional measurement and / or reporting configurations to enable the inter-WTRU measurement in parallel with the regular CSI framework behavior. This may avoid extra RS resources usage and may reuse the existing configuration. For example, the WTRU may be configured with inter-WTRU correlation measurements and reporting reusing a regular RS measurement and / or reporting configuration, and the inter-WTRU correlation measurements may be performed on a subset of the configured regular RS resource (e.g., to have a sparse measurement).

[0149] Correlation and / or measurement configurations may be implemented. The WTRUs may be (pre)configured to perform different types of measurements on the RS and report different types of report quantities, such as the existing layer 1 (L1)-RSRP, layer 3 (L3)-RSRP, SINR, CQI, preferred precoding vectors (e.g., PMI), rank indicator (RI), etc., which are configured as the ReportQuantity via RRC (e.g., cri- RI-PMI-CQI, cri-RI-LI-PMI-CQI, cri-RI-i1, cri-RI-i1-CQI, cri-RI-CQI, cri-RSRP, ssb-index-RSRP, cri-SINR, ssb-index-SINR, etc.).

[0150] In some examples, and in addition to the existing reported quantities, the WTRUs may be (pre)configured to perform measurements and to report new types of quantities, such as the channel coefficient matrix (e.g., when configured for MIMO operations), channel impulse response (CIR), line-of- sight (LoS), and / or angle of arrival (AoA). The channel coefficient matrix or channel impulse responses are low-layer measurements that enable very accurate correlation evaluation when comparing the measurements from different WTRUs and enable small-scale fading channel comparisons. LoS and AoA measurements may give spatial information about the directions and large-scale fading of the channel between the WTRU and the gNB.

[0151] In some examples, a WTRU may be (pre)configured with multiple channel correlation types, and with correlation evaluation metric(s) and parameter(s) (e.g., thresholds). The WTRU may use the threshold(s) to evaluate whether a channel satisfies the conditions to be considered correlated with respect to that correlation type / metric.

[0152] In some examples, a WTRU may be (pre)configured with one or more correlation types, forming a set of correlation configurations. An example of a set of correlation types may include inter-WTRU Correlation (IUC)-Type A (e.g., small-scale fading correlation, where the WTRUs experience similar small- scale fading conditions, such as phase-level, narrow-band correlation). An example of a set of correlation types may include IUC-Type B (e.g., large-scale fading correlation, where the WTRUs experience similar large-scale fading conditions, such as RSRP-level, wide-band correlation). An example of a set of correlation types may include IUC-Type C (e.g., beam correlation, where the WTRUs receive a common RS / beam with a satisfying signal).

[0153] In some examples, a WTRU may be (pre)configured with a correlation type (e.g., the small-scale fading correlation) with a criterion, for example, where the norm between the two (normalized) channel matrices (e.g., using Frobenius Norm) is below a threshold. A WTRU may be (pre)configured with a correlation type (e.g., the small-scale fading correlation) with a criterion where the reported PMI(s) (e.g., the preferred precoding matrix) are the same between the WTRUs. A WTRU may be (pre)configured with a correlation type (e.g., the small-scale fading correlation) type with a criterion where the RSRP difference between the WTRU measurements on the RSs of an RS set is below a threshold (e.g., for at least a configured number of RS in the RS set). The rationale being that if two WTRUs receive the same power level from the gNB transmitting in multiple different directions, they likely experience the same multi-path channels.

[0154] In some examples, a WTRU may be (pre)configured with a correlation type (e.g., the large-scale fading correlation) with a criterion where the RSRP / RSSI / SINR difference between the WTRU measurements on the RS is below a threshold. A WTRU may be (pre)configured with a correlation type (e.g., the large-scale fading correlation) with a criterion where, for example, based on the respective measurements, the WTRUs are both determined to have LoS and a similar AoA (e.g., angle difference below a threshold) on the RS.

[0155] In some examples, a WTRU may be (pre)configured with a correlation type (e.g., the beam correlation) with a criterion where the RSRP / RSSI / SINR of the WTRUs measurements on the RS is higher than a threshold.

[0156] In some examples, a WTRU may be (pre)configured with multiple criterions to use for the evaluation of the correlation. For example, a correlation type (e.g., the large-scale fading correlation) may be (pre)configured with a criterion where the RSRP difference between the WTRU measurements on the RS is below a threshold and the WTRU measured both to have a LoS on the RS.

[0157] In some examples, a WTRU may be (pre)configured with multiple correlation metrics and / or thresholds for a given correlation type, defining different levels of correlation for a given type. For example, the WTRU may be configured with an IUC-Type A correlation with two thresholds on the channel matrix distance metric. The thresholds may define one or more (e.g., three) levels, for example, representing a strong correlation, weak correlation, and no correlation, on that type of correlation and metric. A WTRU may use these multiple types and / or criterions, for example, to have a better granularity for the evaluation of the correlation between WTRUs and / or to enable different aggregation features, which may have their specific correlation requirements.

[0158] In some examples, a WTRU may be (pre)configured to evaluate the correlation over one or multiple narrow-band(s) and / or over one or more wideband measurements. For example, a WTRU may be (pre)configured with a narrowband evaluation (e.g., indicating the frequency range) for the IUC-Type A and / or a wideband measurement for IUC-Type B and / or C.

[0159] In some examples, a WTRU may be (pre)configured with criterions for a given type of correlation (e.g., and / or may also support different criterion and / or different thresholds) that may be configured for specific RS, RS sets and / or usage. The configuration of a criterion and / or criterion threshold for an RS and / or an RS set supersedes the (pre)configuration for a correlation type, if any.

[0160] In some examples, a WTRU may be (pre)configured with correlation criterions (e.g., with a timing dimension) where the criterion may be passed for a configured duration to avoid a one-time successful correlation evaluation, which may favor longer-term correlations. For example, a criterion may be evaluated over successive measurements and evaluations over time to be considered valid. A WTRU may be (pre)configured with a duration (e.g., in (milli)seconds or as a number of consecutive measured RS(s)). Correlations are, for example, separately determined for RS, as they are used to evaluate an RS channel. WTRUs, networks, and / or features may have correlation requirements concerning multiple individual RS correlations.

[0161] A WTRU may be (pre)configured with a reporting configuration that indicates how a WTRU is to report the inter-WTRU correlation measurement. In some examples, a WTRU may be (pre)configured to report the measurement to another WTRU, for example, the group coordinator of the aggregation groupand / or another WTRU in the group. The WTRU to which the measurement is reported may be explicitly identified (e.g., using a WTRU ID) in the configuration and / or implicitly identified, (e.g., if (pre)configured as part of an aggregation group reporting to the GC). In some examples, the WTRU may transmit the report using the SL physical sidelink shared channel (PSSCH), an SL MAC-CE indication, and / or via an indication on the SL physical sidelink feedback channel (PSFCH).

[0162] In some examples, a WTRU may be (pre)configured to report the measurement to the network using PUSCH and / or PUCCH based reports. When the RSs are used for both regular Uu measurements and inter-WTRU correlation, the WTRU may report the corresponding measurement to the network and / or another WTRU (e.g., separately).

[0163] The correlation evaluation procedure may be triggered. In some examples, the evaluation and / or re-evaluation of the channel correlation between WTRUs may be motivated / and / or triggered by several events, for example, from the WTRU and / or the network side.

[0164] In some examples, the WTRU may be (pre)configured with triggers to perform the correlation evaluation and / or to request other WTRUs to perform correlation evaluation measurements. The triggers may include one or more of the following. For example, the trigger may include explicit indications from the network, indicating that the WTRU may perform the measurement. This indication may also include the RS to measure and the WTRU to compare with. An example of explicit indication is an RS measurement request from the network on a RS for correlation evaluation (e.g., using MAC and / or DCI command).

[0165] For example, the triggers may include implicit indications from the network, such as regular indications from the network that also trigger a correlation evaluation. For instance, the trigger may include implicit indications such as a mobility event (e.g., handover, changing serving cell / beam). For example, when the WTRU may be instructed to perform hand over to another cell, it may trigger the correlation evaluation. For instance, the trigger may include implicit indications such as RS (re)configuration. For example, when the WTRU may receive a new RS configuration for the correlation evaluation, the WTRU may perform the measurement to establish the correlation type on that RS.

[0166] For example, the triggers may include change in WTRU aggregation group (e.g., adding and / or removing a WTRU in the group of aggregated and / or potentially aggregated WTRUs). The trigger may include a change in configuration and / or capabilities of a WTRU in the group. For instance, when a WTRU receives aggregation (re)configuration and a new WTRU may be added to the group, a WTRU may perform the measurement to evaluate the correlation with that new WTRU. For instance, when a WTRU receives an aggregation (re)configuration where another WTRU of the group is removed and the WTRU had acorrelation established with that removed WTRU, the WTRU may evaluate similar correlation with another WTRU to maintain an active correlation (e.g., if needed for some aggregation feature).

[0167] For example, the triggers may include measurements on RSs. For instance, when a WTRU measurement changes in signal quality (e.g., variation compared to a previous measurement beyond a threshold, signal quality lower than a threshold, beam failure detection, etc.) for a RS used in a correlation with another WTRU, the WTRU may re-evaluate the correlation on that RS.

[0168] For example, the triggers may include an aggregation feature activation (and / or activation condition verification) and / or maintaining an aggregation feature with correlation constraints. For instance, a WTRU may be (pre)configured with an aggregation feature that has correlation requirements and it is necessary to check that these requirements are satisfied to enable the feature activation or maintain the feature activated. For instance, when a feature is activated, the WTRU starts a regular evaluation of the correlation with the corresponding WTRU(s) and the corresponding feature requirements. For instance, a WTRU may be (pre)configured to trigger the activation of an aggregation feature and / or check for feature requirement by battery level threshold, energy saving mode (de)activation. In an example, the WTRU may evaluate correlation with other WTRUs when its battery is low or it reduces energy consumption, and may then perform aggregation feature with other WTRUs (e.g., to delegate some processing or transmissions). For instance, a WTRU may be (pre)configured to trigger the activation of an aggregation feature and / or check for feature requirement by data buffer status (e.g., payload size, QoS requirements). In an example, the WTRU may evaluate correlation with other WTRUs when the buffer status is beyond a threshold and may then perform an aggregation feature with other WTRUs (e.g., to perform joint transmissions).

[0169] For example, the triggers may include transmission error and / or signal quality. For example, when the WTRU receives HARQ negative acknowledgement (NACK) indications while using an UL transmission aggregation feature, and / or when the WTRU detects a beam failure, a PDCCH / PDSCH RSRP below a threshold, etc., the WTRU may re-evaluate the correlation between the WTRUs of that feature and / or on the RS corresponding to the transmissions.

[0170] For example, the triggers may include a request from another WTRU. For example, the WTRU may be a GC that receives a request from a WTRU of the group to perform the correlation evaluation and / or may include which RS and / or WTRU to perform the evaluation with.

[0171] In some examples, the WTRU may be (pre)configured to report one of the triggers described above and herein and / or one or more of the following indications to the network: the WTRU desiring to enable and / or activate an aggregation feature; the WTRU indicating the proximity presence of anotherWTRU or the indication of a group of aggregated WTRUs; a SL CSI report (e.g., indicating that the signal quality between two WTRU changed and / or crossed thresholds); the distance to / from / between other WTRUs; the connectivity with other WTRU(s) (e.g., SL and / or short-range communication); the WTRU (de)activating energy saving mode; the WTRU data queue and / or corresponding QoS. The WTRU may report the triggers and / or indications using, for example, an UL MAC and / or RRC signaling. The network may trigger the correlation evaluation to the WTRU based on the indication(s), for example, using an explicit command (MAC-CE and / or RRC).

[0172] In some examples, where the network is triggering the inter-WTRU correlation measurement, the WTRU may be (pre)configured with periodic, semi-persistent or aperiodic RS measurement and / or reporting and indicated to perform the measurement on the corresponding RS (e.g., explicitly or implicitly). For example, when a WTRU is (pre)configured with a semi-persistent and / or periodic RS, the WTRU may measure inter-WTRU correlation on a subsequent (e.g., the next) transmission(s) of the RS. The WTRU may be (pre)configured with an offset to allow the WTRUs to coordinate and / or measure inter-WTRU correlation the same RS on a subsequent RS transmission. For example, when the WTRU is (pre)configured with a semi-persistent RS, the WTRU may use the received network indication (e.g., explicit or implicit indication), as an activation of the RS transmission by the network. For example, when the WTRU is (pre)configured with an aperiodic RS, the inter-WTRU correlation measurement may be performed on the transmission(s) of the aperiodic RS.

[0173] In some examples, where the WTRU is triggering the inter-WTRU correlation measurement, the WTRU may use one of the periodic and / or active semi-persistent RS for the measurement. The WTRU may measure one of the RS(s) after the WTRU sends the request to others WTRUs. For example, a subsequent and / or the first next transmission of the RS may be measured. For example, an offset may be indicated and / or pre-configured to allow the other WTRUs to prepare and / or measure the same RS on a subsequent RS transmission.

[0174] In some examples, where the WTRU is triggering the inter-WTRU correlation measurement, the WTRU may use one of the aperiodic RS(s) for the measurement. The WTRU may send the correlation measurement request to the other WTRUs and wait for the network to request that RS measurement. Also, or alternatively, the WTRU may request the network to transmit the RS (e.g., indicating the desired RS ID(s) using MAC-CE and / or uplink control information (UCI) indications).

[0175] The WTRUs and the RSs to perform the inter-correlation measurement may be determined. One or more of the following may apply. In some examples, the WTRU may determine which WTRUs to send thecorrelation evaluation request to. The selection may be based on the group of WTRUs for the aggregation and / or the triggers of the procedure.

[0176] In some examples, a WTRU may determine the others WTRUs to perform the correlation measurement with for its inter-WTRU correlation measurement, for instance, a WTRU triggering and selecting the potential correlation WTRUs for itself.

[0177] In some examples, a WTRU (e.g., the group coordinator) may determine the WTRUs to perform the measurement for another WTRU (e.g., another WTRU in an aggregation group). This may be performed when a GC is configured and responsible for the aggregation management, and that receives the configurations (e.g., WTRU capabilities, positions, etc.) of the other WTRUs.

[0178] In some examples, the WTRU may select all the WTRUs in the aggregation group. For instance, when the procedure is triggered to identify the WTRUs with correlation on one or a specific RS, which may result from a mobility event (e.g., changing cell), a change of aggregation group and / or evaluating on RS(s) that have not being evaluated by the WTRU recently.

[0179] In some examples, the WTRU may select a specific WTRU to perform inter-WTRU correlation measurements if, for example, the correlation measurement procedure is triggered by the WTRU joined the aggregation group and / or that WTRU shared new configuration and / or capabilities.

[0180] In some examples, the WTRU may select WTRUs to perform inter-WTRU correlation measurements based on their capabilities. For example, the WTRUs in the group that are compatible with the expected aggregation feature that the WTRU intends to use the RS and correlation may be selected for inter-WTRU correlation measurements.

[0181] In examples, the WTRU may select WTRUs based on inter-WTRU proximity (e.g., based on distance, position, zone ID, inter-WTRU connectivity (e.g. ideal link, short range communication, SL RSRP higher than a threshold, etc.).

[0182] In examples, the WTRU may receive a request from a WTRU in the group to perform the correlation evaluation, and that requesting WTRU may then be one of the selected WTRUs for the correlation measurement. Also, or alternatively, a WTRU may be (pre)configured to send an indication to the network (e.g., the trigger conditions, inter-WTRU distance, inter-WTRU connectivity, aggregation group or group changes, etc.) and the network may determine the WTRUs to perform the correlation measurement. The WTRU may receive the determined set of WTRUs to perform the correlation measurement.

[0183] In some examples, a WTRU may determine the correlation requirement based on the aggregation feature it desires to enable and / or activate. For example, certain aggregation features may be constrained (e.g., to having a sufficient correlation for the Uu channels of the WTRUs, for correlation type, levels and / or a threshold criterion value).

[0184] In some examples, a WTRU may be (pre)configured with a set of correlation requirements (e.g., correlation type, level, metric, and / or threshold) and with aggregation features referring to one of these correlation requirements separately. The (pre)configured set of correlation requirements for features may be part of the WTRU capabilities (pre)configuration. Also, or alternatively, a WTRU may be (pre)configured with a feature with multiple correlation requirements.

[0185] For example, a WTRU may be (pre)configured with the feature of delegating a RS measurement to another WTRU, where the RS report may be configured with PMI and / or narrow-band reports. This feature configuration may indicate that inter-WTRU correlation is constrained to having established a small-scale fading correlation between the WTRUs. The WTRU may further be configured with another feature, such as a joint UL transmission, using SFN, which may be constrained to having established a beam correlation between the WTRUs, with a given RSRP threshold.

[0186] When activating and / or preparing an (e.g., aggregation) feature, a WTRU may select the correlation requirement corresponding to the (pre)configured feature, and the WTRU may use this requirement in a subsequent correlation evaluation and / or in determining whether the correlation is established or not.

[0187] In some examples, the WTRU may determine the (subset of) RS(s) on which it wants to request a correlation measurement procedure. For example, the WTRU may select the RS(s) based on the signal quality of the RS(s). For instance, the WTRU may select the RS with a CQI / RSRP higher than a threshold, indicating that the RS is received with a good enough quality, so that an aggregation feature requiring a good signal quality on a RS would be satisfied. For instance, the WTRU may also, or alternatively, select the RS with CQI / RSRP lower than a threshold, indicating that the RS is received with a poor quality, so that an aggregation feature is worth being activated on that RS (e.g., a feature helping the WTRU receiving with better signal quality).

[0188] For example, the WTRU may select the RS(s) based on the aggregation feature to be activated. For instance, the WTRU may select the RS(s) based on the aggregation feature to be activated if the WTRU receives a DL grant (e.g., periodic configured grant), where the grant indicates a TCI state with reference to a given RS. If the WTRU is triggering the correlation measurement procedure to enable anaggregation feature for this DL grant, the WTRU may include this RS in the correlation measurement procedure. For instance, if the WTRU performs an aggregation feature on a specific RS or SSB, the WTRU may select that RS or SSB to be measured for correlation.

[0189] For example, the WTRU may select the RS(s) based on the TCI information and QCL state of the RS(s). In instance, if the WTRU is (pre)configured with RSs that have a QCL relationship (e.g., a QCL TypeA, based on the TCI configuration of the RSs), meaning that the transmission parameters and channel for the two RSs are very similar, the WTRU may select only one of these QCL’ed RSs to be measured for inter-WTRU correlation.

[0190] The WTRU may also not sub-select RSs and send all the configured RSs to other WTRUs to evaluate the correlation on all possible RSs. This may, for example, be the case when the correlation evaluation is performed because of another WTRU joining the aggregation group, when the WTRU changes its cell and / or beam, and / or when the WTRU is moving.

[0191] In some examples, the WTRU may determine the recurrence of the correlation measurement. For instance, the WTRU may determine whether the correlation measurement is permanent (e.g., until reconfiguration), semi-permanent (e.g., with activation and / or deactivation triggers) and / or as a one-time (e.g., aperiodic) measurement.

[0192] In examples, if a WTRU triggers the correlation evaluation procedure to update the correlation type for the aggregated WTRU, the correlation measurement may be a one-time event. The one-time event may be used to evaluate whether some aggregation features may be activated or not. In this case, the WTRU may request the network to transmit one of the aperiodic RS.

[0193] In some examples, the WTRU may be (pre)configured to perform the correlation measurement permanently or semi-permanently, for example, when an aggregation feature is initiated and requires that the correlation is maintained.

[0194] In some examples, the WTRU may select the RS(s) used for the inter-WTRU correlation measurement based on the correlation requirement and the RS configuration. As an example, when the WTRU selects an RS for a periodic correlation measurement, the WTRU may select one of the configured periodic RS(s). As an example, when the WTRU selects an RS for a semi-permanent correlation measurement, the WTRU may select one of the configured permanent or semi-permanent RS(s). As an example, when the WTRU selects an RS for an aperiodic correlation measurement, the WTRU may select one of the configured permanent, semi-permanent, or aperiodic RS(s).

[0195] In some examples, the WTRU may send a request to the network to be configured with an RS that has the certain (e.g., suitable) characteristics. The WTRU may send a request to the network to activate an RS (e.g., for semi-persistent RS). The WTRU may send a request to the network to be scheduled with an aperiodic RS. The WTRU may determine to send such a request to the network when, for example, the configured, active, and / or scheduled RS(s) are not suitable for the correlation.

[0196] In some examples, the WTRU may be configured to deactivate the correlation measurement whenever the aggregation feature is also deactivated. The WTRU may indicate the network that the aggregation feature is deactivated and that the RS the measurement relied on is no longer needed, so that the network may deactivate it (e.g., for semi-persistent) or reconfigure it. Also, or alternatively, a WTRU may be (pre)configured by the network with the RS to use for performing the correlation measurement, for example, indicated in the network trigger using the corresponding RS IDs. The WTRU may receive this indication explicitly, or implicitly (e.g., when a RS (re)configuration is sent to the WTRU). The WTRU may use this as the RS to use for the evaluation.

[0197] Correlation measurements may be requested, and the associated configuration may be sent. In some examples, the WTRU may send an indication and / or request to a (e.g., selected) group of aggregated WTRUs to evaluate the channel correlation on the selected RSs. The WTRU may send a request that includes an indication (e.g., implicit or explicit) of the (e.g., selected) RS configuration to perform the measurement, the measurement quantity to report, the WTRU to report to, and / or the recurrence of the measurement. In some examples, a WTRU may send this request for correlation measurements using a unicast transmission (e.g., SL unicast transmission) to each WTRU (e.g., separately). For example, the content of the indication may be limited to WTRU specific configurations. In some examples, a WTRU may send this request for correlation measurements using a grouped transmission (e.g., SL groupcast and / or broadcast) to the group of WTRUs, and the content of the request may include the configuration for the concerned WTRUs. If, for example, the configuration is different from one user to another, the indication may indicate which configuration is for which WTRU (e.g., differentiated with WTRU IDs). In some examples, the WTRU may send this correlation evaluation request using sidelink control information (SCI) (e.g., a CSI request included in the SCI), where the RS to report refers to the RS for correlation measurement. In some examples, the WTRU may send this correlation evaluation request using a SL MAC indication (e.g., a new SL MAC-CE). In some examples, the WTRU may send this correlation evaluation configuration using a SL RRC (re)configuration message.

[0198] In some examples, the WTRU may send a correlation evaluation request that includes the RS measurement and / or reporting configuration for correlation evaluation, for instance, including the RS sets and RS resources configurations, and the correlation evaluation metrics or report configuration. The RS set and RSs are also indicated with IDs, for example, the one that the WTRU received for its own RS configuration, and / or a distinct set of RS IDs. The IDs may be subsequently used to identify the RS measurements made by the other WTRUs when reporting back to the requesting WTRU. The requesting WTRU may include the RS configuration in the case where the RS is WTRU specific and / or not (yet) configured at the other WTRU side.

[0199] In some examples, the WTRU may send a request that indicates the RS to use for performing the correlation measurement (e.g., explicitly via the RS ID). The requesting WTRU may also indicate a measurement quantity to report and a destination WTRU, if not (pre)configured jointly with the RS configuration and / or if different than the (pre)configuration. The WTRU may use the RS ID indication if, for example, the WTRUs already have a common configuration for the RSs resources, measurement, reporting, and / or correlation type etc.

[0200] In some examples, the requesting WTRU may (e.g., explicitly) indicate the report(s) type (e.g., the channel matrix, RSRPs, PMI, etc.). If, for example, the requesting WTRU does not indicate the report(s) type, the WTRU may send the correlation type and / or correlation evaluation metrics, if not being preconfigured, and the other WTRU may determine the report and / or report type based on the metrics. For instance, for a channel matrix distance-based metric, the other WTRU may report its channel matrix.

[0201] A WTRU may be (pre)configured with a reporting configuration including a reporting timing configuration (e.g., a timing window and / or maximum latency to report), to indicate when the WTRU may perform their correlation measurement reporting (e.g., and also when a requesting WTRU may expect the report). The requesting WTRU may monitor for a report in that timing configuration. The WTRU receiving the request may use this timing configuration to constrain the correlation report. The lack of reporting within the (pre)configured latest time may be considered, by the requesting WTRU, as an unavailability and / or failure from the other WTRU.

[0202] Also, or alternatively, the WTRU may send the selection of WTRU(s), RS(s), and measurements to the network (e.g., using MAC and / or RRC signaling), and the network may send the configuration and requests to the other WTRU(s), via DL MAC-CE, and / or RRC signaling.

[0203] Channel measurement for inter-WTRU correlation may be performed. A WTRU may receive and / or measure the RS for correlation evaluation according to the (pre)configuration, transmitted by the network.Depending on the configuration, the WTRU may receive the RS transmission for correlation measurement periodically, semi-periodically, and / or a-periodically; and the WTRU may be triggered by the corresponding RRC, MAC and / or DCI (de)activation and / or signaling.

[0204] In some examples, the WTRU may receive the RS measurement indication (e.g., (de)activation and / or scheduling) using a WTRU-specific indication, and the WTRU may forward this measurement indication to other WTRUs for the measurement (e.g., using SL-RRC, SL-MAC or SCI indication, and / or using other inter-WTRU communication systems).

[0205] In some examples, the WTRU may receive the RS measurement indication (e.g., (de)activation or scheduling) to the group of WTRUs (e.g., the aggregation group, as a group-common command). The WTRUs in an aggregation group selected for correlation evaluation may perform the measurement on the selected RS. The WTRUs may measure the configured RS(s) for the correlation evaluation based on the RS resource configuration and / or following the configured measurement(s) to report. The WTRU may be configured to perform more than one measurement. For example, the WTRU may be configured to report to the network the RSRP value of the RS and / or perform the correlation evaluation with another WTRU using channel matrix distance (e.g., the WTRU may evaluate both measurement values and store the correlation measurement until finishing the correlation evaluation procedure).

[0206] Channel measurements may be reported to and / or from another WTRU. In some examples, a WTRU may receive the inter-WTRU channel correlation measurements from the other selected WTRU(s). For example, the report may be received on the SL interface, in a PSSCH transmission (e.g., via a SL MAC indication). The WTRU may receive the report within a time window between the RS reception and the report, and this time window and / or latency-bound may be provided and / or included in the correlation evaluation configuration. If, for example, an inter-WTRU correlation measurement report is not received in the configured timeframe, the WTRU may determine that the other WTRU was not able to perform the measurement and / or that the other WTRU declined the request.

[0207] The WTRU may receive the report. For example, the report may include the reported quantity and / or the corresponding indications to identify the RS, when multiple RS may be reported (e.g., over time and / or a combined RS report). The identification of the RS may include the corresponding RS ID; a timestamp of the measured RS (e.g., as an absolute time value, relative time value, or an index compared to the report); and / or the sub-band(s) corresponding to the measurement(s).

[0208] In some examples, the WTRU may receive the report including the measurements along with the corresponding RS IDs (e.g., so that the WTRU may identify which measurement corresponds to which RS).

[0209] In some examples, the RS IDs may be common to the WTRUs (e.g., as commonly configured by the network and / or because the WTRU sent the RS configuration with its own RS ID). If the RS IDs are common to the WTRUs, the WTRU may directly associate the received RS ID with its own RS ID.

[0210] In some examples, the RS IDs may be separately and / or differently configured at the WTRU side (e.g., due to independent configuration by the network). If the RS IDs are separately and / or differently configured, the WTRU may also, or alternatively, receive a mapping that indicates the WTRU’s RS ID and the other WTRU’s RS ID (e.g., by the network), so that the WTRU may use this mapping to associate the received measurements to its RSs.

[0211] In some examples, the report includes the ID of the QCL and / or reference signal of the received RS instead of the RS ID, and the WTRU looks up in its own RSs for the common QCL and / or reference signal and associates the QCL and / or reference signal of the received RS together.

[0212] The correlation among a (sub)set of WTRUs and RSs may be determined. In some examples, a WTRU may determine whether a group of WTRUs may have inter-WTRU correlated channel conditions with respect to the measured RS(s), for example, based on: the received RS measurement from the other WTRUs; its own RS measurements (e.g., if included in the selected measurement group); the configuration of the reporting for correlation measures; and / or the correlation criterion configuration (e.g., metrics and thresholds).

[0213] After receiving the measurement report from the other WTRU, the WTRU may calculate one or more of: the correlation metrics (e.g., based on the configured correlation criterion), the received measurements, and / or the measurements the WTRU performed itself. The WTRU may then compare the metric(s) with the thresholds or requirements to determine whether the measurements are correlated and with which correlation type, for a given RS and for a given sub-band or sub-band set.

[0214] In some examples, the WTRU may be able and / or configured to evaluate multiple metrics for a given RS. The WTRU may be able and / or configured to evaluate correlation for multiple RSs. The maximum number of correlation evaluations that can be performed by a WTRU may be (pre)configured and / or indicated by the WTRU (e.g., as a WTRU capability). The WTRU may be able and / or configured to evaluate a given correlation on a single RS and / or multiple RS at once. The WTRU may be able and / or configured to evaluate a correlation for different sub-bands / sub-band sets of a given RS, jointly over all the sub-bands / sub-band sets, and / or on the wideband RS.

[0215] In some examples, the WTRU may be (pre)configured to evaluate correlation based on the channel matrix distance between the WTRU’s channel matrix and the other WTRU’s channel matrices. Toperform the calculation, based on (pre)configuration, the WTRU may calculate the matrix distance as the norm of the matrix difference (e.g., using the Frobenius norm and / or Euclidian Norm (and / or 2-Norm or spectral norm)). For example, the WTRU may normalize the channel matrices calculating the difference. The WTRU may determine that the correlation criterion is passed when the norm value is lower than the (pre)configured threshold. Multiple thresholds may be included in the configuration, for example, to introduce a granularity of how corelated (e.g., highly or lowly correlated) the channels are, even within a correlation type.

[0216] If, for example, the RSRP, RSSI, SINR, and / or CQI difference is used over a number of RSs, the WTRU may receive the RSRP, RSSI, SINR, and / or CQI of the other WTRU on the set of RSs. The WTRU may then calculate the absolute difference (e.g., for each RS). The WTRU may determine that the correlation criterion is passed when more than the configured minimum number of RSs have a difference lower than a configured threshold. In certain scenarios (e.g., if evaluating for a single RS) the difference may be (e.g., may have to be) lower than the configured threshold on that single RS for the correlation to be valid.

[0217] In some examples, the WTRU may evaluate the correlation criterion based on PMI reports. The correlation criterion may be based on whether the WTRUs select the same precoding matrix for the reception of DL signals on the RSs. For example, the WTRU may determine that the correlation criterion is passed when the PMI report is identical. Also, or alternatively, the WTRU may determine that the correlation criterion is passed when the WTRU reports the same precoding matrices (e.g., but not necessarily in the same order). The WTRU may determine that the correlation criterion is passed when there are at least a configured number of common precoding matrices.

[0218] In some examples, the WTRU may determine that the correlation criterion is passed based on a timing window (e.g., where the correlation criterion has to be passed over the given configured time window and / or a successive number of RS measurements). A relaxed criterion may be configured, for example, to allow measurements to not pass the criterion a configured number of occurrences within the time window and / or number of evaluated RSs. If the correlation evaluation uses a timing window, the WTRU may determine that the correlation criterion is passed when the difference in values of the measurements / quantities (e.g., for RSRP) are constant (e.g., or within a configured maximum variation bound), for example, so the WTRUs may still be considered as correlated, including the offset as an additional correlation report value.

[0219] In some examples, the WTRU may determine that a previously established correlation with a WTRU on a RS(s) is no longer satisfying the criterion (e.g., based on the calculated correlation metrics). This determination may be made when, for example, the WTRU is configured with successive evaluations of the correlation (e.g., using a periodic or semi-periodic RS) and / or when an aperiodic RS correlation evaluation follows a previous evaluation. In this case the WTRU may trigger and / or request correlation (re)evaluation with the WTRU (e.g., on a new set of RSs) and / or with other WTRUs (e.g., to fit the aggregation requirements), and / or the WTRU may fallback to a non-aggregation mode with the WTRU if the correlation is not enough for the aggregation feature.

[0220] In some examples, a WTRU may determine and / or estimate complementary inter-WTRU correlations on some RSs that have not been directly measured / compared (e.g., using the complementary inter-WTRU correlation techniques described herein).

[0221] In some examples, a WTRU may determine a (sub)set of WTRUs from the WTRUs that reported the correlation measurements and RSs, based on the determined correlations for the WTRUs on some RSs, and based on the requirements or triggering conditions. Criterions for sub-selection may include one or more of the following. For example, criterion for sub-selection may include trigger conditions or network requests. Criterions for sub-selection may include aggregation feature requirements (e.g., correlation type and / or thresholds, WTRU number). Criterions for sub-selection may include inter-WTRU connectivity. Criterions for sub-selection may include a WTRU’s capabilities and / or one or more other WTRUs’ capabilities. Criterions for sub-selection may include the data buffer status (e.g., payload size, QoS requirements, etc.).

[0222] In some examples, the WTRU may select the (e.g., all of the) WTRUs for each RS and / or RS set, so that the WTRU may report the overall channel correlation situation. For example, the WTRU may select (e.g., all of the) WTRUs for each RS and / or RS set if the WTRU received a correlation evaluation trigger from the network. The network may use this information for WTRU pairing, and / or scheduling and transmission optimization for example.

[0223] In some examples, the WTRU may select a subset of the WTRUs based on (pre)configuration (e.g., if the WTRU is configured to be limited to a maximum number of WTRUs for each RS, group of RSs or RS sets). In that case, the WTRU may select the configured maximum number of WTRU(s), for example, by selecting (e.g., randomly selecting) among the WTRUs that satisfy the criterion and / or by selecting the WTRUs with the highest correlation metrics.

[0224] In some examples, the WTRU may select a subset of the WTRUs based on WTRU capabilities (e.g., if the WTRU(s) having inter-WTRU correlation are capable of supporting a limited number of correlation measurements / establishments at a time). For example, the WTRU may select other WTRUs to accommodate to these limits (e.g., selecting different WTRUs for different RSs).

[0225] In some examples, the WTRU may select a subset of WTRU(s) based on the correlation type (e.g., only selecting the WTRUs with a specific correlation type, metric, and / or threshold on the RSs). The correlation criterion for selection may, for example, be based on the network request and / or aggregation feature requirement.

[0226] In some examples, the WTRU may select a subset of WTRUs for which a (e.g., set of) beam(s) have established a correlation (e.g., the beam correlation (IUC-TypeC)). If the WTRU selects a subset of WTRUs for which a set of beam(s) have established a correlation, the criterion may be used to indicate that the WTRUs have received a satisfying signal reception on the RSs and / or beams. The WTRU may be (pre)configured to select (e.g., at least) a given number of WTRU(s) (e.g., out of the selected WTRUs satisfying the criterion) is enough for the subgroup selection. This may be used, for example, for beam management (e.g., where the network and / or WTRUs know a set of beams that enable Uu communication with the group) and / or for beam failure detection.

[0227] In some examples, a WTRU may select multiple WTRUs, and may perform a further WTRU sub- selection, for example, based on the inter-WTRU connectivity (e.g., preferring a WTRU with wired connection over a SL connection) and / or based on the energy status of the WTRUs (e.g., avoiding WTRUs with low energy).

[0228] The correlation measurement results may be reported. A WTRU may report the determined inter- WTRU channel correlations, to the network and / or to other WTRUs. In some examples, the WTRU may be (pre)configured to report the correlation measurement results to the network (e.g., using UL MAC-CE and / or RRC signaling). For example, the WTRU may report the correlation measurement results to the network when the trigger for the correlation evaluation was network-based.

[0229] The WTRU may also, or alternatively, report the inter-WTRU correlation established with other WTRUs in a (semi-)periodic manner and / or aperiodic, for example, based on network configuration (e.g., the measured RS reporting configuration).

[0230] The WTRU may be (pre)configured to send a cumulative report (e.g., only announcing new correlations to the network (adding or removing WTRU(s))). The WTRU may also, or alternatively, send anabsolute correlation report, which may describe the current correlation status of the WTRU (e.g., removing previously known correlations, if any).

[0231] The WTRU may send the inter-WTRU correlation report including, the correlation type(s) and / or metric value(s), based on the reporting and correlation configurations for the different RSs and / or the WTRUs that have been (sub)selected and identified by their WTRU ID. The inter-WTRU correlation report may include the results for the different RS(s) (e.g., identified by RS IDs). The report may indicate multiple WTRUs, for example, for a given correlation type on a given RS. The report may indicate multiple correlation types satisfied, for example, for a given WTRU on a given RS. The report may indicate that a WTRU satisfies has correlation established on multiple RSs.

[0232] In some examples, the WTRU may report that another WTRU may have a correlation type of large- scale fading correlation on a selected group of RSs with itself, and / or another group of WTRUs may have a small-scale fading correlation on another (e.g., group of) RS(s) with a given value for the channel matrix distance. A WTRU may send the report for measurements to perform itself, for example, to report the correlation it has established between itself and other WTRUs.

[0233] In some examples, the WTRU, for example, a GC of an aggregation group, may report inter-WTRU correlation measurements for other WTRUs. For example, a WTRU may report correlation measurements between WTRU pairs (e.g., either based on received correlation reports from these WTRUs and / or based on received measurement that the WTRU use to determine the correlation with). The WTRU may report correlations to the network, and the report may include the WTRU ID(s), in addition to the other WTRUs when needed, so that the network knows it is included in the group of correlated WTRUs.

[0234] In some examples, a WTRU may be (pre)configured to report the determined correlation to another WTRU (e.g., using SL MAC and / or SL PC5-RRC signaling), and / or other available inter-WTRU interfaces. For example, the WTRU may be (pre)configured to report to the WTRU(s) for which the WTRU evaluated the correlation. The WTRU may be (pre)configured to report to the (sub)selected WTRU(s) that have inter- WTRU correlation. The WTRU may be (pre)configured to report to a (pre)configured reporting WTRU (e.g., the GC of an aggregation group).

[0235] If a WTRU reports to a (pre)configured WTRU (e.g., such as the GC), the report content may be similar to the report content described herein for the network. The GC may centralize the inter-WTRU correlation of the WTRUs in the group, and forward, indicate, and / or report the inter-WTRU correlation to the WTRUs having inter-WTRU correlation established.

[0236] If a WTRU reports to a WTRU it has inter-WTRU correlation with, the report may be limited to the correlation type(s) and / or values and the corresponding RSs. The report may also include other WTRU IDs, when additional (e.g., third and / or more WTRUs) WTRUs in the group are correlated with the reporting WTRU and the WTRU being reported to. If, for example, there are additional correlation types, values, and / or RS(s) for other additional WTRUs, these correlation types, values, and / or RS(s) may also be included in the report.

[0237] The correlation report may be a cumulative report (e.g., only announcing new correlations (adding or removing RSs and correlation type(s))). Also, or alternatively, the correlation report may include the current correlation status with the WTRU (e.g., removing previously known correlations, if any). If the aggregation is concerning a group of WTRUs, the report may also include the ID and / or correlation of the other WTRUs in the group.

[0238] Alternative reporting may be implemented. In some examples, a WTRU may report the absence of a correlation with a group of WTRUs and / or on a set of RSs (e.g., when the WTRU determines that the correlation is not satisfied). This may particularly be interesting for the case where the WTRU may be triggered to evaluate the correlation with a specific group of WTRU(s) and / or on a specific group of RS(s). For example, the specific group of WTRU(s) and / or on the specific group of RS(s) triggered for evaluation may not be determined by the WTRU itself.

[0239] In some examples, the WTRU may report the end of a correlation with WTRU(s) on some RS(s), for instance, when the WTRU previously reported the inter-WTRU correlation for those WTRU(s) and / or RS(s). The WTRU may explicitly report that a previously reported correlation is no longer established, for example, via a remove-type of indication and / or implicitly report (e.g., by not indicating the correlation when the reporting is not cumulative).

[0240] A WTRU may report the (de)activation / (dis)enablement of an aggregation feature with and / or to a given WTRU (e.g., instead of reporting the correlation type / metrics). For example, if a WTRU triggers (e.g., by itself or by the network) the correlation evaluation to enable an aggregation feature and / or feature set, the report may indicate whether the feature(s) are supported and / or enabled, based on the feature requirement for correlation. For example, if a WTRU is (pre)configured with a feature that requires a large- scale fading correlation on a given RS, the WTRU may report that the feature is (dis)enabled and / or (non)supported, based on the determined correlation. In examples, the feature requirement may implicitly indicate whether correlation has been established (e.g., and / or on which RS). In some examples, the reported entity may look up the feature requirement and determine the actual correlation type that wassatisfied. A WTRU receiving such a report may implicitly and / or explicitly (de)activate the corresponding aggregation feature between the WTRUs.

[0241] One or more of the following may be described from the perspective of an assisting WTRU (e.g., the WTRU that receives the correlation evaluation request, may perform the measurement, and / or sends the measurement report to the requesting WTRU).

[0242] In some examples, a WTRU may receive similar RS measurement / reporting and correlation configuration to those described above and herein (e.g., RS(s) configured as a group, received by a network or by a WTRU, etc.).

[0243] In some examples, the WTRU may receive the RS measurement and reporting configuration from another WTRU (e.g., the WTRU that received the RS configuration from the network). The received configuration may (e.g., originally) be WTRU-specific to another WTRU, and the WTRU may need to verify whether the received RS configuration is suitable and / or acceptable.

[0244] In some examples, the WTRU may check the RS resource configuration, and verify whether the same RS resource configuration is already included in its own RS configuration. For example, if a WTRU receives an RS that matches an already configured RS, the WTRU may create and / or maintain a RS ID mapping, for instance, between its own configured RS ID (from the network) and / or the RS ID (received from another WTRU). The WTRU may use this mapping to translate requests from and / or reports to the other WTRU(s) and / or so that the WTRUs may have a common understanding of the same actual RS. For example, if a WTRU receives a RS that does not match an already configured RS, the WTRU may add the RS configuration to its own list of RS, and may check for resource conflicts on that RS (e.g., due to duplexing conflict, overlapping RS resource configuration). If the RS is not suitable, the WTRU may not be able to perform the measurement for correlation and may report back that the RS configuration is not suitable.

[0245] In some examples, the WTRU may receive the request for inter-WTRU channel correlation measurement. The request may be received from another WTRU (e.g., the WTRU that will compare the measurements with its own), by a GC, and / or by the network. Requests by the network are similar to network-based triggers described herein and above.

[0246] In some examples, a WTRU may receive a request from another WTRU (e.g., received on SL via SL MAC, SL SCI indications) that indicates that the WTRU to send the correlation measurement report to and the RSs to measure. The request may also indicate the measurement and / or correlation type to evaluate (e.g., if not already included in the RS configuration). A WTRU may be requested to measure agroup-common RS, using a common RS ID to be used by the WTRU for measurement. A WTRU may be requested to measure a WTRU-specific RS of another WTRU. For example, the request may indicate the RS ID of the other WTRU. The WTRU may use a mapping to translate the received RS ID to its own RS ID, that the WTRU can use for measurement.

[0247] In some examples, a WTRU may receive a request that include explicit RS resource, measurement and reporting configurations, and the WTRU uses these configurations to perform the measurement and / or reporting.

[0248] In some examples, a WTRU may also verify whether the RS measurement is possible (e.g., whether the RS resources are not in conflict), for example, with other scheduled receptions and / or duplexing conflicts. If a conflict with the RS resources exists, the WTRU may prioritize the conflicting transmissions and / or receptions (e.g., based on priorities), which may be configured. For example, the inter-WTRU correlation RS measurement and report may be (pre)configured with a priority by the network or a WTRU, and the WTRU may prioritize conflicting transmissions and receptions based on the (pre)configured priority. If a WTRU is not able to perform or does not prioritize the inter-WTRU correlation measurement, the WTRU may report that the request was declined and / or may not send any report (e.g., to trigger the timeout at the requesting WTRU side).

[0249] In some examples, a WTRU may perform measurements and / or measure the RS channel as described herein and above. In some examples, a WTRU may report the measurement content based on the configuration (e.g., received from the requesting WTRU). A WTRU may send the report within the configured timing or time limit to the other (e.g., requesting) WTRU for the measurement to be considered valid.

[0250] The correlation types of RS(s) that have not been directly measured for correlation may be determined. In some examples, a WTRU may estimate and / or determine an inter-WTRU correlation type between WTRUs on a given RS (e.g., when the RS was not directly measured by other WTRUs). For example, the WTRU may receive and / or determine inter-WTRU correlation with another WTRU (e.g., on some of its (pre)configured RSs), including the corresponding correlation types / metrics. The WTRU may also be configured with some (e.g., other) RSs for which the measurement for inter-WTRU correlation was not performed by (e.g., some) other WTRUs. The RSs configuration may include RS IDs and QCL and / or TCI state information of the RSs.

[0251] In some examples, the WTRU may not have performed inter-WTRU measurements due to several reasons, including, for instance, the measurement was not possible at that time. For example, the WTRUmay be (pre)configured or capable of inter-WTRU correlation measurements that are limited to specific types of RSs (e.g., SSBs). In certain scenarios, however, while the WTRU may desire to establish the correlation (e.g., or perform measurements) on another type of RS than the specific type that is configured (e.g., a CSI-RS).

[0252] In some examples, the WTRU may determine (e.g., for some of its (pre)configured RSs) the inter- WTRU correlation types and / or metrics with some WTRUs, for instance, based on the received and / or determined inter-WTRU correlation types and / or metrics for other of its (pre)configured RSs and on the QCL relation of these RSs.

[0253] In some examples, to find the correspondence between configured RSs to monitor and inter- WTRU correlated RSs, the WTRU may check the IDs and the TCI states of the RSs (e.g., parameter qcl- InfoPeriodicCSI-RS in NZP-CSI-RS-Resource), if configured, indicating which RS is used as reference, for instance, a CSI-RS and / or an SSB and / or the QCL type (e.g., how similar / correlated the RSs transmissions are).

[0254] In some examples, the WTRU may compare its (pre)configured RS and the WTRU-RS pairs of the inter-WTRU correlation configuration, and may determine that a configured RS has inter-WTRU correlated channel with another WTRU if: the reference RS of the configured RS is the same as the RS with inter- WTRU correlation; the configured RS is the same as the RS of reference used for the RS with inter-WTRU correlation; and / or the reference RS of both the configured RS and the inter-WTRU correlated RS are the same.

[0255] In some examples, the TCI state may indicate a QCL relationship between the RS and the reference RS. The TCI state may indicate a QCL type (e.g., TypeA, TypeB, TypeC, TypeD, and / or the reference RS used, for instance, how closely related the channels are between the reference RS and the RS). A QCI TypeA may indicate a higher (e.g., the highest) similarity, and TypeD may indicate a looser type of similarity (e.g., only directional similarity). QCL types may be based on Doppler shift, Doppler spread, average delay, delay spread and spatial TX / RX parameter similarities.

[0256] In some examples, a WTRU may be (pre)configured with an RS that has an inter-WTRU correlation through TCI state reference RS ID, and the WTRU may adjust the inter-WTRU correlation type and / or metric value based on the QCL type in the TCI state and / or the correlation type.

[0257] In some examples, the WTRU may be (pre)configured with adjustments of inter-WTRU correlation due to RS QCL types by the network and / or the WTRU (e.g., the WTRU may receive a list and / or table of input inter-WTRU correlation types, QCL types and / or the corresponding adjusted inter-WTRU correlationtype). For example, if the TCI state indicates a QCL-TypeA, (e.g., the strongest QCL type), the WTRU may consider the inter-WTRU correlation type and metric on the configured RS is the same as the correlation on the reference RS (e.g. a small-scale correlation on the reference RS means a small-scale correlation on the configured RS). For example, if the TCI state indicates a QCL-TypeD, the WTRU may no longer assume that the small-scale fading correlation inter-WTRU correlation type is valid, if it was the case. The inter-EU correlation may be adjusted to a large-scale or a beam correlation type of inter-WTRU correlation.

[0258] Inter-WTRU Uu Channel Orthogonality establishment may be implemented. The inter-WTRU Uu channel non-correlation may also, or alternatively be established. In some examples, a WTRU may determine how non-correlated (e.g., uncorrelated and / or different) the Uu channels (e.g., each of the Uu channels) of the WTRUs are. If a WTRU determines how uncorrelated and / or different the Uu channels are, the WTRU may be able to evaluate the diversity of WTRU channels, which may be used, for example, to group WTRUs to perform aggregation features such as joint transmission and / or reception of Uu signals. Joint transmission and / or reception of signals from different WTRUs enables higher performance in throughput and / or reliability (e.g., due to joint processing of the signals as a distributed antenna system). This performance gain may be subject to WTRUs having different enough channels, so that the joint processing benefits from the diversity gain.

[0259] In some examples, a WTRU may be configured to perform the techniques described herein and above (e.g., after receiving the RS measurement from another WTRU). The WTRU may determine whether the channels of the WTRUs are correlated and / or if the channels are not correlated (e.g., based on a configured threshold on a correlation metric). For instance, if the correlation metric is higher than a threshold, the WTRU may determine that the WTRUs may be correlated, otherwise, the WTRU may determine that they are uncorrelated.

[0260] In some examples, the WTRU may be configured to perform the techniques described herein when the WTRU is configured with non-correlation thresholds, for instance, based on certain metrics, such as channel coefficient matrix difference and / or distance, RSRP, RSSI, and / or SINR difference, LoS and / or non-LoS (NLoS) of the channels, etc. The WTRU may be configured with multiple non-correlation metrics and / or thresholds for a granularity of the evaluation, similar to the IUC types described herein and above.

[0261] The WTRU may evaluate the metrics to determine the WTRUs whose channel are not correlated and / or have diversity (e.g., based on the configured non-correlation thresholds), as described herein. The thresholds may be (e.g., typically) satisfied when the channels are less correlated (e.g., LoS vs NLos, channel matrix distance is higher than a threshold etc.). There may be joint metrics needed for theevaluation, including, for instance, a good enough diversity (e.g. based on channel matrices) and a similar and / or good enough RSRP (e.g., to have a signal that is good enough from the assistant WTRU).

[0262] In some examples (e.g., where the orthogonality and / or non-correlation metric is based on PMI and / or RI reports, the WTRU may compare whether the PMI vectors of the WTRUs are the same and / or how many total different precoding vectors would be reported by both WTRUs. The WTRU may determine a rank for the common transmission(s) and / or reception(s), which may be higher than the rank of individual WTRUs separately.

[0263] In some examples, the WTRU may perform reporting, as described herein. For example, the report may indicate that the channels of the WTRUs may not be correlated and / or may be orthogonal. Different types and levels of non-correlation and / or orthogonality may be reported based on the configuration for a given RS.

[0264] In some examples, a WTRU may report whether the channels are correlated or diverse, for instance, using a flag and / or indicating the diversity similarly as a previously described correlation type. Several thresholds (e.g., for a given metric) may be configured, for instance, to have a granularity on how correlated and / or how non-correlated and / or orthogonal the channels are. The reporting may indicate either the metric value or the granularity (e.g., via an index).

[0265] In some examples, the WTRU may report how non-correlated and / or orthogonal the channels are (e.g., by indicating: the rank of the joint / common measurement on a given RS, the number of ranks / layers that are not in common, the matrix distance, etc.).

[0266] In some examples, the WTRU may be configured to evaluate and report (e.g., only) the non- correlation / diversity of WTRU channels. For example, the WTRU may be configured to evaluate and / or report only the correlation of WTRU channels. Also, or alternatively, the WTRU may be configured to evaluate and report both the correlation and the diversity and may report any of the result.

[0267] Delegated RS monitoring may be performed. A WTRU may have established that the WTRU itself and one or more member WTRUs have correlated channel conditions with respect to one or more RSs (e.g., as described herein). The report of one WTRU for that RS may then be used for another WTRU, and thus one measurement, processing, and / or reporting may be avoided, reducing the power consumption of the WTRU and improving the battery life of the device. For example, this scenario may be applicable if a low-power device is in proximity with higher-power devices, for instance, XR and / or wearable devices.

[0268] A WTRU in an aggregation group (e.g., with low power) may determine which of its RS measurements may be delegated to another WTRU, for instance, based on an established inter-WTRUcorrelation and / or RS monitoring delegation requirements. The WTRU may indicate this delegation to the determined WTRU and the network (e.g., so that the network may use the CSI report of the other WTRU on its behalf).

[0269] A WTRU, (e.g., a WTRU being assisted for RS monitoring) may be configured, as part of an aggregation group, with a set of RS measurement and reporting configurations including: the reporting type (e.g., RSRP, PMI, CQI, etc.) and / or resource configuration; and / or the inter-WTRU correlation requirements to enable RS measurement delegation. A WTRU may be (pre)configured with inter-WTRU channel correlation with member WTRUs including: the member WTRUs that have a correlated channel condition with gNB and the correlation type(s) (e.g., large-scale or small-scale); and / or the RS associated with the inter-WTRU channel correlation. A WTRU may determine a subset of RS measurement and / or reporting configuration to delegate to other WTRU(s) of the group, for instance, based on configured RS measurement reporting type and (pre)configured inter-WTRU channel correlation corresponding to the configured RS. For example, an RSRP measurement on a RS may be delegated to a WTRU with inter- channel correlation of large-scale type associated with the RS. A PMI, RI and / or LI measurement on a RS may be delegated to a WTRU with inter-channel correlation of small-scale type associated with the RS. A WTRU may request the determined WTRU(s) to perform the measurements according to the determined delegated subset of RS measurement and reporting configuration. A WTRU may report to the network the determined set of RSs that are delegated and to which WTRU.

[0270] In some examples, a WTRU may delegate the measurement and / or reporting of a RS to another WTRU (e.g., the WTRU will not be needed to perform the measurement of a configured RS), and the other WTRU will perform the measurement and reporting on its behalf. The network may receive the CSI report from the other WTRU and / or, based on the reported indications, may determine that the CSI report of a WTRU on a given RS is also applicable to the WTRU that delegated its measurement.

[0271] FIG.4 illustrates an example procedure associated with the delegation of RS measurement for an assisted WTRU, assistant WTRU, and a gNB. In procedure 400, a WTRU may trigger the RS delegation when receiving or determining the inter-WTRU correlation with another WTRU and / or in response to receiving an updated correlation configuration (e.g., when the WTRU may have new correlation information). The WTRU may determine whether one or more RS(s) may be delegated to another WTRU. Other triggers that may be used include, for example, the WTRU’s own situation (e.g., such as remaining battery life, power saving mode, or buffer status). The WTRU may trigger this delegation determination as a redetermination (e.g., to evaluate whether an ongoing delegation is still valid or not).

[0272] For example, in procedure 400 at 402, the assisted WTRU, assistant WTRU, and a gNB may be configured with RS measurement and reporting, and configured with delegation criterions. At 404, the assisted WTRU and the assistant WTRU may be configured with inter-WTRU correlation. At 406, the assisted WTRU may be triggered to delegate RSs. At 408, the assisted WTRU may determine the WTRU to delegate some RSs. At 410, the assisted WTRU may request the assistant WTRU with a delegation configuration. At 412, the assistant WTRU may accept the delegation. At 414, the assisted WTRU may report the delegation to the network. At 416, the gNB may transmit the configured RS(s). At 418, the assistant WTRU may measure the delegated RS(s). At 420, the assistant WTRU may report CSI to network on behalf of assisted WTRU using RS(s) and the delegation configuration.

[0273] Receiving configuration for RS delegation may be implemented. In some examples, a WTRU may be configured to enable or support the aggregation feature of RS delegation. For example, the configuration may include: the RS measurement and reporting configurations (e.g., the RSs the WTRU may be configured to monitor); the criterions and / or conditions to enable the RS delegation (e.g., a correlation type criterion); and / or the inter-WTRU correlation configuration with other WTRUs on the RSs.

[0274] In some examples, a WTRU may receive the inter-WTRU channel correlation from the network (e.g., receiving a MAC / RRC level indication), and / or another WTRU (e.g., receiving a report from another WTRU or a GC). Also, or alternatively, the inter-WTRU correlation may be determined by the WTRU itself based on measurements (e.g., resulting from the solutions described herein). The inter-WTRU correlation with other WTRU(s) on some RSs may be characterized by a type(s), level(s) of correlation and / or metric value(s). For example, to complement the inter-WTRU correlation that is established through measurements, the WTRU may determine and / or estimate complementary inter-WTRU correlation on other RSs, for instance, using the complementary techniques described herein.

[0275] The WTRU may receive (e.g., from the network) a set of RSs to monitor with the corresponding RS resource sets, RS resources, and / or RS report configurations. The WTRU may receive a configuration that includes the report quantity required by the network, such as, CQI, RSRP, PMI, RI, LI, and / or the sub-band configuration to measure and / or report, etc.

[0276] In some examples, the WTRU may be (pre)configured with a group-common RS, where, for instance, the same RS configuration may be sent to the WTRUs of the aggregation group (e.g., group configuration of RS or broadcast RS such as SSB). In this case, the WTRUs of the group may have a common configuration and / or understanding of the RSs and / or RS IDs.

[0277] In some examples, the WTRU may be (pre)configured with a WTRU-specific RS, such as regular CSI-RS configurations, where the network sends (e.g., only sends) the RS configuration to the corresponding WTRU. The WTRU may send that RS configuration to other WTRUs. In some examples, the WTRU may be also (pre)configured with criterion that need to be satisfied to enable the RS delegation to another WTRU.

[0278] In some examples, these criterions and / or requirements may be received from the gNB (e.g., as an RRC (re)configuration and / or MAC signaling) either as an independent configuration for the RS delegation feature, and / or jointly with the RS measurement and reporting configuration. The requirements may be common for all the RSs and / or may be RS specific, (e.g., if indicated jointly with the RS measurement and reporting configuration).

[0279] In some examples, a WTRU may be (pre)configured with criterion and / or requirements from another WTRU (e.g., a GC) that handles the management and configuration of aggregation features. For example, the criterion and / or requirements may be received via SL MAC and / or SL RRC signaling.

[0280] The WTRU may be (pre)configured with criterion for RS delegation based on the configured reporting of the RS to delegate and / or the inter-WTRU correlation between the WTRUs. For example, a CSI report that typically requires a high-accuracy measurement, may require a strong correlation between the WTRUs to enable and / or allow the delegation. For example, a WTRU may receive the configuration as a mapping and / or a table between the different measurement quantities and the corresponding minimum inter-WTRU correlation requirement (e.g., as correlation types and / or thresholds on metrics), and / or the list of possible correlation types and / or threshold metrics.

[0281] In some examples, a WTRU may be (pre)configured such that certain quantities, such as a PMI with RI and / or LI, may require an IUC-TypeA correlation (e.g., or small-scale correlation) to enable the RS delegation for that RS report. For example, a WTRU may be (pre)configured so that CQI and / or L1-RSRP require an IUC-TypeB (e.g., large scale correlation) to enable the RS delegation for that RS report.

[0282] In some examples, a WTRU may be explicitly and / or implicitly (pre)configured to enable or disable the RS delegation feature on some RSs. For example, a WTRU may, for instance, receive an RS (pre)configuration with an optional field indicating that the RS (e.g., and / or RS set) may be delegated to other WTRU(s). Also, or alternatively, a binary indication may be used for enabling and / or disabling on the RS. For example, a WTRU may receive an RS (pre)configuration that includes an indication of which types of RSs may be delegated or not. For instance, the WTRU may be configured so that RSs of type CSI-RS may be delegated, while RS of type SSB may not be delegated.

[0283] A WTRU may determine which RSs are to be delegated to which WTRUs. One or more of the following may apply. In some examples, a WTRU may determine which WTRU(s) will be performing the measurement and reporting of some configured RS(s), for instance, based on the information of which WTRUs may have inter-WTRU correlated channels, with what the type(s) of correlations and on which RSs.

[0284] In some examples, the WTRUs may have multiple correlation types that are considered valid measured on a given RS. The WTRUs may have different correlation types and / or metric values for different RSs. Different WTRUs may have different types of correlation types and / or metric values for any given RS. In some examples, a WTRU may determine which of its own RS measurement(s) and / or report(s) to delegate to other WTRU(s) and / or which WTRU(s) to delegate to.

[0285] In some examples, a WTRU may select (e.g., only) the RSs that have been implicitly and / or explicitly enabled and / or allowed to be delegated (e.g., based on the received RS configuration). For example, if the configuration indicates that only RS of type SSB may be delegated, then the WTRU may (sub)select the SSBs for delegation.

[0286] In some examples, a WTRU may select the RS for which the inter-WTRU correlation with another WTRU satisfies the RS delegation requirements. For example, the WTRU may be (pre)configured so that reporting PMI with RI and / or LI may require an IUC-TypeA correlation (e.g., or small-scale correlation) for the delegation and / or with a RS with a PMI with RI and / or LI report. That WTRU may select the WTRUs for which the inter-WTRU correlation is IUC-TypeA correlation (e.g., or small-scale correlation) on a RS for the delegation. For example, the WTRU may be (pre)configured so that reporting CQI and / or L1-RSRP requires an IUC-TypeB correlation (e.g., or large-scale correlation) for delegation with an RS with a PMI with RI and / or LI report. The WTRU may select the WTRUs for which the inter-WTRU correlation is IUC- TypeB correlation (e.g., or large-scale correlation) for that RS for the delegation.

[0287] In some examples, the WTRU may select other WTRU(s) for the delegation of some RSs, for instance, when the other WTRU(s) have the same RS measurement configuration. This configuration may be the same across WTRUs when the RS configurations are group-common, for example. When the WTRU sends its own RS configuration to another WTRU, the RS used may not be a common RS (e.g. not a RS that was configured at the other WTRU), which may increase complexity. For example, a WTRU may select the other WTRU(s) with the capability to support the aggregation feature of RS delegation.

[0288] In some examples, once a WTRU selects a set of WTRUs to monitor a RS (e.g., or set of RSs) for, the WTRU may determine how to share the RS monitoring between the WTRUs, (e.g., in time domainand / or in the spatial domain). For example, where a group of WTRUs have inter-WTRU correlation for a set of RSs / beam, the WTRU may share the monitoring (e.g., by associating each RS with one of the WTRUs), for instance, so that each WTRU is able monitor different RSs / beams. Also, or alternatively, a WTRU may share the monitoring by associating a WTRU to a set of RSs that is configured to be jointly reported. In this case, different WTRUs may be responsible for a given report. For example, where a group of WTRUs have inter-WTRU correlation for a set of RSs / beam, a WTRU may select another WTRU to be responsible for (e.g., all) the RS measurement and / or reporting that is delegated to that WTRU. If, for example, a WTRU selects another WTRU to be responsible for the RS measurement, the number of WTRUs performing measurement may decrease, which may, for example, provide a WTRU with better battery status or energy levels to perform the measurement on behalf of other WTRUs.

[0289] In some examples, where an RS is repeated in time (e.g., periodic), a WTRU may share the RS monitoring by alternating the WTRU(s) that monitor the RS (e.g., round-robin, etc.). The alternating of the WTRU(s) that monitor a given RS may be based on preconfigured patterns (e.g., by specification or received by RRC configuration), so that the WTRU may pick one of the patterns that suits the number of RSs and / or WTRUs. Also, or alternatively, the WTRU(s) that monitor a given RS may be autonomously selected for each RS and / or RS set.

[0290] In some examples, a WTRU may consider one or more of the following aspects to determine how to share / split the RS monitoring: a minimum and / or maximum number of WTRUs for a RS; WTRU battery / energy levels of the WTRUs; WTRU capabilities; and / or WTRU categories (e.g., lower-capability or lower-energy WTRUs may delegate to others while higher-energy WTRUs may perform monitoring on their behalf).

[0291] Assistant WTRU(s) may receive a request to perform correlation measurements. One or more of the following may apply. In some examples, the assisted WTRU delegating its RS measurement and / or reporting to another WTRU may indicate the assistant WTRU of the delegation decision. For example, the assisted WTRU may send a request of RS delegation (e.g., RS delegation request) to the assistant WTRU.

[0292] In some examples, a WTRU may send the RS delegation request using the SL interface (e.g., using PC5-RRC configuration). The RS delegation request may be activated after the RRC message reception until reconfiguration and / or (de)activated using a dedicated SL indication (e.g., using a SL MAC- CE activation and / or deactivation indication). The WTRU may send the RS delegation request using unicast for each WTRU and / or using a groupcast / multicast transmission to the group of WTRU in the aggregation.

[0293] In some examples, the WTRU may send an RS delegation request that includes the necessary configuration so that the other WTRU(s) may correctly receive the RSs to monitor. For example, the configuration may include the RS set(s) and / or RS(s) resources to monitor. The RS(s) and / or RS set(s) may be indicated using the RS and / or RS set IDs, for instance, in the case where the RS IDs are commonly configured across WTRUs or sending the RS and / or RS set configurations. If, for example, temporal delegation (e.g., where multiple WTRUs share the RS monitoring over time, e.g. round-robin) is requested, the WTRU may indicate the times and / or occasions where the WTRUs shall monitor the RS (e.g., using a predefined patterns index).

[0294] In some examples, the WTRU may send a RS delegation request that includes the required CSI report, so that the other WTRU may perform the correct measurement and reporting. If, for example, RSs are commonly configured across WTRUs, the other WTRU(s) may already be configured with the CSI report configuration, and an index and / or pattern indicating which RSs to monitor implicitly may indicate the report type associated with the measurement. If RSs are not commonly configured across WTRUs, a WTRU may include in the assignment the CSI report configuration for the RS(s) to monitor.

[0295] In some examples, a WTRU may send an RS delegation request that indicates the configuration of how the other WTRU(s) may report the CSI. The WTRU may send the request indicating whether the other WTRU(s) may send the CSI report to the WTRU and / or to the network directly (e.g., using an UL transmission and / or resource) on behalf of the WTRU. The RS delegation request may also indicate timing restrictions (e.g., max delay and / or timing window), that may be determined by the WTRU based on the CSI report resource configuration from the network.

[0296] In some examples, the WTRU may send the request to a GC, for instance, using SL MAC and / or SL RRC signaling, and / or the GC may forward the request to the assistant WTRU. In such an example, the request may also include the WTRU ID of the assistant WTRU.

[0297] In some examples, the WTRU may send the request via the network, for instance, using UL MAC or UL RRC signaling, and the network may forward the request to the assistant WTRU. In such an example, the request also includes the WTRU ID of the assistant WTRU. From the assistant WTRU point of view, for example, the assistant WTRU may receive the request and / or assignment for delegation (e.g., over SL MAC or SL RRC command and / or configuration).

[0298] In some example, if RS(s) are commonly configured, the assistant WTRU may receive the indication of the RS ID to monitor on behalf of the assisted WTRU and may prepare the device for the reception of this RS, if not already prepared.

[0299] In some examples, such as in the case of the delegation of a WTRU specific RS configuration, the WTRU may receive the RS measurement and / or report the configuration before the request (e.g., and / or as part of the request). When receiving another WTRU’s RS configuration, the assistant WTRU may check whether the RSs are able to be monitored, and / or if the configuration is already included in its own RS configuration, as described herein and above.

[0300] In some examples, the assistant WTRU may determine that it cannot perform the delegated measurement and reporting. For example, an assistant WTRU may determine that it cannot perform the delegated measurement and / or reporting if: the RS reporting resources are not sufficient to report the delegated measurement; the RS is not common; and / or the WTRU cannot reuse the reporting resource of the assisted WTRU for its own transmission (e.g., due to resource conflicts).

[0301] In some examples, an assistant WTRU may report to the assisted WTRU if the request is accepted or declined. This report may be sent over the SL as a MAC command, and RRC configuration, and / or using the PSFCH corresponding to the request acknowledgement.

[0302] The delegated RSs and WTRUs may be reported to the network. One or more of the following may apply. In some examples, the WTRU may indicate to the network the RS delegation between the WTRUs and RSs for monitoring (e.g., using UL MAC-CE and / or RRC messages). The WTRU may indicate similar information as the one reported to the WTRU performing the delegation, for instance, the delegated RS IDs, the corresponding assistant WTRU IDs, the repartition of RSs among WTRUs, and / or the monitoring patterns of RSs if any.

[0303] In some examples, the WTRU may be (pre)configured to (de)activate the RS delegation, for instance, via RRC (re)configuration and / or using a MAC-CE activation / deactivation indication. The network may receive this indication and may associate the CSI reports of the assistant WTRU ID, for the indicated RS, to the CSI report of assisted WTRU and / or use the report for both WTRUs interchangeably (e.g., for scheduling and / or beam management purposes).

[0304] Measurement and reporting of the RSs may be performed. One or more of the following may apply. In some examples, different behaviors may be employed by different WTRUs, for instance, depending on whether they are the WTRU that delegated the RS measurement and reporting (e.g., the assisted WTRU) and / or the one that performs the RS measurement and reporting on behalf of another (e.g., the assistant WTRU). The WTRU may perform measurements based on the configured reporting quantity of the RSs.

[0305] In some examples, a WTRU (e.g., the assisted WTRU) configured with RS measurement and / or reporting, and that did not measure the RS as part of the configured / determined delegation, may omit (e.g., not transmit) the CSI report on the configured reporting resources.

[0306] In some examples, the WTRU may still measure and / or report RSs that have been configured and / or not delegated. The WTRU may perform the configured and / or determined RS measurements (e.g., the ones that were not delegated) and / or may report the measurements using the configured reporting resources. If a delegated RS measurement is configured to be jointly reported with a measurement that was performed, the WTRU may omit the corresponding report and / or indicate that the report is delegated. In some examples, delegation may apply only on a part of the configured RSs (e.g., one RS set out of multiple RS sets, and / or some RSs within an RS set).

[0307] In some examples, a WTRU may perform the measurement on a part of the configured RS, for instance, when the WTRU is configured with the delegation sharing the RS measurement in time with other WTRUs (e.g., based on a time pattern).

[0308] In some examples, a WTRU may perform the measurement on the delegated configured RS, in addition and / or instead of the assisted WTRU, in sparse occurrences of the RS. The WTRU may report these measurements to the network as configured. These sparse measurements may be meant for the WTRU to evaluate whether the WTRU is still receiving the RS correctly and / or to evaluate that the correlation with the other WTRU is still valid (e.g., by comparing the measurements, for instance, in a similar fashion as described herein and above). For example, an assisted WTRU may be configured with a periodic RS that has been (e.g., entirely) delegated to another WTRU. The assisted WTRU may perform the measurement on that RS periodically, for instance, once every N RS transmissions (e.g., once every N=10 transmissions). Also, or alternatively, the WTRU may perform the measurement regularly based on time, for instance, once every M milliseconds (ms) (e.g., once every M=1000ms) and / or the nearest RS transmission of that regular time. For example, a WTRU may be triggered to perform the measurement on a delegated RS by the network, the other WTRU, the GC, and / or the WTRU itself. A WTRU may be triggered to perform the measurement on a delegated RS by other triggers described herein and above.

[0309] In some examples, when a (e.g., assistant) WTRU receives a delegated RS measurement report from another WTRU, the WTRU may report the received report to the network (e.g., using its reporting resource configuration). The received report may be reported jointly with self-measured RSs. The WTRU may indicate in the report that the received measurement was delegated.

[0310] In some examples, a WTRU (e.g., the assistant WTRU), may perform the measurement of the delegated RS based on the RS configuration and / or reporting measurement. These measurements may be performed in addition with the measurements already configured for the WTRU itself.

[0311] In some examples where the RS configuration is common between the WTRU itself and the delegated RS, the WTRU may perform the measurement on that RS based on the configuration and reports using its own RS resource reporting. If the measurement to perform on the RS is not the same as the self-configured and / or the delegated measurement, the WTRU may perform the measurement to acquire both reporting quantities.

[0312] In some examples where the delegated RS was not initially configured to the WTRU, the WTRU adds the received configuration to its measurement tasks and / or measures according to the (e.g., received) delegated RS measurement and / or reporting configuration.

[0313] For example, the report may (e.g., explicitly) indicate that the measurement is a delegation for another WTRU, for instance, indicating the assisted WTRU ID and the delegated RS ID (of the assisted WTRU) corresponding to the report. Also, or alternatively, a binary indication may be used to indicate that the report corresponds to a delegated measurement (e.g., based on a previously indicated delegation report and / or configuration sent to the network, as described herein and above).

[0314] In some examples, the WTRU’s report may include both measurements configured for itself, and / or measurements that have been delegated by assisted WTRUs. In some examples, the WTRU may transmit the report of delegated measurements using its own configured reporting resources (e.g., when the RS configuration was common, and / or when the WTRU may be (pre)configured with reporting resources not used by other measurements). In some examples, the WTRU may receive (pre)configured reporting resources for delegation by the network, for instance, periodic and / or semi-periodic resources, that the WTRU may use for it assists another WTRU for RS measurements. In some examples, the WTRU may transmit the report of delegated measurements using the delegated RS report resource configuration (e.g., using the assisted WTRU’s reporting resource). In some examples, the WTRU may report the RS measurement quantity to another WTRU (e.g., the assisted WTRU or a GC), for instance, if the WTRU does not have a Uu reporting resources to report the measurement and / or if the WTRU is configured and / or triggered to report to another WTRU in addition to reporting to the network (e.g., as described herein and below).

[0315] Although the examples are presented for WTRUs in a generic manner, the example so far is more described as a version where the assisted WTRU is the WTRU determining the RS measurement and / orreporting delegation for itself and requesting the assistant WTRU. The advantage of this example being that the assisted WTRU knows better its situation (e.g., battery levels, energy saving, performance requirement) and may perform a request based on its needs, but it is less certain whether the assistant WTRUs may be available and / or capable of assisting it.

[0316] Also, or alternatively, a WTRU other than the assisted WTRU may perform the delegation decisions. One or more of the following may apply. In some examples, a WTRU (e.g., an assistant WTRU) may determine which RS measurement and / or reporting of another WTRU (e.g., an assisted WTRU) it will perform on behalf of the other WTRU, based on the inter-WTRU correlation between the WTRUs and / or RS configuration of the other WTRU (e.g., and / or the commonly configured RS configurations). For instance, the assistant WTRU may be the WTRU determining the inter-WTRU correlation between the WTRUs, and / or it may have received the information from another WTRU (e.g., the assisted WTRU and / or a GC) and / or the network. In such a scenario, the assistant WTRU knows what it may handle on behalf of another and its delegation capabilities, but may perform the decision instead of the WTRU that is more impacted. The assistant WTRU may perform similar configuration and determination steps as described herein and above, but using the other WTRU’s RS measurement and configuration (e.g., determining the RS of the other WTRU to be delegated). The WTRU may send a message to the assisted WTRU the RS that it may perform the RS measurement and reporting on its behalf, indicating the corresponding RS IDs, and delegation configuration (e.g., patterns), if any. For example, the assisted WTRU may confirm or reject the delegation in a response to a delegation request (e.g., via PSFCH NACK, SCI, MAC and / or RRC configuration). Upon rejection, the assistant WTRU may not proceed to perform the delegation. Upon reception of the delegation message, if accepted, the assisted WTRU may (re)configure itself to not measure and / or report the indicated RSs. The assistant WTRU may report and / or send a message to the network indicating the delegation of another WTRU (e.g., as discussed herein and above), and / or may indicate the RS configuration ID delegated and the corresponding WTRU ID.

[0317] In some examples, a WTRU (e.g., a GC) may determine, for a second WTRU (e.g., the assisted WTRU) which of its RS measurement and / or configuration may be delegated to a third WTRU (e.g., the assistant WTRU), based on the inter-WTRU correlation between the WTRUs in the aggregation group and their RS configuration (e.g., and / or the commonly configured RS configurations). For example, the WTRU (e.g., a GC), may perform the decision on behalf of the pair (e.g., or group) of WTRUs delegating the RS measurement and / or report for each other. In such an example, a more central coordinator that handles the aggregation features may coordinate the different WTRUs for the delegations (e.g., splitting the tasksamong a group and / or not pair-wise). In such an example, the WTRU may combine aspects from the certain techniques described herein (e.g., WTRU determining its delegation) with other techniques (e.g., WTRU determining the delegation of another), as the WTRU may determine for both assistant and / or assisted WTRU. The WTRU may perform the configuration and / or determination steps described herein (e.g., from the point of view of the GC centralizing the information), and / or using other WTRU’s RS measurement and / or configuration (e.g., determining the RS of the other WTRU to be delegated). The WTRU may then determine a pair (e.g., or group) of WTRUs, instead of simply another WTRU for the delegation. For example, the GC determines both the assistant and / or assisted WTRU for the assisted WTRU’s RS measurement and / or reporting configuration delegation. The WTRU then may send the delegation configuration to both the assistant and / or assisted WTRUs, including the RS to be delegated, the assistant WTRU IDs and / or assisted WTRU IDs. The communication may use either a groupcast for both WTRUs, and / or unicast to each separately. Similarly, as described herein, the WTRUs may confirm and / or decline the delegation in a response report. The WTRU may report a message to the network indicating the delegation and / or the RS configuration ID delegated and / or the corresponding assistant and / or assisted WTRU IDs.

[0318] In some examples, the network may determine, for a WTRU (e.g., the assisted WTRU) which of its RS measurement and / or configuration may be delegated to another WTRU (e.g., the assistant WTRU), based on the inter-WTRU correlation between the WTRUs and / or the RS configuration of the WTRUs. Also, or alternatively, WTRUs may send their information (e.g., correlation and / or indications needed to perform the determination similarly, as described herein and above) to the network, and the network may be the one determining the delegation for the WTRUs. The network has, for example, the advantage of being more capable of centralizing the information (e.g., correlation, RS configurations) used for the decisions, but at the cost of additional overheads between the WTRUs and / or the network. However, in certain examples, this may not be possible (e.g., when some information is not reported back to the network and only handled locally within the WTRUs). For example, the network may act similarly as the GC, including determining the pairs of WTRUs to delegate RS configuration from one to another, and / or sending the delegation indication and / or configuration to the corresponding WTRUs.

[0319] In some examples, the WTRUs may be configured (e.g., by the network and / or by a GC) with RS measurement and / or reporting that includes the WTRUs they may delegate the RS with. For example, the WTRU that is delegated may be determined based on having the same RS resource and / or measurement configuration with another WTRU. The WTRUs may not perform the WTRU and / or RS determination stepthemselves, and / or may apply the provided configuration. The WTRUs may use the delegation configuration and requirements (e.g., inter-WTRU correlation criterions for the RS) and reception and / or determination of inter-WTRU correlation information as triggers to (de)activate the RS measurement and / or reporting delegation.

[0320] Deactivation of RS delegation may be implemented. In some example, after the WTRUs are configured with RS measurement and reporting delegation, a given WTRU may be (re)configured to stop and / or pause the RS delegation based on several factors. To stop or pause the RS measurement and / or reporting delegation, for example, the WTRU may send a message and / or command to the other WTRUs of the delegation and the network to indicate that the delegation on a given RS is no longer active. Also, or alternatively, the WTRU may send a message and / or command to the other WTRUs of the delegation and / or the network indicating the corresponding RS and using, for instance, SCI, SL MAC-CE and / or PC5 RRC. The assisted WTRU may then resume its own measurement and reporting based on the original configuration.

[0321] In some examples, the configuration, determination and / or conditions described herein and above may be applicable for a WTRU to determine that a WTRU is not suitable (e.g., or no longer suitable) for RS delegation on a given RS (e.g., if the assistant WTRU may not be part of the WTRUs whose correlation is sufficient for the delegation). In that case, the WTRU may stop and / or pause the RS delegation of that WTRU on that RS.

[0322] In some examples, a WTRU may pause and / or stop the delegation based on the triggers described herein, such as the triggers that correspond to a potential change of WTRU(s) in the aggregation group or feature, change of RS configuration, and / or triggers that correspond to an issue in the link quality resulting on transmission corresponding to a delegated RS. For example, if a WTRU receives an RS (re)configuration changing the resources and / or configuration of a RS being delegated, the WTRU may pause and / or stop the delegation, waiting to confirm whether the other WTRU may be correlated on that RS or not. Also, or alternatively, a WTRU may pause and / or stop the delegation if a WTRU receives NACKs on UL transmissions based on the delegated RS and / or the DL transmissions using a delegated RS are not correctly received, and / or if a beam failure detection occurs on a delegated RS.

[0323] In some examples, a WTRU may receive (e.g., from the network and / or another WTRU) an explicit and / or implicit indication to pause and / or stop the delegation. As an example of an implicit indication, the WTRU may receive the deactivation of a semi-persistent RS measurement via MAC-CE and / or DCI.

[0324] In some examples, a WTRU may pause and / or stop the delegation in response to a trigger by a (re)configuration or determination of a new or updated inter-WTRU correlation, for instance, checking and / or determining that the assistant WTRU may be no longer satisfying the correlation requirements for the RS delegation on that RS.

[0325] In some examples, an assisted WTRU may (e.g., regularly) perform a measurement of a delegated RS, and / or compare that with the measurement performed by the assistant WTRU (e.g., to verify if the correlation holds and the delegation is valid). The verification may be performed by the WTRU, for instance, by having the assistant WTRU reporting the measurement to the assisted WTRU and / or by reporting the RS measurement to the network that may compare the measurements quantities of the assistant and / or assisted WTRUs. If the measurements are no longer similar, the WTRU may pause and / or stop the RS delegation. A WTRU that pauses and / or stops an RS delegation may trigger an inter-WTRU channel correlation (re)establishment procedure and / or a (re)determination of the RSs and / or WTRUs for delegation.

[0326] Triggering WTRU-to-WTRU reports for delegated RS measurements may be implemented. In some examples, an assistant WTRU may also report the measured RS quantity to another WTRU (e.g., as a complement to determining the correlation types of RS that have not been directly measured for correlation). The other WTRU may be the assisted WTRU and / or a GC. This report may indicate the measurement is done so that the WTRU may use this information (e.g., to trigger procedures conditioned by measurements as if the WTRU measured the RS itself). The assistant WTRU may report the delegated measurement to another WTRU, for instance, either as a configured regular report and / or based on specific triggers.

[0327] In some examples, the assistant WTRU may be configured to report to the assisted WTRU (e.g., and / or GC) regularly (e.g., every X ms and / or every N measurements). This configuration may be included in the configuration of the delegation shared by the WTRUs and / or in the request for RS monitoring delegation. This regular reporting may be used by the assistant WTRU to evaluate whether the assistant WTRU performs the measurements as expected or to (re)evaluate the correlation on the delegated RS. The WTRU may trigger a reevaluation of the correlation, a deactivation of the aggregation feature when the received delegated measurement is not satisfying.

[0328] In some examples, the assistant WTRU may be configured with triggers for when to report the delegated measurement to the assisted WTRU and / or GC. When the assistant WTRU performs the measurement on a delegated RS configured with reporting triggers, the WTRU, upon verification that themeasurement satisfies the configured trigger, may report the measurement to the other WTRU. After their measurements, the other WTRUs may report the CSI report to the WTRU, indicating the corresponding RS ID(s) and / or CSI report content. The reports may be grouped to include the CSI report for several RS(s) and / or RS set(s). These triggers may be designed to let the assistant WTRU have information on the channel when necessary, and / or, for example, be able to trigger procedures and / or decisions that need such measurements.

[0329] For example, an assisted WTRU (e.g., configured with conditional handover with thresholds on specific RS measurements) may send a trigger configuration to the assistant WTRU with similar threshold and metric on that RS, so that the assisted WTRU would be able to trigger the conditional handover without measuring the corresponding RS itself. For example, the assistant WTRU may be configured to report the measurement on a RS when the quality of the delegated RS goes below a given threshold (e.g., based on an RSRP, RSSI, and / or SINR threshold). For example, the WTRU may be configured to report the measurement on a RS, for instance, when the RS is used for PDCCH transmissions and / or the measurement quality is lower than a threshold that would enable the good reception of the PDCCH. For example, the WTRU may be configured to report the measurement and / or failure of measurements when detecting beam failure and / or link failures.

[0330] In some examples, the assisted WTRU, receiving the measurement report from the assistant WTRU, may use this delegated measurement in its own CSI report back to the network, and / or may indicate the network which measurements were delegated and which are self-measured (e.g. using a flag indication in the report).

Claims

CLAIMS:

1. A wireless transmit / receive unit (WTRU) comprising: a processor configured to: receive a configuration of channel correlation measurements from a network, the configuration associated with an aggregation group; detect a trigger to perform the channel correlation measurements; determine, based on the trigger, one or more WTRUs associated with the aggregation group and reference signals (RSs) to perform the channel correlation measurements; send a request to perform the channel correlation measurements to each WTRU of the one or more WTRUs associated with the aggregation group; receive a response from at least one WTRU of the one or more WTRUs associated with the aggregation group, wherein the response comprises the channel correlation measurements performed by the at least one WTRU; determine, based on the received response from the at least one WTRU, a channel correlation of the channel correlation measurements performed by the one or more WTRUs in the aggregation group; and send, based on the determined channel correlation of the channel correlation measurements performed by the one or more WTRUs in the aggregation group, a reporting message to the network or the at least one WTRU of the one or more WTRUs.

2. The WTRU of claim 1, wherein the configuration comprises a first configuration, wherein the trigger to perform the channel correlation measurements comprises at least one of: an indication of a second configuration associated with the aggregation group, an indication to perform the channel correlation measurements from the network, or an indication to activate a feature associated with the aggregation group.

3. The WTRU of claim 2, wherein the indication of a second configuration associated with the aggregation group comprises one or more of an addition of a new WTRU or a removal of one WTRU of the one or more WTRUs, and wherein the indication to perform the channel correlation measurements from the network is indicated via medium access control (MAC) or downlink control information (DCI).

4. The WTRU of claim 1, wherein the configuration comprises one or more reference signals (RSs) to use for the channel correlation measurements.

5. The WTRU of claim 4, wherein the reference signals comprise one or more of reference signal received power (RSRP) or received signal strength indicator (RSSI).

6. The WTRU of claim 1, wherein the configuration comprises an indication of channel correlation type(s) and an indication of channel correlation evaluation thresholds.

7. The WTRU of claim 6, wherein the channel correlation type(s) comprises small-scale channel correlation and large-scale correlation, wherein the small-scale channel correlation is based on correlation metrics of channel coefficient matrix and channel impulse response, and wherein the large-scale channel correlation is based on correlation metrics of one or more of RSRP, RSSI, signal-to-interference plus noise ratio (SINR), or line-of-sight (LoS).

8. The WTRU of claim 7, wherein the reporting message comprises the determined correlation results, wherein the determined correlation results comprises one or more of a WTRU ID, the RSs associated with the channel correlation measurements, the correlation types, or the correlation metrics associated with the respective correlation type.

9. The WTRU of claim 1, wherein the processor is further configured to: determine low power of one or more WTRUs associated with the aggregation group; determine which RS measurements to delegate to another WTRU, wherein the delegation is based on established inter-WTRU correlation and RS monitoring delegation requirements; and send an indication of the delegation to the network.

10. The WTRU of claim 1, wherein the processor is further configured to determine the channel correlation based on quasi co-location (QCL) and transmission configuration indicator (TCI).

11. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising:receiving a configuration of channel correlation measurements from a network, the configuration associated with an aggregation group; detecting a trigger to perform the channel correlation measurements; determining, based on the trigger, one or more WTRUs associated with the aggregation group and reference signals (RSs) to perform the channel correlation measurements; sending a request to perform the channel correlation measurements to each WTRU of the one or more WTRUs associated with the aggregation group; receiving a response from at least one WTRU of the one or more WTRUs associated with the aggregation group, wherein the response comprises the channel correlation measurements performed by the at least one WTRU; determining, based on the received response from the at least one WTRU, a channel correlation of the channel correlation measurements performed by the one or more WTRUs in the aggregation group; and sending, based on the determined channel correlation of the channel correlation measurements performed by the one or more WTRUs in the aggregation group, a reporting message to the network or the at least one WTRU of the one or more WTRUs.

12. The method of claim 11, wherein the configuration comprises a first configuration, wherein the trigger to perform the channel correlation measurements comprises at least one of: an indication of a second configuration associated with the aggregation group, an indication to perform the channel correlation measurements from the network, or an indication to activate a feature associated with the aggregation group.

13. The method of claim 12, wherein the indication of a second configuration associated with the aggregation group comprises one or more of an addition of a new WTRU or a removal of one WTRU of the one or more WTRUs, and wherein the indication to perform the channel correlation measurements from the network is indicated via medium access control (MAC) or downlink control information (DCI).

14. The method of claim 11, wherein the configuration comprises one or more reference signals (RSs) to use for the channel correlation measurements.

15. The method of claim 14, wherein the reference signals comprise one or more of reference signal received power (RSRP) or received signal strength indicator (RSSI).

16. The method of claim 11, wherein the configuration comprises an indication of channel correlation type(s) and an indication of channel correlation evaluation thresholds.

17. The method of claim 16, wherein the channel correlation type(s) comprises small-scale channel correlation and large-scale correlation, wherein the small-scale channel correlation is based on correlation metrics of channel coefficient matrix and channel impulse response, and wherein the large-scale channel correlation is based on correlation metrics of one or more of RSRP, RSSI, signal-to-interference plus noise ratio (SINR), or line-of-sight (LoS).

18. The method of claim 17, wherein the reporting message comprises the determined correlation results, wherein the determined correlation results comprises one or more of a WTRU ID, the RSs associated with the channel correlation measurements, the correlation types, or the correlation metrics associated with the respective correlation type.

19. The method of claim 11, wherein the method further comprises: determining low power of one or more WTRUs associated with the aggregation group; determining which RS measurements to delegate to another WTRU, wherein the delegation is based on established inter-WTRU correlation and RS monitoring delegation requirements; and sending an indication of the delegation to the network.

20. The method of claim 11, wherein the method further comprises determining the channel correlation based on quasi co-location (QCL) and transmission configuration indicator (TCI).

Images