Method and apparatus for scheduling sidelink in unlicensed spectrum

Abstract

Methods and apparatus for scheduling sidelink communications in an unlicensed spectrum are disclosed. A method performed by a first wireless transmit / receive unit (WTRU) may include receiving side link control information (SCI) from a second WTRU initiating a shared channel occupancy time (COT) with the first WTRU, the SCI including: (1) COT information, the COT including an associated channel access priority class (CAPC) value, where the CAPC value has an integer value between 1 and 4; and (2) at least one of (a) a source ID associated with the second WTRU or (b) a destination ID associated with the second WTRU; using a shared COT; a type 2 LBT process for transmission is performed during the shared COT.

Description

[0001] This application is a divisional application of the invention patent application with the application date of October 19, 2022, application number 202280080237.8, and invention name "New Radio (NR) Vehicle to Vehicle (V2X)-Method for Scheduling Sidelinks in Unlicensed Spectrum".

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Application No. 63 / 257,381 filed on October 19, 2021, U.S. Provisional Application No. 63 / 326,401 filed on April 1, 2022, and U.S. Provisional Application No. 63 / 353,939 filed on June 21, 2022, the contents of which are incorporated herein by reference. Background Art

[0004] Vehicular communication is a communication mode where vehicles can communicate directly with each other. One scenario of vehicle-to-everything (V2X) operation is the in-coverage scenario, where the WTRU may receive assistance from the network to start sending and receiving V2X messages. Another scenario of V2X operation is the out-of-coverage scenario, where the WTRU may start sending and receiving V2X messages using pre-configured parameters.

[0005] V2X communications are supported in LTE and are inspired by previous work on device-to-device (D2D) communications. V2X communication services may consist of different 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 RSUs / eNBs; vehicle-to-network (V2N), where vehicle WTRUs may communicate with the core network; and vehicle-to-pedestrian (V2P), where vehicle WTRUs may communicate with WTRUs with special conditions (e.g., low battery capacity). Summary of the invention

[0006] Methods and apparatus for scheduling sidelink communications in an unlicensed spectrum are disclosed. The method performed by a first wireless transmit / receive unit (WTRU) may include: obtaining authorization for transmission on a sidelink (SL); receiving a transmission including first channel occupancy time (COT) information from a second WTRU or an additional WTRU; determining playout information based on transmissions received from the second WTRU, the additional WTRU, or both the second WTRU and the additional WTRU, conditional on the authorization being 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 sending data including second COT information based on the determined playout information, conditional on the LBT procedure being successful.

[0007] The authorization may be obtained from a base station. The authorization may also be obtained by selecting an authorization via the first WTRU. The play information may indicate a unicast play type or a multicast play type. The received information may be the first COT information or the play information. The parameter set may be associated with information received from the second WTRU or the third WTRU, including a transmission priority. The parameter set may be associated with information received from the second WTRU or the third WTRU, including an indirect number. The indirect number may be received from the second WTRU or the additional WTRU via a sidelink control information (SCI) transmission.

[0008] According to one aspect of the present disclosure, a method performed by a first wireless transmit / receiver unit (WTRU) is provided, the method comprising: receiving sidelink control information (SCI) from a second WTRU initiating a shared channel occupancy time (COT) with the first WTRU, the SCI comprising: (1)

[0009] COT information, the COT including an associated channel access priority class (CAPC) value, wherein the CAPC value has an integer value between 1 and 4; and (2) at least one of the following: (a) a source ID associated with a second WTRU or (b) a destination ID associated with the second WTRU; using a shared COT; performing a type 2 LBT process for transmission during the shared COT; wherein if the shared COT is associated with a unicast type, the source ID of the transmission from the first WTRU matches the received destination ID associated with the second WTRU, and the destination ID of the transmission from the first WTRU matches the received source ID associated with the second WTRU; and wherein if the shared COT is associated with a multicast type, the destination ID of the transmission from the first WTRU matches the received destination ID associated with the second WTRU.

[0010] According to one aspect of the present disclosure, a first wireless transmit / receiver unit (WTRU) is provided, the transmit / receiver unit (WTRU) comprising: a transceiver; and a processor; wherein the transceiver and the processor are configured to: receive sidelink control information (SCI) from a second WTRU initiating a shared channel occupancy time (COT) with the first WTRU, the SCI comprising: (1) COT information, the COT comprising an associated channel access priority class (CAPC) value, wherein the CAPC value has an integer value between 1 and 4; and (2) at least one of the following: (a) a source ID associated with the second WTRU or (b) a source ID associated with the second WTRU associated destination ID; using a shared COT; performing a type 2 LBT process during the shared COT; wherein if the shared COT is associated with a unicast type, the processor is also configured to match the source ID of the transmission from the first WTRU with the received destination ID associated with the second WTRU, and match the destination ID of the transmission from the first WTRU with the received source ID associated with the second WTRU; and wherein if the shared COT is associated with a multicast type, the processor is also configured to match the destination ID of the transmission from the first WTRU with the received destination ID associated with the second WTRU. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0013] Figure 1B It is shown that according to one embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within the communication system shown;

[0014] Figure 1C It is shown that according to one embodiment, Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the illustrated communication system;

[0015] Figure 1D It is shown that according to one embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown;

[0016] Figure 2 is a diagram showing an example of unicast COT sharing; and

[0017] Figure 3 is a diagram showing an example of multicast / broadcast COT sharing. DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0052] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a 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 to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and leading to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be transmitted to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the destination STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0072] The following abbreviations and acronyms may be used for reference:

[0073] ACK

[0074] BSR Buffer Status Report

[0075] CAPC Channel Access Priority Class

[0076] CBR Channel Busy Rate

[0077] CG Cell Group

[0078] CG-UCI Cell Group-Uplink Control Information

[0079] COT Channel Occupancy Time

[0080] CSI Channel State Information

[0081] CW Contention Window

[0082] DCI Downlink Control Information

[0083] DCR Direct Communication Request

[0084] DL Downlink

[0085] DRB Data Radio Bearer

[0086] DRX Discontinuous Reception

[0087] DTX Discontinuous Transmission

[0088] FBE Semi-Static Channel Access

[0089] gNB gNodeB

[0090] HARQ Hybrid Automatic Repeat Request

[0091] LBE Dynamic Channel Access

[0092] LBT Listen before you speak

[0093] LCG Logical Channel Group

[0094] LCH Logical Channel

[0095] LCP Logic Control Prioritization

[0096] MAC CE MAC Control Element

[0097] MCR Minimum communication range

[0098] NACK Negative Acknowledgement

[0099] PCell Primary Cell

[0100] PDB Packet Delay Budget

[0101] PDU Protocol Data Unit

[0102] PHY Physical Layer

[0103] PSCCH Physical Sidelink Control Channel

[0104] PSFCH Physical Sidelink Feedback Channel

[0105] PSSCH Physical Sidelink Shared Channel

[0106] PUCCH Physical Uplink Shared Control Channel

[0107] QoS Quality of Service

[0108] RB Resource Block

[0109] RRC Radio Resource Control

[0110] RSRP Reference Signal Received Power

[0111] RSSI Received Signal Strength Indicator

[0112] SCell Secondary Cell

[0113] SCI Sidelink Control Information

[0114] SL Sidelink

[0115] SL UCI Sidelink Uplink Control Information

[0116] SR Scheduling Request

[0117] SRB Signalling Radio Bearer

[0118] SSB Synchronous Signal Block

[0119] TB Transfer Block

[0120] TX Transmitter

[0121] UCI Uplink Control Information

[0122] UE User Equipment

[0123] UL Uplink

[0124] V2X Vehicle to Everything

[0125] WTRU Wireless Transmit / Receive Unit

[0126] MAC Media Access Control

[0127] CWS contention window size

[0128] LTE defines two modes of operation in V2X communications, Mode 3 and Mode 4. In Mode 3, the network may provide the WTRU with scheduling assignments for V2X sidelink transmissions. In Mode 4, the WTRU may autonomously select resources from a configured / pre-configured resource pool. V2X Two types of resource pools are defined in LTE: (1) receive pools that may be monitored for receiving V2X transmissions, and (2) transmit pools that may be used by the WTRU to select transmit resources in Mode 4. A WTRU configured in Mode 3 may not use a transmit pool.

[0129] In LTE, these resource pools may be semi-statically signaled to the WTRU via Radio Resource Control (RRC) signaling. In Mode 4, the WTRU may use sensing before selecting a resource from the RRC configured transmit pool. LTE V2X does not support dynamic resource pool reconfiguration. Pool configuration may only be carried via SIB and / or dedicated RRC signaling.

[0130] 5G NR inherits two resource allocation modes from LTE. Mode 1 resource allocation corresponds to resource allocation scheduled by the base station (i.e., gNB). Mode 2 resource allocation corresponds to WTRU autonomous resource allocation. The concepts of resource pools and sensing for Mode 2 resource allocation are also inherited from LTE.

[0131] In 3GPP, access to unlicensed bands is specified under LAA (licensed assisted access). More specifically, downlink (DL) operation, uplink (UL) operation and autonomous UL and other enhancements are specified. LAA exploits the premise that unlicensed operation is always anchored to the PCell in the licensed band. Access to unlicensed bands in the SCell requires LBT operation of the WTRU / gNB.

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

[0133] To support NR-U, the following modifications are made to the PHY layer signals and channels: (1) DCI 2_0 is enhanced to provide time domain and frequency domain channel occupancy time (COT) structures; (2) a search space group switching feature is introduced, whereby the WTRU can be dynamically controlled to use one of the two search space sets to perform PDCCH monitoring; (3) an additional PDSCH mapping type B length is introduced to enable transmission at the start of COT once COT is initiated; (4) the search space can 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 included in one RB set; (6) SRS transmission can be located on any codeword in the timeslot; and (7) the gNB can schedule multiple consecutive PUSCHs with a single DCI format.

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

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

[0136] A COT can be initiated using CAT4 LBT. Depending on the size of the gap between transmissions at the switching point, a COT can be shared by nodes receiving transmissions from the COT initiating node using CAT1 LBT or CAT2 LBT.

[0137] LBT parameters may be determined by the Channel Access Priority Class (CAPC). The CAPC for radio bearers and MAC CEs is either fixed or configurable: (1) to the lowest priority for Padding BSR and Recommended Bit Rate MAC CE; (2) to the highest priority for SRB0, SRB1, SRB3 and other MAC CEs; and / or (3) to be configured by the gNB for SRB2 and DRB.

