New Radio (NR) Vehicle-to-Vehicle (V2X)-Method for Scheduling Sidelink in Unlicensed Spectrum

Abstract

A method and apparatus are disclosed for scheduling sidelink communications in an unlicensed spectrum. The method performed by a first wireless transmit / receive unit (WTRU) may include obtaining a permission for transmission on a sidelink (SL), receiving a transmission from a second or additional WTRU including first channel occupation time (COT) information, determining cast information from the transmission received from the second WTRU, the additional WTRU, or both the second WTRU and the additional WTRU, provided that the permission is for transmitting on the SL during a COT associated with the second WTRU or the additional WTRU, performing a listen-before-talk (LBT) procedure using a set of parameters associated with the information received from the second WTRU or the additional WTRU, and, provided that the LBT procedure is successful, transmitting data including the second COT information based on the determined cast information.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 257,381, filed October 19, 2021, U.S. Provisional Patent Application No. 63 / 326,401, filed April 1, 2022, and U.S. Provisional Patent Application No. 63 / 353,939, filed June 21, 2022, the contents of which are incorporated herein by reference. [Background technology]

[0002] Vehicle communication is a mode of communication in which vehicles may communicate directly with each other. One scenario of vehicle to everything (V2X) operation is an in-coverage scenario, where the WTRU may receive assistance from the network and begin transmitting and receiving V2X messages. Another scenario of V2X operation is an out-of-coverage scenario, where the WTRU may begin transmitting and receiving V2X messages using one or more pre-configured parameters.

[0003] V2X communication is supported in LTE and was inspired by previous work on device-to-device (D2D) communication. V2X communication services may consist of various types, including vehicle to vehicle (V2V), where vehicular WTRUs may communicate directly with each other, vehicle to infrastructure (V2I), where vehicular WTRUs may communicate with an RSU / eNB, vehicle to network (V2N), where vehicular WTRUs may communicate with a core network, and vehicle to pedestrian (V2P), where vehicular WTRUs may communicate with a WTRU in special conditions (e.g., low battery capacity). Summary of the Invention

[0004] A method and apparatus are disclosed for scheduling sidelink communications in an unlicensed spectrum. The method performed by a first wireless transmit / receive unit (WTRU) may include obtaining a permission for transmission on a sidelink (SL), receiving a transmission from a second or additional WTRU including first channel occupation time (COT) information, determining cast information from the transmission received from the second WTRU, the additional WTRU, or both the second WTRU and the additional WTRU, provided that the permission is for transmitting on the SL during a COT associated with the second WTRU or the additional WTRU, performing a listen-before-talk (LBT) procedure using a set of parameters associated with the information received from the second WTRU or the additional WTRU, and, provided that the LBT procedure is successful, transmitting data including the second COT information based on the determined cast information.

[0005] The grant may be obtained from a base station. The grant may be obtained via the first WTRU selecting a grant. The casting information may indicate a unicast casting type or a groupcast casting type. The received information may be the first COT information or casting information. The set of parameters may be associated with information received from the second or third WTRU including a transmission priority. The set of parameters may be associated with information received from the second or third WTRU including an indirection number. The indirection number may be received from the second or additional WTRU via a sidelink control information (SCI) transmission. [Brief description of the drawings]

[0006] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numbers indicate similar elements and in which: [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B]1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system shown in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Diagram 2] FIG. 13 illustrates an example of unicast COT sharing. [Diagram 3] FIG. 13 is a diagram showing an example of groupcast / broadcast COT sharing. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0008] 1A, communications 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, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of 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 transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, landline or mobile subscriber units, subscription-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain contexts), home electronic devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0009] The communications 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 communications 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 eNodeB (eNodeB, eNB), a next generation Node B such as a Home Node B, Home eNodeB, gNodeB (gNodeB, gNB), a new radio (NR) Node B, a site controller, an access point (AP), a wireless router, etc. Although 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.

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

[0011] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via 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).

[0012] More specifically, as noted above, the communications system 100 may be a multiple access system and may use one or more channel access schemes, such as, for example, CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and the WTRUs 102a, 102b, 102c of the RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communications 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).

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

[0014] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using NR.

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

[0016] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology 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), or the like.

[0017] 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, but may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a location of a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by a drone), a road, etc. 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 one 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 establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106.

[0018] The RAN 104 may communicate with the CN 106, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various Quality of Service (QoS) requirements, such as, for example, 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 shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 may communicate directly or indirectly with other RANs that use 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 communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0019] The CN 106 may also serve 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 providing 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) of the TCP / IP Internet Protocol suite. The networks 112 may include wired 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 that may use the same RAT as the RAN 104 or a different RAT.

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

[0021] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, 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 understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

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

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

[0024] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may use 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.

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

[0026] The processor 118 of the WTRU 102 may be coupled to, and may receive user-entered data from, 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). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. It should be noted that the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or 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, etc. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

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

[0028] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of 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 being received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by way of any suitable location-determination method while remaining consistent with an embodiment.

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

[0030] The WTRU 102 may include a full-duplex radio where some or all of the signals (e.g., associated with a particular subframe in both the UL (e.g., for transmission) and DL (e.g., for reception) may be transmitted and received simultaneously and / or together. The full-duplex transmission radio may include an interference management unit to reduce and or substantially eliminate self-interference either through hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio where some or all of the signals (e.g., associated with a particular subframe in either the UL (e.g., for transmission) or DL ​​(e.g., for reception)) are transmitted and received simultaneously.

[0031] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

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

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

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

[0035] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment 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.

[0036] The SGW 164 may be connected to each of the eNodeBs 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-eNodeB handover, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0037] The SGW 164 may be connected to a 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.

[0038] 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 communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Note that the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

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

[0040] In an exemplary embodiment, the other network 112 may be a WLAN.

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

[0042] When using an 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit a beacon 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 a BSS and may be used by STAs to establish a connection with an AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be active by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0043] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a 20 MHz primary channel and adjacent or non-adjacent 20 MHz channels.

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

[0045] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. The channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter-type control / machine-type communications (MTC), such as MTC devices in macro coverage areas. MTC devices may have specific capabilities, including, for example, support for (e.g., only for) specific and / or limited bandwidths. An MTC device may include a battery that has a battery life that exceeds a threshold (eg, to maintain a very long battery life).

[0046] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. 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 by the STA and / or limited among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah embodiment, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. For example, if a STA (that only supports 1 MHz mode of operation) transmitting to an AP has a busy primary channel, all of the available frequency bands may be considered busy even if most of the available frequency bands are idle.

[0047] In the United States, the available frequency band that can be used by 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.

[0048] 1D is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 104 may also communicate with the CN 106.

[0049] The RAN 104 may include gNBs 180a, 180b, 180c, although it will be understood 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 an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beamforming to transmit and / or receive signals to the gNBs 180a, 180b, 180c. Thus, the gNB 180a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a using, for example, multiple antennas. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, and the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or gNB 180c).

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

[0051] 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 without accessing other RANs (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, while the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0052] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

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

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

[0055] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

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

[0058] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-102d, base stations 114a-114b, eNode-Bs 160a-160c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-180c, AMFs 182a-182b, UPFs 184a-184b, SMFs 183a-183b, DNs 185a-185b, and / or any other device(s) described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

[0060] The one or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a test scenario in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF link and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0061] The following abbreviations and acronyms may be referenced:

[0062] [Table 1]

[0063] LTE defines two operating modes for V2X communications: Mode 3 and Mode 4. In Mode 3, the network may provide the WTRU with an assignment for V2X sidelink transmissions along with scheduling. In Mode 4, the WTRU may autonomously select resources from a configured / pre-configured resource pool. There are two categories of resource pools defined in V2X LTE: (1) receive pools, which may be monitored to receive V2X transmissions, and (2) transmit pools, which may be used by the WTRU to select transmission resources in Mode 4. The transmit pools are not used by WTRUs configured in Mode 3.

[0064] In LTE, the resource pool may be semi-statically signaled to the WTRU via Radio Resource Control (RRC) signaling. In Mode 4, the WTRU may use sensing before selecting resources from the RRC configured transmission pool. LTE V2X does not support dynamic resource pool reconfiguration. The pool configuration may only be conveyed via SIB and / or dedicated RRC signaling.

[0065] 5G NR inherited two modes of resource allocation from LTE: Mode 1 resource allocation corresponds to base station (i.e., gNB) scheduled resource allocation; Mode 2 resource allocation corresponds to WTRU autonomous resource allocation. The concepts of resource pooling and sensing for Mode 2 resource allocation were also inherited from LTE.

[0066] In 3GPP, access to unlicensed bands is specified in License Assisted Access (LAA). More specifically, downlink (DL) operation, uplink (UL) operation, and autonomous UL as well as other extensions are specified. LAA utilizes the premise that unlicensed operation was always fixed to the PCell in licensed bands. Access to unlicensed bands in the SCell required LBT operation by the WTRU / gNB.

[0067] In new radio, an unlicensed spectrum (NR-U) is specified, which supports NR radio access operating with shared spectrum channel access to operate in different modes, where either the PCell, PSCell, or SCell may be in the shared spectrum, and the SCell may or may not be configured in the UL.

[0068] To support NR-U, the following modifications have been made to the PHY layer signals and channels: (1) DCI 2_0 is extended to provide a time and frequency domain channel occupancy time (COT) structure; (2) a search space group switching feature is introduced, whereby the WTRU may be dynamically controlled to perform PDCCH monitoring using one of two groups in the search space set; (3) an additional PDSCH mapping type B length is introduced to enable transmission at the beginning of the COT as soon as it begins; (4) the search space may be configured with multiple monitoring positions in the frequency domain to enable PDCCH monitoring across multiple LBT bands; (5) an interlaced structure is introduced for PUCCH and PUSCH, where the PUCCH format is extended to a PRB interlaced waveform, but contained within one RB set; (6) SRS transmission may be on any symbol of a slot; and (7) the gNB may schedule multiple consecutive PUSCHs with a single DCI format.

[0069] A WTRU operating in a shared spectrum may perform LBT to access the channel. NR-U supports dynamic channel access (LBE) and semi-static channel access (FBE). In some embodiments, in the case of FBE, the gNB may only start COT at a specific time signaled by its fixed frame period (FFP) configuration. The WTRU may share a semi-static channel if a gNB DL transmission is detected in an earlier part of the same FFP. In other embodiments, the WTRU may be configured with a WTRU-FFP and may start COT at a specific time determined from its WTRU-FFP configuration.

[0070] CCA (Clear Channel Assessment) may be performed in 20 MHz increments. The following types of LBT are specified: (1) CAT4 LBT-Type 1, (2) CAT2 LBT-Type 2A, (3) CAT2 LBT-Type 2B, and (4) CAT1 LBT-Type 2C.

[0071] The COT may be initiated using CAT4 LBT and may be shared by nodes receiving transmissions from the COT-initiating node using either CAT1 LBT or CAT2 LBT, depending on the gap size between transmissions at the switching point.

[0072] The LBT parameters may be determined by the Channel Access Priority Class (CAPC), which may be either fixed or configurable for radio bearers and MAC CEs, i.e., (1) fixed to the lowest priority for padding BSR and recommended bit rate MAC CEs, (2) fixed to the highest priority for SRB0, SRB1, SRB3 and other MAC CEs, and / or (3) configured by the gNB for SRB2 and DRBs.

[0073] When selecting a CAPC for a DRB, the gNB may consider the 5 QIs of all QoS flows multiplexed in that DRB, while considering fairness between different traffic types and transmissions. Table 1 below shows which CAPC should be used for which standardized 5QI (i.e., which CAPC is used for a given QoS flow). QoS flows corresponding to a non-standardized 5QI (i.e., an operator-specific 5QI) should use the CAPC of the standardized 5QI that best matches the QoS characteristics of the non-standardized 5QI.

[0074] [Table 2]

[0075] When CAPC is not indicated in the DCI and the WTRU performs a Type 1 LBT procedure for transmission of an uplink TB, the WTRU may select a CAPC as follows: (1) if only MAC CEs are included in the TB, the highest priority CAPC among those MAC CEs is used, or (2) if the TB contains CCCH SDUs, the highest priority CAPC is used, or (3) if the TB contains DCCH SDUs, the highest priority CAPC among the DCCHs is used, or (4) the lowest priority CAPC of the logical channel with MAC SDUs multiplexed in the TB is used, otherwise.

[0076] In NR-U, access to the channel assumes the traditional Uu architecture. Specifically, the gNB schedules multiple WTRUs in its coverage, and the gNB is assumed to have a fixed location. Once the channel is accessed, transmissions by the WTRUs scheduled by the gNB are targeted to the gNB. However, for SL operation in a shared spectrum, these assumptions may no longer be valid.

[0077] One problem that arises is the Mode 1 scheduling problem. In Mode 1 SL, the gNB schedules SL resources to the WTRU. The scheduling DCI may be in a shared spectrum (possibly the same shared spectrum as the WTRU transmission). However, the WTRU's transmission may not be targeted to the gNB but to another WTRU. Thus, the gNB may not know if the WTRU has acquired the channel following the DCI. Furthermore, there may be scenarios where the gNB may not perform an LBT procedure for access to the channel on which the WTRU will transmit (e.g., SL transmission by the WTRU on a carrier different from the carrier on which the DCI is transmitted). Specifically, the WTRU may not be able to share the COT initiated by the gNB. However, the WTRU may share the COT initiated by the WTRU.

[0078] The second problem is that the SL architecture may require new methods for determining LBT parameters. LBT parameters such as channel width (CW) size, maximum COT length, and allowed CW size depend mainly on the QoS of the data to be transmitted. This may be appropriate for the Uu infrastructure / architecture, but may not be appropriate for the distributed architecture typical of V2X. Specifically, V2X may support unicast, groupcast, and broadcast. Furthermore, some transmissions (e.g., broadcast) are typical of unrelated WTRUs, while other transmissions (e.g., unicast) are typical of WTRUs that move together. These factors may affect the LBT parameters required for such transmissions. They may also affect COT usage rules, such as whether a WTRU may share a COT initiated by another WTRU.

[0079] As used herein, the term "initiating a COT" may refer to performing a full LBT (e.g., Type 1 LBT). Similarly, "sharing a COT" may refer to performing a reduced LBT (e.g., Type 2 LBT). The WTRU may identify a grant as a Type 1 LBT grant or a Type 2 LBT grant. The decision of whether to perform a transmission in a grant and what type of transmission based on whether the WTRU is initiating or sharing the grant may be derived based on the identification of the LBT type to be performed for that grant, as discussed herein.

[0080] In this specification, a reference to a WTRU that initiated a COT may refer to the WTRU that performed the SL transmission that created the new COT. Alternatively, the WTRU that initiated the COT may refer to another WTRU that transmits within the COT and whose transmission is detected by the WTRU. Alternatively, the WTRU that initiated the COT may also refer to another WTRU that transmits or forwards COT information when it decides to share an existing COT.

[0081] In the embodiments described herein, LBT behavior may refer to any aspect related to a method (eg, LBT) for accessing a channel in a shared spectrum.

[0082] The LBT behavior may include CAPC or similar access class / classification that determines the set of LBT parameters. For example, the LBT behavior may include the WTRU selecting a channel access priority class for a given data or transmission type (as described herein). For example, the LBT behavior may include the WTRU determining whether to use a UL CAPC table for LBT or a DL CAPC table for LBT. For example, the LBT behavior herein may include determining whether the WTRU can use only one of the UL / DL CAPC tables or whether either table can be used. For example, the LBT behavior may include determining whether the WTRU can select any access priority class for transmission or whether the WTRU can select only a specific access priority class for transmission.

[0083] The LBT behavior may include the WTRU determining whether to determine the CAPC in a first mechanism (e.g., using a first table or a first mapping) or whether to determine the CAPC in a second mechanism (e.g., using a second table or a second mapping). The first or second mapping may comprise mapping any property herein to the CAPC. For example, the first mapping may comprise a mapping between a PQI (QoS Profile Indicator) and the CAPC, and the second mapping may comprise a mapping between a logical priority and the CAPC.

[0084] The LBT behavior may include deciding between a first rule for deriving a CAPC from a transmission that includes multiple elements, each with their own CAPC, (e.g., use the highest priority of the CAPC included in the transmission) and a second rule for deriving a CAPC from such a transmission (e.g., use the lowest priority of the CAPC included in the transmission). For example, the WTRU may use the lowest priority of the CAPC for one type of transmission (e.g., Mode 1 transmission) and the highest priority of the CAPC for another type of transmission (e.g., Mode 2 transmission). The type of transmission may be further configured from any of the SL characteristics defined herein, such as priority (of either data / control included in the PDU), CBR, etc., not necessarily limited to mode.

[0085] When data / control with different CAPCs are multiplexed into the same PDU, determining the rule for obtaining the CAPC of the PDU may consist of any of the following: (1) determining whether to select the highest priority or the lowest priority; (2) determining whether to obtain the CAPC from a fixed mapping or a configurable mapping; (3) determining whether to obtain the CAPC from the MAC CE and / or SRB priority; (4) determining whether to obtain the CAPC from the DRB priority; (5) determining the order of the rules to be applied when determining the CAPC (e.g., consider MAC CE first, consider DRB first, consider SRB first, etc.); (6) determining whether to consider any of the priorities of MAC CE, SRB, or DRB in the determination.

