Method for efficient sidelink scheduling in unlicensed spectrum

Abstract

A wireless transmit / receive unit (WTRU) may receive downlink control information (DCI) that schedules a sidelink (SL) grant indicating a time window for initiating a channel occupancy time (COT). The WTRU may perform a listen before talk (LBT) within the indicated time window for initiating the COT to access an SL unlicensed channel in an unlicensed frequency band. After a successful channel access result of the performed LBT, the WTRU may transmit uplink control information (UCI) to the base station. The UCI may indicate the successful channel access result and a COT start time within the indicated time window for initiating the COT. Likewise, the UCI may further indicate an expected number of transmissions by the WTRU in the COT. In addition, the UCI may further indicate reserved sub-channels, reserved interleaving, or both within the COT. Additionally, based on a buffer state and the COT start time, the WTRU may determine whether to share the COT.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 334,977 filed on April 26, 2022 and U.S. Provisional Application No. 63 / 445,516 filed on February 14, 2023, the contents of which are incorporated herein by reference. Background Art

[0003] In unlicensed bands, a channel access procedure may be required before transmission to ensure fair sharing of the unlicensed spectrum between different radio access technologies. Channel access may use a listen-before-talk (LBT) procedure. If there is an LBT failure, the scheduled grant may not be used. To avoid performing multiple LBTs, the transmitter may initiate a channel occupation time (COT) and keep it for a relatively long duration. In new radio (NR) in unlicensed spectrum, since the transmission is to the gNB, the gNode B (gNB) may be aware of the success or failure of the LBT on the wireless transmit / receive unit (WTRU) side.

[0004] In Mode 1 sidelink, the gNB may be responsible for scheduling in the sidelink channel. The WTRU may request a sidelink grant from the gNB and receive downlink control information (DCI) scheduling the sidelink resources. The WTRU may report the sidelink hybrid automatic repeat request (HARQ) acknowledgement (ACK) feedback to the gNB and accept additional resources for sidelink retransmissions when it reports a negative ACK (NACK).

[0005] The WTRU may not be able to access the channel to send scheduled resources for the sidelink unlicensed channel. For multi-slot scheduling, one LBT failure may affect multiple scheduled slots and result in inefficient resource utilization. The gNB may not be able to determine whether the WTRU can access the channel because the sidelink transmission is not intended for the gNB. Summary of the invention

[0006] Disclosed herein are methods and apparatus for efficiently scheduling SL transmissions and related uplink feedback for a mode 1 side link (SL) in an unlicensed spectrum. In one example, a first wireless transmit / receive unit (WTRU) may receive downlink control information (DCI) scheduling a SL grant from a base station, the SL grant indicating a time window for initiating a channel occupancy time (COT). The first WTRU may perform listen-before-talk (LBT) within the indicated time window for initiating the COT to access the SL unlicensed channel in the unlicensed band. After a successful channel access result of the performed LBT, the first WTRU may send uplink control information (UCI) to the base station. The UCI may indicate or report a successful channel access result and a COT start time within the indicated time window for initiating the COT.

[0007] In another example, the UCI may further indicate an expected number of transmissions by the first WTRU in the COT. Similarly, the UCI may further indicate one or more reserved subchannels within the COT. Additionally, the UCI may further indicate one or more reserved interlaces within the COT. In another example, based on the buffer status and the COT start time, the first WTRU may determine whether to share the COT. Based on determining that the COT is to be shared, the first WTRU may provide a COT sharing recommendation to the base station. Additionally, the first WTRU may receive a COT sharing confirmation that verifies the COT sharing recommendation provided by the first WTRU.

[0008] The first WTRU may also initiate a COT. Likewise, the COT may be initiated at the COT start time and may last for the COT duration. In addition, the first WTRU may occupy a SL unlicensed channel during the COT. In addition, the first WTRU may monitor physical sidelink feedback channel (PSFCH) transmissions of one or more second WTRUs that share the COT initiated by the first WTRU. Likewise, the WTRU may indicate to the base station or may report to the base station SL hybrid automatic repeat request (HARQ)-acknowledgement (ACK) feedback received from one or more PSFCH transmissions of one or more second WTRUs that share the COT initiated by the first WTRU. In one example, the first WTRU may be a transmitter (Tx) WTRU. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate like elements, and in which:

[0010] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0011] Figure 1Bis an example of an embodiment in which Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0012] Figure 1C is an example of an embodiment in which Figure 1A a system diagram of an example Radio Access Network (RAN) and an example Core Network (CN) used within the illustrated communication system;

[0013] Figure 1D is an example of an embodiment in which Figure 1A A system diagram of an additional example RAN and an additional example CN used within the illustrated communication system;

[0014] Figure 2 is a diagram illustrating an example of a WTRU initiating a channel occupancy time (COT) in a sidelink unlicensed channel indicated by a set of resource blocks (RBs) and a time window;

[0015] Figure 3 is a diagram illustrating an example where a WTRU reports a COT start time as an offset;

[0016] Figure 4 is a diagram illustrating an example of a transmitter (Tx) WTRU reporting to a base station on its initiated COT;

[0017] Figure 5 is a flow chart illustrating an example of a WTRU reporting to a base station on a COT it initiates; and

[0018] Figure 6 is a diagram illustrating a Tx WTRU reporting a delayed sidelink hybrid automatic repeat request (HARQ) acknowledgement (ACK) to a base station. DETAILED DESCRIPTION

[0019] Figure 1A1 is a diagram illustrating an example 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 multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

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

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

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

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

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

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

[0026] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology (such as NR radio access) that may establish the air interface 116 using NR.

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

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

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

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

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

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

[0033] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may 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, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

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

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

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

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

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

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

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

[0041] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an 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, module, a frequency modulation (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 device 138 may include one or more sensors. The sensor may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geographic location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0042] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

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

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

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

[0046] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

[0051] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

[0052] In a representative embodiment, the other network 112 may be a WLAN.

[0053] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STA) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Services originating from outside the BSS and directed to the STA may be reached by the AP and may be delivered to the STA. Services originating from the STA and directed to a destination outside the BSS may be transmitted to the AP to be delivered to the corresponding destination. Services between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit services to the AP, and the AP may deliver services to the destination STA. Services between STAs within the BSS may be considered and / or referred to as point-to-point services. Point-to-point services may be transmitted between the source STA and the destination STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0054] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP may send beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may listen to the primary channel. In the case where the primary channel is listened / detected and / or determined to be busy by a specific STA, the specific STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0055] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0056] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0057] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0058] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as 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 may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. In the case where the primary channel is busy, for example, because a STA (which only supports a 1MHz operating mode) is transmitting to the AP, all available bands may be considered busy even if most of the available bands remain idle.

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

[0060] Figure 1D1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

[0062] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths over time).

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

[0064] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, interworking between DC, NR, and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0065] Figure 1DThe illustrated CN 106 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although the aforementioned elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0066] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0067] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 106 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 106 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

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

[0070] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following items may be performed by one or more simulation devices (not shown): WTRU102a to 102d, base station 114a to 114b, evolved Node B 160a to 160c, MME 162, SGW 164, PGW 166, gNB180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0072] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0073] Methods for efficiently scheduling sidelink transmissions and related uplink feedback for Mode 1 sidelink communications in unlicensed spectrum to minimize ambiguity between gNB and WTRU due to Listen Before Talk (LBT) uncertainty are desirable. Embodiments and examples provided herein include solutions for minimizing such ambiguity and improving sidelink communication efficiency.

[0074] In some embodiments, the WTRU may be configured with a set of resource blocks (RBs) within a resource pool and / or transmission window for initiating channel occupancy time (COT) in a sidelink unlicensed channel. The WTRU may then report the LBT status and the COT structure it initiated when acquiring the channel. After the sidelink transmission, the WTRU may send sidelink hybrid automatic repeat request (HARQ) feedback of other WTRUs sent on its own COT. The WTRU may request a sidelink unlicensed grant from the gNB and indicate a preference for initiating its own COT. The WTRU may receive downlink control information (DCI) indicating the RB set / resource pool / transmission window to be initiated in the sidelink unlicensed channel and the maximum COT duration. The WTRU may perform a successful LBT and initiate a COT in time slot n. The WTRU may report the initiated COT characteristics to the gNB using a physical uplink control channel (PUCCH) transmission or a new uplink control information (UCI) type piggybacked in a physical downlink shared channel (PUSCH) transmission. The WTRU may send a PUSCH transmission, a PUCCH transmission, or both in timeslot n+offset_1, where offset_1 is configured by the gNB and may be set to 0 based on the WTRU capabilities. The WTRU may indicate its expected number of transmissions in the COT and the interlaces reserved for its own transmissions. The WTRU may indicate a COT sharing proposal to the gNB. The sharing proposal may include a set of timeslots and interlaces to be shared with other WTRUs.

[0075] The WTRU may receive shared information / confirmation of its own COT by the gNB using group common DCI. Based on the COT shared information, the WTRU may monitor the Physical Sidelink Feedback Channel (PSFCH) of other WTRUs within the WTRU's COT. The WTRU may determine the PSFCH timing to monitor based on the shared Physical Sidelink Shared Channel (PSSCH) transmission timing for other WTRUs. The WTRU may report the sidelink HARQ feedback corresponding to its transmission and the sidelink HARQ feedback sent by other WTRUs to the gNB within the shared COT using PUCCH resources, PUSCH resources, or both.

[0076] In some examples, the transmitter (Tx) WTRU may report a delayed HARQ-acknowledgement (ACK) value to the gNB when it fails to share its COT with the receiver (Rx) WTRU to send sidelink HARQ-ACK feedback. The WTRU may monitor the DCI to indicate whether an additional PUCCH may be allocated for the sidelink ungranted HARQ transmission, or may wait for a one-time HARQ-ACK to be triggered.

