Radio (NR) vehicle to vehicle (V2X)-methods for scheduling sidelink in unlicensed spectrum

Abstract

To provide methods and apparatuses for scheduling sidelink communications in an unlicensed spectrum.SOLUTION: A method performed by a first wireless transmit / receive unit (WTRU) may comprise: obtaining a grant for transmission on a sidelink (SL); receiving, from a second WTRU or an additional WTRU, a transmission that includes first channel occupancy time (COT) information; on a condition that the grant is for transmission on the SL during a COT associated with the second WTRU or the additional WTRU, determining, from the transmission received from the second WTRU, the additional WTRU, or both the second and the additional WTRUs, cast information; performing a listen before talk (LBT) procedure using a set of parameters associated with information received from the second WTRU or additional WTRU; and on a condition that the LBT procedure is successful, transmitting, based on the determined cast information, data that includes second COT information.SELECTED DRAWING: Figure 3

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 Oct. 19, 2021; U.S. Provisional Patent Application No. 63 / 326,401, filed Apr. 1, 2022; and U.S. Provisional Patent Application No. 63 / 353,939, filed Jun. 21, 2022, the contents of which are incorporated herein by reference.

Background Art

[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 a WTRU may receive assistance from a network and initiate transmission and reception of V2X messages. Another scenario of V2X operation is an out - of - coverage scenario, where a WTRU may use one or more pre - configured parameters to initiate transmission and reception of V2X messages.

[0003] V2X communication is supported in LTE and is suggested from previous research on device - to - device (D2D) communication. V2X communication services may be composed of various types, including vehicle - to - vehicle (V2V), where vehicle WTRUs may communicate directly with each other; vehicle - to - infrastructure (V2I), where vehicle WTRUs may communicate with an RSU / eNB; vehicle - to - network (V2N), where vehicle WTRUs may communicate with a core network; and vehicle - to - pedestrian (V2P), where vehicle WTRUs may communicate with a WTRU under special conditions (e.g., low battery capacity).

Summary of the Invention

[0004] A method and apparatus for scheduling sidelink communication in an unauthorized spectrum are disclosed. A method performed by a first wireless transmit / receive unit (WTRU) may include obtaining permission for transmission on a sidelink (SL), receiving a transmission from a second WTRU or an additional WTRU that includes first channel occupancy 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 transmission 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 transmitting data including second COT information based on the determined cast information, provided that the LBT procedure is successful.

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

Brief Description of the Drawings

[0006] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals in the figures indicate like elements.

Fig. 1A

Fig. 1B

Fig. 1C

Fig. 1D

Fig. 2

Fig. 3

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

[0008] As shown in FIG. 1A, the communication system 100 can 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 is understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which can be referred to as a station (STA), can be configured to transmit and / or receive wireless signals and can be a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscriber-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a wristwatch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., telesurgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), a home electronic device, a device operating in a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

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

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

[0011] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via wireless interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 may be established using any suitable Radio Access Technology (RAT).

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

[0013] In one embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can 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 stations 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish the air interface 116 using NR.

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

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

[0017] The base station 114b in FIG. 1A can be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, but can utilize any suitable RAT to facilitate wireless connection in a local area such as a workplace, home, vehicle, campus, industrial facility, aerial corridor (e.g., for use by drones), a location such as a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106.

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

[0019] CN106 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides a Plain Old Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, where these networks and devices use a common communication protocol 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 network 112 may include a wired communication network and / or a wireless communication network that is owned and / or operated by other service providers. For example, the network 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 WTRU102a, 102b, 102c, 102d in the communication system 100 may include a multi-mode function (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A may be configured to communicate with a base station 114a that may use a cellular-based wireless technology and a base station 114b that may use IEEE802 wireless technology.

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

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

[0023] The transmit / receive element 122 may be configured to transmit signals to a base station (e.g., base station 114a) or receive signals from a base station (e.g., base station 114a) via 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, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0024] Although the transmit / receive element 122 is depicted in FIG. 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via 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 noted 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 can be connected to the speaker / microphone 124, keypad 126, and / or display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit), and can receive data input by the user from these. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Note that the processor 118 can access information from and store data in any suitable type of memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 can access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

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

[0029] Processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, peripheral devices 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 / Augmented Reality (VR / AR) device, an activity tracker, etc. Peripheral devices 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0030] WTRU 102 may include a full-duplex radio in which some or all of the transmissions and receptions of signals (e.g., associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be simultaneous and / or together. The full-duplex transmission mode radio may include an interference management unit for reducing and / or substantially eliminating self-interference either via hardware (e.g., a choke) or via signal processing (e.g., via an individual processor (not shown) or processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for some or all of the transmissions and receptions of signals (e.g., associated with specific subframes for either UL (e.g., for transmission) or DL (e.g., for reception)).

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

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

[0033] Each of 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, user scheduling, etc. in UL and / or DL. As shown in Figure 1C, eNode-Bs 160a, 160b, 160c may communicate with each other via the X2 interface.

[0034] CN 106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the foregoing elements are shown as part of 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 can be connected to each of the eNode-Bs 162a, 162b, and 162c in the RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can authenticate users of the WTRUs 102a, 102b, 102c, activate / deactivate bearers, select a specific serving gateway during the initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions for exchange between the RAN 104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

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

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

[0038] CN106 may facilitate communication with other networks. For example, CN106 may provide access to a circuit-switched network such as the PSTN 108 to WTRUs 102a, 102b, 102c to facilitate communication between the WTRUs 102a, 102b, 102c and a conventional landline communication device. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and the PSTN 108. Additionally, CN106 may provide access to other networks 112 to WTRUs 102a, 102b, 102c, where other networks 112 may include other wired and / or wireless networks owned and / or operated by other service providers.

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

[0040] In a representative embodiment, 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 an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic to an STA originating from outside the BSS may reach the STA through the AP and be delivered to the STA. Traffic originating from an STA to a destination outside the BSS may be sent to the AP and delivered to each destination. Traffic between STAs within the BSS may be transmitted, for example, via the AP. The source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be regarded as and / or referred to as peer - to - peer traffic. Peer - to - peer traffic may be transmitted with a direct link setup (DLS) directly between the source STA and the destination STA (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 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 the "ad - hoc" communication mode.

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

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

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

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

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

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

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

[0049] RAN 104 may include gNBs 180a, 180b, and 180c, although it will be understood that RAN 104 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 108b may utilize beamforming to transmit and / or receive signals to / from gNBs 180a, 180b, and 180c. Thus, gNB 180a, for example, may transmit a wireless signal to WTRU 102a and / or receive a wireless signal from WTRU 102a using multiple antennas. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum and the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0050] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM subcarrier interval can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including varying numbers of OFDM symbols and / or varying lengths of absolute time durations).

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

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

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

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

[0055] SMF183a and 183b can be connected to AMF182a and 182b in CN106 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN106 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the traffic path through UPF184a and 184b. SMF183a and 183b can perform other functions such as the function of managing and allocating UE IP addresses, the function of managing PDU sessions, the function of implementing policies and controlling QoS, and the function of providing DL data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

[0056] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c in RAN104 via the N3 interface, thereby providing access to a packet-switched network such as the Internet 110 to WTRU102a, 102b, and 102c to facilitate communication between WTRU102a, 102b, and 102c and IP-corresponding devices. UPF184 and 184b can perform other functions such as packet routing and forwarding, implementation of user plane policies, support for multi-home PDU sessions, processing of user plane QoS, buffering of DL packets, and provision of mobility anchoring.

[0057] CN106 may facilitate communication with other networks. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. Note that CN106 may provide access to other network 112 for WTRU102a, 102b, 102c, where other network 112 may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local DN185a, 185b through UPF184a, 184b via an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0058] In view of FIGS. 1A - 1D and the corresponding descriptions of FIGS. 1A - 1D, one or more or all of the functions described herein with respect to one or more of WTRU102a - 102d, base stations 114a - 114b, eNode - Bs 160a - 160c, MME162, SGW164, PGW166, gNB180a - 180c, AMF182a - 182b, UPF184a - 184b, SMF183a - 183b, DN185a - 185b, and / or any other device(s) described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

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

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

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

[0062] [Table 1]

[0063] LTE defines two operation modes in V2X communication, namely Mode 3 and Mode 4. In Mode 3, the network may provide the WTRU with an allocation for V2X sidelink transmission 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, namely, (1) a reception pool that can be monitored to receive V2X transmissions, and (2) a transmission pool that can be used by the WTRU to select transmission resources in Mode 4. The transmission pool is not used by the WTRU configured in Mode 3.

[0064] In LTE, the resource pool may be signaled to the WTRU semi-statically 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 be carried only via SIB and / or dedicated RRC signaling.

[0065] 5G NR has 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 pool and sensing for Mode 2 resource allocation are also inherited from LTE.

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

[0067] In New Radio, an Unlicensed Spectrum (NR-U) is designated. NR-U supports NR radio access operating in shared spectrum channel access to operate in different modes, where any of the PCell, PSCell, or SCell may be in the shared spectrum, and the SCell may or may not be configured in UL.