[0138] When selecting the CAPC for a DRB, the gNB may consider the 5QIs of all QoS flows multiplexed in that DRB, taking into account fairness between different service types and transports. Table 1 below shows which CAPC should be used for which standardized 5QIs (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 best matches the QoS characteristics of the non-standardized 5QI.

[0139]

[0140] Table 1 - Mapping between channel access priority categories and 5QI

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

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

[0143] One issue that arises is the Mode 1 scheduling issue. In Mode 1 SL, the gNB schedules SL resources to the WTRU. The scheduled DCI may be in a shared spectrum (possibly the same shared spectrum as the WTRU transmission). However, the WTRU's transmission may be intended for another WTRU rather than the gNB. Therefore, the gNB may not know whether the WTRU has acquired the channel after the DCI. In addition, there may be scenarios where the gNB may not perform the LBT procedure for accessing the channel in which the WTRU will transmit (e.g., a SL transmission by the WTRU in a different carrier than the carrier in which the DCI is transmitted). Specifically, the WTRU may not be able to share a COT initiated by the gNB. However, the WTRU may share a COT initiated by the WTRU.

[0144] The second issue is that the SL architecture may require new methods for determining LBT parameters. LBT parameters (such as channel width (CW) size, maximum COT length, and allowed CW size) mainly depend on the QoS of the data to be sent. While this may be suitable for the Uu infrastructure / architecture, it may not be suitable for the distributed architecture typical of V2X. Specifically, V2X can support unicast, multicast, and broadcast. In addition, some transmissions (e.g., broadcasts) are typical transmissions of unrelated WTRUs, while other transmissions (e.g., unicast) are typical transmissions of WTRUs traveling together. These factors may affect the LBT parameters required for such transmissions. These factors may also affect the COT usage rules, such as whether a WTRU can share a COT initiated by another WTRU.

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

[0146] As used herein, reference to a WTRU initiating a COT may refer to a WTRU that performs a SL transmission that creates a new COT. Alternatively, a WTRU initiating a COT may also refer to another WTRU that transmits within the COT and whose transmission is detected by the WTRU. Alternatively, a WTRU initiating a COT may also refer to another WTRU that sends or forwards COT information when deciding to share an existing COT.

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

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

[0149] The LBT behavior may include the WTRU determining whether it determines the CAPC with a first mechanism (e.g., using a first table or a first mapping), or whether it determines the CAPC with a second mechanism (e.g., using a second table or a second mapping). The first mapping or the second mapping may include mapping any attribute herein with a CAPC. For example, the first mapping may consist of a mapping between a PQI (QoS Profile Indicator) and a CAPC, and the second mapping may consist of a mapping between a logical priority and a CAPC.

[0150] The LBT behavior may include determining between a first rule for obtaining a CAPC from a transmission that includes multiple elements, each with its own CAPC (e.g., using the highest priority of the CAPCs included in the transmission) and a second rule for obtaining a CAPC from such a transmission (e.g., using the lowest priority of the CAPCs included in the transmission). For example, the WTRU may use the lowest priority of CAPCs for one type of transmission (e.g., Mode 1 transmissions) and may use the highest priority of CAPCs for another type of transmission (e.g., Mode 2 transmissions). The transmission type may also include any of the SL characteristics defined herein without necessarily being limited to mode, such as priority (priority of any data / control included in the PDU), CBR, etc.

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

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

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

[0154] 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 / subchannels on which to perform LBT to gain access to the channel, etc.

[0155] The LBT behavior may also include any new LBT parameters that are specific to the SL and determine the channel access behavior, such as any allowable / minimum / maximum delays between events for channel access, where such events may be related to measurements 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.

[0156] The LBT behavior may also include an energy threshold for determining channel occupancy. The LBT behavior may also include a number of time slots or equivalent for determining channel occupancy.

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

[0158] The LBT behavior may also include any time instances between LBT executions on the channel. The LBT behavior may also include the minimum / maximum time since the last transmission before the WTRU was able to reuse the COT and / or the type of LBT to be performed given the minimum / maximum time (e.g., no LBT, single LBT, full LBT, etc.).

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

[0160] LBT behavior may also include the 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.

[0161] The LBT behavior may also include a COT length determined by the WTRU initiating the COT and possibly communicated in the COT structure information. For example, the LBT behavior may include the WTRU selecting a COT length over another COT length (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.

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

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

[0164] Any of the LBT procedures related to the LBT behaviors described above may have multiple independent / concurrent instances of the LBT procedure. A WTRU performing LBT for a transmission with a particular factor may then use the parameters associated with the instance of the procedure.

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

[0166] The WTRU may determine whether to perform a transmission with HARQ feedback enabled or a transmission with HARQ feedback disabled based on the CW adjustment state, which may include any of the following: the value of the CW, the number of times the CW has increased since the value of the CW was last reset, whether the value is above a (pre-)configured threshold, etc. For example, when the value of the CW is above a threshold, the WTRU may perform a transmission with HARQ feedback enabled. For example, when the number of consecutive increases of the CW since the last reset is above a threshold, the WTRU may perform a transmission with HARQ feedback enabled.

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

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

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

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

[0171] The above conditions may also 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 process is required, or that a short LBT process is required if the time between scheduling the DCI and the SL resources is below a threshold (only in the case of the same carrier).

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

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

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

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

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

[0177] The WTRU's COT information (e.g., in a form similar to the CG-UCI) may be sent by the WTRU in the SCI. The WTRU may send such COT information in every SCI. Alternatively, the WTRU may send the information in a subset of SCI transmissions, such as periodically, every x transmissions, every x time periods, in an SCI transmission initiating COT, upon receipt of an SCI initiating COT, or in the case of including certain COT information.

[0178] The WTRU may send the COT information in other PHY channels (e.g., in addition to the PSCCH). Alternatively, the WTRU may send the COT information in a SL MAC CE, a SL RRC message, an inter-WTRU resource coordination message, or similar messages. The WTRU may send the COT information that determines when to initiate the COT.

[0179] Alternatively or in combination, the WTRU may send COT information it receives from a base station (e.g., a gNB) and / or other WTRUs (e.g., when it decides to share the COT). For example, the WTRU may send COT information received from a base station (e.g., a gNB) in its own SL transmission, or derive relevant COT information to be sent in the SL from information received from a base station (e.g., a 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., a 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 a SL MAC CE sent with its own transmission. Alternatively, the WTRU may decide to send COT information from another WTRU. In some cases, the WTRU may decide to send COT information from another WTRU even if it does not share the COT in question.

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

[0181] The COT information may also include information about when (i.e., time location) transmissions by one or more other WTRUs or the WTRU within the COT will be terminated (e.g., the WTRU may determine the existence of a COT initiated by the WTRU based on the reception of an SCI indicating that the COT was initiated by the transmission of the SCI). The SCI may also include the duration of the COT. The one or more SCIs received by the WTRU may also include information associated with the expected use of resources within the COT by one or more other WTRUs. For example, the WTRU may determine (e.g., based on an SCI transmission or information in the SCI) a time slot within the COT in which SL resources within the COT will become available, and may transmit the timing information to a base station (e.g., a gNB);

[0182] The COT information may be reported periodically. For example, the WTRU may have a periodic resource on which it sends whether there is an ongoing COT and any COT information associated with the COT.

[0183] The WTRU may be triggered to report COT information to a base station (e.g., a gNB). The trigger may include at least one of: (1) receiving a DCI; (2) the content of the DCI (e.g., a field in the DCI may trigger the reporting of COT information); (3) receiving an SCI; (4) the content of the SCI (e.g., a field in the SCI may trigger the reporting of COT information); (5) transmitting an SR to use COT; (6) based on the result of LBT. For example, if the WTRU shares or initiates COT by successfully performing LBT or failing to perform LBT, the WTRU may report COT information; and / or (7) based on a request to initiate a different COT. The WTRU may report one or more COT information based on receiving a transmission from one or more other WTRUs.

[0184] In one embodiment, the WTRU may report COT information on UL resources associated with the COT, which is initiated / used by the WTRU itself on the SL, which may be associated with the SL grant provided by the network. For example, such reports may be transmitted in the form of HARQ feedback, CG-UCI, MAC CE, or RRC messages in PUCCH, SR. Such information may include any information similar to that in the previously described embodiments (e.g., the WTRU reports information received from a peer WTRU). In addition, the WTRU may also report: (1) the time instance when the COT was initiated / should end; (2) LBT statistics collected by the WTRU (e.g., the number of occupied / available resources within the CW); (3) the HARQ process ID of the transmission that initiated the COT; (4) whether the WTRU was successful or unsuccessful in initiating the COT (if unsuccessful, the reason may be, for example, an error reason, or some statistics associated with failed LBT, such as RSSI, number of available resources in the CW, etc.); (5) whether the WTRU was successful or unsuccessful in transmitting in a shared COT; (6) whether the WTRU obtained the channel because it initiated its own COT, or shared the COT with another WTRU; (7) the amount of time remaining in the COT (the WTRU was able to share the COT), or whether such time is above / below a threshold (where the threshold may depend on the attributes of the data to be sent by the WTRU (e.g., priority)); (8) the number of times the WTRU was successful / unsuccessful in initiating the COT, possibly within a specific time, possibly associated with a specific CAPC or LBT behavior; (9) and / or the L2 ID associated with the transmission that initiated or shared the COT.

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

[0186] In an exemplary embodiment, the WTRU may be configured with one PUCCH resource (possibly associated with a SL grant) for indicating whether the LBT was successful, and another PUCCH resource (possibly associated with the same SL grant) for reporting HARQ ACK / NACK to a base station (e.g., a gNB). Specifically, if the WTRU is able to acquire the SL channel upon grant, the WTRU may transmit an ACK in a first PUCCH resource, and may then transmit an ACK / NACK on a second PUCCH resource based on the SL HARQ feedback from the RX WTRU. Alternatively, the information provided on the first PUCCH resource may indicate: (1) the WTRU's transmission on the grant is achieved by sharing an existing COT (e.g., indicated using a first code point) or by initiating a new COT (indicated using a second code point), or for a channel that was not acquired for the grant (indicated using a third code point), or (2) the WTRU acquires a COT with a remaining COT length greater than a threshold (using a first code point) or less than a threshold (using a second code point), 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 a third codepoint) that it did not acquire the channel for this grant.

[0187] In another method, the WTRU may send 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 performed due to a failed LBT.

[0188] In an exemplary embodiment, for a Mode 1 SL grant, the WTRU may determine whether it can acquire a channel for the grant and whether to use an existing COT or initiate a new COT. Such determinations are also described herein. Following such determinations, the WTRU may determine information (e.g., in the form of UCI) to be provided to a base station (e.g., gNB) following the grant. If the WTRUs share an existing COT, the WTRU may receive COT structure information from another WTRU (e.g., in an SCI sent within the COT) and transmit the COT structure (e.g., remaining COT length, CAPC, etc.) in the UCI to a base station (e.g., gNB).

[0189] If the WTRU initiates 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 the LBT parameters used to acquire the channel, and transmit the created UCI to the base station (e.g., gNB). If the WTRU cannot acquire the channel, the WTRU may indicate this in the UCI and may include additional information about the reason for the access failure, such as: (1) LBT failure when attempting to acquire a new COT, and potential LBT statistics associated with the failure; (2) LBT failure when attempting to acquire an existing COT initiated by another WTRU, and potential LBT statistics associated with the failure (e.g., the gap between transmissions and the type of LBT that the WTRU needs to perform); (3) the remaining COT length of the existing COT at the time of authorization was shorter than required and was therefore not acquired by the WTRU; and / or (4) the L2 ID associated with the transmission that initiated the COT.

[0190] In one example, the WTRU may be configured with SR resources to indicate a failure to acquire a SL channel. The WTRU may also be configured with different SR configurations depending on the priority of the data multiplexed in the PDU that is to be sent on the grant that failed LBT.

[0191] The WTRU may trigger / transmit a report of the COT information described in the embodiments described above. The WTRU may trigger / transmit a report of the COT information when the WTRU cannot acquire a channel that may be associated with one or more SL grants or configured SL grants. For example, if the WTRU cannot successfully perform an LBT process on the resources associated with the SL grant, the WTRU may transmit a HARQ NACK, SR, or similar UL transmission. For example, when the first / last resource associated with the granted LBT process (e.g., the first / last retransmission resource for the grant) fails, the WTRU may perform an UL transmission. For example, when the WTRU cannot acquire at least x resources associated with the SL grant through the network, the WTRU may perform an UL transmission, where x may be (pre-)configured and may depend on one or more other factors described herein.

[0192] When a WTRU receives information about a new possible COT that it is able to initiate (based on its own channel access) or detect (based on reception from another WTRU), the WTRU may trigger / transmit a report of COT information. In one example, the WTRU may send COT information (e.g., in a MAC CE) to the base station when it determines that a COT is initiated by another WTRU (e.g., based on SCI reception from another WTRU).

[0193] In another example, the WTRU may send COT information (e.g., in a MAC CE) to a base station (e.g., a gNB) when there is a change in COT information previously reported to the base station. For example, the change in COT information may be the appearance of a gap within the COT that is larger than a (pre-)configured threshold (e.g., due to a lack of SL transmissions). The change in COT information may be the receipt of a message (e.g., from a second WTRU) indicating an expected COT length that is shorter than a COT length initially indicated for the same COT (perhaps by a first WTRU).

[0194] When the WTRU is configured with conditions (e.g., via RRC configuration or via MAC CE) on whether to report COT information received from other WTRUs or determined by the WTRU, the WTRU may trigger / transmit reporting of COT information. For example, the conditions may include: (1) reporting COT information (e.g., for a newly detected COT) as long as the remaining COT length is less than / 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 (potentially planned) transmissions within the COT is above / below a threshold; and / or (4) reporting COT information if the information of the (potentially the same) COT has changed compared to a previous report, i.e., may have changed by a certain amount (e.g., the COT length has changed by a certain amount).

[0195] The thresholds for the above conditions may depend on data available for the WTRU's transmission, such as priority, remaining PDB, or measurements of the channel (such as CBR). For example, the WTRU may determine a threshold COT length based on the priority of data pending for transmission at the WTRU. If the WTRU detects a COT 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.

[0196] 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 a first COT and may initiate a second COT. For example, the WTRU may use only the COT associated with a base station (e.g., a gNB) for transmissions to a base station (e.g., a gNB). The WTRU may share a COT associated with a base station (e.g., a gNB) for transmissions to another WTRU. The WTRU may indicate a set of COT information in a transmission to a base station (e.g., a gNB). One of the COT information transmitted to a base station (e.g., a gNB) may be associated with a COT associated with the base station (e.g., a gNB).

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

[0198] In another embodiment, the WTRU may initiate the LBT procedure on the SL upon receipt of the grant in the DCI, or at a certain time period after receipt of the DCI. The time period may be (pre)configured, indicated in the DCI and / or depend on the measurement results of the SL and / or the QoS of the transmission.

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

[0200] If the WTRU successfully accesses the channel using LBT (e.g., using UCI or COT information as described herein), the WTRU may also notify the network. The WTRU may also cancel any subsequent grants after channel acquisition on a previous grant. Alternatively, the WTRU may be configured to determine whether to maintain or cancel subsequent grants based on: (1) the amount of data in the buffer (e.g., if the WTRU has data available for transmission, which may be associated with a particular priority, the WTRU may maintain one or more subsequent grants); (2) channel congestion (e.g., if the CBR is above a threshold, the WTRU may cancel the subsequent grant, otherwise, the WTRU may maintain the subsequent grant); (3) the number of subsequent grants remaining (e.g., the WTRU may be configured with a maximum number of subsequent grants that it can maintain and may discard the remaining ones); (4) the priority of the data in the buffer; (5) any combination of (1) to (4) above; and / or (6) any other conditions described herein (e.g., associated with multiple LBT opportunities as described herein).

[0201] The WTRU can determine whether LBT is required before resources of an upcoming grant in the same set of multiple SL grants based on whether LBT was successful before a previous grant in the set of multiple SL grants, the duration since the last success of LBT, and whether there is a gap before the upcoming grant.

[0202] A WTRU utilizing multiple SL grant scheduling may choose whether to share an existing COT or initiate a new COT based on the parameters of one or more SL grants in a set of multiple SL grants. For example, the WTRU may determine whether to share an existing COT based on the amount of grants in a set of multiple SL grants that may be sent 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 initiate a new COT based on m and n. The WTRU may determine whether to share the ongoing COT or initiate a new COT based on the priority of the transmission in one or more SL grants in a set of multiple SL grants.

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

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

[0205] In one embodiment, the WTRU may determine whether to create its own COT information for a transmission or forward / send COT information received from another WTRU or base station based on whether the WTRU is initiating a COT or sharing a COT initiated by another WTRU or base station. Specifically, if the WTRU's authorization or potential authorization does not fall into an existing COT, the WTRU may initiate its own COT and may create COT information (COT structure) based on the LBT it uses to create a COT within its own transmission.

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

[0207] A WTRU may determine its LBT behavior based on one or a combination of factors associated with its own transmissions and / or with its own receptions (e.g., when sharing a COT initiated by another WTRU). Here, the term "combination" may refer to the use of two or more factors in determining the LBT behavior. Combination may refer to excluding one behavior due to the presence of one factor, and selecting from the remaining behaviors based on other factors. Combination may refer to determining one LBT behavior based on a first factor, and determining another LBT behavior based on a second factor. Combination may refer to determining the number or type of LBT behaviors to be determined based on one factor, while selecting the behaviors based on other factors.

[0208] For example, when initiating a COT, any of the following factors may be used to determine the LBT behavior (e.g., LBT parameters). Additionally, any of the following factors may be used to determine whether the WTRU may share an existing COT and / or the LBT behavior (e.g., LBT parameters) to be used when accessing a channel to share a COT. Additionally, the LBT behavior to be used when sharing a COT may depend on the following factors associated with the transmission initiating the COT and / or the transmissions 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 initiate the COT and / or the L2 ID of the transmission that will share the COT.

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

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

[0211] The source / destination of a sidelink transmission (such as an L2 ID) may refer to whether the L2 ID matches some (pre-)configured L2 ID or set of IDs that require specific LBT behavior. The source / destination of a sidelink transmission may refer to whether the reception contains one or any L2 ID or is associated with one or any L2 ID. For example, the WTRU may receive (from the network or from upper layers) an indication of whether the L2 ID may allow COT sharing and / or LBT behavior and / or an indirection number (or the like) to be applied to transmissions of that L2 ID, and may determine the LBT behavior following the transmission / reception of a PDU for that L2 ID. For example, a WTRU may share a COT with a peer WTRU if the peer WTRU initiates a COT by transmitting to the L2 ID for which the WTRU is interested in receiving the L2 ID. For example, if the L2 ID associated with the transmission is the same as the receiving L2 ID (e.g., transmission is performed to the same unicast link, transmission is performed to the same multicast L2 ID, etc.), the WTRU may be allowed to send with simplified LBT requirements (i.e., requiring LBT to share the COT) after receiving on the SL.

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

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

[0214] The HARQ behavior may refer to whether a transmission / reception is associated with HARQ being enabled or disabled. The HARQ behavior may refer to the (pre-)configured HARQ delay or RTT on the sidelink. The HARQ behavior may refer to whether a HARQ specific channel (PSFCH or PUCCH) is configured. The HARQ behavior may refer to multiple potentially consecutive HARQ feedbacks that may be of a specific type (ACK / NACK / DTX) sent or received. The HARQ behavior may refer to the time required to transmit one or more HARQ feedbacks. The HARQ behavior may refer to the type of multicast HARQ being used (e.g. ACK / NACK or NACK only). The HARQ behavior may refer to whether the WTRU sends a HARQ ACK or a HARQ NACK.

[0215] The QoS of transmission / reception may refer to the priority of the transmission. The QoS of transmission / reception may refer to the (pre-)configured parameters associated with the SLRB. The QoS of transmission / reception may refer to the PQI or similar QoS parameters associated with the QoS flow. The QoS of transmission / reception may refer to whether the transmission is on the SL SRB or on the SL DRB. For example, when the transmission is associated with a first priority, the WTRU may assume a first set of LBT parameters to acquire the channel, and when the transmission is associated with a second priority, the WTRU may assume a second set of LBT parameters to acquire the channel. For example, if the received priority is the first priority, the WTRU may assume that the COT length or the time after the reception of another WTRU without performing full LBT is a first value, and if the received priority is the second priority, the WTRU may assume a second value.

[0216] MCR Minimum Communication Range (MCR) related quantities may refer to the value of the MCR sent / received by the WTRU. MCR related quantities may refer to whether the MCR is transmitted. MCR related quantities may refer to whether the WTRU determines that it is within the transmitted MCR. MCR related quantities may refer to the distance remaining before the WTRU is outside / inside the MCR. MCR related quantities may refer to the calculated distance between the transmitter and the receiver. The WTRU may determine or modify its LBT parameters based on the calculated distance between the WTRU and itself in order to transmit after receiving from another WTRU. The WTRU may always perform Type 1 LBT as long as the distance is above a threshold.

[0217] The WTRU may determine its LBT parameters based on the MCR of the transmission. Specifically, the WTRU may be configured with a CW length (or other parameters that affect its LBT) for the MCR or MCR range. For a TB associated with an MCR, the WTRU may select an appropriate CW length. The WTRU may be configured with an offset (e.g., an increase in the CW length) that will be applied to each increase in the MCR from a particular 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 the value of the MCR (e.g., above or below a threshold). The WTRU may determine the length of the COT to be created based on the number of WTRUs in the group (as determined by upper layers).

[0218] An area-dependent quantity may refer to the specific area in which the WTRU is located and whether such area is associated with one or more (pre-)configured areas (e.g., part of a list). An area-dependent quantity may refer to whether the WTRU is located in the same area as another WTRU. An area-dependent quantity may refer to the configured area size.

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

[0220] The distance between two WTRUs may refer to a distance determined between two WTRUs (eg, a WTRU initiating a COT and a WTRU sharing a COT), which may be calculated, for example, from an area indication sent in an SCI.

[0221] A group-related quantity may refer to the number of WTRUs in a group. For example, a group-related quantity may refer to a group ID configured by a higher layer. A group-related quantity may also refer to a multicast HARQ feedback type (ACK / NACK or ACK only). For example, the WTRU may determine the length of the COT to be created based on the group size (indicated by the upper layer). Specifically, the WTRU may be configured with different COT lengths for a group size or a set of group sizes, and may select the COT length based on the configuration. For example, the WTRU may determine whether to share a COT initiated by a peer WTRU based on whether a transmission from a peer WTRU to an L2 ID is performed. If the COT is initiated by an L2 ID of interest to the WTRU, the WTRU may share a COT initiated by a peer WTRU. In addition, if the COT is initiated by an L2 ID of interest to the WTRU and / or the WTRU is assigned a group number for the L2 ID, the WTRU may determine its LBT behavior differentially. For example, a COT initiated by the WTRU may include a group member ID within the transmission. The second WTRU can determine whether it can share the COT with the initiating WTRU and / or determine the LBT behavior required for the transmission based on a comparison of its own group member ID with the group member ID of the initiating WTRU (e.g., the difference is less than a threshold).

[0222] The message type may refer to whether the transmission / reception includes a specific message associated with the sidelink (such as a Direct Communication Request (DCR) or other message associated with unicast link establishment), or includes a specific MAC CE (such as a CSI report or 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 unicast link that initiated the DCR message is established.

[0223] SL channel or channel type may refer to whether transmission / reception is performed on a specific SL channel, such as SL-SSB, PSCCH, PSSCH, PSFCH, etc.

[0224] The transmission or retransmission type may refer to 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.

[0225] The remaining PDB or latency requirement may refer to the remaining PDB associated with a transmission at LBT, and may refer to an amount of time relative to T2 (or any sensing-based window or time frame). The remaining PDB or latency requirement may refer to the CSI feedback latency bound, or the remaining time in that latency bound at 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.

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

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

[0228] Associated with a resource pool may refer to a specific resource pool or a configuration associated with a resource pool and may apply when transmitting / receiving on resources associated with the pool.

[0229] The allocation mode may refer to whether the transmission / reception is Mode 1 or Mode 2. The WTRU may determine whether it may share the COT (e.g., perform Type 2 LBT) based on the transmission mode of the initiating COT and / or its own transmission mode. If the WTRU attempting to share the COT is using the same transmission mode (Mode 1 or Mode 2) as the WTRU initiating the COT, then the WTRU may share the COT. A WTRU transmitting using Mode 2 may / may not share the COT with a WTRU initiating the COT using Mode 1 and / or Mode 2.

[0230] Another factor may be the time between the previous transmission and the WTRU's own transmission. Assuming that the WTRU is sharing the COT, if the WTRU detects another WTRU's transmission (previous transmission) performed in time slot N-1, the WTRU may perform a transmission in time slot N. In addition, the previous transmission in time slot N-1 may also need to meet another condition in this document (e.g., L2 ID / same unicast link, etc.).

[0231] Another factor may be the member ID in the multicast. Specifically, when the member ID has a first value, the WTRU may assume a first LBT behavior, and when the member ID has a second value, the WTRU may assume a second LBT behavior. For example, a WTRU with a 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.

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

[0233] Another factor may be related to the reservation of resources by the WTRU or other WTRUs. For example, the reservation of resources by the WTRU or other WTRUs may refer to whether the transmission is performed on resources that were previously reserved by the WTRU (for a new TB, or for a retransmission). Specifically, the WTRU may assume a first LBT behavior for transmissions that were not previously reserved, and a second LBT behavior for transmissions that it has previously reserved. The reservation of resources by the WTRU or other WTRUs may refer to whether the transmission is performed on a resource, after a resource reserved by another WTRU, or after a certain amount of time after the resource. For example, the WTRU may use a first LBT behavior (e.g., short LBT) in a time slot that follows a time slot reserved by another WTRU, and may use a second LBT behavior (e.g., normal LBT) in a time slot that does not follow a time slot reserved by another WTRU. A similar approach may be used to address the blocking problem of unlicensed V2X.

[0234] Specifically, if the WTRU fails LBT on slot n-1 for a transmission on slot n, and slot n-1 is associated with a slot in which the sensing results indicate that another SL WTRU performed a transmission, the WTRU may perform only short sensing at the beginning of slot n. Otherwise, the WTRU may perform a normal LBT procedure after the LBT failure.

[0235] Any of the above factors are associated or indicated in a transmission decoded / received by the WTRU, where such transmission is included in a COT that the WTRU wishes to share, or is associated with a transmission that initiated the COT. Herein, attributes of the transmission that initiated the COT, attributes of the last detected transmission within the COT, or attributes of any given transmission occurring within the COT may be used interchangeably.

[0236] Any combination of specific LBT behaviors and the specific sidelink factors listed above (although not explicitly mentioned in the embodiments below) can be envisioned by those skilled in the art.

[0237] In one embodiment, the WTRU may determine the CAPC based on one or more of the above-mentioned sidelink factors. Specifically, the WTRU may determine one or more data associated with the transmission based on the data being sent, and may select the CAPC accordingly. The WTRU may also indicate such CAPC in its own transmissions, possibly when the WTRU initiates a COT (as opposed to when the WTRU shares an already existing COT).

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

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

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

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

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

[0243] The WTRU may be configured with a specific CAPC for transmissions including the SL MAC CE.

[0244] The WTRU may be configured with different CAPC values ​​for transmissions including the SL CSI MAC CE, where each CAPC value may correspond to one or a range of configured latency bounds or the remaining time in the latency bound for transmission of a CSI report to a peer WTRU.

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

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

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

[0248] The WTRU may determine the CAPC to use based on the QoS flows active / configured for a particular transmission in an L2 ID. Specifically, the WTRU may determine the CAPC for transmissions of a given L2 ID 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 the parameter.

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

[0250] The WTRU may use different rules, mapping tables, and / or criteria (or the like) to determine the CAPC, depending on the actual value of the QoS parameter or other values ​​used to determine the CAPC in the first place. For example, the WTRU may use a mapping table from PQI to CAPC to determine the CAPC for transmission of data including a certain QoS flow.

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

[0252] The WTRU may use any factors or rules specific to the SL to determine the rules associated with a COT that is shared by a COT initiated by another WTRU and / or a base station (e.g., a gNB). Such factors may include (but are not limited to): (1) the maximum time between the last transmission in the COT and the time that the WTRU can transmit in the COT without performing LBT, and / or the type of LBT to be performed for each amount of time, or (2) whether the WTRU is allowed to share a COT initiated by another WTRU and / or a base station (e.g., a gNB), or whether the WTRU needs to initiate its own COT (i.e., perform full LBT). The tolerance may be different for a COT initiated by a WTRU versus a COT initiated by a base station (e.g., a gNB). Such factors may also include other LBT attributes mentioned herein that describe factors used to share an initiated COT (e.g., such as any of the above factors that may determine LBT behavior).

[0253] For example, the WTRU may determine the COT sharing rules based on the area ID sent by another WTRU and the WTRU's own area ID. The area ID may represent the distance between the WTRU initiating the COT and the WTRU determining whether to share the COT initiated by another WTRU. If the distance is less than a threshold, the WTRU may decide that it may share the COT.

[0254] The WTRU may determine COT sharing rules based on the L2 ID of the transmission initiating the COT (e.g., the destination L2 ID). For example, a WTRU may share a COT initiated by another WTRU if the L2 destination ID of the transmission initiating the COT is the same (or in a set of related L2 destination IDs) as the L2 destination ID of the transmission to be performed by the WTRU sharing the COT. In addition, the WTRU may be configured with LCP restrictions on grants within a shared COT, whereby such restrictions may apply to the allowable (and possibly destination) L2 IDs that may be selected for such grants. The WTRU may select only the L2 destination IDs that are allowed to share a COT initiated by another WTRU to perform transmissions in a grant occurring within a COT initiated by another WTRU.

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

[0256] The WTRU may determine the COT sharing rules based on the broadcast 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 multicast / broadcast, and so on.

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

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

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

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

[0261] The second WTRU may determine its LBT behavior based on any one or a combination of the following: the network node from which the transmission from the first WTRU is received; the network node associated with the second WTRU's own scheduling (e.g., the cell ID of the scheduling WTRU if in Mode 1, and the cell ID of the WTRU when it is RRC_CONNECTED and resides in RRC_IDLE / RRC_INACTIVE if in Mode 2); whether the second WTRU is in-coverage or out-of-coverage, possibly belonging to the same node; the transmission mode of the second WTRU's transmission (Mode 1 or Mode 2); other factors that affect the LBT behavior described herein

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

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

[0264] In one embodiment, the LBT behavior (e.g., whether a WTRU may share a COT) may be determined based on a combination of the WTRU's own destination L2 ID and a list of L2 IDs received by the WTRU from another WTRU or from a base station (e.g., a gNB). Specifically, the WTRU may determine its LBT behavior based on whether the L2 ID of the transmission associated with the LBT matches any L2 ID included in the received list. The list of L2 IDs received by the WTRU may represent L2 IDs of interest associated with another WTRU, possibly where such WTRU has initiated a COT. This allows the sidelink system to limit COT sharing to transmissions where the WTRU initiating the COT should be the intended recipient of the transmission sharing the COT.

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

[0266] The second WTRU may receive a list of L2 IDs from the first WTRU and may use this information to determine whether to share a 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 the first WTRU may share a 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 L2 ID in the list received from the first WTRU. If the source / destination L2 ID of the transmission is one of the source / destination L2 IDs in the received list, the second WTRU may share the COT with the first WTRU, otherwise, the second WTRU may not share the COT with the first WTRU.

[0267] In another embodiment, the second WTRU may receive a list / relationship from a base station (e.g., a 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 a 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 by the list from the base station (e.g., a gNB). In another example, the second WTRU may receive a list of related L2 destination IDs from a base station (e.g., a gNB). Such a list of related destination L2 IDs may represent a multicast transmission that may share a COT. For example, if the L2 destination ID transmitted by the first WTRU and the destination L2 ID transmitted by the second WTRU appear in the same list, the second WTRU may share a COT with the first WTRU.

[0268] The use of the list and how to determine whether to share the COT may depend on the playout type of the transmission from the first WTRU and / or the playout type of the transmission from the second WTRU. For example, the second WTRU may use any one or a combination of the following determinations regarding whether to share the COT initiated by the first WTRU. These determinations may also be more generally applicable to implementations that do not assume the use of a list.

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

[0270] In another determination, if the first WTRU transmission is unicast to the second WTRU, the second WTRU may share the COT as long as the second WTRU is performing a unicast transmission associated with a pair of source / destination L2 IDs that match the destination / source L2 IDs in the list received from / for the first WTRU.

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

[0272] The above embodiments 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 the list to determine whether to perform a first type or a second type of LBT. For example, the second WTRU may use the list to determine whether to use a first CW or a second CW.

[0273] The WTRU may determine whether to share the COT based on a plurality of conditions associated with different factors being satisfied or at least one condition associated with different factors being satisfied. For example, the WTRU may share the COT if the time between the previous transmission and the WTRU's 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 share the COT if the L2 destination ID of the WTRU's transmission matches the L2 destination ID of the transmission that initiated the COT or if the distance between the WTRU and the transmission that initiated the COT is less than a certain distance.

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

[0275] Figure 2 is a diagram showing an example of unicast COT sharing. Figure 2 As shown, if the second WTRU 204 initiates a COT for a transmission associated with the same unicast link as the transmission of the first WTRU 202, then the first WTRU 202 may share the COT. The first WTRU 202 may make this determination based on the L2 source / destination ID included in the SCI of the initiating 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, then the first WTRU 202 may share the COT. Otherwise, the first WTRU 202 may not share the COT.

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

[0277] In the alternative, any of the conditions described above may be used to determine whether to share the COT, but the transmission from the second WTRU 204 under consideration may be a transmission that occurs within the COT and is not necessarily the transmission that initiates the COT. Specifically, as described above, the WTRU may share the COT for transmissions associated with a unicast link if another WTRU associated with the same unicast link performs a transmission within the same COT to be shared.

[0278] Whether the WTRU is allowed to perform any of the above alternatives (one alternative versus another alternative) may also depend on other SL factors herein (e.g., the priority of the transmission). Figure 2 As shown, the second WTRU 204 can transmit in the COT initiated by the first WTRU 202 because the WTRU 202 and WTRU 204 share a unicast link. However, the third WTRU 206 cannot transmit in the COT initiated by the first WTRU 202 because the WTRU 202 and WTRU 206 do not share a unicast link.

[0279] A COT may be associated with or identified as a specific type, where such type may be determined by one or more sidelink factors. For example, a COT may be a Mode 1 COT or a Mode 2 COT, depending on whether the COT is initiated by a Mode 1 transmission or a Mode 2 transmission. Alternatively, a COT may be mode agnostic (or not specific to any mode). For example, a COT may be a unicast COT, a multicast COT, or a broadcast COT. Alternatively, a COT may be play type agnostic. For example, a COT may be a sensing-based COT, a randomly selected COT, etc. A COT may be a HARQ feedback-based COT or a non-HARQ feedback-based COT.

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

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

[0282] The WTRU may determine its COT sharing rules (as defined herein) based on the COT type and any sidelink factors that may be associated with its own transmissions to be performed within the COT. The WTRU may be allowed to share a specific type of COT for unicast transmissions but not for broadcast transmissions. The WTRU may be allowed to share a specific type of COT for mode 1 transmissions but not for mode 2 transmissions. The WTRU may be allowed to share a specific type of COT for transmissions that are only used for transmissions with HARQ feedback enabled / disabled. The WTRU may be allowed to share a COT if the COT type matches the type of data the WTRU is sending. The WTRU may be configured with different COT sharing rules or different LBT parameters depending on whether the transmission is associated with a COT type. The WTRU may be allowed to share a specific type of COT that is only used for PSFCH transmissions. The WTRU may be allowed to share a specific type of COT if the transmission is associated with a specific priority or has a priority greater than / less than a threshold. The WTRU may be configured with LCP restrictions to allow the LCH to use or not use the grant associated with the COT type. A COT may be considered a “universal” COT (ie, usable by all other WTRUs / transmissions) or a type-specific COT (usable only by a single WTRU or WTRU pair or WTRU-base station pair or a specific type of transmission).

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

[0284] In one embodiment, the WTRU may determine COT sharing rules (e.g., whether a WTRU may share a COT, a maximum time after a transmission that a WTRU may share a COT, and / or an application of a particular type of LBT) based on whether the WTRU is able to hear a particular WTRU initiating a COT and / or the level of indirection of such WTRU initiating a COT. For example, the WTRU initiating a COT may be a WTRU that performs a Type 1 LBT (or full LBT) prior to performing its transmission.

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

[0286] For example, if the WTRU determines that another WTRU initiated a COT, then the WTRU may share a COT initiated by the other WTRU. If the WTRU determines that the level of indirection received from a transmission within the COT (which may be the last transmission, or any transmission) is less than a threshold, then the WTRU may share a COT initiated by another WTRU. Such a threshold may also depend on any sidelink specific factors mentioned herein (e.g., priority).

[0287] For example, the WTRU may determine the type of LBT to be performed for sharing a COT with a peer WTRU based on a combination of the level of indirection and the time gap between transmissions. Specifically, for a particular time gap since the last transmission in the COT, the WTRU may use a first LBT type for a first level of indirection, a second LBT type for a second level of indirection, and so on.

[0288] Figure 3 is a diagram showing an example of multicast / broadcast COT sharing. Figure 3As shown, the WTRU 302 may initiate a COT using a first set of LBT parameters, namely LBT(0). Because the WTRU 302 initiates the COT, it may send an indirect value of 0 in the SCI transmission 320 within the COT.

[0289] WTRU 304 may receive COT information from WTRU 302 and decide to share the COT with WTRU 306. WTRU 304 may perform the LBT procedure using the second set of LBT parameters, namely LBT(1), because it indicates an indirection level of 1. WTRU 304 may also send an indirection value of 1 in SCI transmission 322.

[0290] The behavior of WTRU 306 is similar to that of WTRU 304. WTRU 306 may receive COT information from WTRU 304 and decide to share the COT with WTRU 308. WTRU 306 may perform the LBT procedure using the third set of LBT parameters, namely, LBT(2), because it indicates an indirection level of 2. WTRU 306 may also send an indirection value of 2 in the SCI transmission 324.

[0291] WTRU 308 detects COT information for the same COT from WTRU 302 and WTRU 306, but with conflicting indirection numbers. WTRU 308 receives an indirection value of 2 from WTRU 306 via SCI transmission 224, and receives an indirection value of 0 from WTRU 302 via SCI transmission 326. The WTRU may decide to follow the lowest indirection value of 0 from WTRU 302, and behave as a WTRU within the first level of indirection. Additionally, WTRU 308 may send an indirection value of 1 to the other WTRU in any SCI transmission 328.

[0292] 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 send COT information. A second WTRU that does not receive 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 during the COT of the first WTRU. This may cause the sidelink WTRU to occupy the channel longer than the fairness requirement.

[0293] In one embodiment, a WTRU may modify its assumed COT structure after receiving a conflicting COT structure from another WTRU. The conflicting COT structure 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 to be a conflict. The conflicting COT structure may also include different COT lengths. For example, a shorter COT length (or a COT indicated by another WTRU that ends earlier than the COT assumed by the WTRU) may be considered a conflict.

[0294] In case of a conflict, the WTRU may adopt the COT information received from the other WTRU. In case of a conflict, the WTRU may also modify the COT information it sent to comply with the new information. When the WTRU receives conflicting COT structure information, it is possible that the WTRU may cancel the planned transmission if the received COT structure does not allow the transmission. The WTRU may notify the network when a conflicting COT structure is received.

[0295] In another embodiment, a SL WTRU configured with SL transmission on an unlicensed spectrum in mode 1 may receive a 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 the COT initiated by another WTRU, the WTRU may perform a first LBT type to attempt to share the COT. If the SL grant does not fall within the COT initiated by another WTRU, the WTRU may perform a second LBT type to attempt to initiate its own COT. For this grant, if the LBT fails, the WTRU may report the failed LBT to the base station in the UCI.

[0296] If LBT is successful, the WTRU may determine the COT length, report the remaining COT length (depending on the method used) to the base station (e.g., gNB) in the UCI, and report to the base station (e.g., gNB) whether the first WTRU is initiating its own COT or is sharing the COT of another WTRU. For a WTRU-initiated COT, the WTRU may determine the COT length based on the data multiplexed in the SL grant. For a shared COT, the WTRU may determine the COT length based on the COT length received in the SCI of another WTRU.

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

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

[0299] In another embodiment, a WTRU operating in Mode 2 may perform resource selection based on the existence and / or structure of an existing or expected COT on the SL. A COT may include a COT initiated by other WTRUs (and indicated in the SCI by those WTRUs), or a COT initiated by the WTRU performing resource selection. In this document, an existing COT is a COT that has been initiated by a WTRU or another WTRU via a transmission of the SCI (possibly after a complete LBT process). As a result of future transmissions performed by the WTRU being notified in the SCI, an expected COT may include resources or sets of resources that may be expected to be part of the COT. The resource selection methods herein that depend on the existence of a COT may be applied to existing COTs or expected COTs, which have possibly the same / different rules.

[0300] A WTRU performing Mode 2 resource selection may take into account the existence and / or structure of an existing or anticipated COT by selecting resources within or relative to the COT, including limiting resource selection to resources within the COT or prioritizing 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 a greater number of 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 is within the remaining time in the COT; (5) selecting resources within the COT if the start time of the transmission resource is not greater than a predetermined threshold from the end of the COT; (6) providing (to the MAC layer) available resources for resource selection such that a percentage of the number of available resources residing within the COT is greater than a percentage of the number of available resources residing outside the COT; and (7) providing (to the MAC layer) available resources for resource selection such that an amount or ratio of available resources within the COT is greater (compared to a case where prioritization of resource selection within the COT is not performed). Resource selection may include ensuring that the selected resources start within the COT. Resource selection may also include ensuring that the start of the resources occurs a maximum time after the initiation of the COT, thereby ensuring that at least the initial transmission resources are within the COT.

[0301] A WTRU performing Mode 2 resource selection may take into account the existence and / or structure of an existing or desired COT by selecting resources associated with a particular type of COT. The type of COT may be a COT associated with one or more factors described herein (e.g., indirect number meets criteria, play type is associated with particular criteria, L2 ID meets criteria, etc.). The type of COT may be a COT for which the selected (if initiated by the WTRU) or indicated (if initiated by another WTRU) COT has a particular value or is 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 the desired LBT type, i.e., type 1, 2, or 4, or associated with relevant LBT configuration parameters such as congestion period or backoff)

[0302] A WTRU performing Mode 2 resource selection may select a resource by determining parameters associated with the resource selection based on the presence and / or structure of the COT, thereby taking into account the presence and / or structure of an existing or anticipated COT. The determination may include using a first set of parameters when the selection is performed within a COT or a COT type, and using a second set of parameters when the selection is performed outside a COT or in another COT type. The time gap between the last transmission performed on the resource and the start of the next SL transmission that the WTRU intends to perform using the same resource. The duration of the transmission on the SL data resource, and whether it is within the remaining time in the COT. The determination may include adjusting the parameters of the resource selection based on the timing of the resource relative to the start / end of the COT.

[0303] The WTRU may determine parameters associated with resource selection, which may include (but are not limited to) any of the following: the number of retransmission resources; the number of contiguous resources that the WTRU should select; resource patterns, such as minimum / maximum time between transmission / retransmissions, number of time-contiguous resources / frequency-contiguous resources to be selected; maximum / minimum number of RBs; duration of a given transmission / retransmission resource; the total number of resources that can be selected, which may be associated with the COT / COT type; whether to perform / allow periodic resource selection or one-time resource selection.

[0304] The WTRU may select a resource by considering the COT based on one or more conditions. For example, if the condition is met, the WTRU may determine whether to select a resource by considering the COT (otherwise it may not do so). If the condition is met, the WTRU may determine a specific behavior when considering the COT, and if the condition is not met, the WTRU may use another behavior when considering the COT. For example, when a first condition is met, the WTRU may use a first set of parameters when selecting a resource considering the COT, and may use a different set of parameters otherwise. For example, the WTRU may select a resource associated with a first type of COT under a first condition, and select a resource associated with a second type of COT under a second condition.

[0305] These conditions may be related to the type of data available for transmission (e.g., QoS, LCH, MAC CE to data, SRB to DRB, etc.). The condition may be that there is data available for transmission with a certain priority. The condition may be whether the available data consists of only MAC CE, or whether the available data includes MAC CE and data or only data. For example, the condition may be whether the available data consists of only SRB bits, or whether the available data includes SRB data. The condition may be that there is control information available for transmission, which may have a certain priority. The control information may be an SCI multiplexed on a data resource or an SCI sent on a control resource.

[0306] The condition may be related to a configured condition, which is associated with data. For example, one or more LCHs may be configured to have specific behaviors 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 particular LCH associated with the configured condition, the WTRU may select resources 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 enabled HARQ or disabled HARQ. The condition may be whether the LCH is configured with an MCR and / or a condition on the value of the MCR.

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

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

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

[0310] The condition may be related to the presence, ratio, or amount of available resources that fall within the COT. For example, the condition may be that the percentage of available resources that fall within the COT is above a threshold value.

[0311] This condition may be related to the number of COTs currently initiated by the WTRU.

[0312] The condition may be related to whether the TB is a retransmission. For example, if the TB is a retransmission (possibly after several retransmissions or LBT failures), the WTRU may select a certain resource. The retransmission may be due to a previous LBT failure, due to receiving / determining a NACK, or due to not receiving HARQ feedback for a TB that has been sent. In one example, if the WTRU receives a NACK, an LBT failure, and / or the WTRU does not receive HARQ feedback, the WTRU may use a different resource or resource pool to retransmit the TB. If HARQ feedback is not received within the expected time after the TB transmission, the WTRU may monitor the HARQ feedback on a different resource or resource pool.

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

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

[0315] In one embodiment, the WTRU may associate a resource (eg, a time slot, a set of time slots, a sub-channel, a set of sub-channels, etc.) with one or more attributes associated with the COT.

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

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

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

[0319] In one embodiment, the WTRU may be configured with a subset of sidelink data resources that may be used with a specific timing. The WTRU may attempt to acquire the channel only at a certain timing offset associated with the resource. The WTRU may be configured to select and perform LBT only on resources starting within a given slot offset from a radio frame boundary, corresponding to the applicable offset. The WTRU may be configured with a subset of possible offsets within a radio frame or within a slot. If the LBT process fails, the WTRU may attempt to acquire the channel at the next possible offset.

[0320] The WTRU may determine the offset semi-statically based on a configured value, or as the time to the next available resource. Alternatively, the WTRU may determine the offset dynamically. The dynamic determination may depend on: (1) the priority of the data associated with the TB; (2) whether the data is multiplexed from one or more LCHs configured with a high priority index; (3) whether the data is multiplexed from a subset of the configured LCHs or from a subset of the configured 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.

[0321] The WTRU may start a retransmission timer to measure the retransmission period when attempting to (re)send a TB for which LBT failed. The WTRU may start a retransmission timer only when a HARQ-ACK with the value NACK is determined for the HARQ process. The WTRU may not attempt to acquire the channel during the retransmission period. The value of the timer or time period may be configured by upper layers or may be changed dynamically based on previous LBT attempts or the selected timing offset for acquiring the channel.

[0322] The WTRU may be configured with a retransmission timer per resource pool, per SL carrier, per LBT bandwidth / subband, or per MAC entity. In one example, the WTRU may start a timer after a LBT failure on a given resource pool. When a timer associated with a resource pool is running, the WTRU may not select resources to retransmit or send a TB on that 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 the TB size is supported, the WTRU may be able to (re)send the TB on a resource pool different from the last selected resource pool.

[0323] The WTRU may prioritize / select resources within the COT or in a temporal position relative to the COT. The WTRU may determine a set of available resources, where a subset of resources may include resources within the COT and other resources may not be within the COT. Under certain conditions herein, the WTRU may be able to select resources within the COT or prioritize resources within the COT. For example, if the data available for transmission is above a threshold priority, the WTRU may select only from resources within the COT. Otherwise, the WTRU may be allowed to select resources from within the COT or not within the COT. For example, if the measured CBR is above a threshold, the WTRU may select only from resources within the COT or may prioritize the selection of resources within the COT.

[0324] The WTRU may determine that multiple resources are available to select from and perform a transmission or retransmission.

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

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

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

[0328] The WTRU may also prioritize resource selection based on RSSI. The WTRU may select resources that meet a configured or predetermined RSSI or CBR threshold. The WTRU may prioritize resource selection in descending order of RSSI.

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

[0330] In one embodiment, the WTRU may determine a set of selectable resources. The WTRU may select or prioritize resources that appear no more than a threshold number of time slots from the beginning 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 or prioritize resources that require one or more different LBT types to acquire a channel. The WTRU may select or prioritize resources that appear no more than a threshold number of time slots from the current WTRU or another WTRU's transmission (as detected in the SCI) or a planned transmission (as determined based on forward observation information in the SCI). The WTRU may select or prioritize resources that appear no more than a number of time slots away from the current WTRU or another WTRU's transmission based on any of the conditions mentioned herein (e.g., if the measured CBR is above a threshold, if the data available for transmission is above a threshold priority, etc.).

[0331] In one embodiment, the WTRU may determine a set of selectable resources. If the WTRU has initiated a COT and / or the resource selection window overlaps with the COT, the WTRU may select or prioritize resource transmissions within the COT. The WTRU may perform such operations based on conditions herein, such as a measured CBR being above a threshold and / or a priority of data available for transmission being above a threshold.

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

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

[0334] In another example, the WTRU may select or prioritize resources if the number of indirections is below a threshold (possibly under certain conditions as described herein). In another example, the WTRU may select or prioritize resources that are FBE on one condition and may select or prioritize resources that are LBE otherwise (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 attribute of the LCH with the highest priority for which data is available.

[0335] In one embodiment, the WTRU may determine parameters for resource selection based on COT information, where the parameters may include any of the parameters discussed herein. The COT information may be associated with a resource, such as whether the resource is within a COT, the type of COT to which the resource is associated, the time since the WTRU or another WTRU initiated the COT, the time since the last transmission by the WTRU or another WTRU, etc.

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

[0337] The WTRU may select resources using the requirement of having a number of consecutive time slots available for transmission when the resource is associated with LBE, and may not use such a requirement when the resource is associated with FBE. The WTRU may determine an allowable periodicity of resource selection for multiple resource selections based on the configured and / or determined available FBE resources.

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

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

[0340] When performing resource selection that will initiate COT at the WTRU, the WTRU may determine the maximum time between transmission / retransmission / selected resources based on the priority / CAPC of the data available for transmission at the time of resource selection. Specifically, the WTRU may be configured with a first allowed time for a first priority / CAPC, a second allowed time for a second priority / CAPC, etc.

[0341] When the WTRU initiates its own COT, the WTRU may select contiguous time resources. On the other hand, when the WTRU transmits within a COT that has been initiated (by itself or by another WTRU), the WTRU may not be required to select contiguous time resources. The number of contiguous resources (e.g., allowed, required) may also depend on the conditions described herein (e.g., CBR, CAPC, priority of data triggering resource selection, playout, SL measurements, etc.).

[0342] When a WTRU is sharing a COT, or transmitting within a COT that it has initiated, the WTRU may select a continuous time resource based on the time difference between the selected resource and any transmission performed / announced / scheduled by the WTRU itself or by another WTRU. Specifically, the allowable number of continuous transmissions may be a function of the time / gap between the resource and the last transmission by the WTRU (which may be within the same COT, or may be associated with a COT other than the COT in which the resource was selected).

[0343] One advantage of the above described embodiment is that it allows the WTRU to perform transmissions on the unlicensed spectrum using resources that the WTRU selected based on the required LBT rules for transmissions on the unlicensed spectrum. For example, because the WTRU may need to perform CAT4 LBT before transmission, the initiation of COT may require contiguous resources. Specifically, if LBT fails on the first timeslot, the WTRU may still be able to transmit in a subsequent timeslot because the WTRU has also selected the subsequent timeslot during resource selection. In order to share the COT, the WTRU may perform a short LBT and the number of (potentially contiguous) resources that need to be selected may be smaller.

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

[0345] One condition may be that the WTRU fails LBT, possibly multiple times in a row, or possibly for multiple selected (possibly consecutive) resources. Another condition may be that the WTRU fails to initiate a new COT for transmission purposes. Another condition may be that the WTRU fails to share a COT initiated by another WTRU (i.e., a WTRU fails short LBT within an existing COT).

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

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

[0348] In one embodiment, when determining whether resources are available for transmission, the WTRU may consider the resources indicated in the forward reservation signal (i.e., occurring in the reservation period after the reservation SCI) as well as other resources occurring before and / or after the forward reserved resources as unavailable for transmission. Such an embodiment may be advantageous because it allows a first TX WTRU to attempt LBT on multiple, possibly consecutive resources (associated with the resources announced in the previous SCI) until the LBT succeeds (or until a maximum number of resources is reached), while a second TX WTRU may avoid selecting for its own transmission any resources that may be used by the first TX WTRU after a successful LBT.

[0349] In one example, a first TX WTRU may initiate LBT on future announced resources directly indicated by a previous SCI. The first TX WTRU may maintain a scheduled periodicity (compared to the first transmission) for the future announced resources regardless of the number of failed LBTs prior to the success of the first transmission. Alternatively, the first TX WTRU may change the scheduled gap between the first transmission and the second transmission by an amount that depends on the number of failed LBTs performed for the first transmission. Specifically, the first TX WTRU may reduce the scheduled gap for the second transmission by a number of time slots, possibly equal to the number of time slots for which LBT failed for the first transmission. As a second TX WTRU (the TX WTRU that performs sensing to determine available resources), when performing resource selection, the second TX WTRU may assume that the resources indicated by the previous SCI and a number of subsequent (possibly consecutive) time slots are considered unavailable.

[0350] In another example, the first TX WTRU may initiate LBT on a future (second) resource that is always the value of a period T (i.e., a selected periodicity) from the time slot in which the first TX WTRU first initiated LBT for the first transmission. In such an example, the first TX WTRU may include in the SCI an indication of the number of time slots before the indicated future (second) resource, where the first TX WTRU may initiate LBT for transmission in the future resource. The second TX WTRU may assume that the indicated resource and a number of resources before the indicated resource (where this number of resources is indicated in the SCI) are considered occupied. Additionally, the second TX WTRU may assume that a number of time resources or time slots after the indicated resource are occupied, where this number is determined by the total number of possible LBT attempts in consecutive time slots minus the number of time slots indicated in the received SCI (i.e., the time slots before the indicated resource).

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

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

[0353] In another example, if the WTRU receives an SCI indicating that a COT is initiated by another WTRU, the WTRU may trigger a preemption / re-evaluation, where a COT may occur earlier than the selected resources. Such preemption / re-evaluation may be further triggered if the resources selected / reserved by the WTRU require a COT to be initiated (possibly when a COT initiated by another WTRU may be shared by the WTRU). In this case, the WTRU may reselect resources that are only within the COT indicated in the received SCI.

[0354] An advantage of such an embodiment may be that reselection is performed at the WTRU when the WTRU determines that a COT is initiated (possibly by another WTRU), and the WTRU may use that COT for transmission (rather than performing its own COT initiation).

[0355] The WTRU may receive (e.g., in Mode 1), may select (e.g., in Mode 2), or be configured with a multi-opportunity sidelink data transmission resource. A multi-opportunity resource consists of more than one possibly consecutive data transmission opportunities on which there may be LBT opportunities, whereby the WTRU may attempt LBT at each opportunity until LBT succeeds. Once LBT succeeds, the WTRU may transmit at the remaining opportunities in the resource without performing LBT again. For each data transmission opportunity, the WTRU may attempt to transmit the same TB for which LBT failed or may transmit a different TB.

[0356] In one embodiment, a WTRU sharing a COT may indicate a multi-timing resource to be shared with one or more than one WTRU, whereby the sharing WTRU signals to each shared WTRU a starting timing at which the resource may be started and / or used; such indication may be indicated by an SCI or MAC CE. Upon receipt of such an SCI or MAC CE, if the gap between the transmission of the sharing WTRU and the start time of the shared WTRU is less than a preconfigured threshold (e.g., a gap for type 1 LBT), the shared WTRU may perform a short LBT (e.g., type 1 or 2) before starting to transmit at the indicated timing for the shared WTRU, or simply transmit without LBT. The sharing WTRU may indicate the possible remaining starting timings in the COT, and the shared WTRU may randomly select a timing for acquiring the channel among the indicated timings.

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

[0358] The Mode 2 resource pool may be configured with a number of occasions and a start time for multi-occasion resources. The WTRU may determine the HARQ process based on the timing of the first occasion within the multi-occasion combination package. The WTRU may keep using the same HARQ process until LBT succeeds. Once LBT succeeds, the WTRU may increment or change the HARQ process (for example, if the WTRU has other data to send).

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

[0360] A WTRU selecting multiple LBT opportunities in Mode 2 may select multiple resources for its own transmission. The multiple LBT opportunity resources may include the same frequency resources in consecutive or non-consecutive time slots. Alternatively, the multiple LBT opportunity resources may include different frequency resources in the same or different time slots.

[0361] The WTRU may select multiple resources for its initial transmission and subsequently select only a single set of resources for its retransmissions. Alternatively, the WTRU may select multiple resources for the initial transmission and, for each resource of its initial transmission, select multiple resources for each retransmission. Whether the WTRU selects a single retransmission resource (set) or multiple such retransmission resources for each initial transmission resource may depend on the same conditions described below for whether the WTRU uses multiple LBT timing 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 resource and the retransmission resource, the type of LBT required for the retransmission resource, or whether the selected resource occurs within the COT.

[0362] In another embodiment, the WTRU may perform an initial transmission or a retransmission in any one of the multiple LBT opportunity resources. Specifically, after LBT on the multiple LBT opportunity SL resources is successful, the WTRU may perform an initial transmission followed by a retransmission in the remaining resources of the multiple LBT transmission resources. The WTRU may also assume that the transmissions on the remaining resources after LBT is successful do not require LBT (or require a different LBT type).

[0363] Mode 2 WTRUs may select multiple LBT opportunities SL resources based on certain conditions. Specifically, Mode 2 WTRUs may decide to select multiple LBT opportunities and / or the number of retransmission resources for each initial transmission resource based on satisfying any one or a combination of the following:

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

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

[0366] Mode 2 The WTRU may decide to select multiple LBT opportunities and / or the number of retransmission resources for each initial transmission resource based on the type of LBT required to perform the transmission. For example, if a transmission requires a specific LBT type (e.g., Type 1 LBT, Type 2 LBT), the WTRU may select multiple LBT opportunity SL resources, otherwise, the WTRU may perform conventional resource selection.

[0367] Mode 2 The WTRU may decide to select multiple LBT opportunities and / or the number of 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 is above a threshold, the WTRU may select multiple LBT opportunity SL resources, otherwise, the WTRU may perform conventional resource selection.

[0368] Mode 2 The WTRU may select multiple LBT opportunities and / or the number of 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 retransmission resource (set) for all initial transmission resources associated with multiple LBT opportunities.

[0369] Mode 2 WTRU may decide to select multiple LBT opportunities and / or the number of retransmission resources for each initial transmission resource based on the measured CBR or any congestion metric of the SL. For example, if the measured CBR is below a threshold, the WTRU may select multiple LBT opportunity SL resources, otherwise, the WTRU may perform traditional resource selection.

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

[0371] The WTRU may determine the number and / or pattern of resources in multiple LBT opportunities based on the sensing results. For example, the WTRU may select the number of resources (e.g., up to a maximum value) based on other factors herein. However, if the sensing results indicate that this number of resources is not available based on the sensing results, the WTRU may select a lower number of resources. Specifically, if allowed by the availability information provided based on the sensing results, the WTRU may select up to the maximum number of resources.

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

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

[0374] The WTRU may determine the number and / or pattern of resources in multiple LBT opportunities based on the CBR. For example, the WTRU may be configured with a maximum number of resources associated with multiple LBT opportunities for a given measured CBR.

[0375] The WTRU's LBT may fail on one or more individual resources of the multiple LBT opportunity resources. In this case, the WTRU may initiate or continue LBT on the next resource of the multiple LBT opportunity resources. The remote WTRU may perform LBT on each subsequent resource of the multiple LBT opportunity resources until the LBT succeeds or until the WTRU has exhausted LBT attempts on each resource in the multiple LBT opportunity resources.

[0376] When LBT succeeds on one of the resources of the multiple LBT opportunity resources, the WTRU may perform any one or a combination of the following:

[0377] When LBT succeeds on one of the resources of the multiple LBT opportunity resources, the WTRU may perform a transmission on the resources associated with the successful LBT. Specifically, the WTRU may perform an initial transmission on the resources after the LBT succeeds. The WTRU may also determine whether it can perform an initial transmission on the resources after the LBT succeeds, or whether it should select a subsequent resource (not necessarily a resource immediately following the LBT success) based on the conditions described herein. Specifically, if the priority of the pending data transmission is higher than a threshold, if the CBR is lower than a threshold, if the sensing result indicates that the resource is available, or any combination thereof, or any combination together with the other factors described herein, the WTRU may determine whether to perform a transmission in the first resource after the LBT succeeds.

[0378] When LBT succeeds on one of the resources of the multiple LBT opportunity resources, the WTRU may perform a transmission on a subsequent resource associated with the successful LBT. Specifically, the WTRU may select one of the remaining resources associated with the multiple LBT opportunity resources on which to start the transmission, and may initiate the transmission on the selected resource. The WTRU may select the resource based on the following:

[0379] The WTRU may select resources based on priority. For example, the WTRU may be (pre-)configured with a mapping between priority / QoS and the resources on which the transmission will be initiated after LBT is successful. Specifically, a WTRU with a higher priority transmission may initiate a transmission immediately (or earlier) in the remaining resources of the multiple LBT resources, while a WTRU with a lower priority transmission may initiate a transmission later after LBT is successful.

[0380] The WTRU may select a resource based on the remaining PDB. The WTRU may determine on which resource of the remaining resources after a successful LBT to initiate a transmission based on the remaining PDB. For example, the smaller the remaining PBD, the earlier the WTRU may initiate a transmission. The WTRU may select (randomly or based on other rules herein) a resource for initiating a transmission after a successful LBT, which ensures that the transmission and possible subsequent retransmissions are performed before the PBD times out.

[0381] The WTRU may select a resource based on a random or probabilistic rule. For example, the WTRU may randomly select one resource from the remaining resources of the multiple LBT opportunities on which to initiate a transmission, which resource may further satisfy any other criteria. The WTRU may be configured with a probability (which may depend on or be determined by other factors herein) with which a transmission will be initiated on any remaining resource of the multiple LBT opportunities.

[0382] The WTRU may select resources based on the HARQ timeline. For example, the WTRU may select resources among the remaining resources after a successful LBT on which to initiate a transmission that complies with the HARQ timeline selected by the WTRU during the selection of resources for transmission and retransmission.

[0383] The WTRU may select a resource based on the sensing results. For example, the WTRU may determine whether to transmit in one of the resources of the multiple LBT opportunity resources based on whether the WTRU detects other SLWTRU transmissions (i.e., in the SCI). The WTRU may initiate a continuous partial sensing operation when initiating LBT or when LBT is successful. The WTRU may initiate a transmission only in the first resource of the multiple LBT resources where the continuous partial sensing indicates that the resource is available.

[0384] The WTRU may perform transmissions on multiple resources of the multiple LBT resources after LBT success. For example, the WTRU may decide to perform transmissions on multiple (possibly time-contiguous) resources of the multiple LBT resources starting from LBT success. 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:

[0385] 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 is above a threshold, the WTRU may be allowed to use multiple remaining resources after a successful LBT for transmission and retransmission.

[0386] 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 transmissions with a priority higher than a threshold or with a certain priority relative to the first transmission (e.g., at least the same priority as the first transmission and not more than a certain priority lower than the first transmission), then the WTRU may be allowed to use subsequent resources after the first transmission after LBT succeeds.

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

[0388] The WTRU may determine whether to perform multiple transmissions and the number of subsequent retransmissions based on the number of planned / allowed retransmissions: for example, if the WTRU has planned retransmissions, perhaps associated with a TB initially sent in multiple LBT resources after LBT succeeds, the WTRU may use subsequent resources.

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

[0390] The WTRU may continue to perform LBT, or may perform a shorter LBT. For example, after a successful LBT on a multiple LBT occasion, if the WTRU decides to perform a transmission multiple time slots after the LBT success (as determined based on the conditions herein), the WTRU may continue to perform LBT, or may perform a short LBT before the resources selected for the actual transmission after the first successful LBT for the multiple LBT occasions. For example, the type of LBT may further depend on the time between the first successful LBT and the selected resources for the transmission within the multiple LBT occasions. Specifically, if the WTRU decides to transmit immediately after the first successful LBT, or to transmit up to N time slots after the first successful LBT, the WTRU may transmit without a short LBT.

[0391] The WTRU may be configured to perform a recovery procedure upon a failure associated with acquiring resources selected in multiple LBT opportunities. The WTRU may generally be configured to perform a recovery procedure generally upon any failure related to LBT (e.g., after one or more SL LBT failures). Such a recovery procedure may be any of the following:

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

[0393] The trigger for performing the recovery procedure may be associated with the attributes of the multiple LBT resources. The WTRU may trigger a recovery procedure upon failure of resource selection (possibly several times in a row, or several times within a time window) to select an appropriate set of available resources for the multiple LBT opportunities. The appropriate number of available resources may include finding at least N consecutive single-slot resources within the resource selection window.

[0394] The WTRU may trigger a recovery procedure upon LBT failure on all resources associated with multiple LBT opportunities (possibly several times consecutively or within a window).

[0395] The WTRU may trigger a recovery process upon one or more events (e.g., a number of consecutive events, or a number of events occurring within a configured time window) associated with a failure to acquire a channel during a multiple LBT opportunity, or associated with a success in acquiring a channel during a multiple LBT opportunity, but: (1) the amount of resources remaining during the opportunity is below a threshold; (2) no transmission or number of retransmissions are performed due to sensing results indicating that resources are unavailable; and / or (3) a number of transmissions and / or retransmissions are performed within the multiple LBT opportunity, which is less than the configured or expected amount associated with the success event.

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

[0397] Specifically, LCP restrictions may be performed by the WTRU during the selection of an L2 destination ID and / or the selection of a logical channel for transmission on the sidelink. The LCP restrictions may relate to one of the following attributes associated with the grant:

[0398] The LCP restriction may be related to whether the grant is within an existing COT (i.e., whether the grant is associated with the WTRU creating a COT).

[0399] The LCP restrictions may be related to whether the authorization is within the COT, whether the COT is initiated by the WTRU itself or by another WTRU.

[0400] The LCP restriction may be related to whether the authorization is within the COT, and whether the COT is initiated by unicast / multicast / broadcast transmission.

[0401] The LCP restrictions may be related to whether the authorization is within the COT, the source / destination L2 ID of the WTRU whose transmission initiated the COT.

[0402] The LCP restriction may be related to whether the grant is a Mode 1 grant or a Mode 2 grant.

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

[0404] The LCP restriction may be related to whether the authorization is within the COT, the number of SL transmissions that have been performed within the COT, the channel occupancy measured within the COT (CR, CBR or number of reserved / used subchannels), transmissions based on other WTRUs or the WTRU's own transmissions.

[0405] The LCP restriction may be associated with the CAPC of the COT that the grant is in. For example, the WTRU may be allowed to multiplex data for a certain LCH as long as the CAPC of that data has a higher priority than the CAPC associated with the COT that the WTRU is attempting to share.

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

[0407] LCP restrictions may be associated with grants in a COT that is initiated by the WTRU or shared with another WTRU. For example, a WTRU may be allowed / not allowed to multiplex data of a certain priority or range of priorities into a grant used to initiate a COT; a grant in which the WTRU shares a COT; and a grant in which the WTRU transmits on a COT that it has already initiated. Furthermore, combinations of each of these three cases are possible. For example, a WTRU may be allowed to multiplex data with a priority above / below a threshold in a grant in which the WTRU will initiate and / or has initiated its own COT.

[0408] For example, a WTRU may be configured with 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 the WTRU itself. For example, if a grant falls within a COT initiated by another WTRU, the sending WTRU may only select LCHs with a priority at least as high as the priority / CAPC indicated in the COT information. If a grant falls within a COT to be initiated by the WTRU itself, the WTRU may select any LCH priority to be multiplexed into the COT.

[0409] In another example, the WTRU may be configured with a first priority restriction rule for a grant within a COT that results in the initiation of a COT, and a first priority restriction rule for a grant within a COT that has been initiated by the WTRU. For example, if a grant falls within a COT that was previously initiated by the WTRU itself, the WTRU may / may not restrict the LCH, or may use a different priority restriction than the restriction associated with the grant used to initiate the COT.

[0410] LCP restrictions may be associated with attributes associated with the COT and / or with data sent in a grant that initiates the COT, where such attributes may be a play type, destination ID, priority, WTRU group, delay, PDB, or any other SL attribute described herein. For example, a WTRU may be allowed to multiplex data of a particular play type in a grant that occurs within a COT, where such play type is determined by the play type associated with the COT (e.g., included in the information in the COT) or the play type used in the grant that initiated the COT. Specifically, once a COT is used for a particular play type, the COT needs to continue to be used for that play type. In addition, restrictions may depend on the play type itself. For example, a WTRU sharing a COT initiated by a unicast transmission may only select an L2 destination ID that is the same as the L2 source ID of the WTRU that initiated the COT. For example, a WTRU sharing a COT initiated by a broadcast transmission may select an L2 ID associated with a multicast (which may be the same as the L2 ID that initiated the COT) or any unicast transmission. For example, a WTRU sharing a COT initiated by a broadcast transmission may select any L2 ID for the transmission that will share the COT.

[0411] For example, a WTRU may be allowed to multiplex data for a particular L2 ID in a grant occurring within a COT, where such L2 ID is determined by the play type associated with the COT (e.g., in information included in the COT) or the L2 ID used in the grant that initiated the COT. Specifically, once a COT is used for a particular 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 a multicast / broadcast transmission may select the same L2 ID for transmissions on that grant as the L2 ID of the transmission that initiated the COT.

[0412] LCP restrictions may be associated with an indirection, as described herein, with a COT. For example, a WTRU may be configured with a set of LCHs that can / cannot be multiplexed into a grant that appears within the COT of a certain indirection or set of indirections. For example, a WTRU may be configured with one or more playback types that can / cannot be multiplexed into a grant that appears within the COT of a certain indirection or set of indirections.

[0413] The LCP restriction may be associated with a transmission mode (i.e., Mode 1 versus Mode 2). For example, a COT may be associated with a mode (i.e., Mode 1 or Mode 2) which may represent the resource selection mode used by the WTRU when initiating a COT. The WTRU may determine the transmission mode used to initiate a COT based on information in the transmission itself. The WTRU initiating a COT may include an operation mode (Mode 1 or Mode 2) for initiating 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.

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

[0415] In another example, the WTRU may decide the allowable L2 destination IDs, LCH priorities, or other restrictions on logical channels to be multiplexed in the grant based on whether the WTRU using the grant is inside / outside the MCR of the transmission that initiated the COT. For example, if the WTRU is 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 that shares the COT. Otherwise, if the WTRU is outside the MCR associated with the transmission that initiated the COT, the WTRU may be restricted to selecting the same L2 ID and / or restricting the LCH priorities that may be multiplexed into the grant (e.g., only LCHs with a priority higher than or equal to that of the CAPC associated with the COT)

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

[0417] Furthermore, the WTRU may decide on allowable L2 destination IDs, LCH priorities, or other restrictions on logical channels to be multiplexed in a grant based on any of the three combinations described above.

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

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

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

[0421] The WTRU may decide whether to apply LCP restrictions (e.g., any of the above-described LCP restrictions) based on SL factors or transmission types, as identified herein. For example, the WTRU may apply LCP restrictions on a first resource allocation mode (e.g., mode 1) and not apply LCP restrictions on a second resource allocation mode (e.g., mode 2).

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

Claims

1. A method performed by a first wireless transmit / receiver unit (WTRU), the method comprising: receiving sidelink control information (SCI) from a second WTRU initiating a shared channel occupancy time (COT) with the first WTRU, the SCI comprising: (1) COT information, the COT including an associated channel access priority class (CAPC) value, wherein the CAPC value has an integer value between 1 and 4; and (2) at least one of: (a) a source ID associated with the second WTRU or (b) a destination ID associated with the second WTRU; Using the shared COT; performing a type 2 LBT procedure for transmission during the shared COT; wherein if the shared COT is associated with a unicast type, the source ID of the transmission from the first WTRU matches the received destination ID associated with the second WTRU, and the destination ID of the transmission from the first WTRU matches the received source ID associated with the second WTRU; and Wherein if the shared COT is associated with a multicast type, the destination ID of the transmission from the first WTRU matches the received destination ID associated with the second WTRU.

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

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

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

5. The method according to claim 1, wherein: Data is sent on the condition that the Type 2 LBT process is successful. 6 . 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. The method of claim 1 , wherein the SCI further comprises a duration of the COT.

8. A first wireless transmit / receiver unit (WTRU), the transmit / receiver unit (WTRU) comprising: Transceiver; and processor; Wherein the transceiver and the processor are configured to: receiving sidelink control information (SCI) from a second WTRU initiating a shared channel occupancy time (COT) with the first WTRU, the SCI comprising: (1) COT information, the COT including an associated channel access priority class (CAPC) value, wherein the CAPC value has an integer value between 1 and 4; and (2) at least one of: (a) a source ID associated with the second WTRU or (b) a destination ID associated with the second WTRU; Using the shared COT; performing a type 2 LBT procedure during the shared COT; wherein 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 received destination ID associated with the second WTRU, and to match the destination ID of the transmission from the first WTRU with the received source ID associated with the second WTRU; and Wherein 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 received destination ID associated with the second WTRU.

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

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 process is performed on a channel associated with the COT based on a determination that the COT can be shared.

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

13. The first WTRU of claim 8, 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.

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

Images