Method and apparatus for scheduling sidelink in unlicensed spectrum

Abstract

Methods and apparatuses for scheduling sidelink communications in unlicensed spectrum are disclosed. A method performed by a first wireless transmit / receive unit (WTRU) can include receiving, from a second WTRU that initiates a shared channel occupancy time (COT) with the first WTRU, sidelink control information (SCI), the SCI including: (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.

Description

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

[0002] Cross-references to related applications

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

[0004] Vehicle-to-everything (V2X) communication is a communication mode in which vehicles can communicate directly with each other. One scenario for V2X operations is within coverage, where the WTRU can receive assistance from the network to begin sending and receiving V2X messages. Another scenario for V2X operations is outside coverage, where the WTRU can use pre-configured parameters to begin sending and receiving V2X messages.

[0005] V2X communication is supported in LTE and is inspired by previous work on device-to-device (D2D) communication. V2X communication services can consist of different types, including: vehicle-to-vehicle (V2V), where vehicle WTRUs can communicate directly with each other; vehicle-to-infrastructure (V2I), where vehicle WTRUs can communicate with RSUs / eNBs; vehicle-to-network (V2N), where vehicle WTRUs can communicate with the core network; and vehicle-to-pedestrian (V2P), where vehicle WTRUs can communicate with WTRUs with special conditions (e.g., low battery capacity). Summary of the Invention

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

[0007] The authorization can be obtained from the base station. The authorization can also be obtained via authorization selection from the first WTRU. The playback information can indicate unicast or multicast playback type. The received information can be the first COT information or the playback information. The parameter set can be associated with information received from the second or third WTRU, including transmission priority. The parameter set can be associated with information received from the second or third WTRU, including indirection number. The indirection number can be received from the second or additional WTRU via sidelink control information (SCI) transmission.

[0008] According to one aspect of this disclosure, a method is provided performed by a first wireless transmit / receive unit (WTRU), the method comprising: receiving side-side link control information (SCI) from a second WTRU that initiates 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 the second WTRU or (b) a destination ID associated with the second WTRU; using a shared COT; performing a type 2LBT 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.

[0010] According to one aspect of this disclosure, a first wireless transceiver unit (WTRU) is provided, the WTRU comprising: a transceiver; and a processor; wherein the transceiver and the processor are configured to: receive side-side link 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 category (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) an ID associated with the second WTRU. The associated destination ID; using a 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 a transmission from the first WTRU with the received destination ID associated with the second WTRU, and to match the destination ID of a 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 a transmission from the first WTRU with the received destination ID associated with the second WTRU. Attached Figure Description

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

[0012] Figure 1A This is a system diagram illustrating an exemplary communication system that can be implemented in one or more of the disclosed embodiments;

[0013] Figure 1B This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary wireless transceiver unit (WTRU) used within the communication system shown;

[0014] Figure 1C This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown;

[0015] Figure 1D This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown;

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

[0017] Figure 3 This is a diagram illustrating an example of multicast / broadcast COT sharing. Detailed Implementation

[0018] Figure 1A This is a schematic diagram illustrating an exemplary communication system 100 that can be implemented in one or more of the disclosed embodiments. Communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, communication system 100 can 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 Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0019] like Figure 1A As shown, the communication system 100 may include wireless transceiver 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. However, 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, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile user units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, 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 base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (such as CN 106, Internet 110, and / or other networks 112). As an example, base stations 114a and 114b may be base transceiver stations (BTS), Node Bs, evolved Node Bs (eNBs), home Node Bs, home evolved Node Bs, next-generation Node Bs, such as gNode Bs (gNBs), New Radio (NR) Node Bs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0021] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area, which may be relatively fixed or changeable over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, 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 transmit and / or receive signals in desired spatial directions.

[0022] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[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, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 may implement radio technologies 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 the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0025] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can enable radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0026] In the implementation scheme, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions to / from various types of base stations (e.g., eNBs and gNBs).

[0027] In other implementations, base station 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN).

[0028] Figure 1A Base station 114b can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106.

[0029] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can 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. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1AAs shown, but it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104 which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0032] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may include any sub-combination of the foregoing elements.

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

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

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

[0036] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via various RATs (such as NR and IEEE 802.11).

[0037] The processor 118 of 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) 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, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 may access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in that memory.

[0038] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (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 a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0040] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. Sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0041] WTRU 102 may include a full-duplex radio for which the 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 through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the 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)) are concurrent.

[0042] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to the implementation scheme. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0043] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Each evolved Node B 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In the implementation scheme, evolved Nodes B 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

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

[0045] Figure 1C The CN 106 shown 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 can connect to each of the evolved nodes B 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0047] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-evolved Node B handovers, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0048] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0049] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 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] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

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

[0052] A WLAN in Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for an external BSS destination can be transmitted to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be transmitted via the AP, for example, where a source STA can transmit traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be transmitted between a source STA and a destination STA (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0053] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically configured. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative implementations, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (including the AP) can listen to the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0054] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0055] The Very High Throughput (VHT) STA supports channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be processed by a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. These streams can be mapped to two 80MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be transmitted to Media Access Control (MAC).

[0056] 802.11af and 802.11ah support operating modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative implementations, 802.11ah may support instrument-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 supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0057] WLAN systems supporting multiple channels, as well as channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS (each supporting a minimum bandwidth operating mode). In the 802.11ah example, for STAs supporting (e.g., only supporting) a 1MHz mode (e.g., MTC type devices), the primary channel can 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 Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, all available frequency bands can be considered busy even if most available 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 available bandwidth for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0059] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to an implementation scheme. As noted above, RAN 104 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0060] RAN 104 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 104 may include any number of gNBs, while remaining consistent with the implementation. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communication with WTRUs 102a, 102b, and 102c via air interface 116. In the implementation, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In the implementation, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an implementation, gNBs 180a, 180b, and 180c may implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

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

[0062] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved nodes B160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate or connect to gNBs 180a, 180b, and 180c, as well as to other RANs (such as evolved Node Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more evolved Node Bs 160a, 160b, and 160c. In a non-standalone configuration, evolved Node Bs 160a, 160b, and 160c can serve as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0063] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

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

[0065] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service used by WTRU 102a, 102b, and 102c. For example, different network slices can 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, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

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

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

[0068] CN 106 can facilitate communication with other networks. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Furthermore, CN 106 can provide WTRU 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, WTRU 102a, 102b, 102c can be connected to DN 185a, 185b via UPF 184a, 184b through the N3 interface to UPF 184a, 184b and the N6 interface between UPF 184a, 184b and local DN 185a, 185b.

[0069] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding descriptions herein refer to one or more of the functions described below, or all of the functions described herein, which may be performed by one or more emulation 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 devices described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0070] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, the one or more simulation devices may perform one or more functions, while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices may perform one or more functions, while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or use over-the-air wireless communication to perform tests.