[0068] To support NR-U, the following modifications are made to the PHY layer signals and channels, namely, (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 of search space sets, (3) an additional PDSCH mapping type B length is introduced to enable transmission at the start of the COT as soon as the COT is started, (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 interleaving structure is introduced for PUCCH and PUSCH, and the PUCCH format is extended to a PRB interleaved waveform, but is included within one RB set, (6) SRS transmission may be on any symbol of the slot, (7) the gNB may schedule multiple consecutive PUSCHs with a single DCI format.

[0069] A WTRU operating in the 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, only the gNB may start the COT at a specific time notified by its fixed frame period (FFP) configuration. The WTRU may share the semi-static channel if gNB DL transmission is detected in an earlier part of the same FFP. In other embodiments, the WTRU may be configured using a WTRU-FFP and may start the COT at a specific time determined from the WTRU-FFP configuration.

[0070] CCA (Clear Channel Assessment) may be performed in 20 MHz units. The following types of LBT are specified, namely, (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 started using CAT4 LBT. The COT may be shared by the node that receives the transmission from the COT start 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). The CAPC for radio bearers and MAC CE is either fixed or configurable, namely, (1) fixed to the lowest priority for padding BSR and recommended bitrate MAC CE, (2) fixed to the highest priority for SRB0, SRB1, SRB3, and other MAC CE, and / or (3) configured by the gNB for SRB2 and DRB.

[0073] When selecting the CAPC for a DRB, the gNB may consider the five QIs of all the QoS flows multiplexed in that DRB, taking into account the 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 non-standardized 5QIs (i.e., operator-specific 5QIs) should use the CAPC of the standardized 5QI that most closely matches the QoS characteristics of the non-standardized 5QI.

[0074]

Table 2

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

[0076] In NR-U, access to the channel assumes the conventional Uu architecture. Specifically, the gNB schedules multiple WTRUs within its coverage, and the gNB is assumed to be fixed in position. Transmissions by the WTRUs scheduled by the gNB when the channel is accessed are targeted at the gNB. However, in the case of SL operation in the shared spectrum, these assumptions may no longer be valid.

[0077] One issue that arises is the Mode 1 scheduling problem. In Mode 1 SL, the gNB schedules SL resources for the WTRU. The scheduling DCI may be in the shared spectrum (possibly the same shared spectrum as the WTRU transmission). However, the WTRU transmission may be targeted at another WTRU instead of the gNB. For this reason, the gNB may not be aware whether the WTRU has acquired the channel following the DCI. Furthermore, there may be scenarios where the gNB does not have to perform the LBT procedure for access to the channel on which the WTRU is to 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] A second issue is that the SL architecture may require a new way to determine the LBT parameters. LBT parameters such as the channel width (CW) size, maximum COT length, and permitted CW size mainly depend 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, and other transmissions (e.g., unicast) are typical of WTRUs moving together. These factors can affect the LBT parameters required for such transmissions. They can also affect the COT usage rules, such as whether a WTRU may share a COT initiated by another WTRU.

[0079] In this specification, the term "starting 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). A WTRU may identify a grant as a type 1 LBT grant or a type 2 LBT grant. The determination of whether to perform a transmission in a grant and which type of transmission based on whether the WTRU is starting or sharing the grant may be derived based on the identification of the LBT type to be performed for that grant, as discussed in this specification.

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

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

[0082] The LBT behavior may include the same access class / classification that determines the CAPC or 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 the UL CAPC table for LBT or use the DL CAPC table for LBT. For example, the LBT behavior herein may include the WTRU determining whether only one of the UL / DL CAPC tables can be used or whether either table can be used. For example, the LBT behavior may include the WTRU determining whether any access priority class can be selected for transmission or whether only a specific access priority class can be selected 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 first mapping) or determine the CAPC in a second mechanism (e.g., using a second table or second mapping). The first or second mapping may consist of mapping any property of this specification to the CAPC. For example, the first mapping may consist of a mapping between the PQI (QoS profile indicator) and the CAPC, and the second mapping may consist of a mapping between the logical priority and the CAPC.

[0084] The LBT behavior may involve determining between a first rule for obtaining the CAPC from transmissions each having their own CAPC (e.g., using the highest priority of the CAPCs included during transmission) and a second rule for obtaining the CAPC from such transmissions (e.g., using the lowest priority of the CAPCs included during transmission). For example, the WTRU may use the lowest priority of the CAPC for one type of transmission (e.g., mode 1 transmission) and may use the highest priority of the CAPC for another type of transmission (e.g., mode 2 transmission). The type of transmission may be further composed of any of the SL characteristics defined herein, which are not necessarily limited to mode, such as the priority (either data / control included in the PDU), CBR, etc.

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

[0086] The LBT behavior may include any existing LBT parameters, such as the contention window size (CWS), the maximum COT length, the acceptable CW size, the CW adjustment procedure, the number of CCAs, the CCA duration, the deferral period, and / or the FFP parameters applied 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 determining whether to use / consider a parameter (such as the deferral period) as part of the LBT. For example, the LBT behavior may include the WTRU selecting the CWS from one of a set of configured values, the WTRU increasing the CWS by a specific amount for each transmission, etc. For example, the LBT behavior may include determining whether to use a first CW adjustment procedure (or set of procedure parameters) or a second CW adjustment procedure (or another set of procedure parameters). For example, selecting an LBT parameter may include either selecting one of a plurality of (pre-)configured values or directly determining the value of the parameter itself from time-related SL characteristics such as PDB, HARQ RTT, separation between different SL channels, etc.

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

[0088] The LBT behavior may also include the LBT beam, beamwidth, or beam direction (including omni-directional). For example, the LBT behavior may include the WTRU selecting the LBT beamwidth, the number of channels / sub-channels on which LBT is performed to obtain access to the channel, etc.

[0089] The LBT behavior may also include any new LBT parameters specific to the SL that determine channel access behavior, such as any acceptable / minimum / maximum delay between events for accessing the channel, and such events may be related to the measurement of energy, or the 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 determining channel occupancy. The LBT behavior may also include the number of time slots or equivalents used for determining channel occupancy.

