FBE Channel Access in Unapproved Sidelink

Abstract

This specification describes systems, methods, and apparatuses related to channel access of frame-based devices (FBEs) in unauthorized sidelink (SL). A wireless transmit / receive unit (WTRU) can receive configuration information that indicates a channel busy ratio (CBR) threshold. The WTRU can determine a CBR value associated with a channel in a listen before talk (LBT) band. The WTRU can compare the CBR value to the CBR threshold. The WTRU can determine channel access parameters based on the comparison of the CBR value and the CBR threshold. The WTRU can change the channel access parameters.

Description

Technical Field

[0001] (Cross - reference to related applications) This application claims priority to U.S. Provisional Patent Application No. 63 / 334,829, filed on April 26, 2022, U.S. Provisional Patent Application No. 63 / 395,970, filed on August 8, 2022, U.S. Provisional Patent Application No. 63 / 421,789, filed on November 2, 2022, and U.S. Provisional Patent Application No. 63 / 445,411, filed on February 14, 2023, the disclosures of which are hereby incorporated by reference in their entireties.

Background Art

[0002] Mobile communications using wireless communication are continuously evolving. The fifth generation may be referred to as 5G. Previous (conventional) generations of mobile communications can be, for example, the fourth generation (4G) long term evolution (LTE).

Summary of the Invention

[0003] This specification describes systems, methods, and devices that may be related to channel access of frame - based devices (FBE) in unauthorized sidelink (SL).

[0004] A device (e.g., a wireless transmit / receive unit (WTRU)) can receive configuration information that indicates a channel busy ratio (CBR) threshold. The device can determine a CBR value associated with a channel in a listen before talk (LBT) band. The device can compare the CBR value with the CBR threshold. The device can determine channel access parameters based on the comparison of the CBR value and the CBR threshold. The device can change the channel access parameters.

[0005] Configuration information may indicate a channel access failure threshold and a fixed frame period (FFP) switching window. The device may perform a plurality of channel access attempts associated with the FFP switching window (e.g., before comparing the CBR value with the CBR threshold). The device may determine that the number of channel access attempts (e.g., before comparing the CBR value with the CBR threshold) meets the channel access failure threshold.

[0006] Comparing the CBR value with the CBR threshold may involve comparing the CBR value with the CBR threshold based on the number of channel access attempts meeting the channel access failure threshold. Changing the channel access parameters may involve changing the FFP configuration if the CBR value is less than the CBR threshold. The FFP configuration may include one or more of FFP periodicity or the FFP offset value. Changing the channel access parameters may involve switching to a different LBT band or sub-band if the CBR value meets the CBR threshold. Changing the channel access parameters may involve changing the resource block set if the CBR value meets the CBR threshold.

Brief Description of the Drawings

[0007]

Fig. 1A

Fig. 1B

Fig. 1C

Fig. 1D

Fig. 2

Fig. 3

Fig. 4

Fig. 5

Fig. 6

Fig. 7

Fig. 8

Fig. 9

Fig. 10

Fig. 11

Fig. 12

Fig. 13

Fig. 14

Fig. 15

Fig. 16

Fig. 17

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

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

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

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

[0012] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via a wireless 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 wireless interface 116 may be established using any suitable radio access technology (RAT).

[0013] More specifically, as described above, the communication system 100 can be a multiple access system and can use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a within RAN104 / 113 and the WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use wideband CDMA (WCDMA) to establish radio interfaces 115 / 116 / 117. WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0014] In one embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro) to establish radio interface 116.

[0015] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish radio interface 116.

[0016] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement both LTE radio access and NR radio access using, for example, the dual connectivity (DC) principle. Accordingly, the radio interfaces utilized by the WTRUs 102a, 102b, 102c may be characterized by transmissions sent between multiple types of radio access technologies and / or multiple types of base stations (e.g., eNBs and gNBs).

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

[0018] The base station 114b in FIG. 1A can be, for example, a wireless router, a home node B, a home e-node B, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by drones, for example), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless 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 can utilize a cellular-based RAT (such as WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

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

[0020] CN106 / 115 can also serve as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, Internet 110, and / or other network 112. The PSTN108 may include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, and these networks and devices use common communication protocols such as the transmission control protocol (TCP), user datagram protocol (UDP), and / or the Internet protocol (IP) of the TCP / IP Internet protocol suite. The network 112 may include a wired communication network and / or a wireless communication network that is owned and / or operated by another service provider. For example, the network 112 may include another CN connected to one or more RANs that may use the same RAT or a different RAT as the RAN104 / 113.

[0021] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 may include a multimode function (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A may be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and a base station 114b that may employ IEEE802 wireless technology.

[0022] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 can include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 can include any partial combination of the foregoing elements while remaining consistent with one embodiment.

[0023] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120 that can be coupled to a transmit / receive element 122. Although Figure 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

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

[0026] The transceiver 120 may be configured to modulate signals transmitted by the transmitting / receiving element 122 and demodulate signals received by the transmitting / receiving element 122. As noted above, the WTRU 102 may have a multimode function. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, NR and IEEE 802.11.

[0027] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, keypad 126, and / or display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive data input by the user from these. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. In addition, the processor 118 may access information from and store data in any suitable type of 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, etc. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0029] Processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via the wireless interface 116 and / or may determine its location based on the timing of signals received from two or more neighboring base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location determination method while remaining consistent with one embodiment.

[0030] Processor 118 may further be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos 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, etc. The peripheral devices 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0031] The WTRU 102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference either via hardware (e.g., a choke) or via signal processing through a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either uplink (e.g., for transmission) or downlink (e.g., for reception)).

[0032] Figure 1C is a system diagram illustrating RAN 104 and CN 106, according to one embodiment. As described above, the RAN 104 may employ E-UTRA radio technology to communicate with WTRU 102a, 102b, 102c via wireless interface 116. The RAN 104 may also communicate with the CN 106.

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

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

[0035] CN106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing elements is depicted as part of CN106, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0036] The MME 162 can be connected to each of the eNodeBs 162a, 162b, and 162c in the RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can authenticate users of the WTRUs 102a, 102b, and 102c, activate / deactivate bearers, select a specific serving gateway during the initial attach of the WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0037] SGW 164 can be connected to each of the eNodeBs 160a, 160b, and 160c in RAN 104 via the S1 interface. SGW 164 can generally route and transfer user data packets between the WTRUs 102a, 102b, and 102c. SGW 164 can perform other functions such as the function of anchoring the user plane during handover between eNodeBs, the function of triggering paging when DL data is available to the WTRUs 102a, 102b, and 102c, and the function of managing and storing the context of the WTRUs 102a, 102b, and 102c.

[0038] SGW 164 can be connected to PGW 166, and PGW 166 can provide the WTRUs 102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0039] CN 106 can facilitate communication with other networks. For example, CN 106 can provide the WTRUs 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108 to facilitate communication between the WTRUs 102a, 102b, and 102c and conventional landline communication devices. For example, CN 106 can include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN 106 and PSTN 108. In addition, CN 106 can provide the WTRUs 102a, 102b, and 102c with access to another network 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.

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

[0041] In a representative embodiment, the other network 112 can be a WLAN.

[0042] A WLAN in infrastructure basic service set (BSS) mode can have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or interface to another type of wired / wireless network that carries traffic entering and / or exiting the Distribution System (DS) or BSS. Traffic destined for an STA that originates outside the BSS can reach and be delivered to the STA through the AP. Traffic originating from an STA and destined for a destination outside the BSS can be sent to the AP so as to be delivered to their respective destinations. Traffic between STAs within the BSS can be sent, for example, through the AP. The source STA can send traffic to the AP, and the AP can send the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between the source STA and the destination STA (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) can communicate directly with each other. The IBSS mode of communication can be referred to herein as the "ad hoc" communication mode.

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

[0044] A High Throughput (HT) STA can use a 40 MHz wide channel for communication, and this 40 MHz wide channel can be formed, for example, via a combination of a primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel.

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

[0046] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier frequency are reduced in 802.11af and 802.11ah as compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication, such as machine type communication (MTC) devices within a macro coverage area. The MTC device may have limited capabilities, including support for certain capabilities, such as support for a particular and / or limited bandwidth (e.g., supporting only these). The MTC device may include a battery having a battery life above a threshold (e.g., to maintain a very long battery life).

[0047] A WLAN system that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by an STA from among all STAs operating in a BSS that supports the minimum bandwidth operation mode. In an example of 802.11ah, the primary channel supports the 1MHz mode (e.g., supports only this) for an STA (e.g., an MTC type device) that has a 1MHz width even when the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or Network Allocation Vector (NAV) setting may depend on the status of the primary channel. For example, due to an STA transmitting to an AP (supporting only the 1MHz operation mode), when the primary channel is in operation, most of the frequency band remains in an operation pause and, even if it may be available, the entire available frequency band may be considered to be in operation.

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

[0049] FIG. 1D is a system diagram illustrating RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, 102c via a radio interface 116. RAN 113 may also communicate with CN 115.

[0050] RAN113 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via radio interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 108b may utilize beamforming to transmit and / or receive signals between gNBs 180a, 180b, and 180c. Thus, gNB 180a may transmit and / or receive radio signals with WTRU 102a using, for example, multiple antennas. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of such component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 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).

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

[0052] gNBs 180a, 180b, and 180c may be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, 160c, etc.). In a stand-alone configuration, WTRUs 102a, 102b, and 102c may utilize one or more of gNBs 180a, 180b, and 180c as a mobility anchor point. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with and connect to gNBs 180a, 180b, and 180c while also communicating with and connecting to another RAN such as eNodeBs 160a, 160b, 160c. For example, WTRUs 102a, 102b, and 102c may implement a DC principle for communicating with one or more gNBs 180a, 180b, and 180c and one or more eNodeBs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, eNodeBs 160a, 160b, and 160c may function as a mobility anchor for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c may provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0053] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decision-making, handover decision-making, user scheduling in UL and / or DL, support for network slicing, simultaneous communication, coordination between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0054] CN 115 shown in FIG. 1D can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of CN 115, it will be understood that any of these elements can be owned and / or operated by entities other than the CN operator.

[0055] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can authenticate users of WTRUs 102a, 102b, and 102c, support network slicing (e.g., handle various packet data unit (PDU) sessions with different requirements), select specific SMFs 183a and 183b, manage the registration area, terminate NAS signaling, perform mobility management, etc. Network slicing can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on the type of service being utilized by WTRUs 102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. AMF 162 can provide control plane functions for exchange between RAN 113 and other RANs (not shown) that use other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or WiFi.

[0056] SMF183a and 183b can be connected to AMF182a and 182b within CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b within CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b, and configure the routing of traffic passing through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, enforcing policies and controlling QoS, and providing downlink data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

[0057] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c within RAN113 via the N3 interface, thereby providing access to a packet-switched network such as the Internet 110 to WTRU102a, 102b, and 102c and assisting in the communication between WTRU102a, 102b, and 102c and IP-corresponding devices. UPF184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0058] CN115 can assist in communicating with other networks. For example, CN115 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and the PSTN 108. In addition, CN115 can provide access to other networks 112 for the WTRUs 102a, 102b, 102c, and this other network may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to the local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0059] In view of FIGS. 1A - 1D, and the corresponding descriptions of FIGS. 1A - 1D, one or more, or all, of the functions described herein with respect to one or more of the WTRUs 102a - d, base stations 114a and b, eNodeBs 160a - c, MME 162, SGW 164, PGW 166, gNBs 180a - c, AMFs 182a and b, UPFs 184a and b, SMFs 183a and b, DNs 185a and b, and / or any other device described herein can be performed by one or more emulation devices (not shown). An emulation device can be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functionality.

[0060] An emulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more emulation devices can execute one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test another device in the communication network. One or more emulation devices can execute one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. An emulation device can be directly coupled to another device for testing purposes and / or can use radio wireless communication to execute the test.

[0061] One or more emulation devices can execute one or more functions including all functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a test scenario in a test laboratory and / or in a non-deployed (e.g., for testing) wired and / or wireless communication network to implement tests of one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (which can include one or more antennas) can be used by the emulation device to transmit and / or receive data.

[0062] Functions associated with resource prioritization are provided herein. Functions associated with resource allocation are provided herein. Functions associated with synchronization procedures are provided herein.

[0063] The WTRU can determine whether to reserve a Channel Occupancy Time (COT) period / Fixed Frame Period (FFP). The WTRU can determine a Cyclic Prefix Extension (CPE) for transmission based on reservation information within the reserved resources. The WTRU can change its FFP configuration based on the resource reservation information. The WTRU can rate match / puncture the PSCCH / PSSCH before the COT / FFP reserved for other WTRUs. The WTRU can determine whether to permit other WTRUs to share its COT / FFP. The WTRU may reselect the frequency resources (e.g., interleaves) for PSCCH / PSSCH transmission in its FFP. The WTRU can determine whether to prioritize its COT / FFP.

[0064] This specification describes systems, methods, and apparatuses for frame - based equipment (FBE) channel access in an unauthorized sidelink (SL).

[0065] The Wireless Transmit / Receive Unit (WTRU) can select fixed frame (FF) parameters. For example, the WTRU can determine a fixed frame period (FFP) configuration for (e.g., one) channel access type. The WTRU can notify other nodes of its FFP configuration. The WTRU can trigger sending the FFP configuration to other nodes. The WTRU can change (e.g., determine to change) the FFP configuration for (e.g., one) channel access type.

[0066] A WTRU can provide sidelink feedback. The WTRU can request hybrid automatic repeat request (HARQ) feedback for the transmission of a (e.g., one) transport block (TB). The WTRU can determine the physical sidelink feedback channel (PSFCH) transmission timing and / or the PSFCH resources. For example, a transmitting WTRU (Tx WTRU) can indicate the maximum number of HARQ feedback attempts. The WTRU can perform a retransmission for the TB, for example, based on the HARQ feedback status. The WTRU can determine when to end a HARQ feedback attempt for a (e.g., one) transmission. The WTRU can determine the channel occupancy time (COT) and / or the FFP for which HARQ feedback should be performed for a (e.g., one) transmission. The Tx WTRU can indicate information regarding the HARQ feedback of the transmission. For example, a receiving WTRU (Rx WTRU) can perform HARQ feedback to the Tx WTRU. The Tx WTRU can indicate the maximum number of HARQ feedback attempts. The WTRU can determine the HARQ feedback transmission timing for performing the HARQ feedback of a (e.g., one) transmission. The WTRU can request HARQ feedback at the current COT and / or FFP of the WTRU. The WTRU can determine the type of transmission regarding the TB. The WTRU can determine whether to puncture / rate match the physical sidelink control channel (PSCCH) / physical sidelink shared channel (PSSCH) within the PSFCH slot.

[0067] A WTRU can implement a synchronization procedure. For example, the WTRU may transmit a synchronization signal block (SSB) in a (pre-)configured resource. The WTRU can determine, for example, whether to perform a clear channel assessment (CCA) and / or listen before talk (LBT) before a (pre-)configured resource for sidelink SSB (S-SSB) transmission. The WTRU can determine the number of S-SSB transmissions during a synchronization period. The WTRU can pause the COT and / or FFP of the WTRU for another transmission. The WTRU can resume the COT and / or FFP of the WTRU after a (pre-)configured resource.

[0068] A WTRU can perform resource allocation. For example, the WTRU can determine whether to initialize a COT and / or FFP (e.g., a new COT and / or FFP). The WTRU can determine whether to share the COT and / or FFP with other WTRUs. The WTRU can determine the number of interfaces to select. The WTRU can perform resource reservation.

[0069] The WTRU can determine to perform different load-based equipment (LBE) channel access types. The WTRU can perform FBE and / or LBE to access the channel. The WTRU can determine a set of resource elements (REs) and / or physical resource blocks (PRBs) for transmitting HARQ feedback. The WTRU can resume COT / FFP after physical SL feedback channel (PSFCH) resources. The WTRU can be (pre-)configured with the mapping of the physical SL control channel (PSCCH) and / or the physical SL shared channel (PSSCH) to multiple PSFCH transmission timings. The WTRU can resume its COT / FFP after (pre-)configured resources. The WTRU can be (pre-)configured using multiple types of resources for S-SSB transmission / reception. The WTRU can perform S-SSB transmission in (pre-)configured S-SSB slots within a resource pool. The WTRU can be (pre-)configured using the type of S-SSB transmission. The WTRU can determine the S-SSB option and / or S-SSB pattern to transmit.

[0070] In HARQ-enabled TB, the Tx WTRU may require that the receiving WTRU (Rx WTRU) provide feedback in the Tx WTRU's COT and / or FFP (e.g., the Tx WTRU may indicate the PSFCH transmission timing to provide feedback), and / or provide feedback in the (e.g., the Rx WTRU's own) initiated COT and / or FFP of the Rx WTRU. The Tx WTRU may determine whether to request feedback in the Tx WTRU's COT / FFP or in the Rx WTRU's COT / FFP based on one or more of the service quality (QoS) of the TB, the remaining transmissions of the WTRU within the period (e.g., to maintain the COT until the indicated PSFCH), the remaining COT duration, and / or the gap to the next COT and / or FFP of the Rx WTRU.

[0071] A WTRU (e.g., a Tx WTRU) can perform one or more of the following (e.g., any combination) for transmitting a HARQ-enabled TB: receive a PSFCH configuration within a resource pool (e.g., for each slot), receive a COT and / or FFP and PSFCH configuration from a peer WTRU (e.g., WTRU-B) via, e.g., PC5-RRC, obtain a COT with an (e.g., one) FFP, determine a feedback transmission timing (e.g., for each transmission of the HARQ-enabled TB) based on one or more of the TB priority, remaining number of transmissions, remaining COT duration, next COT of the Rx WTRU, and / or gap to the FFP, and / or PSFCH configuration, determine the duration and / or number of HARQ feedback attempts of the Rx WTRU (e.g., based on the QoS of the TB and / or the FFP configuration of the WTRU), indicate the HARQ feedback transmission timing / resource in the SL control information (SCI) for the maximum number of (e.g., each) transmission and / or feedback attempts, monitor the feedback for (e.g., each) transmission, and / or access the channel and perform a retransmission for the TB (e.g., if NACK / DTX is detected in the maximum number of HARQ attempts).

[0072] The Rx WTRU can perform channel access (e.g., continuously) in the COT and / or FFP (e.g., for each FFP period) until it successfully transmits a (e.g., one) PSFCH at N transmission timings. For example, the Rx WTRU can perform channel access in the COT and / or FFP until it can successfully transmit one PSFCH at N transmission timings based on the reception of a transmission from the Tx WTRU with feedback in the FFP of the Rx WTRU (e.g., requested) at one of the N PSFCH transmission timings (e.g., one PSFCH transmission timing).