[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 devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via an RF circuit system (e.g., which may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0072] Please refer to the following abbreviations and acronyms:

[0073] ACK confirmation

[0074] BSR Buffer Status Report

[0075] CAPC Channel Access Priority Categories

[0076] CBR Channel Busyness

[0077] CG Community 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 Priority Sequencing

[0096] MAC CE MAC control element

[0097] MCR Minimum Communication Range

[0098] NACK (Negative Acknowledgment)

[0099] PCell main cell

[0100] PDB Packet Delay Budget

[0101] PDU Protocol Data Unit

[0102] PHY physical layer

[0103] PSCCH (Physical Side Link Control Channel)

[0104] PSFCH Physical Side Link Feedback Channel

[0105] PSSCH Physical Side Link 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 auxiliary cell

[0113] SCI sidelink control information

[0114] SL side link

[0115] SL UCI sidelink uplink control information

[0116] SR scheduling request

[0117] SRB signaling radio bearer

[0118] SSB Synchronization Signal Block

[0119] TB transfer block

[0120] TX transmitter

[0121] UCI uplink control information

[0122] UE User Equipment

[0123] UL uplink

[0124] V2X: From Vehicles to Everything

[0125] WTRU Wireless Transmit / Receive Unit

[0126] MAC Media Access Control

[0127] CWS contention for window size

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

[0129] In LTE, these resource pools can be semi-statically signaled to the WTRU via Radio Resource Control (RRC) signaling. In Mode 4, the WTRU can use sensing before selecting resources from the transmit pools configured by RRC. LTE V2X does not support dynamic resource pool reconfiguration. Pool configuration can be carried solely 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 autonomous resource allocation by the WTRU. The concepts of resource pooling and sensing used for Mode 2 resource allocation are also inherited from LTE.

[0131] In 3GPP, access to unlicensed frequency bands is defined under the Licensed Assisted Access (LAA) framework. More specifically, it specifies downlink (DL) operations, uplink (UL) operations, autonomous UL, and other enhancements. The LAA leverages the premise that unlicensed operations are always anchored to a PCell within a licensed frequency band. Access to unlicensed frequency bands within a SCell requires LBT operations by the WTRU / gNB.

[0132] The new radio designation specifies unlicensed spectrum (NR-U). NR-U supports NR radio access operating via shared spectrum channel access, thus enabling operation in different modes, where PCell, PSCell, or SCell can be in the shared spectrum and SCell may or may not be configured with a UL.

[0133] To support NR-U, the following modifications were made to the PHY layer signals and channels: (1) DCI 2_0 was enhanced to provide time-domain and frequency-domain Channel Occupied Time (COT) structures; (2) Search space group switching features were introduced, which allow WTRUs to be dynamically controlled to perform PDCCH monitoring using one of two search space sets; (3) An additional PDSCH mapping type B length was introduced to enable transmission at the start of COT once it is initiated; (4) The search space can be configured with multiple monitoring locations in the frequency domain to enable PDCCH monitoring across multiple LBT bands; (5) Interleaving structures were introduced for PUCCH and PUSCH, and the PUCCH format was extended to PRB interleaved waveforms but included within a single RB set; (6) SRS transmissions can be located on any symbol in the time slot; and (7) gNBs can schedule multiple consecutive PUSCHs using a single DCI format.

[0134] WTRUs operating in shared spectrum can perform LBT to access the channel. NR-U supports Dynamic Channel Access (LBE) and Semi-Static Channel Access (FBE). In some implementations, for FBE, only gNBs can initiate COT at a specific time notified by their Fixed Frame Period (FFP) configuration. If a gNB DL transmission is detected in an earlier portion of the same FFP, the WTRU can share the semi-static channel. In other implementations, the WTRU can be configured with a WTRU-FFP and can initiate COT at a specific time determined according to its WTRU-FFP configuration.

[0135] Clear Channel Assessment (CCA) can be performed in 20MHz units. The following types of LBTs 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 a 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 either a CAT1 LBT or a CAT2 LBT.

[0137] LBT parameters can be determined by the Channel Access Priority Class (CAPC). The CAPC for radio bearers and MAC CEs is fixed or configurable: (1) fixed to the lowest priority for padding BSRs and recommended bit rate MAC CEs; (2) fixed to the highest priority for SRB0, SRB1, SRB3 and other MAC CEs; and / or (3) configured by the gNB for SRB2 and DRBs.

[0138] When selecting a CAPC for a DRB, the gNB can consider the 5QI of all QoS flows multiplexed within that DRB, while also considering fairness between different service types and transports. Table 1 below shows which CAPC should be used for which standardized 5QIs (i.e., which CAPC should be 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 no CAPC is indicated in the DCI and the WTRU performs a Type 1 LBT procedure for transmissions in the uplink TB, the WTRU may select the CAPC as follows: (1) if only MAC CEs are included in the TB, use the highest priority CAPC of those MAC CEs; or (2) if CCCH SDUs are included in the TB, use the highest priority CAPC; or (3) if DCCH SDUs are included in the TB, use the highest priority CAPC of the DCCH; or (4) otherwise use the lowest priority CAPC of the logical channel with MAC SDUs multiplexed in the TB.

[0142] In NR-U, channel access employs a traditional Uu architecture. Specifically, the gNB schedules multiple WTRUs within its coverage area, and it is assumed that the gNB's location is fixed. Once a channel is accessed, the transmissions scheduled by the gNB and performed by the WTRUs are directed to the gNB. However, for SL operations in shared spectrum, these assumptions may no longer hold true.

[0143] One issue that arises is the Mode 1 scheduling problem. In Mode 1 SL, the gNB schedules SL resources to the WTRU. The scheduled DCI may reside in a shared spectrum (possibly the same shared spectrum as the WTRU's transmission). However, the WTRU's transmission may be intended for another WTRU instead of the gNB. Therefore, the gNB may not know whether the WTRU has acquired the channel after the DCI. Furthermore, there may be scenarios where the gNB does not perform the LBT procedure for accessing the channel, in which the WTRU will perform a transmission (e.g., an SL transmission by the WTRU on a different carrier than the one in which the DCI is transmitted). Specifically, the WTRU may not share the COT initiated by the gNB. However, the WTRU may share the 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) are primarily dependent on the QoS of the data to be transmitted. While this may be suitable for Uu infrastructure / architecture, it may not be suitable for the typical distributed architecture of V2X. Specifically, V2X can support unicast, multicast, and broadcast. Furthermore, some transports (e.g., broadcast) are typical of unrelated WTRUs, while others (e.g., unicast) are typical of WTRUs traveling together. These factors can influence the LBT parameters required for such transports. These factors can also affect COT usage rules, such as whether WTRUs can share a COT initiated by another WTRU.

[0145] In this document, the term "initiating COT" can refer to performing a full LBT (e.g., type 1 LBT). Similarly, "sharing COT" can refer to performing a simplified LBT (e.g., type 2 LBT). The WTRU can identify an authorization as a type 1 LBT authorization or a type 2 LBT authorization. As discussed herein, determining whether a transport in an authorization is performed, and determining the type of transport based on whether the WTRU is initiating or sharing an authorization, can be derived based on the identifier of the type of LBT to be performed on that authorization.

[0146] In this document, the reference to the WTRU that initiates the COT may refer to the WTRU that performs the SL transmission, which creates a new COT. Alternatively, the WTRU that initiates the COT may also refer to another WTRU that transmits within the COT and whose transmission is detected by the WTRU. Alternatively, the WTRU that initiates the 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 can refer to any aspect relating to a method for accessing a channel in a shared spectrum (e.g., LBT).

[0148] LBT behavior may include CAPC, or determining a similar access class / classification of the LBT parameter set. For example, LBT behavior may include the WTRU selecting a channel access priority class for a given data or transport type (as described herein). For example, LBT behavior may include the WTRU determining whether to use the UL CAPC table or the DL CAPC table for the LBT. For example, LBT behavior as described 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, LBT behavior may include the WTRU determining whether it can select any access priority class for a transport, or whether it can select a specific access priority class only for a transport.

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

[0150] LBT behavior may include determining between a first rule for obtaining a CAPC from a transport comprising multiple elements (e.g., using the highest priority of the CAPCs included in the transport) and a second rule for obtaining a CAPC from such a transport (e.g., using the lowest priority of the CAPCs included in the transport), each of which has its own CAPC. For example, the WTRU may use the lowest priority of the CAPC for one type of transport (e.g., mode 1 transport) and the highest priority of the CAPC for another type of transport (e.g., mode 2 transport). The transport type may also include any SL characteristics defined herein and is not necessarily limited to modes, such as priority (including the priority of any data / control data 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 used to obtain the PDU may include any of the following: (1) determining whether to select the highest or 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 MAC CE and / or SRB; (4) determining whether to obtain the CAPC from the priority of DRB; (5) determining the order in which the rules are applied when determining the CAPC (e.g., considering MAC CE first, DRB first, SRB first, etc.); (6) determining whether to consider the priority of MAC CE, SRB or DRB in the determination.

[0152] LBT behavior can include any existing LBT parameters, such as contention window size (CWS), maximum COT length, allowable CW size, CW adjustment process, number of CCAs, CCA duration, delay period, and / or FFP parameters applied to the SL. For example, LBT behavior may include the WTRU selecting a specific maximum COT length instead of another. For example, LBT behavior may include the WTRU determining whether to use / consider parameters (such as delay period) as part of the LBT. For example, 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, LBT behavior may include deciding whether to use a first CW adjustment process (or a set of parameters for that process) or whether to use a second CW adjustment process (or another set of parameters for that process). For example, selecting LBT parameters may include selecting one of several (pre-)configured values, or determining the parameter's value directly based on time-related SL characteristics (such as PDB, HARQ RTT, intervals between different SL channels, etc.).

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

[0154] LBT behavior may also include LBT beam, beamwidth, or beam direction (including omnidirectional). For example, LBT behavior may include the WTRU selecting the LBT beamwidth, performing LBT on it to obtain the number of channels / sub-channels for channel access, etc.

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

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

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

[0158] LBT behavior may also include any time instance between LBT executions on the channel. 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 that minimum / maximum time (e.g., no LBT, single LBT, full LBT, etc.).

[0159] LBT behavior may also include whether WTRUs are allowed to share COTs initiated by a base station (e.g., gNB) and / or another WTRU. For example, LBT behavior may include a WTRU determining whether it can share a COT initiated by another WTRU. For example, LBT behavior may include a 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 a transmission of the WTRU itself that requires one or another type of LBT to access the channel.

[0161] LBT behavior may also include the COT length, determined by the WTRU that initiated the COT and possibly transmitted in the COT structure information. For example, LBT behavior may include the WTRU selecting one COT length instead of another (e.g., both can be configured). For example, LBT behavior may include whether the WTRU restricts the selected COT length to a specific value.

[0162] 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, LBT behavior may include the initiating WTRU determining whether to indicate that the COT can be shared. For example, 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 implementation, the WTRU may have multiple independent LBT behaviors and / or procedures. An LBT procedure (e.g., CW adjustment) may involve multiple steps, with parameters (e.g., CW applied to a given access priority) updated after one or more steps. The WTRU performing SL LBT may maintain multiple independent / concurrent LBT procedures that independently update parameters within the procedure. Each independent / concurrent LBT procedure may be associated with SL factors such as: (1) playback type (e.g., one procedure for unicast and one procedure for multicast / broadcast); (2) L2 source / destination ID (e.g., one procedure for each destination L2 ID); (3) unicast link (e.g., one procedure for each pair of source / destination IDs); (4) QoS flow; (5) resource pool; and / or (6) HARQ-enabled and HARQ-disabled transports.

[0164] Any of the LBT processes related to the LBT behavior described above may have multiple independent / concurrent instances of the LBT process. The WTRU that performs LBT for a transport with specific factors can then use parameters associated with an instance of that process.

[0165] The WTRU can have different CW adjustments for transmissions that enable / disable HARQ. In one implementation, the WTRU can 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 can use different adjustment parameters / values ​​after a transmission that includes enabled HARQ feedback versus one that includes disabled HARQ feedback. In another example, after a transmission that disables HARQ feedback, the WTRU can set the CW to a default or configured value. In another example, for a transmission that disables HARQ feedback, the WTRU can increase / decrease the CW by a default / configured amount. In another example, the WTRU can ignore all transmissions that disable HARQ feedback when a CW update is determined. In another example, the WTRU can set the CW to an initial value after a transmission that disables HARQ feedback. In yet another example, the WTRU can decrease the CW adjustment by an amount based on the number of transmissions that disable HARQ within a time window or the number of transmissions that have disabled HARQ since the last transmission that enabled HARQ. In another example, after a transmission with HARQ feedback disabled, the WTRU can reset the CW to its default / initial value. In yet another example, the WTRU can be configured to increment the CW for NACK. Furthermore, if HARQ feedback is disabled, the increment of the CW can be associated with a function (e.g., half, double, etc.). This function can also depend on other non-static factors at the WTRU. In yet another example, the determination of whether the WTRU increments the CW by a first or second amount after a transmission with HARQ feedback disabled can depend on whether the previous transmission resulted in an ACK or a NACK.

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

[0167] Mode 1 scheduling for SL can depend on the base station's (e.g., gNB) ability to access channel availability information (e.g., information about COT obtained from the SL 3GPP system). In one implementation, the WTRU can determine whether to perform LBT procedures and LBT behaviors (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 can receive an indication of whether an LBT procedure is required / not required and / or the type of LBT required in the DCI authorized by the scheduled SL. The WTRU can determine whether an LBT is required or not, or the type of LBT, is required, based on the time difference between the received scheduled DCI and the scheduled SL resource. Here, for example, the WTRU may be (pre-)configured with a mapping of LBT types to the time difference between the scheduled DCI and the SL resource, and can use this time difference to determine the type of LBT to be performed. For example, if the time between the scheduled DCI and the SL resource is below a threshold, the WTRU may assume that an LBT is not required, or that a short LBT is required.

[0169] The WTRU can receive explicit indications of whether an LBT procedure is required or not and / or the type of LBT required in a separate DCI. The WTRU can be configured with an SL-configured authorization and can receive a scheduling DCI prior to any instance of that authorized authorization to indicate whether an LBT procedure is required or not and the type of LBT.

[0170] Furthermore, combinations of the above examples are possible. For example, the WTRU can receive an explicit indication of whether to execute type 1 LBT, or whether to execute an LBT type determined by the time difference between the scheduling DCI and the SL authorization timing. Such explicit indications can reside in the DCI. Such explicit configuration can 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 an LBT process is not required, or that a short LBT process is required if the time between scheduling the DCI and SL resources is less than a threshold (only in the case of the same carrier).

[0172] In another implementation, the WTRU can determine the LBT parameters to use based on a combination of information from 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 can use the first LBT if its authorization falls within the COT indicated in the SCI. If the DCI does not explicitly indicate the LBT type, the WTRU can follow the DCI indication.

[0173] In another implementation, the WTRU can determine the LBT parameters based on the source of the received SCI. Specifically, the WTRU can 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 SCI transmission detected on the SL and a comparison with a threshold (such threshold can 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 authorization. The WTRU can determine how it combines such information based on information in the DCI or similar information provided in the RRC signaling.

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

[0175] The LBT type or parameter 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 (which may include the maximum CW size or the currently used CW size); (4) LBT beam orientation or beamwidth (e.g., the LBT may be omnidirectional); (5) COT duration (which may include the maximum COT duration); (6) delay period duration; and / or (7) FFP configuration.

[0176] For example, if the WTRU receives a CAPC or similar information in the DCI, the WTRU can determine the type of LBT to use based on the time difference between the DCI and SCI. This corresponds to a scenario where the base station (e.g., gNB) performs an LBT itself to transmit the DCI. If the WTRU does not receive a CAPC in the DCI, the WTRU can determine the type of LBT to perform based on the SCI transmission. Specifically, if the WTRU does not find a COT initiated by another WTRU to share, the WTRU can perform a type 1 LBT. Otherwise, if the WTRU shares a COT, it can perform an LBT where the type can be determined based on the time gap between the WTRU's authorization and the last SCI / transmission of another WTRU. Similarly, the WTRU can also determine the type of data (e.g., priority, playback, etc.) based on similar rules.

[0177] The COT information of the WTRU (e.g., in a form similar to CG-UCI) can be sent by the WTRU in the SCI. The WTRU can send such COT information in each SCI. Alternatively, the WTRU can send information in a subset of SCI transmissions, such as periodically, every x transmissions, every x time intervals, in the SCI transmission that initiates the COT, upon receiving the SCI that initiates the COT, or where some COT information is included.

[0178] WTRUs can send COT information in other PHY channels (e.g., besides PSCCH). Alternatively, WTRUs can send COT information in SL MAC CE, SL RRC messages, WTRU inter-resource coordination messages, or similar messages. WTRUs can send COT information that determines when to initiate COT.

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

[0180] In one implementation, the WTRU may report COT information received from another WTRU to the base station (e.g., gNB), or COT information determined by the WTRU based on reception from another WTRU. For example, such reports may be transmitted in the PUCCH or SR in the form of HARQ feedback, CG-UCI, MAC CE, or RRC messages. COT information may include any of the following: (1) COT structure (e.g., time / frequency resources associated with the COT); (2) remaining COT duration; (3) CAPC associated with (or used to initiate) the COT; (4) LBT statistics collected by the WTRU (e.g., the amount of occupied / available resources within the CW); (5) COT type (as defined herein) or COT attributes that determine the availability attributes of the WTRU or transmission that initiated the COT or sent the COT information, such as L2 ID, WTRU type (e.g., sensing / non-sensing WTRU, DRX WTRU, WTRU release or profile), IC / OOC WTRU, and / or IC (5) WTRU associated cell ID (may operate 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. The set of BWs (which may include the set of BWs on which LBT is performed, the set of BWs on which LBT is considered successful, or the set of BWs on which LBT is considered to have failed); (13) the occupied / available resources within the COT (based on sensing); (14) the QoS information (e.g., priority) associated with the transmission that initiated the COT; (15) the expected gap between two sidelink transmissions, or the existence of a gap between two sidelink transmissions; (16) whether the transmission that initiated the COT is an initial transmission or a retransmission; (17) the identity of the node that initiated the COT; (18) whether the COT has been shared by WTRUs; and / or (19) whether the COT can be shared by a base station (e.g., gNB) or another WTRU.

[0181] COT information may also include information about when (i.e., time location) a transmission within the COT initiated by one or more other WTRUs or said WTRUs will terminate (e.g., a WTRU may determine the existence of a COT initiated by a WTRU based on the reception of an SCI indicating that the COT was initiated via the transmission of that SCI). The SCI may also include the duration of the COT. One or more SCIs received by said WTRU may also include information associated with the expected use of resources within the COT by one or more other WTRUs. For example, a WTRU may determine (e.g., based on the 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 this timing information to a base station (e.g., a gNB).

[0182] COT information can be reported periodically. For example, a WTRU can have a periodic resource on which to send information about the existence of an ongoing COT and any COT information associated with it.

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

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

[0185] The WTRU can report COT information periodically or non-periodically. Periodic or non-periodic reporting can reuse the methods described herein for reporting COT information received from peer devices.

[0186] In one exemplary implementation, the WTRU may be configured with one PUCCH resource (possibly associated with SL grant) for indicating whether LBT was successful, and another PUCCH resource (possibly associated with the same SL grant) for reporting HARQ ACK / NACK to the base station (e.g., gNB). Specifically, if the WTRU is able to acquire the SL channel at grant, the WTRU may transmit ACK in the first PUCCH resource and may then transmit ACK / NACK on the second PUCCH resource based on the SL HARQ feedback from the RX WTRU. Alternatively, the information provided on the first PUCCH resource may indicate: (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 not acquired under 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), wherein the threshold may be based on the priority of data in the buffer, included in the PDU, or reported in the BSR. WTRU can also indicate (using a third code point) that it has not acquired a channel for that license.

[0187] In another approach, the WTRU can send feedback on a single PUCCH resource. The feedback can indicate one of three states (ACK, NACK, or DTX), where DTX indicates that the transmission was not performed due to a failed LBT.

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

[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 the potential LBT statistics associated with the failure; (2) LBT failure when attempting to acquire an existing COT initiated by another WTRU, and the 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 is shorter than required at the time of authorization, and therefore was 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 can be configured with SR resources to indicate failure to acquire the SL channel. The WTRU can also be configured with different SR configurations, depending on the priority of the data multiplexed in the PDU that will be sent on the grant of LBT failure.

[0191] The WTRU can trigger / transmit a report of COT information as described in the embodiments above. The WTRU can trigger / transmit a report of COT information when it 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 procedure on a resource associated with an SL grant, the WTRU can transmit a HARQ NACK, SR, or similar UL transmission. For example, the WTRU can perform a UL transmission when the first / last resource associated with the grant LBT procedure (e.g., the first / last retransmission resource for granting) fails. For example, the WTRU can perform a UL transmission when it cannot acquire at least x resources associated with an SL grant over the network, 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 potential Channel Access Target (COT) that it can initiate (based on its own channel access) or detects (based on reception from another WTRU), the WTRU can trigger / transmit a COT information report. In one example, the WTRU can send COT information to the base station (e.g., in MAC CE) when it determines that a COT was initiated by another WTRU (e.g., based on SCI reception from another WTRU).

[0193] In another example, the WTRU can send COT information to the base station (e.g., gNB) when the COT information previously reported to the base station changes (e.g., in the MAC CE). For example, the change in COT information could be the appearance of a gap within the COT that is greater than a (pre-)configured threshold (e.g., due to a lack of SL transmission). The change in COT information could also be a received message (e.g., from a second WTRU) indicating a desired COT length that is shorter than the COT length initially indicated for the same COT (possibly by the first WTRU).

[0194] When a WTRU is configured with conditions regarding whether to report COT information received from other WTRUs or determined by the WTRU (e.g., via RRC configuration or via MAC CE), the WTRU may trigger / transmit the reporting of COT information. For example, the conditions may include: (1) reporting COT information as long as the remaining COT length is less than / greater than a threshold (e.g., for newly detected COT); (2) reporting COT information as long as the CAPC is higher than / lower than a threshold; (3) reporting COT information as long as the maximum time gap in the (potentially planned) transmission within the COT is higher than / lower than 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., a specific amount may have changed (e.g., the COT length has changed by a certain amount).

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

[0196] A WTRU can maintain multiple COTs. For example, a WTRU can 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). A WTRU can maintain different COT parameters for each COT. For example, a WTRU can share a first COT and can initiate a second COT. For example, a WTRU can use only the COT associated with a base station (e.g., a gNB) for a transmission to a base station (e.g., a gNB). A WTRU can share a COT associated with a base station (e.g., a gNB) for a transmission to another WTRU. A WTRU can 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) can be associated with the COT associated with the base station (e.g., a gNB).

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

[0198] In another implementation, once authorization is received in the DCI, or at some time after receiving the DCI, the WTRU can initiate an LBT procedure on the SL. This time period can be (pre-)configured, indicated in the DCI, and / or depend on the measurements of the SL and / or the QoS of the transmission.

[0199] In another implementation, the WTRU may provide multiple SL grants (possibly with a single DCI, or with a DCI and mode configured by RRC or MAC CE). Multiple SL grants can be explicitly indicated in the DCI. Alternatively, the multiple SL grants may follow a predefined time / frequency pattern. The purpose of the grants may be to allow the WTRU to attempt the LBT procedure 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 previously granted grant. Alternatively, the WTRU may be configured to determine whether to retain or cancel subsequent grants based on: (1) the amount of data in the buffer (e.g., if the WTRU has data available for transmission, possibly associated with a specific 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 subsequent grants, otherwise the WTRU may retain subsequent grants); (3) the number of remaining subsequent grants (e.g., the WTRU may be configured with a maximum number of subsequent grants that it can maintain and may discard the remainder); (4) the priority of the data in the buffer; (5) any combination of (1) to (4) above; and / or (6) any other conditions as described herein (e.g., associated with the multi-LBT timing described herein).

[0201] WTRU can determine whether an LBT is required before an upcoming authorization for a resource in the same set of multiple SL authorizations, based on whether the LBT was successful before a previous authorization in the set of multiple SL authorizations, the duration since the most recent successful LBT, and whether there is a gap before the upcoming authorization.

[0202] A WTRU utilizing multiple SL grants can choose whether to share an existing COT or initiate a new COT based on parameters of one or more SL grants within a set of multiple SL grants. For example, the WTRU can determine whether to share an existing COT based on the amount of grants in the set of multiple SL grants that can be transmitted within the COT. For instance, if the WTRU has n SL grants in the SL grant set and the ongoing COT has sufficient resources for the transmission of m SL grants, the WTRU can determine whether to share the ongoing COT or initiate a new COT based on m and n. The WTRU can also determine whether to share the ongoing COT or initiate a new COT based on the transmission priority of one or more SL grants within the set of multiple SL grants.

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

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

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

[0206] If the authorization or potential authorization of a WTRU falls within a COT initiated by a base station or another WTRU, the WTRU may transmit the COT information received in a transmission by the other WTRU or base station (i.e., the COT structure indicated by the other WTRU). The WTRU can determine whether to share the existing COT or initiate a new COT based on the information received from the other WTRU within the existing COT in the COT information, wherein 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 its own receptions (e.g., when sharing a COT initiated by another WTRU). Here, the term "combination" can refer to the use of two or more factors in determining LBT behavior. Combination can refer to excluding a behavior due to the presence of one factor and selecting from the remaining behaviors based on other factors. Combination can refer to determining one LBT behavior based on a first factor and determining another LBT behavior based on a second factor. Combination can refer to determining the number or type of LBT behaviors to be determined based on one factor while selecting behaviors based on other factors.

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

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

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

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

[0212] A WTRU can receive COT information from multiple peer UEs and can determine its own LBT behavior and / or initiate or share COT based on one or more COT information. In one example, the WTRU can use COT information received from a peer WTRU associated with the longest / shortest COT length, the highest / lowest priority, the priority of conditions matching the data priority associated with the sending WTRU itself, and the nearest peer WTRU (in terms of the distance between the peer WTRU and the sending WTRU receiving the COT information).

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

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

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

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

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

[0218] Region-related quantities can refer to the specific region where the WTRU resides, and whether such a region is associated with one or more (pre-)configured regions (e.g., a portion of a list). Region-related quantities can also refer to whether the WTRU is located in the same region as another WTRU. Region-related quantities can also refer to the configured region size.

[0219] CBR-related parameters can refer to the CBR measured at the WTRU. They can also indicate whether the CBR is below or above a threshold, whether the CBR is measurable, or the time period in which the CBR was measured.

[0220] The distance between two WTRUs can refer to the distance determined between two WTRUs (e.g., the WTRU that initiates the COT and the WTRU that shares the COT), for example, the distance can be calculated by the area indication sent in the SCI.

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

[0222] The message type can refer to whether the transmission / reception includes specific messages associated with the sidelink (such as Direct Communication Request (DCR) or other messages associated with unicast link establishment), or specific MAC CEs (such as CSI reports or WTRU inter-coordination messages). For example, when receiving / transmitting a DCR message, the WTRU may assume that an LBT is not required, or only that a specific LBT is required until the unicast link initiating the DCR message is established.

[0223] The SL channel or channel type can 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 can refer to whether the transmission / reception consists of an initial transmission or a retransmission. For example, this could refer to the number of retransmissions associated with a retransmission.

[0225] Remaining PDB or delay requirement can refer to the remaining PDB associated with the transmission at LBT, and can refer to the amount of time relative to T2 (or any sense-based window or time frame). Remaining PDB or delay requirement can refer to the CSI feedback delay limit, or the remaining time within that delay limit at the time of transmission. Remaining PDB or time delay requirement can 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 a transfer-related SCI can refer to the presence or absence of any values ​​in the SCI. For example, this could refer to the value of any field in the SCI. Content included in a transfer-related SCI can refer to whether the SCI is used to trigger a CSI report. Content included in a transfer-related SCI can refer to whether the SCI is reserving any future resources. Content included in a transfer-related SCI can refer to the time between the current transfer and the future reserved resources (e.g., whether it is above or below a specific value).

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

[0228] The association with a resource pool can refer to a specific resource pool or a configuration associated with a resource pool, and can be applied when transmitting / receiving on resources associated with that pool.

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

[0230] Another factor could be the time between a previous transmission and the WTRU's own transmission. Assuming the WTRUs are sharing a COT, if the WTRU detects a transmission from another WTRU (a previous transmission) being performed in time slot N-1, it can perform a transmission in time slot N. Additionally, the previous transmission in time slot N-1 may also need to satisfy another condition described in this paper (e.g., L2 ID / same unicast link, etc.).

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

[0232] Another factor can be the L2 source / destination ID. Specifically, WTRU can be configured (e.g., via PC5-RRC, via Uu RRC, via upper layers, etc.) with LBT behavior that will be applied to a given L2 ID or L2 ID pair.

[0233] Another factor can relate to the reservation of resources by the WTRU or other WTRUs. For example, the reservation of resources by the WTRU or other WTRUs can refer to whether a transmission is performed on a resource previously reserved by the WTRU (for a new TB, or for a retransmission). Specifically, the WTRU can assume a first LBT behavior for transmissions that were not previously reserved, and a second LBT behavior for transmissions that were previously reserved. The reservation of resources by the WTRU or other WTRUs can also refer to whether a transmission is performed on a resource, after a resource reserved by another WTRU, or after a certain amount of time following that resource. For example, the WTRU can use a first LBT behavior (e.g., short LBT) in a time slot following a time slot reserved by another WTRU, and can use a second LBT behavior (e.g., normal LBT) in a time slot not following a time slot reserved by another WTRU. Similar approaches can be used to address the congestion problem of unlicensed V2X.

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

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

[0236] Any combination of a particular LBT behavior with the particular sidelink factors listed above (although not explicitly mentioned in the embodiments below) can be conceived by those skilled in the art.

[0237] In one implementation, the WTRU can determine CAPC based on one or more of the sidelink factors described above. Specifically, the WTRU can determine one or more data associated with the transmission based on the data being transmitted, and can select CAPC accordingly. The WTRU can also indicate such CAPC in its own transmissions, possibly when the WTRU initiates a COT (or vice versa when sharing an existing COT with the WTRU).

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

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

[0240] WTRU can determine CAPC based on whether HARQ is enabled or disabled for a transport. For example, WTRU can be configured with a first set of CAPCs (e.g., by LCH or by priority) for transports with HARQ enabled, and a second set of CAPCs for transports with HARQ disabled.

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

[0242] The WTRU can use a fixed, predefined, or (pre-)configured CAPC for a specific side link transmission, or for a transmission that includes a specific message, such as a DCR message. For example, an SL MAC CE can use a fixed CAPC. Alternatively, the WTRU can use any CAPC for a specific SL transmission or for a transmission that includes a specific message (e.g., a DCR).

[0243] WTRU can be configured with specific CAPCs for use in transports including SL MAC CE.

[0244] WTRUs can be configured with different CAPC values ​​for transmissions including SL CSIMAC CE, wherein each CAPC value can correspond to one or a range of configured delay limits or remaining time within delay limits for transmitting CSI reports to peer WTRUs.

[0245] WTRU can use a first CAPC value or set of values ​​for mode 1 transmission, and can use a second CAPC value or set of values ​​for mode 2 transmission.

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

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

[0248] The WTRU can determine the CAPC to use based on the QoS flows / configurations for a specific transport activity in an L2 ID. Specifically, the WTRU can determine the CAPC for a transport in an L2 ID based on PQI information associated with one or more QoS flows for a given L2 ID activity. The WTRU can select the flow with the highest value of a parameter (e.g., priority) and determine the CAPC for the L2 ID based on that parameter.

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

[0250] WTRU can use different rules, mapping tables, and / or criteria (or similar) to determine CAPC, depending on the actual value of the QoS parameter or other values ​​initially used to determine CAPC. For example, WTRU can use a mapping table from PQI to CAPC to determine the CAPC for transmissions of data that include a certain QoS flow.

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

[0252] The WTRU may use any SL-specific factors or rules 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 during which the WTRU can transmit in the COT without performing an LBT, and / or the type of LBT to be performed for each time interval, or (2) whether the WTRU is permitted to share a COT initiated by another WTRU and / or a base station (e.g., a gNB), or whether the WTRU is required to initiate its own COT (i.e., perform a full LBT). This tolerance may differ for COTs initiated by the WTRU versus those initiated by a base station (e.g., a gNB). Such factors may also include other LBT attributes mentioned herein that describe factors used for sharing an initiated COT (e.g., any of the factors described above that can determine LBT behavior).

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

[0254] A WTRU can determine COT sharing rules based on the L2 ID (e.g., destination L2 ID) of the transmission initiating the COT. For example, if the L2 destination ID of the transmission initiating the COT is the same as (or within a set of related L2 destination IDs) the L2 destination ID of the transmission to be performed by the WTRU sharing the COT, then the WTRU can share the COT initiated by another WTRU. Furthermore, the WTRU can be configured with LCP restrictions for authorizations within the shared COT, whereby such restrictions can be applied to permissible (potentially destination) L2 IDs that can be selected for such authorizations. The WTRU can select only the L2 destination IDs that are allowed to be shared within the authorizations occurring in the COT initiated by the other WTRU to perform the transmission.

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

[0256] WTRU can determine COT sharing rules based on the playback type of the transmission. For example, WTRU can 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 can determine whether to share a COT based on the amount of available resources that can be determined within the duration of the COT (e.g., based on sensing). Specifically, if the amount of resources available within the duration of the COT and / or within the required delay is higher than a threshold, the WTRU can decide to share the COT; otherwise, the WTRU can decide to initiate a new COT.

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

[0259] WTRU can determine its LBT behavior based on specific network scheduling nodes (such as base stations (gNBs), cells, etc.).

[0260] The first WTRU may transmit the network node ID (e.g., cell ID, base station (gNB) ID, etc.) during transmissions on its sidelink, possibly as part of COT information. When the WTRU is scheduled in mode 1, the WTRU may include a network node. Alternatively, the WTRU in mode 2 may transmit the network node ID while performing mode 2 transmissions, while being within the coverage area of ​​a specific network node and / or under RRC_CONNECTED.

[0261] The LBT behavior of the second WTRU can be determined based on any 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 scheduling of the second WTRU itself (e.g., the cell ID of the scheduling WTRU in mode 1, or the cell ID of the WTRU when it is in RRC_CONNECTED and residing in RRC_IDLE / RRC_INACTIVE in mode 2); whether the second WTRU is in-coverage or out-of-coverage, and may belong to the same node; the transmission mode of the second WTRU transmission (mode 1 or mode 2); and other factors that affect the LBT behavior described herein.

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

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

[0264] In one implementation, LBT behavior (e.g., whether a WTRU can share a COT) can 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 can determine its LBT behavior based on whether the L2 ID of a transmission associated with the LBT matches any L2 ID included in the received list. The list of L2 IDs received by the WTRU may represent L2 IDs of interest associated with another WTRU, possibly in cases where such a WTRU has already initiated a COT. This allows the sidelink system to restrict COT sharing to transmissions where the WTRU initiating the COT should be the intended recipient of the transmission sharing the COT.

[0265] In one implementation, the 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 this 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 whenever such information changes (i.e., changes to the destination L2 ID signaling by the upper layer, additions / removals of the WTRU itself and its associated unicast links, etc.). Alternatively, the first WTRU may send this list along with a transmission within its own COT. For example, the first WTRU may send the list in a MAC CE included in its SL transmission.

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

[0267] In another implementation, 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 which transmission to apply that list to the first WTRU based on the source / destination L2 IDs provided by the list from the base station (e.g., the gNB). In another example, the second WTRU may receive a list of associated L2 destination IDs from the base station (e.g., the gNB). Such a list of associated destination L2 IDs may represent multicast transmissions where a COT can be shared. For example, if the L2 destination IDs transmitted by the first WTRU and the destination L2 IDs transmitted by the second WTRU appear in the same list, the second WTRU may share the COT with the first WTRU.

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

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

[0270] In another determination, if a first WTRU transmission is unicast to a second WTRU, the second WTRU can share a 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 multicast / broadcast, the second WTRU can share the COT as long as it is performing a multicast / broadcast transmission associated with a destination L2 ID that matches a destination L2 ID in a list received from the first WTRU. Alternatively, if the first WTRU transmission is multicast / broadcast, the second WTRU can share the COT as long as it is performing a multicast / broadcast transmission to the same destination L2 ID as the first WTRU's transmission. Furthermore, the second WTRU can only use this latest condition if it does not have a list associated with the first WTRU.

[0272] The above implementation scheme can be extended to any behavior associated with LBT to access a channel for a second WTRU, as described herein. Specifically, the second WTRU can use this list to determine whether to perform a first type or a second type of LBT. For example, the second WTRU can use this list to determine whether to use a first CW or a second CW.

[0273] A WTRU can determine whether to share a COT based on multiple conditions associated with different factors being met, or at least one condition associated with different factors being met. For example, a WTRU can share a COT if the time between a previous transmission and the WTRU's planned transmission is less than a threshold, and the L2 destination of the WTRU's transmission matches the L2 ID of the transmission initiating the COT. A WTRU can also share a COT if the L2 destination ID of the WTRU's transmission matches the L2 destination ID of the transmission initiating the COT, or if the distance between the WTRU and the transmission initiating the COT is less than a certain distance.

[0274] WTRUs can use different conditions / factors to determine whether to share 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 WTRUs can share COT as long as the L2 IDs match, and if the time between the previous transmission and the WTRU's own transmission is within a second range, then WTRUs can share COT as long as the distance between them is less than a threshold.

[0275] Figure 2 This is a diagram illustrating an example of unicast COT sharing. (See diagram for example.) Figure 2 As shown, if the second WTRU 204 initiates a COT for a transmission associated with the same unicast link as the first WTRU 202's transmission, then the first WTRU 202 can share the COT. The first WTRU 202 can make this determination based on the L2 source / destination IDs included in the SCI of the initiating link. Specifically, if the L2 source ID of the first WTRU 202's transmission is the same as the L2 destination ID of the second WTRU 204, and the L2 destination ID of the first WTRU 202's transmission is the same as the L2 source ID of the second WTRU 204, then the first WTRU 202 can 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 having a unicast link with the first WTRU 202, the first WTRU 202 can share the COT regardless of the destination of the transmission from the first WTRU 202. Specifically, if the COT is initiated by a transmission with a source / destination L2 ID pair corresponding to a unicast link active at the first WTRU 202, the first WTRU 202 can share the COT for any transmission.

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

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

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

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

[0281] The WTRU that initiates a specific type of COT can be configured with LBT behaviors to be used when initiating such a COT (as defined in this document) (e.g., CW size, maximum allowed COT length, etc.).

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

[0283] A 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., playback, HARQ enabled, mode, etc.); (2) the measured CBR; (3) the 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 that may come from higher layers, which are associated with the number of WTRUs in the area, or a potential attempt to share resources. For example, based on one or a combination of the above factors, a WTRU may decide to initiate a general COT or a specific type of COT.

[0284] In one implementation, the WTRU can determine COT sharing rules based on whether the WTRU is able to listen to the specific WTRU that initiated the COT and / or the level of indirection of such WTRU that initiated the COT (e.g., whether the WTRU can share the COT, the maximum time the WTRU can share the COT after the transmission, and / or the maximum time for applying a specific type of LBT). For example, the WTRU that initiated the COT may be a WTRU that performs type 1 LBT (or full LBT) before performing its transmission.

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

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

[0287] For example, the WTRU can determine the type of LBT to perform for sharing the COT with its peer WTRU based on a combination of indirection levels and time slots between transmissions. Specifically, for a given time slot since the last transmission in the COT, the WTRU can use a first LBT type for the first indirection level, a second LBT type for the second indirection level, and so on.

[0288] Figure 3 This is a diagram illustrating an example of multicast / broadcast COT sharing. (See diagram for example.) Figure 3As shown, WTRU 302 can initiate COT using the first LBT parameter set (i.e., LBT(0)). Because WTRU 302 initiates COT, it can send the indirect value 0 in the SCI transmission 320 within COT.

[0289] WTRU 304 can receive COT information from WTRU 302 and decide to share COT with WTRU 306. WTRU 304 can use the second LBT parameter set (i.e., LBT(1)) to perform the LBT procedure, as it represents indirection level 1. WTRU 304 can also send indirection value 1 in SCI transmission 322.

[0290] WTRU 306 behaves similarly to WTRU 304. WTRU 306 can receive COT information from WTRU 304 and decide to share COT with WTRU 308. WTRU 306 can perform the LBT procedure using the third LBT parameter set (i.e., LBT(2)), as it represents indirection level 2. WTRU 306 can also send indirection value 2 in SCI transmission 324.

[0291] WTRU 308 detects COT information from WTRU 302 and WTRU 306, but with conflicting indirection numbers, for the same COT. WTRU 308 receives indirection value 2 from WTRU 306 via SCI transmission 224 and indirection value 0 from WTRU 302 via SCI transmission 326. WTRU can decide to follow the minimum indirection number 0 from WTRU 302 and behave as the WTRU within the first indirection level. Furthermore, WTRU 308 can send indirection value 1 to another WTRU in any SCI transmission 328.

[0292] A potential problem with distributed COT sharing stems from the hidden node problem. Specifically, the first WTRU can initiate a COT and send COT information. A second WTRU, which did not receive COT information from the first WTRU (due to the hidden node problem), can also initiate its own COT. The second WTRU can initiate a COT during the first WTRU's COT period. This can cause the sidelink WTRU to occupy the channel for longer than the fairness requirement.

[0293] In one implementation, the WTRU can modify its assumed COT structure after receiving a conflicting COT structure from another WTRU. A conflicting COT structure may include different assumed LBT behaviors associated with the COT (e.g., different CAPCs, different desired LBT types, etc.). For example, if the received CAPC is lower / higher than the assumed CAPC, the WTRU may consider this a conflict. A 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 the event of a conflict, the WTRU can adopt COT information received from other WTRUs. The WTRU can also modify its transmitted COT information to comply with the new information. When a WTRU receives conflicting COT structure information, if the received COT structure does not allow transmission, the WTRU may cancel the planned transmission. The WTRU can notify the network upon receiving a conflicting COT structure.

[0295] In another implementation, the SL WTRU configured for SL transmission on unlicensed spectrum in Mode 1 can receive SL grants from the base station and determine whether the SL grant falls within a COT initiated by another WTRU based on COT structure information received from SCI transmissions of other WTRUs. If the SL grant falls within a COT initiated by another WTRU, the WTRU can perform a first LBT type to attempt to share the COT. If the SL grant does not fall within a COT initiated by another WTRU, the WTRU can perform a second LBT type to attempt to initiate its own COT. For this grant, if the LBT fails, the WTRU can report the failed LBT to the base station in the UCI.

[0296] If LBT is successful, the WTRU can 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 initiated its own COT or is sharing another WTRU's COT. For a WTRU-initiated COT, the WTRU can determine the COT length based on data multiplexed in the SL grant. For a shared COT, the WTRU can determine the COT length based on the COT length received in the SCI of another WTRU.

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

[0298] In one implementation, the SL WTRU can determine whether it can share a COT initiated by another WTRU by receiving COT information, including the indirection number associated with the COT, and LBT parameters for transmission within that COT, from one or more other WTRUs. 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, the SL WTRU determines it can share the COT and performs LBT using the parameters determined by the indirection number and priority. If the WTRU acquires the channel, it can transmit an indirection number one greater than the received indirection number. Otherwise, the WTRU can determine it cannot share a COT initiated by another WTRU and can initiate its own COT.

[0299] In another implementation, the WTRU operating in Mode 2 may perform resource selection based on the presence and / or structure of existing or anticipated COTs on the SL. COTs may include COTs initiated by other WTRUs (and indicated by those WTRUs in the SCI), or COTs initiated by the WTRU performing the resource selection. In this document, an existing COT is a COT that has already been initiated by a WTRU or another WTRU via a transfer through the SCI (possibly after the complete LBT process). As a result of notifying future transfers performed by WTRUs in the SCI, an anticipated COT may include resources or sets of resources that can be expected to be part of a COT. The resource selection methods described herein, depending on the presence of COTs, can be applied to existing or anticipated COTs with potentially the same / different rules.

[0300] The WTRU performing the Mode 2 resource selection can consider the existence and / or structure of the existing or anticipated COT by selecting resources within or relative to the COT, including restricting resource selection to resources within the COT or prioritizing resources within the COT. In the context of resource selection, prioritizing resources within a 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 larger number of resources within the COT than outside the COT; (3) selecting resources within the COT more times than 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) (to the MAC layer) providing available resources for resource selection such that the percentage of available resources residing within the COT is greater than the percentage of available resources residing outside the COT; and (7) (to the MAC layer) providing available resources for resource selection such that the amount or ratio of available resources within the COT is greater (compared to the case where prioritization of resource selection within the COT is not performed). Resource selection may include ensuring that the selected resources begin within the COT. Resource selection may also include ensuring that the start of the resource occurs at the maximum time after the initiation of the COT, thereby ensuring that at least the initial transmission resource is within the COT.

[0301] The WTRU performing mode 2 resource selection can consider the existence and / or structure of existing or desired COTs by selecting resources associated with a specific type of COT. The type of COT can be a COT associated with one or more factors described herein (e.g., indirection number meets a criterion, playback type is associated with a specific criterion, L2 ID meets a criterion, etc.). A COT type can be one where, for that COT, the selected (if initiated by the WTRU) or indicated (if initiated by another WTRU) COT has a specific value or is below / above a threshold. Resources can be associated with FBE resources or LBE resources. The type of COT can 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] The WTRU performing resource selection in Mode 2 can select resources by determining parameters associated with resource selection based on the existence and / or structure of the COT, taking into account the existence and / or structure of existing or anticipated COTs. This determination may include using a first set of parameters when performing selection within a COT or COT type, and a second set of parameters when performing selection outside a COT or in another COT type. The time interval 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 falls within the remaining time in the COT. This determination may include adjusting the resource selection parameters based on the timing of the resource relative to the start / end of the COT.

[0303] The WTRU can 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 consecutive resources that the WTRU should select; resource patterns, such as the minimum / maximum time between transmissions / retransmissions, the number of time-continuous resources / frequency-continuous resources to select; the maximum / minimum number of RBs; the duration of a given transmission / retransmission resource; the total number of resources that can be selected, which may be associated with COT / COT type; and whether to perform / allow periodic resource selection or single resource selection.

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

[0305] These conditions can be related to the type of data available for transmission (e.g., QoS, LCH, MAC CE to data, SRB to DRB, etc.). A condition can be the existence of data available for transmission with a specific priority. A condition can be whether the available data consists only of MAC CEs, or whether the available data includes both MAC CEs and data, or only data. For example, a condition can be whether the available data consists only of SRB bits, or whether the available data includes SRB data. A condition can be the existence of control information available for transmission, which may have a specific priority. The control information can be an SCI multiplexed on data resources or an SCI transmitted on control resources.

[0306] This condition can be associated with configured conditions, which are linked to data. For example, one or more LCHs can be configured to have the specific behavior described herein with respect to resource selection associated with COT. An LCH can trigger resource selection from an LBE / FBE resource. For example, if data is available for a specific LCH associated with the configured condition, the WTRU can select a resource by considering the COT information / structure. Otherwise, the WTRU can select a resource without considering the COT structure during resource selection. For example, the condition could be whether the LCH is configured with enabled or disabled HARQ. The condition could also be whether the LCH is configured with MCR and / or a value related to the MCR.

[0307] This condition can be related to SL measurements, such as CBR, SL RSRP, and SL CSI. For example, this condition could be an SL CBR or SL RSRP associated with a unicast link that is higher / lower than a threshold.

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

[0309] This condition can relate to the existence of a COT initiated by the WTRU that performs resource selection. For example, the condition could be that the WTRU has a COT for the activity it initiates during resource selection.

[0310] This condition can be related to the presence, ratio, or quantity of available resources falling within the COT. For example, this condition could be that the percentage of available resources falling within the COT is higher than a threshold.

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

[0312] This condition can 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 can select a resource. Retransmissions might be due to a previous LBT failure, a receive / acknowledge NACK, or the absence of a HARQ response for the already transmitted TB. In one example, if the WTRU receives a NACK, an LBT failure, and / or does not receive a HARQ response, the WTRU can use a different resource or resource pool to retransmit the TB. If no HARQ response is received within the expected time after the TB transmission, the WTRU can monitor for HARQ responses on a different resource or resource pool.

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

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

[0315] In one implementation, the WTRU can associate resources (such as time slots, time slot sets, subchannels, subchannel sets, etc.) with one or more attributes that are associated with the COT.

[0316] In one implementation, a resource may be considered to be inside or outside the COT, or partially overlapping with the COT (i.e., part of the resource is inside the COT and part of the resource is outside the COT). For example, if the remaining time of a resource in the COT ends, then the resource may be inside the COT. In another implementation, a resource may be considered to be in the COT for a given number of indirections or its range, as described herein; or

[0317] In another implementation, a resource can be considered either FBE (Frame-Based Equipment) or LBE (Load-Based Equipment). Specifically, a resource can be labeled as one that allows channel access using FBE rules or channel access using LBE rules. The WTRU can determine this access type based on configurations from higher layers (e.g., RRC or SIB configurations) or based on LCH configurations (e.g., some LCHs can be transmitted on FBE resources).

[0318] The WTRU can be (pre-)configured or pre-defined to allow the COT to be (re)shared with other WTRUs a certain number of times. Configuration from the upper layer can configure the COT to be shared no more than x times. The WTRU can include the number of times the COT has been shared and the remaining time in the COT within the SCI or the COT sharing the MAC CE. If the WTRU acquires the COT for the xth time, the WTRU can omit the SCI or the MAC CE associated with the COT shared with other WTRUs. Alternatively, the WTRU can include an indication that the COT can no longer be shared (e.g., in the SCI or MAC CE). The WTRU can stop using the COT at the end of the xth transmission after it has been acquired, or the WTRU can hold the COT until the MCOT completes.

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

[0320] WTRU can semi-statically determine the offset based on configuration values, or determine the time to the next available resource. Alternatively, WTRU can dynamically determine the offset. Dynamic determination may depend on: (1) the priority of the data associated with the TB; (2) whether the data is reused from one or more LCHs configured with high-priority indexes; (3) whether the data is reused from a subset of the configured LCHs or a subset of the configured DRBs; (4) the subscription type of WTRU; or (5) the HARQ procedure ID selected for the TB. After a failed LBT attempt, WTRU can increment the offset or use a different resource with a different starting offset.

[0321] The WTRU can start a retransmission timer to measure the retransmission period when a TB fails to retransmit an LBT. The WTRU can only start the retransmission timer if a HARQ-ACK with a value of NACK is determined for the HARQ procedure. The WTRU may not attempt to acquire the channel during the retransmission period. The value of the timer or time period can be configured by the upper layer or dynamically changed based on previous LBT attempts or a selected timing offset used to acquire the channel.

[0322] The WTRU can be configured with retransmission timers for each resource pool, each SL carrier, each LBT bandwidth / subband, or each MAC entity. In one example, the WTRU can start a timer after an LBT failure on a given resource pool. While a timer associated with a resource pool is running, the WTRU may not select a resource to retransmit or send a TB on that resource pool. If the timer associated with that pool is not running, and / or if a HARQ procedure ID is configured for that resource pool, and / or TB size is supported, the WTRU may (re)transmit a TB on a different resource pool than the last selected resource pool.

[0323] The WTRU can prioritize / select resources within the COT or relative to the COT's time position. The WTRU can determine a set of available resources, where a subset of resources may include those within the COT, and other resources may not be within the COT. Under certain conditions described herein, the WTRU may be able to select resources within the COT or prioritize those 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 either within the COT or not. 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] WTRU can identify multiple resources available for selection and perform transmission or retransmission.

[0325] The WTRU can prioritize resource selection based on the remaining time in the COT. The WTRU can prioritize resource selection in descending order of remaining COT time. The WTRU can 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 control information notified by signaling) or based on the remaining time in the COT determined by the resource's start time and / or the timing of previous transmissions in the same COT.

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

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

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

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

[0330] In one implementation, the WTRU can determine a set of selectable resources. The WTRU can select or prioritize resources that appear at the beginning or end of the COT, up to a threshold number of time slots. Alternatively, the WTRU can select or prioritize resources that require one or more LBT types to acquire the channel, and can choose not to select resources that require one or more different LBT types to acquire the channel or lower their priority. The WTRU can select or prioritize resources that appear at a threshold number of time slots from transmissions of the current WTRU or another WTRU (as detected in the SCI) or planned transmissions (as determined based on forward observation information in the SCI). The WTRU can select or prioritize resources that are no more than a few time slots apart from the transmissions of the current WTRU or another WTRU based on any of the conditions mentioned herein (e.g., if the measured CBR is higher than a threshold, if the available data for transmission is higher than the threshold priority, etc.).

[0331] In one implementation, the WTRU can 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 can select or prioritize resource transfers within the COT. The WTRU can perform such operations based on conditions described herein, such as a measured CBR above a threshold and / or the priority of available data for transfer above a threshold.

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

[0333] In one implementation, the WTRU can select or prioritize resources associated with a specific COT type. In one example, when data available for transmission is associated with multicast (potentially having the same L2 ID), the WTRU can select or prioritize resources associated with the multicast COT to perform resource selection. For instance, the WTRU can select resources associated with a COT initiated by any WTRU on a unicast link, perhaps in a case where resource selection is initiated when data available for transmission is associated with a transmission to that unicast link.

[0334] In another example, the WTRU can select or prioritize resources if the number of indirections is below a threshold (possibly under specific conditions described herein). In yet another example, the WTRU can select or prioritize resources that are FBEs under one condition, or select or prioritize resources that are LBEs (or vice versa) if the number of indirections is below a threshold. Such conditions can be based on the measured CBR. Such conditions can be based on the priority of the data. Such conditions can also be based on the attribute of the LCH with the highest priority for which data is available.

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

[0336] When selecting resources within a COT, the WTRU can select a first maximum number of RBs, and when selecting resources outside a COT, the WTRU can select a second maximum number of RBs. The WTRU can only select resources associated with an FBE if those resources are used for periodic transmissions. Otherwise, if resource selection is triggered for a single transmission, the WTRU can select resources only from those associated with an LBE, or it can select resources from those associated with either an FBE or an LBE.

[0337] When a resource is associated with an LBE, the WTRU can select the resource using demand with several consecutive time slots available for transmission, and when a resource is associated with an FBE, such demand may not be used. The WTRU can determine the permissible periodicity of resource selection for multiple resource selections based on the configured and / or determined available FBE resources.

[0338] WTRU can determine the number of permissible retransmissions for a TB based on the COT duration (e.g., possibly indicated in a single SCI).

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

[0340] When executing a resource selection process that initiates a COT at the WTRU, the WTRU can determine the maximum time between transmission / retransmission / selected resource based on the priority / CAPC of the data available for transmission at the time of resource selection. Specifically, the WTRU can be configured with a first allowed time for the first priority / CAPC, a second allowed time for the second priority / CAPC, and so on.

[0341] When a WTRU initiates its own COT, it can select consecutive time resources. Conversely, when a WTRU is transmitting within a COT that has already been initiated (either by itself or by another WTRU), it may not be necessary for the WTRU to select consecutive time resources. The amount of consecutive resources (e.g., allowed, required) can also depend on the conditions described herein (e.g., CBR, CAPC, priority of the data triggering resource selection, playback, SL measurement, etc.).

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

[0343] One advantage of the above implementation is that it allows the WTRU to use resources to perform transmissions on unlicensed spectrum, which are selected by the WTRU based on the required LBT rules for transmission on unlicensed spectrum. For example, because the WTRU may need to perform a CAT4 LBT before transmission, the initiation of COT may require contiguous resources. Specifically, if the LBT fails in the first time slot, the WTRU can still transmit in a subsequent time slot because the WTRU has already selected the subsequent time slot during resource selection. To share COT, the WTRU can perform short LBTs and the number of (potentially contiguous) resources that need to be selected can be smaller.

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

[0345] One condition could be that the WTRU's LBT fails, possibly multiple times consecutively, or possibly for multiple selected (potentially consecutive) resources. Another condition could be that the WTRU fails to initiate a new COT for transport purposes. Yet another condition could be that the WTRU fails to share a COT initiated by another WTRU (i.e., the WTRU's short LBT fails within an existing COT).

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

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

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