[0091] The LBT behavior may also include the number of instances of application of procedures related to channel access, such as LBT, or a part of LBT (where 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 LBT can be attempted before a second action (potentially mentioned herein) can be initiated.

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

[0093] The LBT behavior may also include whether the WTRU is permitted to share a COT initiated by a base station (e.g., 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 is necessary to start a new COT for transmission.

[0094] The LBT behavior may also include a minimum / maximum time between a previous transmission (e.g., from another WTRU or 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 be determined by the WTRU that starts the COT and may include the COT length transmitted in the COT structure information in some cases. 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 restricts the selected COT length to a specific value.

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

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

[0098] Any of the LBT procedures associated with the LBT behavior described above may have multiple independent / simultaneous instances of the LBT procedure. The WTRU then performing LBT for transmission using a particular factor may use the parameter associated with that instance of the procedure.

[0099] The WTRU may have different CW adjustments for HARQ enabled / disabled transmissions. In one embodiment, the WTRU may perform different CW adjustments based on whether the transmission is associated with HARQ enabled transmission or HARQ disabled transmission. For example, the WTRU may use different adjustment parameters / values following a transmission that includes enabled HARQ feedback versus disabled HARQ feedback. In another example, the WTRU may set the CW to a default value or a 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 a transmission with HARQ feedback disabled. In another example, the WTRU may ignore all transmissions with disabled HARQ feedback in the determination of CW updates. 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 during a 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. Further, if the 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 a non-static WTRU. In another example, the determination of 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 determine whether to perform transmission in a state where HARQ feedback is enabled or disabled based on a CW adjustment state that may consist of, for example, the value of CW, the number of times CW has increased since the last reset of the value, whether the value exceeds a (pre-)configured threshold, etc. For example, when the value of CW exceeds the threshold, the WTRU may perform transmission with HARQ feedback enabled. For example, when the number of consecutive increases in CW since the last reset exceeds the threshold, the WTRU may perform transmission with HARQ feedback enabled.

[0101] Mode 1 scheduling for SL may depend on the capabilities of a base station (e.g., gNB) having access to channel availability information (e.g., information about the COT obtained by the SL 3GPP system). In one embodiment, the WTRU may determine whether to perform the LBT procedure on 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 the LBT procedure is required / not required and / or the type of LBT required in the DCI scheduling the SL grant. The WTRU may determine whether LBT is required / not required or the type of LBT based on the time difference between the reception of the scheduling DCI and the scheduled SL resource. Here, for example, the WTRU may be (pre-)configured using a mapping of the LBT type to the time difference between the scheduling DCI and the SL resource and use that time difference to determine the type of LBT to perform. For example, the WTRU may assume that LBT is not required or a short LBT is required when the time between the scheduling DCI and the SL resource is below a threshold.

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

[0104] Furthermore, combinations of the above examples are possible. For example, the WTRU may receive an explicit indication as to whether to perform type 1 LBT or the type of LBT 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 conditions 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 no LBT procedure is required or a short LBT procedure is required if the time between the scheduling DCI and the SL resource is less than a threshold (only in the case of the same carrier).

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

[0107] In another embodiment, the WTRU may determine LBT parameters according to the source of the received SCI. Specifically, the WTRU may determine the LBT type or parameters as the following combinations, that is, (1) CAPC or similar information in the DCI and / or SCI, (2) the time gap between detected SCI transmissions on the SL compared with a threshold value (such a threshold value may be determined or derived by the information in the DCI in addition to other SL-specific information described in this specification), 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 by RRC signaling.

[0108] In another embodiment, the WTRU may determine LBT parameters based on whether the DCI and the SL transmission are on the same (unauthorized) carrier. Specifically, the WTRU receiving the DCI on the same unauthorized carrier as the SL transmission may interpret the reception of the DCI as the start of the COT by the base station (e.g., gNB). Alternatively, when the DCI is received on a carrier different from the SL carrier, the WTRU may determine whether to rely on the SL transmission to start the COT or whether the COT is started by another WTRU.

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

[0110] For example, when 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. In this case, it may correspond to a scenario where the base station (e.g., gNB) performs LBT to transmit the DCI itself. If the WTRU does not receive CAPC in the DCI, the WTRU may determine the LBT type to execute based on the SCI transmission. Specifically, if the WTRU does not find a COT started by another sharing WTRU, the WTRU may perform type 1 LBT. Otherwise, if sharing the COT, the WTRU may perform an LBT where the type may be determined based on the time gap between the WTRU permission and the last SCI / transmission by another WTRU. Similarly to the above, the WTRU may also determine the type of data (e.g., priority, cast, etc.) based on similar rules.

[0111] The COT information by the WTRU (e.g., in a similar format to 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 the information periodically, for each x transmission, for each x time period, in the SCI transmission starting the COT, at the time of receiving the SCI starting the COT, or in a subset of the SCI transmissions 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 the SL MAC CE, SL RRC message, inter-WTRU resource coordination message, or similar messages. The WTRU may transmit COT information that determines when it starts the COT.

[0113] Alternatively, or in addition, the WTRU may transmit COT information received from a base station (e.g., gNB) and / or another WTRU (e.g., when it has determined to share the 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 on the SL from the information received from the base station (e.g., gNB). The COT information may include any COT information described herein. For example, the WTRU may receive the remaining COT length from a base station (e.g., gNB). The WTRU may calculate the 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 the SL MAC CE transmitted with its own transmission. Alternatively, the WTRU may determine to transmit COT information from another WTRU. In some cases, the WTRU may determine to transmit COT information from another WTRU even if it does not share the COT in question.

[0114] In one embodiment, the 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., gNB). For example, such reporting may be sent on the PUCCH, SR, in the form of HARQ feedback, CG-UCI, MAC CE, or an RRC message. The COT information may include any of the following: namely, (1) the COT structure (e.g., the time / frequency resources associated with the COT), (2) the remaining COT duration, (3) the CAPC associated with (or used to initiate) the COT, (4) the LBT statistics collected by the WTRU (e.g., the number of occupied / available resources within a CW), (5) characteristics of the COT that determine the WTRU that initiated the COT or transmitted the COT information or the type of COT transmission (as defined herein) or the usability property of the COT, such as the L2 ID, WTRU type (e.g., sensing / non-sensing WTRU, DRX WTRU, release or profile of the WTRU), 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) the energy detection threshold used to initiate the COT, (10) the LBT type or parameters used to initiate the COT, (11) FFP parameters, (12) a set of LBT BW associated with the COT (which may include the set of BWs on which LBT was performed, the set of BWs considered to have a successful LBT, or the set of BWs considered to have a failed LBT), (13) (sensing-based) occupied / available resources placed within the COT, (14) QoS information (e.g., priority) associated with the transmission that initiated the COT, (15) the expected gap between two sidelink transmissions, or the presence of a gap between two sidelink transmissions, (16) whether the transmission that initiated the COT is an initial transmission or a retransmission, (17) the identification 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., gNB) or another WTRU.

[0115] The COT information may also include information within the COT as to when transmissions by one or more other WTRUs or by the WTRU will end (i.e., the time position) (e.g., the WTRU may determine the existence of a COT started by the WTRU based on receipt of an SCI indicating the start of the COT by the transmission of its SCI. The SCI may further include the duration of the COT. 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 the SCI transmission or information within the SCI) the time slot within the COT in which SL resources within the COT will become available and may transmit this timing information to a base station (e.g., a gNB)).

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

[0117] The WTRU may be triggered to report the COT information to a base station (e.g., a gNB). The trigger may include at least one of the following, i.e., (1) receipt of a DCI, (2) the content of the DCI (e.g., a field in the DCI may trigger the reporting of COT information), (3) receipt of an SCI, (4) the content of the SCI (e.g., a field in the SCI may trigger the reporting of COT information), (5) transmission of an SR for using the COT, (6) based on the result of LBT. For example, the WTRU may report the COT information if it has succeeded or failed in LBT for sharing or starting a COT, and / or (7) based on a request to start a different COT. The WTRU may report one or more COT information based on receipt of transmissions from one or more other WTRUs.

[0118] In one embodiment, the WTRU may report COT information on UL resources associated with a COT initiated / used by the WTRU itself on SL, which may be associated with an SL permission provided by the network in some cases. Such reporting may be sent on the PUCCH, SR, for example, in the form of HARQ feedback, CG-UCI, MAC CE, or an RRC message. Such information may include any of the same information as the information in the foregoing embodiments (e.g., WTRU reporting information received from a peer WTRU). In addition, the WTRU may further report the following, namely, (1) the time instance at which the COT was initiated / should end, (2) LBT statistics collected by the WTRU (e.g., the number of occupied / available resources within a 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 statistic associated with a failed LBT, such as RSSI, the number of available resources in the CW, etc.), (5) whether the WTRU was successful / failed in transmitting on a shared COT, (6) whether the WTRU acquired the channel since it initiated its own COT, or shared the COT with another WTRU, (7) the amount of time remaining within the COT (which the WTRU could share), or whether such time exceeds / falls below a threshold (such a threshold may depend on the properties of the data transmitted by the WTRU, e.g., priority), (8) in some cases, the number of times the WTRU was successful / unsuccessful in initiating the COT over a particular time period, associated with a particular CAPC or LBT behavior in some cases, (9) and / or the L2 ID associated with the transmission that initiated or shared the COT.

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

[0120] In one exemplary embodiment, the WTRU may be composed of one PUCCH resource (optionally associated with an SL grant) for indicating whether the LBT was successful and another PUCCH resource (optionally associated with the same SL grant) for reporting HARQ ACK / NACK to the base station (e.g., gNB). Specifically, if the WTRU can acquire the SL channel in the grant, it may transmit an ACK on the first PUCCH resource and then transmit the 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 whether (1) the WTRU's transmission on the grant was achieved by sharing an existing COT (indicated, e.g., using the first code point) or starting a new COT (indicated using the second code point), or the channel was not acquired for the grant (indicated using the third code point), or (2) the WTRU acquired a COT with a remaining COT length greater than (using the first code point) or less than (using the second code point) 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 (using the third code point) that it did not acquire the channel for the grant.

[0121] In another way, the WTRU may transmit feedback on a single PUCCH resource. The feedback may indicate one of three states, ACK, NACK, or DTX, where DTX may indicate that the transmission was not executed due to a failed LBT.

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

[0123] If the WTRU starts its own COT, the WTRU 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 obtain the channel and transmit the created UCI to the base station (e.g., gNB). If the WTRU is unable to obtain a channel, the WTRU may indicate such in the UCI and may also include additional information regarding the reason for the failure of the access, such as, for example, (1) LBT failure when attempting to obtain a new COT and the potential LBT statistics associated with the failure, (2) LBT failure when attempting to obtain an existing COT started by another WTRU and the potential LBT statistics associated with the failure (e.g., the gap between transmissions and the type of LBT the WTRU was required to perform), (3) the remaining COT length of the existing COT at the time of permission is shorter than required and, thus, not obtained by the WTRU, and / or (4) the L2 ID associated with the transmission that started the COT.

[0124] In one example, the WTRU may be configured with SR resources to indicate a failure to obtain an SL channel. The WTRU may be further configured with different SR configurations depending on the priority of the data multiplexed in the PDU that should have been transmitted on a permission where the LBT failed.

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

[0126] The WTRU may trigger / transmit the reporting of the COT information when the WTRU receives information regarding a new possible COT that it was able to initiate (based on its own channel access) or detect (based on reception from another WTRU). In one example, the WTRU may transmit the COT information to the base station (e.g., in a MAC CE) when determining 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 the COT information to the base station (e.g., a gNB) (e.g., in a MAC CE) when there is a change in the COT information previously reported to the base station. For example, the change in the COT information may be the occurrence of a gap within the COT that is larger than a (previously) configured threshold (e.g., due to the absence of an SL transmission). The change in the COT information may be the reception of a message (e.g., from a second WTRU) indicating a predicted COT length that is shorter than the COT length first indicated for the same COT (e.g., by a first WTRU).

[0128] When the WTRU is configured with conditions regarding whether to report COT information received from other WTRUs or determined by the WTRU (e.g., via RRC configuration or via MAC CE), the WTRU may trigger / send a report of the COT information. For example, the conditions may include, i.e., (1) reporting COT information (e.g., for a newly detected COT) as long as the remaining COT length is smaller / greater than a threshold, (2) reporting COT information as long as the CAPC is above / below a threshold, (3) reporting COT information as long as the maximum time gap in a (potentially scheduled) transmission within the COT exceeds / falls below a threshold, and / or (4) reporting COT information if the information of a (potentially the same) COT has changed by a certain amount (e.g., the COT length has changed by an amount) compared to a previous report.

[0129] The thresholds for the above conditions may depend on data available for transmission by the WTRU, such as the priority, remaining PDB, or channel measurement values such as CBR. For example, the WTRU may determine a threshold COT length based on the priority of data pending transmission in the WTRU. If the WTRU detects a COT whose COT length is greater than the determined threshold (based on information received from another WTRU), 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 initiate the second COT. The WTRU may use only the COT associated with the base station (e.g., gNB) for transmission to the base station (e.g., gNB). The WTRU may share the COT associated with the base station (e.g., gNB) for transmission to another WTRU. The WTRU may indicate a set of COT information in transmission to the base station (e.g., gNB). One of the COT information transmitted to the base station (e.g., gNB) may be associated with the COT associated with the base station (e.g., gNB).

[0131] In one embodiment, the WTRU may initiate an LBT procedure on the SL when it instructs the network that it has SL data to be transmitted. For example, the WTRU may be configured (in advance) at a time instance following the transmission of an SL SR / BSR that initiates the LBT. Such a time instance may depend on properties of the data to be transmitted, such as information provided in QoS, cast, or 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 DCI or during some time period following the receipt of DCI. The time period may be pre-configured, indicated in the DCI, and / or depend on measurements of the transmitting SL and / or QoS.

[0133] In another embodiment, the WTRU may be provided with multiple SL grants, which may be (in some cases, a single DCI, and in other cases, a pattern composed of DCI and RRC or MAC CE). The multiple SL grants may be explicitly indicated within the DCI. Alternatively, the multiple SL grants may follow a pre-defined time / frequency pattern. The purpose of the grant may be to enable the WTRU to attempt the LBT procedure multiple times on the SL. Specifically, the WTRU may attempt LBT in a first grant. If the LBT fails, it may attempt LBT on a second grant, and so on.

[0134] The WTRU may further notify the network whether it has successfully accessed the channel using LBT (e.g., using UCI or COT information described herein). The WTRU may further cancel any subsequent grants following channel acquisition in a previous grant. Alternatively, the WTRU may be configured to determine whether to hold or cancel subsequent grants based on the following, i.e., (1) the amount of data in the buffer (e.g., if the WTRU has data available for transmission associated with a particular priority in some cases, it may maintain one or more of the subsequent grants), (2) channel congestion (e.g., if the CBR exceeds a threshold, the WTRU may cancel subsequent grants, and if not, it may hold them), (3) the number of remaining subsequent grants (e.g., the WTRU may be composed of the maximum number of subsequent grants it can maintain and drop the rest), (4) the priority of the data in the buffer, (5) any combination of (1) to (4) above, and / or (6) any other condition described herein (e.g., associated with the multi-LBT occasion described herein).

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

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

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

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

[0139] In one embodiment, the WTRU may determine whether to create its own COT information for transmission or transfer / transmit the COT information received from another WTRU or base station based on whether the WTRU starts a COT or shares a COT started by another WTRU or base station. Specifically, if the permission or potential permission of the WTRU does not fall within an existing COT, the WTRU may start its own COT and create COT information (COT structure) based on the LBT used to create the COT within its own transmission.

[0140] If the permission or potential permission of the WTRU falls within a COT started by a base station or another WTRU, the WTRU may transmit the COT information received in the transmission of the other WTRU or base station (i.e., the COT structure indicated by the other WTRU). The WTRU may determine whether to share the existing COT or start a new COT according to 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] The 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 started by another WTRU). Here, the term "combination" may refer to using two or more factors when determining the LBT behavior. The combination may refer to excluding one behavior due to the presence of one factor and selecting from the remaining behaviors based on other factors. The combination may refer to determining one LBT behavior based on the first factor and determining another LBT behavior based on the second factor. The combination may refer to determining the number or type of LBT behaviors to be determined based on factors and, at the same time, selecting behaviors based on other factors.

