Excluding resources to avoid beam conflicts

Abstract

Devices and techniques for excluding resources to avoid beam conflict. An example device may receive information that indicates 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 a PSFCH receive beam and a PSFCH occasion. The device may determine that a beam conflict exists between the PSFCH receive beam associated with the reserved PSSCH resource and the 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 a sidelink resource pool is associated with the PSFCH occasion, and determine to exclude the candidate PSSCH resource from a PSSCH resource set. The device may select a PSSCH resource from the PSSCH resource set and transmit a PSSCH transmission associated with the sidelink TB in the PSSCH resource.

Description

EXCLUDING RESOURCES TO AVOID BEAM CONFLICTSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 530,763, filed August 4, 2023, the contents of which is incorporated by reference herein.BACKGROUND

[0001] Mobile communications using wireless communication continue to evolve. A fifth generation may be referred to as 5G. A previous (legacy) generation of mobile communication may be, for example, fourth generation (4G) long term evolution (LTE).SUMMARY

[0002] Devices and techniques for excluding resources to avoid beam conflicts are provided herein.

[0003] An example device (e.g., a wireless transmit / receive unit (WTRU)) may receive information that indicates a first physical sidelink feedback channel (PSFCH) receive (RX) beam associated with a sidelink transport block (TB), and a reserved physical sidelink shared channel (PSSCH) resource. The reserved PSSCH resource may be associated with a second PSFCH RX beam and a PSFCH occasion. The device may determine that a 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. Based on the determination 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, the device may determine that a candidate PSSCH resource in a sidelink resource pool is associated with the PSFCH occasion, and determine a PSSCH resource set, in the sidelink resource pool. The candidate PSSCH resource may be excluded from the PSSCH resource set. The device may select a PSSCH resource from the PSSCH resource set. The device may transmit a PSSCH transmission associated with the sidelink TB in the PSSCH resource.

[0004] The device may 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 by determining that there is a difference between a first sidelink (SL) transmission configuration indicator (TCI) state associated with the first PSFCH RX beam associated with the sidelink TB and asecond SL TCI state associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

[0005] The device may 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 by determining that there is a difference between a first beam index associated with the first PSFCH RX beam associated with the sidelink TB and a second beam index associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

[0006] The device may 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 by determining that a first destination WTRU identifier associated with the first PSFCH RX beam associated with the sidelink TB is different from a second destination WTRU identifier associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

[0007] The device may 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 by determining that a 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.

[0008] The information may further indicate the second PSFCH RX beam associated with the reserved PSSCH resource. The device may 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 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.

[0009] The device may 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 by determining that signal reception via the second PSFCH RX beam associated with the reserved PSSCH resource is below a quality threshold.

[0010] The information may be first information. The device may receive second information that indicates a set of sidelink resource pools. The first information may further indicate the sidelink resource pool, from the set of sidelink resource pools, from which to determine the PSSCH resource set.

[0011] An example device may receive an indication of: a resource pool, a hybrid automatic repeat request (HARQ) processing period, a resource selection window, a physical sidelink feedback channel (PSFCH) receive (RX) beam associated with a sidelink transport block (TB), a reserved physical sidelink shared channel (PSSCH) resource, and a reserved PSFCH RX beam. The device may determine acandidate PSSCH resource set based on the resource selection window. The device may identify a beam conflict between the PSFCH RX beam associated with the sidelink TB and the reserved PSFCH RX beam. The device may determine a PSFCH occasion associated with the reserved PSSCH resource based on the resource pool and the reserved PSSCH resource. The device may determine, based on the HARQ processing period, a candidate PSSCH resource, from the candidate PSSCH resource set, associated with the PSFCH occasion associated with the reserved PSSCH resource. The device may exclude the candidate PSSCH resource from the candidate PSSCH resource set to generate a reduced candidate PSSCH resource set. The device may select a PSSCH resource from the reduced candidate PSSCH resource set. The device may transmit a PSSCH transmission associated with the sidelink TB in the PSSCH resource.

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

[0013] Identifying the beam conflict between the PSFCH RX beam associated with a sidelink TB and the reserved PSFCH RX beam may involve determining a difference between a first beam index associated with the PSFCH RX beam associated with the sidelink TB and a second beam index associated with the reserved PSFCH RX beam.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0016] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

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

[0018] FIG. 2 illustrates an example beam conflict.

[0019] FIG. 3 illustrates an example of a WTRU excluding physical sidelink shared channel (PSSCH) resources to avoid a physical sidelink feedback channel (PSFCH) receive (RX) beam conflict.

[0020] FIG. 4 illustrates repeated PSFCH occasions in a single slot.

[0021] FIG. 5 illustrates an example of a rotating PSFCH occasion.

[0022] FIG. 6 illustrates example selection / indication of a PSFCH occasion based on a corresponding RX beam.

[0023] FIG. 7 illustrates an example of multiple PSFCH occasions used for PSFCH backup.

[0024] FIG. 8 illustrates an example of a PSFCH repetition indication.

[0025] FIG. 9 illustrates an example of using sensing information during resource selection.DETAILED DESCRIPTION

[0026] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

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

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

[0029] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

[0031] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed PacketAccess (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

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

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

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

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

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

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

[0038] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit- switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

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

[0040] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0041] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

[0047] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable locationdetermination method while remaining consistent with an embodiment.

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

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

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

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

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

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

[0054] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

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

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

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

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

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

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

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

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

[0064] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0065] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices)that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

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

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

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

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

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

[0071] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0072] The CN 115 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0073] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access,services for machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0074] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernetbased, and the like.

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

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

[0077] In view of Figures 1 A-1 D, and the corresponding description of Figures 1 A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

[0079] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0080] A wireless transmit / receive unit (WTRU) may be connected to multiple other WTRUs. The other WTRU(s) may be located in different directions from the WTRU. If beamforming is enabled with HARQ feedback, different transmissions may be mapped to simultaneous resources (e.g., resources sent at the same time). The WTRU may not be able to receive multiple different beams at the same time. In this case, the WTRU may have a receive (RX) beam conflict. FIG. 2 illustrates an example beam conflict.

[0081] Vehicular communication may involve WTRUs communicating with each other (e.g., directly). There may be one or more (e.g., two) scenarios for V2X operations. For example, an in-coverage scenario may involve WTRUs receiving assistance from the network to start transmitting and receiving V2X messages. An out-of-coverage scenario may involve WTRUs using pre-configured parameter(s) to start transmitting and receiving V2X messages.

[0082] V2X communication may be supported (e.g., in Rel-14 LTE). V2X communication may be based on Device-to-Device (D2D) communications. V2X communication services may include one or more (e.g., four) different types. For example, V2X communication services may include one or more of: Vehicle to Vehicle (V2V), where vehicular WTRUs may communicate with each other (e.g., directly); Vehicle to infrastructure (V2I), where vehicular WTRUs may communicate with roadside units (RSUs) and / or eNBs; Vehicle to Network (V2N), where vehicular WTRUs may communicate with the core network; and / or Vehicle to Pedestrian (V2P), where vehicular WTRUs may communicate with WTRUs with special conditions (e.g., low battery capacity).

[0083] Feature(s) associated with NR SL channels and resource pools are provided herein.

[0084] A physical sidelink control channel (PSCCH) may indicate resources and / or other transmission parameters (e.g., that may be used by a WTRU for PSSCH). PSCCH transmission may be associated with a demodulation reference signal (DM-RS).

[0085] A physical sidelink shared channel (PSSCH) may transmit the TBs of data. The PSSCH may transmit control information for HARQ procedures, CSI feedback triggers, and / or the like. One or more (e.g., at least six) OFDM symbols within a slot may be used for PSSCH transmission. PSSCH transmission may be associated with a DM-RS and / or with a PT-RS.

[0086] A physical sidelink feedback channel (PSFCH) may carry HARQ feedback (e.g., over the sidelink from a WTRU that is an intended recipient of a PSSCH transmission to the WTRU that performed the transmission). A PSFCH sequence may be transmitted in a (e.g., one) PRB repeated over one or more (e.g., two) OFDM symbols (e.g., near the end of the sidelink resource in a slot).

[0087] PSCCH and PSSCH resources may be defined within resource pools for the respective channels. PSCCH / PSSCH may not be transmitted (e.g., and thus are not expected to be received) in one or more (e.g., all) RBs and slots in the NR system bandwidth. PSCCH / PSSCH may not be transmitted within the frequency span configured for V2X sidelink. A resource pool may imply (e.g., in resource allocation Mode 2) that a WTRU will make its resource selections based on sensing within the resource pool.

[0088] Resource pools may be (pre)configured to a WTRU (e.g., separately from the transmission perspective (TX pools) and the reception perspective (RX pools)). The WTRU may monitor for PSCCH (e.g., and receive PSSCH transmissions) in resource pools other than those in which the WTRU transmits (e.g., so that the WTRU may attempt to receive transmissions made by other WTRUs in those RX pools).

[0089] Feature(s) associated with new radio (NR) SL resource allocation are provided herein.

[0090] In some examples (e.g., 3GPP Release 17 and above), for NR, one or more (e.g., two SL resource allocation modes may be supported (e.g., Mode 1 and Mode 2). In Mode 1 , the SL resource allocation may be provided by the network. In Mode 2, the WTRU may decide the SL transmission resources in the resource pool(s).

[0091] In Mode 1 , scheduled resource allocation may be characterized by one or more of: the WTRU is in RRC_CONNECTED to transmit data; NG-RAN schedules transmission resources; NG-RAN may dynamically allocate resources to the WTRU via the SL-RNTI on PDCCH(s) for NR SL communication; NG-RAN may allocate SL resources to a WTRU with one or more (e.g., two) types of configured SL grants (e.g., type 1 , in which RRC directly provides the configured SL grant only for NR sidelink communication, and type 2, in which RRC defines the periodicity of the configured SL grant while PDCCH may signal and activate the configured SL grant, or deactivate the configured SL grant, and the PDCCH is addressed toSL-CS-RNTI for NR SL communication); NG-RAN may semi-persistently allocate sidelink resources to the WTRU via the SL semi-persistent scheduling V-RNTI on PDCCH(s) for V2X sidelink communication; and / or the WTRU may send sidelink buffer status report (SL-BSR) to support scheduler operation in NG-RAN.

[0092] For NR sidelink communication, the SL-BSRs may refer to the data that is buffered in for a group of logical channels (LCG) (e.g., per destination in the WTRU). One or more (e.g., eight) LCGs may be used for reporting of the sidelink buffer status reports. One or more (e.g., two) formats (e.g., SL-BSR and truncated SL-BSR) may be used. SL-BSR and truncated SL-BSR MAC control elements (MAC CE) may include a (e.g., one) destination index field, a (e.g., one) LCG ID field, and / or a (e.g., one) corresponding buffer size field (e.g., per reported target group).

[0093] In Mode 2, a WTRU may perform autonomous resource selection. In Mode 2, the WTRU may transmit data if the WTRU is inside NG-RAN coverage (e.g., irrespective of which RRC state the WTRU is in), and if the WTRU is outside NG-RAN coverage. The WTRU may autonomously select SL resource(s) from resource pool(s) (e.g., provided by broadcast system information or dedicated signaling while inside NG-RAN coverage or by (pre)configuration while outside NG-RAN coverage).

[0094] SCIs (e.g., the first-stage SCIs) transmitted by WTRUs on PSCCH may indicate the timefrequency resources in which the WTRU will transmit a PSSCH. The first-stage SCIs may be used by sensing WTRUs 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 a re-selection trigger), the WTRU may consider a sensing window. The sensing window may start a (pre)configured time (e.g., in the past) and may finish before (e.g., shortly before) the trigger time.

[0095] The sensing WTRU may select resources for its (re)transmission(s) from within a resource selection window. The window may start after (e.g., shortly after) the trigger for (re)selection of resources. The window may not be longer than the remaining latency budget of the packet due to be transmitted. Reserved resources in the selection window with SL-RSRP above a threshold may be excluded from being candidates by the sensing WTRU. The threshold may be set according to the priorities of the traffic of the sensing and transmitting WTRUs. A higher priority transmission from a sensing WTRU may occupy resources that are reserved by a transmitting WTRU with sufficiently low SL-RSRP and sufficiently lower- priority traffic.

[0096] A selected resource may be announced if the resource has been (e.g., has already been) identified by a previous SCI (e.g., in the case of periodic transmissions), configured grant, or reserved HARQ retransmissions. A selected resource may not be announced (e.g., yet) if the resource has not been identified by an SCI (e.g., only the WTRU having selected the resource knows about the selection, for example, internally).

[0097] If the MAC entity is configured with SL resource allocation Mode 2 to transmit on a resource pool, the resource(s) of a selected sidelink grant for a MAC PDU to transmit from a multiplexing and assembly entity may be reevaluated by a physical (PHY) layer (e.g., at T3 before the slot where the SCI indicating the resource(s) is signaled at a first time). The resource(s) of a selected sidelink grant that has been indicated by a prior SCI for a MAC PDU to transmit from the multiplexing and assembly entity may be checked for pre-emption by the PHY layer (e.g., at T3 before the slot where the resource(s) is located), if the resource pool is configured to enable preemption. The cut-off time T3 may be long enough before transmission to allow the WTRU to perform calculations relating to resource re-selection.

[0098] For the reevaluation and preemption check, the MAC layer may instruct the PHY layer to check whether the selected PSSCH resource(s) are still in the set of available candidate resources for the transmission (e.g., based on sensing). If any of the resources are not available anymore (e.g., based on the sensing results), the PHY may report the resources for reevaluation or preemption. The MAC layer may replace the unavailable resources with resources (e.g., newly selected resources) from the subset of candidate available resource (e.g., provided by the PHY layer).

[0099] Logical channel prioritization (LCP) for SL may be applied if a new transmission is performed. RRC may be used to control the scheduling of uplink data (e.g., by signaling for each logical channel per MAC entity with LC specific parameters, such as the sl-priority where an increasing priority value indicates a lower priority level). The LCP may involve selecting (e.g., amongst other eligibility criterions) the LC that has the highest priority. The MAC entity may allocate the resources to the selected LC (e.g., in decreasing priority order).

[0100] Feature(s) associated with SL feedback mechanisms are provided herein.

[0101] NR-V2X may support HARQ based on transmission of ACK / NACK (or DTX) for SL unicast and groupcast services, and / or a NACK-only HARQ scheme particular to groupcast services. NR-V2X may support blind retransmission schemes.

[0102] If an ACK / NACK (or DTX) operation is used, the SL HARQ scheme may be similar to the Uu scheme for non-codeblock group feedback (e.g., the HARQ feedback is transmitted based on the success or failure of the whole transport block).

[0103] A bit (e.g., one bit) of SL HARQ feedback may be carried on PSFCH from an Rx WTRU to an associated Tx WTRU. If the TX WTRU is under the control of a gNB in resource allocation Mode 1 , the Tx WTRU may inform the gNB (e.g., via PUCCH or PUSCH) of the status of the SL HARQ feedback that the TX WTRU has computed (e.g., SL HARQ feedback related to a particular dynamic or configured grant to assist the scheduling of re-transmissions and allocation of sidelink resources).

[0104] A WTRU may receive an indication (e.g., via an SCI format) scheduling a PSSCH reception to transmit a PSFCH with HARQ-ACK information (e.g., in response to the PSSCH reception). The WTRU may provide HARQ-ACK information. The HARQ-ACK information may include ACK and / or NACK (e.g., only NACK in some cases).

[0105] A WTRU may receive (e.g., by sl-PSFCH-period) a number of slots in a resource pool for a period of PSFCH transmission occasion resources. If the number is zero, PSFCH transmissions from the WTRU in the resource pool may be disabled.

[0106] If a WTRU receives a PSSCH in a resource pool and the HARQ feedback enabled / disabled indicator field in an associated SCI format 2-A / 2-B / 2-C has value 1 , the WTRU may provide the HARQ- ACK information in a PSFCH transmission in the resource pool. The WTRU may transmit the PSFCH in a first slot that includes PSFCH resources and is at least a number of slots (e.g., provided by sl- MinTimeGapPSFCH) of the resource pool after a last slot of the PSSCH reception.

[0107] For a PSFCH transmission with HARQ-ACK information, a WTRU may determine a cyclic shift value (e.g., depending on the SCI format and / or from a cyclic shift pair index corresponding to a PSFCH resource index).

[0108] One or more (e.g., multiple) PSFCH receptions may occur at the same time instant (e.g., whether the PSFCH is using different cyclic shifts or transmitted over different subchannels).