[0077] The Tx WTRU may be configured with a single timeslot or multiple timeslots for sidelink unlicensed transmissions from the gNB. The Tx WTRU may transmit on a scheduled grant when LBT is successful. Based on its expected transmission, such as buffering at the start of the transmission, the WTRU may determine whether it will share the COT with the Rx WTRU. If the Tx WTRU does not share its COT with the Rx WTRU to send the sidelink HARQ-ACK feedback, the WTRU may report a delayed HARQ-ACK feedback value to the gNB. The delayed HARQ-ACK feedback may carry an estimated time for sidelink HARQ transmission based on the expected future COT sharing of the Tx WTRU in subsequent timeslots, and / or the available sidelink unlicensed grants in the Tx WTRU. When the packet delay budget (PDB) expires, the Tx WTRU may refresh the HARQ-ACK buffer corresponding to the sidelink unlicensed transmission. The WTRU may indicate the ACK value to the gNB when the PDB expires.

[0078] When reporting delayed HARQ feedback, the Tx WTRU may receive a DCI that may indicate new PUCCH resources for acknowledging the sidelink HARQ-ACK transmission in a later opportunity and / or wait for a one-time HARQ-ACK codebook to trigger HARQ feedback for the sidelink unlicensed grant group.

[0079] Vehicle-to-everything (V2X) communications support direct communications between vehicle WTRUs using sidelink channels. Vehicle platooning enables vehicles traveling together to dynamically form groups. All vehicles in a platoon may receive periodic data from the lead vehicle for platoon operation. This information allows the distance between vehicles to become extremely small. In one example, the gap distance converted to time may be very low, such as sub-second. Platooning applications may allow following vehicles to drive autonomously.

[0080] Extended sensors enable the exchange of raw or processed data or live video data collected by local sensors between vehicles, roadside units (RSUs), pedestrian devices, and V2X application servers. Vehicles can enhance their perception of their environment beyond the range of their own sensors and have a more comprehensive view of local conditions.

[0081] Advanced driving enables semi-autonomous or fully autonomous driving. Longer inter-vehicle distances are assumed. Each vehicle and / or RSU shares data obtained from its local sensors with nearby vehicles, allowing the vehicles to coordinate their trajectories or maneuvers. In addition, each vehicle shares its driving intent with nearby vehicles. The benefits of this set of use cases are safer travel, collision avoidance, and improved traffic efficiency.

[0082] Remote driving enables a remote driver or V2X application to operate a remote vehicle for passengers who are unable to drive themselves or for a remote vehicle located in a hazardous environment. For situations where changes are limited and routes are predictable, such as public transportation, cloud-based driving can be used. In addition, this use case group can consider access to a cloud-based backend service platform.

[0083] Resource allocation is used in NR V2X. There are two modes defined for V2X scheduling in NR V2X: Mode 1 and Mode 2. In the case of Mode 1, the gNB is responsible for scheduling the sidelink grant to be used in the sidelink channel. There are two ways for the gNB to assign grants to the V2X WTRU, namely by using dynamic grants scheduled by DCI or using configured grants. Two types of configured grants are supported: Type 1 and Type 2. Type 1 configured grants are semi-statically configured using Radio Resource Control (RRC) and the V2X WTRU can use it when needed. In Type 2 configured grants, some configurations are signaled using RRC, but the grant itself is activated using DCI.

[0084] In Mode 2, the WTRU uses sensing methods to autonomously select sidelink resources from a preconfigured resource pool to minimize conflicts with other V2X WTRUs.

[0085] In Mode 1, the gNB is responsible for allocating sidelink resources to the V2X WTRU for initial transmissions and retransmissions. The gNB may need to know the outcome of the sidelink transmission, e.g., whether the transmission was successful, to allocate new resources as needed. A V2X WTRU operating in Mode 1 may use PUCCH resources to report sidelink HARQ-ACK for scheduled transmissions to the gNB, the network, or both. The gNB uses the DCI that schedules the sidelink grant to assign PUCCH resources to the WTRU.

[0086] The unlicensed spectrum provides large bandwidth at no cost. Since operation in the unlicensed spectrum reduces costs for service providers, more WTRUs are expected to operate in the unlicensed spectrum.

[0087] In unlicensed bands, a channel access procedure is required before transmission to ensure fair sharing of the unlicensed spectrum between different radio access technologies. Channel access uses the LBT procedure. The LBT procedure can be defined as a mechanism for the equipment to apply a clear channel assessment (CCA) check before using the channel. CCA utilizes at least energy detection to determine the presence or absence of other signals on the channel to determine whether the channel is occupied or idle, respectively. For some LBT types, a fixed sensing duration equal to 16μs or 25μs is used, and for other types, a random number N corresponding to the number of empty idle time slots is used. Four channel access types are defined, which may be referred to as LBT types.

[0088] In Type 1 channel access, the transmitter may transmit after sensing that the channel is idle during N sensing time slots, where N is a random number. An additional deferral duration is sensed whenever the channel is sensed busy on one of the N time slots. In Type 2A channel access, the transmitter may send a transmission immediately after sensing that the channel is idle for at least 25 microseconds. In Type 2B channel access, the transmitter may send a transmission immediately after sensing that the channel is idle for at least 16 microseconds. In Type 2C channel access, the transmitter does not sense the channel before transmitting.

[0089] Once a transmitter acquires a channel, it occupies the channel for the duration of the COT. Depending on which LBT type is used to acquire the channel, the COT may have a maximum duration. A transmitter may initiate a COT and share it with another transmitter under some restrictions. For example, LBT type 4 may be used to initially acquire a channel, and the gaps between different transmissions may be smaller than the specified gap.

[0090] NR supports full deployment in unlicensed bands. Both downlink and uplink may use unlicensed spectrum to send data and control signaling. The gNB and WTRU may perform LBT before transmission. The gNB may initiate a COT, which may be referred to as a gNB-initiated COT, and share the COT with the WTRU for uplink transmissions. The WTRU may initiate a COT, which may be referred to as, for example, a UE-initiated COT or a WTRU-initiated COT. The WTRU may then share the COT with the serving gNB. The WTRU determines whether to initiate a COT or share the gNB COT based on an indication from the gNB. For dynamic grants, the DCI of the scheduling grant may indicate to the WTRU whether to initiate a COT or share the gNB COT. For configured grants, the WTRU determines whether to initiate a COT or share the gNB COT based on the group-common DCI sent by the gNB to the WTRU group.

[0091] It may be beneficial to initiate a COT and keep it for a relatively long duration to avoid performing multiple LBTs. For example, when a transmitter has multiple transmissions, it may initiate a COT and keep it for multiple slots. Due to these benefits, NR-Unlicensed (NR-U) supports multi-slot uplink scheduling, where a single DCI may schedule multiple consecutive PUSCH transmissions. A different transport block (TB) may be sent on each slot. A single DCI message scheduling multiple transport blocks may provide resource allocation parameters for each TB.

[0092] Sidelink operation in unlicensed spectrum in FR1 (SL U) for both Mode 1 and Mode 2 is currently under study. The unlicensed sidelink bands may be 5 GHz and 6 GHz, and Uu operation associated with Mode 1 may be limited to licensed spectrum. The sidelink unlicensed channel access design will be based on regional regulatory requirements with existing NR-U channel access as a starting point.

[0093] In order to support the sidelink in an unlicensed band while maintaining resource allocations under the control of the gNB or base station (such as in resource allocation mode 1), the gNB or base station may need to know the status of the scheduled transmissions. In the case where NR V2X is deployed in unlicensed spectrum, the WTRU may not be able to access the channel to send the sidelink transmission. For multi-slot scheduling, one LBT failure affects multiple scheduled time slots and leads to inefficient resource utilization. This problem does not exist in NR-U because the multi-slot scheduling is intended to be received by the gNB or base station, so the gNB or base station can determine whether the transmission exists. The gNB or base station may not be able to determine whether the V2X WTRU can access the channel because the sidelink transmission is not intended for the gNB or base station. Waiting for several time slots in order to receive the sidelink HARQ-ACK feedback for the scheduled transmission may not be efficient because those resources may be configured for another V2X WTRU that can access the channel. Therefore, a method for efficiently scheduling WTRU sidelink transmissions and related uplink feedback in mode 1 in unlicensed spectrum to minimize the ambiguity between the gNB or base station and the WTRU due to LBT uncertainty is desirable.

[0094] The terms pre-configuration and configuration can be used interchangeably throughout the embodiments and examples provided herein. As used herein, the term resource can refer to a single resource or can be considered to refer to multiple resources and still be consistent with the embodiments and examples provided herein. Similarly, the term resource can refer to multiple resources or can be considered to refer to a single resource and still be consistent with the embodiments and examples provided herein.

[0095] In addition, as used herein, PSCCH / PSSCH transmission may refer to any one of PSCCH transmission, PSSCH transmission, or a combination of PSCCH transmission and PSSCH transmission and still be consistent with the embodiments and examples provided herein. Similarly, PSCCH / PSSCH resources may refer to any one of PSCCH resources, PSSCH resources, or a combination of PSCCH resources and PSSCH resources and still be consistent with the embodiments and examples provided herein. As used herein, resources may include any one of one or more time resources, one or more frequency resources, or a combination of one or more time resources and one or more frequency resources.

[0096] The embodiments and examples provided herein include COT configurations for a mode 1 sidelink in an unlicensed band. In some examples, the WTRU may request a specific COT configuration from a gNB or base station along with a sidelink unlicensed grant request. For example, the WTRU may request a sidelink unlicensed grant from a gNB or base station within a shared COT. Additionally or alternatively, the WTRU may request a sidelink unlicensed grant to initiate its own COT. In some examples, the WTRU may request a COT duration from a base station. For example, the WTRU may request a 5ms COT duration for sidelink unlicensed transmissions from a base station.