[0086] The LBT behavior may include any existing LBT parameters, such as a contention window size (CWS), a maximum COT length, an allowable CW size, a CW adjustment procedure, a number of CCAs, a CCA duration, a deferral period, and / or an FFP parameter that applies to the SL. For example, the LBT behavior may include the WTRU selecting one particular maximum COT length over another. For example, the LBT behavior may include the WTRU deciding whether to use / consider a parameter (such as a deferral period) as part of the LBT. For example, the LBT behavior may include the WTRU selecting a CWS from one of a set of configured values, the WTRU increasing the CWS by a particular amount per transmission, etc. For example, the LBT behavior may include deciding whether to use a first CW adjustment procedure (or set of parameters for the procedure) or a second CW adjustment procedure (or another set of parameters for the procedure). For example, selecting an LBT parameter may involve either selecting one of multiple (pre-)configured values, or directly determining the value of the parameter itself from time-associated SL characteristics such as PDB, HARQ RTT, separation between different SL channels, etc.

[0087] The LBT behavior may also include an LBT type or category. For example, the LBT behavior may include determining whether the WTRU uses one LBT type or another LBT type and / or one LBT category.

[0088] The LBT behavior may also include an LBT beam, beam width, or beam direction (including omnidirectional). For example, the LBT behavior may include the WTRU selecting an LBT beam width, the number of channels / subchannels on which LBT is performed to gain access to the channel, etc.

[0089] The LBT behavior may also include any new LBT parameters specific to the SL that determine the channel access behavior, such as any tolerable / minimum / maximum delay between events for access of the channel, which may be related to energy measurements or occurrence of sidelink specific events such as reception / transmission of sidelink channels (e.g., SCI, PSCCH, PSFCH, etc.), control information, or HARQ feedback.

[0090] The LBT behavior may also include an energy threshold for the determination of channel occupancy. The LBT behavior may also include a number of time slots or equivalent used for the determination of channel occupancy.

[0091] The LBT behavior may also include the number of instances of application of a procedure related to channel access, such as the LBT, or a portion of the LBT (where the LBT may be an access procedure specific to the SL channel or the same access procedure used in Uu). For example, the LBT behavior may include determining the number of times the LBT can be attempted before a second action (potentially referred to herein) can be initiated.

[0092] The LBT behavior may also include any time instance during which an LBT is performed on a channel. The LBT behavior may also include a min / max time from the last transmission before the WTRU can reuse the COT, and / or the type of LBT to be performed in the event of this min / max time (e.g., no LBT, one-shot LBT, full LBT, etc.).

[0093] The LBT behavior may also include whether the WTRU is permitted to share a COT initiated by a base station (e.g., a gNB) and / or another WTRU. For example, the LBT behavior may include determining whether the WTRU can share a COT initiated by another WTRU. For example, the LBT behavior may include the WTRU determining whether it needs to initiate a new COT for a transmission.

[0094] The LBT behavior may also include a minimum / maximum time between a previous transmission (e.g., from another WTRU or a base station (e.g., gNB)) and the WTRU's own transmission that requires one or another type of LBT to access the channel.

[0095] The LBT behavior may also include a COT length that is determined by the WTRU initiating the COT and possibly transmitted in the COT structure information. For example, the LBT behavior may include the WTRU selecting one COT length over another (e.g., both may be configured). For example, the LBT behavior may include whether the WTRU limits the selected COT length to a particular value.

[0096] The LBT behavior may also include whether the WTRU initiating the COT can share the COT with other WTRUs and whether it indicates this sharing capability in the COT structure information. For example, the LBT behavior may include the initiating WTRU determining whether it indicates whether the COT can be shared. For example, the LBT behavior may include the initiating WTRU determining which WTRUs can share the COT and potentially indicating that in the COT information.

[0097] In one embodiment, a WTRU may have multiple independent LBT behaviors and / or procedures. An LBT procedure (e.g., CW adjustment) may involve multiple steps in which parameters (e.g., CW applied for a given access priority) are updated following one or more steps. A WTRU performing SL LBT may maintain multiple independent / concurrent LBT procedures that independently update parameters within the procedure. Each independent / concurrent LBT procedure may be associated with a SL factor, such as: (1) cast type (e.g., one procedure for unicast and one procedure for groupcast / broadcast), (2) L2 source / destination ID (e.g., one procedure for each destination L2 ID), (3) unicast link (e.g., one procedure for each source / destination ID pair), (4) QoS flow, (5) resource pool, and / or (6) HARQ enabled and HARQ disabled transmissions.

[0098] Any of the LBT procedures associated with the LBT behaviors described above may have multiple independent / concurrent instances of the LBT procedure, and a WTRU that performs an LBT for a transmission with a particular factor may then use the parameters associated with that instance of the procedure.

[0099] The WTRU may have different CW adjustments for HARQ enabled / disabled transmissions. In an embodiment, the WTRU may perform the CW adjustment differently based on whether the transmission is associated with a HARQ enabled or disabled transmission. For example, the WTRU may use different adjustment parameters / values ​​following a transmission with enabled versus disabled HARQ feedback. In another example, the WTRU may set the CW to a default or configured value following a transmission with HARQ feedback disabled. In another example, the WTRU may increase / decrease the CW by a default / configured amount for transmissions with HARQ feedback disabled. In another example, the WTRU may ignore all transmissions with disabled HARQ feedback in determining a CW update. In another example, the WTRU may set the CW to an initial value following a transmission with HARQ feedback disabled. In another example, the WTRU may decrease the CW adjustment by an amount depending on the number of HARQ disabled transmissions in the time window or since the last HARQ enabled transmission. In another example, the WTRU may reset the CW to a default / initial value following a transmission with HARQ feedback disabled. In another example, the WTRU may be configured to increase the CW for a NACK. Furthermore, if HARQ feedback is disabled, the increase in CW may be associated with a function (e.g., half, double, etc.). The function may also depend on other factors in the WTRU that are not static. In another example, the decision as to whether the WTRU increases the CW by a first amount or a second amount following a HARQ feedback disabled transmission may depend on whether the previous transmission resulted in an ACK or a NACK.

[0100] The WTRU may decide whether to perform transmission with HARQ feedback enabled or disabled based on the CW adjustment state, which may consist of any of the value of CW, the number of times CW has been increased since the last reset of its value, whether the value is above a (pre-)configured threshold, etc. For example, the WTRU may perform transmission with HARQ feedback enabled when the value of CW is above a threshold. For example, the WTRU may perform transmission with HARQ feedback enabled when the number of successive increases in CW since the last reset is above a threshold.

[0101] Mode 1 scheduling for SL may depend on the capabilities of the base station (e.g., gNB) that has access to channel availability information (e.g., information about COT obtained by the SL 3GPP system). In one embodiment, the WTRU may determine whether to perform an LBT procedure over SL and the LBT behavior (e.g., LBT type) based on an implicit / explicit indication in the SL scheduling DCI or other message from the base station (e.g., gNB).

[0102] For example, the WTRU may receive an indication that an LBT procedure is needed / not needed and / or the type of LBT required in a DCI scheduling an SL grant. The WTRU may determine whether an LBT is needed / not needed or the type of LBT based on the time difference between the reception of the scheduling DCI and the SL resource being scheduled. Here, for example, the WTRU may be (pre-)configured with a mapping of LBT types to the time difference between the scheduling DCI and the SL resource and may use that time difference to determine the LBT type to perform. For example, the WTRU may assume that an LBT is not needed or a short LBT is needed if the time between the scheduling DCI and the SL resource is below a threshold.

[0103] The WTRU may receive an explicit indication that an LBT procedure is required / not required and / or the type of LBT required in a separate DCI. The WTRU may be configured with an SL configured grant and may receive a scheduling DCI before any instance of that configured grant to indicate whether an LBT procedure is required / not required and the type of LBT.

[0104] Furthermore, combinations of the above examples are also possible. For example, the WTRU may receive an explicit indication of whether to perform a Type 1 LBT or an LBT type determined by the time difference between the scheduling DCI and the SL grant timing. Such an explicit indication may be in the DCI. Such an explicit indication may be provided to the WTRU as part of the RRC configuration.

[0105] The above condition may further depend on whether the carrier / BW on which the DCI is received is the same as the carrier on which the SL is scheduled. Specifically, the WTRU may assume that if the time between the scheduling DCI and the SL resource is less than a threshold (same carrier only), then no LBT procedure or a short LBT procedure is required.

[0106] In another embodiment, the WTRU may determine the LBT parameters to use based on a combination of information in a DCI received from the network and an SCI received from another WTRU. For example, if the DCI does not explicitly indicate an LBT type, the WTRU may use the first LBT if its permission is within the COT indicated in the SCI. If the DCI explicitly indicates an LBT type, the WTRU may follow the DCI indication.

[0107] In another embodiment, the WTRU may determine the LBT parameters depending on the source of the received SCI. Specifically, the WTRU may determine the LBT type or parameters as a combination of: (1) CAPC or similar information in the DCI and / or SCI, (2) the time gap between SCI transmissions detected on the SL compared to a threshold (such threshold may be determined or derived by information in the DCI in addition to other SL-specific information described herein), and / or (3) the time gap between the DCI and the SL grant. The WTRU may determine how to combine such information based on the information in the DCI or similar information provided in RRC signaling.

[0108] In another embodiment, the WTRU may determine the LBT parameters based on whether the DCI and the SL transmission are on the same (unlicensed) carrier. Specifically, a WTRU that receives a DCI on the same unlicensed carrier as the SL transmission may interpret the receipt of the DCI as initiation of COT by the base station (e.g., gNB). Alternatively, if the DCI is received on a carrier different from the SL carrier, the WTRU may determine whether to rely on the SL transmission to initiate the COT or whether the COT is initiated by another WTRU.

[0109] The LBT type or parameters may include at least one of the following: (1) LBT category (e.g., LBT CAT1, LBT CAT2, LBT CAT3, or LBT CAT4); (2) CCA duration; (3) CW size (which may include a maximum CW size or a currently used CW size); (4) LBT beam direction or beam width (e.g., the LBT may be omnidirectional); (5) COT duration (which may include a maximum COT duration); (6) deferral period duration; and / or (7) FFP configuration.

[0110] For example, if the WTRU receives CAPC or similar information in the DCI, it may determine the LBT type to be used based on the time difference between the DCI and the SCI. This case may correspond to a scenario where the base station (e.g., gNB) performed an LBT to transmit the DCI by itself. If the WTRU does not receive CAPC in the DCI, the WTRU may determine the LBT type to perform based on the SCI transmission. Specifically, if the WTRU does not find a COT initiated by another WTRU to share, the WTRU may perform a Type 1 LBT. Otherwise, if sharing a COT, the WTRU may perform an LBT whose type may be determined based on the time gap between the WTRU grant and the last SCI / transmission by another WTRU. Similar to above, the WTRU may also determine the type of data (e.g., priority, cast, etc.) based on similar rules.

[0111] COT information by the WTRU (e.g., in a format similar to the CG-UCI) may be transmitted by the WTRU in the SCI. The WTRU may transmit such COT information in each SCI. Alternatively, the WTRU may transmit information in a subset of SCI transmissions, such as periodically, every x transmissions, every x time periods, in an SCI transmission that initiates a COT, upon reception of an SCI that initiates a COT, or when specific COT information is included.

[0112] The WTRU may transmit the COT information on other PHY channels (e.g., other than the PSCCH). Alternatively, the WTRU may transmit the COT information in a SL MAC CE, SL RRC message, Inter-WTRU Resource Coordination message, or a similar message. The WTRU may transmit the COT information that determines when it starts COT.

[0113] Alternatively, or in conjunction, the WTRU may transmit COT information it receives from a base station (e.g., gNB) and / or other WTRUs (e.g., when it decides to share a COT). For example, the WTRU may transmit COT information received from a base station (e.g., gNB), or may derive relevant COT information for transmission in the SL from information received from a base station (e.g., gNB). The COT information may include any COT information described herein. For example, the WTRU may receive a remaining COT length from a base station (e.g., gNB). The WTRU may calculate a remaining COT length after its SCI transmission (e.g., by subtracting the time gap between DCI receptions from the received remaining COT length) and include this information in its own SCI transmission or in a SL MAC CE transmitted with its own transmission. Alternatively, the WTRU may decide to transmit COT information from another WTRU. In some cases, the WTRU may decide to transmit COT information from another WTRU even if they do not share the COT in question.

[0114] In one embodiment, a WTRU may report COT information received from another WTRU or determined by the WTRU based on reception from another WTRU to a base station (e.g., a gNB). For example, such a report may be sent in the PUCCH, SR, in the form of HARQ feedback, CG-UCI, MAC CE, or RRC message. The COT information may include any of the following: (1) COT structure (e.g., time / frequency resources associated with the COT); (2) remaining COT duration; (3) CAPC associated with the COT (or used to initiate the COT); (4) LBT statistics collected by the WTRU (e.g., number of occupied / available resources in the CW); (5) COT characteristics that determine the COT type (as defined herein) or COT usability properties of the WTRU or transmission that initiated the COT or transmitted the COT information, such as L2 ID, WTRU type (e.g., sensing / non-sensing WTRU, DRX WTRU, WTRU release or profile), IC / OOC WTRU, and / or cell ID associated with the IC WTRU (which may be operating in Mode 1); (6) RSSI measurements of the channel / carrier / LBT bandwidth; (7) channel occupancy; (8) CCA results; (9) energy detection threshold used to initiate the COT; (10) LBT type or parameters used to initiate the COT; (11) FFP parameters; (12) LBT associated with the COT; (13) the set of BWs (which may include a set of BWs on which the LBT was performed, a set of BWs on which the LBT was deemed successful, or a set of BWs on which the LBT was deemed unsuccessful); (14) the QoS information (e.g., priority) associated with the transmission that initiated the COT; (15) the expected gap between two sidelink transmissions, or the existence of a gap between two sidelink transmissions; (16) whether the transmission that initiated the COT is an initial transmission or a retransmission; (17) the identity of the node that initiated the COT; (18) whether the COT is shared by the WTRU; and / or (19) whether the COT may be shared by a base station (e.g., a gNB) or another WTRU.

[0115] The COT information may also include information about when (i.e., the time location) within the COT a transmission by one or more other WTRUs or the WTRU itself will end (e.g., the WTRU may determine the existence of a COT initiated by the WTRU based on receiving an SCI indicating the start of a COT by transmitting that SCI. The SCI may further include the duration of the COT. The one or more SCIs received by the WTRU may further include information associated with the intended use of resources within the COT by one or more other WTRUs. For example, the WTRU may determine (e.g., based on an SCI transmission or information in the SCI) a time slot within the COT at which SL resources within the COT are available and may transmit this timing information to the base station (e.g., gNB)).

[0116] The COT information may be reported periodically, for example, the WTRU may have a periodic resource for transmitting the ongoing COT and whether there is any COT information associated with the COT.

[0117] The WTRU may be triggered to report COT information to a base station (e.g., gNB). The trigger may include at least one of the following: (1) receipt of a DCI, (2) content of the DCI (e.g., a field in the DCI may trigger reporting of COT information), (3) receipt of an SCI, (4) content of the SCI (e.g., a field in the SCI may trigger reporting of COT information), (5) transmission of an SR to use the COT, (6) based on the result of an LBT. For example, the WTRU may report COT information if an LBT to share or start a COT is successful or unsuccessful, and / or (7) based on a request to start a different COT. The WTRU may report one or more pieces of COT information based on receipt of a transmission from one or more other WTRUs.

[0118] In one embodiment, the WTRU may report COT information on UL resources associated with the COT initiated / used by the WTRU itself on the SL, possibly associated with a SL grant provided by the network. Such reports may be sent in PUCCH, SR, for example, in the form of HARQ feedback, CG-UCI, MAC CE, or RRC messages. Such information may include any of the information similar to that in the previous embodiment (e.g., WTRU report information received from a peer WTRU). In addition, the WTRU may further report: (1) the time instance at which the COT was initiated / should be terminated, (2) LBT statistics collected by the WTRU (e.g., number of occupied / available resources in the CW), (3) the HARQ process ID of the transmission that initiated the COT, (4) whether the WTRU was successful / unsuccessful in initiating the COT (if unsuccessful, the reason may be, for example, an error reason or some statistics associated with the failed LBT, e.g., RSSI, number of available resources in the CW, etc.), (5) whether the WTRU was successful / unsuccessful in transmitting on the shared COT. (6) whether the WTRU has acquired the channel since initiating its own COT or shared the COT with another WTRU; (7) the amount of time remaining in the COT (that the WTRU could have shared) or whether such time is above / below a threshold (such a threshold may depend on the properties (e.g., priority) of the data transmitted by the WTRU); (8) the number of times the WTRU successfully / failed to initiate a COT, possibly over a particular period of time, possibly associated with a particular CAPC or LBT behavior; and / or (9) the L2 ID associated with the transmission that initiated or shared the COT.

[0119] The WTRU may report the COT information periodically or aperiodically, which may reuse the methods described herein for reporting COT information received from a peer.