[0349] In one example, the first TX WTRU can initiate LBT on a resource that is future-announced directly indicated by a previous SCI. The first TX WTRU can maintain the periodicity of the planned resource maintenance schedule (compared to the first transmission), regardless of the number of LBTs that failed before the first transmission succeeded. Alternatively, the first TX WTRU can change the planned interval between the first and second transmissions by an amount that depends on the number of LBTs that failed to execute the first transmission. Specifically, the first TX WTRU can reduce the planned interval for the second transmission by several time slots, possibly equal to the number of time slots for which the LBTs failed for the first transmission. As the second TX WTRU (the TX WTRU that performs sensing to determine available resources), when performing resource selection, the second TX WTRU can assume that the resource indicated by the previous SCI and several subsequent (possibly consecutive) time slots are considered unavailable.

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

[0351] A WTRU can trigger preemption / reassessment 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 resource, the WTRU can trigger preemption / reassessment. The WTRU can then perform a reassessment and select a new resource for transmission as a result.

[0352] In another example, if a WTRU receives an SCI indicating that the COT was initiated by another WTRU and the COT overlaps with the selected resource at that WTRU, the WTRU may trigger preemption / reassessment. If the CAPC associated with the COT differs from (e.g., higher priority, lower priority) the CAPC assumed by the WTRU when selecting its (overlapping) resource, the WTRU may further trigger preemption / reassessment.

