WO2025034596A1

WO2025034596A1 - Flexible psfch reporting associated with multiple psfch resources

Info

Publication number: WO2025034596A1
Application number: PCT/US2024/040834
Authority: WO
Inventors: Tao Deng; Tuong Duc HOANG; Moon-Il Lee; Aata El HAMSS; Benoit Pelletier; Virgile Garcia
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2023-08-04
Filing date: 2024-08-02
Publication date: 2025-02-13
Anticipated expiration: 2026-02-04

Abstract

Devices and techniques for flexible physical sidelink feedback channel (PSFCH) reporting associated with multiple PSFCH resources. An example device may receive configuration information that indicates a physical sidelink shared channel (PSSCH)-to-PSFCH resource mapping. The device may receive, in a PSSCH resource, a hybrid automatic repeat request (HARQ)-enabled sidelink transmission, wherein the HARQ-enabled sidelink transmission comprises sidelink control information (SCI) that indicates an index associated with PSFCH resource selection. The device may determine a set of PSFCH resources based on the PSSCH resource and the PSSCH-to-PSFCH resource mapping. The device may select a PSFCH resource, from the set of PSFCH resources, based on the index associated with PSFCH resource selection. The device may determine a PSFCH transmit (TX) beam associated with the PSFCH resource. The device may transmit a PSFCH transmission in the PSFCH resource, using the PSFCH TX beam associated with the PSFCH resource.

Description

FLEXIBLE PSFCH REPORTING ASSOCIATED WITH MULTIPLE PSFCH RESOURCES

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63/530,770, 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 flexible physical sidelink feedback channel (PSFCH) reporting associated with multiple PSFCH resources are provided herein.

[0003] An example device (e.g., a wireless transmit/receive unit (WTRU)) may receive configuration information that indicates a physical sidelink shared channel (PSSCH)-to-physical sidelink feedback channel (PSFCH) resource mapping. The device may receive, in a PSSCH resource, a hybrid automatic repeat request (HARQ)-enabled sidelink transmission. The HARQ-enabled sidelink transmission may include sidelink control information (SCI) that indicates an index associated with PSFCH resource selection. The device may determine a set of PSFCH resources based on the PSSCH resource and the PSSCH-to-PSFCH resource mapping. The device may select a PSFCH resource, from the set of PSFCH resources, based on the index associated with PSFCH resource selection. The device may determine a PSFCH transmit (TX) beam associated with the PSFCH resource. The device may transmit, to a second WTRU, a PSFCH transmission in the PSFCH resource, using the PSFCH TX beam associated with the PSFCH resource.

[0004] The PSSCH-to-PSFCH resource mapping may be a 1-to-N mapping between the PSSCH resource and N PSFCH resources. The set of PSFCH resources may include the N PSFCH resources.

[0005] The index associated with PSFCH resource selection may be a bit sequence. The bit sequence may indicate an nth PSFCH resource if an n^th bit in the bit sequence is set to one. [0006] The index associated with PSFCH resource selection may be a PSFCH occasion index. The PSFCH occasion index may indicate an n^th PSFCH resource if a value of the PSFCH occasion index is n.

[0007] The configuration information may indicate a set of PSFCH occasion patterns. The index associated with PSFCH resource selection may indicate a PSFCH occasion pattern, from the set of PSFCH occasion patterns. The device may select the PSFCH resource, from the set of PSFCH resources, based on the index associated with PSFCH resource selection by selecting the PSFCH resource, from the set of PSFCH resources, based on the PSFCH occasion pattern.

[0008] The SCI may indicate for the first WTRU to perform beam sweeping over the set of PSFCH resources. The device may determine the PSFCH TX beam associated with the PSFCH resource by determining the PSFCH TX beam via beam sweeping over the set of PSFCH resources.

[0009] The PSFCH resource may be a first PSFCH resource in a first PSFCH period. The SCI may indicate for the first WTRU to perform PSFCH repetition. The device may send, based on the indication for the first WTRU to perform PSFCH repetition, the PSFCH transmission in a second PSFCH resource in a second PSFCH period.

BRIEF DESCRIPTION OF THE DRAWINGS

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

[0011] 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.

[0012] 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.

[0013] 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.

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

[0015] FIG. 3 illustrates repeated PSFCH occasions in a single slot.

[0016] FIG. 4 illustrates an example of a rotating PSFCH occasion.

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

[0018] FIG. 6 illustrates an example of multiple PSFCH occasions used for PSFCH backup.

[0019] FIG. 7 illustrates an example of a PSFCH repetition indication. DETAILED DESCRIPTION

[0020] 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.

[0021] 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), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0022] 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.

[0023] 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.

[0024] 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).

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