[0109] Example SL-PSFCH-Config field descriptions are provided herein. sl-MinTimeGapPSFCH may indicate the minimum time gap between PSFCH and the associated PSSCH in the unit of slots, sl- NumMuxCS-Pair may indicate the number of cyclic shift pairs used for a PSFCH transmission that can be multiplexed in a PRB. sl-PSFCH-CandidateResourceType may indicate the number of PSFCH resources available for multiplexing HARQ-ACK information in a PSFCH transmission. sl-PSFCH-HopID may indicate a scrambling ID for sequence hopping of the PSFCH used in the resource pool. sl-PSFCH-Period may indicate the period of PSFCH resource in the unit of slots within this resource pool. If set to slO, no resource for PSFCH, and HARQ feedback for all transmissions in the resource pool is disabled. sl-PSFCH-RB-Set may indicate the set of PRBs that are used for PSFCH transmission and reception. The leftmost bit of the bitmap may refer to the lowest RB index in the resource pool, and so on. Value 0 in the bitmap may indicate that the corresponding PRB is not used for PSFCH transmission and reception. Value 1 may indicate that the corresponding PRB is used for PSFCH transmission and reception.

[0110] A WTRU may be connected to multiple other WTRUs in different directions. If SL transmissions and receptions are performed using beamforming (e.g., SL on FR2), a beam conflict may appear if the WTRU intends to transmit or receive using different beams while only being capable of a using a single beam at a time. This situation may occur if the WTRU is scheduled with multiple PSCCH / PSSCHtransmissions at the same time that are multiplexed in the frequency domain. A beam conflict may occur if HARQ feedback is enabled and different transmissions are mapped to a simultaneous PSFCH resources (e.g., not the same resource, but at the same time).

[0111] A WTRU may perform beam-aware SL resource allocation to avoid beam conflicts (e.g., for Mode 1 and Mode 2, and for PSFCH reception and PSSCH transmissions).

[0112] A beam conflict may occur if a WTRU performs Mode 2 sensing to acquire SL sensing information for resource selection. In SL FR2 operation, to improve link performance, a WTRU may apply a directional sensing RX beam for PSCCH reception to enable beamforming gain. The sensing result may be different for different RX beams. The sensing result may be used to determine the available resource for transmission (e.g., that also may apply a directional TX beam).

[0113] Mode 2 resource selection may be enabled for directional transmissions (e.g., based on directional sensing).

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

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

[0116] A WTRU may apply a TX beam (e.g., one TX beam) for a SL transmission in a given SL slot.

[0117] Feature(s) associated with TX beam indication are provided herein. A TX beam may be indicated by one or more of the following: a (pre)configured numeric index; and / or a numeric index of a SL reference signal transmission (e.g., a SL SSB, SL CSI-RS, PSCCH DMRS, PSSCH DMRS or a SL TRS transmitted using the TX beam).

[0118] Feature(s) associated with RX beams are provided herein.

[0119] A SL receive beam (e.g., referred to herein as an RX beam) may denote one or more of the following: a WTRU SL RX configuration; a WTRU SL RX spatial configuration; a WTRU SL RX spatial filter; set of antenna element weights applied for one or more antenna panels used for a WTRU SL reception; and / or a WTRU reception in a steering direction (e.g., a unique steering direction characterized by beam width, beam gain, beam center and beam peak lobe, which are determined by a WTRU SL RX configuration, a WTRU SL RX spatial configuration, a WTRU SL RX spatial filter, and / or a set of antenna element weights applied for one or more antenna panels used for a WTRU SL reception).

[0120] A WTRU may apply an RX beam (e.g., one RX beam) for a SL transmission in a given SL slot.

[0121] Feature(s) associated with RX beam indication are provided herein. An RX beam may be indicated by one or more of the following: a (pre)configured numeric index; a numeric index of a SL reference signal reception (e.g., a SL SSB, SL CSI-RS, PSCCH DMRS, PSSCH DMRS or a SL TRS transmitted using the RX beam); and / or a corresponding TX beam indication. A corresponding TX beam indication may be used for RX beam indication if a WTRU supports beam correspondence.

[0122] A WTRU may (e.g., need to) rely on a (e.g., single) beam for transmission or reception at a time. Feature(s) associated with avoiding a situation in which a user would use (e.g., require) multiple beams at a time. Some feature(s) described herein may be proactive (e.g., anticipating the issue and preparing the resource selection to avoid such cases or reactive, and / or if a conflict is detected, handling the case to avoid the conflict).

[0123] Feature(s) described herein may be associated with NR SL operating with beamforming (e.g., in FR2 bands) are provided herein, but are not limited to that case.

[0124] A WTRU may use beamformed transmissions for SL. The WTRU may be (pre)configured with TX beams for transmissions (e.g., PSCCH, PSSCH, PSFCH) with destination WTRUs (e.g., each intended destination WTRU). The WTRU may be (pre)configured with RX beams to be applied to the receptions from theses WTRUs (e.g., PSCCH, PSSCH, PSFCH). A WTRU may have a (configured) mapping between WTRU IDs and the corresponding beams to apply. This mapping may (e.g., if needed) be share between the MAC and PHY layer of a WTRU (e.g., so that the different procedures may determine the beam(s) to use for a given transmission or reception to / from a given WTRU, for example, based on the WTRU-to- beam mapping).

[0125] The (pre)configuration of the beam may be based on RRC configuration (e.g., a (default) TX or RX beam for a given BWP, RP, or unicast connection), indicated by receiving MAC CE commands, and / or dynamically indicated (e.g., using DCI or SCI) for selected transmissions.

[0126] Beams may be (pre)configured for a given WTRU ID (e.g., for all the transmissions and receptions with that WTRU). Beams may be (pre)configured with a WTRU-to-beam mapping. Beams maybe (pre)configured separately for receptions and transmissions for each WTRUs (e.g., in the case where if channel reciprocity is not assumed). Beams may be (pre)configured separately for different channels and / or different WTRUs (e.g., PSCCH, PSSCH, PSFCH).

[0127] The determination of a beam to apply for a transmission or a reception may be based on the measurement of SL-RS by the WTRU (e.g., SL-SSB, SL-CSI-RS, PSSCH DMRS, PSCCH DMRS) and / or a reported measurement of a SL-RS from the pair WTRU.

[0128] Feature(s) associated with the PSFCH in NR SL are provided herein (e.g., focusing on the case where the PSFCH is used to report HARQ feedback). The feature(s) described herein may apply to PSFCH used for any other purposes (e.g., if the PSFCH is used for SL beam management or SL CSI reporting). The associated usage-based mapping to determine the PSFCH resources may be used (e.g., SL (CSI-)RS to PSFCH mapping report based on the (pre)configuration of the resource pool or of the WTRUs).

[0129] Beam conflict may occur between two transmissions. Feature(s) described herein related to beam conflict between two transmissions may be applicable to more than two transmissions being checked for conflicts (e.g., by duplicating or grouping the processes for the different transmissions).

[0130] Feature(s) associated with Mode 2 Rx beam conflict avoidance are provided herein.

[0131] An NR SL WTRU may be (pre)configured to perform transmissions using beamformed signals(e.g., on FR2 carriers). The resource pool may be (pre)configured with HARQ feedback enabled. The resource pool may be (pre)configured with HARQ feedback parameters (e.g., the RRC field SL-PSFCH- Config that includes the parameters for mapping PSSCH transmissions to PSFCH resources).

[0132] A WTRU may be (pre)configured to use Mode 2 resource selection (e.g., configured by the network or when the WTRU is out of coverage).

[0133] A WTRU may be triggered to select resource selection for a PSSCH transmission (e.g., if HARQ feedback is enabled for the SL TB). The resource selection may be indicated on a resource pool configured to support HARQ feedback.

[0134] If the MAC entity has been (pre)configured with SL resource allocation Mode 2 to transmit using pool(s) of resources in a carrier, the PHY layer may receive an indication with the specifications (e.g., requirements) for the resource selection. The specifications for the resource selection may include: the amount of selected resources (e.g., a number of subchannels), the selected number of HARQ retransmissions, the priority and the remaining PDB of the SL data, and / or the like.

[0135] In SL resource selection (e.g., Mode 2 resource selection) beam information may not be considered during the resource selection. Other scheduled transmissions (and beams) may not beconsidered during the resource selection (e.g., independent resource allocations). A resource selection that is blind to beams and other transmissions / receptions may cause beam conflict.

[0136] SL resource selection (e.g., Mode 2 resource selection) may be used (e.g., to avoid beam conflict).

[0137] SL resource selection may be based on scheduled resources (e.g., previously scheduled resources) and / or beam considerations. PSSCH resources that would map to a PSFCH RX beam conflict may be excluded (e.g., based on a feedback configuration and / or SL-UE beam mapping). One or more of the following may be performed.

[0138] A WTRU may be (pre)configured with PSFCH occasions in a resource pool and / or a HARQ processing period. The WTRU may receive an indication (e.g., by higher layers) of one or more of the following parameters of a resource selection (e.g., for a PSSCH transmission of a HARQ-enabled SL transport block (TB): a resource pool; a destination WTRU ID of the SL TB; a PSFCH RX beam associated with the SL TB; a reserved PSSCH resource and / or associated PSFCH RX beam; and / or a resource selection window.

[0139] The WTRU may determine a candidate PSSCH resource set (e.g., based on the indicated resource selection window).

[0140] The WTRU may determine that a beam conflict exists between the PSFCH RX beam associated with the reserved PSSCH resource and the PSFCH RX beam associated with the sidelink TB. The WTRU may determine that the PSFCH RX beam(s) of the transmission are not aligned with the PSFCH RX beam of the reserved transmission (e.g., based on different SL TCI states, beam indexes, etc.).

[0141] The WTRU may determine the PSFCH occasion corresponding to the indicated reserved PSSCH resource (e.g., based on the (pre)configuration of the indicated resource pool and / or the indicated reserved PSSCH resource).

[0142] Based on identifying the beam conflict, the WTRU may determine a candidate PSSCH resource(s) (e.g., all candidate PSSCH resources) associated with (e.g., corresponding to) the determined PSFCH occasion of the reserved transmission (e.g., based on the PSFCH occasion (pre)configuration of the indicated resource pool and / or a HARQ processing time period).

[0143] The WTRU may exclude the determined candidate PSSCH resource(s) from the candidate PSSCH resource set. The WTRU may select a PSSCH resource (e.g., perform resource selection in / from) the determined candidate resource set. The WTRU may transmit a PSSCH transmission of a HARQ- enabled SL TB in a selected resource.

[0144] In SL resource reevaluation (e.g., Mode 2), no beam information may be considered during the resource selection. Other scheduled transmissions (and beams) may not be considered during the resource selection (e.g., independent resource allocations).

[0145] An RX beam may change between scheduling and transmission (e.g., a configured grant). The resource reevaluation may not consider beam aspects and / or other transmissions.

[0146] One or more resources may be excluded to avoid beam conflict.

[0147] In SL resource selection (e.g., Mode 2 resource selection) beam information may not be considered during the resource selection. Other scheduled transmissions (and beams) may not be considered during the resource selection (e.g., independent resource allocations). A resource selection that is blind to beams and other transmissions / receptions may cause beam conflict.

[0148] SL resource selection (e.g., Mode 2 resource selection) may be used (e.g., to avoid beam conflict).

[0149] SL resource selection may be based on scheduled resources (e.g., previously scheduled resources) and / or beam considerations. PSSCH resources that would map to a PSFCH RX beam conflict may be excluded (e.g., based on a feedback configuration and / or SL-UE beam mapping). One or more of the following may be performed.

[0150] A WTRU may be (pre)configured with PSFCH occasions in a resource pool and / or a HARQ processing period. The WTRU may receive an indication (e.g., by higher layers) of one or more of the following parameters of a resource selection (e.g., for a PSSCH transmission of a HARQ-enabled SL transport block (TB): a (sidelink) resource pool; a destination WTRU ID of the SL TB; a PSFCH RX beam associated with the SL TB; a reserved PSSCH resource and / or associated PSFCH RX beam; and / or a resource selection window.

[0151] The WTRU may determine a candidate PSSCH resource set (e.g., based on the indicated resource selection window).

[0152] The WTRU may determine that the PSFCH RX beam(s) of the transmission are not aligned with the PSFCH RX beam of the reserved transmission (e.g., based on different SL TCI states, beam indexes, etc.).

[0153] The WTRU may determine the PSFCH occasion corresponding to the indicated reserved PSSCH resource (e.g., based on the (pre)configuration of the indicated resource pool and / or the indicated reserved PSSCH resource).

[0154] The WTRU may determine candidate PSSCH resource(s) (e.g., all candidate PSSCH resources) corresponding to the determined PSFCH occasion of the reserved transmission (e.g., based on the PSFCH occasion (pre)configuration of the indicated resource pool and / or a HARQ processing time period).

[0155] The WTRU may exclude the determined PSSCH resources from the candidate resource set. The WTRU may perform resource selection in (e.g., from) the determined candidate resource set. The WTRU may transmit a PSSCH transmission of a HARQ-enabled SL TB in a selected resource.

[0156] An SL TX WTRU may add the beam conflict consideration in the resource allocation phase. If the WTRU is selecting the resources for a transmission, the WTRU may exclude the resources that would create a PSFCH RX beam conflict. The WTRU may perform the resource selection considering the already scheduled transmissions and the PSFCH RX beams.

[0157] If the MAC entity has been (pre)configured with SL resource allocation Mode 2 to transmit using pool(s) of resources in a carrier, and using beamformed transmission, the PHY layer may receive an indication of one or more of the following: the destination WTRU ID of the SL TB and / or the associated PSFCH RX beam, and / or a reserved PSSCH resource (e.g., an already reserved PSSCH resource) and the associated PSFCH RX beam.

[0158] The PSFCH RX beam may 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).

[0159] The WTRU may determine the resource selection window (e.g., based on the indicated remaining PDB). The WTRU may determine an initial candidate PSSCH resource set (e.g., by excluding its own already selected resources). The WTRU may exclude resources considered as not available (e.g., based on sensing measurements, for example, the resources indicated by a received SCI with a RSRP higher than a given threshold).

[0160] The WTRU may determine potential PSFCH RX beam conflicts.

[0161] The WTRU may evaluate the potential RX beam conflict for PSFCH reception (e.g., by comparing the PSFCH RX beam configured for the SL TB being scheduled and the PSFCH RX beam indicated for the already selected PSSCH resources).

[0162] The WTRU may determine a potential RX beam conflict if the RX beam indexes for the reserved and transmissions being scheduled are different. The WTRU may determine a potential RX beam conflict if the TCI state used for the RX beams for the reserved and transmissions being scheduled are different (e.g., different TCI index or using different RS).

[0163] The WTRU may determine a potential RX beam conflict if the RX beams are using TX-RX beam correspondence and the TX beam indexes for the reserved and transmissions being scheduled aredifferent. The WTRU may determine a potential RX beam conflict if the RX beams are indicated using different indication methods between the reserved and transmissions being scheduled are different (e.g., a beam index and a TCI state). For example, the WTRU may determine a potential RX beam conflict if the PSFCH RX beam associated with the reserved PSSCH resource is indicated using a first indication type, and the PSFCH RX beam associated with the sidelink TB is indicated using a second indication type, different from the first indication type.

[0164] The WTRU may determine a potential RX beam conflict if the WTRU destination IDs of the reserved and transmissions being scheduled are different. In this case, the WTRU may be able to perform a comparison without a beam indication. The WTRU may determine a potential RX beam conflict if the correlation of the RX beams of the reserved and transmissions being scheduled is below a ((pre)configured) threshold (e.g., based on the WTRU knowledge of its beams, for example, based on the weights applied or the spatial domain filters used to generate the beams).

[0165] The WTRU may determine a potential RX beam conflict if signal reception via the PSFCH RX beam associated with the reserved PSSCH resource is below a quality threshold. For example, the WTRU may determine the potential RX beam conflict if the WTRU estimates that the reception of a signal from the destination WTRU (e.g., using the RX beam configured to receive the reserved transmission) would be of low quality (e.g., the RSRP below a threshold). The estimation may be based on previous measurements (e.g., during beam management).

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

[0167] Feature(s) described herein may be described in the context of a WTRU that supports (e.g., only supports) one RX beam at a time. However, a person of ordinary skill in the art will understand that a similar approach may be extended for any number of supported simultaneous beams. The terms “beam conflict” and “beams not aligned” may be used interchangeably.

[0168] A WTRU may determine and exclude conflicted PSSCH resources from the PSSCH resource set.

[0169] If the WTRU determined that the PSFCH RX beam of the transmission being scheduled is in conflict with the PSFCH RX beam of a transmission already scheduled, the WTRU may determine the set of PSSCH resources to be excluded from the candidate resource set (e.g., to avoid the PSFCH RX beam conflict).

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

[0171] The WTRU may determine (e.g., in a reverse mapping way) one or more (e.g., all) PSSCH resources that map to a PSFCH resource having a time overlap (e.g., based on the (pre)configuration of the indicated resource pool).

[0172] In some examples (e.g., 3GPP NR Release 17), PSSCH resources that map to a PSFCH resource having a time overlap may correspond to the PSSCH resources (e.g., all the PSSCH resources) in the same slot as the indicated reserved PSSCH resource, and / or the PSSCH resources (e.g., all the PSSCH resources) in the slots that correspond to the same PSFCH period.

[0173] The WTRU may exclude the determined PSSCH resources from the candidate resource set.

[0174] FIG. 3 illustrates an example of a WTRU excluding physical sidelink shared channel (PSSCH) resources to avoid a physical sidelink feedback channel (PSFCH) receive (RX) beam conflict. As illustrated, the WTRU may determine a PSFCH occasion (e.g., in blue) corresponding to an already reserved PSSCH resource (e.g., in purple). Using the PSFCH period and / or PSFCH-to-PSSCH minimum time gap, the WTRU may determine the resources (e.g., in yellow) that map to the same PSFCH instance. The WTRU may exclude them from the resource selection window (RSW) if the beams are in conflict.

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

[0176] The WTRU may determine the resources to exclude for PSSCH TX beam conflict.

[0177] The WTRU may be (pre)configured to prevent PSSCH TX beam conflicts. If the channel reciprocity is assumed for the transmission links of different WTRUs, preventing a TX beam conflict (e.g., transmitting simultaneously with multiple different beams at a time) may prevent PSFCH RX beam conflict.

[0178] Similarly, the TX beam conflict may be determined based on having: different beam IDs, different TCI states, different SL-RSs used for reference, different WTRU IDs, low-correlated TX beams, and / or low RSRP signal reception.

[0179] The WTRU may determine (e.g., may first determine) the PSSCH resources that are scheduled with a TX beam that is in conflict with the TX beam of the transmission being scheduled (e.g., the PSSCH resources in the same slot of a conflicting PSSCH transmission).

[0180] If the WTRU is (pre)configured to prevent PSFCH RX beam conflict (e.g., using channel reciprocity assumption), the WTRU may determine the PSSCH resources that are in the slots of the same PSFCH period as the conflicted PSSCH transmission (e.g., using the resource pool (pre)configuration). The WTRU may exclude (e.g., may then exclude) the determined PSSCH resources from the candidate set of PSSCH resources. RX beam indications may not be used (e.g., required) in this case. This case may (e.g., instead) use the TX beam indication for the reserved transmission and the transmission being scheduled. If the beam conflict is based on the WTRU ID (e.g., only the WTRU ID), beam information may not be used (e.g., may not be needed).

[0181] Feature(s) described herein may be used individually (e.g., to prevent TX beam conflicts and RX beam conflicts if channel reciprocity is assumed) or as a complement with other feature(s) (e.g., to prevent both PSSCH TX beam conflicts and PSFCH RX beam conflicts if channel reciprocity is not assumed).

[0182] The PHY layer may report the subset of resource to the MAC layer (e.g., after the exclusion of the PSSCH resources due to beam conflict). The MAC layer may select a resource for the SL transmission.

[0183] The MAC layer may exclude resources. The resource exclusion due to beam conflict may be performed by the MAC layer. The MAC layer may receive the following information: a subset of PSSCH resources available for transmission (e.g., the subset of PSSCH resources provided by the PHY layer only excluded the resources based on own transmission and sensing, for example, not based on beam conflicts); the destination WTRU ID of the transmission; the PSFCH RX beam corresponding to the transmission; and / or an already reserved PSSCH resource and the corresponding PSFCH RX beam.

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

[0185] The WTRU may determine (e.g., may first determine) a potential PSFCH RX beam conflict using the determined / indicated PSFCH RX beams of the reserved transmission and / or the PSFCH of the transmissions being scheduled (e.g., using techniques as described herein).

[0186] The WTRU may determine the set of PSSCH resources with beam conflictsfe.g. , using techniques as described herein). The WTRU may exclude the determined conflicting PSSCH resources from the received subset of resources from the PHY layer. If the size of the remaining set of PSSCH resources is below a configured threshold, the MAC layer may request another set of resources to the PHY layer. The technique may then be repeated (e.g., with the new set of resources).