[0097] The WTRU may include one or more of the following along with the COT configuration request. The WTRU may include a COT duration, where the WTRU may request a specific COT duration to be used for sidelink unlicensed transmissions. Likewise, the WTRU may include a shared COT or a COT initiated by the WTRU itself. In the example for a shared COT, the WTRU may indicate a preference for a specific COT, such as, for example, a different Tx WTRU or a base station initiated COT in the vicinity. Additionally, the WTRU may include multiple sharable time slots within the COT. For example, the WTRU may request a COT with multiple time slots that may be shared with other sidelink WTRUs.

[0098] In some examples, the WTRU may use a MAC control element (CE) to indicate the COT configuration preference to the base station or gNB. For example, the WTRU may use a new buffer status report (BSR) format, which may indicate the COT configuration preference together with the BSR. In other examples, the WTRU may be configured with a PUCCH resource to indicate the COT configuration preference to the base station. The PUCCH resource may carry a new UCI format indicating the COT configuration preference.

[0099] In some embodiments and examples, a base station (or gNB) may share its COT with a sidelink Tx WTRU. In some examples, the WTRU may be configured to send a sidelink unlicensed grant on a shared COT initiated by a gNB in ​​an unlicensed band. The WTRU may receive a DCI scheduling a sidelink unlicensed grant within the shared COT and may indicate the COT initiator for the configured COT. For example, the DCI may include a bit field indicating three values: a first value indicating that the COT is initiated by the gNB, a second value indicating that the COT is initiated by another WTRU, and a third value indicating that the WTRU is responsible for initiating the COT. When sending a sidelink grant within a gNB-initiated COT or within a COT initiated by another WTRU, the WTRU may be instructed by the gNB which LBT type and / or channel access priority category to use for LBT. For example, the DCI format may carry a bit field indicating the LBT type and / or channel access priority category.

[0100] In some embodiments and examples, the base station (or gNB) may request the Tx WTRU to initiate a COT in a sidelink unlicensed channel. Specifically, in some examples, the WTRU may be instructed by the gNB to initiate a COT in a sidelink unlicensed channel to send a scheduled grant on the sidelink unlicensed channel. The WTRU may be configured with a new DCI format for scheduling the WTRU to initiate its own COT, or an existing DCI may be reused and the interpretation of the bit fields may be different. The WTRU may receive one or more of the following from the gNB to initiate a COT in a sidelink unlicensed channel: a resource pool, a subband within a carrier bandwidth, a set of RBs, a subchannel, one or more interleaving indices, a transmission window, a transmission time, and / or a COT configuration.

[0101] The received resource pools may be those resource pools on which the WTRU may attempt to access the channel. For example, the WTRU may receive resource pools on which the WTRU may attempt to access the channel. The WTRU may select a subchannel for transmission based on the LBT result. The DCI scheduling the sidelink grant may indicate the set of resource pools on which to attempt to access the channel and initiate COT.

[0102] The subbands within the received carrier bandwidth may be those subbands on which the WTRU may attempt to access the channel.The DCI scheduling the sidelink grant may indicate the set of subbands on which to attempt to access the channel and initiate COT.

[0103] The received RB set may be the RB set on which the WTRU may attempt to access the channel. In such an example, the WTRU may select a subchannel to transmit on based on the result of the channel access procedure (i.e., LBT success or failure). For example, if the WTRU transmits on a subchannel where LBT succeeded. The DCI scheduling the sidelink grant may indicate the RB set on which to attempt to access the channel and initiate COT.

[0104] The received subchannels may be those on which the WTRU may attempt to access the channel. In this case, the WTRU may transmit only on the configured subchannels. If LBT fails, the WTRU does not send a sidelink ungranted grant. The DCI scheduling the sidelink grant may indicate the set of subchannels on which to attempt to access the channel and initiate a COT.

[0105] The received one or more interlace indices may be those interlace indices on which the WTRU may attempt to access the channel.The DCI scheduling the sidelink grant may indicate the set of interlaces on which to attempt to access the channel and initiate COT.

[0106] The received transmission window may be a transmission window over which the WTRU is allowed to access the channel. In this case, the WTRU may attempt to access the channel at multiple times within the transmission time window until the channel is acquired (i.e., LBT succeeds). The DCI scheduling the sidelink grant may indicate the time window for attempting to access the channel and initiating COT.

[0107] In some examples, the WTRU may only be able to transmit on the configured transmission time if a transmission time is received. If LBT fails, the WTRU may not send a sidelink ungranted grant.

[0108] The COT configuration may include a maximum COT duration and the number of sharable time slots. For example, the WTRU may be configured with a maximum COT duration to be used for sidelink unlicensed transmissions. The maximum COT duration may be defined from the start of the time window for starting COT, or alternatively, from the time the sidelink unlicensed channel is acquired (e.g., LBT is successful). The DCI for the scheduling grant may indicate the COT configuration using a bit field in the DCI.

[0109] Figure 2 is a diagram illustrating an example of a WTRU initiating COT in a sidelink unlicensed channel indicated by an RB set and a time window. In the example shown in diagram 200, the WTRU may be a Tx WTRU. For example, the Tx WTRU may receive a DCI from a base station in time slot #n indicating a time window to start COT starting from time slot #n+k0 and RBs for initiating COT for a certain COT duration. After some LBT attempts, the Tx WTRU is able to acquire the channel in time slot #n+k1 and start transmitting on the bandwidth within the configured RB set. The bandwidth within the configured RB set depends on the LBT result.

[0110] The Tx WTRU may then initiate a COT for a duration of one slot or multiple slots. For example, the Tx WTRU may initiate a COT 210 for four slots starting from slot #n+k1. In one example, the slots may be PSSCH / PSCCH slots, and the Tx WTRU may begin sending PSSCH / PSCCH transmissions in the slots during the COT 210. For example, the Tx WTRU may send PSSCH / PSCCH transmissions 240 and PSSCH / PSCCH transmissions 260 in the COT 210.

[0111] Figure 3is a diagram illustrating an example of a WTRU reporting a COT start time as an offset. In some embodiments and examples, the WTRU may be configured to report the LBT result to the base station upon successful access to the channel (e.g., LBT success) or upon failure to access the channel within the configured time window for starting COT. In the example shown in diagram 300, the WTRU may receive a DCI indicating scheduling in the SLU. In each example, the WTRU may be a Tx WTRU.

[0112] In some examples where the Tx WTRU is reporting LBT success, the Tx WTRU may also report the initiated channel occupancy time characteristics to the base station. To report the LBT results and the initiated COT characteristics, the Tx WTRU may be configured to use one or more PUCCH resources, or as Figure 3 A new UCI type is piggybacked in the PUSCH transmission as shown in the example in FIG.

[0113] exist Figure 3 In the example shown, the Tx WTRU may initiate a COT for a duration of one slot or multiple slots. For example, the Tx WTRU may initiate a COT 310 for four slots starting from slot #n+k1. In one example, the slots may be PSSCH / PSCCH slots, and the Tx WTRU may begin sending PSSCH / PSCCH transmissions in the slots during the COT 310. For example, the Tx WTRU may send PSSCH / PSCCH transmissions 340 and PSSCH / PSCCH transmissions 360 in the COT 310.

[0114] Additionally or alternatively, the Tx WTRU may use a MAC control element (CE) to report the LBT results and the initiated COT characteristics. For example, a new BSR may be used by the Tx WTRU to report the initiated COT characteristics. When reporting the Tx WTRU initiated COT characteristics, the Tx WTRU may indicate to the base station one or more of the following information: COT start time, expected number of transmissions in the COT, reserved subchannels / interlaces within the initiated COT, COT sharing recommendations to the base station, candidate WTRUs, and whether the Tx WTRU is sharing the COT with another WTRU.

[0115] like Figure 3 As shown, in an example solution where the COT start time is indicated by the Tx WTRU, the Tx WTRU may be configured to report time slot #n+k1. In some example solutions, the WTRU may explicitly report the COT start time using a UCI code point that is mapped to a preconfigured set of slot offsets relative to a reference time slot. Figure 3As shown, the reference time slot may be the time slot in which the DCI is scheduled to be received by the Tx WTRU or the start of the time window for initiating COT. Figure 3 As shown, the Tx WTRU may be configured to send a PUCCH / UCI carrying a timeslot offset at a fixed time after the end of the time window for initiating COT. For example, the Tx WTRU may send a PUCCH / UCI carrying a timeslot offset during COT 310. In one example, the DCI scheduling the sidelink grant may indicate the PUCCH time for reporting the COT start time.

[0116] In another example solution, the Tx WTRU may implicitly report the COT start time using the PUCCH / UCI reporting time. For example, the Tx WTRU may be configured to send the PUCCH / UCI after a fixed time offset relative to the COT start time. This offset may be configured by the base station or fixed in the specification based on the capabilities of the Tx WTRU.

[0117] In some example solutions where the expected number of transmissions in the COT is indicated, the Tx WTRU may determine how many time slots it will use for sidelink transmissions depending on the acquisition time of the COT. For example, if the Tx WTRU acquires the channel at the end of the configured time window for starting the COT, the Tx WTRU may not have enough time slots to share with other WTRUs.

[0118] In some example solutions to reserve subchannels / interlaces within the initiated COT, the Tx WTRU may reserve a set of subchannels / interlaces within its initiated COT that cannot be shared by other sidelink WTRUs. The Tx WTRU may then report the reserved interlace / subchannel indices.