[0026] 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).

[0027] 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). [0028] 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).

[0029] 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.

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

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

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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. [0036] 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.

[0037] 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.

[0038] 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.

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

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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)).

[0044] 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. [0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

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

[0054] 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.

[0055] 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 the AP. 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.

[0056] 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. [0057] 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 ST A, 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).

[0058] 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).

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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).

[0063] 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).

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

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

[0073] 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.

[0074] 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.

[0075] 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.

[0076] 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).

[0077] 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.

[0078] 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.

[0079] 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).

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

[0081] 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).

[0082] 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.

[0083] 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).

[0084] 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.

[0085] 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). [0086] Feature(s) associated with new radio (NR) SL resource allocation are provided herein.

[0087] 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).

[0088] 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 to SL-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. [0089] 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).

[0090] 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).

[0091] 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.

[0092] 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. [0093] 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).

[0094] 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.

[0095] 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).

[0096] 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).

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

[0098] 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.

[0099] 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). [0100] 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).

[0101] 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).

[0102] 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.

[0103] 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.

[0104] 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).

[0105] 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).

[0106] 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.

[0107] 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/PSSCH transmissions 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).

[0108] 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).

[0109] 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).

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

[0111] 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.

[0112] 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). [0113] A WTRU may apply a TX beam (e.g., one TX beam) for a SL transmission in a given SL slot.

[0114] 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).

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

[0116] 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).

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

[0118] 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.

[0119] 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).

[0120] 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.

[0121] 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).

[0122] 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.

[0123] 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 may be (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).

[0124] 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.

[0125] 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).

[0126] 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).

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

[0128] 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).

[0129] 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).

[0130] 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. [0131] 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.

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

[0133] 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.

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

[0135] 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.

[0136] 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).

[0137] 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).

[0138] 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.

[0139] 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. [0140] 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.

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

[0142] 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).

[0143] 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.

[0144] 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).

[0145] 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).

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

[0147] 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. [0148] Flexible PSFCH reporting may impact the SL TX WTRU and the SL RX WTRU, as described herein.

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

[0150] 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).

[0151] 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).

[0152] 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 nonoverlapping 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. 3 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. 3.

[0153] 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.

[0154] FIG. 4 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. 4.

[0155] 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.

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

[0157] 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.

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

[0159] 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.

[0160] 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.

[0161] 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.

[0162] 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. [0163] 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.

[0164] 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.

[0165] 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).

[0166] 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).

[0167] 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).

[0168] 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.

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

[0170] 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). [0171] 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).

[0172] 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). For example, 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).

[0173] 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 3^rd PSFCH 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. [0174] 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 2^nd PSFCH 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.

[0175] 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). For example, 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).

[0176] 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).

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

[0178] 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). [0179] The SL TX WTRU may be (pre)configured with a PSFCH occasion-to-RX beam mapping (e.g., based on its RX beam capabilities).

[0180] 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. 3 (e.g., where each PSFCH occasion number will be received with different RX beams).

[0181] 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. 4, 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).

[0182] 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.

[0183] 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) PSFCH occasion 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. 5. 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.

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

[0185] 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).

[0186] 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). [0187] 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).

[0188] FIG. 6 illustrates an example of multiple PSFCH occasions used for PSFCH backup.

[0189] 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. 6.

[0190] 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 the PSSCH resources). The WTRU may be configured with subset occasion patterns and/or with beamsweeping indications.

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

[0192] 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.

[0193] 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.

[0194] 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).

[0195] FIG. 7 illustrates an example of a PSFCH repetition indication. As illustrated in FIG. 7, 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).

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

[0197] 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.

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

[0199] 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.

[0200] 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).

[0201] 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).

[0202] 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.

[0203] 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.

[0204] 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.

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

[0206] 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).

[0207] 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.

[0208] 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). [0209] 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).

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

[0211] 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.

[0212] 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.

[0213] 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.

[0214] 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, which computer 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. [0215] 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.

[0216] 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.

[0217] 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

CLAIMS What is Claimed:

1 . A wireless transmit/receive unit (WTRU) comprising: a processor configured to: receive configuration information that indicates a physical sidelink shared channel (PSSCH)-to- physical sidelink feedback channel (PSFCH) resource mapping; receive, in a PSSCH resource, a hybrid automatic repeat request (HARQ)-enabled sidelink transmission, wherein the HARQ-enabled sidelink transmission comprises sidelink control information (SCI) that indicates an index associated with PSFCH resource selection; determine a set of PSFCH resources based on the PSSCH resource and the PSSCH-to- PSFCH resource mapping; select a PSFCH resource, from the set of PSFCH resources, based on the index associated with PSFCH resource selection; determine a PSFCH transmit (TX) beam associated with the PSFCH resource; and transmit, to a second WTRU, a PSFCH transmission in the PSFCH resource, using the PSFCH TX beam associated with the PSFCH resource.