[0353] In another example, if a WTRU receives an SCI indicating that a COT was initiated by another WTRU, the WTRU can trigger preemption / reassessment, where the COT may occur earlier than the selected resource. Such preemption / reassessment can be further triggered if the resource selected / reserved by the WTRU needs to initiate a COT (potentially when a COT initiated by another WTRU can be shared by the WTRU). In this case, the WTRU can reselect the resource only within the COT indicated in the received SCI.

[0354] The advantage of this implementation is that when the WTRU determines that the COT has been initiated (possibly by another WTRU), a reselection can be performed at the WTRU, and the WTRU can use the COT for transport (instead of initiating its own COT).

[0355] The WTRU can receive (e.g., in Mode 1), selectively (e.g., in Mode 2), or configure multi-time side-link data transmission resources. A multi-time resource consists of more than one potentially consecutive data transmission opportunity, on which LBT opportunities may exist. The WTRU can attempt LBT at each opportunity until LBT succeeds. Once LBT succeeds, the WTRU can transmit on the remaining opportunities in the resource without performing LBT again. For each data transmission opportunity, the WTRU can attempt to transmit the same TB that failed with LBT or a different TB.

[0356] In one implementation, the WTRU sharing the COT can indicate a multi-time resource to be shared with one or more WTRUs, whereby the sharing WTRU signals a start time to each shared WTRU at which the resource can be started and / or used; such indication can be provided by an SCI or MAC CE. Upon receiving 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 pre-configured threshold (e.g., the gap for a Type 1 LBT), the shared WTRU can perform a short LBT (e.g., Type 1 or 2) before starting transmission at the indicated time for the shared WTRU, or simply transmit without an LBT. The sharing WTRU can indicate possible remaining start times in the COT, and the shared WTRU can randomly select a time from the indicated times to acquire the channel.

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