[0120] In one example embodiment, the WTRU may be configured with one PUCCH resource (possibly associated with an SL grant) for indicating whether the LBT was successful, and another PUCCH resource (possibly associated with the same SL grant) for reporting a HARQ ACK / NACK to the base station (e.g., gNB). Specifically, if the WTRU can acquire the SL channel in the grant, it may send an ACK in the first PUCCH resource, and then send an ACK / NACK on the second PUCCH resource based on the SL HARQ feedback from the RX WTRU. Alternatively, the information provided on the first PUCCH resource may indicate that (1) transmission by the WTRU on the grant was accomplished by sharing an existing COT (e.g., indicated using the first codepoint) or by starting a new COT (indicated using the second codepoint), or that no channel was acquired for the grant (indicated using the third codepoint), or (2) that the WTRU acquired a COT with a remaining COT length greater (using the first codepoint) or smaller (using the second codepoint) than a threshold, where the threshold may be based on the priority of the data in the buffer included in the PDU or reported in the BSR. The WTRU may also indicate that it did not acquire a channel for the grant (using the third codepoint).

[0121] Alternatively, the WTRU may transmit feedback on a single PUCCH resource, and the feedback may indicate one of three states: ACK, NACK, or DTX, where DTX may indicate that a transmission was not performed due to a failed LBT.

[0122] In one example embodiment, the WTRU may determine for a Mode 1 SL grant whether it can acquire a channel for the grant and whether to use an existing COT or start a new COT. Such determination is described further herein. Following such determination, the WTRU may determine information to be provided to the base station (e.g., gNB) following the grant (e.g., in the form of a UCI). If the WTRU shares an existing COT, the WTRU may receive COT structure information from another WTRU (e.g., in an SCI transmitted within that COT) and transmit the COT structure (e.g., remaining COT length, CAPC, etc.) in the UCI to the base station (e.g., gNB).

[0123] If the WTRU initiates its own COT, it may create a UCI indicating the COT structure based on the CAPC of the data included in the transmission and / or LBT parameters used to acquire the channel, and may send the created UCI to the base station (e.g., gNB). If the WTRU is unable to acquire the channel, it may indicate such in the UCI and may include additional information regarding the reason for the access failure, such as: (1) an LBT failure when attempting to acquire a new COT, and potential LBT statistics associated with the failure, (2) an LBT failure when attempting to acquire an existing COT initiated by another WTRU, and potential LBT statistics associated with the failure (e.g., the gap between transmissions and the type of LBT the WTRU was requested to perform), (3) the remaining COT length of the existing COT at the time of grant is shorter than required and therefore not acquired by the WTRU, and / or (4) an L2 ID associated with the transmission that initiated the COT.

[0124] In one example, the WTRU may be configured with SR resources to indicate failure to acquire the SL channel. The WTRU may be further configured with different SR configurations depending on the priority of the data multiplexed in the PDU that was to be transmitted on the grant for which the LBT failed.

[0125] The WTRU may trigger / send a report of the COT information as described in the embodiments described above. The WTRU may trigger / send a report of the COT information when the WTRU is unable to acquire, possibly, one or more SL grants or channels associated with a configured SL grant. For example, the WTRU may send a HARQ NACK, SR, or similar UL transmission if it is unable to successfully perform an LBT procedure on resources associated with an SL grant. For example, the WTRU may perform an UL transmission when the first / last resource associated with a grant LBT procedure (e.g., the first / last retransmission resource for a grant) fails. For example, the WTRU may perform an UL transmission when it is unable to acquire at least x resources associated with an SL grant by the network, where x may be configured (pre-) and may depend on one or more other factors described herein.

[0126] A WTRU may trigger / send a report of COT information when the WTRU receives information regarding a new possible COT that it could have initiated (based on its own channel access) or detected (based on reception from another WTRU). In one example, a WTRU may send COT information (e.g., in a MAC CE) to the base station upon determination of a COT initiated by another WTRU (e.g., based on reception of an SCI from another WTRU).

[0127] In another example, the WTRU may transmit (e.g., in a MAC CE) COT information to a base station (e.g., a gNB) upon a change in COT information previously reported to the base station. For example, a change in the COT information may be the occurrence of a gap in the COT (e.g., due to a lack of SL transmission) that is greater than a (pre-)configured threshold. A change in the COT information may be the receipt (e.g., from a second WTRU) of a message indicating an expected COT length that is shorter than a COT length initially indicated (possibly by a first WTRU) for the same COT.

[0128] A WTRU may trigger / send a report of COT information when the WTRU is configured (e.g., via RRC configuration or via MAC CE) with conditions on whether to report COT information received from other WTRUs or determined by the WTRU. For example, the conditions may include: (1) report COT information (e.g., for a newly detected COT) as long as the remaining COT length is smaller / larger than a threshold, (2) report COT information as long as the CAPC is above / below a threshold, (3) report COT information as long as the maximum time gap in (potentially planned) transmissions within the COT is above / below a threshold, and / or (4) report COT information if, compared to a previous report, the information of the (potentially same) COT has changed, possibly by a certain amount (e.g., the COT length changes by a certain amount).

[0129] The thresholds for the above conditions may depend on the data available for transmission by the WTRU, such as priority, remaining PDB, or channel measurements such as CBR. For example, the WTRU may determine a threshold COT length based on the priority of data pending for transmission at the WTRU. If the WTRU detects a COT (based on receiving information from another WTRU) whose COT length is greater than the determined threshold, the WTRU may report the COT information to the base station.

[0130] The WTRU may maintain multiple COTs. For example, the WTRU may maintain a first COT associated with a first node (e.g., a base station) and a second COT associated with a second node (e.g., another WTRU). The WTRU may maintain different COT parameters for each COT. For example, the WTRU may share the first COT and may initiate a second COT. The WTRU may, for example, use only the COT associated with a base station (e.g., a gNB) for transmission to the base station (e.g., a gNB). The WTRU may share the COT associated with a base station (e.g., a gNB) for transmission to another WTRU. The WTRU may indicate a set of COT information in a transmission to the base station (e.g., a gNB). One of the COT information transmitted to the base station (e.g., a gNB) may be associated with the COT associated with the base station (e.g., a gNB).

[0131] In one embodiment, the WTRU may initiate an LBT procedure on the SL when it indicates to the network that it has SL data to be transmitted. For example, the WTRU may be (pre-)configured with a time instance following the transmission of an SL SR / BSR at which to initiate the LBT. Such a time instance may depend on properties of the data to be transmitted, such as QoS, cast, or information provided in the BSR (e.g., LCG, destination index, etc.).

[0132] In another embodiment, the WTRU may initiate an LBT procedure on the SL upon receipt of a grant in the DCI or at some time period following receipt of the DCI, which may be (pre-)configured, indicated in the DCI, and / or dependent on measurements of the SL and / or QoS of the transmission.

[0133] In another embodiment, the WTRU may be provided with multiple SL grants (possibly a single DCI, possibly a DCI and a pattern configured by the RRC or MAC CE). The multiple SL grants may be explicitly indicated in the DCI. Alternatively, the multiple SL grants may follow a predefined time / frequency pattern. The purpose of the grant may be to allow the WTRU to attempt the LBT procedure multiple times on the SL. Specifically, the WTRU may attempt LBT on the first grant. If the LBT fails, it may attempt LBT on the second grant, and so on.

[0134] The WTRU may further inform the network whether it was successful in accessing the channel with the LBT (e.g., using UCI or COT information as described herein). The WTRU may further cancel any subsequent grants following channel acquisition in a previous grant. Alternatively, the WTRU may be configured to decide whether to keep or cancel subsequent grants based on: (1) the amount of data in the buffer (e.g., if the WTRU has data available for transmission, possibly associated with a particular priority, it may keep one or more of the subsequent grants); (2) channel congestion (e.g., if the CBR is above a threshold, the WTRU may cancel subsequent grants and may keep them otherwise); (3) the number of remaining subsequent grants (e.g., the WTRU may be configured with the maximum number of subsequent grants it can keep and may drop the rest; (4) the priority of the data in the buffer; (5) any combination of (1)-(4) above; and / or (6) any other conditions described herein (e.g., associated with a multi-LBT occasion as described herein).

[0135] The WTRU may determine whether an LBT is required before the resources of the next grant in a set of SL grants depending on whether an LBT was successful before a previous grant in the same set of SL grants and the duration since the most recent successful LBT, and whether there is a gap before the next grant.

[0136] A WTRU scheduled with multiple SL grants may select whether to share an existing COT or start a new COT based on parameters of one or more SL grants in the set of multiple SL grants. For example, the WTRU may decide whether to share an existing COT depending on the amount of grants in the set of multiple SL grants that may be transmitted within the COT. For example, if a WTRU has n SL grants in the set of SL grants and an ongoing COT has sufficient resources for transmission of m SL grants, the WTRU may decide whether to share the ongoing COT or start a new COT depending on m and n. The WTRU may decide whether to share the ongoing COT or start a new COT depending on the priority of the transmissions in one or more of the sets of multiple SL grants.

[0137] The transmission of COT information on the SL may depend on whether the WTRU initiates or shares the COT.

[0138] A transmitting SL WTRU may transmit COT information (e.g., COT structure) on the SL along with its own transmission. For example, the WTRU may include the COT information in the SCI, SL MAC CE, dedicated PHY channel, SL RRC, UCI, CG-UCI, SL-UCI, or a combination thereof. The COT information may include information described herein or COT information in the prior art, or a combination thereof.

[0139] In one embodiment, a WTRU may decide whether to create its own COT information for a transmission or forward / transmit COT information received from another WTRU or base station based on whether the WTRU initiates a COT or shares a COT initiated by another WTRU or base station. Specifically, if the WTRU's grant or potential grant does not fall into an existing COT, the WTRU may initiate its own COT and may create the COT information (COT structure) based on the LBT used to create the COT in its own transmission.

[0140] If the WTRU's grant or potential grant falls within a COT initiated by the base station or another WTRU, the WTRU may transmit COT information received in the other WTRU's or base station's transmission (i.e., the COT structure indicated by the other WTRU). The WTRU may decide whether to share an existing COT or initiate a new COT depending on the information received in the COT information from another WTRU for the existing COT, where the information received in the COT information is described herein.

[0141] A WTRU may determine its LBT behavior based on one or a combination of factors associated with its own transmission and / or its own reception (e.g., when sharing a COT initiated by another WTRU). Here, the term combination may refer to using two or more factors in determining the LBT behavior. Combination may refer to eliminating one behavior due to the presence of one factor and selecting from the remaining behaviors based on other factors. Combination may refer to determining one LBT behavior based on a first factor and another LBT behavior based on a second factor. Combination may refer to determining the number or type of LBT behaviors to determine based on factors and simultaneously selecting a behavior based on another factor.

[0142] For example, any of the following factors may be used to determine the LBT behavior (e.g., LBT parameters) when initiating a COT: In addition, any of the following factors may be used to determine whether a WTRU can share an existing COT and / or which LBT behavior (e.g., LBT parameters) to use when accessing a channel to share the COT: Furthermore, the LBT behavior to be used when sharing a COT may depend on the following factors associated with the transmission that initiated the COT and / or the transmission planned by the WTRU that will share the COT: For example, in case of L2 ID, it may be the L2 ID used to initiate the COT and / or the L2 ID of the transmission sharing the COT).