[0142] For example, any of the following factors may be used to determine the LBT behavior (e.g., LBT parameters) when starting 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) should be used when accessing a channel to share a COT. Further, 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 the case of an L2 ID, it may be the L2 ID used to start the COT and / or the L2 ID of the transmission that will share the COT).

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

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

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

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

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

[0148] The HARQ behavior may refer to whether the transmission / reception is associated with HARQ enabled or HARQ disabled. The HARQ behavior may refer to a (pre-)configured HARQ delay or the RTT on the sidelink. The HARQ behavior may refer to whether a HARQ-specific channel (PSFCH or PUCCH) is configured. The HARQ behavior may, in some cases, refer to some potentially consecutive HARQ feedback of a particular type (ACK / NACK / DTX) that is 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 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 QoS for transmission / reception may refer to the priority of transmission. The QoS for transmission / reception may refer to the (pre-)configured parameters associated with the SLRB. The QoS for transmission / reception may refer to the PQI, or similar QoS parameters related to the QoS flow. The QoS for transmission / reception may refer to whether the transmission is on the SL SRB or on the 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 assume 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 when the received priority is the first priority, the COT length, or the time not to perform a full LBT following the reception by another WTRU, is a first value, and may assume a second value when the received priority is the second priority.

[0150] The MCR-related quantity for the minimum communication range (MCR) 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 transmission MCR. The MCR-related quantity may refer to the remaining distance 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 transmission following reception from another WTRU based on the calculated distance between that WTRU and itself. The WTRU may always perform type 1 LBT as long as the distance exceeds a threshold.

[0151] The WTRU may determine its LBT parameters based on the transmission MCR. Specifically, the WTRU may be configured with the CW length (or other parameters affecting its LBT) for the MCR or range of MCRs. In the case of a TB associated with the MCR, the WTRU may select an appropriate CW length. The WTRU may be configured with an offset (e.g., an increase in CW length) applied for each increase in the MCR from a specific baseline value. The WTRU may determine whether to use the UL CAPC table or the DL CAPC table based on whether the transmission has an MCR and / or 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 the upper layer).

[0152] The zone-related quantity may refer to the specific zone in which the WTRU is located and whether such a zone is associated with one or more pre-configured zones (e.g., part of a list). 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 the 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 over which the CBR is measured.

[0154] The distance between two WTRUs may refer to the determined distance between the two WTRUs (e.g., the WTRU starting the COT and the 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 within a group. For example, the group-related quantity may refer to a group ID configured by a higher layer. The group-related quantity may also refer to a group-cast 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 the higher layer). Specifically, the WTRU may be configured with different COT lengths for one or a set of group sizes 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 transmission of the peer WTRU 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. Further, the WTRU may determine to have a different LBT behavior if the COT was initiated by an L2 ID that the WTRU is interested in and / or if the WTRU is assigned a group number for that L2 ID. For example, the WTRU-initiated COT may include a group member ID within the transmission. A second WTRU may determine whether it can share the COT with the initiating WTRU and / or 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 refer to whether the transmission / reception consists of a specific message associated with 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 an inter-WTRU coordination message. For example, when receiving / transmitting a DCR message, the WTRU may assume that no LBT is required or only a specific LBT is required until the establishment of the unicast link initiated by the DCR message.

[0157] The SL channel or channel type may indicate whether a transmission / reception configuration is performed on a specific 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, this may refer to the number of retransmissions associated with the retransmission.

[0159] The remaining PDB or time latency requirement may refer to the remaining PDB associated with the transmission at the time of LBT, or the amount of time with respect to T2 (or any sensing-based window or time frame). The remaining PDB or time latency requirement may refer to the CSI feedback latency limit, or the remaining time within that latency limit 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 the transmission may indicate the presence or 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 the transmission may indicate whether the SCI is used to trigger a CSI report. The content included in the SCI associated with the transmission may indicate whether the SCI reserves any future resources. The content included in the SCI associated with the transmission may indicate the time between the current transmission and the future reserved resources (e.g., whether it exceeds or is less than a specific value).

[0161] Any parameter 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 the percentage of available resources, the number of selected resources, the timing between selected resources, whether a retransmission resource has been selected, whether a sufficient number of resources are available (in any given instance of availability determination), etc. The sensing mechanism may refer to the amount of resources considered available within a particular time that may represent the COT, and / or the required latency of a pending transmission in the WTRU.

[0162] Being associated with a resource pool may refer to a particular resource pool or a configuration associated with the resource pool, and may be applicable when transmission / reception is performed on resources associated with this pool.

[0163] The allocation mode may refer to whether the transmission / reception is in 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 the transmission that started the COT and / or the mode of its own transmission. The WTRU may share the COT if the WTRU attempting to share the COT is using the same transmission mode (mode 1 or mode 2) as the WTRU that started the COT. A WTRU transmitting using mode 2 may or may not share the COT with a WTRU that started the COT using mode 1 and / or mode 2.

[0164] Another factor may be the time between a previous transmission and the WTRU's own transmission. If the WTRU detects a transmission (previous transmission) of another WTRU that is performed in slot N-1, it may assume that it is sharing the COT and perform a transmission in slot N. Additionally, the previous transmission in slot N-1 may also need to satisfy another condition in this specification (e.g., L2 ID / same unicast link, etc.).

[0165] Another factor may be the member ID in a groupcast. Specifically, the WTRU may assume a first LBT behavior when the member ID has a first value, and may assume 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 using the LBT behavior to be applied to a given L2 ID or L2 ID pair (e.g., by PC5-RRC, by Uu RRC, by the upper layer, etc.).