[0358] The Mode 2 resource pool can be configured with several timings and a start time for multi-timing resources. The WTRU can determine the HARQ procedure based on the timing of the first timing within the multi-timing combination packet. The WTRU can maintain the same HARQ procedure until LBT succeeds. Once LBT succeeds, the WTRU can increment or change the HARQ procedure (e.g., if the WTRU has other data to send).

[0359] In one implementation, a multi-time resource may include multiple resource pools, whereby each time slot may be associated with one or more resource pools. The WTRU may be configured with a resource skipping mode such that if LBT fails on one time slot, the WTRU attempts LBT on the next time slot, which may be associated with a different resource pool.

[0360] In Mode 2, a WTRU that selects multiple LBT timings can choose multiple resources for its own transmission. Multiple LBT timing resources can include the same frequency resources in consecutive or discontinuous time slots. Alternatively, multiple LBT timing resources can include different frequency resources in the same or different time slots.

[0361] A WTRU can select multiple resources for its initial transmission and then select only a single set of resources for its retransmissions. Alternatively, a WTRU can select multiple resources for its initial transmission and, for each resource in its initial transmission, select multiple resources for each retransmission. Whether a WTRU selects a single retransmission resource (set) or multiple such retransmission resources for each initial transmission resource can depend on the same conditions described below for whether a WTRU uses multiple LBT timing selection. For example, whether a WTRU selects a single retransmission resource (set) for each initial transmission resource can 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 appears within the COT.