[0073] A WTRU (e.g., an Rx WTRU) can perform one or more of the following procedures (e.g., any combination) to perform HARQ feedback transmission (e.g., for one or more transmissions): for example, determining an FFP configuration (e.g., period and / or offset) based on whether a configured service supports HARQ feedback (e.g., the COT and / or the initial symbol of the FFP can be used for, e.g., PSFCH transmission if the service supports HARQ feedback and can be used for, e.g., PSCCH / PSSCH if the service does not support HARQ feedback), receiving a transmission from a Tx WTRU (e.g., which can indicate at least one of the execution of HARQ feedback in the Rx WTRU's COT and / or FFP and / or the evaluation of the maximum N available channel assessment (CCA) transmission timings), performing CCA (e.g., for each COT and / or FFP in the next N COTs and / or FFP) to access the channel and transmit a PSFCH at the PSFCH transmission timing until a transmission of the PSFCH at one transmission timing is successful, and / or reporting a channel access failure to the gNB if, for example, the WTRU fails to access the channel at all N transmission timings.

[0074] Sidelink (SL) operation can be implemented in unlicensed spectrum. Sidelink operation can be implemented for modes 1 and 2 in unlicensed spectrum in FR1 (e.g., SL U). The unlicensed SL frequency band can be, for example, 5 GHz and 6 GHz. The Uu operation associated with mode 1 can be in licensed spectrum (e.g., limited to licensed spectrum only). SL U channel access can be based on regional regulations. NR U channel access can be the starting point.

[0075] The SL resource allocation mechanism for the licensed spectrum can be reused for SL operations in the UL spectrum. SL U can implement changes to the physical (PHY) channel structure and procedures of NR SL to operate in the frequency band of the unlicensed spectrum (e.g., HARQ feedback supported in unicast and groupcast transmissions in NR V2X).

[0076] NR U channel access can be provided for frame-based equipment (FBE) systems. The FBE system can be utilized in an environment where the absence of other technologies is guaranteed (e.g., by government regulations, private facility policies, etc.).

[0077] A WTRU (e.g., an NR U FBE system) can be composed of a fixed frame period (FFP) for channel access that may include an offset and FFP. The WTRU can perform burst transmissions from the start of the FFP until T idle (e.g., when T idle = max{5% of FFP, 100 us}). Data can be transmitted when the channel is idle. The WTRU can perform a CCA (e.g., which may be based on local regulations and span 9 or 16 μs). The WTRU can wait for the CCA until the next cycle (e.g., if originally so).

[0078] Figure 2 is a diagram illustrating an exemplary FFP configuration in an FBE frame for an FBE system.

[0079] A WTRU can be composed of, for example, a system information block (SIB) with different offsets and / or FFP, and / or an FFP from dedicated RRC. The FFP can be asynchronous with respect to the gNB. The FFP can be configurable (e.g., it can be {1, 2, 2.5, 4, 5, 10} ms). The WTRU can change the FFP configuration (e.g., after 200 ms).

[0080] The gNB can share the COT initiated by a WTRU (e.g., a WTRU COT initiator), for example, in downlink (DL) transmission (e.g., when the WTRU is one of the target receivers). The WTRU can share the COT initiated by the gNB (e.g., a gNB COT initiator). Multiple (e.g., two) WTRUs may not share the COT (e.g., based on restricted gNB implementation).

[0081] The gNB (e.g., an NR U) can perform UL scheduling. The gNB can configure the FFP and / or schedule the UL resources, for example, for the data of each WTRU and / or for feedback, in order to avoid collisions between UL transmissions (e.g., to ensure collisions).

[0082] The WTRU (e.g., a mode 2 FBE) can select the FFP configuration (e.g., autonomously) and / or perform resource allocation for transmitting the PSFCH and / or data. Adjustments can be provided between the Tx WTRU and the Rx WTRU for HARQ-enabled transmission (e.g., regarding the uncertainty of channel access).

[0083] The description that the WTRU may be (e.g., somehow) preconfigured is equivalent to the description that "the WTRU is (e.g., somehow) preconfigured" or, for example, the description that the WTRU may receive a configuration from another node (e.g., the gNB) (e.g., of something), and may be used in the same sense.

[0084] Priority control and / or resource re-evaluation can be used to determine whether a pre-selected resource (e.g., for resource re-evaluation) or a reserved resource (e.g., for priority control) is still available for transmission. If the resource is still available, the WTRU can use the resource for transmission. If the resource is not available, the WTRU can select another resource for transmission. Resource allocation can be used to determine the resources for transmission. Thus, resource allocation, priority control, and resource re-evaluation can be used interchangeably. Such terms can describe, for example, identifying whether a pre-selected or reserved resource is still available and / or identifying and extracting the resources available for transmission based on detection. Resource allocation can refer to initial resource allocation, priority control, and / or resource re-evaluation.

[0085] FFP parameters may be selected. The WTRU may perform different FBE channel access types (e.g., be able to determine to perform). In some embodiments, the WTRU may perform one or more FBE channel access types. (For example, each) channel access type may be associated with (e.g., one) FFP configuration. (For example, each) FFP configuration may include, for example, one or more (e.g., any combination) of the following parameters: COT, and / or FFP, FFP offset, zero CCA duration (e.g., no CCA), CCA duration, zero operation pause duration (e.g., no operation pause duration), operation pause duration, frequency of channel access per one or more COTs, and / or FFP, one or more listen-before-talk (LBT) parameters for accessing the channel, a PSFCH configuration having COT, and / or FFP, and including, for example, one or more (e.g., any combination) of the following: availability of PSFCH in COT, and / or FFP, periodicity of PSFCH, number of PSFCH transmission timings in COT, and / or FFP, presence of PSFCH at the beginning, middle, and / or end of COT, number of PSFCH resources at one PSFCH transmission timing, and / or mapping rules between PSCCH / PSSCH and PSFCH in COT, and / or FFP, which is a PSFCH configuration.

[0086] The term FFP may be used in the same sense as the term COT used herein. For example, FFP, and / or COT may be used to indicate the channel occupancy time, or channel occupancy period, of a WTRU. The clear channel assessment (CCA), and / or LBT duration may include one or more of the following: no CCA / LBT (e.g., the WTRU may perform transmission without LBT / CCA), fixed CCA / LBT (e.g., the WTRU may be similar to type 2A, and / or type 2B LBT, e.g., may perform CCA / LBT for a fixed duration of 9 μs / 16 μs / 25 μs), or a flexible CCA / LBT duration (e.g., the WTRU may perform type 1 LBT before transmission of one or more TBs).

[0087] The term CCA may be used in the same sense as the term LBT herein. These terms may be used to describe the procedure by which the WTRU senses the channel before transmission.

[0088] The WTRU can perform (e.g., can determine to perform) various load-based equipment (LBE) channel access types. The WTRU may perform one or more LBE channel access types. The channel access type (e.g., each channel access type) may be associated with one or more LBT parameters. The WTRU can determine one or more of the following LBT parameters: the LBT type for LBT sub-band channel access (e.g., LBT type 1, type 2, type 2A, type 2B, and / or type 2C), the channel access priority class (CAPC), and the contention window size, the current contention window (e.g., CW p ), the channel access priority class p (e.g., CW p , CW min,p , and CW max,pA contention window size that may include a minimum and / or maximum contention window related to , a current value or an initial value of a backoff counter (N), a COT duration that may include a current COT and / or a maximum COT, and a delay period (e.g., T d ) and an LBT energy detection threshold used to determine channel availability, an FFP configuration, a CCA duration, or a channel access time in a slot (e.g., each slot) or a Cyclic Prefix Extension (CPE) duration. In an embodiment, the WTRU may be configured (in advance) with an earlier stage (e.g., earlier) channel access time and / or a longer CPE duration for a certain type of transmission (e.g., a high-priority transmission such as high-priority data, S-SSB, etc.). In an embodiment, the WTRU may be configured (in advance) with a later stage channel access time and / or a shorter CPE duration for another type of transmission (e.g., a low-priority transmission such as low-priority data, etc.).

[0089] The LBT parameter may include one or more of the parameters related to the channel access procedure. The parameters include the LBT type of LBT sub-band channel access, CAPC, CW p, CW min,p and a contention window size that may include CW max,p , a currently or initialized backoff counter N, a COT duration, a delay period, an LBT energy detection, an FFP configuration, and / or a CCA duration may be included.

[0090] In an embodiment where FBE channel access is performed based on an FFP offset, the WTRU may be configured (in advance) with a plurality (e.g., two) types of FFP offsets. The first type of FFP offset may be associated with a slot-level FFP offset. The second type of FFP offset may be associated with a symbol-level FFP offset.

[0091] In an embodiment where FBE channel access is performed based on the frequency of channel access for one or more COTs and / or FFP, the WTRU may be permitted to access the channel at (for example, up to) X% of the time (for example, in an FFP configuration) (for example, in each observation period). For example, the WTRU may be permitted to access the channel in X out of a total of N COTs and / or FFP. The WTRU may be permitted to access the channel in (for example, up to) X consecutive COTs and / or FFP (for example, in an FFP configuration). For example, in an (additional and / or alternative) embodiment, the WTRU may be permitted to access the channel in (for example, the longest) X (ms) in a (for example, consecutive) set of COTs and / or FFP.

[0092] In an embodiment where FBE channel access is performed based on a PSFCH configuration having COTs and / or FFP, the WTRU may not have to have a PSFCH within the COTs and / or FFP (for example, based on an FFP configuration). The WTRU may have a PSFCH every N slots (for example, based on an FFP configuration). The WTRU may have a PSFCH in one or more slots in the center of the WTRU's COT (for example, based on an FFP configuration). The WTRU may have a PSFCH (for example, only the PSFCH) at the end of the WTRU's COT (for example, based on an FFP configuration). The WTRU may have a PSFCH at the beginning of the COTs and / or FFP (for example, based on an FFP configuration). The WTRU may have a PSFCH at the beginning of the COTs and / or FFP (for example, based on an FFP configuration) and / or at the end of the COT.

[0093] The WTRU can determine the type of FBE channel access to perform based on, for example, one or more of the types of channels that the WTRU can transmit on (e.g., PSFCH, PSCCH / PSSCH, and / or S-SSB). For example, the WTRU can access the channel for PSCCH / PSSCH using a first FFP configuration. The WTRU can use a second FFP configuration (e.g., without CCA) for PSFCH and / or S-SSB transmission.

[0094] The WTRU can perform FBE and / or LBE to access the channel. The WTRU can perform FBE-type channel access and / or LBE-type channel access to access the channel and perform the transmission of one or more TBs. For example, during a certain period, the WTRU can access the channel using FBE-based channel access, in which case the WTRU performs CCA over a certain period (e.g., 9 μs, or 16 μs) and can perform the transmission within a (pre)-configured duration. In another period, the WTRU can access the channel using LBE-based channel access, in which case the WTRU can perform LBT (e.g., type 1 LBT). In another period, the WTRU can access the channel using LBE-based channel access, in which case the WTRU can perform another type of LBT (e.g., type 2 LBT).

[0095] The WTRU may determine an FFP configuration for (e.g., one) channel access type. For (e.g., one) channel access type, the WTRU may determine one or more (e.g., any combination) of the following parameters: COT and / or FFP, an FFP offset, a CCA duration that may include a zero CCA / LBT duration (e.g., no CCA / LBT, a fixed CCA / LBT duration such as 9 μs, 16 μs, or 25 μs, and / or a flexible CCA / LBT duration), an operation pause period that may include a 0 operation pause period (e.g., no operation pause period), one or more COTs, and / or the frequency of channel access per FFP, and / or a PSFCH configuration by COT and / or FFP.

[0096] The value of one or more parameters of the FFP configuration may be determined based on one or more (e.g., any combination) of the following: a destination ID of the service, QoS associated with the sidelink communication service (e.g., an established logical channel (LCH) / sidelink radio bearer (SLRB) of the sidelink service), a traffic pattern, and / or a HARQ feedback requirement of the established sidelink service.

[0097] In an example of determining the value of one or more parameters of the FFP configuration based on the destination ID of the service, the WTRU may be (pre)configured with (e.g., one) FFP configuration for (e.g., one) sidelink service. The WTRU may be associated with (e.g., involved in) multiple sidelink services. For example, the WTRU may determine an FFP configuration for multiple sidelink services based on the FFP configuration for each sidelink service. For example, the WTRU may select the minimum number of COTs and / or FFPs, or the greatest common divisor of all COTs and / or FFPs, (pre)configured for each sidelink service.

[0098] In an example of determining the value of one or more parameters of the FFP configuration based on QoS associated with the sidelink communication service (e.g., established LCH / SLRB for the sidelink service), the WTRU can establish a sidelink communication service. The WTRU can be configured with one or more LCH / SLRBs. The WTRU can determine QoS parameters associated with the sidelink communication service, such as latency requirements, priorities, etc. The WTRU can determine the FFP configuration, for example, based on the associated QoS parameters. The WTRU can determine the FFP configuration, for example, based on the LCH / SLRB established for sidelink communication.

[0099] In an example of determining the value of one or more parameters of the FFP configuration based on the traffic pattern, the WTRU can select an FFP offset, and / or a COT, and / or an FFP according to the sidelink traffic pattern. The WTRU can select the COT and / or the FFP to be equal to the traffic generation period of the WTRU. The WTRU can select the FFP offset to be equal to the traffic generation offset of the WTRU.

[0100] In an embodiment of determining the value of one or more parameters of the FFP configuration based on the established HARQ feedback requirements for sidelink services, the WTRU may determine the FFP configuration based on the COT of the Rx WTRU and / or the availability of the sidelink communication service that requests / permits HARQ feedback at first for the FFP. In an embodiment, the WTRU may have a sidelink service that requires HARQ feedback. The WTRU may select an FFP offset having symbol-level granularity. The WTRU may select an FFP offset such that, for example, the WTRU can transmit a PSFCH at the COT and / or at first for the FFP. For example, if there is no sidelink service that requires HARQ feedback in the WTRU, the WTRU may select an FFP offset having slot-level granularity. The WTRU may select an FFP offset such that the WTRU can transmit a PSCCH / PSSCH at the COT and / or at first for the FFP. If the HARQ feedback to be transmitted is not in the WTRU, the WTRU may perform transmission at the PSFCH transmission timing (e.g., the first PSFCH of the COT and / or the FFP). The COT may be maintained. The WTRU may transmit one or any combination of the following: dummy data, repetition of one or more symbols in the next PSCCH / PSSCH slot, and / or a sequence for automatic gain control (AGC) setting.

[0101] Figure 3 illustrates an embodiment in which the WTRU selects various FFP offsets based on whether the WTRU has a HARQ-enabled sidelink service. As shown by the embodiment of Figure 3, for example, if the WTRU has a HARQ-enabled sidelink service, the WTRU may select a first FFP offset (e.g., FFP offset 1) for the first FFP configuration. For example, if the WTRU does not have a sidelink service involving HARQ-enabled transmission, the WTRU may select a second FFP offset (e.g., FFP offset 2) for the second FFP configuration.

[0102] The WTRU can notify other nodes about the FFP configuration of the WTRU. The WTRU can (e.g., decide to) send (e.g., one) channel access type of FFP configuration (e.g., one or more parameters of the FFP configuration) to other nodes (e.g., gNB, other WTRUs). For example, the WTRU can report the FFP configuration to the network (e.g., to the gNB). The WTRU can report the FFP configuration to the network (e.g., to the gNB) using, for example, an UL media access control (MAC) control element (CE), radio resource control (RRC), and / or a non-access stratum (NAS) message. For example, the WTRU can send the FFP configuration to other WTRUs (e.g., where the WTRU may have ongoing unicast communications). For example, the WTRU can send the FFP configuration to a group of WTRUs (e.g., where the WTRU may have ongoing groupcast communications). The WTRU can carry the FFP configuration to other nodes via the PC5 interface using, for example, a SCI (e.g., a second SCI), MAC CE, PC5 RRC, and / or a NAS message.

[0103] The WTRU can trigger other nodes to send the FFP configuration. The WTRU can trigger (e.g., one) channel access type of the WTRU's FFP configuration to be sent to other nodes (e.g., gNB, other WTRUs) based on one or more (e.g., any combination) of the events described herein and / or based on one or more (e.g., any combination) of the following events: the WTRU establishing a unicast link with another WTRU, a groupcast service being established for a group of WTRUs, and / or the WTRU changing its FFP configuration.

[0104] In an embodiment that triggers sending the FFP configuration of a WTRU of a (e.g., one) channel access type to other nodes based on the WTRU establishing a unicast link with another WTRU, the WTRU may send the FFP configuration to the peer WTRU (e.g., after a unicast link between two WTRUs is established). The WTRU may use PC5-RRC to notify the peer WTRU of the FFP configuration.

[0105] In an embodiment that triggers sending the FFP configuration of a WTRU of a (e.g., one) channel access type to other nodes based on a multicast service being established for a group of WTRUs, the WTRU may send the FFP configuration to the group of WTRUs based on (e.g., in response to) the establishment of the multicast connection. The WTRU may use group PC5 RRC to convey the FFP configuration.

[0106] In an embodiment that triggers sending the FFP configuration of a WTRU of a (e.g., one) channel access type to other nodes based on the WTRU changing the FFP configuration, the WTRU may trigger sending the FFP configuration to other nodes (e.g., the peer WTRU of each unicast link, the group of WTRUs of the multicast service, gNB, etc.) when the WTRU changes one or more parameters of the FFP configuration (e.g., FFP offset, COT, and / or changes to the FFP, PSFCH configuration, etc.).

[0107] The WTRU can change (e.g., determine to change) the FFP configuration for (e.g., one) channel access type. The WTRU can change (e.g., determine to change) the FFP configuration for (e.g., one) channel access type by changing one or more (e.g., any combination) of the following parameters: COT, and / or FFP, and the FFP offset, and the CCA / LBT duration which may include zero CCA / LBT (e.g., no CCA / LBT, a fixed CCA / LBT duration such as 9 μs, 16 μs, or 25 μs, and / or a flexible CCA / LBT duration), and the operation pause period which may include zero operation pause period (e.g., no operation pause period), and the frequency of channel access for one or more COTs, and / or FFP, and / or the PSFCH configuration by COT and / or FFP.

[0108] The WTRU can change (e.g., determine to change) one or more parameters within the FFP configuration based on, for example, one or more (e.g., any combination of) events described herein and / or one or more (e.g., any combination of) trigger events as follows: receiving an indication from another node, detecting a semi - persistent CCA / LBT failure, and / or detecting a semi - persistent reservation from another WTRU.

[0109] In an example of changing one or more parameters in the FFP configuration based on receiving an indication from another node, the WTRU can receive an indication / request to change the WTRU's FFP configuration from another node (e.g., the WTRU). The WTRU can then (e.g.,) change the FFP configuration.

[0110] In an embodiment where one or more parameters in the FFP configuration (e.g., FFP periodicity and / or FFP offset value) are changed based on detecting semi - persistent CCA failure, the WTRU can (e.g., can decide to) change the FFP configuration of the WTRU (e.g., FFP offset, COT, and / or FFP) if the WTRU fails to access the channel N times during an observation period. For example, the WTRU can receive configuration information that indicates a channel access failure threshold (e.g., N). The WTRU can perform multiple channel access attempts (e.g., in an FFP switching window). The WTRU can determine that the number of channel access attempts meets the channel access failure threshold (e.g., the WTRU fails to access the channel N times). The value of N can be determined based on, for example, the COT and / or FFP of the WTRU. The value of N may be (pre -)configured.

[0111] The WTRU may fail to access the channel N times during the observation period. The WTRU can (e.g., based on the failure) change the FFP configuration and / or change the LBT band / sub-band (e.g., can decide to change). The WTRU can decide whether to change the FFP configuration and / or change the LBT band / sub-band, e.g., based on the channel busy ratio (CBR) of the resource pool. The WTRU can determine (e.g., measure) the CBR value associated with the resource pool and / or the LBT band. The WTRU can compare the CBR value with a CBR threshold. The WTRU can compare the CBR value with the CBR threshold based on the number of channel access attempts meeting the channel access failure threshold (e.g., the WTRU fails to access the channel N times). The WTRU can change (e.g., decide to change) the channel access parameters based on the comparison of the CBR value and the CBR threshold. For example, the WTRU can change (e.g., decide to change) the FFP configuration if the CBR of the resource pool is less than (e.g., below) a threshold (e.g., the CBR threshold). The WTRU can switch to a different LBT band / sub-band (e.g., decide to switch) if the CBR of the resource pool is greater than (e.g., the same) threshold (e.g., the CBR value meets the CBR threshold). The CBR threshold can be (pre-)configured (e.g., the WTRU can receive configuration information indicating the CBR threshold). The WTRU can change the channel access parameters (e.g., based on the decision). The WTRU can report to other nodes (e.g., gNB) that it has failed to access the channel N times during the observation period, where N can be (pre-)configured to be consecutive or non-consecutive.

[0112] In an example of changing one or more parameters in an FFP configuration based on detecting a semi - persistent reservation from another WTRU, the WTRU may detect a semi - persistent reservation from another WTRU, and as a result, at least N CCA failures may occur in the (e.g., one) observation period of the WTRU.

[0113] Figure 4 illustrates an example in which a WTRU continuously fails CCA based on, for example, one or more WTRUs in the system. As illustrated in Figure 4, the WTRU may receive semi - persistent CCA failures in multiple FFP. The WTRU (e.g., WTRU - A) may receive a CCA failure due to a collision with a plurality of WTRUs (e.g., WTRU - B, WTRU - C, WTRU - D) and due to a high system load (e.g., an example that may result in a high CBR) (e.g., in case 1). The WTRU - A may receive a CCA failure (e.g., an example that may result in a low CBR) (e.g., in case 2) by another WTRU (e.g., WTRU - B) with the same FFP and with a CCA slot earlier than the CCA slot of the WTRU - A. In case 1, the WTRU - A may be able to decide to switch to a different set of resource blocks (RBs) / LBT sub - bands. For example, the WTRU - A may be able to change to a set of resource blocks / LBT sub - bands when the CBR value meets the CBR threshold. In case 2, the WTRU - A may be able to decide to change the FFP configuration.

[0114] FIG. 5 illustrates an example where a WTRU is enabled to perform one or more actions to update (e.g., flexibly update) one or more access parameters. For example, the WTRU may be pre-configured with one or more of the following: a switching window (e.g., an FFP configuration switching window) that can be used by the WTRU to evaluate the status of channel access failure, a threshold number of channel access failures (e.g., a channel access failure threshold for the switching window), and / or a channel busy ratio (CBR) threshold. The WTRU can perform CCA (e.g., to obtain the current FFP). If CCA fails during a certain period (e.g., the current FFP), the WTRU can determine whether the number of CCA failures in the switching window (e.g., the FFP switching window) is greater than a certain threshold (e.g., the channel access failure threshold).

[0115] If the number of CCA failures in a switching window (e.g., an FFP switching window) is greater than a channel access failure threshold, the WTRU may determine whether a CBR (e.g., the CBR of a resource pool or the CBR of an LBT sub - band) is greater than a threshold (e.g., a CBR threshold). If the CBR (e.g., the CBR of a resource pool or the CBR of an LBT sub - band) is not greater than the CBR threshold, the WTRU may change to another configuration, e.g., another FFP configuration (e.g., change the FFP offset and / or the FFP). If the CBR (e.g., the CBR of a resource pool or an LBT sub - band) is greater than the CBR threshold, the WTRU may switch to another band (e.g., an LBT band). The duration of the switching window (e.g., an FFP switching window) may be (pre -)configured. The WTRU may use the switching window (e.g., an FFP switching window) to evaluate the channel status of the system. After each CCA failure, the WTRU may determine (e.g., first) the number of CCA failures within the switching window (e.g., an FFP switching window, e.g., the number of CCA failures that occurred during the duration of the FFP switching window). If the number of CCA failures in the switching window (e.g., an FFP switching window) is less than a (pre -)configured failure threshold, the WTRU may continue to use the configuration (e.g., an FFP configuration). If the number of CCA failures in the switching window (e.g., an FFP switching window) is greater than a (pre -)configured threshold, the WTRU may determine whether to switch to another resource pool or sub - band (e.g., an LBT sub - band) based on the CBR (e.g., of a resource pool or an LBT sub - band), or change the configuration (e.g., an FFP configuration, e.g., change the FFP offset and / or the FFP periodicity, etc.). For example, if the CBR (e.g., of a resource pool or an LBT sub - band) is less than a (pre -)configured threshold, the WTRU may change the configuration (e.g., an FFP configuration); otherwise, if the CBR (e.g., of a resource pool or an LBT sub - band) is greater than the threshold, the WTRU may switch to another band (e.g., another LBT sub - band).

[0116] A WTRU can receive configuration information that indicates a channel busy ratio (CBR) threshold. The WTRU can determine a CBR value associated with a channel in a listen before talk (LBT) band. The WTRU can compare the CBR value with the CBR threshold. The WTRU can determine channel access parameters to change based on a comparison of the CBR value with the CBR threshold. The WTRU can change the channel access parameters.

[0117] The configuration information can indicate a channel access failure threshold and a fixed frame period (FFP) switching window. The WTRU can perform a plurality of channel access attempts associated with the FFP switching window (e.g., before comparing the CBR value with the CBR threshold). The WTRU can determine that the number of channel access attempts (e.g., before comparing the CBR value with the CBR threshold) meets the channel access failure threshold.

[0118] Comparing the CBR value with the CBR threshold can involve comparing the CBR value with the CBR threshold based on the number of channel access attempts meeting the channel access failure threshold. Changing the channel access parameters can involve changing the FFP configuration if the CBR value is less than the CBR threshold. The FFP configuration can include one or more of FFP periodicity or an FFP offset value. Changing the channel access parameters can involve switching to a different LBT band or sub - band if the CBR value meets the CBR threshold. Changing the channel access parameters can involve changing a resource block set if the CBR value meets the CBR threshold.

[0119] This specification provides functions related to sidelink feedback. A WTRU can request HARQ feedback for the transmission of a TB (e.g., once). The WTRU can perform (e.g., determine to perform) the transmission of an HARQ-enabled TB. The WTRU can request HARQ feedback for the transmission (e.g., an acknowledgement (ACK) / negative acknowledgement (NACK), ACK only, NACK only). The WTRU can request, for example, in one or more of the following periods (e.g., any combination), that the Rx WTRU perform HARQ feedback: during the (e.g., one) (pre-)configured PSFCH transmission timing within a resource pool, during the current COT, and / or during the FFP (e.g., the Rx WTRU can share the COT with the Tx WTRU), during a future COT, and / or during the FFP, during (e.g., one) COT of the (e.g., one) Rx WTRU, and / or during the FFP, and / or during a future requested period.

[0120] The WTRU can determine, for example, based on one or more of the following (e.g., any combination), the period for which to request HARQ feedback and / or the HARQ feedback transmission timing: the QoS of the TB, the remaining number of transmissions of the WTRU in the current COT and / or FFP, whether the Tx WTRU initializes its own COT and / or FFP or shares it with other nodes, the remaining COT duration, the gap to the next COT and / or FFP of the Tx WTRU, the gap to the next COT and / or FFP of the Rx WTRU, the availability of the Rx WTRU's semi-static reservation, the availability of the Tx WTRU's semi-static reservation, the transmission cast type for the TB, and / or the availability of the FFP configuration of the Rx WTRU.

[0121] The WTRU can determine, for example, the period during which HARQ feedback is required and / or the HARQ feedback transmission timing based on the QoS of the TB. The WTRU can require, for example, that the Rx WTRU perform HARQ feedback for transmission in the current COT and / or FFP (e.g., once) when the QoS of the TB (e.g., priority, remaining permitted delay time (PDB), etc.) meets a criterion (e.g., the priority of the TB is less than a threshold, or the remaining PDB of the TB is less than a threshold). The WTRU can (e.g., originally) require that the Rx WTRU perform HARQ feedback for transmission in another COT and / or FFP (e.g., the COT and / or FFP of the Rx WTRU, or the future COT and / or FFP of the Tx WTRU). The WTRU can require, for example, based on the remaining PDB of the TB, that the Rx WTRU perform HARQ feedback in a future requested period (e.g., be able to determine whether to require it). The WTRU can require, for example, that the Rx WTRU perform HARQ feedback in a future requested period when the remaining PDB of the TB is greater than a threshold. The WTRU can require, for example, that the Rx WTRU perform HARQ feedback in another COT and / or FFP (e.g., the current COT and / or FFP of the Tx WTRU) when the remaining PDB of the TB is less than (e.g., the same) threshold (e.g., below).

[0122] The WTRU can determine, for example, the period for which HARQ feedback is requested and / or the HARQ feedback transmission timing, based on, for example, the remaining number of transmissions of the WTRU in the current COT and / or FFP. The Tx WTRU can request (e.g., can determine to request) that the Rx WTRU perform HARQ feedback in the current COT and / or FFP, if, for example, the remaining number of transmissions (e.g., the remaining number of transmissions and / or the remaining number of TBs to be transmitted within the COT) is within a range. The WTRU can request that the Rx WTRU transmit HARQ feedback in another COT and / or FFP (e.g., the COT and / or FFP of the Rx WTRU, or the future COT and / or FFP of the Tx WTRU), if, for example, the remaining number of transmissions is outside a range (e.g., including the minimum number of remaining transmissions and / or the maximum number of remaining transmissions).

[0123] The WTRU can determine, for example, the period for which HARQ feedback is requested and / or the HARQ feedback transmission timing, based on whether the Tx WTRU initializes its own COT and / or FFP or shares the COT and / or FFP with another node. For example, the TX WTRU can request (e.g., when the TX WTRU initializes the COT) that the Rx WTRU perform HARQ feedback in the current COT and / or FFP. The Tx WTRU can request that the Rx WTRU perform HARQ feedback in another COT and / or FFP (e.g., the COT and / or FFP of the Rx WTRU, or the next COT and / or FFP of the Tx WTRU, etc.), if, for example, the TX WTRU does not initialize the COT.

[0124] The WTRU can determine, for example, the period for requesting HARQ feedback and / or the HARQ feedback transmission timing based on, for example, the remaining COT duration. The Tx WTRU can request, for example, that the Rx WTRU transmit HARQ feedback in its current FFP if the remaining COT duration is greater than a threshold. The WTRU can request, for example, that the Rx WTRU transmit HARQ feedback in another COT and / or FFP (e.g., the COT and / or FFP of the RX WTRU, or the future COT and / or FFP of the Tx WTRU) if the remaining COT duration is less than (e.g., the same) threshold (e.g., below). One or more thresholds can be (pre-)configured based on, for example, the QoS of the TB (e.g., priority and / or the remaining PDB of the TB).

[0125] The WTRU can determine, for example, the period for requesting HARQ feedback and / or the HARQ feedback transmission timing based on, for example, the gap to the next COT and / or FFP of the Tx WTRU. The WTRU can request, for example, that the Rx WTRU perform HARQ feedback in the next COT and / or FFP of the Tx WTRU if the time gap to the next COT and / or FFP of the Tx WTRU is less than a threshold. The WTRU can request, for example, that the Rx WTRU perform feedback in another COT and / or FFP (e.g., the current COT and / or FFP of the Tx WTRU, the future COT and / or FFP of the Rx WTRU) if the time gap to the next COT and / or FFP of the Tx WTRU is greater than (e.g., the same) threshold (e.g., above). One or more thresholds can be (pre-)configured based on, for example, the QoS of the TB (e.g., priority and / or the remaining PDB of the TB).

[0126] The WTRU can determine, for example, the period for which HARQ feedback is required and / or the HARQ feedback transmission timing based on, for example, the next COT of the Rx WTRU and / or the gap to the FFP. The WTRU can require, for example, that the Rx WTRU perform HARQ feedback in the next COT of the Rx WTRU and / or the FFP if the time gap to the next COT of the Rx WTRU and / or the FFP is less than a threshold. The WTRU can require, for example, that the Rx WTRU perform feedback in another COT and / or FFP (e.g., the current COT of the Tx WTRU and / or the FFP, a future COT of the Tx WTRU and / or the FFP) if the time gap to the next COT of the Rx WTRU and / or the FFP is greater than (e.g., equal to or greater than) a (e.g., same) threshold. One or more thresholds can be (pre-)configured based on, for example, the QoS of the TB (e.g., priority and / or the remaining PDB of the TB).

[0127] The WTRU can determine, for example, the period for which HARQ feedback is required and / or the HARQ feedback transmission timing based on the availability of the Rx WTRU's semi-static reservation. The Tx WTRU can require (e.g., determine that) the Rx WTRU perform HARQ feedback for transmission by the Tx WTRU in the COT of the Rx WTRU and / or the FFP based on, for example, whether the Rx WTRU reserves one or more semi-static resources. The Tx WTRU can require (e.g., determine that) the Rx WTRU perform HARQ feedback in the COT of the RX WTRU and / or the FFP if, for example, the earliest COT of the Rx WTRU and / or the FFP is less than a threshold. The threshold can be (pre-)configured based on, for example, the QoS of the TB (e.g., priority and / or the remaining PDB of the TB).

[0128] The WTRU can determine, for example, the period for which HARQ feedback is requested and / or the HARQ feedback transmission timing, based on the availability of, for example, the semi-static reservation of the Tx WTRU. The Tx WTRU can, for example, request (e.g., determine to request) that the Rx WTRU perform HARQ feedback in one of the Tx WTRU's COT and / or FFP if the Tx WTRU has one or more semi-static reservation resources.

[0129] The WTRU can determine, for example, the period for which HARQ feedback is requested and / or the HARQ feedback transmission timing, based on the transmission cast type for the TB. For example, the WTRU (e.g., the Tx WTRU) can request (e.g., determine to request) that the Rx WTRU perform HARQ feedback in a future COT and / or FFP for unicast transmission, or in the Rx WTRU's COT and / or FFP. The WTRU can request (e.g., determine to request) that the Rx WTRU perform HARQ feedback in the Tx WTRU's future COT and / or FFP (e.g., for groupcast transmission).

[0130] The WTRU can determine, for example, the period for which HARQ feedback is requested and / or the HARQ feedback transmission timing, based on the availability of the FFP configuration of the Rx WTRU. For example, if the FFP configuration of the Rx WTRU is not available, the WTRU can request that the Rx WTRU perform HARQ feedback in the Tx WTRU's COT and / or FFP. If the FFP configuration of the Rx WTRU is available, the Tx WTRU can request that the Tx WTRU or the Rx WTRU perform HARQ feedback in the COT and / or FFP.

[0131] Figure 6 illustrates an example of a HARQ feedback option for transmission that requests HARQ feedback. As shown by the example of Figure 6, WTRU-A can initialize its COT in one COT and / or FFP. The WTRU (e.g., WTRU-A) can have, for example, three TBs for transmission in the COT and / or FFP. WTRU-A can, for example, as one of three options, request that the Rx WTRU (e.g., WTRU-B) perform HARQ feedback. In an example of the first option (Option 1), WTRU-A can request that WTRU-B perform HARQ feedback in the current COT of the Tx WTRU and / or FFP. In an example of the second option (Option 2), WTRU-A can request that WTRU-B perform HARQ feedback in the COT of WTRU-B and / or FFP. In the third option (Option 3), WTRU-A can request that WTRU-B perform HARQ feedback in the next COT of the Tx WTRU and / or FFP.

[0132] The WTRU can determine the PSFCH transmission timing and / or the PSFCH resources. The WTRU (e.g., Tx WTRU) can determine, for example, the COT and / or the FFP that perform HARQ feedback for transmission of the TB. The WTRU can determine the PSFCH transmission timing (e.g., the slot within the COT and / or the FFP) for performing HARQ feedback. The WTRU can determine the PSFCH resources at the PSFCH transmission timing for performing HARQ feedback. In some embodiments, the WTRU can be (pre)-configured with an (e.g., implicit) mapping between the PSCCH / PSSCH and the PSFCH resources. In some embodiments, the Tx WTRU can determine the PSFCH resources. In some embodiments, the Tx WTRU can determine the COT and / or the FFP, and / or the Rx WTRU can determine the PSFCH transmission timing and / or the PSFCH resources at the PSFCH transmission timing. In some embodiments, the Tx WTRU can determine the COT and / or the FFP and / or the PSFCH transmission timing, and / or the Rx WTRU can determine the PSFCH resources within the indicated PSFCH transmission timing.

[0133] A WTRU (e.g., a Tx or Rx WTRU) can determine the PSFCH transmission timing for performing HARQ feedback and / or the PSFCH resources based on, for example, one or more of the following (e.g., any combination): the slot index of the PSCCH / PSSCH, the resource index of the PSCCH / PSSCH within the slot (e.g., the interleaving index), the number of interleavings per PSCCH / PSSCH slot, the time gap between the PSCCH / PSSCH and PSFCH slots, the destination ID associated with the PSCCH / PSSCH transmission, the source ID of the Tx WTRU, the member ID of the Rx WTRU (e.g., for groupcast communication), the WTRU ID of the Rx WTRU, the COT and / or FFP associated with the HARQ feedback resource, one or more FFP configuration parameters of the FFP associated with the HARQ feedback resource, and / or the order of HARQ feedback attempts for transmission.

[0134] The Tx WTRU can indicate the maximum number of HARQ feedback attempts. In some embodiments, the WTRU (e.g., the Tx WTRU) can require the Rx WTRU to access the channel one or more times to perform HARQ feedback. The Tx WTRU can indicate to the Rx WTRU one or more of the following information (e.g., any combination) for HARQ feedback for a (e.g., single) transmission: the maximum number of HARQ feedback attempts, the window of HARQ feedback, and / or the maximum latency for HARQ feedback. For example, the Tx WTRU can indicate the maximum number of HARQ feedback attempts to the Rx WTRU. The Tx WTRU can trigger, for example, resource allocation for retransmission of the TB if the Tx WTRU has not received a HARQ ACK feedback from the Rx WTRU after the maximum number of HARQ transmission timings.

[0135] One or more (e.g., any combination) of the parameters (e.g., as indicated by the Tx WTRU to the Rx WTRU) can be determined based on, for example, one or more (e.g., any combination) of the following: the QoS of the TB (e.g., the priority of the TB and / or the remaining PDB of the TB), and / or (e.g., one) COT, and / or the PSFCH configuration in the FFP. For example, the WTRU can indicate the maximum latency for HARQ feedback, which can be responsive to the remaining PDB of the TB (e.g., half of the remaining PDB). For example, the WTRU can determine the maximum number of HARQ feedback attempts based on the number of PSFCH transmission timings per period.

[0136] The WTRU can perform a retransmission for the TB based on the HARQ feedback status. The WTRU (e.g., the Tx WTRU) can indicate / configure multiple HARQ feedback transmission timings for the transmission of the TB (e.g., one time). The WTRU can perform (e.g., determine) a retransmission of the TB based on, for example, the HARQ feedback status for the previous transmission of the TB. The WTRU can perform a retransmission of the TB based on, for example, one or any combination of the following: the WTRU has not received the HARQ ACK feedback for at least N transmission timings, the WTRU has not received the HARQ ACK feedback in N COTs and / or FFP (e.g., N = 1), and / or the WTRU has acquired channels of other COTs and / or FFP (e.g., for the transmission of other TBs).

[0137] The WTRU can perform a retransmission of the TB, for example, if the WTRU has not received the HARQ ACK feedback for at least N transmission timings. The value of N can be determined based on, for example, the QoS of the TB (e.g., priority and / or the remaining PDB of the TB). The value of N can be conveyed to the Rx WTRU in the transmission that requires HARQ feedback.

[0138] The WTRU can execute a retransmission of the TB, for example, when the WTRU has not received a HARQ ACK feedback in N COTs and / or FFP (e.g., N = 1). For example, the WTRU can request that the WTRU execute a HARQ feedback in its current COT and / or FFP. The WTRU can execute a retransmission in a future COT and / or FFP, for example, when the WTRU has not received a HARQ ACK feedback at the (e.g., all) transmission timings of the current COT and / or FFP.

[0139] For example, when the WTRU has acquired channels of other COTs and / or FFP (e.g., for transmission of other TBs), the WTRU can execute a retransmission of the TB. For example, the WTRU may not be able to receive a HARQ ACK feedback for transmission of the TB. The WTRU can acquire channels in another COT and / or FFP (e.g., then). In some embodiments, the WTRU can execute a retransmission of the TB in the newly acquired channels of the new COT and / or FFP and can execute a retransmission of the TB. In some embodiments, the WTRU can determine whether to execute a retransmission of the TB based on one or any combination of the following: the remaining PDB of the TB and / or the priority of the TB.

[0140] The WTRU can determine whether to execute a retransmission of the TB, for example, based on the remaining PDB of the TB. The WTRU can execute a retransmission of the TB, for example, when the remaining PDB of the TB is less than a threshold. The WTRU does not have to execute a retransmission for the TB in the current COT and / or FFP, for example, when the remaining PDB of the TB is greater than the threshold. The threshold can be (pre-)configured, for example, based on the QoS of the TB (e.g., priority and / or the remaining PDB of the TB).

[0141] The WTRU can determine whether to perform a retransmission of a TB, for example, based on the priority of the TB. The WTRU can perform a retransmission of the TB, for example, when the remaining PDB of the TB is less than a threshold. The WTRU does not need to perform a retransmission for the TB in the current COT and / or FFP, for example, when the remaining PDB of the TB is greater than the threshold. The threshold can be (pre-)configured, for example, based on the QoS of the TB (e.g., priority and / or the remaining PDB of the TB).

[0142] The WTRU can determine when to end a HARQ feedback attempt for a (e.g., single) transmission. In some embodiments, the WTRU (e.g., Tx WTRU, Rx WTRU) can have multiple HARQ feedback attempts that transmit the HARQ feedback for the transmission to the Tx WTRU. The Rx WTRU can attempt to access the channel (e.g., sequentially) at each HARQ feedback attempt transmission timing (e.g., by performing CCA). The WTRU can attempt to access the channel at the next HARQ feedback attempt transmission timing (e.g., in the next COT and / or FFP), for example, if the WTRU fails to access the channel at the HARQ feedback attempt transmission timing for a (e.g., single) transmission. The WTRU can stop the procedure, for example, based on one or more (e.g., any combination of) events described herein and / or one or more (e.g., any combination of) the following events: the WTRU has successfully transmitted HARQ feedback at a (e.g., single) transmission timing, the WTRU has reached the maximum number of HARQ feedback attempts (e.g., if the WTRU cannot access the channel after the maximum number of HARQ feedback attempts, the WTRU may report a channel access failure to another node such as the gNB), and / or the WTRU has reached the maximum HARQ feedback latency.

[0143] The WTRU may determine a COT, and / or an FFP, that performs HARQ feedback for a (e.g., single) transmission. The WTRU (e.g., Rx WTRU) may perform (e.g., be permitted to perform) HARQ feedback for a (e.g., single) transmission of a TB in multiple COTs, and / or FFPs, where the HARQ feedback may include one or more (e.g., any combination) of the following COTs, and / or FFP / transmission timings: during one (pre)configured PSFCH transmission timing within a resource pool, during the current COT, and / or FFP (e.g., the Rx WTRU may share the COT with the Tx WTRU), during a future COT, and / or FFP, during (e.g., one) COT, and / or FFP of (e.g., one) Rx WTRU, and / or during a future requested period.

[0144] The WTRU (e.g., Rx WTRU) may determine the COT, and / or FFP / transmission timing for performing HARQ feedback, based on, for example, one or more (e.g., any combination) of the following: an indication from the Tx WTRU, the availability of data in a buffer (e.g., the WTRU may determine to perform HARQ feedback in a COT, and / or FFP if there is data to transmit to the WTRU), the availability of data in a buffer targeted for the Tx WTRU (e.g., the WTRU may determine to perform HARQ feedback in a COT, and / or FFP if there is data for the Tx WTRU at the WTRU), the availability of reserved resources of the WTRU (e.g., the WTRU may determine to perform HARQ feedback in a COT, and / or FFP if there are semi-persistent resources reserved for the WTRU).

[0145] The Tx WTRU may indicate information regarding HARQ feedback for transmission. The WTRU (e.g., Tx WTRU) may indicate one or more (e.g., any combination) of the following information regarding HARQ feedback for transmission to another WTRU (e.g., Rx WTRU): the COT of the WTRU, and / or the PSFCH configuration in the FFP, the COT for transmitting HARQ feedback for transmission, and / or the FFP, the HARQ feedback transmission timing, the COT, and / or the HARQ resources in the FFP, the HARQ feedback resources for the HARQ feedback transmission timing, the HARQ ID, and / or the CCA / LBT period before the PSFCH transmission timing (e.g., no CCA / LBT, a fixed CCA / LBT duration such as 9 μs, 16 μs, or 25 μs, and / or a flexible CCA / LBT duration).

[0146] The WTRU may use one or more (e.g., any combination) of the following to send a message carrying information regarding HARQ feedback: SCI (e.g., second SCI, or third SCI), MAC CE, and / or PC5 RRC. The WTRU may use an SCI (e.g., second SCI, or third SCI) message to carry information regarding HARQ feedback. For example, the WTRU (e.g., Tx WTRU) may use the SCI to indicate the COT, and / or the FFP, the HARQ transmission timing, and / or the HARQ resources for performing HARQ feedback. The WTRU may use a MAC CE message to carry information regarding HARQ feedback. For example, the WTRU may use a MAC CE message to request that the Rx WTRU feedback the status of multiple HARQ IDs. The WTRU may use a PC5 RRC message to carry information regarding HARQ feedback. For example, the WTRU may use PC5 RRC to send the PSFCH configuration and the CCA period.

[0147] The Rx WTRU can perform (e.g., provide) HARQ feedback to the Tx WTRU. The Rx WTRU can use one or more of the following messages (e.g., any combination) to perform HARQ feedback regarding one or more transmissions of one or more TB / HARQ process identifiers (HARQ IDs): PSFCH, SCI (e.g., second SCI, or third SCI), MAC CE, and / or PC5 RRC.

[0148] The WTRU (e.g., Rx WTRU) can determine a message for sending HARQ feedback to the Tx WTRU based on, for example, one or more of the following (e.g., any combination): the COT in which the WTRU performs HARQ feedback, and / or FFP, and / or the number of HARQ IDs to feedback to the Tx WTRU.

[0149] The WTRU (e.g., Rx WTRU) can determine a message for sending HARQ feedback to the Tx WTRU based on, for example, the COT and / or FFP in which the WTRU performs HARQ feedback. The WTRU can use PSFCH, for example, if the WTRU performs HARQ feedback for (e.g., one) transmission in the FFP of the Tx WTRU. The WTRU can use SCI, MAC CE, and / or PC5 RRC to feedback the status of one or more HARQ IDs to the Tx WTRU, for example, if the WTRU does not perform HARQ feedback for (e.g., one) transmission in the FFP of the Tx WTRU.

[0150] A WTRU (e.g., an Rx WTRU) can determine a message for sending HARQ feedback to a Tx WTRU, for example, based on the number of HARQ IDs to feedback to the Tx WTRU. For example, the WTRU may be requested to feedback the status of a plurality of HARQ IDs to the Tx WTRU. The WTRU can feedback the status of those HARQ IDs, for example, using SCI, MAC CE, and / or PC5 RRC.

[0151] The Tx WTRU may indicate the maximum number of HARQ feedback attempts. In some embodiments, the WTRU (e.g., the Tx WTRU) can require the Rx WTRU to access the channel one or more times to perform HARQ feedback. The Tx WTRU can indicate to the Rx WTRU one or more of the following information (e.g., any combination) for HARQ feedback of a (e.g., single) transmission: the maximum number of HARQ feedback attempts, the HARQ feedback window, and / or the maximum latency for HARQ feedback.

[0152] One or more of the parameters (e.g., any combination) can be determined, for example, based on one or more of the following (e.g., any combination): the QoS of the TB (e.g., the priority of the TB and / or the remaining PDB of the TB), and / or (e.g., one) COT, and / or the PSFCH configuration in the FFP. One or more of the parameters (e.g., any combination) can be determined, for example, based on the QoS of the TB (e.g., the priority of the TB and / or the remaining PDB of the TB). For example, the WTRU can indicate the maximum latency for HARQ feedback, which may depend on the remaining PDB of the TB (e.g., half of the remaining PDB). One or more of the parameters (e.g., any combination) can be determined, for example, based on one COT and / or the PSFCH configuration in the FFP. For example, the WTRU can determine the maximum number of HARQ feedback attempts based on the number of PSFCH transmission timings per period.

[0153] The WTRU can determine the HARQ feedback transmission timing for performing (e.g., a single) HARQ feedback for transmission. The WTRU (e.g., Rx WTRU) can perform (e.g., be permitted to perform) the HARQ feedback for transmission of the TB at a plurality of HARQ feedback transmission timings. The WTRU can, for example, access the channel and / or perform the HARQ feedback at one or more (e.g., all) feedback transmission timings in chronological order when the WTRU has acquired the channel (e.g., can determine to access and / or perform). The WTRU can determine the HARQ feedback transmission timing for feedback based on, for example, one or more of the following (e.g., any combination): the availability of data in the buffer, the availability of data in the buffer targeted for the Tx WTRU, and / or the availability of reserved resources of the WTRU.

[0154] The WTRU can determine the HARQ feedback transmission timing for feedback based on, for example, the availability of data in the buffer. For example, the WTRU can perform the HARQ feedback for transmission at the (e.g., one) PSFCH transmission timing at which the WTRU performs the PSCCH / PSSCH transmission (e.g., when there is data to be transmitted to the WTRU). The WTRU can perform the HARQ feedback at the (e.g., first) PSFCH transmission timing of the COT and / or FFP of the WTRU where the COT and / or FFP can first occur (e.g., when there is no data to be transmitted to the WTRU).

[0155] The WTRU can determine the HARQ feedback transmission timing to feedback, for example, based on the availability of data in the buffer targeted at the Tx WTRU. For example, the WTRU can piggyback the HARQ feedback in the transmission to the Tx WTRU (e.g., in the SCI of the transmission to the Tx WTRU, or in the MAC CE).

[0156] The WTRU can determine the HARQ feedback transmission timing to feedback, for example, based on the availability of reserved resources of the WTRU. For example, if the WTRU has one or more reserved resources, the WTRU can perform the HARQ feedback in the same slot having a (e.g., one) reservation period (e.g., at the end of the slot).

[0157] The WTRU may request HARQ feedback in the current COT and / or FFP. For example, the Tx WTRU can request that the Rx WTRU perform HARQ feedback in the current COT of the Tx WTRU and / or FFP. In some embodiments, the Tx WTRU can indicate the PSFCH transmission timing and PSFCH resources to the Rx WTRU. In some embodiments, the Tx WTRU can indicate the PSFCH transmission timing to the Rx WTRU. The Rx WTRU can determine the PSFCH resources (e.g., next) based on, for example, one or more of the following (e.g., any combination): the time gap between the PSFCH and the PSCCH / PSSCH, the number of interleaves per PSCCH / PSSCH slot, the slot index of the PSCCH / PSSCH, the resource index of the PSCCH / PSSCH in the slot (e.g., interleave index), the time gap between the PSCCH / PSSCH and the PSFCH slot, the destination ID associated with the PSCCH / PSSCH transmission, the source ID of the Tx WTRU, the member ID of the Rx WTRU (e.g., for groupcast communication), and / or the WTRU ID of the Rx WTRU.

[0158] Figure 7 illustrates an example of an implicit mapping rule between PSCCH / PSSCH and PSFCH resources. As illustrated in Figure 7, the Tx WTRU can request the Rx WTRU to perform HARQ feedback at the end of the COT. The Rx WTRU can determine the PSFCH resources at the PSFCH transmission timing, for example, based on the implicit mapping rule between PSCCH / PSSCH and PSFCH resources.

[0159] FIG. 8 illustrates an example of a WTRU that determines a set of REs / PRBs for feedback of associated PSCCH / PSSCH. The WTRU can determine a set of REs / PRBs for transmitting HARQ feedback. At a PSFCH transmission timing (e.g., a PSFCH slot), the WTRU can be configured with a set of REs / PRBs (e.g., two sets of REs / PRBs) for transmitting HARQ feedback. A first set of REs / PRBs can be used for a WTRU (e.g., any WTRU) transmitting a PSFCH in a slot, and another set of REs / PRBs can be used by the WTRU to feedback a HARQ status (e.g., HARQ ACK / NACK) associated with a PSCCH / PSSCH. The WTRU can determine a subset of REs / PRBs within a second set of REs / PRBs for feedback of the HARQ status of the associated PSCCH / PSSCH based on one or more of the following: an interleaving index of the PSCCH / PSSCH, a slot index of the PSCCH / PSSCH, a number of slots associated with the PSFCH, a number of PRBs / REs within the second set of REs / PRBs configured within one PSFCH slot, a source ID of the associated PSCCH / PSSCH, a destination ID of the associated PSCCH / PSSCH, a cast type of the TB, or in the case of groupcast option 2, a member ID within the group and a number of members. For HARQ transmission, the WTRU can transmit with REs / PRBs within the first and second sets of REs / PRBs (e.g., both sets of REs / PRBs). The WTRU can transmit a default sequence with the first set of REs / PRBs. A sequence transmitted within a subset of REs / PRBs within the second set can be used to carry a HARQ ACK or HARQ NACK feedback. This can help the WTRU meet the occupied channel bandwidth (OCB) requirement for PSFCH transmission. As seen in FIG. 8, the WTRU can be pre-configured with a first set of REs / PRBs 802 and a second set of REs / PRBs 804 as a set of REs / PRBs (e.g., two sets) within a PSFCH slot.The PSFCH transmission timing (e.g., each PSFCH transmission timing) may have four PSCCH / PSSCH slots. The WTRU can determine the RE / PRB to feedback the associated PSCCH / PSSCH based on the position of the PSCCH / PSSCH and the mapping function between the PSCCH / PSSCH and the PSFCH. For example, the Rx WTRU may receive the PSCCH / PSSCH in the interleaving 806 and may determine the PRB in the second set of RE / PRB. The Rx WTRU can provide the HARQ feedback for the associated PSCCH / PSSCH transmission in the interleaving 806. Specifically, the WTRU can perform the HARQ ACK / NACK transmission that occupies two PRBs 808 of the first set of RE / PRB and one PRB 810 of the second set of RE / PRB. The two PRBs 808 can be used to meet the OCB requirement. The PRB 810 can be used to carry the ACK or NACK bit.

[0160] The WTRU can determine the transmission type for the TB. The WTRU can be (pre)-configured, for example, in one or more (e.g., any combination) of the following LCH / SLRBs (e.g., regarding the HARQ feedback options for one or more transmissions of a TB having each LCH): HARQ-enabled LCH / SLRB, HARQ-disabled LCH / SLRB, and / or HARQ-mixed LCH / SLRB. The WTRU can be (pre)-configured with a HARQ-enabled LCH / SLRB. The WTRU may not request HARQ feedback for a (e.g., any) transmission of the TB for the transmission of the TB including a HARQ-enabled type of LCH / SLRB. The WTRU can be (pre)-configured with a HARQ-disabled LCH / SLRB. In some embodiments, the WTRU may not be able to request HARQ feedback for a (e.g., each) transmission of the TB for the transmission of the TB including a HARQ-disabled type of LCH / SLRB. The WTRU can be (pre)-configured with a HARQ-mixed LCH / SLRB. In some embodiments, the WTRU may request HARQ feedback for one (e.g., one) set of transmissions and may not request HARQ feedback for another set of transmissions for the transmission of the TB including a HARQ-mixed type of LCH / SLRB.

[0161] The WTRU can enforce logical channel prioritization (LCP) restrictions for various types of LCH / SLRBs. The WTRU can enforce LCP restrictions for various types of HARQ feedback LCH / SLRBs. In some embodiments, the WTRU can limit (e.g., each) type of LCH / SLRB to be multiplexed. The WTRU can enable HARQ-enabled LCH / SLRBs and HARQ hybrid LCH / SLRBs to be multiplexed. The WTRU can consider a multiplexed TB as a HARQ hybrid TB, in which case the WTRU can request HARQ feedback for (e.g., one) set of transmissions and not request HARQ feedback for another set of transmissions. The WTRU can consider a multiplexed TB as a HARQ-enabled TB, in which case the WTRU can request HARQ feedback for one or more (e.g., any) transmissions of the TB.

[0162] The WTRU can determine whether to request HARQ feedback for (e.g., one) transmission of the TB. In some embodiments, the WTRU can perform more than one transmission for (e.g., one) HARQ-enabled TB. For example, the WTRU can perform (e.g., determine to perform) HARQ hybrid transmission for the TB if the WTRU requests HARQ feedback for (e.g., one) set of transmissions and the WTRU does not request HARQ feedback for another set of transmissions of the TB. The WTRU can then (e.g., next) determine whether to require the Rx WTRU to perform HARQ feedback for (e.g., one) transmission based on one or more (e.g., any combination) of the following: the order of transmissions within the TB and / or the time gap to the PSFCH slot within the current COT of the Tx WTRU.

[0163] The WTRU can determine whether to require the Rx WTRU to perform HARQ feedback for transmission based on the order of transmission in the TB. For example, the WTRU can perform consecutive transmissions of the TB. The WTRU may not require the Rx WTRU to perform HARQ feedback for the initial transmission and / or one or more intermediate transmissions. If the WTRU does not require HARQ feedback, the WTRU may implicitly or explicitly indicate in the SCI (e.g., the second SCI) that HARQ feedback is not required for transmission. The WTRU can require the Rx WTRU to perform HARQ feedback for the final transmission of the TB in the COT. If the WTRU requires HARQ feedback, the WTRU may implicitly / explicitly indicate in the SCI (e.g., the second SCI) that HARQ feedback is required for transmission.

[0164] The WTRU can determine whether to require the Rx WTRU to perform HARQ feedback for transmission based on the time gap for the PSFCH slot in the current COT of the Tx WTRU. For example, the WTRU can perform consecutive transmissions of the TB. The WTRU can determine, for example, the transmission of the TB in the FFP that requires HARQ feedback based on the time gap between the transmission and the PSFCH transmission timing. The WTRU can select a transmission (e.g., one time) for which HARQ feedback is required where the time gap between the transmission slot and the PSFCH slot is greater than a threshold. The threshold can be determined, for example, based on the WTRU processing capability (e.g., the threshold can be 2 or 3 slots).

[0165] The WTRU can determine whether to perform CCA for PSFCH transmission timing. The WTRU can be requested / instructed to perform PSFCH at a certain transmission timing (e.g., one transmission timing). The WTRU may not need to perform CCA. The WTRU can perform (e.g., directly) PSFCH transmission at the instructed transmission timing. The WTRU can perform CCA before the PSFCH transmission timing to determine the channel availability before performing PSFCH transmission. The WTRU can determine (e.g., one) CCA / LBT duration before the PSFCH transmission timing (e.g., no CCA / LBT, first duration CCA / LBT, second duration CCA / LBT, flexible duration CCA / LBT, etc.) based on, for example, one or more of the following (e.g., any combination): pre-configuration in the resource pool, instruction from the Tx WTRU, availability of transmissions from other WTRUs in the current slot, and / or QoS of the TB (e.g., priority, remaining PDB of the TB). For example, the WTRU (e.g., Rx WTRU) can be (pre-)configured in a resource pool with periodic PSFCH slots. The WTRU can be (pre-)configured to perform CCA / LBT for a fixed duration (e.g., 9 μs / 16 μs / 25 μs) before transmitting HARQ feedback. The WTRU can determine the CCA / LBT duration according to the resource pool configuration. The WTRU can transmit HARQ feedback if the channel is in an inoperative state. Otherwise, the WTRU cannot transmit HARQ feedback in that slot.

[0166] The WTRU can determine the CCA duration before (e.g., one) PSFCH transmission timing based on, for example, an instruction from the Tx WTRU.

[0167] The WTRU can determine the CCA duration prior to (e.g., one) PSFCH transmission timing, for example, based on the availability of transmissions from other WTRUs in the current slot. The WTRU may not be able to perform (e.g., may decide not to perform) CCA if, for example, the WTRU detects (e.g., via SCI decoding and / or received signal strength indicator (RSSI) measurement) that (e.g., one) WTRU is performing a transmission in the current slot. The WTRU can decide to perform CCA if, for example, it does not detect that (e.g., any) WTRU within the system is performing a transmission in the current slot. The WTRU may not be able to perform (e.g., may decide not to perform) CCA if, for example, the WTRU detects that (e.g., one) WTRU has reserved resources in the current slot. Transmissions that reserve resources in the current slot can be performed in the same COT and / or FFP of the current slot. The WTRU can perform CCA if, for example, it does not detect (e.g., any) WTRU performing a transmission in the current COT and / or FFP reserving a transmission in the current slot of the PSFCH.

[0168] The WTRU can determine the CCA duration prior to (e.g., one) PSFCH transmission timing, for example, based on the QoS of the TB (e.g., priority, remaining PDB of the TB). The WTRU may not be able to perform (e.g., may decide not to perform) CCA if, for example, the priority of the TB is higher than a threshold. The WTRU may be able to perform CCA if, for example, the priority of the TB is less than (e.g., the same) threshold (e.g., below). The WTRU can delay the PSFCH transmission if, for example, the CCA is not cleared. The threshold for the priority of the TB can be (pre-)configured.

[0169] The WTRU can determine whether to puncture / rate match the PSCCH / PSSCH in the PSFCH slot. The WTRU (e.g., Tx WTRU) can perform the PSCCH / PSSCH in a slot that may have (e.g., potential) PSFCH transmissions. The WTRU can determine whether to rate match / puncture (e.g., one) portion of the PSCCH / PSSCH resources (e.g., within the CCA period and / or within the region overlapping with the PSFCH) based on whether there is a (e.g., any) PSFCH scheduled within the slot. The WTRU can, for example, rate match / puncture (e.g., one) portion of the PSCCH / PSSCH if it determines that there is one or more PSFCHs scheduled within the slot by the WTRU. The WTRU cannot rate match / puncture the PSCCH / PSSCH if it is determined, for example, by the WTRU that the PSFCH is not scheduled in the slot. The WTRU can determine whether there is one or more PSFCHs scheduled in the slot based on, for example, one or more of the following (e.g., any combination): whether the COT is shareable in the frequency domain, whether the WTRU instructs another WTRU to perform PSFCH transmission in the slot, and / or whether the WTRU detects any other WTRU that instructs PSFCH transmission in the slot. For example, in one of the transmissions, the WTRU can instruct / request that the receiver-side WTRU report the PSFCH in the current slot. The WTRU can expect to receive the PSFCH in the current slot. The WTRU can puncture / rate match the PSCCH / PSSCH for one or more symbols to receive the PSFCH. For example, in the slot associated with the PSFCH, the WTRU can perform the transmission without using (e.g., without requesting) the Rx WTRU to provide feedback.The WTRU can determine not to rate match / puncture its PSCCH / PSSCH transmission in the current slot for PSFCH transmission. The WTRU may not expect to receive a PSFCH. For example, the WTRU may monitor the channel in a slot having an associated PSFCH in the current slot. In an embodiment, the WTRU may determine to rate match / puncture the PSCCH / PSSCH in one or more symbols of the current slot if it detects a transmission from another WTRU transmitting a HARQ-enabled TB in the slot being monitored. The WTRU cannot rate match / puncture the PSCCH / PSSCH of the current slot if it does not detect a transmission in the previous slot having an associated PSFCH in the current slot.

[0170] The WTRU can determine whether one or more PSFCHs scheduled in a slot may exist, for example, based on whether the COT is sharable in the frequency domain. The WTRU can, for example, puncture / rate match (e.g., determine to puncture / rate match) (e.g., one) portion of the PSCCH / PSSCH within the slot if the COT is sharable. The WTRU can determine whether to puncture / rate match (e.g., one) portion of the PSCCH / PSSCH in the slot, for example, based on whether to request any other WTRU to perform a PSFCH transmission in the slot (e.g., if the COT is not sharable). The WTRU can cause (e.g., one) portion of the PSCCH / PSSCH transmission to be punctured / rate matched if it instructs / requests another WTRU to perform a PSFCH transmission in the slot. The WTRU cannot puncture / rate match the PSCCH / PSSCH within the slot if it does not instruct / request another WTRU to perform a PSFCH transmission in the slot.

[0171] The WTRU can determine whether there is one or more PSFCHs scheduled within a slot, for example, based on whether the WTRU has instructed other WTRUs to perform PSFCH transmission within the slot. The WTRU can determine whether there is one or more PSFCHs scheduled within a slot, for example, based on whether the WTRU has detected other WTRUs that instruct PSFCH transmission within the slot.

[0172] FIG. 9 illustrates an example of a determination by a WTRU regarding whether to puncture / rate match a (e.g., one) PSCCH / PSSCH. As illustrated in FIG. 9, the WTRU may have one or more (e.g., two) PSFCH transmission timings in the COT and / or FFP of the WTRU. The WTRU can determine, for example, not to puncture / rate match the PSCCH / PSSCH in the slot of the first PSFCH if the WTRU is not performing PSFCH transmission on the first PSFCH. The WTRU can determine, for example, to puncture / rate match the PSCCH / PSSCH in the slot of the second PSFCH if the WTRU has requested (e.g., one) other WTRU to perform PSFCH transmission in (e.g., one) early transmission.

[0173] The WTRU can resume its COT / FFP after the PSFCH resource. The WTRU can stop / suspend transmission for other WTRUs to perform LBT / CCA and / or to transmit PSFCH. The WTRU can resume its transmission after a (pre-)configured period (e.g., PSFCH transmission / reception period). The WTRU can perform CCA / LBT to vacate the channel before the resumed resource. In an embodiment, the WTRU can perform a certain type of CCA / LBT (e.g., fixed CCA / LBT over a duration of 9 μs / 16 μs / 25 μs) to resume its transmission after PSFCH. The CCA / LBT duration can be fixed in the resource pool or (pre-)configured. In an embodiment, the WTRU can perform various types of CCA / LBT based on one or more conditions. The WTRU can determine one or more CCA / LBT parameters (e.g., CCA / LBT duration without CCA / LBT, fixed CCA / LBT duration, and / or flexible CCA / LBT duration) used to perform CCA / LBT after the suspension duration based on one or more of the following. The WTRU can determine one or more CCA / LBT parameters based on the QoS associated with its data. For example, the WTRU can perform a fixed LBT / CCA duration if the QoS of the TB is less than a threshold. Otherwise, i.e., if the QoS of the TB is greater than the threshold, the WTRU can perform a flexible LBT / CCA duration (e.g., type 1 LBT). The WTRU can determine one or more CCA / LBT parameters based on one or more CCA / LBT parameters used to acquire the COT / FFP. For example, the WTRU may not perform LBT / CCA if it uses type 1 LBT to acquire the channel. Otherwise, i.e., if the WTRU shares the COT / FFP of other WTRUs, the WTRU can use type 2 LBT (e.g., type 2A or type 2B) to sense the channel after the suspension duration. For example, the WTRU can have a channel access priority class p (e.g., CWp , CW min,p , and CW max,p )-associated contention window (e.g., CW p) If the minimum and / or maximum contention window is smaller than the threshold, type 1 LBT can be used. Otherwise, the WTRU can use type 2 LBT. The WTRU can determine one or more CCA / LBT parameters based on the CBR of the resource pool. If the CBR is smaller than the threshold, the WTRU can use a certain type of LBT / CCA (e.g., type 1 LBT). Otherwise, the WTRU can use another type of LBT / CCA (e.g., type 2 LBT). The WTRU can determine one or more CCA / LBT parameters based on the reception / monitoring status during the PSFCH period. In an embodiment, the WTRU can determine one or more CCA / LBT parameters when the WTRU receives the PSFCH. When the WTRU decodes the HARQ feedback (e.g., HARQ ACK / NACK) from the Rx WTRU, the WTRU can acquire the channel without performing CCA / LBT, or the WTRU can acquire the channel for a fixed duration (e.g., LBT2A type or 2B type). When the WTRU detects DTX (e.g., when there is no feedback from the Rx WTRU), or when the WTRU does not detect a transmission (e.g., any transmission) in the PSFCH symbol, the WTRU can use another type of LBT (e.g., type 1 LBT) to acquire the channel. In an embodiment, the WTRU can determine one or more CCA / LBT parameters when the WTRU does not receive the PSFCH. After the PSFCH symbol, the WTRU can perform a certain type of LBT (e.g., type 2 LBT). The WTRU can determine the CCA / LBT type based on the energy detected in the PSFCH symbol. If the energy detected in the PSFCH symbol is smaller than the threshold, the WTRU can perform a certain type of LBT (e.g., type 1 LBT). Otherwise, the WTRU can perform another type of CCA / LBT (e.g., type 2 LBT).

[0174] The WTRU can (pre-)configure by mapping one PSCCH / PSSCH to multiple PSFCH transmission timings. The WTRU can be (pre-)configured using a resource pool where each PSCCH / PSSCH resource (e.g., each PSCCH / PSSCH resource) has multiple associated PSFCH transmission timings (e.g., two PSFCH transmission timings can be mapped to one PSCCH / PSSCH resource). Based on the reception of the PSCCH / PSSCH, the Rx WTRU can perform CCA / LBT (e.g., sequentially) to access the PSFCH transmission timing (e.g., each PSFCH transmission timing) to transmit HARQ ACK / NACK feedback to the Tx WTRU. In an embodiment, if the WTRU can successfully transmit HARQ ACK / NACK feedback at a certain transmission timing (e.g., one transmission timing), it can stop performing CCA / LBT at the remaining transmission timings. The WTRU can perform CCA / LBT at multiple associated PSFCH transmission timings (e.g., all associated PSFCH transmission timings). The WTRU can perform HARQ ACK / NACK feedback at multiple PSFCH transmission timings. The WTRU can determine the transmission timing (e.g., at one or multiple PSFCH transmission timings and / or at any transmission timing) for performing CCA / LBT and transmitting HARQ feedback based on one or more of the following. The WTRU can determine the transmission timing for performing CCA / LBT and transmitting HARQ feedback based on the (pre-)configuration in the resource pool. For example, if the PSSCH / PSSCH has multiple associated PSFCH transmission timings, the WTRU can be (pre-)configured in the resource pool using information regarding whether to feedback one PSCCH / PSSCH once or multiple times. The WTRU can perform HARQ feedback transmission based on the (pre-)configuration within the resource pool.The WTRU can determine the transmission timing for performing CCA / LBT and HARQ feedback transmissions based on an indication from the Tx WTRU. For example, the WTRU can determine whether to perform feedback at one or more associated PSFCH transmission timings of the PSCCH / PSSCH based on an indication from the Tx WTRU. The Tx WTRU can indicate to the Tx WTRU (e.g., in a second SCI) whether it expects the Rx WTRU to feedback at one or more PSFCH transmission timings. For example, the Tx WTRU can indicate (e.g., in an SCI) whether it expects HARQ feedback at the indicated transmission timing or at a (pre-)configured transmission timing. The Rx WTRU can determine whether to transmit a HARQ ACK / NACK as indicated by the Tx WTRU. For example, if the Tx WTRU does not indicate a HARQ feedback transmission timing, the Rx WTRU can transmit a HARQ ACK / NACK at one or more (pre-)configured HARQ feedback transmission timings within a resource pool associated with the PSCCH / PSSCH. Otherwise, i.e., if the Tx WTRU indicates a HARQ ACK / NACK feedback transmission timing, the Rx WTRU can perform a HARQ ACK / NACK feedback at the indicated transmission timing. The WTRU can determine the transmission timing for performing CCA / LBT and HARQ feedback transmissions based on the HARQ feedback type (e.g., whether the HARQ feedback type is HARQ feedback option 1 or option 2). For example, the WTRU can feedback once for unicast / groupcast option 2. The WTRU can feedback multiple times for groupcast option 1.The WTRU can determine the transmission timing for performing CCA / LBT and HARQ feedback transmissions based on HARQ information that the WTRU intends to feedback (e.g., whether the WTRU plans to report a HARQ ACK or a HARQ NACK). For example, if the WTRU is to feedback a HARQ ACK to indicate successful decoding of a TB, the WTRU can perform one HARQ feedback transmission. In an embodiment, if the WTRU is to feedback a HARQ NACK to indicate failure in decoding a TB, the WTRU can feedback multiple times (e.g., at multiple (pre)-configured / indicated PSFCH transmission timings associated with a PSCCH / PSSCH resource). The WTRU can determine the transmission timing for performing CCA / LBT and HARQ feedback transmissions based on the QoS of the TB. For example, if the QoS of the TB is less than a threshold, the WTRU can perform one HARQ feedback transmission. Otherwise, i.e., if the QoS of the TB is greater than the threshold, the WTRU can feedback multiple times (e.g., at multiple (pre)-configured / indicated PSFCH transmission timings associated with a PSCCH / PSSCH resource). The QoS threshold can be (pre)-configured for a resource pool or can be (pre)-configured for a service.

[0175] Synchronization procedures can be performed. The WTRU can transmit an SSB in a (pre)-configured resource. The WTRU can be a synchronization reference WTRU (e.g., can determine that it is a synchronization reference WTRU). The WTRU can perform an S-SSB transmission (e.g., can then determine to perform it). The WTRU can transmit an S-SSB in one or more (pre)-configured resources for the S-SSB (e.g., can determine to transmit it).

[0176] FIG. 10 illustrates an example of resources (pre-)configured for S-SSB transmission. As shown by the example of FIG. 10, the WTRU can be (pre-)configured with N resources for S-SSB transmission.

[0177] The WTRU can determine whether to perform CCA before a resource (pre-)configured for S-SSB transmission. The WTRU can determine whether to perform CCA before a resource (pre-)configured for S-SSB transmission, for example, based on the availability of transmissions by other WTRUs in a slot before a slot (pre-)configured for S-SSB transmission. The WTRU can perform S-SSB transmission without CCA, for example, if the WTRU detects other WTRUs in a system where the WTRU is transmitting within a slot. The WTRU can perform CCA before a resource (pre-)configured for S-SSB transmission, for example, if the WTRU does not detect other WTRUs in a system where the WTRU is transmitting within a slot. The WTRU can perform S-SSB transmission, for example, if the channel is idle. The WTRU can refrain from transmitting S-SSB on a resource, for example, if the channel is not idle. The WTRU can determine the number of S-SSB transmissions during a synchronization period. In some embodiments, the WTRU can be (pre-)configured with a minimum number and / or a maximum number of S-SSB transmissions within a synchronization period (e.g., 160 ms). The WTRU can perform CCA before each (pre-)configured resource for S-SSB transmission. The CCA duration can be set to 0, for example, if the WTRU is not required to perform CCA before an S-SSB resource. The WTRU can perform S-SSB transmission within a resource, for example, if the channel is idle. The WTRU can determine whether to perform CCA and / or S-SSB transmission (e.g., for each configured resource for S-SSB transmission), for example, based on the number of S-SSBs transmitted by the WTRU during a synchronization period. The WTRU may not need to perform CCA and / or S-SSB transmission, for example, if the number of S-SSBs transmitted during a synchronization period is greater than a maximum threshold. The WTRU can perform CCA and / or S-SSB transmission in a resource (pre-)configured for S-SSB transmission, for example, if the number of S-SSBs transmitted during a synchronization period is less than a minimum threshold. The WTRU can pause the WTRU's COT for another transmission.In some embodiments, a WTRU may occupy a COT (e.g., one COT, and / or FFP), e.g., one COT, which may have one or more resources preconfigured for other transmissions (e.g., S-SSB transmissions). The WTRU may stop the execution of transmissions in the preconfigured resources. The WTRU may rate match and / or puncture a portion of the resources (e.g., one or more orthogonal frequency division multiplexing (OFDM) symbols) in a transmission in a slot prior to a slot preconfigured for S-SSB transmission. Rate matching and / or puncturing a portion of the resources may enable the Tx WTRU for S-SSB to vacate the channel when performing CCA. The WTRU may resume its COT after the preconfigured resources. The WTRU may resume transmission after the preconfigured resources (e.g., after pausing its COT for transmissions of other WTRUs). In some embodiments, the WTRU may not perform CCA before the resumed resources. In some embodiments, the WTRU may perform CCA to vacate the channel before the resumed resources. The WTRU may perform a transmission, e.g., if the channel is clear. The WTRU may wait until the next COT and / or FFP to perform CCA to access the channel, e.g., if the channel is not clear.

[0178] The WTRU can determine one or more CCA / LBT parameters (e.g., CCA / LBT duration without CCA / LBT, fixed CCA / LBT duration, and / or flexible CCA / LBT duration) for performing CCA / LBT based on one or more of the following. The WTRU can determine one or more CCA / LBT parameters based on a (pre-)configuration. For example, the WTRU can be (pre-)configured to perform a certain type of CCA / LBT (e.g., type 2 LBT) after an S-SSB slot. The WTRU can perform CCA / LBT after the S-SSB and resume transmission. The WTRU can determine one or more CCA / LBT parameters based on the QoS associated with its data. For example, the WTRU can perform a fixed LBT / CCA duration if the QoS of the TB is less than a threshold. Otherwise, i.e., if the QoS of the TB is greater than the threshold, the WTRU can perform a flexible LBT / CCA duration (e.g., type 1 LBT). The WTRU can determine one or more CCA / LBT parameters based on one or more CCA / LBT parameters used to obtain COT / FFP. For example, the WTRU need not perform LBT / CCA if the WTRU uses type 1 LBT to obtain COT / FFP. Otherwise, if the WTRU shares the COT / FFP of another WTRU, the WTRU can use type 2 LBT (e.g., type 2A or type 2B) to sense the channel after a pause duration. The WTRU can determine one or more CCA / LBT parameters based on the CBR of the resource pool. The WTRU can use a certain type of LBT / CCA (e.g., type 1 LBT) if the CBR is less than a threshold. Otherwise, the WTRU can use another type of LBT / CCA (e.g., type 2 LBT). The WTRU can determine based on the reception / monitoring status in the S-SSB slot. The WTRU can monitor the S-SSB slot.The WTRU can determine one or more CCA / LBT parameters based on the reception / monitoring status of the WTRU. In an embodiment, the WTRU can determine the CCA / LBT type based on the energy detected in the S-SSB slot. If the energy detected in the S-SSB is greater than a threshold, the WTRU can perform a certain type of CCA / LBT (e.g., type 2 LBT). Otherwise, i.e., if the energy detected in the S-SSB is less than the threshold, the WTRU can perform another type of CCA / LBT (e.g., type 1 LBT). In an embodiment, the WTRU can detect S-SSB signals (e.g., sidelink secondary synchronization signal (S-SSS), sidelink primary synchronization signal (S-PSS), and / or sidelink synchronization signal (SLSS)) within the slot. If the S-SSB is detected, the WTRU can perform a certain type of CCA / LBT (e.g., type 2 LBT). Otherwise, i.e., if the S-SSB is not detected, the WTRU can perform another type of CCA / LBT (e.g., type 1 LBT).

[0179] FIG. 11 illustrates an example where the WTRU pauses the transmission of the S-SSB and then resumes the transmission. As illustrated in FIG. 11, the WTRU can acquire a COT (e.g., COT and / or FFP) in which there is (e.g., one) (pre-)configured resource for S-SSB transmission. The WTRU can perform (e.g., the first) puncturing / rate matching of one or more OFDM symbols for other WTRUs to perform CCA in the slot before the resource (pre-)configured for S-SSB transmission. The WTRU can (e.g., further) stop the transmission in the slot. The WTRU can resume the transmission (e.g., from the slot) after the resource (pre-)configured for S-SSB transmission.

[0180] FIG. 12 is a diagram showing an example in which a WTRU determines an S-SSB pattern to be transmitted. The WTRU can be (pre-)configured using multiple types of resources for S-SSB transmission / reception. The WTRU can be (pre-)configured in a carrier, a sidelink bandwidth part (SL-BWP), and / or one or more types of S-SSB slots for S-SSB transmission / reception in a resource pool. The first type of slot can be SL-BWP and / or carrier-specific. The WTRU cannot use this (pre-)configured slot for transmissions other than S-SSB (e.g., any transmission). The second type of slot can be (pre-)configured in a resource pool. The WTRU can use this slot for other transmissions such as PSCCH / PSSCH and / or PSFCH. The WTRU can use the second type of slot for other transmissions based on one or more of the following. The WTRU can use the second type based on the detection of one or more S-SSBs in the first type of slot during a period. For example, if the WTRU detects one or more S-SSBs transmitted in the first type of S-SSB slot, the WTRU can use the second type of S-SSB slot for other transmissions. Otherwise, the WTRU cannot perform other transmissions in the second type of slot. The number of detected S-SSBs that can be transmitted in the second type of S-SSB slot during a period can be fixed (e.g., 1 S-SSB) or (pre-)configured within a carrier. The WTRU can use the second type based on energy detection in one or more S-SSBs of the first type of slot during a period. For example, if the WTRU detects one or more S-SSBs transmitted in the first type of S-SSB slot, the WTRU can use the second type of S-SSB slot for other transmissions. Otherwise, the WTRU cannot perform other transmissions in the second type of slot. The WTRU can use the second type based on the QoS of the TB. For example, if the QoS of the TB is greater than a threshold, the WTRU can use the second type of S-SSB slot for other transmissions.Otherwise, the WTRU cannot use a second type of S-SSB slot for other transmissions. The WTRU can use the second type based on one or more parameters for acquiring a channel. For example, the WTRU can use a second type of S-SSB slot for other transmissions if the CAPC for acquiring the channel is greater than a threshold. Otherwise, the WTRU cannot use a second type of S-SSB slot for other transmissions. The WTRU can use the second type based on the CBR of a resource pool. For example, the WTRU can use a second type of S-SSB slot for other transmissions if the CBR of the resource pool meets a (pre-)configured condition (e.g., the CBR is greater than a threshold). Otherwise, i.e., if the CBR of the resource pool does not meet the (pre-)configured condition, the WTRU cannot use a second type of S-SSB slot for other transmissions.

[0181] The WTRU can perform S-SSB transmission in a (pre-)configured S-SSB slot within a resource pool. In an embodiment, the WTRU can determine to transmit an S-SSB in order to be a synchronization reference WTRU (e.g., SyncRefUE). The WTRU can be (pre-)configured in two types of S-SSB slots. The first type of slot can be dedicated to S-SSB, and the second type of S-SSB slot can be shared with other transmissions. Before one second type of S-SSB slot, the WTRU can determine whether to transmit an S-SSB based on one or more of the following. The WTRU can determine whether to transmit an S-SSB based on the number of S-SSB transmissions (e.g., S-SSB transmissions in the first type of slot and / or S-SSB transmissions in the second type of slot) that the WTRU has made during the synchronization period. For example, the WTRU can perform CCA / LBT to transmit in an S-SSB slot if the number of S-SSB transmissions that the WTRU has made during the synchronization period is less than a threshold. Otherwise, the WTRU cannot transmit an S-SSB in the slot. The threshold can be (pre-)configured in a resource pool, an SL-BWP, and / or a carrier. The WTRU can determine whether to transmit an S-SSB based on whether the WTRU has acquired COT / FFP before the S-SSB slot. For example, the WTRU can prioritize transmitting an S-SSB in an S-SSB slot if it has acquired COT / FFP for data transmission in one or more slots before the (pre-)configured S-SSB slot. Otherwise, the WTRU cannot transmit an S-SSB. The WTRU can determine whether to transmit an S-SSB based on the QoS of the data. For example, the WTRU can acquire COT / FFP. The WTRU can determine whether to prioritize S-SSB or data transmission in COT / FFP based on the QoS of the data. If the QoS of the data is greater than a threshold, the WTRU can prioritize data transmission. Otherwise, the WTRU can prioritize S-SSB transmission.The WTRU can determine whether to transmit the S-SSB based on the CBR of the resource pool. For example, the WTRU can determine whether to transmit in the second type of S-SSB slot based on the CBR of the resource pool. If the CBR of the resource pool meets the (pre-)configured condition (e.g., the CBR is smaller than the threshold), the WTRU can perform S-SSB transmission. Otherwise, that is, if the CBR of the resource pool does not meet the (pre-)configured condition, the WTRU cannot perform S-SSB transmission in the second type of S-SSB slot. The CBR threshold may be (pre-)configured in the resource pool. The WTRU can determine whether to transmit the S-SSB based on the priority associated with the synchronization source. For example, the WTRU can determine whether to transmit in the second type of S-SSB slot based on the priority of the synchronization source. If the priority of the synchronization source is greater than the threshold, the WTRU can perform S-SSB transmission. Otherwise, that is, if the priority of the synchronization source is smaller than the threshold, the WTRU cannot perform S-SSB transmission in the second type of S-SSB slot. The synchronization source threshold may be (pre-)configured in the resource pool. The WTRU can determine whether to transmit the S-SSB based on the coverage status. For example, the WTRU can determine whether to transmit in the second type of S-SSB slot based on its coverage status. If the WTRU is within coverage, the WTRU can perform S-SSB transmission. Otherwise, the WTRU cannot perform S-SSB transmission in the second type of S-SSB slot.

[0182] The WTRU can be (pre-)configured using types of S-SSB transmissions. The WTRU can be (pre-)configured with one or more of the following types of S-SSB transmissions, which can be described with respect to FIG. 12. In a first option (e.g., Option 1), the WTRU can be (pre-)configured to perform S-SSB repetitions across the entire LBT sub-band. In a second option (e.g., Option 2), the WTRU can (pre-)configure multiple S-SSB repetitions. The WTRU can select one S-SSB repetition pattern to transmit. In a third option (e.g., Option 3), the WTRU can be (pre-)configured to transmit S-SSB using an interleaving-based transmission. In a fourth option (e.g., Option 4), the WTRU can transmit S-SSB over a bandwidth.

[0183] The WTRU can determine the S-SSB option to transmit and / or the S-SSB pattern. The WTRU can determine the S-SSB transmission option to select (e.g., option 1, 2, 3, or 4). If option 2 or 3 is selected, the WTRU can determine the S-SSB pattern to select (e.g., S-SSB repetition and / or S-SSB interleaving index). The WTRU can determine the S-SSB transmission to transmit and / or the S-SSB pattern based on one or more of the following. The WTRU can determine the S-SSB transmission to transmit and / or the S-SSB pattern based on the (pre)configuration in the carrier and / or resource pool. The WTRU can determine the S-SSB transmission to transmit and / or the S-SSB pattern based on the type of S-SSB slot. For example, the WTRU can be (pre)configured with two types of S-SSB slots, and the first type of S-SSB slot can be dedicated to S-SSB transmission, and the second type of S-SSB slot can be shared with other transmissions. The WTRU can determine the selected S-SSB transmission and / or the S-SSB pattern based on the type of S-SSB slot. In an example, the WTRU can be (pre)configured with two different types of S-SSB transmissions, and the first type of S-SSB transmission can be associated with the first type of S-SSB slot (e.g., option 4 which may not require OCB), and the second type of S-SSB transmission can be associated with the second type of S-SSB slot (e.g., option 2 which may require OCB). The WTRU can determine which type of S-SSB transmission it is based on the type of S-SSB slot. The WTRU can determine the S-SSB pattern based on the WTRU ID. For example, the WTRU can select the S-SSB pattern based on its ID. The WTRU can determine the S-SSB pattern based on the sidelink synchronization signal identifier (SLSSID). For example, the WTRU can select the S-SSB pattern based on its ID.The WTRU can determine the S-SSB pattern based on the synchronization priority. For example, the WTRU can select the S-SSB pattern based on its ID. The WTRU can determine the S-SSB pattern based on the coverage status. For example, the WTRU can select the S-SSB pattern based on its ID.

[0184] The WTRU can be (pre-)configured with multiple types of S-SSB resources. The S-SSB resources (e.g., each type of S-SSB resource) can be determined based on one or more of the following: the priority associated with S-SSB transmission, whether the S-SSB resource can be used for other transmissions (e.g., data transmission, or feedback), or the priority access and transmission of the S-SSB.

[0185] Regarding the priority associated with S-SSB transmission, the priority of the S-SSB can be associated with the synchronization source of the WTRU (e.g., whether the synchronization source is a global navigation satellite system (GNSS), gNB, in-coverage WTRU, out-of-coverage WTRU, etc.). The priority of the S-SSB resource can refer to the (pre-)configured synchronization source (e.g., synchronization priority level) of the synchronizing WTRU.

[0186] Regarding whether the S-SSB resource can be used for other transmissions (e.g., data transmission, or feedback), the WTRU can be (pre-)configured with two types of S-SSB resources. The first type of S-SSB resource can be shared with other sidelink transmissions (e.g., data, PSFCH), and the second type of S-SSB resource cannot be shared with other sidelink transmissions (e.g., this resource can only be used for S-SSB transmission).

[0187] Regarding the prioritized access and transmission of S-SSB, the WTRU can be configured with two types of S-SSB resources (previously). The WTRU can prioritize accessing the channel and transmitting S-SSB on one or more resources associated with the first type. If the WTRU cannot access the channel and transmit S-SSB on one or more resources associated with the first type, the WTRU can access the channel and transmit S-SSB on one or more resources associated with the second type. For example, if the WTRU cannot access the channel and transmit S-SSB on N resources associated with the first type, the WTRU can access the channel and transmit S-SSB on one or more resources associated with the second type. The value of N is fixed (e.g., fixed as 1) and / or can be configured (previously). The value of N can be determined (e.g., further determined) based on the number of pre-configured S-SSB resources associated with the first type.

[0188] The WTRU can determine the type of S-SSB resource to use for transmitting S-SSB. The WTRU can be configured with multiple sets of S-SSB resources, and each set of S-SSB resources (e.g., each set of S-SSB resources) can be associated with one S-SSB resource priority (e.g., based on the synchronization source of the S-SSB). The WTRU can determine (e.g., next determine) the set of S-SSB resources to use for transmitting S-SSB based on the priority of the S-SSB and the priority associated with the S-SSB resource. In an embodiment, the WTRU can transmit S-SSB at the S-SSB transmission timing with the same priority. In an embodiment, the WTRU can transmit S-SSB at the S-SSB transmission timing with a priority equal to or lower than the priority of the transmitted S-SSB.

[0189] The WTRU can determine the S-SSB transmission timing (e.g., various types of S-SSB transmission timing) and the LBT parameters for S-SSB transmission. In an embodiment, the WTRU can determine the LBT parameters to be used for transmitting S-SSB at the S-SSB transmission timing (e.g., each (pre-)configured S-SSB transmission timing). The WTRU can determine the value of one or more LBT parameters to be used (e.g., the LBT type of one LBT sub-band channel access (e.g., LBT type 1, type 2, type 2A, type 2B, type 2C)), the channel access priority class (CAPC), the current contention window (e.g., CW p ), the minimum and / or maximum contention window associated with the channel access priority class p (e.g., CW p , CW min,p , and CW max,p ), the contention window size that may include the current value or initial value of the backoff counter (N), the current COT, and / or the maximum COT, the contention duration, the delay period (e.g., T d ), the LBT energy detection threshold used to determine the channel availability, the FFP configuration, the clear channel access (CCA) duration, the channel access time of each slot, and / or the value of the cyclic prefix extension (CPE) duration: the type associated with the S-SSB transmission timing, the priority associated with the S-SSB transmission, or the priority associated with the S-SSB transmission timing.

[0190] Regarding the type associated with S-SSB transmission timing (e.g., the priority associated with S-SSB transmission timing, whether the S-SSB resource is dedicated for S-SSB transmission, or shared with other transmissions), when the S-SSB transmission timing is shared with other sidelink communications (e.g., data, or PSFCH), the WTRU can (pre-)configure the CPE duration for S-SSB transmission, or the channel access time (e.g., the duration until the slot boundary). The WTRU can use the (pre-)configured CPE duration, or the channel access time (pre-)configured according to the S-SSB transmission in the shared resource with other sidelink transmissions (e.g., for next use).

[0191] Regarding the priority associated with S-SSB transmission, the WTRU can be (pre-)configured with one or more of the channel sensing durations (e.g., CAPC, CCA duration). It is the CPE duration for accessing the channel based on the channel access time, or the priority of S-SSB transmission. The WTRU can determine the LBT parameters (e.g., CAPC, channel sensing time, CPE duration, or channel access time) to use based on the priority associated with S-SSB transmission (e.g., for next determination).

[0192] Regarding the priority associated with S-SSB transmission timing (e.g., the lowest or highest synchronization priority permitted to be transmitted at the S-SSB transmission timing), the WTRU can be (pre-)configured with a set of LBT parameters for accessing the SSB transmission timing (e.g., each S-SSB transmission timing). The WTRU can determine the LBT parameters for accessing the channel based on the accessed S-SSB transmission timing (e.g., for next determination).

[0193] The WTRU can determine whether to transmit data / feedback at the S-SSB transmission timing. In an embodiment, the WTRU can be (pre-)configured at the S-SSB transmission timing at which other types of transmissions can be made available on the resources. The WTRU can use the resources to transmit one or more of the following types of transmissions: sidelink data, or sidelink feedback.

[0194] In the case of sidelink data transmission, the WTRU can be (pre-)configured for a particular type of data (e.g., data having a particular QoS, cast type, destination ID, HARQ type) for transmission at the S-SSB transmission timing. The WTRU can determine (e.g., next determine) to transmit the data at the S-SSB transmission timing if the data meets the (pre-)configured conditions. For example, the WTRU can transmit the data at the S-SSB transmission timing if the priority of the data is greater than a threshold. Otherwise, the WTRU cannot transmit the data at the S-SSB transmission timing.

[0195] In the case of sidelink data transmission, the WTRU can be (pre-)configured with a set of LBT parameters for transmission at the S-SSB transmission timing. The WTRU can use the (pre-)configured LBT parameters to access the channel. In an embodiment, the WTRU can be (pre-)configured with a CAPC, channel access time, and / or CPE duration to access the channel. The WTRU can use the (pre-)configured channel access time and / or CPE duration to access the channel and transmit the data (e.g., next use).

[0196] In sidelink feedback transmission, the WTRU may be permitted to send a PSFCH transmission if the transmission is within the S-SSB transmission timing. In sidelink feedback transmission, the WTRU may be permitted to send a PSFCH at the S-SSB transmission timing if the QoS of the data associated with the feedback is greater than a (pre-)configured threshold.

[0197] If a failure occurs in the first type of S-SSB resource, the WTRU can transmit in the second type of S-SSB resource. The WTRU can be (pre-)configured with two types of S-SSB resources. One or more of the first type of S-SSB resources may have one or more associated second type of S-SSB resources. The WTRU may attempt to access the channel to transmit an S-SSB in one or more resources associated with the first type. The WTRU can perform LBT and determine (e.g., can then determine) whether to transmit an S-SSB in one or more S-SSB resources associated with the second type, based on whether the WTRU was able to successfully transmit an S-SSB in one or more SSB resources associated with the first type. In an example, if the WTRU fails to transmit in one or more S-SSB resources associated with the first type, the WTRU can transmit an S-SSB in one or more resources associated with the second type. Otherwise, i.e., if the WTRU was able to successfully transmit in one or more S-SSB resources associated with the first type, the WTRU cannot transmit an S-SSB in one or more S-SSB resources associated with the second type.

[0198] FIG. 13 illustrates an example of a configuration having multiple types of S-SSB resources. For example (e.g., as shown in Case 1 of FIG. 13), for each set of one or more resources associated with a first type (e.g., type 1 S-SSB resource in FIG. 13), a WTRU may be pre-configured with one or more resources associated with a second type (e.g., type 2 S-SSB resource in FIG. 13). The WTRU may determine (e.g., may then determine) to transmit an S-SSB on one or more resources associated with the second type if the WTRU fails to transmit an S-SSB on one or more resources associated with the first type. If the WTRU can successfully transmit on one or more S-SSB resources associated with the first type, the WTRU may access the channel and transmit data and / or feedback on one or more S-SSB resources associated with the second type. Other WTRUs may access the channel and transmit one or more S-SSBs (e.g., data or PSFCH) on one or more resources associated with the second type if they detect one or more S-SSB transmissions on one or more resources associated with the first type.

[0199] For example (as shown in Case 2 of FIG. 13), the WTRU can be (pre-)configured with two independent sets of S-SSB resources (e.g., type 1 and type 2 S-SSB resources). The WTRU can be (pre-)configured with the maximum number and / or minimum number of S-SSB transmissions during the synchronization period (e.g., next, it can be configured). The WTRU can sequentially access the channels for transmission at the SSB transmission timing from both types of S-SSB transmission timings (e.g., each S-SSB transmission timing) (e.g., next, it can access). If the number of S-SSB transmissions by the WTRU is greater than the (pre-)configured maximum threshold, the WTRU can stop S-SSB transmissions for a period (e.g., next, it can stop). If the number of S-SSB transmissions during that period is less than the minimum (pre-)configured threshold, the WTRU can continue S-SSB transmissions during that period. If the WTRU can successfully transmit at least the minimum number of (pre-)configured S-SSBs, it can access and transmit at the remaining S-SSB transmission timings during the synchronization period. In an embodiment, if at least the (pre-)configured number of S-SSB transmissions are detected during the synchronization period, the WTRU can access the channel and transmit (e.g., data or PSFCH) at the remaining S-SSB transmission timings.

[0200] Figure 14 illustrates an example of the configuration of multiple types of S-SSB resources in the S-SSB burst case. For example (e.g., as shown in Figure 14), the WTRU can be pre-configured with two types of S-SSB resources. One or more S-SSB resources can be associated with the first type, and one or more S-SSB resources can be associated with the second type. The second type can be an S-SSB burst that can follow the S-SSB resources associated with the first type. The WTRU can determine (e.g., can then determine) to transmit the S-SSB on one or more S-SSB resources associated with the second type if the WTRU fails to transmit on one or more S-SSB resources associated with the first type. The WTRU can access the channel and transmit data and / or feedback on one or more S-SSB resources associated with the second type of S-SSB if the WTRU can successfully transmit on one or more S-SSB resources associated with the first type. Other WTRUs can access the channel and transmit (e.g., data or PSFCH) on one or more S-SSB resources associated with the second type if they detect one or more S-SSB transmissions on one or more S-SSB resources associated with the first type.

[0201] The WTRU can determine whether to continue using the COT for data and / or feedback when transmitting the S-SSB. In an example, the WTRU can transmit data and / or feedback when transmitting the S-SSB in an S-SSB burst. The WTRU can determine whether to continue using the COT for data and / or feedback when transmitting the S-SSB in an S-SSB burst based on one or more of the following: the LBT parameters used to obtain the COT, the QoS of the data, or the QoS of the data associated with the feedback.

[0202] Regarding the LBT parameters used to obtain the COT, when the WTRU uses type 1 LBT to obtain the COT, after transmitting the S-SSB, the WTRU can continue to use the COT for data and / or feedback transmission. When the WTRU uses type 2 LBT, the WTRU cannot continue to use the COT for data and / or feedback transmission.

[0203] Regarding the QoS of data, when the priority of the TB is less than the threshold, after transmitting the S-SSB, the WTRU can continue to use the COT for data transmission. Otherwise, the WTRU cannot continue to use the COT.

[0204] Regarding the QoS of data associated with feedback, when the priority of the associated TB is less than the threshold, after transmitting the S-SSB, the WTRU can continue to use the COT for feedback transmission. Otherwise, the WTRU cannot continue to use the COT.

[0205] The WTRU can determine the burst of S-SSB to be used for transmission based on the priority of the Tx S-SSB and / or the S-SSB burst. The WTRU can be (pre)-configured with multiple bursts of S-SSB resources during the synchronization period. The WTRU can determine the S-SSB burst for transmitting the S-SSB based on the priority associated with the S-SSB burst and / or the priority associated with transmitting the S-SSB. In an example, the WTRU can transmit the S-SSB in a burst when the (pre)-configured priority of the S-SSB burst is equal to the priority of the transmitted S-SSB. In an example, the WTRU can transmit the S-SSB in a burst when the priority of the S-SSB burst is less than or equal to the priority of the S-SSB.

[0206] Figure 15 illustrates an example of a configuration (e.g., for a WTRU) for bursts of S-SSB transmission timing for each synchronization period. For example (as shown in Figure 15, for example), a WTRU can be configured (previously) with one or more S-SSB bursts within a synchronization period. The WTRU can be configured (previously) (e.g., can be configured next) to transmit a minimum number and / or a maximum number of S-SSBs within a burst. When transmitting a minimum and / or a maximum (previously) configured number of S-SSBs in an S-SSB burst, the WTRU can perform data and / or feedback transmission at the remaining transmission timing of the S-SSB burst. In an embodiment, when detecting a (previously) configured number of S-SSBs, the WTRU can perform LBT and acquire a channel for data and / or feedback transmission.

[0207] The WTRU can acquire a channel before the S-SSB transmission timing and transmit data. The WTRU can perform LBT (e.g., type 1 LBT) and acquire a channel before one or more (previously) configured S-SSB transmission timings. The WTRU can perform LBT and acquire a COT for data transmission. The WTRU can transmit (previously) configured S-SSB transmission timings (e.g., can transmit next) using a set of LBT parameters that can be different from those of a WTRU that does not acquire a COT before transmitting an S-SSB. The set of LBT parameters can be (previously) configured / (previously) defined when the WTRU uses one initialized for data transmission for S-SSB transmission. In an embodiment, the WTRU may not be able to perform LBT (e.g., type 2C) or may perform LBT with a shorter duration compared to a COT not acquired before S-SSB transmission. When transmitting an S-SSB, the WTRU can resume using the COT for subsequent data and / or feedback transmission (e.g., can resume next).

[0208] The WTRU can determine whether to use a data COT to transmit an S-SSB within a COT. In an embodiment, the WTRU can determine whether to transmit the S-SSB at a (pre-)configured S-SSB transmission timing within the data COT based on one or more of the following: the priority of S-SSB transmission, or the priority associated with the (pre-)configured S-SSB transmission timing.

[0209] Regarding the priority of S-SSB transmission, if the priority of transmitting the S-SSB is greater than a threshold, the WTRU can transmit the S-SSB in the acquired COT for data transmission. If the priority of transmitting the S-SSB is less than the threshold, the WTRU can stop the COT. In an embodiment, the WTRU can perform LBT using (pre-)configured LBT parameters to acquire a channel for transmitting the S-SSB.

[0210] Regarding the priority associated with the (pre-)configured S-SSB transmission timing, if the priority associated with the (pre-)configured S-SSB is less than a threshold, the WTRU can determine to transmit the S-SSB at the (pre-)configured transmission timing within the data COT using the data COT. Otherwise, the WTRU cannot use the COT acquired for data to transmit the S-SSB.

[0211] FIG. 16 illustrates an example of a WTRU that uses a COT acquired for data transmission to transmit an S-SSB. For example (as shown in FIG. 16, for example), the WTRU can first perform LBT (e.g., type 1 LBT) to acquire a COT for transmitting data. The WTRU can transmit the S-SSB at the (pre-)configured S-SSB transmission timing. The WTRU can use the COT for transmitting data (e.g., can be used next).

[0212] The WTRU can acquire a channel at the center of the S-SSB slot. In an embodiment, the WTRU can acquire a channel at the center of the S-SSB slot of the S-SSB burst. The WTRU can perform one or more of the following: transmit a reservation signal (e.g., dummy data), transmit mini-slot based sidelink transmissions, or perform latency detection and resume before a subsequence.

[0213] Resources can be allocated. The WTRU can determine whether to initialize a new COT and / or FFP. The WTRU can determine whether to initialize a new COT and / or FFP (e.g., whether to initialize a new COT) based on, for example, one or more of the following (e.g., any combination): the amount of data in the buffer, whether the WTRU has HARQ for feedback in the WTRU's COT and / or FFP, the QoS of the TB, and / or the CBR of the resource pool.

[0214] The WTRU can determine whether to initialize a new COT and / or FFP (e.g., whether to initialize a new COT) based on, for example, the amount of data in the buffer. The WTRU can initialize a new COT and / or FFP (e.g., can determine to initialize) if, for example, the amount of data in its buffer is greater than a threshold. The WTRU can share a COT with another WTRU if, for example, the amount of data in the WTRU's buffer is less than the threshold.

[0215] The WTRU can determine, for example, whether to initialize a new COT and / or FFP (e.g., initialize a new COT) based on, for example, whether the WTRU has HARQ for feedback in the COT of the WTRU and / or FFP. The WTRU can prioritize, for example, the start of a new COT and / or FFP if the WTRU has pending HARQ feedback for transmission to the Tx WTRU within the COT and / or FFP. The WTRU can share the COT with other WTRUs, for example, if the WTRU does not have pending HARQ feedback for transmission to the Tx WTRU in the COT and / or FFP.

[0216] The WTRU can determine whether to initialize a new COT and / or FFP, for example, based on the QoS of the TB. The WTRU can initialize a new COT and / or FFP, for example, when the QoS of the TB (e.g., priority, remaining PDB) is less than a threshold. The WTRU does not necessarily have to prioritize starting a new COT and / or FFP, for example, when the QoS of the TB (e.g., priority, remaining PDB) is greater than or equal to the threshold. The WTRU can initialize a new COT, for example, when the QoS of the TB (e.g., priority, remaining PDB) is greater than the threshold. The WTRU does not necessarily have to prioritize starting a new COT and / or FFP, for example, when the QoS of the TB (e.g., priority, remaining PDB) is less than or equal to the threshold. In some embodiments, the WTRU can be (pre-)configured with a maximum of N COTs and / or FFPs for access during an observation period. N can be (pre-)configured to be continuous or non - continuous. N can be a function of the QoS (such as priority) of the TB. The WTRU can determine whether to access a new COT and / or FFP, for example, based on the QoS of the TB. The WTRU can access the channel, for example, for the N COTs and / or FFPs when the WTRU is not accessing the channel. The WTRU cannot access the channel of the current COT and / or FFP, for example, when the WTRU has accessed the channel in the N COTs and / or FFPs.

[0217] The WTRU can determine whether to initialize a new COT and / or FFP, for example, based on the CBR of the resource pool. The WTRU can initialize a new COT, for example, when the CBR of the resource pool is less than a threshold. The WTRU may not need to initialize a new COT and / or FFP (e.g., may not prioritize initialization), for example, when the CBR of the resource pool is greater than (e.g., greater than or equal to) the threshold. The WTRU can initialize a new COT, for example, when the CBR of the resource pool is greater than the threshold. The WTRU may not need to initialize a new FFP (e.g., may not prioritize initialization), for example, when the CBR of the resource pool is less than (e.g., less than or equal to) the threshold.

[0218] The WTRU can determine whether to share the COT and / or FFP with other WTRUs. In some embodiments, the WTRU may have a TB for performing resource allocation. The WTRU can determine whether to share the COT and / or FFP with other WTRUs, for example, based on one or more of the following (e.g., any combination): the QoS of the TB (e.g., remaining PDB, priority); the distance to the COT-sharing WTRU; the CBR of the resource pool; the channel gain between the WTRU and the COT-sharing WTRU; and / or the target receiver of the TB.

[0219] The WTRU can determine whether to share the COT and / or FFP with other WTRUs, for example, based on the QoS of the TB (e.g., remaining PDB, priority). The WTRU can share the COT and / or FFP, for example, when the priority of the TB is greater than a threshold.

[0220] The WTRU can determine whether to share the COT and / or FFP of other WTRUs, for example, based on the distance to the COT-sharing WTRU. The WTRU can share the COT and / or FFP, for example, if the distance to the COT-sharing WTRU is less than a threshold value. The threshold value can be (pre-)configured or determined (for example, based on the minimum communication range (MCR) of the TB).

[0221] The WTRU can determine whether to share the COT and / or FFP of other WTRUs, for example, based on the CBR of the resource pool. The WTRU can share the COT and / or FFP, for example, if the CBR of the resource pool is less than a threshold value. The WTRU can share the COT, for example, if the CBR of the resource pool is greater than a threshold value.

[0222] The WTRU can determine whether to share the COT and / or FFP of other WTRUs, for example, based on the channel gain between the WTRU and the COT-sharing WTRU. The WTRU can share the COT and / or FFP, for example, if the channel gain between the two WTRUs (for example, the sidelink reference signal received power (SL-RSRP)) is greater than a threshold value.

[0223] The WTRU can determine whether to share the COT and / or FFP of other WTRUs, for example, based on the target receiver of the TB. The WTRU can share the COT and / or FFP, for example, if the COT-sharing WTRU is one of the target receivers.

[0224] The WTRU can determine the number of interleaves to select. The WTRU can determine the number of interleaves to select for (e.g., one) transmission of a TB. The WTRU can be (pre-)configured with a maximum number of interleaves to select, based on, for example, one or more of the following (e.g., any combination): the QoS (e.g., priority) of the TB, and / or the CBR of the resource pool. The WTRU can select the number of interleaves to meet the maximum (pre-)configured number of interleaves.

[0225] The WTRU can perform resource reservation. The WTRU can (e.g., decide to) reserve one or more of the following (e.g., any combination) (e.g., periodically): FFP (e.g., the WTRU can decide to reserve one FFP per N FFPs), (e.g., one) slot of an FFP, and / or one or more interleaves in an FFP slot of an FFP.

[0226] The WTRU can determine whether to reserve COT / FFP.

[0227] The WTRU can be (pre-)configured with one or more restrictions for reserving COT / FFP. For example, the WTRU may not be permitted to reserve COT / FFP if one or more restrictions are met. The WTRU can be (pre-)configured with one or more conditions for reserving COT / FFP. For example, the WTRU may be permitted to reserve COT / FFP if one or more conditions are met. The WTRU can determine whether to reserve COT / FFP based on one or more of the following (e.g., any combination).

[0228] The WTRU can determine whether to reserve COT / FFP based on the QoS of the TB. For example, the WTRU can reserve COT / FFP if the priority of the data is greater than a (pre-)configured threshold. Otherwise, the WTRU cannot reserve COT / FFP.

[0229] The WTRU can determine whether to reserve COT / FFP based on the number of transmission resources within a certain period. For example, the WTRU can reserve COT / FFP if the number of transmission resources in COT / FFP is less than a (pre-)configured threshold. Otherwise, the WTRU cannot reserve COT / FFP.

[0230] The WTRU can determine whether to reserve COT / FFP based on FFP. For example, the WTRU can reserve COT / FFP if FFP is less than a (pre-)configured threshold. Otherwise, the WTRU may not be permitted to reserve COT / FFP.

[0231] The WTRU can determine whether to reserve COT / FFP based on a (pre-)configuration. For example, the WTRU can be (pre-)configured with the maximum number of resources to reserve within a window. For example, the WTRU can be (pre-)configured with the maximum number of FFP to reserve within a window. The WTRU can determine whether to reserve COT / FFP based on, for example, whether it has reached the (pre-)configured maximum number of reserved resources and / or the maximum number of reserved COT / FFP within the window.

[0232] The WTRU can determine the CPE for the transmission of the WTRU based on the reservation information within the reserved resources.

[0233] The WTRU can be (pre-)configured with multiple CPEs to access the channel. One or more CPEs (e.g., each CPE) can be associated with one priority. The WTRU can transmit (e.g., determine to transmit) PSCCH / PSSCH in the reserved slots of other WTRUs (e.g., using different sets of interleaves). The WTRU can determine the CPEs to use based on one or more of the following (e.g., any combination).

[0234] The WTRU can determine the CPE to use based on the priority associated with the reserved resources. For example, the WTRU can use the CPE associated with the reserved resources as the CPE for its transmission. The CPE of the reserved resources can be determined based on the information (e.g., CAPC, priority) indicated in the transmission (e.g., SCI) that reserves the resources.

[0235] The WTRU can determine the CPE to use based on the priority of the WTRU's data transmission.

[0236] The WTRU can determine the CPE to use based on the (pre-)configured CPE. For example, the WTRU can use the (pre-)configured CPE if it determines to transmit in the same slot as another WTRU (e.g., using a different set of interfaces).

[0237] The WTRU can determine the CPE to use based on an indication from another WTRU. For example, the WTRU can receive an indication from the COT initiator WTRU of the CPE to use for performing FDM transmission in one or more reserved slots. The WTRU can access the channel and perform the transmission using the indicated CPE. In another example, another WTRU can reserve resources for future potential transmissions. That WTRU can indicate (e.g., implicitly / explicitly) the CPE to use. The WTRU can use the CPE indicated by the resource-reserving WTRU.

[0238] In an embodiment, the WTRU can transmit in the same slot as other WTRUs that have reserved the slot (e.g., can determine to transmit) (e.g., the WTRU can use different sets of interleaves). The WTRU can determine the CPE to use based on the priority of the WTRU's data and / or a function of the priority associated with the reserved slots of other WTRUs. The WTRU can use the CPE associated with the lowest priority among two priorities. This can ensure that reservations with higher priorities may be permitted to access the channel first. The WTRU can use the CPE associated with the highest priority among two priorities. This can assist the WTRU in accessing the channel (e.g., making it easier to access the channel). The WTRU can use the CPE associated with the priority of the reserved WTRU. The WTRU can use the CPE associated with its priority.

[0239] The WTRU can transmit in the same slot as other WTRUs that have reserved the slot (e.g., can determine to transmit) (e.g., the WTRU can use different sets of interleaves). The slot-reserving WTRU can instruct its CPE to access the channel (e.g., implicitly / explicitly). The WTRU can determine the potential CPE used to access the channel based on the QoS of its data (e.g., CAPC, priority). The WTRU can determine the CPE to use based on the indicated CPE regarding the slot-reserving WTRU and / or its potential CPE. The WTRU can use the shortest CPE among two CPEs. The WTRU can use the longest CPE among two CPEs. The WTRU can use the CPE of the slot-reserving WTRU. The WTRU can use its potential CPE.

[0240] The WTRU can change its FFP configuration based on the resource reservation information.

[0241] Based on persistent CCA failures in multiple FPPs within the evaluation window, the WTRU can (e.g., can decide to) change its FPP configuration. The WTRU can (e.g., can decide to) change its FPP configuration based on detection / reception of FPP configurations from one or more WTRUs that may cause persistent CCA failures. The WTRU can receive an indication regarding their FPP configurations from one or more WTRUs. The WTRU can determine that the FPP configurations of one or more WTRUs may result in persistent CCA failures. The WTRU can request that one or more WTRUs change their FPP configurations. The WTRU can change its FPP configuration. The WTRU can determine whether to change its FPP configuration or request that one or more other WTRUs change their configurations based on one or more of the following (e.g., any combination).

[0242] Based on the QoS associated with the WTRU's data, the WTRU can determine whether to change its FPP configuration or request that one or more other WTRUs change their configurations. For example, if the QoS associated with the WTRU's data is greater than a (pre-)configured threshold, the WTRU can request that other WTRUs change their FPP configurations. Otherwise, the WTRU can change its (e.g., its own) FPP configuration.

[0243] Based on the QoS associated with other WTRUs, the WTRU can determine whether to change its FPP configuration or request that one or more other WTRUs change their configurations. For example, if the QoS associated with the data of other WTRUs is less than a (pre-)configured threshold, the WTRU can request that other WTRUs change their FPP configurations. Otherwise, the WTUR can change its (e.g., its own) FPP configuration.

[0244] The WTRU can determine whether to change its FFP configuration or request that one or more other WTRUs change their configurations based on the data of the WTRU and the relative QoS of the data of other WTRUs. For example, the WTRU can request that another WTRU change its FFP configuration if the relative priority between the data of the WTRU (e.g., its own) and the data of other WTRUs is greater than a (pre-)configured threshold. Otherwise, the WTRU can change its (e.g., its own) FFP configuration.

[0245] The WTRU can determine whether to change its FFP configuration or request that one or more other WTRUs change their configurations based on one or more parameters of the WTRU's FFP configuration. For example, the WTRU can request that another WTRU change its FFP configuration if the WTRU's (e.g., its own) FFP is greater than a (pre-)configured threshold. Otherwise, the WTRU can change its (e.g., its own) FFP configuration.

[0246] The WTRU can determine whether to change its FFP configuration or request that one or more other WTRUs change their configurations based on one or more parameters of the FFP configurations of other WTRUs. For example, the WTRU can request that another WTRU change its FFP configuration if the FFP of the other WTRU is less than a (pre-)configured threshold. Otherwise, the WTRU can change its (e.g., its own) FFP configuration.

[0247] A WTRU can determine whether to change its FFP configuration based on the latency required for each WTRU to change its FFP configuration, or to request that one or more other WTRUs change their configurations. For example, a WTRU may be required to remain in one FFP configuration for a certain period (e.g., 200 ms). If a (e.g., one) WTRU has recently changed its FFP configuration, that WTRU may take a long time to change its FFP configuration compared to other WTRUs (e.g., that may have changed their FFP configurations quite some time ago). For example, a WTRU can request that another WTRU change its FFP configuration if the latency (e.g., required) for the other WTRU to change its FFP configuration is less than the latency for the WTRU (e.g., itself) to change its FFP configuration. Otherwise, the WTRU can change its (e.g., its own) FFP configuration (e.g., itself).

[0248] A WTRU can rate match / puncture PSCCH / PSSCH before the COT / FFP reserved for other WTRUs.

[0249] A WTRU can acquire a COT / FFP and transmit PSCCH / PSSCH. The WTRU can detect the COT / FFP reserved within the COT / FFP. The WTRU can share (e.g., decide to share) the COT / FFP with other WTRUs if the reserved frequency resources (e.g., interlaces) are orthogonal to its transmitted frequency resources. A WTRU can rate match / puncture PSCCH / PSSCH before the COT / FFP reserved for other WTRUs. The rate matching / puncturing duration can be determined based on the FFP configuration of other WTRUs. The FFP configuration of other WTRUs can be indicated in transmissions (e.g., SCI, MAC CE) that reserve the COT / FFP. This allows other WTRUs to potentially perform CCA before the reserved FFP.

[0250] Figure 17 illustrates a WTRU sharing its COT / FFP with other WTRUs. As illustrated in Figure 17, WTRU1 can start its FFP and transmit PSCCH / PSSCH. WTRU1 can detect WTRU2, which reserves one COT / FFP where the start of the FFP is within the COT / FFP of WTRU1. WTRU1 can determine to share its COT / FFP with WTRU2 by using various frequency resources (e.g., WTRU1 and WTRU2 can use different RB interleaves). WTRU1 can rate match / puncture the period in PSCCH / PSSCH transmission before the reserved COT / FFP of WTRU2. When WTRU1 rate matches / punctures the period, WTRU1 cannot transmit during that period (e.g., cannot execute transmission). WTRU1 can perform rate matching / puncturing for a certain period (e.g., one period) to support other WTRUs to perform LBT before the transmissions of other WTRUs in subsequent slots. WTRU1 and WTRU2 can share the COT / FFP (e.g., by using different frequency resources for each PSCCH / PSSCH transmission).

[0251] The WTRU can determine whether to permit other WTRUs to share its COT / FFP.

[0252] The WTRU can determine whether to allow other WTRUs to share its COT / FFP based on one or more parameters associated with its FFP, the QoS of its data, and / or one or more parameters indicated by a reserved COT / FFP. For example, the WTRU can determine whether to allow other WTRUs to share its COT / FFP. The WTRU can indicate whether its COT / FFP may be shared and / or which of the other WTRUs can share its COT / FFP (e.g., perform one or more transmissions). The WTRU can be (pre-)configured with rules or conditions for determining whether the WTRU's COT / FFP can be shared by other WTRUs. The rules or conditions can be based on the QoS of the transmission, the FFP configuration, and / or the COT information associated with the WTRU. The QoS of the transmission, the FFP configuration, and / or the COT information associated with the WTRU can be indicated in one or more transmissions of the WTRU in the COT / FFP. The WTRU can determine (e.g., next determine) whether to share the WTRU's COT / FFP based on one or more of the following (e.g., any combination).

[0253] The WTRU can determine whether to allow other WTRUs to share its COT / FFP based on the QoS of the data (e.g., CAPC, priority). For example, the WTRU can be (pre-)configured to share its COT / FFP with other WTRUs if the priority of the data is less than a (pre-)configured threshold. Otherwise, the WTRU cannot share its COT / FFP with other WTRUs.

[0254] The WTRU can determine whether to allow other WTRUs to share its COT / FFP based on the QoS (e.g., CAPC, priority) of the data associated with the reserved COT / FFP. For example, the WTRU can be (pre)-configured to share its COT / FFP with other WTRUs if the priority of the data associated with the reserved COT / FFP is greater than a (pre)-configured threshold. Otherwise, the WTRU cannot share its COT / FFP with other WTRUs.

[0255] The WTRU can determine whether to allow other WTRUs to share its COT / FFP based on the relative QoS between its data and the data associated with the reserved COT / FFP. For example, the WTRU can be (pre)-configured to share its COT / FFP with other WTRUs if the priority offset between its data and the data associated with the reserved COT / FFP is greater than a (pre)-configured threshold. Otherwise, the WTRU cannot share its COT / FFP with other WTRUs.

[0256] The WTRU can determine whether to allow other WTRUs to share its COT / FFP based on the location of the reserved COT / FFP. For example, the WTRU can rate match / puncture the PSCCH / PSSCH at a time prior to the reserved COT / FFP. If the location of the reserved COT / FFP causes the WTRU to rate match / puncture the PSCCH / PSSCH for a duration greater than a (pre)-configured threshold for the WTRU, the WTRU may not allow other WTRUs to share the COT. Otherwise, the WTRU may allow other WTRUs to share the COT / FFP.

[0257] The WTRU can determine whether to permit other WTRUs to share its COT / FFP based on the reserved FFP. For example, the WTRU can share its COT / FFP with other WTRUs if the duration of the reserved COT / FFP within the WTRU's COT / FFP is less than a (pre-)configured threshold. Otherwise, the WTRU cannot share its COT / FFP with other WTRUs.

[0258] The WTRU can determine whether to permit other WTRUs to share its COT / FFP based on the duration of the activated COT / FFP. For example, the WTRU can share its COT / FFP with other WTRUs if the duration of the activated COT / FFP within the WTRU's COT / FFP is less than a (pre-)configured threshold. Otherwise, the WTRU cannot share its COT / FFP with other WTRUs.

[0259] The WTRU can determine whether to permit other WTRUs to share its COT / FFP based on the reserved frequency resources. For example, the WTRU can share its COT / FFP with other WTRUs if the amount of reserved frequency resources (e.g., the number of reserved interlaces) is less than a (pre-)configured threshold. Otherwise, the WTRU cannot share its COT / FFP with other WTRUs. As another example, the WTRU can share its COT / FFP with other WTRUs if the reserved frequency resources are different from its selected frequency resources. Otherwise, the WTRU cannot share its COT / FFP with other WTRUs.

[0260] The WTRU can determine whether to allow other WTRUs to share its COT / FFP based on the buffer status of the WTRU. For example, if the amount of data (e.g., having a certain QoS) in its buffer is less than a (pre-)configured threshold, the WTRU can share its COT / FFP with other WTRUs. Otherwise, the WTRU cannot share its COT / FFP with other WTRUs.

[0261] The WTRU can determine whether to allow other WTRUs to share its COT / FFP based on the amount of frequency resources. For example, if the required amount of its frequency resources (e.g., within each slot) is less than a (pre-)configured threshold, the WTRU can share its COT / FFP with other WTRUs. Otherwise, the WTRU cannot share its COT / FFP with other WTRUs.

[0262] The WTRU can reselect the frequency resources (e.g., interleaves) for PSCCH / PSSCH transmission in its FFP.

[0263] When the WTRU permits sharing of its COT / FFP with another WTRU, the WTRU can reselect another frequency resource (e.g., another set of interleaves) to avoid collision with the reserved frequency (e.g., interleaves) for sharing of the COT / FFP by the other WTRU. The WTRU can use the reselected resource to perform an initial transmission of a new TB. The WTRU can continue to retransmit the TB in the reselected resources of subsequent slots.

[0264] The WTRU can determine whether to prioritize its COT / FFP.

[0265] The WTRU can detect the reserved COT / FFP of other WTRUs within its COT / FFP. The WTRU can determine whether to prioritize its COT / FFP (e.g., by ceasing the use of its COT / FFP) in order to provide resources to other WTRUs. The WTRU can determine whether to prioritize its COT / FFP based on one or more of the following (e.g., any combination).

[0266] The WTRU can determine whether to prioritize its COT / FFP based on the QoS of the data (e.g., CAPC, priority). For example, the WTRU can prioritize the COT / FFP if the priority of the data is less than a (pre-)configured threshold. Otherwise, the WTRU cannot prioritize its COT / FFP.

[0267] The WTRU can determine whether to prioritize its COT / FFP based on the QoS of the data associated with the reserved COT / FFP (e.g., CAPC, priority). For example, the WTRU can prioritize the COT / FFP if the priority of the data associated with the reserved COT / FFP is greater than a (pre-)configured threshold. Otherwise, the WTRU cannot prioritize its COT / FFP.

[0268] The WTRU can determine whether to prioritize its COT / FFP based on the relative QoS between its data and the reserved COT / FFP. For example, the WTRU can prioritize the COT / FFP if the priority offset between the WTRU's data and the data associated with the reserved COT / FFP is greater than a (pre-)configured threshold. Otherwise, the WTRU cannot prioritize its COT / FFP.

[0269] The WTRU can determine whether to preferentially control the COT / FFP based on the reserved COT / FFP. For example, the WTRU can preferentially control the COT / FFP if the reserved COT / FFP within its COT / FFP is greater than a (pre-)configured threshold. Otherwise, the WTRU cannot preferentially control the COT / FFP.

[0270] The WTRU can determine whether to preferentially control the COT / FFP based on the duration of the activated COT / FFP. For example, the WTRU can preferentially control the COT / FFP if the duration of the activated COT / FFP is less than a (pre-)configured threshold. Otherwise, the WTRU cannot preferentially control the COT / FFP.

[0271] The WTRU can determine whether to preferentially control the COT / FFP based on the reserved frequency resources. For example, the WTRU can preferentially control the COT / FFP if the amount of reserved frequency resources (e.g., the number of reserved interleaves) is greater than a (pre-)configured threshold. Otherwise, the WTRU cannot preferentially control the COT / FFP.

[0272] The WTRU can determine whether to preferentially control the COT / FFP based on the amount of its frequency resources. For example, the WTRU can preferentially control the COT / FFP if the amount of its frequency resources used in each slot (e.g., the number of reserved interleaves) is less than a (pre-)configured threshold. Otherwise, the WTRU cannot preferentially control the COT / FFP.

[0273] The WTRU can determine whether to prioritize the control of COT / FFP based on the buffer status of the WTRU. For example, if the amount of data in the buffer of the WTRU is less than a (pre-)configured threshold, the WTRU can prioritize the control of its COT / FFP. Otherwise, the WTRU cannot prioritize the control of its COT / FFP.

[0274] The WTRU can determine the FFP that requests HARQ feedback from the Rx WTRU and / or the HARQ transmission timing. For example, the TB may request HARQ feedback. The Tx WTRU can request (e.g., determine) that the Rx WTRU provide feedback in the FFP of the TX WTRU (e.g., for the PSFCH transmission timing instructed to provide feedback), or in the FFP initiated by the Rx WTRU itself, based on one or more of the following: the QoS of the TB, the remaining transmissions of the WTRU within the period (e.g., to maintain the COT until the instructed PSFCH), the remaining COT duration, and / or the gap to the next FFP of the Rx WTRU. The WTRU can perform one or more of the following (e.g., any combination): receive the PSFCH configuration within the resource pool (e.g., per slot), receive the FFP and / or the PSFCH configuration from a peer WTRU (e.g., WTRU-B) via, for example, PC5-RRC, acquire the COT in an FFP (e.g., one), determine the feedback transmission timing (e.g., for each transmission of the HARQ-enabled TB) based on one or more of the following: the priority of the TB, the remaining number of WTRU transmissions, the remaining COT duration, the gap to the next FFP of the Rx WTRU, and / or the PSFCH configuration, determine the duration and / or the number of HARQ feedback attempts of the Rx WTRU based on the QoS of the TB and / or the FFP configuration of the WTRU, indicate the HARQ feedback transmission timing / resource in the SL control information (SCI) for (e.g., each) transmission and / or the maximum number of transmissions and / or feedback attempts, monitor the feedback for (e.g., each) transmission, and / or access the channel and perform a retransmission for the TB if, for example, NACK / DTX is detected in the maximum number of HARQ attempts.

[0275] The Rx WTRU can perform HARQ feedback. The WTRU (e.g., Rx WTRU) can receive, from the Tx WTRU, a transmission that requests feedback at the FFP of the Rx WTRU at (e.g., one of) the N PSFCH transmission timings. The WTRU (e.g., Rx WTRU) can perform channel access (e.g., continuously at each FFP) until it succeeds in transmitting the PSFCH at the N transmission timings (e.g., one of). The WTRU (e.g., Rx WTRU) can perform one or more of the following (e.g., any combination): for example, determining the FFP configuration (e.g., period and / or offset) based on whether the configured service supports HARQ feedback (e.g., the initial symbol of the FFP can be used for, e.g., PSFCH transmission if the service supports HARQ feedback, and the initial symbol of the FFP can be used for, e.g., PSCCH / PSSCH if the service does not support HARQ feedback), performing HARQ feedback at the FFP of the Rx WTRU, and / or receiving a transmission from the Tx WTRU that can indicate at least one of the evaluation of up to N CCA transmission timings, performing CCA (e.g., for each of the next N FFPs) to access the channel until it succeeds in transmitting the PSFCH at the (e.g., one) transmission timing and transmitting the PSFCH at the PSFCH transmission timing, and / or reporting a channel access failure to the gNB if the WTRU fails to access the channel at the transmission timings (e.g., all N transmission timings).

[0276] The features and elements described above are presented in specific combinations, but 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.

[0277] The implementation forms described in this specification may consider the 3GPP specification protocol, but it can be understood that the implementation forms described in this specification are not limited to this scenario and may be applicable to other wireless systems. For example, the solutions described in this specification consider LTE, LTE-A, New Radio (NR), or 5G specification protocols, but it can be understood that the solutions described in this specification are not limited to this scenario and are similarly applicable to other wireless systems.

[0278] 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 a processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via a wired connection and / or a wireless connection) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and / or optical media such as Compact Disc (CD)-ROM disks and / or Digital Versatile Disk (DVD). A radio frequency transceiver for use in a WTRU, a terminal, a base station, an RNC (Radio Network Controller), and / or any host computer may be implemented using a processor associated with the software.

Claims

1. A wireless transmit / receive unit (WTRU) comprising a processor, the processor being configured to: receive configuration information, the configuration information including an indication of a channel busy ratio (CBR) threshold; determine a CBR value associated with a channel in a listen before talk (LBT) band; compare the CBR value with the CBR threshold; determine channel access parameters based on a comparison of the CBR value and the CBR threshold; and change the channel access parameters. A wireless transmit / receive unit (WTRU) configured to perform the above.

2. The configuration information further includes an indication of a channel access failure threshold and a fixed frame period (FFP) switching window. Before comparing the CBR value with the CBR threshold, the processor is further configured to: perform a plurality of channel access attempts associated with the FFP switching window; and determine that the number of channel access attempts meets the channel access failure threshold. The WTRU according to claim 1, configured to perform the above.

3. The configuration information further includes an indication of a channel access failure threshold. The processor is configured to compare the CBR value with the CBR threshold based on a determination that the number of channel access attempts meets the channel access failure threshold. The WTRU according to claim 1, configured to perform the above.

4. The processor being configured to change the channel access parameters includes the processor being configured to change the FFP configuration when the CBR value is less than the CBR threshold. The WTRU according to claim 4, wherein the FFP configuration includes one or more of FFP periodicity or an FFP offset value.

5. The processor being configured to change the channel access parameters includes the processor being configured to switch to a different LBT band or sub-band when the CBR value meets the CBR threshold. The WTRU according to any one of claims 1 to 5, configured to perform the above.

6. The fact that the processor is configured to change the channel access parameter includes that the processor is configured to change a resource block set when the CBR value satisfies the CBR threshold value, the WTRU according to any one of claims 1 to 5.

8. The configuration information further includes an indication of a first set of sidelink synchronization signal block (S-SSB) resources and an indication of a second set of S-SSB resources, and the processor further uses the first set of S-SSB resources to transmit a first message; determines a transmission status of the first message; determines to use the second set of S-SSB resources to transmit a second message based on the transmission status of the first message; uses the second set of S-SSB resources to transmit the second message, the WTRU according to claim 1, configured to perform.

9. The fact that the processor is configured to determine to use the second set of S-SSB resources to transmit the second message based on the transmission status of the first message includes that the processor is configured to determine to use the second set of S-SSB resources to transmit the second message based on the transmission status of the first message indicating that the first message transmission has failed, the WTRU according to claim 8.

10. The configuration information further includes an indication of a first set of sidelink synchronization signal block (S-SSB) resources and an indication of a second set of S-SSB resources, the second set of S-SSB resources being configured to be shared between S-SSB transmissions and other sidelink transmissions, and the processor further uses the first set of S-SSB resources to transmit S-SSB; determines a transmission status of the S-SSB; determines a quality of service (QoS) of sidelink data or a QoS of feedback information; Determining to transmit the sidelink data or the feedback information using the second set of S-SSB resources based on the transmission status of the S-SSB, the QoS of the sidelink data, or the QoS of the feedback information; The WTRU according to claim 1, configured to perform transmitting the sidelink data or the feedback information using the second set of S-SSB resources. **Claim 11** A method comprising: Receiving configuration information, the configuration information including an indication of a channel busy ratio (CBR) threshold; Determining a CBR value associated with a channel in a listen before talk (LBT) band; Comparing the CBR value with the CBR threshold; Determining channel access parameters based on a comparison of the CBR value and the CBR threshold; Changing the channel access parameters. **Claim 12** The configuration information further indicates a channel access failure threshold and a fixed frame period (FFP) switching window, The method further comprises, before comparing the CBR value with the CBR threshold, Performing a plurality of channel access attempts associated with the FFP switching window; Determining that the number of channel access attempts meets the channel access failure threshold. The method according to claim 11. **Claim 13** The configuration information further indicates a channel access failure threshold, and comparing the CBR value with the CBR threshold includes comparing the CBR value with the CBR threshold based on that the number of channel access attempts meets the channel access failure threshold. The method according to claim 11. **Claim 14** Changing the channel access parameters includes changing the FFP configuration when the CBR value is less than the CBR threshold. The method according to claim 11 or 12. **Claim 15** The FFP configuration includes one or more of FFP periodicity or an FFP offset value. The method according to claim 14. **Claim 16** Changing the channel access parameters includes switching to a different LBT band or sub-band when the CBR value meets the CBR threshold. The method according to any one of claims 11 to 15. **Claim 17** The method according to any one of claims 11 to 15, wherein changing the channel access parameter includes changing a resource block set when the CBR value satisfies the CBR threshold value.

18. The configuration information further includes an indication of a first set of sidelink synchronization signal block (S-SSB) resources and an indication of a second set of S-SSB resources, and the method further includes transmitting a first message using the first set of S-SSB resources; determining a transmission status of the first message; determining to transmit a second message using the second set of S-SSB resources based on the transmission status of the first message; transmitting the second message using the second set of S-SSB resources, the method according to claim 11.

19. Determining to transmit the second message using the second set of S-SSB resources based on the transmission status of the first message includes determining to transmit the second message using the second set of S-SSB resources based on the transmission status of the first message indicating that the first message has failed to be transmitted, the method according to claim 18.

20. The configuration information further includes an indication of a first set of sidelink synchronization signal block (S-SSB) resources and an indication of a second set of S-SSB resources, and the second set of S-SSB resources is configured to be shared between S-SSB transmission and other sidelink transmissions, and the method further includes transmitting S-SSB using the first set of S-SSB resources; determining a transmission status of the S-SSB; determining a quality of service (QoS) of sidelink data or QoS of feedback information; determining to transmit the sidelink data or the feedback information using the second set of S-SSB resources based on the transmission status of the S-SSB and the QoS of the sidelink data or the QoS of the feedback information. Using the second set of the S-SSB resources to transmit the sidelink data or the feedback information, the method according to claim 11, comprising.

Images