[0167] Another factor may relate to resource reservation by a WTRU or another WTRU. For example, resource reservation by a WTRU or another WTRU may refer to whether transmission is performed on resources previously reserved by the WTRU (for a new TB or for 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. Resource reservation by a WTRU or another WTRU may refer to whether transmission is performed on, follows, or is performed a certain amount of time after resources reserved by another WTRU. For example, the WTRU may use a first LBT behavior (e.g., short LBT) in a slot following a slot reserved by another WTRU and a second LBT behavior (e.g., normal LBT) in a slot not following a slot reserved by another WTRU. A similar approach may be used to solve blocking problems related to unauthorized V2X.

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

[0169] For any of the above factors associated with or indicated for a transmission decoded / received by a WTRU, such transmission is either included within a COT that the WTRU desires to share or is associated with a transmission that initiated the COT. In this specification, the characteristics of a transmission that initiated the COT, the characteristics of the last detected transmission within the COT, or the 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 a particular LBT behavior and the specific sidelink factors listed above can be envisioned by those 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 one or more data associated with the transmission from the transmitted data and, accordingly, select the CAPC. The WTRU may further indicate such a CAPC in its own transmission, in some cases when the WTRU starts a COT (as opposed to when the WTRU shares an existing COT).

[0172] The WTRU may be configured to select the CAPC based on a combination of the cast type and the LCH configuration. Specifically, the WTRU may be configured using the CAPC for each given logical channel priority and for each of unicast, groupcast, or broadcast. For example, if the 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 using a mapping of both the priority and the cast type to the CAPC.

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

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

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

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

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

[0178] The WTRU may be configured with different values of CAPC for use in transmissions that include the SL CSI MAC CE, where each CAPC value may correspond to one or a range of the configured latency limits or remaining time within the latency limit for the transmission of CSI reports to the 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 with the time difference between the selected resource and the timing of the PSFCH resource associated with 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 the 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 upper layer information (e.g., TX profile, DRX on / off, explicit information) provided by the upper layer along with the destination L2 ID. For example, the WTRU may maintain / change the CAPC associated with the L2 ID based on an SL event (e.g., HARQ, LBT failure, etc.) and may apply the CAPC to that L2 ID until changed by a subsequent event.

[0182] The WTRU may determine the CAPC to be used based on the active / configured QoS flow for a particular transmission at the L2 ID. Specifically, the WTRU may determine the CAPC for a given L2 ID transmission based on the 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 according to the SL-specific factors or characteristics described herein. For example, the WTRU may use the mapping of PQI to CAPC to determine the CAPC for mode 1 transmission, or use the 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 exceeds a threshold, and use a second mapping table when the CBR is below the threshold.

[0184] The WTRU may determine the CAPC using different rules, mapping tables, and / or criteria (or the like) according to the QoS parameter or other actual value that was first used to determine the CAPC. For example, the WTRU may use a mapping table from PQI to CAPC to determine the CAPC for transmission including data for a certain QoS flow.

[0185] However, for non-standardized PQI values, the WTRU may use different techniques such as, for example, (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 having the QoS parameter closest to the PQI parameter of the standardized PQI associated with that CAPC, (4) using the CAPC value allocated by the network (e.g., in DCI) for the last transmission associated with, possibly the same QoS or similar priority / QoS, and / or (5) using the CAPC value indicated by the peer WTRU in SL transmission or configured by the peer WTRU in PC5-RRC (e.g., as the default CAPC value to be used).

[0186] The WTRU may use any factor or rule specific to SL to determine rules associated with COT sharing with a COT initiated by another WTRU and / or a base station (e.g., 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 at which the WTRU may transmit in the COT without performing LBT, and / or the type of LBT performed for each time amount, or (2) whether the WTRU is permitted to share a COT initiated by another WTRU and / or base station (e.g., gNB), or whether the WTRU needs to initiate its own COT (i.e., perform a full LBT). The permission may be different for a COT initiated by the WTRU and a COT initiated by a base station (e.g., gNB). Such factors may also include other LBT properties referred to herein that account for factors for sharing an already initiated COT (e.g., any of the factors described above that may determine LBT behavior).

[0187] For example, the WTRU may determine COT sharing rules based on a zone ID transmitted by another WTRU and the WTRU's own zone ID. The zone ID may represent the distance between the WTRU initiating the COT and the WTRU determining whether to share a COT initiated by another WTRU. The WTRU may determine that it can share the COT if the distance is less than a threshold value.

[0188] The WTRU may determine COT sharing rules 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 transmission that initiated the COT is the same as the L2 destination ID (or within a set of related L2 destination IDs) of transmissions performed by the WTRUs sharing the COT. Further, the WTRU may be configured using LCP restrictions for permissions within the shared COT, whereby such restrictions may apply to acceptable (and possibly destination) L2 IDs that can be selected for such permissions. The WTRU may select only L2 destination IDs that are permitted to share a COT initiated by another WTRU in order to perform transmissions in the permissions that occur within the COT initiated by the other WTRU.

[0189] The WTRU may determine COT sharing rules 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 is initiated by a transmission that includes an MCR, and the WTRU is within the MCR, the WTRU may share the COT for transmissions with the same / related L2 destination ID. If the WTRU is outside of the MCR, the WTRU may not share the COT for transmissions with the same / related L2 ID.

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

[0191] The WTRU may determine whether to share a 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 exceeds a threshold, the WTRU may determine to share the COT; otherwise, the WTRU may determine to start a new COT.

[0192] The WTRU may determine whether to share a COT or start a new COT based on the remaining period of the COT and the priority / PDB of the pending transmission. Specifically, the WTRU may be configured using an association between the priority / LCH and the remaining required duration of the COT. The remaining duration of the COT may further represent the time within the remaining duration of the COT within the PDB of the transmission. If the remaining duration is less than the remaining duration required for its 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 specific network scheduling node (e.g., a base station (gNB), a cell, etc.).

[0194] The first WTRU may, in some cases, transmit a network node ID (e.g., a cell ID, a base station (gNB) ID, etc.) in its transmission on the sidelink 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 the network node ID when performing a mode 2 transmission while within the coverage of a specific network node and / or while being RRC_CONNECTED to a specific network node.

[0195] The second WTRU may determine its LBT behavior based on any one or a combination of the following, namely, the network node received from the transmission of the first WTRU, the network node associated with the scheduling of the second WTRU itself (e.g., in mode 1, the cell ID that schedules the WTRU, in mode 2, the cell ID where the WTRU is RRC_CONNECTED and camped on RRC_IDLE / RRC_INACTIVE), whether the second WTRU is, in some cases, within the coverage of the same node or outside the coverage, the transmission mode of the transmission of the second WTRU (mode 1 or mode 2), other factors affecting the LBT behavior described herein.

[0196] A mode 1 WTRU may be permitted to share the COT started by another WTRU if the other WTRUs are also in mode 1 and are scheduled by the same cell ID. A mode 2 WTRU may be permitted to share the COT started by another WTRU if the cell ID included in the COT information from another WTRU matches the cell ID of the cell on which the WTRU is connected / camped. For example, the WTRU may perform LBT using a first set of parameters if the cell ID of the WTRU itself matches the cell ID received together with the COT information, and may perform LBT using a second set of parameters if the cell ID of the WTRU itself does not match the cell ID received together with the COT information.

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

[0198] In one embodiment, the LBT behavior (e.g., whether the WTRU can share the 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 associated with the LBT for transmission matches any of the L2 IDs 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 be starting a COT. This is to enable the sidelink system to restrict COT sharing for transmissions where the WTRU that started the COT should be the intended recipient of the transmission sharing the COT.

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

[0200] The second WTRU may receive a list of L2 IDs from the first WTRU and 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 IDs of the unicast link with the first WTRU. When determining whether it can share the COT initiated by the first WTRU, the first WTRU may determine whether the destination L2 ID of the transmission of the second WTRU matches any of the L2 IDs 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 be able to share the COT with the first WTRU; otherwise, the second WTRU may not have to 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 transmission of the first WTRU 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 related L2 destination IDs from the base station (e.g., gNB). Such a list of related destination L2 IDs may represent groupcast transmissions that may share the COT. For example, if the L2 destination ID of the first WTRU transmission and the destination L2 ID of the second WTRU transmission occur in the same list, the second WTRU may share the COT with the first WTRU.

[0202] How to determine whether to use the list and 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 one or combination of the following decisions regarding whether to share the COT initiated by the first WTRU. These decisions may also be more generally applicable to an embodiment that does not assume the use of a list.

[0203] In one decision, if the first WTRU transmission is a unicast to the 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 a 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 pair of source / destination L2 IDs that match the destination / source L2 IDs in the list received from / to the first WTRU.

[0205] In another decision, 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 the 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. Further, 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 LBT to access a channel for a second WTRU, as described herein. Specifically, the second WTRU may use a list to determine whether to perform a first type or a second type of LBT. For example, the second WTRU may use a list to determine whether to use a first CW or a second CW.

[0207] The WTRU may determine whether to share a COT based on multiple conditions associated with different factors being met, or at least one condition associated with different factors being met. For example, the WTRU may share a COT if the time between a previous transmission and the WTRU's scheduled 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 also share a 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 within a certain distance from the transmission that initiated the COT.

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

[0209] Figure 2 is a diagram showing an example of unicast COT sharing. As shown in Figure 2, when the COT is initiated by the second WTRU 204 for a transmission associated with the same unicast link as the transmission of the first WTRU 202, 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 transmission of the first WTRU 202 is the same as the L2 destination ID of the second WTRU 204 and the L2 destination ID of the transmission of the first WTRU 202 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, when the COT is initiated by the second WTRU 204 that the first WTRU 202 has a unicast link with, 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 corresponding to the unicast link 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 the COT, but the transmission from the second WTRU 204 in question may be a transmission performed within the COT and not necessarily the transmission that initiated the COT. Specifically, as described above, the WTRU may share the COT for a transmission associated with the unicast link if another WTRU associated with the same unicast link executes a transmission within the same COT to be shared.

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

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

[0214] The WTRU that initiates a specific type of COT may indicate the COT type within 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, an SL RRC message, etc. Alternatively, the COT type may be implicitly determined based on other information included in the sidelink transmission by the WTRU that initiates the transmission or other WTRUs that transmit within the COT.

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

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

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

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

[0219] For example, a TX WTRU that initiates a COT may send an indication (e.g., a value of 0) that it is the WTRU that initiated the COT (e.g., in the SCI). A TX WTRU that shares a COT may send an indication associated with an indirect level associated with the WTRU that initiated the COT (e.g., in the SCI). Specifically, when a first WTRU shares a COT initiated by a second WTRU, the first WTRU may send an indication representing a first level of indirectness (e.g., a value of 1). A WTRU that shares a COT initiated by another WTRU may always increment by 1 the indirect level to be sent in the SCI from, for example, the minimum value received in any SCI associated with that COT. The same applies hereinafter. A WTRU that desires to share a COT initiated by another WTRU may use such an indication (optionally in addition to factors herein such as the time since the last transmission and / or the cast type or mode) to determine whether to 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 another WTRU has initiated the COT. A WTRU may share a COT initiated by another WTRU if it determines that the indirect level received from a transmission (optionally the last transmission or any transmission) within the COT is less than 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 a COT with a peer WTRU based on a combination of the indirect level and the time gap between transmissions. Specifically, during a particular time gap from the last transmission in the COT, the WTRU may use a first LBT type for a first indirect level and a second LBT type for a second indirect level, etc.

[0222] FIG. 3 is a diagram illustrating an example of group cast / broadcast COT sharing. As shown in FIG. 3, the WTRU 302 may start a COT using a first set of LBT parameters (i.e., LBT(0)). Since the WTRU 302 has started the COT, it may transmit an indirect value of 0 in the SCI transmission 320 within the COT.

[0223] The WTRU 304 may receive COT information from the WTRU 302 and decide to share the COT with the WTRU 306. Since the WTRU 304 represents an indirect level of 1, it may perform an LBT procedure using a second set of LBT parameters (i.e., LBT(1)). The WTRU 304 may also transmit an indirect 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 COT information from the WTRU 04 and decide to share the COT with the WTRU 308. Since the WTRU 306 represents an indirect level of 2, it may perform an LBT procedure using a third set of LBT parameters (i.e., LBT(2)). The WTRU 306 may also transmit an indirect 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 indirect numbers. The WTRU 308 receives an indirect value of 2 from the WTRU 306 via the SCI transmission 224 and an indirect value of 0 from the WTRU 302 via the SCI transmission 326. The WTRU may decide to follow the minimum indirect number of 0 from the WTRU 302 and act as a WTRU within the first indirect level. Further, the WTRU 308 may transmit an indirect value of 1 to an additional WTRU in any SCI transmission 328.

[0226] Potential problems that may arise with distributed COT sharing are caused by the hidden node problem. Specifically, a first WTRU may initiate a COT and transmit COT information. A second WTRU that does not receive the COT information from the first WTRU (due to the hidden node problem) may also initiate its own COT. The second WTRU may initiate a COT well into the first WTRU's COT. This may result in a sidelink WTRU occupying the channel for longer than fairness requirements.

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

[0228] The WTRU may adopt COT information received from another WTRU in case of a conflict. The WTRU may further modify the COT information to be transmitted to follow the new information in case of a conflict. The WTRU may cancel a planned transmission when it receives competing COT structure information, if in some cases the received COT structure does not permit transmission. The WTRU may notify the network upon receipt of a competing COT structure.

[0229] In another embodiment, an SL WTRU configured in mode 1 using SL transmission 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 SCI transmissions of other WTRUs. If the SL grant falls within a COT initiated by another WTRU, the WTRU may attempt to share the COT by performing a first type of LBT. If the SL grant is not included within a COT initiated by another WTRU, the WTRU may attempt to start its own COT by performing a second type of LBT. If the LBT fails for the grant, the WTRU may report the failed LBT to the base station in UCI.

[0230] If the LBT is successful, the WTRU may determine the COT length and report the remaining COT length in UCI to the base station (e.g., gNB) (depending on which method was used), and report to the base station (e.g., gNB) whether the first WTRU has started its own COT or is sharing another WTRU's COT. For a COT started by the WTRU, the WTRU may determine the COT length based on data multiplexed in the SL grant. For a 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 starting or sharing a COT and the time remaining in the COT (determined differently depending on whether the COT is shared or started). The SL WTRU may determine whether it can share a COT initiated by another WTRU based on a combination of the transmission priority and the indirect number received from another WTRU.

[0232] In one embodiment, the SL WTRU determines whether it can share the COT started by another WTRU and the LBT parameters used to transmit in that COT, including the COT information with the indirect number associated with that COT, received from one or more other WTRUs, and determines that the COT can be shared if the minimum indirect 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 LBT using the parameters determined by the indirect number and the priority. When the WTRU acquires a channel, it may transmit an indirect number that is 1 greater than the received indirect number. Otherwise, the WTRU may determine that it cannot share the COT started by another WTRU and may start its own COT.

[0233] In another embodiment, a WTRU operating in mode 2 may perform resource selection based on the presence and / or structure of existing or expected COTs on the SL. The COT may include COTs started by other WTRUs (and indicated in the SCI by those WTRUs), or COTs started by the WTRU performing the resource selection. As used herein, an existing COT is a COT started by a WTRU or another WTRU through the transmission of an SCI, optionally following a full LBT procedure. An expected COT may include resources or a set of resources that may be expected to be part of a COT as a result of future transmissions by a WTRU announced in the SCI. The method for resource selection herein that depends on the presence of a COT may be applied to either the existing COT or the expected COT, optionally with the same / different rules.

[0234] A WTRU that performs mode 2 resource selection may consider the presence and / or structure of an existing or anticipated COT by selecting resources within the COT or resources associated with the COT, including restricting or prioritizing the 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: (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 fits within the remaining time in the COT; (5) selecting resources within the COT if the start time of the transmission resource fit is below a predetermined threshold from the end of the COT; (6) providing (to the MAC layer) the resources available for resource selection such that a greater percentage of the number of available resources exists inside the COT than outside the COT; and (7) providing (to the MAC layer) the resources available for resource selection such that the amount or ratio of available resources inside the COT is greater (compared to when prioritization of resource selection inside the COT is not performed). The selection of resources may include ensuring that the start of the selected resources is within the COT. The selection of resources may also include ensuring that the start of the resources occurs at the maximum time following the start of the COT, and thus may include ensuring that at least the initial transmission resources are within the COT.

[0235] The WTRU performing mode 2 resource selection may consider the presence and / or structure of existing or anticipated COTs by selecting resources associated with a particular type of COT. The type of COT may be a COT associated with one or more of the factors described herein (e.g., the indirect number meets a criterion, the cast type is associated with a particular criterion, the L2 ID meets a criterion, etc.). The type of COT may be a COT that is selected (when initiated by the WTRU) or directed (when initiated by another WTRU). The CAPC is a particular value or below / above a threshold. The resources may be associated with FBE resources 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 required LBT type - type 1, 2, or 4 - or associated LBT configuration parameters such as contention period or backoff).

[0236] The WTRU performing mode 2 resource selection may consider the presence and / or structure of existing or anticipated COTs by selecting resources by determining parameters associated with resource selection according to the presence and / or structure of the COT. The determination may include using a first set of parameters when the selection is performed within a COT or COT type and using a second set of parameters when the selection is performed outside of the COT or within 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 transmission duration on the SL data resource and whether it fits within the remaining time within the COT. The determination may include adapting the parameters of the resource selection depending on the timing of the resource with respect 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: i.e., the number of retransmission resources, the number of consecutive resources the WTRU should select, the minimum / maximum time between transmissions / retransmissions, resource patterns such as the number of time / frequency consecutive resources selected, the maximum / minimum number of RBs, the duration of a given transmission / retransmission resource, the total number of resources that may be selected, which may be associated with COT / COT type in some cases, periodic resource selection, or one-shot resource selection is performed / permitted.

[0238] The WTRU may select resources by considering COT based on one or more conditions. For example, the WTRU may determine whether to select resources by considering COT if a condition is met (or not do so otherwise). The WTRU may determine a specific behavior when considering COT if a condition is met, and may use another behavior when considering COT if the condition is not met. For example, the WTRU may use a first set of parameters when selecting resources considering 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 be related 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 having a specific priority. The condition may be whether the available data consists only of MAC CE, or whether the available data includes MAC CE and data or data only. For example, the condition may be whether the available data consists only of SRB bits, or whether the available data includes SRB data. The condition may, in some cases, be the presence of control information available for transmission having a specific priority. The control information may be SCI multiplexed on a data resource or SCI transmitted on a control resource.

[0240] The condition may be related to configured conditions associated with the data. For example, one or more LCHs may be configured to have a specific behavior described herein with respect to resource selection associated with a COT. The LCH may trigger resource selection from LBE / FBE resources. For example, if data is available for a specific 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 activation or HARQ deactivation. 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 SL measurement values 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 exceeds / falls below a threshold

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

[0243] The condition may be related to the existence of a COT initiated by a WTRU that performs 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 be related to the existence, ratio, or amount of available resources within the COT. For example, the condition may be that the percentage of available resources within the COT exceeds a threshold.

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

[0246] The condition may be related to whether the TB is a retransmission. For example, the WTRU may select a certain resource when the TB is a retransmission (in some cases, after several retransmissions or LBT failures). The retransmission may be due to a previous LBT failure, receiving / deciding on a NACK, or not receiving HARQ feedback for a previously transmitted TB. In one example, the WTRU may retransmit the TB using a different resource or resource pool when it receives a NACK, when the LBT fails, and / or when it has not received HARQ feedback. The WTRU may monitor HARQ feedback on a different resource or resource pool when HARQ feedback is not received within the expected time following TB transmission.

[0247] The condition may be related to whether a consistent LBT failure is detected on a resource associated with a first type of COT.

[0248] The condition may be related 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 (previously) configured past period of time.

[0249] In one embodiment, the WTRU may associate a resource (e.g., a time slot, a set of time slots, a subchannel, a set of subchannels, etc.) with one or more properties associated with the COT.

[0250] In one embodiment, the resource may be considered to be inside the COT, outside the COT, or partially overlapping with the COT (i.e., part of the resource is inside the COT and part of the resource is outside the COT). For example, if the resource ends within the remaining time of the COT, the resource may be inside the COT. In another embodiment, the resource may be considered to be within a given indirect number or range of COTs as described herein. Or

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

[0252] The WTRU may be configured (in advance) with the number of times the COT can be (re)shared with other WTRUs, or it may be pre-determined. Configuration from the upper layer may configure that the COT can be shared x times or less. 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 within the COT. When the WTRU obtains the COT for the xth time, the WTRU may omit the SCI or MAC CE associated with sharing the COT with other WTRUs. Alternatively, the WTRU may include an indication (e.g., in the SCI or MAC CE) that this COT can no longer be shared. The WTRU may stop using the COT at the end of the xth transmission it obtains, or it may occupy the COT until an MCOT occurs.

[0253] In one embodiment, the WTRU may be composed of a subset of sidelink data resources that can be used at a specific 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 the radio frame boundary that corresponds to the applicable offset. The WTRU may be configured using a subset of the possible offsets within the radio frame or within the 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 as a time from a configured value or until the next available resource. Alternatively, the WTRU may dynamically determine the offset. The dynamic determination may depend on, i.e., (1) the priority of the data associated with the TB, (2) whether the data is multiplexed from one or more LCHs configured with a high priority index, (3) whether the data is multiplexed from a subset of the configured LCHs or DRBs, (4) the subscription type of the WTRU, 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 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 a 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 the upper layer or may be dynamically changed based on a previous LBT attempt or the selected timing offset used to acquire the channel.

[0256] The WTRU may maintain a retransmission timer per resource pool, per SL carrier, per LBT bandwidth / sub-band, or per MAC entity and may be configured using the retransmission timer. In one example, the WTRU may start the timer after an LBT failure on a given resource pool. While the timer associated with a resource pool is running, the WTRU may not select a resource to retransmit or transmit a TB on that resource pool. The WTRU may, in some cases, retransmit the TB on a different resource pool than the last selected resource pool if the timer associated with the pool is not running and / or if the 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 the time position of the COT. The WTRU may determine a set of available resources, and a subset of the resources may include resources within the COT and other resources may not be within the COT. The WTRU may, in some cases and under some conditions of this specification, select or prioritize resources within the COT. For example, if the data available for transmission exceeds a threshold priority, the WTRU may select only from resources within the COT. Otherwise, the WTRU may be permitted to select resources from within the COT or may not select resources from within the COT. For example, if the measured CBR exceeds a threshold, the WTRU may select only from resources within the COT or may prioritize the selection of resources within the COT.

[0258] The WTRU may determine that multiple resources are available for selection to perform a transmission or retransmission.

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

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

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

[0262] The WTRU may also prioritize the selection of resources based on the RSSI. The WTRU may select a configured or a resource that meets a predetermined RSSI or CBR threshold. The WTRU may prioritize the selection of resources in 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 that require LBT type 1, type 2, and then type 4 in that order. The WTRU may preferentially select a resource with the minimum CAPC, i.e., a resource that requires a shorter contention 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 within 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 a channel and may not select / prioritize resources that require one or more different LBT types to acquire a channel. The WTRU may select or prioritize resources that occur within a threshold number of slots from a transmission of the current WTRU or another WTRU (such as detected in the SCI) or a scheduled transmission (such as determined based on the forward looking information in the SCI). The WTRU may select or prioritize resources that are spaced within a number of slots from a transmission of the current WTRU or another WTRU based on any of the conditions recited herein, such as when the measured CBR exceeds a threshold, when the data available for transmission exceeds a threshold priority, etc.

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

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

[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 the data available for transmission is associated with a groupcast, and possibly the same L2 ID. For example, the WTRU may select resources associated with a COT initiated by any WTRU in a unicast link when resource selection is initiated when the data available for transmission is associated with transmission to that unicast link.

[0268] In another example, the WTRU may select or prioritize resources where the indirect number 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, if not, resources that are LBE (or vice versa). Such conditions may be based on the measured CBR. Such conditions may be based on the priority of the data. Such conditions may also be based on the characteristics of the LCH having the highest priority with the available data.

[0269] In one embodiment, the WTRU may determine parameters for resource selection based on COT information, and the parameters may include any of the parameters described herein. The COT information may be associated with the resource, such as whether the resource is within a COT, the type of COT with which the resource is associated, 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] When the resource is selected within the COT, the WTRU may select the first maximum number of RBs, and when the resource is selected outside the COT, the WTRU may select the second maximum number of RBs. The WTRU may select resources for periodic transmission only when such resources are associated with an FBE. Otherwise, when resource selection is triggered for one-shot transmission, the WTRU may select resources only from resources associated with an LBE, or may select resources from resources associated with an FBE or an LBE.

[0271] When the resource is associated with an LBE, the WTRU may select the resource using the required ones having several consecutive slots available for transmission, and when the resource is associated with an FBE, such requirements may be used. The WTRU may determine an acceptable periodicity of resource selection for multi-shot resource selection based on the configured and / or determined available FBE resources.

[0272] The WTRU may determine an acceptable number of retransmission counts for a TB (e.g., indicated in a single SCI in some cases) based on the COT duration.

[0273] The WTRU may determine a maximum time between transmitted / rescheduled / selected resources based on information associated with the COT or COT structure (e.g., CAPC, indirect number, etc.). For example, the WTRU may be configured with an acceptable time between retransmissions performed within the COT, such acceptable time being associated with the CAPC for the COT (either indicated as part of a COT started by another WTRU or determined by the WTRU itself when starting 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 to initiate a COT in the WTRU, it may determine the maximum time between transmissions / resmissions / selected resources based on the priority / CAPC of the data available for transmission at the time of resource selection. Specifically, the WTRU may be composed of a first allowable time for a first priority / CAPC, a second allowable time for a second priority / CAPC, and so on.

[0275] The WTRU may select contiguous time resources when the WTRU is initiating its own COT. On the other hand, the WTRU may not be required to select contiguous time resources when it is transmitting within a COT that has already been initiated (either by itself or by another WTRU). The number of contiguous resources (e.g., permitted, 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 contiguous time resources when the WTRU is sharing a COT or when it is transmitting within a COT that the WTRU has already initiated, based on the time difference between the selected resources and any execution / notification / 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 resources and the last transmission by the WTRU (optionally associated with the same COT or a COT that is not the COT in which the resources are selected).

[0277] One advantage of the above-described embodiments is that it enables the WTRU to perform transmissions on the unlicensed spectrum using resources selected based on the LBT rules required for transmissions on the unlicensed spectrum. For example, since the WTRU may need to perform CAT4 LBT before transmission, contiguous resources may be required for the start of the COT. Specifically, if the LBT fails on the first slot, the WTRU may still transmit in subsequent slots since it is selecting subsequent slots during resource selection. To share the COT, the WTRU may perform a short LBT and the number of resources that need to be selected (contiguous in some cases) may be smaller.

[0278] The WTRU may trigger resource reselection based on conditions associated with the COT structure, COT start, and LBT in the WTRU, in combination with other conditions referred to 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 the LBT, either a continuous number of times in some cases, or for the number of (contiguous in some cases) resources selected. 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 the short LBT within an existing COT).

[0280] Another condition may be that the WTRU receives an SCI indicating the start of a COT by another WTRU, and in some cases, if such a COT overlaps with resources already selected by the WTRU, in some cases, if such a COT occurs before resources already selected by the WTRU, in some cases, if the WTRU has selected resources that require it to perform its own COT start. The WTRU may select resources adjusted in accordance with the start of the COT. Upon receiving an SCI indicating that a COT has been started by another WTRU, the WTRU may trigger re-selection of these resources to select new resources for transmission in the already started COT. The WTRU may have several resources selected for future transmission. The WTRU may then receive an SCI indicating the start of a COT by another WTRU that overlaps with the resources. If a COT is used by a group of WTRUs not involved with the WTRU, the WTRU may perform preemption / resource re-selection 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 a CAPC of higher / lower priority than any existing / started COT. Another condition may be that the data available for transmission is at least a particular priority. For example, resource re-selection may be triggered as a result above only if the data priority exceeds a threshold. Another condition may be that the measured CBR is below a threshold. For example, resource re-selection may be triggered as a result above only if the CBR is below a threshold.

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

[0283] In one example, the first TX WTRU may start LBT on the future announced resources directly indicated by the previous SCI. The first TX WTRU may maintain the planned periodicity for the future announced resources (compared to the first transmission) regardless of the number of failed LBTs prior to 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 for performing the first transmission. Specifically, the first TX WTRU may reduce the planned gap for the second transmission by a number of slots that is, in some cases, equal to the number of slots in which LBT failed for the first transmission. As the 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 (in some cases contiguous) slots that are considered unavailable when performing resource selection.

[0284] In another example, the first TX WTRU may start LBT on a future (second) resource that is always the value of period T (i.e., the selected periodicity) from the slot in which it first started 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 at which LBT may be started for transmission in the future resource. The second TX WTRU may assume that the indicated resources, as well as some resources before the indicated resources (if the number of such resources is indicated in the SCI), are occupied. Additionally, the second TX WTRU may assume the number of time resources or slots to be occupied after the indicated resource, and such number is determined by subtracting the number of slots (i.e., the slots before the indicated resource) indicated in the received SCI from the total number of possible LBT attempts in consecutive slots.

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

[0286] In another example, the WTRU may trigger preemption / re - evaluation if the WTRU receives an SCI indicating that the COT has been started by another WTRU and the COT overlaps with the resources selected by the WTRU. The WTRU may further trigger preemption / re - evaluation if the CAPC associated with the COT is different (e.g., higher priority, lower priority) from the CAPC assumed by the WTRU for selecting the (overlapping) resources.

[0287] In another example, the WTRU may trigger preemption / re-evaluation when it receives an SCI indicating that the COT was initiated by another WTRU, and the COT may occur earlier than the selected resource. Such preemption / re-evaluation may further be triggered when the resources selected / reserved by the WTRU require the start of the COT (in some cases, while a COT initiated by another WTRU can be shared by the WTRU). In such a case, the WTRU may reselect only the resources within the COT indicated in the received SCI.

[0288] The advantage of such an embodiment may be to perform reselection in the WTRU when the WTRU determines that the COT was initiated (by another WTRU in some cases) and the WTRU can use that COT for transmission (instead of performing its own COT start).

[0289] The WTRU may receive (e.g., in mode 1), select (e.g., in mode 2), or be configured using multi-occasion sidelink data transmission resources. The multi-occasion resources consist of two or more, and in some cases consecutive, data transmission occasions where LBT occasion is possible, whereby the WTRU may attempt LBT in each occasion until LBT is successful. When LBT is successful, the WTRU may transmit to the remaining occasions in the resource without performing LBT again. For each data transmission occasion, the WTRU may attempt to transmit the same TB that failed in LBT or a different TB.

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

[0291] The WTRU may receive multi-occasion resources from a base station (e.g., gNB) by 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 to each WTRU the applicable start occasion. The WTRU may transmit without LBT or using a short LBT prior to the indicated start occasion.

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

[0293] In one embodiment, the multi-opportunity resource may include a plurality of resource pools, whereby each opportunity may be associated with one or more resource pools. The WTRU may be configured in a resource hopping pattern such that if LBT fails for an opportunity, the WTRU attempts LBT for the next opportunity, which may be associated with different resource pools.

[0294] The WTRU that selects multi-LBT opportunities in mode 2 may select a plurality of resources for its own transmission. The multi-LBT opportunity resources may include the same frequency resources in consecutive or non-consecutive slots. Alternatively, the multi-LBT opportunity resources may include different frequency resources in the same or different slots.

[0295] The WTRU may select a plurality of resources for its first transmission and then select only a single set of resources for its retransmission. Alternatively, the WTRU may select a plurality of resources for the initial transmission and, for each resource of that initial transmission, select a plurality of resources for each retransmission. Whether the WTRU selects a single retransmission resource (set) or a plurality of such resources for each initial transmission resource may depend on the same conditions described below with respect to whether the WTRU uses multi-LBT opportunity 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 resources, the type of LBT required for the retransmission resources, or whether the selected resources occur within the COT.

[0296] In another embodiment, the WTRU may perform an initial transmission or a retransmission in any of the multi-LBT occasion resources. Specifically, when LBT on the multi-LBT occasion SL resource is successful, the WTRU may perform an initial transmission and then may perform a retransmission in the remaining resources of the multi-LBT transmission resource. The WTRU may further assume that LBT is not 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 a selection of the multi-LBT occasion SL resource based on certain conditions. Specifically, the mode 2 WTRU may determine to perform a selection of the number of multi-LBT occasions and / or retransmission resources 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 a selection of the number of multi-LBT occasions and / or retransmission resources for each initial transmission resource based on the selection being performed on a resource pool associated with unauthorized operations. For example, the WTRU may select a multi-LBT occasion SL resource if the selection is performed on a pool of resources associated with SL unauthorized, and may not perform such a selection when the resource pool is on an unshared spectrum (non-unauthorized spectrum).

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

[0300] The mode 2 WTRU may determine to perform a selection of the number of multi-LBT occasions and / or retransmission resources for each initial transmission resource based on the type of LBT required to perform the transmission. For example, if the transmission requires a specific LBT type (e.g., type 1 LBT, type 2 LBT), the WTRU may perform a selection of multi-LBT occasion SL resources, and otherwise, the WTRU may perform a legacy resource selection.

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

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

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

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

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

[0306] The WTRU may determine the number and / or pattern of resources in a multi-LBT occasion based on priority / QoS. For example, the WTRU may select some resources that depend 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 COT information. For example, the WTRU may determine the allowable time between resources of the multi-LBT resources based on whether the resource is within a COT (e.g., initiated by another WTRU) and / or COT information (e.g., CAPC).

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

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

[0310] If the WTRU succeeds at LBT on one of the resources of the multi-LBT occasion resources, it may perform any one or combination of the following.

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

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

[0313] The WTRU may select resources based on priority. For example, the WTRU may be (pre-)configured using 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 resources, and a WTRU with a lower priority transmission may start transmission later following a successful LBT.

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

[0315] The WTRU may select resources based on random rules or probabilistic rules. For example, the WTRU may randomly select one of the remaining resources of the multi-LBT occasion, which may further meet any of the other criteria for starting transmission. The WTRU may be configured with a probability (which may depend on or be determined by other factors in this specification) of starting transmission on any of the remaining resources of the multi-LBT occasion.

[0316] The WTRU may select resources based on the HARQ feedback timeline. For example, the WTRU may select a resource among the remaining resources following a successful LBT to start a transmission that adheres to the HARQ timeline selected by the WTRU during the selection of resources for transmission and retransmission.

[0317] The WTRU may select a resource based on the sensing result. For example, the WTRU may determine whether to transmit on 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 initiate continuous partial sensing operations at the start of LBT or upon successful LBT. The WTRU may initiate transmission only on the first resource of the multi-LBT resource where continuous partial sensing indicates that the resource is available.

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

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

[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 a transmission with a priority exceeding a threshold or some priority for the first transmission (e.g., at least the same priority as the first transmission, below a certain priority lower than the first transmission), the WTRU may be permitted 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 permitted 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 whether to perform multiple transmissions and the number of subsequent retransmissions based on whether multiple transmissions should be performed and the number of scheduled / permitted retransmissions. For example, if the WTRU is planning retransmissions that may be associated with the TB first transmitted on the multi-LBT resource following a successful LBT, the WTRU may use subsequent resources.

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

[0324] The WTRU may continue to perform the LBT or perform a shorter LBT. For example, following a successful LBT in a multi-LBT occasion, if the WTRU determines to perform a transmission in some slots after the successful LBT (as determined based on the conditions herein), the WTRU may continue to perform 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 resource selected for the transmission within the multi-LBT occasion. Specifically, if the WTRU determines to transmit immediately after the first successful LBT or within a maximum of N slots after the first successful LBT, the WTRU may transmit without performing a short LBT.

[0325] The WTRU may be configured to execute a recovery procedure upon failure associated with obtaining a selected resource in a multi-LBT occasion. The WTRU may be generally configured to execute a recovery procedure upon any failure related to LBT (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 a UL transmission and, optionally, notify the base station (e.g., gNB) of the failure. The recovery procedure may also be to declare an SL RLF. The recovery procedure may also be to start transmission on an FBE resource. The recovery procedure may also be to start an RRC connection.

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

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

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

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

[0331] Specifically, the LCP limitation may be performed by the WTRU during the selection of the L2 destination ID and / or the selection of the logical channel for transmission on the sidelink. The LCP limitation may relate to any of the following properties associated with the grant, namely,

[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 restriction may relate to whether the permission is within a COT, whether the COT was initiated by the WTRU itself, or whether it was initiated by another WTRU.

[0334] The LCP restriction may relate to whether the permission is within a COT, whether the COT was initiated by unicast / groupcast / broadcast transmission.

[0335] The LCP restriction may relate to whether the permission is within a COT, and the source / destination L2 ID of the WTRU that initiated the COT for the transmission.

[0336] The LCP restriction may relate to whether the permission is a mode 1 permission or a mode 2 permission.

[0337] The LCP restriction may relate to whether the permission is within a COT, the COT length, the remaining COT length, or any temporal relationship between the COT and the permission itself.

[0338] The LCP restriction may relate to whether the permission is within a COT, the number of SL transmissions already executed within the COT, the channel occupancy rate (CR, CBR, or the number of reserved / used sub-channels) 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 exists. For example, a WTRU may be permitted to multiplex data of a certain LCH as long as the CAPC of its data has a higher priority than the CAPC associated with the COT that the WTRU is attempting 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 with the grant to LCHs having a priority associated with the CAPC, e.g., a list of permitted priorities associated with the CAPC, a priority above a threshold determined based on the CAPC, and / or a priority having some relationship (e.g., above a certain number of levels lower, not less than it) to the priority of the CAPC.

[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, the WTRU may or may not be permitted to multiplex data of a certain priority or priority range with a grant used to initiate a COT, a grant for the WTRU to share a COT, and a grant for the WTRU to transmit on a COT that the WTRU has already initiated. Further, each combination of the three cases is possible. For example, the WTRU may be permitted to multiplex data with a priority higher / lower than a threshold in a grant for the WTRU to initiate and / or has initiated its own COT.

[0342] For example, a WTRU may be configured using a first priority restriction rule for a grant within a COT initiated by another WTRU and a second priority restriction rule for a COT initiated by that WTRU itself. For example, when a grant falls within a COT initiated by another WTRU, the transmitting WTRU may select only LCHs having a priority at least as high as the priority / CAPC indicated in the COT information. When a grant is to fall within a COT to be initiated by the WTRU itself, the WTRU may select any LCH priority for multiplexing with the COT.

[0343] In another example, the WTRU may be configured using a first priority restriction rule for a grant within a COT that results in the start of the COT for a grant that is already within a COT initiated by the WTRU itself. For example, if the grant enters a COT previously initiated by the WTRU itself, the WTRU may or may not restrict the LCH, or may use a priority restriction different from the restriction associated with the grant used to start the COT.

[0344] The LCP restriction may be associated with a property associated with the COT and / or with data transmitted in the grant that started the COT, such property may be a cast type, destination ID, priority, WTRU group, delay, PDB, or any other SL property described herein. For example, the 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 started the COT. Specifically, if the COT is used for a particular cast type, the COT needs to continue to be used for that cast type. Further, the restriction may depend on the cast type itself. For example, a WTRU sharing a COT started by a unicast transmission may select only an L2 destination ID that is the same as the L2 source ID of the WTRU that started the COT. For example, a WTRU sharing a COT started by a broadcast transmission may select an L2 ID associated with either a groupcast or any unicast transmission (optionally, of the same L2 ID that started the COT). For example, a WTRU sharing a COT started by a broadcast transmission may select any L2 ID for the transmission sharing the COT.

[0345] For example, the WTRU may be permitted to multiplex data of a specific L2 ID in a grant occurring within a COT, and such case types are 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, when a COT is used for a specific L2 ID, the COT needs to continue to be used for that L2 ID. Specifically, a WTRU with a pending grant occurring within a COT initiated by 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] The LCP restriction may be associated with an indirect number associated with the COT, as described herein. For example, the WTRU may be configured with a set of LCHs that can / cannot be multiplexed in a grant occurring within a COT of a certain indirect number or set of indirect numbers. For example, the WTRU may be configured with one or more cast types that can / cannot be multiplexed in a grant occurring within a COT of a certain indirect number or set of indirect numbers.

[0347] The LCP restriction may be associated with the transmission mode (i.e., mode 1 versus mode 2). For example, the COT may be associated with a mode (i.e., mode 1 or mode 2) that may represent the resource selection mode used by the WTRU when initiating the COT. The WTRU may determine the transmission mode used to initiate the COT from the information within the transmission itself. The WTRU that initiates the COT may include the operation 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 a COT associated with mode 1 and / or mode 2.

[0348] The LCP restriction 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 ID, LCH priority, or other restrictions for the logical channels multiplexed in the grant based on whether the COT was initiated by a transmission with / without an MCR. For example, a WTRU that shares the COT initiated by a transmission with an MCR may select only the L2 ID that matches the L2 ID of the transmission that initiated the COT. Otherwise, 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 ID, LCH priority, or other restrictions for the logical channels multiplexed in the grant based on whether the WTRU using the grant is located inside / outside the MCR of the transmission that initiated the COT. For example, if the WTRU is located inside the MCR associated with the transmission that initiated the COT, the WTRU may select any L2 ID and / or LCH priority for the grant sharing the COT. Otherwise, if the WTRU is located outside the MCR associated with the transmission that initiated the COT, the WTRU may be restricted to the selection of the same L2 ID and / or the restriction of the LCH priority that can be multiplexed in the grant (e.g., only LCHs with a priority above the CAPC associated with the COT).

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

[0351] Furthermore, the WTRU may determine an acceptable L2 destination ID, LCH priority, or other restrictions for logical channels multiplexed in a grant based on any of the three combinations described above.

[0352] The LCP restriction may be based on the occupancy of the SL resources within the COT. For example, the WTRU may determine an acceptable destination L2 ID, LCH priority, or other restrictions based on the measured occupancy rate of the SL resources within the COT. For example, in some cases where it is determined that the occupancy rate of the channels within the COT is low (e.g., below a threshold), the WTRU may include LCHs with a lower priority (e.g., below a threshold, below the CAPC of the COT, etc.) when sharing the COT. Alternatively, in some cases where it is determined that the occupancy rate of the channels within the COT is high (e.g., above a threshold), the WTRU may be restricted to only LCHs with a 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, the WTRU may be configured with a set of LCHs that can / cannot be multiplexed in grants occurring 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 determine to apply LCP restrictions such that the PDU contains only data associated with equal priorities, equal data / control types, or the like. Such embodiments may be used to avoid the case where the WTRU selects a low-priority CAPC (due to the low-priority data being included in the PDU) when the PDU contains high-priority data. In one example, the WTRU may limit the difference between the minimum and maximum priorities to less than a threshold value. In one example, if the WTRU includes data or control with a priority greater than the threshold value, the WTRU may not include any data or control with a priority less than the threshold value. In one example, the WTRU may be (pre-)configured with a set of priority combinations that can be included together in the PDU. In one example, the WTRU may apply LCP restrictions when the PDU includes a MAC CE or a DRB. In such embodiments herein, the priority may refer to an LCH priority, an L1 priority, or directly to a CAPC.

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

[0356] Although the features and elements are described above in a particular combination, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Additionally, the methods described herein can be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software can be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method performed by a first wireless transmit / receive unit (WTRU), comprising: receiving sidelink control information (SCI) from a second WTRU initiating a shared channel occupation time (COT) with the first WTRU, the SCI comprising: (1) COT information, including associated Channel Access Priority Class (CAPC) values; and （２） (a) a source ID associated with the second WTRU; or (b) a destination ID associated with the second WTRU. At least one of and Using the shared COT; performing a type 2 LBT procedure for transmissions during the shared COT; Equipped with If the shared COT is associated with a unicast type, the source ID of the transmission from the first WTRU matches the receiving destination ID associated with the second WTRU, and the destination ID of the transmission from the first WTRU matches the receiving source ID associated with the second WTRU; If the shared COT is associated with a multicast type, the destination ID of the transmission from the first WTRU matches the receiving destination ID associated with the second WTRU; The CAPC value associated with the COT information and the CAPC value associated with the data for transmission have integer values ​​between 1 and 4. A method comprising:

2. 2. The method of claim 1, wherein the first WTRU is a responding WTRU.

3. 2. The method of claim 1, wherein the second WTRU is an initiating WTRU.

4. 2. The method of claim 1, wherein the Type 2 LBT procedure is performed on a channel associated with the COT based on a determination that the COT can be shared.

5. 2. The method according to claim 1, characterized in that the data is transmitted on the condition that the Type 2 LBT procedure is successful.

6. 2. The method of claim 1, wherein a lower value of the CAPC value associated with the COT information and the CAPC value associated with data for transmission indicates a higher priority.

7. The method of claim 1 , wherein the SCI further comprises a duration of the COT.

8. A first wireless transmit / receive unit (WTRU), Transceivers, and Processor wherein the transceiver and processor receiving sidelink control information (SCI) from a second WTRU initiating a shared channel occupation time (COT) with the first WTRU, the SCI comprising: (1) COT information, including associated Channel Access Priority Class (CAPC) values; and （２） (a) a source ID associated with the second WTRU; or (b) a destination ID associated with the second WTRU. At least one of Including, Using the shared COT, Perform a Type 2 LBT procedure for transmissions during the shared COT. It is configured as follows: If the shared COT is associated with a unicast type, the processor is further configured to match the source ID of the transmission from the first WTRU with the receiving destination ID associated with the second WTRU, and match the destination ID of the transmission from the first WTRU with the receiving source ID associated with the second WTRU; If the shared COT is associated with a multicast type, the processor is further configured to match the destination ID of the transmission from the first WTRU with the receiving destination ID associated with the second WTRU; The CAPC value associated with the COT information and the CAPC value associated with the data for transmission have integer values ​​between 1 and 4. A first WTRU comprising:

9. 10. The first WTRU of claim 8, wherein the first WTRU is a responding WTRU.

10. 10. The first WTRU of claim 8, wherein the second WTRU is an initiating WTRU.

11. The first WTRU of claim 8 , wherein the Type 2 LBT procedure is performed on a channel associated with the COT based on a determination that the COT can be shared.

12. 10. The first WTRU of claim 8, wherein the transceiver is further configured to transmit data on the condition that the Type 2 LBT procedure is successful.

13. 9. The first WTRU of claim 8, wherein a lower CAPC value associated with the COT information and the CAPC value associated with data for transmission indicates a higher priority.

14. The first WTRU of claim 8 , wherein the SCI further includes a duration of the COT.

Images