[0362] In another implementation, the WTRU can perform an initial transmission or retransmission on any of the multiple LBT timing resources. Specifically, after a successful LBT on the multiple LBT timing SL resource, the WTRU can perform an initial transmission, followed by retransmissions on the remaining resources of the multiple LBT transmission resource. The WTRU can also assume that transmissions on the remaining resources after a successful LBT do not require an LBT (or require a different LBT type).

[0363] The Mode 2 WTRU can select multiple LBT timings and / or the number of retransmission resources for each initial transmission resource based on certain conditions. Specifically, the Mode 2 WTRU can determine the selection of multiple LBT timings and / or the number of retransmission resources for each initial transmission resource based on satisfying any one or a combination of the following:

[0364] In Mode 2, the WTRU can determine the selection of multiple LBT timings and / or the number of retransmission resources for each initial transmission resource based on resource selection performed on the resource pool associated with the unlicensed operation. For example, if selection is performed on the resource pool associated with an unlicensed SL, the WTRU can select multiple LBT timing SL resources, and such selection may not be performed if the resource pool is on non-shared spectrum (non-unlicensed spectrum).

[0365] In Mode 2, the WTRU can determine the selection of multiple LBT timings 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 can select multiple LBT timing SL resources; otherwise, the WTRU can not select multiple LBT timing SL resources (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 can select a single retransmission resource (set) for the initial transmission resource. Otherwise, the WTRU can select multiple (e.g., multiple LBRT timings) SL resources for each retransmission.

[0366] The Mode 2 WTRU can determine the timing of multiple LBTs 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 the transmission requires a specific LBT type (e.g., Type 1 LBT, Type 2 LBT), the WTRU can select multiple LBT timing SL resources; otherwise, the WTRU can perform conventional resource selection.

[0367] Mode 2 WTRU can determine the selection of multiple LBT timings 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 higher than a threshold, the WTRU can select multiple LBT timings (SL) resources; otherwise, the WTRU can perform conventional resource selection.

[0368] Mode 2 WTRU can select multiple LBT timings 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, WTRU can select only a single retransmission resource (set) for all initial transmission resources associated with multiple LBT timings.

[0369] Mode 2 WTRU can determine the timing of multiple LBTs and / or the number of retransmission resources for each initial transmission resource based on any congestion metric of the measured CBR or SL. For example, if the measured CBR is below a threshold, the WTRU can select multiple LBT timings for SL resources; otherwise, the WTRU can perform conventional resource selection.

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

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

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

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

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

[0375] A WTRU's LBT (Local Time-Based Test) may fail on one or more individual resources within a multi-LBT timing resource. In this case, the WTRU can initiate or continue the LBT on the next resource within the multi-LBT timing resource. A remote WTRU can perform the LBT on each subsequent resource within the multi-LBT timing resource until the LBT succeeds, or until the WTRU has exhausted its LBT attempts on every resource within the multi-LBT timing resource.

[0376] When LBT succeeds on one of the resources in a multi-LBT timing resource, WTRU can perform any of the following or a combination thereof:

[0377] When an LBT succeeds on one of the resources in a multi-LBT timing resource pool, the WTRU can perform a transfer on the resource associated with the successful LBT. Specifically, the WTRU can perform the initial transfer on the resource following the successful LBT. The WTRU can also determine whether it is able to perform the initial transfer on the resource following the successful LBT, or whether it should select a subsequent resource (not necessarily the one immediately following the successful LBT), based on the conditions described herein. Specifically, the WTRU can determine whether to perform a transfer on the first resource following the successful LBT if the priority of 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 of these factors along with other factors described herein.

[0378] When an LBT succeeds on one of the resources in a multi-LBT timing resource pool, the WTRU can perform a transfer on the subsequent resource associated with the successful LBT. Specifically, the WTRU can select one of the remaining resources associated with the multi-LBT timing resource pool on which to begin a transfer, and can initiate a transfer on the selected resource. The WTRU can select a resource based on the following:

[0379] WTRUs can select resources based on priority. For example, WTRUs can be (pre-)configured with a mapping between priority / QoS and the resources on which transmissions will be initiated after a successful LBT. Specifically, a WTRU with higher priority transmission can initiate transmissions immediately (or earlier) among the remaining resources in a multi-LBT resource pool, while a WTRU with lower priority transmission can initiate transmissions later after a successful LBT.

[0380] The WTRU can select resources based on the remaining PDB. The WTRU can determine which resource among the remaining resources after a successful LBT to initiate a transmission on. For example, the smaller the remaining PDB, the earlier the WTRU can initiate a transmission. The WTRU can (randomly or based on other rules in this document) select the resource for initiating a transmission after a successful LBT, ensuring that the transmission and any subsequent retransmissions are performed before the PDB times out.

[0381] The WTRU can select resources based on random or probabilistic rules. For example, the WTRU can randomly select a resource from the remaining resources of a multi-LBT timing on which to initiate a transmission, and that resource may further satisfy any other criteria. The WTRU can be configured with a probability (which may depend on or be determined by other factors in this document) to initiate a transmission on any remaining resource of a multi-LBT timing.

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

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

[0384] The WTRU can perform transmissions on multiple resources across multiple LBT resources after a successful LBT. For example, the WTRU can decide to perform transmissions on multiple (potentially time-contiguous) resources across multiple LBT resources starting from a successful LBT. The WTRU can determine whether to perform multiple transmissions and the number of subsequent retransmissions based on any one or a combination of the following:

[0385] WTRU can determine whether to perform multiple transmissions and the number of subsequent retransmissions based on transmission priority / QoS. For example, if the TB priority is higher than a threshold, WTRU can be allowed to use multiple remaining resources after a successful LBT for transmission and retransmission.

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

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

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

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

[0390] The WTRU can continue performing the LBT or perform a shorter LBT. For example, after a successful LBT in a multi-LBT period, if the WTRU decides to perform transmission in multiple time slots following the successful LBT (as determined based on the conditions herein), the WTRU can continue performing the LBT, or it can perform a short LBT before the resources selected for the actual transmission following the first successful LBT in a multi-LBT period. For example, the type of LBT can further depend on the time between the first successful LBT and the selected resources for the transmission within the multi-LBT period. Specifically, if the WTRU decides to transmit immediately after the first successful LBT, or at most N time slots after the first successful LBT, the WTRU can transmit without a short LBT.

[0391] WTRU can be configured to perform a recovery procedure in the event of a failure associated with acquiring a resource selected during multiple LBT events. WTRU can typically be configured to perform a recovery procedure generally on the event of any failure associated with LBT (e.g., after one or more SL LBT failures). Such a recovery procedure can be any of the following:

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

[0393] The triggering of the recovery process can be associated with the attributes of the multi-LBT resources. WTRU can trigger the recovery process (potentially several times consecutively, or several times within a time window) when resource selection fails to select an appropriate set of available resources for the multi-LBT timing. An appropriate number of available resources may include finding at least N consecutive single-slot resources within the resource selection window.

[0394] WTRU can trigger a recovery process when LBT failures occur on all resources associated with multiple LBT events (possibly several consecutive times or several times within a window).

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

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

[0397] Specifically, LCP restrictions can be performed by the WTRU during the selection of the L2 destination ID and / or the selection of the logical channel for transmission on the side link. LCP restrictions can involve one of the following attributes associated with the grant:

[0398] LCP restrictions can be related to whether the authorization is within an existing COT (i.e., whether the authorization is associated with WTRU creating a COT).

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

[0400] LCP restrictions can be related to whether the authorization is within the COT and whether the COT is initiated by a unicast / multicast / broadcast transmission.

[0401] LCP restrictions can be related to whether the authorization is within the COT and the source / destination L2 ID of the WTRU that initiated the COT.

[0402] LCP restrictions can be related to whether the authorization is mode 1 or mode 2.

[0403] LCP limitations can 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] LCP limitations can be related to whether the license is within the COT, the number of SL transmissions already performed within the COT, the channel occupancy measured within the COT (CR, CBR, or the number of reserved / used sub-channels), transmissions based on other WTRUs, or transmissions of the WTRU itself.