[0187] The WTRU may select the PSSCH resources for the transmission (e.g., picking a resource randomly within the remaining set of PSSCH resources). The WTRU may use the PSSCH resources to transmit the SL transmission.

[0188] Beam-aware sidelink (SL) resource allocation may be used to avoid physical sidelink feedback channel (PSFCH) RX beam conflicts. Transmissions may be resolved / prioritized if a PSFCH RX beam conflict is anticipated.

[0189] Resource reevaluation (e.g., Mode 2 resource reevaluation) may be used (e.g., to avoid beam conflict).

[0190] A WTRU may detect a beam conflict for PSFCH reception (e.g., before the transmission). The WTRU may trigger the cancellation / reselection of a SL transmission to avoid the conflict.

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

[0192] The WTRU may receive a SL beam conflict reevaluation (pre)configuration. The SL beam conflict reevaluation (pre)configuration may include a resource reselection window (e.g., a beam conflict reselection maximum time). The WTRU may select or be granted with a set of PSSCH resources. A PSSCH resource (e.g., each PSSCH resource) may be associated with one or more of the following resource association information: a PSSCH transmission of a SL TB in the selected PSSCH resource (e.g., a WTRU destination ID of the SL TB; a remaining packet delay budget (PDB) of the SL TB; and / or a SL priority of the SL TB); a PSFCH RX beam to use for reception of HARQ feedback for the PSSCH transmission; and / or a reservation status of the selected resource (e.g., unannounced, where the selected resource is not reserved in SL transmission; or announced, where the selected resource is reserved in a SL transmission).

[0193] The WTRU may perform a PSFCH beam conflict re-evaluation if the PSFCH RX beam associated with one or more transmitted PSSCH resource reservation is updated (e.g., based on beam pairing reconfiguration).

[0194] The WTRU may determine that there is a PSFCH beam conflict 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 indexes).

[0195] The WTRU may determine PSSCH transmission(s) associated with the determined PSFCH RX beams in conflict (e.g., based on the resource association information).

[0196] The WTRU may trigger resource reselection for a PSSCH transmission (e.g., for a SL TB with lowest priority, a remaining PDB above a threshold, and / or the reservation is not yet announced). For example, the WTRU may determine that the PSSCH resource satisfies the reselection condition if the PSSCH transmission (e.g., associated with the PSSCH resource) has a lower priority than the first PSSCH transmission; the second PSSCH transmission (e.g., associated with the PSSCH resource) is associated with a remaining PDB above a threshold; or a reservation status of the PSSCH resource is unannounced.

[0197] The WTRU may trigger resource reselection if the time until the selected resource of the PSSCH transmission is larger than the (pre)configured beam conflict re-selection maximum time. On a condition that the second PSSCH resource satisfies a reselection condition and the resource reselection window is ongoing, the WTRU may select another PSSCH resource in which to send the PSSCH transmission.

[0198] The WTRU may perform the prioritized / adjusted PSSCH transmissions in the selected / granted resources.

[0199] A WTRU may perform a reevaluation with beam conflict consideration.

[0200] In SL resource reevaluation (e.g., Mode 2), no beam information may be considered during the resource selection. Other scheduled transmissions (and beams) may not be considered during the resource selection (e.g., independent resource allocations).

[0201] An RX beam may change between scheduling and transmission (e.g., a configured grant). The resource reevaluation may not consider beam aspects and / or other transmissions.

[0202] Resource reevaluation (e.g., Mode 2 resource reevaluation) may be used (e.g., to avoid beam conflict).

[0203] A WTRU may detect a beam conflict for PSFCH reception (e.g., before the transmission). The WTRU may trigger the cancellation / reselection of a SL transmission to avoid the conflict.

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

[0205] The WTRU may receive a SL beam conflict reevaluation (pre)configuration. The SL beam conflict reevaluation (pre)configuration may include resource reselection window (e.g., a beam conflict re-selection maximum time). The WTRU may select or be granted with a set of PSSCH resources. A PSSCH resource (e.g., each PSSCH resource) may be associated with one or more of the following resource association information: a PSSCH transmission of a SL TB in the selected PSSCH resource (e.g., a WTRU destination ID of the SL TB; a remaining PDB of the SL TB; and / or a SL priority of the SL TB); a PSFCH RX beam to use for reception of HARQ feedback for the PSSCH transmission; and / or a reservation status of the selected resource (e.g., unannounced, where the selected resource is not reserved in SL transmission; or announced, where the selected resource is reserved in a SL transmission).

[0206] The WTRU may perform a PSFCH beam conflict re-evaluation if the PSFCH RX beam associated with one or more transmitted PSSCH resource reservation is updated (e.g., based on beam pairing reconfiguration).

[0207] The WTRU may determine that there is a PSFCH beam conflict 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 indexes).

[0208] The WTRU may determine PSSCH transmission(s) associated with the determined PSFCH RX beams in conflict (e.g., based on the resource association information).

[0209] The WTRU may trigger resource reselection for a PSSCH transmission (e.g., for a SL TB with lowest priority, a remaining PDB above a threshold, and / or the reservation is not yet announced). For example, the WTRU may trigger resource reselection if the time until the selected resource of the PSSCH transmission is larger than the (pre)configured beam conflict re-selection maximum time.

[0210] The WTRU may perform the prioritized / adjusted PSSCH transmissions in the selected / granted resources.

[0211] An SL TX WTRU may determine that there will be a RX beam conflict to receive the PSFCH of its scheduled transmissions. If a beam conflict is detected, the WTRU may act (e.g., cancellation, reselection, etc.) on the corresponding transmissions to avoid the conflict.

[0212] In this case, the WTRU may be acting in a reactive manner to solve beam conflicts (e.g., based on the reevaluation and / or preemption checks), for example, if the scheduling did not prevent beam conflict (e.g., because such techniques were not implemented or changes have been made between the scheduling decision and the actual transmissions, for example, a resource change, beam change, etc.). In this case, the reevaluation and / or preemption checks may be extended to the verification to beam conflicts.

[0213] Feature(s) associated with configuration and information exchange are provided herein.

[0214] A WTRU may be (pre)configured to use resource allocation Mode 2 with a resource pool supporting preemption. A WTRU may be (pre)configured to support beam conflict reevaluation and / or preemption. The time at which the WTRU performs the reevaluation and / or preemption with beam consideration may be configured (e.g., so that the WTRU has enough time to perform the reevaluation and / or preemption check and, if needed, the selection of a new resource). This time limit may be the same or different than a legacy reevaluation and / or preemption time limit (e.g., T3).

[0215] To perform the reevaluation or preemption check for beam conflicts, the PHY layer may receive the following information (e.g., for each of the selected / granted resources): the PSSCH transmission of a 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 to use for the reception of the HARQ feedback corresponding to the PSSCH transmission; and / or the reservation status of the selected resources (e.g., unannounced, where the resources are selected but not indicated in a SCI transmission; or announced, wherein the resources are selected and indicated in a SCI transmission).

[0216] The reevaluation may apply to unannounced resources. The preemption may apply to announced resources.

[0217] Example triggers for beam conflict evaluation are provided herein. One or more triggers may cause a WTRU to perform the reevaluation or preemption for beam conflict of selected resources. The WTRU may determine a change that may result in a beam conflict change (e.g., based on the resources for the transmissions already scheduled and the PSFCH RX beams for these transmissions). A trigger for the reevaluation or preemption of scheduled resources may be the WTRU determining that the configured PSFCH RX beam for a scheduled resource is reconfigured. The reconfiguration of the PSFCH RX beam may happen if: the WTRU receives a beam indication for PSFCH RX beam from another WTRU or from the network; the WTRU determines a new beam for PSFCH RX beam (e.g., by the WTRU itself, based on measurements of a SL RS, for example, SL-SSB, SL-CSI-RS, PSSCH DMRS, PSCCH DMRS, from the destination WTRU, or reception of measurement report from the destination WTRU, for example, an SL CSI report); and / or the WTRU determines a TX beam change toward the destination WTRU (e.g., based on received beam indication or self-determination, assuming channel reciprocity for beam determination).

[0218] A trigger for the reevaluation or preemption of scheduled resources may be the WTRU receiving or determining a new PSSCH resource for a SL transmission (e.g., that did not consider beam conflict). For example, reevaluation or preemption may be triggered if: the WTRU performs an autonomous resource selection (e.g., Mode 2) that does not implement beam verification; the WTRU performs an autonomous resource reselection (e.g., Mode 2) that does not implement beam verification, following a reevaluation or a preemption; and / or the WTRU receives a grant from another WTRU (e.g., for WTRU assisted resource selection).

[0219] The WTRU may trigger the reevaluation or preemption of scheduled resources for beam conflict at the configured beam conflict maximum reevaluation and / or preemption time of a resource.

[0220] A subset of resources to reevaluate and / or check for preemption for beam conflicts may be determined. In some (e.g., legacy) reevaluation and / or preemption checks, the PHY layer may be given a set of resources to verify that they are still available. For example, the set of resources may include the scheduled resources arriving at T3 (e.g., before transmissions or announcement). The check (e.g., legacy check) may be performed against sensing reservation (e.g., based on the reservation announced by other WTRUs).

[0221] The verification may be performed against the resources and the associated beams selected by the WTRU. The WTRU may (e.g., need to) determine the PSSCH resources to be included in the verification. The set of PSSCH resources determined by the WTRU for beam conflict verification may include scheduled resources (e.g., all the scheduled resources) of the WTRU. The set of PSSCH resourcesdetermined by the WTRU for beam conflict verification may include the scheduled PSSCH resources (e.g., all the scheduled PSSCH resources) that are mapping to a same PSFCH instance. The WTRU may determine this set based on the known PSSCH resources and the SL HARQ feedback configuration.

[0222] The set of PSSCH resources determined by the WTRU for beam conflict verification may include the scheduled PSSCH resources (e.g., all the scheduled PSSCH resources) that are mapping to at least one PSFCH resource overlapping in time with a PSFCH resource of the PSSCH transmission that triggered the beam conflict verification. The WTRU may determine this set based on the known PSSCH resources and / or the SL HARQ feedback configuration.

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

[0224] If the beam conflict reevaluation or preemption is triggered by a change in one of the PSFCH reception configuration (e.g., beam change), the reevaluation or preemption may limit the verification (e.g., to only pairs of PFSCHs that include the reconfigured PSFCH).

[0225] The WTRU may determine an RX beam conflict if the PSFCH RX beam indexes of a pair of reserved transmissions are different. The WTRU may determine an RX beam conflict if the TCI state used for the PSFCH RX beams for a pair of reserved transmissions are different (e.g., different TCI index or using different RS).

[0226] The WTRU may determine an RX beam conflict if the PSFCH RX beams are indicated using different indication methods for a pair of reserved transmissions, (e.g., a beam index and a TCI state). For example, the WTRU may determine a potential RX beam conflict if the PSFCH RX beam associated with the reserved PSSCH resource is indicated using a first indication type, and the PSFCH RX beam associated with the sidelink TB is indicated using a second indication type, different from the first indication type.

[0227] The WTRU may determine an RX beam conflict if the RX beams are using TX-RX beam correspondence and the TX beam indexes for a pair of reserved transmissions are different. The WTRU may determine an RX beam conflict if the WTRU destination IDs of a pair of reserved transmissions are different. In this case, the WTRU may be able to perform a comparison without the need for beam indication.

[0228] The WTRU may determine an RX beam conflict if the correlation of the RX beams of a pair of reserved transmissions is below a (configured) threshold (e.g., based on the WTRU knowledge of its beams, for example, based on the weights applied or the spatial domain filters used to generate the beams).

[0229] The WTRU may determine an RX beam conflict if signal reception via the PSFCH RX beam associated with the reserved PSSCH resource is below a quality threshold. For example, the WTRU may determine the potential RX beam conflict if the WTRU estimates that the reception of a signal from a destination WTRU, using the RX beam configured to receive a transmission from another destination WTRU, would be of low quality (e.g., the RSRP below a threshold, based on previous measurements, for example, during beam management).

[0230] If a beam conflict is determined between at least a pair of transmissions, the WTRU may determine the PSSCH resources associated with the beam conflict (e.g., the reserved PSSCH resources that maps to the conflicted PSFCH) using the HARQ feedback configuration.

[0231] The reevaluation or preemption verification may report the conflicted PSSCH resources (e.g., to the MAC layer).

[0232] The WTRU may act to resolve beam conflicts. The WTRU may perform actions to (e.g., some of) the reported PSSCH resources with beam conflict (e.g., to resolve and avoid the beam conflict). The WTRU may determine (e.g., at least) a PSSCH resource from the reported conflicted PSSCH resources. For example, the WTRU may determine a PSSCH resource from the reported conflicted PSSCH resources based on one or more of: the SL TB using the PSSCH resource has the lowest priority of the reported conflicted PSSCH resources; the remaining PDB of the SL TB using the PSSCH resource is above a configured threshold; the reserved resource is not yet announced in a SCI; and / or the maximum time limit for resource reselection with beam conflict of PSSCH resource has not passed.