[0143] Factors for determining the LBT behavior (e.g., LBT parameters) when initiating a COT may include: (1) a cast type, (2) a source / destination of the sidelink transmission, (3) a HARQ behavior, (4) a QoS of transmission / reception, (5) (minimum communication range (MCR) related quantities, (6) a zone related quantity, (7) a CBR related quantity, (8) a distance between two WTRUs, (9) a group related quantity, (10) a message type, (11) a SL channel or channel type, (12) a transmission or retransmission type, remaining PDB or time latency requirement, (13) based on any content included in the SCI associated with the transmission, (14) any parameters related to the sensing mechanism and / or sensing results, (15) associated with a resource pool, (16) an allocation mode, (17) a time between a previous transmission and the WTRU's own transmission, (18) a member ID in the group cast, (19) an L2 source / destination ID, and / or (20) related to a reservation of resources by the WTRU or another WTRU.

[0144] The cast type may refer to whether a planned or executed transmission corresponds to a unicast, a groupcast, or a broadcast. The cast type may refer to whether a received transmission corresponds to a unicast, a groupcast, or a broadcast. The cast type may refer to whether a WTRU has data of a particular cast type available for transmission. The cast type may refer to whether a WTRU has a particular unicast link established. The cast type may refer to whether a WTRU is interested in a service associated with a particular cast type. For example, a WTRU may use a first LBT type or category, or number of timeslots, to determine occupancy when a transmission / reception is unicast, and may use a second LBT type or category, or number of timeslots, to determine occupancy when a transmission / reception is broadcast / groupcast. For example, a WTRU may use a DL CAPC table for unicast transmissions and a UL CAPC table for groupcast / broadcast transmissions. For example, two WTRUs with unicast links may negotiate (possibly using PC5-RRC signaling) which of the WTRUs will use the DL CAPC table and which will use the UL CAPC table. For example, a WTRU may be configured with one or more COT lengths (possibly associated with other factors such as priority) to use for COT initiation for unicast transmissions, and another one or more COT lengths to use for COT initiation for groupcast / broadcast transmissions.

[0145] The source / destination of a sidelink transmission (e.g., an L2 ID) may indicate whether the L2 ID matches some (pre-)configured L2 ID or set of IDs for which a specific LBT behavior is required. The source / destination of a sidelink transmission may indicate whether the reception includes or is associated with one or any L2 ID. For example, the WTRU may receive an indication (from the network or from higher layers) of whether an L2 ID can enable COT sharing and / or LBT behavior and / or indirection number (or the like) to be applied for that L2 ID transmission and may determine the LBT behavior following transmission / reception of a PDU targeted to that L2 ID. For example, the WTRU may share a COT with a peer WTRU if the COT was initiated by a transmission by the peer WTRU to an L2 ID for which the WTRU is interested in receiving the L2 ID. For example, the WTRU may be allowed to transmit with a reduced LBT requirement (i.e., the LBT required to share the COT) following reception on an SL if the L2 ID associated with the transmission is the same as the receiving L2 ID (e.g., the transmission is performed on the same unicast link, the transmission is performed on the same groupcast L2 ID, etc.).

[0146] The WTRU may receive COT information from multiple peer UEs and may determine its own LBT behavior and / or whether to initiate / share a COT based on one or more of them. In one example, the WTRU may use COT information received from a peer WTRU associated with the longest / shortest indicated COT length, the highest / lowest indicated priority, a priority matching a condition associated with the transmitting WTRU's own data priority, the closest peer WTRU (in terms of distance between the peer WTRU and the transmitting WTRU receiving the COT information), etc.

[0147] In another example, the WTRU may decide whether to use one rule (e.g., COT information associated with minimum or maximum, highest / lowest priority, etc.) or another based on other factors herein, such as the priority of the WTRU's own transmission. For example, for a high priority transmission, the WTRU may use the COT information with the longest COT length, and for a low priority transmission, the WTRU may use the COT information with the shortest COT length.

[0148] The HARQ behavior may refer to whether a transmission / reception is associated with HARQ enabled or disabled. The HARQ behavior may refer to a (pre)configured HARQ delay or RTT on the sidelink. The HARQ behavior may refer to whether a HARQ specific channel (PSFCH or PUCCH) is configured. The HARQ behavior may refer to several potentially consecutive HARQ feedbacks of a particular type (ACK / NACK / DTX) that are possibly transmitted or received. The HARQ behavior may refer to the time required to send one or more HARQ feedbacks. The HARQ behavior may refer to the type of groupcast HARQ that is being used (e.g., ACK / NACK or NACK only). The HARQ behavior may refer to whether the WTRU transmits a HARQ ACK or a HARQ NACK.

[0149] The transmit / receive QoS may refer to the priority of the transmission. The transmit / receive QoS may refer to (pre-)configured parameters associated with the SLRB. The transmit / receive QoS may refer to a PQI or similar QoS parameter associated with a QoS flow. The transmit / receive QoS may refer to whether the transmission is on an SL SRB or an SL DRB. For example, the WTRU may assume a first set of LBT parameters to acquire a channel when the transmission is associated with a first priority and a second set of LBT parameters to acquire a channel when the transmission is associated with a second priority. For example, the WTRU may assume that the COT length, or the time to not perform a complete LBT following reception of another WTRU, is a first value if the received priority is the first priority and a second value if the received priority is the second priority.

[0150] The MCR minimum communication range (MCR) related quantity may refer to the value of the MCR transmitted / received by the WTRU. The MCR related quantity may refer to whether the MCR is transmitted. The MCR related quantity may refer to whether the WTRU determines that it is within the MCR of the transmission. The MCR related quantity may refer to the distance remaining before the WTRU is outside / inside the MCR. The MCR related quantity may refer to the calculated distance between the transmitter and the receiver. The WTRU may determine or modify its LBT parameters for a transmission following a reception from another WTRU based on the calculated distance between the WTRU and itself. The WTRU may always perform Type 1 LBT as long as the distance is above a threshold.

[0151] The WTRU may determine its LBT parameters based on the MCR of the transmission. Specifically, the WTRU may be configured with the CW length (or other parameters that affect its LBT) for the MCR or range of MCRs. For a TB associated with an MCR, the WTRU may select an appropriate CW length. The WTRU may be configured with an offset (e.g., an increase in CW length) to be applied for each increase in MCR from a particular baseline value. The WTRU may decide whether to use the UL CAPC table or the DL CAPC table based on whether the transmission has an MCR and / or a value of MCR (e.g., above or below a threshold). The WTRU may determine the length of the COT to create based on the number of WTRUs in the group (determined by higher layers).

[0152] The zone-related quantity may refer to a particular zone in which the WTRU is located and whether such zone is associated with (e.g., part of a list of) one or more (pre-)configured zones. The zone-related quantity may refer to whether the WTRU is located in the same zone as another WTRU. The zone-related quantity may refer to a configured zone size.

[0153] The CBR-related quantity may refer to the CBR measured at the WTRU. The CBR-related quantity may refer to whether the CBR is below or above a threshold. The CBR-related quantity may also refer to whether the CBR can be measured. The CBR-related quantity may also refer to the time period during which the CBR is measured.

[0154] The distance between two WTRUs may refer to a determined distance between two WTRUs (e.g., a WTRU initiating a COT and a WTRU sharing the COT), which may be calculated, for example, by a zone indication transmitted in the SCI.

[0155] The group-related quantity may refer to the number of WTRUs in a group. For example, the group-related quantity may refer to a group ID configured by higher layers. The group-related quantity may also refer to a groupcast HARQ feedback type (ACK / NACK or ACK only). For example, the WTRU may determine the length of the COT to create based on the group size (indicated by higher layers). Specifically, the WTRU may be configured with one or different COT lengths for a set size of groups and may select the COT length based on this configuration. For example, the WTRU may determine whether to share a COT initiated by a peer WTRU based on whether the peer WTRU's transmission was performed for an L2 ID. The WTRU may share a COT initiated by a peer WTRU if the COT was initiated by an L2 ID that the WTRU is interested in. Furthermore, the WTRU may determine its LBT behavior differently if the COT was initiated by an L2 ID that the WTRU is interested in and / or if the WTRU has been assigned a group number for that L2 ID. For example, the WTRU-initiated COT may include a group member ID in the transmission. The second WTRU may determine whether it can share a COT with the initiating WTRU and / or may determine the LBT behavior required for transmission based on its own group member ID compared to the group member ID of the initiating WTRU (e.g., the difference is less than a threshold).

[0156] The message type may indicate whether the transmission / reception consists of a specific message associated with the sidelink, such as a direct communication request (DCR) or other message associated with unicast link establishment, or includes a specific MAC CE, such as a CSI report or inter-WTRU coordination message. For example, the WTRU may assume upon reception / transmission of a DCR message that no LBT is required, or only a specific LBT, is required until the establishment of the unicast link for which the DCR message was initiated.

[0157] The SL channel or channel type may refer to whether the transmission / reception configuration is performed on a particular SL channel, e.g., SL-SSB, PSCCH, PSSCH, PSFCH, etc.

[0158] The transmission or retransmission type may indicate whether the transmission / reception consists of an initial transmission or a retransmission. For example, it may indicate the retransmission number associated with the retransmission.

[0159] The remaining PDB or time latency requirement may refer to the remaining PDB associated with a transmission at the time of the LBT, or may refer to the amount of time relative to T2 (or any sensing-based window or time frame). The remaining PDB or time latency requirement may refer to a CSI feedback latency bound, or the remaining time within that latency bound at the time of transmission. The remaining PDB or time latency requirement may refer to the relationship between the remaining PDB (or an equivalent metric such as priority) and the duration of the COT to be shared.

[0160] The content included in the SCI associated with a transmission may refer to the presence of the absence of any value in the SCI. For example, this may refer to the value of any field in the SCI. The content included in the SCI associated with a transmission may refer to whether the SCI is used to trigger a CSI report. The content included in the SCI associated with a transmission may refer to whether the SCI reserves any future resources. The content included in the SCI associated with a transmission may refer to the time between the current transmission and the future reserved resources (e.g., whether it is above or below a certain value).

[0161] Any parameters related to the sensing mechanism and / or sensing result may refer to a particular sensing mechanism (e.g., whether to use full sensing, partial sensing, random selection, etc.) used to determine resources for final transmission. The sensing mechanism may refer to whether asynchronous sensing is being performed. The sensing mechanism may refer to whether sensing is being performed for preemption / re-evaluation. The sensing mechanism may refer to a particular sensing result, such as either a percentage of available resources, a number of selected resources, a timing between selected resources, whether a retransmission resource was selected, whether a sufficient number of resources are available (at any given instance of availability determination), etc. The sensing mechanism may refer to an amount of resources considered available within a particular time, which may represent the COT, and / or a required latency of pending transmissions at the WTRU.

[0162] Associated with a resource pool may refer to a particular resource pool or configuration associated with a resource pool, and may apply when transmission / reception occurs on resources associated with that pool.

[0163] The allocation mode may refer to whether the transmission / reception is Mode 1 or Mode 2. The WTRU may determine whether it can share the COT (e.g., perform Type 2 LBT) based on the mode of transmission that initiated the COT and / or its own mode of transmission. A WTRU may share the COT if the WTRU seeking to share the COT uses the same transmission mode (Mode 1 or Mode 2) as the WTRU that initiated the COT. A WTRU transmitting using Mode 2 may / may not share the COT with a WTRU that initiated the COT using Mode 1 and / or Mode 2.

[0164] Another factor may be the time between the previous transmission and the WTRU's own transmission. If a WTRU detects another WTRU's transmission (previous transmission) occurring in slot N-1, it may transmit in slot N, assuming they share the COT. In addition, the previous transmission in slot N-1 may also need to meet other conditions herein (e.g., L2 ID / same unicast link, etc.).

[0165] Another factor may be the member ID in the groupcast. Specifically, the WTRU may assume a first LBT behavior when the member ID has a first value, and a second LBT behavior when the member ID has a second value. For example, a WTRU with member ID=0 may use the DL CAPC table for LBT, and a WTRU with any other member ID may use the UL CAPC table for LBT.

[0166] Another factor may be the L2 source / destination ID. Specifically, the WTRU may be configured (e.g., by PC5-RRC, by Uu RRC, by higher layers, etc.) with the LBT behavior to be applied for a given L2 ID or L2 ID pair.

[0167] Another factor may be related to the reservation of resources by a WTRU or another WTRU. For example, the reservation of resources by a WTRU or another WTRU may refer to whether a transmission is performed on a resource previously reserved by the WTRU (for a new TB or for a retransmission). Specifically, the WTRU may assume a first LBT behavior for transmissions not previously reserved and a second LBT behavior for transmissions it previously reserved. The reservation of resources by a WTRU or another WTRU may refer to whether a transmission is performed on a resource, following, or at a certain amount of time after a resource reserved by another WTRU. For example, the WTRU may use a first LBT behavior (e.g., short LBT) in slots following a slot reserved by another WTRU and a second LBT behavior (e.g., normal LBT) in slots not following a slot reserved by another WTRU. A similar approach may be used to solve blocking problems for unauthorized V2X.

[0168] Specifically, if a WTRU fails an LBT on slot n-1 for a transmission on slot n, and slot n-1 is associated with a slot where the sensing result indicates that another SL WTRU has performed a transmission, the WTRU may perform short sensing only at the beginning of slot n. Otherwise, the WTRU may perform a normal LBT procedure following the LBT failure.

[0169] Any of the above factors associated with or indicated by a transmission decoded / received by the WTRU, such transmission was either included in the COT that the WTRU wants to share or is associated with the transmission that initiated the COT. As used herein, characteristics of the transmission that initiated the COT, characteristics of the last detected transmission in the COT, or characteristics of any given transmission occurring within the COT may be used interchangeably.

[0170] Although not explicitly mentioned in the following embodiments, any combination of specific LBT behaviors and specific sidelink factors listed above can be envisaged by one skilled in the art.

[0171] In one embodiment, the WTRU may determine the CAPC based on one or more of the above sidelink coefficients. Specifically, the WTRU may determine from the data being transmitted one or more data associated with its transmission and may select the CAPC accordingly. The WTRU may also indicate such a CAPC in its own transmission, possibly when the WTRU starts a COT (as opposed to when the WTRU shares an existing COT).

[0172] The WTRU may be configured to select a CAPC based on a combination of the cast type and the LCH configuration. Specifically, the WTRU may be configured with a CAPC to use for a given logical channel priority and each of unicast, groupcast, or broadcast. For example, if a transmission is associated with unicast, the WTRU may select a CAPC configured for the priority of the LCH for unicast. In such a case, the WTRU may be configured with a mapping of both priority and cast type to a CAPC.

[0173] The WTRU may determine a CAPC based on the determined MCR of the transmission. For example, the WTRU may be configured with a CAPC to be used for a combination of priority and MCR, which may include a range of MCRs or whether the transmission is configured with / without MCR.

[0174] The WTRU may determine the CAPC based on whether HARQ is enabled or disabled for a transmission. For example, the WTRU may be configured with a first set of CAPCs to use for HARQ-enabled transmissions (e.g., per LCH or per priority) and a second set of CAPCs to use for HARQ-disabled transmissions.

[0175] The WTRU may determine the CAPC based on the measured CBRs of the sidelink resources. Such CBRs may be similar to legacy SL measured CBRs or may be adapted to a shared spectrum scenario. For example, the WTRU may be configured with a first set of CAPCs (e.g., per priority or per LCH) to use for a first range of CBRs, a second set of CAPCs to use for a second range of CBRs, etc.

[0176] The WTRU may use a fixed, predefined, or (pre)configured CAPC for a particular sidelink transmission, or if the SL transmission includes a particular message. For example, a DCR message may use a fixed CAPC. For example, a SL MAC CE may use a fixed CAPC. Alternatively, the WTRU may use any CAPC for a particular SL transmission, or a transmission including a particular message (e.g., DCR).

[0177] The WTRU may be configured with a particular CAPC to use for transmissions involving the SL MAC CE.

[0178] The WTRU may be configured with different values ​​of CAPC to use for transmissions including SL CSI MAC CE, and each CAPC value may correspond to one or a range of configured latency limits or remaining times in the latency limits for transmission of a CSI report to a peer WTRU.

[0179] The WTRU may use a first CAPC value or set of values ​​for Mode 1 transmissions and may use a second CAPC value or set of values ​​for Mode 2 transmissions.

[0180] The WTRU may determine the CAPC to use based on the HARQ feedback resource timing. The WTRU may select from (pre-)configured CAPCs associated to the time difference between the selected resource and the timing of the PSFCH resource associated to the transmission.

[0181] The WTRU may determine the CAPC to use based on the L2 destination ID associated with the transmission. For example, the WTRU may be configured with a CAPC associated with a source / destination L2 ID and may use that CAPC for all (subsequent) transmissions to that source / destination L2 ID. For example, the WTRU may determine the CAPC based on higher layer information (e.g., TX profile, DRX on / off, explicit information) provided by higher layers along with the destination L2 ID. For example, the WTRU may maintain / change the CAPC associated with an L2 ID based on an SL event (e.g., HARQ, LBT failure, etc.) and may apply the CAPC for that L2 ID until changed by the next event.

[0182] The WTRU may determine the CAPC to be used based on the QoS flows active / configured for a particular transmission on the L2 ID. Specifically, the WTRU may determine the CAPC for a given L2 ID transmission based on PQI information associated with one or more QoS flows active for that L2 ID. The WTRU may select the flow with the highest value of a parameter (e.g., priority) and determine the CAPC for the L2 ID based on that parameter.

[0183] The WTRU may use different rules, mapping tables, or criteria to determine the CAPC depending on the SL-specific factors or characteristics described herein. For example, the WTRU may use a mapping of PQI to CAPC to determine the CAPC for Mode 1 transmission, and may use a mapping of L1 priority or LCH priority to CAPC to determine the CAPC for Mode 2 transmission. For example, the WTRU may use a first mapping table when the CBR is above a threshold and a second mapping table when the CBR is below a threshold.

[0184] The WTRU may determine the CAPC using different rules, mapping tables, and / or criteria (or the like) depending on the actual values ​​of the QoS parameters or other values ​​originally used to determine the CAPC. For example, the WTRU may use a PQI-to-CAPC mapping table to determine the CAPC for a transmission that includes data for a QoS flow.

[0185] However, in the case of non-standardized PQI values, the WTRU may use different approaches, such as: (1) using a fixed CAPC value; (2) using a table that maps priority to CAPC instead of mapping PQI to CAPC; (3) using the CAPC value associated with the PQI whose QoS parameters are closest to the PQI parameters of the standardized PQI associated with that CAPC; (4) using the CAPC value assigned by the network (e.g., in the DCI) for the last transmission associated, possibly with the same or similar QoS or priority / QoS; and / or (5) using the CAPC value indicated by the peer WTRU in the SL transmission or configured by the peer WTRU in PC5-RRC (e.g., as the default CAPC value to be used).

[0186] A WTRU may use any factor or rule specific to the SL to determine rules associated with COT sharing with a COT initiated by another WTRU and / or a base station (e.g., a gNB). Such factors may include, but are not limited to, any of the following: (1) the maximum time between the last transmission in the COT and the time the WTRU may transmit in the COT without performing an LBT, and / or the type of LBT performed for each amount of time, or (2) whether the WTRU is permitted to share a COT initiated by another WTRU and / or a base station (e.g., a gNB) or whether the WTRU must initiate its own COT (i.e., perform a complete LBT). The permission may be different for a WTRU-initiated COT and a base station (e.g., a gNB)-initiated COT. Such factors may also include other LBT properties mentioned herein that describe factors for sharing an already initiated COT (e.g., any of the factors described above that may determine the LBT behavior, etc.).

[0187] For example, the WTRU may determine the COT sharing rule based on the zone ID transmitted by other WTRUs and the WTRU's own zone ID. The zone ID may represent the distance between the WTRU initiating the COT and the WTRU that determines whether to share the COT initiated by the other WTRU. The WTRU may determine that the COT can be shared if the distance is smaller than a threshold.

[0188] The WTRU may determine a COT sharing rule based on the L2 ID (e.g., destination L2 ID) of the transmission that initiated the COT. For example, the WTRU may share a COT initiated by another WTRU if the L2 destination ID of the COT initiated transmission is the same as the L2 destination ID (or in a set of associated L2 destination IDs) of a transmission made by the WTRU that shares the COT. Furthermore, the WTRU may be configured with LCP restrictions for grants in a shared COT, whereby such restrictions may apply to permissible (possibly destination) L2 IDs that may be selected for such grants. The WTRU may select only L2 destination IDs that are permitted to share a COT initiated by another WTRU to perform transmissions in grants occurring within a COT initiated by another WTRU.

[0189] The WTRU may determine a COT sharing rule based on the MCR associated with the transmission that initiated the COT and / or whether the WTRU is within the MCR of that transmission. For example, if the COT was initiated with a transmission that includes an MCR, and if the WTRU is within the MCR, the WTRU may share the COT for transmissions with the same / associated L2 destination ID. If the WTRU is outside the MCR, the WTRU may not share the COT for transmissions with the same / associated L2 ID.

[0190] The WTRU may determine the COT sharing rule based on the cast type of the transmission, e.g., the WTRU may apply a first maximum gap between transmissions for unicast, a second maximum gap between transmissions for groupcast / broadcast, etc.

[0191] The WTRU may decide whether to share the COT based on the number of available resources that can be determined within the duration of the COT (e.g., based on sensing). Specifically, if the number of available resources within the duration of the COT and / or within the required latency is above a threshold, the WTRU may decide to share the COT, otherwise the WTRU may decide to start a new COT.

[0192] The WTRU may decide whether to share the COT or start a new COT based on the remaining duration of the COT and the priority / PDB of the pending transmission. Specifically, the WTRU may be configured with an association between a priority / LCH and a required remaining duration of the COT. The remaining duration of the COT may further represent the time within the remaining duration in the COT that is in the PDB of the transmission. If the remaining duration is less than the required remaining duration for that priority / LCH, the WTRU may not share the COT and may start a new COT.

[0193] The WTRU may determine its LBT behavior based on a particular network scheduling node (e.g., a base station (gNB), a cell, etc.).

[0194] The first WTRU may transmit a network node ID (e.g., cell ID, base station (gNB) ID, etc.) in its transmission on the sidelink, possibly as part of the COT information. The WTRU may include the network node when it is scheduled in Mode 1. Alternatively, a Mode 2 WTRU may transmit a network node ID when performing Mode 2 transmissions while in coverage of and / or RRC_CONNECTED to a particular network node.

[0195] The second WTRU may determine its LBT behavior based on any or a combination of the following: the network node received from the first WTRU's transmission; the network node associated with the second WTRU's own scheduling (e.g., the cell ID scheduling the WTRU if in Mode 1, the cell ID the WTRU is RRC_CONNECTED and camped on RRC_IDLE / RRC_INACTIVE if in Mode 2); whether the second WTRU is in or out of coverage of the same node as the case may be; the transmission mode (Mode 1 or Mode 2) of the second WTRU's transmission; and other factors affecting LBT behavior as described herein.

[0196] A WTRU in Mode 1 may be allowed to share a COT initiated by another WTRU if the other WTRU is also in Mode 1 and scheduled with the same cell ID. A WTRU in Mode 2 may be allowed to share a COT initiated by another WTRU if the cell ID included in the COT information from the other WTRU matches the cell ID of the cell to which the WTRU is connected / camped. For example, the WTRU may perform LBT using a first set of parameters if its own cell ID matches the cell ID received with the COT information, and may perform LBT using a second set of parameters if its own cell ID does not match the cell ID received with the COT information.

[0197] The LBT behavior may be determined based on a list of associated / interesting L2 IDs provided to the WTRU.

[0198] In one embodiment, the LBT behavior (e.g., whether a WTRU can share a COT) may be determined based on a combination of the WTRU's own destination L2 ID and a list of L2 IDs received by the WTRU from either another WTRU or a base station (e.g., gNB). Specifically, the WTRU may determine its LBT behavior based on whether the L2 ID of a transmission associated with the LBT matches any L2 ID included in the received list. The list of L2 IDs received by the WTRU may represent L2 IDs of interest associated with another WTRU, and in some cases, such a WTRU may have initiated a COT. This is to allow the sidelink system to restrict COT sharing to transmissions for which the WTRU that initiated the COT should be the intended recipient of the transmission sharing the COT.

[0199] In one embodiment, the first WTRU may transmit its L2 IDs of interest (e.g., L2 IDs of any groupcast / broadcast services of interest and / or source / destination ID pairs of any ongoing unicast links) to one or more other WTRUs. For example, the first WTRU may transmit such information, possibly associated with unicast link establishment with the second WTRU, in PC5-RRC signaling. For example, the first WTRU may transmit updated information upon any change of such information (i.e., change of interested destination L2 ID signaling by higher layers, addition / removal of unicast links to which the WTRU has associated itself, etc.). Alternatively, the first WTRU may transmit the list along with the transmission in the COT itself. For example, the first WTRU may transmit the list in a MAC CE included in its SL transmission.

[0200] The second WTRU may receive the list of L2 IDs from the first WTRU and may use that information to determine whether to share the COT initiated by the first WTRU. For example, the second WTRU may associate the list of L2 IDs from the first WTRU with the source / destination L2 ID of the unicast link with the first WTRU. When the first WTRU determines whether it can share the COT initiated by the first WTRU, it may determine whether the destination L2 ID of the second WTRU's transmission matches any L2 ID in the list received from the first WTRU. If the source / destination L2 ID of the transmission is one of the source / destination L2 IDs in the received list, the second WTRU may share the COT with the first WTRU, otherwise the second WTRU may not share the COT with the first WTRU.

[0201] In another embodiment, the second WTRU may receive a list / relationship from a base station (e.g., gNB). For example, the second WTRU may receive a list of L2 IDs of interest associated with each source / destination L2 ID representing a peer WTRU in unicast. The second WTRU may determine to apply the list to the first WTRU's transmission based on the source / destination L2 ID provided with the list from the base station (e.g., gNB). In another example, the second WTRU may receive a list of associated L2 destination IDs from a base station (e.g., gNB). Such a list of associated destination L2 IDs may represent groupcast transmissions that may share a COT. For example, if the L2 destination ID of the first WTRU transmission and the destination L2 ID of the second WTRU's transmission occur in the same list, the second WTRU may share a COT with the first WTRU.

[0202] The use of the list and how to decide whether to share the COT may depend on the cast type of the transmission from the first WTRU and / or the cast type of the transmission from the second WTRU. For example, the second WTRU may use any or a combination of the following decisions regarding whether to share the COT initiated by the first WTRU. These decisions may also apply more generally to an embodiment that does not assume the use of a list.

[0203] In one decision, if a first WTRU transmission is unicast to a second WTRU, the second WTRU may share the COT as long as the second WTRU is performing a unicast transmission to the same unicast link.

[0204] In another decision, if the first WTRU transmission is unicast to the second WTRU, the second WTRU may share the COT as long as the second WTRU is performing a unicast transmission associated with a source / destination L2 ID pair that matches a destination / source L2 ID in the list received from / for the first WTRU.

[0205] In another determination, if the first WTRU transmission is a groupcast / broadcast, the second WTRU may share the COT as long as the second WTRU is performing a groupcast / broadcast transmission associated with a destination L2 ID that matches a destination L2 ID in the list received from the first WTRU. Alternatively, if the first WTRU transmission is a groupcast / broadcast, the second WTRU may share the COT as long as the second WTRU is performing a groupcast / broadcast transmission to the same destination L2 ID as the first WTRU's transmission. Furthermore, the second WTRU may use this latest condition only if the second WTRU does not have a list associated with the first WTRU.

[0206] The embodiments described above may be generalized to any behavior associated with an LBT for accessing a channel for a second WTRU as described herein. Specifically, the second WTRU may use the list to determine whether to perform a first type or a second type of LBT. For example, the second WTRU may use the list to determine whether to use a first CW or a second CW.

[0207] The WTRU may determine whether to share the COT based on multiple conditions associated with different factors being satisfied or at least one condition associated with different factors being satisfied. For example, the WTRU may share the COT if the time between the previous transmission and the WTRU's planned transmission is less than a threshold and the L2 destination of the WTRU's transmission matches the L2 ID of the transmission that initiated the COT. The WTRU may share the COT if the L2 destination ID of its transmission matches the L2 destination ID of the transmission that initiated the COT or if the WTRU is less than a certain distance from the transmission that initiated the COT.

[0208] The WTRU may use different conditions / factors to determine whether to share the COT based on whether another condition / factor is met / tested. For example, if the time between the previous transmission and the WTRU's own transmission is within a first range, the WTRU may share the COT as long as the L2 IDs match, and if the time between the previous transmission and the WTRU's own transmission is within a second range, the WTRU may share the COT as long as the distance between the WTRUs is less than a threshold.

[0209] FIG. 2 illustrates an example of unicast COT sharing. As shown in FIG. 2, if a COT is initiated by the second WTRU 204 for a transmission associated with the same unicast link as the first WTRU 202's transmission, the first WTRU 202 may share the COT. The first WTRU 202 may make this decision based on the L2 source / destination ID included in the SCI that initiated the link. Specifically, if the L2 source ID of the first WTRU 202's transmission is the same as the L2 destination ID of the second WTRU 204 and the L2 destination ID of the first WTRU 202's transmission is the same as the L2 source ID of the second WTRU 204, the first WTRU 202 may share the COT. Otherwise, the first WTRU 202 may not share the COT.

[0210] Alternatively, if the COT is initiated by a second WTRU 204 with which the first WTRU 202 has a unicast link, the first WTRU 202 may share the COT regardless of the destination of the transmission of the first WTRU 202. Specifically, if the COT is initiated by a transmission with a source / destination L2 ID pair that corresponds to a unicast link that is active in the first WTRU 202, the first WTRU 202 may share the COT for any transmission.

[0211] Alternatively, any of the conditions described above may be used to determine whether to share a COT, although the transmission from the second WTRU 204 in question may be one that occurs within the COT, and not necessarily one that starts the COT. Specifically, as described above, a WTRU may share a COT for a transmission associated with a unicast link if another WTRU associated with the same unicast link has performed a transmission within the same COT that should be shared.

[0212] Whether a WTRU is permitted to perform either of the above alternatives (one alternative versus another alternative) may further depend on other SL factors (e.g., transmission priority) herein. For example, as shown in FIG. 2, the second WTRU 204 may transmit in the COT initiated by the first WTRU 202 because the WTRUs 202 and 204 share a unicast link. However, the third WTRU 206 cannot transmit in the COT initiated by the first WTRU 202 because the WTRUs 202 and 206 do not share a unicast link.

[0213] A COT may be associated with or identified to be of a particular type, and such type may be determined by one or more sidelink factors. For example, a COT may be a Mode 1 COT or a Mode 2 COT depending on whether it is initiated by a Mode 1 transmission or a Mode 2 transmission. Alternatively, a COT may be mode independent (or may not be specific to any mode). For example, a COT may be a unicast COT, a groupcast COT, or a broadcast COT. Alternatively, a COT may be cast type independent. For example, a COT may be a sensing-based COT, a random selection COT, etc. A COT may be a HARQ feedback-based COT or a non-HARQ feedback-based COT.

[0214] A WTRU initiating a particular type of COT may indicate the COT type in its transmission. Such a COT type indication may be carried, for example, in an SCI, a dedicated PHY channel, a MAC CE, a CG-UCI, a SL RRC message, etc. Alternatively, the COT type may be implicitly determined based on other information included in the sidelink transmission by the WTRU initiating the transmission or by other WTRUs transmitting within the COT.

[0215] A WTRU that initiates a particular type of COT may be configured with the LBT behavior (as defined herein) to be used when initiating such COT (e.g., CW size, maximum allowable COT length, etc.).

[0216] A WTRU may determine its COT sharing rule (as defined herein) based on the COT type and any sidelink factors that may be associated with its own transmission to be performed within the COT. A WTRU may be allowed to share a particular type of COT for unicast transmissions, but not for broadcast transmissions. A WTRU may be allowed to share a particular type of COT for Mode 1 transmissions, but not for Mode 2 transmissions. A WTRU may be allowed to share a particular type of COT only for HARQ feedback enabled / disabled transmissions. A WTRU may be allowed to share a COT if the COT type matches the type of data being transmitted by the WTRU. A WTRU may be configured with different COT sharing rules or different LBT parameters depending on whether the transmission is associated with a COT type. A WTRU may be allowed to share a particular type of COT only for PSFCH transmissions. A WTRU may be allowed to share a particular type of COT if the transmission is associated with a particular priority or has a priority greater / less than a threshold. The WTRU may be configured with LCP restrictions to enable whether the LCH uses the grant associated with the COT type. The COT may be considered a "universal" COT (i.e., usable by all other WTRUs / transmissions) or a specific type of COT (usable only by a single WTRU or WTRU pair or WTRU base station pair or transmission of a specific type).

[0217] The WTRU may decide whether to initiate a particular type of COT based on one or a combination of the following: (1) sidelink specific factors mentioned herein and associated with the data to be transmitted (e.g., cast, HARQ enabled, mode, etc.), (2) measured CBR, (3) measured channel occupancy, possibly associated with WiFi (which may be determined based on LBT statistics, RSSI measurements, channel occupancy or interference levels, etc.), and / or (4) instructions from higher layers, possibly associated with the number of WTRUs in the area, or possibly attempting to share resources. For example, based on one or a combination of the above factors, the WTRU may decide to initiate a universal COT, or a particular type of COT.

[0218] In one embodiment, a WTRU may determine a COT sharing rule (e.g., whether a COT may be shared, a maximum time after a transmission that a COT may be shared, and / or a maximum time that a particular type of LBT may be applied) based on whether the WTRU can hear a particular WTRU that initiated a COT and / or a level of indirection to such WTRU that initiated a COT. For example, a WTRU that initiated a COT may be a WTRU that performed a Type 1 LBT (or a full LBT) prior to performing its transmission.

[0219] For example, a TX WTRU initiating a COT may transmit (e.g., in an SCI) an indication that it is the WTRU that initiated the COT (e.g., a value of 0). A TX WTRU sharing a COT may transmit (e.g., in an SCI) an indication associated with the indirection level associated with the WTRU that initiated the COT. Specifically, if a first WTRU shares a COT initiated by a second WTRU, the first WTRU may transmit an indication representing a first level of indirection (e.g., a value of 1). A WTRU sharing a COT initiated by another WTRU may, for example, always increment the indirection level it transmits in an SCI by 1 from the minimum value received in any SCI associated with that COT, and so on. A WTRU wishing to share a COT initiated by another WTRU may use such an indication (possibly in addition to other factors herein, such as time since last transmission and / or cast type or mode) to determine whether it may share the COT and / or what type of LBT to perform to share the COT.

[0220] For example, a WTRU may share a COT initiated by another WTRU if it determines that the other WTRU has initiated a COT. A WTRU may share a COT initiated by another WTRU if it determines that a level of indirection received from a transmission (possibly the last transmission, or any transmission) in the COT is below a threshold. Such a threshold may further depend on any sidelink specific factors (e.g., priority) mentioned herein.

[0221] For example, a WTRU may determine the type of LBT to perform to share the COT with a peer WTRU based on a combination of the indirection level and the time gap between transmissions. Specifically, during a particular time gap since the last transmission in the COT, the WTRU may use a first LBT type for a first indirection level, a second LBT type for a second indirection level, etc.

[0222] 3 illustrates an example of groupcast / broadcast COT sharing. As shown in FIG. 3, the WTRU 302 may start the COT using a first set of LBT parameters (i.e., LBT(0)). Now that the WTRU 302 has started the COT, it may send an indirect value of 0 in the SCI transmission 320 in the COT.

[0223] The WTRU 304 may receive the COT information from the WTRU 302 and determine to share the COT with the WTRU 306. The WTRU 304 may perform the LBT procedure using the second set of LBT parameters (i.e., LBT(1)) as it represents an indirection level of 1. The WTRU 304 may also transmit an indirection value of 1 in the SCI transmission 322.

[0224] The behavior of the WTRU 306 is similar to that of the WTRU 304. The WTRU 306 may receive the COT information from the WTRU 04 and determine to share the COT with the WTRU 308. The WTRU 306 may perform the LBT procedure using a third set of LBT parameters (i.e., LBT(2)) since it represents an indirection level of 2. The WTRU 306 may also transmit an indirection value of 2 in the SCI transmission 324.

[0225] The WTRU 308 detects COT information for the same COT from both the WTRU 302 and the WTRU 306, but with conflicting indirection numbers. The WTRU 308 receives an indirection value of 2 from the WTRU 306 via the SCI transmission 224 and an indirection value of 0 from the WTRU 302 via the SCI transmission 326. The WTRU may determine to follow the minimum indirection number of 0 from the WTRU 302 and behave as a WTRU in the first indirection level. Additionally, the WTRU 308 may transmit an indirection value of 1 in any SCI transmission 328 to additional WTRUs.

[0226] A potential problem that may arise with distributed COT sharing is caused by the hidden node problem. Specifically, a first WTRU may start a COT and transmit COT information. A second WTRU that does not receive COT information from the first WTRU (due to the hidden node problem) may also start its own COT. The second WTRU may start a COT well into the COT of the first WTRU. This may result in a sidelink WTRU occupying the channel longer than the fairness requirement.

[0227] In one embodiment, a WTRU may modify its assumed COT structure following receipt of a conflicting COT structure from another WTRU. The conflicting COT structures may encompass different assumed LBT behaviors (e.g., different CAPC, different required LBT type, etc.) associated with the COT. For example, if the received CAPC is lower / higher than the assumed CAPC, the WTRU may consider this a conflict. The conflicting COT structures may also encompass different COT lengths. For example, a shorter COT length (or a COT indicated by another WTRU that ends earlier than the COT assumed by the WTRU) may be considered a conflict.

[0228] The WTRU may adopt COT information received from other WTRUs in case of a conflict. The WTRU may also modify the COT information it transmits to comply with the new information in case of a conflict. The WTRU may cancel a planned transmission when it receives conflicting COT structure information, possibly if the received COT structure does not allow the transmission. The WTRU may inform the network upon receipt of a conflicting COT structure.

[0229] In another embodiment, an SL WTRU configured in Mode 1 with SL transmissions on an unlicensed spectrum may receive an SL grant from a base station and determine whether the SL grant falls within a COT initiated by another WTRU based on COT structure information received from the other WTRU's SCI transmission. If the SL grant falls within a COT initiated by another WTRU, the WTRU may perform a first LBT type to attempt to share the COT. If the SL grant is not included within a COT initiated by another WTRU, the WTRU may perform a second LBT type to attempt to initiate its own COT. If the LBT fails for a grant, the WTRU may report the failed LBT to the base station in the UCI.

[0230] If the LBT is successful, the WTRU may determine the COT length and report the remaining COT length in the UCI (depending on which method was used) to the base station (e.g., gNB) and may report to the base station (e.g., gNB) whether the first WTRU initiated its own COT or shared another WTRU's COT. In the case of WTRU-initiated COT, the WTRU may determine the COT length based on the data multiplexed in the SL grant. In the case of shared COT, the WTRU may determine the COT length from the COT length received in the SCI of another WTRU.

[0231] An SL WTRU configured in Mode 1 may report to the base station the success / failure of initiating or sharing the COT and the time remaining in the COT (determined differently depending on whether the COT is shared or initiated). An SL WTRU may determine whether it can share a COT initiated by another WTRU based on a combination of the transmission priority and an indirect number received from another WTRU.

[0232] In one embodiment, a SL WTRU may determine whether it can share a COT initiated by another WTRU with the LBT parameters to use for transmitting on that COT by receiving COT information from one or more other WTRUs including an indirection number associated with that COT, and may determine that the COT can be shared if the minimum indirection number received by the WTRU associated with that COT is less than a threshold configured based on the priority of the data to be transmitted, and may perform the LBT using parameters determined by the indirection number and the priority. If the WTRU acquires a channel, it may transmit an indirection number that is one greater than the received indirection number. Otherwise, the WTRU may determine that it cannot share a COT initiated by another WTRU and may initiate its own COT.

[0233] In another embodiment, a WTRU operating in Mode 2 may perform resource selection based on the existence and / or structure of an existing or expected COT on the SL. The COT may include COTs initiated by other WTRUs (and indicated in the SCI by them) or COTs initiated by the WTRU performing resource selection. In this specification, an existing COT is a COT initiated by a WTRU or another WTRU through the transmission of an SCI, possibly following a complete LBT procedure. An expected COT may include a resource or set of resources that may be expected to be part of the COT as a result of a future transmission by the WTRU announced in the SCI. Methods for resource selection in this specification that rely on the existence of a COT may be applied to either an existing COT or an expected COT, possibly with the same / different rules.

[0234] A WTRU performing Mode 2 resource selection may take into account the existence and / or structure of an existing or expected COT by selecting resources within or associated with the COT, including limiting or prioritizing resource selection to resources within the COT. In the context of resource selection, prioritizing resources within the COT may include, but is not limited to, the following: (1) selecting resources within the COT with a higher priority than selecting resources outside the COT, (2) selecting more resources within the COT than outside the COT, (3) selecting resources within the COT more times than selecting resources outside the COT, (4) selecting resources within the COT if the transmission duration on the resource falls within the remaining time in the COT, (5) selecting resources within the COT if the start time of the transmission resource fit is equal to or less than a predefined threshold from the end of the COT, (6) providing available resources (to the MAC layer) for resource selection such that a greater percentage of the number of available resources is inside the COT than outside the COT, and (7) providing available resources (to the MAC layer) for resource selection such that the amount or proportion of available resources inside the COT is greater (compared to when prioritization of resource selection inside the COT is not performed). Resource selection may include ensuring that the start of the selected resource is within the COT. Selection of a resource may also include ensuring that the start of a resource occurs at a maximum time following the start of the COT, and therefore ensuring that at least the initial transmission resource is within the COT.

[0235] A WTRU performing Mode 2 resource selection may take into account the existence and / or structure of an existing or expected COT by selecting resources associated with a particular type of COT. The type of COT may be a COT associated with one or more factors described herein (e.g., an indirect number meets a criterion, a cast type is associated with a particular criterion, an L2 ID meets a criterion, etc.). The type of COT may be a selected (if initiated by the WTRU) or indicated (if initiated by another WTRU) COT, where the CAPC is a particular value or is below / above a threshold. The resources may be associated with FBE or LBE resources. The type of COT may be a COT initiated by another WTRU (i.e., a shared COT) or a COT initiated by the WTRU itself (e.g., associated with a requested LBT type - type 1, 2, or 4 - or associated with associated LBT configuration parameters such as congestion period or backoff).

[0236] A WTRU performing Mode 2 resource selection may take into account the existence and / or structure of an existing or expected COT by selecting resources by determining parameters associated with the resource selection depending on the existence and / or structure of the COT. The determination may include using a first set of parameters when the selection is performed within the COT or COT type, and using a second set of parameters when the selection is performed outside the COT or in another COT type. The time gap between the last transmission made on the resource and the start of the next SL transmission intended by the WTRU using the same resource. The duration of the transmission on the SL data resource and whether it fits within the remaining time in the COT. The determination may include adapting the parameters of the resource selection depending on the timing of the resource relative to the start / end of the COT.

[0237] The WTRU may determine parameters associated with resource selection, which may include (but are not limited to) any of the following: number of retransmission resources, number of consecutive resources the WTRU should select from, minimum / maximum time between transmission / retransmission, pattern of resources such as number of time / frequency consecutive resources selected, maximum / minimum number of RBs, duration of a given transmission / retransmission resource, total number of resources that can be selected, possibly associated with COT / COT type, whether periodic resource selection or one-shot resource selection is performed / allowed.

[0238] The WTRU may select resources by considering the COT based on one or more conditions. For example, the WTRU may decide whether to select resources by considering the COT if the condition is met (or not otherwise). The WTRU may determine a particular behavior when considering the COT if the condition is met and may use a different behavior when considering the COT if the condition is not met. For example, the WTRU may use a first set of parameters when selecting resources by considering the COT when a first condition is met and a different set of parameters otherwise. For example, the WTRU may select resources associated with a first type of COT under a first condition while selecting resources associated with a second type of COT under a second condition.

[0239] The condition may relate to the type of data available for transmission (e.g. QoS, LCH, MAC CE vs. data, SRB vs. DRB, etc.). The condition may be the presence of data available for transmission with a certain priority. The condition may be whether the available data consists of MAC CE only, or whether the available data includes MAC CE and data or only data. For example, the condition may be whether the available data consists of SRB bits only, or whether the available data includes SRB data. The condition may be the presence of control information available for transmission, possibly with a certain priority. The control information may be SCI multiplexed on data resources or SCI transmitted on control resources.

[0240] The condition may relate to a configured condition associated with the data. For example, one or more LCHs may be configured to have a particular behavior described herein with respect to resource selection associated with COT. The LCH may trigger resource selection from LBE / FBE resources. For example, if data is available for a particular LCH associated with a configured condition, the WTRU may select a resource by considering the COT information / structure. Otherwise, the WTRU may not consider the COT structure during resource selection. For example, the condition may be whether the LCH is configured with HARQ enabled or disabled. The condition may be whether the LCH is configured with MCR and / or a condition regarding the value of MCR.

[0241] The condition may be related to a measurement of SL, such as CBR, SL RSRP, SL CSI, etc. For example, the condition may be that the SL CBR or SL RSRP associated with a unicast link is above / below a threshold.

[0242] The condition may be related to a cast type of the data available for transmission. For example, the condition may be that the data available for transmission that triggers the resource selection is associated with a particular cast type.

[0243] The condition may be related to the existence of a COT initiated by the WTRU performing the resource selection, for example, the condition may be that the WTRU has an active COT initiated at the time of resource selection.

[0244] The condition may relate to the presence, proportion, or amount of available resources that fall within the COT. For example, the condition may be that the percentage of available resources that fall within the COT is above a threshold.

[0245] The condition may relate to the number of COTs currently initiated by the WTRU.

[0246] The condition may relate to whether the TB is a retransmission. For example, the WTRU may select a resource if the TB is a retransmission (possibly after several retransmissions or LBT failures). The retransmission may be due to a previous LBT failure, due to receiving / determining a NACK, or due to not receiving HARQ feedback for an already transmitted TB. In one example, the WTRU may retransmit the TB using a different resource or resource pool if it receives a NACK, if the LBT fails, and / or if it has not received HARQ feedback. The WTRU may monitor for HARQ feedback on a different resource or resource pool if HARQ feedback is not received at the expected time following the TB transmission.

[0247] The condition may relate to whether consistent LBT failures are detected on resources associated with the first type of COT.

[0248] The condition may relate to the number of COTs initiated by the WTRU over a recent period of time. For example, the condition may be that the WTRU has initiated at least N COTs over a (pre-)configured past period of time.

[0249] In one embodiment, the WTRU may associate a resource (eg, a timeslot, a set of timeslots, a subchannel, a set of subchannels, etc.) with one or more properties associated with the COT.

[0250] In one embodiment, a resource may be considered to be within the COT, or outside the COT, or to overlap partially with the COT (i.e., part of the resource is within the COT and part of the resource is outside the COT). For example, a resource may be within the COT if it will end within the time remaining in the COT. In another embodiment, a resource may be considered to be in the COT for a given indirection number or range thereof, as described herein; or

[0251] In yet another embodiment, resources may be considered to be FBE (frame-based equipment) or LBE (load-based equipment). Specifically, resources may be tagged as resources that allow channel access using FBE rules or channel access using LBE rules. The WTRU may determine this access type based on configuration from higher layers (e.g., RRC or SIB configuration) or based on LCH configuration (e.g., some LCHs may be transmitted on FBE resources).

[0252] The WTRU may be (pre-)configured or pre-determined with the number of times the COT can be (re)shared with other WTRUs. Configuration from higher layers may configure that the COT can be shared no more than x times. The WTRU may include in the SCI or COT sharing MAC CE the number of times this COT has been shared, along with the remaining time in the COT. When the WTRU acquires the COT for the xth time, the WTRU may omit the SCI or MAC CE associated with the COT sharing to other WTRUs. Alternatively, the WTRU may include an indication (e.g., in the SCI or MAC CE) indicating that this COT can no longer be shared. The WTRU may stop using the COT at the end of the xth transmission in which it was acquired, or may occupy the COT until the MCOT is performed.

[0253] In one embodiment, the WTRU may be configured with a subset of sidelink data resources that can be used at a particular timing. The WTRU may attempt to acquire the channel only at some timing offsets associated with the resources. The WTRU may be configured to select and perform LBT only for resources starting within a given slot offset from a radio frame boundary that corresponds to the applicable offset. The WTRU may be configured with a subset of possible offsets within a radio frame or slot. If the LBT procedure fails, the WTRU may attempt to acquire the channel at the next possible offset.

[0254] The WTRU may semi-statically determine the offset from a configured value or as a time to the next available resource. Alternatively, the WTRU may dynamically determine the offset. The dynamic determination may depend on: (1) the priority of the data associated with the TB, (2) whether the data is multiplexed from one or more LCHs configured with a higher priority index, (3) whether the data is multiplexed from a subset of the configured LCHs or DRBs, (4) the WTRU's subscription type, or (5) the HARQ process ID selected for the TB. After a failed LBT attempt, the WTRU may increment the offset or use a different resource with a different starting offset.

[0255] When the WTRU attempts to (re)transmit a TB that failed the LBT, it may start a retransmission timer to measure the retransmission time period. The WTRU may start the retransmission timer only if a HARQ-ACK with value NACK is determined for the HARQ process. The WTRU may not attempt to acquire the channel during the retransmission time period. The value of the timer or time period may be configured by higher layers or may be dynamically changed based on a previous LBT attempt or a selected timing offset used to acquire the channel.

[0256] The WTRU may maintain and be configured with a retransmission timer per resource pool, per SL carrier, per LBT bandwidth / subband, or per MAC entity. In one example, the WTRU may start a timer after an LBT failure on a given resource pool. While a timer associated with a resource pool is running, the WTRU may not select resources on that resource pool for retransmitting or transmitting the TB. The WTRU may possibly (re)transmit the TB on a resource pool different from the last selected resource pool if the timer associated with the pool is not running and / or if a HARQ process ID is configured for the resource pool and / or if the TB size is supported.

[0257] The WTRU may prioritize / select resources within the COT or with respect to time position of the COT. The WTRU may determine a set of available resources, where a subset of resources may include resources in the COT and other resources may not be in the COT. The WTRU may select or prioritize resources in the COT, possibly under some conditions herein. For example, if the data available for transmission is above a threshold priority, the WTRU may only select from resources in the COT. Otherwise, the WTRU may be allowed to select resources from within the COT or may not select resources from within the COT. For example, if the measured CBR is above a threshold, the WTRU may only select from resources in the COT or may prioritize selection of resources in the COT.

[0258] The WTRU may determine that multiple resources are available to select between performing a transmission or retransmission.

[0259] The WTRU may prioritize resource selection based on the remaining time in the COT. The WTRU may prioritize resource selection in descending order of remaining COT time. The WTRU may select the resource with the largest remaining time in the COT based on the remaining time in the COT indicated (e.g., in the SCI or signaled control information) or determined from the start time of the resource and / or the timing of a previous transmission in the same COT.

[0260] The WTRU may also prioritize resource selection based on the time required to perform a TB transmission. The WTRU may select a resource only if the remaining time can support transmission of the desired buffered bits, number of bits per packet, or number of bits in a TB. The WTRU may select a resource only if the TB of the grant supports the TB size. Among multiple resources that meet the time required to perform a TB transmission criterion, the WTRU may select the resource with the smallest duration.

[0261] The WTRU may also prioritize the selection of resources based on the transmission latency. The WTRU may select resources that meet the transmission latency (which may be determined from QoS requirements associated with the data to be transmitted or the data multiplexed in the TB). For example, the WTRU may select resources that have a COT that ends before the latency budget associated with the data and / or that include data resources that start immediately after a short LBT period.

[0262] The WTRU may also prioritize resource selection based on RSSI. The WTRU may select resources that meet configured or predefined RSSI or CBR thresholds. The WTRU may prioritize resource selection by descending order of RSSI.

[0263] The WTRU may also prioritize the selection of resources based on the required LBT type or configuration associated with the resource. For example, the WTRU may prioritize the selection of resources requiring LBT type 1, type 2, then type 4, in that order. The WTRU may prioritize the selection of resources with the smallest CAPC, i.e., requiring a shorter congestion window size for CCA.

[0264] In one embodiment, the WTRU may determine a set of available resources. The WTRU may select or prioritize resources that occur less than a threshold number of slots from the start or end of the COT. Alternatively, the WTRU may select or prioritize resources that require one or more LBT types to acquire the channel, and may not select / prioritize resources that require one or more different LBT types to acquire the channel. The WTRU may select or prioritize resources that occur less than a threshold number of slots from the current WTRU's or another WTRU's transmission (as detected in the SCI) or a planned transmission (as determined based on forward looking information in the SCI). The WTRU may select or prioritize resources spaced less than or equal to the number of slots from the current WTRU's or another WTRU's transmission based on any condition mentioned herein, such as, for example, if the measured CBR is above a threshold, if the data available for transmission is above a threshold priority, etc.

[0265] In one embodiment, the WTRU may determine a set of available resources. The WTRU may select or prioritize transmission of resources within the COT if the WTRU has already started the COT and / or if the resource selection window overlaps with the COT. The WTRU may do so based on conditions herein, such as a measured CBR above a threshold and / or a priority of data available for transmission above a threshold.

[0266] In the above embodiments, the rules may apply only to COTs initiated by the WTRU performing resource selection. Alternatively, the rules may apply to COTs initiated by any other WTRU. Alternatively, the rules may apply to COTs initiated by related WTRUs (e.g., WTRUs transmitting to the same L2 destination ID, WTRUs having a unicast link with the WTRU performing resource selection, WTRUs that are part of the same group as the WTRU performing resource selection, etc.) or within a certain number of levels of indirection.

[0267] In one embodiment, the WTRU may select or prioritize resources associated with a particular COT type. In one example, the WTRU may select or prioritize resources associated with a groupcast COT to perform resource selection when data available for transmission is associated with a groupcast, possibly with the same L2 ID. For example, the WTRU may select resources associated with a COT initiated by any WTRU in a unicast link, possibly when resource selection is initiated when data available for transmission is associated with a transmission to that unicast link.

[0268] In another example, the WTRU may select or prioritize resources for which the number of indirections is below a threshold, possibly under certain conditions described herein. In another example, the WTRU may select or prioritize resources that are FBE under one condition and LBE otherwise (or vice versa). Such conditions may be based on a measured CBR. Such conditions may be based on the priority of the data. Such conditions may also be based on characteristics of the LCH that has the highest priority with the available data.

[0269] In one embodiment, the WTRU may determine parameters for resource selection based on the COT information, which may include any of the parameters described herein. The COT information may be associated with the resource, such as whether the resource is in the COT, the type of COT the resource is associated with, the time since the start of the COT by the WTRU or another WTRU, the time since the last transmission by the WTRU or another WTRU, etc.

[0270] The WTRU may select a first maximum number of RBs when resources are selected within the COT, and may select a second maximum number of RBs when resources are selected outside the COT. The WTRU may select resources for periodic transmissions only when such resources are associated with FBE. Otherwise, if resource selection is triggered for one-shot transmission, the WTRU may select resources only from resources associated with LBE, or from resources associated with FBE or LBE.

[0271] The WTRU may select a resource using a requested one that has several consecutive slots available for transmission when the resource is associated with an LBE, and may use such a request when the resource is associated with an FBE. The WTRU may determine an allowable periodicity of resource selection for multi-shot resource selection based on the configuration and / or determined available FBE resources.

[0272] The WTRU may determine an allowable number of retransmissions for a TB (eg, possibly indicated in a single SCI) based on the COT duration.

[0273] The WTRU may determine the maximum time between transmissions / retransmissions / selected resources based on information associated with the COT or COT structure (e.g., CAPC, indirection number, etc.). For example, the WTRU may be configured with an allowable time between retransmissions performed within the COT, and such allowable time is associated with a CAPC for the COT (either indicated as part of a COT initiated by another WTRU or determined by the WTRU itself when initiating the COT). The WTRU may ensure that the maximum allowed time between retransmissions for a particular CAPC is respected when selecting resources for transmission within the COT.

[0274] When the WTRU performs resource selection that initiates a COT at the WTRU, the WTRU may determine a maximum time between transmissions / retransmissions / selected resources based on the priority / CAPC of the data available for transmission at the time of resource selection. Specifically, the WTRU may be configured with a first allowable time for a first priority / CAPC, a second allowable time for a second priority / CAPC, etc.

[0275] A WTRU may select contiguous time resources when it is initiating its own COT, whereas a WTRU may not be required to select contiguous time resources when transmitting within a COT that has already been initiated (either by itself or by another WTRU). The number of contiguous resources (e.g., allowed, required) may further depend on the conditions described herein (e.g., CBR, CAPC, priority of the data that triggered the resource selection, CAST, SL measurements, etc.).

[0276] The WTRU may select consecutive time resources when the WTRUs are sharing a COT or when the WTRU is transmitting within a COT that has already started, based on the time difference between the selected resource and any performed / announced / scheduled transmission by the WTRU itself or another WTRU. Specifically, the allowable number of consecutive transmissions may be a function of the time / gap between the resource and the last transmission by the WTRU (possibly in the same COT, or possibly associated with a COT other than the COT for which the resource is selected).

[0277] One advantage of the above embodiment is that it allows a WTRU to perform transmissions on an unlicensed spectrum using resources selected based on LBT rules required for transmissions on an unlicensed spectrum. For example, consecutive resources may be required for the start of a COT because the WTRU may need to perform a CAT4 LBT before transmission. Specifically, if the LBT fails on the first slot, the WTRU may still transmit in the subsequent slots because it also selected the subsequent slots during resource selection. To share the COT, the WTRU may perform a short LBT and the number of (possibly consecutive) resources that need to be selected may be smaller.

[0278] The WTRU may trigger resource reselection based on conditions associated with the COT structure, COT initiation, LBT at the WTRU, in combination with other conditions mentioned herein. Specifically, the WTRU may trigger resource reselection based on any or a combination of the events or conditions described below.

[0279] One condition may be that the WTRU fails to LBT, possibly a consecutive number of times, or possibly for a selected (possibly consecutive) number of resources. Another condition may be that the WTRU fails to start a new COT for transmission purposes. Another condition may be that the WTRU fails to share a COT started by another WTRU (i.e., the WTRU fails a short LBT within an existing COT).

[0280] Another condition may be that the WTRU receives an SCI indicating the initiation of a COT by another WTRU, possibly where such a COT overlaps with resources already selected by the WTRU, possibly where such a COT occurs before resources already selected by the WTRU, or possibly where the WTRU has selected resources that require it to perform its own COT initiation. The WTRU may select resources aligned with the initiation of the COT. Upon receiving an SCI indicating that the COT has been initiated by another WTRU, the WTRU may trigger a reselection of these resources to select new resources for transmission in the already initiated COT. The WTRU may have some resources selected for future transmissions. The WTRU may then receive an SCI indicating the initiation of a COT by another WTRU that overlaps with the resources. If the COT is used by a group of WTRUs not involved with the WTRU, the WTRU may perform preemption / resource reselection to ensure that its future reserved resources do not overlap with the COT.

[0281] Another condition may be that the WTRU has data available for transmission with CAPC of higher / lower priority than any existing / initiated COT. Another condition may be that the data available for transmission is at least of a certain priority. For example, resource reselection may be triggered as a result of the above only if the data priority is above a threshold. Another condition may be that the measured CBR is below a threshold. For example, resource reselection may be triggered as a result of the above only if the CBR is below a threshold.

[0282] In one embodiment, when determining whether resources are available for transmission, the WTRU may consider both the resources indicated in the forward booking signal (i.e., occurring in the booking period after the reserved SCI) as well as other resource(s) occurring before and / or after the forward booked resource as unavailable for transmission. Such an embodiment may be advantageous in that it allows the first TX WTRU to attempt an LBT on multiple possible contiguous resources (related to resources announced in the previous SCI) until the LBT is successful (or until a maximum number of resources is reached), but the second TX WTRU may avoid selecting for its own transmission any resources that may be used by the first TX WTRU following a successful LBT.

[0283] In one example, the first TX WTRU may initiate an LBT on future announced resources directly indicated by the previous SCI. The first TX WTRU may maintain the planned periodicity for future announced resources (relative to the first transmission) regardless of the number of failed LBTs before the successful first transmission. Alternatively, the first TX WTRU may change the planned gap between the first and second transmissions by an amount that depends on the number of failed LBTs to perform the first transmission. Specifically, the first TX WTRU may reduce the planned gap for the second transmission by a number of slots, possibly equal to the number of slots in which the LBT failed for the first transmission. As a second TX WTRU (the TX WTRU that performs sensing to determine available resources), the second TX WTRU may assume the resources indicated by the previous SCI, as well as some subsequent (possibly consecutive) slots that are considered unavailable when performing resource selection.

[0284] In another example, the first TX WTRU may start an LBT on a future (second) resource that is always a value of the period T (i.e., the selected periodicity) from the slot where it first started an LBT for the first transmission. In such an example, the first TX WTRU may include in the SCI an indication of the number of slots before the indicated future (second) resource where it may start an LBT for a transmission on the future resource. The second TX WTRU may assume that the indicated resource, as well as some resources before the indicated resource (if the number of such resources is indicated in the SCI), are considered occupied. In addition, the second TX WTRU may assume a number of time resources or slots to be occupied after the indicated resource, with such number being determined by the total number of possible LBT attempts in consecutive slots minus the number of slots indicated in the received SCI (i.e., slots before the indicated resource).

[0285] The WTRU may trigger preemption / reassessment based on triggers associated with COT information (possibly received from another WTRU) and / or LBT status in the WTRU itself. In one example, the WTRU may trigger preemption / reassessment if it fails to acquire a channel (using LBT) before the selected and / or indicated resource. The WTRU may perform the reassessment and select new resources for transmission as a result.

[0286] In another example, a WTRU may trigger preemption / re-evaluation if it receives an SCI indicating that a COT was initiated by another WTRU and the COT overlaps with resources selected at the WTRU. The WTRU may also trigger preemption / re-evaluation if the CAPC associated with the COT is different (e.g., higher priority, lower priority) than the CAPC assumed by the WTRU to select the (overlapping) resources.

[0287] In another example, a WTRU may trigger preemption / reevaluation if it receives an SCI indicating that a COT has been initiated by another WTRU, and the COT may occur earlier than the selected resources. Such preemption / reevaluation may also be triggered if the resources selected / reserved by the WTRU require the initiation of a COT (possibly while the COT initiated by the other WTRU may be shared by the WTRU). In such a case, the WTRU may reselect only resources within the COT indicated in the received SCI.

[0288] An advantage of such an embodiment may be to perform reselection in the WTRU when the WTRU determines that a COT has been initiated (possibly by another WTRU) and is able to use that COT for transmission (rather than performing its own COT initiation).

[0289] A WTRU may receive (e.g., in Mode 1) or may select (e.g., in Mode 2) or may be configured with a multi-occasion sidelink data transmission resource. A multi-occasion resource consists of two or more possibly consecutive data transmission occasions where LBT occasions are possible, whereby the WTRU may attempt an LBT on each occasion until the LBT is successful. If the LBT is successful, the WTRU may transmit on the remaining occasions in the resource without performing the LBT again. For each data transmission occasion, the WTRU may attempt to transmit the same TB that failed the LBT or a different TB.

[0290] In one embodiment, a WTRU sharing the COT may indicate multi-occasion resources shared with one WTRU or two or more WTRUs, whereby the shared WTRU signals to each shared WTRU a starting occasion at which the resource may start and / or be used. Such an indication may be received by an SCI or MAC CE. Upon receiving such an SCI or MAC CE, the shared WTRU may perform a short LBT (e.g., Type 1 or 2) before starting transmission on the occasion indicated to the shared WTRU, or may simply transmit without an LBT if the gap between the shared WTRU's transmission and the shared WTRU start time is less than a preconfigured threshold (e.g., the gap for Type 1 LBT). The shared WTRU may indicate possible remaining starting occasions in the COT, and the shared WTRU may randomly select an occasion from among the indicated occasions to acquire the channel.

[0291] A WTRU may receive multi-occasion resources from a base station (e.g., gNB) via Mode 1 type scheduling. The base station may schedule multi-occasion resources from one or more WTRUs. The base station (e.g., gNB) may indicate an applicable starting occasion to each WTRU. The WTRU may transmit without an LBT or with a short LBT before the indicated starting occasion.

[0292] The Mode 2 resource pool may consist of several occasions and start times for multi-occasion resources. The WTRU may determine the HARQ process from the timing of the first occasion in the multi-occasion bundle. The WTRU may continue to use the same HARQ process until the LBT is successful. Once the LBT is successful, the WTRU may increment or change the HARQ process (e.g., if the WTRU has more data to transmit).

[0293] In one embodiment, the multi-occasion resource may include multiple resource pools, whereby each occasion may be associated with one or more resource pools. The WTRU may be configured with a resource hopping pattern such that if the LBT fails on one occasion, the WTRU attempts the LBT on the next occasion, which may be associated with a different resource pool.

[0294] A WTRU selecting multiple LBT occasions in Mode 2 may select multiple resources for its transmission. The multiple LBT occasion resources may include the same frequency resources in consecutive or non-consecutive slots. Alternatively, the multiple LBT occasion resources may include different frequency resources in the same or different slots.

[0295] A WTRU may select multiple resources for its initial transmission and then select only a single set of resources for its retransmissions. Alternatively, a WTRU may select multiple resources for an initial transmission as well as multiple resources for each retransmission for each resource of the initial transmission. Whether the WTRU selects a single retransmission resource (set) for each initial transmission resource or multiple such may depend on the same conditions described below for whether the WTRU uses multiple LBT occasion selection. For example, whether the WTRU selects a single retransmission resource (set) for each initial transmission resource may depend on the time between the transmission and the retransmission resource, the LBT type required for the retransmission resource, or whether the selected resource occurs within the COT.

[0296] In another embodiment, the WTRU may perform an initial transmission or a retransmission on any of the multi-LBT occasion resources. Specifically, if the LBT on the multi-LBT occasion SL resource is successful, the WTRU may perform an initial transmission and then a retransmission on the remaining resources of the multi-LBT transmission resources. The WTRU may further assume that no LBT is required (or a different LBT type is required) for transmission on the remaining resources after a successful LBT.

[0297] The Mode 2 WTRU may perform multi-LBT occasion SL resource selection based on certain conditions. Specifically, the Mode 2 WTRU may determine to perform multi-LBT occasion and / or retransmission resource selection for each initial transmission resource based on any one or combination of the following being satisfied:

[0298] The Mode 2 WTRU may determine to perform selection of the number of multiple LBT occasions and / or retransmission resources for each initial transmission resource based on the resource selection being performed on a resource pool associated with unlicensed operation. For example, the WTRU may select multiple LBT occasion SL resources if the selection is performed on a pool of resources associated with SL unlicensed, and may not perform such selection when the pool of resources is on a non-shared spectrum (non-unlicensed spectrum).

[0299] Mode 2 The WTRU may decide to perform a selection of multiple LBT occasions and / or the number of retransmission resources for each initial transmission resource based on whether the selected resource occurs in the COT. For example, the WTRU may select a multiple LBT occasion SL resource if the selected resource (e.g., the first selected resource) occurs outside the COT, otherwise the WTRU may not select a multiple LBT occasion SL resource (i.e., if the selected resource occurs in the COT). For example, if the selected retransmission resource occurs within the COT started by any of the initial transmission resources, the WTRU may select a single (set of) retransmission resources for the initial transmission resource. Otherwise, the WTRU may select multiple (e.g., multiple LBRT occasion) SL resources for each retransmission.

[0300] A Mode 2 WTRU may decide to perform multiple LBT occasion and / or number of retransmission resources selection for each initial transmission resource based on the type of LBT required to perform the transmission. For example, the WTRU may perform multiple LBT occasion SL resource selection if the transmission requires a particular LBT type (e.g., Type 1 LBT, Type 2 LBT), and may perform legacy resource selection otherwise.

[0301] The Mode 2 WTRU may decide to perform multi-LBT occasion and / or retransmission resource number selection for each initial transmission resource based on the priority of the data to be transmitted. For example, the WTRU may perform multi-LBT occasion SL resource selection if the priority of the data available for transmission is above a threshold, and may perform legacy resource selection otherwise.

[0302] The Mode 2 WTRU may decide to perform a selection of the number of multiple LBT occasions and / or retransmission resources for each initial transmission resource based on the time between transmission and retransmission. For example, if the time between the selected transmission and retransmission is below a threshold, the WTRU may select only a single (set of) retransmission resources for all of the initial transmission resources associated with a multiple LBT occasion.

[0303] The Mode 2 WTRU may decide to perform multi-LBT occasion and / or number of retransmission resources selection for each initial transmission resource based on the measured CBR or any congestion metric of SL. For example, the WTRU may perform multi-LBT occasion SL resource selection if the measured CBR is below a threshold, and may perform legacy resource selection otherwise.

[0304] The WTRU may further be configured with rules and / or parameters for determining the number and / or pattern of resources in a multi-LBT occasion. The WTRU may be configured with a maximum number of resources (i.e., single slot resources) that may be selected for a multi-LBT occasion. The WTRU may also be configured with a minimum / maximum number of slots between each / any single slot resource of a multi-LBT occasion. The WTRU may also be configured with a start / end of a resource selection window or a maximum time from the moment of resource selection that the start of a multi-LBT occasion may occur. The WTRU may also be configured with a minimum / maximum number of frequency resources that can be part of a multi-LBT occasion. The WTRU may determine any of the above rules and / or parameters based on a combination of the following:

[0305] The WTRU may determine the number and / or pattern of resources in a multi-LBT occasion based on the sensing results. For example, the WTRU may select a number of resources (e.g., up to a maximum) based on other factors herein. However, if the sensing results indicate that such number of resources is not available based on the sensing results, the WTRU may select a smaller number of resources. Specifically, the WTRU may select up to a maximum number of resources, if permitted, based on availability information provided by the sensing results.

[0306] The WTRU may determine the number and / or pattern of resources in a multi-LBT occasion based on the priority / QoS. For example, the WTRU may select a number of resources depending on the priority / QoS of the data available for transmission.

[0307] The WTRU may determine the number and / or pattern of resources in a multi-LBT occasion based on the COT information. For example, the WTRU may determine whether the resources are within the COT (e.g., initiated by another WTRU) and / or the allowable time between resources of the multi-LBT resource based on the COT information (e.g., CAPC).

[0308] The WTRU may determine the number and / or pattern of resources in a multi-LBT occasion based on the CBR, for example, the WTRU may be configured with the maximum number of resources associated with a multi-LBT occasion for a given measured CBR.

[0309] The WTRU may fail the LBT on one or more single resources of the multi-LBT occasion resource. In such a case, the WTRU may initiate or continue the LBT on the next resource of the multi-LBT occasion resource. The remote WTRU may perform the LBT on each subsequent resource of the multi-LBT occasion resource until the LBT is successful or until the WTRU has exhausted its LBT attempts on each of the resources in the multi-LBT occasion resource.

[0310] The WTRU may perform any one or a combination of the following upon successful LBT on one of the resources of the multi-LBT occasion resource:

[0311] The WTRU may perform a transmission on a resource associated with the successful LBT upon a successful LBT on one of the resources of the multi-LBT occasion resource. Specifically, the WTRU may perform an initial transmission on a resource following the successful LBT. The WTRU may further determine whether it can perform an initial transmission on a resource following the successful LBT or whether to select a subsequent resource (not necessarily the resource immediately following the successful LBT) based on conditions described herein. Specifically, the WTRU may determine whether to perform a transmission on a first resource following a successful LBT if the priority of a pending data transmission is above a threshold, if the CBR is below a threshold, if the sensing result indicates that the resource is available, or any combination thereof, or in conjunction with other factors described herein.

[0312] The WTRU may perform transmission on a subsequent resource associated with the successful LBT upon a successful LBT on one of the resources of the multi-LBT occasion resource. Specifically, the WTRU may select one of the remaining resources associated with the multi-LBT occasion resource on which to start transmission and may start transmission on the selected resource. The WTRU may select a resource based on the following:

[0313] The WTRU may select resources based on priority. For example, the WTRU may be (pre-)configured with a mapping between priority / QoS and resources following a successful LBT to start transmission. Specifically, a WTRU with a higher priority transmission may start transmission immediately (or earlier) in the remaining resources of the multi-LBT resource, and a WTRU with a lower priority transmission may start transmission later following a successful LBT.

[0314] The WTRU may select a resource based on the remaining PDB. The WTRU may determine on which resource in the remaining resources to start transmission following a successful LBT based on the remaining PDB. For example, the smaller the remaining PBD, the sooner the WTRU may start transmission. The WTRU may select a resource (randomly or based on other rules herein) for start of transmission following a successful LBT, which ensures that the transmission and possibly subsequent retransmissions are performed before the PBD expires.

[0315] The WTRU may select a resource based on a random or probabilistic rule. For example, the WTRU may randomly select from one of the remaining resources of the multi-LBT occasion, which may also satisfy any of the other criteria for initiating transmission. The WTRU may be configured with a probability (which may depend on or be determined by other factors herein) of initiating transmission on any of the remaining resources of the multi-LBT occasion.

[0316] The WTRU may select resources based on the HARQ feedback timeline, e.g., the WTRU may select resources among the remaining resources following a successful LBT to initiate a transmission that respects the HARQ timeline selected by the WTRU during resource selection for transmission and retransmission.

[0317] The WTRU may select resources based on the sensing results. For example, the WTRU may decide whether to transmit in one of the resources of the multi-LBT occasion resource based on whether the WTRU detects other SL WTRU transmissions (i.e., in the SCI). The WTRU may start the successive partial sensing operation at the start of the LBT or upon success of the LBT. The WTRU may start transmission only in the first resource of the multi-LBT resource for which the successive partial sensing indicates that the resource is available.

[0318] The WTRU may perform transmissions on multiple resources of a multi-LBT resource following a successful LBT. For example, the WTRU may decide to perform transmissions on multiple (possibly contiguous in time) resources of a multi-LBT resource starting from a successful LBT. The WTRU may determine whether to perform multiple transmissions and the number of subsequent retransmissions based on any or a combination of the following:

[0319] The WTRU may decide whether to perform multiple transmissions and the number of subsequent retransmissions based on the priority / QoS of the transmission. For example, the WTRU may be allowed to use multiple of the remaining resources after a successful LBT for transmission and retransmission if the priority of the TB is above a threshold.

[0320] The WTRU may determine whether to perform multiple transmissions and the number of subsequent retransmissions based on the priority / QoS of the subsequent data. For example, if the WTRU has additional data for transmission with priority above a threshold or with some priority relative to the first transmission (e.g., at least the same priority as the first transmission, up to some priority lower than the first transmission), the WTRU may be allowed to use subsequent resources following the first transmission after a successful LBT.

[0321] The WTRU may determine whether to perform multiple transmissions and the number of subsequent retransmissions based on the CBR. For example, the WTRU may be allowed to use subsequent resources of the multi-LBT resource as long as the CBR is below a threshold. The number of subsequent resources of the multi-LBT resource that can be used may depend on the measured CBR.

[0322] The WTRU may determine the number of subsequent retransmissions based on whether to perform multiple transmissions and the number of planned / allowed retransmissions, e.g., the WTRU may use subsequent resources if it plans a retransmission that may be associated with a TB that was first transmitted in a multi-LBT resource following a successful LBT.

[0323] The WTRU may indicate (e.g., in the SCI) that it may maintain the resource or perform transmission on the next resource. The WTRU may further indicate whether it decides to use the next resource for an initial transmission or a retransmission and / or the priority of such (re)transmission.

[0324] The WTRU may continue performing the LBT or perform a shorter LBT. For example, following a successful LBT in a multi-LBT occasion, if the WTRU decides to perform a transmission in some slots after the successful LBT (as determined based on the conditions herein), the WTRU may continue performing the LBT or may perform a short LBT before the resource selected for the actual transmission following the first successful LBT for the multi-LBT occasion. For example, the type of LBT may further depend on the time between the first successful LBT and the selected resource of the transmission in the multi-LBT occasion. Specifically, if the WTRU decides to transmit immediately after the first successful LBT or up to N slots after the first successful LBT, the WTRU may transmit without a short LBT.

[0325] The WTRU may be configured to perform a recovery procedure upon failure associated with acquiring selected resources in a multi-LBT occasion. The WTRU may be configured to perform a recovery procedure upon any failure related to LBT in general (e.g., after one or several failed SL LBTs). Such a recovery procedure may be any of the following:

[0326] The recovery procedure may be to perform resource and / or carrier reselection. The recovery procedure may also perform UL transmission and possibly notify the base station (e.g., gNB) of the failure. The recovery procedure may also be to declare a SL RLF. The recovery procedure may also be to start transmission on FBE resources. The recovery procedure may also be to start an RRC connection.

[0327] A trigger for performing a recovery procedure may be associated with the characteristics of the multi-LBT resource. The WTRU may trigger a recovery procedure upon resource selection failure (possibly consecutive times or times within a time window) to select an appropriate set of available resources for the multi-LBT occasion. An appropriate number of available resources may include finding at least N consecutive single-slot resources within the resource selection window.

[0328] The WTRU may trigger a recovery procedure upon LBT failure for all of the resources associated with a multi-LBT occasion, possibly consecutive times or times within a window.

[0329] The WTRU may trigger a recovery procedure upon one or more events (e.g., a consecutive number of events, or several events occurring within a configured time window) associated with failing to acquire a channel during a multi-LBT occasion, or successfully acquiring a channel during a multi-LBT occasion but having: (1) the number of resources remaining in the occasion falling below a threshold; (2) not performing a transmission or some retransmissions due to a sensing result indicating resources are unavailable; and / or (3) performing a transmission and / or some retransmissions in the multi-LBT occasion that is below a configured or desired amount associated with a successful event.

[0330] The WTRU may perform data multiplexing for transmissions on the SL using rules / restrictions specific to the COT information (e.g., LCP restrictions) that may be associated with a grant. Such restrictions may relate to any property herein that is tied to the COT or COT-related information. The WTRU may determine information about the COT from an explicit transmission from another WTRU (i.e., information elements about the COT provided by a peer WTRU). The WTRU may alternatively or additionally determine information about the COT from the transmission itself (e.g., cast type, L2 ID, MCR, or any other information included in the sidelink transmission, etc.). For example, the WTRU may identify the presence of a COT and associate the cast type, L2 ID, MCR, etc. to the COT by determining any of these parameters associated with one (e.g., the first) or any transmission occurring in the COT.

[0331] In particular, the LCP restriction may be performed by the WTRU during the selection of an L2 destination ID and / or the selection of a logical channel for transmission on the sidelink, and may relate to any of the following properties associated with a grant:

[0332] The LCP restriction may relate to whether the permission is within an existing COT (i.e., whether it is associated with the creation of a COT by the WTRU)

[0333] The LCP restrictions may relate to whether the grant is within the COT, and whether the COT was initiated by the WTRU itself or by another WTRU.

[0334] The LCP restrictions may relate to whether the grant is within the COT and whether the COT was initiated by a unicast / groupcast / broadcast transmission.

[0335] The LCP restrictions may relate to whether the grant is within the COT and the source / destination L2 ID of the WTRU whose transmission initiated the COT.

[0336] The LCP restrictions may relate to whether the grant is a Mode 1 grant or a Mode 2 grant.

[0337] The LCP restrictions may relate to whether the grant is within the COT, the COT length, the remaining COT length, or any time relationship between the COT and the grant itself.

[0338] The LCP restrictions may relate to whether the grant is within the COT, the number of SL transmissions already performed within the COT, the channel occupancy (CR, CBR, or number of reserved / used subchannels) measured within the COT based on transmissions of other WTRUs or the WTRU itself.

[0339] The LCP restriction may be associated with the CAPC of the COT in which the permission resides. For example, a WTRU may be allowed to multiplex data of an LCH as long as the CAPC of that data is of higher priority than the CAPC associated with the COT that the WTRU is trying to share.

[0340] For example, a WTRU may receive a CAPC within a COT initiated by another WTRU. The WTRU may limit the selection of LCHs that may be multiplexed into a grant to those LCHs that have a priority associated with the CAPC, e.g., a list of granted priorities associated with the CAPC, a priority above a threshold determined based on the CAPC, and / or a priority that has some relationship to the priority of the CAPC (e.g., is greater than or equal to a certain number of levels lower than, is not less than).

[0341] The LCP restriction may be associated with a grant in a COT initiated by the WTRU or may be shared with another WTRU. For example, a WTRU may / may not be allowed to multiplex data of a certain priority or priority range into a grant used to initiate a COT, a grant with which the WTRU shares a COT, and a grant that the WTRU transmits on a COT that the WTRU has already initiated. Furthermore, combinations of each of the three cases are possible. For example, a WTRU may be allowed to multiplex data with a priority higher / lower than a threshold in a grant that the WTRU initiated its own COT and / or initiated.

[0342] For example, a WTRU may be configured with a first priority restriction rule for grants in a COT initiated by another WTRU and a second priority restriction rule for COT initiated by the WTRU itself. For example, if a grant falls within a COT initiated by another WTRU, the transmitting WTRU may select only LCHs with a priority at least as high as the priority / CAPC indicated in the COT information. If a grant falls within a COT to be initiated by the WTRU itself, the WTRU may select any LCH priority to multiplex into the COT.

[0343] In another example, the WTRU may be configured with a first priority restriction rule for grants in a COT that result in the initiation of a COT for grants in a COT already initiated by the WTRU, For example, if a grant enters a COT previously initiated by the WTRU itself, the WTRU may / may not restrict the LCH or may use a different priority restriction than the restriction associated with a grant used to initiate the COT.

[0344] LCP restrictions may be associated with properties tied to the COT and / or associated with data transmitted in a grant that initiated the COT, such properties may be cast type, destination ID, priority, WTRU group, delay, PDB, or any other SL property described herein. For example, a WTRU may be permitted to multiplex data of a particular cast type in a grant occurring within the COT, such case type being determined by the cast type associated with the COT (e.g., included in the information in the COT) or the cast type used in the grant that initiated the COT. Specifically, once a COT has been used for a particular cast type, the COT must continue to be used for that cast type. Furthermore, restrictions may depend on the cast type itself. For example, a WTRU sharing a COT initiated by a unicast transmission may only select an L2 destination ID that is the same as the L2 source ID of the WTRU that initiated the COT. For example, a WTRU sharing a COT initiated by a broadcast transmission may select an L2 ID associated with either a groupcast or any unicast transmission (possibly of the same L2 ID that initiated the COT). For example, a WTRU sharing a COT initiated by a broadcast transmission may select an arbitrary L2 ID for the transmission sharing the COT.

[0345] For example, a WTRU may be permitted to multiplex data of a particular L2 ID on a grant occurring within the COT, with such case type being determined by the L2 ID associated with the COT (e.g., included in the information in the COT) or the L2 ID used in the grant that initiated the COT. Specifically, once a COT has been used for a particular L2 ID, the COT should continue to be used for that L2 ID. Specifically, a WTRU with a pending grant occurring within a COT initiated by a groupcast / broadcast transmission may select an L2 ID for transmission on that grant that is the same as the L2 ID of the transmission that initiated the COT.

[0346] LCP restrictions may be associated with an indirect number associated with a COT, as described herein. For example, a WTRU may be configured with a set of LCHs that can / cannot be multiplexed onto grants occurring within the COT of an indirect number or set of indirect numbers. For example, a WTRU may be configured with one or more cast types that can / cannot be multiplexed onto grants occurring within the COT of an indirect number or set of indirect numbers.

[0347] The LCP restrictions may be associated with the mode of transmission (i.e., Mode 1 vs. Mode 2). For example, the COT may be associated with a mode (i.e., Mode 1 or Mode 2), which may represent the resource selection mode used by the WTRU when initiating the COT. The WTRU may determine the mode of transmission used to initiate the COT from information in the transmission itself. The WTRU initiating the COT may include the operating mode (Mode 1 or Mode 2) used to initiate the COT. The WTRU may be configured with a set of LCHs that can / cannot be multiplexed in the COT associated with Mode 1 and / or Mode 2.

[0348] The LCP restrictions may be associated with the data available for transmission and / or the MCR of the transmission that initiated the COT. For example, the WTRU may determine the allowable L2 destination IDs, LCH priorities, or other restrictions for logical channels multiplexed in a grant based on whether the COT was initiated by a transmission with / without an MCR. For example, a WTRU that shares a COT initiated by a transmission with an MCR may only select an L2 ID that matches the L2 ID of the transmission that initiated the COT. Alternatively, if the COT was initiated by a transmission without an MCR, the WTRU may select any L2 ID.

[0349] In another example, the WTRU may determine the allowable L2 destination IDs, LCH priorities, or other restrictions for logical channels multiplexed in a grant based on whether the WTRU using the grant is inside / outside the MCR of the COT-initiated transmission. For example, if the WTRU is inside the MCR associated with the COT-initiated transmission, the WTRU may select any L2 ID and / or LCH priority for the grant that shares the COT. If the WTRU is instead outside the MCR associated with the COT-initiated transmission, the WTRU may be limited to selecting the same L2 ID and / or restricting the LCH priorities that can be multiplexed into the grant (e.g., only LCHs with priority equal to or higher than CAPC associated with the COT).

[0350] In another example, the WTRU may determine the allowable L2 destination IDs, LCH priorities, or other restrictions for logical channels multiplexed in a grant based on whether the MCR of the transmission that initiated the COT is above / below a threshold. For example, the WTRU may configure a threshold MCR or may determine a threshold MCR (e.g., based on other factors described herein). If the MCR of the PDU is above the threshold, the WTRU may allow inclusion of logical channels with any priority. If the MCR is below the threshold, the WTRU may only include logical channels with a priority equal to or determining the CAPC.

[0351] Additionally, the WTRU may determine the allowable L2 destination IDs, LCH priorities, or other restrictions for the logical channels multiplexed in the grant based on any of the three combinations described above.

[0352] The LCP restriction may be based on the occupancy of SL resources in the COT. For example, the WTRU may determine the allowable destination L2 IDs, LCH priorities, or other restrictions based on the measured occupancy of the SL resources in the COT. For example, if the occupancy of a channel in the COT is determined to be low (e.g., below a threshold), the WTRU may include an LCH with a lower priority (e.g., below a threshold, below the CAPC of the COT, etc.) when sharing the COT. Alternatively, if the occupancy of a channel in the COT is determined to be high (e.g., above a threshold), the WTRU may be restricted to only LCHs with high priority (e.g., above a threshold, below the CAPC of the COT, etc.).

[0353] LCP restrictions associated with the node that initiated the COT. For example, a WTRU may be configured with a set of LCHs that can / cannot be multiplexed into grants that occur in a COT initiated by a base station (e.g., gNB) or by another WTRU. For example, the WTRU may use a first LCP restriction rule for a COT initiated by another WTRU and a second LCP restriction rule for a COT initiated by a base station (e.g., gNB).

[0354] The WTRU may decide to apply LCP restrictions to include only data related to equal priority, equal data / control type, or the like. Such an embodiment may be used to avoid cases where the WTRU selects a low priority CAPC (due to low priority data being included in the PDU) when the PDU includes high priority data. In one example, the WTRU may limit the difference between the minimum and maximum priority to less than a threshold. In one example, if the WTRU includes data or control with a priority greater than a threshold, the WTRU may not include any data or control with a priority less than the threshold. In one example, the WTRU may be (pre)configured with a set of priority combinations that can be included together in a PDU. In one example, the WTRU may apply LCP restrictions when the PDU includes a MAC CE or DRB. In such an embodiment herein, the priority may refer to LCH priority, L1 priority, or directly CAPC.

[0355] The WTRU may determine whether to apply an LCP restriction (e.g., any of the LCP restrictions listed above) based on the SL factor or the type of transmission, as identified herein. For example, the WTRU may apply an LCP restriction for a first resource allocation mode (e.g., mode 1) and not apply an LCP restriction for a second resource allocation mode (e.g., mode 2).

[0356] Although the features and elements are described above in certain combinations, one skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) 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 internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, a WTRU, a terminal, a base station, an RNC, or any host computer.