[0405] LCP restrictions can be associated with the CAPC of the COT where the authorization is located. For example, a WTRU can be allowed to reuse data from 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 trying to share.

[0406] For example, a WTRU can receive a CAPC within a COT initiated by another WTRU. The WTRU can restrict the selection of LCHs that can be reused in the authorization to LCHs with priorities associated with the CAPC, such as: a list of allowed priorities associated with the CAPC; priorities higher than a threshold determined based on the CAPC; and / or priorities that have some relationship with the CAPC priority (e.g., greater than or equal to the CAPC priority, and not less than a certain number of levels lower than the CAPC priority).

[0407] LCP restrictions can be associated with authorizations in a COT initiated by a WTRU or shared with another WTRU. For example, it may be permissible for a WTRU to reuse data of a certain priority or priority range in an authorization used to initiate a COT; for WTRUs to share COT authorizations; and for WTRUs to transmit on a COT they have already initiated. Furthermore, combinations of each of these three cases are possible. For example, in an authorization where a WTRU will initiate and / or has already initiated its own COT, it may be permissible for the WTRU to reuse data at a priority higher than / lower than a threshold.

[0408] For example, a WTRU can be configured with a first priority restriction rule for authorizations within a COT initiated by another WTRU, and a second priority restriction rule for COTs initiated by the WTRU itself. For instance, if an authorization falls within a COT initiated by another WTRU, the sending WTRU can select only LCHs with a priority at least as high as the priority / CAPC indicated in the COT information. If an authorization falls within a COT to be initiated by the WTRU itself, the WTRU can select any LCH priority to reuse in the COT.

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