[0233] The WTRU may trigger a reselection of the resource for the determined PSSCH resource. This may be applicable if the PSSCH resource has been determined based on whether there is a sufficient remaining PDB for the SL TB and / or that the resource reselection window (e.g., the time limit for reselection) is ongoing (e.g., has not passed).

[0234] If the reselection of resource does not consider the beam conflict aspect, the WTRU may trigger the beam conflict verification corresponding to that resource.

[0235] The WTRU may cancel the transmission. For example, the WTRU may cancel the transmission if the remaining PDB of the SL TB is below a (pre)configured threshold. The WTRU may cancel the transmission if the resource reselection window (e.g., the time limit for beam conflict based-reselection) has ended / passed (e.g., meaning there is not enough time to reselect a satisfactory resource). The WTRU maycancel the transmission if the WTRU received the grant from another WTRU. In that case, the WTRU may report to the granting device that the transmission was canceled (e.g., due to a beam conflict). If a transmission is cancelled, the WTRU may reallocate (e.g., via the LCP procedure) the resource for a PSSCH transmission towards another destination WTRU (e.g., limited to destination WTRUs that are associated with a PSFCH RX beam configuration that is aligned with the remaining RX beams of the simultaneous PSFCH reception).

[0236] The WTRU may disable the HARQ feedback for the SL TB. In that case, the WTRU may indicate for the destination WTRU to not report the HARQ feedback in the SCI of that PSSCH resource. The WTRU may not have to perform a reselection of resource (e.g., if the remaining PDB is below a configured threshold or the reselection time limit is passed, or for if a retransmission is reserved that will enable HARQ feedback).

[0237] The WTRU may determine another RX beam to use to receive the conflicted PSFCH resources. The WTRU may (e.g., at least temporarily) reconfigure the RX beam of the PSFCH of these transmissions to the determined RX beam. The RX beam may be determined based on one or more of the following: a (pre)configured RX beam to apply by default if no beam is configured or suitable, or if a beam conflict is detected (e.g., a wide beam); and / or an RX beam that has good signal quality (e.g., RSRP above a threshold) for receiving a transmission from the different destination WTRUs of the conflicted PSSCH transmissions. The WTRU may indicate the determined RX beam to the paired WTRU (e.g., so that the paired WTRU can further adjust the TX beam used to transmit the PSFCH).

[0238] Actions described herein may be performed jointly or repeated on different resources (e.g., until the beam conflicts are solved).

[0239] PSSCH TX beam conflict may be avoided. The WTRU may perform the reevaluation or preemption for beam conflict to avoid transmission conflicts (e.g., avoiding the WTRU transmitting PSCCH / PSSCHs simultaneously with different beams). This may be similar to the feature(s) described herein related to the PSFCH RX beam, with the following changes: a similar configuration and / or indicated information may be used as for RX beam conflict, where the indication of RX beam for PSFCH is replaced by the indication of TX beam for PSCCH / PSSCH; trigger(s) for the reevaluation or preemption of scheduled resources for TX beam conflict may include the WTRU determining that the configured PSCCH / PSSCH TX beam for a scheduled resource is reconfigured; the reconfiguration of the TX beam may occur if: the WTRU receives a beam indication for a PSCCH / PSSCH TX beam from the other WTRU or from the network, or the WTRU determines a new beam for the PSCCH / PSSCH TX beam by the WTRU (e.g., itself). The WTRU may determine a new beam for the PSCCH / PSSCH TX beam based on one or more of:measurements of a SL RS (e.g., SL-SSB, SL-CSI-RS, PSSCH DMRS, PSCCH DMRS) from the destination WTRU; or reception of measurement report from the destination WTRU (e.g., SL CSI report).

[0240] A WTRU may determine which PSSCH resources to evaluate. The set of PSSCH resources determined by the WTRU for TX beam conflict verification may include scheduled resources (e.g., all the scheduled resources) of the WTRU for a given slot (e.g., the slot of the PSSCH transmission that triggered the reevaluation or preemption verification).

[0241] A WTRU may determine that a TX beam conflict exists. The WTRU may determine the TX beam conflict in a similar manner as determination of the RX beam conflict described herein, with the RX beams (for PSFCH) replaced by TX beams (for PSSCH / PSCCH).

[0242] Feature(s) associated with Mode 1 reevaluation and / or preemption are provided herein.

[0243] A WTRU configured with Mode 1 resource allocation (e.g., receiving grants from the network) may perform resource reevaluation or preemption verification for beam conflict.