[0119] In some example solutions where a COT sharing proposal is indicated to a base station, the Tx WTRU may indicate to the base station a set of time slots within its COT that may be shared with other sidelink WTRUs. For example, the Tx WTRU may indicate available time slots for sharing.

[0120] In some example solutions where candidate WTRUs are indicated, the Tx WTRU may report a set of candidate WTRUs that may share the COT. The Tx WTRU may determine the candidate WTRUs based on a WTRU discovery procedure in a sidelink channel.

[0121] In some example solutions where the Tx WTRU indicates whether the Tx WTRU is sharing the COT with another WTRU, the Tx WTRU may determine that the other WTRU needs to use the COT and decide to share the COT it initiated and report this information to the base station. For example, the Tx WTRU may decide to share the COT with the receiving WTRU and report this information to the base station. The Tx WTRU may further exclude resources that are planned to be shared with the receiving WTRU from the available time slots when reporting to the base station.

[0122] In some example solutions, the Tx WTRU may receive sharing information / confirmation of its own COT from the base station. The base station verifies the COT sharing proposal from the Tx WTRU or indicates new COT sharing information about the COT initiated by the Tx WTRU. In some example solutions, the Tx WTRU may be configured to receive a group-common DCI indicating COT sharing information about the COT initiated by it. The group-common DCI may indicate a set of time slots within the COT that can be used for sidelink data transmission. For example, the time slots may be used for PSSCH transmission. In other examples, the Tx WTRU may receive a WTRU-specific DCI that verifies the COT sharing proposal from the Tx WTRU.

[0123] In the examples provided herein, the Tx WTRU may broadcast its COT structure information in a sidelink unlicensed channel. In some example solutions, the Tx WTRU may be configured to send its initiated COT structure to other sidelink unlicensed WTRUs. The Tx WTRU may use a new sidelink control information (SCI) format to send the COT structure. Such an SCI may be specific to a certain WTRU with a certain destination identity (ID), for example, or a group-common SCI may be specific to a WTRU group. The Tx WTRU may use the broadcast ID as the destination ID in the SCI to send the COT structure it initiated. In some example solutions, the Tx WTRU may send the COT structure in a sidelink unlicensed channel only after verification / confirmation of the COT shared information is received by the base station. In one example, the Tx WTRU may receive verification / confirmation of the COT shared information after sending the COT shared information to the base station. As described above, such confirmation / verification may be sent using a group-common DCI or a WTRU-specific DCI. In other example solutions, the Tx WTRU may send a COT structure indication in the sidelink unlicensed channel without waiting for verification / confirmation of the COT sharing information to be received by the base station.

[0124] The COT structure indication sent by the Tx WTRU may include a set of time slots reserved for the Tx WTRU (e.g., the initiator of the COT) and a set of time slots that may be shared by other Tx WTRUs. For example, a bitmap having a size of the COT duration and a value equal to one (1) for indicating sharable time slots and a value equal to zero (0) for indicating reserved time slots. The COT duration may be indicated in addition to the bitmap. In other examples, the sidelink WTRU may be preconfigured with possible COT durations and structures, and the WTRU may use a code point in the COT structure indication to indicate one of the preconfigured values.

[0125] The COT structure may also include the priorities of the sidelink transmissions that may be used in the COT. For example, the Tx WTRU may indicate that only sidelink transmissions with a priority greater than or equal to the indicated priority may be used in the shared COT. The COT structure indication may also include the start time of the COT, the bandwidth portion, subband, and / or set of RBs and resource pools that may be used during the COT. The COT structure indication may include a set of reserved frequency resources, such as a set of subchannels and / or interlaces, for the Tx WTRU initiating the COT.

[0126] In some example solutions, the base station may send a COT structure of a COT initiated by a Tx WTRU to the sidelink WTRU. The sidelink WTRU may use the Uu link to receive a COT structure indication from the base station, which may contain information described elsewhere herein. The Tx WTRU may receive a group common DCI or a WTRU specific DCI from the base station that may indicate the COT structure information.

[0127] In some embodiments and examples, the base station (or gNB) may share a COT initiated by another Tx WTRU with the Tx WTRU. Specifically, in some examples, the Tx WTRU may be instructed by the base station to use a shared COT initiated by another Tx WTRU to transmit on a sidelink unlicensed channel. In some example solutions, the Tx WTRU may request a sidelink transmission within a specific COT detected by the Tx WTRU. For example, the Tx WTRU may detect an SCI indicating a COT structure initiated by other WTRUs. The TxWTRU may report all detected COTs to the base station and wait for base station scheduling. The set of COTs initiated by other WTRUs may be indexed based on the WTRU ID of the WTRU initiating the COT. In one example, the COT index is equal to the WTRUID that is initiating the COT. The Tx WTRU may indicate a preferred COT when reporting a set of detected COTs to the base station. The Tx WTRU may select a preferred COT based on its expected sidelink transmission characteristics. For example, the expected sidelink transmission characteristics may include one or more of a subband, a start time, a transmission duration, and a transmission duration. For example, the Tx WTRU may select a preferred COT based on a priority indicated for the COT, such as the priority described in the COT structure transmission described elsewhere herein. The base station may then schedule the Tx WTRU with the sidelink resources belonging to the requested COT. The base station may indicate the COT ID / index in the DCI that schedules the sidelink unlicensed grant (which may be referred to as the scheduled COT).

[0128] In some example solutions, the Tx WTRU may be requested by the base station to determine whether a scheduled COT has been initiated to be able to transmit on the COT. The Tx WTRU may be configured to decode the SCI sent by the WTRU that initiates the COT to verify that the scheduled COT from the base station corresponds to one of the detected COTs. The SCI sent by the WTRU that initiates the COT may carry COT identification information such as the COT ID. The WTRU may use the COT ID of the COT initiator and the WTRU ID to determine which COT is scheduled by the base station. In other example solutions, the WTRU may be configured to verify the COT based on the reference signal received power (RSRP) of the received SCI sent by the WTRU that initiates the COT. For example, if the RSRP of the PSCCH transmission is higher than the configured threshold, the WTRU may determine that the detected COT is a COT scheduled by the base station.

[0129] In some example solutions, the Tx WTRU may be configured to perform a short LBT before transmitting on the shared COT. For example, the Tx WTRU may perform a short duration LBT of 16 microseconds before transmitting on the shared COT. The Tx WTRU may be indicated using DCI with the type of LBT and channel access priority category to be used for sidelink transmission. A bit field in the scheduling DCI may indicate the LBT type and / or channel access priority. A new DCI format may be introduced to support such indications. Additionally or alternatively, existing bit fields may be reinterpreted differently. For example, the HARQ process ID bit field may be reused to indicate the LBT type and channel access priority category.

[0130] In some example solutions, the Tx WTRU may be configured to report to the base station whether COT sharing is successful. For example, the Tx WTRU may report to the base station whether the Tx WTRU is able to detect a COT with the same COT ID as the scheduled COT. The Tx WTRU may be configured with one or more PUCCH resources for indicating the COT sharing status to the base station. In some example solutions, the Tx WTRU may report to the base station whether a short LBT before transmission is successful.

[0131] The embodiments and examples provided herein include a temporary COT structure. In each example, the COT structure may include a set of time slots and symbols for sidelink transmissions (including time slots for sidelink data transmissions and time slots for sidelink HARQ feedback transmissions), a set of time slots and symbols for uplink transmissions, and a set of time slots and symbols for downlink transmissions. The COT structure may also include time domain resources reserved for the WTRU initiating the COT and time domain resources that can be shared with other sidelink WTRUs. In each example, the time domain resources may be a set of time slots, a set of symbols, or both.

[0132] A COT structure may be characterized by a length that may have a maximum duration equal to the duration of the COT. A temporary COT structure may be defined as a COT structure whose duration is less than the total duration of the COT. In some example solutions, the WTRU may use a temporary COT structure before receiving a COT structure configuration from a base station. The WTRU may be preconfigured with a temporary COT structure that may be used after initiating the COT. For example, the WTRU may be preconfigured with temporary COT structures having different lengths. The WTRU may select one of the preconfigured temporary COT structures based on any one or any combination of the following: the time for LBT to succeed, the expected time to receive the COT structure configuration from the base station (or gNB), the processing time required for the WTRU to process the COT structure configuration from the base station (or gNB), or the resource pool configuration of the sidelink channel.

[0133] In one example, the WTRU may select one of the preconfigured temporary COT structures based on the time when the LBT was successful, which in one example may be considered to be based on the time to acquire the channel. The WTRU may be configured with a time window for performing LBT and for transmitting on the sidelink unlicensed channel. When acquiring the channel, the WTRU may select the temporary COT structure length depending on the remaining time window configured for transmission.

[0134] In another example, the WTRU may select one of the preconfigured temporary COT structures based on the expected time to receive the COT structure configuration from the base station (or gNB). For example, if the WTRU expects to receive the COT structure configuration from the base station soon, the WTRU may select a short temporary COT structure. The WTRU may select a temporary COT structure that ends immediately before receiving the COT configuration from the base station.

[0135] In an additional example, the WTRU may select one of the preconfigured temporary COT structures based on the processing time required for the WTRU to process the COT structure configuration from the base station (or gNB). For example, the WTRU may need one time slot to process the DCI sent by the base station to configure the COT structure. The WTRU may be expecting DCI to configure the COT structure in time slot n. The WTRU may select a temporary COT structure that ends in time slot n+1.

[0136] In another example, the WTRU may select one of the preconfigured temporary COT structures based on the resource pool configuration of the sidelink channel. For example, the resource pool configuration may indicate a set of time slots for sidelink transmission and time slots for uplink transmission. Based on the time when LBT is successful, the WTRU may determine which time slots are used for sidelink transmission within the COT duration.

