Eliminating resources to avoid beam conflicts

Abstract

Devices and techniques for excluding resources to avoid beam collisions. An example device may receive information indicating a physical sidelink feedback channel (PSFCH) receive beam associated with a sidelink transport block (TB) and a reserved physical sidelink shared channel (PSSCH) resource associated with the PSFCH receive beam and a PSFCH occasion. The device may determine that a beam conflict exists between a PSFCH receive beam associated with the reserved PSSCH resource and a PSFCH receive beam associated with the sidelink TB. Based on the determination that the beam conflict exists, the device may determine that a candidate PSSCH resource in the sidelink resource pool is associated with the PSFCH occasion, and determine to exclude the candidate PSSCH resource from the set of PSSCH resources. The device may select a PSSCH resource from the set of PSSCH resources, and transmit a PSSCH transmission associated with the sidelink TB in the PSSCH resource.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 530,763, filed August 4, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] Mobile communication using wireless communication continues to evolve. The fifth generation can be called 5G. The previous generation (legacy) mobile communication can be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] This article provides equipment and techniques for eliminating resources to avoid beam collisions.

[0004] An example device (e.g., a Wireless Transmit / Receive Unit (WTRU)) can receive information indicating a first Physical Sidelink Feedback Channel (PSFCH) receive (RX) beam associated with a sidelink transport block (TB), and reserved Physical Sidelink Shared Channel (PSSCH) resources. The reserved PSSCH resources can be associated with a second PSFCH RX beam and a PSFCH timing. The device can determine that a beam conflict exists between the second PSFCH RX beam associated with the reserved PSSCH resources and the first PSFCH RX beam associated with the sidelink TB. Based on the determination of a beam conflict, the device can determine candidate PSSCH resources in the sidelink resource pool associated with PSFCH timing and determine a set of PSSCH resources in the sidelink resource pool. Candidate PSSCH resources can be excluded from the PSSCH resource set. The device can select PSSCH resources from the PSSCH resource set. The device can transmit PSSCH transmissions associated with the sidelink TB in the PSSCH resource.

[0005] The device can determine a beam conflict between a second PSFCH RX beam associated with a reserved PSSCH resource and a first PSFCH RX beam associated with a sidelink TB by determining a difference between a first sidelink (SL) Transmission Configuration Indicator (TCI) state and a second SL TCI state. The first sidelink (SL) Transmission Configuration Indicator (TCI) state is associated with the first PSFCH RX beam associated with the sidelink TB, and the second SL TCI state is associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

[0006] The device can determine a beam conflict between a second PSFCH RX beam associated with a reserved PSSCH resource and a first PSFCH RX beam associated with a sidelink TB by determining a difference between a first beam index and a second beam index, wherein the first beam index is associated with the first PSFCH RX beam associated with the sidelink TB and the second beam index is associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

[0007] The device can determine a beam conflict between a second PSFCH RX beam associated with a reserved PSSCH resource and a first PSFCH RX beam associated with a sidelink TB by determining that a first destination WTRU identifier is different from a second destination WTRU identifier. The first destination WTRU identifier is associated with the first PSFCH RX beam associated with the sidelink TB, and the second destination WTRU identifier is associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

[0008] The device can determine that there is a beam conflict between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the sidelink TB by determining that the correlation between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the sidelink TB is below a threshold.

[0009] This information can further indicate the second PSFCH RX beam associated with the reserved PSSCH resource. The device can determine that there is a beam conflict between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the sidelink TB by determining that a first indication type (e.g., in the information) used to indicate the first PSFCH RX beam associated with the sidelink TB is different from a second indication type (e.g., in the information) used to indicate the second PSFCH RX beam associated with the reserved PSSCH resource.

[0010] The device can determine that there is a beam conflict between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the side link TB by determining that the signal reception via the second PSFCH RX beam associated with the reserved PSSCH resource is below a quality threshold.

[0011] This information can be the first piece of information. The device can receive second information indicating a set of sidelink resource pools. The first information can further indicate a sidelink resource pool from the set of sidelink resource pools that has determined a PSSCH resource set therefrom.

[0012] An example device can receive indications of: a resource pool, a Hybrid Automatic Repeat Request (HARQ) processing cycle, a resource selection window, a Physical Sidelink Feedback Channel (PSFCH) receive (RX) beam associated with a sidelink transport block (TB), reserved Physical Sidelink Shared Channel (PSSCH) resources, and reserved PSFCH RX beams. The device can determine a candidate PSSCH resource set based on the resource selection window. The device can identify beam conflicts between the PSFCH RX beams associated with the sidelink TB and the reserved PSFCH RX beams. The device can determine the PSFCH timing associated with the reserved PSSCH resources based on the resource pool and the reserved PSSCH resources. The device can determine candidate PSSCH resources associated with PSFCH timings from the candidate PSSCH resource set based on the HARQ processing cycle, the PSFCH timings being associated with the reserved PSSCH resources. The device can exclude candidate PSSCH resources from the candidate PSSCH resource set to generate a reduced candidate PSSCH resource set. The device can select PSSCH resources from a reduced set of candidate PSSCH resources. The device can then transmit PSSCH transmissions associated with the sidelink TB within those PSSCH resources.

[0013] The PSFCH RX beam can be derived based on the destination WTRU ID of the sidelink TB. Identifying beam conflicts between the PSFCH RX beam associated with the sidelink TB and the reserved PSFCH RX beam may involve determining the difference between a first SL TCI state and a second SL TCI state, the first SL TCI state associated with the PSFCH RX beam associated with the sidelink TB and the second SL TCI state associated with the reserved PSFCH RX beam.

[0014] Identifying beam conflicts between the PSFCH RX beam associated with the sidelink TB and the reserved PSFCH RX beam may involve determining the difference between a first beam index and a second beam index, the first beam index being associated with the PSFCH RX beam associated with the sidelink TB and the second beam index being associated with the reserved PSFCH RX beam. Attached Figure Description

[0015] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented.

[0016] Figure 1B The illustration shows a method according to one embodiment. Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0017] Figure 1C The illustration shows a method according to one embodiment. Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used in the communication system.

[0018] Figure 1D The illustration shows a method according to one embodiment. Figure 1A The illustrated system diagram shows yet another example RAN and yet another example CN used in the communication system.

[0019] Figure 2 The illustration shows an example of beam collision.

[0020] Figure 3 The illustration shows an example of WTRU excluding Physical Side Link Shared Channel (PSSCH) resources to avoid Physical Side Link Feedback Channel (PSFCH) receive (RX) beam collisions.

[0021] Figure 4 The diagram illustrates the timing of PSFCH repeating within a single time slot.

[0022] Figure 5 An example of the rotation of the PSFCH is illustrated.

[0023] Figure 6 The illustration shows an example selection / indication of PSFCH timing based on the corresponding RX beam.

[0024] Figure 7 The illustration shows examples of multiple PSFCH timings used for PSFCH backup.

[0025] Figure 8 An example of a PSFCH repeat instruction is illustrated.

[0026] Figure 9 The illustration shows an example of using sensing information during resource selection. Detailed Implementation

[0027] Figure 1AThis is a schematic diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messages, and broadcasts to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 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 Spectrum OFDM (ZT UWDTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0028] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0029] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), node Bs, eNode Bs, home node Bs, home eNode Bs, gNBs, NR node Bs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0030] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0031] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0032] More specifically, as described above, the communication system 100 can be a multi-access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0033] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0034] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using a new radio (NR).

[0035] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0036] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0037] For example, Figure 1A Base station 114b can be a wireless router, home node B, home eNodeB, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b may not need to access the Internet 110 via CN 106 / 115.

[0038] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1AAlthough not shown, it should be understood that RAN104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to connecting to RAN 104 / 113, which may utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0039] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0041] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, among other things, WTRU 102 may include, in particular, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

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

[0043] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 can be, for example, a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

[0045] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, for example, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs, such as, for example, NR and IEEE 802.11.

[0046] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data therefrom. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 can access and store information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. 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. Removable memory 132 may include a user identification module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access and store information from memory that is not physically located on WTRU 102 (e.g., a server or home computer (not shown)).

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

[0048] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information on the air interface 116 from base stations (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0049] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, and / or humidity sensors.

[0050] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for 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 to reduce and / or substantially eliminate self-interference via hardware (e.g., chokes) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0051] Figure 1C This diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0052] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c on air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

[0053] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other on the X2 interface.

[0054] Figure 1C The CN 106 shown 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 is described as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0055] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0056] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0057] SGW 164 can connect to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks such as Internet 110, so as to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0058] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108, facilitating communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0059] Despite WTRU in Figure 1A-1D While described as a wireless terminal, it is conceivable that, in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

[0060] In a representative embodiment, another network 112 may be a WLAN.

[0061] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can access or interface with a distributed system (DS) or another type of wired / wireless network that transmits traffic to and / or out of the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for an external BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be transmitted via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be transmitted between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to here as the "ad-hoc" communication mode.

[0062] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide bandwidth of 20 MHz) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0063] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0064] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0065] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (TVWS) spectrum, while 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 can support metering-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0066] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA among all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, 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 Sense and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the available band remains idle and can be available.

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

[0068] Figure 1D This diagram illustrates a system diagram of RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0069] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c on air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0070] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a variable number of OFDM symbols and / or a continuously variable absolute time).

[0071] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0072] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing user plane data to User Plane Functions (UPF) 184a and 184b, and routing control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other on the Xn interface.

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

[0074] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency Time (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and / or so on. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies such as WiFi.

[0075] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure the routing of services through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0076] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. This N3 interface provides WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can 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, and providing mobility anchoring.

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

[0078] Given Figure 1A-1D as well as Figure 1A-1D The corresponding descriptions herein indicate that one or more of the following functions can be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF183a-b, DN 185a-b, and / or any other device(s) described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0079] Simulation devices can be designed to perform tests on one or more other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform 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 to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing purposes and / or can perform tests using over-the-air wireless communication.

[0080] One or more simulation devices may perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used to test test scenarios in laboratory and / or non-deployment (e.g., testing) wired and / or wireless communication networks to implement the testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0081] A wireless transmit / receive unit (WTRU) can be connected to multiple other WTRUs. These other WTRUs (one or more) can be located in a different direction from the WTRU. If beamforming is enabled using HARQ feedback, different transmissions can be mapped to concurrent resources (e.g., resources transmitted at the same time). A WTRU may not be able to receive multiple different beams simultaneously. In this case, the WTRU may experience receive (RX) beam collision. Figure 2 The illustration shows an example of beam collision.

[0082] Vehicle communication can involve communication between WTRUs (e.g., direct communication). For V2X operation, there may be one or more (e.g., two) scenarios. For example, an in-coverage scenario may involve the WTRU receiving assistance from the network to begin transmitting and receiving V2X messages. An out-of-coverage scenario may involve the WTRU using one or more pre-configured parameters to begin transmitting and receiving V2X messages.

[0083] V2X communication can be supported (e.g., in Rel-14 LTE). V2X communication can be based on device-to-device (D2D) communication. V2X communication services can include one or more (e.g., four) different types. For example, V2X communication services can include one or more of the following: vehicle-to-vehicle (V2V), where vehicle WTRUs can communicate with each other (e.g., direct communication); vehicle-to-infrastructure (V2I), where vehicle WTRUs can communicate with roadside units (RSUs) and / or eNBs; vehicle-to-network (V2N), where vehicle WTRUs can communicate with the core network; and / or vehicle-to-pedestrian (V2P), where vehicle WTRUs can communicate with WTRUs under special conditions (e.g., low battery capacity).

[0084] This article provides one or more features associated with NR SL channels and resource pools.

[0085] The Physical Side Link Control Channel (PSCCH) can indicate resources and / or other transmission parameters (e.g., it can be used by the WTRU for PSSCH). PSCCH transmissions can be associated with the Demodulation Reference Signal (DM-RS).

[0086] The Physical Side Link Shared Channel (PSSCH) can transmit TB of data. The PSSCH can transmit control information for HARQ procedures, CSI feedback triggering, and / or other purposes. One or more (e.g., at least six) OFDM symbols within a time slot can be used for PSSCH transmission. PSSCH transmission can be associated with DM-RS and / or PT-RS.

[0087] The Physical Sidelink Feedback Channel (PSFCH) can carry HARQ feedback (e.g., from the WTRU that is the intended receiver of the PSSCH transmission to the WTRU that performs the transmission via the sidelink). The PSFCH sequence can be transmitted in one or more (e.g., two) OFDM symbols in a PRB (e.g., near the end of the sidelink resource in the time slot).

[0088] PSCCH and PSSCH resources can be defined within the resource pool for the corresponding channel. PSCCH / PSSCH may not be transmitted in one or more (e.g., all) RBs and time slots within the NR system bandwidth (e.g., and therefore not expected to be received). PSCCH / PSSCH may not be transmitted within the frequency span configured for the V2X sidelink. The resource pool can imply (e.g., in resource allocation mode 2) that the WTRU will make its resource selection based on sensing within the resource pool.

[0089] Resource pools can be (pre-)configured to WTRUs (e.g., separate from the transmit angle (TX pool) and receive angle (RX pool)). WTRUs can monitor PSCCH (e.g., and receive PSSCH transmissions) in resource pools other than those in which the WTRU transmits (e.g., enabling the WTRU to attempt to receive transmissions made by other WTRUs in those RX pools).

[0090] This article provides one or more features associated with the allocation of New Radio (NR) SL resources.

[0091] In some examples (e.g., 3GPP Release 17 and above), for NR, one or more (e.g., two SL resource allocation modes (e.g., Mode 1 and Mode 2)) can be supported. In Mode 1, SL resource allocation can be provided by the network. In Mode 2, the WTRU can determine the SL transport resources in one or more resource pools.

[0092] In Mode 1, the scheduled resource allocation can be characterized by one or more of the following: the WTRU is in RRC_CONNECTED to transmit data; the NG-RAN schedules transmission resources; the NG-RAN can dynamically allocate resources to the WTRU for NR SL communication via SL-RNTI on (one or more) PDCCHs; the NG-RAN can allocate SL resources to the WTRU with one or more (e.g., two) types of SL grants (e.g., type 1, where the RRC directly provides SL grants for NR sidelink communication only, and type 2, where the RRC defines the periodicity of the SL grants, and the PDCCH can signal and activate or deactivate the SL grants, and the PDCCH is addressed to SL-CS-RNTI for NR SL communication); the NG-RAN can semi-persistently allocate sidelink resources to the WTRU for V2X sidelink communication via SL semi-persistent scheduling V-RNTI on (one or more) PDCCHs; and / or the WTRU can send a Sidelink Buffer Status Report (SL-BSR) to support scheduler operations in the NG-RAN.

[0093] For NR sidelink communication, SL-BSR can refer to data buffered for a Logical Channel Group (LCG) (e.g., each destination in a WTRU). One or more (e.g., eight) LCGs can be used to report sidelink buffer status. One or more (e.g., two) formats (e.g., SL-BSR and truncated SL-BSR) can be used. The SL-BSR and truncated SL-BSR MAC control element (MAC CE) can include (e.g., one) a destination index field, (e.g., one) an LCG ID field, and / or (e.g., one) a corresponding buffer size field (e.g., for each reported target group).

[0094] In Mode 2, the WTRU can perform autonomous resource selection. In Mode 2, the WTRU can transmit data if it is within NG-RAN coverage (e.g., regardless of its RRC status) and if it is outside NG-RAN coverage. The WTRU can autonomously select one or more SL resources from one or more resource pools (e.g., provided by broadcast system information or dedicated signaling when within NG-RAN coverage, or by (pre)configuration when outside NG-RAN coverage).

[0095] A Service Context (SCI) transmitted by a WTRU on the PSCCH (e.g., a Level 1 SCI) can indicate the time-frequency resources on which the WTRU will transmit the PSCCH. The Level 1 SCI can be used by the sensing WTRU to maintain a record of which resources have been reserved by other WTRUs (e.g., in the recent past). If a resource selection is triggered (e.g., by traffic arrival or reselection), the WTRU can consider a sensing window. The sensing window can start at a (pre)configured time (e.g., in the past) and end before the trigger time (e.g., shortly before).

[0096] The sensing WTRU can select resources for its (one or more) (re)transmissions from a resource selection window. This window can begin after (re)selecting resources is triggered (e.g., shortly thereafter). This window may not be longer than the remaining latency budget for the packets expected to be transmitted. The sensing WTRU can exclude reserved resources in the selection window that have an SL-RSRP higher than a threshold from the candidates. This threshold can be set based on the priority of traffic from the sensing and transmitting WTRUs. Higher-priority transmissions from the sensing WTRU may occupy resources reserved by the transmitting WTRU with sufficiently low SL-RSRP and sufficiently low-priority traffic.

[0097] If a resource has been identified by a previous SCI (e.g., in the case of periodic transmissions), configured authorization, or reserved HARQ retransmission, the selected resource can be declared. If a resource has not yet been identified by an SCI (e.g., only the WTRU that selected the resource knows about the selection, e.g., internally), the selected resource may not be declared (e.g., not yet).