[0244] In some examples (e.g., in legacy examples up to NR Rel.17), the network may perform resource selection, and the WTRU LCP allocates the granted resource to a TB (e.g., without considering the SL beamforming). A beam conflict verification on the allocated resource may be used (e.g., may be needed). The beam conflict verification on the allocated resource may be similar to other feature(s) described herein (e.g., feature(s) described for Mode 2, both RX or TX beam conflict). The beam conflict verification on the allocated resource may include one or more of the following (e.g., additional) feature(s): additional triggers (e.g., a trigger for the reevaluation or preemption of scheduled resources is if the WTRU receives a new dynamic grant from the network, for example, via DCI, or a configured grant, for example, via RRC configuration or DCI activation, for a SL transmission, and the MAC / LCP allocated the resource to a SL TB.

[0245] The WTRU may perform one or more actions on conflicted resources. Mode 1 WTRUs may not be configured or enabled to perform resource reselection. The resource reselection option may not be applicable to Mode 1 granted conflicted resources. The WTRU may cancel a determined conflicted PSSCH resource. The WTRU may report, to the network, an indication that the transmission was cancelled (e.g., using MAC CE). The report may include information to identify the resources of the cancelled transmission (e.g., time / frequency of the granted resource). The WTRU may indicate for the MAC layer and LCP to reallocate the resource to another destination WTRU (e.g., due to beam conflict).

[0246] In SL HARQ feedback transmissions, there may be a PSFCH resource (e.g., only a single PSFCH resource) that is mapped based on (pre)configuration. There may not be beam consideration for transmission (TX) or RX of the PSFCH.

[0247] One or more PSFCH occasions and PSFCH beam-sweeping may be used (e.g., to avoid beam conflict).

[0248] The SL RX WTRU may repeat the HARQ feedback transmission (e.g., over multiple symbols / occasions). The SL RX WTRU may repeat the HARQ feedback transmission based on a sidelink control information (SCI) indication. The SL TX WTRU may allocate SL resources without RX beam conflicts. The WTRU may monitor PSFCH using beam-sweeping. One or more of the following may be performed.

[0249] A WTRU (e.g., on the data RX side, for example, PSFCH transmitter) may receive a PSFCH resource (pre)configuration in a resource pool. A PSFCH resource may correspond to one or more symbols at a (pre)configured PSFCH occasion. The PSFCH resource (pre)configuration may include an associated PSSCH-to-PSFCH resources mapping (e.g., a 1 -to-N mapping between 1 PSSCH and N PSFCH resources).

[0250] The WTRU may be (pre)configured with a SCI format. The SCI format may include one or more of: a PSFCH resource indication format (e.g., a bitmap or an activation flag), and / or an indication for PSFCH TX beam(s).

[0251] The WTRU may receive a HARQ-enabled PSCCH / PSSCH transmission. The HARQ-enabled sidelink transmission may include sidelink control information (SCI) that indicates an index associated with PSFCH resource selection. The HARQ-enabled PSCCH / PSSCH transmission may include a WTRU source and / or destination ID.

[0252] The WTRU may determine one or more PSFCH resource(s). The WTRU may determine the associated PSFCH TX beam(s). The WTRU may determine the one or more PSFCH resource(s) and / or the associated PSFCH TX beam(s) based on the SCI indication in the received PSCCH / PSSCH, the WTRU source and / or destination IDs, and / or the resource pool (pre)configuration. The WTRU may determine a set of PSFCH resources based on the PSSCH resource and the PSSCH-to-PSFCH resource mapping. For example, the received bit map may indicate a subset of the (pre)configured resources for PSFCH transmissions.

[0253] The WTRU may transmit a PSFCH in a determined resource (e.g., each determined resource). The WTRU may transmit the PSFCH using the determined PSFCH TX beam.

[0254] PSFCH occasions and PSFCH beam-sweeping may be used (e.g., to avoid beam conflict). One or more of the following may be performed.

[0255] A WTRU (e.g., on a data TX side, for example, a PSFCH receiver) may receive a PSFCH resource (pre)configuration in a resource pool. A PSFCH resource may correspond to one or more symbols at a (pre)configured PSFCH occasion. The PSFCH resource (pre)configuration may include an associated PSSCH-to-PSFCH resources mapping (e.g., a 1 -to-N mapping between 1 PSSCH and N PSFCHresources). The PSFCH resource (pre)configuration may include an associated PSFCH-to-RX beam mapping (e.g., a 1 -to-1 mapping between a beam index and a PSFCH resource).

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

[0257] The WTRU may determine one or more PSFCH resource(s). The WTRU may determine the PSFCH RX beam(s) and / or PSFCH TX beam(s) associated with a PSSCH transmission. For example, the WTRU may determine the PSFCH RX beam(s) and / or PSFCH TX beam(s) associated with a PSSCH transmission based on one or more of: a PSFCH resource that maps to the RX PSFCH beam associated with the transmission; a PSFCH resource that is not already associated with a RX beam different than the PSFCH RX beam; and / or multiple PSFCH resources (e.g., if PSFCH RX beam RSRP is below a threshold).

[0258] The WTRU may transmit the PSCCH / PSSCH. The PSCCH / PSSCH may indicate (e.g., in the SCI) the determined PSFCH resource(s) and / or PSFCH beams (e.g., based on the (pre)configured PSFCH indication format).

[0259] The WTRU may receive the indicated PSFCH resource(s) with the determined associated PSFCH RX beams.

[0260] Feature(s) associated with one or more (e.g., multiple) PSFCH occasions and PSFCH beamsweeping are provided herein.

[0261] In SL HARQ feedback transmissions, there may be a PSFCH resource (e.g., only a single PSFCH resource) that is mapped based on (pre)configuration. There may not be beam consideration for transmission (TX) or RX of the PSFCH.

[0262] One or more PSFCH occasions and PSFCH beam-sweeping may be used (e.g., to avoid beam conflict).

[0263] The SL RX WTRU may repeat the HARQ feedback transmission (e.g., over multiple symbols / occasions). The SL RX WTRU may repeat the HARQ feedback transmission based on a sidelink control information (SCI) indication. The SL TX WTRU may allocate SL resources without RX beam conflicts. The WTRU may monitor PSFCH using beam-sweeping. One or more of the following may be performed.

[0264] A WTRU (e.g., on the data RX side, for example, PSFCH transmitter) may receive a PSFCH resource (pre)configuration in a resource pool. A PSFCH resource may correspond to one or more symbols at a (pre)configured PSFCH occasion. The PSFCH resource (pre)configuration may include an associated PSSCH-to-PSFCH resources mapping (e.g., a 1 -to-N mapping between 1 PSSCH and N PSFCH resources).

[0265] The WTRU may be (pre)configured with a SCI format. The SCI format may include one or more of: a PSFCH resource indication format (e.g., a bitmap or an activation flag), and / or an indication for PSFCH TX beam(s).

[0266] The WTRU may receive a HARQ-enabled PSCCH / PSSCH transmission. The HARQ-enabled PSCCH / PSSCH transmission may include a WTRU source and / or destination ID. The HARQ-enabled PSCCH / PSSCH transmission may include SCI that indicates an index (e.g., bit map) associated with PSFCH resource reselection.

[0267] The WTRU may determine one or more PSFCH resource(s). The WTRU may determine the associated PSFCH TX beam(s). The WTRU may determine the one or more PSFCH resource(s) and / or the associated PSFCH TX beam(s) based on the SCI index indication in the received PSCCH / PSSCH, the WTRU source and / or destination IDs, and / or the resource pool (pre)configuration. For example, the received index / bit map may indicate a subset of the (pre)configured resources for PSFCH transmissions.

[0268] The WTRU may transmit a PSFCH in a determined resource (e.g., each determined resource). The WTRU may transmit the PSFCH using the determined PSFCH TX beam.

[0269] PSFCH occasions and PSFCH beam-sweeping may be used (e.g., to avoid beam conflict). One or more of the following may be performed.

[0270] A WTRU (e.g., on a data TX side, for example, a PSFCH receiver) may receive a PSFCH resource (pre)configuration in a resource pool. A PSFCH resource may correspond to one or more symbols at a (pre)configured PSFCH occasion. The PSFCH resource (pre)configuration may include an associated PSSCH-to-PSFCH resources mapping (e.g., a 1 -to-N mapping between 1 PSSCH and N PSFCH resources). The PSFCH resource (pre)configuration may include an associated PSFCH-to-RX beam mapping (e.g., a 1 -to-1 mapping between a beam index and a PSFCH resource).

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

[0272] The WTRU may determine one or more PSFCH resource(s). The WTRU may determine the PSFCH RX beam(s) and / or PSFCH TX beam(s) associated with a PSSCH transmission. For example, the WTRU may determine the PSFCH RX beam(s) and / or PSFCH TX beam(s) associated with a PSSCH transmission based on one or more of: a PSFCH resource that maps to the RX PSFCH beam associated with the transmission; a PSFCH resource that is not already associated with a RX beam different than the PSFCH RX beam; and / or multiple PSFCH resources (e.g., if PSFCH RX beam RSRP is below a threshold).

[0273] The WTRU may transmit the PSCCH / PSSCH. The PSCCH / PSSCH may indicate (e.g., in the SCI) the determined PSFCH resource(s) and / or PSFCH beams (e.g., based on the (pre)configured PSFCH indication format).

[0274] The WTRU may receive the indicated PSFCH resource(s) with the determined associated PSFCH RX beams.

[0275] Flexible PSFCH reporting may be used if multiple PSFCH resources are (pre)configured and / or an indication is transmitted in the SCI for the SL RX WTRU to determine resource(s) on which the WTRU will transmit the PSFCH. The determination of the PSFCH resource(s) (e.g., on the SL TX WTRU side) may be made to avoid RX beam conflicts or to perform beam-sweeping.

[0276] Flexible PSFCH reporting may impact the SL TX WTRU and the SL RX WTRU, as described herein.

[0277] Feature(s) associated with PSFCH occasion mapping and configuration are provided herein.

[0278] The SL TX WTRU and the SL RX WTRU may be (pre)configured in a resource pool (e.g., a resource pool in which: HARQ feedback is enabled; a PSFCH resource corresponds to one or more symbols at a (pre)configured PSFCH occasion; and / or there is an associated PSSCH-to-PSFCH resources mapping, for example, a 1 -to-N mapping between a PSSCH and N PSFCH occasions).

[0279] Different configurations may be possible (e.g., for having multiple PSFCH occasions in a resource pool). The different configurations may correspond to a given PSSCH transmission. The purpose of having multiple PSFCH occasions for a PSSCH (e.g., each PSSCH) is that, by using different beamforming for an occasion (e.g., each occasion), the WTRU may perform a beam-sweeping of the PSFCH. The beam-sweeping may be performed by the SL TX WTRU (e.g., PSFCH reception beamforming) or the SL RX WTRU (e.g., PSFCH TX beamforming). The SL TX WTRU beam-sweeping may solve the PSFCH RX beam conflict (e.g., because the SL TX WTRU receives the PSFCH in at least the right RX beam, assuming that all the configured PSFCH RX beams are used in the beam-sweeping).

[0280] One or more (e.g., multiple) PSFCH occasions for a given PSSCH may be defined within a (e.g., single) slot. A SL slot may be multiplexed in time with one or more (e.g., multiple) PSFCHs (e.g., using non-overlapping symbols of a slot). The different PSFCH occasions in a slot may be consecutive in time. For example, for N=4, four consecutive symbols of a slots may be configured to be four PSFCH occasions (e.g., where each symbol is one of the occasions). FIG. 4 illustrates repeated PSFCH occasions in a single slot. The shading of the PSFCH occasion means that it corresponds to the PSSCH with the same shading. Assuming a single slot delay between PSSCH to PSFCH, a PSSCH may correspond to the four PSFCH symbols / occasions in the following slot, as illustrated in FIG. 4.

[0281] One or more (e.g., multiple) PSFCH occasions for a given PSSCH may be defined across one or more (e.g., multiple slots). The slots may be configured to be consecutive. The position of the PSFCH occasion within the slot may not necessarily be the same across the different slots. A pattern for the position of the PSFCH may be (pre)configured. One or more (e.g., multiple) PSFCH occasions, corresponding to different PSSCHs, may be configured within a slot.

[0282] FIG. 5 illustrates an example rotating PSFCH occasion. The shading of the PSFCH occasion means that the PSFCH occasion corresponds to the PSSCH with the same shading. The index associated with PSFCH resource selection may indicate a PSFCH occasion pattern (e.g., from a (pre)configured set of PSFCH occasion patterns). The WTRU may select the PSFCH resource, from the set of PSFCH resources, based on based on the PSFCH occasion pattern. For example, for N=4, a rotating PSFCH occasion pattern may be defined using four slots and four symbols in each slot. Assuming a single slot delay between PSSCH and PSFCH, a (e.g., one) configuration may be that a PSSCH corresponds to the first PSFCH occasion / symbol in the slot following the PSSCH transmission, to the second occasion / slot in the slot after the first, to the third occasion / symbol in the subsequent slot, and to the fourth occasion / symbol in the following slot, as illustrated in FIG. 5.

[0283] For a given PSSCH, one or more (e.g., multiple) PSFCH occasions may be (pre)configured in a slot and across multiple slots. This option may be a mixture of other feature(s) described herein.

[0284] Although a single symbol per occasion is used as an example herein, multiple symbols may be used for an occasion in a similar manner.

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

[0286] Feature(s) associated with PSFCH occasion sub-selection indication format and configuration are provided herein.

[0287] If configured in a resource pool with multiple PSFCH occasions per PSSCH, a SL RX WTRU may be configured to repeat the PSFCH transmission in the PSFCH occasions (e.g., all the PSFCH occasions) of the PSSCH, or only in a subset of the PSFCH occasions. The repetition and / or subset selection may be semi-statically or dynamically indicated to the WTRU.

[0288] The SL TX WTRU sends an indication in the SCI (e.g., the second-stage SCI) of the PSSCH to indicate the PSFCH occasion(s) to be used by the SL RX WTRU to report HARQ feedback.

[0289] The PSFCH occasion(s) to use for a HARQ report may be indicated using a sequence of bits (e.g., bitmap, bit-string). The nth bit may indicate whether the nth PSFCH occasion is activated for this PSSCH transmission. The size of the sequence may be N. The size of the sequence may be based on the resource pool configuration. This option may provide flexibility to enable any subset of occasions.

[0290] A (e.g., single) PSFCH occasion may be indicated to HARQ report. A PSFCH occasion index may be indicated in the SCI. The indication may be a numeric value (e.g., size is ceil(log2(N))). The value of n may indicate that the PSFCH occasion to use is the nth occasion from the (pre)configured occasions. This option may provide an overhead-efficient indication for a (e.g., single) occasion indication.

[0291] Preselected subsets of PSFCH occasions (or PSFCH patterns) may be (e.g., first) configured for the resource pool. The PSFCH patterns may be subsets (e.g., any subsets) of the PSFCH occasions. A pattern indication may be sent in the SCI. The pattern index may refer to one of the (pre)configured PSFCH pattern of occasions. A (e.g., single) bit binary indication may be configured to use a single PSFCH occasion or to use one or more (e.g., all) of the configured PSFCH occasions.

[0292] The indication may be sent in the SCI. The SCI format to use may be configured (e.g., to avoid blind decoding of different SCI formats). The PSFCH indication in the SCI may be (pre)configured in the resource pool (e.g., using RRC configuration). The configuration may indicate the type of subset selection and subset possible pattern (e.g., if needed). For example, the configuration may indicate a selection between the sequence of bits, the occasion index, and the pattern index.

[0293] The SCI format may be indicated in the PSSCH. If the PSFCH indication is in the 2nd stage SCI, the 1st stage SCI (e.g., which is included in the PSCCH) may indicate the 2nd stage SCI format (e.g., for a set of 2nd stage SCI formats that may include a format with the multiple PSFCH occasion schemes).

[0294] The SCI format with PSFCH indication may be used as a default in resource pools with SL beamforming (e.g., for resource pool on a FR2 carrier).

[0295] The indication may not be sent dynamically in the SCI. The indication may be configured semi- statically (e.g., using RRC configuration and / or MAC CE indication). Other options (e.g., bit sequence, index, pattern index) to identify the PSFCH occasions (e.g., to use as the dynamic options) may be configured for semi-static configurations. The semi-static indication may (de)activate the PSFCH occasion(s) to use for a PSSCH (e.g., each PSSCH) received in that resource pool. The semi-static configuration may indicate that the SL RX WTRU will repeat the PSFCH (e.g., in all the configured PSFCH occasions).

[0296] A delay may be (pre)configured in the resource pool. The delay may indicate how long for a WTRU to wait for the new PSFCH occasions configuration to be effective. The delay may refer to the next PSSCH transmission that implements the indicated PSFCH occasions scheme. The delay may be configured as a number of slots or an absolute time indication.

[0297] The PSFCH resource(s) may be determined at the RX WTRU side.

[0298] A SL RX WTRU may be configured with a resource pool with enabled HARQ feedback. The SL RX WTRU may determine the PSFCH occasion(s) on which to transmit / repeat the HARQ feedback. For example, the SL RX WTRU may determine the PSFCH occasion(s) on which to transmit / repeat the HARQ feedback based on one or more of the following configurations: multiple PSFCH occasions configuration (e.g., number of PSFCH occasions, PSSCH to PSFCH occasions mapping and mapping patterns if any); and / or a PSFCH format indication and an associated configuration (e.g., semi-static or dynamic).

[0299] A SL RX WTRU may be (pre)configured with a dynamic sequence of bits indication for a PSFCH indication in the SCI. The SL RX WTRU may receive an SL transmission on the resource pool. The SL RX WTRU may decode the SCI based on the indicated SCI format. The SL RX WTRU may decode the sequence of bits (e.g., based on the number of PSFCH occasions configured in the resource pool). The SL RX WTRU may read the bits that are active (e.g., set to 1 if active and 0 if not active). The SL RX WTRU may determine the PSFCH occasions on which to transmit the HARQ feedback (e.g., based on the (pre)configured PSSCH-to-PSFCH mapping, the indicated bit sequence, and / or the PSSCH resources). The index associated with PSFCH resource selection may be a bit sequence. The bit sequence may indicate an nth PSFCH resource if an nth bit in the bit sequence is set to one. For example, if N=4 and the sequence is 0101 , the 2nd and 4th PSFCH occasions may be used for PSFCH transmissions. The SL RX WTRU may decode the SL TB. The SL RX WTRU may transmit the associated HARQ feedback on the determined PSFCH occasion(s).

[0300] An SL RX WTRU may be (pre)configured with a semi-static sequence of bits indication for a PSFCH indication in the SCI. The semi-static configuration (e.g., from RRC or MAC CE) may be indicated a sequence of bits (e.g., based on the number of PSFCH occasions configured in the resource pool). Forexample, if N=4 and the sequence is 1000, the 1st PSFCH occasion may be used for PSFCH transmissions of incoming PSSCH transmissions. The SL RX WTRU may receive an SL transmission on the resource pool. The SL RX WTRU may decode the SCI. The SL RX WTRU may determine the PSFCH occasions on which to transmit the HARQ feedback (e.g., based on the (pre)configured PSSCH-to-PSFCH mapping, the indicated bit sequence, and / or the PSSCH resources). The SL RX WTRU may decode the SL TB. The SL RX WTRU may transmit the associated HARQ feedback on the determined PSFCH occasion(s).

[0301] An SL RX WTRU may be (pre)configured with a dynamic occasion index indication for a PSFCH indication in the SCI. The SL RX WTRU may receive a SL transmission on the resource pool. The SL RX WTRU may decode the SCI based on the indicated SCI format. The SL RX WTRU may decode the PSFCH occasion index value (e.g., based on the number of PSFCH occasions configured in the resource pool). The SL RX WTRU may determine the PSFCH occasion on which to transmit the HARQ feedback (e.g., based on the (pre)configured PSSCH-to-PSFCH mapping, the PSSCH resources, and / or the indicated occasion index). The index associated with PSFCH resource selection is a PSFCH occasion index. The PSFCH occasion index may indicate an nth PSFCH resource if a value of the PSFCH occasion index is n. For example, if the value is 3, the 3rdPSFCH occasion may be used for the PSFCH transmission. The SL RX WTRU may decode the SL TB. The SL RX WTRU may transmit the associated HARQ feedback on the determined PSFCH occasion.

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

[0303] An SL RX WTRU may be (pre)configured with a dynamic pattern indication for a PSFCH indication in the SCI. The SL RX WTRU may receive a SL transmission on the resource pool. The SL RX WTRU may decode the SCI (e.g., based on the indicated SCI format). The SL RX WTRU may decode the pattern index (e.g., based on the number of configured patterns). The SL RX WTRU may determine the PSFCH occasions on which to transmit the HARQ feedback (e.g., based on the (pre)configured PSSCH-to- PSFCH mapping, the indicated pattern index, list of configured patterns, and / or the PSSCH resources). Forexample, the pattern may indicate to use the configured PSFCH occasions (e.g., all the configured PSFCH occasions) for the PSSCH. The SL RX WTRU may decode the SL TB. The SL RX WTRU may transmit the associated HARQ feedback on the determined PSFCH occasion(s).

[0304] An SL RX WTRU may be (pre)configured with a semi-static pattern indication for PSFCH indication in the SCI. The semi-static configuration (e.g., from RRC or MAC CE) may indicate the PSFCH occasion pattern or the pattern index to use from a (pre)configured pattern list in the resource pool. For example, the pattern may indicate to use a single transmission corresponding to the 1st PSFCH occasion. The SL RX WTRU may receive a SL transmission on the resource pool. The SL RX WTRU may decode the SCI. The SL RX WTRU may determine the PSFCH occasion on which to transmit the HARQ feedback (e.g., based on the (pre)configured PSSCH-to-PSFCH mapping, the indicated occasion(s) from the pattern, and / or the PSSCH resources). The SL RX WTRU may decode the SL TB. The SL RX WTRU may transmit the associated HARQ feedback on the determined PSFCH occasion(s).

[0305] The PSFCH resource(s) may be determined at the SL TX WTRU side.

[0306] The SL TX WTRU may be (pre)configured on a resource pool with PSFCH occasion(s). The SL TX WTRU may determine the occasion(s) that the RX SL WTRU will use to report the HARQ feedback. The SL TX WTRU may transmit the SL TB and / or the PSFCH indication in the SCI (if any) of the transmission. The SL TX WTRU may receive the PSFCH on the indicated PSFCH occasion(s) (e.g., using its configured PSFCH RX beam).

[0307] The SL TX WTRU may be (pre)configured with a PSFCH occasion-to-RX beam mapping (e.g., based on its RX beam capabilities).

[0308] A (e.g., each) successive PSFCH occasion may correspond to a different RX beam (e.g., so that a group of PSFCH occasions are received using a RX beam sweeping. In a slot, multiple symbols may correspond to different PSFCH occasions, as illustrated in FIG. 4 (e.g., where each PSFCH occasion number will be received with different RX beams).

[0309] A group of successive PSFCH occasions may correspond with a given RX beam. Successive groups may correspond to different RX beams (e.g., as illustrated in Fig. 5, where all the PSFCH of a slot are configured to be received with a given RX beam and each slot will be configured with successively different RX beams).

[0310] A PSSCH (e.g., each PSSCH) may be configured to have at least one PSFCH that corresponds to the correct RX beam for PSFCH reception.

[0311] The SL TX WTRU may determine the PSFCH occasions on which the SL RX WTRU should transmit. The SL TX WTRU may select the PSFCH occasion that maps to the PSFCH RX beam configured to receive the PSFCH corresponding to the destination WTRU of the SL TB. A (e.g., single) PSFCHoccasion may be indicated). The PSFCH occasion may be indicated using the corresponding bit sequence or resource index (e.g., depending on the PSFCH indication configuration). The indication may be performed dynamically (e.g., in the SCI), as illustrated in FIG. 6. The indication may be performed semi- statically (e.g., using an SL MAC CE indication or SL RRC configuration). The semi-static configurations may be updated if (e.g., every time) the WTRU changes its RX beam configuration with a destination WTRU.

[0312] FIG. 6 illustrates example selection / indication of a PSFCH occasion based on a corresponding RX beam.

[0313] The SL TX WTRU may determine several PSFCH occasions for the SL RX WTRU to report (e.g., where each of the PSFCH occasions corresponds to a different RX beam, so that the SL TX WTRU may perform a beam-sweeping of the PSFCH reception). The determination of using beam-sweeping for PSFCH may be based on the signal quality on the SL link (e.g., if the SL-RSRP is below a given threshold). The WTRU may determine a subset (e.g., only a subset) of RX beams on which to perform a beam sweep (e.g., based on the RX RSRP of different RX beams for that destination WTRU).

[0314] If configured with dynamic HARQ feedback indication, the WTRU may indicate (e.g., dynamically indicate) the beam sweeping choice (e.g., by using the bit sequence or beam pattern that corresponds to all the PSFCH occasions).

[0315] The WTRU may be configured to use semi-static configuration. The WTRU may be configured to use SL MAC CE or SL RRC configuration (e.g., to indicate the (de)activation of the PSFCH beamsweeping).

[0316] FIG. 7 illustrates an example of multiple PSFCH occasions used for PSFCH backup.

[0317] The WTRU may determine the PSFCH occasion to use based on the PSFCH RX beam corresponding to the PSSCH transmission and the PSFCH RX beams of other scheduled transmissions. For example, the PSFCH occasions may not be (semi)statically associated with an RX beam at the SL TX WTRU side. The PSFCH occasion to use may be configured (e.g., as a default) to be a PSFCH occasion (e.g., the first occasion, to reduce the 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 (e.g., in Mode 1) for an incoming PSSCH transmission, the WTRU may select one or more other configured PSFCH occasions. This may create a backup PSFCH scheduling (e.g., to dynamically avoid PSFCH beam conflicts). The indication in the SCI (e.g., using beam patterns indication, bit sequence or index) may refer to the PSFCH occasion(s) to use to avoid the beam conflict, as illustrated in FIG. 7.

[0318] The WTRU may be configured with (semi)static PSFCH occasions selection. The WTRU may determine the PSFCH occasion(s) to monitor for a given PSSCH (e.g., based on the configuration and thePSSCH resources). The WTRU may be configured with subset occasion patterns and / or with beamsweeping indications.

[0319] Feature(s) associated with PSFCH TX / RX beam determination and indication are provided herein.

[0320] The WTRU(s) may be configured to (or receive an indication to) perform beam sweeping or to use a constant beam over the different PSFCH resources.

[0321] The SL TX WTRU may be (pre)configured to perform beam-sweeping over the configured PSFCH occasions (e.g., at least by default). The configuration may be an RRC for the resource pool or SL RRC configuration with the paired WTRU. The configuration may be based on WTRU capabilities (e.g., supported number of PSFCH RX beams). In this case, the SL TX WTRU may determine that the SL RX WTRU will perform beam-sweeping (e.g., based on SL link quality, for example, SL-RSRP is below a threshold or instructed by the beam management procedure.) The SL TX WTRU may send an indication (e.g., in the SCI) to trigger a PSFCH TX beam sweeping (e.g., a bit flag). If the SL TX WTRU sends the indication, the SL TX WTRU may not be expected to perform RX beam sweeping over the PSFCH resources associated with the PSSCH.

[0322] The SL RX WTRU may be (pre)configured to transmit PSFCH with a static PSFCH TX beam, over the configured PSFCH occasions, at least by default. The configuration may be an RRC for the resource pool or SL RRC configuration with the paired WTRU. In this case, if the SL RX WTRU receives an indication (e.g., in the SCI) to trigger a PSFCH TX beam sweeping (e.g., a bit flag), the SL RX WTRU may perform TX beam sweeping over the PSFCH resources associated with the PSSCH (e.g., to determine a PSFCH TX beam associated with a PSSCH resource).

[0323] FIG. 8 illustrates an example of a PSFCH repetition indication. As illustrated in FIG. 8, the TX WTRU may send a PSSCH / PSSCH transmission to the RX WTRU. The SCI may include the indication for PSFCH repetition over configured PSFCH occasions in successive PSFCH periods (e.g., via an activation bit-flag). The indication may be joint with an SCI indication that the RX WTRU intends to transmit the PSFCHs using the same or different TX beams. The WTRU may send the PSFCH transmission in a second PSFCH resource in a first PSFCH period and a second PSFCH period (e.g., based on the indication for the first WTRU to perform PSFCH repetition).

[0324] Feature(s) associated with SL RX WTRUs and SL TX WTRUs are provided herein.

[0325] Mode 1 Rx beam conflict avoidance may be used.

[0326] In NR Sidelink Mode 1 resource allocation (e.g., up to Release 17), the network may perform the resource scheduling. The network may send a SL grant to the WTRU (e.g., using a DCI, for example, DCI 3_0). The DCI may include the resource indications (e.g., time and frequency) to use. The DCI may notindicate the SL TB or SL WTRU that the grant is targeting. At the SL TX WTRU side, if receiving a Mode 1 grant, the granted resources may be used by the MAC layer for logical channel prioritization (LCP). The LCP may determine which logical channel (LC) has the highest priority (e.g., based on data priority and / or latency considerations). The WTRU may allocate the granted resources to the SL TB of the determined highest priority LC. In SL, an LC may correspond to a (e.g., single) WTRU.

[0327] The network may not know of the beams that the WTRU will use for the transmission. The network may not know the destination WTRU associated with the transmission that will use the granted resources. This may not be an issue in the case of non-directional SL transmission. Using directional beams for reception and transmission with limited number of simultaneous beams may lead to beam conflicts.

[0328] In SL resource allocation (e.g., Mode 1 SL resource allocation), beam information may not be considered at the network side. The WTRU may allocate the granted resource via LCP to the LC (e.g., based on priority and / or timing). There may not be beam consideration at the LCP side.

[0329] LCP-based prioritization (e.g., Mode 1) may be used (e.g., to avoid PSFCH RX beam conflict).

[0330] If the resource is selected by a gNB (e.g., without WTRU beam knowledge), the SL WTRU LCP may add a criterion to select the WTRU / TB that would avoid RX PSFCH beam conflict. One or more of the following may be performed.

[0331] A WTRU may be (pre)configured with PSFCH occasions in a resource pool and / or a HARQ processing period. The WTRU may receive an indication of one or more of the following parameters: PSFCH RX beams of the WTRUs that have an active SL connection; a destination WTRU ID of the SL TB (e.g., for a PSSCH transmission of a HARQ-enabled SL TB on that resource pool); the reserved PSSCH resources (e.g., for a PSSCH transmission of a HARQ-enabled SL TB on that resource pool); a PSSCH-to- PSFCH resource mapping; and / or the associated PSFCH resource and PSFCH RX beam (e.g., for a PSSCH transmission of a HARQ-enabled SL TB on that resource pool).

[0332] The WTRU may transmit a sidelink buffer status report (SL-BSR) to the network. The SL-BSR may include one or more (e.g., different) WTRU destinations.

[0333] The WTRU may receive a grant of a PSSCH resource from the network (e.g., via DCI) for SL transmission (e.g., SL Mode 1 ).

[0334] The WTRU may determine the PSFCH resource associated with the PSSCH resource of the received grant (e.g., based on the PSSCH-to-PSFCH resource mapping configuration).

[0335] The WTRU may determine that the PSFCH resource is simultaneous with the PSFCH resource of an already scheduled transmission.

[0336] The WTRU may determine (e.g., for the logical channels having available SL data to transmit) a PSFCH RX beam associated with the granted PSSCH resource (e.g., corresponding with the transmission of a PSSCH to the destination WTRU associated with the logical channels).

[0337] The WTRU may select the logical channel with available SL data that has the highest priority. The WTRU may select the logical channel for which the RX PSFCH beam is the same as the RX PSFCH beam of the already reserved / scheduled transmissions.

[0338] The WTRU may allocate the received grant to the selected logical channel. The WTRU may transmit the PSCCH / PSSCH on the granted resource. The WTRU may receive the corresponding PSFCH using the determined RX PSFCH beam.

[0339] The WTRU may transmit an updated SL-BSR to the network.

[0340] Feature(s) associated with using LCP to select an LC that avoids a beam conflict are provided herein.

[0341] In SL resource allocation (e.g., Mode 1 SL resource allocation), beam information may not be considered at the network side. The WTRU may allocate the granted resource via LCP to the LC (e.g., based on priority and / or timing). There may not be beam consideration at the LCP side.

[0342] LCP-based prioritization (e.g., Mode 1) may be used (e.g., to avoid PSFCH RX beam conflict).

[0343] If the resource is selected by a gNB (e.g., without WTRU beam knowledge), the SL WTRU LCP may add a criterion to select the WTRU / TB that would avoid RX PSFCH beam conflict. One or more of the following may be performed.

[0344] A WTRU may be (pre)configured with PSFCH occasions in a resource pool and / or a HARQ processing period. The WTRU may receive an indication of one or more of the following parameters: PSFCH RX beams of the WTRUs that have an active SL connection; a destination WTRU ID of the SL TB (e.g., for a PSSCH transmission of a HARQ-enabled SL TB on that resource pool); the reserved PSSCH resources (e.g., for a PSSCH transmission of a HARQ-enabled SL TB on that resource pool); a PSSCH-to- PSFCH resource mapping; and / or the associated PSFCH resource and PSFCH RX beam (e.g., for a PSSCH transmission of a HARQ-enabled SL TB on that resource pool).

[0345] The WTRU may transmit a sidelink buffer status report (SL-BSR) to the network. The SL-BSR may include one or more (e.g., different) WTRU destinations.

[0346] The WTRU may receive a grant from the network (e.g., via DCI) for SL transmission (e.g., SL Mode l).

[0347] The WTRU may determine the PSFCH resource associated with the PSSCH resource of the received grant (e.g., based on the PSSCH-to-PSFCH resource mapping configuration).

[0348] The WTRU may determine that a beam conflict exists between a first PSFCH RX beam associated with the granted PSSCH resource and a second PSFCH RX beam associated with the reserved PSSCH resource. For example, the WTRU may determine that the PSFCH resource is simultaneous with the PSFCH resource of a reserved (e.g., already scheduled) transmission.

[0349] Based on the determination that the beam conflict exists between the first PSFCH RX beam and the second PSFCH RX beam, the WTRU may select an LC associated with a third PSFCH RX beam that is aligned with the first PSFCH RX beam. For example, the WTRU may determine (e.g., for the logical channels having available SL data to transmit) a PSFCH RX beam corresponding with the transmission of a PSSCH to the destination WTRU associated with the logical channels.

[0350] The WTRU may select the LC by determining a set of LCs associated with PSFCH RX beams that are aligned with the first PSFCH RX beam and selecting the LC (e.g., from the set of LCs) based on a priority associated with the LC. For example, the WTRU may select the logical channel with available SL data that has the highest priority. The WTRU may select the logical channel for which the RX PSFCH beam is the same as the RX PSFCH beam of the already reserved / scheduled transmissions.

[0351] The WTRU may allocate the received grant to the selected logical channel. The WTRU may transmit the PSCCH / PSSCH on the granted resource. The WTRU may receive the corresponding PSFCH using the determined RX PSFCH beam.

[0352] The WTRU may transmit an updated SL-BSR to the network.

[0353] The gNB may not be aware of the beams used by WTRUs in SL (e.g., while preparing the SL grant). The SL TX WTRU may decide a destination WTRU for which a received SL grant will be used (e.g., to avoid beam conflicts). LCP may be adapted to take beams and / or other scheduled transmissions into account (e.g., while selecting the LC).

[0354] A SL TX WTRU may be configured with resource allocation Mode 1 on a resource pool supporting. The SL TX WTRU may be configured with HARQ feedback. The SL TX WTRU may use beamformed SL transmissions.

[0355] The WTRU may be connected in SL with one or more WTRUs. Each of the WTRUs may be assigned a different LC. The WTRU may transmit an SL-BSR to the gNB. The SL-BSR may include one or more destination WTRU IDs. The WTRU may receive the SL grant from the network. The WTRU may determine the granted PSSCH resources.

[0356] Potential PSFCH RX beam conflict transmissions may be determined.

[0357] The SL TX WTRU may determine a list of PSFCH RX beam conflicted WTRU pairs. The list of conflicted WTRU pairs may list WTRU combinations (e.g., all WTRU combinations) that would lead to aPSFCH RX beam conflict (e.g., if they were to transmit PSFCH to the SL TX WTRU at the same time). A conflicted pair may be determined based on the PSFCH RX beams for two of the destination WTRU IDs not being aligned. RX beam conflict determination is described herein. A conflicted pair may be determined based on the destination WTRU IDs being different. For example, the WTRU may avoid PSFCH RX beam conflict by avoiding receiving PSFCH from two or more different WTRUs. This may reduce the scheduling flexibility and may avoid additional inter-layer information sharing.

[0358] The WTRU may determine a potential RX beam conflict if the RX beam indexes for the reserved and transmissions being scheduled are different. The WTRU may determine a potential RX beam conflict if the TCI state used for the RX beams for the reserved and transmissions being scheduled are different (e.g., different TCI index or using different RS).

[0359] The WTRU may determine a potential RX beam conflict if the RX beams are using TX-RX beam correspondence and the TX beam indexes for the reserved and transmissions being scheduled are different. The WTRU may determine a potential RX beam conflict if the RX beams are indicated using different indication methods between the reserved and transmissions being scheduled are different (e.g., a beam index and a TCI state). For example, the WTRU may determine a potential RX beam conflict if the PSFCH RX beam associated with the reserved PSSCH resource is indicated using a first indication type, and the PSFCH RX beam associated with the sidelink TB is indicated using a second indication type, different from the first indication type.

[0360] The WTRU may determine a potential RX beam conflict if the WTRU destination IDs of the reserved and transmissions being scheduled are different. In this case, the WTRU may be able to perform a comparison without a beam indication. The WTRU may determine a potential RX beam conflict if the correlation of the RX beams of the reserved and transmissions being scheduled is below a ((pre)configured) threshold (e.g., based on the WTRU knowledge of its beams, for example, based on the weights applied or the spatial domain filters used to generate the beams).

[0361] The WTRU may determine a potential RX beam conflict if signal reception via the PSFCH RX beam associated with the reserved PSSCH resource is below a quality threshold. For example, the WTRU may determine the potential RX beam conflict if the WTRU estimates that the reception of a signal from the destination WTRU (e.g., using the RX beam configured to receive the reserved transmission) would be of low quality (e.g., the RSRP below a threshold). The estimation may be based on previous measurements (e.g., during beam management).

[0362] The WTRU (e.g., MAC layer) may receive an indication of the following information: PSFCH RX beam conflicted WTRU pairs; and / or (e.g., for each already scheduled SL transmission with 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 resource. The associated PSFCH resource of the already scheduled transmissions may be given (e.g., explicitly) or determined based on the reserved PSSCH resources and the resource pool configuration.

[0363] The WTRU may determine the PSFCH resource associated with the granted PSSCH (e.g., based on the resource pool configuration). The WTRU may verify whether the PSFCH resource of the granted PSSCH is simultaneous with (e.g., occurs in a same time slot as) the PSFCH resource of an already scheduled transmission (e.g., based on the indicated information).

[0364] If the PSFCH resource of the granted PSSCH is not simultaneous with (e.g., does not occur in a same time slot as) the PSFCH resource of an already scheduled transmission, LCP may be performed (e.g., similar to legacy behavior).

[0365] If the PSFCH resource of the granted PSSCH is simultaneous with (e.g., occurs in a same time slot as) the PSFCH resource of an already scheduled transmission, LCP is adapted as follows. An LC subset may be determined. If the WTRU identifies a PSFCH potential conflict, the WTRU may determine the (e.g., first) destination WTRU ID of the reserved (e.g., already scheduled) PSSCH associated with the PSFCH that is simultaneous with the granted PSFCH. The WTRU may determine (e.g., for each LC having available SL data to transmit) the destination WTRU ID associated with of the LC.

[0366] The WTRU may determine the subset of LCs that are associated with a WTRU that is not paired with the conflicted WTRU ID of the already scheduled transmission. For example, the WTRU may determine a set of LCs that are associated with a second destination WTRU identifier that is different from the first destination WTRU identifier (e.g., associated with the reserved PSSCH resource). The WTRU may select an LC, from the set of LCs, based on a priority associated with the LC. If the pairs of conflicted WTRUs are based (e.g., directly) on having different WTRU IDs, the WTRU may select, for the LC subset, the LC(s) that correspond to the same destination WTRU ID. A destination WTRU ID may be mapped to multiple LCs (e.g., with different priority or QoS settings).

[0367] The PSFCH RX beam of the transmissions may be given (e.g., explicitly instead of the WTRU conflict pairs and WTRU destination IDs). The WTRU may select, for the LC subset, the LC(s) that correspond to PSFCH RX beam(s) that are aligned / not in conflict with the PSFCH RX beam of the already scheduled transmission.

[0368] Among the determined subset of LC, the WTRU may determine the LC that has the highest priority (e.g., based on the transmission priority, maximum PDB and time in the queue of the LC, etc., for example, similar to legacy LCP but for a non-confl icted subset of LCs).

[0369] The granted PSSCH resource may be allocated to the SL data of the determined highest priority LC that does not have a beam conflict. The WTRU may transmit the SL data TB on the granted PSSCH.

[0370] The WTRU may transmit a SL-BSR to the network to indicate the updated buffer status. The updated buffer status may indicate to the network that the grant did not necessarily go to the highest priority LC (e.g., due to beam conflict).

[0371] Feature(s) associated with LCP-based PSSCH TX beam conflict avoidance are provided herein.

[0372] LCP may be used (e.g., adapted) to avoid the PSSCH TX beam conflict of the SL TX WTRU.Feature(s) associated with beamformed transmission conflicts are provided herein. The WTRU may not be configured on a resource pool supporting HARQ feedback.

[0373] The SL TX WTRU may determine a list of PSSCH TX beam conflicted WTRU pairs. The list of conflicted WTRU pairs may list WTRU combinations (e.g., all WTRU combinations) that would lead to a PSSCH TX beam conflict if the SL TX WTRU were to transmit PSSCH to the WTRUs in the pair at the same time. A conflicted pair may be determined based on: the PSSCH TX beams for two of the destination WTRU IDs not being aligned (e.g., using TX beam conflict determination, as described herein); or the destination WTRU IDs being different. If the conflicted paid is determined based on destination WTRU IDs, the WTRU may avoid PSSCH TX beam conflicts by avoiding transmitting to two different WTRUs at the same time. This may reduce the scheduling flexibility and avoid additional inter-layer information sharing.

[0374] The WTRU (e.g., MAC layer) may receive an indication of the following information: PSSCH TX beam conflicted WTRU pairs; and / or (e.g., for each already scheduled SL transmission) the destination WTRU ID of the SL TB, and / or the scheduled PSSCH resources.

[0375] The WTRU may be connected in SL with one or more (e.g., multiple) WTRUs. The WTRUs (e.g., each of the WTRUs may be assigned a different LC. The WTRU may transmit the SL-BSR to the gNB. The SL-BSR may include one or more (e.g., multiple) destination WTRU IDs.

[0376] The WTRU may receive an SL grant from the network. The WTRU may determine the granted PSSCH resources. The WTRU may verify whether the granted PSSCH resource is simultaneous with (e.g., occurs in a same time slot as) the PSSCH resource of an already scheduled transmission (e.g., based on the indicated information). If the granted PSSCH resource is not simultaneous with (e.g., does not occur in a same time slot as) the PSSCH resource of an already scheduled transmission, LCP may be performed in a similar manner as legacy behavior.

[0377] If the granted PSSCH resource is simultaneous with (e.g., occurs in a same time slot as) the PSSCH resource of an already scheduled transmission, LCP may be adapted as described herein.

[0378] The granted PSSCH resource may be allocated to the SL data of the determined highest priority LC that does not have beam conflict. The WTRU may transmit the SL data TB on the granted PSSCH. The WTRU may transmit an SL-BSR to the network (e.g., to indicate the updated buffer status). The SL-BSRmay indicate to the network that the grant did not necessarily go to the highest priority LC (e.g., due to beam conflict).

[0379] LCP-based feature(s) described herein for SL Mode 1 may similarly apply to SL resource allocation Mode 2 (e.g., because LCP is also used to allocate an autonomously selected PSSCH resource to LCs). For example, LCP-based feature(s) may be used if resource selection is not performed with beam conflict considerations.

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

[0381] WTRU-assisted scheduling with beam information may be used (e.g., in Mode 1), for example, to avoid PSFCH beam conflict.

[0382] The WTRU may send an indication to the network. The indication may allow the network to determine the beam conflicts and perform proper scheduling. The scheduling grant may indicate a WTRU targeted by the grant (e.g., so that the WTRU’s LCP can allocate the grant to the correct WTRU). One or more of the following may be performed.

[0383] A WTRU may transmit, to the network, an indication of the beam conflict(s) between different WTRUs (e.g., using MAC CE or RRC). For example, the WTRU may send an indication of a beam conflict associated with two or more other WTRUs (e.g., a first and second WTRU). The WTRU may indicate a first identifier associated with the first WTRU and a second identifier associated with the second WTRU. The WTRU may send a WTRU-to-PSFCH RX beam mapping (e.g., beam ID or TCI state) for the connected SL WTRUs. The WTRU may send a list of WTRU pairs that would experience a beam conflict.

[0384] The WTRU may transmit a SL-BSR to the network. The SL-BSR may include different WTRU destinations (e.g., WTRU identifiers).

[0385] The WTRU may receive a grant of sidelink resource(s) (e.g., a SL grant) from the network (e.g., via DCI) for SL transmission (SL Mode 1). The SL grant may include an indication of a WTRU identifier (e.g., a destination WTRU ID) with which the grant is associated.

[0386] The WTRU may select a logical channel associated with the identifier indicated in the SL grant. The WTRU may select the logical channel with available SL data that has the highest priority. The WTRU may select the logical channel with available SL data that has the highest priority and for which the destination WTRU ID is the same as the destination WTRU ID indicated in the scheduling grant.

[0387] The WTRU may transmit, on the granted sidelink resource, a sidelink transmission associated with the selected logical channel. The WTRU may transmit the TB of the destination WTRU ID (e.g., on thegranted PSCCH / PSSCH resources). The WTRU may receive a PSFCH transmission using (e.g., with) the associated PSFCH RX beam (e.g., the PSFCH RX beam associated with the granted sidelink resource).

[0388] Mode 1 resource selection may be performed with WTRU beam conflict information assistance.

[0389] WTRU-assisted scheduling with beam information may be used (e.g., in Mode 1), for example, to avoid PSFCH beam conflict.

[0390] The WTRU may determine that a beam conflict exists between two or more WTRUs. For example, the WTRU may determine a potential RX beam conflict if the RX beam indexes for the reserved and transmissions being scheduled are different. The WTRU may determine a potential RX beam conflict if the TCI state used for the RX beams for the reserved and transmissions being scheduled are different (e.g., different TCI index or using different RS).

[0391] The WTRU may determine a potential RX beam conflict if the RX beams are using TX-RX beam correspondence and the TX beam indexes for the reserved and transmissions being scheduled are different. The WTRU may determine a potential RX beam conflict if the RX beams are indicated using different indication methods between the reserved and transmissions being scheduled are different (e.g., a beam index and a TCI state). For example, the WTRU may determine a potential RX beam conflict if the PSFCH RX beam associated with the reserved PSSCH resource is indicated using a first indication type, and the PSFCH RX beam associated with the sidelink TB is indicated using a second indication type, different from the first indication type.

[0392] The WTRU may determine a potential RX beam conflict if the WTRU destination IDs of the reserved and transmissions being scheduled are different. In this case, the WTRU may be able to perform a comparison without a beam indication. The WTRU may determine a potential RX beam conflict if the correlation of the RX beams of the reserved and transmissions being scheduled is below a ((pre)configured) threshold (e.g., based on the WTRU knowledge of its beams, for example, based on the weights applied or the spatial domain filters used to generate the beams).

[0393] The WTRU may determine a potential RX beam conflict if signal reception via the PSFCH RX beam associated with the reserved PSSCH resource is below a quality threshold. For example, the WTRU may determine the potential RX beam conflict if the WTRU estimates that the reception of a signal from the destination WTRU (e.g., using the RX beam configured to receive the reserved transmission) would be of low quality (e.g., the RSRP below a threshold). The estimation may be based on previous measurements (e.g., during beam management).

[0394] The WTRU may send an indication to the network. The WTRU may send an indication of a beam conflict associated with two or more WTRUs (e.g., a first WTRU and a second WTRU). The WTRU may indicate a first identifier associated with the first WTRU, and a second identifier associated with the secondWTRU. The indication may allow the network to determine the beam conflicts and perform proper scheduling. The scheduling grant may indicate a WTRU targeted by the grant (e.g., so that the WTRU’s LCP can allocate the grant to the correct WTRU). One or more of the following may be performed.

[0395] A WTRU may transmit, to the network, an indication of the beam conflict(s) between different WTRUs (e.g., using MAC CE or RRC). The WTRU may send a WTRU-to-PSFCH RX beam mapping (e.g., beam ID or TCI state) for the connected SL WTRUs. The WTRU may send a list of WTRU pairs that would experience a beam conflict.

[0396] The WTRU may transmit a SL-BSR to the network. The SL-BSR may include different WTRU destinations.

[0397] The WTRU may receive a grant of a sidelink resource (e.g., a SL grant) from the network (e.g., via DCI) for SL transmission (SL Mode 1). The SL grant may include an indication of an identifier (e.g., a destination WTRU ID) with which the grant is associated. For example, the grant may indicate the first identifier associated with the first WTRU.

[0398] The WTRU may select a logical channel associated with the indicated identifier (e.g., the first identifier in the example above). For example, a logical channel associated with the first identifier may be associated with first sidelink data with a first priority level, and a logical channel associated with the second identifier may be associated with second sidelink data with a second priority level. The WTRU may compare the first priority level to the second priority level. On a condition that the first priority level is higher than the second priority level, the WTRU may select the logical channel associated with the first identifier. The WTRU may select the logical channel with available SL data that has the highest priority. The WTRU may select the logical channel with available SL data that has the highest priority and for which the destination WTRU ID is the same as the destination WTRU ID indicated in the scheduling grant.

[0399] The WTRU may transmit, on the granted sidelink resource, a sidelink transmission associated with the selected logical channel. For example, the WTRU may transmit the TB of the destination WTRU ID (e.g., on the granted PSCCH / PSSCH resources). The WTRU may receive the PSFCH transmission using / with the associated PSFCH RX beam.

[0400] The WTRU may send, to the network, beam conflict information (e.g., so that the network may perform a beam-aware resource allocation). The WTRU may receive a grant. The grant may include a WTRU / beam indication (e.g., so that the WTRU can map the grant with the intended WTRU destination / beam).

[0401] Feature(s) described herein may be a “proactive” version of other feature(s) described herein.

[0402] An SL TX WTRU may be configured with resource allocation Mode 1 on a resource pool supporting and configured with HARQ feedback. The SL TX WTRU may use beamformed SL transmissions.

[0403] A beam conflict indication may be transmitted. The WTRU may be (pre)configured to report an indication of potential scheduling conflict to the network (e.g., indicating the potential PSSCH TX beam conflicts and / or PSFCH RX beam conflict). The network may use the conflict information to schedule the resources to the SL TX WTRU in Mode 1 (e.g., based on already scheduled transmissions and the SL-BSR information).

[0404] The WTRU may send, to the network, an indication of beam conflicts for the WTRUs to which the WTRU has connections (e.g., at least for the WTRUs associated with an LC or the WTRUs indicated in the SL-BSR). The indication may be sent using a MAC CE message (e.g., a new MAC CE message) or RRC. The indication may be for PSFCH RX beam conflicts and / or for PSSCH TX beam conflicts.

[0405] The indication may be a list of WTRU pairs that have beam conflicts (e.g., determined as described herein). The gNB may use the WTRU ID from the SL-BSR and the WTRU pair conflicts indication to avoid simultaneous transmissions of PSSCH or to avoid scheduling a PSSCH that would lead to a PSFCH RX beam conflict. The gNB may determine the PSFCH corresponding to the transmissions based on the resource pool configuration.

[0406] The indication may be updated if the list of conflicted pairs is updated (e.g., following a change in beam association between the SL TX WTRU and a destination WTRU). The update may be incremental (e.g., only indicating the pairs of conflicts to add and / or to remove).

[0407] The WTRU may send a SL-BSR to the network. The SL-BSR may include one or more destination WTRU IDs, the corresponding logical channel group (LCG) ID, and / or their corresponding buffer size.

[0408] The LCs of destination WTRU IDs may be regrouped into a (e.g., single) LCG (e.g., there may be a one-to-one mapping between the WTRU ID and LCG ID, and the information may be used interchangeably).

[0409] A grant with an indication and LCP mapping may be received. The WTRU may receive a grant from the network (e.g., using DCI). The grant may include the reserved resource. The grant may include an indication of the corresponding LCG ID or destination WTRU ID. The indication in the grant may enable the network to associate the grant with a destination. This may enable the WTRU to follow the scheduling of the network.

[0410] The WTRU may read the LCG or WTRU IDs that corresponds to the received grant. The WTRU may indicate, to the LCP, the granted resource and the corresponding WTRU ID or LCG ID.

[0411] The LCP procedure may determine the subset of LCs that correspond to the WTRU ID / LCG ID indicated in the received grant. For example, the WTRU may determine, based on the indication of the first identifier in the grant, a set of WTRUs that are compatible with the second WTRU. The WTRU may determine a set of logical channels associated with the set of WTRUs. The WTRU may select the logical channel from the set of logical channelsThe LCP may proceed with the selection of the LC (e.g., from the subset of LCs) that has the highest priority in terms of SL data priority and timing considerations (e.g., similar to legacy LCP, but on the determined subset of LCs).

[0412] The WTRU may transmit the SL data of the determined LC on the granted PSSCH resources.

[0413] Explicit beam indications may be used. The WTRU send explicit beam conflict indications (e.g., rather than WTRU conflict information). In this case, the LCP may be adapted so that the WTRU has more flexibility to allocate any WTRU that matches the beam (e.g., rather than a single WTRU).

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

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

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

[0417] The WTRU may transmit the SL-BSR to the network. The WTRU may receive an SL grant (e.g., using DCI). The DCI may include the granted resources and the PSSCH TX and / or PSFCH RX beam indication(s).

[0418] The WTRU may determine (e.g., based on the configured beams for each WTRUs) the list of WTRU(s) that are compatible with the beam(s) indicated in the grant (e.g., the WTRUs configured with the same beam(s) or with beams that are not in conflict).

[0419] LCP may be indicated with a list of suitable WTRUs for a grant. The LCP may sub-select the LCs associated with the suitable WTRUs. The LCP may select the highest priority LC among the subset of LCs. The WTRU may transmit the SL data of the determined LC on the granted PSSCH resources.

[0420] In SL resource selection (e.g., Mode 2 SL resource selection), sensing may not be performed with beamforming. The candidate resources in the resource selection window may not be evaluated with respect to the TX beam of the transmission.

[0421] WTRU TX-beam-specific resource selection may be based on sensing information. The sensing information may be obtained in sensing occasions using RX beam corresponding to the TX beam.

[0422] The SL sensing may be performed with beamforming. The candidate resources in the resource selection window may be based on the TX beams and / or the sensing information corresponding to the TX beam. One or more of the following may be performed.

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

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

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

[0426] The WTRU may receive a sidelink transport block associated with a transmit (TX) beam. The WTRU may determine sensing occasions in a sensing window corresponding to the TX beam associated with the (e.g., unicast) transmission to a peer WTRU. The sensing occasions may use a RX beam thatcorresponds to the TX beam (e.g., based on beam correspondence). For example, the WTRU may determine that the first RX beam and the first sensing occasion are associated with the TX beam.

[0427] The WTRU may determine a candidate resource set (e.g., including all candidate resources at the determined (first) sensing occasion(s)). If the number of determined candidate resources is lower than a (pre)configured threshold, the WTRU may indicate a resource selection failure to MAC layer.

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

[0429] The WTRU may transmit a sidelink transport block (e.g., PSCCH / PSSCH) in a determined available candidate resource (e.g., using the TX beam associated with the unicast link).

[0430] WTRU TX-beam-specific resource selection may be performed, for example, based on sensing information obtained in sensing occasions using RX beam corresponding to the TX beam.

[0431] In SL resource selection (e.g., Mode 2 SL resource selection), sensing may not be performed with beamforming. The candidate resources in the resource selection window may not be evaluated with respect to the TX beam of the transmission.

[0432] WTRU TX-beam-specific resource selection may be based on sensing information. The sensing information may be obtained in sensing occasions using RX beam corresponding to the TX beam. For example, the WTRU may (pre)configured with a sensing RX beam-to-TX beam mapping. The WTRU may determine that the first RX beam and the first sensing occasion are associated with the TX beam based on the sensing RX beam-to-TX beam mapping.

[0433] The SL sensing may be performed with beamforming. The candidate resources in the resource selection window may be based on the TX beams and / or the sensing information corresponding to the TX beam. One or more of the following may be performed.

[0434] A WTRU may perform SL sensing in a sensing occasion (e.g., each sensing occasion). The WTRU may perform SL sensing using an associated RX beam in a sensing window. For example, the WTRU may determine (e.g., (e.g., based on a first transmission received via a first RX beam) first sidelink sensing information associated with a first sensing occasion. The WTRU may determine (e.g., based on a second transmission received via a second RX beam) second sidelink sensing information associated with a second sensing occasion. The association between RX beam and sensing occasion may be based on a (pre)configuration. The association between RX beam and sensing occasion may be based on a number of unicast links using the RX beam.

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

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

[0437] The WTRU may determine sensing occasions in a sensing window corresponding to the TX beam associated with the unicast transmission to a peer WTRU. The sensing occasions may use a RX beam that corresponds to the TX beam (e.g., based on beam correspondence).

[0438] The WTRU may determine a candidate resource set (e.g., including all candidate resources at the determined sensing occasions). If the number of determined candidate resources is lower than a (pre)configured threshold, the WTRU may indicate a resource selection failure to MAC layer.

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

[0440] The WTRU may transmit PSCCH / PSSCH in a determined available candidate resource (e.g., using the TX beam associated with the unicast link).

[0441] Directional Mode 2 SL sensing may be based on a sensing RX beam.

[0442] A WTRU may perform Mode 2 sensing to acquire SL sensing information for resource selection. In SL FR1 operation, a WTRU may apply an omni-directional sensing RX beam to perform Mode 2 sensing. The WTRU may be able to receive PSCCH transmission(s) arriving at different incoming directions. In SL FR2 operation (e.g., to improve link performance), a WTRU may apply a directional sensing RX beam for PSCCH reception (e.g., to enable beamforming gain). The beamwidth and direction of a sensing RX beam may be based on a receive spatial domain filter used for the Mode 2 sensing. A direction of a RX beam may denote a spatial direction where the maximum gain of the RX beam is present.

[0443] A WTRU may (e.g., in directional Mode 2 sensing) receive PSCCH in a PSCCH candidate resource (e.g., each PSCCH candidate resource) at a sensing occasion within in a sensing window. A WTRU may perform the PSCCH reception using a sensing RX beam at a sensing occasion (e.g., each sensing occasion). If a PSCCH is detected (e.g., a PSCCH CRC check is successful), a WTRU may decode the PSCCH. The WTRU may acquire SL control information (SCI). The SCI may include resource reservation information. The WTRU may measure a DMRS associated with the decoded PSCCH and / orthe associated PSSCH in the same transmission. The WTRU may acquire a sensing RSRP value associated with a decoded SCI and sending occasion (e.g., each decoded SCI and sensing occasion).

[0444] Feature(s) associated with a sensing configuration are provided herein. To perform directional Mode 2 sensing, a WTRU may be (pre)configured in a resource pool with one or more of the following Mode 2 sensing configuration information. The WTRU may be (pre)configured with a sensing occasion. A sensing occasion may be a slot, one or more symbols in one slot, a sub-frame in a resource pool, and / or the like. The WTRU may be (pre)configured with a PSCCH candidate resource. A PSCCH candidate resource may include a time and frequency resource allocation for PSCCH transmission and / or reception. A PSCCH time resource may include the first N symbols in a slot (e.g., where the value of N may be (pre)configured). A frequency resource may be one or more RB(s) and / or sub-carrier(s) in a sub-channel in a resource pool. The RB(s) and / or sub-carrier(s) may be the RB(s) and / or sub-carrier(s) with the lowest RB and / or sub-carrier index(es) in a sub-channel. The WTRU may be (pre)configured with a sensing window. A sensing window (pre)configuration may include a duration (e.g., length) of the window (e.g., in units of milliseconds and / or slots in a resource pool).

[0445] A sensing RX beam may be determined. A WTRU may determine a sensing RX beam to associate with a sensing occasion (e.g., each sensing occasion) within a sensing window. For example, the WTRU may determine the sensing RX beam based on a sensing RX beam (pre)configuration. A WTRU may be (pre)configured with a periodical sensing RX beam to use for a slot (e.g., each slot) in a resource pool. A periodic sensing RX beam (pre)configuration may include a set of RX beam indication (s). The WTRU may apply an indicated RX beam according to the sequential order of the RX beam indication(s). A RX beam indication may include an RX beam index, an SL TCI state of an RX beam, and / or the like.

[0446] The WTRU may determine the sensing RX beam based on a PSSCH RX beam to use at a sensing occasion. A WTRU may use a sensing RX beam based on a PSSCH RX beam to use at a sensing occasion. The WTRU may use a sensing RX beam that covers a PSSCH reception RX beam to use at a sensing occasions. A sensing RX beam may be (e.g., may be identical to) the PSSCH RX beam (e.g., with an identical RX beam index and / or SL TCI state). If no PSSCH RX beam is to be used at a sensing occasion, the WTRU may apply a sensing RX beam based on a sensing RX beam (pre)configuration.

[0447] The WTRU may determine a PSSCH RX beam to use for a sensing occasion based on one or more of the following: a PSSCH RX beam associated with an SL; semi-persistent scheduling information of PSSCH reception of an SL; a number of operated SLs; a traffic pattern of an SL; and / or a resource selection status.

[0448] A WTRU may operate a number of SLs (e.g., broadcast, groupcast, and / or unicast SLs). An SL (e.g., each SL) may be identified by a WTRU destination ID (e.g., for broadcast or groupcast SL) or a pairof WTRU source and destination ID (e.g., for unicast SL). A WTRU may perform SL beam pairing (e.g., to determine a PSSCH TX and / or PSSCH RX beam associated with a SL, for example, with a WTRU destination and / or source ID).

[0449] A WTRU may determine a PSSCH RX beam to use for a slot (e.g., each slot) based on the number of operated SLs and / or traffic pattern. For example, a WTRU may allocate a set of slots in a resource pool to an operated SL (e.g., each operated SL). The WTRU may determine to use PSSCH RX beam associated with the SL in a set of slots (e.g., each set of slots). A WTRU may determine the number of slots in a set (e.g., each set), for example, based on the traffic of the SL. If a WTRU operates an (e.g., one) SL, the WTRU may use a same PSSCH RX beam in the slots (e.g., all slots) in a resource pool.

[0450] The WTRU may determine RX beam(s) based on a destination WTRU identifier(s) associated with peer WTRU(s). For example, if a slot is reserved for a semi-persistent PSSCH reception of the SL identified by the WTRU destination and / or source ID, the WTRU may determine to use a PSSCH RX beam associated with a WTRU destination ID or a pair of WTRU destination and source ID.

[0451] If a failure of a resource selection associated with a TX beam is indicated, the WTRU may determine to perform sensing using a sensing RX beam paired with the TX beam in a (pre)configured period. This may increase the number of candidate resources specific to the TX beam for resource selection.

[0452] Directional sensing information may be associated with a sensing RX beam.

[0453] A WTRU may acquire SL sensing information at a sensing occasion (e.g., each sensing occasion) specific to a sensing RX beam used at the sensing occasion. A WTRU may obtain the SL sensing information from a based on a received sidelink control transmission (e.g., decoded SCI, for example, from a PSCCH received in a sensing occasion). A WTRU may determine a direction Mode 2 sensing information for resources at a sensing occasion (e.g., each sensing occasion). The sending information may include one or more of the following: resource reservation information from the decoded SCI in the PSCCH (e.g., the resource reservation may indicate the time and / or frequency resources reserved from one or more future SL transmission(s)); associated measured PSCCH and / or PSSCH RSRP; associated sensing RX beam information (e.g., a RX beam index and / or a RX beam TCI state of the sensing RX beam); and / or TX power information associated with the resource reservation. A WTRU may determine a power level used for transmission(s) in the reserved resource(s) (e.g., based on the TX power indicated in the decoded SCI).

[0454] TX beam-specific resource selection may be based on directional Mode 2 SL sensing information.

[0455] The WTRU may receive a sidelink transport block (TB) associated with a TX beam. If an SL TB arrives in a WTRU buffer, a WTRU may perform a TX beam-specific resource selection to determine a resource for transmission of the SL TB. A WTRU may determine a TX beam associated with the SL TB (e.g., and the TX beam to use for the transmission of the SL TB). For example, the WTRU may determine a TX beam associated with the SL TB based on one or more of the following: a WTRU destination and / or source ID of the SL TB; and / or an indication (e.g., from higher layers, for example, from RRC and / or MAC layer).

[0456] A WTRU may determine a TX beam (e.g., a TX beam index and / or an SL TCI state of a TX beam associated with a SL TB). For example, the WTRU may determine the TX beam based on an association between a TX beam and the WTRU destination and / or source ID of the SL TB. If the association is maintained by RRC and / or MAC layer of a WTRU, a TX beam may be indicated to the PHY layer to perform the resource selection.

[0457] Resource selection may be based on sensing information from a candidate resource set applicable to a TX beam. FIG. 9 illustrates an example of using sensing information during resource selection.

[0458] In a TX beam-specific resource selection, a WTRU may select one or more resource(s) among candidate resources at the sensing occasions associated with an RX beam corresponding to the TX beam. A WTRU may determine a sensing window (e.g., based on the sensing window (pre)configuration and whether periodic reservation is enabled in the resource pool). For example, if a sensing occasion is a 1 millisecond slot (e.g., SCS of 15 kHz) and a sensing window is 1000 milliseconds (e.g., for periodic reservation-enabled resource pools), a WTRU may determine 1000 sensing occasions.

[0459] Feature(s) associated with a candidate resource set are provided herein. The candidate resource set may include resources at sensing occasions associated with a RX beam paired with the TX beam.

[0460] Within the sensing the window, a WTRU may determine a subset of sensing occasions (e.g., a first, second, third, etc. sensing occasion) associated with a sensing RX beam paired with the TX beam associated with the SL TB intended for the resource selection. For example, the WTRU may determine that a first RX beam and a first sensing occasion are associated with the TX beam. The WTRU may determine a candidate resource set associated with the first sensing occasion.

[0461] The WTRU may determine a sensing RX beam paired with a TX beam (e.g., based on beam correspondence and / or (pre)configuration). If beam correspondence is present (e.g., an identical spatial domain filter used for the TX beam may be applied to the RX beam) an SL TCI state of an RX beam may be a TX beam index or an RX beam index may be identical with a TX beam index. A TX beam and an RX beam may be paired in a (pre)configuration.

[0462] In resource selection, a WTRU may estimate an interference caused by transmission (e.g., using a TX beam in a selected resource based on the measured RSRP using an RX beam). The gain difference between TX and RX beam may cause error in the interference estimate. The WTRU may be (pre)configured with an RSRP offset (e.g., an RX beam RSRP offset) for each paired TX beam and RX beam. If the RX beam and TX beam apply the same (e.g., identical) spatial domain filter, the RSRP adjustment offset may be zero. If the RX beam covers a paired TX beam (e.g., but with a wider bandwidth), the RSRP adjustment offset may be determined based on a calibration of the TX and RX beam gain difference. The WTRU may adjust the measured RSRP by the RX beam RSRP offset. The WTRU may select the candidate resource based on the adjusted RSRP satisfying the signal quality threshold (e.g., being below the signal quality threshold).

[0463] The WTRU may determine a TX transmit power associated the resource reservation (e.g., the TX power level indicated in the SCI). The WTRU may determine an RSRP offset based on the indicated TX power and gain of the sensing RX beam (e.g., which may provide an estimate of path loss and potential interference).

[0464] A WTRU may determine an RSRP offset based on a previous measurement performed on the WTRU making the resource reservation. For example, a WTRU may determine the WTRU making the resource reservation based on the WTRU source and / or destination ID indicated in the SCI (e.g., including the resource reservation information). The measurement may include CSI, L1 -RSRP, RSRP, and / or RSSI measurements.

[0465] A WTRU may determine a candidate resource set. The candidate resource set may include one or more resources at the sensing occasions in the subset of sensing occasion(s) associated with a sensing RX beam paired with the TX beam associated with the SL TB intended for the resource selection. A WTRU may determine a candidate resource set including resources at sensing occasions (e.g., all sensing occasions) within a sensing window. The WTRU may exclude a sensing occasion from the candidate resource set if the sensing occasion is associated with a sensing RX beam not paired with the TX beam associated with the SL TB intended for the resource selection.

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

[0467] The resource selection failure may indicate that the sensing information specific to the TX beam may not be sufficient (e.g., due to a TX beam and RX beam conflict). The used sensing RX beam may not pair with the TX beam at one or more sensing occasions. A WTRU may reassociate an RX sensing beam to a sensing occasion (e.g., to increase the number of candidate resources specific to the TX beam for another resource selection of the same TB).

[0468] The threshold may be a ratio of the number sensing occasions in the candidate resource set to the total number of sensing occasions within the sensing window. In Mode 2 resource selection, a WTRU may select (e.g., randomly select) resource(s) in a candidate resource set to avoid collision. If the number of candidate resources is low, the collision probability may become higher.

[0469] A WTRU may perform resource selection based on the candidate resource set specific to a TX beam. A WTRU may perform a Mode 2 resource selection based on the candidate resource set. The WTRU may determine one or more available candidate resource(s) for transmission of the SL TB (e.g., using an associated TX beam). A WTRU may exclude candidate resource(s) corresponding to a sensing occasion from resource selection if the candidate resource(s) are reserved by another WTRU (e.g., according to the resource reservation information included in the SCI decoded at the sensing occasion).

[0470] A WTRU may exclude candidate resource(s) corresponding to a sensing occasion from resource selection if the associated PSCCH and / or PSSCH RSRP measurement value after adjustment exceed a (pre)configured threshold. The WTRU may adjust the RSRP value based on a (pre)configured RSRP offset (e.g., associated with the pair of RX beam associated with sensing occasion and TX beam associated with SL TB intended for the resource selection). The threshold may be based on the priority information (e.g., included in the SCI that was decoded at the sensing occasion, and the priority of the SL TB intended for the resource selection).

[0471] A WTRU may select (e.g., randomly select) one or more available candidate resource(s) from among the remaining candidate resources within the candidate resource set for transmission of the SL TB.

[0472] The WTRU may perform resource selection in a candidate resource subset (e.g., with each candidate resource being associated with a different TX beam).

[0473] The WTRU may determine a number of a candidate resource subsets. A candidate resource subset (e.g., each candidate resource subset) may include candidate resources at sensing occasions associated with a different sensing RX beam used at the sensing occasion. A WTRU may perform a resource selection based on a candidate resource subset (e.g., each candidate resource subset). The WTRU may determine one or more available candidate resources (e.g., in each candidate resource set). AWTRU may determine which available candidate resource(s) may be applied for a SL TB (e.g., if the TX beam associated with the SL TB may pair with the RX sensing beam used for the available candidate resources).

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

[0475] A WTRU may perform resource reevaluation or preemption with a specific TX beam.

[0476] A WTRU may perform a Mode 2 resource reevaluation or preemption for already scheduled resources. The MAC layer may provide a set of resources to reevaluate. The WTRU (e.g., the PHY layer) may perform resource selection to find the candidate resources. The resource selection for reevaluation or preemption may involve the resources to check and the associated TX beams.

[0477] If the subset(s) of candidate resources based on directional sensing are obtained in the resource allocation, the WTRU may verify whether the indicated resources are present in the subset of available resources of their corresponding TX beam. If the indicated resources are not present, the PHY layer may report a reevaluation or preemption to the MAC layer for the corresponding resources and their associated TX beams. The report may trigger a resource reselection.

[0478] A WTRU may perform SL sensing in a sensing occasion (e.g., each sensing occasion) using an associated sensing RX beam in a sensing window. The association between sensing RX beam and sensing occasion may be based on a (pre)configuration or a number of unicast links using the RX beam.

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

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

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

[0482] The WTRU may determine a candidate sensing resource set including a candidate resource (e.g., all candidate resources) at the determined sensing occasions. If the number of determined candidate sensing resources is lower than a (pre)configured threshold, the WTRU may indicate a resource selection failure to MAC layer.

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

[0484] The WTRU may transmit PSCCH / PSSCH in a determined available candidate resource (e.g., using the TX beam associated with the unicast link).

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

[0486] Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0487] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, 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)-ROM disks, and / or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

[0488] It is understood that the entities performing the processes described herein may be logical entities that may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of, and executing on a processor of, a mobile device, network node or computer system. That is, the processes may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of a mobile device and / or network node, such as the node or computer system, whichcomputer executable instructions, when executed by a processor of the node, perform the processes discussed. It is also understood that any transmitting and receiving processes illustrated in figures may be performed by communication circuitry of the node under control of the processor of the node and the computer-executable instructions (e.g., software) that it executes.

[0489] The various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the implementations and apparatus of the subject matter described herein, or certain aspects or portions thereof, may take the form of program code (e.g., instructions) embodied in tangible media 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 program code is stored on media, it may be the case that the program code in question is stored on one or more media that collectively perform the actions in question, which is to say that the one or more media taken together contain code to perform the actions, but that - in the case where there is more than one single medium - there is no requirement that any particular part of the code be stored on any particular medium. In the case of program code execution on programmable devices, the computing device generally includes a processor, a storage medium readable by the processor (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 that may implement or utilize the processes described in connection with the subject matter described herein, e.g., through the use of an API, reusable controls, or the like. Such programs are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

[0490] Although example embodiments may refer to utilizing aspects of the subject matter described herein in the context of one or more stand-alone computing systems, the subject matter described herein is not so limited, but rather may be implemented in connection with any computing environment, such as a network or distributed computing environment. Still further, aspects of the subject matter described herein may be implemented in or across a plurality of processing chips or devices, and storage may similarly be affected across a plurality of devices. Such devices might include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems such as automobiles and airplanes.

[0491] In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter,however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

Claims

CLAIMSWhat is Claimed:1 . A wireless transmit / receive unit (WTRU) comprising: a processor configured to: receive information that indicates a first physical sidelink feedback channel (PSFCH) receive (RX) beam associated with a sidelink transport block (TB), and a reserved physical sidelink shared channel (PSSCH) resource, wherein the reserved PSSCH resource is associated with a second PSFCH RX beam and a PSFCH occasion; determine that a 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; based on the determination 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: determine that a candidate PSSCH resource in a sidelink resource pool is associated with the PSFCH occasion, and determine a PSSCH resource set, in the sidelink resource pool, wherein the candidate PSSCH resource is excluded from the PSSCH resource set; select a PSSCH resource from the PSSCH resource set; and transmit a PSSCH transmission associated with the sidelink TB in the PSSCH resource.

2. The WTRU of claim 1 , wherein the processor being 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 comprises the processor being configured to determine that there is a difference between a first sidelink transmission configuration indicator (TCI) state associated with the first PSFCH RX beam associated with the sidelink TB and a second sidelink TCI state associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

3. The WTRU of claim 1 , wherein the processor being 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 comprises the processor being configured to determine that there is a difference between a first beam index associated with the first PSFCH RX beam associated with the sidelink TB and a second beam index associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

4. The WTRU of claim 1 , wherein the processor being 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 comprises the processor being configured to determine that a first destination WTRU identifier associated with the first PSFCH RX beam associated with the sidelink TB is different from a second destination WTRU identifier associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

5. The WTRU of claim 1 , wherein the processor being 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 comprises the processor being configured to determine that a 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 of claim 1 , wherein the information further indicates the second PSFCH RX beam associated with the reserved PSSCH resource, and the processor being 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 comprises the processor being configured to determine that a first indication type used to indicate the first PSFCH RX beam associated with the sidelink TB is different from a second indication type used to indicate the second PSFCH RX beam associated with the reserved PSSCH resource.

7. The WTRU of claim 1 , wherein the processor being 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 comprises the processor being 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 of any one of claims 1 to 7, wherein the information is first information, and the processor is further configured to receive second information that indicates a set of sidelink resource pools, and the first information further indicates the sidelink resource pool, from the set of sidelink resource pools, from which to determine the PSSCH resource set.

9. A method, performed by a wireless transmit / receive unit (WTRU), the method comprising:receiving information that indicates a first physical sidelink feedback channel (PSFCH) receive (RX) beam associated with a sidelink transport block (TB), and a reserved physical sidelink shared channel (PSSCH) resource, wherein the reserved PSSCH resource is associated with a second PSFCH RX beam and a PSFCH occasion; determining that a 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; based on the determination 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: determining that a candidate PSSCH resource in a sidelink resource pool is associated with the PSFCH occasion, and determining a PSSCH resource set, in the sidelink resource pool, wherein the candidate PSSCH resource is excluded from the PSSCH resource set; selecting a PSSCH resource from the PSSCH resource set; and transmitting a PSSCH transmission associated with the sidelink TB in the PSSCH resource.

10. The method of claim 9, wherein determining that the beam conflict exists between the second PSFCH RX beam associated with the first reserved PSSCH resource and the PSFCH RX beam associated with the sidelink TB comprises determining that there is a difference between a first sidelink transmission configuration indicator (TCI) state associated with the first PSFCH RX beam associated with the sidelink TB and a second sidelink TCI state associated with the second PSFCH RX beam associated with the reserved PSSCH resource.11 . The method of claim 9, wherein determining that the beam conflict exists between the second PSFCH RX beam associated with the first reserved PSSCH resource and the PSFCH RX beam associated with the sidelink TB comprises determining that there is a difference between a first beam index associated with the first PSFCH RX beam associated with the sidelink TB and a second beam index associated with the second PSFCH RX beam associated with the reserved PSSCH resource.

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

13. The method of claim 9, wherein determining that the beam conflict exists between the second PSFCH RX beam associated with the first reserved PSSCH resource and the PSFCH RX beam associated with the sidelink TB comprises determining that a 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.

14. The method of claim 9, wherein the information further indicates the second PSFCH RX beam associated with the reserved PSSCH resource, and determining 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 comprises determining that a first indication type used to indicate the first PSFCH RX beam associated with the sidelink TB is different from a second indication type used to indicate the second PSFCH RX beam associated with the reserved PSSCH resource.

15. The method of claim 9, wherein determining 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 comprises determining that signal reception via the second PSFCH RX beam associated with the reserved PSSCH resource is below a quality threshold.

16. The method of any one of claims 9-15, wherein the information is first information, and the method further comprises receiving second information that indicates a set of sidelink resource pools, and the first information further indicates the sidelink resource pool, from the set of sidelink resource pools, from which to determine the PSSCH resource set.

Images