[0410] LCP restrictions can be associated with attributes related to the COT and / or with the data sent in the authorization that initiated the COT, where such attributes can be playback type, destination ID, priority, WTRU group, delay, PDB, or any other SL attribute described herein. For example, WTRUs may be allowed to reuse data of a specific playback type in an authorization occurring within a COT, where such playback type is determined by the playback type associated with the COT (e.g., included in information within the COT) or the playback type used in the authorization that initiated the COT. Specifically, once a COT is used for a particular playback type, that COT needs to continue to be used for that playback type. Furthermore, restrictions can depend on the playback type itself. For example, WTRUs 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, WTRUs sharing a COT initiated by a broadcast transmission may select an L2 ID associated with multicast (possibly the same as the L2 ID of the initiating COT) or any unicast transmission. For example, WTRUs sharing a COT initiated by a broadcast transmission may select any L2 ID for transmissions that will share the COT.

[0411] For example, a WTRU can be allowed to reuse data with a specific L2 ID in an authorization occurring within a COT, where such an L2 ID is determined by the playback type associated with the COT (e.g., information included in the COT) or by the L2 ID used in the authorization that initiated the COT. Specifically, once a COT uses a specific L2 ID, the COT needs to continue using that L2 ID. Specifically, a WTRU with pending authorizations occurring within a COT initiated by a multicast / broadcast transmission can choose the same L2 ID used for transmissions on that authorization as the L2 ID of the transmission that initiated the COT.

[0412] LCP restrictions can be associated with the number of indirections, as described herein, and with the COT. For example, a WTRU can be configured with a set of LCHs that can / cannot be reused in licenses appearing within a certain number of indirections or a COT of the indirection set. Similarly, a WTRU can be configured with one or more playback types that can / cannot be reused in licenses appearing within a certain number of indirections or a COT of the indirection set.

[0413] LCP restrictions can be associated with transport modes (i.e., mode 1 versus mode 2). For example, a COT can be associated with a mode (i.e., mode 1 or mode 2), which can represent the resource selection mode used by the WTRU when initiating the COT. The WTRU can determine the transport mode used to initiate the COT based on information within the transport itself. The WTRU initiating the COT may include the operating mode (mode 1 or mode 2) used to initiate the COT. The WTRU can be configured with a set of LCHs that can / cannot be multiplexed in COTs associated with mode 1 and / or mode 2.

[0414] LCP restrictions can be associated with the data available for transmission and / or the MCR of the transmission initiating the COT. For example, the WTRU can determine the permissible L2 destination ID, LCH priority, or other restrictions on logical channels to be multiplexed in the license based on whether the COT is initiated by a transmission with or without an MCR. For instance, a WTRU sharing a COT initiated by a transmission with an MCR can select only the L2 ID that matches the L2 ID of the transmission initiating the COT. Otherwise, if the COT is initiated using a transmission without an MCR, the WTRU can select any L2 ID.

[0415] In another example, the WTRU can determine the permissible L2 destination ID, LCH priority, or other restrictions regarding logical channels to be multiplexed in the grant based on whether the WTRU using the grant is located inside / outside the MCR that initiated the COT transmission. For example, if the WTRU is located inside the MCR associated with the COT-initiating transmission, the WTRU can select any L2 ID and / or LCH priority for a shared COT grant. Otherwise, if the WTRU is located outside the MCR associated with the COT-initiating transmission, the WTRU can be restricted to selecting the same L2 ID and / or restricted to LCH priorities that can be multiplexed in the grant (e.g., only LCHs with a priority higher than or equal to the CAPC associated with the COT).

[0416] In another example, the WTRU can determine the permissible L2 destination ID, LCH priority, or other restrictions on logical channels to be multiplexed in the grant based on whether the MCR of the transmission initiating the COT is higher / lower than a threshold. For example, the WTRU may be configured with or can determine (e.g., based on other factors described herein) a threshold MCR. If the MCR for the PDU is higher than the threshold, the WTRU may be allowed to include logical channels with any priority. If the MCR is lower than the threshold, the WTRU may include only logical channels with a priority equal to or determined by the CAPC.

[0417] In addition, WTRU can determine the permissible L2 destination ID, LCH priority, or other restrictions on logical channels to be multiplexed in the grant based on any of the three combinations described above.

[0418] LCP restrictions can be based on the occupancy of SL resources within the COT. For example, the WTRU can determine the permissible destination L2 ID, LCH priority, or other restrictions based on the measured occupancy of SL resources within the COT. For instance, if channel occupancy within the COT is likely to be determined to be low (e.g., below a threshold), then when sharing the COT, the WTRU may include LCHs with lower priority (e.g., below the threshold, below the COT's CAPC, etc.). Alternatively, if channel occupancy within the COT is likely to be determined to be high (e.g., above a threshold), the WTRU may be restricted to LCHs with only high priority (e.g., above the threshold, below the COT's CAPC, 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 reused in authorizations occurring in a COT initiated by a base station (e.g., a gNB) or by another WTRU. For example, a WTRU may apply a first LCP restriction rule to a COT initiated by another WTRU and a second LCP restriction rule to a COT initiated by a base station (e.g., a gNB).

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

[0421] The WTRU can determine whether to apply LCP restrictions (such as any of the LCP restrictions mentioned above) based on SL factors or transport type, as identified herein. For example, the WTRU may apply LCP restrictions on a first resource allocation mode (e.g., mode 1) but not on a second resource allocation mode (e.g., mode 2).

[0422] Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, 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 (transmitted 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 internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile optical discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a first wireless transceiver unit (WTRU), the method comprising: The second WTRU receives a Link Control Information (SCI) from the first WTRU. The second WTRU initiates a Shared Channel Occupancy Time (COT) with the first WTRU. The SCI includes: (1) COT information, wherein the COT information includes the associated Channel Access Priority Class (CAPC) value; and (2) at least one of the following: (a) the source ID associated with the second WTRU or (b) the destination ID associated with the second WTRU; Using the shared COT; and During the shared COT, a type 2 LBT process for transmission is performed; 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. Wherein, if the shared COT is associated with a multicast type, the destination ID transmitted from the first WTRU matches the received destination ID associated with the second WTRU, and The CAPC value associated with the COT information and the CAPC value associated with the data used for transmission have the following values: the values ​​are selected from the group consisting of 1, 2, 3 and 4.

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

3. The method according to claim 1, wherein the second WTRU is the 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 the determination that the COT can be shared.

5. The method according to claim 1, wherein, The data is sent if the Type 2 LBT process is successful.

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

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

8. A first wireless transceiver unit (WTRU), the WTRU comprising: transceiver; and processor; The transceiver and the processor are configured as follows: The second WTRU receives a Link Control Information (SCI) from the first WTRU. The second WTRU initiates a Shared Channel Occupancy Time (COT) with the first WTRU. The SCI includes: (1) COT information, wherein the COT information includes the associated Channel Access Priority Class (CAPC) value; and (2) at least one of the following: (a) the source ID associated with the second WTRU or (b) the destination ID associated with the second WTRU; Use the shared COT; During the shared COT, a type 2 LBT process for transmission is performed; If the shared COT is associated with a unicast type, the processor is further configured to match the source ID of a transmission from the first WTRU with the received destination ID associated with the second WTRU, and to match the destination ID of a transmission from the first WTRU with the received source ID associated with the second WTRU; and If the shared COT is associated with a multicast type, the processor is further configured to match the destination ID transmitted from the first WTRU with the received destination ID associated with the second WTRU; and The CAPC value associated with the COT information and the CAPC value associated with the data used for transmission have the following values: the values ​​are selected from the group consisting of 1, 2, 3 and 4.

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

10. The first WTRU of claim 8, wherein the second WTRU is the 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 transmit the data upon successful completion of the type 2 LBT process.

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

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

Images