[0137] The temporary COT structure may be configured using a system information block (SIB) message, RRC configuration, or fixed in the specification. In other example solutions, the WTRU may determine a temporary COT structure that is different from the pre-configured temporary structure.

[0138] In some example solutions, if the WTRU does not receive a COT configuration from the gNB, the WTRU may continue to use the temporary COT structure for the entire duration of the COT. For example, the WTRU may report a preferred COT configuration to the base station after initiating a COT in a sidelink unlicensed channel and start using the temporary COT structure starting from the preconfigured temporary COT structure. The WTRU may monitor the COT configuration from the base station and may not receive any COT configuration from the base station. In this case, the WTRU may continue to use the temporary COT structure for the entire duration of the initiated COT. The duration of the initiated COT may be the maximum COT duration allowed by regulation.

[0139] Additionally or alternatively, if the WTRU does not receive a COT configuration from the base station, the WTRU may be configured to stop transmitting on the sidelink unlicensed channel. The WTRU may use the sidelink unlicensed channel only before the expected time of receiving the COT configuration from the base station.

[0140] This document provides implementations and examples for efficient base station (or gNB) scheduling for Mode 1 SLU. The examples herein include efficient SLU grant scheduling.

[0141] Examples herein include multi-slot scheduling for SLU. In some example solutions, the sidelink Tx WTRU may be configured with multiple TBs for transmission on a sidelink unlicensed channel within the COT. The Tx WTRU may be configured with continuous sidelink TBs or alternatively non-continuous sidelink transmissions. For example, the Tx WTRU may receive a DCI indicating time domain resource allocations for multiple sidelink TBs from a gNB or a base station. The time domain resource allocation may indicate the number of sidelink TBs. In some example solutions, the Tx WTRU may indicate from the base station whether the sidelink TBs will be transmitted continuously. If the base station indicates non-continuous sidelink TB transmissions, the base station may further provide gaps between each sidelink TB transmission. In other example solutions, the TxWTRU may autonomously decide whether to transmit the scheduled sidelink TBs continuously or non-continuously. The Tx WTRU may decide to transmit the sidelink TBs continuously or non-continuously within the COT based on one or more of the following: expected sidelink HARQ feedback from the receiving WTRU, COT structure, and / or COT duration.

[0142] In an example where the Tx WTRU decides whether to continuously send a sidelink TB based on expected sidelink HARQ feedback from the receiving WTRU, the Tx WTRU may need to send a sidelink HARQ feedback immediately after a sidelink TB transmission for a waiting time requirement by the receiving WTRU. In this case, the Tx WTRU may send a sidelink TB and wait for the sidelink HARQ before sending a second sidelink TB. In other example solutions, the Tx WTRU may disable the sidelink HARQ for the sidelink TB transmissions. In this case, the Tx WTRU may continuously send the scheduled sidelink TBs.

[0143] In an example where the Tx WTRU decides whether to send sidelink TBs consecutively based on a COT structure, the WTRU may receive a COT structure indication from a base station along with a plurality of sidelink TB transmissions. The COT structure may include transmissions in different directions: sidelink transmissions, UL transmissions, or DL ​​transmissions. The Tx WTRU may determine the number of consecutive sidelink TBs based on consecutive time slots used for sidelink transmissions in the COT structure.

[0144] In one example, the Tx WTRU decides whether to continuously transmit the sidelink TBs based on the COT duration. For example, the Tx WTRU may initiate a COT with a maximum COT duration that does not have enough time for the gap between different sidelink TB transmissions.

[0145] In some examples, the WTRU may be configured with a flexible SLU grant. In some example solutions, the WTRU may be configured with a sidelink grant that is not associated with a HARQ process ID. For example, the WTRU may receive a DCI that schedules a sidelink grant using a HARQ process ID value that points to a reserved HARQ process value. In other example solutions, the sidelink grant may be scheduled by a new DCI format without a HARQ process ID bit field. In the event that no HARQ process ID is associated with the scheduled sidelink grant, the WTRU may be configured to not send sidelink HARQ-ACK feedback for the scheduled sidelink transmission to the gNB or base station. Instead of reporting the sidelink HARQ-ACK value to the base station, the WTRU may be configured to report a new sidelink scheduling request (SR) when a negative ACK (NACK) value is received by the receiving WTRU or the Tx WTRU fails to access the channel due to LBT failure.

[0146] In some example solutions, the WTRU may be configured with PUCCH resources for sending such SRs. The DCI that schedules the sidelink grant may utilize the PUCCH-SR resources to configure the WTRU to send requests for new sidelink resources as needed. The WTRU may not send a PUCCH-SR if the sidelink is not successfully granted for transmission. For example, the WTRU may not send a PUCCH-SR if an ACK value is received from a receiving WTRU. The base station may detect the presence / absence of the PUCCH-SR and schedule the WTRU accordingly. The WTRU may be configured with a multi-state PUCCH-SR, for example, a PUCCH-SR carrying multiple states to indicate the number of grants requested. For example, multiple sidelink grants may be scheduled by different DCIs and point to the same PUCCH-SR transmission time. In the event that one or more NACK values ​​are received by the receiving WTRU or the Tx WTRU fails to access the channel due to a LBT failure on one or more sidelink grants, the WTRU may use the indicated PUCCH-SR resources to request one or more sidelink grants.

[0147] In some example solutions, the WTRU may be configured to retransmit an initial transmission using a dynamic sidelink grant using a configured sidelink grant. For example, the WTRU may receive a NACK value from a receiving WTRU and use a PUCCH-SR to report the need for a new sidelink grant to the base station. The WTRU may receive a DCI activating a configured sidelink grant and retransmit a sidelink transport block using the activated sidelink configured grant.

[0148] In some example solutions, the WTRU may be configured to maintain the initiated COT for possible retransmissions as needed. In the case of NACK reception by the Rx WTRU, the WTRU may receive an indication from the base station in the scheduling DCI whether to use the initiated COT for retransmission. Additionally or alternatively, the WTRU may receive an indication in the group common DCI whether to use the initiated COT for retransmission. If the COT is maintained by another transmission, the WTRU may be configured to use the initiated COT for sidelink retransmissions. For example, if the Tx WTRU is sharing the COT with another WTRU and the gap between different transmissions is below a configured threshold, the COT is maintained. The WTRU may determine whether its own COT is maintained based on energy detection of sidelink transmissions within the shareable time slot / subchannel / interlace of its own COT or based on decoding of other sidelink transmissions on the shareable resources of its own COT. In each example, the decoding may be one or more of SCI decoding, PSSCH decoding, or PSFCH decoding. For example, if the WTRU receives a PSFCH carrying a sidelink HARQ-ACK feedback transmission from a receiving WTRU within its COT, the WTRU may determine that its COT is maintained. In another example, if the WTRU detects energy above a configured threshold on a timeslot allocated for a shared sidelink transmission, the WTRU may determine that its COT is maintained. If the WTRU determines that its COT is lost, the WTRU may request additional resources from the base station for retransmission. In one example, the COT may be lost if it is not maintained. The WTRU may be configured to report to the base station whether the COT is maintained.

[0149] This document provides implementation schemes and example solutions for reporting sidelink unlicensed HARQ-ACK status. In some example solutions, the WTRU may be configured to report to the base station (or gNB) the SL HARQ-ACK feedback sent on the COT it initiated. The WTRU that initiates the COT may be configured to monitor all PSFCH resources associated with PSSCH resources within its COT. In one example, the WTRU that initiates the COT may be a Tx WTRU. The Tx WTRU may determine the PSFCH timing within its COT based on a predefined association between one or more PSSCHs and one or more PSFCHs. In this case, another Tx WTRU that does not share the COT is required to send sidelink HARQ-ACK feedback to the base station (or gNB). Alternatively, the Tx WTRU that initiates the COT may be responsible for forwarding the sidelink HARQ-ACK feedback to the base station (or gNB). The Tx WTRU that initiates the COT may be configured with PUCCH resources for carrying all sidelink HARQ-ACK feedback within its COT.

[0150] Figure 4is a diagram illustrating a Tx WTRU reporting to a base station on its initiated COT. As shown in the example provided in diagram 400, Tx WTRU1 420 may request a sidelink unlicensed grant from a base station (or gNB) and indicate a preference for initiating its own COT. Tx WTRU1 may receive a DCI indicating the RB set / resource pool / transmission window to be initiated in the sidelink U and the maximum COT duration. The DCI may indicate the time window for initiating the COT. Tx WTRU1 may perform a successful LBT and initiate a COT in time slot n. Tx WTRU1 may report the initiated COT characteristics to the base station or gNB using a PUCCH transmission in time slot n+offset_1 or a new UCI type piggybacked in a PUSCH transmission, where offset_1 is configured by the base station or gNB and may be set to 0 based on the capabilities of the WTRU. Tx WTRU1 may indicate its expected number of transmissions in the COT and the interlaces reserved for its own transmissions based on the COT start time and the remaining COT duration. Tx WTRU1 may indicate to the gNB a COT sharing proposal: a set of time slots and interlaces to be shared with other WTRUs (such as other Tx WTRUs). In addition, Tx WTRU1 may receive a DCI indicating a COT structure for other Tx WTRUs.

[0151] The WTRU may receive shared information / confirmation of its own COT using group common DCI in time slot n+offset_1+offset_2 by the base station or gNB. Based on the COT shared information, which may include shareable PSSCH opportunities, the WTRU may monitor the PSFCH of other WTRUs within the WTRU's COT. The WTRU may determine the PSFCH opportunities to monitor for other WTRUs based on the shared PSSCH transmission opportunities. Figure 4 In the illustrated examples, Tx WTRU2 470 may be sharing a COT. Tx WTRU1 420 may use PUCCH / PUSCH resources to report sidelink HARQ feedback corresponding to the transmission of Tx WTRU1 420 and sidelink HARQ feedback sent by other Tx WTRUs (such as Tx WTRU2 470) to the base station or gNB within the shared COT.