Claims

1. 1. A method performed by a first wireless transmit / receive unit (WTRU), the method comprising: Obtaining permission for transmission on a side link (SL); receiving a transmission from a second or additional WTRU, the transmission including a first channel occupancy time (COT) information; determining cast information from a transmission received from the second WTRU, the additional WTRU, or both the second WTRU and the additional WTRU, provided that the grant is for transmitting on the SL during a COT associated with the second WTRU or the additional WTRU; performing a listen-before-talk (LBT) procedure using a set of parameters associated with the information received from the second or additional WTRU; and transmitting data including second COT information based on the determined CAST information on the condition that the LBT procedure is successful; The method, wherein the grant is obtained via the first WTRU selecting a grant.

2. The method of claim 1 , wherein the permission is obtained from a base station.

3. The method of claim 1 , wherein the cast information indicates a unicast cast type.

4. The method of claim 1 , wherein the cast information indicates a groupcast type.

5. The method of claim 1 , wherein the received information is the first COT information.

6. The method of claim 1 , wherein the received information is the cast information.

7. The method of claim 1 , wherein the set of parameters associated with information received from the second or additional WTRU includes a transmission priority.

8. The method of claim 1 , wherein the set of parameters associated with information received from the second or additional WTRU includes an indirection number.

9. The method of claim 8 , wherein the indirect number is received from the second or additional WTRU via a sidelink control information (SCI) transmission.