2. The first WTRU of claim 1 , wherein the PSSCH-to-PSFCH resource mapping is a 1 -to-N mapping between the PSSCH resource and N PSFCH resources, and the set of PSFCH resources comprises the N PSFCH resources.

3. The first WTRU of claim 1 or 2, wherein the index associated with PSFCH resource selection is a bit sequence, and wherein the bit sequence indicates an n^th PSFCH resource if an n^th bit in the bit sequence is set to one.

4. The first WTRU of claim 1 or 2, wherein the index associated with PSFCH resource selection is a PSFCH occasion index, and the PSFCH occasion index indicates an n^th PSFCH resource if a value of the PSFCH occasion index is n.

5. The first WTRU of any of claims 1 to 4, wherein the configuration information further indicates a set of PSFCH occasion patterns, wherein the index associated with PSFCH resource selection indicates a PSFCH occasion pattern, from the set of PSFCH occasion patterns, the processor being configured to select the PSFCH resource, from the set of PSFCH resources, based on the index associated with PSFCH resource selection comprises the processor being configured to select the PSFCH resource, from the set of PSFCH resources, based on the PSFCH occasion pattern.

6. The first WTRU of any of claims 1 to 5, wherein the SCI further indicates for the first WTRU to perform beam sweeping over the set of PSFCH resources, and the processor being configured to determine the PSFCH TX beam associated with the PSFCH resource comprises the processor being configured to determine the PSFCH TX beam via beam sweeping over the set of PSFCH resources.

7. The first WTRU of any of claims 1 to 6, wherein the PSFCH resource is a first PSFCH resource in a first PSFCH period, the SCI further indicates for the first WTRU to perform PSFCH repetition, and the processor is further configured to send, based on the indication for the first WTRU to perform PSFCH repetition, the PSFCH transmission in a second PSFCH resource in a second PSFCH period.

8. A method, performed by a first wireless transmit/receive unit (WTRU), the method comprising: receiving configuration information that indicates a physical sidelink shared channel (PSSCH)- to-physical sidelink feedback channel (PSFCH) resource mapping; receiving, in a PSSCH resource, a hybrid automatic repeat request (HARQ)-enabled sidelink transmission, wherein the HARQ-enabled sidelink transmission comprises sidelink control information (SCI) that indicates an index associated with PSFCH resource selection; determining a set of PSFCH resources based on the PSSCH resource and the PSSCH-to- PSFCH resource mapping; selecting a PSFCH resource, from the set of PSFCH resources, based on the index associated with PSFCH resource selection; determining a PSFCH transmit (TX) beam associated with the PSFCH resource; and transmitting, to a second WTRU, a PSFCH transmission in the PSFCH resource, using the PSFCH TX beam associated with the PSFCH resource.

9. The method of claim 8, wherein the PSSCH-to-PSFCH resource mapping is a 1-to-N mapping between the PSSCH resource and N PSFCH resources, and the set of PSFCH resources comprises the N PSFCH resources.

10. The method of claim 8 or 9, wherein the index associated with PSFCH resource selection is a bit sequence, and wherein the bit sequence indicates an n^th PSFCH resource if an n^th bit in the bit sequence is set to one.

11 . The method of claim 8 or 9, wherein the index associated with PSFCH resource selection is a PSFCH occasion index, and the PSFCH occasion index indicates an n^th PSFCH resource if a value of the PSFCH occasion index is n.

12. The method of any one of claims 8 to 11 , wherein the configuration information further indicates a set of PSFCH occasion patterns, wherein the index associated with PSFCH resource selection indicates a PSFCH occasion pattern, from the set of PSFCH occasion patterns, selecting the PSFCH resource, from the set of PSFCH resources, based on the index associated with PSFCH resource selection comprises selecting the PSFCH resource, from the set of PSFCH resources, based on the PSFCH occasion pattern.

13. The method of any one of claims 8 to 12, wherein the SCI further indicates for the first WTRU to perform beam sweeping over the set of PSFCH resources, and determining the PSFCH TX beam associated with the PSFCH resource comprises determining the PSFCH TX beam via beam sweeping over the set of PSFCH resources.

14. The method of any one of claims 8 to 13, wherein the PSFCH resource is a first PSFCH resource in a first PSFCH period, the SCI further indicates for the first WTRU to perform PSFCH repetition, and the method further comprises sending, based on the indication for the first WTRU to perform PSFCH repetition, the PSFCH transmission in a second PSFCH resource in a second PSFCH period.