[0152] exist Figure 4In the example shown, Tx WTRU1 420 may transmit one or more of PSSCH / PSCCH transmission 430, PSSCH / PSCCH transmission 440, PSSCH / PSCCH transmission 450, or PSSCH / PSCCH transmission 460. The PSSCH / PSCCH transmissions use PSSCH / PSCCH resources. In one example, PSSCH / PSCCH transmission 430 and PSSCH / PSCCH transmission 440 may be associated with one or more PSFCH transmissions 445. Thus, Tx WTRU1 420 may transmit PSSCH / PSCCH transmission 430 and expect to receive sidelink HARQ feedback regarding the transmitted PSSCH / PSCCH transmission 430 in the PSFCH transmission in PSFCH transmission 445. Similarly, Tx WTRU1 420 may transmit PSSCH / PSCCH transmission 440 and expect to receive sidelink HARQ feedback regarding the transmitted PSSCH / PSCCH transmission 440 in a PSFCH transmission in PSFCH transmission 445. Transmitter WTRU1 420 may then receive this sidelink HARQ feedback. In addition, PSSCH / PSCCH transmission 450 and PSSCH / PSCCH transmission 460 may be associated with one or more PSFCH transmissions 465. Thus, Tx WTRU1 420 may transmit PSSCH / PSCCH transmission 450 and expect to receive sidelink HARQ feedback regarding the transmitted PSSCH / PSCCH transmission 450 in a PSFCH transmission in PSFCH transmission 465. Transmitter WTRU1 420 may then receive this sidelink feedback. Similarly, Tx WTRU1 420 may send a PSSCH / PSCCH transmission 460 and expect to receive sidelink HARQ feedback regarding the transmitted PSSCH / PSCCH transmission 460 in a PSFCH transmission 465. Transmitter WTRU1 420 may then receive this feedback.

[0153] In addition, Figure 4In the example shown, Tx WTRU2 470 may transmit one or more of a PSSCH / PSCCH transmission 480 or a PSSCH / PSCCH transmission 490. Additionally, the PSSCH / PSCCH transmission 480 and the PSSCH / PSCCH transmission 490 may be associated with one or more PSFCH transmissions 495. Thus, Tx WTRU2 470 may transmit the PSSCH / PSCCH transmission 480 and expect to receive sidelink HARQ feedback regarding the transmitted PSSCH / PSCCH transmission 480 in a PSFCH transmission in PSFCH transmission 495. Similarly, Tx WTRU2 470 may transmit the PSSCH / PSCCH transmission 490 and expect to receive sidelink HARQ feedback regarding the transmitted PSSCH / PSCCH transmission 490 in a PSFCH transmission in PSFCH transmission 495. Transmitter WTRU2 470 may receive this feedback in a PSFCH transmission.

[0154] In addition, as mentioned above, Figure 4 In the example shown, Tx WTRU1 420 may share its COT with Tx WTRU2 470. Therefore, Tx WTRU1 420 may determine a PSFCH opportunity to monitor for WTRU2 470 based on the shared PSSCH transmission opportunity. For example, Tx WTRU1 420 may determine to monitor a PSFCH opportunity associated with a PSSCH / PSCCH transmission 480 or a PSSCH / PSCCH transmission 490 of Tx WTRU2 470. As a result, Tx WTRU1 420 may receive sidelink HARQ feedback regarding the transmitted PSSCH / PSCCH transmission 480 in a PSFCH transmission in PSFCH transmission 495. Additionally or alternatively, WTRU1 420 may receive sidelink HARQ feedback regarding the transmitted PSSCH / PSCCH transmission 490 in a PSFCH transmission in PSFCH transmission 495. Transmitter WTRU1 420 may then report to the base station the received sidelink HARQ feedback regarding the transmission of Tx WTRU2 470. Additionally, Tx WTRU1 420 may use PUCCH / PUSCH resources to report this sidelink HARQ feedback.

[0155] Figure 5 500 is a flow chart illustrating an example of a WTRU reporting to a base station on a COT it has initiated. In the example shown in flow chart 500, the WTRU may receive a DCI 520 from a base station scheduling a sidelink grant indicating a time window for initiating a COT. In one example, the COT may be initiated in a sidelink unlicensed channel. In addition, the WTRU may perform LBT to access the sidelink unlicensed channel 530 in the unlicensed band within the indicated time window for initiating the COT.

[0156] In addition, in one example, the WTRU may initiate a COT. The COT may be initiated by the WTRU at a COT start time and the COT may last for a COT duration. In addition, the WTRU may occupy a sidelink unlicensed channel during the COT.

[0157] After a successful channel access result of the performed LBT, the WTRU may provide information about the initiated COT to the base station. In one example, the WTRU may send a UCI about the COT to the base station 540. The UCI may indicate or report the successful channel access result of the performed LBT. In addition, the UCI may indicate or report the start time of the COT within the indicated time window for initiating the COT. The UCI may be a new UCI type or a modified UCI type. In one example, the WTRU may include the characteristics of the initiated COT in the information provided to the base station. In another example, the WTRU may use PUCCH transmission to provide information about the initiated COT to the base station.

[0158] In one example, the UCI may indicate or report the expected number of transmissions by the WTRU in the COT. In another example, the UCI may indicate or report one or more reserved subchannels within the COT. In another example, the UCI may indicate or report one or more reserved interlaces within the COT. In an additional example, the UCI may indicate or report one or more reserved time slots within the COT.

[0159] In another example, the WTRU reporting on the COT it initiated may be the first WTRU. In addition, the first WTRU may determine whether to share its COT with other WTRUs. The other WTRUs may be the second WTRU. The first WTRU may make a determination based on the buffer status and the COT start time. In one example, the first WTRU may determine to share its COT with the second WTRU. The first WTRU may then also provide a COT sharing proposal to the base station. The first WTRU may then receive a COT sharing confirmation from the base station that verifies the COT sharing proposal provided by the first WTRU. In one example, the COT sharing confirmation may be received using a group common DCI.

[0160] In addition, the first WTRU may monitor one or more PSFCH transmissions of one or more second WTRUs that share a COT initiated by the first WTRU. Additionally, the first WTRU may report to the base station sidelink HARQ ACK feedback from one or more PSFCH transmissions of one or more second WTRUs that share a COT initiated by the first WTRU. In another example, the first WTRU may be a Tx WTRU. In another example, the second WTRU may be another Tx WTRU. In an alternative or additional example, the second WTRU may be or may include an Rx WTRU.

[0161] In some example solutions, the WTRU may be configured to use a HARQ-ACK codebook to report sidelink HARQ-ACK feedback sent within the COT it initiated. Such a HARQ-ACK codebook may be configured with a fixed size and may include sidelink HARQ-ACK feedback sent within the same COT. The WTRU may determine the HARQ-ACK codebook size based on the number of PSFCH time slots within the COT. The WTRU may determine the HARQ-ACK codebook size based on the COT structure indicated by the base station (or gNB). For example, after the WTRU initiates the COT and reports the LBT status to the gNB, it may receive a COT structure from the gNB using a set of time slots that can be shared with other WTRUs. Based on the number of time slots used for PSSCH transmission, the WTRU may determine the HARQ-ACK codebook size. In one example, the HARQ-ACK codebook size may be equal to the number of PSSCH time slots within the COT.

[0162] Additionally or alternatively, the WTRU may use DCI to receive the HARQ-ACK codebook size from the base station (or gNB). Such a HARQ-ACK codebook may support 3-state HARQ-ACK values. In each example, the first state indicates a NACK value, the second state indicates an ACK value, and the third state indicates that the sidelink HARQ-ACK feedback cannot be received / detected / correctly decoded. The WTRU may be configured to sort the sidelink HARQ-ACK feedback in ascending order of reception time. For example, the first value of the HARQ-ACK codebook may correspond to the first PSFCH time slot within the COT, and the last value of the HARQ-ACK codebook may correspond to the last PSFCH time slot within the COT. In other examples, the WTRU may first place the sidelink HARQ-ACK value of its own transmission and append the HARQ ACK values ​​of other sidelink transmissions.

[0163] In some example solutions, the WTRU may be configured to determine the presence of sidelink HARQ-ACK within its COT based on SCI decoding. For example, the WTRU may detect the SCI of the Tx WTRU within its COT and determine whether to enable sidelink HARQ-ACK for each transmission. In other examples, the WTRU may determine the presence of sidelink HARQ-ACK within its COT based on energy detection of PSFCH resources. For example, the WTRU may monitor the PSFCH resources corresponding to the PSSCH transmission within its COT and determine whether the detected energy is above or below a configured threshold. Upon detecting that the PSFCH is not transmitted, the WTRU may report a third state of the HARQ-ACK to the base station or gNB. For example, the WTRU may indicate that the sidelink HARQ-ACK feedback cannot be received / detected / correctly decoded.

[0164] In some example solutions, the WTRU may be configured to report / forward to the base station (gNB) the SL HARQ-ACK feedback of a subgroup of the SL HARQ feedback sent within the COT initiated by it. The WTRU may be configured to determine the subgroup of SL HARQ-ACK feedback based on any one or any combination of the following: the ID of the WTRU that sent the sidelink HARQ-ACK feedback on the COT initiated by the WTRU, the priority associated with the sidelink data corresponding to the sidelink HARQ-ACK feedback, or the QoS associated with the sidelink data corresponding to the sidelink HARQ-ACK feedback.