10. A first wireless transmit / receive unit (WTRU), a receiver, a transmitter, and a processor; The receiver and processor are configured to obtain a grant on a side link (SL); the receiver is configured to receive a transmission from a second or additional WTRU, the transmission including a first channel occupancy time (COT) information; The processor, determining cast information from a transmission received from the second WTRU, the additional WTRU, or both the second WTRU and the additional WTRU, provided that the grant is for transmitting on the SL during a COT associated with the second WTRU or the additional WTRU; configured to perform a listen-before-talk (LBT) procedure using a set of parameters associated with information received from the second or additional WTRU; The transmitter is configured to transmit data including second COT information based on the determined CAST information on the condition that the LBT procedure is successful; The grant is obtained via the first WTRU selecting a grant.

11. The first WTRU of claim 10 , wherein the permission is obtained from a base station.

12. The first WTRU of claim 10 , wherein the cast information indicates a unicast cast type.

13. The first WTRU of claim 10 , wherein the cast information indicates a groupcast type.

14. The first WTRU of claim 10 , wherein the received information is the first COT information.

15. The first WTRU of claim 10 , wherein the received information is the cast information.

16. The first WTRU of claim 10, wherein the set of parameters associated with the information received from the second or additional WTRU includes at least one of a transmission priority.

17. The first WTRU of claim 10 , wherein the set of parameters associated with the information received from the second or additional WTRU includes an indirection number.

18. The first WTRU of claim 17, wherein the indirect number is received from the second or additional WTRU via a sidelink control information (SCI) transmission.

Images