[0098] If the MAC entity is configured with SL resource allocation mode 2 for transmission on a resource pool, the physical (PHY) layer can re-evaluate the selected sidelink grant(s) for transmitting the MAC PDU from the multiplexing and assembly entity (e.g., T3 before the time slot of the first signaled SCI indicating the resource(s) ...

[0099] For re-evaluation and preemption checks, the MAC layer can instruct the PHY layer to check (one or more) whether the selected PSSCH resources are still in the set of available candidate resources for transmission (e.g., based on sensing). If any resource is no longer available (e.g., based on sensing results), the PHY can report that resource for re-evaluation or preemption. The MAC layer can replace the unavailable resource with a resource (e.g., a newly selected resource) from a subset of available candidate resources (e.g., provided by the PHY layer).

[0100] If a new transmission is performed, Logical Channel Priority Ordering (LCP) of the SL can be applied. RRC can be used to control the scheduling of uplink data (e.g., by signaling each logical channel per MAC entity with an LC-specific parameter such as the SL priority, where an increment in the SL priority indicates a lower priority level). LCP can involve (e.g., among other eligibility criteria) selecting the LC with the highest priority. The MAC entity can allocate resources to the selected LC (e.g., in descending order of priority).

[0101] This paper provides one or more features associated with the SL feedback mechanism.

[0102] NR-V2X can support HARQ based on ACK / NACK (or DTX) transmissions for SL unicast and multicast services, and / or NACK-only HARQ schemes specific to multicast services. NR-V2X can support blind retransmission schemes.

[0103] If ACK / NACK (or DTX) operations are used, the SL HARQ scheme can be similar to the Uu scheme with non-block group feedback (e.g., HARQ feedback is transmitted based on the success or failure of the entire transport block).

[0104] The SL HARQ feedback bit (e.g., a single bit) can be carried from the Rx WTRU to the associated Tx WTRU on the PSFCH. If the Tx WTRU is under the control of the gNB in ​​resource allocation mode 1, the Tx WTRU can (e.g., via PUCCH or PUSCH) notify the gNB of the status of the SL HARQ feedback that the TX WTRU has calculated (e.g., SL HARQ feedback related to specific dynamic or configured authorizations to assist in retransmission scheduling and sidelink resource allocation).

[0105] The WTRU can receive instructions to schedule PSSCH reception (e.g., via SCI format) to transmit a PSFCH with HARQ-ACK information (e.g., in response to PSSCH reception). The WTRU can provide HARQ-ACK information. HARQ-ACK information may include ACK and / or NACK (e.g., in some cases only NACK).

[0106] The WTRU can receive (e.g., via sl-PSFCH-period) the number of time slots in the resource pool for the period of PSFCH transmission timing resources. If this number is zero, PSFCH transmissions from the WTRU in the resource pool may be disabled.

[0107] If the WTRU receives a PSSCH in the resource pool and the HARQ feedback enable / disable indicator field in the associated SCI format 2-A / 2-B / 2-C has a value of 1, the WTRU can provide HARQ-ACK information in the PSFCH transmission in the resource pool. The WTRU can transmit the PSFCH in a first time slot, which includes the PSFCH resources and is at least one of the multiple time slots in the resource pool following the last time slot of PSSCH reception (e.g., provided by sl-MinTimeGapPSFCH).

[0108] For PSFCH transmissions with HARQ-ACK information, WTRU can determine the cyclic shift value (e.g., depending on the SCI format and / or based on the cyclic shift pair index corresponding to the PSFCH resource index).

[0109] One or more (e.g., multiple) PSFCH receptions can occur at the same time (e.g., whether the PSFCH uses different cyclic shifts or is transmitted on different sub-channels).

[0110] This document provides a sample description of the SL-PSFCH-Config fields. `sl-MinTimeGapPSFCH` indicates the minimum time gap between the PSFCH and its associated PSSCH, in time slots. `sl-NumMuxCS-Pair` indicates the number of cyclic shift pairs that can be multiplexed in the PRB for PSFCH transmission. `sl-PSFCH-CandidateResourceType` indicates the number of PSFCH resources available for multiplexing HARQ-ACK information in PSFCH transmission. `sl-PSFCH-HopID` indicates the scrambling ID for the sequence transitions of the PSFCH used in the resource pool. `sl-PSFCH-Period` indicates the period of the PSFCH resources in this resource pool, in time slots. If set to... sl0 If no PSFCH resource is specified, then no resources are available for PSFCH, and HARQ feedback for all transmissions in the resource pool is disabled. `sl-PSFCH-RB-Set` indicates the set of PRBs used for PSFCH transmission and reception. The leftmost bit of the bitmap can indicate the lowest RB index in the resource pool, etc. A value of 0 in the bitmap indicates that the corresponding PRB is not used for PSFCH transmission and reception. A value of 1 indicates that the corresponding PRB is used for PSFCH transmission and reception.

[0111] A WTRU can be connected to multiple other WTRUs in different directions. If beamforming is used to perform SL transmit and receive (e.g., SL on FR2), beam collisions can occur if the WTRU intends to use different beams for transmit or receive, and can only use a single beam at a time. This can happen if the WTRU is scheduled to have multiple PSCCH / PSSCH transmissions multiplexed in the frequency domain at the same time. Beam collisions can also occur if HARQ feedback is enabled and different transmissions are mapped to concurrent PSFCH resources (e.g., not the same resource, but at the same time).

[0112] WTRU can perform beam-aware SL resource allocation to avoid beam collisions (e.g., for modes 1 and 2, and for PSFCH reception and PSSCH transmission).

[0113] Beam collisions may occur if the WTRU performs Mode 2 sensing to obtain SL sensing information for resource selection. In SL FR2 operation, to improve link performance, the WTRU can apply a directional sensing RX beam to the PSCCH receiver to achieve beamforming gain. The sensing results may differ for different RX beams. The sensing results can be used to determine available resources for transmission (e.g., it can also apply a directional TX beam).

[0114] Mode 2 resource selection (e.g., based on directional sensing) can be enabled for directional transmission.

[0115] In SL, both the transmitter and receiver are WTRUs (e.g., SL TX WTRU and SL RX WTRU, respectively). A WTRU that transmits SL TB via PSSCH can be referred to as an SL TX WTRU. A WTRU that receives SL TB via PSSCH can be referred to as an SL RX WTRU. If HARQ feedback is enabled, the SL RX WTRU can be a WTRU that transmits HARQ feedback (e.g., using PSFCH). The SL TX WTRU can be a WTRU that receives PSFCH.

[0116] The SL transmit beam (e.g., referred to herein as the TX beam) may represent one or more of the following: WTRU SLTX configuration; WTRU SL TX spatial configuration; WTRU SL TX spatial filter; a set of antenna element weights applied to one or more antenna panels for WTRU SL transmission; WTRU transmission in the control direction (e.g., a unique control direction characterized by beamwidth, beam gain, beam center, and beam peak lobe, which may be determined, for example, by the WTRU SL TX configuration, WTRU SLTX spatial configuration, WTRU SL TX spatial filter, and / or a set of antenna element weights applied to one or more antenna panels for WTRU SL transmission); and a radiation pattern emitted from the antenna port (e.g., using the WTRU SL TX configuration, WTRU SL TX spatial configuration, WTRU SL TX spatial filter, and / or a set of antenna element weights applied to one or more antenna panels for WTRU SL transmission).

[0117] WTRU can apply a TX beam (e.g., a TX beam) for SL transmission in a given SL time slot.

[0118] This document provides one or more features associated with TX beam indication. The TX beam may be indicated by one or more of the following: a (pre)configured digital index; and / or a digital index of the SL reference signal transmission (e.g., SL SSB, SL CSI-RS, PSCCH DMRS, PSSCH DMRS, or SL TRS transmitted using the TX beam).

[0119] This article provides one or more features associated with the RX beam.

[0120] The SL receive beam (e.g., referred to herein as the RX beam) may represent one or more of the following: WTRU SLRX configuration; WTRU SL RX spatial configuration; WTRU SL RX spatial filter; a set of antenna element weights applied to one or more antenna panels for WTRU SL reception; and / or WTRU reception in the control direction (e.g., a unique control direction characterized by beamwidth, beam gain, beam center, and beam peak lobe, which is determined by the WTRU SL RX configuration, WTRU SL RX spatial configuration, WTRU SL RX spatial filter, and / or a set of antenna element weights applied to one or more antenna panels for WTRU SL reception).

[0121] WTRU can apply an RX beam (e.g., one RX beam) for SL transmission in a given SL time slot.

[0122] This document provides one or more features associated with RX beam indication. The RX beam can be indicated by one or more of the following: a (pre-)configured digital index; a digital index for SL reference signal reception (e.g., SL SSB, SL CSI-RS, PSCCH DMRS, PSSCH DMRS, or SL TRS transmitted using the RX beam); and / or a corresponding TX beam indication. If the WTRU supports beam correspondence, the corresponding TX beam indication can be used for RX beam indication.

[0123] WTRU may (e.g., need to) rely on (e.g., a single) beam for transmission or reception at a time. Features(s) associated with avoiding situations where a user will use (e.g., require) multiple beams at once. Some of the features(s) described herein may be proactive (e.g., predicting problems and preparing resource choices to avoid such situations, or reactive, and / or handling situations to avoid collisions if they are detected).

[0124] The features described herein may be associated with, but are not limited to, NR SLs that utilize beamforming (e.g., in the FR2 band) as provided herein.

[0125] A WTRU can use beamforming transmission for SL. A WTRU can be (pre-)configured with TX beams (e.g., PSCCH, PSSCH, PSFCH) for transmissions to a destination WTRU (e.g., each intended destination WTRU). A WTRU can be (pre-)configured with RX beams to be applied to receptions (e.g., PSCCH, PSSCH, PSFCH) from these WTRUs. A WTRU can have a (configured) mapping between its WTRU ID and the corresponding beams to be applied. This mapping can be (e.g., if needed) shared between the WTRU's MAC and PHY layers (e.g., allowing different procedures to determine, for example, one or more beams for a given transmission or reception to / from a given WTRU based on the WTRU-to-beam mapping).

[0126] The (pre)configuration of the beam can be based on an RRC configuration (e.g., a (default) TX or RX beam for a given BWP, RP, or unicast connection), which is indicated by receiving a MAC CE command and / or dynamically indicated for the selected transmission (e.g., using DCI or SCI).

[0127] Beams can be (pre)configured for a given WTRU ID (e.g., for all transmits and receives with that WTRU). Beams can be (pre)configured using WTRU-to-beam mapping. Beams can be (pre)configured individually for each WTRU's receive and transmit (e.g., without assuming channel reciprocity). Beams can be (pre)configured separately for different channels and / or different WTRUs (e.g., PSCCH, PSSCH, PSFCH).

[0128] The determination of the beam used for transmission or reception can be based on WTRU measurements of SL-RS (e.g., SL-SSB, SL-CSI-RS, PSSCH DMRS, PSCCH DMRS) and / or measurements of SL-RS reported by WTRU.

[0129] This document provides one or more features associated with the PSFCH in NR SL (e.g., focusing on cases where the PSFCH is used to report HARQ feedback). The features described herein can be applied to the PSFCH for any other purpose (e.g., if the PSFCH is used for SL beam management or SL CSI reporting). A usage-based mapping (e.g., a (pre-)configured SL (CSI-)RS to PSFCH mapping report based on resource pools or WTRUs) can be used to determine the association of PSFCH resources.

[0130] Beam collisions can occur between two transmissions. The features(s) described herein related to beam collisions between two transmissions can be applied to examine collisions in more than two transmissions (e.g., by copying or grouping different transmissions).

[0131] This article provides one or more features associated with Mode 2 Rx beam collision avoidance.

[0132] The NR SL WTRU can be (pre-)configured to perform transmissions using beamforming signals (e.g., on an FR2 carrier). The resource pool can be (pre-configured) to enable HARQ feedback. The resource pool can be (pre-configured) with HARQ feedback parameters (e.g., including the RRC field SL-PSFCH-Config for parameters used to map PSSCH transmissions to PSFCH resources).

[0133] WTRU can be (pre-)configured to use mode 2 resource selection (e.g., configured by the network or when WTRU is outside coverage).

[0134] WTRU can be triggered to select resources for PSSCH transport (e.g., if HARQ feedback is enabled for SL TB). Resource selection can be indicated on resource pools configured to support HARQ feedback.

[0135] If the MAC entity has been (pre-)configured with SL resource allocation mode 2 to transmit using one or more resource pools in the carrier, the PHY layer can receive an indication with resource selection specifications (e.g., requirements). Resource selection specifications may include: the amount of resources selected (e.g., the number of sub-channels), the number of selected HARQ retransmissions, the priority of the SL data, and the remaining PDB and / or so on.

[0136] In SL resource selection (e.g., Mode 2 resource selection), beam information may not be considered during resource selection. Other scheduled transmissions (and beams) (e.g., independent resource allocation) may also be disregarded during resource selection. Resource selection that is blind to beams and other transmit / receive signals can lead to beam collisions.

[0137] SL resource selection (e.g., mode 2 resource selection) can be used (e.g., to avoid beam collisions).

[0138] SL resource selection can be based on scheduled resources (e.g., previously scheduled resources) and / or beamforming considerations. PSSCH resources that would conflict with PSFCH RX beamforming can be excluded (e.g., based on feedback configuration and / or SL-UE beamforming). One or more of the following can be performed.

[0139] The WTRU can be (pre)configured with PSFCH timings during resource pooling and / or HARQ processing cycles. The WTRU can receive (e.g., via a higher layer) indications of one or more of the following parameters for resource selection (e.g., for PSSCH transmissions of HARQ-enabled SL transport blocks (TBs): resource pool; destination WTRU ID of the SL TB; PSFCH RX beam associated with the SL TB; reserved PSSCH resources and / or associated PSFCH RX beams; and / or resource selection window.

[0140] WTRU can determine a candidate set of PSSCH resources (e.g., based on the indicated resource selection window).

[0141] The WTRU can determine that there is a beam conflict between the PSFCH RX beam associated with a reserved PSSCH resource and the PSFCH RX beam associated with a sidelink TB. The WTRU can determine that the transmitted PSFCH RX beam(s) is misaligned with the reserved transmitted PSFCH RX beam(s) (e.g., based on different SL TCI states, beam indices, etc.).

[0142] WTRU can determine the PSFCH timing corresponding to the indicated reserved PSSCH resources (e.g., based on the indicated resource pool and / or the (pre)configuration of the indicated reserved PSSCH resources).

[0143] Based on the identified beam conflict, the WTRU can determine (e.g., corresponding to) one or more candidate PSSCH resources (e.g., all candidate PSSCH resources) associated with (e.g., corresponding to) the determined PSSCH timing of the reserved transmission (e.g., based on the PSSCH timing (pre)configuration and / or HARQ processing time period of the indicated resource pool).

[0144] The WTRU can exclude one or more identified candidate PSSCH resources from the candidate PSSCH resource set. The WTRU can select PSSCH resources from the identified candidate resource set (e.g., perform resource selection within / based on the identified candidate resource set). The WTRU can transmit HARQ-enabled SL TB PSSCH transports from the selected resources.

[0145] In SL resource reassessment (e.g., Mode 2), beam information may not be considered during resource selection. Other scheduled transmissions (and beams) (e.g., independent resource allocations) may also be disregarded during resource selection.

[0146] The RX beam can be changed between scheduling and transmission (e.g., configuration authorization). Resource reassessment can be performed without considering beam aspects and / or other transmissions.

[0147] One or more resources can be excluded to avoid beam collisions.

[0148] In SL resource selection (e.g., Mode 2 resource selection), beam information may not be considered during resource selection. Other scheduled transmissions (and beams) (e.g., independent resource allocation) may also be disregarded during resource selection. Resource selection that is blind to beams and other transmit / receive signals can lead to beam collisions.

[0149] SL resource selection (e.g., mode 2 resource selection) can be used (e.g., to avoid beam collisions).

[0150] SL resource selection can be based on scheduled resources (e.g., previously scheduled resources) and / or beamforming considerations. PSSCH resources that would conflict with PSFCH RX beamforming can be excluded (e.g., based on feedback configuration and / or SL-UE beamforming). One or more of the following can be performed.

[0151] The WTRU can be (pre-)configured with PSFCH timings during resource pooling and / or HARQ processing cycles. The WTRU can (e.g., via a higher layer) receive indications of one or more of the following parameters for resource selection (e.g., for PSSCH transmissions of HARQ-enabled SL transport blocks (TBs): (sidelink) resource pool; destination WTRU ID of the SL TB; PSFCH RX beam associated with the SL TB; reserved PSSCH resources and / or associated PSFCH RX beams; and / or resource selection window.

[0152] WTRU can determine a candidate set of PSSCH resources (e.g., based on the indicated resource selection window).

[0153] WTRU can determine that the transmitted PSFCH RX beam(s) are misaligned with the reserved transmitted PSFCH RX beam(s) (e.g., based on different SL TCI states, beam indices, etc.).

[0154] WTRU can determine the PSFCH timing corresponding to the indicated reserved PSSCH resources (e.g., based on the indicated resource pool and / or the (pre)configuration of the indicated reserved PSSCH resources).

[0155] WTRU can identify one or more candidate PSSCH resources (e.g., all candidate PSSCH resources) corresponding to the identified reserved transmission PSSCH timing (e.g., based on the PSSCH timing (pre)configuration and / or HARQ processing time period of the indicated resource pool).

[0156] The WTRU can exclude determined PSSCH resources from the candidate resource set. The WTRU can perform resource selection from the determined candidate resource set (e.g., based on the determined candidate resource set). The WTRU can transmit HARQ-enabled SL TB PSSCH transports from the selected resources.

[0157] The SL TX WTRU can incorporate beam conflict considerations during the resource allocation phase. If the WTRU is selecting resources for transmission, it can exclude resources that would cause PSFCH RX beam conflicts. The WTRU can perform resource selection while considering already scheduled transmissions and PSFCH RX beams.

[0158] If the MAC entity is (pre-)configured with SL resource allocation mode 2 to use one or more resource pools in the carrier and transmit using beamforming transmission, the PHY layer can receive indications for one or more of the following: the destination WTRU ID of the SL TB and / or the associated PSFCH RX beam, and / or the reserved PSSCH resources (e.g., already reserved PSSCH resources) and the associated PSFCH RX beam.

[0159] The PSFCH RX beam can be derived from the destination WTRU ID of the SL TB (e.g., based on the RX beam configured for the SL unicast link between the WTRU and the destination WTRU).

[0160] The WTRU can determine a resource selection window (e.g., based on the indicated remaining PDB). The WTRU can determine an initial set of candidate PSSCH resources (e.g., by excluding resources it has already selected). The WTRU can exclude resources deemed unavailable (e.g., based on sensing measurements, such as resources indicated by a received SCI with an RSRP above a given threshold).

[0161] WTRU can identify potential PSFCH RX beam conflicts.

[0162] WTRU can assess potential RX beam conflicts for PSFCH reception (e.g., by comparing the PSFCH RX beam configured for a scheduled SLTB with the PSFCH RX beam indicated for an already selected PSSCH resource).

[0163] If the RX beam indices used for the reserved and scheduled transmissions are different, the WTRU can identify potential RX beam conflicts. If the TCI states of the RX beams used for the reserved and scheduled transmissions are different (e.g., different TCI indices or using different RSs), the WTRU can also identify potential RX beam conflicts.

[0164] If the RX beam is using TX-RX beam mapping and the TX beam indices used for the reserved and scheduled transmissions are different, the WTRU can identify a potential RX beam conflict. A potential RX beam conflict can also be identified if different indication methods are used to indicate differences in the RX beams between the reserved and scheduled transmissions (e.g., beam index and TCI status). For example, if a first indication type is used to indicate the PSFCH RX beam associated with a reserved PSSCH resource, and a second indication type, different from the first, is used to indicate the PSFCH RX beam associated with a sidelink TB, the WTRU can identify a potential RX beam conflict.

[0165] If the WTRU destination IDs of the reserved and scheduled transmissions are different, the WTRU can identify a potential RX beam conflict. In this case, the WTRU may be able to perform a comparison without beam indication. If the correlation between the RX beams of the reserved and scheduled transmissions is below a (pre-)configured threshold (e.g., based on the WTRU's knowledge of its beams, such as based on applied weights or spatial domain filters used to generate the beams), the WTRU can identify a potential RX beam conflict.

[0166] If signal reception via the PSFCH RX beam associated with reserved PSSCH resources falls below a quality threshold, the WTRU can identify a potential RX beam conflict. For example, if the WTRU estimates that signal reception from the destination WTRU (e.g., using an RX beam configured to receive reserved transmissions) will be of low quality (e.g., RSRP below a threshold), the WTRU can identify a potential RX beam conflict. This estimation can be based on previous measurements (e.g., during beam management).

[0167] The WTRU can define RX beam conflict (e.g., based on its capabilities). For example, the WTRU can determine RX beam conflict if: at least two RX beams are conflicting (e.g., if the WTRU supports only a single RX beam at a time); and / or at least N+1 RX beams are conflicting (e.g., if the WTRU supports N RX beams at a time).

[0168] The features(s) described herein can be described in the context of a WTRU that supports only one RX beam at a time (e.g., only one). However, those skilled in the art will understand that similar approaches can be extended to any number of simultaneously supported beams. The terms “beam collision” and “beam misalignment” are used interchangeably.

[0169] WTRU can identify and exclude conflicting PSSCH resources from the PSSCH resource set.

[0170] If the WTRU determines that the PSFCH RX beam of the transmission being scheduled conflicts with the PSFCH RX beam of an already scheduled transmission, the WTRU can determine the set of PSSCH resources to be excluded from the candidate resource set (e.g., to avoid PSFCH RX beam conflicts).

[0171] WTRU can determine (e.g., first determine) the PSFCH resources corresponding to the indicated reserved PSSCH resources (e.g., based on the indicated resource pool and / or the (pre)configuration of the indicated reserved PSSCH resources).

[0172] WTRU can determine (e.g., in a reverse mapping manner) one or more (e.g., all) PSSCH resources that are mapped to PSFCH resources with time overlap (e.g., based on the (pre)configuration of the indicated resource pool).

[0173] In some examples (e.g., 3GPP NR Release 17), PSSCH resources mapped to PSFCH resources with time overlap may correspond to PSSCH resources in the same time slot as the indicated reserved PSSCH resources (e.g., all PSSCH resources), and / or correspond to PSSCH resources in the same time slot of the same PSFCH period (e.g., all PSSCH resources).

[0174] WTRU can exclude identified PSSCH resources from the candidate resource set.

[0175] Figure 3 The illustration shows an example of a WTRU excluding Physical Side Link Shared Channel (PSSCH) resources to avoid Physical Side Link Feedback Channel (PSFCH) receive (RX) beam collisions. As illustrated, the WTRU can determine the PSFCH timing (e.g., in blue) corresponding to already reserved PSSCH resources (e.g., in purple). Using the PSFCH period and / or the PSFCH-to-PSSCH minimum time gap, the WTRU can determine resources mapped to the same PSFCH instance (e.g., in yellow). If beam collisions occur, the WTRU can exclude them from the Resource Selection Window (RSW).

[0176] The exclusion order described herein may not be the order used by WTRU. Any other exclusion order may be used. For example, the exclusion order may involve: excluding self-scheduled resources; excluding resources declared by the received SCI; and excluding PSFCH RX beam conflict resources.

[0177] WTRU can determine the resources to be excluded from PSSCH TX beam collisions.

[0178] WTRUs can be (pre-)configured to prevent PSSCH TX beam collisions. If channel reciprocity is assumed for transmission links with different WTRUs, preventing TX beam collisions (e.g., transmitting simultaneously with multiple different beams) can prevent PSSCH RX beam collisions.

[0179] Similarly, TX beam conflict can be determined based on the following: different beam IDs, different TCI states, different SL-RS used for reference, different WTRU IDs, low correlation TX beams, and / or low RSRP signal reception.

[0180] The WTRU can determine (e.g., it can determine first) the PSSCH resources scheduled with the TX beam that conflict with the TX beam being scheduled for transmission (e.g., PSSCH resources in the same time slot of the conflicting PSSCH transmission).

[0181] If the WTRU is (pre-)configured to prevent PSFCH RX beam collisions (e.g., using the channel reciprocity assumption), the WTRU can determine PSSCH resources in the same PSFCH period slot as the colliding PSSCH transmission (e.g., using a resource pool (pre-)configured). The WTRU can exclude (e.g., then exclude) the determined PSSCH resources from the candidate set of PSSCH resources. In this case, RX beam indication may not be used (e.g., required). This situation can (e.g., instead) use TX beam indication for reserved transmissions and transmissions being scheduled. If beam collisions are based on the WTRU ID (e.g., based only on the WTRU ID), beam information may not be used (e.g., may not be required).

[0182] The features described herein may be used individually (e.g., preventing TX and RX beam collisions if channel reciprocity is assumed) or as a complement to other features (e.g., preventing both PSSCH TX and PSFCH RX beam collisions if channel reciprocity is not assumed).

[0183] The PHY layer can report a subset of resources to the MAC layer (e.g., after excluding PSSCH resources due to beam collisions). The MAC layer can select resources for SL transports.

[0184] The MAC layer can exclude resources. Resource exclusion due to beam collisions can be performed by the MAC layer. The MAC layer can receive the following information: a subset of PSSCH resources available for transmission (e.g., a subset of PSSCH resources provided by the PHY layer that excludes only resources based on its own transmission and sensing, e.g., not based on beam collisions); the destination WTRU ID of the transmission; the PSFCH RX beam corresponding to the transmission; and / or the PSSCH resources that have been reserved and the corresponding PSFCH RX beam.

[0185] The PSFCH RX beam can be indicated using a direct PSFCH RX beam indication (e.g., a direct PSFCH RX beam indication). The PSFCH RX beam can be determined based on the mapping between the destination WTRU ID and the indicated WTRU-to-RX beam mapping.

[0186] WTRU can use the determined / indicated PSFCH RX beam of a reserved transmission and / or the PSFCH of a transmission being scheduled (e.g., using techniques as described herein) to determine (e.g., can be determined first) potential PSFCH RX beam conflicts.

[0187] The WTRU can identify a set of PSSCH resources with beam collisions (e.g., using techniques as described herein). The WTRU can exclude the identified conflicting PSSCH resources from a subset of resources received from the PHY layer. If the size of the remaining set of PSSCH resources is below a configured threshold, the MAC layer can request another set of resources from the PHY layer. The technique can then be repeated (e.g., utilizing the new set of resources).

[0188] The WTRU can select the PSSCH resources to use for transmission (e.g., randomly select resources from the remaining set of PSSCH resources). The WTRU can use the PSSCH resources to transmit SL transmissions.

[0189] Beam-aware sidelink (SL) resource allocation can be used to avoid RX beam collisions in the Physical Sidelink Feedback Channel (PSFCH). If a PSFCH RX beam collision is predicted, the transmission can be resolved or prioritized.

[0190] Resources can be reassessed (e.g., Mode 2 resource reassessment) (e.g., to avoid beam collisions).

[0191] The WTRU can detect beam collisions in PSFCH reception (e.g., before transmission). The WTRU can trigger cancellation / reselection of SL transmissions to avoid collisions.

[0192] For example, if a conflict occurs after the initial resource selection (e.g., due to beam changes), the WTRU can trigger a cancellation / reselection of the SL transmission to avoid the conflict. One or more of the following can be performed.

[0193] The WTRU can receive SL beam conflict reassessment (pre)configuration. SL beam conflict reassessment (pre)configuration may include a resource reselection window (e.g., maximum beam conflict reselection time). The WTRU can select or be authorized a set of PSSCH resources. PSSCH resources (e.g., each PSSCH resource) may be associated with one or more of the following resource association information: PSSCH transmissions of SL TBs in the selected PSSCH resource (e.g., WTRU destination ID of the SL TB; remaining packet delay budget (PDB) of the SL TB; and / or SL priority of the SL TB); the PSFCH RX beam for receiving HARQ feedback for the PSSCH transmission; and / or the reservation status of the selected resource (e.g., undeclared, where the selected resource is not reserved in the SL transmission; or declared, where the selected resource is reserved in the SL transmission).

[0194] If the PSFCH RX beam associated with one or more transmitted PSSCH resource reservations is updated (e.g., based on beam pairing reconfiguration), the WTRU can perform a PSFCH beam conflict reassessment.

[0195] If two or more PSFCH RX beams associated with different PSSCH resource reservations are not aligned (e.g., based on different SL TCI states, beam indices), WTRU can determine that there is a PSFCH beam conflict.

[0196] WTRU can identify one or more PSSCH transmissions associated with the identified PSFCH RX beam (e.g., based on resource association information).

[0197] The WTRU can trigger resource reselection for PSSCH transmissions (e.g., for SL TBs with the lowest priority, remaining PDBs above a threshold, and / or undeclared reservations). For example, if a PSSCH transmission (e.g., associated with a PSSCH resource) has a lower priority than a first PSSCH transmission; (e.g., associated with a PSSCH resource) a second PSSCH transmission is associated with a remaining PDB above a threshold; or the reservation status of the PSSCH resource is undeclared, the WTRU can determine that the PSSCH resource meets the reselection criteria.

[0198] If the time until the selected resource for PSSCH transmission exceeds the (pre)configured maximum beam collision reselection time, the WTRU may trigger resource reselection. If the second PSSCH resource meets the reselection criteria and the resource reselection window is in progress, the WTRU may choose to transmit another PSSCH resource within it.

[0199] WTRU can perform priority-ordered / adjusted PSSCH transfers in selected / authorized resources.

[0200] WTRU can perform a reassessment while taking beam conflict into account.

[0201] In SL resource reassessment (e.g., Mode 2), beam information may not be considered during resource selection. Other scheduled transmissions (and beams) (e.g., independent resource allocations) may also be disregarded during resource selection.

[0202] The RX beam can be changed between scheduling and transmission (e.g., configuration authorization). Resource reassessment can be performed without considering beam aspects and / or other transmissions.

[0203] Resources can be reassessed (e.g., Mode 2 resource reassessment) (e.g., to avoid beam collisions).

[0204] The WTRU can detect beam collisions for PSFCH reception (e.g., before transmission). The WTRU can trigger cancellation / reselection of SL transmissions to avoid collisions.

[0205] For example, if a conflict occurs after the initial resource selection (e.g., due to beam changes), the WTRU can trigger a cancellation / reselection of the SL transmission to avoid the conflict. One or more of the following can be performed.

[0206] The WTRU can receive SL beam conflict reassessment (pre)configuration. SL beam conflict reassessment (pre)configuration may include a resource reselection window (e.g., maximum beam conflict reselection time). The WTRU can select or be authorized a set of PSSCH resources. PSSCH resources (e.g., each PSSCH resource) may be associated with one or more of the following resource association information: PSSCH transmissions of SL TBs in the selected PSSCH resource (e.g., WTRU destination ID of the SL TB; remaining PDB of the SL TB; and / or SL priority of the SL TB); the PSFCH RX beam used to receive HARQ feedback for the PSSCH transmission; and / or the reservation status of the selected resource (e.g., undeclared, where the selected resource is not reserved in the SL transmission; or declared, where the selected resource is reserved in the SL transmission).

[0207] If the PSFCH RX beam associated with one or more transmitted PSSCH resource reservations is updated (e.g., based on beam pairing reconfiguration), the WTRU can perform a PSFCH beam conflict reassessment.

[0208] If two or more PSFCH RX beams associated with different PSSCH resource reservations are not aligned (e.g., based on different SL TCI states, beam indices), WTRU can determine that there is a PSFCH beam conflict.

[0209] WTRU can identify one or more PSSCH transmissions associated with the identified PSFCH RX beam in a collision (e.g., based on resource association information).

[0210] The WTRU can trigger resource reselection for PSSCH transmissions (e.g., for SL TBs with the lowest priority, remaining PDBs above a threshold, and / or reservations that have not yet been declared). For example, the WTRU can trigger resource reselection if the time until the selected resource for PSSCH transmission is greater than the (pre)configured maximum beam collision reselection time.

[0211] WTRU can perform priority-ordered / adjusted PSSCH transfers in selected / authorized resources.

[0212] The SL TX WTRU can determine that the PSFCH receiving its scheduled transmissions will have an RX beam collision. If a beam collision is detected, the WTRU can take action on the corresponding transmission (e.g., cancel, reselect, etc.) to avoid the collision.

[0213] In this scenario, for example, if scheduling fails to prevent beam collisions (e.g., because such a technique is not implemented or changes have occurred between the scheduling decision and the actual transmission, such as resource changes, beam changes, etc.), the WTRU can take reactive action to resolve beam collisions (e.g., based on reassessment and / or preemption checks). In this case, reassessment and / or preemption checks can be extended to beam collision verification.

[0214] This article provides one or more features associated with configuration and information exchange.

[0215] The WTRU can be (pre-)configured to use resource allocation mode 2, where the resource pool supports preemption. The WTRU can be (pre-configured) to support beam collision reassessment and / or preemption. The timeframe for the WTRU to perform reassessment and / or preemption considering beam collisions can be configured (e.g., to allow the WTRU sufficient time to perform reassessment and / or preemption checks and, if necessary, select a new resource). This timeframe can be the same as or different from legacy reassessment and / or preemption timeframes (e.g., T3).

[0216] To perform reassessment or preemption checks for beam collisions, the PHY layer may receive the following information (e.g., for each selected / authorized resource): the PSSCH transmission for the SL TB corresponding to the PSSCH resource (e.g., the WTRU destination ID of the SL TB, the remaining PDB of the SL TB, and / or the SL priority of the SL TB); the PSFCH RX beam for receiving HARQ feedback corresponding to the PSSCH transmission; and / or the reservation status of the selected resource (e.g., undeclared, where the resource is selected but not indicated in the SCI transmission; or declared, where the resource is selected and indicated in the SCI transmission).

[0217] Reassessment can be applied to undeclared resources. Preemption can be applied to declared resources.

[0218] This document provides example triggers for beam conflict assessment. One or more triggers can cause the WTRU to perform a reassessment or preemption of beam conflicts for selected resources. The WTRU can determine changes that may lead to changes in beam conflicts (e.g., resources based on already scheduled transmissions and the PSFCH RX beams of those transmissions). A trigger for reassessment or preemption of scheduled resources could be that the WTRU determines that the PSFCH RX beams configured for the scheduled resources have been reconfigured. If: the WTRU receives a beam indication for the PSFCH RX beam from another WTRU or from the network; the WTRU determines a new beam for the PSFCH RX beam (e.g., by the WTRU itself based on measurements of SL RS (e.g., SL-SSB, SL-CSI-RS, PSSCH DMRS, PSCCH DMRS) from the destination WTRU, or receives a measurement report (e.g., an SL CSI report) from the destination WTRU); and / or the WTRU determines a TX beam change toward the destination WTRU (e.g., based on the received beam indication or self-determination, assuming channel reciprocity for beam determination), then a reconfiguration of the PSFCH RX beam may occur.

[0219] The re-evaluation or preemption of scheduled resources can be triggered by the WTRU receiving or determining a new PSSCH resource for SL transmission (e.g., without considering beam conflict). For example, a re-evaluation or preemption can be triggered if: the WTRU performs an autonomous resource selection without beam verification (e.g., mode 2); after a re-evaluation or preemption, the WTRU performs an autonomous resource reselection without beam verification (e.g., mode 2); and / or the WTRU receives authorization from another WTRU (e.g., for WTRU-assisted resource selection).

[0220] WTRU can trigger a reassessment or preemption of resources scheduled for beam collisions during the maximum reassessment and / or preemption time of the resource configuration.

[0221] A subset of resources can be identified for reassessing beam collisions and / or checking beam collision preemption. In some (e.g., legacy) reassessment and / or preemption checks, the PHY layer can be provided with a set of resources to verify their continued availability. For example, this set of resources may include resources scheduled to arrive at T3 (e.g., prior to transmission or announcement). Checks (e.g., legacy checks) can be performed against sensed reservations (e.g., reservations announced by other WTRUs).

[0222] Verification can be performed on resources and associated beams selected by the WTRU. The WTRU can (e.g., needs to) determine the PSSCH resources to be included in the verification. The set of PSSCH resources determined by the WTRU for beam collision verification can include resources scheduled by the WTRU (e.g., all scheduled resources). The set of PSSCH resources determined by the WTRU for beam collision verification can include PSSCH resources scheduled to be mapped to the same PSFCH instance (e.g., all scheduled PSSCH resources). The WTRU can determine this set based on known PSSCH resources and the SL HARQ feedback configuration.

[0223] The set of PSSCH resources for beam collision verification determined by the WTRU may include scheduled PSSCH resources (e.g., all scheduled PSSCH resources) mapped to at least one PSFCH resource that temporally overlaps with the PSSCH resource that triggered the beam collision verification transmission. The WTRU may determine this set based on known PSSCH resources and / or SL HARQ feedback configuration.

[0224] The WTRU can determine RX beam conflicts. For example, the WTRU can determine RX beam conflicts between two or more scheduled transmissions by comparing the PSFCH RX beams configured for possible pairs of simultaneous PSFCH receptions (e.g., all possible pairs of simultaneous PSFCH receptions), for example, based on the HARQ feedback configuration given in the subset of PSFCH resources to be evaluated and / or the beams associated with different PSFCH receptions.

[0225] If a beam collision reassessment or preemption is triggered by a change in one of the PSFCH receive configurations (e.g., a beam change), the reassessment or preemption may limit verification (e.g., to pairs of PFSCHs that include the reconfigured PSFCH).

[0226] If the PSFCH RX beam indices of a pair of reserved transmissions are different, the WTRU can determine an RX beam conflict. If the TCI states of the PSFCH RX beams used for a pair of reserved transmissions are different (e.g., different TCI indices or using different RSs), the WTRU can determine an RX beam conflict.

[0227] If different indication methods are used to indicate the PSFCH RX beam for a pair of reserved transmissions, the WTRU can determine an RX beam conflict (e.g., beam index and TCI status). For example, if a first indication type is used to indicate the PSFCH RX beam associated with a reserved PSSCH resource, and a second indication type, different from the first, is used to indicate the PSFCH RX beam associated with a sidelink TB, the WTRU can determine a potential RX beam conflict.

[0228] If the RX beam is using TX-RX beam mapping and the TX beam indices of a pair of reserved transmissions are different, the WTRU can determine an RX beam collision. The WTRU can also determine an RX beam collision if the WTRU destination IDs of a pair of reserved transmissions are different. In this case, the WTRU may be able to perform the comparison without beam indication.

[0229] If the correlation between a pair of reserved transmission RX beams is below a (configured) threshold (e.g., based on the WTRU knowing its beams, such as based on the applied weights or the spatial filters used to generate the beams), then the WTRU can determine an RX beam collision.

[0230] If signal reception via the PSFCH RX beam associated with reserved PSSCH resources falls below a quality threshold, the WTRU can identify an RX beam conflict. For example, if the WTRU estimates that receiving a signal from another destination WTRU using an RX beam configured to receive transmissions from one destination WTRU would be of low quality (e.g., based on previous measurements during beam management, such as RSRP being below a threshold), the WTRU can identify a potential RX beam conflict.

[0231] If a beam collision is identified between at least one pair of transmissions, the WTRU can use the HARQ feedback configuration to determine the PSSCH resource associated with that beam collision (e.g., a reserved PSSCH resource mapped to the PSFCH of the collision).

[0232] Re-evaluating or preempting verification can (e.g., reporting conflicting PSSCH resources to the MAC layer).

[0233] The WTRU can take action to resolve beam collisions. The WTRU can perform actions (e.g., to resolve and avoid beam collisions) on reported PSSCH resources with beam collisions (e.g., some of the reported PSSCH resources with beam collisions). The WTRU can determine the PSSCH resources from the reported conflicting PSSCH resources (e.g., at least). For example, the WTRU can determine the PSSCH resources from the reported conflicting PSSCH resources based on one or more of the following: the SLTB using the PSSCH resource has the lowest priority among the reported conflicting PSSCH resources; the SLTB using the PSSCH resource has a remaining PDB higher than a configured threshold; there are undeclared reserved resources in the SCI; and / or the maximum time limit for resource reselection for beam collisions against the PSSCH resource has not yet passed.

[0234] WTRU can trigger a resource reselection for the identified PSSCH resource. This may be applicable if the PSSCH resource has already been determined based on whether there are sufficient remaining PDBs for the SL TB and / or if the resource reselection window (e.g., a reselection time limit) is in progress (e.g., has not yet passed).

[0235] If the reselection of a resource does not take beam conflict into account, the WTRU can trigger a beam conflict verification corresponding to that resource.

[0236] A WTRU can cancel a transmission. For example, a WTRU can cancel a transmission if the remaining PDB of the SL TB is below a (pre)configured threshold. A WTRU can cancel a transmission if a resource reselection window (e.g., a time limit for reselection based on beam collision) has ended / passed (e.g., meaning there is not enough time to reselect a satisfactory resource). A WTRU can cancel a transmission if it receives authorization from another WTRU. In that case, the WTRU can report the transmission cancellation to the authorizing device (e.g., due to beam collision). If a transmission is cancelled, the WTRU can (e.g., via an LCP procedure) reallocate the resources used for PSSCH transmissions to another destination WTRU (e.g., limited to a destination WTRU associated with a PSFCH RX beam configuration aligned with the remaining RX beams received simultaneously by the PSFCH).

[0237] WTRU can disable HARQ feedback for SL TB. In that case, WTRU can instruct the destination WTRU not to report HARQ feedback in the SCI of that PSSCH resource. WTRU does not need to perform resource reselection (e.g., if the remaining PDB is below a configured threshold or the reselection time limit has expired, or if retransmissions that would enable HARQ feedback are reserved).

[0238] The WTRU can determine to use an alternative RX beam to receive conflicting PSFCH resources. The WTRU can (e.g., at least temporarily) reconfigure the RX beam of these transmitted PSFCHs to the determined RX beam. The RX beam can be determined based on one or more of the following: if no beam is configured or suitable, or if beam conflict (e.g., wide beam) is detected, a (pre-)configured RX beam is applied by default; and / or an RX beam with good signal quality (e.g., RSRP above a threshold) is used for receiving transmitted PSFCHs from different destination WTRUs from conflicting PSFCH transmissions. The WTRU can indicate the determined RX beam to paired WTRUs (e.g., allowing paired WTRUs to further adjust the TX beam used for transmitting PSFCHs).

[0239] The actions described in this article can be performed jointly or repeatedly on different resources (e.g., until beam collisions are resolved).

[0240] PSSCH TX beam collisions can be avoided. WTRUs can perform reassessment or preemption for beam collisions to avoid transmission conflicts (e.g., preventing WTRUs from simultaneously transmitting PSCCH / PSSCH with different beams). This can be similar to one or more features associated with the PSFCH RX beam described herein, with the following variations: similar configuration and / or indication information can be used for RX beam collisions, where the indication for the RX beam of the PSFCH is replaced by the indication for the TX beam of the PSCCH / PSSCH; triggering one or more of the scheduled resources for reassessment or preemption in response to TX beam collisions can include: the WTRU determining that the configured PSCCH / PSSCH TX beam for the scheduled resource has been reconfigured; TX beam reconfiguration can occur if: the WTRU receives a beam indication for the PSCCH / PSSCH TX beam from another WTRU or from the network, or the WTRU determines a new beam for the PSCCH / PSSCH TX beam through itself. The WTRU may determine a new beam for the PSCCH / PSSCH TX beam based on one or more of the following: measurements of SL RS (e.g., SL-SSB, SL-CSI-RS, PSSCH DMRS, PSCCH DMRS) from the destination WTRU; or receiving a measurement report (e.g., SL CSI report) from the destination WTRU.

[0241] The WTRU can determine which PSSCH resources to evaluate. The set of PSSCH resources determined by the WTRU for TX beam collision verification can include resources (e.g., all scheduled resources) that the WTRU schedules for a given time slot (e.g., the time slot that triggers a PSSCH transmission for re-evaluation or preemption verification).

[0242] The WTRU can determine the presence of TX beam conflict. The WTRU can determine TX beam conflict in a similar manner to that described herein, where the RX beam (for PSFCH) is replaced by the TX beam (for PSSCH / PSCCH).

[0243] This article provides one or more features associated with Mode 1 re-evaluation and / or preemption.

[0244] A WTRU configured with mode 1 resource allocation (e.g., receiving authorization from the network) can perform resource reassessment or preemption verification in response to beam collisions.

[0245] In some examples (e.g., in legacy examples up to NR Rel.17), the network can perform resource selection, and the WTRU LCP allocates the authorized resources to the TB (e.g., without considering SL beamforming). Beam collision verification of the allocated resources can be used (e.g., may be required). Beam collision verification of the allocated resources can be similar to one or more other features described herein (e.g., one or more features described for both Mode 2, RX beam, or TX beam collision). Beam collision verification of the allocated resources can include one or more of the following features (e.g., additional one or more): additional triggers (e.g., triggers for re-evaluating or preempting scheduled resources are whether the WTRU receives a new dynamic grant from the network (e.g., via DCI) or configuration grants (e.g., via RRC configuration or DCI activation for SL transport, and MAC / LCP allocation of resources to the SL TB).

[0246] A WTRU can perform one or more actions on conflicting resources. A Mode 1 WTRU may not be configured or enabled to perform resource reselection. Resource reselection options may not be available for conflicting resources authorized in Mode 1. A WTRU can cancel a determined conflicting PSSCH resource. A WTRU can report an indication that a transmission has been canceled to the network (e.g., using MAC CE). This report may include information identifying the resource whose transmission was canceled (e.g., the time / frequency of the authorized resource). A WTRU can instruct the MAC layer and LCP to reassign the resource to another destination WTRU (e.g., due to beam conflict).

[0247] In SL HARQ feedback transmission, there may be PSFCH resources mapped based on (pre)configuration (e.g., a single PSFCH resource). There may be no beaming considerations for the transmission (TX) or RX of the PSFCH.

[0248] One or more PSFCH timings and PSFCH beam scans can be used (e.g., to avoid beam collisions).

[0249] The SL RX WTRU can repeat HARQ feedback transmissions (e.g., on multiple symbols / timings). The SL RX WTRU can repeat HARQ feedback transmissions based on Side Link Control Information (SCI) indications. The SL TX WTRU can allocate SL resources in the absence of RX beam collisions. The WTRU can use beam scanning to monitor the PSFCH. One or more of the following can be performed.

[0250] A WTRU (e.g., on the data RX side, such as a PSFCH transmitter) can receive (pre)configured PSFCH resources from a resource pool. At the (pre)configured PSFCH time, a PSFCH resource can correspond to one or more symbols. The (pre)configured PSFCH resources can include associated PSSCH-to-PSFCH resource mappings (e.g., a one-to-N mapping between 1 PSSCH and N PSFCH resources).

[0251] The WTRU can be (pre-)configured with an SCI format. The SCI format may include one or more of the following: a PSFCH resource indication format (e.g., a bitmap or activation flag), and / or an indication of (one or more) PSFCH TX beams.

[0252] The WTRU can receive HARQ-enabled PSCCH / PSSCH transmissions. HARQ-enabled sidelink transmissions may include sidelink control information (SCI) indicating an index associated with PSFCH resource selection. HARQ-enabled PSCCH / PSSCH transmissions may include WTRU source and / or destination IDs.

[0253] A WTRU can identify one or more PSFCH resources. A WTRU can identify one or more associated PSFCH TX beams. A WTRU can identify one or more PSFCH resources and / or one or more associated PSFCH TX beams based on the SCI indication in the received PSCCH / PSSCH, the WTRU source and / or destination ID, and / or the (pre)configuration of the resource pool. A WTRU can identify a set of PSFCH resources based on the PSSCH resources and the PSSCH-to-PSFCH resource mapping. For example, a received bitmap can indicate a subset of (pre)configured resources used for PSFCH transmission.

[0254] The WTRU can transmit the PSFCH in a defined resource (e.g., each defined resource). The WTRU can transmit the PSFCH using a defined PSFCH TX beam.

[0255] PSFCH timing and PSFCH beam scanning can be used (e.g., to avoid beam collisions). One or more of the following can be performed.

[0256] A WTRU (e.g., on the data TX side, such as a PSFCH receiver) can receive (pre)configured PSFCH resources from a resource pool. At the (pre)configured PSFCH time, a PSFCH resource can correspond to one or more symbols. The (pre)configured PSFCH resources can include associated PSSCH-to-PSFCH resource mappings (e.g., a one-to-N mapping between 1 PSSCH and N PSFCH resources). The (pre)configured PSFCH resources can also include associated PSFCH-to-RX beam mappings (e.g., a one-to-one mapping between a beam index and a PSFCH resource).

[0257] The WTRU can be (pre-)configured with an SCI format. The SCI format may include a PSFCH resource indication format (e.g., a bitmap or activation flag). The WTRU can receive indications of resource information for one or more HARQ-enabled SL transmissions. The resource information may include one or more of the following: reserved / selected PSSCH resources; associated PSFCH RX beams; and / or RX reference signal received power (RSRP) associated with the PSFCH RX beams.

[0258] The WTRU can identify one or more PSFCH resources. The WTRU can identify one or more PSFCH RX beams and / or one or more PSFCH TX beams associated with a PSSCH transmission. For example, the WTRU can identify one or more PSFCH RX beams and / or one or more PSFCH TX beams associated with a PSSCH transmission based on one or more of the following: PSFCH resources mapped to the RX PSFCH beam associated with the transmission; PSFCH resources not yet associated with an RX beam different from the PSFCH RX beam; and / or multiple PSFCH resources (e.g., if the PSFCH RX beam RSRP is below a threshold).

[0259] The WTRU can transmit PSCCH / PSSCH. The PSCCH / PSSCH can indicate (e.g., in the SCI) one or more determined PSFCH resources and / or PSFCH beams (e.g., based on a (pre)configured PSFCH indication format).

[0260] The WTRU can receive (one or more) of the indicated PSFCH resources using the identified associated PSFCH RX beam.

[0261] This article provides one or more features associated with one or more (e.g., multiple) PSFCH timing and PSFCH beam scanning.

[0262] In SL HARQ feedback transmission, there may be PSFCH resources mapped based on (pre)configuration (e.g., a single PSFCH resource). There may be no beaming considerations for the transmission (TX) or RX of the PSFCH.

[0263] One or more PSFCH timings and PSFCH beam scans can be used (e.g., to avoid beam collisions).

[0264] The SL RX WTRU can repeat HARQ feedback transmissions (e.g., on multiple symbols / timings). The SL RX WTRU can repeat HARQ feedback transmissions based on Side Link Control Information (SCI) indications. The SL TX WTRU can allocate SL resources in the absence of RX beam collisions. The WTRU can use beam scanning to monitor the PSFCH. One or more of the following can be performed.

[0265] A WTRU (e.g., on the data RX side, such as a PSFCH transmitter) can receive (pre)configured PSFCH resources from a resource pool. At the (pre)configured PSFCH time, a PSFCH resource can correspond to one or more symbols. The (pre)configured PSFCH resources can include associated PSSCH-to-PSFCH resource mappings (e.g., a one-to-N mapping between 1 PSSCH and N PSFCH resources).

[0266] The WTRU can be (pre-)configured with an SCI format. The SCI format may include one or more of the following: a PSFCH resource indication format (e.g., a bitmap or activation flag), and / or an indication of (one or more) PSFCH TX beams.

[0267] WTRU can receive HARQ-enabled PSCCH / PSSCH transports. HARQ-enabled PSCCH / PSSCH transports may include WTRU source and / or destination IDs. HARQ-enabled PSCCH / PSSCH transports may include an SCI indicating an index (e.g., a bitmap) associated with PSFCH resource reselection.

[0268] A WTRU can identify one or more PSFCH resources. A WTRU can identify one or more associated PSFCH TX beams. A WTRU can identify one or more PSFCH resources and / or one or more associated PSFCH TX beams based on the SCI index indication in the received PSCCH / PSSCH, the WTRU source and / or destination ID, and / or the (pre)configuration of the resource pool. For example, the received index / bitmap can indicate a subset of (pre)configured resources used for PSFCH transmission.

[0269] The WTRU can transmit the PSFCH in a defined resource (e.g., each defined resource). The WTRU can transmit the PSFCH using a defined PSFCH TX beam.

[0270] PSFCH timing and PSFCH beam scanning can be used (e.g., to avoid beam collisions). One or more of the following can be performed.

[0271] A WTRU (e.g., on the data TX side, such as a PSFCH receiver) can receive (pre)configured PSFCH resources from a resource pool. At the (pre)configured PSFCH time, a PSFCH resource can correspond to one or more symbols. The (pre)configured PSFCH resources can include associated PSSCH-to-PSFCH resource mappings (e.g., a one-to-N mapping between 1 PSSCH and N PSFCH resources). The (pre)configured PSFCH resources can also include associated PSFCH-to-RX beam mappings (e.g., a one-to-one mapping between a beam index and a PSFCH resource).

[0272] The WTRU can be (pre-)configured with an SCI format. The SCI format may include a PSFCH resource indication format (e.g., a bitmap or activation flag). The WTRU can receive indications of resource information for one or more HARQ-enabled SL transmissions. The resource information may include one or more of the following: reserved / selected PSSCH resources; associated PSFCH RX beams; and / or RX reference signal received power (RSRP) associated with the PSFCH RX beams.

[0273] The WTRU can identify one or more PSFCH resources. The WTRU can identify one or more PSFCH RX beams and / or one or more PSFCH TX beams associated with a PSSCH transmission. For example, the WTRU can identify one or more PSFCH RX beams and / or one or more PSFCH TX beams associated with a PSSCH transmission based on one or more of the following: PSFCH resources mapped to the RX PSFCH beam associated with the transmission; PSFCH resources not yet associated with an RX beam different from the PSFCH RX beam; and / or multiple PSFCH resources (e.g., if the PSFCH RX beam RSRP is below a threshold).

[0274] The WTRU can transmit PSCCH / PSSCH. The PSCCH / PSSCH can indicate (e.g., in the SCI) one or more determined PSFCH resources and / or PSFCH beams (e.g., based on a (pre)configured PSFCH indication format).

[0275] The WTRU can receive one or more of the indicated PSFCH resources using the identified associated PSFCH RX beam.

[0276] Flexible PSFCH reporting can be used if multiple PSFCH resources are (pre-)configured and / or if the SL RX WTRU transmit indication in the SCI determines one or more resources on which the WTRU will transmit PSFCH. One or more PSFCH resources can be determined (e.g., on the SL TX WTRU side) to avoid RX beam collisions or to perform beam scanning.

[0277] As described in this article, flexible PSFCH reporting may affect SL TX WTRU and SL RX WTRU.

[0278] This article provides one or more features associated with PSFCH timing mapping and configuration.

[0279] SL TX WTRU and SL RX WTRU can be (pre-)configured in a resource pool (e.g., a resource pool where: HARQ feedback is enabled; PSFCH resources correspond to one or more symbols of (pre-)configured PSFCH timings; and / or there is an associated PSSCH to PSFCH resource mapping (e.g., a 1-to-N mapping between PSSCH and N PSFCH timings)).

[0280] Different configurations are possible (e.g., multiple PSFCH timings in the resource pool). Different configurations can correspond to a given PSSCH transmission. The purpose of having multiple PSFCH timings for a PSSCH (e.g., per PSSCH) is that the WTRU can perform beam scanning of the PSFCH by using different beamforming for each timing (e.g., each timing). Beam scanning can be performed by an SL TX WTRU (e.g., PSFCH receive beamforming) or an SL RX WTRU (e.g., PSFCH TX beamforming). SL TX WTRU beam scanning can resolve PSFCH RX beam conflicts (e.g., since the SL TX WTRU receives the PSFCH in at least the right RX beam, assuming all configured PSFCH RX beams are used in the beam scan).

[0281] One or more (e.g., multiple) PSFCH timings for a given PSSCH can be defined within a (e.g., a single) time slot. SL time slots can be temporally multiplexed with one or more (e.g., multiple) PSFCHs (e.g., using non-overlapping symbols of the time slot). Different PSFCH timings within a time slot can be temporally consecutive. For example, for N=4, four consecutive symbols of a time slot can be configured as four PSFCH timings (e.g., where each symbol is one timing). Figure 4 The diagram illustrates the PSFCH timing that repeats within a single time slot. The shading of a PSFCH timing indicates that it corresponds to a PSSCH with the same shading. Figure 4 As illustrated, assuming a single slot delay between PSSCH and PSFCH, PSSCH can correspond to four PSFCH symbols / timings in the next slot.

[0282] One or more PSFCH timings for a given PSSCH can be defined across one or more (e.g., multiple) time slots. These time slots can be configured to be consecutive. The location of PSFCH timings within a time slot may not necessarily be the same across different time slots. The pattern of PSFCH location can be (pre)configured. One or more PSFCH timings corresponding to different PSSCHs can be configured within a single time slot.

[0283] Figure 5 The illustration shows an example of a rotating PSFCH timing. The shading of a PSFCH timing indicates that the PSFCH timing corresponds to a PSSCH with the same shading. An index associated with the PSFCH resource selection can indicate the PSFCH timing pattern (e.g., from a set of (pre)configured PSFCH timing patterns). WTRU can select PSFCH resources from the set of PSFCH resources based on the PSFCH timing pattern. For example, for N=4, a rotating PSFCH timing pattern can be defined using four slots and four symbols in each slot. Figure 5 As illustrated, assuming a single slot delay between PSSCH and PSFCH, (e.g., one) the configuration could be PSSCH corresponding to the first PSFCH timing / symbol in the slot following PSSCH transmission, corresponding to the second timing / slot in the slot following the first, corresponding to the third timing / symbol in the subsequent slot, and corresponding to the fourth timing / symbol in the subsequent slot.

[0284] For a given PSSCH, one or more (e.g., multiple) PSFCH timings can be (pre)configured in time slots and span multiple time slots. This option can be a combination of one or more other features described herein.

[0285] Although a single symbol for each timing is used as an example in this article, multiple symbols can be used for a timing in a similar manner.

[0286] The HARQ configuration of a resource pool may include: configuring the number (e.g., N) of PSFCH opportunities for each PSSCH in the resource pool (e.g., this may be (pre)configured for the resource pool, and its determination by the gNB or WTRU may be based on WTRU capabilities, e.g., based on the number of supported beams); and / or an indication of the mapping type (e.g., PSSCH to PSFCH mapping mode). A list of PSSCH to PSFCH mapping modes (e.g., {intra-slot repetition, inter-slot rotation}) may be predefined. An indication of which mode to use may be (pre)configured in the resource pool. The determination of PSSCH to PSFCH resources (e.g., the exact PSSCH to PSFCH resource) may be based on the indicated mode and / or the indicated value of N.

[0287] This document provides one or more features associated with the time selection indication format and configuration in PSFCH.

[0288] If configured in a resource pool with multiple PSFCH times per PSSCH, the SL RX WTRU can be configured to repeat PSFCH transmissions in the PSFCH times of the PSSCH (e.g., all PSFCH times) or only in a subset of PSFCH times. Repeating and / or subset selection can be indicated to the WTRU semi-statically or dynamically.

[0289] The SL TX WTRU sends an instruction in the SCI (e.g., Level 2 SCI) of the PSSCH to indicate the timing of the PSFCH(one or more) to which the SL RX WTRU should report HARQ feedback.

[0290] A bit sequence (e.g., bitmap, bit string) can be used to indicate one or more PSFCH timings used for HARQ reporting. The nth bit can indicate whether the nth PSFCH timing is activated for this PSFCH transmission. The size of the sequence can be N. The size of the sequence can be configured based on the resource pool. This option provides flexibility to implement any subset of timings.

[0291] You can report indications (e.g., a single PSFCH timing) to HARQ. The PSFCH timing index can be indicated in the SCI. This indication can be numeric (e.g., of size ceil(log2(N))). The value of n can indicate that the PSFCH timing to be used is the nth timing from the (pre)configured timing. This option can provide an overhead-efficient indication for (e.g., a single timing indication).

[0292] A preselected subset of PSFCH timings (or PSFCH modes) can be configured for the resource pool (e.g., firstly). A PSFCH mode can be a subset of PSFCH timings (e.g., any subset). Mode indications can be sent in the SCI. A mode index can point to one of the (pre)configured PSFCH modes for the timing. A single-bit binary indication can be configured to use a single PSFCH timing or one or more (e.g., all) of the configured PSFCH timings.

[0293] This instruction can be sent within the SCI. The SCI format to be used can be configured (e.g., to avoid blind decoding of different SCI formats). The PSFCH instruction in the SCI can be (pre)configured in the resource pool (e.g., using RRC configuration). This configuration can indicate the type of subset selection and the possible patterns of the subset (e.g., if needed). For example, this configuration can indicate the selection between bit sequences, timing indices, and pattern indices.

[0294] The SCI format can be indicated in the PSSCH. If the PSFCH is indicated in the second-level SCI, then the first-level SCI (e.g., which is included in the PSCCH) can indicate the second-level SCI format (e.g., for a set of second-level SCI formats that may include formats with multiple PSFCH timing schemes).

[0295] The SCI format with PSFCH indication can be used as the default format in resource pools with SL beamforming (e.g., for resource pools on FR2 carriers).

[0296] This indication may not be dynamically sent in the SCI. It can be configured semi-statically (e.g., using RRC configuration and / or MAC CE indication). Other options for identifying PSFCH timing (e.g., bit sequence, index, pattern index) (e.g., used as dynamic options) can be configured for semi-static configuration. A semi-static indication can activate (or deactivate) one or more PSFCH timings for use with PSSCHs received in that resource pool (e.g., per PSSCH). A semi-static configuration can instruct the SLRX WTRU to repeat the PSFCH (e.g., across all configured PSFCH timings).

[0297] A delay can be (pre)configured in the resource pool. This delay can indicate the time spent by the WTRU waiting for a new PSFCH timing configuration to take effect. The delay can also indicate the next PSSCH transmission to implement the indicated PSFCH timing scheme. The delay can be configured as multiple time slots or as an absolute time indication.

[0298] One or more PSFCH resources can be identified on the RX WTRU side.

[0299] The SL RX WTRU can be configured with a resource pool that enables HARQ feedback. The SL RX WTRU can determine one or more PSFCH timings for issuing / repeating HARQ feedback. For example, the SL RX WTRU can determine one or more PSFCH timings for issuing / repeating HARQ feedback based on one or more of the following configurations: multiple PSFCH timing configurations (e.g., the number of PSFCH timings, the mapping from PSSCH to PSFCH timings, and the mapping mode, if any); and / or the configuration of PSFCH format indication and association (e.g., semi-static or dynamic).

[0300] The SL RX WTRU can be (pre-)configured with a dynamic bit sequence indicator for PSFCH indication in the SCI. The SL RX WTRU can receive SL transmissions on a resource pool. The SL RX WTRU can decode the SCI based on the indicated SCI format. The SL RX WTRU can decode the bit sequence (e.g., based on the number of PSFCH timings configured in the resource pool). The SL RX WTRU can read the active bits (e.g., set to 1 if active and 0 if inactive). The SL RX WTRU can determine the PSFCH timing on which to transmit HARQ feedback (e.g., based on the (pre-)configured PSSCH-to-PSFCH mapping, the indicated bit sequence, and / or PSSCH resources). The index associated with PSFCH resource selection can be a bit sequence. If the nth bit in the bit sequence is set to 1, then the bit sequence can indicate the nth PSFCH resource. For example, if N=4 and the sequence is 0101, then the second and fourth PSFCH timings can be used for PSFCH transmissions. The SL RX WTRU can decode the SL TB. The SL RX WTRU can transmit associated HARQ feedback at one or more determined PSFCH timings.

[0301] The SL RX WTRU can be (pre-)configured with a semi-static bit sequence indication for PSFCH indication in the SCI. The semi-static configuration (e.g., from RRC or MAC CE) can be indicated as a bit sequence (e.g., based on the number of PSFCH timings configured in the resource pool). For example, if N=4 and the sequence is 1000, the first PSFCH timing can be used for the PSFCH transmission of the incoming PSSCH transmission. The SL RX WTRU can receive SL transmissions on the resource pool. The SL RX WTRU can decode the SCI. The SL RX WTRU can determine the PSFCH timing on which to transmit HARQ feedback (e.g., based on the (pre-)configured PSSCH-to-PSFCH mapping, the indicated bit sequence, and / or PSSCH resources). The SL RX WTRU can decode the SL TB. The SL RX WTRU can transmit associated HARQ feedback on one or more of the determined PSFCH timings.

[0302] The SL RX WTRU can be (pre-)configured with a dynamic timing index indicator for PSFCH indication in the SCI. The SL RX WTRU can receive SL transmissions on a resource pool. The SL RX WTRU can decode the SCI based on the indicated SCI format. The SL RX WTRU can decode the PSFCH timing index value (e.g., based on the number of PSFCH timings configured in the resource pool). The SL RX WTRU can determine the PSFCH timing on which to transmit HARQ feedback (e.g., based on the (pre-)configured PSSCH-to-PSFCH mapping, PSSCH resources, and / or the indicated timing index). The index associated with PSFCH resource selection is the PSFCH timing index. If the value of the PSFCH timing index is n, then the PSFCH timing index can indicate the nth PSFCH resource. For example, if the value is 3, then the third PSFCH timing can be used for PSFCH transmission. The SL RX WTRU can decode the SL TB. The SL RX WTRU can transmit associated HARQ feedback at a determined PSFCH timing.

[0303] The SL RX WTRU can be (pre-)configured with a semi-static timing index indicator for PSFCH indication in the SCI. The semi-static configuration (e.g., from RRC or MAC CE) can indicate a PSFCH timing index value (e.g., based on the number of PSFCH timings configured in the resource pool). For example, if the value is 2, a second PSFCH timing can be used for an incoming PSSCH transmission. The SL RX WTRU can receive SL transmissions on the resource pool. The SL RX WTRU can decode the SCI. The SL RX WTRU can determine the PSFCH timing on which to transmit HARQ feedback (e.g., based on the (pre-)configured PSSCH-to-PSFCH mapping, the indicated timing index value, and / or PSSCH resources). The SL RX WTRU can decode the SL TB. The SL RX WTRU can transmit the associated HARQ feedback on the determined PSFCH timing.

[0304] The SL RX WTRU can be (pre-)configured with a dynamic mode indicator for PSFCH indication in the SCI. The SL RX WTRU can receive SL transports on a resource pool. The SL RX WTRU can decode the SCI (e.g., based on the indicated SCI format). The SL RX WTRU can decode the mode index (e.g., based on the number of configured modes). The SL RX WTRU can determine the PSFCH timing on which to transmit HARQ feedback (e.g., based on the (pre-)configured PSSCH-to-PSFCH mapping, the indicated mode index, the configured mode list, and / or PSSCH resources). For example, the mode can indicate that the configured PSFCH timing (e.g., all configured PSFCH timings) is used for PSSCH. The SL RX WTRU can decode the SL TB. The SL RX WTRU can transmit associated HARQ feedback on one or more of the determined PSFCH timings.

[0305] The SL RX WTRU can be (pre)configured with a semi-static mode indication for PSFCH indication in the SCI. The semi-static configuration (e.g., from RRC or MAC CE) can indicate the PSFCH timing mode or mode index to be used from a (pre)configured mode list in the resource pool. For example, the mode can indicate the use of a single transport corresponding to the first PSFCH timing. The SL RX WTRU can receive SL transports on the resource pool. The SL RX WTRU can decode the SCI. The SL RX WTRU can determine the PSFCH timing on which to transmit HARQ feedback (e.g., based on a (pre)configured PSSCH-to-PSFCH mapping, the timing indicated from one or more of the mode, and / or PSSCH resources). The SL RX WTRU can decode the SL TB. The SL RX WTRU can transmit associated HARQ feedback on one or more of the determined PSFCH timings.

[0306] One or more PSFCH resources can be determined on the SL TX WTRU side.

[0307] The SL TX WTRU can be (pre-)configured on a resource pool with one or more PSFCH timings. The SL TX WTRU can determine one or more timings that the RX SL WTRU will use to report HARQ feedback. The SL TX WTRU can transmit SL TB and / or PSFCH indications in the transmitted SCI (if any). The SL TX WTRU can receive PSFCH (e.g., using its configured PSFCH RX beam) on one or more indicated PSFCH timings.

[0308] The SL TX WTRU can be (pre-)configured with PSFCH timing-to-RX beam mapping (e.g., based on its RX beam capability).

[0309] (For example, each) consecutive PSFCH timing can correspond to a different RX beam (e.g., making it possible to receive a set of PSFCH timings using RX beam scanning). Within a time slot, multiple symbols can correspond to different PSFCH timings, such as... Figure 4 The diagram in the image shows (for example, where each PSFCH timing number will be received with a different RX beam).

[0310] A series of consecutive PSFCH timings can correspond to a given RX beam. A series of consecutive timings can correspond to different RX beams (e.g., such as...). Figure 5 As illustrated, all PSFCHs in a time slot are configured to be received with a given RX beam, and each time slot will be configured with consecutively different RX beams.

[0311] PSSCH (e.g., each PSSCH) can be configured to have at least one PSFCH corresponding to the correct RX beam for PSFCH reception.

[0312] The SL TX WTRU can determine the PSFCH timing on which the SL RX WTRU should transmit. The SL TX WTRU can select the PSFCH timing mapped to a PSFCH RX beam configured to receive the PSFCH corresponding to the destination WTRU of the SL TB. The PSFCH timing can be indicated (e.g., a single PSFCH timing). The PSFCH timing can be indicated using a corresponding bit sequence or resource index (e.g., depending on the PSFCH indication configuration). Figure 6 As illustrated, instructions can be executed dynamically (e.g., in SCI). These instructions can also be executed semi-statically (e.g., using SL MAC CE instructions or SL RRC configuration). The semi-static configuration can be updated if (e.g., each time) the WTRU changes its RX beam configuration with the destination WTRU.

[0313] Figure 6 The illustration shows an example selection / indication of PSFCH timing based on the corresponding RX beam.

[0314] The SL TX WTRU can determine several PSFCH timings for the SL RX WTRU to report (e.g., each PSFCH timing corresponds to a different RX beam, allowing the SL TX WTRU to perform beam scanning of PSFCH reception). The determination of beam scanning for PSFCH can be based on signal quality on the SL link (e.g., if the SL RSRP is below a given threshold). The WTRU can determine a subset (e.g., only a subset) of the RX beams to be beam scanned (e.g., based on the RX RSRP of the different RX beams of the destination WTRU).

[0315] If the WTRU is configured with a dynamic HARQ feedback indication, the WTRU can indicate (e.g., dynamically) beam scan selection (e.g., by using a bit sequence or beam pattern corresponding to all PSFCH timings).

[0316] WTRU can be configured to use a semi-static configuration. WTRU can be configured to use SL MAC CE or SL RRC configuration (e.g., indicating (de)activation of PSFCH beam scanning).

[0317] Figure 7 The illustration shows examples of multiple PSFCH timings used for PSFCH backup.

[0318] The WTRU can determine the PSFCH timing to use based on the PSFCH RX beam corresponding to the PSSCH transmission and the PSFCH RX beam of other scheduled transmissions. For example, on the SL TX WTRU side, the PSFCH timing may not be (semi-)statically associated with the RX beam. The PSFCH timing to use can be configured (e.g., as a default) as a PSFCH timing (e.g., the first timing to reduce latency). If the WTRU determines a PSFCH RX beam conflict (e.g., as described herein), or if the WTRU receives one or more SL grants for an incoming PSSCH transmission (e.g., in Mode 1), the WTRU can select one or more other configured PSFCH timings. This can create a backup PSFCH schedule (e.g., to dynamically avoid PSFCH beam conflicts). Indications in the SCI (e.g., using beam pattern indicators, bit sequences, or indexes) can refer to one or more PSFCH timings(s) used to avoid beam conflicts, such as... Figure 7 As shown in the diagram.

[0319] The WTRU can be configured with (semi-)static PSFCH timing selection. The WTRU can determine the timing of one or more PSFCHs to monitor for a given PSSCH (e.g., based on configuration and PSSCH resources). The WTRU can be configured with subset timing modes and / or beam scan indication.

[0320] This article provides one or more features associated with PSFCH TX / RX beam determination and indication.

[0321] One or more WTRUs can be configured (or receive instructions to) perform beam scanning or use a constant beam on different PSFCH resources.

[0322] The SL TX WTRU can be (pre-)configured to perform beam scanning on a configured PSFCH timing (e.g., at least by default). This configuration can be an RRC for a resource pool or an SL RRC configuration with paired WTRUs. This configuration can be based on WTRU capabilities (e.g., the number of supported PSFCH RX beams). In this case, the SL TX WTRU can determine that the SL RX WTRU will perform beam scanning (e.g., based on SL link quality, such as SL RSRP being below a threshold or indicated by the beam manager). The SL TX WTRU can send an indication (e.g., in the SCI) to trigger a PSFCH TX beam scan (e.g., a bit flag). If the SL TX WTRU sends this indication, it is not expected that the SL TX WTRU will perform an RX beam scan on the PSFCH resource associated with the PSSCH.

[0323] At least by default, the SL RX WTRU can be (pre-)configured to transmit PSFCH using a static PSFCH TX beam at the configured PSFCH timing. This configuration can be an RRC for a resource pool or an SL RRC configuration with paired WTRUs. In this case, if the SL RX WTRU receives (e.g., in an SCI) an indication (e.g., a bit flag) to trigger a PSFCH TX beam scan, the SL RX WTRU can perform a TX beam scan on the PSFCH resource associated with the PSSCH (e.g., to determine the PSFCH TX beam associated with the PSSCH resource).

[0324] Figure 8 The illustration shows an example of a PSFCH repeat indicator. For example... Figure 8 As illustrated, the TX WTRU can send PSSCH / PSSCH transmissions to the RX WTRU. The SCI can include an indication (e.g., via an activation bit flag) of PSSCH repetition at configured PSSCH timings within consecutive PSSCH cycles. This indication can be combined with an SCI indication that the RX WTRU intends to transmit PSSCH using the same or a different TX beam. The WTRU can transmit PSSCH transmissions in a second PSSCH resource within a first PSSCH cycle and a second PSSCH cycle (e.g., based on an indication of PSSCH repetition performed on the first WTRU).

[0325] This article provides one or more features associated with SL RX WTRU and SL TX WTRU.

[0326] Beam collision can be avoided using Mode 1 Rx.

[0327] In NR-side link mode 1 resource allocation (e.g., up to version 17), the network can perform resource scheduling. The network can send SL grants to WTRUs (e.g., using DCI, such as DCI 3_0). The DCI can include indications of the resources to be used (e.g., time and frequency). The DCI may not indicate whether the grant is targeted at an SL TB or an SL WTRU. On the SL TX WTRU side, if a mode 1 grant is received, the granted resources can be used by the MAC layer for Logical Channel Priority Ordering (LCP). The LCP can determine which logical channel (LC) has the highest priority (e.g., based on data priority and / or latency considerations). The WTRU can allocate the granted resources to the SL TB of the determined highest priority LC. In the SL, an LC may correspond to (e.g., a single) WTRU.

[0328] The network may not know the WTRU for which the transmission will be used. The network may not know the destination WTRU associated with a transmission that will use authorized resources. This may not be a problem in the case of non-directional SL transmissions. Using directional beams to receive and transmit a limited number of simultaneous beams can lead to beam collisions.

[0329] In SL resource allocation (e.g., Mode 1 SL resource allocation), beam information may not be considered on the network side. WTRU can allocate authorized resources to LC via LCP (e.g., based on priority and / or timing). Beam considerations may not exist on the LCP side.

[0330] LCP-based priority ordering (e.g., mode 1) can be used (e.g., to avoid PSFCH RX beam collision).

[0331] If the resource is selected by the gNB (e.g., the WTRU beam is unknown), the SL WTRU LCP can add criteria to select the WTRU / TB that will avoid RX PSFCH beam conflicts. One or more of the following can be performed.

[0332] WTRUs may be (pre)configured with PSFCH timings during resource pool and / or HARQ processing cycles. WTRUs may receive indications for one or more of the following parameters: the PSFCH RX beam of the WTRU with an active SL connection; the destination WTRU ID of the SL TB (e.g., the PSSCH transmission of the SL TB for HARQ enablement on that resource pool); reserved PSSCH resources (e.g., the PSSCH transmission of the SL TB for HARQ enablement on that resource pool); PSSCH-to-PSFCH resource mapping; and / or associated PSFCH resources and PSFCH RX beams (e.g., the PSSCH transmission of the SL TB for HARQ enablement on that resource pool).

[0333] WTRUs can transmit Side Link Buffer Status Reports (SL-BSRs) to the network. SL-BSRs can include one or more (e.g., different) WTRU destinations.

[0334] The WTRU can receive authorization for PSSCH resources for SL transport (e.g., SL mode 1) from the network (e.g., via DCI).

[0335] WTRU can determine the PSFCH resource associated with the received authorized PSSCH resource (e.g., based on the PSSCH to PSFCH resource mapping configuration).

[0336] WTRU can determine that PSFCH resources are concurrent with PSFCH resources that have already been scheduled for transmission.

[0337] The WTRU can determine (e.g., for a logical channel with available SL data for transmission) the PSFCH RX beam associated with the authorized PSSCH resources (e.g., corresponding to PSSCH transmission to the destination WTRU associated with the logical channel).

[0338] The WTRU can select the logical channel with the highest priority and available SL data. The WTRU can select a logical channel for which the RX PSFCH beam is the same as the RX PSFCH beam that has been reserved / scheduled for transmission.

[0339] The WTRU can assign received grants to selected logical channels. The WTRU can transmit PSCCH / PSSCH on the granted resources. The WTRU can use a defined RX PSFCH beam to receive the corresponding PSFCH.

[0340] WTRU can send updated SL-BSRs to the network.

[0341] This article provides one or more features associated with using LCP to select LCs that avoid beam collisions.

[0342] In SL resource allocation (e.g., Mode 1 SL resource allocation), beam information may not be considered on the network side. WTRU can allocate authorized resources to LC via LCP (e.g., based on priority and / or timing). Beam considerations may not exist on the LCP side.

[0343] LCP-based priority ordering (e.g., mode 1) can be used (e.g., to avoid PSFCH RX beam collision).

[0344] If the resource is selected by the gNB (e.g., the WTRU beam is unknown), the SL WTRU LCP can add criteria to select the WTRU / TB that will avoid RX PSFCH beam conflicts. One or more of the following can be performed.

[0345] WTRUs may be (pre)configured with PSFCH timings during resource pool and / or HARQ processing cycles. WTRUs may receive indications for one or more of the following parameters: the PSFCH RX beam of the WTRU with an active SL connection; the destination WTRU ID of the SL TB (e.g., the PSSCH transmission of the SL TB for HARQ enablement on that resource pool); reserved PSSCH resources (e.g., the PSSCH transmission of the SL TB for HARQ enablement on that resource pool); PSSCH-to-PSFCH resource mapping; and / or associated PSFCH resources and PSFCH RX beams (e.g., the PSSCH transmission of the SL TB for HARQ enablement on that resource pool).

[0346] WTRUs can transmit Side Link Buffer Status Reports (SL-BSRs) to the network. SL-BSRs can include one or more (e.g., different) WTRU destinations.

[0347] The WTRU can receive authorization for SL transport (e.g., SL mode 1) from the network (e.g., via DCI).

[0348] WTRU can determine the PSFCH resource associated with the received authorized PSSCH resource (e.g., based on the PSSCH to PSFCH resource mapping configuration).

[0349] The WTRU can determine that there is a beam conflict between a first PSFCH RX beam associated with an authorized PSSCH resource and a second PSFCH RX beam associated with a reserved PSSCH resource. For example, the WTRU can determine that the PSFCH resource is concurrent with a reserved (e.g., already scheduled) PSFCH transmission.

[0350] Based on the determination that there is a beam conflict between the first PSFCH RX beam and the second PSFCH RX beam, the WTRU can select an LC associated with a third PSFCH RX beam that is aligned with the first PSFCH RX beam. For example, the WTRU can determine (e.g., for a logical channel with available SL data for transmission) the PSFCH RX beam corresponding to the PSSCH transmitted to the destination WTRU associated with the same logical channel.

[0351] The WTRU can select an LC by identifying a set of LCs associated with the PSFCH RX beam aligned with the first PSFCH RX beam and selecting an LC based on the priority associated with that LC (e.g., from that set of LCs). For example, the WTRU can select the logical channel with available SL data that has the highest priority. The WTRU can select a logical channel for which the RXPSFCH beam is the same as the RX PSFCH beam that has been reserved / scheduled for transmission.

[0352] The WTRU can assign received grants to selected logical channels. The WTRU can transmit PSCCH / PSSCH on the granted resources. The WTRU can use the determined RX PSFCH beam to receive the corresponding PSFCH.

[0353] WTRU can send updated SL-BSRs to the network.

[0354] The gNB may not be aware of the beam used by the WTRU in the SL (e.g., when preparing the SL grant). The SL TX WTRU can decide which destination WTRU to use based on the received SL grant (e.g., to avoid beam collisions). The LCP can be applied to transmissions that take beam and / or other scheduling into account (e.g., when selecting the LC).

[0355] The SL TX WTRU can be configured with resource allocation mode 1 on supported resource pools. The SL TX WTRU can be configured with HARQ feedback. The SL TX WTRU can use beamforming SL transmissions.

[0356] A WTRU can connect to one or more WTRUs within an SL. Each WTRU can be assigned a different LC. WTRUs can transmit SL-BSRs to the gNB. SL BSRs can include one or more destination WTRU IDs. WTRUs can receive SL authorizations from the network. WTRUs can determine the authorized PSSCH resources.

[0357] Potential PSFCH RX beam collision transmissions can be identified.

[0358] The SL TX WTRU can identify a list of WTRU pairs that will cause PSFCH RX beam collisions. This list can include combinations of WTRUs that would lead to PSFCH RX beam collisions (e.g., all WTRU combinations) if they transmit PSFCH to the SL TX WTRU at the same time. Collision pairs can be identified based on two misaligned PSFCH RX beams in the destination WTRU ID. RX beam collision identification is described in this document. Collision pairs can also be identified based on different destination WTRU IDs. For example, a WTRU can avoid PSFCH RX beam collisions by avoiding receiving PSFCH from two or more different WTRUs. This may reduce scheduling flexibility and may avoid additional inter-layer information sharing.

[0359] If the reserved and scheduled transmissions use different RX beam indices, the WTRU can identify potential RX beam conflicts. Similarly, if the RX beams used for the reserved and scheduled transmissions have different TCI states (e.g., different TCI indices or different RSs), the WTRU can identify potential RX beam conflicts.

[0360] If the RX beam is using TX-RX beam correspondence, and the TX beam indices of the reserved and scheduled transmissions are different, the WTRU can identify a potential RX beam conflict. A potential RX beam conflict can also be identified if different indication methods are used to indicate differences in the RX beams between the reserved and scheduled transmissions (e.g., beam index and TCI status). For example, if a first indication type is used to indicate the PSFCH RX beam associated with a reserved PSSCH resource, and a second indication type, different from the first, is used to indicate the PSFCH RX beam associated with a sidelink TB, the WTRU can identify a potential RX beam conflict.

[0361] If the WTRU destination IDs of the reserved and scheduled transmissions are different, the WTRU can identify a potential RX beam conflict. In this case, the WTRU may be able to perform a comparison without beam indication. If the correlation between the RX beams of the reserved and scheduled transmissions is below a (pre-)configured threshold (e.g., based on the WTRU's knowledge of its beams, such as based on applied weights or spatial domain filters used to generate the beams), the WTRU can identify a potential RX beam conflict.

[0362] If signal reception via the PSFCH RX beam associated with reserved PSSCH resources falls below a quality threshold, the WTRU can identify a potential RX beam conflict. For example, if the WTRU estimates that signal reception from the destination WTRU (e.g., using an RX beam configured to receive reserved transmissions) will be of low quality (e.g., RSRP below a threshold), the WTRU can identify a potential RX beam conflict. This estimation can be based on previous measurements (e.g., during beam management).

[0363] WTRUs (e.g., the MAC layer) can receive indications of: WTRU pairs with PSFCH RX beam collisions; and / or (e.g., for each scheduled SL transport utilizing a HARQ-enabled SL TB on that resource pool) the destination WTRU ID of the SL TB, the scheduled PSSCH resources, and / or the associated PSFCH resources. The associated PSFCH resources for scheduled transports can be given (e.g., explicitly) or determined based on reserved PSSCH resources and resource pool configuration.

[0364] The WTRU can determine the PSFCH resources associated with an authorized PSSCH (e.g., based on resource pool configuration). The WTRU can verify (e.g., based on indicated information) whether the PSFCH resources of the authorized PSSCH are concurrent with (e.g., appearing in the same time slot as the PSFCH resources of the already scheduled transport).

[0365] If the PSFCH resource of the authorized PSSCH is different from the PSFCH resource of the already scheduled transport (e.g., it does not appear in the same time slot as the PSFCH resource of the already scheduled transport), LCP can be performed (e.g., similar to legacy behavior).

[0366] If the PSFCH resources of an authorized PSSCH coincide with the PSFCH resources of an already scheduled transmission (e.g., appearing in the same time slot as the already scheduled PSFCH resources), then the LCP is adapted as follows. A subset of LCs can be determined. If the WTRU identifies a potential PSFCH conflict, the WTRU can determine the (e.g., first) destination WTRU ID of the reserved (e.g., already scheduled) PSSCH associated with the PSFCH that coincides with the authorized PSFCH. The WTRU can determine (e.g., for each LC with available SL data for transmission) the destination WTRU ID associated with the LC.

[0367] A WTRU can identify a subset of LCs associated with WTRUs that do not conflict with WTRU IDs already scheduled for transport. For example, a WTRU can identify a set of LCs associated with a second destination WTRU identifier that is different from the first destination WTRU identifier (e.g., associated with reserved PSSCH resources). The WTRU can select LCs from this set of LCs based on the priority associated with the LC. If conflicting WTRU pairs (e.g., directly) are based on having different WTRU IDs, the WTRU can select one or more LCs corresponding to the same destination WTRU ID for a subset of LCs. Destination WTRU IDs can be mapped to multiple LCs (e.g., with different priorities or QoS settings).

[0368] The PSFCH RX beam of the transmission can be given (e.g., explicitly instead of WTRU collision pairs and WTRU destination IDs). WTRU can select one or more LCs for a subset of LCs that correspond to one or more PSFCH RX beams that are aligned with or do not collide with the PSFCH RX beams of the already scheduled transmission.

[0369] Within the determined subset of LCs, WTRU can identify the LC with the highest priority (e.g., based on transmission priority, maximum PDB, and time in the LC queue), such as a non-collision subset of LCs similar to legacy LCPs.

[0370] Authorized PSSCH resources can be allocated to SL data on the highest priority LC with no beam collisions. WTRU can transmit SL data TB on the authorized PSSCH.

[0371] The WTRU can transmit an SL-BSR to the network to indicate an updated buffer state. The updated buffer state can indicate to the network that authorization does not necessarily go to the highest priority LC (e.g., due to beam collision).

[0372] This article provides one or more features associated with LCP-based PSSCH TX beam collision avoidance.

[0373] LCP can be used (e.g., applicable to) to avoid PSSCH TX beam collisions in SL TX WTRUs. This document provides one or more features associated with beamforming transmission collisions. WTRUs cannot be configured on resource pools that support HARQ feedback.

[0374] The SL TX WTRU can identify a list of WTRU pairs that will cause PSSCH TX beam collisions. This list can include WTRU combinations (e.g., all WTRU combinations) that will result in PSSCH TX beam collisions if the SL TX WTRU transmits PSSCH to WTRUs in the pair at the same time. A colliding pair can be identified based on whether the PSSCH TX beams of the two destination WTRUs are not aligned (e.g., using TX beam collision identification as described herein); or whether the destination WTRU IDs are different. If the colliding pair is identified based on the destination WTRU ID, the WTRU can avoid PSSCH TX beam collisions by avoiding transmitting to two different WTRUs at the same time. This may reduce scheduling flexibility and avoid additional inter-layer information sharing.

[0375] WTRU (e.g., MAC layer) can receive indications of the following information: WTRU pairs with PSSCH TX beam collisions; and / or (e.g., for each scheduled SL transmission) the destination WTRU ID of SL TB, and / or the scheduled PSSCH resources.

[0376] A WTRU can be connected to one or more (e.g., multiple) WTRUs in an SL. Each WTRU (e.g., each of the WTRUs) can be assigned a different LC. A WTRU can transmit an SL-BSR to a gNB. An SL-BSR can include one or more (e.g., multiple) destination WTRU IDs.

[0377] The WTRU can receive SL grants from the network. The WTRU can determine the granted PSSCH resource. The WTRU can verify (e.g., based on indicated information) whether the granted PSSCH resource is concurrent with (e.g., appears in the same time slot as the PSSCH resource of a scheduled transmission). If the granted PSSCH resource is not concurrent with (e.g., does not appear in the same time slot as the PSSCH resource of a scheduled transmission), LCP can be performed in a manner similar to legacy behavior.

[0378] If the authorized PSSCH resource is concurrent with the PSSCH resource of an already scheduled transport (e.g., in the same time slot as the PSSCH resource of an already scheduled transport), then LCP can be adapted as described herein.

[0379] Authorized PSSCH resources can be allocated to SL data on the highest priority LC (Limited Space Carrier) that is determined to be free of beam collisions. The WTRU can transmit SL data (TB) on the authorized PSSCH. The WTRU can transmit SL-BSR (e.g., to indicate an updated buffer status) to the network. The SL-BSR can indicate to the network that authorization does not necessarily go to the highest priority LC (e.g., due to beam collisions).

[0380] The LCP-based features described in this paper for SL mode 1 can be similarly applied to SL resource allocation mode 2 (e.g., because LCP is also used to allocate autonomously selected PSSCH resources to LCs). For example, if resource selection is performed without considering beam conflict, one or more LCP-based features can be used.

[0381] In SL resource selection (e.g., Mode 1 SL resource selection), beam information may not be considered on the network side. WTRU can allocate authorized resources to LC via LCP (e.g., based on priority and timing). Beams may not be considered on the LCP side.

[0382] For example, WTRU-assisted scheduling with beam information (e.g., in mode 1) can be used to avoid PSFCH beam collisions.

[0383] The WTRU can send an indication to the network. This indication allows the network to identify beam collisions and perform appropriate scheduling. Scheduling authorization can instruct the WTRU to which the authorization is targeted (e.g., enabling the WTRU's LCP to assign the authorization to the correct WTRU). One or more of the following can be performed.

[0384] A WTRU can transmit to the network indications of beam collisions between (one or more) different WTRUs (e.g., using MAC CE or RRC). For example, a WTRU can send indications of beam collisions associated with two or more other WTRUs (e.g., first and second WTRUs). A WTRU can indicate a first identifier associated with a first WTRU and a second identifier associated with a second WTRU. A WTRU can send WTRU-to-PSFCH RX beam mappings (e.g., beam IDs or TCI states) for connected SL WTRUs. A WTRU can send a list of WTRU pairs that will experience beam collisions.

[0385] WTRUs can transmit SL-BSRs to the network. SL-BSRs can include different WTRU destinations (e.g., WTRU identifiers).

[0386] The WTRU can receive authorization (e.g., SL authorization) for one or more sidelink resources for SL transport (SL mode 1) from the network (e.g., via DCI). The SL authorization may include an indication of a WTRU identifier (e.g., destination WTRU ID) associated with the authorization.

[0387] The WTRU can select a logical channel associated with the identifier indicated in the SL authorization. The WTRU can select the logical channel with the highest priority and available SL data. Alternatively, the WTRU can select a logical channel with available SL data, which has the highest priority and whose destination WTRU ID is the same as the destination WTRU ID indicated in the scheduling authorization.

[0388] The WTRU can transmit sidelink transmissions associated with a selected logical channel on licensed sidelink resources. The WTRU can transmit a TB with a destination WTRU ID (e.g., on licensed PSCCH / PSSCH resources). The WTRU can receive PSFCH transmissions using associated PSFCH RX beams (e.g., PSFCH RX beams associated with licensed sidelink resources).

[0389] Mode 1 resource selection can be performed with the assistance of WTRU beam conflict information.

[0390] Scheduling aided by WTRU with beam information can be used (e.g., in mode 1) to avoid PSFCH beam collisions.

[0391] A WTRU can identify beam collisions between two or more WTRUs. For example, a WTRU can identify a potential RX beam collision if the reserved and scheduled transmissions have different RX beam indices. A WTRU can also identify a potential RX beam collision if the TCI states of the RX beams used for the reserved and scheduled transmissions are different (e.g., different TCI indices or using different RSs).

[0392] If the RX beam is using TX-RX beam mapping and the TX beam indices used for the reserved and scheduled transmissions are different, the WTRU can identify a potential RX beam conflict. A potential RX beam conflict can also be identified if different indication methods are used to indicate differences in the RX beams between the reserved and scheduled transmissions (e.g., beam index and TCI status). For example, if a first indication type is used to indicate the PSFCH RX beam associated with a reserved PSSCH resource, and a second indication type, different from the first, is used to indicate the PSFCH RX beam associated with a sidelink TB, the WTRU can identify a potential RX beam conflict.

[0393] If the WTRU destination IDs of the reserved and scheduled transmissions are different, the WTRU can identify a potential RX beam conflict. In this case, the WTRU may be able to perform a comparison without beam indication. If the correlation between the RX beams of the reserved and scheduled transmissions is below a (pre-)configured threshold (e.g., based on the WTRU's knowledge of its beams, such as based on applied weights or spatial domain filters used to generate the beams), the WTRU can identify a potential RX beam conflict.

[0394] If signal reception via the PSFCH RX beam associated with reserved PSSCH resources falls below a quality threshold, the WTRU can identify a potential RX beam conflict. For example, if the WTRU estimates that signal reception from the destination WTRU (e.g., using an RX beam configured to receive reserved transmissions) will be of low quality (e.g., RSRP below a threshold), the WTRU can identify a potential RX beam conflict. This estimation can be based on previous measurements (e.g., during beam management).

[0395] A WTRU can send an indication to the network. A WTRU can send an indication of a beam conflict associated with two or more WTRUs (e.g., a first WTRU and a second WTRU). The WTRU can indicate a first identifier associated with the first WTRU and a second identifier associated with the second WTRU. This indication allows the network to determine the beam conflict and perform appropriate scheduling. Scheduling authorization can indicate the WTRU to which the authorization is targeted (e.g., enabling the WTRU's LCP to assign the authorization to the correct WTRU). One or more of the following can be performed.

[0396] A WTRU can transmit to the network an indication of beam collisions (one or more) between different WTRUs (e.g., using MAC CE or RRC). A WTRU can send a WTRU-to-PSFCH RX beam map (e.g., beam ID or TCI status) for connected SL WTRUs. A WTRU can send a list of WTRU pairs that will experience beam collisions.

[0397] WTRUs can send SL-BSRs to the network. SL-BSRs may include different WTRU destinations.

[0398] The WTRU can receive authorization (e.g., SL authorization) for sidelink resources from the network (e.g., via DCI) for SL transport (SL mode 1). The SL authorization may include an indication of an identifier associated with the authorization (e.g., destination WTRU ID). For example, the authorization may indicate a first identifier associated with a first WTRU.

[0399] The WTRU can select a logical channel associated with an indicated identifier (e.g., the first identifier in the example above). For instance, a logical channel associated with the first identifier could be associated with first-sidelink data having a first priority level, and a logical channel associated with the second identifier could be associated with second-sidelink data having a second priority level. The WTRU can compare the first priority level with the second priority level. If the first priority level is higher than the second priority level, the WTRU can select the logical channel associated with the first identifier. The WTRU can select the logical channel with available SL data that has the highest priority. The WTRU can select a logical channel with available SL data that has the highest priority and whose destination WTRU ID is the same as the destination WTRUID indicated in the scheduling authorization.

[0400] A WTRU can transmit sidelink transmissions associated with a selected logical channel on licensed sidelink resources. For example, a WTRU can transmit a TB with a destination WTRU ID (e.g., on licensed PSCCH / PSSCH resources). A WTRU can receive PSFCH transmissions using an associated PSFCH RX beam / can receive PSFCH transmissions with an associated PSFCH RX beam.

[0401] The WTRU can send beam collision information to the network (e.g., enabling the network to perform beam-aware resource allocation). The WTRU can receive authorization. This authorization may include WTRU / beam indication (e.g., enabling the WTRU to map the authorization to the intended WTRU destination / beam).

[0402] The features described herein may be "forward-looking" versions of other features described herein.

[0403] The SL TX WTRU can be configured with resource allocation mode 1 on a resource pool that supports and is configured with HARQ feedback. The SLTX WTRU can use beamforming SL transmission.

[0404] Beam collision indications can be transmitted. WTRUs can be (pre-)configured to report indications of potential scheduling collisions to the network (e.g., indicating potential PSSCH TX beam collisions and / or PSFCH RX beam collisions). The network can use the collision information to schedule resources to SL TX WTRUs in Mode 1 (e.g., based on already scheduled transmissions and SL-BSR information).

[0405] The WTRU can send an indication to the network of beam collisions for WTRUs connected to it (e.g., at least for WTRUs associated with the LC or those indicated in the SL-BSR). This indication can be sent using a MAC CE message (e.g., a new MAC CE message) or an RRC. The indication can be for PSFCH RX beam collisions and / or for PSSCH TX beam collisions.

[0406] This indication can be a list of WTRU pairs with beam collisions (e.g., determined as described herein). The gNB can use the WTRU ID and WTRU pair collision indication from the SL-BSR to avoid simultaneous transmission of PSSCH, or to avoid scheduling PSSCHs that would result in PSFCH RX beam collisions. The gNB can determine the PSFCH corresponding to the transmission based on the resource pool configuration.

[0407] This indication can be updated if the list of conflicting pairs is updated (e.g., after a beam association change between the SL TX WTRU and the destination WTRU). The update can be incremental (e.g., indicating only conflicting pairs to be added and / or removed).

[0408] WTRUs can send SL-BSRs to the network. An SL-BSR may include one or more destination WTRU IDs, the corresponding Logical Channel Group (LCG) ID, and / or their corresponding buffer sizes.

[0409] The destination WTRU ID's LC can be regrouped into (e.g., a single) LCG (e.g., there can be a one-to-one mapping between WTRU ID and LCGID, and this information can be used interchangeably).

[0410] The WTRU can receive authorizations with indications and LCP mappings. The WTRU can receive authorizations from the network (e.g., using DCI). This authorization may include reserved resources. The authorization may include an indication of the corresponding LCG ID or destination WTRU ID. The indications in the authorization enable the network to associate the authorization with the destination. This allows the WTRU to follow network scheduling.

[0411] The WTRU can read the LCG or WTRU ID corresponding to the received authorization. The WTRU can indicate the authorized resource and the corresponding WTRU ID or LCG ID to the LCP.

[0412] The LCP procedure can determine a subset of LCs corresponding to the WTRU ID / LCG ID indicated in the received authorization. For example, a WTRU can determine a group of WTRUs compatible with a second WTRU based on the indication of a first identifier in the authorization. The WTRU can determine a logical channel group associated with that group of WTRUs. The WTRU can then select a logical channel from that logical channel group. The LCP can then proceed to select the LC with the highest priority in terms of SL data priority and timing considerations (e.g., from a subset of LCs) (e.g., similar to legacy LCP, but based on a subset of the determined LCs).

[0413] WTRU can transmit the determined LC SL data on authorized PSSCH resources.

[0414] Explicit beam indication can be used. The WTRU sends an explicit beam collision indication (e.g., instead of WTRU collision information). In this case, LCP can be adapted to give the WTRU greater flexibility to assign any WTRU that matches the beam (e.g., instead of a single WTRU).

[0415] This indication can be a mapping between the WTRU ID and the associated RX beam (and / or associated TX beam). The gNB can resolve conflicts by not scheduling transmissions that will simultaneously use (e.g., require) different TX beams (e.g., TX PSSCH) or RX beams (e.g., PSFCH RX) (e.g., based on the WTRU ID and PSFCH configuration of the resource pool in the SL-BSR).

[0416] This indication can be a mapping between the WTRU ID and the associated RX beam (and / or associated TX beam), as well as a list of conflicting beam pairs. Conflicting beam pairs can be determined by the WTRU (e.g., as described herein). One or more indications (e.g., two indications) can be sent or updated (e.g., separately, for example, in separate MAC CE / RRC indications). Beam pair conflicts can be updated if the beam's spatial filter changes (e.g., only if the beam's spatial filter changes). The association of the WTRU with the beam can change independently. The gNB can resolve beam conflicts (e.g., RX or TX beam conflicts) by avoiding the selection of transmissions from the beam pair that use (e.g., require) conflicting beams. This indication can be a list of compatible beam pairs (e.g., beams that do not conflict with each other). The list of compatible beam pairs can be shorter than the list of conflicting beam pairs (e.g., if the beams are configured to be (quasi)orthogonal to each other).

[0417] The SL-BSR (e.g., as an enhanced SL-BSR format) can be used to (e.g., jointly) indicate the mapping from WTRU to beams. The enhanced SL-BSR format may include (e.g., for each LCG): WTRU ID, LCG ID, PSSCH TX beam, and / or PSFCH RX beam.

[0418] The WTRU can transmit SL-BSR to the network. The WTRU can receive SL licenses (e.g., using DCI). The DCI can include licensed resources and (one or more) PSSCH TX and / or PSFCH RX beam indications.

[0419] WTRU can determine (e.g., based on the beam configured for each WTRU) a list of WTRUs that are compatible with the beams indicated in the authorization (e.g., WTRUs configured with the same or non-conflicting beams).

[0420] The LCP can use an appropriate list of WTRUs to indicate authorization. The LCP can subselect the LC associated with the appropriate WTRU. The LCP can select the highest priority LC from a subset of LCs. The WTRU can transmit the SL data of the designated LC on the authorized PSSCH resource.

[0421] In SL resource selection (e.g., Mode 2 SL resource selection), sensing can be performed without beamforming. Candidate resources in the resource selection window may not be evaluated relative to the transmitted TX beam.

[0422] WTRU TX beam-specific resource selection can be based on sensing information. Sensing information can be obtained during sensing when the RX beam corresponding to the TX beam is used.

[0423] SL sensing can be performed using beamforming. Candidate resources in the resource selection window can be based on the TX beam and / or sensing information corresponding to the TX beam. One or more of the following can be performed.

[0424] The WTRU can perform SL sensing within a sensing window (e.g., each sensing window). The WTRU can perform SL sensing using associated RX beams within the sensing window. For example, the WTRU can determine first sidelink sensing information associated with a first sensing window (e.g., based on a first transmission received via a first receive (RX) beam). The WTRU can determine second sidelink sensing information associated with a second sensing window (e.g., based on a second transmission received via a second RX beam). The association between RX beams and sensing windows can be based on (pre)configuration. The association between RX beams and sensing windows can be based on the number of unicast links using RX beams.

[0425] SL sensing information can be obtained from sensing time slots (e.g., each sensing time slot). SL sensing information may include resource reservation information, measured RSRP and / or RX beam information (e.g., RX beam indication and / or pre-configured RX beam RSRP offset).

[0426] The WTRU can perform resource selection for PSCCH / PSSCH transmissions. The WTRU can perform resource selection for PSCCH / PSSCH transmissions within a resource selection window. The WTRU can use the TX beam associated with the unicast transmission to the peer WTRU to perform resource selection for PSCCH / PSSCH transmissions (e.g., based on SL sensing information).

[0427] The WTRU can receive sidelink transport blocks associated with the transmit (TX) beam. The WTRU can determine a sensing timing within a sensing window corresponding to the TX beam associated with a (e.g., unicast) transmission to a peer WTRU. The sensing timing can use an RX beam corresponding to the TX beam (e.g., based on beam correspondence). For example, the WTRU can determine a first RX beam and a first sensing timing associated with the TX beam.

[0428] The WTRU can determine a set of candidate resources (e.g., all candidate resources included in the determined (one or more) (first) sensing time). If the number of determined candidate resources is less than a (pre)configured threshold, the WTRU can indicate to the MAC layer that resource selection has failed.

[0429] The WTRU can identify one or more available candidate resources within a defined candidate resource set (e.g., based on sidelink sensing information and a threshold). For example, the WTRU can identify one or more available candidate resources within the defined candidate resource set based on one or more of the following: a measured RSRP adjusted by a pre-configured RX beam RSRP offset; and / or a (pre-)configured RSRP threshold.

[0430] WTRU can transmit sidelink transport blocks (e.g., PSCCH / PSSCH) from identified available candidate resources (e.g., using the TX beam associated with the unicast link).

[0431] For example, WTRU TX beam-specific resource selection can be performed based on sensing information obtained when using the RX beam corresponding to the TX beam.

[0432] In SL resource selection (e.g., Mode 2 SL resource selection), sensing can be performed without beamforming. Candidate resources in the resource selection window may not be evaluated relative to the transmitted TX beam.

[0433] WTRU TX beam-specific resource selection can be based on sensing information. Sensing information can be obtained during sensing times when the corresponding RX beam is used. For example, the WTRU can be (pre-)configured with a sensing RX beam-to-TX beam mapping. The WTRU can determine the first RX beam and the first sensing time associated with the TX beam based on the sensing RX beam-to-TX beam mapping.

[0434] SL sensing can be performed using beamforming. Candidate resources in the resource selection window can be based on the TX beam and / or sensing information corresponding to the TX beam. One or more of the following can be performed.

[0435] The WTRU can perform SL sensing within a sensing window (e.g., each sensing window). The WTRU can perform SL sensing using associated RX beams within the sensing window. For example, the WTRU can determine first side-link sensing information associated with a first sensing window (e.g., based on a first transmission received via a first RX beam). The WTRU can determine second side-link sensing information associated with a second sensing window (e.g., based on a second transmission received via a second RX beam). The association between RX beams and sensing windows can be based on (pre)configuration. The association between RX beams and sensing windows can be based on the number of unicast links using RX beams.

[0436] SL sensing information can be obtained from sensing time slots (e.g., each sensing time slot). SL sensing information may include resource reservation information, measured RSRP and / or RX beam information (e.g., RX beam indication and / or pre-configured RX beam RSRP offset).

[0437] The WTRU can perform resource selection for PSCCH / PSSCH transmissions. The WTRU can perform resource selection for PSCCH / PSSCH transmissions within a resource selection window. The WTRU can use the TX beam associated with the unicast transmission to the peer WTRU to perform resource selection for PSCCH / PSSCH transmissions (e.g., based on SL sensing information).

[0438] The WTRU can determine the sensing timing within a sensing window that corresponds to the TX beam associated with a unicast transmission to the peer WTRU. The sensing timing can use the RX beam corresponding to the TX beam (e.g., based on beam correspondence).

[0439] The WTRU can determine a set of candidate resources (e.g., including all candidate resources at the determined sensing time). If the number of determined candidate resources is less than a (pre)configured threshold, the WTRU can indicate to the MAC layer that resource selection has failed.

[0440] The WTRU can identify one or more available candidate resources within a defined candidate resource set. For example, the WTRU can identify one or more available candidate resources within the defined candidate resource set based on one or more of the following: a measured RSRP adjusted by a pre-configured RX beam RSRP offset; and / or a (pre-)configured RSRP threshold.

[0441] WTRU can transmit PSCCH / PSSCH from identified available candidate resources (e.g., using the TX beam associated with a unicast link).

[0442] Directional mode 2 SL sensing can be based on sensing the RX beam.

[0443] The WTRU can perform mode 2 sensing to acquire SL sensing information for resource selection. In SL FR1 operation, the WTRU can apply an omnidirectional sensing RX beam to perform mode 2 sensing. The WTRU may be able to receive PSCCH(s)(s) arriving from different directions of inflow. In SL FR2 operation (e.g., to improve link performance), the WTRU can apply a directional sensing RX beam to PSCCH reception (e.g., to achieve beamforming gain). The beamwidth and orientation of the sensing RX beam can be based on the receive spatial domain filter used for mode 2 sensing. The orientation of the RX beam can represent the spatial direction in which the maximum gain of the RX beam exists.

[0444] The WTRU can (e.g., in directional mode 2 sensing) receive PSCCHs from PSCCH candidate resources (e.g., each PSCCH candidate resource) at sensing times within the sensing window. The WTRU can perform PSCCH reception using the sensing RX beam at each sensing time (e.g., each sensing time). If a PSCCH is detected (e.g., a successful PSCCH CRC check), the WTRU can decode the PSCCH. The WTRU can acquire SL control information (SCI). The SCI may include resource reservation information. The WTRU can measure the DMRS associated with the decoded PSCCH and / or associated PSSCH in the same transmission. The WTRU can acquire the sensing RSRP value associated with the decoded SCI and the transmission time (e.g., each decoded SCI and sensing time).

[0445] This document provides one or more features associated with the sensing configuration. To perform directional Mode 2 sensing, a WTRU can be (pre-)configured in a resource pool using one or more of the following Mode 2 sensing configuration information. The WTRU can be (pre-)configured with sensing timing. Sensing timing can be a time slot, one or more symbols within a time slot, a subframe in the resource pool, and / or the like. The WTRU can be (pre-)configured with PSCCH candidate resources. PSCCH candidate resources can include time and frequency resource allocations for PSCCH transmission and / or reception. PSCCH time resources can include the first N symbols in a time slot (e.g., where the value of N can be (pre-)configured). Frequency resources can be one or more RBs and / or subcarriers in a subchannel within the resource pool. One or more RBs and / or subcarriers can be one or more RBs and / or subcarriers in a subchannel with the lowest RB and / or (one or more) subcarrier index. The WTRU can be (pre-)configured with a sensing window. Sensing window (pre-)configuration can include the duration (e.g., length) of the window (e.g., in milliseconds and / or time slots in the resource pool).

[0446] The sensing RX beam can be determined. The WTRU can determine the sensing RX beam associated with a sensing timing within a sensing window (e.g., each sensing timing). For example, the WTRU can determine the sensing RX beam based on a (pre)configured sensing RX beam. The WTRU can be (pre)configured with periodic sensing RX beams for use in time slots within a resource pool (e.g., each time slot). The periodic sensing RX beam (pre)configuration can include a set (one or more) of RX beam indicators. The WTRU can apply the indicated RX beams according to the ordered sequence of the (one or more) RX beam indicators. RX beam indicators can include RX beam indices, RX beam SL TCI states, and / or more.

[0447] The WTRU can determine the sensing RX beam based on the PSSCH RX beam to be used during sensing. The WTRU can use the sensing RX beam based on the PSSCH RX beam to be used during sensing. The WTRU can use a sensing RX beam that covers the PSSCH receiving RX beam to be used during sensing. The sensing RX beam can be the PSSCH RX beam (e.g., it can be the same as it) (e.g., having the same RX beam index and / or SL TCI state). If the PSSCH RX beam will not be used during sensing, the WTRU can apply the sensing RX beam based on the (pre)configured sensing RX beam.

[0448] The WTRU may determine the PSSCH RX beam for sensing timing based on one or more of the following: the PSSCH RX beam associated with the SL; the semi-persistent scheduling information received by the PSSCH of the SL; the number of SLs in operation; the service mode of the SL; and / or the resource selection status.

[0449] A WTRU can operate multiple SLs (e.g., broadcast, multicast, and / or unicast SLs). SLs (e.g., each SL) can be identified by a WTRU destination ID (e.g., for a broadcast or multicast SL) or a pair of WTRU source and destination IDs (e.g., for a unicast SL). The WTRU can perform SL beamp pairing (e.g., to determine the PSSCH TX and / or PSSCH RX beams associated with the SL, such as the PSSCH TX and / or PSSCH RX beams associated with the WTRU destination and / or source IDs).

[0450] The WTRU can determine the PSSCH RX beam used for a time slot (e.g., per time slot) based on the number of service slots (SLs) and / or traffic patterns of the operation. For example, the WTRU can allocate a set of time slots in the resource pool to the SLs of an operation (e.g., SLs for each operation). The WTRU can determine the PSSCH RX beam associated with the SL to use in a set of time slots (e.g., per set of time slots). For example, the WTRU can determine the number of time slots in a set (e.g., per set) based on the traffic of the SL. If the WTRU operates (e.g., one) an SL, the WTRU can use the same PSSCH RX beam in the time slots (e.g., all time slots) of the resource pool.

[0451] A WTRU can determine one or more RX beams based on one or more destination WTRU identifiers associated with one or more peer WTRUs. For example, if a time slot is reserved for semi-persistent PSSCH reception of an SL identified by a WTRU destination and / or source ID, the WTRU can determine to use a PSSCH RX beam associated with the WTRU destination ID or a pair of WTRU destination and source IDs.

[0452] If the indicated resource selection associated with the TX beam fails, the WTRU can determine to perform sensing using the sensing RX beam paired with the TX beam in a (pre)configured cycle. This can increase the number of candidate resources specific to the TX beam used for resource selection.

[0453] Directional sensing information can be correlated with the sensing RX beam.

[0454] The WTRU can acquire SL sensing information at sensing times specific to the sensing RX beam used at the sensing time (e.g., each sensing time). The WTRU can acquire SL sensing information based on received sidelink control transmissions (e.g., decoded SCIs, such as those from PSCCHs received at the sensing time). The WTRU can determine direction mode 2 sensing information for resources at each sensing time (e.g., each sensing time). Transmitted information may include one or more of the following: resource reservation information from decoded SCIs in the PSCCH (e.g., resource reservations may indicate time and / or frequency resources reserved for one or more future SL transmissions); associated measured PSCCH and / or PSSCH RSRPs; associated sensing RX beam information (e.g., RX beam index and / or RX beam TCI status of the sensing RX beam); and / or TX power information associated with resource reservations. The WTRU can determine the power level (e.g., based on the TX power indicated in the decoded SCI) for transmissions in one or more reserved resources.

[0455] TX beam-specific resource selection can be based on directional mode 2 SL sensing information.

[0456] The WTRU can receive sidelink transport blocks (TBs) associated with a TX beam. If an SL TB arrives at the WTRU buffer, the WTRU can perform TX beam-specific resource selection to determine the resources used to transmit the SL TB. The WTRU can determine the TX beam associated with the SL TB (e.g., and the TX beam used to transmit the SL TB). For example, the WTRU can determine the TX beam associated with the SL TB based on one or more of the following: the WTRU destination and / or source ID of the SL TB; and / or indications (e.g., from a higher layer, such as from the RRC and / or MAC layer).

[0457] The WTRU can determine the TX beam (e.g., the SL TCI status and / or TX beam index of the TX beam associated with the SL TB). For example, the WTRU can determine the TX beam based on the association between the TX beam and the WTRU destination and / or source ID of the SL TB. If this association is maintained by the WTRU's MAC layer and / or RRC, the TX beam can be instructed to the PHY layer to perform resource selection.

[0458] Resource selection can be based on sensing information from a set of candidate resources applicable to the TX beam. Figure 9 The illustration shows an example of using sensing information during resource selection.

[0459] In TX beam-specific resource selection, the WTRU can select one or more resources from candidate resources at a sensing opportunity associated with the RX beam corresponding to the TX beam. The WTRU can determine the sensing window (e.g., based on a (pre)configured sensing window and whether periodic reservation is enabled in the resource pool). For example, if the sensing opportunity is a 1-millisecond time slot (e.g., a 15 kHz SCS) and the sensing window is 1000 milliseconds (e.g., for a periodically reserved resource pool), the WTRU can determine 1000 sensing opportunities.

[0460] This document provides one or more features associated with a candidate resource set. The candidate resource set may include resources associated with the sensing timing of the RX beam paired with the TX beam.

[0461] Within the sensing window, the WTRU can determine a subset of sensing moments associated with the sensing RX beam (e.g., a first sensing moment, a second sensing moment, a third sensing moment, etc.), which is paired with the TX beam intended for use in resource selection by the SL TB. For example, the WTRU can determine that a first RX beam and a first sensing moment are associated with a TX beam. The WTRU can then determine a set of candidate resources associated with the first sensing moment.

[0462] The WTRU can determine the sensed RX beam paired with the TX beam (e.g., based on beam correspondence and / or (pre)configuration). If beam correspondence exists (e.g., the same spatial domain filter used for the TX beam can be applied to the RX beam), the SL TCI state of the RX beam can be the TX beam index, or the RX beam index can be the same as the TX beam index. The TX beam and RX beam can be paired in the (pre)configuration.

[0463] In resource selection, the WTRU can estimate interference caused by transmissions (e.g., using the TX beam in the selected resource based on the RSRP measured using the RX beam). Gain differences between the TX and RX beams can introduce errors in interference estimation. For each pair of paired TX and RX beams, the WTRU can be (pre-)configured with an RSRP offset (e.g., RX beam RSRP offset). If the RX and TX beams apply the same (e.g., the same) spatial domain filter, the RSRP adjustment offset can be zero. If the RX beam covers the paired TX beam (e.g., but with a wider bandwidth), the RSRP adjustment offset can be determined based on the calibration of the gain difference between the TX and RX beams. The WTRU can adjust the measured RSRP using the RX beam RSRP offset. The WTRU can select candidate resources based on the adjusted RSRP meeting a signal quality threshold (e.g., below a signal quality threshold).

[0464] The WTRU can determine the TX transmit power associated with resource reservation (e.g., the TX power level indicated in the SCI). The WTRU can determine the RSRP offset based on the indicated TX power and the gain of the sensed RX beam (e.g., this can provide an estimate of path loss and potential interference).

[0465] The WTRU can determine the RSRP offset based on measurements previously performed on the WTRU that made resource reservations. For example, the WTRU can determine the WTRU that made resource reservations based on the WTRU source and / or destination ID indicated in the SCI (e.g., including resource reservation information). This measurement may include CSI, L1-RSRP, RSRP, and / or RSSI measurements.

[0466] The WTRU can determine a candidate resource set. The candidate resource set can include one or more resources of sensing times within a subset of sensing times(s) associated with a sensing RX beam, which is paired with a TX beam associated with the SL TB intended for resource selection. The WTRU can determine a candidate resource set of resources for sensing times included within a sensing window (e.g., all sensing times). If a sensing time is associated with a sensing RX beam that is not paired with a TX beam associated with the SL TB intended for resource selection, the WTRU can exclude that sensing time from the candidate resource set.

[0467] If the number of candidate resources is below a (pre)configured threshold, the WTRU can indicate resource selection failure (e.g., to the MAC layer). For example, the WTRU can receive a second sidelink transport block associated with a second TX beam. The WTRU can determine that a second RX beam and a second sensing timing are associated with the second TX beam. The WTRU can determine a second set of candidate resources associated with the second sensing timing. The WTRU can determine that the number of candidate resources in the second set is below a minimum resource threshold. Based on the fact that the number of candidate resources in the second set is below the minimum resource threshold, the WTRU can transmit an indication of resource selection failure.

[0468] Resource selection failure can indicate that TX-beam-specific sensing information may be insufficient (e.g., due to TX and RX beam conflict). At one or more sensing times, the sensing RX beam used may not be paired with the TX beam. The WTRU can reassociate the RX sensing beam to the sensing time (e.g., increasing the number of TX-beam-specific candidate resources for another resource selection within the same TB).

[0469] The threshold can be the ratio of the number of sensing opportunities in the candidate resource set to the total number of sensing opportunities within the sensing window. In Mode 2 resource selection, the WTRU can select (e.g., randomly select) one or more resources from the candidate resource set to avoid collisions. If the number of candidate resources is low, the probability of collisions may become higher.

[0470] The WTRU can perform resource selection based on a candidate resource set specific to the TX beam. The WTRU can also perform mode 2 resource selection based on the candidate resource set. The WTRU can determine one or more available candidate resources for transmitting the SL TB (e.g., using the associated TX beam). If one or more candidate resources are reserved by another WTRU (e.g., based on resource reservation information included in the SCI decoded at the sensing time), the WTRU can exclude one or more candidate resources corresponding to that sensing time from the resource selection.

[0471] If the adjusted associated PSCCH and / or PSSCH RSRP measurements exceed a (pre)configured threshold, the WTRU can exclude one or more candidate resources corresponding to the sensing timing from resource selection. The WTRU can adjust the RSRP values ​​based on a (pre)configured RSRP offset (e.g., a (pre)configured RSRP offset associated with a pair of RX beams associated with the sensing timing and TX beams associated with the SL TB intended for resource selection). The threshold can be based on priority information (e.g., included in the SCI decoded during the sensing timing and the priority of the SL TB intended for resource selection).

[0472] The WTRU can select (e.g., randomly select) one or more available candidate resources from the remaining candidate resources in the candidate resource set for use in transmitting SL TB.

[0473] WTRU can perform resource selection within a subset of candidate resources (e.g., where each candidate resource is associated with a different TX beam).

[0474] The WTRU can determine the number of candidate resource subsets. Each candidate resource subset (e.g., each candidate resource subset) can include candidate resources for sensing times associated with different sensing RX beams used at the sensing time. The WTRU can perform resource selection based on candidate resource subsets (e.g., each candidate resource subset). The WTRU can determine one or more available candidate resources (e.g., in each candidate resource set). The WTRU can determine which(s) of the available candidate resources can be applied to the SL TB (e.g., if the TX beam associated with the SL TB can be paired with the RX sensing beam used for the available candidate resources).

[0475] If the TX beam associated with the SL TB may not pair with the RX sensing beam (e.g., any RX sensing beam) used for available candidate resources, then none of the available candidate resources can be used for SL TB transmission. In this case, the WTRU may (e.g., to the MAC layer) indicate a resource selection failure (e.g., due to TX and RX beam conflict). In this case, there may be no TX beam-specific sensing information (e.g., any sensing information).

[0476] WTRU can perform resource reassessment or preemption using a specific TX beam.

[0477] The WTRU can perform mode 2 resource re-evaluation or preemption on already scheduled resources. The MAC layer can provide a set of resources for re-evaluation. The WTRU (e.g., the PHY layer) can perform resource selection to find candidate resources. Resource selection for re-evaluation or preemption may involve the resources to be examined and the associated TX beam.

[0478] If a subset(s) of candidate resources based on directional sensing is obtained during resource allocation, the WTRU can verify that the indicated resources exist within a subset of available resources for their corresponding TX beams. If the indicated resources do not exist, the PHY layer can report to the MAC layer a re-evaluation or preemption of the corresponding resources and their associated TX beams. This report can trigger resource reselection.

[0479] WTRU can perform SL sensing in sensing moments (e.g., per sensing moment) using the sensing RX beams associated in the sensing window. The association between the sensing RX beams and sensing moments can be based on (pre)configured or the number of unicast links using the RX beams.

[0480] SL sensing information can be obtained from each sensing opportunity. SL sensing information may include resource reservation information, measured RSRP, RX beam information (e.g., RX beam indication and / or (pre)configured RX beam RSRP offset), and / or the like.

[0481] The WTRU can perform resource selection for PSCCH / PSSCH transmissions within a resource selection window based on SL sensing information (e.g., using the TX beam associated with the unicast transmission to the peer WTRU).

[0482] The WTRU can determine the sensing timing within a sensing window corresponding to a TX beam associated with a unicast transmission to the peer WTRU. For example, the WTRU can determine the sensing timing using an RX beam that can correspond to the TX beam, based on beam correspondence and / or (pre)configuration.

[0483] The WTRU can determine a set of candidate sensing resources, including candidate resources (e.g., all candidate resources), at a given sensing time. If the number of determined candidate sensing resources is less than a (pre)configured threshold, the WTRU can indicate to the MAC layer that resource selection has failed.

[0484] The WTRU can identify one or more available candidate resources within a defined candidate resource set. For example, the WTRU can identify one or more available candidate resources within a defined candidate resource set based on the measured RSRP adjusted by a pre-configured RX beam RSRP offset and / or (pre-)configured RSRP threshold.

[0485] WTRU can transmit PSCCH / PSSCH from the identified available candidate resources (e.g., using the TX beam associated with the unicast link).

[0486] Although the above features and elements are described in specific combinations, each feature or element may be used alone without other features and elements of the preferred embodiment, or in various combinations with or without other features and elements.

[0487] While the implementations described in this paper can take into account 3GPP-specific protocols, it should be understood that the implementations described herein are not limited to this scenario and can be applied to other wireless systems. For example, although the solutions described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this scenario and can also be applied to other wireless systems.

[0488] The above processes can be implemented in computer programs, software, and / or firmware incorporated in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as compact disc (CD)-ROMs and / or digital versatile discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver used in WTRUs, terminals, base stations, RNCs, and / or any host computer.

[0489] It should be understood that the entity performing the processes described herein can be a logical entity, which can be implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a mobile device, network node, or computer system and executed on the processor of that mobile device, network node, or computer system. That is, the processes can be implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a mobile device and / or network node (such as a node or computer system), which executes the processes in discussion when executed by the node's processor. It should also be understood that any transmit and receive processes illustrated in the figures can be executed by the node's communication circuitry under the control of the node's processor and the computer-executable instructions (e.g., software) it executes.

[0490] The various techniques described herein can be implemented in combination with hardware or software, or, where appropriate, with a combination of both. Therefore, implementation schemes and apparatuses of the subject matter described herein, or certain aspects or portions thereof, can take the form of program code (e.g., instructions) embodied in a tangible medium, including any other machine-readable storage medium, wherein when the program code is loaded into and executed by a machine such as a computer, the machine becomes an apparatus for practicing the subject matter described herein. In the case where the program code is stored on a medium, it may be that the program code in question is stored on one or more media that collectively perform the actions in question; that is, one or more media together contain the code for performing the actions. However, in the case of more than one single medium, it is not required that any particular portion of the code be stored on any particular medium. In the case of program code executed on a programmable device, the computing device typically includes a processor, processor-readable storage media (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. One or more programs can be implemented, for example, by using APIs, reusable controls, etc., or utilize the processes described in connection with the subject matter described herein. Such programs are preferably implemented in a high-level program or an object-oriented programming language to communicate with a computer system. However, if needed, one or more programs can be implemented in assembly language or machine language. In any case, the language can be a compiled language or an interpreted language, and it must be combined with a hardware implementation scheme.

[0491] While the exemplary embodiments may relate to utilizing aspects of the subject matter described herein within the context of one or more independent computing systems, the subject matter described herein is not limited thereto, but can be implemented in any computing environment, such as a network or distributed computing environment. Furthermore, aspects of the subject matter described herein may be implemented in or across multiple processing chips or devices, and storage devices may similarly be affected across multiple devices. Such devices may include personal computers, web servers, handheld devices, supercomputers, or computers integrated into other systems, such as automobiles and aircraft.

[0492] In describing preferred embodiments of the subject matter of this disclosure, as illustrated in the figures, specific terminology is used for clarity. However, the claimed subject matter is not intended to be limited to the specific terminology thus chosen, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

Claims

1. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: The processor is configured as follows: The system receives information indicating the first physical sidelink feedback channel (PSFCH) receive (RX) beam associated with the sidelink transport block (TB) and reserved physical sidelink shared channel (PSSCH) resources, wherein the reserved PSSCH resources are associated with the second PSFCH RX beam and PSFCH timing. A beam conflict is identified between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the side link TB. Based on the determination that there is a beam conflict between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the sidelink TB: Determine the candidate PSSCH resources in the sidelink resource pool and associate them with the PSFCH timing, and A PSSCH resource set is determined in the sidelink resource pool, wherein candidate PSSCH resources are excluded from the PSSCH resource set. Select PSSCH resources from the PSSCH resource set; and Transmit PSSCH transmissions associated with the sidelink TB in the PSSCH resource.

2. The WTRU according to claim 1, wherein, The processor is configured to determine that the beam conflict exists between a second PSFCH RX beam associated with the reserved PSSCH resource and a first PSFCH RX beam associated with the sidelink TB, including: the processor is configured to determine that there is a difference between a first sidelink Transmission Configuration Indicator (TCI) state and a second sidelink TCI state, the first sidelink Transmission Configuration Indicator (TCI) state being associated with the first PSFCH RX beam associated with the sidelink TB and the second sidelink TCI state being associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

3. The WTRU according to claim 1, wherein, The processor is configured to determine that the beam conflict exists between a second PSFCH RX beam associated with the reserved PSSCH resource and a first PSFCH RX beam associated with the sidelink TB, including: the processor is configured to determine that there is a difference between a first beam index and a second beam index, the first beam index being associated with the first PSFCH RX beam associated with the sidelink TB and the second beam index being associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

4. The WTRU according to claim 1, wherein, The processor is configured to determine that the beam conflict exists between a second PSFCH RX beam associated with the reserved PSSCH resource and a first PSFCH RX beam associated with the sidelink TB, including: the processor is configured to determine that a first destination WTRU identifier is different from a second destination WTRU identifier, the first destination WTRU identifier being associated with the first PSFCH RX beam associated with the sidelink TB, and the second destination WTRU identifier being associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

5. The WTRU according to claim 1, wherein, The processor is configured to determine that the beam conflict exists between a second PSFCH RX beam associated with the reserved PSSCH resource and a first PSFCH RX beam associated with the sidelink TB, including: the processor is configured to determine that the correlation between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the sidelink TB is below a threshold.

6. The WTRU according to claim 1, wherein, The information further indicates a second PSFCH RX beam associated with the reserved PSSCH resource, and the processor is configured to determine that the beam conflict between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the sidelink TB includes: the processor is configured to determine that a first indication type for indicating the first PSFCH RX beam associated with the sidelink TB is different from a second indication type for indicating the second PSFCH RX beam associated with the reserved PSSCH resource.

7. The WTRU according to claim 1, wherein, The processor is configured to determine that the beam conflict exists between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the sidelink TB, including that the processor is configured to determine that signal reception via the second PSFCH RX beam associated with the reserved PSSCH resource is below a quality threshold.

8. The WTRU according to any one of claims 1 to 7, wherein, The information is first information, and the processor is further configured to receive second information indicating a set of sidelink resource pools, and the first information further indicates sidelink resource pools from the set of sidelink resource pools, and to determine the PSSCH resource set from the sidelink resource pools.

9. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: The system receives information indicating the first physical sidelink feedback channel (PSFCH) receive (RX) beam associated with the sidelink transport block (TB) and reserved physical sidelink shared channel (PSSCH) resources, wherein the reserved PSSCH resources are associated with the second PSFCH RX beam and PSFCH timing. A beam conflict is identified between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the side link TB. Based on the determination that there is a beam conflict between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the sidelink TB: Determine the candidate PSSCH resources in the sidelink resource pool and associate them with the PSFCH timing, and A PSSCH resource set is determined in the sidelink resource pool, wherein candidate PSSCH resources are excluded from the PSSCH resource set. Select PSSCH resources from the PSSCH resource set; and Transmit PSSCH transmissions associated with the sidelink TB in the PSSCH resource.

10. The method according to claim 9, wherein, Determining that a beam conflict exists between a second PSFCH RX beam associated with a first reserved PSSCH resource and a PSFCH RX beam associated with the sidelink TB includes: determining that there is a difference between a first sidelink Transmission Configuration Indicator (TCI) state and a second sidelink TCI state, the first sidelink Transmission Configuration Indicator (TCI) state being associated with a first PSFCH RX beam associated with the sidelink TB and the second sidelink TCI state being associated with a second PSFCH RX beam associated with the reserved PSSCH resource.

11. The method according to claim 9, wherein, Determining that there is a beam conflict between a second PSFCH RX beam associated with a first reserved PSSCH resource and a PSFCH RX beam associated with the sidelink TB includes: determining that there is a difference between a first beam index and a second beam index, the first beam index being associated with a first PSFCH RX beam associated with the sidelink TB and the second beam index being associated with a second PSFCH RX beam associated with the reserved PSSCH resource.

12. The method according to claim 9, wherein, Determining the beam conflict between a second PSFCH RX beam associated with a first reserved PSSCH resource and a PSFCH RX beam associated with the sidelink TB includes: determining that a first destination WTRU identifier is different from a second destination WTRU identifier, wherein the first destination WTRU identifier is associated with a first PSFCH RX beam associated with the sidelink TB, and the second destination WTRU identifier is associated with a second PSFCH RX beam associated with the reserved PSSCH resource.

13. The method according to claim 9, wherein, Determining that there is a beam conflict between a second PSFCH RX beam associated with a first reserved PSSCH resource and a PSFCH RX beam associated with the side link TB includes determining that the correlation between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the side link TB is below a threshold.

14. The method according to claim 9, wherein, The information further indicates a second PSFCH RX beam associated with the reserved PSSCH resource, and determining that there is a beam conflict between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the side link TB includes: determining that a first indication type for indicating the first PSFCH RX beam associated with the side link TB is different from a second indication type for indicating the second PSFCH RX beam associated with the reserved PSSCH resource.

15. The method according to claim 9, wherein, Determining that there is a beam conflict between the second PSFCH RX beam associated with the reserved PSSCH resource and the first PSFCH RX beam associated with the side link TB includes determining that signal reception via the second PSFCH RX beam associated with the reserved PSSCH resource is below a quality threshold.

16. The method according to any one of claims 9-15, wherein, The information is first information, and the method further includes receiving second information indicating a set of sidelink resource pools, and the first information further indicates sidelink resource pools from the set of sidelink resource pools, and determining the PSSCH resource set from the sidelink resource pools.

Images