[0165] In one example, the WTRU may be configured to determine a subgroup of SL HARQ-ACK feedback based on the ID of the WTRU that sent the sidelink HARQ-ACK feedback on the WTRU-initiated COT. For example, the WTRU may report / forward the sidelink HARQ-ACK feedback of only a group of WTRUs. The WTRU may be configured with a WTRU ID to which the sidelink HARQ-ACK feedback may be forwarded to the base station (or gNB).

[0166] In another example, the WTRU may be configured to determine a subgroup of SL HARQ-ACK feedback based on a priority associated with the sidelink data corresponding to the sidelink HARQ-ACK feedback. If the priority of the sidelink data transmission associated with the SL HARQ-ACK feedback is higher than the configured priority, the WTRU may be configured to report / forward the sidelink HARQ-ACK feedback to the base station (or gNB). In one example, the priority of the sidelink data transmission may be a higher priority.

[0167] In another example, the WTRU may be configured to determine a subgroup of SL HARQ-ACK feedback based on the QoS associated with the sidelink data corresponding to the sidelink HARQ-ACK feedback. If the QoS of the sidelink data transmission associated with the SL HARQ-ACK feedback corresponds to one or more preconfigured QoS values, the WTRU may be configured to report / forward the sidelink HARQ-ACK feedback to the gNB.

[0168] In some example solutions, the WTRU may be configured to report / forward the SL HARQ-ACK feedback of the WTRU's expected Rx WTRU only to the base station (or gNB). For example, a Tx WTRU initiates a COT and sends to multiple Rx WTRUs and shares the COT with other Tx WTRUs. The Tx WTRU may report the SL HARQ-ACK only to the base station (or gNB) of its expected Rx WTRU. The expected Rx WTRU here may mean the Rx WTRU that receives the sidelink data from the Tx WTRU that initiated the COT.

[0169] In some example solutions, the WTRU may be configured to report SL HARQ-ACK feedback sent by other WTRUs within its COT using a separate HARQ-ACK codebook. The size of the HARQ-ACK codebook may be determined based on the number of PSFCH opportunities within the COT initiated by the WTRU. Additionally or alternatively, the size may be indicated to the WTRU by the base station (or gNB). For example, the DCI configuring the COT structure may indicate the size of the HARQ-ACK codebook for the SL HARQ-ACK of other WTRUs. The WTRU may determine the size of the HARQ codebook using the subgroups identified above.

[0170] In some example solutions, the WTRU may be configured to report delayed sidelink HARQ-ACK values ​​to the gNB when it fails to share its COT with the Rx WTRU to send sidelink HARQ-ACK feedback. For example, the Tx WTRU may be configured with a single slot or multiple slots for sidelink unlicensed transmission from the base station or gNB.

[0171] Figure 6600 is a diagram illustrating a Tx WTRU reporting a delayed sidelink HARQ-ACK to a base station. The Tx WTRU may transmit on a scheduled grant when LBT is successful as shown in the example of diagram 600. For example, the Tx WTRU may receive a time window for initiating a COT. In addition, the Tx WTRU may transmit one or more of a PSSCH / PSCCH transmission 630, a PSSCH / PSCCH transmission 640, a PSSCH / PSCCH transmission 650, or a PSSCH / PSCCH transmission 660 in a COT 610 initiated by the Tx WTRU.

[0172] Based on its expected number of transmissions (e.g., buffer status) and the start of the transmission (COT start time), the Tx WTRU may determine whether it will share the COT with the Rx WTRU 610. If the Tx WTRU does not share its COT with the Rx WTRU for sending sidelink HARQ-ACK feedback, the WTRU may report the delayed sidelink HARQ-ACK feedback value to the base station (or gNB).

[0173] The WTRU may determine whether to share its COT with the Rx WTRU based on the available time slots for PSFCH within its own COT. For example, the WTRU may be configured with a resource pool for initiating a COT. The resource pool may have a time slot configuration indicating which time slot is used for PSSCH transmission and which transmission is for PSFCH transmission. Upon successfully initiating a COT, the WTRU may determine that no PSFCH time slots are available for PSFCH transmission within its COT duration. The WTRU then does not share its COT with the Rx WTRU to send sidelink HARQ-ACK feedback.

[0174] Additionally, in one example, the Tx WTRU may determine that sidelink feedback from the Rx WTRU is not available. In one example, feedback may not be available due to a short amount of time between a PSSCH / PSCCH transmission and an associated PSFCH transmission. For example, the Tx WTRU may send a PSSCH / PSCCH transmission 630. However, the PSFCH transmission received in the PFSCH transmission 635 will not include feedback from the PSSCH / PSCCH transmission 630 because there will not be enough time for the Rx WTRU to receive the PSSCH / PSCCH transmission 630 and then generate corresponding feedback. As a result, the Tx WTRU may send information on a PUCCH transmission indicating that sidelink feedback is not available.

[0175] In some example solutions, the Tx WTRU may be configured to determine whether to share its COT with the Rx WTRU for sidelink HARQ-ACK transmission based on the sidelink TB priority and / or packet delay budget (PDB) of the sidelink transmission. For example, the Tx WTRU may prioritize the sidelink HARQ-ACK feedback over the new sidelink TB transmission in the COT that is then initiated. The Tx WTRU may use SCI signaling to indicate this prioritization to the Rx WTRU. For example, a bit field in the SCI may indicate to the Rx WTRU whether to use the current COT or a different COT for the sidelink HARQ-ACK transmission. In the case where the sidelink HARQ-ACK is prioritized, the RxWTRU may use one of the time slots within the COT to send the HARQ-ACK feedback. The Rx WTRU may determine the time slot in which the feedback is to be transmitted based on a preconfigured time slot offset between the PSSCH and the PSFCH. Additionally or alternatively, the Tx WTRU may indicate to the RxWTRU the time slot in which the feedback is to be transmitted. In some examples, the Rx WTRU may report HARQ-ACK for a set of HARQ processes to the Tx WTRU if LBT fails and / or cannot share COT.

[0176] In some example solutions, the Tx WTRU may be configured to report an estimated time for a sidelink HARQ transmission when reporting delayed sidelink HARQ-ACK feedback. The WTRU may be preconfigured with multiple possible estimated values ​​and indicate one of the preconfigured values. The WTRU may determine the estimated time for the sidelink HARQ transmission based on the available sidelink unlicensed grants and the expected future COT sharing of the WTRU in subsequent time slots. For example, the WTRU is expecting to initiate a COT to transmit on an assigned sidelink unlicensed grant. The WTRU may then report the estimated time based on the estimated COT structure of the next sidelink unlicensed grant.

[0177] In some example solutions, the Tx WTRU may be configured to monitor for new PUCCH resource assignments after reporting delayed sidelink HARQ-ACK values ​​to the base station or gNB. For example, when reporting delayed sidelink HARQ feedback to the base station or gNB, the Tx WTRU may receive a DCI indicating new PUCCH resources to confirm the sidelink HARQ-ACK transmission at a later opportunity. The Tx WTRU may then send the delayed sidelink HARQ feedback in the new PUCCH opportunity. In other examples, the Tx WTRU may receive a one-time HARQ-ACK trigger to report HARQ feedback for a group or all sidelink unlicensed grants.

[0178] In some example solutions, the Tx WTRU may be configured to report a delayed sidelink HARQ-ACK value to the base station or gNB when it fails to receive the sidelink HARQ-ACK feedback from the Rx WTRU. For example, the Tx WTRU may not share the COT with the Rx WTRU, but the Tx WTRU may know that the Rx WTRU is configured with a subsequent grant on which the sidelink HARQ-ACK may be sent. In this case, the Tx WTRU may report the delayed sidelink HARQ-ACK feedback to the base station or gNB.

[0179] In some example solutions, the WTRU may be configured to flush the HARQ-ACK buffer corresponding to the sidelink unlicensed transmission when the PDB expires. In this case, the WTRU may indicate the ACK value to the base station or gNB when flushing the HARQ-ACK buffer.

[0180] In some example solutions, the WTRU may be configured to group a set of sidelink HARQ-ACK feedback in the same HARQ codebook to be reported to the base station or gNB simultaneously. In some example solutions, the WTRU may be configured to group the sidelink HARQ-ACK based on the WTRU destination ID. For example, the WTRU may group the sidelink HARQ-ACKs of the same WTRU destination ID in the same group. In other examples, the WTRU may group the sidelink HARQ-ACKs of a range of WTRU destination IDs in the same group. In other example solutions, the WTRU may be configured with an association between a HARQ codebook / group and a set of sidelink HARQ-ACK processes. The base station or gNB may use DCI to request the transmission of one or more HARQ codebooks / groups. In other examples, the base station or gNB may configure the WTRU by HARQ grouping based on the BSR report and the priority of the reported BSR. For example, some WTRU destination IDs may have a higher priority. When reporting the sidelink HARQ group, the WTRU may indicate the HARQ group ID along with the HARQ group feedback.

[0181] In some example solutions, when reporting HARQ groups to the base station or gNB, the WTRU may be configured to prioritize between different sidelink HARQ groups. For example, the WTRU may prioritize based on the destination ID of one or more WTRUs in the HARQ group.

[0182] In some example solutions, the Rx WTRU may prioritize between multiple PSFCH transmissions to different Tx WTRUs based on whether the COT was initiated by the Tx WTRU and whether it is being shared with the Rx WTRU. For example, the Rx WTRU may receive two PSSCH transmissions from two different WTRUs, such as, for example, Tx WTRU1 and Tx WTRU2, where Tx WTRU1 shares its COT with the Rx WTRU, while Tx WTRU2 does not share a COT and indicates that a different COT was initiated for the sidelink HARQ transmission. The Rx WTRU may prioritize the PSFCH transmission to Tx WTRU1. In some example solutions, the priority of the sidelink HARQ feedback may increase after each missed PSFCH transmission.

[0183] The examples provided herein include additional HARQ-ACK feedback opportunities. An Rx WTRU having HARQ feedback to send may initiate a COT to send the feedback. For example, the Rx WTRU may have one or more resources in which the Rx WTRU may send feedback to the Tx WTRU. In one example, the one or more resources may be one or more periodic resources. If the Rx WTRU may initiate a COT before the HARQ-ACK feedback resources, it may send HARQ feedback to at least one Tx WTRU. The Rx WTRU may have one or more or a group of HARQ-ACK feedback resources associated with each transmission from one or more Tx WTRUs.

[0184] If the HARQ-ACK feedback is valid, the Rx WTRU may attempt to initiate a COT before at least one HARQ-ACK feedback resource. The Rx WTRU may determine whether the HARQ-ACK feedback is valid based on at least one of the following: the PDB of the sidelink TB, an indication from the Tx WTRU, a maximum number of feedback attempts, configuration information such as from the base station or from the gNB, or a priority of the feedback.

[0185] The Rx WTRU may monitor the channel for an indication from the Tx WTRU that the Tx WTRU has initiated a COT for RxWTRU transmission of HARQ-ACK feedback. For example, if the Rx WTRU fails to initiate a COT for transmission of HARQ-ACK feedback, the RxWTRU may monitor for an indication that the Tx WTRU has initiated a COT in which the Rx WTRU may report HARQ-ACK feedback. The Rx WTRU may determine what HARQ-ACK feedback to report based on at least one of: an indication from the Tx WTRU, the identity of the WTRU that initiated the COT, the timing of the COT, the priority of the feedback, the timing of the feedback resources within the COT, and / or the validity of the HARQ-ACK feedback.

[0186] The Tx WTRU may be triggered to initiate a COT for the purpose of sharing the COT with one or more Rx WTRUs for transmission of HARQ-ACK feedback. For example, if the Tx WTRU determines that the Rx WTRU has not yet been able to initiate a COT for transmission of HARQ-ACK feedback, the Tx WTRU may be triggered to initiate a COT. In other examples, the Tx WTRU may be triggered by signaling from the base station or gNB to initiate a COT for the purpose of sharing the COT with one or more Rx WTRUs.

[0187] A Tx WTRU initiating a COT for the purpose of sharing with one or more Rx WTRUs may indicate that the COT may be used for transmission of HARQ-ACK feedback. The indication may be included in one or more of a PSSCH transmission, an SCI, or a PUSCH transmission. The indication may be implicitly sent via a SL reference signal (RS) or a SL synchronization signal (SS) / SS block (SSB) transmission.

[0188] The Tx WTRU may indicate to the Rx WTRU that they may share the COT for transmission of HARQ-ACK feedback. The Tx WTRU may indicate the set of HARQ processes for which it expects HARQ-ACK feedback. The set of HARQ processes may be indicated as a set.

[0189] Embodiments and examples of the measurement and reporting of SLU auxiliary information are provided herein. In some example solutions, the WTRU may be configured to report auxiliary information to the base station (or gNB) to help distinguish the situation of a congested resource pool due to one or more other side link transmissions or another unlicensed transmission such as WiFi. The WTRU may be configured with a set of time windows. Each window may potentially correspond to a COT initiated by the WTRU itself or by another WTRU. In some example solutions, for each set of time windows / COTs, the WTRU may be configured to measure the ratio of subchannels where the received signal strength indicator (RSSI) or RSRP exceeds a preconfigured threshold. The WTRU may then report a set of ratios corresponding to each COT / time window to the base station (or gNB). In other example solutions, the WTRU may be configured to measure the ratio of subchannels where the RSSI or RSSP exceeds a preconfigured threshold outside the COT and inside the COT, and may report the difference between the ratio measured outside the COT and the ratio measured inside the COT for each COT. In other example solutions, for each set of time windows / COTs, the WTRU may be configured to measure the number of subchannels used by the WTRU. In other example solutions, the WTRU may be configured to report the above measurement results only when one or more of the following conditions are met: the number of LBT failures of the WTRU is higher than the configured threshold within the preconfigured time window, and / or the number of LBT successes of the WTRU is lower than the configured threshold within the preconfigured time window.

[0190] In some example solutions, the WTRU may be configured to perform some measurements to distinguish between half-duplex and channel access failures. The WTRU may be configured to then report to the base station or gNB the ratio of the number of half-duplex problem occurrences to the number of channel access failures over a configured time window. In one example, the number of channel access failures may be or may include the number of LBT failures. If the ratio is above or below a configured threshold, the WTRU may trigger such a report. The WTRU may use one or more of RRC signaling, MACCE, or UCI to send the ratio. In some example solutions, if the measured ratio is above or below a configured threshold, the WTRU may be configured to use a different bandwidth part (BWP) / subband / RB set / resource pool. The WTRU may then indicate the BWP / subband / RB set / resource pool change to other WTRUs. For example, the Rx WTRU may indicate the change of BWP / subband / RB set / resource pool to the Tx WTRU.

[0191] The methods and procedures in the embodiments and examples described herein may be performed by one or more of a processor, an integrated circuit, a network node, a relay node, a base station, an AP, a STA, a vehicle, or a drone. In addition, it will be understood by those skilled in the art that the embodiments and examples described herein include devices for performing the methods and procedures described herein or devices configured to perform the methods and procedures described herein.

[0192] Although features and elements are described above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (sent via a wired or wireless connection), non-transitory storage media, and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a first wireless transmit / receive unit (WTRU), the method comprising: receiving downlink control information (DCI) scheduling a sidelink grant from a base station, wherein the sidelink grant indicates a time window for initiating a channel occupancy time (COT); performing listen-before-talk (LBT) to access a sidelink unlicensed channel in an unlicensed frequency band within the indicated time window for initiating the COT; as well as After a successful channel access result of the performed LBT, uplink control information (UCI) is sent to the base station, wherein the UCI indicates the successful channel access result and a COT start time within the indicated time window for initiating the COT.

2. The method of claim 1 , wherein the UCI further indicates an expected number of transmissions by the first WTRU in the COT. The method of claim 1 , wherein the UCI further indicates one or more reserved subchannels within the COT. The method of claim 1 , wherein the UCI further indicates one or more reserved interlaces within the COT.

5. The method according to claim 1, further comprising: determining, based on a buffer status and the COT start time, whether the first WTRU will share the COT; as well as Based on determining that the COT is to be shared, a COT sharing suggestion is provided to the base station.

6. The method according to claim 5, further comprising: A COT sharing confirmation is received verifying the COT sharing proposal provided by the first WTRU.

7. The method according to claim 1, further comprising: The COT is initiated, wherein the COT is initiated at the COT start time and lasts for a COT duration, and wherein the first WTRU occupies the sidelink unlicensed channel during the COT.

8. The method according to claim 7, further comprising: Monitoring one or more physical sidelink feedback channel (PSFCH) transmissions of one or more second WTRUs sharing the COT initiated by the first WTRU.

9. The method according to claim 8, further comprising: Sidelink hybrid automatic repeat request (HARQ) acknowledgement (ACK) feedback of the one or more PSFCH transmissions from the one or more second WTRUs sharing the COT initiated by the first WTRU is reported to the base station.

10. The method of claim 1, wherein the first WTRU is a transmitter (Tx) WTRU.

11. A first wireless transmit / receive unit (WTRU), the first wireless transmit / receive unit (WTRU) comprising: Transceiver; and a processor operatively coupled to the transceiver; wherein: The transceiver is configured to receive downlink control information (DCI) scheduling a sidelink grant from a base station, wherein the sidelink grant indicates a time window for initiating a channel occupancy time (COT); The transceiver and the processor are configured to perform listen-before-talk (LBT) to access a sidelink unlicensed channel in an unlicensed band within an indicated time window for initiating the COT; and The transceiver and the processor are configured to send uplink control information (UCI) to the base station after a successful channel access result of the performed LBT, wherein the UCI indicates the successful channel access result and a COT start time within the indicated time window for initiating the COT.

12. The first WTRU of claim 11, wherein the UCI further indicates an expected number of transmissions by the first WTRU in the COT.

13. The first WTRU of claim 11, wherein the UCI further indicates one or more reserved sub-channels within the COT.

14. The first WTRU of claim 11, wherein the UCI further indicates one or more reserved interlaces within the COT.

15. The first WTRU of claim 11, wherein the processor is further configured to determine whether the first WTRU will share the COT based on a buffer status and the COT start time; and wherein the transceiver and the processor are further configured to provide a COT sharing recommendation to the base station based on determining that the COT is to be shared.

16. The first WTRU of claim 15, wherein the transceiver is further configured to receive a COT sharing confirmation validating the COT sharing proposal provided by the first WTRU.

17. The first WTRU of claim 11, wherein the transceiver and the processor are further configured to initiate the COT, wherein the COT is initiated at the COT start time and lasts for a COT duration, and wherein the first WTRU occupies the sidelink unlicensed channel during the COT.

18. The first WTRU of claim 17, wherein the transceiver and the processor are further configured to monitor one or more physical sidelink feedback channel (PSFCH) transmissions of one or more second WTRUs that share the COT initiated by the first WTRU.

19. A first WTRU according to claim 18, wherein the transceiver and the processor are configured to report to the base station sidelink hybrid automatic repeat request (HARQ) acknowledgment (ACK) feedback of the one or more PSFCH transmissions from the one or more second WTRUs sharing the COT initiated by the first WTRU.

20. The first WTRU of claim 11, wherein the first WTRU is a transmitter (Tx) WTRU.

Images